draft-ott-mmusic-cap-00.txt

[Graham Klyne <[e-mail]>]

[Please include my address <[e-mail]> 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
([e-mail])