To that point, the remediation URL only works if the client and the CP are in
sync; that is, if the client wondered off to another network for a while (LTE,
because of whatever reason) and then re-connected to WiFi, is the remediation
URL supposed to be visited because the wall-clock time
On Mon, Jan 20, 2020, at 17:54, Michael Richardson wrote:
> There are a number of locations where you get 20 minutes free, and then you
> have to purchase the extension. That doesn't seem to fit into remedial to
> me. (Montreal Airport comes to mind)
>
> I guess such locations have an incentive
Lorenzo, my impression is that the User Portal URL (already distinct from the
Venue URL) should cover that use case; or at least we should encourage it to be
so. Once a user is logged in, the page generally won’t just show a new log in.
If for some reason the renew page needs to be a different
I also thought "remediation-supported" was not ideal but could not come up
with a better name. "can-extend-session" does sound clearer to me.
Cheers,
Remi
On Sat, Jan 18, 2020 at 1:53 AM Tommy Pauly wrote:
> I'm fine with adding the boolean to the main draft. I discussed this a bit
> with
As far as the Android implementation is concerned, I think it would be nice
to have capport API support in the next (android R) version; however due to
deadlines, it's going to be harder for me to change the attributes read
from the API very soon.
Following this discussion my current plan is to
If there's working group consensus to add it to the current API draft then
definitely add it. Otherwise, probably a separate document that would need
a call for wg adoption.
Separately, and hopefully without starting a massive bikeshed, is there a
more apt word than "remediation"? I think this
I have a similar initial reaction to Erik's. Adding another URL that
effectively is just another user portal, but meant to be used at certain times,
adds a lot of complexity. I'm certainly not ruling out adding such a key as
need arises, but I'd hesitate to make it part of the initial set.
On Mon, 13 Jan 2020 at 15:26, Heng Liu 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
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.
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
Hi all,
In some captive portals, it's possible to extend (or remediate) an existing
session without losing connectivity. This use case is covered in the
CAPPORT architecture draft:
4.2. Conditions About to Expire
This section describes a possible work-flow when access is about to
expire.
10 matches
Mail list logo
