Re: [Captive-portals] Remediation url for CAPPORT

Heng Liu <> Mon, 13 January 2020 23:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD1E1120128 for <>; Mon, 13 Jan 2020 15:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vVmd35C-GU9A for <>; Mon, 13 Jan 2020 15:26:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B75831200E3 for <>; Mon, 13 Jan 2020 15:26:33 -0800 (PST)
Received: by with SMTP id c7so4071530uaf.5 for <>; Mon, 13 Jan 2020 15:26:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zf2k8EO9z1Rp0DdKlZOX0lwN8/ro4cmT+F1vXVnP3BA=; b=FZpbNdjYy4bqD69p1G/QadAzLo6H1ffqfOvXJU9x2T8ojXYb4AEVIXSvOTyYqUGTke R6Xn6wcqrc+o8aubeM9T/MV/qowYGuA9en/2Kaza+YlmHVevcj1urS0CHSu14RpSMkw6 P63laSfeAEObsWjzG+Bz5MqAgw48EZXM6j2gXZf9rn22o1bXmhObfbAAzdIXs9F9tZB5 YmEpMUwPH0vwa30Ytc54ZuKvAzYkmvUMzh/PmT/yT0X/j4ZlY4ZXLvf/Tz2+9oefoXII okr3no+uesU71mZX8vTrBOEemgzl5u7zxxs/fbte3YoPTiia7otMUwgzH8dOop9Ow+ct Whxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zf2k8EO9z1Rp0DdKlZOX0lwN8/ro4cmT+F1vXVnP3BA=; b=LRO8DvDdNgSyT6VIFWvM5N15PHDq6QcR/tgsGEjvudN/NlE5H8Eyk5VMh7YM325zYW SHu+ZyU0i0L1+dJs8GmjgDaDq21NmumyVVG+6Rc5C/OLcgri/v8CtQrEAhZSfnYZ3pRf Pg+chpsPXLQRseVKInCKr0M6fIvAX2Iuz/kU4A4j4gu5PWnD+swkMP6fOZvUI/SMuS1D VkmSGBMYQvBoieoBG7Mm7J6R+mIGMeMuTrT2EjYbxheNsIfISkxNvLqHDjfa/fIpt1dJ d2cci5wNbgBNDJcXDX+4UJeaIcLffpku0a2RdeDqi1jQNXN4rApNqT50xcN5PjcODInB xKOw==
X-Gm-Message-State: APjAAAXfRrtb9g4Wrx/uqeAnPz/n+JmjaGWZ9bNftw6LUpOQL7BMLSWd Dwp+L74tEi8+uPk4P/qdYAE4EHK5eZaBTOJx9QkvrA==
X-Google-Smtp-Source: APXvYqyvl4LliwueejWdX2cGe7QNz8Y3Pnjq+fBaVBLUOfWQ2Sq6eTTmE2UqFs/N7cqgE2CxV3qmOLH/PM52kHhcV4s=
X-Received: by 2002:ab0:b94:: with SMTP id c20mr9312827uak.67.1578957991918; Mon, 13 Jan 2020 15:26:31 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Heng Liu <>
Date: Mon, 13 Jan 2020 15:26:20 -0800
Message-ID: <>
To: Erik Kline <>
Cc: Remi NGUYEN VAN <>, captive-portals <>, Heng Liu <>
Content-Type: multipart/alternative; boundary="00000000000039b826059c0dcef8"
Archived-At: <>
Subject: Re: [Captive-portals] Remediation url for CAPPORT
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Jan 2020 23:26:36 -0000

On Sun, Jan 12, 2020 at 2:34 PM Erik Kline <> wrote:

> Why should this different from the user-portal-url?  It seems to me that
> either the user-portal-url would remediation UI elements or it wouldn't.
Some CP vendors want to specify a different URL specifically tailored for
remediation of a session. By providing a 3rd URL, we can accommodate this
use case.

> With this 3rd URL, if the bytes/time does expire should the OS try to
> launch an interaction the remediation URL and then fallback to the user URL
> if it failed to load?  In which case, why not just leave all interaction
> with the user-portal-url?
if a remediation URL is present, and if it fails to load for whatever
reason, no need to fallback to user portal URL: CP vendor should make sure
the remediation URL is working properly (this is similar to user-portal url
should work properly, if not, there is no other way for user to clear a CP)

> If the vendor doesn't implement a means to extend your session without
> completely shutting everything down and forcing to the user to restart the
> interaction flow anew, I could see that an OS would not want to bother the
> user with an interaction where they couldn't actually do anything useful.
> But that might suggest a boolean capability, rather than a new URL
> (remediation-supported={true|false})?
A boolean field could also be a positive signal to notify UE that
remediation is possible, but this would prevent CP vendors from using
different URLs for remediation.

(As mentioned in the initial thread, this URL approach is also taken by the
Passpoint release 2.0 spec to signal remediation process.)