W3C home > Mailing lists > Public > ietf-discuss@w3.org > December 1998

Re: Looking for comments on the HTTP Extension draft

From: Graham Klyne <GK@Dial.pipex.com>
Date: Tue, 29 Dec 1998 19:52:25 +0000
Message-Id: <3.0.32.19981225194344.00691b98@pop.dial.pipex.com>
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: Ted Hardie <hardie@equinix.com>, masinter@parc.xerox.com, Chris.Newman@innosoft.com, discuss@apps.ietf.org
At 21:38 23/12/98 -0500, Henrik Frystyk Nielsen wrote:

>At 12:21 12/22/98 -0800, Ted Hardie wrote:
>>4) The content negotiation implied by the document is also not
>>workable within the current CONNEG framework, because the set
>>intersection model CONNEG uses presumes that the resource is intended
>>for a single purpose; it has no provision for a resource that is a
>>token, a description, and machine-usable code.  In the current
>>framework, a device selects among multiple values in a set
>>intersection by q-value, not purpose.  It can't really select "one for
>>this and one for that" in the same operation.
>
>Unless this is different from HTTP then the q values describe the value on
the axis and not the dimension of the axis. q values can be applied to any
dimension be it type or some other property. In fact, the negotiation
hinted at here only spans the media type.



If my understanding of HTTP is correct (and, for the purposes of this
distinction, not including TCN), each of the dimensions of variability
(indicated by Accept:, Accept-charset:, Accept-language:) is presumed to
independently variable.  Thus, it makes sense to permit q-values to be
determined independently for each such dimension.

The 'conneg' framework greatly increases the number of dimensions of
variability (through feature registration), and also provides a general
framework for constraining variations in one dimension with respect to
variations in some other dimension(s).  Thus it seems more helpful to apply
the q-value unidimensionally to a combination of variable features, rather
than independently to each dimension of variability.  TCN [RFC2295] adopts
a similar approach when describing the source quality of a resource, and
avoids allowing a client to indicate quality values associated with feature
tags.

The 'conneg' framework does not preclude further development of some more
fine grained q-value indication, but has not attempted to specify such at
this time.

#g

------------
Graham Klyne
(GK@ACM.ORG)
Received on Tuesday, 29 December 1998 13:50:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 March 2006 20:11:25 GMT