W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: feature negotiation

From: Koen Holtman <koen@win.tue.nl>
Date: Mon, 26 Feb 1996 21:56:15 +0100 (MET)
Message-Id: <199602262056.UAA28107@wsooti13.win.tue.nl>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Larry Masinter:
>[Koen Holtman:]
>> [## Question to be resolved: Should a rudimentary feature negotiation
>> facilities that work for 90% of the cases be added as a stopgap??  I
>> wonder if we won't be doing the web community a disservice if we delay
>> a 90% solution in order to construct a 99% solution for HTTP 1.2.
>> After all, most negotiation that happens now is on tables vs. no
>> tables, not on language or MIME type.
>> ##]
>
>I think we should just put this as a separate issue.

I agree.  I have tried to write draft-holtman-http-negotiation-00.txt
in such a way that it would be orthogonal to the feature negotiation
issue.

>Here's a strawman proposal:
>
>*   request that IANA extend media type registrations to allow
>    registration of feature names for each media type.
>    90% solution says: feature names are atomic, contain
>    only alphanumeric characters, feature registration
>    for an Internet Media Type requires same documentation
>    rules as for Media Type but no waiting period (since 
>    there are no additional security considerations).
>    
>*    Extend syntax of Accept: to allow
>     :features=f1;f2;f3;f4
>
>Example:
>
>Register "color, 24bit" to image/gif, "color" to
>application/postscript and "tables, font, style, center" to text/html.
>
>Accept: text/html;version=2:q=0.8:features=tables;font
>
>This assumes we can unblock IANA registrations. I don't know any other
>way of negotiating features unless feature names are registered,
>though. (Otherwise, where's the web of trust?)

I think your proposal is a good start.  I also like the 'Appendix B'
ideas brought up elsewhere in this thread.

I have thought a lot about feature negotiation, and here is my list of
associated problems:

1) What is the granularity of the feature identifiers?  Do we want 5,
   50, or 500 to be in general use?  The granularity had an impact on
   almost everything below.

2) Finding someone to register feature identifiers, and getting
   consensus about rules for registration. As you say: "This assumes
   we can unblock IANA registrations.".
   
   Maybe the only viable option is to spec a mechanism which will not
   suffer if 1000 feature identifiers, most of them overlapping and
   thought up by bozo's, are registered.  With such an
   insanity-resistant mechanism, the registration rules can be
   `anything you send us, we register'.  This means that the
   registration authority does not have to filter out the insanity,
   which is good because filtering could lead to a registration
   process too slow to keep up with the Web.  Eventually, evolution
   would weed out the bozotic identifiers.  Web robots could (as a
   side effect) gather statistics on which identifiers actually get
   used in content.

3) If we have feature negotiation, we make it easier for everyone
   (browser and content authors alike) not to comply to the full
   HTML x.y standard.  People who hope that one day, everybody will
   finally comply to one HTML x.y standard will not like this.  Don't
   we throw away our long term chances for a universaly implemented
   HTML standard by making life easier now?

   A political struggle between the `suffer now to make the future
   great' and the `make the present more comfortable' camps could
   stall consensus on feature negotiation till well past the end of
   this millenium.

4) Feature negotiation, if it is specified in the wrong way, will put
   pressure on browsers to send very long lists of all supported
   features in every request. 

   Specifying it so that it is safe to keep accept headers short,
   omitting some of the more obscure features you support, because you
   will get a reactive negotiation response in this case, not the
   <pre>...</pre> version even though you can handle the
   <obscure>...</obscure> version, is not trivial.

   It can be done, though, draft-holtman-http-negotiation-00.txt
   contains a mechanism that removes the pressure to send long lists
   of supported MIME types, and a similar mechanism is possible for
   lists of supported features.

Koen.
Received on Monday, 26 February 1996 13:04:59 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:46 EDT