- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 5 Jun 2009 01:30:17 -0700
- To: Mark Baker <distobj@acm.org>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jun 2, 2009 at 5:41 AM, Mark Baker <distobj@acm.org> wrote: > 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:" Fixed. > 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). I've changed this to a note explaining why using file extension to determine the media type of HTTP resources is a bad idea. > 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). I've softened this a bit and made it just a lead in to the explanation of why using a divergent algorithm is a bad idea. If you see a better way to bridge the first sentence (UAs shouldn't sniff) to the example (using a different algorithm causes problems), please let me know. > 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" Fixed. > 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. Ugg. That's super wordy. Is there really not a better way to refer to the thing contained in an HTTP response? Would entity-body be appropriate? Adam
Received on Friday, 5 June 2009 08:31:14 UTC