Warren Kumari <war...@kumari.net> wrote: >> 2. There isn't a clear way to signal that there is no captive portal >> in the network. It has been suggested that we use a special URL - >> e.g., urn:ietf:params:capport:unrestricted. Alternatively, we could >> privilege the empty string, but that doesn't have as clear a signal of >> intent.
> Oooh, I like the special URL idea -- initially the thought was a > combination of: > 1: Until this is ubiquitously deployed (ha!), devices will need to do > CP heuristics, and so will discover the lack of CP through that. > 2: If there is no CP, no-one is likely to include the option. > 3: Since the vast majority of networks don't use CPs, is this an undue > burden on them? In the case where there *was* a captive portal on a network, and now there is not, it might be useful to tell clients that life has changed. The client might prefer to stay on 3G or pick another network rather than try that portal. It might also be meaningful to signal no-captive portal to clients which have previously connected, but will no longer be challenged (ever? until DHCP lease timeout?). For instance, if I whitelist your laptop MAC address in my home. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
Description: PGP signature
_______________________________________________ Captive-portals mailing list Captiveemail@example.com https://www.ietf.org/mailman/listinfo/captive-portals