[Captive-portals] Content Negotiation language

[Mark Nottingham <mnot@mnot.net>]

In <https://tools.ietf.org/html/draft-ekwk-capport-rfc7710bis-02#section-2>:

> A captive portal MAY do content negotiation ([RFC7231] section 3.4) and attempt to redirect clients querying without an explicit indication of support for the captive portal API content type (i.e. without application/ capport+json listed explicitly anywhere within an Accept header vis. [RFC7231] section 5.3). In so doing, the captive portal SHOULD redirect the client to the value associated with the "user-portal- url" API key.

This is confusing, and not quite right on some details. I'd suggest something like:

~~~
A captive portal MAY redirect requests that do not have an Accept header field ([RFC7231] Section 5.3) containing a field item whose content-type is "application/capport+json" to the URL conveyed in the "user-portal-url" API key. When performing such content negotiation ([RFC7231] Section 3.4), captive portals need to keep in mind that such responses might be cached, and therefore SHOULD include an appropriate Vary header field ([RFC7231] Section 7.1.4) or mark them explicitly uncacheable (for example, using Cache-Control: no-store [RFC7234] Section 5.2.2.3).
~~~


--
Mark Nottingham   https://www.mnot.net/