W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Parameters for transfer-codings?

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Wed, 19 Nov 1997 13:47:19 -0500
Message-Id: <>
To: Jeffrey Mogul <mogul@pa.dec.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4736
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

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 Frystyk Nielsen,
World Wide Web Consortium
Received on Wednesday, 19 November 1997 10:51:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC