> On Jul 2, 2020, at 11:55 AM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > 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?
One of the goals of having the portal URL be transmitted in the API is to aid ways of getting back to that URL. We don’t have any such way in the beta UI, but such an experience is possibility in the future if networks adopt the API. Thanks, Tommy > > 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 =- > > > _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
