Re: [MMUSIC] "New" style for defining SDP attributes

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 14 May 2018 17:34 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D804D127076 for <mmusic@ietfa.amsl.com>; Mon, 14 May 2018 10:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFGVWFVJf1cm for <mmusic@ietfa.amsl.com>; Mon, 14 May 2018 10:34:42 -0700 (PDT)
Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id ACF7D1241FC for <mmusic@ietf.org>; Mon, 14 May 2018 10:34:42 -0700 (PDT)
X-AuditID: 12074412-f8dff700000013fa-57-5af9c8b18e19
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id E1.9A.05114.1B8C9FA5; Mon, 14 May 2018 13:34:41 -0400 (EDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id w4EHYdEH001594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 May 2018 13:34:41 -0400
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <d39c9615-ad46-a840-fd02-9a3eac4b53a9@gmail.com> <D7161134.2F512%christer.holmberg@ericsson.com> <919f4302-29b2-3f48-ffef-aab290bb6e96@gmail.com> <7594FB04B1934943A5C02806D1A2204B72EB88D8@ESESSMB109.ericsson.se> <2950acc1-ab24-ebb4-cc50-1c64193fbe0d@gmail.com> <7594FB04B1934943A5C02806D1A2204B72EBD35F@ESESSMB109.ericsson.se> <d7ad13b7-5d18-8c7c-b93b-f3670cefa70e@gmail.com> <7594FB04B1934943A5C02806D1A2204B72EBE59B@ESESSMB109.ericsson.se> <5f01be58-d29d-b45f-87d5-879d171cf703@comcast.net> <7594FB04B1934943A5C02806D1A2204B72ECED9D@ESESSMB109.ericsson.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <e5dd87c6-2971-7db9-c02a-8548930ee495@alum.mit.edu>
Date: Mon, 14 May 2018 13:34:39 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72ECED9D@ESESSMB109.ericsson.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixO6iqLvpxM8og/mzmC0uzDzMaDF1+WMW ByaPX1+vsnksWfKTKYApissmJTUnsyy1SN8ugSvj7uK5rAVrpSomvrrK3MB4UKiLkZNDQsBE 4u62cyxdjFwcQgI7mCS2t31iA0kICTxkkri9kAPEFhawlbhw8C9TFyMHh4hAisSRLkaI+jMs EvuuH2EFqWET0JKYc+g/C4jNK2AvcejPQbA5LAKqEgfWnwKzRQXSJO5vnsQIUSMocXLmE7B6 TgE/iWcfFoDZzAJmEvM2P2SGsMUlbj2ZzwRhy0tsfzuHeQIj/ywk7bOQtMxC0jILScsCRpZV jHKJOaW5urmJmTnFqcm6xcmJeXmpRbpmermZJXqpKaWbGCGBKrSDcf1JuUOMAhyMSjy8CdN+ RgmxJpYVV+YeYpTkYFIS5c3pBQrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4d1tBJTjTUmsrEot yodJSXOwKInzMpvsjRISSE8sSc1OTS1ILYLJynBwKEnwzjwO1ChYlJqeWpGWmVOCkGbi4AQZ zgM0PB+khre4IDG3ODMdIn+KUZdjyvP+HmYhlrz8vFQpcd7lIEUCIEUZpXlwc2AJ5hWjONBb wrzTQap4gMkJbtIroCVMQEuKTn0HWVKSiJCSamBcltrN+79Ba9X2hC0aoYwFS/fPeXe86Idd sVM5n8AdJrPvx2VEig49uGXKLMfs8e3A7KI5K7o7D9VrH51x/+fC6y/nnrafwNYlcTFUMcfv cRNHknSg2YfNWu+nux9Sd920Q2WfpivzxRN6ddNaZn54EfnkHOOGdTFbZ3uffXIl4aHH9zRG OVFdJZbijERDLeai4kQA1JAwUwsDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/_CR-q1SNYBdnn2yxtMpII4s0M9U>
Subject: Re: [MMUSIC] "New" style for defining SDP attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2018 17:34:45 -0000

Christer,

Note that I changed the subject line here. My intent was to start a 
different discussion that isn't specifically related to trickle-ice-sip. 
The intent instead is to discuss if we should change 4566bis to be more 
explicit about how to define attributes.

	Thanks,
	Paul

On 5/13/18 4:47 AM, Christer Holmberg wrote:
> Hi,
> 
> My suggestion would be to simply reference the syntax. Something like:
> 
> trickle-ice-sdpfrag =   session-level-fields
>                                        pseudo-media-descriptions
> session-level-fields = bundle-group-attribute CRLF          \
>                                        ice-lite-attribute CRLF                      \
>                                        ice-pwd-attribute CRLF                     \
>                                        ice-ufrag-attribute CRLF                    \
>                                        ice-options-attribute CRLF                \
>                                        ice-pacing-attribute CRLF                  \
>                                        end-of-candidates-attribute CRLF   \
>                                        extension-attribute-fields
> 
> The attribute fields follow the generic syntax for SDP attributes [RFCXXXX]. The list below reference the specific syntax for each attribute field.
> 
> ice-lite-attribute              ; as ice-lite defined in [RFCXXXX]
> ice-pwd-attribute            ...
> ice-ufrag-attribute           ...
> ice-pacing-attribute         ...
> ice-options-attribute       ....
> 
> Then we don't need to worry about "new" and "old" in this draft. We simply define the high-level syntax for the sdpfrag message body, and reference the appropriate specifications for the attributes etc.
> 
> In addition, I think it would be useful to say that in order to use an extension attribute, there needs to be a specification for how that attribute is used within a sdpfrag message body. Otherwise someone could include any SDP attribute just like that.
> 
> Regards,
> 
> Christer
> 
> 
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: 12 May 2018 19:41
> To: mmusic@ietf.org
> Subject: [MMUSIC] "New" style for defining SDP attributes
> 
> On 5/10/18 12:59 PM, Christer Holmberg wrote:
> 
>> That's a bad example since a=bundle-only doesn't have a value.
>>
>> A better example is the tls-id attribute, defined in Section 4 of
>> https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-32.txt.
>>
>>
>> I'd rather prefer ( just personal preference ) the style of
>> https://tools.ietf.org/html/draft-ietf-mmusic-rid-14, where the
>> registration in section 11 refers to the grammar in section 10.
>>
>> The ABNF is not according to the new style.
>>
>> And, just to clarify, my comments are not based on my personal
>> preference, but on my understanding of how SDP attributes are to be
>> defined nowadays.
> 
> I've been finding that the "new" style that I have been trying to get institutionalized isn't well enough specified. I'm thinking that we need to firm it up, and preferably get that written down in 4566bis.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>