Charles Lindsey wrote:
In <3E1F1926(_dot_)2050203(_at_)Sonietta(_dot_)blilly(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
Charles Lindsey wrote:
The problem is not so much with software that decodes RFC 2047 (though
even that gets it wrong sometimes), as with software that encodes it in
the first place and which gets stuck as soon as it encounters a header
that it does not know how to parse.
An entity (software or human) must have syntax information in order to
correctly generate *any* header with *any* content (including RFC 2047
encoded-words). Your sentence quoted directly above therefore makes no
sense -- an entity cannot generate a header with unknown syntax.
A human can quite well generate such a header in full accord with some
recently published standards-track RFC that allows it. He will of course
generate it in whichever charset his editor is configured to use at that
point.
And he will necessarily use RFC 2047/2231 to tag that charset and ensure
that the header field complies with the standards-track RFC, which forbids
non-ASCII characters which do not use 2047/2231. And there is no need for
a gateway to subsequently change that header field.
If it arises in Netnews, and his User Agent manages to produce UTF-8 for
it, then it is some gateway that may get stuck.- at which point that
gateway needs either to apply my heuristic, or apply one of the other
solutions suggested, e.g. drop that header, or stick an "X-" in front of
it.
No, if the field is properly encoded, as it must be per RFC 1036, no
gateway needs to do anything with that header field other than pass it along.
And if a "header field" contains illegal characters, sticking an "X-" in
front of the field name won't make it legal. And as discussed at length,
the proposed "heuristic" simply cannot work in the scenario given (viz. no
syntax information available).