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

From: Graham Klyne <[email-masked]>
Date: Fri, 06 Nov 1998 12:43:39 +0000

At 19:48 30/10/98 +0100, Koen Holtman wrote:
>
>A comment on the discussion of q values in the -01- draft (sections
>3.6, 3.7):
>
>These sections express a very pessimistic view on the topic of whether
>one could have a working semantics for q values.  I do not share that
>pessimism.  I am not sure if the sections are supposed to express the
>WG consensus on the topic, or the opinion of the author, and whether
>they are meant to apply to fully generic frameworks only or to
>special-case frameworks too.

It was my belief that I was capturing a forming workgroup consensus.  If I
am wrong in this, I am fully prepared to be corrected.

>In 3.6 third paragraph it says:
>
>  Numeric quality values in the range 0 to 1 (as 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 by this memo,
>
>I believe 'this memo' above is RFC 2068, and on that basis I object to
>the above wording.  I would argue that the two headers

'this memo' was meant to indicate the -syntax- draft in which the statement
occurred.

Does this make the intent clearer?:

>  Numeric quality values in the range 0 to 1 (as 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,
......................................................^^^^

The intent was to permit more specific q-value semantics, but to explicitly
not state in the -syntax- draft what they should be.

As such I am not attempting to make any comment on the content of RFC2068.

>At the end of the paragraph it would be good to add a pointer to
>rfc2295 (section 5.3) as an example of a system which does 'suitably
>define' a scale for quality values in one context.

.......................

>The note at the end of 3.7 is misleading, because there has been
>'research and experimentation' with q value semantics in the past.  In
>fact the apache server mod_negotiation is an example of a deployed
>system which calculates with q values.  I believe these calculations
>in apache predate TCN, they were instead based on the multiplication
>formulae in very old HTTP specs, which are in turn based on still
>older work by Tim BL.  TCN is of course another example of past work
>on the topic.  There may be examples outside of HTTP negotiation too.

The current text reads:

       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 future research and experimentation.

Would you find the following more acceptable?:

       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.
......................^^^^^^^^^^

>Overall the sections provide a very one-sided view: I would like to
>see something more balanced, especially if this is to progress on the
>standards track as a guidleline for the authors and of negotiation
>protocols.

I writing this, it was not my intention to either promote of discourage
more specific q-value semantics.  Rather, I wanted to reflect what I
thought was an emerging consensus that q-value semantics was a difficult
area, with many possible variations and no clear Right Way.  The document
attempts to indicate some minimal q-value semantics that can be a starting
point for more detailed work, while trying to avoid prescription of such
detail.

I have no objection to adding examples of past work to the note indicated
above.  TCN is one such candidate;  can you provide a full reference for
the Apache work that you mention?

I think two well-chosen examples here would be sufficient indication here
to show that there is existing work upon which more specific q-value
semantics might be based.

#g

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

---

From: [email-masked] (Koen Holtman)
Date: Thu, 12 Nov 1998 14:31:56 +0100 (MET)

>At 19:48 30/10/98 +0100, Koen Holtman wrote:
[....]
>>  the actual number used has no significance defined here,

I think the way to resolve this is to state explicitely in the
-syntax- draft that the work makes no prescriptions *at all* about q
value semantics, and that this is left completely to individual
negotiation procotocols.  After this statement some protocols which do
make prescriptions (like http and TCN) could be discussed or
referenced.

Reading the 01 syntax draft I gathered that you intended to prescribe
rfc2068 q value semantics as the baseline for all q value semantics in
any negotriation protocol.  Reading your and Ted's responses on the
mailing list I think this impression was wrong, and that you do not
want to prescribe anything.  I would agree to taking this position,
and then my only complaint is that it should be made more clear in the
draft.  We can shelve the issue of getting a conneg consensus about
the exact interpretation of the scope of q value semantics in 2086.

>       as an area for continuing research and experimentation.

Yes, this is much better.

[...]
>the Apache work that you mention?

The current apache negotiation algorithm is described at
http://www.apache.org/docs/content-negotiation.html . It multiples
source quality with mime type quality, but does not perform
calculations on other quality values (e.g. language quality), probably
because at the time the code was written browsers did not send quality
factors on languages etc (I do not know if many do now).

Koen.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 12 Nov 1998 16:11:21 -0800 (PST)

This is substantially in agreement with my sense of things, with
two caveats:  we do need to specify the data type and range for
q values (we don't want q="real good") and we do need to specify
the directionality (we don't want some people thinking higher
is better and others thinking lower is better).  Those two
don't significantly restrict future, intelligent q value
processing, and they significantly increase the chance that
later systems can have some minimal interaction without breaking.

		regards,
			Ted Hardie
			[email-masked]