Re: Content Sniffing impact on HTTPbis - #155

On Tue, 2 Jun 2009, Mark Baker 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:"

I don't really agree with this (how do you conform to the spec if it 
doesn't have any conformance criteria?) but in case this happens, I've 
referenced the algorithm with a "must" from HTML5.


> 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 don't mind making this requirement non-normative (since as you say it's 
implicit), but I do think we should explicitly state that file extensions 
don't and mustn't have an effect, since it is so common to use them for 
this exact purpose in clients.


> 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 don't really understand what you mean here.


> 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"

Adam: assuming you have a conformance section which invokes RFC2119 and 
includes a sentence such as "Requirements phrased in the imperative as 
part of algorithms (such as "strip any leading space characters" or 
"return false and abort these steps") are to be interpreted with the 
meaning of the key word ("must", "should", "may", etc) used in introducing 
the algorithm.", and assuming you keep the "must"s in the invokations of 
the algorithms, I agree that it makes sense to remove the "must"s from the 
steps.


> 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.

A resource is a bag of bits. I would object to this change.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 12 June 2009 22:04:05 UTC