Re: comments on draft-barth-mime-sniffing

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?

Received on Monday, 22 June 2009 14:56:13 UTC