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

From: Graham Klyne <[email-masked]>
Date: Mon, 26 Jul 1999 14:32:28 +0100

[Please include my address <[email-masked]> in any response to this]

I have read through the draft <draft-ott-mmusic-cap-00.txt> with some
interest, as it closely parallels work with which I have been involved.
For the most part, I shall not make detailed comments, but shall try to
address some broader issues about what I see as the relationship between
this draft and the IETF CONNEG work.

- In section 1.3 comments about the CONNEG work seem generally reasonable,
but do not explain what is accomplished by this proposal that is not
accomplished by the CONNEG work.

   The IETF Content Negotiation (conneg) working group is developing a
   collection of media features for display, print and fax [6], a
   registration procedure for feature tags (the names of capability
   properties) [7] as well as description and negotiation models [8] [9]
   for media features and capabilities. One of conneg's goals is to
   develop a ``tag independent negotiation'' process that can work
   without knowing the meaning of feature tags.

I note that references [8] and [9] refer to different versions of
essentially the same document, now published as RFC 2533.

For "tag independent negotiation" I think it would be more accurate to say
"tag independent feature matching".  The CONNEG work does not address
mechanisms for actually exchanging capabilities.

If I understand correctly the description of the T.124 capability
expression,  it turns out that the form provided is a special case of that
supported by the CONNEG syntax (and is effectively a Disjunctive Normal
Form which results from the feature set matching process described in RFC
2533).

- Section 2

Discusses the concept of "components", but it is not clear to me how these
are related to the "description language".

I did not see anything in this draft to address the following goals,
especially with respect to user preferences:

   The collapsing process may be influenced by additional constraints
   that may be expressed on the possible combinations of alternatives --
   between multiple instances of the same component as well as across
   (instances of) different components.  Also, user preferences may be
   taken into account -- during the collapsing process as well as when
   deciding on which potential configuration is to be instantiated as
   the actual configuration for a component.

- 2.4.  Collapsing Algorithm

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

How does the algorithm act to find a subset to "exclude as few systems as
possible"?

I note that, apart from the final clause, this description could apply to
the feature matching algorithm in RFC 2533.  In this respect the goals are
the same (and, as far as I can tell, the algorithms used are not very
different).

I also note that the collapsing algorithm does not handle cases where
different constraints are applied to some given feature (e.g. one party
might specify "fps<=30" and another might specify "fps=15" for a video
frame rate).

- 3.  Specification of the Decription Language

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

To illustrate this point, I express the example from section 3.2.1 in the
CONNEG notation:

The example:

           media: audio {
                   mode = receive | send;
                   channels = 1;
                   encoding: g711 {
                           compression: mulaw {
                                   sampling_rate = 8000 | 11025 | 16000;
                           } || compression: alaw {
                                   sampling_rate = 8000 | 11025 | 32000;
                           };
                   } || encoding: gsm {
                           compression = half | full | enhanced_full;
                   };
           };

(BTW, as far as I can tell, the ABNF in <draft-ott-mmusic-cap-00.txt>
allows only one level of grouped constraint, but this example uses two.)

RFC 2533 equivalent (assuming appropriate feature teg registrations):

           (& (media=audio)
              (mode=[receive,send])
              (channels=1)
              (| (& (encoding=G711)
                    (| (& (compression=mulaw)
                          (sampling-rate=[8000,11025,16000]) )
                       (& (compression=alaw)
                          (sampling-rate=[8000,11025,32000]) ) ) )
                 (& (encoding=gsm)
                    (compression=[half,full,enhanced-full]) ) ) )

- 6.  Composed Configurations

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

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

- XML form of capability expression

I have had some correspondence with a CC/PP participant who has defined an
XML/RDF representation for CONNEG feature expressions.  I would expect this
work to be formalized as a result of ongoing liaison between the CONNEG and
CC/PP groups.

- Mapping from/to SDP
- Integration into SDP

I believe this work would be equally applicable to the CONNEG syntax and
framework.

#g

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

---

From: Dirk Kutscher <[email-masked]>
Date: 18 Aug 1999 18:15:26 +0200

>>>>> "Graham" == Graham Klyne <[email-masked]> 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