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

From: Graham Klyne <[email-masked]>
Date: Thu, 29 Oct 1998 15:13:25 +0000

At 21:12 28/10/98 +0100, Koen Holtman wrote:
>
>[Oops, forgot one point in my previous message]
>
>Graham Klyne:
>>
>>At 21:22 21/10/98 +0200, Koen Holtman wrote:
>[...]
>>>5.1.5: you forgot the rules for handling negation ( !filter ).
>>
>>One of the points of 5.1.4 is that it eliminates all negations.
>
>As far as I can see the syntax allows constructs like
>
>  (!(& a=5 b=7 (| c=8 d=9)))
>
>and these are not eliminated.

You are quite correct.  This is an omission on my part, and needs to be fixed.

Thanks for pointing that out.

(Originally, negations were moved inward as part of the reduction to normal
form.  That got lost along the line.  I think I need an additional step to
handle that case, so that all negations are forced to be part of the atomic
predicate processing.)

#g

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

---

From: [email-masked] (Koen Holtman)
Date: Fri, 30 Oct 1998 19:48:13 +0100 (MET)

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.  I note that we do not seem to have a
consensus on this topic in the WG (yet).  We seem to be leaning
towards the view however that full q value semantics will add too much
complexity if all parties in the negotiation process can use
unrestricted feature predicates for expressing their negotiation
capabilitities/preferences.

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

Accept-language: en=1.0, da=0.99, de=0.01

and

Accept-language: en=1.0, da=0.02, de=0.01

are *not* equivalent under RFC 2068, even though they express exacly
the same ranking.  There are certainly implementations around which do
not treat them as equivalent (see below).  According to 2068 these
numbers are 'weigths', not just funny devices for expressing an
ordering:

   HTTP content negotiation (section 12) uses short "floating point"
   numbers to indicate the relative importance ("weight") of various
   negotiable parameters.
   [....]
   "Quality values" is a misnomer, since these values merely represent
   relative degradation in desired quality.

The draft revision of 2068 also clarifies that q=0 has a special
meaning:

  If a
  parameter has a quality value of 0, then content with this parameter
is
  `not acceptable' for the client.

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.

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.

Koen.