- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 20 Jan 2017 11:52:43 +1100
- To: RFC Errata System <rfc-editor@rfc-editor.org>
- Cc: me@brianchang.info, HTTP working group mailing list <ietf-http-wg@w3.org>
REJECT. See subsequent discussion. > On 9 Feb 2016, at 11:05 am, RFC Errata System <rfc-editor@rfc-editor.org> wrote: > > The following errata report has been submitted for RFC7234, > "Hypertext Transfer Protocol (HTTP/1.1): Caching". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7234&eid=4616 > > -------------------------------------- > Type: Editorial > Reported by: Brian Chang <me@brianchang.info> > > Section: GLOBAL > > Original Text > ------------- > (See Section 3.2 for additional details related to the use of public in > response to a request containing Authorization, and Section 3 for > details of how public affects responses that would normally not be > stored, due to their status codes not being defined as cacheable > by default; see Section 4.2.2.) > > has a status code that is defined as cacheable by default > (see Section 4.2.2), or > > Corrected Text > -------------- > (See Section 3.2 for additional details related to the use of public in > response to a request containing Authorization, and Section 3 for > details of how public affects responses that would normally not be > stored, due to their status codes not being defined as cacheable > by default; see Section 6.1 of [RFC7231].) > > has a status code that is defined as cacheable by default > (see Section 6.1 of [RFC7231]), or > > Notes > ----- > Section 4.2.2 is titled "Calculating Heuristic Freshness" but is referenced in the original text when talking about status codes. This is confusing despite having a reference to Section 6.1 of RFC7231 buried within the text. > > There are other references to 4.2.2 as well, but those actually talk about heuristic freshness. > > 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 (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7234 (draft-ietf-httpbis-p6-cache-26) > -------------------------------------- > Title : Hypertext Transfer Protocol (HTTP/1.1): Caching > Publication Date : June 2014 > Author(s) : R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed. > Category : PROPOSED STANDARD > Source : Hypertext Transfer Protocol Bis APP > Area : Applications > Stream : IETF > Verifying Party : IESG > > -- Mark Nottingham https://www.mnot.net/
Received on Friday, 20 January 2017 00:53:16 UTC