A few more comments: Section 4:
Note that when an IRI is used for resource retrieval over HTTP, the IRI is first converted to a URI according the procedure defined in [RFC3987] section 3.1. The resource that the IRI locates is the same as the one located by the URI obtained after converting the IRI. IRI to URI conversion is mentioned at least twice in the spec. It would probably be a good idea to eliminate the duplicates Also, the protocol indicates that POST is used for creation of resources, however, POST is only defined on the Collection URI. There has been discussion about and there is an example of (gdata) using the POST method on Member resource edit URI's for purposes other than creation of resources. Perhaps it would make sense to include a note that the behavior of the POST operation on any URI other than the Collection URI is undefined. Section 5.3.2 1. The client PUTs an updated representation to the Member's URI. This should probably be "The client PUTs an updated representation to the Member's edit URI" given that there is a distinction between the Location URI and the edit URI as specified by the edit via (e.g. the gdata api). Also, 2. Upon a successful update of the resource the server responds with a status code of 200. Would not a 204 No Content be appropriate as well given that we're not requiring or recommending the update to return a response? Also, should we recommend that a PUT response contain the entry just like with POST requests? Section 5.3.3 1. The client sends a DELETE request to the Member's URI. Same as section 5.3.2 above. "The client sends a DELETE request to the Member's edit URI" 2. Upon the successful deletion of the resource the server responds with a status code of 200. Same as section 5.3.2 above, a 204 No Content would also be appropriate and is likely desirable in this case given that there is no response entity. Section 7.2.2 appCollection+ should be appCollection* Section 7.2.4 media-type = xsd:string { pattern = "entry,(.+/.+,?)*" } entry-or-media-type = xsd:string { pattern = "(.+/.+,?)*" } Aren't these patterns backwards? e.g. the media-type pattern belongs to entry-or-media-type. Section 8.2 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. Using the author's name in this example is odd given that the name *is* provided in the original post. Perhaps if the email address of the author were filled in on the created entry it would make more sense. Section 9 The entries in the returned Atom Feed MUST be ordered by their "atom: updated" property, with the most recently updated entries coming first in the document order. Clients SHOULD be constructed in consideration of the fact that changes which do not alter the entry's atom:updated value will not affect the position of the entry in a collection. If the client PUTs an atom:entry with an changed atom:updated, is the server required to honor it? [EMAIL PROTECTED] wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Atom Publishing Format and Protocol Working > Group of the IETF. > > Title : The Atom Publishing Protocol > Author(s) : B. de Hora, J. Gregorio > Filename : draft-ietf-atompub-protocol-09.txt > Pages : 41 > Date : 2006-6-28 > > The Atom Publishing Protocol (APP) is an application-level protocol > for publishing and editing Web resources. The protocol is based on > HTTP transport of Atom-formatted representations. The Atom format is > documented in the Atom Syndication Format (RFC4287). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-09.txt > > To remove yourself from the I-D Announcement list, send a message to > [EMAIL PROTECTED] with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-atompub-protocol-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > [EMAIL PROTECTED] > In the body type: > "FILE /internet-drafts/draft-ietf-atompub-protocol-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft.