On Mar 19, 2013, at 8:52 PM, Glenn Maynard wrote:
> On Tue, Mar 19, 2013 at 1:41 PM, Arun Ranganathan <a...@mozilla.com> wrote:
>
> > 2. Convert every character in relativeContentType to lower case.
>
> I recommend referencing "Converting a string to ASCII lowercase" in HTML.
> http://www.whatwg.org/specs/web-apps/current-work/#converted-to-ascii-lowercase
Done.
>
> > 1. If relativeContentType contains any non-ASCII characters, then set
> > relativeContentType to the empty string and return from these substeps.
> > 3. If relativeContentType contains any line break characters like "CR"
> > or "LF" or any CTLs or separators, then set relativeContentType to the
> > empty string and return from these substeps.
>
> #3 is too vague. I recommend combining #1 and #3, saying: "If any character
> in relativeContentType outside of the range U+0020 to U+007E". That's the
> printable ASCII range, and excludes all control characters.
>
Done (+ thanks).
> > 4. Parse relativeContentType as an RFC2616 media-type, tokenizing it
> > according to the ABNF for media-type [RFC2616] with the ASCII "/" character
> > separating tokens representing the type and subtype productions. If
> > relativeContentType cannot be tokenized according to the ABNF for
> > media-type [RFC2616], then set relativeContentType to the empty string and
> > return from these substeps.
>
> I'm not sure we should be this strict. I'd lean towards keeping it simple,
> allowing any string at all as long as it contains only lowercase, printable
> ASCII.
Done -- we restrict it now, but don't mandate tokenization along the lines of
RFC2616.
> You don't need to say "The following requirements are normative for this
> parameter". That's what the normative language that follows ("must") means.
Done.
> My only concern is that blob.type should never contain parameters. Comparing
> it to "text/plain" or "image/jpeg" should work, and not mysteriously fail a
> year later when somebody eventually throws a MIME type parameter into the
> mix. Today, all browsers expose text files at text/plain. If a browser a
> year from now decides to call text files with a UTF-8 BOM "text/plain;
> charset=UTF-8", it'll break interop.
>
> Additionally, determining a blob's file type seems like the most obvious use
> of this property, and making people say "if(blob.type.split(";")[0] ==
> 'text/plain')" is simply not a good interface.
OK -- you're strongly opinionated on the matter of NOT allowing a charset
parameter. I'd like to see if implementers who had an opinion on its
usefulness can weigh in -- Darin? Alexey?
http://dev.w3.org/2006/webapi/FileAPI/
-- A*
