- From: Mark Baker <distobj@acm.org>
- Date: Tue, 2 Jun 2009 08:41:15 -0400
- To: Adam Barth <w3c@adambarth.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Jun 1, 2009 at 4:58 PM, Adam Barth <w3c@adambarth.com> wrote: > On Mon, Jun 1, 2009 at 12:30 PM, Mark Baker <distobj@acm.org> wrote: >>> 2) specify the algorithm to use if sniffing is done by referring to >>> draft-abarth-mime-sniff directly. >> >> I don't think that has any place in the HTTP spec, especially as even >> the revised version continues to use prescriptive language that >> supercedes key parts of the HTTP protocol. > > I'd like to incorporate your feedback into the draft, but the above is > too vague for me to act upon. Are there specific statements you'd > like me to revise? Here they are; "The /sniffed type/ of a resource MUST be found as follows:" to; "The /sniffed type/ of a resource is found as follows:" This should be removed; "File extensions MUST NOT be used for determining resource types for resources fetched over HTTP." As it's clear from the algorithm that file extensions are not referenced, and it's HTTP's job to say what meaning is or isn't given to them (which, of course, is none). Also, this introductory claim should be removed; "However, if the user agent does emply[sic] a content sniffing algorithm, it is imperative that the algorithm in this document be followed exactly" It should suffice that the draft explains the drawbacks of not following the algorithm because a) the algorithm is still evolving (e.g. text/plain), b) if an implementor has a good reason to implement a different algorithm, they will, and c) the document should describe the algorithm, and any conformance requirements about its use should be left to the referrer (e.g. if the HTTP spec refers to it). Just for completeness' sake (removing the MUSTs), this; "the user agent MUST stop this algorithm, and assume that the /sniffed type/ of the resource is "text/html"." could be changed to "the algorithm stops and the /sniffed type/ of the resource representation is "text/html" Separately, as an editorial comment, as listed directly above, I'd like to see a big s/resource/resource representation/g (or just s/resource/representation/g as the resource is what is identified by the URI, not the bag-o-bits returned in an HTTP response. I have some other editorial comments too, but those will have to wait until I have time to write them down. Mark.
Received on Tuesday, 2 June 2009 12:41:55 UTC