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

Re: Content Negotiation: state of the art!

From: Koen Holtman <koen@win.tue.nl>
Date: Wed, 13 Nov 1996 00:37:41 +0100 (MET)
Message-Id: <199611122337.AAA27603@wsooti04.win.tue.nl>
To: "David W. Morris" <dwm@xpasc.com>
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
David W. Morris:
>On Mon, 11 Nov 1996, Koen Holtman wrote:
>
>> I do too, and it is accounted for.  What happens is that the user
>> agent uses a feature-expr "x_version<=100" to say:
>> 
>>  I support X versions 0 -- 100
>
>While it seems safer to state support for a bounded interval, it seems
>likely that some will wish to state support for 101 --> oo
>because of a significant change in 101.  Probably better to
>say x_version >=101 and x_version <= 200 

I think you make a good case for adding complexity with the `I support
versions 101 -- 200' example.

>but until a conflict on the
>upside is known, x_version>=101 would work.

x_version>=101 would work at first, but it is fundamentally broken.
If 201 is a newer version of x with a significant change, then a
browser which sends only x_version>=101 will choke when getting a 201
version it reported it could handle.  The broad deployment of a
browser which sends only x_version>=101 will thus _prevent_ the smooth
introduction of version 201.  This is the kind of trickiness we are
dealing with.

So I think that if we have ">=", because it is useful in some cases,
we should also make it very easy to say that you support an interval
like 101 -- 200.

We cannot go for the interval notation "x_version=101-200" because we
would get a parsing ambiguity: x_version could also be a non-numeric
tag with the value "101-200".

I guess that adding a notation

  x_version=<101-200>

which allows the shorter versions

  blah=<255->    wox=<-200>

meets all concerns best.  I'll add it in the next version.  If you
know a nicer notation, let me know.

Note that I'll also keep the wox<=200 notation.

> But I may also wish to
>say I support colors >= 256, etc.

I don't know if you would want that for the color case.  If your
screen can show at most 2^8 colors and you say you can handle more,
you run the risk of getting the best variant with 2^24 colors, which
takes twice as long to download and 5 times as long to render in 2^8
colors, instead of the 2^8 color variant the server also had.

>Dave

Koen.
Received on Tuesday, 12 November 1996 15:49:10 EST

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