[mdx] md-query-00 comments

[Ian Young]

I've had my head in HTTP header space for various reasons, which has meant mentally swapping in RFC 2616, and as a result I noticed a couple of things in the -00 document that may want to be modified or at least clarified.

2.2 HHTP Method

Typo: "All metadata retrieval request" --> "requests"

2.3 Request Headers

I don't think it makes sense to say that all retrieval requests SHOULD include If-Modified-Since and If-None-Match, as those can only apply if the client has already received them as part of a previous request (neither of these headers are defined such that you can supply them without a value attached).  I think it would improve things to separate these two cases out and say that these headers are included if the client has made a previous request which returned them.

Note also that RFC 2616 13.3.4 says that if the server sent an ETag in the original response (which your spec says MUST be the case on that original 200 response) then subsequent conditional requests MUST include that ETag (not SHOULD, as in your current document).

SHOULD does appear to be the right approach to If-Modified-Since, however, if for no other reason than to permit clockless operation.

2.4 Response Headers

"ETag ... if and only if ... 200"

That "if and only if" language seems to be another way of saying that ETag MUST NOT be included in a 304 response to a conditional GET.  This contradicts RFC 2616 section 10.3.5, which says that the ETag MUST be included in a 304 response if it would have been included in a 200 response (where in this document the "if and only if" is another way of saying MUST).

One of the reasons behind that stipulation, I think, is related to the way that you'd be doing conditional GETs: If-None-Match in RFC 2616 permits multiple etags.  You don't restrict If-None-Match to a single ETag in this document (and although I can't think offhand of a scenario in which the client might keep multiple entities around, I can't really see why you would want to make such a restriction as strong as a MUST NOT, maybe a SHOULD NOT at worst) so one function of the ETag in the response is to identify *which* of the entities the client has access to is the one the server would have returned for this request.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3672 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20100714/f993f6c2/attachment-0002.bin>