Re: Summary of opinions on Negotiate header

>> 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).
> 
> Anyone else *REALLY* peeved at this 'abbreviate until meaningless'
> approach to header design? You might as well go whole hog - why just save
> two bytes from the *value* of the when you can save 8 from the *name* of
> the header? Just call it 'N: t'. :/ If you are *SERIOUS* about saving
> bytes in the header - change to a machine readable format. But don't play
> this game of 'this is a human readable format so we will give it a
> meaningful name and then chop so many letters out that the meaning is
> lost'. The first rule of abbreviation for humans is to remove as many
> letters as possible without losing the meaning *and no more*. 

You have to understand the protocol design issues involved.

HTTP includes a number of separate namespaces, each of which has differing
constraints, but all of which share the requirement of being extensible
without bound.  Some of the namespaces are governed by HTTP (status codes,
content-codings, etc.) and others are governed by other standards
(mime-types, charset, etc.) and some of which are shared by multiple
standards.  Header field-names fall into the latter category.  We define
new field names as close to their meaning as possible in order to avoid
name collision with those other standards and with applications that
have separately extended the same namespace.

In contrast, a field value is a separate context, and thus a separate
namespace.  Provided that we don't do anything stupid like redefine
existing practice, we can be as abbreviated as we like without worrying
about namespace collision.  It is a choice we have to make, and one that
should be made based on the frequency of that field's occurrence in a
"normal" HTTP request.

Right now, HTTP shares its field-name namespace with MIME/E-mail.
That is why we have preferred long names in the past -- human readability
of the protocol is not a significant concern beyond what is required
to be readable at all via TELNET.  A tokenized HTTP (what I sometimes
call HTTP/2.x, but really shouldn't) would essentially make the namespace
private to HTTP, at which point most of these issues go away.

In terms of human readability,

    Negotiate: t
and
    Negotiate: transparent

are equally readable.  If the person doesn't know what Negotiate means,
then "transparent" is also meaningless (and might even be misleading).
In contrast, there is a significant difference between the above and

    N: t

particularly if it were received in an unusual context like E-mail.

That is the rationale behind the HTTP/1.1 design. It may seem at times
to be a contradiction, but we live in an imperfect world.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Thursday, 26 September 1996 16:53:05 UTC