Not really a CAPPORT protocol problem... but... Tommy Pauly <[email protected]> wrote: > One point I wanted to clarify: the iOS and macOS betas support for > CAPPORT discovery and APIs still goes through the standard and existing > UI flow for captive portals. The times in which the captive portal UI > is shown is limited, for example to times when the user is in WiFi > settings.
Is there a simple way for the user to get back to the portal page from the
notification bar? Can the user choose to keep it open longer?
I noticed on the Thalys train that if you closed the portal page that it
tended to kick you off the network. That is definitely an anti-pattern!!!
I don't know how we will cope with it, while at the same time, making it
clear that it's a bad design.
Worse was that the portal page had a nice tiled map with the current
location... AND THE TILES WERE NOT LOCAL. So as more and more people learnt
to keep the page open... the network got significantly slower.
> Thus, while adoption should indeed be easy and only require
> adding a small bit of infrastructure in order to provide a flow that
> doesn’t require redirects, the set of circumstances in which a network
> can display content to the user is not increased.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
