Tim Bray wrote:
If the pace is accepted, I'd like to mention Content-Location at this
point. "What's Content-Location for? "is the first question that will
be asked.
Suggest language?
Off the top of my head I don't know what it's for without going back
through the archives (sigh, will wander off to look later).
== 8.4 Media Resources and Media Link Entries
"media resource", "media link entry"
No information is lost when these concepts are dropped. For example,
rewriting, 8.4 p2
I disagree strongly. I don't think they're concepts, they're labels. I
think we have consensus behind the idea of creating two URIs: one for
the binary-bucket-of-bits and another for the
atom-entry-about-the-binary-bucket. Life is going to be easier for the
spec writer and the spec reader if we also say "please use these two
names when you discuss these things". This is actually one of the big
value-adds in writing specifications.
Unconvinced, but I've withdrawn the objection.
[[[ A server MAY reject a client's attempts to modify the values of
these elements.]]]
Which begs the question of what the response should be in that case.
Um, do we need to touch this? The answer is "it depends", right? Is
there any response code that couldn't come up, in principle?
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**, 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."
It's an annoyance we can't use standard codes like 406 to cater for this
(spec in an atom entry media type as per Rob makes sense). I guess
that's no reason to hold things up.
cheers
Bill
* "200 Ok and here's a message saying that i won't change the author data"
** "i ignored some changes but accepted the others".
