I mean from the point of view of a software developer creating a library to
generate email messages. This software developer is not the one who comes up
with values for header fields (such as URLs for List-Unsubscribe header
fields). If the developer's software library is passed a List-Unsubscribe
header field value greater than 998 characters in length (e.g., when a
third-party user uses that library to generate a blank message, then to set the
List-Unsubscribe header field to such a value, then to generate a finished
message), the software developer would then have to make a choice whether to
program that library--
- to reject the user-provided value,
- to accept the value and later be required to generate a message with a line
exceeding 998 characters or to fold lines to fit that character limit, or
- to take some other error-handling action.
--Peter Occil
From: John Levine
Sent: Tuesday, July 24, 2018 12:13 AM
To: ietf-822(_at_)ietf(_dot_)org
Cc: poccil14(_at_)gmail(_dot_)com
Subject: Re: [ietf-822] (no subject)
In article
<5b56a4ba(_dot_)1c69fb81(_dot_)836c0(_dot_)d955(_at_)mx(_dot_)google(_dot_)com>
you write:
Plan B: figure out how to make your URLs short enough that your
List-Unsubscribe
headers are under 998 characters. ...
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. ....
You lost me here. Is there some force that requires you to pass giant
URLs to List-Unsubscribe? If you want to interoperate, use reasonably
short URLs. This should not be rocket science.
R's,
John
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822