- From: Koen Holtman <koen@win.tue.nl>
- Date: Thu, 24 Jul 1997 19:59:43 +0200 (MET DST)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Jeffrey Mogul: > >I realize that some people were opposed to the introduction of qvalues >on Accept-Encoding. However, during today's editorial-group discussion >of the CONTENT-ENCODING issue, we realized that the syntax for the >various Accept-* request headers in RFC2068 is almost, but not quite, >uniform, and we reached a tentative agreement that it might be a good >idea to have all of the Accept-* request headers (Accept-Range is a >response header) have similar syntaxes. Well, I guess I disagree with your tentative agreement about what might be a good idea. >As I said in my previous message, introducing qvalues for >Accept-Encoding won't work "if any existing servers or proxies would >choke on a qvalue in an Accept-Encoding header." >But (so far) nobody has asserted than this is an actual problem. I feel that the burden of proof that adding q values does *not* introduce new problems is entirely on your side. You need to show that this does not break or disable existing implementations. At this stage in the standards process, we are supposed to be fixing problems based on implementation experience. For me, this means that compatibility considerations *always* outweigh considerations of cosmetic uniformity. So you'd better show that the compatibility considerations are absent. >-Jeff Koen.
Received on Thursday, 24 July 1997 11:06:55 UTC