W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: [FileAPI] File.mediaType

From: Arun Ranganathan <arun@mozilla.com>
Date: Tue, 17 Nov 2009 13:26:20 -0800
Message-ID: <4B0314FC.9090102@mozilla.com>
To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
CC: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
Marcin Hanclik wrote:
>>> What if the @type is derived from unverified metadata and the UA relies on the underlying OS (assuming the file is local) ?
>>> Does it mean that the UAs should always sniff to ensure that the @type is correct?
>>>       
>
> Should we apply the procedure similar to the one from P&C that derives the @type from the file name [4]?
>
> [4] http://dev.w3.org/2006/waf/widgets/Overview.html#rule-for-identifying-the-media-type-of-a
>   

User agents can use a variety of different steps to determine the type 
of a file.  For instance:

https://developer.mozilla.org/En/How_Mozilla_determines_MIME_Types#ExternalHelperAppService

I am not sure it is necessary to specify a common approach here, but it 
is useful to specify what happens when the user agent cannot determine 
the type.  I've made the following changes:

1. I agree that name consistency is desirable, so mediaType is now 
simply type.  I'll point out that <style>.type expects very few types 
back, whereas for files, the picture is more complicated, so simply 
calling it type has drawbacks, but since mediaType isn't used elsewhere 
on the platform, I agreed that reusing the same name was desirable.

>
> "mediaType
>     The ASCII-encoded string in lower case representing the media type of the file, expressed as an RFC2046 MIME type [RFC2046]."
>
> Although IANA registered types are all lower case, the subtypes are not (not sure whether we want to mandate the toLower() normalization in the FileReader API).
> Therefore I suggest referring to IANA and RFC4288.
>
>   


2. I've put in an editor's note to mention IANA and RFC4288.  I'm not 
sure *exactly* how useful subtypes are here, but it's worth making the 
specification text more robust.
> What if the @type is derived from unverified metadata and the UA relies on the underlying OS (assuming the file is local) ?
> Does it mean that the UAs should always sniff to ensure that the @type is correct?
>   

I think UAs *should* try to determine that the type is correct, but 
don't think this is a *must*.


3. The empty string is returned if user agents cannot make a determination.

-- A*
Received on Tuesday, 17 November 2009 21:26:54 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT