governance vs intergovernance

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?

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