--On Monday, 07 June, 2004 15:16 +0200 "J-F C. (Jefsey) Morfin"
Post by J-F C. (Jefsey) MorfinDear 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.
Post by J-F C. (Jefsey) MorfinFrom 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
---------------
Post by J-F C. (Jefsey) MorfinA 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
Post by John C Klensin--On Friday, 04 June, 2004 17:15 +0800 dongxiaoli
Post by dongxiaoliHello 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.
Post by dongxiaoliAnd 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