Re: [MMUSIC] New Draft: SDP Grouping Identifiers

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 03 December 2013 18:47 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390E21AE018 for <mmusic@ietfa.amsl.com>; Tue, 3 Dec 2013 10:47:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level:
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 yKRSRg4nSuCu for <mmusic@ietfa.amsl.com>; Tue, 3 Dec 2013 10:47:31 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6521AE0C5 for <mmusic@ietf.org>; Tue, 3 Dec 2013 10:47:30 -0800 (PST)
X-AuditID: c1b4fb32-b7f388e0000057e0-69-529e273f8b2e
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id AB.6D.22496.F372E925; Tue, 3 Dec 2013 19:47:27 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 19:47:27 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] New Draft: SDP Grouping Identifiers
Thread-Index: AQHO8DGoMkkD/YYgU0+O4sL8daxpcZpCpnyAgAAogjM=
Date: Tue, 03 Dec 2013 18:47:26 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C569222@ESESSMB209.ericsson.se>
References: <529DE6AF.1060300@nostrum.com>,<529E129F.2080304@alum.mit.edu>
In-Reply-To: <529E129F.2080304@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.147]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvra69+rwgg+2dZhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVx/PtSpoItwhV3O3ewNDA+4O9i5OSQEDCR 2PSznxnCFpO4cG89WxcjF4eQwAlGiQvPl0M5ixgl5i95yt7FyMHBJmAh0f1PG6RBRMBX4tnj 22wgYWEBS4l9t+UhwlYSiz/OZISxbx7sBrNZBFQkmradYgGxeYFap279xARiCwl4SRw6eJUN xOYU0JHY0PkJ7B5GoHu+n1oDVsMsIC5x68l8Jog7BSSW7DkPdbOoxMvH/1hBTpAQUJKYtjUN olxHYsHuT2wQtrbEsoWvmSHWCkqcnPmEZQKj6CwkU2chaZmFpGUWkpYFjCyrGCWLU4uLc9ON DPRy03NL9FKLMpOLi/Pz9IpTNzECY+Xglt9GOxhP7rE/xCjNwaIkznudtSZISCA9sSQ1OzW1 ILUovqg0J7X4ECMTB6dUA6PwqS1PHgr6FzQlnz97+osNU8bbqc6BDG//nJzcljf36ZVXGXES FxX2rbZZcfln6DcfVYbLb5efrtvlNvO/UXhnscGh4t26zzR2xl1Kn9ytr1N1YsvPK0GL5P9M ypPIzH1Qty5ZZ6GbxDr9RSyvpdlrq8oCFS0mXKr2Mvdbz1rI+MWT+fgnfSMlluKMREMt5qLi RAAsrvICYwIAAA==
Subject: Re: [MMUSIC] New Draft: SDP Grouping Identifiers
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 03 Dec 2013 18:47:33 -0000

Hi,

I share Paul's concern regarding mandating a specific order.

There are parsers that do not necessarily keep the order when parsing an SDP body, why e.g. something that "enter" a SIP proxy is not necessarily what "comes out".

Regards,

Christer
________________________________________
From: mmusic [mmusic-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzivat@alum.mit.edu]
Sent: Tuesday, 03 December 2013 7:19 PM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] New Draft: SDP Grouping Identifiers

On 12/3/13 9:11 AM, Adam Roach wrote:
> Based on the conversations we had during the partial offer/partial
> answer draft discussion in Vancouver, Martin and I put together a
> separate document that formally defines a group identifier for RFC 5888
> SDP groups:
>
> http://tools.ietf.org/html/draft-roach-mmusic-groupid-00
>
> We've made this a separate document because the utility of identifying
> groups extends beyond its (upcoming) use in the partial offer/partial
> answer draft.
>
> The document is mercifully short. Feedback is solicited.

This is yet another example of the contortions that we are now going
through because of the inadequacy of SDP syntax. :-(

I find the approach troubling because of strict ordering requirement on
attributes. AFAIK this is the first time time I have seen any ordering
requirements on attributes other than the session level/media level
distinction.

Clearly there is a need to bind a group-id to a particular group line,
so there must be some ordering requirement. I see no reason that the two
lines must be adjacent, but once the need for some attribute ordering
has been accepted I guess there is no reason not to accept this stronger
requirement.

Since group-ids are required to be unique within the session, why is it
necessary to include the group semantic in the in-group attribute. IOW,
why not:
   a=in-group abc
rather than
   a=in-group LS:abc


It would be "cleaner" (to the extent that anything is clean in SDP) to
just define a new alternative grouping syntax that isn't backward
compatible. It could be as simple as using an a=in-group attribute (this
time including the semantic tag) as the only definer of groups.
Is there any great need to preserve backward compatibility here?

        Thanks,
        Paul


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic