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, ned.freed@mrochek.com 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
Attachment:
pgp00002.pgp
Description: PGP signature