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.
