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) <rfcerrata8...@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 mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
