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

[Christer Holmberg <[e-mail]>]

Hi,

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

My suggestion was to add text about the special case of port 9 and IP address 0.0.0.0.

Because, when you use trickle, the offer may not contain any address information at all (you can send an offer without any candidates), so it is a special case no matter what.

Regards,

Christer