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

Re: [widgets] Potential bug in Rule for Identifying the Media Type of a File

From: Marcos Caceres <marcosc@opera.com>
Date: Thu, 22 Oct 2009 18:12:02 +0200
Message-ID: <b21a10670910220912m3d82e010k68bec2bf62e19938@mail.gmail.com>
To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Cc: public-webapps <public-webapps@w3.org>
2009/10/22 Marcin Hanclik <Marcin.Hanclik@access-company.com>:
> Hi Marcos,
>
>>>To be clear: All we want to do is check if the file extension of a
>>>file case-insensitively matches one of the extensions in the File
>>>Identification Table. If you can't match it, then the MIME type gets
>>>resolved with SNIFF.
> Ok, I understand the intention of this section.
>
> The ranges are an implementation detail (optimization/efficiency of some implementation, not a MUST for all).
> So in general all the comments about Unicode comparison/difficulty etc are irrelevant.
> Thus ranges as well.

Ok, cool. We are in agreement.

> Then the only really disputable thing is whether ".jpg" should be sniffed (your proposal) or whether it is to be interpreted as pure file extension (my proposal).
> In my argumentation I showed that on *nix/*inux systems ".jpg" is a file extension to support the interpretation as pure file extension.
>

Yes, and on my Mac, it was not. It seems more logical to me to not
treat it as an extension. Look at all the .whatever files on your
system. I bet you 2 beers that 99% will be text files. And I bet you
will ".whatever.ext" will identify a type (like .something.plist).

> The suggestion to remove ranges aims at facilitating any extensions/additions to the spec. E.g. if we would like to add ".p12" or Unicode extension to the File Identification Table, we should only have to add it there and not change the processing algorithm.
>

I understand the rationale, but I don't see it as necessary. Lets just
cover what is in the spec. In version 2, if we need to support this
later, we can add it easily. It won't break backwards compat because
we will just be expanding the range.

-- 
Marcos Caceres
http://datadriven.com.au
Received on Thursday, 22 October 2009 16:12:36 GMT

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