Re: Summary of opinions on Negotiate header

On Wed, 25 Sep 1996, Roy T. Fielding wrote:

> >>I would prefer `Negotiate: t' myself, since the 'cn' serves no useful
> >>purpose given the context.  I was thinking of using `Negotiate: a'
> >>for pure agent-driven negotiation (without the proxy mumbo jumbo).
> > 
> > Please no.  Is the savings of "cn" or "gent-driven" enough to justify
> > (a) the possible confusion; and (b) the rush to use the other 24 letters?
> 
> (a) there will be no confusion (it isn't subject to English interpretation,
>     only mechanical)

Then you are engaged in writing a *machine interpretable* HTTP. Quit
playing around with long meaningful header names and start using machine
coding. Either this is for people or this is for machines.

> 
> (b) every single byte on a request message matters if it is the one
>     that causes the request to exceed two TCP packets.

Then use 'N: t'. It saves *eight* bytes - four times as many as the switch
from 'tcn' to 't'. Ditto for the other headers. They are coded in ways
that take *at least* ten times as many bytes as a true machine oriented
protocal would. ISO8859-1 'pseudo-english' is an incredibly inefficient
way to talk to computers. This is one of the big reasons why content
negotiation has never worked - it adds so many bytes to requests that
browsers go for the wildcards and omit q values completely - thus making
negotiation all but impossible. I am of the opinion that content
negotiation was mis-handled right from the start with the 'hide several
resources behind a single URL' approach. Transparent negotiation was both
obvious and suggested (under the guise of adding variants to HTML -
which I *still* think is a good idea - you save an round trip over
Transparent Neg with all the same benefits) a long time ago. 

> 
> and I'll add,
> 
> (c) namespace collision is not an issue provided that the syntax
>     remains open-ended (a token) for other directives.
> 
> and "tcn" is no more meaningful than "t" in this context.

Both are an abuse of the header system. Either it is for humans and should
be readable *by humans* or it is for machines and should be coded densely
*for machines*. Quit pussy footing around with 'semi-human readable'. It
has serious costs for computers and is nearly useless for humans other
than the designers of the protocal anyway. 

By the way, a benefit of the alternate proposal for adding a new MIME type
of 'n/t' instead of a new 'Negotiate' header that no one has mentioned is
that it could be used *today* with the Apache 1.1.1 server's content
negotiation and .asis or .meta modules. This means that Transparent
negotiation would *already* have a working and widely installed working
implementation rather than waiting for *someone* to implement it and even
longer for the implementation to reach a significant market share. All you
would need is a browser to implement it (which should be trivial). And it
saves another byte (or two, depending on browser implementation).

I think that having a new MIME type 'n/t' is really the way to go rather
than a 'Negotiate:' (unimplemented by anyone yet) header. 

-- 
Benjamin Franz

Received on Wednesday, 25 September 1996 22:28:02 UTC