Re: comments on draft-barth-mime-sniffing

> but why can't I as a user turn it off, either as a preference or on 
> a case-by-case basis? Sometimes "going the extra mile" gets it 
> wrong, and as with any heuristic, there needs to be a way to say 
> "no, don't do that!"

Well, lets give both author and the actual browser pilot a chance.
First, from authoring, for <audio> and <video> the author can present 
from a small, safe group of content models using simple reference to 
file MIME and file extension. These are first class objects; the 
element is a trusted context that can negotiate directly with the host 
DOM. These are active, live nodes but their content is not active.

Until these spec <audio> and <video> MIMEs are officially registered 
and the servers are actually updated, or the author can produce 
.htaccess file  to control the served ContentType, the server response 
is uncertain. So at this time and in the future, the server may 
actually produce the target content with no content type string.

In fact, the only information that needs to be be relied upon at this 
point is that if the author says audio me.ogg then the UA either:
1. fetches the resource for sniffing then sends it to the media 
handler, or
2  sends the handler the absolute URL and leaves until the handler 
context needs it again.
I think 2 is preferred.

Next, from the browser user, since <audio> and <video> are first class 
objects, there are no special permissions required to render asap, In 
particular, there are no "Security" issues. Default is as the author 
specified for the current object.
Although UA might provide some common means of defining use 
preferences to allow local control of the browing environment produced 
by particular pieces of the document it is on same order as the 
choices provide by the author with @sandbox. or CSS. If any halt or 
significant delay is produced by these user-selected UA actions, the 
fallback content must be rendered, then replaced by the parent content 
when approved.

As for UA sniffing of this particular <audio> or <video> content, it 
is useless and counter-productive. First, for these types, no matter 
what goes into the handler. the content can only confuse or break the 
handler not its container. Next, although a fine idea, we are unlikely 
to find a MIME-like string in the essentially binary file we want the 
handler to be dealing with. There are metadata in there, and the whole 
thing could be XML someday but only the handler needs to know about 
that in this case. For example, no matter what the served or sniffed 
MIME, if the author said ogg then the handler will treat the content 
only as ogg. Can there be scripts or any other 'security' issues in 
these content types?

I will check more about ogg, but for .wav, I find that any suffix to 
.wav to tell more about the particular internal data is for internal 
production sorting convenience in authoring tools, maybe. Otherwise, 
you do have to actually read some file front matter to determine some 
actual characteristics, such as sample rate, and others. These are of 
no value to the UA or the handler in this instance because a handler 
that does .wav is not going to have trouble with any spec form of the 
.wav. PDM is just the best open choice of other mod alternatives. 
Again, if it works on a couple of HTML 5 browsers at home, then it 
should just work out there in the HTML 5 WWW.

Thank You and Best Regards,
Joe

Received on Wednesday, 17 June 2009 17:43:30 UTC