I'm basically OK with Bill's edits [dammit, we're gonna get to
PaceMediaEntries37 before we converge], with one exception, and a few
niggles.
On Jun 12, 2006, at 3:17 PM, Bill de hÓra wrote:
Alter p4;
-why has it "ascertained the author's via the authentication
protocol used to establish the right to post", when the author's
name was sent in the submitted entry? Strike that please, or change
the author in one entry to Jane Doe. Perhaps it's meant to go into
the binary discussion.
OK, I think we all agree that it's important that the example not
contain any unexplained magic.
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?
== 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.
[[[ 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?
"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?
== 8.4.1 Title: Header
is this co-occurent with non-atom submissions? Implementation
specific behaviour if it arrives with an application/atom+xml
submission?
Huh?
-Tim
