On Jun 14, 2006, at 9:43 AM, Jan Algermissen wrote:
Isn't the real problem here that the ID is somewhat bound to the
origin server that owns a given entry?
Right. The notion of doing a PUT on a URI returned from an APP POST,
and changing the atom:id, gives me severe heartburn. It's just
wrong, it will break all sorts of things, and if I were a server
implementor, I'd have code to check the body that came in with a PUT
and keep it from fucking with my ID space. Alternatively, returning
any of 401, 403, or 409 seem reasonable.
Maybe we should write this into the protocol?
Hmm... upon reviewing protocol-08 I observe that this whole PUT-to-
update is thinly covered. I suggest that it deserves a place in the
doc outside of the example-oriented section 5.
I suggest a new subsection of whatever Section 8 ends up being
numbered as
x.y Updating and Deleting Entries.
The URI to use in updating and deleting entries is included in the
collection listing in an atom:link element with a rel attribute value
of "edit". Entries may be updated by sending a PUT request
containing a revised Atom entry to such an edit URI, or removed by
sending it a DELETE request.
In the case where an APP client is updating an such an entry by
sending a PUT request to the edit URI, the Atom Entry in the body of
the request MUST NOT attempt to change to value of the entry's
atom:id. An appropriate response from an APP server to such a
request would be to fail with a status code of "409 Conflict".
Here's an alternative formulation of the last paragraph, slightly
redistributing the work:
In the case where an APP client is updating an such an entry by
sending a PUT request to the edit URI, it cannot change the value of
the entry's atom:id. Servers MUST NOT change the atom:id value,
even if requested by a client.
I.e. in the first case, we're saying "Client: don't do this." In the
second "Server: if the client stupidly requests this, ignore it." -Tim
