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