Re: Status of draft-abarth-mime-sniff?

On Sun, Jun 6, 2010 at 5:37 PM, Mark Nottingham <mnot@mnot.net> wrote:
> Perhaps it would be helpful to make this discussion a bit more concrete.

Sure.

> The portion of Larry's post directly related to sniffing is:
>
>> update mimesniff / HTML spec on sniffing, versioning, MIME types, charset sniffing
>>       • Sniffing uses MIME registry

I don't quite understand what this bullet means, but I think he's
talking about a registry for extending the sniffing tables in
draft-abarth-mime-sniff, which seems like a reasonable idea.

>>       • all sniffing can a upgrade

I couldn't parse this bullet.

>>       • discourage sniffing unless there is no type label
>>               • malformed content-type: error
>>               • no knowledge that given content-type isn't better than guessed content-type
>
> Adam, can you speak to how these have implementation problems specifically?

This is basically the status-quo for specs, but it doesn't reflect
what implementation do.  For example, it's quite important to sniff
when the Content-Type header has the value "*/*" or the value
"(null)".

The bullet above says "malformed content-type: error", but I don't
know what that means.  User agents typically take some kind of default
action when they encounter a MIME type that they can't handle (e.g.,
triggering a download).  I don't think UA implementors will be
interested in implementing an error experience for these cases.

Also, it's quite important to sniff various image MIME types from
other image MIME types.  For example, it's very common that servers
will send a JPEG with the MIME type image/gif.  Another common mistake
is to send a JPEG with the (incorrect) MIME type of image/jpg (the
correct MIME type is image/jpeg).

Anyway, I have lots of data on this stuff and have been around this
block several times.

> Also, are you (Adam, Ian, others) planning to be in Maastricht? It would be nice to sit down face-to-face and discuss how to progress this document.

It's looking like I'll be able to go to Maastricht.

I have no wish to ram this document down anyone's throats.  I just
think it's dumb that every browser uses a different sniffing
algorithm.  In Larry's terminology, that makes things unreliable.  :)

Adam


> On 07/06/2010, at 7:41 AM, Adam Barth wrote:
>> We agree that the goal is reliability (in this case, reliability and
>> security are highly correlated).  We disagree about how best to ensure
>> reliability.
>>
>> In particular, I take as a hard constraint what user agent
>> implementors are willing to implement.  We can debate for years how
>> many MIME types can dance on a the head of a pin, but it doesn't
>> matter if it's not implemented in the real world.  We can continue to
>> ignore the constraints faced by user agent implements, but that will
>> lead to this problem festering for another decade.
>>
>> Adam
>>
>>
>> On Sat, Jun 5, 2010 at 8:32 PM, Larry Masinter <LMM@acm.org> wrote:
>>> (putting public-ietf-w3c@w3.org back):
>>>
>>> I wrote up something in the hopes of establishing some common agreement
>>> about where we were and how we got here, since some lack of common ground
>>> seems to me to be interfering with making progress.
>>>
>>> http://masinter.blogspot.com/2010/06/mime-and-web.html
>>>
>>> is a first cut at laying out the issues that have arisen over the
>>> years. Incomplete? Inaccurate?
>>>
>>> Anyway, rather than focusing on "sniffing", I thought we should get
>>> out there all of the MIME type issues, registration, etc, and then
>>> even for "sniffing", there are reliability issues that might not
>>> actually have significant security impact but still need to be
>>> addressed.
>>>
>>> There's a TAG meeting this week where this was scheduled to be discussed,
>>> but I'm not able to attend after all, so I thought I'd go ahead and get
>>> more IETF review as well.
>>>
>>> Larry
>>>
>>>
>>> On 5/17/10 3:17 AM, Larry Masinter wrote:
>>>>>   I'd be
>>>>> happy to go over your technical feedback again, but I suspect this
>>>>> isn't the proper forum for that discussion.
>>>>
>>>> This *is* a useful forum for talking about the proper forum for
>>>> that discussion.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: public-ietf-w3c-request@w3.org
>>>> [mailto:public-ietf-w3c-request@w3.org] On Behalf Of Adam Barth
>>>> Sent: Sunday, May 16, 2010 11:37 PM
>>>> To: Larry Masinter
>>>> Cc: Mark Nottingham; Ian Hickson; public-ietf-w3c; Dan Wing
>>>> Subject: Re: Status of draft-abarth-mime-sniff?
>>>>
>>>> Woah, sorry Larry.  I didn't mean to misrepresent your views.  I'd be
>>>> happy to go over your technical feedback again, but I suspect this
>>>> isn't the proper forum for that discussion.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Sun, May 16, 2010 at 11:20 PM, Larry Masinter <LMM@acm.org> wrote:
>>>>> Rather than resorting to an ad hominem argument about whether I
>>>>> am or am not a "fan" of something, could you please actually address
>>>>> the technical issues I raised on the document itself? Trolling
>>>>> my blog for some argument that you imagine I might have made
>>>>> and then arguing against them is an interesting tactic.
>>>>>
>>>>> My blog post -- a pretty general and theoretical one,
>>>>> have nothing to do with the specific comments on this document,
>>>>> and your speculation is misdirection at best.
>>>>>
>>>>> I don't think the problem with this document is "over-specifying",
>>>>> I think the problem is that it doesn't "reflect reality"
>>>>> and that it is also detrimental to the stability, security, and
>>>>> reliability of the web.
>>>>>
>>>>> I think you addressed a few of the issues I raised in:
>>>>>
>>>>>
>>>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01250.htm
>>>>> l
>>>>>
>>>>> but for the most part, not.
>>>>>
>>>>> Whether or not there is substantial community that would agree
>>>>> with me can only be found if you were willing to actually get the
>>>>> document reviewed, rather than trying to find the "path of least
>>>>> resistance".
>>>>>
>>>>> Finding the "path of least resistance" for a technical specification
>>>>> that affects the stability, security and reliability of the web
>>>>> is irresponsible.
>>>>>
>>>>> Don't.
>>>>>
>>>>> Thanks so much,
>>>>>
>>>>> Larry
>>>>>
>>>>> --
>>>>> http://larry.masinter.net
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: public-ietf-w3c-request@w3.org
>>>>> [mailto:public-ietf-w3c-request@w3.org] On Behalf Of Adam Barth
>>>>> Sent: Sunday, May 16, 2010 9:28 PM
>>>>> To: Mark Nottingham
>>>>> Cc: Ian Hickson; public-ietf-w3c
>>>>> Subject: Re: Status of draft-abarth-mime-sniff?
>>>>>
>>>>> On Sun, May 16, 2010 at 9:16 PM, Mark Nottingham <mnot@mnot.net>
>>>>> wrote:
>>>>>> On 17/05/2010, at 2:11 PM, Adam Barth wrote:
>>>>>>> On Sun, May 16, 2010 at 9:01 PM, Ian Hickson <ian@hixie.ch> wrote:
>>>>>>>> On Mon, 17 May 2010, Mark Nottingham wrote:
>>>>>>>>> What's the status of this draft? It doesn't nominate an Intended
>>>>> Status,
>>>>>>>>> nor is it being tracked by an Area Director, so its future in
>>>> the
>>>>> IETF
>>>>>>>>> isn't defined. Do you still consider its venue the IETF?
>>>>>>>>
>>>>>>>> So long as it is implemented interoperably, I don't really mind
>>>>> where it
>>>>>>>> is published, personally. I defer to Adam, who has done most of
>>>>> the work
>>>>>>>> on this draft so far (I just did the first bit, basically).
>>>>>>>
>>>>>>> Philosophically, I think the IETF is the "right" venue for the
>>>>>>> document, but I understand that it's politically unpopular.
>>>>>>
>>>>>> Do you mean by the IETF, browser vendors, W3C, someone else?
>>>>>
>>>>> In the past, it has seemed like Larry Masinter wasn't a big fan of
>>>> the
>>>>> document.  My understanding is that Larry is generally again "over
>>>>> specifying" (e.g.,
>>>>>
>>>> http://masinter.blogspot.com/2010/01/over-specification-is-anti-compet
>>>>> itive.html).
>>>>>  I certainly don't want to speak for Larry, but I think he views
>>>> this
>>>>> document in that light.
>>>>>
>>>>> As for browser vendors, they seem generally supportive, if cautious
>>>> of
>>>>> change.  The smaller vendors seem to be the most positive.  For
>>>>> example, libsoup implemented content sniffing based on the spec:
>>>>>
>>>>> https://bugzilla.gnome.org/show_bug.cgi?id=572589
>>>>>
>>>>>>>  Browser vendors are converging on the algorithm in the draft,
>>>>> which is great.
>>>>>>> I think it makes sense to publish it in a permanent form so that
>>>>> folks
>>>>>>> years from now will know how this stuff works.  If you have advice
>>>>> for
>>>>>>> how to make it more palatable to the IETF, I'd welcome your input.
>>>>>>
>>>>>> I think the best thing you could do would be to try to progress the
>>>>> draft and see what happens. Otherwise we're just speculating.
>>>>>
>>>>> Ok.  I'll chat with various folks and try to figure out the path of
>>>>> least resistance here.
>>>>>
>>>>> Thanks,
>>>>> Adam
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Peter Saint-Andre
>>> https://stpeter.im/
>>>
>>>
>>>
>>>
>>>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>

Received on Monday, 7 June 2010 06:40:12 UTC