[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
>    I18N.

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 

Regards,    Martin.

More information about the rfc-interest mailing list