Re: comments on draft-barth-mime-sniffing

On Tue, 16 Jun 2009, David Singer wrote:
> > 
> > I've updated HTML5 to require that Content-Types of types that are not 
> > supported cause the resource to be ignored (even if it would otherwise 
> > be supported).
> 
> We're concerned about this, though we support the hope that we can get 
> away from doing content-type sniffing in this area.
> 
> 1) if you use a multimedia framework that you don't control, and it does 
> content-type sniffing, then you get it whether you want it or not.  
> QuickTime does, so Safari does, right now.

There are many requirements in the spec that require that libraries do 
particular things. If the library you use doesn't do the right thing, you 
will either need to fix it or reimplement it. (This is why some browsers, 
for instance, don't use their system HTTP stack -- it's often the case 
that the system's HTTP stack isn't standards-compliant enough.)

> 2) End-users posting AV content rarely have access to the MIME type 
> config. of their server (often, their ISP's server).  Getting the MIME 
> type table updated can take ages.

Indeed.

> 3) Once one browser gets a competitive 'edge' by sniffing, the rest 
> usually follow.  It's hard to see why this would not happen in this 
> case.

Once it does, I guess we'll define how the sniffing must occur.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: comments on draft-barth-mime-sniffing

> We're concerned about this, though we support the hope that we can 
> get away from doing content-type sniffing in this area.

I hope so too. For <video> and <audio> it seems like a fairly 
specified contract about what can be expected to play in a W3C HTML 5 
browser. Is sniffing always required? For <object> it has seemed like 
 <at> data targets were sniffed, but for a param URL the url was sent to 
the player and the player essentially got to manage getting and 
running the content.

If the allowed by the spec file extensions are listed then that will 
probably be enough to start out with.
Trust the author to test before deployment.

I would not expect to be using any particular media player, but one 
essentially built-in that is tuned to work with this spec. If I want 
_all_ the bells and whistles and the specific or optimized or 
(streaming?) file types and codecs provided by the major competitors 
in media players, then I will 'fallback' to <object> for possible 
access to maybe proprietary file extensions.
What I as an author am looking for in these elements is a sure-fire 
way to get something running. From abstraction I would not expect to 
get the current default win/ie or apple/safari or realplayer or adobe 
whatever optioned media player, for example, or something else that 
the user may have installed and uses for the system default for the 
registered mimes, but instead the 'standard' simple, possibly 
restricted "no brand" player 'built-in' to the HTML 5 browser. This 
will not handle everything, but if it runs and I need more or 
different then maybe I can get user cooperation to bootstrap me into 
what might be more complex or effective interactive multiple media 
environment.

So, me as the author knows the rules and what is supposed to be where 
I say it is so I would expect the host to get that <video> or <audio> 
player going with what I have put out there without a lot of delay and 
questions. On the other hand, if I don't know what is coming in and I 
wanted to try <video> first and I got an unsupported (by <video> or 
<audio>) MIME or file extension, then I would have to fallback to 
<object> to try and handle it by  <at> type and/or  <at> classid selection with 
what might end up to be the actual current user specified default 
player for the browser host platform .

I think the reason for host browser needing to sniff content streams 
in general is not so much needed in this case. Perhaps the file 
extensions for these element's content are more well known and better 
defined than their MIMEs. Since the author should know (I mean if 
tested at home; it should work on the WWW!). So I would say in this 
case it is not possible to recommend actual sniffing by the host 
browser past the file extension. Maybe in these cases of <audio> and 
<video> if the file extension is recognized, treat it if  <at> type was 
+xml and just pass the URL to the handler and let it start to work it 
out?

Thank You and Best Regards,
Joe

Re: comments on draft-barth-mime-sniffing

Simon Pieters wrote:
> On Fri, 12 Jun 2009 20:55:29 +0200, Ian Hickson <ian@...> wrote:
> 
> >I've updated HTML5 to require that Content-Types of types that are not
> >supported cause the resource to be ignored (even if it would otherwise be
> >supported).
> 
> If a UA does not know what is not supported, is it reasonable to consider  
> anything that is not video/* or audio/* to be not supported?

For video, content negotiation is probably going to end up being done
in Javascript rather than HTTP, or by User-Agent recognition.

The Content-Type of video/* simply doesn't provide enough information,
in practice to tell if the file can be played or not by a particular
browser / video player.  The file itself must be read, to determine
the codecs used.  Of course the client must understand the file
format, but the tough part is understanding the codec format inside
the file format, which is just a container.

Although there is an RFC specifying MIME sub-types to video/*
describing the codecs, I don't see any way to sensibly fit that into
HTTP's Accept: content-negotiation.

-- Jamie

Re: comments on draft-barth-mime-sniffing

Jamie Lokier wrote:
> Am I right that the Content-Type merely says the type of the container
> format, and says nothing about the format of encoded video(s) within?

I believe this is correct.  Certainly the MIME type Gecko looks for 
where video is concerned is video/ogg or application/ogg.

I would hope that container formats define how to figure out the types 
of media streams they contain.  If they don't, then that's unfortunate....

-Boris

Re: comments on draft-barth-mime-sniffing