Subject: draft-ietf-conneg-feature-syntax-xx.txt

From: Graham Klyne <[email-masked]>
Date: Tue, 10 Nov 1998 20:11:59 +0000

I have changed the -syntax- draft wording to reflect concerns raised.  The
changes are quite modest and do not justify re-publication of the entire
draft at this time, so I include the proposed re-wording below.

#g
--

3.6 Describing preferences

A convenient way to describe preferences is by numeric 
"quality values", as used in HTTP "Accept" headers, etc. 
(see RFC 2068 [9], section 3.9).

It has been suggested that numeric quality values are 
potentially misleading if used as more than just a way of 
ranking options.  For the purposes of this memo, ranking 
of options is sufficient.

Numeric quality values in the range 0 to 1 (using the 
syntax defined by RFC 2068 [9], section 3.9) are used to 
rank feature sets according to preference.  Higher values 
are preferred over lower values, and equal values are 
presumed to be equally preferred.  Beyond this, the 
actual number used has no significance defined here.
Arithmetic operations on quality values are likely to 
produce unpredictable results unless appropriate 
semantics have been defined for the context where such 
operations are used.

In the absence of any explicitly applied quality value, a 
value of "1" is assumed, suggesting an "ideal" option 
that is equally or more preferred than any other.

Using the notation defined later, a quality value may be 
attached to any feature set predicate sub-expression:

(| (& (pix-x=750) (pix-y=500) (color=15) );q=0.8
   (& (dpi>=150) (papersize=iso-A4) )     ;q=0.7 )

The next section explains that quality values attached to 
sub-expressions are not always useful.

3.7 Combining preferences

The general problem of describing and combining 
preferences among feature sets is very much more complex 
than simply describing allowable feature sets.  For 
example, given two feature sets:

(& (a1);q=0.8 (b1);q=0.7 )
(& (a2);q=0.5 (b2);q=0.9 )

where:

feature a1 is preferred over a2
feature b2 is preferred over b1

Which of these feature sets is preferred?  In the absence 
of additional information or assumptions, there is no 
generally satisfactory answer to this.

The proposed resolution of this issue is simply to say 
that no rules are provided for combining preference 
information.  Applied to the above example, any 
preference information about (a1) in relation to (a2), or 
(b1) in relation to (b2) is not presumed to convey 
information about preference of (& (a1) (b1) ) in 
relation to (& (a2) (b2) ).

In practical terms, this restricts the application of 
preference information to top-level predicate clauses.  A 
top-level clause completely defines an allowable feature 
set;  clauses combined by logical-AND operators cannot be 
top-level clauses (see canonical format for feature set 
predicates, described later).

NOTE: This memo does not apply specific meaning 
to quality values or rules for combining them.  
Application of such meanings and rules is not 
prohibited, but is seen as an area for 
continuing research and experimentation.

An example of a design that uses extended 
quality value semantics and combining 
operations is "Transparent Content Negotiation 
in HTTP" [4].

------------
Graham Klyne
([email-masked])

---

From: Al Gilman <[email-masked]>
Date: Tue, 10 Nov 1998 20:49:35 -0500 (EST)

to follow up on what Graham Klyne said:

> I have changed the -syntax- draft wording to reflect concerns
> raised.  The changes are quite modest and do not justify
> re-publication of the entire draft at this time, so I include
> the proposed re-wording below.

Sounds good.  Did you consider making an explicit statement that
q=0 means categorically unacceptable?  Or do we leave
applications free to decide how not-mentioned complares with q=0?

Al