RE: First reactions to mandatory draft

From: Paul Leach (
Date: Tue, Jan 20 1998

Message-ID: <>
From: Paul Leach <>
To: "'Scott Lawrence'" <>
Cc: Rohit Khare <>,,
Date: Tue, 20 Jan 1998 11:58:06 -0800
Subject: RE: First reactions to mandatory draft

> ----------
> From: 	Scott Lawrence[]
> Sent: 	Tuesday, January 20, 1998 11:41 AM
> To: 	Paul Leach
> Cc: 	Rohit Khare;;
> Subject: 	Re: First reactions to mandatory draft
> >>>>> "PL" == Paul Leach <> writes:
> PL> Numeric perfixes aren't to allow multiple instances of the _same_
> extension
> PL> in one message -- they are to guard against the possibility (to use
> your
> PL> example) that two independent parties design an extension, and both
> call it
> PL> "Skidoo" (but they will have different URLs for the extension, of
> course),
> PL> and still allow both to be used in one request.
>   I think that having different URLs to identify the extentions is
>   sufficient; if the extentions are so incompatible that they cannot
>   be used in the same header syntax unambiguously, then they shouldn't
>   be implemented in the same place anyway.
What? First, if two groups invented the extension independently, there will
almost certainly be _no_ relation between them. Second, if there's just a
URL, how can you tell which headers go with that URL?

>   I don't want to have to (won't) implement a parser that can deal
>   with:
>     GET /xyz HTTP/1.1
>     Host: foobar
>     23-Skidoo: abc
>     65-Skidoo: def
>     Man: ""; ns=23-,
>          ""; ns=65-
>   by having to backtrack my parser to remove the 23- and recognize the
>   'Skidoo'; by the time I get to the Man header, I've seen the
>   two numeric prefix headers and discarded them as unrecognized (and
>   therefor automatically optional) headers.
This is independent of the use of numerical prefixes. I always thought it
was obvious that the Man header was required to come _ahead_ of any uses --
but I can't recall if the spec _says_ that.

>   Even supposing hypothetically that we did do this, what happens to
>   the headers now - granted we separated them for transmission, but
>   internally the values will be combined anyway as though they were
>   sent as
>     Skidoo: abc, def
>   because that is what header folding rules say we should be able to
>   do.
23-Skidoo and 65-SKidoo are _not_ the same header, so they shouldn't be

>   We're close to having a registry for header field names anyway; I
>   just don't think that this extra complexity is warranted.
It seems that at least some of the complexity is due to a misconception.