From owner-idn@ops.ietf.org Sat Mar 1 19:19:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21182 for ; Sat, 1 Mar 2003 19:19:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pH4D-000NJV-00 for idn-data@psg.com; Sat, 01 Mar 2003 16:10:57 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 18pH3Z-000NHP-00 for idn@ops.ietf.org; Sat, 01 Mar 2003 16:10:17 -0800 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.7/8.12.7) with ESMTP id h220A8qt020791 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 2 Mar 2003 01:10:09 +0100 Cc: IDN To: "Eric A. Hall" Subject: [idn] Re: converter page? X-Payment: hashcash 1.1 0:030302:ehall@ehsco.com:3060e85d5b8c028f X-Hashcash: 0:030302:ehall@ehsco.com:3060e85d5b8c028f X-Payment: hashcash 1.1 0:030302:idn@ops.ietf.org:d7e14c474cb8d990 X-Hashcash: 0:030302:idn@ops.ietf.org:d7e14c474cb8d990 From: Simon Josefsson Date: Sun, 02 Mar 2003 01:10:08 +0100 In-Reply-To: <3E5FA1B8.1070009@ehsco.com> ("Eric A. Hall"'s message of "Fri, 28 Feb 2003 11:51:52 -0600") Message-ID: User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 (i686-pc-linux-gnu) References: <3E5FA1B8.1070009@ehsco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" 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. From owner-idn@ops.ietf.org Mon Mar 3 04:39:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13190 for ; Mon, 3 Mar 2003 04:39:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pmGQ-000P26-00 for idn-data@psg.com; Mon, 03 Mar 2003 01:29:38 -0800 Received: from maya40.nic.fr ([192.134.4.151]) by psg.com with esmtp (Exim 3.36 #1) id 18pmGO-000P1u-00 for idn@ops.ietf.org; Mon, 03 Mar 2003 01:29:36 -0800 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h239TVNV832313; Mon, 3 Mar 2003 10:29:32 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 9369E110C4; Mon, 3 Mar 2003 10:29:31 +0100 (CET) Date: Mon, 3 Mar 2003 10:29:31 +0100 From: Stephane Bortzmeyer To: "Eric A. Hall" Cc: IDN Subject: Re: [idn] converter page? Message-ID: <20030303092931.GA17242@nic.fr> References: <3E5FA1B8.1070009@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E5FA1B8.1070009@ehsco.com> User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Fri, Feb 28, 2003 at 11:51:52AM -0600, Eric A. Hall wrote a message of 11 lines which said: > 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. http://tac.eureg.org/idn.cgi From owner-idn@ops.ietf.org Mon Mar 3 11:57:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02866 for ; Mon, 3 Mar 2003 11:57:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pt4F-000BOn-00 for idn-data@psg.com; Mon, 03 Mar 2003 08:45:31 -0800 Received: from hosting.altserver.com ([209.124.80.2]) by psg.com with esmtp (Exim 3.36 #1) id 18pt47-000BOY-00 for idn@ops.ietf.org; Mon, 03 Mar 2003 08:45:23 -0800 Received: from f11v-10-189.d1.club-internet.fr ([213.44.169.189] helo=mine.jefsey.com) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18pt45-0006QL-00 for idn@ops.ietf.org; Mon, 03 Mar 2003 08:45:21 -0800 Message-Id: <5.2.0.9.0.20030303174449.0392b3a0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 03 Mar 2003 17:50:22 +0100 To: idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [idn] converter page? In-Reply-To: <20030303092931.GA17242@nic.fr> References: <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On 10:29 03/03/03, Stephane Bortzmeyer said: >On Fri, Feb 28, 2003 at 11:51:52AM -0600, > Eric A. Hall wrote > a message of 11 lines which said: > > > 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. > >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 owner-idn@ops.ietf.org Sat Mar 8 02:25:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05536 for ; Sat, 8 Mar 2003 02:25:57 -0500 (EST) From: owner-idn@ops.ietf.org Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rYYF-000GfF-00 for idn-data@psg.com; Fri, 07 Mar 2003 23:15:23 -0800 Message-Id: To: idn-data@psg.com Date: Fri, 07 Mar 2003 23:15:23 -0800 Fri, 7 Mar 2003 16:58:11 -0800 (PST) Message-Id: <200303080058.h280wBZ14683@gamma.isi.edu> To: IETF-Announce: ; Subject: [idn] RFC 3491 on Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) Cc: rfc-editor@rfc-editor.org, idn@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 07 Mar 2003 16:58:10 -0800 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3491 Title: Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) Author(s): P. Hoffman, M. Blanchet Status: Standards Track Date: March 2003 Mailbox: paul.hoffman@imc.org, Marc.Blanchet@viagenie.qc.ca Pages: 7 Characters: 10316 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idn-nameprep-11.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3491.txt This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). This document is a product of the Internationalized Domain Name Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute .. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030307165621.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3491 --OtherAccess Content-Type: Message/External-body; name="rfc3491.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030307165621.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Sat Mar 8 02:26:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05560 for ; Sat, 8 Mar 2003 02:26:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rYZ5-000GiZ-00 for idn-data@psg.com; Fri, 07 Mar 2003 23:16:15 -0800 To: IETF-Announce: ; Subject: [idn] RFC 3492 on Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) Cc: rfc-editor@rfc-editor.org, idn@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 07 Mar 2003 17:00:04 -0800 Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3492 Title: Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) Author(s): A. Costello Status: Standards Track Date: March 2003 Mailbox: http://www.nicemice.net/amc/ Pages: 35 Characters: 67439 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idn-punycode-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3492.txt Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. This document is a product of the Internationalized Domain Name Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute .. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030307165836.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3492 --OtherAccess Content-Type: Message/External-body; name="rfc3492.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030307165836.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Sat Mar 8 02:26:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05613 for ; Sat, 8 Mar 2003 02:26:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rYYf-000GiD-00 for idn-data@psg.com; Fri, 07 Mar 2003 23:15:49 -0800 To: IETF-Announce: ; Subject: [idn] RFC 3490 on Internationalizing Domain Names in Applications (IDNA) Cc: rfc-editor@rfc-editor.org, idn@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 07 Mar 2003 16:56:00 -0800 Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3490 Title: Internationalizing Domain Names in Applications (IDNA) Author(s): P. Faltstrom, P. Hoffman, A. Costello Status: Standards Track Date: March 2003 Mailbox: paf@cisco.com, phoffman@imc.org, http://www.nicemice.net/amc/ Pages: 22 Characters: 51943 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idn-idna-14.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3490.txt Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. This document is a product of the Internationalized Domain Name Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute .. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030307165244.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3490 --OtherAccess Content-Type: Message/External-body; name="rfc3490.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030307165244.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Sat Mar 8 02:29:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06239 for ; Sat, 8 Mar 2003 02:29:02 -0500 (EST) From: owner-idn@ops.ietf.org Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rYgR-000HBX-00 for idn-data@psg.com; Fri, 07 Mar 2003 23:23:51 -0800 To: IETF-Announce: ; Subject: [idn] RFC 3491 on Nameprep: A Stringprep Profile for Internationalized Message-Id: Date: Fri, 07 Mar 2003 23:23:51 -0800 Domain Names (IDN) Cc: rfc-editor@rfc-editor.org, idn@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 07 Mar 2003 16:58:10 -0800 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3491 Title: Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) Author(s): P. Hoffman, M. Blanchet Status: Standards Track Date: March 2003 Mailbox: paul.hoffman@imc.org, Marc.Blanchet@viagenie.qc.ca Pages: 7 Characters: 10316 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idn-nameprep-11.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3491.txt This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). This document is a product of the Internationalized Domain Name Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute .. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030307165621.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3491 --OtherAccess Content-Type: Message/External-body; name="rfc3491.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030307165621.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Sat Mar 8 16:14:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09987 for ; Sat, 8 Mar 2003 16:14:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rlZG-000Ih8-00 for idn-data@psg.com; Sat, 08 Mar 2003 13:09:18 -0800 Received: from tux.w3.org ([18.29.0.27]) by psg.com with esmtp (Exim 3.36 #1) id 18rlZD-000Igw-00 for idn@ops.ietf.org; Sat, 08 Mar 2003 13:09:15 -0800 Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h28L90rC012852; Sat, 8 Mar 2003 16:09:01 -0500 Message-Id: <4.2.0.58.J.20030308144925.03c6fad0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sat, 08 Mar 2003 15:31:07 -0500 To: Simon Josefsson , "Eric A. Hall" From: Martin Duerst Subject: Re: [idn] Re: converter page? Cc: IDN In-Reply-To: References: <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk 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 bug-libidn@gnu.org, 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ürst.josefsson.org' | /usr/local/bin/idn --idna-to-ascii 2>&1 but $ echo 'D&uuml;rst.josefsson.org' | /usr/local/bin/idn --idna-to-ascii 2>&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 , instead of simply 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"). At 01:10 03/03/02 +0100, Simon Josefsson wrote: >"Eric A. Hall" 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. > > From owner-idn@ops.ietf.org Sat Mar 8 17:08:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20486 for ; Sat, 8 Mar 2003 17:08:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rmMw-000LNo-00 for idn-data@psg.com; Sat, 08 Mar 2003 14:00:38 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 18rmMt-000LNY-00 for idn@ops.ietf.org; Sat, 08 Mar 2003 14:00:35 -0800 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.8/8.12.8) with ESMTP id h28M0PZG019452 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 8 Mar 2003 23:00:27 +0100 To: Martin Duerst Cc: "Eric A. Hall" , IDN Subject: [idn] Re: converter page? X-Payment: hashcash 1.2 0:030308:duerst@w3.org:d5d686c9da6ea20a X-Hashcash: 0:030308:duerst@w3.org:d5d686c9da6ea20a X-Payment: hashcash 1.2 0:030308:ehall@ehsco.com:934bee3dc769c9fb X-Hashcash: 0:030308:ehall@ehsco.com:934bee3dc769c9fb X-Payment: hashcash 1.2 0:030308:idn@ops.ietf.org:7f2a2449c0572883 X-Hashcash: 0:030308:idn@ops.ietf.org:7f2a2449c0572883 From: Simon Josefsson Date: Sat, 08 Mar 2003 23:00:25 +0100 In-Reply-To: <4.2.0.58.J.20030308144925.03c6fad0@localhost> (Martin Duerst's message of "Sat, 08 Mar 2003 15:31:07 -0500") Message-ID: User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 (gnu/linux) References: <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Martin Duerst writes: > Hello Simon, > > 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. > 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. 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. > 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 bug-libidn@gnu.org, 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. 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. > 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ürst.josefsson.org' | /usr/local/bin/idn --idna-to-ascii 2>&1 > > but > > $ echo 'D&uuml;rst.josefsson.org' | /usr/local/bin/idn > --idna-to-ascii 2>&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 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 > , > instead of simply > > 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 owner-idn@ops.ietf.org Sat Mar 8 17:09:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20772 for ; Sat, 8 Mar 2003 17:09:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rmM1-000LLA-00 for idn-data@psg.com; Sat, 08 Mar 2003 13:59:41 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 18rmLy-000LKy-00 for idn@ops.ietf.org; Sat, 08 Mar 2003 13:59:38 -0800 Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 18rmLv-000B5y-00; Sat, 08 Mar 2003 16:59:35 -0500 Date: Sat, 08 Mar 2003 16:59:35 -0500 From: John C Klensin To: Martin Duerst , Simon Josefsson cc: IDN Subject: Re: [idn] Re: converter page? Message-ID: <460810180.1047142775@p3.JCK.COM> In-Reply-To: <4.2.0.58.J.20030308144925.03c6fad0@localhost> References: <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 wrote: > 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 bug-libidn@gnu.org, 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ürst.josefsson.org' | /usr/local/bin/idn > --idna-to-ascii 2>&1 > > but > > $ echo 'D&uuml;rst.josefsson.org' | /usr/local/bin/idn > --idna-to-ascii 2>&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 > , instead of simply > 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"). > > > > At 01:10 03/03/02 +0100, Simon Josefsson wrote: >> "Eric A. Hall" 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. >> >> > > From owner-idn@ops.ietf.org Sat Mar 8 19:18:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14808 for ; Sat, 8 Mar 2003 19:18:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18roQM-000211-00 for idn-data@psg.com; Sat, 08 Mar 2003 16:12:18 -0800 Received: from tux.w3.org ([18.29.0.27]) by psg.com with esmtp (Exim 3.36 #1) id 18roQI-00020p-00 for idn@ops.ietf.org; Sat, 08 Mar 2003 16:12:14 -0800 Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h290BurC005543; Sat, 8 Mar 2003 19:11:57 -0500 Message-Id: <4.2.0.58.J.20030308174815.03cc8af8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sat, 08 Mar 2003 19:11:48 -0500 To: Simon Josefsson From: Martin Duerst Subject: Re: [idn] Re: converter page? Cc: "Eric A. Hall" , IDN In-Reply-To: References: <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_05_08 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Hello Simon, Many thanks for your quick reply. At 23:00 03/03/08 +0100, Simon Josefsson wrote: >Martin Duerst writes: > > > Hello Simon, > > > > 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. Well, my impression is that you have fixed some, but not all. > > 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. > >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 >UTF-8. Only supporting UTF-8 would restrict the page's usefulness. 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. > > 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 bug-libidn@gnu.org, 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. > >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. 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. > > 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ürst.josefsson.org' | /usr/local/bin/idn --idna-to-ascii 2>&1 > > > > but > > > > $ echo 'D&uuml;rst.josefsson.org' | /usr/local/bin/idn > > --idna-to-ascii 2>&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. But there are cases where you produce garbage on your own. For example, if I input ü.josefsson.org, ü followed by an actual u-umlaut, (where 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---8ya.josefsson.org. The correct result is of course xn--ü-8ya.josefsson.org, which is in the source, but not visible. So you have to fix the source to be xn--&uuml;-8ya.josefsson.org. > > 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 > > , > > instead of simply > > > > 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. Strictly speaking, 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 owner-idn@ops.ietf.org Sat Mar 8 21:04:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04364 for ; Sat, 8 Mar 2003 21:04:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rptt-0006Y5-00 for idn-data@psg.com; Sat, 08 Mar 2003 17:46:53 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 18rptp-0006Xt-00 for idn@ops.ietf.org; Sat, 08 Mar 2003 17:46:49 -0800 Received: (qmail 24897 invoked from network); 9 Mar 2003 01:59:22 -0000 Received: from bb220-255-118-213.singnet.com.sg (HELO JSENGTOSHIBA) (220.255.118.213) by sentosa.post1.com with SMTP; 9 Mar 2003 01:59:22 -0000 Message-ID: <012901c2e5dd$bf3993f0$2700a8c0@JSENGTOSHIBA> From: "James Seng" To: "John C Klensin" , "Martin Duerst" , "Simon Josefsson" Cc: "IDN" References: <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <460810180.1047142775@p3.JCK.COM> Subject: Re: [idn] Re: converter page? Date: Sun, 9 Mar 2003 09:46:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=2.3 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT_OE version=2.43 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 ----- Original Message ----- From: "John C Klensin" To: "Martin Duerst" ; "Simon Josefsson" Cc: "IDN" Sent: Sunday, March 09, 2003 5:59 AM Subject: Re: [idn] Re: converter page? > 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 > wrote: > > > 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 bug-libidn@gnu.org, 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ürst.josefsson.org' | /usr/local/bin/idn > > --idna-to-ascii 2>&1 > > > > but > > > > $ echo 'D&uuml;rst.josefsson.org' | /usr/local/bin/idn > > --idna-to-ascii 2>&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 > > , instead of simply > > 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"). > > > > > > > > At 01:10 03/03/02 +0100, Simon Josefsson wrote: > >> "Eric A. Hall" 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. > >> > >> > > > > > > > > > > From owner-idn@ops.ietf.org Sun Mar 9 08:23:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11831 for ; Sun, 9 Mar 2003 08:23:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18s0ed-000Ph0-00 for idn-data@psg.com; Sun, 09 Mar 2003 05:15:51 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 18s0ea-000Pgo-00 for idn@ops.ietf.org; Sun, 09 Mar 2003 05:15:48 -0800 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.8/8.12.8) with ESMTP id h29DFcZG014342 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 9 Mar 2003 14:15:39 +0100 To: Martin Duerst Cc: "Eric A. Hall" , IDN Subject: [idn] Re: converter page? X-Payment: hashcash 1.2 0:030309:duerst@w3.org:1fb8242dacfeb6d8 X-Hashcash: 0:030309:duerst@w3.org:1fb8242dacfeb6d8 X-Payment: hashcash 1.2 0:030309:ehall@ehsco.com:4e0de98b487f590d X-Hashcash: 0:030309:ehall@ehsco.com:4e0de98b487f590d X-Payment: hashcash 1.2 0:030309:idn@ops.ietf.org:ebfb52f32599c939 X-Hashcash: 0:030309:idn@ops.ietf.org:ebfb52f32599c939 From: Simon Josefsson Date: Sun, 09 Mar 2003 14:15:38 +0100 In-Reply-To: <4.2.0.58.J.20030308174815.03cc8af8@localhost> (Martin Duerst's message of "Sat, 08 Mar 2003 19:11:48 -0500") Message-ID: User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 (gnu/linux) References: <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-4.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Martin Duerst writes: >>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. 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. >>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. 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. > "The following string must only contain characters that can be > represented in ISO-8859-1." Thanks, I'm using it now. > But there are cases where you produce garbage on your own. > For example, if I input ü.josefsson.org, > ü followed by an actual u-umlaut, (where 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---8ya.josefsson.org. The correct > result is of course ü.josefsson.org, which is in the > source, but not visible. So you have to fix the source to > be xn--&uuml;-8ya.josefsson.org. Ah, true. I'll see if there is a handy function for escaping... From owner-idn@ops.ietf.org Mon Mar 10 02:45:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11989 for ; Mon, 10 Mar 2003 02:44:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sHrY-0005Zw-00 for idn-data@psg.com; Sun, 09 Mar 2003 23:38:20 -0800 Received: from hosting.altserver.com ([209.124.80.2]) by psg.com with esmtp (Exim 3.36 #1) id 18sHrV-0005Zj-00 for idn@ops.ietf.org; Sun, 09 Mar 2003 23:38:17 -0800 Received: from f04a-11-83.d1.club-internet.fr ([212.194.82.83] helo=mine.jefsey.com) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18sHrR-0004jq-00; Sun, 09 Mar 2003 23:38:14 -0800 Message-Id: <5.2.0.9.0.20030310083758.048c6c30@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 08:40:16 +0100 To: idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Re: converter page? Cc: IDN In-Reply-To: References: <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-1AA2741; boundary="=======22B04B07=======" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk --=======22B04B07======= Content-Type: text/plain; x-avg-checked=avg-ok-1AA2741; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit 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 --=======22B04B07======= Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-1AA2741 Content-Disposition: inline --- 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 --=======22B04B07=======-- From owner-idn@ops.ietf.org Mon Mar 10 12:22:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04336 for ; Mon, 10 Mar 2003 12:22:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sQkt-000N9z-00 for idn-data@psg.com; Mon, 10 Mar 2003 09:08:03 -0800 Received: from w1309.hostcentric.net ([66.40.78.254]) by psg.com with smtp (Exim 3.36 #1) id 18sQkm-000N8X-00 for idn@ops.ietf.org; Mon, 10 Mar 2003 09:07:56 -0800 Received: (qmail 1439 invoked by alias); 10 Mar 2003 17:07:55 -0000 Received: from unknown (HELO DAVIS1) (12.234.231.250) by 0 with SMTP; 10 Mar 2003 17:07:55 -0000 Message-ID: <005101c2e727$8f805bd0$7900a8c0@DAVIS1> From: "Mark Davis" To: "John C Klensin" , "Martin Duerst" , "Simon Josefsson" Cc: "IDN" References: <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <460810180.1047142775@p3.JCK.COM> Subject: Re: [idn] Re: converter page? Date: Mon, 10 Mar 2003 09:07:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT_OE version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit 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 ________ mark.davis@jtcsv.com IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193 (408) 256-3148 fax: (408) 256-0799 ----- Original Message ----- From: "John C Klensin" To: "Martin Duerst" ; "Simon Josefsson" Cc: "IDN" Sent: Saturday, March 08, 2003 13:59 Subject: Re: [idn] Re: converter page? > 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 > wrote: > > > 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 bug-libidn@gnu.org, 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ürst.josefsson.org' | /usr/local/bin/idn > > --idna-to-ascii 2>&1 > > > > but > > > > $ echo 'D&uuml;rst.josefsson.org' | /usr/local/bin/idn > > --idna-to-ascii 2>&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 > > , instead of simply > > 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"). > > > > > > > > At 01:10 03/03/02 +0100, Simon Josefsson wrote: > >> "Eric A. Hall" 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. > >> > >> > > > > > > > > > > From owner-idn@ops.ietf.org Mon Mar 10 17:59:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18503 for ; Mon, 10 Mar 2003 17:59:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sVxD-000Chi-00 for idn-data@psg.com; Mon, 10 Mar 2003 14:41:07 -0800 Received: from tux.w3.org ([18.29.0.27]) by psg.com with esmtp (Exim 3.36 #1) id 18sVxA-000ChV-00 for idn@ops.ietf.org; Mon, 10 Mar 2003 14:41:04 -0800 Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2AMevrC026551; Mon, 10 Mar 2003 17:40:58 -0500 Message-Id: <4.2.0.58.J.20030310161505.05621448@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 10 Mar 2003 16:15:42 -0500 To: "Mark Davis" , "John C Klensin" , "Simon Josefsson" From: Martin Duerst Subject: Re: [idn] Re: converter page? Cc: "IDN" In-Reply-To: <005101c2e727$8f805bd0$7900a8c0@DAVIS1> References: <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <460810180.1047142775@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk 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 owner-idn@ops.ietf.org Mon Mar 10 19:34:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22256 for ; Mon, 10 Mar 2003 19:34:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sXZl-000IVc-00 for idn-data@psg.com; Mon, 10 Mar 2003 16:25:01 -0800 Received: from w1309.hostcentric.net ([66.40.78.254]) by psg.com with smtp (Exim 3.36 #1) id 18sXZh-000IVD-00 for idn@ops.ietf.org; Mon, 10 Mar 2003 16:24:57 -0800 Received: (qmail 2601 invoked by alias); 11 Mar 2003 00:24:56 -0000 Received: from unknown (HELO DAVIS1) (129.42.184.35) by 0 with SMTP; 11 Mar 2003 00:24:56 -0000 Message-ID: <002501c2e764$9c053cd0$99d52b09@DAVIS1> From: "Mark Davis" To: "John C Klensin" , "Simon Josefsson" , "Martin Duerst" Cc: "IDN" References: <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <460810180.1047142775@p3.JCK.COM> <4.2.0.58.J.20030310161505.05621448@localhost> Subject: Re: [idn] Re: converter page? Date: Mon, 10 Mar 2003 16:24:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_OE version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Whoops, here it is: http://oss.software.ibm.com/cgi-bin/icu/tr Mark ________ mark.davis@jtcsv.com IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193 (408) 256-3148 fax: (408) 256-0799 ----- Original Message ----- From: "Martin Duerst" To: "Mark Davis" ; "John C Klensin" ; "Simon Josefsson" Cc: "IDN" Sent: Monday, March 10, 2003 13:15 Subject: Re: [idn] Re: converter page? > 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 owner-idn@ops.ietf.org Sat Mar 15 14:59:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23581 for ; Sat, 15 Mar 2003 14:59:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uHfP-000Pp6-00 for idn-data@psg.com; Sat, 15 Mar 2003 11:50:03 -0800 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 18uHfM-000Poh-00 for idn@ops.ietf.org; Sat, 15 Mar 2003 11:50:00 -0800 Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2FJnvg24263 for ; Sat, 15 Mar 2003 11:49:57 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sat, 15 Mar 2003 11:48:10 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: [idn] Announcement of IDNConnect, to be held May 28-30 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.0 required=5.0 tests=HABEAS_SWE,SPAM_PHRASE_01_02,SUBJECT_MONTH version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Greetings again. IDNConnect will take place May 28-30, 2003, in the San Francisco area. It is the first international, face-to-face event for internationalized domain names. The two purposes of the event are to help implementers of IDNs in programs, software libraries, and DNS servers to test their software against other programs and against reference implementations, and to foster a discussion of issues with registering IDNs in zones throughout the world. We have already gotten good response from software implementers and registries from around the world, so we expect to fill up well before the event. Registration is $195 per person for the three-day event. Much more information on the event can be found at . --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sat Mar 15 15:45:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26065 for ; Sat, 15 Mar 2003 15:45:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uIUB-0003Og-00 for idn-data@psg.com; Sat, 15 Mar 2003 12:42:31 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 18uIU6-0003Nt-00 for idn@ops.ietf.org; Sat, 15 Mar 2003 12:42:26 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h2FKgDk02637; Sat, 15 Mar 2003 12:42:13 -0800 (PST) From: Bill Manning Message-Id: <200303152042.h2FKgDk02637@boreas.isi.edu> Subject: Re: [idn] Announcement of IDNConnect, to be held May 28-30 In-Reply-To: from Paul Hoffman / IMC at "Mar 15, 3 11:48:10 am" To: phoffman@imc.org (Paul Hoffman / IMC) Date: Sat, 15 Mar 2003 12:42:13 -0800 (PST) Cc: idn@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02,SUBJECT_MONTH version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % Greetings again. IDNConnect will take place May 28-30, 2003, in the % San Francisco area. It is the first international, face-to-face event % for internationalized domain names. The two purposes of the event are % to help implementers of IDNs in programs, software libraries, and DNS % servers to test their software against other programs and against % reference implementations, and to foster a discussion of issues with % registering IDNs in zones throughout the world. % % We have already gotten good response from software implementers and % registries from around the world, so we expect to fill up well before % the event. Registration is $195 per person for the three-day event. % % Much more information on the event can be found at % . % % --Paul Hoffman, Director % --Internet Mail Consortium Very cool. If folks want to work on such things in a persistant fashion, they could take advantage of the testbed, visable at http://www.rs.net --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-idn@ops.ietf.org Mon Mar 17 00:05:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20019 for ; Mon, 17 Mar 2003 00:05:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18umfn-000K0J-00 for idn-data@psg.com; Sun, 16 Mar 2003 20:56:31 -0800 From: "Georg Ochsner" To: References: <200303152042.h2FKgDk02637@boreas.isi.edu> Subject: [idn] Everything done yet? Date: Sun, 16 Mar 2003 23:01:11 +0100 Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Hello everybody, is it certain now that IDNs will be implementet around the world according to the new RFCs? Can all IDNs (com/net/org) registered so far be migrated to xn-punycode? What else will have to be done next? When will the German registry denic implement IDNs? Bye, Georg From owner-idn@ops.ietf.org Mon Mar 17 01:53:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23087 for ; Mon, 17 Mar 2003 01:53:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uoQH-000PyP-00 for idn-data@psg.com; Sun, 16 Mar 2003 22:48:37 -0800 Received: from mailout09.sul.t-online.com ([194.25.134.84]) by psg.com with esmtp (Exim 3.36 #1) id 18uoQE-000Py4-00 for idn@ops.ietf.org; Sun, 16 Mar 2003 22:48:34 -0800 Received: from fwd08.sul.t-online.de by mailout09.sul.t-online.com with smtp id 18uoQC-0008NH-02; Mon, 17 Mar 2003 07:48:32 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.19.232]) by fmrl08.sul.t-online.com with esmtp id 18uoPz-0IrV0CC; Mon, 17 Mar 2003 07:48:19 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2H6mHvV002137; Mon, 17 Mar 2003 07:48:17 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id h2H6mFCl002134; Mon, 17 Mar 2003 07:48:15 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: "Georg Ochsner" Cc: Subject: Re: [idn] Everything done yet? References: <200303152042.h2FKgDk02637@boreas.isi.edu> From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 17 Mar 2003 07:48:15 +0100 In-Reply-To: Message-ID: Lines: 28 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-2.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA, X_AUTH_WARNING,X_OSIRU_DUL version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk "Georg Ochsner" writes: > is it certain now that IDNs will be implementet around the world according > to the new RFCs? Yes. > Can all IDNs (com/net/org) registered so far be migrated to > xn-punycode? I think so. The IDNs in .nu are already migrated, and the Verisign pages indicate that Verisign is migrating the testbed registrations in the near future. > What else will have to be done next? Browsers need to support it, and the resolver libraries that potentially have the notion of Unicode. I believe the Mozilla CVS supports it, and Mozilla 1.3 with certain configuration settings. > When will the German registry denic implement IDNs? I just asked last week, and they said they will form a working group, and start a testbed within two-three month :-( Regards, Martin From owner-idn@ops.ietf.org Wed Mar 19 03:09:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15780 for ; Wed, 19 Mar 2003 03:09:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vYNv-000Iyq-00 for idn-data@psg.com; Tue, 18 Mar 2003 23:53:15 -0800 Received: from mail1.ics.ntts.co.jp ([202.32.24.45]) by psg.com with esmtp (Exim 3.36 #1) id 18vYNr-000IxQ-00 for idn@ops.ietf.org; Tue, 18 Mar 2003 23:53:11 -0800 Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3/3.7W-NTTSOFT-SUR2.0) id QAA07652 for ; Wed, 19 Mar 2003 16:53:08 +0900 (JST) (envelope-from yone@po.ntts.co.jp) Received: from daemon.inl.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.6/3.7W-silk-4.6) id h2J7r6B00455 for ; Wed, 19 Mar 2003 16:53:07 +0900 (JST) (envelope-from yone@po.ntts.co.jp) Received: (qmail 5395 invoked by alias); 19 Mar 2003 16:53:07 +0900 Received: (qmail 5380 invoked from network); 19 Mar 2003 16:53:06 +0900 Received: from daemon.inl.ntts.co.jp (HELO localhost) by daemon.inl.ntts.co.jp with SMTP; 19 Mar 2003 16:53:06 +0900 To: idn@ops.ietf.org Subject: [idn] idnkit-1.0 released X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030319165252J.yone@po.ntts.co.jp> Date: Wed, 19 Mar 2003 16:52:52 +0900 (JST) From: Yoshiro YONEYA X-Dispatcher: imput version 20000414(IM141) Lines: 43 X-Spam-Status: No, hits=0.5 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Today, JPNIC released idnkit-1.0 which is fully compliant to IDN RFCs. You can obtain idnkit-1.0 from following URL: http://www.nic.ad.jp/ja/idn/idnkit/download/ The idnkit-1.0 is a bsd-like licensed open source free software, and its major features are: - provides IDN <--> Punycode converter named `idnconv' It will help system administrators who manage IDN in zone files and / or Web configuration files. - provides IDNA C programming APIs named `libidnkit' and `libidnkitlite' They will help software programmers who are going to develop IDNA compliant products. The difference between `libidnkit' and `libidnkitlite' is, `libidnkit' can handle many charsets and encodings using `iconv' while `libidnkitlite' can handle only UTF-8. For users mDNkit-2.X/idnkit-1.0prX: - Supports Unicode 3.2 only. Unicode 3.0.1 and 3.1 are no longer supported. NFKC table size is significantly reduced. - idnkit provides mDNkit compatible APIs if `--enable-mdnkit-compat' configure option is specified. - idnkit supports RACE in addition to Punycode if `--enable-extra-ace' configure option is specified. This is migration purpose only. - idn.conf is incompatible with idnkit-1.0prX, so to upgrade from idnkit-1.0prX, please do `make install install-config' to overwrite previous configuration. - Actually, configuration file such as idn.conf is not required. Regards, -- Yoshiro YONEYA aka From owner-idn@ops.ietf.org Fri Mar 21 19:15:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03149 for ; Fri, 21 Mar 2003 19:15:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wWPy-00005g-00 for idn-data@psg.com; Fri, 21 Mar 2003 15:59:22 -0800 Received: from w1309.hostcentric.net ([66.40.78.254]) by psg.com with smtp (Exim 3.36 #1) id 18wWPw-00005R-00 for idn@ops.ietf.org; Fri, 21 Mar 2003 15:59:20 -0800 Received: (qmail 4655 invoked by alias); 21 Mar 2003 23:59:17 -0000 Received: from unknown (HELO DAVIS1) (12.234.231.250) by 0 with SMTP; 21 Mar 2003 23:59:17 -0000 Message-ID: <006701c2f005$d778dc00$7900a8c0@DAVIS1> From: "Mark Davis" To: , "Yoshiro YONEYA" References: <20030319165252J.yone@po.ntts.co.jp> Subject: Re: [idn] idnkit-1.0 released Date: Fri, 21 Mar 2003 15:58:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit BTW, the next version of ICU will contain an IDNA implementation. One of our engineers also put together an on-line demonstration that maps back and forth, at: http://oss.software.ibm.com/cgi-bin/icu/idnademo Mark (ᛗᚪᚱᚳ) ________ mark.davis@jtcsv.com IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193 (408) 256-3148 fax: (408) 256-0799 ----- Original Message ----- From: "Yoshiro YONEYA" To: Sent: Tuesday, March 18, 2003 23:52 Subject: [idn] idnkit-1.0 released > Hi, > > Today, JPNIC released idnkit-1.0 which is fully compliant to IDN RFCs. > You can obtain idnkit-1.0 from following URL: > > http://www.nic.ad.jp/ja/idn/idnkit/download/ > > The idnkit-1.0 is a bsd-like licensed open source free software, and > its major features are: > > - provides IDN <--> Punycode converter named `idnconv' > It will help system administrators who manage IDN in zone files > and / or Web configuration files. > > - provides IDNA C programming APIs named `libidnkit' and `libidnkitlite' > They will help software programmers who are going to develop IDNA > compliant products. > The difference between `libidnkit' and `libidnkitlite' is, > `libidnkit' can handle many charsets and encodings using `iconv' > while `libidnkitlite' can handle only UTF-8. > > For users mDNkit-2.X/idnkit-1.0prX: > > - Supports Unicode 3.2 only. Unicode 3.0.1 and 3.1 are no longer > supported. NFKC table size is significantly reduced. > > - idnkit provides mDNkit compatible APIs if `--enable-mdnkit-compat' > configure option is specified. > > - idnkit supports RACE in addition to Punycode if `--enable-extra-ace' > configure option is specified. This is migration purpose only. > > - idn.conf is incompatible with idnkit-1.0prX, so to upgrade from > idnkit-1.0prX, please do `make install install-config' to > overwrite previous configuration. > > - Actually, configuration file such as idn.conf is not required. > > Regards, > > -- > Yoshiro YONEYA > aka > > From owner-idn@ops.ietf.org Sat Mar 22 12:02:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29925 for ; Sat, 22 Mar 2003 12:02:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wmGI-000IGU-00 for idn-data@psg.com; Sat, 22 Mar 2003 08:54:26 -0800 Received: from tux.w3.org ([18.29.0.27]) by psg.com with esmtp (Exim 3.36 #1) id 18wmGF-000IFq-00 for idn@ops.ietf.org; Sat, 22 Mar 2003 08:54:23 -0800 Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2MGs8rM018559 for ; Sat, 22 Mar 2003 11:54:22 -0500 Message-Id: <4.2.0.58.J.20030321204149.0321f9c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 21 Mar 2003 20:47:02 -0500 To: IDN From: Martin Duerst Subject: [idn] IDN eamples for testing In-Reply-To: References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.6 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01, TO_LOCALPART_EQ_REAL version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk 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 owner-idn@ops.ietf.org Sat Mar 22 16:15:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05294 for ; Sat, 22 Mar 2003 16:15:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wqE0-0005tc-00 for idn-data@psg.com; Sat, 22 Mar 2003 13:08:20 -0800 Received: from mailout01.sul.t-online.com ([194.25.134.80]) by psg.com with esmtp (Exim 3.36 #1) id 18wqDx-0005tQ-00 for idn@ops.ietf.org; Sat, 22 Mar 2003 13:08:17 -0800 Received: from fwd07.sul.t-online.de by mailout01.sul.t-online.com with smtp id 18wqDt-0005av-06; Sat, 22 Mar 2003 22:08:13 +0100 Received: from v.loewis.de (03047300346-0001@[217.232.40.1]) by fmrl07.sul.t-online.com with esmtp id 18wqDr-0Krn6mC; Sat, 22 Mar 2003 22:08:11 +0100 Message-ID: <3E7CD0BF.1050807@v.loewis.de> Date: Sat, 22 Mar 2003 22:08:15 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.3) Gecko/20030312 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: Martin Duerst CC: IDN Subject: Re: [idn] IDN eamples for testing References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> In-Reply-To: <4.2.0.58.J.20030321204149.0321f9c0@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG,X_OSIRU_DUL, X_OSIRU_DUL_FH version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Martin Duerst schrieb: > 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? 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 owner-idn@ops.ietf.org Sat Mar 22 19:11:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08897 for ; Sat, 22 Mar 2003 19:11:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wt0O-000KQO-00 for idn-data@psg.com; Sat, 22 Mar 2003 16:06:28 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 18wt0K-000KQ8-00 for idn@ops.ietf.org; Sat, 22 Mar 2003 16:06:24 -0800 Received: (qmail 57497 invoked from network); 23 Mar 2003 00:17:48 -0000 Received: from bb220-255-109-44.singnet.com.sg (HELO JSENGTOSHIBA) (220.255.109.44) by sentosa.post1.com with SMTP; 23 Mar 2003 00:17:48 -0000 Message-ID: <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> From: "James Seng" To: "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 08:06:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=1.4 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_01_02,TO_LOCALPART_EQ_REAL,USER_AGENT_OE version=2.44 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The .nu operator supports IDNA, among other things (you also > can sent UTF-8 and various local encodings to their DNS servers). This sound bad. This is breaking the basic functionity of DNS. 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? > 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") 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 owner-idn@ops.ietf.org Sat Mar 22 20:08:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09659 for ; Sat, 22 Mar 2003 20:08:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wthT-000OOq-00 for idn-data@psg.com; Sat, 22 Mar 2003 16:50:59 -0800 Received: from h00045aed6116.ne.client2.attbi.com ([24.60.107.9] helo=Thinkpad) by psg.com with esmtp (Exim 3.36 #1) id 18wthR-000OOe-00 for idn@ops.ietf.org; Sat, 22 Mar 2003 16:50:57 -0800 Received: from Thinkpad.mail.nic.nu ([127.0.0.1]) by Thinkpad with Microsoft SMTPSVC(6.0.2600.1106); Sat, 22 Mar 2003 19:50:55 -0500 Message-Id: <5.1.1.6.2.20030322194748.04be9e38@mail.nic.nu> X-Sender: billnospam@nic.nu@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 22 Mar 2003 19:50:54 -0500 To: "James Seng" , "IDN" From: "J. William Semich" Subject: Re: [idn] IDN examples for testing In-Reply-To: <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 23 Mar 2003 00:50:55.0910 (UTC) FILETIME=[4317DC60:01C2F0D6] X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk 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 At 07:06 PM 3/22/2003, James Seng wrote: > > The .nu operator supports IDNA, among other things (you also > > can sent UTF-8 and various local encodings to their DNS servers). > >This sound bad. This is breaking the basic functionity of DNS. From owner-idn@ops.ietf.org Sat Mar 22 22:56:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12133 for ; Sat, 22 Mar 2003 22:56:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wwMG-000DQB-00 for idn-data@psg.com; Sat, 22 Mar 2003 19:41:16 -0800 Received: from h00045aed6116.ne.client2.attbi.com ([24.60.107.9] helo=Thinkpad) by psg.com with esmtp (Exim 3.36 #1) id 18wwLk-000DOP-00 for idn@ops.ietf.org; Sat, 22 Mar 2003 19:40:44 -0800 Received: from Thinkpad.mail.nic.nu ([127.0.0.1]) by Thinkpad with Microsoft SMTPSVC(6.0.2600.1106); Sat, 22 Mar 2003 22:40:41 -0500 Message-Id: <5.1.1.6.2.20030322223729.04026f70@mail.nic.nu> X-Sender: billnospam@nic.nu@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 22 Mar 2003 22:40:40 -0500 To: =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , Martin Duerst From: "J. William Semich" Subject: Re: [idn] IDN examples for testing Cc: IDN In-Reply-To: <3E7CD0BF.1050807@v.loewis.de> References: <4.2.0.58.J.20030321204149.0321f9c0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 23 Mar 2003 03:40:41.0786 (UTC) FILETIME=[FA5931A0:01C2F0ED] X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA12133 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. Lwis wrote: >Martin Duerst schrieb: >>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? > >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. From owner-idn@ops.ietf.org Sun Mar 23 03:52:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27794 for ; Sun, 23 Mar 2003 03:52:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x13k-000LHT-00 for idn-data@psg.com; Sun, 23 Mar 2003 00:42:28 -0800 Received: from mailout06.sul.t-online.com ([194.25.134.19]) by psg.com with esmtp (Exim 3.36 #1) id 18x13D-000LGZ-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 00:41:55 -0800 Received: from fwd00.sul.t-online.de by mailout06.sul.t-online.com with smtp id 18x12d-0000V8-03; Sun, 23 Mar 2003 09:41:19 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.20.50]) by fmrl00.sul.t-online.com with esmtp id 18x12T-23Ey6SC; Sun, 23 Mar 2003 09:41:09 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2N8fGvg002033; Sun, 23 Mar 2003 09:41:16 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id h2N8fEHD002030; Sun, 23 Mar 2003 09:41:14 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: "James Seng" Cc: "IDN" Subject: Re: [idn] IDN eamples for testing References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 23 Mar 2003 09:41:14 +0100 In-Reply-To: <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> Message-ID: Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA, X_AUTH_WARNING version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk "James Seng" writes: > > The .nu operator supports IDNA, among other things (you also > > can sent UTF-8 and various local encodings to their DNS servers). > > 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. > 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:. 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 owner-idn@ops.ietf.org Sun Mar 23 04:25:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28145 for ; Sun, 23 Mar 2003 04:25:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x1fN-000Mr1-00 for idn-data@psg.com; Sun, 23 Mar 2003 01:21:21 -0800 Received: from mailout11.sul.t-online.com ([194.25.134.85]) by psg.com with esmtp (Exim 3.36 #1) id 18x1eq-000MoW-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 01:20:48 -0800 Received: from fwd05.sul.t-online.de by mailout11.sul.t-online.com with smtp id 18x1eN-0001he-08; Sun, 23 Mar 2003 10:20:19 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.46.170]) by fmrl05.sul.t-online.com with esmtp id 18x1eC-1ogTaaC; Sun, 23 Mar 2003 10:20:08 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2N9KFLW001398; Sun, 23 Mar 2003 10:20:15 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id h2N9KD7i001395; Sun, 23 Mar 2003 10:20:13 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: "J. William Semich" Cc: "James Seng" , "IDN" Subject: Re: [idn] IDN examples for testing References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <5.1.1.6.2.20030322194748.04be9e38@mail.nic.nu> From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 23 Mar 2003 10:20:13 +0100 In-Reply-To: <5.1.1.6.2.20030322194748.04be9e38@mail.nic.nu> Message-ID: Lines: 141 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA, X_AUTH_WARNING version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA28145 "J. William Semich" 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 owner-idn@ops.ietf.org Sun Mar 23 07:32:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00890 for ; Sun, 23 Mar 2003 07:32:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x4Pb-00041O-00 for idn-data@psg.com; Sun, 23 Mar 2003 04:17:15 -0800 Received: from [3ffe:1001:1:f024::2] (helo=attila.bofh.it ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 18x4PU-0003zF-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 04:17:08 -0800 Received: by attila.bofh.it (Postfix, from userid 10) id D7A065F73E; Sun, 23 Mar 2003 13:16:43 +0100 (CET) Received: by wonderland.linux.it (Postfix/Md, from userid 1001) id 66AEF33D1E; Sun, 23 Mar 2003 12:48:45 +0100 (CET) Date: Sun, 23 Mar 2003 12:48:45 +0100 From: "Marco d'Itri" Cc: IDN Subject: Re: [idn] IDN eamples for testing Message-ID: <20030323114845.GA1224@wonderland.linux.it> References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4.2.0.58.J.20030321204149.0321f9c0@localhost> User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-3.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,MISSING_HEADERS,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Mar 22, Martin Duerst wrote: >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? 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 owner-idn@ops.ietf.org Sun Mar 23 08:14:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01301 for ; Sun, 23 Mar 2003 08:14:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x5Cx-0006Pb-00 for idn-data@psg.com; Sun, 23 Mar 2003 05:08:15 -0800 Received: from www.namesbeyond.com ([216.220.34.103] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 18x5C3-0006OU-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 05:07:19 -0800 Message-ID: <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> From: "Edmon Chung" To: "James Seng" , "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 08:03:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 ----- Original Message ----- From: "James Seng" To: "IDN" Sent: Saturday, March 22, 2003 7:06 PM Subject: Re: [idn] IDN eamples for testing > > The .nu operator supports IDNA, among other things (you also > > can sent UTF-8 and various local encodings to their DNS servers). > > This sound bad. This is breaking the basic functionity of DNS. > > 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? > > > 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") > > 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 owner-idn@ops.ietf.org Sun Mar 23 08:52:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01956 for ; Sun, 23 Mar 2003 08:52:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x5op-0008PA-00 for idn-data@psg.com; Sun, 23 Mar 2003 05:47:23 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 18x5oI-0008Lz-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 05:46:50 -0800 Received: (qmail 62209 invoked from network); 23 Mar 2003 13:57:50 -0000 Received: from bb220-255-109-44.singnet.com.sg (HELO JSENGTOSHIBA) (220.255.109.44) by sentosa.post1.com with SMTP; 23 Mar 2003 13:57:50 -0000 Message-ID: <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> From: "James Seng" To: "Edmon Chung" , "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 21:46:08 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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" To: "James Seng" ; "IDN" Sent: Sunday, March 23, 2003 9:03 PM Subject: Re: [idn] IDN eamples for testing > 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 > > > ----- Original Message ----- > From: "James Seng" > To: "IDN" > Sent: Saturday, March 22, 2003 7:06 PM > Subject: Re: [idn] IDN eamples for testing > > > > > The .nu operator supports IDNA, among other things (you also > > > can sent UTF-8 and various local encodings to their DNS servers). > > > > This sound bad. This is breaking the basic functionity of DNS. > > > > 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? > > > > > 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") > > > > 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 owner-idn@ops.ietf.org Sun Mar 23 09:06:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02129 for ; Sun, 23 Mar 2003 09:06:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x65u-0009I8-00 for idn-data@psg.com; Sun, 23 Mar 2003 06:05:02 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 18x65N-0009G5-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 06:04:30 -0800 Received: (qmail 62515 invoked from network); 23 Mar 2003 14:15:30 -0000 Received: from bb220-255-109-44.singnet.com.sg (HELO JSENGTOSHIBA) (220.255.109.44) by sentosa.post1.com with SMTP; 23 Mar 2003 14:15:30 -0000 Message-ID: <014b01c2f145$0721d390$1300a8c0@JSENGTOSHIBA> From: "James Seng" To: "=?iso-8859-1?Q?Martin_v._L=F6wis?=" Cc: "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030308144925.03c6fad0@localhost><3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com><4.2.0.58.J.20030308144925.03c6fad0@localhost><4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030321204149.0321f9c0@localhost><3E7CD0BF.1050807@v.loewis.de><004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 22:03:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 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. Two wrong dont make it right. Nothing in RFC 1034 & 1035 mention the DNS should response error with error. > 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. 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 owner-idn@ops.ietf.org Sun Mar 23 09:18:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02262 for ; Sun, 23 Mar 2003 09:18:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x6Gk-0009xQ-00 for idn-data@psg.com; Sun, 23 Mar 2003 06:16:14 -0800 Received: from www.namesbeyond.com ([216.220.34.103] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 18x6GE-0009tn-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 06:15:42 -0800 Message-ID: <00e301c2f146$862aecc0$f108bdc8@neteka.inc> From: "Edmon Chung" To: "James Seng" , "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 09:14:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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" To: "Edmon Chung" ; "IDN" Sent: Sunday, March 23, 2003 8:46 AM Subject: Re: [idn] IDN eamples for testing > 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" > To: "James Seng" ; "IDN" > Sent: Sunday, March 23, 2003 9:03 PM > Subject: Re: [idn] IDN eamples for testing > > > > 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 > > > > > > ----- Original Message ----- > > From: "James Seng" > > To: "IDN" > > Sent: Saturday, March 22, 2003 7:06 PM > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > The .nu operator supports IDNA, among other things (you also > > > > can sent UTF-8 and various local encodings to their DNS servers). > > > > > > This sound bad. This is breaking the basic functionity of DNS. > > > > > > 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? > > > > > > > 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") > > > > > > 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 owner-idn@ops.ietf.org Sun Mar 23 09:38:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02434 for ; Sun, 23 Mar 2003 09:38:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x6Zi-000B7u-00 for idn-data@psg.com; Sun, 23 Mar 2003 06:35:50 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 18x6Xs-000Azd-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 06:33:56 -0800 Received: (qmail 62707 invoked from network); 23 Mar 2003 14:44:56 -0000 Received: from bb220-255-109-44.singnet.com.sg (HELO JSENGTOSHIBA) (220.255.109.44) by sentosa.post1.com with SMTP; 23 Mar 2003 14:44:56 -0000 Message-ID: <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> From: "James Seng" To: "Edmon Chung" , "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 22:33:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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" To: "James Seng" ; "IDN" Sent: Sunday, March 23, 2003 10:14 PM Subject: Re: [idn] IDN eamples for testing > 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" > To: "Edmon Chung" ; "IDN" > Sent: Sunday, March 23, 2003 8:46 AM > Subject: Re: [idn] IDN eamples for testing > > > > 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" > > To: "James Seng" ; "IDN" > > Sent: Sunday, March 23, 2003 9:03 PM > > Subject: Re: [idn] IDN eamples for testing > > > > > > > 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 > > > > > > > > > ----- Original Message ----- > > > From: "James Seng" > > > To: "IDN" > > > Sent: Saturday, March 22, 2003 7:06 PM > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > The .nu operator supports IDNA, among other things (you also > > > > > can sent UTF-8 and various local encodings to their DNS servers). > > > > > > > > This sound bad. This is breaking the basic functionity of DNS. > > > > > > > > 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? > > > > > > > > > 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") > > > > > > > > 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 owner-idn@ops.ietf.org Sun Mar 23 09:40:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02467 for ; Sun, 23 Mar 2003 09:40:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x6cd-000BHM-00 for idn-data@psg.com; Sun, 23 Mar 2003 06:38:51 -0800 Received: from mailout05.sul.t-online.com ([194.25.134.82]) by psg.com with esmtp (Exim 3.36 #1) id 18x6c7-000BEm-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 06:38:19 -0800 Received: from fwd04.sul.t-online.de by mailout05.sul.t-online.com with smtp id 18x6bf-0007Pr-0B; Sun, 23 Mar 2003 15:37:51 +0100 Received: from v.loewis.de (03047300346-0001@[217.232.44.212]) by fmrl04.sul.t-online.com with esmtp id 18x6bZ-2Hz0fgC; Sun, 23 Mar 2003 15:37:45 +0100 Message-ID: <3E7DC6C0.4010801@v.loewis.de> Date: Sun, 23 Mar 2003 15:37:52 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.3) Gecko/20030312 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: James Seng CC: IDN Subject: Re: [idn] IDN eamples for testing References: <4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030308144925.03c6fad0@localhost><3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com><4.2.0.58.J.20030308144925.03c6fad0@localhost><4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030321204149.0321f9c0@localhost><3E7CD0BF.1050807@v.loewis.de><004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <014b01c2f145$0721d390$1300a8c0@JSENGTOSHIBA> In-Reply-To: <014b01c2f145$0721d390$1300a8c0@JSENGTOSHIBA> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng schrieb: >>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. > > > Two wrong dont make it right. Nothing in RFC 1034 & 1035 mention the DNS > 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". > According to RFC 2616, the BNF for Host header is as follows: > > Host = "Host" ":" host [ ":" port ] > > 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 owner-idn@ops.ietf.org Sun Mar 23 09:42:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02493 for ; Sun, 23 Mar 2003 09:42:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x6dc-000BJx-00 for idn-data@psg.com; Sun, 23 Mar 2003 06:39:52 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 18x6d6-000BHP-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 06:39:20 -0800 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.8/8.12.8) with ESMTP id h2NEcsrk018785 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 23 Mar 2003 15:38:54 +0100 To: "James Seng" Cc: "Martin v. =?iso-8859-1?q?L=F6wis?=" , "IDN" Subject: [idn] Re: IDN eamples for testing X-Payment: hashcash 1.2 0:030323:jseng@pobox.org.sg:15b693aedb5afc5f X-Hashcash: 0:030323:jseng@pobox.org.sg:15b693aedb5afc5f X-Payment: hashcash 1.2 0:030323:martin@v.loewis.de:851dd7acdc8e78b7 X-Hashcash: 0:030323:martin@v.loewis.de:851dd7acdc8e78b7 X-Payment: hashcash 1.2 0:030323:idn@ops.ietf.org:385f0fa0ed3ec092 X-Hashcash: 0:030323:idn@ops.ietf.org:385f0fa0ed3ec092 From: Simon Josefsson Date: Sun, 23 Mar 2003 15:38:54 +0100 In-Reply-To: <014b01c2f145$0721d390$1300a8c0@JSENGTOSHIBA> ("James Seng"'s message of "Sun, 23 Mar 2003 22:03:47 +0800") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.3.50 (gnu/linux) References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <014b01c2f145$0721d390$1300a8c0@JSENGTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk "James Seng" writes: >> 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. > > Two wrong dont make it right. Nothing in RFC 1034 & 1035 mention the DNS > 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 owner-idn@ops.ietf.org Sun Mar 23 10:02:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02714 for ; Sun, 23 Mar 2003 10:02:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x6wt-000Dz2-00 for idn-data@psg.com; Sun, 23 Mar 2003 06:59:47 -0800 Received: from www.namesbeyond.com ([216.220.34.103] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 18x6wO-000Deo-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 06:59:16 -0800 Message-ID: <016301c2f14c$a2547e10$f108bdc8@neteka.inc> From: "Edmon Chung" To: "James Seng" , "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 09:58:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 ----- From: "James Seng" > 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. > 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" > To: "James Seng" ; "IDN" > Sent: Sunday, March 23, 2003 10:14 PM > Subject: Re: [idn] IDN eamples for testing > > > > 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" > > To: "Edmon Chung" ; "IDN" > > Sent: Sunday, March 23, 2003 8:46 AM > > Subject: Re: [idn] IDN eamples for testing > > > > > > > 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" > > > To: "James Seng" ; "IDN" > > > Sent: Sunday, March 23, 2003 9:03 PM > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > 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 > > > > > > > > > > > > ----- Original Message ----- > > > > From: "James Seng" > > > > To: "IDN" > > > > Sent: Saturday, March 22, 2003 7:06 PM > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > > The .nu operator supports IDNA, among other things (you also > > > > > > can sent UTF-8 and various local encodings to their DNS servers). > > > > > > > > > > This sound bad. This is breaking the basic functionity of DNS. > > > > > > > > > > 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? > > > > > > > > > > > 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") > > > > > > > > > > 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 owner-idn@ops.ietf.org Sun Mar 23 10:07:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03187 for ; Sun, 23 Mar 2003 10:07:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x72d-000Gh9-00 for idn-data@psg.com; Sun, 23 Mar 2003 07:05:43 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 18x71y-000GSF-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 07:05:02 -0800 Received: (qmail 63144 invoked from network); 23 Mar 2003 15:16:02 -0000 Received: from bb220-255-109-44.singnet.com.sg (HELO JSENGTOSHIBA) (220.255.109.44) by sentosa.post1.com with SMTP; 23 Mar 2003 15:16:02 -0000 Message-ID: <00d601c2f14d$7749db60$1300a8c0@JSENGTOSHIBA> From: "James Seng" To: "Simon Josefsson" Cc: "=?iso-8859-1?Q?Martin_v._L=F6wis?=" , "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030308144925.03c6fad0@localhost><3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com><4.2.0.58.J.20030308144925.03c6fad0@localhost><4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030321204149.0321f9c0@localhost><3E7CD0BF.1050807@v.loewis.de><004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA><014b01c2f145$0721d390$1300a8c0@JSENGTOSHIBA> Subject: [idn] Re: IDN eamples for testing Date: Sun, 23 Mar 2003 23:04:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 > "James Seng" writes: > > >> 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. > > > > Two wrong dont make it right. Nothing in RFC 1034 & 1035 mention the DNS > > 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 owner-idn@ops.ietf.org Sun Mar 23 10:09:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03346 for ; Sun, 23 Mar 2003 10:09:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x74F-000H2O-00 for idn-data@psg.com; Sun, 23 Mar 2003 07:07:23 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 18x73h-000Gqd-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 07:06:49 -0800 Received: (qmail 63154 invoked from network); 23 Mar 2003 15:17:49 -0000 Received: from bb220-255-109-44.singnet.com.sg (HELO JSENGTOSHIBA) (220.255.109.44) by sentosa.post1.com with SMTP; 23 Mar 2003 15:17:49 -0000 Message-ID: <00ee01c2f14d$b6b423f0$1300a8c0@JSENGTOSHIBA> From: "James Seng" To: "Edmon Chung" , "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> <016301c2f14c$a2547e10$f108bdc8@neteka.inc> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 23:05:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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" To: "James Seng" ; "IDN" Sent: Sunday, March 23, 2003 10:58 PM Subject: Re: [idn] IDN eamples for testing > 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 ----- > From: "James Seng" > > 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. > > > > > > > > > > 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" > > To: "James Seng" ; "IDN" > > Sent: Sunday, March 23, 2003 10:14 PM > > Subject: Re: [idn] IDN eamples for testing > > > > > > > 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" > > > To: "Edmon Chung" ; "IDN" > > > Sent: Sunday, March 23, 2003 8:46 AM > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > 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" > > > > To: "James Seng" ; "IDN" > > > > Sent: Sunday, March 23, 2003 9:03 PM > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "James Seng" > > > > > To: "IDN" > > > > > Sent: Saturday, March 22, 2003 7:06 PM > > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > > > > > The .nu operator supports IDNA, among other things (you also > > > > > > > can sent UTF-8 and various local encodings to their DNS > servers). > > > > > > > > > > > > This sound bad. This is breaking the basic functionity of DNS. > > > > > > > > > > > > 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? > > > > > > > > > > > > > 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") > > > > > > > > > > > > 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 owner-idn@ops.ietf.org Sun Mar 23 10:19:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04193 for ; Sun, 23 Mar 2003 10:19:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x7E8-000O7t-00 for idn-data@psg.com; Sun, 23 Mar 2003 07:17:36 -0800 Received: from mailout10.sul.t-online.com ([194.25.134.21]) by psg.com with esmtp (Exim 3.36 #1) id 18x7Dc-000NeR-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 07:17:04 -0800 Received: from fwd04.sul.t-online.de by mailout10.sul.t-online.com with smtp id 18x7D4-0006cA-05; Sun, 23 Mar 2003 16:16:30 +0100 Received: from v.loewis.de (03047300346-0001@[217.232.44.212]) by fmrl04.sul.t-online.com with esmtp id 18x7Cw-229b7YC; Sun, 23 Mar 2003 16:16:22 +0100 Message-ID: <3E7DCFCC.1020104@v.loewis.de> Date: Sun, 23 Mar 2003 16:16:28 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.3) Gecko/20030312 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: James Seng CC: Simon Josefsson , IDN Subject: [idn] Re: IDN eamples for testing References: <4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030308144925.03c6fad0@localhost><3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com><4.2.0.58.J.20030308144925.03c6fad0@localhost><4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030321204149.0321f9c0@localhost><3E7CD0BF.1050807@v.loewis.de><004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA><014b01c2f145$0721d390$1300a8c0@JSENGTOSHIBA> <00d601c2f14d$7749db60$1300a8c0@JSENGTOSHIBA> In-Reply-To: <00d601c2f14d$7749db60$1300a8c0@JSENGTOSHIBA> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng schrieb: > Secondly, such solution deployed outside a testbed/trials would only hinder > 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 owner-idn@ops.ietf.org Sun Mar 23 10:19:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04207 for ; Sun, 23 Mar 2003 10:19:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x7CM-000MIm-00 for idn-data@psg.com; Sun, 23 Mar 2003 07:15:46 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 18x7BQ-000Ld9-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 07:14:49 -0800 Received: (qmail 63217 invoked from network); 23 Mar 2003 15:25:49 -0000 Received: from bb220-255-109-44.singnet.com.sg (HELO JSENGTOSHIBA) (220.255.109.44) by sentosa.post1.com with SMTP; 23 Mar 2003 15:25:48 -0000 Message-ID: <011e01c2f14e$d2a6b900$1300a8c0@JSENGTOSHIBA> From: "James Seng" To: "James Seng" , "Edmon Chung" , "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> <016301c2f14c$a2547e10$f108bdc8@neteka.inc> <00ee01c2f14d$b6b423f0$1300a8c0@JSENGTOSHIBA> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 23:13:55 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=1.1 required=5.0 tests=FROM_AND_TO_SAME_6,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03,USER_AGENT_OE version=2.44 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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" To: "Edmon Chung" ; "IDN" Sent: Sunday, March 23, 2003 11:05 PM Subject: Re: [idn] IDN eamples for testing > 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" > To: "James Seng" ; "IDN" > Sent: Sunday, March 23, 2003 10:58 PM > Subject: Re: [idn] IDN eamples for testing > > > > 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 ----- > > From: "James Seng" > > > 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. > > > > > > > > > > > > > > > > > > > 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" > > > To: "James Seng" ; "IDN" > > > Sent: Sunday, March 23, 2003 10:14 PM > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > 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" > > > > To: "Edmon Chung" ; "IDN" > > > > Sent: Sunday, March 23, 2003 8:46 AM > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > 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" > > > > > To: "James Seng" ; "IDN" > > > > > Sent: Sunday, March 23, 2003 9:03 PM > > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "James Seng" > > > > > > To: "IDN" > > > > > > Sent: Saturday, March 22, 2003 7:06 PM > > > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > > > > > > > > The .nu operator supports IDNA, among other things (you also > > > > > > > > can sent UTF-8 and various local encodings to their DNS > > servers). > > > > > > > > > > > > > > This sound bad. This is breaking the basic functionity of DNS. > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > 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") > > > > > > > > > > > > > > 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 owner-idn@ops.ietf.org Sun Mar 23 10:26:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04302 for ; Sun, 23 Mar 2003 10:26:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x7KL-0004es-00 for idn-data@psg.com; Sun, 23 Mar 2003 07:24:01 -0800 Received: from h00045aed6116.ne.client2.attbi.com ([24.60.107.9] helo=Thinkpad) by psg.com with esmtp (Exim 3.36 #1) id 18x7Jp-0003yS-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 07:23:29 -0800 Received: from Thinkpad.mail.nic.nu ([127.0.0.1]) by Thinkpad with Microsoft SMTPSVC(6.0.2600.1106); Sun, 23 Mar 2003 10:23:03 -0500 Message-Id: <5.1.1.6.2.20030323102250.06203ca8@mail.nic.nu> X-Sender: billnospam@nic.nu@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sun, 23 Mar 2003 10:23:01 -0500 To: =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , James Seng From: "J. William Semich" Subject: Re: [idn] IDN examples for testing Cc: IDN In-Reply-To: <3E7DC6C0.4010801@v.loewis.de> References: <014b01c2f145$0721d390$1300a8c0@JSENGTOSHIBA> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <014b01c2f145$0721d390$1300a8c0@JSENGTOSHIBA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 23 Mar 2003 15:23:03.0503 (UTC) FILETIME=[18C4E5F0:01C2F150] X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA04302 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. Lwis wrote: >James Seng schrieb: >>>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. >> >>Two wrong dont make it right. Nothing in RFC 1034 & 1035 mention the DNS >>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". > >>According to RFC 2616, the BNF for Host header is as follows: >> Host = "Host" ":" host [ ":" port ] >>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 Bill Semich President and CEO .NU Domain Ltd http://www.nunames.nu bill@nic.nu +1 508 359 5600 ext 110 See IDG's "IT Folk" http://itfolk.idg.se/person.asp?n=william_j_semich&type=2 From owner-idn@ops.ietf.org Sun Mar 23 10:33:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04468 for ; Sun, 23 Mar 2003 10:33:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x7Qx-0008JA-00 for idn-data@psg.com; Sun, 23 Mar 2003 07:30:51 -0800 Received: from www.namesbeyond.com ([216.220.34.103] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 18x7QQ-00084U-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 07:30:18 -0800 Message-ID: <01a201c2f150$f81ef010$f108bdc8@neteka.inc> From: "Edmon Chung" To: "James Seng" , "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> <016301c2f14c$a2547e10$f108bdc8@neteka.inc> <00ee01c2f14d$b6b423f0$1300a8c0@JSENGTOSHIBA> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 10:29:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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" To: "Edmon Chung" ; "IDN" Sent: Sunday, March 23, 2003 10:05 AM Subject: Re: [idn] IDN eamples for testing > 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" > To: "James Seng" ; "IDN" > Sent: Sunday, March 23, 2003 10:58 PM > Subject: Re: [idn] IDN eamples for testing > > > > 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 ----- > > From: "James Seng" > > > 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. > > > > > > > > > > > > > > > > > > > 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" > > > To: "James Seng" ; "IDN" > > > Sent: Sunday, March 23, 2003 10:14 PM > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > 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" > > > > To: "Edmon Chung" ; "IDN" > > > > Sent: Sunday, March 23, 2003 8:46 AM > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > 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" > > > > > To: "James Seng" ; "IDN" > > > > > Sent: Sunday, March 23, 2003 9:03 PM > > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "James Seng" > > > > > > To: "IDN" > > > > > > Sent: Saturday, March 22, 2003 7:06 PM > > > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > > > > > > > > The .nu operator supports IDNA, among other things (you also > > > > > > > > can sent UTF-8 and various local encodings to their DNS > > servers). > > > > > > > > > > > > > > This sound bad. This is breaking the basic functionity of DNS. > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > 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") > > > > > > > > > > > > > > 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 owner-idn@ops.ietf.org Sun Mar 23 10:45:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04724 for ; Sun, 23 Mar 2003 10:45:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x7c4-000GLj-00 for idn-data@psg.com; Sun, 23 Mar 2003 07:42:20 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 18x7bX-000G0U-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 07:41:47 -0800 Received: (qmail 63462 invoked from network); 23 Mar 2003 15:52:47 -0000 Received: from bb220-255-109-44.singnet.com.sg (HELO JSENGTOSHIBA) (220.255.109.44) by sentosa.post1.com with SMTP; 23 Mar 2003 15:52:47 -0000 Message-ID: <01ee01c2f152$954c40d0$1300a8c0@JSENGTOSHIBA> From: "James Seng" To: "Edmon Chung" , "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> <016301c2f14c$a2547e10$f108bdc8@neteka.inc> <00ee01c2f14d$b6b423f0$1300a8c0@JSENGTOSHIBA> <01a201c2f150$f81ef010$f108bdc8@neteka.inc> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 23:40:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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" To: "James Seng" ; "IDN" Sent: Sunday, March 23, 2003 11:29 PM Subject: Re: [idn] IDN eamples for testing > 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" > To: "Edmon Chung" ; "IDN" > Sent: Sunday, March 23, 2003 10:05 AM > Subject: Re: [idn] IDN eamples for testing > > > > 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" > > To: "James Seng" ; "IDN" > > Sent: Sunday, March 23, 2003 10:58 PM > > Subject: Re: [idn] IDN eamples for testing > > > > > > > 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 ----- > > > From: "James Seng" > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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" > > > > To: "James Seng" ; "IDN" > > > > Sent: Sunday, March 23, 2003 10:14 PM > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > 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" > > > > > To: "Edmon Chung" ; "IDN" > > > > > Sent: Sunday, March 23, 2003 8:46 AM > > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > > > > 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" > > > > > > To: "James Seng" ; "IDN" > > > > > > Sent: Sunday, March 23, 2003 9:03 PM > > > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "James Seng" > > > > > > > To: "IDN" > > > > > > > Sent: Saturday, March 22, 2003 7:06 PM > > > > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > > > > > > > > > > > The .nu operator supports IDNA, among other things (you also > > > > > > > > > can sent UTF-8 and various local encodings to their DNS > > > servers). > > > > > > > > > > > > > > > > This sound bad. This is breaking the basic functionity of DNS. > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > > 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") > > > > > > > > > > > > > > > > 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 owner-idn@ops.ietf.org Sun Mar 23 10:58:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04994 for ; Sun, 23 Mar 2003 10:58:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x7q3-000Lsk-00 for idn-data@psg.com; Sun, 23 Mar 2003 07:56:47 -0800 Received: from smtp.mailbox.co.uk ([195.82.125.32]) by psg.com with esmtp (Exim 3.36 #1) id 18x7pX-000LTj-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 07:56:15 -0800 Received: from [212.18.236.61] (helo=STEVE-LAPTOP.centralnic.com) by smtp.mailbox.co.uk with esmtp (Exim 3.36 #1) id 18x7p9-00057k-00; Sun, 23 Mar 2003 15:55:51 +0000 Message-Id: <5.1.0.14.2.20030323154440.01da7d40@lon-imap-1.centralnic.net> X-Sender: steve@lon-imap-1.centralnic.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 23 Mar 2003 15:55:49 +0000 To: "Edmon Chung" , "IDN" From: Steve Dyer Subject: Re: [idn] IDN eamples for testing In-Reply-To: <01a201c2f150$f81ef010$f108bdc8@neteka.inc> References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> <016301c2f14c$a2547e10$f108bdc8@neteka.inc> <00ee01c2f14d$b6b423f0$1300a8c0@JSENGTOSHIBA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:29 23/03/2003 -0500, Edmon Chung wrote: >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?... 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 owner-idn@ops.ietf.org Sun Mar 23 11:10:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05119 for ; Sun, 23 Mar 2003 11:10:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x80F-000Odx-00 for idn-data@psg.com; Sun, 23 Mar 2003 08:07:19 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 18x7zj-000OUP-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 08:06:47 -0800 Received: (qmail 63678 invoked from network); 23 Mar 2003 16:17:46 -0000 Received: from bb220-255-109-44.singnet.com.sg (HELO JSENGTOSHIBA) (220.255.109.44) by sentosa.post1.com with SMTP; 23 Mar 2003 16:17:46 -0000 Message-ID: <020d01c2f156$107d16f0$1300a8c0@JSENGTOSHIBA> From: "James Seng" To: "Edmon Chung" , "IDN" , "Steve Dyer" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> <016301c2f14c$a2547e10$f108bdc8@neteka.inc> <00ee01c2f14d$b6b423f0$1300a8c0@JSENGTOSHIBA> <5.1.0.14.2.20030323154440.01da7d40@lon-imap-1.centralnic.net> Subject: Re: [idn] IDN eamples for testing Date: Mon, 24 Mar 2003 00:05:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 > 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 owner-idn@ops.ietf.org Sun Mar 23 11:24:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05215 for ; Sun, 23 Mar 2003 11:24:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x8E3-00026A-00 for idn-data@psg.com; Sun, 23 Mar 2003 08:21:35 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 18x8DW-0001cl-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 08:21:02 -0800 Received: (qmail 63827 invoked from network); 23 Mar 2003 16:32:02 -0000 Received: from bb220-255-109-44.singnet.com.sg (HELO JSENGTOSHIBA) (220.255.109.44) by sentosa.post1.com with SMTP; 23 Mar 2003 16:32:02 -0000 Message-ID: <02ca01c2f158$0a72d8b0$1300a8c0@JSENGTOSHIBA> From: "James Seng" To: "Edmon Chung" , "IDN" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> <016301c2f14c$a2547e10$f108bdc8@neteka.inc> <00ee01c2f14d$b6b423f0$1300a8c0@JSENGTOSHIBA> <01a201c2f150$f81ef010$f108bdc8@neteka.inc> Subject: Re: [idn] IDN eamples for testing Date: Mon, 24 Mar 2003 00:19:54 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_OE version=2.44 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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" To: "James Seng" ; "IDN" Sent: Sunday, March 23, 2003 11:29 PM Subject: Re: [idn] IDN eamples for testing > 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" > To: "Edmon Chung" ; "IDN" > Sent: Sunday, March 23, 2003 10:05 AM > Subject: Re: [idn] IDN eamples for testing > > > > 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" > > To: "James Seng" ; "IDN" > > Sent: Sunday, March 23, 2003 10:58 PM > > Subject: Re: [idn] IDN eamples for testing > > > > > > > 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 ----- > > > From: "James Seng" > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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" > > > > To: "James Seng" ; "IDN" > > > > Sent: Sunday, March 23, 2003 10:14 PM > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > 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" > > > > > To: "Edmon Chung" ; "IDN" > > > > > Sent: Sunday, March 23, 2003 8:46 AM > > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > > > > 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" > > > > > > To: "James Seng" ; "IDN" > > > > > > Sent: Sunday, March 23, 2003 9:03 PM > > > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "James Seng" > > > > > > > To: "IDN" > > > > > > > Sent: Saturday, March 22, 2003 7:06 PM > > > > > > > Subject: Re: [idn] IDN eamples for testing > > > > > > > > > > > > > > > > > > > > > > > The .nu operator supports IDNA, among other things (you also > > > > > > > > > can sent UTF-8 and various local encodings to their DNS > > > servers). > > > > > > > > > > > > > > > > This sound bad. This is breaking the basic functionity of DNS. > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > > 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") > > > > > > > > > > > > > > > > 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 owner-idn@ops.ietf.org Sun Mar 23 13:08:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06183 for ; Sun, 23 Mar 2003 13:08:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x9jz-000Ibw-00 for idn-data@psg.com; Sun, 23 Mar 2003 09:58:39 -0800 Received: from www.namesbeyond.com ([216.220.34.103] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 18x9jT-000IVS-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 09:58:07 -0800 Message-ID: <01d101c2f165$9dda3730$f108bdc8@neteka.inc> From: "Edmon Chung" To: "James Seng" , "IDN" , "Steve Dyer" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> <016301c2f14c$a2547e10$f108bdc8@neteka.inc> <00ee01c2f14d$b6b423f0$1300a8c0@JSENGTOSHIBA> <5.1.0.14.2.20030323154440.01da7d40@lon-imap-1.centralnic.net> <020d01c2f156$107d16f0$1300a8c0@JSENGTOSHIBA> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 12:57:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-12.9 required=5.0 tests=ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "James Seng" > claiming conformance to standard but they are not. I am living to my own > standard. > 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 owner-idn@ops.ietf.org Sun Mar 23 13:13:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06227 for ; Sun, 23 Mar 2003 13:13:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x9sI-000JBs-00 for idn-data@psg.com; Sun, 23 Mar 2003 10:07:14 -0800 Received: from www.namesbeyond.com ([216.220.34.103] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 18x9rG-000J14-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 10:06:11 -0800 Message-ID: <01fd01c2f166$c3877d70$f108bdc8@neteka.inc> From: "Edmon Chung" To: Subject: [idn] IDN Operations (Charprep, Zoneprep & IDNoverEPP) Date: Sun, 23 Mar 2003 13:05:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Everyone, Just in case this didnt get through: I have been working on a number of documents about Character Equivalence preparation issues leading towards their implications to registration provisioning such as EPP. More specifically, a technical framework (elaborating IDN-ADMIN) that provides a generic transaction architecture for provisioning and zone preparations for IDNs. I wonder if anyone might be interested in discussing those topics... and I wonder if this list is an appropriate forum. What do people think? Edmon PS. I apologize to my side discussion with James about "his standard" which might have obscured this discussion. From owner-idn@ops.ietf.org Sun Mar 23 15:53:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10711 for ; Sun, 23 Mar 2003 15:53:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xCLg-0003rs-00 for idn-data@psg.com; Sun, 23 Mar 2003 12:45:44 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 18xCL8-0003m6-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 12:45:12 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18xCKi-0004da-00 for ; Sun, 23 Mar 2003 12:44:44 -0800 Date: Sun, 23 Mar 2003 20:44:44 +0000 From: "Adam M. Costello" To: IDN Subject: Re: [idn] IDN eamples for testing Message-ID: <20030323204444.GA16244@nicemice.net> Reply-To: IETF idn working group References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <014b01c2f145$0721d390$1300a8c0@JSENGTOSHIBA> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit "Martin v. Lwis" wrote: > 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. 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 owner-idn@ops.ietf.org Sun Mar 23 18:52:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15724 for ; Sun, 23 Mar 2003 18:52:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xFAB-000I9N-00 for idn-data@psg.com; Sun, 23 Mar 2003 15:46:03 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 18xF9f-000I51-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 15:45:31 -0800 Received: (qmail 66145 invoked from network); 23 Mar 2003 23:56:28 -0000 Received: from bb220-255-109-44.singnet.com.sg (HELO JSENGTOSHIBA) (220.255.109.44) by sentosa.post1.com with SMTP; 23 Mar 2003 23:56:28 -0000 Message-ID: <053401c2f196$321105c0$1300a8c0@JSENGTOSHIBA> From: "James Seng" To: "Edmon Chung" , "IDN" , "Steve Dyer" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <3E7CD0BF.1050807@v.loewis.de> <004801c2f0d0$08cf43a0$1300a8c0@JSENGTOSHIBA> <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> <016301c2f14c$a2547e10$f108bdc8@neteka.inc> <00ee01c2f14d$b6b423f0$1300a8c0@JSENGTOSHIBA> <5.1.0.14.2.20030323154440.01da7d40@lon-imap-1.centralnic.net> <020d01c2f156$107d16f0$1300a8c0@JSENGTOSHIBA> <01d101c2f165$9dda3730$f108bdc8@neteka.inc> Subject: Re: [idn] IDN eamples for testing Date: Mon, 24 Mar 2003 07:44:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 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". 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 owner-idn@ops.ietf.org Sun Mar 23 19:05:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15950 for ; Sun, 23 Mar 2003 19:05:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xFPk-000Jjl-00 for idn-data@psg.com; Sun, 23 Mar 2003 16:02:08 -0800 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 18xFOK-000Jak-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 16:00:40 -0800 Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2O00Cg09182; Sun, 23 Mar 2003 16:00:12 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <01fd01c2f166$c3877d70$f108bdc8@neteka.inc> References: <01fd01c2f166$c3877d70$f108bdc8@neteka.inc> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sun, 23 Mar 2003 16:00:10 -0800 To: "Edmon Chung" , From: Paul Hoffman / IMC Subject: Re: [idn] IDN Operations (Charprep, Zoneprep & IDNoverEPP) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.2 required=5.0 tests=EMAIL_ATTRIBUTION,HABEAS_SWE,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk At 1:05 PM -0500 3/23/03, Edmon Chung wrote: >Hi Everyone, > >Just in case this didnt get through: > >I have been working on a number of documents about Character Equivalence >preparation issues leading towards their implications to registration >provisioning such as EPP. More specifically, a technical framework >(elaborating IDN-ADMIN) that provides a generic transaction architecture for >provisioning and zone preparations for IDNs. I wonder if anyone might be >interested in discussing those topics... and I wonder if this list is an >appropriate forum. There are lots of folks interested in discussing them. I don't think the IDN WG list is appropriate because those discussions are outside the charter of the soon-to-be-closed-down WG. I have just created a new list for discussing the non-protocol parts of the area (see my previous message). For the protocol parts, such as how to handle whois, you should have the discussion on the appropriate protocol mailing list. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sun Mar 23 19:09:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16008 for ; Sun, 23 Mar 2003 19:09:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xFPB-000Jgw-00 for idn-data@psg.com; Sun, 23 Mar 2003 16:01:33 -0800 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 18xFOH-000Jah-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 16:00:37 -0800 Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2O00Bg09177 for ; Sun, 23 Mar 2003 16:00:11 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sun, 23 Mar 2003 15:57:37 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: [idn] New mailing list for IDN registry policy Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.3 required=5.0 tests=HABEAS_SWE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Greetings again. IMC has set up a new mailing list for discussing IDN registration policy. See for subscription information. There are a few reasons for us setting up this new list: - The IDN WG mailing list is for discussing IETF protocols, and IDN registration policy is not protocol-based - The mailing list at ICANN is closed and is not discussed on the ICANN site - The new list can be used to help give people background information before the IDNConnect event Note that this new list is for discussing non-protocol issues with IDN registration; protocol-oriented discussions (such as how to handle registry-registrar interactions and whois) should happen on the appropriate IETF mailing lists. Please let me know if you have any questions. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sun Mar 23 20:27:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17402 for ; Sun, 23 Mar 2003 20:27:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xGfs-00015x-00 for idn-data@psg.com; Sun, 23 Mar 2003 17:22:52 -0800 Received: from dav51.sea2.hotmail.com ([207.68.164.40] helo=hotmail.com) by psg.com with esmtp (Exim 3.36 #1) id 18xGfM-000129-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 17:22:20 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 23 Mar 2003 17:21:57 -0800 Received: from 68.84.47.36 by DAV51.sea2.internal.hotmail.com with DAV; Mon, 24 Mar 2003 01:21:57 +0000 X-Originating-IP: [68.84.47.36] X-Originating-Email: [ricjohnsoniii@hotmail.com] From: "Ric Johnson" To: "IDN" , "Martin Duerst" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> Subject: Re: [idn] IDN eamples for testing Date: Sun, 23 Mar 2003 20:21:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: X-OriginalArrivalTime: 24 Mar 2003 01:21:57.0628 (UTC) FILETIME=[C32D3BC0:01C2F1A3] X-Spam-Status: No, hits=-12.9 required=5.0 tests=ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit 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 ----- Original Message ----- From: "Martin Duerst" To: "IDN" Sent: Friday, March 21, 2003 8:47 PM Subject: [idn] IDN eamples for testing > 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 owner-idn@ops.ietf.org Mon Mar 24 02:03:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28434 for ; Mon, 24 Mar 2003 02:03:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xLkN-0003rz-00 for idn-data@psg.com; Sun, 23 Mar 2003 22:47:51 -0800 Received: from mailout05.sul.t-online.com ([194.25.134.82]) by psg.com with esmtp (Exim 3.36 #1) id 18xLjq-0003iQ-00 for idn@ops.ietf.org; Sun, 23 Mar 2003 22:47:18 -0800 Received: from fwd02.sul.t-online.de by mailout05.sul.t-online.com with smtp id 18xLjQ-0000gh-00; Mon, 24 Mar 2003 07:46:52 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.17.30]) by fmrl02.sul.t-online.com with esmtp id 18xLjP-1s8xjkC; Mon, 24 Mar 2003 07:46:51 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2O6koo0001647; Mon, 24 Mar 2003 07:46:50 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id h2O6km3S001644; Mon, 24 Mar 2003 07:46:48 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: "Ric Johnson" Cc: "IDN" , "Martin Duerst" Subject: Re: [idn] IDN eamples for testing References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 24 Mar 2003 07:46:48 +0100 In-Reply-To: Message-ID: Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-30.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk "Ric Johnson" writes: > U+0192 > > 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 owner-idn@ops.ietf.org Mon Mar 24 09:05:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19010 for ; Mon, 24 Mar 2003 09:05:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xSIw-0008um-00 for idn-data@psg.com; Mon, 24 Mar 2003 05:47:58 -0800 Received: from www.namesbeyond.com ([216.220.34.103] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 18xSIH-0008ph-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 05:47:18 -0800 Message-ID: <038e01c2f20b$bdd2b520$f108bdc8@neteka.inc> From: "Edmon Chung" To: , "Paul Hoffman / IMC" References: <01fd01c2f166$c3877d70$f108bdc8@neteka.inc> Subject: Re: [idn] IDN Operations (Charprep, Zoneprep & IDNoverEPP) Date: Mon, 24 Mar 2003 08:46:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-12.9 required=5.0 tests=ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree entirely. That was why in the first place I asked about whether this is appropriate. :-) Edmon ----- Original Message ----- From: "Paul Hoffman / IMC" To: "Edmon Chung" ; Sent: Sunday, March 23, 2003 7:00 PM Subject: Re: [idn] IDN Operations (Charprep, Zoneprep & IDNoverEPP) > At 1:05 PM -0500 3/23/03, Edmon Chung wrote: > >Hi Everyone, > > > >Just in case this didnt get through: > > > >I have been working on a number of documents about Character Equivalence > >preparation issues leading towards their implications to registration > >provisioning such as EPP. More specifically, a technical framework > >(elaborating IDN-ADMIN) that provides a generic transaction architecture for > >provisioning and zone preparations for IDNs. I wonder if anyone might be > >interested in discussing those topics... and I wonder if this list is an > >appropriate forum. > > There are lots of folks interested in discussing them. I don't think > the IDN WG list is appropriate because those discussions are outside > the charter of the soon-to-be-closed-down WG. I have just created a > new list for discussing the non-protocol parts of the area (see my > previous message). For the protocol parts, such as how to handle > whois, you should have the discussion on the appropriate protocol > mailing list. > > --Paul Hoffman, Director > --Internet Mail Consortium > > From owner-idn@ops.ietf.org Mon Mar 24 09:05:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19032 for ; Mon, 24 Mar 2003 09:05:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xSIO-0008u7-00 for idn-data@psg.com; Mon, 24 Mar 2003 05:47:24 -0800 Received: from www.namesbeyond.com ([216.220.34.103] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 18xSHj-0008ot-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 05:46:44 -0800 Message-ID: <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> From: "Edmon Chung" To: "Ric Johnson" , "Martin v. Lwis" Cc: "IDN" , "Martin Duerst" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030308144925.03c6fad0@localhost><3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com><4.2.0.58.J.20030308144925.03c6fad0@localhost><4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030321204149.0321f9c0@localhost> Subject: Re: [idn] IDN eamples for testing Date: Mon, 24 Mar 2003 08:45:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-12.9 required=5.0 tests=ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit 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 ----- Original Message ----- From: "Martin v. Lwis" To: "Ric Johnson" Cc: "IDN" ; "Martin Duerst" Sent: Monday, March 24, 2003 1:46 AM Subject: Re: [idn] IDN eamples for testing > "Ric Johnson" writes: > > > U+0192 > > > > 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 owner-idn@ops.ietf.org Mon Mar 24 11:02:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24127 for ; Mon, 24 Mar 2003 11:02:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xUIr-000JXw-00 for idn-data@psg.com; Mon, 24 Mar 2003 07:56:01 -0800 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 18xUHR-000JMS-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 07:54:33 -0800 Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OFs5g16438 for ; Mon, 24 Mar 2003 07:54:05 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> References: <4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030308144925.0 3c6fad0@localhost><3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com><4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030321204149.0 321f9c0@localhost> <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 24 Mar 2003 07:54:00 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] IDN eamples for testing Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-16.1 required=5.0 tests=EMAIL_ATTRIBUTION,HABEAS_SWE,IN_REP_TO autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk 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 >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? 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 owner-idn@ops.ietf.org Mon Mar 24 11:51:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25154 for ; Mon, 24 Mar 2003 11:51:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xV1j-000Neh-00 for idn-data@psg.com; Mon, 24 Mar 2003 08:42:23 -0800 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 18xV1A-000NS5-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 08:41:51 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h2OGehu16301; Mon, 24 Mar 2003 11:40:43 -0500 (EST) Date: Mon, 24 Mar 2003 11:40:20 -0500 From: Marc Blanchet To: Edmon Chung cc: IDN Subject: Re: [idn] IDN eamples for testing Message-ID: <213630000.1048524020@classic.viagenie.qc.ca> In-Reply-To: <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost><3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com><4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-19.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -- lundi, mars 24, 2003 08:45:42 -0500 Edmon Chung wrote/a ecrit: > 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? quite simple: non-conformant to the standards. Marc. From owner-idn@ops.ietf.org Mon Mar 24 11:51:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25182 for ; Mon, 24 Mar 2003 11:51:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xV3F-000NkR-00 for idn-data@psg.com; Mon, 24 Mar 2003 08:43:57 -0800 Received: from mta6-0.mail.adelphia.net ([64.8.50.190] helo=mta6.adelphia.net) by psg.com with esmtp (Exim 3.36 #1) id 18xV2j-000Nfn-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 08:43:25 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.119]) by mta6.adelphia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with SMTP id <20030324164301.BSWL11848.mta6.adelphia.net@DouglasEwell.anhmca.adelphia.net>; Mon, 24 Mar 2003 11:43:01 -0500 Message-ID: <00d701c2f224$4788fe60$77424244@anhmca.adelphia.net> From: "Doug Ewell" To: Cc: "Edmon Chung" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030308144925.03c6fad0@localhost><3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com><4.2.0.58.J.20030308144925.03c6fad0@localhost><4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030321204149.0321f9c0@localhost> <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> Subject: Re: [idn] IDN eamples for testing Date: Mon, 24 Mar 2003 08:41:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=-22.8 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edmon Chung wrote: > 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? 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 owner-idn@ops.ietf.org Mon Mar 24 12:44:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26686 for ; Mon, 24 Mar 2003 12:44:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xVtY-00034e-00 for idn-data@psg.com; Mon, 24 Mar 2003 09:38:00 -0800 Received: from www.namesbeyond.com ([216.220.34.103] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 18xVt1-00030p-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 09:37:28 -0800 Message-ID: <042c01c2f22b$e99d9790$f108bdc8@neteka.inc> From: "Edmon Chung" To: "Doug Ewell" , References: <4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030308144925.03c6fad0@localhost><3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com><4.2.0.58.J.20030308144925.03c6fad0@localhost><4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030321204149.0321f9c0@localhost> <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> <00d701c2f224$4788fe60$77424244@anhmca.adelphia.net> Subject: Re: [idn] IDN eamples for testing Date: Mon, 24 Mar 2003 12:36:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-12.9 required=5.0 tests=ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ok. So the right way to do it is a clean break with no transition is what we are saying. That is good. Edmon ----- Original Message ----- From: "Doug Ewell" To: Cc: "Edmon Chung" Sent: Monday, March 24, 2003 11:41 AM Subject: Re: [idn] IDN eamples for testing > Edmon Chung wrote: > > > 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? > > 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 owner-idn@ops.ietf.org Mon Mar 24 12:52:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26848 for ; Mon, 24 Mar 2003 12:52:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xW0r-0003lM-00 for idn-data@psg.com; Mon, 24 Mar 2003 09:45:33 -0800 Received: from hosting.altserver.com ([209.124.80.2]) by psg.com with esmtp (Exim 3.36 #1) id 18xW0K-0003gn-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 09:45:00 -0800 Received: from f16v-5-49.d1.club-internet.fr ([212.195.204.49] helo=mine.jefsey.com) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18xVzl-00024M-00; Mon, 24 Mar 2003 09:44:26 -0800 Message-Id: <5.2.0.9.0.20030324180208.00a1d930@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 24 Mar 2003 18:51:45 +0100 To: Paul Hoffman / IMC , idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [idn] IDN eamples for testing In-Reply-To: References: <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.0 3c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0 321f9c0@localhost> <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Status: No, hits=-9.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk At 16:54 24/03/03, Paul Hoffman / IMC wrote: >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 owner-idn@ops.ietf.org Mon Mar 24 14:28:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29794 for ; Mon, 24 Mar 2003 14:28:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xXRE-000Cxu-00 for idn-data@psg.com; Mon, 24 Mar 2003 11:16:52 -0800 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by psg.com with esmtp (Exim 3.36 #1) id 18xXQh-000CqA-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 11:16:20 -0800 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HC90049YPE07C@firewall.wcom.com> for idn@ops.ietf.org; Mon, 24 Mar 2003 19:13:12 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HC900401PE098@pmismtp05.wcomnet.com>; Mon, 24 Mar 2003 19:13:12 +0000 (GMT) Received: from vint.wcom.com ([166.60.14.60]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HC9001A0PBARS@pmismtp05.wcomnet.com>; Mon, 24 Mar 2003 19:13:12 +0000 (GMT) Date: Mon, 24 Mar 2003 15:04:24 -0300 From: "vinton g. cerf" Subject: Re: [idn] IDN eamples for testing In-reply-to: <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> X-Sender: vcerf@pop.wcomnet.com To: Edmon Chung , Ric Johnson , "Martin v. =?UNKNOWN?Q?L=F6wis?=" Cc: IDN , Martin Duerst Message-id: <5.2.0.9.2.20030324150152.027559b8@pop.wcomnet.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; charset=iso-8859-1 References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> X-Spam-Status: No, hits=-26.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id OAA29794 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 At 08:45 AM 3/24/2003 -0500, Edmon Chung wrote: >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 > > >----- Original Message ----- >From: "Martin v. Lwis" >To: "Ric Johnson" >Cc: "IDN" ; "Martin Duerst" >Sent: Monday, March 24, 2003 1:46 AM >Subject: Re: [idn] IDN eamples for testing > > >> "Ric Johnson" writes: >> >> > U+0192 >> > >> > 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 >> >> 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 owner-idn@ops.ietf.org Mon Mar 24 16:15:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03997 for ; Mon, 24 Mar 2003 16:15:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xZ7C-000OPy-00 for idn-data@psg.com; Mon, 24 Mar 2003 13:04:18 -0800 Received: from www.namesbeyond.com ([216.220.34.103] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 18xZ6g-000OMZ-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 13:03:46 -0800 Message-ID: <047e01c2f248$bad9d3c0$f108bdc8@neteka.inc> From: "Edmon Chung" To: "vinton g. cerf" , "Ric Johnson" , "Martin v. Lwis" Cc: "IDN" , "Martin Duerst" References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <5.2.0.9.2.20030324150152.027559b8@pop.wcomnet.com> Subject: Re: [idn] IDN eamples for testing Date: Mon, 24 Mar 2003 16:02:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-25.9 required=5.0 tests=EMAIL_ATTRIBUTION,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit 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" To: "Edmon Chung" ; "Ric Johnson" ; "Martin v. Lwis" Cc: "IDN" ; "Martin Duerst" Sent: Monday, March 24, 2003 1:04 PM Subject: Re: [idn] IDN eamples for testing 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 At 08:45 AM 3/24/2003 -0500, Edmon Chung wrote: >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 > > >----- Original Message ----- >From: "Martin v. Lwis" >To: "Ric Johnson" >Cc: "IDN" ; "Martin Duerst" >Sent: Monday, March 24, 2003 1:46 AM >Subject: Re: [idn] IDN eamples for testing > > >> "Ric Johnson" writes: >> >> > U+0192 >> > >> > 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 >> >> 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 owner-idn@ops.ietf.org Mon Mar 24 16:47:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05033 for ; Mon, 24 Mar 2003 16:47:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xZfu-00018s-00 for idn-data@psg.com; Mon, 24 Mar 2003 13:40:10 -0800 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 18xZcg-0000oV-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 13:36:50 -0800 Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OLaMg02069 for ; Mon, 24 Mar 2003 13:36:22 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.2.0.9.2.20030324150152.027559b8@pop.wcomnet.com> References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <5.2.0.9.2.20030324150152.027559b8@pop.wcomnet.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 24 Mar 2003 13:33:55 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] IDN eamples for testing Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.2 required=5.0 tests=EMAIL_ATTRIBUTION,HABEAS_SWE,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk At 3:04 PM -0300 3/24/03, vinton g. cerf wrote: >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. 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 --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Mar 24 17:19:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05935 for ; Mon, 24 Mar 2003 17:19:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xa7f-0003QW-00 for idn-data@psg.com; Mon, 24 Mar 2003 14:08:51 -0800 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by psg.com with esmtp (Exim 3.36 #1) id 18xa78-0003Ja-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 14:08:19 -0800 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HC9002HZXAPL7@firewall.wcom.com> for idn@ops.ietf.org; Mon, 24 Mar 2003 22:04:01 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HC900901X3619@pmismtp04.wcomnet.com>; Mon, 24 Mar 2003 22:04:01 +0000 (GMT) Received: from vint.wcom.com ([166.60.14.60]) by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HC90094TXAB9M@pmismtp04.wcomnet.com>; Mon, 24 Mar 2003 22:03:54 +0000 (GMT) Date: Mon, 24 Mar 2003 19:03:38 -0300 From: "vinton g. cerf" Subject: Re: [idn] IDN eamples for testing In-reply-to: X-Sender: vcerf@pop.wcomnet.com To: Paul Hoffman / IMC , idn@ops.ietf.org Message-id: <5.2.0.9.2.20030324190256.02510598@pop.wcomnet.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; charset=us-ascii References: <5.2.0.9.2.20030324150152.027559b8@pop.wcomnet.com> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <5.2.0.9.2.20030324150152.027559b8@pop.wcomnet.com> X-Spam-Status: No, hits=-22.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk At 01:33 PM 3/24/2003 -0800, Paul Hoffman / IMC wrote: >At 3:04 PM -0300 3/24/03, vinton g. cerf wrote: >>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. > >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. >--Paul Hoffman, Director >--Internet Mail Consortium 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 owner-idn@ops.ietf.org Mon Mar 24 17:34:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06433 for ; Mon, 24 Mar 2003 17:34:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xaQg-0004sb-00 for idn-data@psg.com; Mon, 24 Mar 2003 14:28:30 -0800 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 18xaQ2-0004oC-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 14:27:50 -0800 Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OMRNg05379 for ; Mon, 24 Mar 2003 14:27:23 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.2.0.9.2.20030324190256.02510598@pop.wcomnet.com> References: <5.2.0.9.2.20030324150152.027559b8@pop.wcomnet.com> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <5.2.0.9.2.20030324150152.027559b8@pop.wcomnet.com> <5.2.0.9.2.20030324190256.02510598@pop.wcomnet.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 24 Mar 2003 14:27:21 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] IDN eamples for testing Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.2 required=5.0 tests=EMAIL_ATTRIBUTION,HABEAS_SWE,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk 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 --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Mar 24 17:56:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07108 for ; Mon, 24 Mar 2003 17:56:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xamz-0006kx-00 for idn-data@psg.com; Mon, 24 Mar 2003 14:51:33 -0800 Received: from [195.97.154.19] (helo=InterScan.psglaw.dk) by psg.com with smtp (Exim 3.36 #1) id 18xalx-0006cc-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 14:50:29 -0800 Received: from 172.16.10.4 by InterScan.psglaw.dk (InterScan E-Mail VirusWall NT); Mon, 24 Mar 2003 23:50:00 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [idn] IDN eamples for testing X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 24 Mar 2003 23:49:59 +0100 Message-ID: <0057BC9383E9AA4ABC1749790A6E201A0118A597@PSG-MAIL.psglaw.dk> Thread-Topic: [idn] IDN eamples for testing Thread-Index: AcLyVYBI/MuE0Bd7Qtesi+segg0WLAAATS8g From: "Peter Gustav Olson - pgo" To: "vinton g. cerf" , "Paul Hoffman / IMC" , X-Spam-Status: No, hits=-6.5 required=5.0 tests=EMAIL_ATTRIBUTION autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA07108 At least in the Scandinavian countries there are many of the old test bed registrations which are registered by cybersquatters who ought not be allowed to continue. In that the IDN will significantly increase the available name space much like the introduction of a new TLD, a "sunrise" period for trademark owners is needed. In other words, there should not be an automatic re-registration, now or later. Peter Gustav Olson -----Original Message----- From: vinton g. cerf [mailto:vinton.g.cerf@wcom.com] Sent: Monday, March 24, 2003 11:04 PM To: Paul Hoffman / IMC; idn@ops.ietf.org Subject: Re: [idn] IDN eamples for testing At 01:33 PM 3/24/2003 -0800, Paul Hoffman / IMC wrote: >At 3:04 PM -0300 3/24/03, vinton g. cerf wrote: >>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. > >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. >--Paul Hoffman, Director >--Internet Mail Consortium 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 owner-idn@ops.ietf.org Mon Mar 24 19:01:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10369 for ; Mon, 24 Mar 2003 19:01:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xblI-000C3E-00 for idn-data@psg.com; Mon, 24 Mar 2003 15:53:52 -0800 Received: from mailout04.sul.t-online.com ([194.25.134.18]) by psg.com with esmtp (Exim 3.36 #1) id 18xbkm-000BsO-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 15:53:20 -0800 Received: from fwd00.sul.t-online.de by mailout04.sul.t-online.com with smtp id 18xbkM-00031r-02; Tue, 25 Mar 2003 00:52:54 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.34.222]) by fmrl00.sul.t-online.com with esmtp id 18xbkF-19eL68C; Tue, 25 Mar 2003 00:52:47 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2ONqkbh003339; Tue, 25 Mar 2003 00:52:46 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id h2ONqiZi003336; Tue, 25 Mar 2003 00:52:44 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: "Edmon Chung" Cc: "Doug Ewell" , Subject: Re: [idn] IDN eamples for testing References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> <00d701c2f224$4788fe60$77424244@anhmca.adelphia.net> <042c01c2f22b$e99d9790$f108bdc8@neteka.inc> From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 25 Mar 2003 00:52:44 +0100 In-Reply-To: <042c01c2f22b$e99d9790$f108bdc8@neteka.inc> Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-30.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk "Edmon Chung" writes: > ok. So the right way to do it is a clean break with no transition is what > we are saying. 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 owner-idn@ops.ietf.org Mon Mar 24 19:01:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10383 for ; Mon, 24 Mar 2003 19:01:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xbir-000Bkv-00 for idn-data@psg.com; Mon, 24 Mar 2003 15:51:21 -0800 Received: from mailout04.sul.t-online.com ([194.25.134.18]) by psg.com with esmtp (Exim 3.36 #1) id 18xbiK-000BiP-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 15:50:49 -0800 Received: from fwd01.sul.t-online.de by mailout04.sul.t-online.com with smtp id 18xbht-0000y1-02; Tue, 25 Mar 2003 00:50:21 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.34.222]) by fmrl01.sul.t-online.com with esmtp id 18xbhi-2AkEr2C; Tue, 25 Mar 2003 00:50:10 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2ONo8bh003330; Tue, 25 Mar 2003 00:50:08 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id h2ONo6ow003327; Tue, 25 Mar 2003 00:50:06 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: "Edmon Chung" Cc: "Ric Johnson" , "IDN" , "Martin Duerst" Subject: Re: [idn] IDN eamples for testing References: <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 25 Mar 2003 00:50:06 +0100 In-Reply-To: <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-33.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk "Edmon Chung" writes: > 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? 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 owner-idn@ops.ietf.org Mon Mar 24 19:05:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10494 for ; Mon, 24 Mar 2003 19:05:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xbqZ-000CXn-00 for idn-data@psg.com; Mon, 24 Mar 2003 15:59:19 -0800 Received: from mailout01.sul.t-online.com ([194.25.134.80]) by psg.com with esmtp (Exim 3.36 #1) id 18xboc-000CKn-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 15:57:19 -0800 Received: from fwd08.sul.t-online.de by mailout01.sul.t-online.com with smtp id 18xboD-0003jR-05; Tue, 25 Mar 2003 00:56:53 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.34.222]) by fmrl08.sul.t-online.com with esmtp id 18xboA-1MQq36C; Tue, 25 Mar 2003 00:56:50 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2ONunbh003345; Tue, 25 Mar 2003 00:56:49 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id h2ONulJw003342; Tue, 25 Mar 2003 00:56:47 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: "Peter Gustav Olson - pgo" Cc: "vinton g. cerf" , "Paul Hoffman / IMC" , Subject: Re: [idn] IDN eamples for testing References: <0057BC9383E9AA4ABC1749790A6E201A0118A597@PSG-MAIL.psglaw.dk> From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 25 Mar 2003 00:56:47 +0100 In-Reply-To: <0057BC9383E9AA4ABC1749790A6E201A0118A597@PSG-MAIL.psglaw.dk> Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-33.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk "Peter Gustav Olson - pgo" writes: > At least in the Scandinavian countries there are many of the old > test bed registrations which are registered by cybersquatters who > ought not be allowed to continue. In that the IDN will significantly > increase the available name space much like the introduction of a > new TLD, a "sunrise" period for trademark owners is needed. In other > words, there should not be an automatic re-registration, now or > later. That, of course, is a policy decision that the registrars should make. For example, DENIC has rejected any labels which have "--" as third and fourth characters for a while, precisely to stop cybersqatters. Regards, Martin From owner-idn@ops.ietf.org Mon Mar 24 19:43:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11490 for ; Mon, 24 Mar 2003 19:43:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xcQ7-000FjL-00 for idn-data@psg.com; Mon, 24 Mar 2003 16:36:03 -0800 Received: from [202.27.17.100] (helo=sentosa.post1.com) by psg.com with smtp (Exim 3.36 #1) id 18xcPa-000FZn-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 16:35:30 -0800 Received: (qmail 82606 invoked from network); 25 Mar 2003 00:45:33 -0000 Received: from ida80.ida.gov.sg (HELO JSENGTOSHIBA) (210.24.194.80) by sentosa.post1.com with SMTP; 25 Mar 2003 00:45:33 -0000 Message-ID: <006a01c2f266$3b5a6100$07514b0a@JSENGTOSHIBA> From: "James Seng" To: "Edmon Chung" , "Doug Ewell" , References: <4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030308144925.03c6fad0@localhost><3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com><4.2.0.58.J.20030308144925.03c6fad0@localhost><4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030321204149.0321f9c0@localhost> <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> <00d701c2f224$4788fe60$77424244@anhmca.adelphia.net> <042c01c2f22b$e99d9790$f108bdc8@neteka.inc> Subject: Re: [idn] IDN eamples for testing Date: Tue, 25 Mar 2003 08:34:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-12.9 required=5.0 tests=ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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: ----- Original Message ----- From: "Edmon Chung" To: "Doug Ewell" ; Sent: Tuesday, March 25, 2003 1:36 AM Subject: Re: [idn] IDN eamples for testing > ok. So the right way to do it is a clean break with no transition is what > we are saying. > That is good. > Edmon > > > ----- Original Message ----- > From: "Doug Ewell" > To: > Cc: "Edmon Chung" > Sent: Monday, March 24, 2003 11:41 AM > Subject: Re: [idn] IDN eamples for testing > > > > Edmon Chung wrote: > > > > > 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? > > > > 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 owner-idn@ops.ietf.org Mon Mar 24 19:45:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11564 for ; Mon, 24 Mar 2003 19:45:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xcSw-000G3I-00 for idn-data@psg.com; Mon, 24 Mar 2003 16:38:58 -0800 Received: from [202.27.17.100] (helo=sentosa.post1.com) by psg.com with smtp (Exim 3.36 #1) id 18xcSO-000FwF-00 for idn@ops.ietf.org; Mon, 24 Mar 2003 16:38:25 -0800 Received: (qmail 82658 invoked from network); 25 Mar 2003 00:48:55 -0000 Received: from ida80.ida.gov.sg (HELO JSENGTOSHIBA) (210.24.194.80) by sentosa.post1.com with SMTP; 25 Mar 2003 00:48:55 -0000 Message-ID: <009501c2f266$b3d4f820$07514b0a@JSENGTOSHIBA> From: "James Seng" To: "Edmon Chung" , "Doug Ewell" , References: <4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030308144925.03c6fad0@localhost><3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com><4.2.0.58.J.20030308144925.03c6fad0@localhost><4.2.0.58.J.20030308174815.03cc8af8@localhost><4.2.0.58.J.20030321204149.0321f9c0@localhost> <038d01c2f20b$ac6ad600$f108bdc8@neteka.inc> <00d701c2f224$4788fe60$77424244@anhmca.adelphia.net> <042c01c2f22b$e99d9790$f108bdc8@neteka.inc> Subject: Re: [idn] IDN eamples for testing Date: Tue, 25 Mar 2003 08:37:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-12.9 required=5.0 tests=ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 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 ----- Original Message ----- From: "Edmon Chung" To: "Doug Ewell" ; Sent: Tuesday, March 25, 2003 1:36 AM Subject: Re: [idn] IDN eamples for testing > ok. So the right way to do it is a clean break with no transition is what > we are saying. > That is good. > Edmon > > > ----- Original Message ----- > From: "Doug Ewell" > To: > Cc: "Edmon Chung" > Sent: Monday, March 24, 2003 11:41 AM > Subject: Re: [idn] IDN eamples for testing > > > > Edmon Chung wrote: > > > > > 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? > > > > 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 owner-idn@ops.ietf.org Mon Mar 24 21:01:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13615 for ; Mon, 24 Mar 2003 21:01:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xdd6-000MEf-00 for idn-data@psg.com; Mon, 24 Mar 2003 17:53:32 -0800 From: Dan Oscarsson Reply-To: Dan Oscarsson Subject: Re: [idn] IDN eamples for testing To: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: rQOcTcREOjujRjDlYCeb1Q== Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 24 Mar 2003 17:53:32 -0800 Paul Hoffman wrote: >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. > That is correct, but sending ISO 8859-1 is. The DNS RFCs allows any octet values in a domain name. Nor is it necessary to implement IDNA in applications. You can do it in the DNS server and allow the clients be unmodified. Dan From owner-idn@ops.ietf.org Tue Mar 25 07:21:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07327 for ; Tue, 25 Mar 2003 07:21:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xnAA-0005Us-00 for idn-data@psg.com; Tue, 25 Mar 2003 04:04:18 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.36 #1) id 18xn9e-0005Sc-00 for idn@ops.ietf.org; Tue, 25 Mar 2003 04:03:46 -0800 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HCB002AC05HET@firewall.wcom.com> for idn@ops.ietf.org; Tue, 25 Mar 2003 12:03:18 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HCB00C0105H11@dgismtp01.wcomnet.com>; Tue, 25 Mar 2003 12:03:17 +0000 (GMT) Received: from vint.wcom.com ([166.60.14.59]) by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HCB00B1Q05DFW@dgismtp01.wcomnet.com>; Tue, 25 Mar 2003 12:03:17 +0000 (GMT) Date: Tue, 25 Mar 2003 09:03:07 -0300 From: "vinton g. cerf" Subject: Re: [idn] IDN eamples for testing In-reply-to: X-Sender: vcerf@pop.wcomnet.com To: Paul Hoffman / IMC , idn@ops.ietf.org Message-id: <5.2.0.9.2.20030325085655.025a1fc0@pop.wcomnet.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; charset=us-ascii References: <5.2.0.9.2.20030324190256.02510598@pop.wcomnet.com> <5.2.0.9.2.20030324150152.027559b8@pop.wcomnet.com> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <3E5FA1B8.1070009@ehsco.com> <3E5FA1B8.1070009@ehsco.com> <4.2.0.58.J.20030308144925.03c6fad0@localhost> <4.2.0.58.J.20030308174815.03cc8af8@localhost> <4.2.0.58.J.20030321204149.0321f9c0@localhost> <5.2.0.9.2.20030324150152.027559b8@pop.wcomnet.com> <5.2.0.9.2.20030324190256.02510598@pop.wcomnet.com> X-Spam-Status: No, hits=-22.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk 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: >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 >--Internet Mail Consortium 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 owner-idn@ops.ietf.org Tue Mar 25 07:35:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07597 for ; Tue, 25 Mar 2003 07:35:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xnYY-0006ZM-00 for idn-data@psg.com; Tue, 25 Mar 2003 04:29:30 -0800 Received: from maya40.nic.fr ([192.134.4.151]) by psg.com with esmtp (Exim 3.36 #1) id 18xnY2-0006Xh-00 for idn@ops.ietf.org; Tue, 25 Mar 2003 04:28:58 -0800 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h2PCSTPd535757; Tue, 25 Mar 2003 13:28:29 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 7A852110F0; Tue, 25 Mar 2003 13:28:32 +0100 (CET) Date: Tue, 25 Mar 2003 13:28:32 +0100 From: Stephane Bortzmeyer To: James Seng Cc: IDN Subject: Re: [idn] IDN eamples for testing Message-ID: <20030325122832.GA19172@nic.fr> References: <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> <016301c2f14c$a2547e10$f108bdc8@neteka.inc> <00ee01c2f14d$b6b423f0$1300a8c0@JSENGTOSHIBA> <5.1.0.14.2.20030323154440.01da7d40@lon-imap-1.centralnic.net> <020d01c2f156$107d16f0$1300a8c0@JSENGTOSHIBA> <01d101c2f165$9dda3730$f108bdc8@neteka.inc> <053401c2f196$321105c0$1300a8c0@JSENGTOSHIBA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <053401c2f196$321105c0$1300a8c0@JSENGTOSHIBA> User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ X-Spam-Status: No, hits=-16.3 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk On Mon, Mar 24, 2003 at 07:44:49AM +0800, James Seng wrote a message of 28 lines which said: > http://www.neteka.com/en/pages/products/nedns/index.html > > 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 . 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 owner-idn@ops.ietf.org Tue Mar 25 08:12:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07326 for ; Tue, 25 Mar 2003 07:21:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xnDY-0005ms-00 for idn-data@psg.com; Tue, 25 Mar 2003 04:07:48 -0800 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by psg.com with esmtp (Exim 3.36 #1) id 18xnCt-0005iU-00 for idn@ops.ietf.org; Tue, 25 Mar 2003 04:07:07 -0800 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HCB004030B61B@firewall.wcom.com> for idn@ops.ietf.org; Tue, 25 Mar 2003 12:06:42 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HCB006010B6MA@dgismtp02.wcomnet.com>; Tue, 25 Mar 2003 12:06:42 +0000 (GMT) Received: from vint.wcom.com ([166.60.14.59]) by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HCB0053O0B3Q6@dgismtp02.wcomnet.com>; Tue, 25 Mar 2003 12:06:41 +0000 (GMT) Date: Tue, 25 Mar 2003 09:06:33 -0300 From: "vinton g. cerf" Subject: RE: [idn] IDN eamples for testing In-reply-to: <0057BC9383E9AA4ABC1749790A6E201A0118A597@PSG-MAIL.psglaw.d k> X-Sender: vcerf@pop.wcomnet.com To: Peter Gustav Olson - pgo , Paul Hoffman / IMC , idn@ops.ietf.org Message-id: <5.2.0.9.2.20030325090542.0273eba8@pop.wcomnet.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-9.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Peter, thanks for pointing out the cybersquatter problem - I certainly agree that we don't want to adopt policies that will encourage or support cybersquatting! vint At 11:49 PM 3/24/2003 +0100, Peter Gustav Olson - pgo wrote: >At least in the Scandinavian countries there are many of the old test bed registrations which are registered by cybersquatters who ought not be allowed to continue. In that the IDN will significantly increase the available name space much like the introduction of a new TLD, a "sunrise" period for trademark owners is needed. In other words, there should not be an automatic re-registration, now or later. > >Peter Gustav Olson 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 owner-idn@ops.ietf.org Tue Mar 25 08:22:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09185 for ; Tue, 25 Mar 2003 08:22:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xoKK-0008AY-00 for idn-data@psg.com; Tue, 25 Mar 2003 05:18:52 -0800 Received: from [200.189.15.25] (helo=ns1.icannrio.added.com.br) by psg.com with esmtp (Exim 3.36 #1) id 18xoJH-00085d-00 for idn@ops.ietf.org; Tue, 25 Mar 2003 05:17:47 -0800 Received: from EDMON15 (12.238.dhcp.icann.org.br [200.189.12.238]) by ns1.icannrio.added.com.br (Postfix) with SMTP id 1F13E38BC8; Tue, 25 Mar 2003 11:16:29 -0300 (BRT) Message-ID: <061001c2f2d0$c9d230b0$f108bdc8@neteka.inc> From: "Edmon Chung" To: "Stephane Bortzmeyer" Cc: "IDN" References: <00c201c2f13c$d6a7fb20$f108bdc8@neteka.inc> <013501c2f142$8f3388d0$1300a8c0@JSENGTOSHIBA> <00e301c2f146$862aecc0$f108bdc8@neteka.inc> <000f01c2f149$2201b8c0$1300a8c0@JSENGTOSHIBA> <016301c2f14c$a2547e10$f108bdc8@neteka.inc> <00ee01c2f14d$b6b423f0$1300a8c0@JSENGTOSHIBA> <5.1.0.14.2.20030323154440.01da7d40@lon-imap-1.centralnic.net> <020d01c2f156$107d16f0$1300a8c0@JSENGTOSHIBA> <01d101c2f165$9dda3730$f108bdc8@neteka.inc> <053401c2f196$321105c0$1300a8c0@JSENGTOSHIBA> <20030325122832.GA19172@nic.fr> Subject: Re: [idn] IDN eamples for testing Date: Tue, 25 Mar 2003 07:50:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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" > > http://www.neteka.com/en/pages/products/nedns/index.html > > > > 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 > . > > 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 owner-idn@ops.ietf.org Tue Mar 25 08:33:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09524 for ; Tue, 25 Mar 2003 08:33:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xoWM-0008h7-00 for idn-data@psg.com; Tue, 25 Mar 2003 05:31:18 -0800 Received: from [195.97.154.19] (helo=InterScan.psglaw.dk) by psg.com with smtp (Exim 3.36 #1) id 18xoVp-0008do-00 for idn@ops.ietf.org; Tue, 25 Mar 2003 05:30:45 -0800 Received: from 172.16.10.4 by InterScan.psglaw.dk (InterScan E-Mail VirusWall NT); Tue, 25 Mar 2003 14:30:13 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [idn] IDN eamples for testing X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 25 Mar 2003 14:30:13 +0100 Message-ID: <0057BC9383E9AA4ABC1749790A6E201A020398DA@PSG-MAIL.psglaw.dk> Thread-Topic: [idn] IDN eamples for testing Thread-Index: AcLyzFowsYK9a2snTyKaNLRsgsgKVgABi3yQ From: "Peter Gustav Olson - pgo" To: "vinton g. cerf" , "Paul Hoffman / IMC" , X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA09524 > -----Original Message----- > From: vinton g. cerf [mailto:vinton.g.cerf@wcom.com] > Sent: Tuesday, March 25, 2003 1:03 PM > To: Paul Hoffman / IMC; idn@ops.ietf.org > Subject: Re: [idn] IDN eamples for testing > > > Paul, > > There was an implicit question in my note: is anyone using > these "test" registrations for operational purposes? Yes, see, e.g. www.l.com and www.kreklar.com, which work due to Internet Explorer supporting Verisign's plug-in (you do not have to download the plug-in). There are numerous other Scandinavian websites using the letters , , , and . Yours Sincerely, Peter Gustav Olson PLESNER SVANE GRNBORG Law firm 34, Esplanaden DK-1263 Copenhagen K. Tel: +45 33 12 11 33 Fax: +45 33 12 00 14 E-mail: pgo@psglaw.dk Website: www.psglaw.dk This e-mail and any attachment are confidential and may also be privileged. If you are not the intended recipient, please notify us immediately and then delete this e-mail and any attachment without retaining copies or disclosing the contents thereof to any other person. Thank you. From owner-idn@ops.ietf.org Tue Mar 25 08:41:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10512 for ; Tue, 25 Mar 2003 08:41:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xodC-000912-00 for idn-data@psg.com; Tue, 25 Mar 2003 05:38:22 -0800 Received: from [195.97.154.19] (helo=InterScan.psglaw.dk) by psg.com with smtp (Exim 3.36 #1) id 18xocZ-0008yQ-00 for idn@ops.ietf.org; Tue, 25 Mar 2003 05:37:43 -0800 Received: from 172.16.10.4 by InterScan.psglaw.dk (InterScan E-Mail VirusWall NT); Tue, 25 Mar 2003 14:37:19 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [idn] IDN eamples for testing X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 25 Mar 2003 14:37:19 +0100 Message-ID: <0057BC9383E9AA4ABC1749790A6E201A0118A59E@PSG-MAIL.psglaw.dk> Thread-Topic: [idn] IDN eamples for testing Thread-Index: AcLyxwCC3UMgn0c4T+G51FsW/IcKNAAC7WMQ From: "Peter Gustav Olson - pgo" To: "vinton g. cerf" , "Paul Hoffman / IMC" , X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA10512 > -----Original Message----- > From: vinton g. cerf [mailto:vinton.g.cerf@wcom.com] > Sent: Tuesday, March 25, 2003 1:07 PM > To: Peter Gustav Olson - pgo; Paul Hoffman / IMC; idn@ops.ietf.org > Subject: RE: [idn] IDN eamples for testing > > > Peter, > > thanks for pointing out the cybersquatter problem - I > certainly agree that we don't want to adopt policies that > will encourage or support cybersquatting! For companies like Ben & Jerry's, Bang & Olufsen, Nestl, L'Oreal, Kooka, etc. the IDN will be much more significant than the introduction of .biz and .info. Let's make it significant in a positive sense, rather than a significant new anti-cybersquatting expenditure. Yours Sincerely, Peter Gustav Olson PLESNER SVANE GRNBORG Law firm 34, Esplanaden DK-1263 Copenhagen K. Tel: +45 33 12 11 33 Fax: +45 33 12 00 14 E-mail: pgo@psglaw.dk Website: www.psglaw.dk This e-mail and any attachment are confidential and may also be privileged. If you are not the intended recipient, please notify us immediately and then delete this e-mail and any attachment without retaining copies or disclosing the contents thereof to any other person. Thank you. From owner-idn@ops.ietf.org Tue Mar 25 15:02:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28853 for ; Tue, 25 Mar 2003 15:02:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xuTy-0000dd-00 for idn-data@psg.com; Tue, 25 Mar 2003 11:53:14 -0800 Received: from med31.ndl.net.nu ([216.133.64.31] helo=Thinkpad) by psg.com with esmtp (Exim 3.36 #1) id 18xuTR-0000Xx-00 for idn@ops.ietf.org; Tue, 25 Mar 2003 11:52:41 -0800 Received: from Thinkpad.mail.nic.nu ([127.0.0.1]) by Thinkpad with Microsoft SMTPSVC(6.0.2600.1106); Tue, 25 Mar 2003 14:52:16 -0500 Message-Id: <5.1.1.6.2.20030325145023.06016a70@mail.nic.nu> X-Sender: billnospam@nic.nu@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 25 Mar 2003 14:52:15 -0500 To: "Peter Gustav Olson - pgo" , "vinton g. cerf" , "Paul Hoffman / IMC" , From: "J. William Semich" Subject: RE: [idn] IDN eamples for testing In-Reply-To: <0057BC9383E9AA4ABC1749790A6E201A020398DA@PSG-MAIL.psglaw.d k> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 25 Mar 2003 19:52:17.0281 (UTC) FILETIME=[09FF4F10:01C2F308] X-Spam-Status: No, hits=-19.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA28853 .NU also works with the VeriSign Explorer Browser plugin via IDNA. If you are using the VeriSign plugin, try http://www.kreklar.nu Bill Semich At 08:30 AM 3/25/2003, Peter Gustav Olson - pgo wrote: > > -----Original Message----- > > From: vinton g. cerf [mailto:vinton.g.cerf@wcom.com] > > Sent: Tuesday, March 25, 2003 1:03 PM > > To: Paul Hoffman / IMC; idn@ops.ietf.org > > Subject: Re: [idn] IDN eamples for testing > > > > > > Paul, > > > > There was an implicit question in my note: is anyone using > > these "test" registrations for operational purposes? > > >Yes, see, e.g. www.l.com and www.kreklar.com, which work due to Internet >Explorer supporting Verisign's plug-in (you do not have to download the >plug-in). There are numerous other Scandinavian websites using the letters >, , , and . > >Yours Sincerely, > >Peter Gustav Olson > >PLESNER SVANE GRNBORG >Law firm > >34, Esplanaden >DK-1263 Copenhagen K. > >Tel: +45 33 12 11 33 >Fax: +45 33 12 00 14 >E-mail: pgo@psglaw.dk >Website: www.psglaw.dk > > >This e-mail and any attachment are confidential and may also be >privileged. If you are not the intended recipient, please notify us >immediately and then delete this e-mail and any attachment without >retaining copies or disclosing the contents thereof to any other >person. Thank you. > From owner-idn@ops.ietf.org Fri Mar 28 11:10:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05301 for ; Fri, 28 Mar 2003 11:10:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ywDy-000Ahv-00 for idn-data@psg.com; Fri, 28 Mar 2003 07:56:58 -0800 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 18ywDl-000AeO-00 for idn@ops.ietf.org; Fri, 28 Mar 2003 07:56:45 -0800 Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SFuYg04260 for ; Fri, 28 Mar 2003 07:56:37 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 28 Mar 2003 07:55:59 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: [idn] Fwd: I-D ACTION:draft-josefsson-idn-test-vectors-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-15.3 required=5.0 tests=BAYES_10,CLICK_BELOW,HABEAS_SWE,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk There is a new draft that is of very direct interest to this mailing list. It would be great if people who have implemented IDNA could check their results against this draft. And thank you to Simon for doing the work on this! These kinds of documents are very useful in the IETF and can help IDNA progress on standards track. --Paul Hoffman >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-josefsson-idn-test-vectors-00.txt >Date: Fri, 28 Mar 2003 07:22:21 -0500 >Sender: owner-ietf-announce@ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Nameprep and IDNA Test Vectors > Author(s) : S. Josefsson > Filename : draft-josefsson-idn-test-vectors-00.txt > Pages : 41 > Date : 2003-3-27 > >This document contains test vectors for Nameprep and IDNA > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-josefsson-idn-test-vectors-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-josefsson-idn-test-vectors-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-josefsson-idn-test-vectors-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > >[The following attachment must be fetched by mail. Command-click the >URL below and send the resulting message to get the attachment.] > >[The following attachment must be fetched by ftp. Command-click the >URL below to ask your ftp client to fetch it.] > From owner-idn@ops.ietf.org Fri Mar 28 13:25:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10919 for ; Fri, 28 Mar 2003 13:25:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yyQB-0008i9-00 for idn-data@psg.com; Fri, 28 Mar 2003 10:17:43 -0800 Received: from mailout04.sul.t-online.com ([194.25.134.18]) by psg.com with esmtp (Exim 3.36 #1) id 18yyQ7-0008hk-00 for idn@ops.ietf.org; Fri, 28 Mar 2003 10:17:39 -0800 Received: from fwd02.sul.t-online.de by mailout04.sul.t-online.com with smtp id 18yyQ2-0007Rn-0D; Fri, 28 Mar 2003 19:17:34 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.37.113]) by fmrl02.sul.t-online.com with esmtp id 18yyPv-0bTbGaC; Fri, 28 Mar 2003 19:17:27 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2SIHWl9002248; Fri, 28 Mar 2003 19:17:32 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id h2SIHURI002245; Fri, 28 Mar 2003 19:17:30 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: Paul Hoffman / IMC Cc: idn@ops.ietf.org Subject: Re: [idn] Fwd: I-D ACTION:draft-josefsson-idn-test-vectors-00.txt References: From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 28 Mar 2003 19:17:30 +0100 In-Reply-To: Message-ID: Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-38.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Paul Hoffman / IMC writes: > There is a new draft that is of very direct interest to this mailing > list. It would be great if people who have implemented IDNA could > check their results against this draft. Please correct me if I'm wrong: I believe the UTF-8 strings are wrong in a number of tests: 4.3: U+00DF should be \xc3\x9f, not \xc3\xdf 4.9: U+01F0 should be \xc7\xb0, not \xc7\xf0 4.44: U+00DF should be \xc3\x9f, not \xc3\xdf 4.45: Likewise. Regards, Martin From owner-idn@ops.ietf.org Fri Mar 28 15:11:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16433 for ; Fri, 28 Mar 2003 15:10:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z07U-0004mP-00 for idn-data@psg.com; Fri, 28 Mar 2003 12:06:32 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 18z07K-0004eF-00 for idn@ops.ietf.org; Fri, 28 Mar 2003 12:06:22 -0800 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.8/8.12.8) with ESMTP id h2SK67rk005759 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 28 Mar 2003 21:06:09 +0100 To: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Cc: Paul Hoffman / IMC , idn@ops.ietf.org Subject: [idn] Re: Fwd: I-D ACTION:draft-josefsson-idn-test-vectors-00.txt X-Payment: hashcash 1.2 0:030328:martin@v.loewis.de:72d1e9a8fb41bb28 X-Hashcash: 0:030328:martin@v.loewis.de:72d1e9a8fb41bb28 X-Payment: hashcash 1.2 0:030328:phoffman@imc.org:dc1faea231373b95 X-Hashcash: 0:030328:phoffman@imc.org:dc1faea231373b95 X-Payment: hashcash 1.2 0:030328:idn@ops.ietf.org:5e2b6e618f2f8d5a X-Hashcash: 0:030328:idn@ops.ietf.org:5e2b6e618f2f8d5a From: Simon Josefsson Date: Fri, 28 Mar 2003 21:06:07 +0100 In-Reply-To: (martin@v.loewis.de's message of "28 Mar 2003 19:17:30 +0100") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.3.50 (gnu/linux) References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit martin@v.loewis.de (Martin v. Lwis) writes: > Paul Hoffman / IMC writes: > >> There is a new draft that is of very direct interest to this mailing >> list. It would be great if people who have implemented IDNA could >> check their results against this draft. > > Please correct me if I'm wrong: I believe the UTF-8 strings are wrong > in a number of tests: > > 4.3: U+00DF should be \xc3\x9f, not \xc3\xdf > 4.9: U+01F0 should be \xc7\xb0, not \xc7\xf0 > 4.44: U+00DF should be \xc3\x9f, not \xc3\xdf > 4.45: Likewise. You are right. I thought I could convert simple strings by hand, but obviously I didn't select the proper UTF-8 encoding (in some cases). I believe you catched all errors. Since those examples test whether the application uses a validating UTF-8 decoder, I will keep those examples modified to result in an UTF-8 decoding error. Non-validating UTF-8 decoders should produce the correct Unicode code point for those UTF-8 encodings though. From owner-idn@ops.ietf.org Fri Mar 28 15:29:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17552 for ; Fri, 28 Mar 2003 15:29:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z0Oe-0008gE-00 for idn-data@psg.com; Fri, 28 Mar 2003 12:24:16 -0800 Received: from mailout09.sul.t-online.com ([194.25.134.84]) by psg.com with esmtp (Exim 3.36 #1) id 18z0Oa-0008g2-00 for idn@ops.ietf.org; Fri, 28 Mar 2003 12:24:13 -0800 Received: from fwd02.sul.t-online.de by mailout09.sul.t-online.com with smtp id 18z0OU-0001kc-09; Fri, 28 Mar 2003 21:24:06 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.37.113]) by fmrl02.sul.t-online.com with esmtp id 18z0OO-1kfcKOC; Fri, 28 Mar 2003 21:24:00 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2SKO5l9023292; Fri, 28 Mar 2003 21:24:05 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id h2SKO3tJ023289; Fri, 28 Mar 2003 21:24:03 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: Simon Josefsson Cc: Paul Hoffman / IMC , idn@ops.ietf.org Subject: [idn] Re: Fwd: I-D ACTION:draft-josefsson-idn-test-vectors-00.txt References: From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 28 Mar 2003 21:24:03 +0100 In-Reply-To: Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-38.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Simon Josefsson writes: > You are right. I thought I could convert simple strings by hand, but > obviously I didn't select the proper UTF-8 encoding (in some cases). > I believe you catched all errors. Since those examples test whether > the application uses a validating UTF-8 decoder, I will keep those > examples modified to result in an UTF-8 decoding error. > Non-validating UTF-8 decoders should produce the correct Unicode code > point for those UTF-8 encodings though. I suggest to correct the examples; those tests really test something else. UTF-8 is not part of IDNA, and any self-respecting UTF-8 library should have separate test cases, eg. the ones from RFC 2279. (and yes, I probably found all such errors, as I literally copied the test cases into my Python IDNA test suite). Regards, Martin From owner-idn@ops.ietf.org Fri Mar 28 16:00:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18503 for ; Fri, 28 Mar 2003 16:00:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z0t7-000FdU-00 for idn-data@psg.com; Fri, 28 Mar 2003 12:55:45 -0800 Received: from w1309.hostcentric.net ([66.40.78.254]) by psg.com with smtp (Exim 3.36 #1) id 18z0t5-000FdH-00 for idn@ops.ietf.org; Fri, 28 Mar 2003 12:55:43 -0800 Received: (qmail 10689 invoked by alias); 28 Mar 2003 20:55:40 -0000 Received: from unknown (HELO DAVIS1) (12.234.231.178) by 0 with SMTP; 28 Mar 2003 20:55:40 -0000 Message-ID: <010101c2f56c$58e28af0$7900a8c0@DAVIS1> From: "Mark Davis" To: "=?utf-8?Q?Martin_v._L=C3=B6wis?=" , "Simon Josefsson" Cc: "Paul Hoffman / IMC" , References: Subject: Re: [idn] Re: Fwd: I-D ACTION:draft-josefsson-idn-test-vectors-00.txt Date: Fri, 28 Mar 2003 21:55:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_10,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I want to point out that nobody should be using non-validating UTF-8 converters; not only are they not conformant to the Unicode standard, they also represent a security risk. Mark (ᛗᚪᚱᚳ) ________ mark.davis@jtcsv.com IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193 (408) 256-3148 fax: (408) 256-0799 ----- Original Message ----- From: "Simon Josefsson" To: "Martin v. Löwis" Cc: "Paul Hoffman / IMC" ; Sent: Friday, March 28, 2003 21:06 Subject: [idn] Re: Fwd: I-D ACTION:draft-josefsson-idn-test-vectors-00.txt > martin@v.loewis.de (Martin v. Löwis) writes: > > > Paul Hoffman / IMC writes: > > > >> There is a new draft that is of very direct interest to this mailing > >> list. It would be great if people who have implemented IDNA could > >> check their results against this draft. > > > > Please correct me if I'm wrong: I believe the UTF-8 strings are wrong > > in a number of tests: > > > > 4.3: U+00DF should be \xc3\x9f, not \xc3\xdf > > 4.9: U+01F0 should be \xc7\xb0, not \xc7\xf0 > > 4.44: U+00DF should be \xc3\x9f, not \xc3\xdf > > 4.45: Likewise. > > You are right. I thought I could convert simple strings by hand, but > obviously I didn't select the proper UTF-8 encoding (in some cases). > I believe you catched all errors. Since those examples test whether > the application uses a validating UTF-8 decoder, I will keep those > examples modified to result in an UTF-8 decoding error. > Non-validating UTF-8 decoders should produce the correct Unicode code > point for those UTF-8 encodings though. > > > From owner-idn@ops.ietf.org Fri Mar 28 16:01:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18590 for ; Fri, 28 Mar 2003 16:01:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z0pY-000EiT-00 for idn-data@psg.com; Fri, 28 Mar 2003 12:52:04 -0800 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 18z0pT-000Eey-00 for idn@ops.ietf.org; Fri, 28 Mar 2003 12:51:59 -0800 Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SKprg20026 for ; Fri, 28 Mar 2003 12:51:54 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 28 Mar 2003 12:51:52 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: [idn] Re: Fwd: I-D ACTION:draft-josefsson-idn-test-vectors-00.txt Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,HABEAS_SWE,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At 9:24 PM +0100 3/28/03, Martin v. Lwis wrote: >I suggest to correct the examples; those tests really test something >else. UTF-8 is not part of IDNA, and any self-respecting UTF-8 library >should have separate test cases, eg. the ones from RFC 2279. I agree with Martin here: tests of UTF-8 don't belong in IDNA. Remember that IDNA is encoding-independent. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Mar 28 16:33:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19725 for ; Fri, 28 Mar 2003 16:33:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z1Ok-000Lu6-00 for idn-data@psg.com; Fri, 28 Mar 2003 13:28:26 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 18z1Oh-000Ltr-00 for idn@ops.ietf.org; Fri, 28 Mar 2003 13:28:23 -0800 Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 18z1Of-000Kq7-00; Fri, 28 Mar 2003 16:28:21 -0500 Date: Fri, 28 Mar 2003 16:28:21 -0500 From: John C Klensin To: Mark Davis , Simon Josefsson cc: "idn@ops.ietf.org" Subject: Re: [idn] Re: Fwd: I-D ACTION:draft-josefsson-idn-test-vectors-00.txt Message-ID: <95525798.1048868901@p3.JCK.COM> In-Reply-To: <010101c2f56c$58e28af0$7900a8c0@DAVIS1> References: <010101c2f56c$58e28af0$7900a8c0@DAVIS1> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, 28 March, 2003 21:55 +0100 Mark Davis wrote: > I want to point out that nobody should be using non-validating > UTF-8 converters; not only are they not conformant to the > Unicode standard, they also represent a security risk. Mark, I clearly agree with this, and with Paul's point that UTF-8 is not part of IDNA. But that, it seems to me, is an argument for Simon's tests containing those tests, rather than against it: if non-validating/ non-conforming UTF-8 converters are out there, then testbeds that catch them would seem to be in everyone's interest. john From owner-idn@ops.ietf.org Fri Mar 28 18:40:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25652 for ; Fri, 28 Mar 2003 18:40:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z3KG-000MEp-00 for idn-data@psg.com; Fri, 28 Mar 2003 15:31:56 -0800 From: "AM" To: Subject: [idn] Re: IDN Registration Integrity Date: Wed, 26 Mar 2003 19:44:48 -0700 Message-ID: <000001c2f40a$d571cad0$8bb83f44@cc634135b> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-idn@ops.ietf.org Precedence: bulk AM amitbusy@hotmail.com Re: IDN Registration Integrity As an individual concerned with the future of IDNs, I would like to recommend that ICANN seriously consider incorporating a clause in their registry agreements that ensures registrants that their IDN = registrations will be valid through all changes in registry operators, through all standards' progressions, through to the day when multi-lingual domains = will be incorporated into zone files as are ASCII domains. Though confident in ICANN, the IETF, and Registry Operators, individuals = are concerned that their IDNs are the work of proprietary standards put = forth by the Registry Operators. Plug-in applications used as a link between = ASCII names and their multi-lingual equivalents further this suspicion. = Though the suspicion is false, I learned the truth only after speaking to a = number of individuals at my registrar, Verisign-GRS, ICANN and the IETF working group. Still, they could not be completely certain that "your name = would always be your name." =20 The question at hand is are my current IDN registrations so-called "ICANN-certified" registrations, as are the ASCII domains of today? In ASCII registrations, I am confident that through all registry operator changes, through any accidental deletions or transfers of my domain, I = can be assured that my domain name will be valid and governed by ICANN = policies. I would like to be assured that not just my ASCII "bq--" or "xn--" = string will be "ICANN-certified" but that its multi-lingual equivalent will = always be a constant registration, valid and governed by ICANN policies, = through to the day when multi-lingual domains will be incorporated into zone files = as are ASCII domains. Again, after learning about the issue, I am most confident that "my registration will most likely always be my registration." This is = probably not a major issue. Still, it may be worth clarification from ICANN. = Any discussions or statements by the applicable IDN committees in future meetings would be most appreciated. Thank you for your consideration. Best wishes, AM ----- Original Message ----- From: To: Sent: Thursday, March 27, 2003 10:45 AM Subject: BOUNCE idn@ops.ietf.org: Non-member submission from ["AM" ] > From amitbusy@hotmail.com Wed Mar 26 18:45:02 2003 > Received: from dav42.sea1.hotmail.com ([207.68.162.100] helo=hotmail.com) > by psg.com with esmtp (Exim 3.36 #1) > id 18yNO1-000F3k-00 > for idn@ops.ietf.org; Wed, 26 Mar 2003 18:45:01 -0800 > Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; > Wed, 26 Mar 2003 18:45:01 -0800 > Received: from 68.63.184.139 by dav42.sea1.hotmail.com with DAV; > Thu, 27 Mar 2003 02:44:56 +0000 > X-Originating-IP: [68.63.184.139] > X-Originating-Email: [amitbusy@hotmail.com] > From: "AM" > To: > Subject: Re: IDN Registration Integrity > Date: Wed, 26 Mar 2003 19:44:48 -0700 > Message-ID: <000001c2f40a$d571cad0$8bb83f44@cc634135b> > MIME-Version: 1.0 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook, Build 10.0.4510 > Importance: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 > X-OriginalArrivalTime: 27 Mar 2003 02:45:01.0077 (UTC) FILETIME=[DCC87450:01C2F40A] > X-Spam-Status: No, hits=-5.8 required=5.0 > tests=BAYES_10 > version=2.50 > X-Spam-Level: > X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) > > AM > amitbusy@hotmail.com > Re: IDN Registration Integrity > > > As an individual concerned with the future of IDNs, I would like to > recommend that ICANN seriously consider incorporating a clause in their > registry agreements that ensures registrants that their IDN = > registrations > will be valid through all changes in registry operators, through all > standards' progressions, through to the day when multi-lingual domains = > will > be incorporated into zone files as are ASCII domains. > > Though confident in ICANN, the IETF, and Registry Operators, individuals = > are > concerned that their IDNs are the work of proprietary standards put = > forth by > the Registry Operators. Plug-in applications used as a link between = > ASCII > names and their multi-lingual equivalents further this suspicion. = > Though > the suspicion is false, I learned the truth only after speaking to a = > number > of individuals at my registrar, Verisign-GRS, ICANN and the IETF working > group. Still, they could not be completely certain that "your name = > would > always be your name." =20 > > The question at hand is are my current IDN registrations so-called > "ICANN-certified" registrations, as are the ASCII domains of today? In > ASCII registrations, I am confident that through all registry operator > changes, through any accidental deletions or transfers of my domain, I = > can > be assured that my domain name will be valid and governed by ICANN = > policies. > I would like to be assured that not just my ASCII "bq--" or "xn--" = > string > will be "ICANN-certified" but that its multi-lingual equivalent will = > always > be a constant registration, valid and governed by ICANN policies, = > through to > the day when multi-lingual domains will be incorporated into zone files = > as > are ASCII domains. > > Again, after learning about the issue, I am most confident that "my > registration will most likely always be my registration." This is = > probably > not a major issue. Still, it may be worth clarification from ICANN. = > Any > discussions or statements by the applicable IDN committees in future > meetings would be most appreciated. > > Thank you for your consideration. > > > > Best wishes, > AM > > From owner-idn@ops.ietf.org Fri Mar 28 20:06:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27327 for ; Fri, 28 Mar 2003 20:06:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z4bV-000FOh-00 for idn-data@psg.com; Fri, 28 Mar 2003 16:53:49 -0800 From: "Adam M. Costello" To: IETF idn working group , AM Subject: Re: [idn] Re: IDN Registration Integrity Message-ID: <20030329003839.GI22667@nicemice.net> References: <000001c2f40a$d571cad0$8bb83f44@cc634135b> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c2f40a$d571cad0$8bb83f44@cc634135b> Sender: owner-idn@ops.ietf.org Precedence: bulk Date: Fri, 28 Mar 2003 16:53:49 -0800 AM wrote: > As an individual concerned with the future of IDNs, I would like to > recommend that ICANN seriously consider incorporating a clause in > their registry agreements I don't know how closely ICANN monitors this mailing list. > that ensures registrants that their IDN registrations will be valid > through all changes in registry operators, through all standards' > progressions, through to the day when multi-lingual domains will be > incorporated into zone files as are ASCII domains. Non-ASCII IDNs are likely to start appearing very soon (if they haven't already) in non-standard zone files for internal use by registry operators, but standard zone files might continue to be ASCII-only for a long time, maybe forever. Widespread deployment of IDNs does not depend on any upgrades to the zone file format or any other infrastructure; upgrades of end-user applications is sufficent. > The question at hand is are my current IDN registrations so-called > "ICANN-certified" registrations, as are the ASCII domains of today? Your current "IDN" registrations are not IDN registrations. IDN did not exist when those registrations were made. Those registrations are part of an experimental testbed based on a very early (and long ago rejected) draft of IDNA. > I would like to be assured that not just my ASCII "bq--" or "xn--" > string will be "ICANN-certified" but that its multi-lingual equivalent > will always be a constant registration, valid and governed by ICANN > policies, Your bq-- string under mltbd.com has no standard meaning; it means whatever Verisign says it means, and Verisign can either discard it or convert it to a standard IDN, at their whim. They have announced plans to convert these registrations, but I doubt there are (or will be) any ICANN policies compelling them to do so. But if you register an xn-- string at the second level (which is not yet possible because ICANN has not yet opened the gates), it will have a standard interpretation defined by IETF standards (not by Verisign or ICANN), and will also be a regular ASCII domain name with the same protections as any other ASCII domain name (unless those protections are explicitly removed). Disclaimer: This is all to the best of my knowledge, but I have no authority, and I don't speak for any of the organizations mentioned above. AMC From owner-idn@ops.ietf.org Fri Mar 28 20:53:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28382 for ; Fri, 28 Mar 2003 20:53:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z5PG-000182-00 for idn-data@psg.com; Fri, 28 Mar 2003 17:45:14 -0800 Received: from mailout07.sul.t-online.com ([194.25.134.83]) by psg.com with esmtp (Exim 3.36 #1) id 18z5PA-00017o-00 for idn@ops.ietf.org; Fri, 28 Mar 2003 17:45:08 -0800 Received: from fwd00.sul.t-online.de by mailout07.sul.t-online.com with smtp id 18z5P1-0004Pi-08; Sat, 29 Mar 2003 02:44:59 +0100 Received: from v.loewis.de (03047300346-0001@[217.232.28.130]) by fmrl00.sul.t-online.com with esmtp id 18z5Ov-18Ch9cC; Sat, 29 Mar 2003 02:44:53 +0100 Message-ID: <3E84FA9B.7090608@v.loewis.de> Date: Sat, 29 Mar 2003 02:44:59 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.3) Gecko/20030312 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: "Adam M. Costello" CC: IETF idn working group , AM Subject: Re: [idn] Re: IDN Registration Integrity References: <000001c2f40a$d571cad0$8bb83f44@cc634135b> <20030329003839.GI22667@nicemice.net> In-Reply-To: <20030329003839.GI22667@nicemice.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-29.8 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_NJABL, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello schrieb: > But if you register an xn-- string at the second level (which is not > yet possible because ICANN has not yet opened the gates), Can you elaborate? What gates need to be opened? There are certainly already xn-- registrations at the second level. Regards, Martin From owner-idn@ops.ietf.org Fri Mar 28 21:53:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29534 for ; Fri, 28 Mar 2003 21:53:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z6NE-000Aa9-00 for idn-data@psg.com; Fri, 28 Mar 2003 18:47:12 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 18z6NC-000AZu-00 for idn@ops.ietf.org; Fri, 28 Mar 2003 18:47:10 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18z6NB-0007oT-00 for ; Fri, 28 Mar 2003 18:47:09 -0800 Date: Sat, 29 Mar 2003 02:47:09 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Re: IDN Registration Integrity Message-ID: <20030329024709.GJ22667@nicemice.net> Reply-To: IETF idn working group References: <000001c2f40a$d571cad0$8bb83f44@cc634135b> <20030329003839.GI22667@nicemice.net> <3E84FA9B.7090608@v.loewis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3E84FA9B.7090608@v.loewis.de> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit "Martin v. Lwis" wrote: > What gates need to be opened? There are certainly already xn-- > registrations at the second level. Under some TLDs, yes, but last I heard ICANN was not yet allowing xn-- registrations under any TLD whose registry had signed a contract with ICANN, which includes all the gTLDs and some ccTLDs (like .jp). I've heard that xn-- registrations are happening under .nu. Do you know of others? The .nu registry claims that "NU Domain Ltd is the only Top Level Domain (TLD) in the world offering this service", but I wouldn't be surprised if the claim is exaggerated or out of date. I guess there are many ccTLDs that are not blocked by ICANN, but are waiting while they develop their own registration policies. AMC From owner-idn@ops.ietf.org Sat Mar 29 04:22:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17533 for ; Sat, 29 Mar 2003 04:22:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zCN1-000L3M-00 for idn-data@psg.com; Sat, 29 Mar 2003 01:11:23 -0800 Received: from mailout10.sul.t-online.com ([194.25.134.21]) by psg.com with esmtp (Exim 3.36 #1) id 18zCMV-000KoE-00 for idn@ops.ietf.org; Sat, 29 Mar 2003 01:10:51 -0800 Received: from fwd05.sul.t-online.de by mailout10.sul.t-online.com with smtp id 18zCMT-0000VF-02; Sat, 29 Mar 2003 10:10:49 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.47.123]) by fmrl05.sul.t-online.com with esmtp id 18zCMD-1ZIHseC; Sat, 29 Mar 2003 10:10:33 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2T9Abe9001616 for ; Sat, 29 Mar 2003 10:10:37 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id h2T9Aa8M001613; Sat, 29 Mar 2003 10:10:36 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: IETF idn working group Subject: Re: [idn] Re: IDN Registration Integrity References: <000001c2f40a$d571cad0$8bb83f44@cc634135b> <20030329003839.GI22667@nicemice.net> <3E84FA9B.7090608@v.loewis.de> <20030329024709.GJ22667@nicemice.net> From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 29 Mar 2003 10:10:35 +0100 In-Reply-To: <20030329024709.GJ22667@nicemice.net> Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-39.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,MAILTO_TO_REMOVE, QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk "Adam M. Costello" writes: > Under some TLDs, yes, but last I heard ICANN was not yet allowing xn-- > registrations under any TLD whose registry had signed a contract with > ICANN, which includes all the gTLDs and some ccTLDs (like .jp). Very interesting. Was this published anywhere? What is the rationale? > I've heard that xn-- registrations are happening under .nu. Do you know > of others? The .nu registry claims that "NU Domain Ltd is the only Top > Level Domain (TLD) in the world offering this service", but I wouldn't > be surprised if the claim is exaggerated or out of date. Me, atleast, I cannot counter that claim. Thanks, Martin From owner-idn@ops.ietf.org Sat Mar 29 06:40:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19387 for ; Sat, 29 Mar 2003 06:40:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zEZp-0003NE-00 for idn-data@psg.com; Sat, 29 Mar 2003 03:32:45 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 18zEZm-0003N2-00 for idn@ops.ietf.org; Sat, 29 Mar 2003 03:32:42 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18zEZm-0000My-00 for ; Sat, 29 Mar 2003 03:32:42 -0800 Date: Sat, 29 Mar 2003 11:32:42 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Re: IDN Registration Integrity Message-ID: <20030329113242.GM22667@nicemice.net> Reply-To: IETF idn working group References: <000001c2f40a$d571cad0$8bb83f44@cc634135b> <20030329003839.GI22667@nicemice.net> <3E84FA9B.7090608@v.loewis.de> <20030329024709.GJ22667@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-39.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit "Martin v. Lwis" wrote: > > Under some TLDs, yes, but last I heard ICANN was not yet allowing > > xn-- registrations under any TLD whose registry had signed a > > contract with ICANN, which includes all the gTLDs and some ccTLDs > > (like .jp). > > Very interesting. Was this published anywhere? What is the > rationale? http://www.icann.org/riodejaneiro/idn-topic.htm Note that that is not the only point of view on the subject of IDN registration policy. See also: http://www.imc.org/idn-reg-policy/ AMC From owner-idn@ops.ietf.org Sat Mar 29 07:24:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20158 for ; Sat, 29 Mar 2003 07:24:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zFE1-000ChB-00 for idn-data@psg.com; Sat, 29 Mar 2003 04:14:17 -0800 Received: from www.namesbeyond.com ([216.220.34.103] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 18zFDz-000Cgo-00 for idn@ops.ietf.org; Sat, 29 Mar 2003 04:14:15 -0800 Message-ID: <017e01c2f5ec$b478fc70$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "IETF idn working group" References: <000001c2f40a$d571cad0$8bb83f44@cc634135b> <20030329003839.GI22667@nicemice.net> <3E84FA9B.7090608@v.loewis.de> <20030329024709.GJ22667@nicemice.net> <20030329113242.GM22667@nicemice.net> Subject: Re: [idn] Re: IDN Registration Integrity Date: Sat, 29 Mar 2003 07:14:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-22.3 required=5.0 tests=BAYES_01,MAILTO_TO_REMOVE,ORIGINAL_MESSAGE, QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit The number of ccTLDs that have a contract with ICANN is however quite small. ;-) http://www.icann.org/cctlds/ ----- Original Message ----- From: "Adam M. Costello" To: "IETF idn working group" Sent: Saturday, March 29, 2003 6:32 AM Subject: Re: [idn] Re: IDN Registration Integrity > "Martin v. Lwis" wrote: > > > > Under some TLDs, yes, but last I heard ICANN was not yet allowing > > > xn-- registrations under any TLD whose registry had signed a > > > contract with ICANN, which includes all the gTLDs and some ccTLDs > > > (like .jp). > > > > Very interesting. Was this published anywhere? What is the > > rationale? > > http://www.icann.org/riodejaneiro/idn-topic.htm > > Note that that is not the only point of view on the subject of IDN > registration policy. See also: > > http://www.imc.org/idn-reg-policy/ > > AMC > >