[MMUSIC] Comments on draft-even-mmusic-application-token-02

[Paul Kyzivat <[e-mail]>]

This is much improved from prior versions I reviewed!!!

General comments:

I think this would be easier to read if in examples mnemonic values were 
used for appID tokes, rather than numbers.

Now that recv-appId is being proposed, I think it would read better if 
there was symmetry in the names for the two directions. Also this mixing 
of hyphenated names with camelCase names is pretty ugly. So how about: 
app-id-send, app-id-recv?

Section 3.1:

    The definition is

    a=appId:token

    a=appId:token <attribute>

    a=appId:token <attribute>:<value>

    The formal representation of the appId token is:
       appId-attribute = "appId:" token *[WSP attribute]
       attribute =/ appId-attr
       ; The base definition of "attribute" is in [RFC4566].
       ; (It is the content of "a=" lines.)
       ; WSP and DIGIT defined in [RFC5234]
       ; token defined in [RFC4566]

The examples above are a bit misleading because the definition of 
'attribute' includes the value. Also the above defines appId-attribute 
but then uses appId-attr.

I think the following would be clearer:

    The definition is

    a=appId:token

    a=appId:token <att-field>

    a=appId:token <att-field>:<att-value>

    The formal representation of the appId token is:
       appId-attribute = "appId:" token *[WSP attribute]
       attribute =/ appId-attribute
       ; The base definition of "attribute" is in [RFC4566].
       ; (It is the content of "a=" lines.)
       ; WSP and DIGIT defined in [RFC5234]
       ; token defined in [RFC4566]
       ; att-field and att-value defined in [RFC4566]

Section 3.1.3:

The syntax here is messed up. I think you mean:

    The formal representation of recv-appId is:
       recv-appId-attribute = "recv-appId:" token
       attribute =/ appId-attr
       ; The base definition of "attribute" is in [RFC4566].
       ; (It is the content of "a=" lines.)
       ; token defined in [RFC4566]

Also, if there will be multiple appIds per m-line, with different roles, 
then won't the receiver care which role is assigned to each of the 
appIds it requests? How can that be specified? (Maybe the pt attribute 
specified later, but then this needs to be extended to allow that.)

Section 3.2:

    Editor note: Since the appId is unique in an SDP session the app-Id
    group can be used also at the session level - do we want it?

You say that an appID is unique to an SDP session. But must it not also 
be unique to an RTP session? If so, that seems like it could present 
problems - the two constraints might conflict for certain types of RTP 
middle boxes.

Section 3.3.1:

I'm confused. IIUC the appId attribute in an offer or answer defines the 
appIds that will be *sent* by the end sending that offer or answer. But 
the pt numbers in the corresponding m-line define the PTs that it will 
*receive*.

Section 4:

This is just an example of O/A. More is expected. Clear normative 
specifications, e.g.:

Generating the Initial Offer
Receiving the Initial Offer
Generating the Initial Answer
Receiving the Initial Answer
Subsequent Offer/Answer Exchanges:
   Generating the Offer
   Receiving the Offer
   Generating the Answer
   Receiving the Answer

Some things that need explanation:

If recv-appId is used in an offer, that can lead to an answer that uses 
the same values in an appId. But can recv-appId be used in an answer? If 
so, what does that mean? What about the *next* O/A? Should the 
recv-appId from the prior O/A be repeated in the new one?

For that matter, what is the meaning if the the token in an appId 
attribute changes from one O/A to the next?

	Thanks,
	Paul