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

Re: Accept-Transfer header field (was HTTP/1.1 Issues:

From: Scott Lawrence <lawrence@agranat.com>
Date: Wed, 19 Nov 1997 18:25:20 -0500
Message-Id: <199711192325.SAA30638@devnix.agranat.com>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4752

>>>>> "JM" == Jeffrey Mogul <mogul@pa.dec.com> writes:

JM> Koen writes:
JM>     And no gunky parameters about compression quality or dictionaries
JM>     please -- adding these would take the whole thing way beyond a 1.1
JM>     cleanup, and how are we ever going to claim two independent
JM>     implementations for such things if we add them?

JM> [...]

JM> But beyond that, if we don't add parameters NOW, we will never
JM> be able to do so, because then there will be an incompatibility
JM> with the installed base.  History has shown us that HTTP has
JM> suffered in many ways from a lack of extensibility mechanisms,
JM> and since this one is exactly the same as we already have used
JM> in other headers, it seems rational to use it for transfer-codings.

  I buy the argument that allowing for extentions in the syntax is a
  good thing even (perhaps especially) if we don't use them now, so
  put it in.

  I also feel strongly that the transfer coding is the servers
  business and 'q' values will, in practice, be ignored.  If this
  argues for renaming the header to not be Accept-*, then rename it.

Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/
Received on Wednesday, 19 November 1997 15:39:37 UTC

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