Re: [idn] UTF-8 as the long-term IDN solution

[Keith Moore <moore@cs.utk.edu>]

> > do you really think we'll be using a paper-tape I/O model 10 years
> > from now?  even on UNIX?  maybe we will - it's endured a long time -
> > but I wouldn't bet the farm on it.
> 
> Ever heard of TCP? Byte streams aren't going away.

okay, well perhaps I should have asked:

"do you really think we'll be using user interfaces designed for a
paper-tape I/O model 10 years from now?"

> > p.s. if and when qmail has been around for 20+ years,  and if it still
> > has significant popularity, some young upstart is going to trash your
> > code for being shortsighted and brain-damaged.
> 
> It has been around for more than 5 years. It hasn't needed any syntax
> extensions except to work around bugs in other software (space after
> MAIL FROM, for example). If it turns out someday that I haven't planned
> ahead far enough, I'll make whatever changes are necessary.

unlike sendmail, you had the luxury of implementing qmail after the 
mail standards had stabilized, when pretty much everyone was using
DNS with MX records and SMTP over TCP.

> For comparison: In February 1999, when it became clear that the revised
> USENET message header field format was going to allow unencoded UTF-8, I
> explained to Eric Allman how to make sendmail 8-bit-clean. (USENET
> messages are often forwarded through mail by 8-bit-clean gateways.) A
> few days ago, he released another security-fix release of sendmail. It
> still isn't 8-bit-clean.

As a matter of fact, message headers are still required to be in ASCII.
An MTA that accepts or relays broken message headers is arguably broken.
Fortunately, most deployed MTAs block 8-bit characters in message 
headers, which keeps people from depending on them. This is a good thing 
because their behavior isn't defined they wouldn't be reliable even if
they were passed cleanly.  So when are you going to fix qmail?

(you don't have to answer that, it's a rhetorical question)

You stubbornly refuse to fix qmail to comply with the standards, 
because you think that you know better than anyone else how things 
should work - which characteristics of software or a protocol are 
bugs and which are features, who should deploy what new servers at
what timeframe, etc.  It's your right and privilege to think that, and 
you are free to implement your own software however you wish.  But you 
shouldn't be surprised to find out that others have different opinions 
about how things should work.  

For a protocol to be interoperable in the real world it must be able to
tolerate some variation in implementation, user interface, and deployment.
People everywhere will not follow your game plan (or anyone else's) just
because you claim it's a good idea.  Different people in different 
situations will inevitably favor different solution paths. 

Keith