On 6/13/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
So, - if we are sending entries, and - servers can "reject" entry alterations, and, - servers can ignore entry alterations, and, - servers can accept entry alterations then yes, *you* can send any response code, but what will some other server send? That's the point. Here, 1. i accepted your changes: 202 (and/or 2xx) 2. i ignored your changes, or took some, or...: 403/202/?? 3. i spit on your changes: 403 see the problem? It would be good to get that down to 2 states, where the server is fail fast and not operationally silent at the protocol level* - 1. i accepted your changes: 202 (and/or 2xx) 2. i spit on your changes: 403 (and/or 409) no partial entry handling**,
Are you really saying that you want every server to accept every entry as-is and promise not to change anything or to reject with an error? That's completely unrealistic today and if you wanted to go down this path it would make the APP introspection completely unwieldly because we'd have to have the ability to discover the list of acceptable authors, the list of acceptable 'rel' values, the list of acceptable values for atom:rights, the list of acceptable HTML markup in content elements, the list of naughty words to avoid using in text, etc. And don't forget that this would make the APP a 'must-understand' protocol with respect to foreign markup.
no client confusion, less chance of data loss/weirdness. I'm all for sloppy extensibility, except when it comes to dropping data on the floor. >> "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." >> >> I didn't understand this, as in I don't know what the code should do. > > What we're trying to say is "we don't specify what the code should do". > There's an obvious anomaly in that we talk about case A, it's an Atom > entry, case B, it's of a non-Atom media type. Clearly that leaves a > class we don't discuss: the Atom medium type but not an entry. Either > we get WG consensus on what to do in this case (good luck), or we're > clear that we don't cover it. > > But the fact that you didn't see what's going on is a symptom of > something wrong. Got a better approach to suggest? Ah, ok. If we're talking about feeds, let's say that plainly: "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 an Atom Feed document."
+1 -joe -- Joe Gregorio http://bitworking.org
