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

Philipp Hancke <> Fri, 05 July 2019 08:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C3BC120196 for <>; Fri, 5 Jul 2019 01:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ayYq9pizRtto for <>; Fri, 5 Jul 2019 01:43:22 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1EA89120286 for <>; Fri, 5 Jul 2019 01:43:21 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.3/8.14.3/Debian-9.4) with ESMTP id x658hLrL030389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <>; Fri, 5 Jul 2019 10:43:23 +0200
From: Philipp Hancke <>
References: <> <> <> <> <> <> <> <> <> <>
Message-ID: <>
Date: Fri, 5 Jul 2019 10:43:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Fri, 05 Jul 2019 08:43:37 -0000

Am 04.07.19 um 23:23 schrieb Harald Alvestrand:
> Den 04.07.2019 20:46, skrev Roman Shpount:
>> I understand that running experiments before proposing a solution is
>> probably a good thing and this is what Chrome was doing up until this
>> point. At the same time, rolling this feature into production before at
>> least documenting it, will definitely cause interop problems. What we
>> have now is a fairly major feature with a fairly outdated specification
>> where all the interop issues weren't considered.
> To be precise, we have documentation for the feature
> (draft-ietf-rtcweb-mdns-ice-candidates), it's been largely unchanged for
> quite some time, and it's what Chrome is in the process of shipping

Where has the plan to ship this in M75 been communicated? It doesn't 
even seem to be using the blink launch process?

> It addresses a quite substantive issue (as in "millions of occurenes
> per day" of the behavior we want to prevent).

I think 3.5% of pageloads (from chromestatus' metric 1054) is a bit more 
than "millions".

> The fact that we're only getting the interoperability issues discovered
> as we roll out the feature to stable is sad; I don't know how to get
> other people's software tested earlier in the cycle, which is what would
> have given us more time to work through these issues.

Have you tried talking to said other people? (this is rhetorical. I 
remember the dtls 1.0 deprecation and many other cases)

in this particular case I reported that the previous choice of putting 
an empty string into c= was broken back in January:
I find it quite sad that this was fixed without verifying that Firefox 
(which I indicated as 'throws' in the second comment) is ok with this.
(yes, I could have tested this myself; OTOH this isn't part of my job)

I suspect the interop issue with Firefox is restriced to non-trickle 
usage where no stun/turn servers are used. Which might be uncommon in 
general (for P2P) but might be a highly relevant deployment scenario for 
some applications that talk to servers.

This is a pattern that has broken things in the past (see for example 
the "unified plan breaks my cma" episode) because errors in those apps 
are not visible in the very noisy system that "chrome as a whole"