Mark Crispin <[EMAIL PROTECTED]> writes: > Now, let's factor out the items in which all three choices are > equivalent, and the superiority of choice "C" becomes even more > apparent.
> | 1 2 3 4 5 6 10 12 13 > -+----------------------------------- > A| D C N N D Y Y D Y > B| Y Y C Y Y N N N C > C| D C C C D N N N C That was the conclusion that was jumping out at me as well, but here are a few other things to keep in mind: * These columns don't really have equal weight, in that some of them represent small numbers of installations of relatively easily changed software and some of them represent very large installed bases or software that's difficult to change. In particular, (1) and (5), the installed base of news readers, will take a very long time to change, and (2), (3), and (4), the news server software, we know is rarely updated and upgrades are difficult to motivate. Usenet server software routinely runs for years on autopilot without any maintenance. By comparison, (6), the process that sends mail to moderated groups, is a small and easily changed component in most situations, and the number of moderators (10), news to mail gateways (12), and IMAP servers serving news messages (13) are all, while certainly significant, much smaller than the number of installations of the core Usenet software. * The single largest set of installed software, (1) and (5), is almost a C for proposal (A). We know that some existing software will work with UTF-8 newsgroup names out of the box without modification, although it will require some tweaking for ideal operation. By comparison, punycode (C) we know won't work correctly with *any* existing software; the only reason why that column is a D instead of Y is that users can use the funny-looking encoded names and still participate in the groups. This is one of the stronger arguments in favor of (A), namely that you can implement it to a surprising degree without changing any news software at all. * There are other issues not reflected on this matrix at all, such as complexity of implementation and compatibility with the existing messaging format, that weigh in various directions. Again, this is not to disagree with your conclusion. I just wanted to point out that while I found the table helpful, it's a bit over-simplified and hides the nature of some of the issues and tradeoffs. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
