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

[Paul Kyzivat <[e-mail]>]

On 10/27/13 4:59 PM, Martin Thomson wrote:
> In addition to absent colons, the examples use a variety of uppercase
> and lowercase characters.  Consistency would be helpful, unless the
> intent is to highlight the fact that ABNF permits these to be in mixed
> case.  (RFC 4566 is silent on the subject, so I assume that a=appid is
> equivalent to a=ApPId, following RFC 5234; I'd rather that weren't the
> case, but that seems to be the intent at least).
>
> I'm not sure about the assertion regarding 1-1 correspondence between
> appid and SSRC.

Note that I said "at any point in time", and made provision for changing 
the mapping.

Even so, I am also not sure.

> Putting the fact that SSRC can change aside, I
> believe that the intent is to label the source, which can manifest as
> multiple SSRCs.

I *thought* that for instance in case of FEC, the original stream and 
the repair stream would have the same appid. But the example showed 
otherwise.

I'd like the model to be spelled out. Then we wouldn't be wondering.

	Thanks,
	Paul

> Editorial: This document needs a serious proofread.  The spelling
> seems right, but I'm continually being distracted by poor grammar as I
> read through.  Doublespacing all the examples is annoying too.
>
> On 27 October 2013 11:35, Paul Kyzivat <[e-mail]> wrote:
>> 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
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>