Re: [MMUSIC] The simulcast colon

Christer Holmberg <> Sat, 24 October 2015 17:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F32D31B3729 for <>; Sat, 24 Oct 2015 10:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5XZolIoCt8zn for <>; Sat, 24 Oct 2015 10:46:46 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 490251B3728 for <>; Sat, 24 Oct 2015 10:46:45 -0700 (PDT)
X-AuditID: c1b4fb25-f79a26d00000149a-57-562bc403caa1
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 6A.E2.05274.304CB265; Sat, 24 Oct 2015 19:46:43 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Sat, 24 Oct 2015 19:46:42 +0200
From: Christer Holmberg <>
To: Bo Burman <>, "Mo Zanaty (mzanaty)" <>, Peter Thatcher <>
Thread-Topic: [MMUSIC] The simulcast colon
Thread-Index: AQHRDDvlCP6hG7LO4UeeBW3L/Vbcz5520TOAgACmDwCAA09UAIAAJChA
Date: Sat, 24 Oct 2015 17:46:41 +0000
Message-ID: <>
References: <>, <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37B8CF97ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM+JvrS7zEe0wg+uNShZTlz9msXjxYA6T xbXlr1kdmD2m/N7I6rFgU6nHkiU/mQKYo7hsUlJzMstSi/TtErgyvvzez1hwYhJjRd+xHywN jLebGbsYOTkkBEwkrjZ9ZYKwxSQu3FvP1sXIxSEkcJRR4s71z4wQzmJGiZOX7wE5HBxsAhYS 3f+0QRpEBKokLjx/yAYSZhZQl7i6OAgkLCygKfF4xVoWiBItie8N9xkhbDeJrcsegsVZBFQl lrUtYAJp5RXwldi1LBli0wQmibNdE8Hu4RTwk9g96Rc7iM0IdNv3U2vA4swC4hK3nsyHullA Ysme88wQtqjEy8f/WCFsJYkV2y8xQtTnS8zZOgOsnldAUOLkzCcsExhFZyEZNQtJ2SwkZRBx HYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0Vo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmAM HtzyW3UH4+U3jocYBTgYlXh4H6zVChNiTSwrrsw9xCjBwawkwiuwVztMiDclsbIqtSg/vqg0 J7X4EKM0B4uSOG8z04NQIYH0xJLU7NTUgtQimCwTB6dUA2OcsuzMi3khh4sZ1QUOPExiPlm7 r6n8Q4SjdjrvVP1PGk1qnjnnIv96OrFbmNv77uZJCFBMm9a/8FBw6UObM6uOdh0/L5KxQPV/ 3ZLwm9wL3lbceKTA3Ja+5bXAL8k9n2aaHknxCEvrtbwwwXOLkrZqx1bJH+ubxJ655vBZTxO6 ERz489f+x0osxRmJhlrMRcWJABr7wMW9AgAA
Archived-At: <>
Cc: "" <>
Subject: Re: [MMUSIC] The simulcast colon
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 24 Oct 2015 17:46:49 -0000


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..."



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

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.


From: mmusic [] On Behalf Of Mo Zanaty (mzanaty)
Sent: den 22 oktober 2015 15:48
To: Peter Thatcher
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.


On Oct 22, 2015, at 12:54 AM, Peter Thatcher <<>> wrote:
+1 to removing the colon

On Wed, Oct 21, 2015 at 1:05 PM, Martin Thomson <<>> wrote:
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.

mmusic mailing list<>

mmusic mailing list<>