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

[Dirk Kutscher <[e-mail]>]

>>>>> "Graham" == Graham Klyne <[e-mail]> writes:

    Graham> I have just read through your above-mentioned draft with
    Graham> some interest, as it closely parallels work with which I
    Graham> have been involved.  For the most part, I shall not make
    Graham> detailed comments, but shall try to address some broader
    Graham> issues about what I see as the relationship between your
    Graham> draft and the IETF CONNEG work.

Graham,

Thank you for your comments on the draft and please excuse the rather
long delay in answering.

Most of your notes make a lot of sense to me. Here are some comments
from my side:

You correctly identified some deficits of the specification that need
to be worked on: The relation between the system model, the mentioned
requirements and the specified description language will be made
explicit.

You are right in emphasizing the similarities between the conneg work
and our draft.

    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.


    Graham> - 2.4.  Collapsing Algorithm

    Graham>    The objective of the collapsing algorithm is to take
    Graham>    capability description sets from each end system in
    Graham>    order to find a set of media-types, encodings and
    Graham>    features that are supported by all end system, or, if
    Graham>    this is not possible, to find a subset that would
    Graham>    exclude as few systems as possible.

    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.


    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.

    Graham> - 3.  Specification of the Decription Language

    Graham> As far as I can tell, your description language is
    Graham> semantically a subset of that described in RFC 2533; your
    Graham> "Basic description language" being equivalent to
    Graham> Disjunctive Normal Form of the CONNEG syntax, and your
    Graham> "Concise Description Language" being closer to the general
    Graham> CONNEG syntax form.

True, the idea was exactly to provide a subset of RFC 2533's
functionality for expressing feature sets, while allowing for
"non-collapsing parameters" and the definition of "simultaneous
capabilities".

The proposal we made in the draft actually tries to accomplish a set
of different objectives:

1) provide an abstract model of capability negotiation and session
   descriptions for multiparty conferences that can be used
   to gather some requirements for a capability description framework.
2) define a syntax and a framwork for capability definitions;
3) define a syntax for session descriptions and provide a migration
   path from currently deployed standards.

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.


    Graham> - 6.  Composed Configurations

    Graham> If I understand your intent correctly, I note that the
    Graham> CONNEG work includes a concept of auxiliary predicates
    Graham> that can be used to label configurations.

    Graham> We are also working on another proposal
    Graham> <draft-ietf-conneg-feature-hash-xx.txt> for labelling of
    Graham> arbitrary feature sets using an MD5-hash-based identifier.


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.

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

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.

So, summarizing, we acknowledge the semantic simliarities between RFC
2533 and our proposal. It is certainly worthwhile to explore the
possibility to build on RFC 2533 for specifying a description and
negotiation framework for multiparty cooperation. Resting upon some of
conneg's work we decided not to do so for this first draft because it
was not completely understood how to implement all aspects of the
system model. The objective was to raise interest in mmusic group and
to initiate the discussion.

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.


-- 
	Dirk