On Mon, 18 Mar 2002 11:57:17 GMT, Paul Robinson said: > > Hmm.. so you're saying that *ALL* that code out there that double-checked that > > things that claimed (possibly implicitly) to be USASCII were in fact in the > > 0-127 range are "crusty" code?
> No. I'm saying that if a piece of software gets input that is unexpectedly
> 'out of range' and then crashes and burns it is badly written. Sure,
> checking data is a good thing. Not checking it and letting things 'just
> break' is stupid. There are 14-year olds in high school in their second
> class of visual basic programming who know this.
OK.. Thanks for the clarification. The distinction is important, because:
On Mon, 18 Mar 2002 06:08:25 PST, [EMAIL PROTECTED] said:
> I have very little sympathy for software that breaks when given unexpected
> input. But this is not the concern. The concern is that there is a bunch of
> widely used software that prohibits certain inputs. It does so because the
> standards in effect at the time the software was written said those inputs are
> illegal.
And let's remember - currently, if it's *not* ascii and *not* RFC2047-encoded,
it is *illegal* in email headers and *IF* it works, it only does so either
*BY ACCIDENT* or *BY MUTUAL PRIVATE AGREEMENT*.
As such, I have to insist that *any* IDN proposal be required to be backwards
transparent to the current 2821/2822/2045-2049 standards the same way that
MIME/ESMTP was required to be backwards transparent to the then-existing 821/822
infrastructure.
On the other hand, I *will* accept an IDN proposal that looks as ugly
to non-upgraded software as 2047-encoding does to a non-2047 capable MUA.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
msg07846/pgp00000.pgp
Description: PGP signature
