Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?

Nils Ohlmeier <> Thu, 04 July 2019 04:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F31A91200DE for <>; Wed, 3 Jul 2019 21:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Nv7rBn9-O2H for <>; Wed, 3 Jul 2019 21:50:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B75ED120088 for <>; Wed, 3 Jul 2019 21:50:23 -0700 (PDT)
Received: by with SMTP id t7so2394521plr.11 for <>; Wed, 03 Jul 2019 21:50:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=h77aPwLh2Jqtn5S5UXu7DbJLnxztytkBR5G7/RL6hJo=; b=Uo7HdbeBnjh0vSK3Rwl8Dlv90bCn5iVH+GXCuRsDQ3Da01rKdKXZ0AVzJYQrAeNVJU K8oC/tH+I6a1FfmIutNDK9T+DXWj7t9+p8z1pw8XZUl0uVRexSAlqlFzasWWZYUcRJye h79GURFMYjxJc9Ol1U8uqOL4nWCea5QYux4UY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=h77aPwLh2Jqtn5S5UXu7DbJLnxztytkBR5G7/RL6hJo=; b=maG31xGB7Axur4+yXheOQWYLN8Zdc1fbPwas29wf9U02Hplt6+0fBnutfenzUazVtq y0ulOLVN7a7y06bMs/FfCJIR42Oc8NehAfUwPdcVOo227bU2eJGzbmkkqeljU1lr7sr1 j9kEa8cT4+vHsSc7v8YNwj8B0sKS3xXLqNjjrX7zME6uEfxEcSwXVPxxA4ansAbH9U1u wflr+DO5aUzlSJ73q59xNwm5UCsgTw/JC2rFXyfvxzTmaJ4UayzXhus11SJIxIwmYNKE lTkiw8vZPzRQelJkIZyCj7mL1zCgbAcNEbtwbgH+PKRQhoZE61xMObDj1wDGUHw4Cwsb PK4g==
X-Gm-Message-State: APjAAAVBAKglic+7P094uzWEUbdsWaTQkV4aHt90kr1rO2WUOBpfGQdp sOfgn60f5j0I26fUmrVtWWlTCA==
X-Google-Smtp-Source: APXvYqx04U7Pl00r2xmKpSgt6y0O+b04ZA4grny7b+OfaWO/ktb8vOaXjo0lM8BtpelhE4zHQy/zHw==
X-Received: by 2002:a17:902:7787:: with SMTP id o7mr43240018pll.120.1562215822923; Wed, 03 Jul 2019 21:50:22 -0700 (PDT)
Received: from ?IPv6:2601:647:4600:3f31:3126:36db:8c73:b0d5? ([2601:647:4600:3f31:3126:36db:8c73:b0d5]) by with ESMTPSA id b15sm3933555pfi.141.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 21:50:22 -0700 (PDT)
From: Nils Ohlmeier <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4CF7AB50-8C40-4811-9FF7-312A9F7CABEA"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 3 Jul 2019 21:50:20 -0700
In-Reply-To: <>
Cc: Roman Shpount <>, "" <>
To: Justin Uberti <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Jul 2019 04:50:28 -0000

Probably not the ideal forum to point this out, but I hope the Chrome team is aware that rolling out this feature, assuming it includes using mDNS in the connection line, will break interop with Firefox.
So I have to concur that rolling this out appears to be premature to me.

  Nils Ohlmeier

> On 3Jul, 2019, at 17:58, Justin Uberti <> wrote:
> Hmm, that's unfortunate. I think this is a mistake, given that we are about to throw the switch to enable mDNS for 100% of Chrome endpoints; Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this extension spec is written.
> ice-sip-sdp isn't published yet, so it seems an update to that document could still be a possibility. If that's not an option, putting forth #1 as a specific extension that allows FQDN candidates to be generated in certain situations seems like the right path.
> On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount < <>> wrote:
> Part of the problem is that mmusic have decided to punt on the FQDN support. In the current mmusic-ice-sip-sdp the final language that was included:
> <connection-address>:  is taken from RFC 4566 [RFC4566].  It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs).  When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6.  An agent generating local candidates MUST NOT use FQDN addresses.  An agent processing remote candidates MUST ignore candidate lines that include candidates with FQDN or IP address versions that are not supported or recognized.  The procedures for generation and handling of FQDN candidates, as well as, how agents indicate support for such procedures, need to be specified in an extension specification.
> So, at this point we have two options: 
> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and define how FQDN candidates generated by mdns are handled
> 2. write a new draft in mmusic which defines FQDN handling
> In any case some sort of mmusic discussion is needed to reconcile this.
> Best Regards,
> _____________
> Roman Shpount
> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti < <>> wrote:
> The problem this draft is trying to solve is fairly RTCWEB-specific. If there are individual issues to resolve, we can send them out to mmusic for discussion, but AFAIK no changes to existing ICE specs are needed.
> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount < <>> wrote:
> Hi All,
> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? This entire draft seems to be ICE/SDP specific and not limited to rtcweb. Also, there are significant interop implications for this draft between browser and non-browser end points which probably warrant larger discussion outside of rtcweb group. I would think mmusic would be a much better place for this draft. I know there is an incentive to complete this draft quickly but this has a potential to break a lot of things (it already did break interop with almost every existing ICE implementation).
> Regards,
> _____________
> Roman Shpount
> _______________________________________________
> rtcweb mailing list
> <>
> <>
> _______________________________________________
> rtcweb mailing list