On Fri, 10 Jan 2003 15:26:03 GMT
"Charles Lindsey" <chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk> 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.
Does this same software "get stuck" as soon as it encounters some other
syntax error in the input? After all, a non-ascii character in the message
header of an input message is a violation of the message syntax.
Some errors are recoverable with a reasonable degree of safety - so for
instance you can often make sense of a malformed rfc822 style date
even if the syntax is completely wrong. Similarly, you can make sense of
some header fields which contain non-ascii characters by encoding them
per 2047. But that doesn't mean you can recover from all inappropriate
uses of non-ascii characters.
For example, until we have a specification for use of non-ascii characters
in email addresses, there's no way that you can convert an input message
that contains a non-ascii character in an email address into a valid message.
"getting stuck" (or hopefully, reporting an error) is the best you can do.
The standard of implementation of RFC 2047 in current software is
exceedingly poor. The reason seems to be that implementors find that doing
it correctly is so burdensome that they decide to cut corners. You would
say that it is all the wicked inplementors' fault. Other would say it
illustrates that it is a bad standard.
it may be a bad standard, and at the same time, it may be (close to) optimal.
the two are not mutually exclusive.
Keith