Subject: Re: Questions about draft-abarth-mime-sniff-00

From: Adam Barth <[email-masked]>
Date: Sat, 30 May 2009 15:46:46 -0700

On Mon, Apr 6, 2009 at 1:07 PM, Lisa Dusseault
<[email-masked]> wrote:
> I now think we mean something completely different by "extension".  I had
> assumed "protocol extension", i.e. a specification that extends HTTP, but
> now I see you mean "file name extension".

I've now fixed all references to "extension" to say "file extension".

Adam

---

From: Adam Barth <[email-masked]>
Date: Sat, 30 May 2009 15:49:05 -0700

On Tue, Apr 7, 2009 at 1:34 AM, Julian Reschke <[email-masked]> wrote:
> IE does, although badly documented. It would be nice if other UAs did it
> better, instead of not doing it at all.

I've left explicit mention of a user interface for content sniffing
out of the next draft, but the draft does account for the possibility
that a user agent might be configured to strictly obey the
Content-Type header.  Hopefully this will nudge implementors to permit
users to configure them thusly.

Adam

---

From: Adam Barth <[email-masked]>
Date: Sat, 30 May 2009 15:51:56 -0700

On Mon, Apr 6, 2009 at 1:17 PM, Anne van Kesteren <[email-masked]> wrote:
> I sort of expect <video src> and <audio src> to do sniffing as well
> (ignoring Content-Type altogether most likely). @font-face ignores
> Content-Type as well because nobody had registered media types for fonts.

The draft now admits for the possibility that user agents will extend
the list of sniffable types.  However, the draft admonishes them not
to add more signatures for the current types and to take the security
implicitations into considersation.

Adam

---

From: Adam Barth <[email-masked]>
Date: Sat, 30 May 2009 15:56:22 -0700

On Mon, Apr 6, 2009 at 1:07 PM, Lisa Dusseault
<[email-masked]> wrote:
> That makes more sense now.  It might be nice to specifically mention that
> the threat model assumes that the server can lie about Content-Type anyway,
> and in the security considerations warn that a server might trick clients
> into handling one content type as another if the client isn't careful.

Thanks.  I've added this note to the draft.  Let me know if you'd like
more exposition here.

Adam

---

From: Larry Masinter <[email-masked]>
Date: Sun, 31 May 2009 10:26:22 -0700

> Content-Type as well because nobody had registered media types for fonts.

If content-type sniffing is context dependent -- @font-face sniffs font
types which img@src doesn't -- then the draft should be explicit about
that, rather than suggesting font sniffing for image sources.

There's no justification for allowing video@src or audio@src to be
sniffed. It just opens the door to more problems, and is not supported
by the justification of backward-compatibility with deployed content --
is there any other justification, besides someone "sort of expect"ing
it?

Larry

---

From: Adam Barth <[email-masked]>
Date: Sun, 31 May 2009 13:23:19 -0700

> that, rather than suggesting font sniffing for image sources.

The draft does not suggest font sniffing for image sources.

> is there any other justification, besides someone "sort of expect"ing

The current draft does not sniff video or audio.  (Actually, we do
sniff MP3s because MP3s turn out to be widely mislabeled.)

Adam