- From: Henrik Frystyk Nielsen <frystyk@w3.org>
- Date: Wed, 19 Nov 1997 13:47:19 -0500
- To: Jeffrey Mogul <mogul@pa.dec.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
At 17:16 11/18/97 PST, Jeffrey Mogul wrote: >I expect to get flamed for this message, but I sort of promised someone >that I would make the attempt. ... >Somewhat more exotic, but hardly without practical merit, is the >possibility of using pre-agreed compression dictionaries to further >reduce the size of the transferred compressed form. The idea is that >it should take fewer bytes to send the name of the appropriate >dictionary than to transmit its contents. However, in this case, the >sender needs a way to name the dictionary used in the message. I wouldn't say that - for small files of often used media types (HTML, XML, SGML, for example), it may make a lot of sense to have pregenerated dictionaries. Jim and I talked to Mark Adler and Jean-loup Gailly during our performance testing but didn't have time to try it out. If the dictionary was a resource in itself, it would work fine. Deflate uses a Adler32 hash to name the dictionary. Depending on how good the hash is (I don't know), it may be used as a location indendent identifier in itself or by hashing it again using some stronger hash algorithm. >Suppose, therefore, that we change this syntax in section 3.6 >(Transfer Codings) from You have a good point - and we actually already have the BNF for generalized parameters from the Accept header and the Content-Type header fields. However, it introduces the problem of separating extension parameters in Accept-TE from extension parameters in transfer-codings just like is currently the case with Accept (see 14.1): Note: Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters in Accept. Future media types should be discouraged from registering any parameter named "q". Are people willing to live with that? Henrik -- Henrik Frystyk Nielsen, World Wide Web Consortium http://www.w3.org/People/Frystyk
Received on Wednesday, 19 November 1997 10:51:34 UTC