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 expired, or not visited because the time-on-network has not yet expired. The CP may have abandoned that client, figuring it went away permanently when it disconnected from WiFi.
-d > On Jan 13, 2020, at 5:02 PM, 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 >> <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
