English language

[John C Klensin]

--On Monday, 26 May, 2008 10:52 +0200 JFC Morfin
<jefsey at jefsey.com> wrote:

> At 20:05 25/05/2008, John C Klensin wrote:
>> If there are other organizational proposals, I wish someone
>> would  start formulating them and sharing them with the rest
>> of us.
> 
> I think we have a problem with RFC 3935 considering English as
> an element of security for the IETF technology. This is in
> line with the IDNA conception retaining English ASCII as the
> core of the system.

The two have nothing to do with each other.  IDNA is the way it
is for compatibility with the DNS and, in particular, the
"hostname" (letter-digit-hyphen) requirements of RFC 1035 and a
whole series of applications protocols.   And, while that
requirement uses ASCII  (i.e., more or less undecorated
Latin-derived characters) at a base, there is no binding of the
DNS to English and never has been.  First, the letters permitted
are no more able to express all of English in an
orthographically-correct way than they are to express all of,
e.g., French.  Second, a rather large fraction of the labels in
the DNS (pre-IDNA and continuing) are not "words" in English or
any other language.  We have labels with embedded digits,
abbreviations and acronyms for strings that are not necessary
English, strings with no vowels (impossible for English words),
and so on.  As an example, of the pre-ICANN gTLDs, only "net" is
an English word and its normal and traditional definitions/ uses
have more to do with fishing, spiders, and measurements than
they do with computers.  

Repeating the "English DNS" story over and over again does not
make it true and never will; it is either the result of stubborn
misunderstanding or an attempt to confuse and/or inflame.

> However, IDNA should deploy in a multilingual environment 
> as well. 

I thought we had gotten over this.  IDNA should deploy, and is
deployed, in a _DNS_ environment.  That is an environment of
mnemonic strings, not words, and is not inherently in any
language or "lingual" in any other sense.  What IDNA does is to
expand the list of characters that can be effectively used in
domain names to include additional characters (specifically
letters and digits in IDNA2008 as proposed) beyond the 63
permitted by the traditional hostname/LDH rule.     Many of us
have considerable hope that IDNs will help support a more
multilingual Internet (even while we may disagree about how much
they, by themselves, will add).  And we believe it is worth
paying careful attention to the identified needs of multilingual
(and, more important, culturally-localized and appropriate)
environments as we evaluate IDNA details and choices.  But to
say, as you have on many occasions, that "IDNA should deploy in
a multilingual environment" as if that is different from or
contrasts with the DNS environment is just (at best) confusion.

> I would therefore suggest
> that we retain the minimum English verbosity in the Protocol
> and Tables parts, to simplify translations and insure  a clear
> understanding of the translated texts.
> 
> I am ready to cooperate in applying an ISO approach and
> working on a parallel version in French. ISO experience shows
> that it leads to much clearer and terser English texts. Very
> often ISO translations in other languages are also based upon
> the French version considered as more precise. This create a
> problem when there is a better French wording due to the value
> added by the ISO translators that has not been fed-back to
> then closed English speaking working group.

I don't know how much actual experience you have with
information technology standards in ISO, but your assumption of
dual-language work is incorrect for ISO/IEC JTC1 (where SC2 and
the information technology multilingual/multicultural work is
housed).  Quoting from the most recent version of the JTC1
Directives I have handy (probably current, but I don't have time
to check):

	"7.9.1 The languages of JTC 1 are English, French and
	Russian. In general, the work of JTC 1 and its
	subsidiary bodies may be in any one or more of the
	above-mentioned languages."

In practice, virtually all JTC 1 work is carried out in English
and translations are rare (and even more rare for parallel
development because of a general recognition that, for technical
documents, working in parallel introduces errors, confusions,
and delays.  They have concluded that it is generally more
important to have one, definitive and authoritative version
rather than translations and the possible confusion among them.

JTC 1 encourages parallel language versions as an aid to
clarification of the text of Resolutions (Note to Directives
7.10.1), but those are not draft documents for the standards
themselves.

> Due to the
> importance of IDNA in the Asian part of the world, I would
> also suggest that a similar parallel version in Chinese and/or
> Japanese is/are also worked out. There is a multilinguistics
> rule we identified that when working in parallel on a document
> using several languages semantics mutually refine and
> pragmatics mutually filter.

I'm a big fan of working in parallel in multiple languages when
the work being done is user-facing and when the text being
considered is narrative, descriptive, or procedural.  But the
IDNA documents (even Rationale) are a protocol specification and
necessary explanation of it, and fall into none of those
categories.

     john