Subject: [MMUSIC] Bundle rejection oddities

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Mar 2016 16:51:50 -0800

Hi folks,

I've been working through the bundle draft and I've come across a sort
of surprising consequence that I wanted to share with the group. Sorry
for the extended example, but I think it's hard to get without that.

Consider the case where an offerer has three m= lines, alpha, bravo,
and charlie. This creates an initial offer that's (schematically) like
this:

   a=group:BUNDLE alpha bravo charlie
   m=audio 1111
   a=mid:alpha
   a=candidate

   m=video 2222
   a=mid:bravo
   a=candidate

   m=video 3333
   a=mid:charlie
   a=candidate

Per 8.2, and because this isn't bundle-only, each m= line has a unique
address and a set of candidates (I'm ignoring the ufrag and ice-pwd
for now).

Assume that the answerer rejects the first m= line, so per 8.3, it
pulls alpha out of the bundle group and sets is port number to 0.  Per
11.2, it only associates candidates with the answerer bundle tag,
which is bravo:

   a=group:BUNDLE bravo charlie
   m=audio 0
   a=mid:alpha

   m=video 4444
   a=mid:bravo
   a=candidate

   m=video 4444
   a=mid:charlie

So far so good. Now consider what happens if the offerer does an
ICE restart and (for instance) changes some property about the
second m= line. Per S 11.1 bullet 1, it only uses a shared address
for the second two m= lines and only attaches a candidate to the
second one (bravo). I.e.,

   a=group:BUNDLE bravo charlie
   m=audio 0
   a=mid:alpha

   m=video 5555
   a=mid:bravo
   a=candidate

   m=video 5555
   a=mid:charlie

If the answerer decides to reject bravo (leaving only charlie),
it now sets its port to 0 and pulls it out of the bundle group,
giving us:

   a=group:BUNDLE charlie
   m=audio 0
   a=mid:alpha

   m=video 0
   a=mid:bravo

   m=video 4444
   a=mid:charlie
   a=candidate     <-- See here

Note that the candidate here is on the third m= line but it needs to
be paired with the candidates on the second (rejected) m= line from
the offerer. I'm not saying that this is fatal: the logical
interpretation is that the candidates (and other ICE parameters) are
associated with the whole bundle group (and implicitly duplicated) and
just appear with one m= line. However, it is a bit odd and probably
should be called out in the spec lest people get confused.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Mar 2016 03:53:05 +0000

Hi Ekr,

I think I presented exactly the same use-case when it was first suggested to not associate shared candidates with each bundled m- line.

I'll look if I can add some additional text somewhere, to point out that the candidates can be associated with different m- lines in offers and answers, e.g. due to the use-case you described.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Eric Rescorla<mailto:[email-masked]>
Sent: ‎04/‎03/‎2016 02:53
To: mmusic WG<mailto:[email-masked]>
Subject: [MMUSIC] Bundle rejection oddities

Hi folks,

   m=video 2222
   a=mid:bravo
   a=candidate

   m=video 3333
   a=mid:charlie
   a=candidate

   m=video 4444
   a=mid:bravo
   a=candidate

   m=video 4444
   a=mid:charlie

   m=video 5555
   a=mid:bravo
   a=candidate

   m=video 5555
   a=mid:charlie

   a=group:BUNDLE charlie
   m=audio 0
   a=mid:alpha

   m=video 0
   a=mid:bravo

   m=video 4444
   a=mid:charlie
   a=candidate     <-- See here

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Mar 2016 07:32:04 +0000

What about adding the following note to section 11.1:

   “NOTE: The ICE-related media-level SDP attributes might end up being associated with
   with an "m=" line in the answer that does not correspond to the "m=" line
   to which the ICE-related SDP attributes were associated in the associated offer.”

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 4. maaliskuuta 2016 5:53
To: Eric Rescorla; mmusic WG
Subject: Re: [MMUSIC] Bundle rejection oddities

Hi Ekr,

Regards,

Christer

   m=video 2222
   a=mid:bravo
   a=candidate

   m=video 3333
   a=mid:charlie
   a=candidate

   m=video 4444
   a=mid:bravo
   a=candidate

   m=video 4444
   a=mid:charlie

   m=video 5555
   a=mid:bravo
   a=candidate

   m=video 5555
   a=mid:charlie

   a=group:BUNDLE charlie
   m=audio 0
   a=mid:alpha

   m=video 0
   a=mid:bravo

   m=video 4444
   a=mid:charlie
   a=candidate     <-- See here

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Mar 2016 03:52:49 -0800

On Thu, Mar 3, 2016 at 7:53 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi Ekr,
>
> I think I presented exactly the same use-case when it was first suggested
> to not associate shared candidates with each bundled m- line.
>

Quite possibly. However, I guess a number of us weren't paying attention
since it came as a surprise to a bunch of us yesterday.

>
> I'll look if I can add some additional text somewhere, to point out that
> the candidates can be associated with different m- lines in offers and
> answers, e.g. due to the use-case you described.
>

Thanks

-Ekr

> ------------------------------
> From: Eric Rescorla <[email-masked]>
> To: mmusic WG <[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Mar 2016 03:56:24 -0800

>    to which the ICE-related SDP attributes were associated in the
I think the key point here is not that but that the attributes may be
attached in the
offer to an m= line which ends up being defunct.

I'd also like to observe that this paragraph exemplifies an infelicity in
the current
draft, which is the overloading of the term "associated", which appears
three times
in this paragraph alone with two different meanings. I think it would be
clearer if
instead different terms were used. I suggest "member of" for being in a
bundle group,
"appears in" or "attached to" for being in a given m= section, and
"corresponding"
for "the SDP offer/answer that this answer/offer" goes with

-Ekr

> Regards,
>
>
>
> Christer
>
>
>
> *From:* mmusic [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 4. maaliskuuta 2016 5:53
> *To:* Eric Rescorla; mmusic WG
> *Subject:* Re: [MMUSIC] Bundle rejection oddities
>
>
>
> Hi Ekr,
>
> *From: *Eric Rescorla <[email-masked]>
> *Sent: *‎04/‎03/‎2016 02:53
> *To: *mmusic WG <[email-masked]>
> *Subject: *[MMUSIC] Bundle rejection oddities
>
> Hi folks,
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Mar 2016 12:41:09 +0000

Hi,

>I think the key point here is not that but that the attributes may be attached in the

That could e.g. be covered by adding the following sentence to the note:

"This could happen e.g. if the "m=" line in the offer is rejected and moved out 
of the bundle group by the answerer."

>I'd also like to observe that this paragraph exemplifies an infelicity in the current
>draft, which is the overloading of the term "associated", which appears three times
>in this paragraph alone with two different meanings. I think it would be clearer if
>instead different terms were used. I suggest "member of" for being in a bundle group,
>"appears in" or "attached to" for being in a given m= section, and "corresponding"

I agree that "associated" is used in many places. But, I have had to change the terminology so many times already, because every time someone has reviewed the document he/she has had ideas on how to modify the terminology.

The current terminology is what we have been able to agreed upon, so I do not want to change it again. I really think it's time to ship BUNDLE.

Regards,

Christer

Hi Ekr,

Regards,

Christer

Sent from my Windows Phone
________________________________________
From: Eric Rescorla
Sent: ‎04/‎03/‎2016 02:53
To: mmusic WG
Subject: [MMUSIC] Bundle rejection oddities
Hi folks,

 
   
   m=video 2222
   a=mid:bravo
   a=candidate
   
   m=video 3333
   a=mid:charlie
   a=candidate

 
   
   m=video 4444
   a=mid:bravo
   a=candidate
   
   m=video 4444
   a=mid:charlie

   
   m=video 5555
   a=mid:bravo
   a=candidate
   
   m=video 5555
   a=mid:charlie

   a=group:BUNDLE charlie
   m=audio 0
   a=mid:alpha
   
   m=video 0
   a=mid:bravo
   
   m=video 4444
   a=mid:charlie
   a=candidate     <-- See here

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Mar 2016 04:49:04 -0800

> of the bundle group by the answerer."

Well, I think the key point here is that you need to take the attributes
out of the
defunct line, which neither this text nor the previous text really captures.

> I agree that "associated" is used in many places. But, I have had to
> change the terminology so many times already, because every time someone
> has reviewed the document he/she has had ideas on how to modify the
> terminology.
>
> The current terminology is what we have been able to agreed upon, so I do
> not want to change it again. I really think it's time to ship BUNDLE.

I'm happy to have different terminology but not to have the same term used
for multiple
purposes, which is the current situation. I'm sympathetic to editor
fatigue, but I think
having the document be readable is more important.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Mar 2016 16:46:03 +0000

Hi,

> Well, I think the key point here is that you need to take the attributes out of the

The 3rd bullet in the bullet list does say:

      "the answerer only associates ICE-related media-level SDP attributes with the "m=" line associated with the
      answerer BUNDLE-tag."

Perhaps we could add to that statement:

"The answerer MUST NOT associated ICE-related media-level SDP attributes with any other "m=" lines within the bundle group."

(And a similar statement to the bullet talking about the offer)

-------------

>> I agree that "associated" is used in many places. But, I have had to change the terminology so many 
>> times already, because every time someone has reviewed the document he/she has had ideas on how to modify the terminology.
>>
>> The current terminology is what we have been able to agree upon, so I do not want to change it again. I really think it's time to ship BUNDLE.
>
> I'm happy to have different terminology but not to have the same term used for multiple
> purposes, which is the current situation. I'm sympathetic to editor fatigue, but I think

Just a few comments on your suggestions:

- You suggest saying "member of bundle group". But, I don't think I say "associated with bundle group", but "within bundle group". At least that is my intention, so please let me know if you've found some places where that's not the case.

- You suggest saying "attribute appearing in m- line". Such terminology has been used in the past, and I was asked to change it, because attributes are not part of m- lines.

- I do use "corresponding" when I talk about m- lines in offers and answers. If we use it "corresponding" also for offers and answers we would end up with text like "the corresponding m- line in the corresponding answer".

Regards,

Christer

Hi Ekr,

Regards,

Christer

 

   m=video 2222
   a=mid:bravo
   a=candidate
   
   m=video 3333
   a=mid:charlie
   a=candidate

 
   
   m=video 4444
   a=mid:bravo
   a=candidate
   
   m=video 4444
   a=mid:charlie

   
   m=video 5555
   a=mid:bravo
   a=candidate
   
   m=video 5555
   a=mid:charlie

   a=group:BUNDLE charlie
   m=audio 0
   a=mid:alpha
   
   m=video 0
   a=mid:bravo
   
   m=video 4444
   a=mid:charlie
   a=candidate     <-- See here

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 5 Mar 2016 15:41:26 +0000

Ekr, did you comment my latest text suggestion (see below)?

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 04 March 2016 18:46
To: Eric Rescorla <[email-masked]>
Cc: mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] Bundle rejection oddities

Hi,

>>>attached in the offer to an m= line which ends up being defunct.
>
>> "This could happen e.g. if the "m=" line in the offer is rejected and 
>>moved out of the bundle group by the answerer."
>
> Well, I think the key point here is that you need to take the 
> attributes out of the defunct line, which neither this text nor the previous text really captures.

-------------

>>>I'd also like to observe that this paragraph exemplifies an 
>>>infelicity in the current draft, which is the overloading of the term 
>>>"associated", which appears three times in this paragraph alone with 
>>>two different meanings. I think it would be clearer if instead 
>>>different terms were used. I suggest "member of" for being in a bundle group, "appears in" or "attached to" for being in a given m= section, and "corresponding"
>> change the terminology so many times already, because every time someone has reviewed the document he/she has had ideas on how to modify the terminology.
>>
> I'm happy to have different terminology but not to have the same term 
> used for multiple purposes, which is the current situation. I'm 
> sympathetic to editor fatigue, but I think having the document be readable is more important.

Regards,

Christer

Hi Ekr,

Regards,

Christer

Sent from my Windows Phone
________________________________________
From: Eric Rescorla
Sent: ‎04/‎03/‎2016 02:53
To: mmusic WG
Subject: [MMUSIC] Bundle rejection oddities Hi folks,
 
I've been working through the bundle draft and I've come across a sort of surprising consequence that I wanted to share with the group. Sorry for the extended example, but I think it's hard to get without that.
 
Consider the case where an offerer has three m= lines, alpha, bravo, and charlie. This creates an initial offer that's (schematically) like
this:

   m=video 2222
   a=mid:bravo
   a=candidate
   
   m=video 3333
   a=mid:charlie
   a=candidate
 
Per 8.2, and because this isn't bundle-only, each m= line has a unique address and a set of candidates (I'm ignoring the ufrag and ice-pwd for now).
 
Assume that the answerer rejects the first m= line, so per 8.3, it pulls alpha out of the bundle group and sets is port number to 0.  Per 11.2, it only associates candidates with the answerer bundle tag, which is bravo:

   m=video 4444
   a=mid:bravo
   a=candidate
   
   m=video 4444
   a=mid:charlie

So far so good. Now consider what happens if the offerer does an ICE restart and (for instance) changes some property about the second m= line. Per S 11.1 bullet 1, it only uses a shared address for the second two m= lines and only attaches a candidate to the second one (bravo). I.e.,

   m=video 5555
   a=mid:bravo
   a=candidate
   
   m=video 5555
   a=mid:charlie

If the answerer decides to reject bravo (leaving only charlie), it now sets its port to 0 and pulls it out of the bundle group, giving us:
 
   a=group:BUNDLE charlie
   m=audio 0
   a=mid:alpha
   
   m=video 0
   a=mid:bravo
   
   m=video 4444
   a=mid:charlie
   a=candidate     <-- See here

Note that the candidate here is on the third m= line but it needs to be paired with the candidates on the second (rejected) m= line from the offerer. I'm not saying that this is fatal: the logical interpretation is that the candidates (and other ICE parameters) are associated with the whole bundle group (and implicitly duplicated) and just appear with one m= line. However, it is a bit odd and probably should be called out in the spec lest people get confused.
 
-Ekr

 

 

 

 

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Mar 2016 09:20:06 -0800

On Fri, Mar 4, 2016 at 8:46 AM, Christer Holmberg <
[email-masked]> wrote:

> "The answerer MUST NOT associated ICE-related media-level SDP attributes
> with any other "m=" lines within the bundle group."
>

No I don't think this is getting at the right point, which is about the
mismatch.

I would add after the third bullet:

   Note that because the ICE parameters apply to the bundle group rather
than
   to a given "m=" line, but only appear within the "m=" section associated
with
   the sender's BUNDLE-tag,, it is possible for the offerer's and answerer's
   ICE parameters to appear within "m=" sections that do not correspond to
   each other, for instance if the answerer rejects the "m=" section
associated
   with the offeror's BUNDLE-tag. It is the responsibility of both sides to
match
   up the ICE parameters appropriately, regardless of which "m=" section of
   the bundle group they appear in.

> change the terminology so many
> >> times already, because every time someone has reviewed the document
> he/she has had ideas on how to modify the terminology.
> >>
> >> The current terminology is what we have been able to agree upon, so I
> do not want to change it again. I really think it's time to ship BUNDLE.
> >
> used for multiple
> - You suggest saying "member of bundle group". But, I don't think I say
> "associated with bundle group", but "within bundle group". At least that is
> my intention, so please let me know if you've found some places where
> that's not the case.
>

S1.
   The offerer and answerer [RFC3264] use the BUNDLE extension to
   negotiate the BUNDLE addresses, one for the offerer (offerer BUNDLE
   address) and one for the answerer (answerer BUNDLE address), to be
   used for receiving the bundled media associated with a BUNDLE group.

S 5.
   All media associated with a BUNDLE group share a single 5-tuple, i.e.
   in addition to using a single address:port combination all bundled
   media MUST be transported using the same transport-layer protocol

- You suggest saying "attribute appearing in m- line". Such terminology has
> been used in the past, and I was asked to change it, because attributes are
> not part of m- lines.
>

I would recommend the JSEP terminology of "appearing within an m= section"
In any case, the problem is the use of "associated" here. Feel free to use
another term that's not "associated"

> - I do use "corresponding" when I talk about m- lines in offers and
> answers. If we use it "corresponding" also for offers and answers we would
> end up with text like "the corresponding m- line in the corresponding
> answer".
>

Again, the problem is "associated". Feel free to choose another term than
corresponding.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 5 Mar 2016 18:59:35 +0000

Hi,

>No I don't think this is getting at the right point, which is about the mismatch.
>
>   Note that because the ICE parameters apply to the bundle group rather than
>   to a given "m=" line, but only appear within the "m=" section associated with
>   each other, for instance if the answerer rejects the "m=" section associated
>   with the offeror's BUNDLE-tag. It is the responsibility of both sides to match

I can work with that.

Now, IF we move ahead with Peter's suggestion (feel free to comment on that) to apply the same rule also for other attributes with identical values, the text would be put in the general O/A section.

> - You suggest saying "member of bundle group". But, I don't think I say "associated with bundle group", but "within bundle 
> group". At least that is my intention, so please let me know if you've found > some places where that's not the case.
>
> S1.

In those cases the text talks about the MEDIA, not SDP parameters. I am happy to change it to something else, but I am not sure whether we could say "media attached to the bundle group", "media that appears in the bundle group" or "media that is a member of the bundle group"?

>another term that's not "associated"

"m= line" is used throughout the document, so I don't want to change that to "m= section", because I don't think it can be done with a simple search/replace.

At one point I think I suggested "media description", which would include both the "m=" line and the attributes. Then we could have said "within the media description", "add to the media description", etc. But, people weren't happy with that either.

Whatever change I do, it has to be something that EVERYONE agrees with. Otherwise, when X reviews the document, I may end up having to change it all again...

I know that at least Paul and Flemming have had comments on the terminology, so I'd like to get some input from them.

Regards,

Christer

Hi Ekr,

Regards,

Christer

 

   m=video 2222
   a=mid:bravo
   a=candidate
   
   m=video 3333
   a=mid:charlie
   a=candidate

 
   
   m=video 4444
   a=mid:bravo
   a=candidate
   
   m=video 4444
   a=mid:charlie

   
   m=video 5555
   a=mid:bravo
   a=candidate
   
   m=video 5555
   a=mid:charlie

   a=group:BUNDLE charlie
   m=audio 0
   a=mid:alpha
   
   m=video 0
   a=mid:bravo
   
   m=video 4444
   a=mid:charlie
   a=candidate     <-- See here

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 6 Mar 2016 17:28:18 -0500

> In those cases the text talks about the MEDIA, not SDP parameters. I am happy to change it to something else, but I am not sure whether we could say "media attached to the bundle group", "media tha…

How about "media {described / identified / specified} by the bundle group"?

> I know that at least Paul and Flemming have had comments on the terminology, so I'd like to get some input from them.

Yes, I was one of the people that had problems with prior terminology. 
And "associated" seemed to work at the time.

I agree that now we do have a problem with "associated" being used in 
other contexts to mean something different, and the result again being 
confusing.

I am not attached to "associated", as long as we end up with something 
clear, that uses the same terminology consistently for a concept, and 
clearly different terminology for *different* concepts. But it is hard. 
So I share Christer's desire to be conservative about making changes now.

So I guess I would prefer to keep with "associated with an m= line" for 
attributes and the like that follow an m-line, and something different 
for other uses of "associated", especially in the same sentence or 
paragraph.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Mar 2016 08:31:44 +0000

Hi,

> How about "media {described / identified / specified} by the bundle group"?

I've probably tried that already in the past too, but if people are ok with it, then fine... :)

-----------------

>>> In any case, the problem is the use of "associated" here. Feel free 
>>> to use another term that's not "associated"
>>
> I agree that now we do have a problem with "associated" being used in other contexts to mean something different, and the result again being confusing.
>
> I am not attached to "associated", as long as we end up with something clear, that uses the same terminology consistently for a concept, and clearly different terminology for *different* concepts. But it is hard. 
> So I guess I would prefer to keep with "associated with an m= line" for attributes and the like that follow an m-line,

I agree, and at this point I will actually refuse to change that. But, if someone else wants to take the pen, then fine...

>and something different for other uses of "associated", especially in the same sentence or paragraph.

I guess we could use "corresponding" when we match offers and answers, and when we match "m=" lines in an offer and answer.

For example:

"Take the value from the corresponding "m=" line in the corresponding offer".

Yes, we'd use "corresponding" for two things, but at least we'd get rid of one "associated" usage.

But, if someone has another suggestion, please let me know. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Mar 2016 11:36:20 +0000

Hi,

I've compiled a new version of draft-bundle, where I've replaced "associated" in a number of places. 

I've not submitted the draft yet, but you can see the changes on github:

https://github.com/cdh4u/draft-sdp-bundle

NOTE: I have not yet added the additional text requested by Ekr - this version only does the terminology changes.

Ekr/Paul/Flemming, please indicate whether you are ok or not with the changes.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 7. maaliskuuta 2016 10:32
To: Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] Bundle rejection oddities

Hi,

-----------------

> So I guess I would prefer to keep with "associated with an m= line" 
> for attributes and the like that follow an m-line,

For example:

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 7 Mar 2016 22:53:15 -0500

Hi Christer

I don't think the change from "associated with ...'m=' line" to 
"specified by ...'m=' line" is a good change (and I thought you were 
against that based on your earlier e-mail too, but the draft I pulled 
from github seems to have made that change). Attributes and other 
parameters are not specified by 'm=' lines; they are indeed "associated" 
with them (or more generally speaking they can be seen as part of the 
media description which is another way of referring to 'm=' line and its 
various "associated" parameters).

I realize the term "associated" is used a lot in the current document 
and it doesn't improve overall readability, however I think technical 
accuracy needs to come first. I don't see the current usage as being 
overloaded, but I'm certainly open to alternative text suggestions as 
long as they are technically sound and we can get everybody (that cares) 
to agree on them.

Lastly, given the substantial amount of work the primary author has put 
into this document, incl. trying to accommodate input from many 
different people, going through multiple WGLCs, etc., I would also ask 
people to be mindful of how much an issue they really see here.

Thanks

-- Flemming

On 3/7/16 6:36 AM, Christer Holmberg wrote:
> .

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Mar 2016 04:41:59 +0000

Hi Flemming,

Note that I did the change to "specified by" only when talking about media. Parameters etc are still "associated with" m- lines.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Flemming Andreasen<mailto:[email-masked]>
Sent: ‎08/‎03/‎2016 05:53
To: Christer Holmberg<mailto:[email-masked]>; Paul Kyzivat<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Eric Rescorla ([email-masked])<mailto:[email-masked]>
Subject: Re: [MMUSIC] Bundle rejection oddities

Hi Christer

Thanks

-- Flemming

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Mar 2016 08:54:52 +0000

Ekr, can you live with the suggested changes (as seen on github)? I got rid of a few “associated” usages.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 8. maaliskuuta 2016 6:42
To: Flemming Andreasen; Paul Kyzivat; [email-masked]; Eric Rescorla ([email-masked])
Subject: Re: [MMUSIC] Bundle rejection oddities

Hi Flemming,

Regards,

Christer

Thanks

-- Flemming

On 3/7/16 6:36 AM, Christer Holmberg wrote:
> To: Paul Kyzivat; [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 10 Mar 2016 15:46:21 -0500

On 3/7/16 11:41 PM, Christer Holmberg wrote:
> Hi Flemming,
>
> Note that I did the change to "specified by" only when talking about 
> media. Parameters etc are still "associated with" m- lines.
>
Right - overall I think readability is improved here, especially where 
you changed "associated" to "corresponding". I'd still prefer keeping 
"associated" when you refer to "m=" lines, but in the interest of moving 
forward, I won't insist on that if EKR is happy with the current text 
and nobody else complains either.

Thanks

-- Flemming (as individual)

> ------------------------------------------------------------------------
> From: Flemming Andreasen <mailto:[email-masked]>
> To: Christer Holmberg <mailto:[email-masked]>; Paul 
> Kyzivat <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; Eric Rescorla ([email-masked]) 
> <mailto:[email-masked]>
> > NOTE: I have not yet added the additional text requested by Ekr - 
> this version only does the terminology changes.
> >
> >>> In those cases the text talks about the MEDIA, not SDP parameters. 
> I am happy to change it to something else, but I am not sure whether 
> we could say "media attached to the bundle group", "media that appears 
> in the bundle group" or "media that is a member of the bundle group"?
> >>>>> - You suggest saying "attribute appearing in m- line". Such 
> terminology has been used in the past, and I was asked to change it, 
> because attributes are not part of m- lines.
> >>> "m= line" is used throughout the document, so I don't want to 
> change that to "m= section", because I don't think it can be done with 
> a simple search/replace.
> >>>
> >>> At one point I think I suggested "media description", which would 
> include both the "m=" line and the attributes. Then we could have said 
> "within the media description", "add to the media description", etc. 
> But, people weren't happy with that either.
> >>>
> >>> Whatever change I do, it has to be something that EVERYONE agrees 
> with. Otherwise, when X reviews the document, I may end up having to 
> change it all again...
> >>>
> >>> I know that at least Paul and Flemming have had comments on the 
> terminology, so I'd like to get some input from them.
> >> I agree that now we do have a problem with "associated" being used 
> in other contexts to mean something different, and the result again 
> being confusing.
> >>
> >> I am not attached to "associated", as long as we end up with 
> something clear, that uses the same terminology consistently for a 
> concept, and clearly different terminology for *different* concepts. 
> But it is hard.
> > I agree, and at this point I will actually refuse to change that. 
> But, if someone else wants to take the pen, then fine...
> >
> > I guess we could use "corresponding" when we match offers and 
> answers, and when we match "m=" lines in an offer and answer.
> >
> > For example:
> >