Subject: [Editorial Errata Reported] RFC7231 (6814)

From: RFC Errata System <[email-masked]>
Date: Sun, 9 Jan 2022 23:03:42 -0800 (PST)

The following errata report has been submitted for RFC7231,
"Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".

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

--------------------------------------
Type: Editorial
Reported by: jk <[email-masked]>

Section: Table of Contents

Original Text
-------------
noneed

Corrected Text
--------------
noneed

Notes
-----
There is no hyper link to section 7.1.1 in Contents.

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. 

--------------------------------------
RFC7231 (draft-ietf-httpbis-p2-semantics-26)
--------------------------------------
Title               : Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Publication Date    : June 2014
Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
Category            : PROPOSED STANDARD
Source              : Hypertext Transfer Protocol Bis APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Jan 2022 09:17:15 +0100

Am 10.01.2022 um 08:03 schrieb RFC Errata System:
> ...

The actual problem is that the ToC in the source file is mangled:

>    7. Response Header Fields .........................................64
>       7.1. Control Data ..............................................64
> ed            7.1.1. Origination Date ...................................65
>            7.1.2. Location ...........................................68

I don't think thatb was the case when RFC 7231 was published, but I
can't prove that right now.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Jan 2022 10:47:30 +0100

> can't prove that right now.

Ok, trust in immutabililty restored...:

https://web.archive.org/web/20140614032649/https://www.rfc-editor.org/rfc/rfc7231.txt

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Jan 2022 13:17:29 +0100

As another weak piece of evidence,

Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-announce/EhxcgsgikJo2BDFRbvVjBWshXPY

said on 2014-06-07:

Characters: 235053

And that is the size of the file

http://www.rfc-editor.org/rfc/rfc7231.txt

up to today:

$ curl -sI https://www.rfc-editor.org/rfc/rfc7231.txt | grep ent-Le
Content-Length: 235053

Phew.

Grüße, Carsten

> On 2022-01-10, at 10:47, Julian Reschke <[email-masked]> wrote:
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 10 Jan 2022 12:27:06 +0000

--------

> Instructions:

FWIW:

I have a .txt downloaded June 7th 2014 where the TOC looks slightly weird there:

    |   7. Response Header Fields .........................................64|
    |      7.1. Control Data ..............................................64|
    |ed            7.1.1. Origination Date ...................................65|
    |           7.1.2. Location ...........................................68|
    |           7.1.3. Retry-After ........................................69|

(I added '|' chars added to mark begin and end of line)

The relevant bit in hexdump:

    000026f0  2e 2e 2e 2e 2e 2e 2e 2e  2e 36 34 0a 20 20 20 20  |.........64.    |
    00002700  20 20 37 2e 31 2e 20 43  6f 6e 74 72 6f 6c 20 44  |  7.1. Control D|
    00002710  61 74 61 20 2e 2e 2e 2e  2e 2e 2e 2e 2e 2e 2e 2e  |ata ............|
    00002720  2e 2e 2e 2e 2e 2e 2e 2e  2e 2e 2e 2e 2e 2e 2e 2e  |................|
    00002730  2e 2e 2e 2e 2e 2e 2e 2e  2e 2e 2e 2e 2e 2e 2e 2e  |................|
    00002740  2e 2e 36 34 0a 65 64 20  20 20 20 20 20 20 20 20  |..64.ed         |
    00002750  20 20 20 37 2e 31 2e 31  2e 20 4f 72 69 67 69 6e  |   7.1.1. Origin|
    00002760  61 74 69 6f 6e 20 44 61  74 65 20 2e 2e 2e 2e 2e  |ation Date .....|
    00002770  2e 2e 2e 2e 2e 2e 2e 2e  2e 2e 2e 2e 2e 2e 2e 2e  |................|
    00002780  2e 2e 2e 2e 2e 2e 2e 2e  2e 2e 2e 2e 2e 2e 36 35  |..............65|
    00002790  0a 20 20 20 20 20 20 20  20 20 20 20 37 2e 31 2e  |.           7.1.|
    000027a0  32 2e 20 4c 6f 63 61 74  69 6f 6e 20 2e 2e 2e 2e  |2. Location ....|

I also have a rfc7231.xml downloaded December 8th 2016, but I dont know what to look for in it...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Jan 2022 13:41:35 +0100

Am 10.01.2022 um 13:38 schrieb jk:
> 
> That's my fault, should be html version rather than text version, just 
> look the picture above.
> ...

For RFCs from that time, the HTML version has no official standing. It 
is autogenerated from the plain text RFC, and that one indeed has 
garbage characters in the ToC.

Best regards, Julian

-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Jan 2022 13:40:23 +0100

> I also have a rfc7231.xml downloaded December 8th 2016, but I dont know what to look for in it...

The bug was introduced by the RFC Editor *after* converting the XML; 
thus there's nothing to look for in the XML.

Best regards, Julian

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 11 Jan 2022 09:33:47 +1100

Whatever sleuthing we do here, this error has been noted already:

https://www.rfc-editor.org/errata/eid4072

Can we just reject this erratum?

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Jan 2022 10:21:05 +0100

> Can we just reject this erratum?

Yes.

(Good catch!)

Best regards, Julian