Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07

Bo,

On 3/13/17 10:48 AM, Bo Burman wrote:
> Paul, thanks for good comments,
>
> Please see my responses inline.
>
> /Bo
> (as individual)
>
>> -----Original Message-----
>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: den 3 mars 2017 20:08
>> To: mmusic@ietf.org
>> Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07
>>
>> Dale,
>>
>> On 3/3/17 10:56 AM, Dale R. Worley wrote:
>>> Iñaki Baz Castillo <ibc@aliax.net> writes:
>>>>> but according to
>>>>> https://tools.ietf.org/html/draft-ietf-mmusic-rid-09
>>>>> it seems that "direction" (send/recv) should be placed *before*
>>>>> "pt=xx":
>>>>>
>>>>> a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>...
>>>>
>>>> In fact, pt=xx seems to be yet another "param".
>>>
>>> That purported BNF is really bizarre, since it generates the clearly
>>> incorrect form:
>>
>> IIUC you are commenting on the ABNF in draft-ietf-mmusic-rid-08, not in draft-ietf-mmusic-sdp-simulcast-07, right?
>>
>>>    a=rid:<rid-id> <direction>
>>> <restriction>=<value><restriction>=<value>
>>
>> I'm not seeing how the ABNF generates that.
>>
>>> A correct description is:
>>>
>>>    a=rid:<rid-id> <direction> ( pt=<fmt-list> | <restriction>=<value>
>>> ) *( ; <restriction>=<value> )
>>
>> ISTM the ABNF in the draft is equivalent to what you have written.
>> (Though yours is clearer.)
>>
>> Meanwhile, the ABNF of draft-ietf-mmusic-sdp-simulcast-07 does some small problems:
>>
>> 1) it allows either one or two 'sc-str-list's. I presume this is so you can have both send and recv lists, but it also allows two
>> send lists or two recv lists.
> [BoB] That is to allow for having both send and receive directions on the same line, because use of multiple lines are not defined (section 6.2 says "The meaning of including multiple "a=simulcast" lines in a single SDP media description is undefined, MUST NOT be used by implementations of this specification and any additional 'a=simulcast' lines beyond the first in a media description MUST be ignored if received"). The current ABNF thus allows listing the same direction twice, but this is explicitly disallowed by text in section 6.2 ("each direction MUST NOT occur more than once on the same line").
>
>>
>> 2) it references rid-identifier from draft-ietf-mmusic-rid-08, but that isn't defined there. I guess it means to reference rid-
>> id.
> [BoB] Yes, this should be aligned; to be included in -08.
>
>>
>> 3) this syntax defines the syntax of the entire attribute, including "a=" and the separation between attribute name and
>> value. We are trying to get away from that as part of the cleanup in rfc4566bis. (Because people keep getting it wrong, so
>> that it doesn't match with the generic syntax of an attribute.)
>>
>> I suggest a better syntax for this would be:
>>
>>     sc-value     = sc-send [SP sc-recv] / sc-recv [SP sc-send]
> [BoB] OK, that works and is a more clear description of what was already intended. I can make that change in -08.
>
>>     sc-send      = "send" sc-str-list
>>     sc-recv      = "recv" sc-str-list
>>     sc-str-list  = SP sc-alt-list *( ";" sc-alt-list )
> [BoB] Is there any specific reason you include SP as first part of sc-str-list? I would think it clearer to have SP as separator in sc-send and sc-recv definitions.

Either way works. This way it is only specified once. Its really a 
matter of taste.

	Thanks,
	Paul

>>     sc-alt-list  = sc-id *( "," sc-id )
>>     sc-id-paused = "~"
>>     sc-id        = [sc-id-paused] rid-id
>>     ; SP defined in [RFC5234]
>>     ; rid-id defined in [I-D.ietf-mmusic-rid]
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic