I'm fine with adding the boolean to the main draft. I discussed this a bit with Heng yesterday, and we discussed naming it something like "can-extend-session". Thoughts on that name?
Thanks, Tommy > On Jan 16, 2020, at 11: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 > <mailto: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 > <mailto: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 > <mailto: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 >> <mailto: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 <mailto: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 >>> <mailto:e...@loon.com>> wrote: >>> >>> >>> >>> On Mon, 13 Jan 2020 at 15:26, Heng Liu >>> <liucougar=40google....@dmarc.ietf.org >>> <mailto:40google....@dmarc.ietf.org>> wrote: >>> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline <ek.i...@gmail.com >>> <mailto: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 <mailto:Captive-portals@ietf.org> >>> https://www.ietf.org/mailman/listinfo/captive-portals >>> <https://www.ietf.org/mailman/listinfo/captive-portals> >>> _______________________________________________ >>> Captive-portals mailing list >>> Captive-portals@ietf.org <mailto:Captive-portals@ietf.org> >>> https://www.ietf.org/mailman/listinfo/captive-portals >>> <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
