What I hear in these discussions can get translated into a lot of "it
would be nice" and
little if any "it is essential that".
Changes to existing procedures tend to get driven by "it is essential
that," which is my point.
A working group saying that
the existing format restrictions are severely hindering their work
would count for a lot here.
I'll have a go at it (I am not a working group, but I hope you allow me
to express my opinion anyway). Plain ASCII makes work on drafts which
deal with internationalisation very hard. I have just uploaded a draft
with an example second-level domain containing the German small u-Umlaut
[U+00FC] as input to an algorithm.
Sorry, in fact the draft did of course *not* contain the umlaut. I had
to escape it with the [U+00FC]. Writing that impairs the readability and
understandability of the example quite a bit since the input on "paper"
is not the same as the actual input. This is, IMHO, "severely hindering"
If merely expressing oneself *about* i18n problems properly is
impossible, I'm not really surprised that internationalisation is
perceived as hard and cumbersome. (It's hard and cumbersome enough
without these restrictions already anyway.) Unicode is there for a while
already and I think switching to any kind of format that supports
international character sets is essential. Pick any format you like, as
long as it allows people to express their problems and solutions without
ugly hacks (read: as long as it supports the full set of Unicode - not
just the first 127 characters).
P.S.: "a2ps" never failed on me for producing 2-up, nicely framed and
properly page-breaked printer output.
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la
6, rue Richard Coudenhove-Kalergi
Tel: +352 424409 1
Fax: +352 422473
Ietf mailing list