Not really a CAPPORT protocol problem... but...
Tommy Pauly <tpauly=40apple....@dmarc.ietf.org> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
