Subject: [rtcweb] mdns-ice-candidates: Single IP address:port

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Sep 2018 15:55:18 +0000

Hi,

A couple of comments:

Q1: As discussed back in July, as an ICE candidate by definition is associated with a single IP address:port, we should make it clear in the draft that there can only be an 1:1 mapping between the "mdns candidate" and an IP address:port.

Q2: Related to Q1, I assume we can remove the last paragraph in section 3.2.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Sep 2018 14:35:28 -0500

[as an individual]

On 9/13/18 10:55 AM, Christer Holmberg wrote:
>
> Hi,
>
> A couple of comments:
>
> Q1: As discussed back in July, as an ICE candidate by definition is 
> associated with a single IP address:port, we should make it clear in 
> the draft that there can only be an 1:1 mapping between the “mdns 
> candidate” and an IP address:port.
>

Part of why this wasn't simple enough to slipstream into the existing 
documents is that we don't have well-defined handling in SDP for dealing 
with names in the <connection-address> field of "c=" lines. The extent 
of RFC 4566's text on the topic is:

    A session description can contain domain names in the "o=", "u=",
    "e=", "c=", and "a=" lines.  Any domain name used in SDP MUST comply
    with [1], [2].  Internationalised domain names (IDNs) MUST be
    represented using the ASCII Compatible Encoding (ACE) form defined in
    [11] and MUST NOT be directly represented in UTF-8 or any other
    encoding (this requirement is for compatibility with RFC 2327 and
    other SDP-related standards, which predate the development of
    internationalised domain names).

Unfortunately, this doesn't provide a lot of clarity about what happens 
if a DNS lookup of the corresponding domain name returns multiple A or 
AAAA records. (The fact that "c=" lines clearly indicate their address 
family saves us from having to worry about any happy-eyeballs-style 
address family fiddling, but the handling of name lookups is still 
somewhat ambiguous).

So I think we need to reach a common understanding about how to handle 
the normal name-to-address mapping case, and then apply the same 
principle to mDNS as we do to DNS.

/a

---

From: youenn fablet <[email-masked]>
Date: Fri, 14 Sep 2018 10:46:31 -0700

> with names in the <connection-address> field of "c=" lines. The extent of
> RFC 4566's text on the topic is:
>
>
> Unfortunately, this doesn't provide a lot of clarity about what happens if
> a DNS lookup of the corresponding domain name returns multiple A or AAAA
> records. (The fact that "c=" lines clearly indicate their address family
> saves us from having to worry about any happy-eyeballs-style address family
> fiddling, but the handling of name lookups is still somewhat ambiguous).
>
> So I think we need to reach a common understanding about how to handle the
> normal name-to-address mapping case, and then apply the same principle to
> mDNS as we do to DNS.
>
I agree with the principle.
In practice though, MDNS might be simpler to use.
The MDNS specification does not require an application to register a name
for both IPv4 and IPv6.
We might end up with two different MDNS ids for IPv4 and IPv6, each id
resolving to exactly one record.