Re: [MMUSIC] Adam Roach's Yes on draft-ietf-mmusic-sdp-bundle-negotiation-49: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Thu, Apr 19, 2018 at 2:41 AM, Ben Campbell <[e-mail]> wrote:

>
>
> On Apr 18, 2018, at 9:23 AM, Christer Holmberg <
> [e-mail]> wrote:
>
> >> This doesn't answer my question. Who, specifically, thinks that this
> terminology
> >> of focusing on the address:port and not the m= section is good?
> >
> > Considering that the focus has been on the address and port since day
> one, for 7 years, I think it is good. After all, while there is more to it
> than the address:port, the main reason for BUNDLE is to be able to
> multiplex in a single address:port.
> >
> > Now, we HAVE discussed changing "address:port" to "transport", but it
> would still not be about the m= section.
> >
> >>> Having said that, if we can change it with a search/replace operation
> I am
> >>> happy to discuss it. I THINK we could do that e.g., with "transport" or
> >>> "3-tuple".
> >>>
> >>> But I don¹t want to make yet another re-write of the document just to
> once
> >>> again change the terminology.
> >>
> >> This document is going to be used by a lot of people. It's important
> that it be
> >> clear.
> >
> > I fully agree. But, I am not sure that endless re-writings the document
> is going to achieve that.
>
> I think this has turned into an argument about style. One usage may be
> more pleasing to the “ear” than the other, but I don’t see issues of
> technical correctness or clarity here. As I asked for the the “associated
> with” question, is anyone arguing that the word choice here is likely to
> cause material implementation errors?
>

I don't think "address:port" versus "transport" will, but I do think
"address:port" versus "m=section" or "transport parameters" will, and in
fact I identified a material issue around trickle the other day, that I
haven't seen a response to.

-Ekr

Ben.
>