Martin Rex wrote:
Stefan Winter wrote:
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"
Good example. Wrong conclusion.
Specifications that deal with processing of unicode ought to use
literal Unicode codepoints throughout (and not graphical glyphs),
because the Unicode codepoints are the things that end up in code
and need to be correct, whereas the glyphs are hard to read and
If the non-ASCII code point is part of the protocol: yes.
On the other hand, if the code point appears in an example, illustrating
how to deal with I18N, no.
Ietf mailing list