Subject: [MMUSIC] New Draft: SDP Grouping Identifiers

From: Adam Roach <[email-masked]>
Date: Tue, 03 Dec 2013 08:11:59 -0600

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.

Thanks!

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Dec 2013 12:19:27 -0500

> 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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Dec 2013 09:35:42 -0800

> Is there any great need to preserve backward compatibility here?

That's the key question I guess.  The question is whether an offer to
an unknown entity is required to include grouping semantics that a
legacy implementation depends on.  In that sense, having two parallel
grouping mechanisms in an offer is desirable, I think.

In that context, the group-id thing enables an equivalency test.  It's
really quite optional, and given that we are requiring complete
redundancy of the grouping statements, it can be ignored too.

>From my perspective, and I can't speak for Adam here, this group-id
correlation thingy is the only piece of this puzzle that I'm not that
attached to.  We could just have a completely parallel grouping
semantic.  The cost there is that any attempt to maintain and use the
5888 groupings would be impossible once you move to partial offers and
answers.

(I'd rather keep the semantic on in-group, so that group-id remains
optional in this regard.)

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Dec 2013 18:47:26 +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 [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Tuesday, 03 December 2013 7:19 PM
To: [email-masked]
Subject: Re: [MMUSIC] New Draft: SDP Grouping Identifiers

        Thanks,
        Paul

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 03 Dec 2013 17:02:28 -0600

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

That would be folly, as we already (even in the base spec) have the idea 
of order significance; e.g.:

          Multiple sdplang
          attributes can be provided either at session or media level if
          multiple languages in the session description or media use
          multiple languages, in which case the order of the attributes
          indicates the order of importance of the various languages in
          the session or media from most important to least important.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 03 Dec 2013 17:05:13 -0600

On 12/3/13 11:19, Paul Kyzivat wrote:
> 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 

The idea behind the syntax here is that you can implicitly define a new 
group in a partial offer without having to include any session-level 
attributes. I'll admit that there are other ways to address this 
capability, but this is the one I prefer.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 03 Dec 2013 17:06:35 -0600

> 5888 groupings would be impossible once you move to partial offers and

Yeah, that would make me sad. I don't want to develop a parallel 
grouping semantic to compete with 5888 -- just some mechanism to fix a 
relatively minor (but important) shortcoming.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Dec 2013 12:11:41 +0000

Hi,

Just because we have done something wrong in the past, we don’t have to do it again :)

Also, I don’t think re-ordering of sdplang attributes would cause a technical error.

Regards,

Christer

From: Adam Roach [mailto:[email-masked]]
Sent: 4. joulukuuta 2013 1:02
To: Christer Holmberg; Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] New Draft: SDP Grouping Identifiers

That would be folly, as we already (even in the base spec) have the idea of order significance; e.g.:

         Multiple sdplang

/a