W3C home > Mailing lists > Public > ietf-http-ext@w3.org > January to March 1998

Re: First reactions to mandatory draft

From: Scott Lawrence <lawrence@agranat.com>
Date: Tue, 20 Jan 1998 10:15:33 -0500
Message-Id: <199801201515.KAA01090@devnix.agranat.com>
To: Rohit Khare <rohit@bordeaux.ics.uci.edu>
cc: frystyk@w3.org, paulle@microsoft.com, ietf-http-ext@w3.org

>>>>> "RK" == Rohit Khare <rohit@bordeaux.ics.uci.edu> writes:

RK> Scott LAwrence wrote:
>> If your intent is to allow me to define an extention that uses a
>> "Skidoo" header and then at run time decide that today I'm going to
>> send it as "23-Skidoo" then I think that is taking flexibility too
>> far.  If I'm adding support for an extention to my product, then I
>> want to know what headers it uses and just write code to recognize
>> them; not have to make the parser so general that it can strip and
>> ignore prefixes on the fly that may be different in each request.

RK> That's what it comes down to: how dynamically do we envision these
RK> extensions being added to systems? In short, can we expect an
RK> admin to drop in two versions of a Skidoo-handling extension that
RK> may both want to operate on the message. [...]

RK> There is no requirement for numeric-prefixes, of course.  It's
RK> just an option.  But, options have a cost, too, I'll grant.

  I discussed this by phone with Henrik a week or so ago, and promised
  him some revised text to address my concerns here.  Essentially, I'd
  like to clarify that the use of the numeric prefix mechanism is
  optional, and add a response indication from the server to
  communicate that while it may understand the proposed extention, it
  does not implement the ns= mechanism so that the request must be
  resent without it.

  I'll try to get that text out this week.

Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/
Received on Tuesday, 20 January 1998 10:17:03 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 15:49:07 UTC