[Top] [All Lists]

[ietf-822] (no subject)

2018-07-23 23:02:16
Remember that MUST means "do this if you want to interoperate", not "do this 
or die."

Plan A: update RFC 2369 to say MAY add spaces, send out a press release, wait 
everyone in the world to update their software to remove spaces when parsing 

Plan B: figure out how to make your URLs short enough that your 
headers are under 998 characters.

I know what I'd do.

Plan A is not what I suggest at all; I suggest rather that whitespace "SHOULD 
NOT" be generated between the angle brackets (compare with RFC 2557 sec. 4.4, 
which applies to the Content-Location header field, which uses URLs similarly 
to how List-Unsubscribe and certain other list header fields do).

Plan B is only feasible if the same person provides the URL _and_ writes the 
code to generate the List-Unsubscribe header field (or any other list header 
field) for the corresponding message; not so if a software library generates a 
message containing the value of a List-Unsubscribe (or other) header field 
provided by a (third-party) user that, while otherwise syntactically valid, 
could exceed 998 characters in length.  The software library would then have to 

- reject the user-provided value (even though it’s otherwise syntactically 
valid – note that RFC 2369 neither specifies nor mandates a character limit), 
- be forced to generate a message with a line exceeding 998 characters or to 
fold lines to fit that character limit, or
- take some other error-handling action.

ietf-822 mailing list
<Prev in Thread] Current Thread [Next in Thread>