wkumari / draft-ekwk-capport-rfc7710bis Goto Github PK

Add some text proposing a URL value that can be used to indicate no portal is present.

Suggested IANA request for "urn:ietf:params:capport-unrestricted".

When URIs are learned via multiple means and (heavens forbid) they differ, an order of precedence will be needed.

Suggest the following:

[1] RA (PVD containing RA takes precedence)
[2] (a) DHCPv6, then (b) DHCPv4
[3] Link: relation

As discussed in Montreal, some captive portal deployments are not able to change (or not willing to risk changing) DHCP parameters. For such deployments, a link relation that identifies the API endpoint may be the simplest deployment method.

Add such text and another URL, urn:ietf:params:capport-api, that can be used in an RFC8288 section 3.3 Link relation header.

We should remove the IP address literal recommendation, as it's not very amenable to upgrading the TLS.

Proposal: add text to the effect of captive portals SHOULD use HTTPS URLs with DNS hostnames for which they can correctly serve useful DNS results to clients/UEs.

Add Updates: RFC7710 tag.

It should be possible for @ekline to do this.

EK has text from mnot on content negotiation.

The text should make clear that the RFC URL should be used to reach the capport API.

Additionally, captive portals may do content negotiation, though if the content type is not that specified for the capport JSON API format, initial testing by Martin suggests that current browser behaviour when served with content type "applicaton/capport+json" yields:

"""
sort of OK in Firefox
plain text in Chrome
opens a "save as" dialog in Edge and Internet Exploiter
(I don't have Safari handy, though I probably should)
"""

As such, not doing content negotiation and simply serving the API content as-is may be fine.

This doc still needs a final summary of the differences between itself and 7710.