Re: Accept-Transfer header field (was HTTP/1.1 Issues:
Scott Lawrence (lawrence@agranat.com)
Wed, 19 Nov 1997 18:25:20 -0500
>>>>> "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/