Re: governance vs intergovernance

--On Monday, 07 June, 2004 15:16 +0200 "J-F C. (Jefsey)  Morfin"
<[email protected]> wrote:

> 
> Dear John,
> since you were one of the most reasonable actors of the WG-IDN
> and that the LHS will face the same real world oppositions as
> the RHS, I would be interested in your comments about the
> current MINC positions over the Arabic/Poland situation. This
> is a direct consequence of the concept of
> "internationalization" I fought as inapropriate (IMO) to the
> real world and of the demands from the ICANN governance.
> 
> NB. If you do not have it, I have a copy of the letter as a
> Member of the MINC, but I do not know if it is online. I can
> copy it to those interested but I suppose netiquette opposes
> that I put it myself on line?

Since it was addressed primarily to ICANN and the ICANN Board, I
have seen a copy of it.  I suspect most readers of the IMAA list
have not.  Given the quite inflamed and inflammatory content/
tone of the letter, I think it would be inappropriate for me to
attempt to summarize it, so, while I want to respond to the
portion of this that can easily be explained out of context,
further discussion should almost certainly be taken elsewhere
(and the old IETF IDN mailing list isn't an appropriate place
either).

To review a situation which I hope everyone here understands,
when the IDN standards were produced, the IDN WG, and thence the
IETF, made a quite explicit decision to specify mappings and
codings but to become as little involved as possible with the
specification of usage, which characters and character
combinations should actually be used, etc.  The IESG reinforced
the nature of this decision by issuing a "statement" along with
the standards that might be described as "this is what we have
done, but you don't have a complete picture until you do some
other things, and you should be careful about them".

Following that extremely broad guideline, ICANN adopted a
guideline/ recommendation that strongly suggested that IDN
registrations occur only "by language".  This was consistent
with extended discussions on the IDN list (while the standards
were under development) about the advantages of "one label / one
language" (or "one script") strategies in eliminating a number
of opportunities for problems, but the IDN WG did not make a
recommendation on that subject (for or against).  ICANN also
created, as a convenience, a registry for the tables of
characters permitted by given DNS registries.  E.g., if the DNS
ccTLD registry for Lower Slobbovia wanted to permit
language-based registrations in Klingon, and wanted to make
their "Klingon script" definition public and available to
others, they could register their Klingon table (including
character variants if they wanted to go that route) with IANA.
Of course, to do that, they would first have to convince the
Unicode Consortium and ISO to define and create standard code
points for Klingon.

>From the standpoint of this list, or any other IETF-related
list, there is one important message from the above: with one
very small exception, none of the about involves the IETF in any
way.  It is up to the registries what characters they support
and what to call them.  The registry of tables is an ICANN-IANA
registry, not an IETF-IANA registry.  Even if the IETF were
involved in it (which it is not, in any way) the registry is a
"pure" registry, with no decision-making processes: any TLD
administrator can submit any list of character they want, under
any name, to be registered.  The small exception applies to
Klingon, which makes a good example, but is probably not a major
concern for languages and scripts used by contemporary humans
who use the Internet: IDNA is firmly tied to Unicode 3.2 and,
regardless of what UTC might do about Klingons and Klingon in
the future, it would require some IETF action (and presumably
expansion of Stringprep) to deal with a later, expanded, version
of Unicode.

Now the situation and letter to which you refer involved one in
which a ccTLD registry filed a table of characters with IANA
that they associated with a language name.  The language is not
an official or majority language in that country.   Someone who
is, I think, a native speaker of that language and who has roots
in a country where it is the majority and official language,
took serious exception to the registration, especially since no
registration for the language or script had occurred by anyone
he was willing to recognize as authoritative.  Again, not a set
of IETF issues in any way.  Not even an ICANN issue unless ICANN
is willing to go into the business of "world cultural authority"
figuring out what bodies should be able to decide, for everyone
else in the world, what characters are or are not in a given
script and for what purposes they may be used.  And ICANN isn't
nearly that stupid, nor is any other rational international
organization I know of, governmental, treaty, NGO, or completely
private.

This particular letter raises a number of other issues about
cultures, international politics, and other topics, but they are
even further from anything related to IETF (or even ICANN) work.

And, in my opinion, none of it suggests any reason for an
IETF-related discussion on this subject, nor does it justify
your conclusions below.  One thing it certainly does do is to
illustrate the fact that people get extremely sensitive about
their languages and how they are used.  But we all know that
already, and it was one of the things that drove IETF to stay
very far away from those issues.  And, even more certainly, it
has nothing to do with the rather specific technical question
which was asked and which Adam and I answered (I think and hope
consistently, although in different terms).

     john

---------------


> A part from the impossible situation where it puts ICANN which
> has to chose between a non existing Arabic moral authority and
> now Europe, through a choice involving three parties described
> as at war (real life, real world) and no one understand right
> now the political impact, my concern is that RHS "only"
> involves 260 TLDs while LHS involves millions of domain
> holders.
> 
> 1. you have not come with a satisfactory way to MLize RHS
> against my own patch to intlnzation. I see now that the MINC
> letter opposes your global understanding of the problem -
> please read carefully the part about ".xxx".
> 
> 2. this confirms my opinon that an internationlization of the
> LHS cannot work and that multinationlization must use another
> upper layer - so not to conflict with the current situation
> but to complete it.
> 
> Don't you think that time has come now to start a clean sheat
> study of the real life e-intergovernance and to deduct from it
> what the constraints on the datacoms architecture?
> 
> jfc
> 
> 
> At 15:01 04/06/04, John C Klensin wrote:
> 
> 
>> --On Friday, 04 June, 2004 17:15 +0800 dongxiaoli
>> <[email protected]> wrote:
>> 
>> > Hello everyone.
>> > 
>> >        Have anybody can tell me WHY we need do "*Divide the
>> > sequence into segments*" in the ToASCII process  as
>> > described in the
>> > IMAA draft (draft-hofmann-imaa-03.txt)??
>> 
>> In many circumstances, there is a good deal of information
>> that is already encoded into email local-parts.  The most
>> common of these, these days, are subaddresses and internal
>> routing codes, but external routing and address component
>> identification, such as those used for X.400 addresses and
>> fax-like attribute identification when those are mapped to
>> the Internet, have been common (and probably still are) in
>> some communities.
>> 
>> In many of those cases, the presence of the encoding and its
>> components must be recognized by the delivery MTA or, at the
>> boundary of an outright violation of the standards (however
>> necessary) by organizational-boundary relays such as
>> SMTP-handling firewalls.  If the clues that the codings are
>> present are hidden by the i18n encoding, we gain
>> internationalization at the cost of the features supported by
>> that information-encoding.
>> 
>> We have no standard for any of those information encodings --
>> they have, so far, been protected by an extremely strong rule
>> that no MTA before the final delivery one is permitted to
>> interpret the contents of a local-part in any way.   All
>> previous systems and MTAs, including the originating user and
>> MUA, are required to treat the entire local-part address an an
>> atomic and opaque string.
>> 
>> The segments and delimiters of draft-hoffman-imaa-03 are
>> intended to alleviate the problem with hiding these encodings
>> while providing internationalization for the various address
>> components.
>> 
>> This issue was the original philosophical departure point
>> between draft-hoffman-imaa and draft-klensin-emailaddr-i18n.
>> The latter takes a somewhat stronger and more protective view
>> of the local-part addresses, noting particularly that the
>> approach in draft-hoffman-imaa will not protect either
>> information in local-parts that is length-encoded (e.g., "the
>> address contains a 'project distribution' component beyond
>> the mailbox name for the recipient; the last three characters
>> are the project identifier, the other characters are the
>> mailbox name") or information that is separated by non-ASCII
>> delimiters.  For example, were you to want to use
>> subaddresses with a mailbox whose name was in Chinese, the
>> rules of draft-hoffman-imaa would require that you separate
>> the mailbox and subaddress elements with an ASCII delimiter,
>> not one that might appear more appropriate for Chinese, if
>> the classification and action were to be done by an MTA that
>> did not, itself, run ToUnicode. There is some additional
>> discussion on this issue in
>> draft-klensin-emailaddr-i18n-02.txt.
>> 
>> >         And  another question: "The "*protected code points"
>> > are 0..40, 5B..60, 7B..7F (in other words, those
>> > corresponding to ASCII characters other than letters and
>> > digits). *" is from draft-hofmann-imaa-03.txt.  But the
>> > code points of digits range between 0...40,so why said the
>> > *digits is not  protected code points*?
>> 
>> Paul or Adam will need to answer this one.
>> 
>> best,
>>     john
>