+1 to all changes.
Tim Bray wrote:
>
> 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
>
>
>
>
