Re: First reactions to mandatory draft

From: Scott Lawrence (lawrence@agranat.com)
Date: Tue, Jan 20 1998


Message-Id: <199801201941.OAA01664@devnix.agranat.com>
To: Paul Leach <paulle@microsoft.com>
cc: Rohit Khare <rohit@bordeaux.ics.uci.edu>, frystyk@w3.org, ietf-http-ext@w3.org
Date: Tue, 20 Jan 1998 14:41:19 -0500
From: "Scott Lawrence" <lawrence@agranat.com>
Subject: Re: First reactions to mandatory draft


>>>>> "PL" == Paul Leach <paulle@microsoft.com> 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.

  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: "http://screwball.org/skidoo.html"; ns=23-,
         "http://nutcase.org/skidoo.html"; 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.

  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.

  We're close to having a registry for header field names anyway; I
  just don't think that this extra complexity is warranted.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/