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

From: [email-masked] (Koen Holtman)
Date: Wed, 21 Oct 1998 21:22:07 +0200 (MET DST)

Graham,

I have finally had the time to read
draft-ietf-conneg-feature-syntax-00.txt.  Here are some comments.

I find the draft quite readable overall, but I am probably not an
average reader in this respect, as I have an extensive background in
this kind of logic (my CS department is very big on this kind of stuff
even for a European CS department).  Maybe the average
reader/implementer will find it quite frightening, especially if a
treatment of q factors (or another way to choose in ambiguous
situations) is also added.  I think that having a generic symmetric
framework with q factors is quite valuable in itself, but there is a
definite risk that such a framework will be too complex to get
deployed.  I would like to hear opinions of other readers on this
issue.

From a high level point of view I would like to see a framework that
is powerful enough to make TCN feature negotiation a special case.  On
a mathematical level this would mean changing from boolean logic to
fuzzy set logic.  You would go from set-intersection between two sets
of feature collections to fuzzy-set-intersection between two fuzzy
sets of feature collections.  It should be doable on theoretical
grounds but I have no real idea about the complexity of the resulting
notational system.  And of course the is the point of choosing a
particular fuzzy-set-intersection operator.  (Note that TCN feature
negotiation can be thought of as computing a set intersection between
a fuzzy and a crisp set of feature collections.)

Some specifics:

Section 2.  It would be good to mention in a note that TCN uses the
term 'feature set' in a different way.  In TCN a feature set is
mathematically somewhere between a feature collection and a feature
set in your terminology.

4.2.1: For brevity you could drop the discussion of named predicates,
or move it to an appendix.

5.1: As noted before, though you define a syntax for q values, you do
not define a semantics.

5.1: You talk about propositional calculus vs. predicate calculus in
the note.   I do not know exactly which calculus you mean with
propositional calculus.  Could you give a reference?

5.1.1: item 5.1: 'just one feature value' should be 'just one feature
tag'.

5.1.4: this canonicalisation step is done too early to be of any real
benefit, especially because:

5.1.5: you forgot the rules for handling negation ( !filter ).

5.1.7: I would omit 5.1.4 and invent new rules here starting from the
=, !=, <= and >= operators.  I think the result would be shorter. 

Koen.

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Fri, 23 Oct 1998 10:17:26 -0700

Please see below.

Lloyd

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Wednesday, October 21, 1998 12:22 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Comments on draft-ietf-conneg-feature-syntax-00.txt
> 
> 
> Graham,
> 
	[McIntyre, Lloyd]  I share this concern with regard to
complexity. A number of fax manufacturers have expressed concern for
understanding and interpreting the syntax draft. I fear that they will
not implement it. Please see if may be possible to extract a minimum set
that would target the IFax applications. This minimum set may be
expanded over time as comfort level rises.

> a fuzzy and a crisp set of feature collections.)
	[McIntyre, Lloyd]  This sounds appealing.

---

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

At 20:36 28/10/98 +0100, Koen Holtman wrote:
>Graham Klyne:
[...]
>>I'm not certain what you mean by 'fuzzy set logic'.

[your explanation]

OK, thanks for that.

[...]
>Of course, computing normal forms etc. for such beasts is more
>complicated than in the boolean case, and I think we should stay away
>from that at least for the time being.

I agree!

>...  Documenting the basic
>principles of fuzzy negotiation as I did above may be a nice addition
>to the syntax draft though, because this allows one to describe how
>various systems are limiting cases.

I could use your explanation as a basis of an appendix to the syntax document.

[...]
>>I'll add a citation.
>>By "propositional calculus", I mean Boolean expressions that combine
>>independent atomic propositions:
>>
>>   e.g.  (A&B)|(C&D)
>>
>>By "predicate calculus", I mean Boolean expresions that combine predicates
>>that may refer to other (typically non-Boolean) variables:
>>
>>   e.g.  (A(x)&B(y))|(C(x)|D(y))
>
>Hmm, with these definitions of predicate and propositional calculus,
>if you consider things like 'pix-x=500' to be one atomic proposition,
>then propositional calcululus would be powerful enough to handle your
>case.

Propositional calculus cannot capture the dependencies between different
atomic propositions.  For example, if one says:

   (& ... (pix-x=500) ... (pix-x=400) ... )

then using propositional calculus as you suggest these simply remain as
distinct propositions.  Predicate calculus allows the application of
additional rules (by noting that the two "propositions" are statements
about the same "variable") to recognize that the whole predicate in this
case is always FALSE.

That's my interpretation.

My citation for this is "Logic and its Applications" by Edmund Burke and
Eric Foxley, part of the Prentice Hall International Series in Computer
Science, ISBN 0-13-030263-5.  (Actually, the terms they use are
Propositional Logic and Predicate Logic, but I think the terms -calculus
also apply.)

#g

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