D. J. Bernstein wrote:
Bruce Lilly writes:
Display (as opposed to generation) does not require information about
header field syntax
False. See RFC 2047, section 6.1. Encoded words can appear as
* substrings (up to 75 bytes) of fields defined as unstructured,
* words inside phrases in fields defined as structured, and
* substrings of comments in fields defined as structured.
It is true (as RFC 2047 states) that encoded-words may appear in
those places and that parsing recognized header fields per RFC 822
rules is necessary to locate those encoded words unambiguously. But
that is only for display -- hardly a critical issue.
False. You are confusing extension fields with user-defined fields; see
RFC 822. Every structured extension field changes the set of locations
where RFC 2047 encoded words can appear.
I assure you *I* am not in the least confused by the distinction. That
some may be confused is another matter; e.g. to use the terminology of
your earlier message, if "some nitwit defines and deploys a new header
field", such as "Mail-Followup-To", that would be an extension field
*if and only if standardized in an RFC*, and is clearly not a user-defined
field since user-defined fields are required to begin with "X-".
For purpose of display, it is perfectly acceptable to treat an unrecognized
field as unstructured when looking for encoded-words; the worst that can
happen is the display might show some garbage which was not intended to be
an encoded-word but which matched the syntax for an encoded-word in *text
context. It's also acceptable to simply ignore looking for encoded-words
in unrecognized fields (for purpose of display). The issue is strictly
limited to display. It is also limited to structured fields that might
contain encoded words (structured fields that provide for neither phrase
nor comments cannot contain encoded words). And implementation issues are
strictly limited to user agents.
All of which is entirely different from the unworkable Usefor draft which
as currently worded requires gateways to do the impossible, viz. to construct
correct header fields containing encoded-words for unrecognized header fields
for transmission.