Re: Content Sniffing impact on HTTPbis - #155

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