Re: [idn] WG last call summary

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(_dot_)freed(_at_)mrochek(_dot_)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

pgpiC1YnWUKAq.pgp
Description: PGP signature