Subject: Re: DDNS-DHCP [5]: IDN in DDNS-DHCP docs

From: Ralph Droms <[email-masked]>
Date: Wed, 02 Jul 2003 13:01:48 -0400

There has been no discussion of this issue.  We need
additional discussion on the mailing list to determine
WG consensus on the resolution of this issue.

- Ralph

At 07:01 AM 6/6/2003 -0400, Ralph Droms wrote:

>DDNS-DHCP issue:
>
>    The IDN WG has concluded and the results of its work should be
>    considered in the DDNS-DHCP documents.  The changes may be as
>    minimal as specifying the use of the IDN on-the-wire format.
>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/namedroppers/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Jul 2003 19:16:41 +0000

> >    minimal as specifying the use of the IDN on-the-wire format.

I think the reason for the lack of discussion is that this is a non-issue - 
the reason we went to using the DNS wire format was to avoid having to deal 
with this issue later.   I think that if the IDN folks think there is a 
problem here, they should say what it is and propose a solution.   I don't 
think there is a problem.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 02 Jul 2003 15:28:19 -0400

I think I read that draft-ietf-dhc-fqdn-option-05.txt
only refers to "DNS encoding as specified in RFC1035".
Is there a need for an additional reference, perhaps
to RFC 3490?  Or is the internationalization transparent
to the FQDN option?

- Ralph

---

From: Mark Stapp <[email-masked]>
Date: Wed, 02 Jul 2003 17:11:50 -0400

Issue [5] just states that there was a wg that concluded. I'm not aware of 
any issues raised by that wg, based on my (admittedly limited) 
understanding of their work. rfc3490, sec 1.1 states that no changes or 
demands are made on DNS servers, and I think that the idn work involved the 
user-visible parts of applications, and techniques for rendering unicode 
into canonical dns encoding. Once something's in dns encoding, the existing 
dns rules apply to it. The dhcp/dns drafts only use dns encoding, excepting 
only the special description of the legacy behavior of older clients which 
might use the fqdn option.

-- Mark

At 01:01 PM 7/2/2003 -0400, Ralph Droms wrote:
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 2 Jul 2003 23:12:41 +0200 (CEST)

> to RFC 3490?  Or is the internationalization transparent

It might make sense to add a note saying that Internationalized Domain
Names are encoded using an ASCII compatible encoding as specified in
RFC 3490.

  Erik

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 3 Jul 2003 20:25:15 +0859 ()

Ted;

> with this issue later.

Right!

It is merely that IDN is hopeless, primarily because Unicode is
hopeless. As has been proven for these 10 years, that Microsoft and
other commercial entities are insisting on Unicode does not make it
hopeful.

> I think that if the IDN folks think there is a 

The problem of them is that they must admit Unicode is hopeless and
propose a solution to abandan it, which will take time of yet
another few decades.

Unless you want to waste the decades, just ignore IDN.

							Masataka Ohta

PS

IPv6 is hopeless too, which is why IPv6 folks is trying to push
their problems to other WGs, which is why interaction between IPv6
and DNS is obscure.  But, it should be admitted that IPv6 is a lot
better than Unicode, especially after multihoming issues are solved
end to end.

PPS

DHCP is the right way to go for any kind of autoconfiguration. It
properly recognized roles of routers. On the other hand, half hearted
attempt of stateless autoconfiguration of Neighbor Discovery is hopeless,
because it expects too much on routers as the intermediate intelligent
entities.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 4 Jul 2003 14:11:13 +0200

[Warning: probably off-topic]

On Thu, Jul 03, 2003 at 08:25:15PM +0859,
 Masataka Ohta <[email-masked]> wrote 
 a message of 52 lines which said:

> propose a solution to abandan it, 

Yes, what is the alternative to Unicode? (Except switching to English
and US-ASCII.)

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 4 Jul 2003 21:46:37 +0859 ()

Stephane;

> Yes, what is the alternative to Unicode? (Except switching to English

As a Japanese using Japanese characters daily over the Internet,
ASCII only communication is no solution.

The solution, of course, has been ISO 2022. See RFC 1554 for details
on how efficient and stateless it can be.

A sad history was that there was a wrong argument that state maintenance
of ISO 2022 were complex.

The reality is that it is simple switching treated by finite state
automaton.

It should now be easily recognized that, given the complex state
transition of Unicode, which essentially needs push down automaton,
you can't say state transition of ISO 2022 complex,

Moreover, it has been well known that state transition of ISO 2022
can be simplified a lot to be almost stateless as is documented in
RFC1468 in 1993.

Note that, in Japan, Unicode is not used at all and ISO 2022
and Shift JIS (a skewed ISO 2022) are the encoding.

Situation is not so different in Europe and ISO 8859/1.

See RFC 1815 on poor performance of Unicode.

						Masataka Ohta

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 04 Jul 2003 09:29:35 -0400

Masataka San,

The comments of the CDNC and JET to the IETF circa London and Salt Lake
are to the same point.

Eric

---

From: James Seng <[email-masked]>
Date: Sun, 06 Jul 2003 22:51:44 +0800

I dont remember similar statement from JET made to IETF similar to what 
Masataka-san made.

I mean, considering I am also a member of JET and you are not, one of us 
obviously have a memory gap.

-James Seng