This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"The ASCII-encoded string in lower case representing the media type of the Blob" DOMStrings aren't ASCII-encoded. If type was set with the Blob() constructor, it isn't necessarily in lowercase, either.
Is the intent for it to be restricted to the ASCII subset, and/or converted to lowercase in the ctor?
I looked at RFC2046 and at the HTML5 specification, which
*sigh Sorry for Comment 2; I submitted too soon. I looked at RFC2046 and at the HTML5 specification, which defines a valid MIME type string as matching RFC2616's media types section (3.7), to see if MIME type strings themselves are restricted to ASCII. They aren't as far as I can tell, and so we shouldn't have this requirement.
RFC 2616 section 3.7 says: media-type = type "/" subtype *( ";" parameter ) type = token subtype = token Section 2.2 says: token = 1*<any CHAR except CTLs or separators> Section 2.2 says: CHAR = <any US-ASCII character (octets 0 - 127)> So MIME types are in fact restricted to ASCII. Furthermore, they're restricted to a subset of ASCII: "except CTLs or separators".
So my first reading was right, which is why the requirement was there. But it's true that DOMStrings aren't ASCII-encoded. We may as well ignore this, and do what we do for invalid MIME types on the platform in general. Otherwise maybe we'd have to specify that: 1. Implementations throw if type is set with "invalid" non-ASCII chars 2. Specify that implementations do case conversion, if necessary. Don't know if we can really do those.
> do what we do for invalid MIME types on the platform in general. It probably varies. At least some implementations, in some cases, byte-deflate and ASCII-lowercase.
We can do that in the Blob constructor and in Blob.slice (and anywhere else where Blobs are created with an author-specified MIME type).
Marking this fixed. http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob