Re: [MMUSIC] Open Issues: draft-ietf-mmusic-sdp-simulcast-03 - ABNF

[Paul Kyzivat <[e-mail]>]

Martin pointed out a bug in the examples. Here is a correction:

6.1 Simulcast attribute

    Name: simulcast

    Value: simulcast-value

    Usage Level: media

    Charset Dependent: no

    Syntax:

       simulcast-value = sc-send-opt [SP sc-recv-opt]
                       / sc-recv-opt
       sc-send-opt = "send" SP sc-sendrecv-args
       sc-recv-opt = "recv" SP sc-sendrecv-args

       sc-sendrecv-args = sc-pt-args / sc-rid-args
       sc-pt-args = "pt=" sc-pt-list *(";" sc-pt-list)
       sc-rid-args = "rid=" sc-rid-list *(";" sc-rid-list)
                     [SP sc-pause-opt]

       sc-pt-list = payload-type *("," payload-type)
       sc-rid-list = rid-identifier *("," rid-identifier)
       sc-pause-opt = "paused=" sc-rid-list

       ; SP defined in [RFC5234]
       ; payload-type, defined in [draft-ietf-mmusic-rfc4566bis-15]
       ; rid-identifier defined in [I-D.pthatcher-mmusic-rid]

    Examples:

       a=simulcast:send pt=97;98 recv pt=97
       a=simulcast:send rid=1,2,3 recv rid=4 paused=3


On 10/23/15 12:49 PM, Paul Kyzivat wrote:
> On 10/22/15 4:52 PM, Adam Roach wrote:
>
>> BIKESHED TIME! I think Martin is correct that the "space-colon"
>> delimiter is unaesthetic; I'll go further and point out that it appears
>> to be unprecedented (I could be missing something), which will make it
>> unnecessary parsing exception as compared to other attributes. Mo's
>> point that we want a colon is well-taken, but that doesn't justify the
>> space. It seems that the current formulation was selected to make the
>> ABNF easy to write. To that end, I've put together a formulation for the
>> "just a colon" format.
>>
>> sc-attr     = "a=simulcast:" sc-str-list [WSP sc-str-list] [WSP
>> sc-pause-list]
>>
>>
>> Is there any reason we can't make the format consistent with all the
>> other "a=foo:bar" syntaxes out there, as described by this rule?
>
> Yes please. And please follow the format for attribute definition
> established in rfc4566bis.
>
> Also, I have some other issues:
> - syntax allows two sends, or two recvs, but those are semantically
> forbidden
> - the syntax allows paused with PTs, but that is semantically forbidden.
> - syntax allows pt values that aren't numeric
> - use of WSP (SP or HTAB). Contrary to typical SDP usage.
>
> Below is a proposal for revised syntax that follows the spirit, but
> aligns better with other attributes and 4566bis. It doesn't have some of
> the extensibility of the prior syntax because I couldn't see how to do
> it in a meaningful way. I don't think it is a great loss here.
>
> This may perhaps need further tweaking based on the ongoing discussion
> of pt vs rid.
>
> The following would replace the beginning of section 6.1, or maybe be a
> new section/subsection. It also ought to be cross referenced from IANA
> considerations as a request to add it to the iana sdp attribute registry.
>
>      Thanks,
>      Paul
>
> 6.1 Simulcast attribute
>
>     Name: simulcast
>
>     Value: simulcast-value
>
>     Usage Level: media
>
>     Charset Dependent: no
>
>     Syntax:
>
>        simulcast-value = sc-send-opt [SP sc-recv-opt]
>                        / sc-recv-opt
>        sc-send-opt = "send" SP sc-sendrecv-args
>        sc-recv-opt = "recv" SP sc-sendrecv-args
>
>        sc-sendrecv-args = sc-pt-args / sc-rid-args
>        sc-pt-args = "pt=" sc-pt-list *(";" sc-pt-list)
>        sc-rid-args = "rid=" sc-rid-list *(";" sc-rid-list)
>                      [SP sc-pause-opt]
>
>        sc-pt-list = payload-type *("," payload-type)
>        sc-rid-list = rid-identifier *("," rid-identifier)
>        sc-pause-opt = "paused=" sc-rid-list
>
>        ; SP defined in [RFC5234]
>        ; payload-type, defined in [draft-ietf-mmusic-rfc4566bis-15]
>        ; rid-identifier defined in [I-D.pthatcher-mmusic-rid]
>
>     Examples:
>
>        a=simulcast: send pt=97;98 recv pt=97
>        a=simulcast: send rid=1,2,3 recv rid=4 paused=3
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>