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

From: [email-masked] (Ted Hardie)
Date: Sun, 1 Nov 1998 19:51:33 -0800 (PST)

I've made some comments below, but I'd like to preface them
with the general observation that the pessimism visible in
the documents may be a result of my pessimism as chair that
anything using q values in complex ways will not succeed in
a multi-protocol framework.  That said, it may be that we need
to move the documents towards encouragement of doing the
simplest possible thing with q values, rather than discouraging
it entirely.

I would also like to make clear that I do not believe that this
discussion is out of scope for the document, and I do not in
any way want my pessimism here to rule out discussion of the
issues.

On Oct 30,  7:48pm, Koen Holtman wrote:
> Subject: Comments on draft-ietf-conneg-feature-syntax-01.txt
>
> 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.

I think this is the key element in the whole set of problems--an unrestricted
set of feature predicates combined with q values seems extremely likely
to create a system that is either unwieldy in its complexity or simply not
used.  There will, however, certainly be contexts in which these documents
are used to build systems which do not allow unrestricted feature predicates
(there won't be many faxes with sound, for example).  In those contexts q
values
may be useful.  Encouraging folks to use q values in the most cautious ways
possible
even in those situations seems to me good design, however, as this means that
gateways and multi-protocol devices will not have severe problems with the
semantics.

>
> 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 usually means "the document you are reading".  If it has
another meaning here, we need different language.

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

Pointers to other work, as you provided above, are very useful in
helping provide balance.  We must be careful, however, that we do
not muddy the specification in the course of making it less pessimistic.

		regards,
			Ted Hardie

---

From: [email-masked] (Koen Holtman)
Date: Wed, 4 Nov 1998 19:05:34 +0100 (MET)

Ted Hardie:
[...]
>another meaning here, we need different language.

Well, if 'this memo' is the internet draft, my objection is
essentially unchanged except for an added level of indirection,
because the draft defines quality values by pointing to 2068.  If you
define q values by pointing to 2068, your definition is one which
*does* make the actual numbers significant, so you should not be
saying that it does not.

[...]
>not muddy the specification in the course of making it less pessimistic.

The draft is part discussion of options and part a definition of a
specific protocol (algorithm).  I have no objection if the definition
of the specific protocol does not include semantics for q values, but
the discussion part should discuss the issue in a balanced manner.

Koen.