Bill de hÓra wrote:
>[snip]
>
> Is this required or not? It's not specified anywhere other than the
> examples, and it is assumed in 8.4 p2.
>
+1 for making it a SHOULD. +1 for including a statement indicating that
servers could reject posts that do not contain a Content-Type header.
> Is there a security risk posed when a client does not send the same
> binary form as indicated by the media type?
>
Yes, I'd be +1 on adding a statement to the Security Considerations
regarding this.
>
> == 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.
>
+1
>[snip]
> [[[
> 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.
>
+0. Not convinced it's a problem, but as you indicate, nothing is lost
if the change is made.
>
> "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.
>
Good point.
>
> "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)?
>
+1. Title should be text only.
- James
