[ietf-822] (no subject)

[Peter Occil <[e-mail]>]

>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 for
everyone in the world to update their software to remove spaces when parsing List-x
headers.
>
> Plan B: figure out how to make your URLs short enough that your List-Unsubscribe
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 either—

- reject the user-provided value (even though it’s otherwise syntactically valid – note that RFC 2369 neither specifies nor mandates a character limit), or 
- 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.

--Peter