RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 8058, "Signaling One-Click Functionality for List Email Headers", January 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5559
Status: Verified
Type: Editorial

Reported By: Etan Wexler
Date Reported: 2018-11-22
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-26

Section 8.3 says:

   Header in Email

   List-Unsubscribe:
       <mailto:listrequest@example.com?subject=unsubscribe>,
       <https://example.com/unsubscribe.html/opaque123456789>
   List-Unsubscribe-Post: List-Unsubscribe=One-Click


   Resulting POST request

   POST /unsubscribe.html/opaque=123456789 HTTP/1.1
                                ^

It should say:

   Header in Email

   List-Unsubscribe:
       <mailto:listrequest@example.com?subject=unsubscribe>,
       <https://example.com/unsubscribe.html/opaque123456789>
   List-Unsubscribe-Post: List-Unsubscribe=One-Click


   Resulting POST request

   POST /unsubscribe.html/opaque123456789 HTTP/1.1

Notes:

The extraneous equality sign (“=”) between “opaque” and “123456789” appears in the target of the HTTP message but not in the “https” URI in the “List-Unsubscribe” field of the mail snippet.

Status: Reported (1)

RFC 8058, "Signaling One-Click Functionality for List Email Headers", January 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5117
Status: Reported
Type: Technical

Reported By: Gerald W. Lester
Date Reported: 2017-09-15

Section 8.3 says:

Content-Type: multipart/form-data; boundary=---FormBoundaryjWmhtjORrn

It should say:

Content-Type: multipart/form-data; boundary=-FormBoundaryjWmhtjORrn 

Status: Rejected (1)

RFC 8058, "Signaling One-Click Functionality for List Email Headers", January 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5558
Status: Rejected
Type: Editorial

Reported By: Etan Wexler
Date Reported: 2018-11-22
Rejected by: Alexey Melnikov
Date Rejected: 2018-11-26

Section 8.3 says:

Content-Length: 124

It should say:

Content-Length: 126

Notes:

The entity body of the message should have the sequence of carriage return and line feed after the final boundary marker. The inclusion of these two control codes would bring the count of octets of bits to 126, not 124. Given that the sequence of carriage return and line feed should have no associated glyphs, no change is needed at the end of the example.
--VERIFIER NOTES--
John R Levine wrote:

I believe this one is wrong and 124 is the correct length. It would be
126 if you put a \r\n after the -- at the end of the last MIME separator.
If the problem were that we'd left out the carriage returns, there are
four lines so the (wrong) length would have been 120.

Report New Errata