[apps-discuss] MIME sniffing and the media type registry magic numbers

[Larry Masinter <[e-mail]>]

I admit to a strong case of cognitive dissonance arguing two sides of these issues, but I think there's a resolution:

Context:   http://tools.ietf.org/html/draft-ietf-websec-mime-sniff proposes a standards track normative algorithm for "sniffing" content to determine its media type.
Document will be discussed at websec working group meeting tomorrow (Wednesday).

In http://trac.tools.ietf.org/wg/websec/trac/ticket/17 I proposed using a (updated, cleaned up, reviewed?) registry for magic numbers rather than an explicit table.

I am quite conflicted about first arguing for loose controls on media type registration in general, but standards track for one of the fields (the magic number).

An alternative is to add a new registry of "Validated magic numbers" and be clearer in the media type registry itself that the "magic number" field is only a hint, and point people at the parallel registry.

In http://trac.tools.ietf.org/wg/websec/trac/ticket/18 i noted that sniffing also covers retrieving documents from ftp: and file: URIs into browsers, in which cases the file extensions *are* used; again, I think this makes the "file extension" field which is optional now into something that might have a "validated" value.

So rather than considering a "registration" to have different status (FCFS, standards track, etc.) perhaps the individual fields of the registration need status metadata.

Larry


-----Original Message-----
From: "Martin J. Dürst" [mailto:[e-mail]] 
Sent: Tuesday, November 15, 2011 9:15 AM
To: David Singer
Cc: Larry Masinter; t.petch; [e-mail]; [e-mail]
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)

On 2011/11/15 3:35, David Singer wrote:
>
> On Nov 12, 2011, at 12:25 , Larry Masinter wrote:
>
>> I see no use case for why having font/opentype is any better than 
>> application/opentype
>>
>> The only use case I can imagine from looking at
>> http://tools.ietf.org/html/draft-singer-font-mime-00
>> is the possibility of defining common parameters across font data types (in the same way that text/.. has a common charset parameter).
>
> How serious is the first concern "First, the  "application" sub-tree is treated (correctly) with great caution with respect to viruses and other active code."?

I very much think that having a  font/ top level type is actually a good idea. But I hinted at this before: a type shouldn't be treated as "more safe" just because it says font/, rather than application/. Many font formats contain active code that is executed by the font engine. Several security holes have been found in this area. So I'd actually de-emphasize or remove this point. draft-singer-font-mime-00 also doesn't have a security section, and it of course needs one.


> (The reason I abandoned the draft was not the difficulty of getting it through, by the way, but because the W3C Timed Text group decided it didn't need it).

Can you be more specific? E.g., does Timed Text only use one font format? Or does it not contain any field that indicates the format, which makes this "somebody else's problem"? Or some other reason?

Regards,    Martin.