> Some observations, and questions for the working group. > > I'm not sure we have enough input on whether 511 is useful or not. There > seemed to be some suggestion > it would help, and some that it wouldn't. Perhaps one question we could ask > is whether it's harmful? And > if we agree it's not harmful, is it worth developing some recommendations for > its use?
I don’t think it’s harmful, and I don’t see why web browsers wouldn’t support it. What has been specified for this status code is basicly the status, and a custom error page with a html variant of a redirect. Web browsers, even if they don’t understand the full detail of the error, they will display the contents of the response. The browser will process the html of this customised error page and do the redirect. But I don’t see this as a holy grail for improving capports (not at all). I see this as a feasible alternative for capport providers that are currently hijacking http traffic. In these implementations, they can “confuse”/“poison” cache and apis. They do this by using redirects or hosting an alternative capport site by hijacking the dns. In these situations, it would improve the experience if they would do a status code 511 and use that to move the user to the capport url. As a recommendation; I would like to discourage any hijacking (http 30x and dns hijacking), but if a capport provider feels this is the way to go, I think we can point them to this ‘friendlier’ method. > As for the ICMP unreachable option, I certainly don't think it would be > harmful (with the extra URL bits > removed for now). Is that something we wish to progress? I think this will be the best way to signal the UE, I am glad David is working on this :-) > Given that we're probably looking at a portal detection method based on > entirely new work, it seems to me > we're free to look at new things like utilizing the PVD detection scheme (DNS > queries for "provisioning > domain names", followed by other interaction still TBD). Have the portal > implementors reviewed this and > given consideration as to whether its useful? (I think of the discovery of > the portal and subsequent interaction > with it as 2 separate processes conducted, obviously, in serial.) I think the multi-hop scenario forces us to think of alternative ways to discover the captive portal url when the UE did not receive it via dhcp. Without an alternative method, the icmp, relying on this url will only have a limited scope where it can be applied. Although this sounds much like an api, I think we should limit the functionality of it to what is required (the captive portal url as being the only identified requirement imo). Gr., Vincent
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
