Re: [Captive-portals] Remediation url for CAPPORT

David Bird <> Mon, 13 January 2020 23:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E53C12006F for <>; Mon, 13 Jan 2020 15:50:09 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N6492TOdy91h for <>; Mon, 13 Jan 2020 15:50:04 -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 E26FE120020 for <>; Mon, 13 Jan 2020 15:50:03 -0800 (PST)
Received: by with SMTP id 59so4083158uap.12 for <>; Mon, 13 Jan 2020 15:50:03 -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=o1q64Xwn3rCwNXpvs7j3dJL3beaiTkiCOkEsNY1/NJ0=; b=AQ8+62QPqwO6f/Bxr+H29B50ldOdviS6W/dyuDCojPf991ocPaxCPNRdlcfNPTo3Rx cKGBUmis9kAi0NCdmo8pBmRw2IuFG9FhGGP4bK1Tuoo7zodmsLmEUg5W7wyT9grUqKvA d+wCTccUkMFk4N9AiLgNgbx75f7cbwHngEfX0wgb0euXryrRf3S3+2pbTXUQLUgddyOC Ayd1aaFgEVSagkqBN3/2OhDE0aVUyVotB1v10jdJyW2iaGO5VUpaR6BDx1FlcaBKmKMJ 2CLdx+d1riPq3DpAnXPO3I2WDa2RkFo9Z10xE5/fEz7XHHJIS3G6biC1fEZJ5jZ6vOQG auiw==
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=o1q64Xwn3rCwNXpvs7j3dJL3beaiTkiCOkEsNY1/NJ0=; b=JbYC519FHipVXvpBBhjB2pl13yxiyV5Sbb/3YTHdOA/VI4RplATTVBvfoIksaMrlVn xdxuHJPGAYRP3skthPdCDLjUrbQwijYV2m1oQzsY6oZU/fX7B+EfTD3yc9GynZOI53+A brwuohiR0lqRBZTW0ZftO3T3BvZ9k31/qDhCIlW5etiKBpJJJdCnmBPA6bAjvP0vQcOo 1THXyfb+bDevCWABtbQn+3IzJm/XeJy5yeY8GqGtb6yOFuBb2T72INpx3MDn8nDvutQO fliUmufA9QWq+cLU1Vz+zQ8xZ2HBRi4F1bUAvVY0yu7Zrf5FxGQt7MDiAJEH7B1wXDeR 1twg==
X-Gm-Message-State: APjAAAUJBoXch9KcaLqQMJfZOg853+U5m+nmPU6xrmnQutvd3rwwv7je IBZsduSHv+STL85jNKaMqoh4hIancwkYa0iGidQOnw==
X-Google-Smtp-Source: APXvYqziORJ097mfBWF4I52PhRGPdE6egrUgfdWUDZ5/6CjftqAxRYM5ngiqlD47BSN6uHCBKBvYoLOwjqT+jHD4Vbs=
X-Received: by 2002:ab0:6258:: with SMTP id p24mr269326uao.24.1578959402112; Mon, 13 Jan 2020 15:50:02 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Bird <>
Date: Mon, 13 Jan 2020 15:49:50 -0800
Message-ID: <>
To: Heng Liu <>
Cc: Erik Kline <>, captive-portals <>, Remi NGUYEN VAN <>
Content-Type: multipart/alternative; boundary="00000000000047aa51059c0e226a"
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:50:09 -0000

I think one difference is that with Passpoint it is the network signaling
the device... not just some API that may or may not really be
integrated with the network policy changes in the network.

I'd be careful allowing hotspot operators a new avenue to prompt the user
for pure "annoyance" purposes -- only for users using a capport device :-)

On Mon, Jan 13, 2020 at 3:26 PM Heng Liu <liucougar=> wrote:

> 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.)
> regards,
> Heng
> _______________________________________________
> Captive-portals mailing list