On Sat, Jun 6, 2020 at 7:54 PM Martin Duke <martin.h.d...@gmail.com> 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.
Tommy is correct. I think the architecture document should add a qualifying subclause to clarify that requirement (2) only applies "if captive portal enforcement may be active on the given network" or something. The model supports, for example, the very experiment we ran on the IETF 106 network [106EXP]. In that experiment we handed out an API URI via 7710/7710bis mechanisms to an API that told the client it was /not/ captive but that a venue-info-url was available (which led to a service that redirected clients to the agenda page, IIRC). [106EXP] https://tickets.meeting.ietf.org/wiki/CAPPORT _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
