- From: Koen Holtman <koen@win.tue.nl>
- Date: Mon, 11 Nov 1996 15:06:04 +0100 (MET)
- To: Ka-Ping Yee <kpyee@aw.sgi.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, masinter@parc.xerox.com, frystyk@w3.org
Ka-Ping Yee: > First, thanks for your support. [...] > >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. > >can i ask why? 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