- From: Rohit Khare <rohit@bordeaux.ics.uci.edu>
- Date: Thu, 15 Jan 1998 00:48:09 -0800
- To: Scott Lawrence <lawrence@agranat.com>
- cc: frystyk@w3.org, paulle@microsoft.com, ietf-http-ext@w3.org
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
Received on Thursday, 15 January 1998 03:49:54 UTC