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 
@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 @type and/or @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 @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

Received on Wednesday, 17 June 2009 00:01:54 UTC