- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 17 Jun 2009 11:11:57 -0700
- To: Joe D Williams <joedwil@earthlink.net>
- Cc: Jonas Sicking <jonas@sicking.cc>, Mark Nottingham <mnot@mnot.net>, Dave Singer <singer@apple.com>, Shane McCarron <shane@aptest.com>, robert@ocallahan.org, Ian Hickson <ian@hixie.ch>, Larry Masinter <masinter@adobe.com>, ietf-http-wg@w3.org, public-html@w3.org
Hi Joe, I had a lot of difficulty understanding your message. Are you suggesting we sniff the media type from the file extension for audio / video content? Adam On Wed, Jun 17, 2009 at 10:42 AM, Joe D Williams<joedwil@earthlink.net> wrote: >> 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 18:12:57 UTC