Re: comments on draft-barth-mime-sniffing

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