RE: [FileAPI] File.mediaType

Hi,

>>The current text says the string is ASCII-encoded. That's not true. It's
>>in 16bit code points like any other DOMString.
+1
The full definition stems from [RFC2045.5.1] and says that content type is not only ASCII, but it also removes some of the ASCII characters from the allowed ones.
The IANA registration [RFC4288.4.2] procedure requires the following syntax:
       type-name = reg-name
       subtype-name = reg-name

       reg-name = 1*127reg-name-chars
       reg-name-chars = ALPHA / DIGIT / "!" /
                       "#" / "$" / "&" / "." /
                       "+" / "-" / "^" / "_"

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

>>> "mediaType" is more specific than "type".
>>
>>But it is less consistent with <style>.type, <script>.type, <link>.type,
>>etc. I'm not sure we use mediaType anywhere right now.
+1 for @type.
[1] lists media types, but technically refers to content types and content subtypes (therefore I was also thinking about @contenttype, but dropped this idea for now).
[2], [3] probably already state what we need in the further discussion (MIMESNIFF?).

"User agents SHOULD return the MIME type of the file, if it is known. If implementations cannot determine the media type of the file, they MUST return null. A string is a valid MIME type if it matches the media-type  token defined in section 3.7 "Media Types" of RFC 2616 [HTTP]."

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?

Thanks,
Marcin

[RFC2045.5.1] http://tools.ietf.org/html/rfc2045#section-5.1

[RFC4288.4.2] http://tools.ietf.org/html/rfc4288#section-4.2

[1] http://www.iana.org/assignments/media-types/

[2] http://dev.w3.org/html5/spec/Overview.html#attr-link-type

[3] http://dev.w3.org/html5/spec/Overview.html#content-type




Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com
-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Anne van Kesteren
Sent: Monday, November 16, 2009 12:29 PM
To: arun@mozilla.com
Cc: WebApps WG
Subject: Re: [FileAPI] File.mediaType

On Fri, 13 Nov 2009 11:36:33 +0100, Arun Ranganathan <arun@mozilla.com>
wrote:
> Anne van Kesteren wrote:
>> This should be a bit more exact as to how the mediaType is returned. I
>> would prefer ASCII-lowercase.
>
> Done.

The current text says the string is ASCII-encoded. That's not true. It's
in 16bit code points like any other DOMString.


>> Returning "application/octet-stream" rather than null also seems better
>> if the type is not known. That way you do not have to type check. Other
>> parts of the platform also handle "application/octet-stream" as unknown.
>
> It's been pointed out that user agents type check on files.  If the
> mediaType is not known, users invoking the attribute can't do anything
> useful with it, so null is better.  What are the use cases for using
> application/octet-stream instead?

I guess not known might be useful. Can't we just make it the empty string
then? I don't really see the need to return something other than a
DOMString.


>> Also, maybe we should just call this type? File.type seems unambiguous
>> enough.
>
> "mediaType" is more specific than "type".

But it is less consistent with <style>.type, <script>.type, <link>.type,
etc. I'm not sure we use mediaType anywhere right now.


--
Anne van Kesteren
http://annevankesteren.nl/



________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Monday, 16 November 2009 12:30:39 UTC