Mark Crispin <mrc(_at_)CAC(_dot_)Washington(_dot_)EDU> 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 (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>