Re: comments on draft-barth-mime-sniffing

2009/6/22 Joe D Williams <joedwil@earthlink.net>:
> 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?

The media type.  That's the purpose of the media type: to give
semantics to the bytes coming over the network.

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

The codec issue is indeed thorning, but thankfully separate from this
discussion.

> 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:)

Thanks.  I'll update my site.

> 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?

Yes.  Please see the discussion on the WHAT WG mailing list.

> 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?

I've removed this from my working draft.

Adam

Received on Monday, 22 June 2009 19:09:27 UTC