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
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822