- From: Dan Brickley <danbri@danbri.org>
- Date: Mon, 01 Dec 2008 17:31:31 +0000
- To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
- Cc: Marcos Caceres <marcosscaceres@gmail.com>, "www-tag@w3.org" <www-tag@w3.org>, public-webapps <public-webapps@w3.org>
Williams, Stuart (HP Labs, Bristol) wrote: >>> Well there are ways around that, add a package description >>> or meta-data file either at the root of the package or at >>> each directory level and have it carry media-type information >>> - or use 'magic numbers' or (if you really must - in the >>> absense of other authoritative information), sniff/guess >>> though I think that should be the least preferred option. >>> >> Right. The new proposal is that we use file extension mappings to MIME >> types, and if that fails, result to sniffing. We are reluctant to >> introduce a meta-data format at this point. (Just allow RDFa+XHTML and leave it to the marketplace...) >> For version 2 of widgets, >> it might be useful to either introduce the meta-data format or have >> an Apache-like file extensions to MIME type mapping. For example: >> >> image/gif .gif >> >> Note however, that widget engine in the wild have no problem working >> without MIME info. From what I have seen, they all do just fine either >> sniffing or using file extensions to derive the content types. >> >>> Anyway - that zip files don't intrinically maintain such >>> info is not a show stopper - though I would have thought that >>> carrying media-type information is a natural requirement for >>> a packaging format for the web. >>> >> I'm not sure it is. When a MIME type is registered with IANA, the file >> extension is also registered. > > What is registered (RFC 4288 section 4.11) is a list of file name extensions commonly used with the media-type. > It does *not* reserve the extension for exclusive use with that media-type. > It does *not* prevent other arbitrary file name extension or indeed no-extension being used. > > So... yes not a bad hint, but nothing is certain. > >> So one has a standardized way to derive >> the media type for a file by the file extension. > > Not with certainty... So this seems like a very small piece of metadata ('this filetree follows the IANA filename to media type mappings') has a lot of value. If the versions of the IANA mapping are easily identified, the metadata becomes a URI rather than a single bit. Either way, you can gain a lot from not a lot, I think. cheers, Dan -- http://danbri.org/
Received on Monday, 1 December 2008 17:32:09 UTC