Re: draft-ott-mmusic-cap-00.txt

[Graham Klyne <[e-mail]>]

Dirk,

Thank you for your comments and explanations.  I think I see scope for
constructive cooperation in this area.  I have some additional comments below.

At 18:15 18/08/99 +0200, Dirk Kutscher wrote:
>    Graham> - In section 1.3 where you discuss relationship to other
>    Graham> developments, while what you say about the CONNEG work
>    Graham> seems generally reasonable, you do not explain what is
>    Graham> accomplished by your proposal that is not accomplished by
>    Graham> the CONNEG work.
>
>The last paragraph in that section states that we aim for a simpler
>solution, so simplicity and probability of being implemented are the
>main characteristics that we thought that our approach can accomplish
>in a better way. We have therefore deliberately chosen the primitive
>"basic description language" as a representation.

Fair enough.  But I would suggest that a similar effect could be obtained
by defining a restructed subset of the CONNEG syntax corresponding to
Disjunctive Normal Form (i.e. a 2-level structure with conjunctions (&)
within a single disjunction (|)) -- indeed RFC 2533 contains just such a
description in section 5, top of page 17.  This has the advantage of being
fully compatible with the more general form.

More generally, I do believe there is useful work to be done in defining a
restricted form and simplified processing rules for simplified deployments.
 (I think the main gains here would be run-time memory requirements rarher
than code complexity.)

FWIW, on the topic of "being implemented", there is a publicly usable Java
source implementation of a CONNEG parser and feature set matching available
at <http://www.imc.org/medfree>.

>    Graham> How does your algorithm act to find a subset to "exclude
>    Graham> as few systems as possible"?
>
>Yes, this is still to be defined.

Maybe there is scope here for some collaborative work?

>    Graham> I also note that your collapsing algorithm does not handle
>    Graham> cases where different constraints are applied to some
>    Graham> given feature (e.g. one party might specify "fps<=30" and
>    Graham> another might specify "fps=15" for a video frame rate).
>
>Right, it would be required to use "fps" consistently either with a
>less-or-equal-than-comparable or a selection-of-fixed-values type.
>For simplification we decided not to allow symbolic values to be
>less-or-equal-than-comparable.

OK.  CONNEG makes the same simplifying assumption for symbolic values.

I note that the CONNEG work (and the implementation mentioned above) allow
for mixing of equality and inequality relations applied to numeric values.

>While the draft proposes to consider a successor of the Session
>Description Protocol (SDP) it is unclear at this time if the mmusic
>working group is going to adopt this (or the topic of multiparty
>capability negotiation in general) as a work item.
>
>Providing session description functionality does not only involve
>feature set definitions and feature match algorithms as currently
>defined in RFC 2533 but also additional facilities to allow for
>unnegotiable parameters of session descriptions.
>
>As you noted, the draft specification does currently no meet all of
>the mentioned demands itself, because some things are in a rather
>premature state, requiring further discussion in the mmusic group.

There are certainly some areas where RFC 2533 does not address all
conceivable requirements (e.g. see <draft-ietf-conneg-W3C-ccpp-01.txt>,
which is a response to some similar issues being considered by W3C).  The
CONNEG framework was designed (among other things) to provide a solid
foundation for exploring some of these extension areas.

There are a number of areas where it would seem to make some sense to
cooperate in building a common semantic framework to address some of these
issues.  (I am less concerned about syntax issues.)

>Right, auxiliary predicates can be used to factor out filter
>expression. As I understand RFC2533 and
>draft-ietf-conneg-feature-hash-02, the main objective is to allow for
>more convenient notations and to enable the use of references to
>external feature set expressions. Since auxiliary predicates are
>expanded before the conversion to DNF for the feature matching
>process, any reference to the named predicate is lost.

Not necessarily.  The regular structure of the CONNEG framework means that
valid and correct expressions are still obtained if auxiliary predicates
are not expanded, and remain in the DNF -- it is possible that some
mismatches are not detected, but the expressions thus obtained would not be
in error.

>When expressing capabilities for redundant encodings (which we deemed
>to be one application of composed configurations) this is
>problematic. (One should note that, at this time, our proposal does not
>contain a solution either).

Due to non-detection of mis-matches noted above, the CONNEG framework is
also not a complete solution.  But I do think it provides a sound basis for
development of possible solutions.  For example:
  - reduce to DNF form without predicate expansion
  - for each conjuunction, expand predicates and re-reduce:
    -- if the result is FALSE, eliminate the conjunction
    -- otherwise, retain the conjunction as satisfiable
(This is just an example of what MIGHT be done, not a proposed final
solution.  Any final solution must be judged in light of clear goals or
requirements.)

>Also, I have a problem with what we call "non-collapsing
>parameters". I note that RFC 2533 has the concept of "parameters" that
>can be attached to any filter value in a predicate. However, I don't
>see how these parameters, including q-values for user preferences, are
>handled in a feature match process.

Currently, they are not.  CONNEG decided that was out of scope for the
initial specification, but the dor was left open for future developments in
this area.

>We would be happy to discuss the open issues within the conneg and/or
>mmusic group as soon as a requirement and working group agenda has
>taken place in mmusic concerning this topic.

That sounds reasonable to me.

#g

------------
Graham Klyne
([e-mail])