headers
dongxiaoli | 15 Apr 2004 08:23
Picon

Why not use the same decode way for the LocalPart as the way for the Domain Name in the IDN


Hello!

    Why not we use the same decode way for the LocalPart as the way for the Domain Name in the IDN.
    For example in this way my name 董晓荔 will became xn--1jvp95dgxa,and now I have got some Free mail used
this name. One of these is  xn--1jvp95dgxa <at> 263.net.  
    Then I can use my Email address in Chinese Laguage: 董晓荔 <at> 263.net
    Thanks..

With best regards, Xiaoli Dong.  E-mail: dongxiaoli <at> cnnic.cn
Permalink | Reply |
headers
Adam M. Costello | 18 Apr 2004 05:43

Re: Why not use the same decode way for the LocalPart as the way for the Domain Name in the IDN


dongxiaoli <dongxiaoli <at> cnnic.cn> wrote:

> Why not we use the same decode way for the LocalPart as the way for
> the Domain Name in the IDN.  For example in this way my name ??????
> will became xn--1jvp95dgxa, and now I have got some Free mail used
> this name.  One of these is xn--1jvp95dgxa <at> 263.net.  Then I can use my
> Email address in Chinese Laguage: ?????? <at> 263.net

Paul Hoffman / IMC <phoffman <at> imc.org> replied:

> Because you can't *encode* many legitimate email addresses using IDNA.
> IDNA prohibits all ASCII characters other than LDH, so mailbox names
> like "josé.muñoz" could not be encoded.

That's true if UseSTD3ASCIIRules is set, but if we wanted to reuse
IDNA for local parts, we could specify that UseSTD3ASCIIRules is
never set for local parts, in which case ToASCII("josé.muñoz") =
"xn--jos.muoz-d1a7f".

I haven't thought about the various issues for a while, but at the
moment the only thing I can think of that prevents us from reusing IDNA
ToASCII for local parts is the problem with structured local parts.  For
example, both humans and computers commonly add and remove prefixes
and suffixes to local parts, like owner- and +tag.  The result will
be different depending on whether you are working with the ASCII form
(which is likely if "you" are legacy software) or the Unicode form
(which is likely if "you" are a human).

Xiaoli, have you seen the IMAA draft (draft-hofmann-imaa-03.txt)?  It
(Continue reading)

Permalink | Reply |
headers
dongxiaoli | 4 Jun 2004 11:15
Picon

WHY we need do "Divide the sequence into segments"


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)??

        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*?

        thanks..

                                                                        
                           Xiaoli Dong

                           CNNIC
Permalink | Reply |
headers
Adam M. Costello | 6 Jun 2004 01:12

Re: WHY we need do "Divide the sequence into segments"


dongxiaoli <dongxiaoli <at> cnnic.cn> wrote:

> "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.                        

Oops, thanks for catching that.  The prose describes the actual
intention.  The number ranges should be 0..2F, 3A..40, 5B..60, 7B..7F.

> 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)??

Before internationalized local parts can be safely created in a mail
domain, a couple questions need to be considered:

 1) Are local parts case-sensitive within this domain?

 2) Are local parts structured within this domain, using delimiters
    other than protected characters?

If the answer to either question is "yes", then internationalized local
parts will not work correctly in the domain unless the MTAs for the
domain are upgraded to understand the IMAA encoding.

However, if the answer to both questions is "no", then there is no need
to upgrade the MTAs.  Internationalized local parts can be created in
the domain and they will work correctly.
(Continue reading)

Permalink | Reply |
headers
dongxiaoli | 7 Jun 2004 04:36
Picon

Re: WHY we need do "Divide the sequence into segments"


Thanks Adam  and  john.You do me a great favor. :-)

                                     Xiaoli Dong
Permalink | Reply |
headers
John C Klensin | 4 Jun 2004 15:01

Re: WHY we need do "Divide the sequence into segments"


--On Friday, 04 June, 2004 17:15 +0800 dongxiaoli
<dongxiaoli <at> cnnic.cn> 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
(Continue reading)

Permalink | Reply |
headers
J-F C. (Jefsey) Morfin | 7 Jun 2004 15:16
Picon

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?
(Continue reading)

Permalink | Reply |
headers
John C Klensin | 7 Jun 2004 16:51

Re: governance vs intergovernance


--On Monday, 07 June, 2004 15:16 +0200 "J-F C. (Jefsey)  Morfin"
<jefsey <at> club-internet.fr> 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,
(Continue reading)

Permalink | Reply |
headers
J-F C. (Jefsey) Morfin | 8 Jun 2004 00:31
Picon

Re: governance vs intergovernance


Dear John,
I am afraid your answer is out of the scope of my question.
My question does not relate in any way to the specificity of the
case, nor to the management of the case by ICANN, nor why
the WG-IDN took that options and why. It is related to the
very existance of the case and of its technical reasons.

This is IETF. So the point is technical. The way the ideas are
expressed are of no interest. What is of interest is the technical
roots of each of the protests. To which extent these technical
objections only relate to RHS or may also concern the LHS. And
what could we do to avoid the related problem in specifying an
LHS solution.

I personnaly (but I may be wrong) read most of them as objecting
to the IETF/ICANN adopted technical strategy. You describe that
strategy as follows:

At 16:51 07/06/04, John C Klensin wrote:
>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
(Continue reading)

Permalink | Reply |
headers
John Cowan | 8 Jun 2004 02:56

Re: governance vs intergovernance


J-F C. (Jefsey)  Morfin scripsit:

> The question is: can the above strategy, together with the
> IETF disclaimer below, be copied for LHS for average registrants,
> when RHS (ie. ccTLD) leads to situation inflaming international
> highly representative organizations?

Yes.  Indeed, it will work better for email providers, because there
are many of them in most environments.  Each can set a private policy
about what characters, or sequences of characters, they will or will
not accept in local-parts.

In general, companies are far less malleable under political pressure than
government agencies.  The only way to forcibly shift one from its policy
will be by private lawsuit, and in a vanishing number of cases will it
be worth doing that rather than just switching to another email provider.

--

-- 
Where the wombat has walked,            John Cowan <jcowan <at> reutershealth.com>
it will inevitably walk again.          http://www.ccil.org/~cowan
Permalink | Reply |
headers
J-F C. (Jefsey) Morfin | 8 Jun 2004 04:29
Picon

Re: governance vs intergovernance


Dear John,
I understand where you come from with this point. But the point here is 
quite the opposite. It is to say that I am entitled to see my culture 
respected and that culture to self determine the way it wants to express 
itself on the internet.

For example, a question debated in here in many accoasion is ; to be case 
sensitive or not? This is not a question for the IETF. This is not a 
question for the Mail service provider, this is a question for the user to 
decide what he wants.

But non only the IETF specification must permit it, but it must deliver a 
tool which will permit the user to decide a parameter set according to the 
Academic, Politic, Family, whatever Lingual Authority he wants to chose.

This may have a lot of implication. MINC rises the point of ".xxx" being or 
not translated by ICANN decision. They say it is to be by lingual 
organization decision. Why? Because most of the Arabic countries are 
Moslems, and they oppose pornography in their constitution. Not translating 
it permits to address the demand of the users to protect them against this 
risk - because "xxx" cannot not be typed easily on an Arabic keyword.

You will say that they could bar it.
- one: this is not to others to decide for their law. Would you accept 
easily if the US car driving had to adapt to the French standard because 
internationalized (you must come back on the right lane on an highway) ?
- two: there is a big difference between censoring and not helping.
- etc.
(Continue reading)

Permalink | Reply |
headers
Paul Hoffman / IMC | 8 Jun 2004 00:47
Picon

Re: governance vs intergovernance


At 12:31 AM +0200 6/8/04, J-F C. (Jefsey)  Morfin wrote:
>This is IETF.

No, it is not. It is a mailing list. And, to be specific, it is a 
mailing list that is not associated with any IETF WG.

I have said this before many times, but you see to have forgotten. 
I'll change the title on the mailing list soon to help folks remember.

--Paul Hoffman, Director
--Internet Mail Consortium
Permalink | Reply |
headers
dongxiaoli | 21 Apr 2004 03:33
Picon

Re: Why not use the same decode way for the LocalPart as the way for the Domain Name in the IDN


Hello,Hoffman ,Adam!

  OK,IC, thanks a lot.

With best regards, Xiaoli Dong.  E-mail: dongxiaoli <at> cnnic.cn
Permalink | Reply |
headers
Paul Hoffman / IMC | 15 Apr 2004 16:27
Picon

Re: Why not use the same decode way for the LocalPart as the way for the Domain Name in the IDN


At 2:23 PM +0800 4/15/04, dongxiaoli wrote:
>     Why not we use the same decode way for the LocalPart as the way 
>for the Domain Name in the IDN.

Because you can't *encode* many legitimate email addresses using 
IDNA. IDNA prohibits all ASCII characters other than LDH, so mailbox 
names like "josé.muñoz" could not be encoded. That is why we rejected 
the idea as non-workable from the very beginning.

--Paul Hoffman, Director
--Internet Mail Consortium
Permalink | Reply |

Gmane