Subject: Re: [idn] Reality Check

From: [email-masked]
Date: Thu, 12 Jul 2001 12:12:48 -0700

Hi,
 I am working on muenonic symbol mapping to ASCII [a-z0-9].
I have done French, English and Chinese.  I may summit it to
WG soon.  I am looking into Indian, Korean, Japanese, Hebrew 
 and other languages. If anyone would like to contribute to this 
effort, please respond to this message.

Liana

On Wed, 11 Jul 2001 15:40:55 -0400 Keith Moore <[email-masked]> writes:
> > > hint: the cost of dealing with two different name representations 
> is
> > > greater than the cost of dealing with a single one.
> > 
> > No kidding. With UTF8 they only do it once. With ACE they do it 
> twice.
> 
> but due to backward compatibility and deployment issues, the ACE 
> representation is the essential one.  The UTF8 one is not needed.
> 
> as I've said before, the time to move to a UTF8 representation in 
> the
> DNS protocol is when we upgrade to something better than DNS.
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 16 Jul 2001 04:46:55 -0700

--On Sunday, 15 July, 2001 22:35 -0500 "Eric A. Hall"
<[email-masked]> wrote:

> As an aside, it is possible to upgrade many of the legacy
> protocols to UTF-8 without actually changing the protocol
> semantics, simply by using out-of-band negotation features.
> Finger, Echo, Gopher, etc., all of them could be upgraded. Not
> by this WG of course, but the work that this WG performs will
> dictate how that work eventually happens.
> 
> For example, if there's an out-of-band negotiation for "use
> UTF-8" that is glued onto finger, then the output can be
> internationalized, but the query inputs will also need to be
> internationalized for maximum functionality. This will include
> IDNs (with Finger in particular).

Eric,

Could you elaborate on what you propose to do with "out of band
negotiation" in these cases.  I can certainly understand a
protocol in which you call me, ask if my server is upgraded, and
then put it on a list, but such things traditionally have lousy
scaling and long-term properties.  It is difficult for me to
imagine how you would add anything out of band to finger, whois,
or other "one connection, one exchange" protoocols.  What did you
have in mind?

    john

---

From: "Russ Rolfe" <[email-masked]>
Date: Wed, 18 Jul 2001 14:34:38 -0700

Patrik Fältström <[email-masked]> wrote:

> I am extremely worried that what I see on this list is IDNA (which 
> include nameprep) or "just send UTF-8 without nameprep".

In my example, it was an over site not to include NamePrep.  I do see the importance of this feature and believe it is import no matter what encoding we choose.

Regards, Russ
Microsoft

-----Original Message-----
From: Adam M. Costello [mailto:[email-masked]] 
Sent: Monday, July 16, 2001 2:54 PM
To: [email-masked]
Subject: Re: [idn] Reality Check

Russ Rolfe <[email-masked]> wrote:

> I see no wrong asking users to take some of the responsibility of 
> moving to a new technology (i.e. having two addresses, adding a line 
> as part of the signature pointing to non-IDN address, requesting 
> System-Operators to upgrade)?

In other words, you'd rather create technical difficulties for users in order to ease the technical burden on engineers (by freeing them from ACE).  I'll concede that it may be possible to do so, but in my opinion it's the wrong tradeoff.  Users are far more numerous than engineers, and less able to deal with technical challenges.  I think it makes more sense to increase the technical burden on the engineers in order to make things easier for the users.

> IMHO if we go with an ACE only solution, it will never go away in the 
> long run.

If the engineers really hate ACE, they will move toward other mechanisms at every opportunity, and ACE will become less common over time.  If the engineers don't mind using ACE, then there's no problem with it remaining common forever.

In either case, I think the desire of users to see the native characters will be sufficient pressure to make ACEs very rarely visible to users. After that, users won't care whether ACE is truly gone or merely hidden.

Patrik Fältström <[email-masked]> wrote:

> I am extremely worried that what I see on this list is IDNA (which 
> include nameprep) or "just send UTF-8 without nameprep".

Nitpick:  The problem isn't sending non-nameprep'd UTF-8.  The problem is receiving UTF-8 and neglecting to run nameprep on it before comparing it with something.  Even with ACE, after a receiver decodes the ACE to obtain a Unicode name X, it must verify that X == nameprep(X), otherwise it's susceptible to spoofing.  But you still have a point: The ACE-decoding function is likely to have the nameprep check built in, whereas nameprep is more likely to be forgotten if UTF-8 is received. Still, I don't think we could stop new protocols from using UTF-8, and I don't think we'd even want to, so we just have to emphasize the importance of using nameprep for comparing IDNs.

AMC