[MMUSIC] comments on draft-even-mmusic-application-token-01

[Paul Kyzivat <[e-mail]>]

Hi. Doing my pre-meeting reading. A few comments on this. Otherwise it 
looks good to me.

Many examples use a=appid and a=recv-appid without the colon.

Section 3.1.3:

       appid-attribute = "recv-appID:" token

       ; The base definition of "attribute" is in [RFC4566].

       ; (It is the content of "a=" lines.)

The comments are spurious here - there is no attribute.

ISTM it would be helpful to have an explicit specification of how this 
relates to RTP. IIUC, its something like the following:

- an RTP session MAY have one or more appid tokens
- at any point in time each appid token maps to at most
   one stream (SSRC) within the session.
- *new* appid:ssrc mappings MAY be initialized via SDP
- new appid:ssrc mappings MAY be initialized via receipt
   of the new RTPC SDES message or header extension
- existing appid:ssrc mappings MAY be updated via
   receipt of the new RTCP SDES message or header extension.

I'm not sure about what is supposed to happen if a new O/A defines a 
mapping in conflict with an existing one. I *think* it probably is to be 
ignored.

	Thanks,
	Paul