ietf-822
[Top] [All Lists]

Re: RFC 2047 and gatewaying

2003-01-12 20:15:12

In <20030110200821(_dot_)666a94df(_dot_)moore(_at_)cs(_dot_)utk(_dot_)edu> 
Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:

On Fri, 10 Jan 2003 15:26:03 GMT
"Charles Lindsey" <chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk> 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.

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.  

Sure. There are a variety of ways software may "get stuck" if it receives
unexpected input. The implementor then has to use his judgement as to
whether to attempt a repair or whether to drop possibly useful
information. I am speaking of gateways and receiving User Agents here.

If the software is close to the poster/author, then sending it back to the
author with an error message is a third possibility.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 
Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

<Prev in Thread] Current Thread [Next in Thread>