[Captive-portals] [Technical Errata Reported] RFC8910 (6620)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 23 June 2021 13:49 UTC

To: warren@kumari.net, ek@loon.com, superuser@gmail.com, francesca.palombini@ericsson.com, ek.ietf@gmail.com, mt@lowentropy.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: rfcerrata8910@vittgam.net, captive-portals@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20210623134917.753AAF40772@rfc-editor.org>
Date: Wed, 23 Jun 2021 06:49:17 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/JjbtL37qNkCPuaipm6wL-76NnDk>
Subject: [Captive-portals] [Technical Errata Reported] RFC8910 (6620)
Precedence: list

The following errata report has been submitted 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

--------------------------------------
Type: Technical
Reported by: Vittorio Gambaletta (VittGam) <rfcerrata8910@vittgam.net>

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".

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
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] [Technical Errata Reported] RFC… RFC Errata System
Re: [Captive-portals] [Technical Errata Reported]… Michael Richardson
Re: [Captive-portals] [Technical Errata Reported]… Tommy Pauly