Based on the discussion in the WG, I've made the following edits.
8.1 s/Location HTTP/HTTP Location/ per Bill, http://www.imc.org/atom-
protocol/mail-archive/msg05193.html
8.1 remove phrase " and SHOULD perform a GET on the member resource
before editing", per Bill.
8.1 added paragraph
" Note that since the server is free to alter the posted entry, for
example by
changing the content of the "id" element, returning the entry as
described
in the previous paragraph may be useful to client software,
enabling it
to correlate the client and server views of the new entry."
Per Bill, and Joe Gregorio: http://www.imc.org/atom-protocol/mail-
archive/msg05213.html
8.2 added, after the example
" In particular, the publishing system in this example filled in
some values
not provided in the original POST. For example, presumably it
ascertained the author's name via the authentication protocol used to
establish the right to post."
Per Bill et al
8.4, at end of section, added
" Note that this specification covers the cases when the POST body
is an Atom Entry, and
when it is of a non-Atom media type. It does not specify any
request semantics or
server behavior in the case where the POST media-type is
application/atom+xml but
the body is something other than an Atom Entry."
Per Bill and Gregorio http://www.imc.org/atom-protocol/mail-archive/
msg05200.html
7.2.4 Change the RNC fragment for appAccept: attribute rule was
appCommonAttributes to undefinedAttribute, per Bill
8.4, added to the 2nd paragraph
" If the server successfully creates a media resource and media
link entry pair, the Location header included in the response
MUST be that of the media link entry."
Per Scheid http://www.imc.org/atom-protocol/mail-archive/
msg05197.html and Snell http://www.imc.org/atom-protocol/mail-archive/
msg05198.html and Bray http://www.imc.org/atom-protocol/mail-archive/
msg05204.html
