Re: Content Sniffing impact on HTTPbis - #155

Thanks the below is very helpful.

Adam


On Tue, Jun 2, 2009 at 5:41 AM, Mark Baker <distobj@acm.org> wrote:
> 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 17:05:56 UTC