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
issue.

Adam


On Mon, Jun 22, 2009 at 2:55 PM, Joe D Williams <joedwil@earthlink.net> 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, ...
> http://www.ietf.org/internet-drafts/draft-abarth-mime-sniff-01.txt
> May 31, 2009
> and
> http://tools.ietf.org/html/draft-abarth-mime-sniff-00
> 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?
>