[Captive-portals] [Errata Verified] RFC8910 (6620)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 24 June 2021 06:32 UTC

To: rfcerrata8910@vittgam.net, warren@kumari.net, ek@loon.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: ek.ietf@gmail.com, iesg@ietf.org, captive-portals@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20210624063209.EF5E9F40722@rfc-editor.org>
Date: Wed, 23 Jun 2021 23:32:09 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/OIF2JghZaOtRNzy8lA4yqjnECT8>
Subject: [Captive-portals] [Errata Verified] RFC8910 (6620)
Precedence: list

The following errata report has been verified for RFC8910,
"Captive-Portal Identification in DHCP and Router Advertisements (RAs)". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6620

--------------------------------------
Status: Verified
Type: Technical

Reported by: Vittorio Gambaletta (VittGam) <rfcerrata8910@vittgam.net>
Date Reported: 2021-06-23
Verified by: Erik Kline (IESG)

Section: 2

Original Text
-------------
   A captive portal MAY do content negotiation (Section 3.4 of
   [RFC7231]) 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 field as described in Section 5.3 of
   [RFC7231]).  In so doing, the captive portal SHOULD redirect the
   client to the value associated with the "user-portal-url" API key.
   When performing such content negotiation (Section 3.4 of [RFC7231]),
   implementors of captive portals need to keep in mind that such
   responses might be cached, and therefore SHOULD include an
   appropriate Vary header field (Section 7.1.4 of [RFC7231]) or set the
   Cache-Control header field in any responses to "private" or a more
   restrictive value such as "no-store" (Section 5.2.2.3 of [RFC7234]).

Corrected Text
--------------
   A captive portal MAY do content negotiation (Section 3.4 of
   [RFC7231]) and attempt to redirect clients querying without an
   explicit indication of support for the captive portal API content
   type (i.e., without application/captive+json listed explicitly
   anywhere within an Accept header field as described in Section 5.3 of
   [RFC7231]).  In so doing, the captive portal SHOULD redirect the
   client to the value associated with the "user-portal-url" API key.
   When performing such content negotiation (Section 3.4 of [RFC7231]),
   implementors of captive portals need to keep in mind that such
   responses might be cached, and therefore SHOULD include an
   appropriate Vary header field (Section 7.1.4 of [RFC7231]) or set the
   Cache-Control header field in any responses to "private" or a more
   restrictive value such as "no-store" (Section 5.2.2.3 of [RFC7234]).

Notes
-----
In RFC8908 the relevant Content-Type is defined as "application/captive+json" and not "application/capport+json".

--------------------------------------
RFC8910 (draft-ietf-capport-rfc7710bis-10)
--------------------------------------
Title               : Captive-Portal Identification in DHCP and Router Advertisements (RAs)
Publication Date    : September 2020
Author(s)           : W. Kumari, E. Kline
Category            : PROPOSED STANDARD
Source              : Captive Portal Interaction
Area                : Applications and Real-Time
Stream              : IETF
Verifying Party     : IESG

[Captive-portals] [Errata Verified] RFC8910 (6620) RFC Errata System