# Re: Content Negotiation: state of the art!

From: Koen Holtman <koen@win.tue.nl>
Date: Mon, 11 Nov 1996 15:06:04 +0100 (MET)
Message-Id: <199611111406.PAA07810@wsooti10.win.tue.nl>
To: Ka-Ping Yee <kpyee@aw.sgi.com>

X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1899
```Ka-Ping Yee:
>

[...]
>
>While skimming through the draft i wondered about two things:
>
>Why do feature expressions allow "<=" but not ">=" ?

Some background: we now have:

ftag=V
ftag is present with the value V
!ftag=V
ftag is present, but not with the value V
ftag={V}
ftag is present with the value V, and not with any other values
ftag<=N
ftag is present with the numeric values from 0 up to and
including N, and not with any other values

In principle, the two forms ftag=V and !ftag=V are all you ever need
if you want to negotiate on a feature tag which has some values.  If
you have a feature tag with the values 100 -- infinity, you would use
expressions like !ftag=99 and ftag=101 to negotiate on it.

The two special forms ftag={V} and ftag<=N are there to optimise the
frequently occuring cases of having a tag with a single value and a
tag with a numeric range 0 -- N of values.

We don't think that a numeric range N -- infinity is a frequently
occuring case, so there is no ftag>=N form to optimize it.

>  And as for the
>following note:
>
>>    The length attribute (if present) must reflect the length of the
>>    variant alone, and not the sum of the lengths of the variant and
>>    any objects inlined or embedded by the variant.
>

It could have been defined the other way around, but you have to pick
one of the two possibilities.  We picked the first one, mainly because
of symmetry with the content-length header and because the length of
the variant alone is easier for a server to measure.

Note that the spec leaves open the possibility of defining a
`length-with-inlined-and-embedded-objects' attribute in a future
specification.

>Curious,
>
>
>Ping

Koen.
```
Received on Monday, 11 November 1996 06:25:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:18 UTC