[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on draft-ietf-conneg-feature-syntax-01.txt



At 19:24 13/11/98 +0100, Koen Holtman wrote:
>The revised wording you posted is an improvement but I think it still
>mixes up the definition of q values too much with the referencing to
>2068.

OK, I've pulled the HTTP references out of the mainline text, and demoted
them to commentary at the end of the section.

>  I would very much like to see a completely self-contained
>definition consisting of 

> - syntax of common representation for ascii-based negotiation
>   frameworks (same as in http)
> - definition of range (0-1)
> - definition of default value (1)
> - discussion of the limited semantics ('ordering, less is worse').
> - declaration that specific protocols may extend the semantics
>   defined here
>
>and with all discussion of use in other protocols, the
>difficulties of combining, etc, in *other* sections (maybe
>subsections).

I believe what I have now is not so far from that goal:  I have separate
sections for defining q-values and their meaning, and combining q-values,
with references to other protocols clearly set apart in commentary.

The revised text is below.

Thanks for your comments.

#g
--



3.6 Describing preferences

A convenient way to describe preferences is by numeric 
"quality values".

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, with up to 3 
fractional digits, 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.

NOTE:  the syntax for quality values used here 
taken from that defined for HTTP 'Accept:' 
headers in RFC 2068 [9], section 3.9.  However, 
the use of quality values defined here does not go as 
far as that defined in RFC 2068.


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].  Other work that also extends 
quality values is the content negotiation 
algorithm in the Apache HTTP server [14].

------------
Graham Klyne
(GK@xxxxxxx)