Subject: [idn] Re: converter page?

From: Simon Josefsson <[email-masked]>
Date: Sun, 02 Mar 2003 01:10:08 +0100

"Eric A. Hall" <[email-masked]> writes:

> Anybody know of a web form that does IDNA conversion on-the-fly? Something
> that will let me enter the domain name and get the IDNA encoded form back.
> I find myself needing to do do some quicky conversions periodically.

<http://josefsson.org/idn.php>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 3 Mar 2003 10:29:31 +0100

On Fri, Feb 28, 2003 at 11:51:52AM -0600,
 Eric A. Hall <[email-masked]> wrote 

> that will let me enter the domain name and get the IDNA encoded form back.

http://tac.eureg.org/idn.cgi

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 03 Mar 2003 17:50:22 +0100

>http://tac.eureg.org/idn.cgi

Interesting service. Bravo!
May I suggest two few things?

1. could you also report the Unicode version un U+ format? (it would be 
convenient for characters not supported on the resquester's terminal)

2. I understand that when an xn--ascii string cannot be transcoded the 
response if first at internal service error and then the copyof the ASCII 
request. May be an easy thing to fix?

Is the code available?
Thank you. jfc

---

From: Martin Duerst <[email-masked]>
Date: Sat, 08 Mar 2003 15:31:07 -0500

Hello Simon,

Very nice to put up such a script.

It would be great if the default page was served as UTF-8.
That way, on any recent browser, any user can just copy/paste
or type in their idn and submit the query, without having to
worry about encoding issues.

Using various different encodings the way you do is exposing
your system internals in a way the Web was designed (and is
implemented) to abstract from.

The 'force charset to' drop-down menu is particularly dangerous,
because it does not force the browser to send the characters
that the user has pasted or input to the server in that encoding,
it just forces the server to MISinterpret the octets that the
browser sent.

At the top of the page, you write:
    Report problems to [email-masked], but first please make sure your
    browser really is encoding the data you type in the charset you select.
    If not, incorrect output or an error is the proper response.

This is heavily backwards. The browser will do the right thing if
you just allow it to do so, and don't allow the user to mess
around with it.

Also, some browsers tend to send named or numeric character references
when characters in a text field are outside of the encoding of the
page. That as such is non-standard, and you don't necessarily
have to deal with it. However, you should make sure that the
output you send back is properly escaped. For example not

$ echo 'D&uuml;rst.josefsson.org' | /usr/local/bin/idn --idna-to-ascii 2>&1

but

$ echo 'D&amp;uuml;rst.josefsson.org' | /usr/local/bin/idn --idna-to-ascii 
2>&amp;1

Regards,    Martin.

P.S.:

I tested this with several browsers. With IE, there were difficulties
to interpret the encoding of your page correctly in the first place.
My current guess is that this is due to the fact that you use additional
double quotes in
<meta http-equiv='Content-Type' content='text/html; charset="ISO-8859-1"' />,
instead of simply
<meta http-equiv='Content-Type' content='text/html; charset=ISO-8859-1' />
I might be wrong, but other than that, I can't see any reason at the moment.
(you should also make sure that you properly escape the '&' in
things such as "&mode=toascii&charset=UTF-8").

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 08 Mar 2003 23:00:25 +0100

> Very nice to put up such a script.

I believe I have fixed the problems you mention, thanks for taking the
time to point them out.

> worry about encoding issues.

The page is served in the charset you select.  Chose UTF-8 if you want
UTF-8.  Only supporting UTF-8 would restrict the page's usefulness.
Standards compliant browsers handle charset conversions in copy/paste.

> you just allow it to do so, and don't allow the user to mess

I have tried to make the intended behaviour more clear.  You must type
characters in the charset the page uses.  If you want to use another
charset, it is a two step process: first change charset, then enter
new data.

> $ echo 'D&amp;uuml;rst.josefsson.org' | /usr/local/bin/idn
> --idna-to-ascii 2>&amp;1

Since it is non-standard, I'll deal with it using the garbage in
garbage out philosophy.  Someone might even find the current behaviour
useful.

> I might be wrong, but other than that, I can't see any reason at the moment.

I don't see anything wrong with the code, and I don't have access to
IE to test this further.  If you, or someone else, wants to
investigate this further, it would be appreciated.

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Mar 2003 16:59:35 -0500

Simon,

Let me make one additional suggestion, which is sort of 
orthogonal to Martin's...  It would be useful, as an alternative 
to UTF-8 and the other encodings you support, to be able to put 
in a string of characters as a list of items in U+nnnn form. 
You show that form in your debugging option, but, if the 
characters going in don't match what you produce, there is no 
obvious way to provide them.  I'm particularly concerned here 
about characters my browser has no way to render (e.g., 
appropriate fonts not installed, etc.)

The script/web page itself is much appreciated.

thanks,
    john

--On Saturday, 08 March, 2003 15:31 -0500 Martin Duerst 
<[email-masked]> wrote:

> The 'force charset to' drop-down menu is particularly
> dangerous, because it does not force the browser to send the
> characters that the user has pasted or input to the server in
> that encoding, it just forces the server to MISinterpret the
> octets that the browser sent.
>
>     Report problems to [email-masked], but first please
> make sure your     browser really is encoding the data you
> type in the charset you select.     If not, incorrect output
> or an error is the proper response.
>
> This is heavily backwards. The browser will do the right thing
> if you just allow it to do so, and don't allow the user to mess
> around with it.
>
> Also, some browsers tend to send named or numeric character
> references when characters in a text field are outside of the
> encoding of the page. That as such is non-standard, and you
> don't necessarily have to deal with it. However, you should
> make sure that the output you send back is properly escaped.
> For example not
>
> I tested this with several browsers. With IE, there were
> difficulties to interpret the encoding of your page correctly
> in the first place. My current guess is that this is due to
> the fact that you use additional double quotes in
> <meta http-equiv='Content-Type' content='text/html;
> charset="ISO-8859-1"' />, instead of simply
> <meta http-equiv='Content-Type' content='text/html;
> charset=ISO-8859-1' /> I might be wrong, but other than that,
> I can't see any reason at the moment. (you should also make
> sure that you properly escape the '&' in things such as
> "&mode=toascii&charset=UTF-8").
>
>
>
>> > Anybody know of a web form that does IDNA conversion
>> > on-the-fly? Something that will let me enter the domain
>> > name and get the IDNA encoded form back. I find myself
>> > needing to do do some quicky conversions periodically.
>>

---

From: Martin Duerst <[email-masked]>
Date: Sat, 08 Mar 2003 19:11:48 -0500

Hello Simon,

Many thanks for your quick reply.

>I believe I have fixed the problems you mention, thanks for taking the

Well, my impression is that you have fixed some, but not all.

>The page is served in the charset you select.

No. When I go to http://josefsson.org/idn.php, I didn't
select iso-8859-1. In fact, my main browser (Netscape 7) sends you
Accept-Charset: UTF-8, *
in its HTTP headers. For the others I used, Opera7 sends
Accept-Charset: windows-1252,utf-8,utf-16,iso-8859-1;q=0.6,*;q=0.1
whereas IE6 and Tango don't send anything. Both Netscape 7
and Opera clearly express a preference for UTF-8 over iso-8859-1.

>Chose UTF-8 if you want

Yes, slightly, because of some old browsers.
But I never said that you have to support only UTF-8.

>Standards compliant browsers handle charset conversions in copy/paste.

Well, yes, they handle character encoding conversion in copy/paste.
They convert from the encoding used in the clipboard to their
internal (unicode-based) encoding. That's why
you should avoid confusing the user with 'charset' stuff.

>charset, it is a two step process: first change charset, then enter

Are you referring to "The following string must be in ISO-8859-1.
If you wish to use another charset you must select it below, submit
the form and wait for a new page, and then enter your string." ?

This shows a confusion of two concepts: The set (also called repertoire)
of characters covered by an encoding, and the actual encoding of these
characters into bytes.

The term 'charset' refers to the later rather than the former.
But the user of a standard browser has no way to input something
in a particular encoding, because the browser takes care of
doing the right conversions. So what you wanted to say was
something like:

"The following string must only contain characters that can be
represented in ISO-8859-1."

Obviously, such a warning is not at all needed for UTF-8.
So the best thing is to start with UTF-8, and let the user
just input her characters, and then have some fallback
page (e.g. triggered by checking whether you really get
UTF-8 back) so users with outdated browsers also have a chance.

>garbage out philosophy.  Someone might even find the current behaviour

But there are cases where you produce garbage on your own.
For example, if I input &uuml;<u">.josefsson.org,
  &uuml; followed by an actual u-umlaut, (where <u"> is actually an u-umlaut),
and switch on UseSTD3ASCIIRules, I get:
/usr/local/bin/idn: idna_to_ascii_from_locale() failed with error 3.
which I guess means IDNA_CONTAINS_LDH = 3.
Now if I switch off UseSTD3ASCIIRules and use the same input,
what I see as a result is xn--<u">-8ya.josefsson.org. The correct
result is of course xn--&uuml;-8ya.josefsson.org, which is in the
source, but not visible. So you have to fix the source to
be xn--&amp;uuml;-8ya.josefsson.org.

>investigate this further, it would be appreciated.

Strictly speaking,
<meta http-equiv='Content-Type' content='text/html; charset="ISO-8859-1"' />
is okay. But I have confirmed that IE (version 6, on Win2000) works well
without the additional quotes, but not with them.

Regards,    Martin.

---

From: "James Seng" <[email-masked]>
Date: Sun, 9 Mar 2003 09:46:47 +0800

The one I love to use is this:

http://www.macchiato.com/unicode/convert.html

with almost all the features you need *except* punycode ;P

-James Seng

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 09 Mar 2003 14:15:38 +0100

> and Opera clearly express a preference for UTF-8 over iso-8859-1.

All your clients support ISO-8859-1, and it makes things easier for me
(I don't have fully working UTF-8 editor on the web server host), so
ISO-8859-1 seemed like a good choice.  ISO-8859-1 is mentioned more
prominently than UTF-8 in HTML 3.2 and HTTP 1.1, so it should be more
interoperable too.

But okay, I have changed to UTF-8 by default.

> you should avoid confusing the user with 'charset' stuff.

It is a debugging tool for libidn, I expect users to at least be aware
of charset stuff.

As it happens, one of the browsers I use to test the page uses mule
for the internal encoding, and has incomplete unicode support, so
moving the page to UTF-8 forces me to select ISO-8859-1 and reload the
page.

Honestly, the only advantage of moving to UTF-8 for the page I can see
is if there is a browser out there that supports UTF-8 but not
ISO-8859-1.  Since HTML 3.2 and HTTP 1.1 uses ISO-8859-1 that browser
would be broken anyway.

> represented in ISO-8859-1."

Thanks, I'm using it now.

> result is of course &uuml;ü.josefsson.org, which is in the

Ah, true.  I'll see if there is a handy function for escaping...

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 10 Mar 2003 08:40:16 +0100

Does someone know about a clean/simple site user could call to know what is 
the UTF-8 of the ACE label they receive? thank you. jfc

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 10 Mar 2003 09:07:40 -0800

On the ICU site there is a page that you might find helpful. For example, if
you input text with foreign characters, like

     Počítače; Οι ηλεκτρονικοί.

and set Compound 1 to

     \P{ascii}  hex

you'll get

Po\u010D\u00EDta\u010De; \u039F\u03B9
\u03B7\u03BB\u03B5\u03BA\u03C4\u03C1\u03BF\u03BD\u03B9\u03BA\u03BF\u03AF.

You can also use "\P{ascii} hex/unicode" to get this format:

PoU+010DU+00EDtaU+010De; U+039FU+03B9
U+03B7U+03BBU+03B5U+03BAU+03C4U+03C1U+03BFU+03BDU+03B9U+03BAU+03BFU+03AF.

And if you want the character names, you can use "\P{ascii} name":

Po\N{LATIN SMALL LETTER C WITH CARON}\N{LATIN SMALL LETTER I WITH
ACUTE}ta\N{LATIN SMALL LETTER C WITH CARON}e; \N{GREEK CAPITAL LETTER
OMICRON}\N{GREEK SMALL LETTER IOTA} \N{GREEK SMALL LETTER ETA}\N{GREEK SMALL
LETTER LAMDA}\N{GREEK SMALL LETTER EPSILON}\N{GREEK SMALL LETTER
KAPPA}\N{GREEK SMALL LETTER TAU}\N{GREEK SMALL LETTER RHO}\N{GREEK SMALL
LETTER OMICRON}\N{GREEK SMALL LETTER NU}\N{GREEK SMALL LETTER IOTA}\N{GREEK
SMALL LETTER KAPPA}\N{GREEK SMALL LETTER OMICRON}\N{GREEK SMALL LETTER IOTA
WITH TONOS}.

(The "\P{ascii}" is a filter, added so that none of the above affect the
ASCII contents.)

Or use "Latin" to get

Počítače? Oi ēlektronikoí.

You could also use "Latin; nfd; \p{mark} remove; nfc" to strip accents,
getting:

Pocitace? Oi elektronikoi.

Mark
________
[email-masked]
IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193
(408) 256-3148
fax: (408) 256-0799

---

From: Martin Duerst <[email-masked]>
Date: Mon, 10 Mar 2003 16:15:42 -0500

At 09:07 03/03/10 -0800, Mark Davis wrote:
>On the ICU site there is a page that you might find helpful.

Would be helpful to know which page that is.
(that's what URIs have been invented for, after all :-).

Regards,    Martin.

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 10 Mar 2003 16:24:41 -0800

Whoops, here it is:

http://oss.software.ibm.com/cgi-bin/icu/tr

Mark
________
[email-masked]

----- Original Message -----
From: "Martin Duerst" <[email-masked]>
To: "Mark Davis" <[email-masked]>; "John C Klensin" <[email-masked]>;
"Simon Josefsson" <[email-masked]>
Cc: "IDN" <[email-masked]>
Sent: Monday, March 10, 2003 13:15
Subject: Re: [idn] Re: converter page?

---

From: Martin Duerst <[email-masked]>
Date: Fri, 21 Mar 2003 20:47:02 -0500

Hello everybody,

Thanks to idnkit, I now have a version of Amaya that should correctly
look up websites with IDNs. However, just verifying punycode with a
debugger isn't much fun :-(.

Can anybody (here or in private) tell me about operational
(or pre-operational) IDNs, preferably running http and serving
a web page at port 80?

Many thanks in advance,   Martin.

---

From: "Martin v. Löwis" <[email-masked]>
Date: Sat, 22 Mar 2003 22:08:15 +0100

> (or pre-operational) IDNs, preferably running http and serving

The .nu operator supports IDNA, among other things (you also
can sent UTF-8 and various local encodings to their DNS servers).

See www.nunames.org for a list of supported example domains,
e.g. http://www.bravå.nu. Notice that they *always* send a page
back, which is a frame set whose only page refers to the real
content (if the hostname is valid). Also notice that they don't
support HTTP 1.0, and resolve all supported hosts to the same IP,
so you have to put the IDNA name also into the Host: header.

HTH,
Martin

P.S. On a related issue: I was wondering whether this is proper
operation of IDNA with HTTP, i.e. whether the ToASCII version
of the host should be put into the Host: header. The obvious
alternative would be to put a MIME-encoded version of the host
name into the Host: field, but RFC 2616 is silent on whether
this is allowed or not (they say that HTTP is "MIME-like")

---

From: "James Seng" <[email-masked]>
Date: Sun, 23 Mar 2003 08:06:20 +0800

> can sent UTF-8 and various local encodings to their DNS servers).

This sound bad. This is breaking the basic functionity of DNS.

<whinning>This reminded me: Various registries have contacted me regarding
how to deploy IDN, should they wish to. At least two of them have mention
that some company in Toronto have told them they can deploy IDN using "just
DNS servers only", customized made I supposed.

Obviously, IETF (or I for that matter) cannot tell anyone what they must do,
how to market their product, or how to deploy it.

But when someone asked me "Are you sure I need to get some client deploy for
IDN? They told me I could just deploy their DNS servers to support IDN.", I
have to explain IETF standardization, the pros & cons from technical &
business perspective, and why they *really* dont want to do so IMO.

I have to do it twice now and it is not fun (not that I get paid for doing
so either). Of course I am chessed off by this Toronto company! Couldnt they
just do their own marketing and educating their potential customer
properly?</whinning>

> this is allowed or not (they say that HTTP is "MIME-like")

RFC 2616 is silent. But IDNA did specify that for any other protocols,
unless it is updated to handle IDN, we will default the encoding to be
Punycode. So yes, Punycode should be used in Host:.

-James Seng

---

From: "J. William Semich" <[email-masked]>
Date: Sat, 22 Mar 2003 19:50:54 -0500

FYI, .nu only supports ASCII zone files in it's implementation of IDN. Any 
redirects of non-ASCII HTTP requests follow the RFCs. This would be pretty 
simple for anyone to verify.

Cheers,

Bill Semich

---

From: "J. William Semich" <[email-masked]>
Date: Sat, 22 Mar 2003 22:40:40 -0500

FYI,  for anodyne testing an IDNA whois client, .nu also supports IDNA and 
punycode queries to our whois server at whois.worldnames.net - again using 
the sample domain names on our site or any of the other registered names in .nu

Cheers,

Bill Semich

At 04:08 PM 3/22/2003, Martin v. Löwis wrote:

>e.g. http://www.bravå.nu.

---

From: [email-masked] (Martin v. Löwis)
Date: 23 Mar 2003 09:41:14 +0100

> This sound bad. This is breaking the basic functionity of DNS.

Can you elaborate? How does this break anything? They respond to
strictly erroneous requests, with erroneous responses. I can't see
how this could cause failures of other participants of the DNS.

> Punycode. So yes, Punycode should be used in Host:.

That is not convincing. RFC 3490 says

   In protocols and document formats that define how to handle
   specification or negotiation of charsets, labels can be encoded in
   any charset allowed by the protocol or document format.  If a
   protocol or document format only allows one charset, the labels MUST
   be given in that charset.

So, I *could* interpret RFC 2616 as defining how to handle
specification of charsets, as it is "MIME-like". Therefore, I infer that
sending

MIME-Version: 1.0
Host: =?iso-8859-1?q?www=2Ebrav=E5=2Enu?=

is conforming to both RFC 3490 and RFC 2616.

Regards,
Martin

---

From: [email-masked] (Martin v. Löwis)
Date: 23 Mar 2003 10:20:13 +0100

"J. William Semich" <[email-masked]> writes:

> FYI, .nu only supports ASCII zone files in it's implementation of
> IDN. Any redirects of non-ASCII HTTP requests follow the RFCs. This
> would be pretty simple for anyone to verify.

Please have a look at the attached tcpdump output. It is a DNS
response, sent in response to MSIE6 querying www.tegumeå.nu.  It shows
the .nu nameservers do respond with non-ASCII labels (which, in this
case, are meant to be interpreted as Latin-1).

Regards,
Martin

Frame 2 (248 bytes on wire, 248 bytes captured)
    Arrival Time: Mar 23, 2003 09:57:52.442733000
    Time delta from previous packet: 0.081533000 seconds
    Time relative to first packet: 0.081533000 seconds
    Frame Number: 2
    Packet Length: 248 bytes
    Capture Length: 248 bytes
Internet Protocol, Src Addr: 217.5.100.1 (217.5.100.1), Dst Addr: 217.232.37.57 (217.232.37.57)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 226
    Identification: 0x1f43
    Flags: 0x00
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 57
    Protocol: UDP (0x11)
    Header checksum: 0x25a0 (correct)
    Source: 217.5.100.1 (217.5.100.1)
    Destination: 217.232.37.57 (217.232.37.57)
User Datagram Protocol, Src Port: domain (53), Dst Port: 3013 (3013)
    Source port: domain (53)
    Destination port: 3013 (3013)
    Length: 206
    Checksum: 0x7bfe (correct)
Domain Name System (response)
    Transaction ID: 0x000b
    Flags: 0x8180 (Standard query response, No error)
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .0.. .... .... = Authoritative: Server is not an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... 1... .... = Recursion available: Server can do recursive queries
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... .... 0000 = Reply code: No error (0)
    Questions: 1
    Answer RRs: 2
    Authority RRs: 6
    Additional RRs: 0
    Queries
        www.tegumeå.nu: type A, class inet
            Name: www.tegumeå.nu
            Type: Host address
            Class: inet
    Answers
        www.tegumeå.nu: type A, class inet, addr 212.181.91.6
            Name: www.tegumeå.nu
            Type: Host address
            Class: inet
            Time to live: 1 day
            Data length: 4
            Addr: 212.181.91.6
        www.tegumeå.nu: type A, class inet, addr 64.55.105.9
            Name: www.tegumeå.nu
            Type: Host address
            Class: inet
            Time to live: 1 day
            Data length: 4
            Addr: 64.55.105.9
    Authoritative nameservers
        nu: type NS, class inet, ns ns0.de.nic.nu
            Name: nu
            Type: Authoritative name server
            Class: inet
            Time to live: 1 day
            Data length: 13
            Name server: ns0.de.nic.nu
        nu: type NS, class inet, ns ns0.telia.nic.nu
            Name: nu
            Type: Authoritative name server
            Class: inet
            Time to live: 1 day
            Data length: 12
            Name server: ns0.telia.nic.nu
        nu: type NS, class inet, ns tld1.ultradns.net
            Name: nu
            Type: Authoritative name server
            Class: inet
            Time to live: 1 day
            Data length: 19
            Name server: tld1.ultradns.net
        nu: type NS, class inet, ns tld2.ultradns.net
            Name: nu
            Type: Authoritative name server
            Class: inet
            Time to live: 1 day
            Data length: 7
            Name server: tld2.ultradns.net
        nu: type NS, class inet, ns ns.nic.nu
            Name: nu
            Type: Authoritative name server
            Class: inet
            Time to live: 1 day
            Data length: 5
            Name server: ns.nic.nu
        nu: type NS, class inet, ns nz.ns.nic.nu
            Name: nu
            Type: Authoritative name server
            Class: inet
            Time to live: 1 day
            Data length: 5
            Name server: nz.ns.nic.nu

0000  00 50 bf 55 39 1b 00 90 1a 10 16 46 88 64 11 00   .P.U9......F.d..
0010  0c 46 00 e4 00 21 45 00 00 e2 1f 43 00 00 39 11   .F...!E....C..9.
0020  25 a0 d9 05 64 01 d9 e8 25 39 00 35 0b c5 00 ce   %...d...%9.5....
0030  7b fe 00 0b 81 80 00 01 00 02 00 06 00 00 03 77   {..............w
0040  77 77 08 74 65 67 75 6d 65 c3 a5 02 6e 75 00 00   ww.tegume...nu..
0050  01 00 01 c0 0c 00 01 00 01 00 01 51 80 00 04 d4   ...........Q....
0060  b5 5b 06 c0 0c 00 01 00 01 00 01 51 80 00 04 40   .[.........Q...@
0070  37 69 09 c0 19 00 02 00 01 00 01 51 80 00 0d 03   7i.........Q....
0080  6e 73 30 02 64 65 03 6e 69 63 c0 19 c0 19 00 02   ns0.de.nic......
0090  00 01 00 01 51 80 00 0c 03 6e 73 30 05 74 65 6c   ....Q....ns0.tel
00a0  69 61 c0 54 c0 19 00 02 00 01 00 01 51 80 00 13   ia.T........Q...
00b0  04 74 6c 64 31 08 75 6c 74 72 61 64 6e 73 03 6e   .tld1.ultradns.n
00c0  65 74 00 c0 19 00 02 00 01 00 01 51 80 00 07 04   et.........Q....
00d0  74 6c 64 32 c0 83 c0 19 00 02 00 01 00 01 51 80   tld2..........Q.
00e0  00 05 02 6e 73 c0 54 c0 19 00 02 00 01 00 01 51   ...ns.T........Q
00f0  80 00 05 02 6e 7a c0 b0                           ....nz..

---

From: "Marco d'Itri" <[email-masked]>
Date: Sun, 23 Mar 2003 12:48:45 +0100

>(or pre-operational) IDNs, preferably running http and serving
Yesterday I enabled http://€.linux.it/ just for this kind of tests.
It has IPv6 connectivity and can receive mail.

BTW, I'd like to know if anybody has been able to use mozilla or galeon
with IDNs, I tried rececent CVS snapshots of both and could not make
them work, even after reading mozilla bug #112169:
http://bugzilla.mozilla.org/attachment.cgi?id=112169&action=view

-- 
ciao,
Marco

---

From: "Edmon Chung" <[email-masked]>
Date: Sun, 23 Mar 2003 08:03:07 -0500

Hi James,

If you are discussing about Neteka, I think you must be misguided in your
discussions.

Neteka supports the IDNA standards and we try to accomodate to the needs of
registries.  In fact we are scheduled to start publishing Punycode to TLD
zones that we work with in the very near term.  While I can understand your
obsession about clients and plugins, asking each registry to create a
"client" is not realistic!  Most will look to Microsoft or Netscape or other
browsers/DNS applications to be upgraded over time to IDNA.  Registries are
not DNS resolver or browser vendors.

Meanwhile, registries really should be exerting some energy in preparing for
their "servers" for IDN registrations (and NOT the resolution side as you
have probably gotten mixed up with).  For example handling registrations and
management of multilingual domain names within registration databases,
considering character equivalence issues and provisioning, defining zone
publishing policies for IDNs, etc. all of these are critical to the success
of the deployment of IDN.  And this is where Neteka mainly focuses on
working with registries and preparing their "servers" to accept IDN
registrations from their end-users.

I hope this clarifies Neteka's works for you and others. :-)

Edmon

---

From: "James Seng" <[email-masked]>
Date: Sun, 23 Mar 2003 21:46:08 +0800

No, I am not "misguided" whatever that means. I am repeating what the people
asked me.

Neither did I ask them to develop a client, or not to.

Lastly, in your private mail to me, you mention that you have not advertise
any server-side resolution solution. Could you confirm this in public?

Once you do, I will forward your response to the registries who have told me
"they said they can provide a DNS server that can resolve IDN" to put the
end to their misconceptions.

-James Seng

----- Original Message -----
From: "Edmon Chung" <[email-masked]>
To: "James Seng" <[email-masked]>; "IDN" <[email-masked]>
Sent: Sunday, March 23, 2003 9:03 PM
Subject: Re: [idn] IDN eamples for testing

> > IDN? They told me I could just deploy their DNS servers to support
IDN.",
> I

---

From: "James Seng" <[email-masked]>
Date: Sun, 23 Mar 2003 22:03:47 +0800

> how this could cause failures of other participants of the DNS.

Two wrong dont make it right. Nothing in RFC 1034 & 1035 mention the DNS
should response error with error.

> is conforming to both RFC 3490 and RFC 2616.

According to RFC 2616, the BNF for Host header is as follows:

    Host = "Host" ":" host [ ":" port ]

And "host" is adopted from RFC 2396,

      host          = hostname | IPv4address
      hostname      = *( domainlabel "." ) toplabel [ "." ]
      domainlabel   = alphanum | alphanum *( alphanum | "-" ) alphanum
      toplabel      = alpha | alpha *( alphanum | "-" ) alphanum

So by this definition, a header like "Host:
=?iso-8859-1?q?www=2Ebrav=E5=2Enu?=" is not conforming to RFC 2616.

-James Seng

---

From: "Edmon Chung" <[email-masked]>
Date: Sun, 23 Mar 2003 09:14:28 -0500

Hi James,

Allow me to clarify again, in terms of IDN, Neteka focuses on helping
registries to understand the registration issues, including character
equivalence preparations, the implications to provisioning protocols that
they are using, finally the zone preparation and publishing policies
including equivalency preparation issues.

All of which are IDNA driven. However, in many cases, databases and
provisioning will likely not be using Punycode, because it likely makes more
sense to store UTF8 or Local Encoding in local databases for all intents and
purposes.  This includes administration of IDNs as well.  So, the servers
does take care of the conversion between UTF8/16/LocalEncoding to Punycode
at the zonefile for the DNS.  So I am not sure which part you are alluding
to.

Anyway, I wish not to continue to advertise our services in this forum
because it is not right.  However I must clarify that we are very supportive
of the standard and we are urging TLDs and other relevant parties to make
appropriate preparations for the challenges of IDNs beyond simply the
"client", because there are a lot of administrative and operational issues
as well as transition and migration issues that warrant attention.

Edmon

----- Original Message -----
From: "James Seng" <[email-masked]>
To: "Edmon Chung" <[email-masked]>; "IDN" <[email-masked]>
Sent: Sunday, March 23, 2003 8:46 AM
Subject: Re: [idn] IDN eamples for testing

> > > Obviously, IETF (or I for that matter) cannot tell anyone what they
must
> > do,
> > > But when someone asked me "Are you sure I need to get some client
deploy
> > for
> > > so either). Of course I am chessed off by this Toronto company!
Couldnt
> > they

---

From: "James Seng" <[email-masked]>
Date: Sun, 23 Mar 2003 22:33:10 +0800

Would prefer if you just answer a simple yes and no to the following
question:

    Did Neteka advertise a server-side resolution DNS?

It is not my business to tell you if you should or should not. I just want
to clarify if you have advertise such a product or not.

ps: It is simple question. I would appreciate a simple yes & no answer. I am
not interested in any of your other product as your long email below
described.

-James Seng

----- Original Message -----
From: "Edmon Chung" <[email-masked]>
To: "James Seng" <[email-masked]>; "IDN" <[email-masked]>
Sent: Sunday, March 23, 2003 10:14 PM
Subject: Re: [idn] IDN eamples for testing

> > Once you do, I will forward your response to the registries who have
told
> me
> > > Neteka supports the IDNA standards and we try to accomodate to the
needs
> > of
> > > browsers/DNS applications to be upgraded over time to IDNA.
Registries
> > are
> > > Meanwhile, registries really should be exerting some energy in
preparing
> > > have probably gotten mixed up with).  For example handling
registrations
> > and
> > > > that some company in Toronto have told them they can deploy IDN
using
> > > "just

---

From: "Martin v. Löwis" <[email-masked]>
Date: Sun, 23 Mar 2003 15:37:52 +0100

> should response error with error.

Certainly correct, and I completely agree that such a server is not 
following the DNS RFCs. However, I was specially asking how this 
protocol violation is "breaking the basic functionity of DNS".

> And "host" is adopted from RFC 2396,

Ah, I see. That was not clear to me, as section 14.23 refers to
section 3.2.2 only, which does not refer further (although 3.2.1
does, which I missed).

Regards,
Martin

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 23 Mar 2003 15:38:54 +0100

> should response error with error.

Garbage in, garbage out.  If returning one particular kind of garbage
to one common client that sends garbage works, then this is what
people will do.  It doesn't violate technical DNS specifications,
since technical specifications by definition cannot regulate things
that isn't part of the protocol.  It may violate an operational DNS
specification or BCP, but I'm not aware of such documents.

---

From: "Edmon Chung" <[email-masked]>
Date: Sun, 23 Mar 2003 09:58:12 -0500

Hi James,

I think I have made it quite clear.
Neteka provides tools, products and services for all facets of TLD registry
systems.

----- Original Message -----
>     Did Neteka advertise a server-side resolution DNS?

Of course DNS resolution includes a server-side element.
If you are asking about IDN, we resolve Punycode.
If you are asking about Punycode conversion, yes our servers do that for
administration and DNS Zone preparations.

If this is not clear enough for you, I am happy to discuss with you
off-list.

Edmon

PS.  I have recently been working on a number of documents on IDN
Operations, that discusses mainly issues around character equivalence
preparation and management.  More specifically taking the discussional
IDN-ADMIN document to create a more generic technical framework that is
capable of allowing different registries to develop their policies freely,
yet driving towards a standard EPP implementation that could take care of
the different needs of registries.  Since this is not the right forum for
this particular discussion, I have not included the documents.  But I will
be more than happy to share it with anyone who might be interested and
comments will be very valuable to help improve the documents.

> > > > registries.  In fact we are scheduled to start publishing Punycode
to
> > TLD
> > > > zones that we work with in the very near term.  While I can
understand
> > > your
> > > > "client" is not realistic!  Most will look to Microsoft or Netscape
or
> > > other
> > > > their "servers" for IDN registrations (and NOT the resolution side
as
> > you
> > > > > have to explain IETF standardization, the pros & cons from
technical
> &
> > > > > I have to do it twice now and it is not fun (not that I get paid
for
> > > doing
> > > > > unless it is updated to handle IDN, we will default the encoding
to
> be

---

From: "James Seng" <[email-masked]>
Date: Sun, 23 Mar 2003 23:04:12 +0800

Okay, perhaps I shouldnt say it is "breaking DNS" but it certainly not
conforming to the DNS specification.

Secondly, such solution deployed outside a testbed/trials would only hinder
us from moving to a UTF-8 or other binary solution in future.

-James Seng

---

From: "James Seng" <[email-masked]>
Date: Sun, 23 Mar 2003 23:05:59 +0800

Please dont obscure it by marketing talk.

Is that a yes or no? I dont want to misinterpret your email.

-James Seng

----- Original Message -----
From: "Edmon Chung" <[email-masked]>
To: "James Seng" <[email-masked]>; "IDN" <[email-masked]>
Sent: Sunday, March 23, 2003 10:58 PM
Subject: Re: [idn] IDN eamples for testing

> > ps: It is simple question. I would appreciate a simple yes & no answer.
I
> am
> > > provisioning will likely not be using Punycode, because it likely
makes
> > more
> > > sense to store UTF8 or Local Encoding in local databases for all
intents
> > > > No, I am not "misguided" whatever that means. I am repeating what
the
> > > people
> > > > "they said they can provide a DNS server that can resolve IDN" to
put
> > the
> > > > > If you are discussing about Neteka, I think you must be misguided
in
> > > > > obsession about clients and plugins, asking each registry to
create
> a
> > > > > considering character equivalence issues and provisioning,
defining
> > zone
> > > > > publishing policies for IDNs, etc. all of these are critical to
the
> > > > success
> > > > > > how to deploy IDN, should they wish to. At least two of them
have
> > > > mention

---

From: "Martin v. Löwis" <[email-masked]>
Date: Sun, 23 Mar 2003 16:16:28 +0100

> us from moving to a UTF-8 or other binary solution in future.

It depends. It wouldn't hinder "us" from moving to UTF-8; it appears 
that the .nu installation supports UTF-8 *today*. It is fairly easy
to recognize UTF-8: If it looks like UTF-8, it probably is. So allowing 
UTF-8 in DNS queries would not break their installation. Furthermore,
it would then still be possible to decide that certain non-conforming
installations will be broken by extension of the standard.

Regardless, I do believe that it is the clear intention of the .nu 
operators to phase out their proprietary extensions once all relevant 
clients have been updated to support IDNA.

Regards,
Martin

---

From: "James Seng" <[email-masked]>
Date: Sun, 23 Mar 2003 23:13:55 +0800

And no, I dont think we need to bring this offlist.

It would be better if this is discussed in public, so we can put the end of
this.

So, please answer a simple yes or no to my answer. And believe me, I have
long memory.

-James Seng

----- Original Message -----
From: "James Seng" <[email-masked]>
To: "Edmon Chung" <[email-masked]>; "IDN" <[email-masked]>
Sent: Sunday, March 23, 2003 11:05 PM
Subject: Re: [idn] IDN eamples for testing

> > > > > > of the deployment of IDN.  And this is where Neteka mainly
focuses
> > on
> > > > > > > <whinning>This reminded me: Various registries have contacted
me
> > > > > regarding

---

From: "J. William Semich" <[email-masked]>
Date: Sun, 23 Mar 2003 10:23:01 -0500

From RFC 1034:

"4.3.3.
Wildcards
In the previous algorithm, special treatment was given to RRs with owner 
names starting with the label "*". Such RRs are called wildcards. Wildcard 
RRs can be thought of as instructions for synthesizing RRs. "

 From the IAB comment on Verisign's implementation of IDN :

"5] The system deployed for .com and .net does not follow the specification 
for targets not in a zone. Instead, it examines the target and decides 
whether to give the specified negative response or a synthesized record 
based on whether the target contains a code point above 127. This is a 
violation of the DNS protocol as described in RFC 2308, Section 2.1. While 
it is possible within the DNS protocol to include *wildcard records* which 
cover all queries not otherwise specified by a zone, this is not what 
VeriSign has done." (emphasis added)

(see http://www.icann.org/correspondence/iab-message-to-lynn-25jan03.htm)

I see no breakage here.

Bill Semich

At 09:37 AM 3/23/2003, Martin v. Löwis wrote:
>following the DNS RFCs. However, I was specially asking how this protocol 
>violation is "breaking the basic functionity of DNS".
>

Bill Semich
President and CEO
.NU Domain Ltd
http://www.nunames.nu
[email-masked]
+1 508 359 5600 ext 110
See IDG's "IT Folk"
http://itfolk.idg.se/person.asp?n=william_j_semich&type=2

---

From: "Edmon Chung" <[email-masked]>
Date: Sun, 23 Mar 2003 10:29:14 -0500

You will not misinterpret me if you include my words in entirety and not try
to take anything out of context.
IDN challenges is not a simple issue James, and definitely it does not boil
down to any yes or no question.  Please do not create a fake sense of
simplicity for the community.  There is a multitude of issues and you know
as well as I do and many in this list that it is critical for the success of
IDNs for more people to understand those challenges.  I personally is quite
passionate to see that IDN is successfully deployed and used.

By the way, there is a discussion at ICANN on IDN Registry implementation, I
am not sure if this is also the right forum to discuss implementation.  Does
the people in this group think this is the right place also to discuss these
issues?  (it will include character equivalence preparation issues, and
since this group have rightly dismissed the discussion for the sake of the
"protocol", I am not sure if we should raise this dead horse from the ground
in this list)... what do people think?...

Edmon

----- Original Message -----
From: "James Seng" <[email-masked]>
To: "Edmon Chung" <[email-masked]>; "IDN" <[email-masked]>
Sent: Sunday, March 23, 2003 10:05 AM
Subject: Re: [idn] IDN eamples for testing

focuses
me

---

From: "James Seng" <[email-masked]>
Date: Sun, 23 Mar 2003 23:40:50 +0800

Please, it is a simple question:

Did you ever tell your potential customers that all they need is to deploy
your DNS servers to support IDN?

You dont need to give me a whole marketing brochure to answer this question.
It is only a yes and no. Neither is it as complicated as you said. Everyone
knows IDN is complex, and need requires different level of perspective. But
my questions isnt so...it is a simple yes and no answer.

So please try again.

-James Seng

----- Original Message -----
From: "Edmon Chung" <[email-masked]>
To: "James Seng" <[email-masked]>; "IDN" <[email-masked]>
Sent: Sunday, March 23, 2003 11:29 PM
Subject: Re: [idn] IDN eamples for testing

> > > > It is not my business to tell you if you should or should not. I
just
> > want
> > > > > equivalence preparations, the implications to provisioning
protocols
> > > that
> > > > > of the standard and we are urging TLDs and other relevant parties
to
> > > make
> > > > > "client", because there are a lot of administrative and
operational
> > > issues
> > > > > > Lastly, in your private mail to me, you mention that you have
not
> > > > > advertise
> > > > > > > working with registries and preparing their "servers" to
accept
> > IDN
> > > > > > > > Obviously, IETF (or I for that matter) cannot tell anyone
what
> > > > > > > > business perspective, and why they *really* dont want to do
so
> > > IMO.

---

From: Steve Dyer <[email-masked]>
Date: Sun, 23 Mar 2003 15:55:49 +0000

>in this list)... what do people think?...

Hi Edmon, James and All,

I think that as IDN moves towards implementation there will be a number of 
transitional systems deployed which help make the jump. IDN is quite a 
complex system where not all the problems have been resolved and a large 
amount of software still requires modification. Along that road there will 
be marketing speak, and the purity of the standard may not survive the 
commercial pressures which have to arise if IDN is to be successfully 
deployed and adopted worldwide. Please can we all try to work to this end 
without too much point scoring on all sides? Commercial ventures have their 
place and it is commerce which funds the Internet.

In relation to ICANN's proposed IDN Discussion group I raised this matter 
at the last RIPE in the CENTR DNR Forum. Whilst discussion is always useful 
I do not regard ICANN as the forum for the discussions of standards 
implementation. ICANN has enough problems without widening its remit.

Regards

Stephen Dyer

---

From: "James Seng" <[email-masked]>
Date: Mon, 24 Mar 2003 00:05:46 +0800

Hi Steve,

Please dont get me wrong. I am not against commercial deployment.

I am against unscrupulous marketing claiming they do one thing while they
are not. If you think I am single out poor Neteka here, then you should see
some of my criticism in the IDN Registry Implementation Committee mailing
list on Verisign deployment.

In my reply to Neil (Verisign) when we managed to reach to some middle
ground, I told him I am critical to any deployment or solution of IDN
claiming conformance to standard but they are not. I am living to my own
standard.

-James Seng

---

From: "James Seng" <[email-masked]>
Date: Mon, 24 Mar 2003 00:19:54 +0800

From your relectant to address my direct question, I think the answer is
fairly obvious.

Yes, you did tell your potential customer you can provide a special DNS
server to resolve IDN without requiring any patch to the client.

So, unless you refute the above statement, I dont think I was "misguide".
And there is no misunderstandings from the registries who has talk to me.

But of course, there is nothing wrong with what you are doing. Nothing in
IETF say you must adopt IETF standard. Everyone should be free to innovate
and create their own product.

But I would appreciate if you stop telling others you are providing IETF
compilence solution.

-James Seng

----- Original Message -----
From: "Edmon Chung" <[email-masked]>
To: "James Seng" <[email-masked]>; "IDN" <[email-masked]>
Sent: Sunday, March 23, 2003 11:29 PM
Subject: Re: [idn] IDN eamples for testing

just
protocols
to
operational
not
accept
what
so

---

From: "Edmon Chung" <[email-masked]>
Date: Sun, 23 Mar 2003 12:57:02 -0500

----- Original Message -----
> claiming conformance to standard but they are not. I am living to my own

James, yes, you are living to your own standard.  The rest of us are trying
to grapple with implementing the IDNA standard we consensually developed.

No, we never advertise about any "special DNS server to resolve IDN without
requiring any patch to the client", In fact, IDNA does NOT require any
"special DNS" and IDNA-aware clients do NOT need any "patch".  IDN-UNAWARE
clients are not discussed in IDNA and they SHOULD be managed based on
existing DNS Standards.  It is not appropriate to twist people's position
into a point of attack for "your own standard".

Edmon

---

From: "Adam M. Costello" <[email-masked]>
Date: Sun, 23 Mar 2003 20:44:44 +0000

"Martin v. Löwis" <[email-masked]> wrote:

> RFC 3490 says
>    specification or negotiation of charsets, labels can be encoded
>    in any charset allowed by the protocol or document format.  If a
>    protocol or document format only allows one charset, the labels
>    MUST be given in that charset.
>
> specification of charsets, as it is "MIME-like".  Therefore, I infer
> that sending
> 
> MIME-Version: 1.0

As James pointed out, RFC 2616 requires a very strict syntax for the
host, which does not allow for MIME encoded-words.  But even if your
suggested Host: field did not violate RFC 2616, it would still violate
RFC 3490, which says:

    Whenever a domain name is put into an IDN-unaware domain name slot,
    it MUST contain only ASCII characters.

Since the Host: field is IDN-unaware (because it predates IDNA),
you're not allowed to put a domain name there that contains non-ASCII
characters, regardless of whether the field supports non-ASCII charsets.

The passage from RFC 3490 that you quote above, which is about
*encoding*, is orthogonal to the requirement about IDN-unaware slots.
The domain names put into IDN-unaware slots must contain only ASCII
characters, but those ASCII characters can be encoded using any charset
supported by the slot, be it ASCII, UTF-16, UTF-32, EDCDIC, or whatever.

This freedom to use any slot-supported charset becomes more interesting
for IDN-aware slots, which can explicitly allow domain names containing
non-ASCII characters.

AMC

---

From: "James Seng" <[email-masked]>
Date: Mon, 24 Mar 2003 07:44:49 +0800

> into a point of attack for "your own standard".

Oh, you mean the answer is no? Sorry I misunderstood you. Could you please
explain the below then? Thanks!

http://www.neteka.com/en/pages/products/nedns/index.html

Neteka Enhanced Domain Name Server
The ubiquitous domain name system connects the Internet together as we know
it today and allows for navigation through the cyberspace with dot-linked
names. Widely accepted it may be, yet traditionally it only supports English
alphanumeric characters to be used as domain names. Neteka's NeDNS is the
world's first server side technology that enables the resolution and
management of multilingual domain names that could be transparently deployed
without requiring any client side reconfiguration or plug-in

-James Seng

---

From: "Ric Johnson" <[email-masked]>
Date: Sun, 23 Mar 2003 20:21:57 -0500

Martin -

Here a few.  Please let me know if you need more, or if you can not get
through.

ƒ.com ( also ƒ.net and ƒ.org )

U+0192

bq--agja.mltbd.com

฿.net

U+0E3F

bq--by7q.mltbd.net

☠.com ( also ☠.net and ☠.org)

U+2620

bq--eyqa.mltbd.com

米子.com

U+7C73 U+5B50

bq--3b6hgw2q.mltbd.com

四輪駆動車.com

U+56DB U+8F2A U+99C6 U+52D5 U+8ECA

bq--3blnxdzkthdffvmozi.mltbd.com

電子計算機.net

U+96FB U+5B50 U+8A08 U+7B97 U+6A5F

bq--3clpww2qriehxf3kl4.mltbd.net

Please note:  All of our .org IDN resolved until the Public interest
Registry assumed control of the TLD.

Ric Johnson

---

From: [email-masked] (Martin v. Löwis)
Date: 24 Mar 2003 07:46:48 +0100

> bq--agja.mltbd.com

These are not, of course, in conformance with the RFCs. IDNA uses the
xn-- prefix and punycode, instead of using RACE. So the Verisign
testbed should be considered proprietary now, until it is upgrade to
support the adopted standards.

Regards,
Martin

---

From: "Edmon Chung" <[email-masked]>
Date: Mon, 24 Mar 2003 08:45:42 -0500

This is actually an interesting question. Since we know that there are
actually quite a bunch of clients out there that uses bq--RACE, do we think
that those testbeds (such as in the case of JPRS) should keep bq--RACE in
the zone (together with xn--punycode) for a while for transitional purposes?
Or must this be considered non-conformant to the standards?
Edmon

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 24 Mar 2003 07:54:00 -0800

At 8:45 AM -0500 3/24/03, Edmon Chung wrote:
>This is actually an interesting question.

Not for people who care about Internet standards. Of course, some 
people and companies don't care about Internet standards...

>  Since we know that there are

How many times on this list do we need to dredge up the 
"transitional" debate? The IETF has lots of experience with the 
failure of "transitional" strategies that involve multiple 
supposedly-identical data.

>Or must this be considered non-conformant to the standards?

There is no standard for RACE; of course any use of it is non-conformant.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 24 Mar 2003 11:40:20 -0500

-- lundi, mars 24, 2003 08:45:42 -0500 Edmon Chung <[email-masked]>
wrote/a ecrit:

> actually quite a bunch of clients out there that uses bq--RACE, do we
> think that those testbeds (such as in the case of JPRS) should keep
> bq--RACE in the zone (together with xn--punycode) for a while for
> transitional purposes? Or must this be considered non-conformant to the
> standards?

quite simple: non-conformant to the standards.

Marc.

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 24 Mar 2003 08:41:52 -0800

Edmon Chung <edmon at neteka dot com> wrote:

> transitional purposes? Or must this be considered non-conformant to
> the standards?

I would think the answers would be unequivocally No, the RACE mechanism
should not be retained, and Yes, it would be non-conformant.

Testbeds are testbeds, intended as temporary feasibility studies to
determine if a new standard or technology will fly in the real world.
Once the "real" standard has been approved, the testbed becomes obsolete
(to the extent it differs from the approved version) and any code or
data created in support of the testbed needs to be updated or removed.

Creating de-facto standards by promoting the use of testbeds beyond
their intended use subverts the standardization process.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

---

From: "Edmon Chung" <[email-masked]>
Date: Mon, 24 Mar 2003 12:36:30 -0500

ok.  So the right way to do it is a clean break with no transition is what
we are saying.
That is good.
Edmon

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 24 Mar 2003 18:51:45 +0100

>There is no standard for RACE; of course any use of it is non-conformant.

1. "xn--" that many understand as "christian", others as "xenophobe" and is 
the European sign for bad things, does not conform to the standard as it is 
not meaningless and should have been removed from the list before the 
random choice.

2. I wander why ACE is RACE format ("cc--") compliant, while most of the 
babel name issue would disapear if the ACE label had used a "c--c" format 
fopr example.

     - "x--n" would not have had any particular meaning
     - "x--nibm.com" is far less appealing to babelsquatters than "xn--ibm.com"

For that two reasons, I would strongly suggest that the "xn--" format would 
be changed into "x--n" before it is carved into distributed code. I know 
that engineers will laught at that stupid proposition, but that laught will 
at least be in the records.
jfc

---

From: "vinton g. cerf" <[email-masked]>
Date: Mon, 24 Mar 2003 15:04:24 -0300

It seems to me (just opinion) that one might reasonably leave these in
place until there is a clear path either to re-register using the new
IDN standards or, if it proves impossible to support any of them in 
the new standard framework, to withdraw them on a reasonable time table.

vint

>> support the adopted standards.

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

---

From: "Edmon Chung" <[email-masked]>
Date: Mon, 24 Mar 2003 16:02:44 -0500

Hi Vint,

I think this is really a better way to go about it, to ensure a smooth user
experience (than to simply have a switch day).
A reasonable timetable in which the registry will maintain both versions
seems to be a good compromise for registries such as JPRS who have
registered domains in RACE and is planning to move towards Punycode.

Edmon

----- Original Message -----
From: "vinton g. cerf" <[email-masked]>
To: "Edmon Chung" <[email-masked]>; "Ric Johnson"
<[email-masked]>; "Martin v. Löwis" <[email-masked]>
Cc: "IDN" <[email-masked]>; "Martin Duerst" <[email-masked]>
Sent: Monday, March 24, 2003 1:04 PM
Subject: Re: [idn] IDN eamples for testing

vint

Vint Cerf

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 24 Mar 2003 13:33:55 -0800

>the new standard framework, to withdraw them on a reasonable time table.

That path is already completely clear and could have been implemented 
a while ago. As for "withdrawing them on a reasonable time table", 
how about "now"? The IDN testbeds are no different than the testbeds 
for any other Internet standard.

--Paul Hoffman, Director

---

From: "vinton g. cerf" <[email-masked]>
Date: Mon, 24 Mar 2003 19:03:38 -0300

At 01:33 PM 3/24/2003 -0800, Paul Hoffman / IMC wrote:
>That path is already completely clear and could have been implemented a while ago. As for "withdrawing them on a reasonable time table", how about "now"? The IDN testbeds are no different than the testbeds for any other Internet standard.

the only reason for suggesting the time table was uncertainty whether any of these registrations were in regular use as sites on the net. as opposed to purely test sites.

Vint Cerf

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 24 Mar 2003 14:27:21 -0800

At 7:03 PM -0300 3/24/03, vinton g. cerf wrote:
>the only reason for suggesting the time table was uncertainty 
>whether any of these registrations were in regular use as sites on 
>the net. as opposed to purely test sites.

Why should that matter? If anyone was using these in "regular use", 
they were doing so with no standard and, for at least the past year, 
no available Internet Draft. Why do you feel that clients that 
conform to IDNA should also conform to every possible Internet Draft 
that preceded it, particularly when those drafts were explicitly 
rejected by the WG years ago?

This is not normally how the IETF makes standards...

--Paul Hoffman, Director

---

From: [email-masked] (Martin v. Löwis)
Date: 25 Mar 2003 00:52:44 +0100

> ok.  So the right way to do it is a clean break with no transition is what

I don't think anybody is saying that, and nobody would object if
Verisign migrates the IDN registrations from RACE to IDNA. You won't
(necessarily) loose all the registrations - they just appear under
different ACE labels.

Whether or not Verisign offers such a migration is their choice - I'm
sure that they advised customers that registrations won't necessarily
be permanent.

Regards,
Martin

---

From: [email-masked] (Martin v. Löwis)
Date: 25 Mar 2003 00:50:06 +0100

> Or must this be considered non-conformant to the standards?

Having the ASCII labels in the zone is certainly conforming to the DNS
protocol. Its just that clients should not interpret them as ACE
versions of IDN labels.

It is also likely that Verisign may remove these labels at any time
they feel like it (probably after they start supporting IDNA).

Regards,
Martin

---

From: "James Seng" <[email-masked]>
Date: Tue, 25 Mar 2003 08:34:01 +0800

You only have "transition" issue *IF* you move from one operational mode to
another. But a testbed, by implication, means it is NOT operational.

Secondly, we have not closed our previous discussion:

Let me quote you again: "No, we never advertise about any "special DNS
server to resolve IDN without requiring any patch to the client", In fact,
IDNA does NOT require any "special DNS" and IDNA-aware clients do NOT need
any "patch".

So could you explain the following link:

---

From: "James Seng" <[email-masked]>
Date: Tue, 25 Mar 2003 08:37:22 +0800

So could you explain the existence of NeDNS, which claims "server side
technology that enables the resolution and management of multilingual domain
names that could be transparently deployed
without requiring any client side reconfiguration or plug-in"

-James Seng

---

From: "vinton g. cerf" <[email-masked]>
Date: Tue, 25 Mar 2003 09:03:07 -0300

Paul,

There was an implicit question in my note: is anyone using these "test" registrations for operational purposes?

I was responding only to the question whether the registrations should be immediately terminated or allowed to phase out. The latter was not intended to place burdens on any clients - the presumption I was making is that if it works now, would it not keep working for that existing subset of clients that use it? If there is a technical mutual-exclusion problem (can't work with both), I would agree that the non-IDNA registrations would have to be terminated.

Vint

At 02:27 PM 3/24/2003 -0800, Paul Hoffman / IMC wrote:
>Why should that matter? If anyone was using these in "regular use", they were doing so with no standard and, for at least the past year, no available Internet Draft. Why do you feel that clients that conform to IDNA should also conform to every possible Internet Draft that preceded it, particularly when those drafts were explicitly rejected by the WG years ago?
>

Vint Cerf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 25 Mar 2003 13:28:32 +0100

On Mon, Mar 24, 2003 at 07:44:49AM +0800,
 James Seng <[email-masked]> wrote 

> Neteka Enhanced Domain Name Server

One can notice also that Neteka claims "we have chosen to release our
multilingual domain name system, NeDNS, as open source code" while
there is no way to download it if you are not registered
<URL:http://www.OpenIDN.org/>.

I tried to register because I want to go as far as possible before
posting publicly but I got an "Internal Server Error The server
encountered an internal error or misconfiguration and was unable to
complete your request." :-)

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 25 Mar 2003 07:50:28 -0500

I guess it is time to update our website.
It has been long overdue.
Sorry about it.  I will have it fixed soon. :-)
Edmon

----- Original Message ----- 
From: "Stephane Bortzmeyer" <[email-masked]>