[rfc-i] I18N constraints (was: Re: Proposed new RFC submission requirements)
"Martin J. Dürst"
duerst at it.aoyama.ac.jp
Tue May 29 04:27:32 PDT 2012
On 2012/05/26 3:07, Martin Rex wrote:
> I'm also OK with I18N characters in some new or some existing submission
> format, under the following constraint:
> There MUST NOT be any new requirement on display devices for rendering
There's no need for a new requirement. The average browsers can display
most non-ASCII characters just fine. It's of course possible to find
counterexamples (because Unicode is still growing), but these aren't
really the characters most needed.
> Any new RFC must still remain fully comprehensible if all
> non-ASCII chars are completely stripped, e.g. because the device
> is not capable of rendering them.
Oh well. Why don't you have a look at a publication from the ACM, or the
IEEE, or some similar professional organization. These managed to use
non-ASCII characters even before ASCII was invented, and have been doing
so throughout their existence, without any serious problems either on
the production or on the consumption side. I don't want to assume that
the IETF and the RFC Editor should not be able to do a similarly good job.
> I don't mind non-ASCII names, but when there is a formal requirement for
> a name in the RFC, a pure-ASCII name MUST be provided, an additional I18N
> is optional.
Again, why would the IETF and the RFC Editor want to have such a policy
if the ACM or the IEEE,... never needed it? I think there's probably
widespread agreement that names in scripts other than Latin need
Latin-script equivalents, but that's different from requiring ASCII
equivalents for non-ASCII. Having something like
Patrik Fältström (Patrik Faltstrom)
would look plain and simple ridiculous.
> Similar for EMail-Addresses. That is a very simple
> backwards-interop requirement with both (a) devices that do not recognize
> that I18N codepoints and humans that do not recognize that I18N glyphs.
I'd agree for email addresses, for the moment, but only because the
specs for how to do non-ASCII email addresses are still very young.
> If a significant fraction of the consumers of the RFC can not recognize,
> read or spell some I18N stuff in a document, then this information can
> NOT be normative, only illustrative. If it can not be normative, it
> can be stripped without loss of significant information.
I'm not exactly sure how author names would fit into the
normative/informative distinction in any way. If they do, I'd certainly
very much want to insist that my normative family name is "Dürst", and
"Duerst" is only an informative equivalent.
It might be better to look at an actual example and tell us where you
think there are problems. I produced one about two months ago, the
version with non-ASCII characters is at
More information about the rfc-interest