Tim Bray wrote:
<co-chair-mode>
Here's the latest: http://intertwingly.net/wiki/pie/PaceMediaEntries5
WG members are invited to express their approval, or lack thereof, for
the record, by next Monday June 12th.
-1. Not enough information to implement outside one administration - imo
this will fail across implementors. I had some security questions. All
seems to be fixable.
Comments below.
== "Content- Type"
Is this required or not? It's not specified anywhere other than the
examples, and it is assumed in 8.4 p2.
Is there a security risk posed when a client does not send the same
binary form as indicated by the media type?
== 8.2 Example:
Change the id on the returned entry - since everyone's an optimist when
it comes to MAY directives, we might as well be pathological upfront.
"may or may not" -> might not. It's not a spec sentence. The spec comes
next up after that.
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.
- if you change the id as suggested, mention it here.
Don't use .atom in the returned URLs. (I'm still cleaning up .html crap
from URLs as of 2006. Use a better framework, or something. Rant over.)
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.
== 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
[[[
If the body of the client's POST is of a media type other than
application/atom+xml, this constitutes a request that the server create
a new Resource as represented by the body of the post, along with an
Atom Entry to the collection to which the POST was addressed, and return
URIs for both. If the server successfully creates the Resource and
Entry pair, the Location header included in the response MUST be that of
the Entry. The Entry MUST have a "content" element with a "src"
attribute which links to the Resource.
]]]
You can disparage this, but I call Occam's razor on it. It does at least
indicate we are architecturally coherent. At least change "Media Link
Entry" to "Media Entry" so terms are symmetric.
"A server may or may not allow a client to modify the server selected
values for these elements. "
MAY and MAY NOT are opposing specs, and all a server can do is reject
the client's attempts:
[[[ 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.
"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.
== 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?
Do we need to say anything now to stop people trying to tunnel escaped
markup through it (and is not trapping that a security risk)?
cheers
Bill
