On Sun, Jun 7, 2020, at 12:53, Martin Duke wrote: > > > On Sat, Jun 6, 2020 at 4:52 PM Tommy Pauly <tpa...@apple.com> wrote: > > > > > > I believe in this case the architecture document needs to change, or > > clarify that this MUST refers to that the mechanism needs to be *able* to > > communicate such a URI, not that such a URI must always be communicated. > > > > The group has discussed this several times, and I believe the API doc > > reflects the consensus: while we aren’t tackling solutions for captive > > portals that don’t involve User Portal pages (future solutions using a more > > OS-driven experience and perhaps built in payment, etc), we want to allow > > the API JSON to be usable in those new models. Not all captive networks > > will necessarily use this kind of URI in the future, and there’s no need to > > make the registry lock that in as mandatory. > > Very well, I’d like to hear from one of the chairs, but if confirmed > I’m happy to move my DISCUSS to -architecture.
I can confirm that Tommy's recollection is correct. There are cases where captivity is not negotiable - well at least not using a web browser. I think that we just didn't capture this very well in the architecture doc. _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
