Re: comments on draft-barth-mime-sniffing

I'm punting on audio and video sniffing for now.  If and when audio
and video sniffing becomes crushingly prevalent, we can revisit this


On Mon, Jun 22, 2009 at 2:55 PM, Joe D Williams <> wrote:
> Hi Adam,
>> 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?
> I have done some wandering on this topic and in this thread, but to me an
> important point is that I am still thinking in terms of audio and video as
> an embedded (nested) or auxiliary context. That is, the audio or video might
> be embedded content using the HTML 5 <audio> or <video> element, and that
> the UA will open an auxiliary context if a standard hyperlink with an audio
> or video file extension as @href is selected. Either way, I get access to
> the host DOM through interfaces granted by the host context.
> What does the host, or source, context need to know about the served content
> type and encoding and maybe contents of the file in order to send it to the
> <audio> or <video> requester, or to the auxiliary context?
> If we knew that, then the mime-sniffing table used to find Sniffed Type by
> the Unknown algorithm might get longer, or maybe more entries in Image, or
> better yet, an added main title for Audio and Video objects. I think this is
> where a real contribution will be made by HTML 5, is when there is a
> standard or highly recommended (evolving) set of mimes that will play
> 'standard' audio and video (@src, @type, @codecs) in W3C HTML 5 UAs. This
>  list needs to be readily available to web authors.
> For example, for audio media, I have commented that the spec should not
> recommend 'any audio codecs' but instead state a selected subset of
> available content types/file extensions as 'native' to the <audio> element.
> I think it would be best to just say current typical .wav and Ogg Vorbis
> (.oog) - if those are as open and free and available as we believe and hope.
> I wish I knew more about this and thus aid my point of view here with
> conclusive argument that allowing 'any' container/codec in the <audio> node
> is not an improvement in what was already there in <object>. Well, fine that
> the media style interfaces are being specified in <audio> and <video>; that
> is a great step forward for simplified implementation-independent authoring,
> for sure. However, if there are no 'native' audio media types in HTML 5 then
> it is just like it was where the author gets to depend upon the client
> determination of which proprietary media player system (legacy audio plugin)
> gets used. Basically, that just means a level of inconvenience for everyone.
> Also, looking at:  [ myemphasis ]  DIFF1
> Metatdata
> ... only the [first last] Content-Type HTTP header, ...
> May 31, 2009
> and
> January 9, 2009
> Adam, please update the link on your site with the latest draft?
> I know now which one to read = 01 but it distracted me for a while:)
> The choice of which of multiple content type headers to use seems important
> and interesting.
> Is there some background on the final choice of last/first?
> Thank You and Best Regards,
> Joe
> ps. can that entry down at the bottom of that unknown type table:| FF FF FF
>          | 49 44 33          | audio/mpeg      | Safe       |
> | Comment: The string "ID3", the MP3 signature.have anything to do with this
> conversation?

Received on Tuesday, 26 January 2010 20:26:48 UTC