On Thu, Mar 1, 2018 at 10:58 PM, Martin Thomson <[email protected]> wrote:
> We've had a number of discussions in the captive portals group about > fixing RFC 7710. > Fixing or make RFC7710 more useful ? > > Erik and I would like to propose a plan for that work. We would keep > this to addressing the issues that we have identified thus far. > Namely: > > 1. The purpose of the URI is not well defined. We would reference the > capport architecture and API documents for that. The group would need > to decide between: > a. point to the API > b. point to a login page > > Our (or at least my thought) was in the beginning, just send the device to the location of the portal, as I hate having connections intercepted. Then the USER could just see that page and decide what to do. Now you are taking that basic idea forward to allow a handshake between device and portal ; this is good Happy to help with that anything that allows [semi/fully]-automated sign-on is great. 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. > > This seems to be a standard problem in DHCP i.e. there is no way to issue a denial or list available options > 3. RFC 7710 states that the URL SHOULD use an address literal. This > works at odds with the idea of using HTTPS. If there is a better way then this is the reason to do an RFC7710-bis, the items above only need to CITE RFC7711, and there could be more than one API proposed/documented. > > Is there anyone who is willing to take on this work? We aim to start > and complete this work in <1 meeting cycle, starting in London. > > This is a great goal, willing to review > For the authors of RFC 7710, let us know if you have any concerns. > not really, thanks for pushing the idea forward. Olafur
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
