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
