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: [email protected]
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Anne van Kesteren
Sent: Monday, November 16, 2009 12:29 PM
To: [email protected]
Cc: WebApps WG
Subject: Re: [FileAPI] File.mediaType
On Fri, 13 Nov 2009 11:36:33 +0100, Arun Ranganathan <[email protected]>
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.
