[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] API access and .well-known

Tommy Pauly <[email protected]> wrote:
    > The benefit of this approach (get [API-URL] first, and follow it to
    > [HTML-URL]) is that we pave the way towards more flexibility when we
    > don’t necessarily need the [HTML-URL] to do traditional captive
    > portals, but instead can do interaction models designed for watch-like
    > devices, or multiple devices that don’t ever need a follow-on URL.


    >>> c. find some way to get two URIs, like revising 7710 or finding an
    >>> alternative mechanism (such as the one in RFC 5986)

    > I think that this approach is effectively saying that [API-URL] and
    > [HTML-URL] are both signaled explicitly in the discovery
    > mechanism. While this avoids the problem of ambiguity, it bakes in the
    > notion of a legacy captive portal URL, and takes up more space in the
    > discovery mechanism.

    > I’d vote for some variation on (a), but we can just explain the meaning
    > of the URL we discover more clearly, instead of using a well known
    > URL.

I think that we need the 7710 mechanism to get the HOST part, and that the
URL part SHOULD be .well-known/blah, but MAY be something else.

Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

Attachment: signature.asc
Description: PGP signature