I've put up a PR for the "can-extend-session" proposal here:
https://github.com/capport-wg/api/pull/32
Please take a look and make suggestions for changes!
Best,
Tommy
> On Jan 19, 2020, at 9:05 PM, Tommy Pauly <tpauly=40apple....@dmarc.ietf.org>
> wrote:
>
> 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 URL, it could
> simply redirect the user portal URL whenever the user is logged in.
>
> If we have three URLs, then we’d have two URLs, the User Portal the new
> Extend URL, that would each only be useful at certain mutually exclusive
> times: one before log in and one while logged in. That seems like an easy
> opportunity to encourage portal designers to have a single page, so we don’t
> have a UI in android or iOS that ever presents a link that takes you to a
> useless “you’re logged in” page.
>
> I’m all for having the venue URL be distinct, but let’s just use a Boolean to
> indicate if the user portal URL is a useful URL while logged in or not.
>
> Tommy
>
>> On Jan 19, 2020, at 8:50 PM, Lorenzo Colitti <lore...@google.com> wrote:
>>
>> I do think something is needed here because we don't want the device
>> to put up a "you're running out of time, please click here to extend"
>> prompt/notification, if tapping that prompt goes to a page that just
>> says "you're logged in" without allowing the user to extend. If the
>> network doesn't support extending sessions, then the device should not
>> display the prompt. So we should give the network a way to express via
>> the API whether it's possible to extend the user's time or not.
>>
>> Once we do decide to have something like that in the API, ISTM that a
>> separate URL is more useful than just a boolean. Whether the URL is
>> present or not gives you the boolean; the content of the URL makes it
>> easier for network operators because it means they can provide a
>> specific "manage my connection" page that is different from the login
>> page. The operator could of course decide what to display based on the
>> login state of the user; this just makes it easier.
>>
>> But as long as this is not the same as the venue URL, that works for
>> me. We do want it to be separate, because we expect most operators
>> will primarily want to surface the venue URL, and we don't want them
>> to have to make a choice between surfacing the venue URL and making
>> the session easy to extend.
>>
>> Cheers,
>> Lorenzo
>>
>>> On Fri, Jan 17, 2020 at 4:25 PM Remi NGUYEN VAN
>>> <reminv=40google....@dmarc.ietf.org> wrote:
>>>
>>> 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 support an optional
>>> "remediation-supported" boolean, and only prompt users to extend their
>>> session shortly before it expires when it is set to true. Hopefully the
>>> boolean can be added to the current draft or in a future, separate draft
>>> considering that we seem to roughly agree on it, but if the group
>>> eventually realizes that it wants to go in another direction, we'll update
>>> behavior in subsequent releases.
>>>
>>> Does that make sense ?
>>>
>>> Cheers,
>>>
>>> Remi
>>>
>>>> On Wed, Jan 15, 2020 at 9:30 AM Erik Kline <e...@loon.com> wrote:
>>>>
>>>> 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 specific word carries the
>>>> connotation of "fixing an error" or "correcting damage" and it seems like
>>>> the use here would be broader. But perhaps I'm completely mistaken.
>>>>
>>>> On Tue, 14 Jan 2020 at 16:21, Heng Liu <liucou...@google.com> wrote:
>>>>>
>>>>> It seems most are comfortable with adding a remediation-capable boolean,
>>>>> which is simpler than another url while also making it explicit on
>>>>> whether remediation is provided or not, so UE could display different
>>>>> notifications.
>>>>>
>>>>> Anyone have any objections on adding this boolean please?
>>>>>
>>>>> If not, what's the next step on moving this forward please?
>>>>>
>>>>> Thanks,
>>>>> Heng
>>>>>
>>>>> On Tue, Jan 14, 2020 at 12:38 PM Tommy Pauly <tpa...@apple.com> wrote:
>>>>>>
>>>>>> Any captive portal that is newly adopting the CAPPORT API will hopefully
>>>>>> be testing the setup in the new model, and will have to think about
>>>>>> which URLs to map to different user experiences.
>>>>>>
>>>>>> A page that only says "you're logged in!", and has no way of adding more
>>>>>> time, etc, is in my opinion a relatively useless page. If we provide a
>>>>>> separate URL for remediation, it would seem to encourage such a design.
>>>>>> Not including this would hopefully urge the portal design to a cleaner
>>>>>> model.
>>>>>>
>>>>>> I do think the boolean is nice for highlighting to the captive portal
>>>>>> deployer that they should think about remediation. I'd be more ok with
>>>>>> that model, although it could also be an extension as we gain experience
>>>>>> in deployment.
>>>>>>
>>>>>> Thanks,
>>>>>> Tommy
>>>>>>
>>>>>> On Jan 13, 2020, at 6:00 PM, Remi NGUYEN VAN
>>>>>> <reminv=40google....@dmarc.ietf.org> wrote:
>>>>>>
>>>>>> If we show prompts to the user shortly before the session expires, we'd
>>>>>> like to make sure that we can redirect them to some page where they can
>>>>>> fix the problem, instead of landing on a page saying "you're logged in".
>>>>>> The user-portal-url would work fine with a remediation-supported boolean
>>>>>> for that purpose; having a separate URL gives additional flexibility to
>>>>>> the access point operator, but from the point of view of the client I
>>>>>> think both are fine.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Remi
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 14, 2020 at 10:02 AM Tommy Pauly
>>>>>> <tpauly=40apple....@dmarc.ietf.org> wrote:
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Particularly, if we start seeing the "venue URL" be the main landing
>>>>>>> page we redirect people to once they're logged it, it kind of makes
>>>>>>> sense to let the user portal be the status/remediation/payment page.
>>>>>>>
>>>>>>> Tommy
>>>>>>>
>>>>>>> On Jan 13, 2020, at 4:06 PM, Erik Kline <e...@loon.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 13 Jan 2020 at 15:26, Heng Liu
>>>>>>> <liucougar=40google....@dmarc.ietf.org> wrote:
>>>>>>>>
>>>>>>>> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline <ek.i...@gmail.com> 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..
>>>>>>>
>>>>>>>
>>>>>>> If the remediation URL is available but the user (somehow) navigates to
>>>>>>> the user-portal-url, what do they see?
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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)
>>>>>>>
>>>>>>>
>>>>>>> I guess I'm just trying to be mindful of one person's flexibility is
>>>>>>> another person's complexity.. I think this just doubles the number of
>>>>>>> URLs that the CP vendor needs to make sure function correctly.
>>>>>>>
>>>>>>>>> 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
>>>>>>>> Captive-portals@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Captive-portals mailing list
>>>>>>> Captive-portals@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>>>>>
>>>>>>>
>>>>>>
>>> _______________________________________________
>>> Captive-portals mailing list
>>> Captive-portals@ietf.org
>>> https://www.ietf.org/mailman/listinfo/captive-portals
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
