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.
+1
>>> 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