- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Wed, 19 Nov 1997 16:21:28 -0800
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Connection: deflate > Deflate: --best > >This has some things to recommend it, but unfortunately it >won't quite work. The most significant problem is that it >doesn't work with multiple transfer-codings on the same message. I was talking about the other side of the information exchange, i.e., what the sender would like to see in the response, not what has been applied to the response. The former is not subject to hierarchy. My impression was that all transfer encodings would be self-descriptive (i.e., that any applied parameters that might be needed by the decoder would be contained at the beginning of the coded body). Granted, you could easily define an encoding for which that is not the case, but I see no reason why we should. Even so, you would only need ordered parameters in the Transfer-Encoding syntax, whereas my proposal is a replacement for only the Accept-TE stuff that Henrik proposed. BTW, I *really* *really* dislike Accept-TE, both in terms of syntax and in the mistake of associating it with end-to-end content negotiation. It is possible to make this feature so complex that nobody will implement it at all, regardless of the potential benefits of compressed transfers. It is also possible to introduce so many optional parameterizations of the "requesting encoding" side of the equation that the actual implementation becomes less optimal (i.e., reusable) than no encoding. In this case, keep it simple really means keep it simple or not at all. I also agree with Larry in that none of these proposals belong in rev-01. ....Roy
Received on Wednesday, 19 November 1997 16:43:22 UTC