RFC Errata
Found 3 records.
Status: Verified (1)
RFC 8058, "Signaling One-Click Functionality for List Email Headers", January 2017
Source of RFC: IETF - NON WORKING GROUPArea Assignment: art
Errata ID: 5559
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
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 GROUPArea Assignment: art
Errata ID: 5117
Status: Reported
Type: Technical
Publication Format(s) : TEXT
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 GROUPArea Assignment: art
Errata ID: 5558
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
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.