Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling

Justin Uberti <juberti@google.com> Wed, 07 March 2018 22:39 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638EF126CBF for <rtcweb@ietfa.amsl.com>; Wed, 7 Mar 2018 14:39:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 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_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRxfJajOLDyF for <rtcweb@ietfa.amsl.com>; Wed, 7 Mar 2018 14:39:37 -0800 (PST)
Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1359127419 for <rtcweb@ietf.org>; Wed, 7 Mar 2018 14:39:37 -0800 (PST)
Received: by mail-ua0-x233.google.com with SMTP id u99so2610026uau.8 for <rtcweb@ietf.org>; Wed, 07 Mar 2018 14:39:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hr7PDmsEO1tCnqWkC7Y6xWspldht6t3UGp2Er3bmH5c=; b=Hp7qSeDEL4cFL3ify/uIff8F7W7foz6HGZdN7Zk24XE0LXXQ0WeWiB/iK1N/lu6yxx G3bbPLT4vbRDdTtMqD9MDIoi+U130YrqJJtcr88OW+Jkxe1NThGMK8+8/32i6z+hkD89 TcMPxxC84W04TVKZSIO9bpR572DbYAbLu3zgOGgY9H3Ff41qMx+1UTlnhS4ZLEV2oWIZ OBtvns0HiNNUyQjnVaFLitPWCfhpSJJWDFRblv9F0n12evN8OtQtbRUX/MyN6zJRqyjN OjGy5beCQyoc3yeY/HBakJztoMC0mVXNRupQaNMaoAyLLXeQ0stF4JdkfsHZOJpDsjtV wLgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hr7PDmsEO1tCnqWkC7Y6xWspldht6t3UGp2Er3bmH5c=; b=B09OYl7+AsAHYW5g2xVDOwlodOrqWCTW+jjr/9TGKzlhNLMGCWdO+f2oYJtIJrngwr aDyt7ERj7jKTlSRF5Ma6Lmp+dXXq4XHtpIByykUrMCKAAuSCo/HWa/dCDCEQQNIjNa/R GkiAEd1KDhTCxfo1ZDn+lHj0WnjWwvuNptZctugqMsocgZ70sjnHGRiLpLljoqO8j5ww TUs+zuC8LH3pQWBBGc2M3V7cbtqvYAaUcs3UEpQgxe3agmhgPcsJaj3uqToUNj5Jku4F A6+syDuUshejxJX+mizd0NMs0AQovxoh2SJQL7tpIMu5mpkSHz5x+LxPIQVZ/52yLgg0 RJnw==
X-Gm-Message-State: AElRT7EC8ov1dmb9WqqKSNov5Zvg1IyuWHpLit4sHIT15oNz1IEdKEGj 64nLW7PcPFUidDjAktNPauFdXc9WGQME94JUpBUqqw==
X-Google-Smtp-Source: AG47ELsslsU2qJgybyqF+2RIfyZ76pViM4/T5CKqnYBCBDW6bDZfJc+UoYXc4xUEF+wu+RkTzgNnCmWgps4KIaSvMB4=
X-Received: by 10.176.6.197 with SMTP id g63mr14458969uag.72.1520462376121; Wed, 07 Mar 2018 14:39:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.167.206 with HTTP; Wed, 7 Mar 2018 14:39:15 -0800 (PST)
In-Reply-To: <CA+9kkMBPUNOuMzM+fMtoFAAVbCD-Vd0Y1uViZmUW-Xi7iWPg5A@mail.gmail.com>
References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <CAOJ7v-1gTq+EEjb+-q-T-pABBW--rpNGegoj_d2_7f7AKGksCA@mail.gmail.com> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <CA+9kkMBPUNOuMzM+fMtoFAAVbCD-Vd0Y1uViZmUW-Xi7iWPg5A@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 07 Mar 2018 14:39:15 -0800
Message-ID: <CAOJ7v-0HExbJJ0YVkB60QAVuW0-f096vp9r4tyo67fYw+mP2Ag@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c122e64d343e80566da3b70"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/t8K4s_4sApL9iy23h_H1J4wcHjU>
Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2018 22:39:39 -0000

On Wed, Mar 7, 2018 at 2:13 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

> On Wed, Mar 7, 2018 at 1:12 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie
> > wrote:
>
>>
>> Hiya,
>>
>> To also be clear: my main objection is to the term consent being
>> used at all. The stuff below isn't that big a deal, though would
>> change if the WG did drop the idea of "consent" supposedly being
>> a real thing.
>>
>>
> So, while I am sympathetic (just generally, really, not just to this), I
> think "consent" is basically a term of art in the web world and that its
> use in the document is consistent with the more general use.
>
> If you know of a different term of art here that would be similarly
> well-understood, I would be glad to know of it.  It may also be an
> interesting project to create such a term.  But I don't think the document
> should wait on that.
>
>
>
>> On 07/03/18 20:47, Justin Uberti wrote:
>> > To be clear, the MUST does not say that all interfaces MUST be used if
>> > consent is given, rather the converse, that you MUST only use all
>> > interfaces if there is consent.
>>
>> It's unclear to me that there's any practical difference there.
>> Are there any implementations that do something else? (Apologies
>> if that's clear to everyone else:-)
>>
>> > In addition, while gUM consent is given as an example, it is not
>> normative.
>> >
>> >    Mode 1 MUST only be used when user consent has been provided.  The
>> >    details of this consent are left to the implementation; one potential
>> >    mechanism is to tie this consent to getUserMedia consent.
>>
>> Sure. OTOH, IIUC, that is what's done in web browsers so it kind
>> of really is normative, in practice. Again, apologies if there
>> are other things done in browsers.
>>
>> If I recall correctly, it was not made normative because mobile
> applications might use this using advice outside browser contexts.  I can't
> find an immediate citation to that, though, so it may be a convenient
> reconstruction rather than an accurate memory.
>
>
Yes, that was one reason; generally, there was squeamishness around
codifying the exact form consent should take in this sort of document
(i.e., an IETF vs W3C recommendation).