Subject: [MMUSIC] The simulcast colon

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Oct 2015 13:05:48 -0700

Is annoying me.  Do we really need two separators (i.e., the colon and
the space)?

BTW,  the examples in the draft have c= and m= lines in the wrong
order, though I'm sure that I'm not the first to note this.

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 21 Oct 2015 21:53:31 -0700

+1 to removing the colon

https://en.wikiquote.org/wiki/Consistency

On Wed, Oct 21, 2015 at 1:05 PM, Martin Thomson <[email-masked]>
wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 22 Oct 2015 14:47:52 +0000

The colon was added after others pointed out that attributes with further parameters should have a colon after the attribute. I don't know how many parsers actually care about that rule, but it seems safer to stick with the convention even if it bothers a few human eyes.

Mo

On Oct 22, 2015, at 12:54 AM, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:

+1 to removing the colon

On Wed, Oct 21, 2015 at 1:05 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
Is annoying me.  Do we really need two separators (i.e., the colon and
the space)?

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bo Burman <[email-masked]>
Date: Sat, 24 Oct 2015 17:20:34 +0000

I note that 4566bis ABNF for "attribute" says:

   ; sub-rules of 'a='
   attribute =           (att-field ":" att-value) / att-field
   att-field =           token
   att-value =           byte-string

The colon does not seem to be a "should" to me, but rather a requirement for any SDP attribute that is not a boolean.
Is there really any slack in how this can be implemented by SDP parsers?

To comply with 4566bis ABNF and still keep a single separator, you should rather remove the space.

/Bo

From: mmusic [mailto:[email-masked]] On Behalf Of Mo Zanaty (mzanaty)
Sent: den 22 oktober 2015 15:48
To: Peter Thatcher
Cc: [email-masked]
Subject: Re: [MMUSIC] The simulcast colon

Mo

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Oct 2015 17:46:41 +0000

Hi,

A few comments on the ABNF:

Q1: The colon MUST be there. As Bo pointed out, it's part of the core syntax for attributes.

In order to now have both the colon and the space, the ABNF can be modified e.g. in the following way:

sc-attr     = "a=simulcast:" sc-str-list  [WSP sc-str-list] [WSP sc-pause-list]

Q2: I don't think SDP allows usage of whitespace (WSP).

RFC 4566 & draft-4566bis say:

              "Whitespace MUST NOT be used on either side of the "=" sign.

In addition, as far as I know, SDP is very strict with spaces, which is the reason they are explicitly stated in the SDP ABNF.

              "In general, <value> is either a number of fields delimited by a single
              space character or a free format string..."

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Bo Burman
Sent: 24 October 2015 20:21
To: Mo Zanaty (mzanaty) <[email-masked]>; Peter Thatcher <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] The simulcast colon

   ; sub-rules of 'a='

/Bo

From: mmusic [mailto:[email-masked]] On Behalf Of Mo Zanaty (mzanaty)
Sent: den 22 oktober 2015 15:48
To: Peter Thatcher
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] The simulcast colon

Mo

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 24 Oct 2015 19:19:40 -0400

Christer, Bo,

Haven't the two of you seen the conversation between me and Martin? That 
thread starts at:
https://mailarchive.ietf.org/arch/msg/mmusic/7bUkyhJAN2IRjm51DyvrPhS_yPI

That first message gives a list of issues that we have been trying to 
address. Here is a restatement of that list:

- the "colon issue"
- 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.
- the conventions for attribute syntax, introduced in rfc4566bis,
   call for only the syntax for the attribute *value* is given, not for
   the "a=" or the attribute name, or the ":".

We have been negotiating a new syntax proposal. We have been converging, 
but not completely converged.

There are a few esthetic loose ends in that proposed syntax. Based on 
that discussion, below is a new proposal for you. It doesn't have some 
of the extensibility of the syntax in -03 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 = simulcast-pt / simulcast-rid
       simulcast-pt = ( simulcast-pt-send [ SP simulcast-pt-recv ] )
                    / simulcast-pt-recv
       simulcast-rid = ( simulcast-rid-send [ SP simulcast-rid-recv ] )
                    / simulcast-rid-recv

       simulcast-pt-send = "send" SP simulcast-pt-args
       simulcast-pt-recv = "recv" SP simulcast-pt-args
       simulcast-pt-args = simulcast-pt-list *(";" simulcast-pt-list)
       simulcast-pt-list = payload-type *("," payload-type)

       simulcast-rid-send = "send" SP simulcast-rid-args
       simulcast-rid-recv = "recv" SP simulcast-rid-args
       simulcast-rid-args = simulcast-rid-list *(";" simulcast-rid-list)
       simulcast-rid-list = simulcast-rid-id *("," simulcast-rid-id)
       simulcast-rid-id = [simulcast-rid-paused] rid-identifier
       simulcast-rid-paused = "~" ; OR (bikeshed color) "/" or "!"

       ; 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: recv pt=97
       a=simulcast: send rid=1,~2,3 recv rid=~A,B

On 10/24/15 1:46 PM, Christer Holmberg wrote:
> *Q1*: The colon MUST be there. As Bo pointed out, it’s part of the core
> syntax for attributes.
>
> *sc-attr     = "a=simulcast:" sc-str-list  [WSP sc-str-list] [WSP
> sc-pause-list]*
>
> *Q2*: I don’t think SDP allows usage of whitespace (WSP).
>
>                “Whitespace MUST NOT be used on either side of the "=" sign.
>
> In addition, as far as I know, SDP is very strict with spaces, which is
> the reason they are explicitly stated in the SDP ABNF.
>
>                “In general, <value> is either a number of fields
> delimited by a *single*
>
> *              space character*or a free format string…”
>
> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Bo Burman
> *Sent:* 24 October 2015 20:21
> *To:* Mo Zanaty (mzanaty) <[email-masked]>; Peter Thatcher
> <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [MMUSIC] The simulcast colon
>
> I note that 4566bis ABNF for “attribute” says:
>
>     ; sub-rules of 'a='
>
> The colon does not seem to be a “should” to me, but rather a requirement
> for any SDP attribute that is not a boolean.
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Mo Zanaty
> (mzanaty)
> *Sent:* den 22 oktober 2015 15:48
> *To:* Peter Thatcher
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [MMUSIC] The simulcast colon
>
> The colon was added after others pointed out that attributes with
> further parameters should have a colon after the attribute. I don't know
> how many parsers actually care about that rule, but it seems safer to
> stick with the convention even if it bothers a few human eyes.
>
> Mo
>
>
> On Wed, Oct 21, 2015 at 1:05 PM, Martin Thomson
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>