Subject: [idn] Re: [idn] Re: Re: [idn] San Diego Meeting Notes

From: [email-masked]
Date: Fri, 26 Jan 2001 11:45:26 +0900

> At 8:32 PM +0900 1/25/01, [email-masked] wrote:
> >I don't think it's a right approach focusing on a short term solution without
> >clear understaning/evaluation on what a long term solution would be.
> 
> Could you clarify your reason for this? As long as the short term 
> presentation-layer solution doesn't force any design change for the 
> long-term solution, it seems that the two can be unrelated. Further, 
> having a short-term solution in place gives people more time to 
> figure out what the long term solution should be, and will also give 
> some valuable data about the attributes of the names that need to be 
> handled in the long term solution.

The problem is we don't know yet what the long term solution would be.
In that context, I'm not sure whether the proposed solution is a solution for a short
term (it could lock us up longer than we expect as Klensin pointed out) though I agree that the ACE-based approach is a simple solution to allow users to use IDN with the current DNS protocol. 

Dongman Lee

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 25 Jan 2001 20:05:11 -0800

At 11:45 AM +0900 1/26/01, [email-masked] wrote:
>term (it could lock us up longer than we expect as Klensin pointed 
>out) though I agree that the ACE-based approach is a simple solution 
>to allow users to use IDN with the current DNS protocol.

Well, I certainly won't speak for John, but but I don't remember him 
speaking about a short-term solution locking us up. He said that an 
even half-successful short-term solution will make it less likely 
that users will pressure us to to a good long-term solution. He also 
warned strongly about any short-term solution that changes the DNS in 
a way that makes it hard to implement a long-term solution. I agree 
with both of those.

The ACE-based solutions proposed so far will not change the DNS in a 
way that makes it hard to implement any long-term solution. The 
ACE-based presentation-layer solutions don't change the characters 
allowed or disallowed in host names (a through z, 0 through 9, 
hyphen), with the terribly minor exception of host names that begin 
with a particular weird prefix.  Even in the presentation layer, 
these solutions don't prevent later presentation-layer changes for 
different encodings.

Of the two themes of long-term DNS proposals so far (marked binary 
names such as UDNS or IDNE, or a radical change to the DNS such as a 
new class), neither is affected by a presentation-layer ACE-based 
solution, other than the desire for them will be slowed. It is easy 
to imagine that a long-term UTF8-based solution would completely 
coexist with an ACE-based solution in the presentation layer and on 
the wire, with no conflict at all.

Even the directory-based solutions that have been discussed but not 
well documented would not be affected by an ACE-based solution, and 
in fact might be helped, because people will see that the Internet is 
truly international much sooner. (As you can tell, this is, so far, 
my preferred long-term solution.)

Am I missing some significant effect that ACEs might have on other 
long-term solutions?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Jan 2001 22:02:12 -0000

> Am I missing some significant effect that ACEs might have on other 

Yes. If we allow ACE-based IDNs, then we'll have to keep them working
during the subsequent transition to UTF-8.

Consider, for example, franXais.com, but with c-cedilla in place of X.
Someone registers the ACE version of this. We make the huge changes
required for ACE. Users can then send mail to franXais.com.

Then we switch to UTF-8. There's a transition period where some clients
send ACE franXais.com and some clients send UTF-8 franXais.com. Both of
these will have to work! The registrar and domain owner have to copy all
their ACE data to UTF-8 data, and make subsequent changes in both forms.

The costs of this duplication aren't present in the initial move to ACE.
They also aren't present in a direct move to UTF-8. They're extra costs
of a transition. An initial move doesn't have to keep old IDNs working;
a transition does.

---Dan

---

From: "Brian W. Spolarich" <[email-masked]>
Date: Fri, 26 Jan 2001 17:59:05 -0500

| Then we switch to UTF-8. There's a transition period where some clients
| send ACE franXais.com and some clients send UTF-8 franXais.com. Both of
| these will have to work! The registrar and domain owner have to copy all
| their ACE data to UTF-8 data, and make subsequent changes in both forms.

  Seems like the nameserver could take care of this automagically if such
a protocol extension were to be defined in the future.

  Meaning, in dumb pseudocode:

  foreach label (zone) {
    if ((label is ACE) and (auto_generate_utf8_flag is TRUE) ){
      utf8_label = acetoutf8(label);
      load(label);
      load(utf8label);
    } elseif ((label is UTF8) and (auto_generate_ace_flag is TRUE)) {
      ace_label = utf8toace(label);
      load(label);
      load(ace_label);
    } else {
      load(label);
    }
  }

  This assumes that all labels have been nameprepped, although that checking
could also be done if necessary before the data is loaded.

  -bws

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 27 Jan 2001 10:57:41 +0100

>could also be done if necessary before the data is loaded.

It can not because the use of the domainname in DNS is only one of 
the places where domainnames are in use.

Client software have to do the right thing, including nameprep, and 
nothing else.

Existing software can _not_ be used.

Can someone remind me why I have to say this so many times on this 
list even though the design teams already have explained this?

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 27 Jan 2001 10:55:40 +0100

>during the subsequent transition to UTF-8.

Why should UTF-8 be the long-term solution? Why not UCS-2 or some 
other representation?

>required for ACE. Users can then send mail to franXais.com.

Consider another example where a user is using an existing software 
which doesn't do nameprep, and tries to send email to a user in a 
domain which include a character which is changed because of 
nameprep, what then happens?

Dan you have still not answered my question on how much email you 
send and receive where the language in the mail is not english, and 
what languages you use? Knowing this will help knowing what scripts 
you actually have experience with, and based on that judge the 
importance of your input to this mailing list.

    Patrik

---

From: "D. J. Bernstein" <[email-masked]>
Date: 27 Jan 2001 18:57:25 -0000

Brian W. Spolarich writes:
  [ copying all ACE data to UTF-8 data during a transition ]
> Seems like the nameserver could take care of this automagically

No! It isn't just the DNS server. You're making the same old ACE mistake
of failing to look at all the ways that names are used.

Example: The domain owner will have the ACE franXais.com in his mail
server's configuration files, but he has to start accepting mail for the
UTF-8 franXais.com too.

---Dan