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

At 16:21 11/19/97 -0800, Roy T. Fielding wrote:

>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.

There has been no claim that Accept-TE is part of content negotiation any
more than Accept-Encoding and Accept-Range. It is the same as
Content-Length and Content-MD5 has nothing to do with metadata and to say
that User-Agent is not used for content-negotiation.

I said that Accept-TE really should be a general header but that HTTP
doesn't have proper support for handling this, it has to be a request header.

I don't buy the argument of complexity. The simple case is indeed simple
but that should not prevent future versions from adding more complexity. If
we don't allow this, then they will kludge around it and the abstract
layering model will break down even more.

As I said, it is in the one hour hacking range - I did the client side
support in that amount of time in libwww.

That put aside, I would like to reach closure on this - otherwise, it will
drop on the floor and we will not be able to introduce new transport
filters. If people think that the name of the header is a problem, then
that's easy to fix.  Suggestions of the top of my head are:

	Transfer
	TE
	47

"TE" seems as a nice compromise to me.

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Thursday, 20 November 1997 06:22:10 UTC