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

From: RFC Errata System <[email-masked]>
Date: Wed, 23 Jun 2021 06:49:17 -0700 (PDT)

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) <[email-masked]>

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Jun 2021 11:42:36 -0400

RFC Errata System <[email-masked]> wrote:
    > -----
    > In RFC8908 the relevant Content-Type is defined as
    > "application/captive+json" and not "application/capport+json".

Wow, thank god for the summary, and even with it, I had to read four times to
really see the difference!

Sounds legit, and a great way to show off the XML patcher!

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 23 Jun 2021 20:45:33 -0700

> On Jun 23, 2021, at 8:42 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

Yes, a definitely good fix to make. Let’s approve it.
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals