Charles Lindsey wrote:
In <3E172358(_dot_)6020404(_at_)alex(_dot_)blilly(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
It is insufficient to say "comply with 2822 / 2047 / 2231); there is
a design defect which prevents that, unless a specific mechanism is
provided to ensure compliance. As it stands,
1. it is impossible for a gateway to determine the syntax of an
experimental header which the gateway author is unaware of
2. Without header field syntax information, it is impossible to
encode non-ASCII "header" content.
Yes, there is certainly a design defect, which accounts for why so many
implementations have chosen to fudge their RFC 2047 handling in so many
ways.
The design defect is in the Usefor draft proposal, which requires
gateways to perform processing which in turn requires header field
syntax to be known, but which is *not* known in all cases, and cannot
be known in advance in the case of experimental header fields.
The design defect can be eliminated by:
You cannot eliminate a desgin defect, but you can maybe work around it:
Since the aforementioned defect does not exist in mail or in the current
Usenet standard (RFC 1036), but only in the paper design in the Usefor
draft, it can be eliminated by correcting the defective design in that
draft.
a. forbidding non-ASCII content in all but a well-defined set which
all gateways are required to recognize, *and* providing a practical
transition plan so that existing gateways can be upgraded while
ensuring that the mail protocols are not violated
Which is what Usefor is trying to do. But Usefor cannot prevent future
extensions to itself from adding to the set. So you still need a fudge.
I see no evidence of a practical transistion plan in the draft; in fact
it is clear from the draft and from discussion in the Usefor mailing list
that there essentially is no transition plan. And rather than restricting
non-ASCII content to a set of well-defined Usenet-specific headers, the
draft instead seeks to introduce non-ASCII content into existing headers
which have always forbidden such content.
or
b. simply using the RFC 822 / 2822 / 2047 / 2231 Internet text message
format, which avoids the encoding problem in gateways and adds no
new restrictions on gateway transformations (thereby obviating that
aspect of a transition plan).
Yes, but Usefor has chosen a different route.
And therein lies the defect.
or
c. require that unrecognized "headers" with non-ASCII content be elided
or moved to an encoded attachment.
And of your various suggestions, that is the one which deserves serious
consideration. It was #3 in my list IIRC. The question to address is
whether it will do more, or less, harm than my workaround proposal. It is
not clear.
Your "workaround proposal", as you now call it, simply won't work because
it requires header syntax to be known in advance for all Usefor "header"
fields which might contain non-ASCII content, including experimental ones,
and that can only be achieved by one of the above three methods, not by
your "proposed workaround". Of the three, "b" is the cleanest approach,
which is fully compatible with existing gateways and with the existing
standard, does not present difficulties w.r.t. IETF standardization, and
has been strongly recommended, independedntly, by several respondents in
this thread.