Subject: [idn] Internet Draft uname.txt

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 19 Mar 2001 19:07:44 +0800

Here is a prelimary I-D on Internationalized Domain Names and Unique
Identifiers/Names. It is unable to reach the cut-off date but a
presentation has been requested to Marc for the meeting as an
alternative view to the current Nameprep-ACE approach taken by the WG.

Please give your comments.

-James Seng

---

From: Yoshiro YONEYA <[email-masked]>
Date: Tue, 20 Mar 2001 01:56:42 +0900 (JST)

From: "James Seng/Personal" <[email-masked]>
Subject: [idn] Internet Draft uname.txt
Date: Mon, 19 Mar 2001 19:07:44 +0800

>        Internationalized Domain Names and Unique Identifiers/Names

My understanding about this draft is using DNS forNAMEPREPping.
Right?

If yes, expected applications' behavior for NAMEPREPping is:

- send 8bit QUERY to DNS servers which include directory.
- receive answer in NAMEPREPped ACE from DNS servers.
- replace internal representation of inputted domain name with
  received answer.

And then, use the replaced internal representation for DNS queries,
application protocol messages, and so on.  I think this requires
upgrading applications.

-- 
Yoshiro YONEYA <[email-masked]>
           aka <[email-masked]>

---

From: "Brian W. Spolarich" <[email-masked]>
Date: Mon, 19 Mar 2001 12:46:43 -0500

In the draft the authors state:

c.	It might be possible to construct a binary string in some legacy 
encoding which gives the same binary representation for another domain 
name (a.k.a. binary collision).

  This is a big problem in my mind.  Sending unidentified codepage data
could create all sorts of opportunities for spoofing, and more mundane
problems like DNS caches giving out the wrong answer.

  -bws

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]]On Behalf Of
| James Seng/Personal
| Sent: Monday, March 19, 2001 6:08 AM
| To: [email-masked]
| Subject: [idn] Internet Draft uname.txt
| 
| 
| Here is a prelimary I-D on Internationalized Domain Names and Unique
| Identifiers/Names. It is unable to reach the cut-off date but a
| presentation has been requested to Marc for the meeting as an
| alternative view to the current Nameprep-ACE approach taken by the WG.
| 
| Please give your comments.
| 
| -James Seng
|

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 20 Mar 2001 02:47:24 +0800

> problems like DNS caches giving out the wrong answer.

Yes. So the workaround would involve preventing binary collision in the
first place.

-James Seng

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 20 Mar 2001 02:46:03 +0800

Erm, I forgot to mention I am *not* the author...altho i wrote the I-D
on the behalf of the authors.

> My understanding about this draft is using DNS forNAMEPREPping.

To be exact, using Directory for "unification of different
representations", which is kind of different from nameprep.

> application protocol messages, and so on.  I think this requires

Yes and No. The answer depends which directory you choose...

-James Seng

---

From: [email-masked] (J. William Semich)
Date: Mon, 19 Mar 2001 14:09:44 -0500

>>        Internationalized Domain Names and Unique Identifiers/Names
<snip>

Hence, we would create the following Resource Records within the name server. 
In the Resource Records, it would look like this:

ML1		UNAME		ACE1
ML2		UNAME		ACE1
ML3		UNAME		ACE1
ML3		UNAME		ACE1 

ACE1		IN 	A	1.2.3.4.
		IN	A	1.2.3.4.

A "UNAME" Resource Record is shown here. In practice, it could be CNAME 
(except CNAME is unable to handle MX).
-------------------------------------------------------

What is the explanation for using the (not-yet-developed) "UNAME" RR type
instead of the currently available DNAME (in BIND 9)? 

Bill Semich

---

From: Yoshiro YONEYA <[email-masked]>
Date: Tue, 20 Mar 2001 04:49:34 +0900 (JST)

From: "James Seng/Personal" <[email-masked]>
Subject: Re: [idn] Internet Draft uname.txt
Date: Tue, 20 Mar 2001 02:46:03 +0800

> on the behalf of the authors.

Yes, I know :-)

> representations", which is kind of different from nameprep.

Thanks.  And repeat again, my understanding is that the most prefered
Directory in this I-Draft is DNS.  So I asked previous question.

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 19 Mar 2001 23:37:52 +0000

> application protocol messages, and so on.  I think this requires

This is an excellent point.  We need to keep reminding ourselves that
the problem goes beyond just DNS.  If I receive mail addressed to me and
various other people with IDN addresses, what goes in the To: field?
Will today's version of the sender's software handle that?  And will
today's version of my software allow me to reply to everyone?

AMC

---

From: "Maynard Kang" <[email-masked]>
Date: Mon, 19 Mar 2001 19:07:24 -0600

> today's version of my software allow me to reply to everyone?

Mail applications will have to be upgraded too, along with other applications which have DNS dependencies.

Interestingly, I feel that there has been one erroneous assumption we have been making in this WG and it is that the solitary purpose for the input of a hostname into an application is for resolution of DNS RRs.

However, IDNs may appear in protocol exchanges or arbitrary data in affected applications and these IDNs may not be used for resolution purposes. The scenario you describe above is one such example - the To: field of an RFC822 message. 

The mail application (MUA) does not resolve the IDN within the To: field. Rather, it is the receiving MTA which does it. But yet, how the MUA formats the IDN within that RFC822 header is still important to us, and we do need to define that standard before vendors start doing their own thing and chaos would result.

Having said that, this discussion may not be in the scope of this WG (it belongs more to the Apps area, really) but perhaps the ADs would like to comment on this?

maynard

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 19 Mar 2001 21:08:18 -0800

The ugliest part of this approach is that code page identification, is at
best imprecise. For example, practically every vendor interprets the term
"JIS" slightly differently.

Mark

---

From: "Kenny Huang" <[email-masked]>
Date: Tue, 20 Mar 2001 13:44:08 +0800

-bws

Do you know any specific case or example regarding the question ? 
That case will be very important as the question has been 
discussed for years. 

We are very interested in the security issue, especially the testbed
is being operated in a national scale.

Thanks

Kenny Huang

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 20 Mar 2001 15:11:08 +0800

I can answer that ;-)

To be exact, there is no codepage. ML1, ML2, ML3, ML4 are just binary
string of an IDNs representation, irregardless of codepage or encodings.

But yes, this means there need to be 13++ (Shift-JIS, GBK, BIG5,
KSC5601, ISO2022-JP, ISO2022-KR, ISO2022-CN, ISO2022-TW, EUC-KR, EUC-CN,
EUC-TW, EUC-JP, UTF-8) binary representation for a two han ideographic
name...

-James Seng