- From: Marcos Caceres <marcosc@opera.com>
- Date: Thu, 22 Oct 2009 18:12:02 +0200
- 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 UTC