IETF Logo Mail Archive

Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

Martin Thomson <mt@lowentropy.net> Tue, 09 June 2020 01:17 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50F63A08CC; Mon, 8 Jun 2020 18:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=h94PhRiC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=u/W4URvh
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 K_SmgNf4ELAv; Mon, 8 Jun 2020 18:17:47 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874CF3A08CB; Mon, 8 Jun 2020 18:17:47 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 503C95CA; Mon, 8 Jun 2020 21:17:46 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 08 Jun 2020 21:17:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm2; bh=3J i0c6GmMA/fHgfjY5lr2WIZEAJi2tHx9WZxU1EKFyw=; b=h94PhRiCUM+hImaaFw TuGHlMo5JTqijAZxJXxXUDOeEcvNatm+EG+18mtSdLylquTqxvQx2ghTRe9yQ+yN kFJN0a0RiGEM3nQUMp4s/4Pk6GyNvlQkp0dVyt8Wo7zw/uo2tBe/HwmeFkf6WNeQ HRs5gG8H+mCC5v//21q+QBWUulm8XjBmGDoanklUmifsGJNI+FM7UelvBsP9/nNz 2fP5G5h/Zar7Vp/VoBqVz9jIvsIgzEojY8mjall/aa253YNE+tZle/vso7HdjCAG H5oT36fO22RflGLYzed6zC1e21TkcmczUK6uDQl7sGedT8U0NcWrkwb35rc5J0xD 1Wmg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=3Ji0c6GmMA/fHgfjY5lr2WIZEAJi2tHx9WZxU1EKF yw=; b=u/W4URvhDbIrY5pGn90xQQuMzSDXe77npbx6Fn4fq1zFv1k0uz9QzMnSG 2OHjydd2Ffl1J0RuHkLwzH6bYoreqkaBd0nOu9oMWFYEOblTH327f+OUAu8MNHAM h5oaOElWyfbo8RyGDxqfapLPdaP5mSe96JWj0lkhhlZaHnH+IBxKZ/yP53tqMkeo X1xD5m6ojPC2200d9wKavFms2WAHVEyPqiVNfo8GIixnWMNbBejcMKRrHENV99+E ru92htRFAl0FB1s53n/nMtTEELrdK8k/Hy/P0kidFjaYnojrlL9H4fDGzIHJxlV1 EU7k0lLbSGcEaCp6A7sPQKnIQs/og==
X-ME-Sender: <xms:OePeXqbSFeBEqSJVQaK-D0v9rNLhAsPeqElqS8WrVZBY4UuBpe9-oA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehfedggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ggtffrrghtthgvrhhnpefgjeeuudeiffeltdegleehjedvtedtjeduudehgfegfefgkefg ueeiteegffdttdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:OePeXtbwiXHviUD75d2SVwMjOlWGM5VAn0xLVTL7hVaCeGFTdOH0bQ> <xmx:OePeXk8nxNYUEqekLc4d0FjlyyBhAN9VS9Nws4kRfhRaFOMsv1I47w> <xmx:OePeXsoijbCRV-OWzOk-If0U28I6Xo3sdOS_sld-Zw9UPOppDNMx1A> <xmx:OePeXs0ObEPAckniLD5IAl1Oq8THejGbskhAvWMiUuSNMxn3Y9qr6A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9AF50E00BB; Mon, 8 Jun 2020 21:17:45 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6
Mime-Version: 1.0
Message-Id: <aca63ad2-aef4-423a-af45-a44c70b100af@www.fastmail.com>
In-Reply-To: <CAM4esxQ=6435NCjtxSa83VZEqj8O4wY9o-dcrpSnOmO3-egxNA@mail.gmail.com>
References: <159148015875.11480.2779938750447142779@ietfa.amsl.com> <387D0387-4CAC-4168-8F72-9D180078D67C@apple.com> <CAM4esxQ=6435NCjtxSa83VZEqj8O4wY9o-dcrpSnOmO3-egxNA@mail.gmail.com>
Date: Tue, 09 Jun 2020 11:17:29 +1000
From: Martin Thomson <mt@lowentropy.net>
To: Martin Duke <martin.h.duke@gmail.com>, Tommy Pauly <tpauly@apple.com>
Cc: The IESG <iesg@ietf.org>, capport-chairs@ietf.org, captive-portals@ietf.org, draft-ietf-capport-api@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/_2O1X8SbaUqleGlE8z47ZyOJ-Qo>
Subject: Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2020 01:17:49 -0000


On Sun, Jun 7, 2020, at 12:53, Martin Duke wrote:
> 
> 
> On Sat, Jun 6, 2020 at 4:52 PM Tommy Pauly <tpauly@apple.com> wrote:
> > 
> > 
> >  I believe in this case the architecture document needs to change, or clarify that this MUST refers to that the mechanism needs to be *able* to communicate such a URI, not that such a URI must always be communicated.
> > 
> >  The group has discussed this several times, and I believe the API doc reflects the consensus: while we aren’t tackling solutions for captive portals that don’t involve User Portal pages (future solutions using a more OS-driven experience and perhaps built in payment, etc), we want to allow the API JSON to be usable in those new models. Not all captive networks will necessarily use this kind of URI in the future, and there’s no need to make the registry lock that in as mandatory. 
> 
> Very well, I’d like to hear from one of the chairs, but if confirmed 
> I’m happy to move my DISCUSS to -architecture.

I can confirm that Tommy's recollection is correct.  There are cases where captivity is not negotiable - well at least not using a web browser.  I think that we just didn't capture this very well in the architecture doc.

v2.23.0 | Report a Bug | By Email