Re: [Captive-portals] Fixing RFC 7710

I always assumed the captive portal URL could function as the API
endpoint as well. For example, if the captive portal url is
'https://mycaptiveportal.com/index.html' then the API could port to
the same URL at index.html. Another solution could take the root part
of the URL and then attach the known URI at the end.

I believe a URL should be transported in the DHCP / RA as it needs to
support HTTPS.  There are work arounds with doing 302s but it then
becomes more steps to develop. I think RFC7710 is easy to implement
for most venders in their DHCP software.  Because of that, it acts as
a stepping stone into further enhancements.

>From an implementation point of view, nothing needs to change the
captive portal to support the DHCP / RA option which really make it
easy to enable.

On Thu, Mar 1, 2018 at 10:58 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> We've had a number of discussions in the captive portals group about
> fixing RFC 7710.
>
> 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
>
> 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.
>
> 3. RFC 7710 states that the URL SHOULD use an address literal.  This
> works at odds with the idea of using HTTPS.
>
> 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.
>
> For the authors of RFC 7710, let us know if you have any concerns.
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

-- 
Alexander Roscoe
484-716-9048