Re: [MMUSIC] Bundle rejection oddities

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:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 8. maaliskuuta 2016 6:42
To: Flemming Andreasen; Paul Kyzivat; mmusic@ietf.org; Eric Rescorla (ekr@rtfm.com)
Subject: Re: [MMUSIC] Bundle rejection oddities

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:fandreas@cisco.com>
Sent: ‎08/‎03/‎2016 05:53
To: Christer Holmberg<mailto:christer.holmberg@ericsson.com>; Paul Kyzivat<mailto:pkyzivat@alum.mit.edu>; mmusic@ietf.org<mailto:mmusic@ietf.org>; Eric Rescorla (ekr@rtfm.com)<mailto:ekr@rtfm.com>
Subject: Re: [MMUSIC] Bundle rejection oddities
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:
> 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:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
> Sent: 7. maaliskuuta 2016 10:32
> To: Paul Kyzivat; mmusic@ietf.org<mailto:mmusic@ietf.org>
> Subject: Re: [MMUSIC] Bundle rejection oddities
>
> Hi,
>
>>>> 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
>>> 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"?
>> 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... :)
>
> -----------------
>
>>>>> - 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"
>>> "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.
>> 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,
> 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
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org<mailto:mmusic@ietf.org>
> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org<mailto:mmusic@ietf.org>
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>