On 6/29/06, James M Snell <[EMAIL PROTECTED]> wrote:
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
+1
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.
We don't say what the response for HEAD for any resource is, or MKCOL,
or PROPFIND, do you see where this is leading? The 'undefined-ness' of
methods we don't specify is part and parcel of working with HTTP.
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).
The text you quoted says Member's URI and not Location URI, so I'm
not quite sure it needs to be changed.
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?
Agreed.
Also, should we recommend that a PUT response contain the entry just
like with POST requests?
I don't believe so, the reason it is a SHOULD on the original POST is that
it allows the client to get the atom:id. We don't need that for subsequent PUTs.
Section 7.2.2
appCollection+ should be appCollection*
Agreed.
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?
No.
-joe
--
Joe Gregorio http://bitworking.org
