Charles Lindsey wrote:
In <20030109083713(_dot_)378e2ac9(_dot_)moore(_at_)cs(_dot_)utk(_dot_)edu> Keith
Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
There are many more pieces of software than Usefor gateways which get
stuck because they do not know the correct way to parse some field. The
design flaw was in RFC 2047 which allowed that situation to be gotten into
in the first place.
rfc 2047 doesn't affect how fields are parsed. it only affects how
fields are displayed. if a viewer doesn't realize that a field
is structured and/or doesn't know how it should be parsed, the worst
that should happen is that encoded-words are not decoded before display.
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.
The root problem is once again the Usefor draft, which is unworkable
because:
1. it permits user agents to generate "header" fields with untagged raw
non-ASCII content, discarding any charset and language information
which the user agent ought to know. [obviously, the user agent must
have syntax information to be able to construct such a "header", unless
it permits the user to input raw text for "header" fields, in which
case the user must know the relevant syntax.]
2. it then requires gateways to magically construct a valid RFC 2822 + MIME
header field from that gobbldeygook, with no charset or language
information, and possibly for some "header" field unrecognized by the
gateway.
That can't be done. End of the line. Back to the drawing board.
For gateways to work at all, either the user agent must preserve charset
and language information in some way that it can be used by gateways *and*
gateways need to have syntax information for any possible header that might
have non-ASCII content generated by any such user agent, *or* the user agent
must use a compatible means of generating the "header" field in the first
place (viz. RFC 2047 / 2231), in which case there is no additional effort --
and no magic -- required of the gateways. In the first case, there is the
additional issue of existing gateways, which requires some reasonable
transition plan whereby the mechanism for conveying preserved charset and
language information and the header field syntax information can be
incorporated into those gateways. Obviously the second method is far
simpler to implement and is compatible with existing gateways and is
consistent with the current article format standard (RFC 1036) and is
compatible with existing software which handles mail and news (including
combined user agents). But "the Usefor WG chose not to do that"; well,
the method in the current Usefor draft simply cannot work, and the Usefor
WG will have to reconsider. Any scheme that requires encoding separate
from header field generation will have the same problems, for the same
reasons.