Re: First reactions to mandatory draft

From: Rohit Khare (rohit@bordeaux.ics.uci.edu)
Date: Thu, Jan 15 1998


To: Scott Lawrence <lawrence@agranat.com>
cc: frystyk@w3.org, paulle@microsoft.com, ietf-http-ext@w3.org
Date: Thu, 15 Jan 1998 00:48:09 -0800
From: Rohit Khare <rohit@bordeaux.ics.uci.edu>
Message-ID:  <9801150048.aa25742@paris.ics.uci.edu>
Subject: Re: First reactions to mandatory draft 

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.
> 

That's what it comes down to: how dynamically do we envision these extensions 
being added to systems? In short, can we expect an admin to drop in two 
versions of a Skidoo-handling extension that may both want to operate on the 
message. This isn't entirely far-fetched, as in mulitple implemntation 
versions of a single extension-spec (23-DSIG for export, el-gamal; 25-DSIG for 
domestic DSA, etc), and for repeated application of the same extension (server 
adds its sig; proxy appends its own).

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

I am not sure there is a showstopper-requirement that numeric-prefixes are 
required for: use foldable field-values for mulitple application; use the same 
header for compatible upgrades and new headers for new purposes. 

The remaining convenience is stripping off all related headers and passing 
them to an ext module for processing. On the other hand, there could be a 
claim that an extension plug in is always capable of registering all headers 
it is interested in. 

Even as one of the original creators and proponents of this mechanism, I admit 
it may not deserve to be in an absolutely minimal version.

Rohit Khare
rohit@uci.edu