From owner-idn@ops.ietf.org Fri Mar 1 07:19:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16649 for ; Fri, 1 Mar 2002 07:19:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16glnb-0007Dy-00 for idn-data@psg.com; Fri, 01 Mar 2002 04:06:07 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16glna-0007Dq-00 for idn@ops.ietf.org; Fri, 01 Mar 2002 04:06:07 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14485; Fri, 1 Mar 2002 07:06:02 -0500 (EST) Message-Id: <200203011206.HAA14485@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-nameprep-08.txt Date: Fri, 01 Mar 2002 07:06:02 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Nameprep: A Stringprep Profile for Internationalized Domain Names Author(s) : P. Hoffman, M. Blanchet Filename : draft-ietf-idn-nameprep-08.txt Pages : Date : 28-Feb-02 This document describes how to prepare internationalized domain name 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 DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-08.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-ietf-idn-nameprep-08.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-ietf-idn-nameprep-08.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228135220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-nameprep-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-nameprep-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228135220.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Fri Mar 1 08:24:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16648 for ; Fri, 1 Mar 2002 07:19:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16glnY-0007Do-00 for idn-data@psg.com; Fri, 01 Mar 2002 04:06:04 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16glnX-0007Di-00 for idn@ops.ietf.org; Fri, 01 Mar 2002 04:06:03 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14446; Fri, 1 Mar 2002 07:05:58 -0500 (EST) Message-Id: <200203011205.HAA14446@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-idna-07.txt Date: Fri, 01 Mar 2002 07:05:57 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Internationalizing Host Names In Applications (IDNA) Author(s) : P. Faltstrom, P. Hoffman, A. Costello Filename : draft-ietf-idn-idna-07.txt Pages : Date : 28-Feb-02 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 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 the same octets used in so-called host names today. IDNA is only meant for processing domain names, not free text. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-07.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-ietf-idn-idna-07.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-ietf-idn-idna-07.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228135205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-idna-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-idna-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228135205.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Mon Mar 4 07:25:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21591 for ; Mon, 4 Mar 2002 07:25:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16hrG5-0004tH-00 for idn-data@psg.com; Mon, 04 Mar 2002 04:08:01 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16hrG4-0004tB-00 for idn@ops.ietf.org; Mon, 04 Mar 2002 04:08:00 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20726; Mon, 4 Mar 2002 07:07:57 -0500 (EST) Message-Id: <200203041207.HAA20726@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-punycode-01.txt Date: Mon, 04 Mar 2002 07:07:57 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Punycode version 0.3.3 Author(s) : A. Costello Filename : draft-ietf-idn-punycode-01.txt Pages : Date : 01-Mar-02 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 [UNICODE] 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). Bootstring is a general algorithm 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 appropriate for IDNA. This document specifies Bootstring and the parameter values for Punycode. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-01.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-ietf-idn-punycode-01.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-ietf-idn-punycode-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020301135329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-punycode-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-punycode-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020301135329.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Mon Mar 4 11:44:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01791 for ; Mon, 4 Mar 2002 11:43:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16hvB6-000ENm-00 for idn-data@psg.com; Mon, 04 Mar 2002 08:19:08 -0800 Received: from smtprelay2.dc3.adelphia.net ([24.50.78.5]) by psg.com with esmtp (Exim 3.35 #1) id 16hvB4-000ENY-00 for idn@ops.ietf.org; Mon, 04 Mar 2002 08:19:06 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.161]) by smtprelay2.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GSGINS00.702 for ; Mon, 4 Mar 2002 11:19:04 -0500 Message-ID: <008001c1c398$41cbb8c0$a1424244@anhmca.adelphia.net> From: "Doug Ewell" To: References: <200203041207.HAA20726@ietf.org> Subject: Re: [idn] I-D ACTION:draft-ietf-idn-punycode-01.txt Date: Mon, 4 Mar 2002 08:18:36 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internationalized Domain Name Working Group of the IETF. > > Title : Punycode version 0.3.3 > Author(s) : A. Costello > Filename : draft-ietf-idn-punycode-01.txt > Pages : > Date : 01-Mar-02 When an announcement like this comes in, it would be really nice for the abstract to mention what has changed since the last version. No need for lengthy explanations or complicated expressions, just something simple like "The conformance rules have been clarified" or "Some spelling and grammatical errors were cleaned up." This would save time when perusing the new version. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Mon Mar 4 12:27:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04637 for ; Mon, 4 Mar 2002 12:27:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16hvzX-000GXq-00 for idn-data@psg.com; Mon, 04 Mar 2002 09:11:15 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.35 #1) id 16hvzW-000GXj-00 for idn@ops.ietf.org; Mon, 04 Mar 2002 09:11:14 -0800 Received: from [] (modemcable151.132-130-66.que.mc.videotron.ca [66.130.132.151]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g24HX0a12560; Mon, 4 Mar 2002 12:33:00 -0500 (EST) Date: Mon, 04 Mar 2002 12:10:35 -0500 From: Marc Blanchet To: idn@ops.ietf.org cc: jseng@pobox.org.sg Subject: [idn] WG last call summary Message-ID: <85930000.1015261835@localhost> X-Mailer: Mulberry/2.2.0b2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The authors of the idna/nameprep/stringprep/punycode documents that were subject to the wg last call, have produced the following summary of comments that were raised during the wg last call period. New versions of drafts have been sent that should follow this summary. The new versions of the documents are available in the internet-drafts directory. These documents are: - draft-ietf-idn-idna-07.txt - draft-ietf-idn-nameprep-08.txt - draft-ietf-idn-punycode-01.txt - draft-hoffman-stringprep-01.txt We will be sending the documents for IESG consideration for Proposed Standard on March 11th 2002. James and Marc, co-chairs. ==================================================================== Summary of the idn WG last call on idna/nameprep/stringprep/punycode Collected by the authors. Note from the chairs: - "editorial changes" are in the first part of this summary. - The last part of the summary discuss about the major technical changes. The chairs have concluded that there is working group consensus not to incorporate those major technical changes in the new versions of documents. - new versions of documents should include the changes in this summary. ========== IDNA ========== Throughout: Carefully check carefully for host->domain. Also change "hostname" to "host name". Abstract: Add "IDNA is only meant for processing domain names, not free text." 1: Remove last paragraph about mailing list. 1.1: Add: 1.1 Interaction of protocol parts IDNA requires that implementations process input strings with Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP], and then with Punycode [PUNYCODE]. Implementations of IDNA MUST fully implement Nameprep and Punycode; neither Nameprep nor Punycode are optional. 2: Replace the three paragraphs that start with "A label is an individual...", "An "internationalized domain name" (IDN) is...", and "An internationalized label contains...", and replace them with the following four paragraphs. [STD13] talks about "domain names" and "host names", but many people use the terms interchangeably. Further, because [STD13] was not terribly clear, many people who are sure they know the exact definitions of each of these terms disagree on the definitions. A label is an individual part of a domain name. Labels are usually shown separated by dots; for example, the domain name "www.example.com" is composed of three labels: "www", "example", and "com". (The zero-length root label that is implied in domain names, as described in [STD13], is not considered a label in this specification.) Throughout this document the term "label" is shorthand for "text label", and "every label" means "every text label". In IDNA, not all text strings can be labels. An "internationalized domain name" (IDN) is a domain name for which the ToASCII operation (see section 4) can be applied to each label without failing. This document does not attempt to define an "internationalized host name". It is expected that protocols and name-handling bodies will want to limit the characters allowed in IDNs further than what is specified in this document, such as to prohibit additional characters that they feel are unneeded or harmful in registered domain names. An "internationalized label" is a label composed of characters from the Unicode character set; note, however, that not every string of Unicode characters can be an internationalized label. To allow internationalized labels to be handled by existing applications, IDNA uses an "ACE label" (ACE stands for ASCII Compatible Encoding), which can be represented using only ASCII characters but is equivalent to a label containing non-ASCII characters. More rigorously, an ACE label is defined to be any label that the ToUnicode operation would alter (see section 4.2). For every internationalized label that cannot be directly represented in ASCII, there is an equivalent ACE label. The conversion of labels to and from the ACE form is specified in section 4. 3: At the beginning of section 3, change "rules" to "requirements" for consistency. 3: In requirement 1, insert "(see section 2)" after "generic domain name slot". 3: Change (2) to: 2) ACE labels obtained from domain name slots SHOULD be hidden from users except when the use of the non-ASCII form would cause problems or when the ACE form is explicitly requested. Given an internationalized domain name, an equivalent domain name containing no ACE labels can be obtained by applying the ToUnicode operation (see section 4) to each label. When requirements 1 and 2 both apply, requirement 1 takes precedence. 4.1: In the first paragraph, change the second sentence to: The original sequence and the resulting sequence are equivalent labels. (If the original is an internationalized label that cannot be directly represented in ASCII, the result will be the equivalent ACE label.) 4.1: In the second paragraph, change the second sentence from "Failure means that the original sequence cannot be used as a label in an IDN." to "If any step fails, the original sequence MUST NOT be used as a label in an IDN." 4.1: After the second paragraph, add the following paragraph: The inputs to ToASCII are a sequence of code points; a flag indicating whether to prohibit unassigned code points (see [STRINGPREP]); and a flag indicating whether to apply the host name syntax rules. The output of ToASCII is either a sequence of ASCII code points or a failure condition. 4.1: In step 2, add "and fail if there is an error". 4.1: In step 3, change the "*" at the beginning of each substep to "(a)" and "(b)" to make them easier to refer to. 4.2: After the second paragraph, add the following paragraph: The inputs to ToUnicode are a sequence of code points; a flag indicating whether to prohibit unassigned code points (see [STRINGPREP]); and a flag indicating whether to apply the host name syntax rules. The output of ToUnicode is always a sequence of Unicode code points. 4.2: In step 2, add "and fail if there is an error". 5: Replace the section with: [[ Note to the IESG and Internet Draft readers: The two uses of the string "IESG--" below are to be changed at time of publication to a prefix which fulfills the requirements in the first paragraph. ]] The ACE prefix, used in the conversion operations (section 4), is two alphanumeric ASCII characters followed by two hyphen-minuses. It cannot be any of the prefixes already used in earlier documents, which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--", "ra--", "wq--" and "zq--". The ToASCII and ToUnicode operations MUST recognize the ACE prefix in a case-insensitive manner. The ACE prefix for IDNA is "IESG--". This means that an ACE label might be "IESG--de-jg4avhby1noc0d", where "de-jg4avhby1noc0d" is the part of the ACE label that is generated by the encoding steps in [PUNYCODE]. 5: Change the example in the second paragraph to "de-jg4avhby1noc0d" because the current example isn't valid Punycode. 6.1: After the first sentence of the second paragraph, add "ACE labels that are displayed or input MUST always include the ACE prefix." 6.2: At the end of the second paragraph, add "ACE labels always include the ACE prefix." 6.4: In the first sentence of the second paragraph, change "in ACE format" to "in ACE format (which always includes the ACE prefix)". 6.7: Add new section. 6.7 Limitations of IDNA The IDNA protocol does not solve all linguistic issues with users inputting names in different scripts. Many important language-based and script-based mappings are not covered in IDNA and must be handled outside the protocol. For example, names that are entered in a mix of traditional and simplified Chinese characters will not be mapped to a single canonical name. Another example is Scandinavian names that are entered with U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH STROKE). 7: Change reference in last paragraph to [STRINGPREP]. 8: Change this section to: IDNs are likely to be somewhat longer than current host names, so the bandwidth needed by the root servers should go up by a small amount. Also, queries and responses for IDNs will probably be somewhat longer than typical queries today, so more queries and responses may be forced to go to TCP instead of UDP. 9: Change the first sentence from "Much of the security of the Internet relies" to "Security on the Internet partly relies". A. Add reference for [STRINGPREP]. Make URL references parallel. B: Remove this appendix. ========== Stringprep ========== Throughout: Clean up capitalization of MUST and SHOULD. 1: Change last sentence in the last paragraph to read: Language-specific equivalences such as "Aepfel" vs. "pfel", which are sometimes considered equivalent in German, may not be considered equivalent in other languages. 1: Remove "Inputs to stringprep are always specified in network byte order (big-endian)." 1.2 and 1.3: Renumber to 1.1 and 1.2. 1.2: Clarified the second paragraph for profiles that want a wide range of characters. 1.4: Remove this section (about the mailing list). 2: Fix off-by-one errors in section references. 3. In the second paragraph, change "database should used to" to "database should be used to". 3: Added a new second paragraph: Mapped characters are not re-scanned during the mapping step. That is, if character A at position X is mapped to character B, character B which is now at position X is not checked against the mapping table. 3: Add a paragraph at the end: The IETF is relying on Unicode not to change the case-mapping of currently-assigned characters in future versions of the CaseFolding.txt file. If a future version of the CaseFolding.txt file changes the mapped value of an existing character, authors of profiles of this document have to look at the changes very carefully before they update their case mapping tables. Such a change could change the behavior that users see in both updated and unupdated systems. 3: Add a paragraph to the end, after the above: Authors of profiles of this document need to consider the effects of changing the mapping of any currently-assigned character when updating their profiles. Adding a new mapping for a currently-assigned character, or changing an existing mapping, could change the behavior that users see in both updated and unupdated systems. 4: In the paragraph starting 'If a profile', change the sentence "Many user interface systems enter compatibility characters instead of the base equivalents." to "Some user interface systems make it possible to enter compatibility characters instead of the base equivalents." 4: In the second-to-last paragraph, change "normalization for KC" to "normalization form KC". 4: Replace Patrik's question at the end with: The composition process described in [UAX15] requires a fixed composition version of Unicode to ensure that strings normalized under one version of Unicode remain normalized under all future versions of Unicode. 4: Add a paragraph at the end: The IETF is relying on Unicode not to change the normalization of currently-assigned characters in future versions of normalization. If a future version of the normalization tables changes the normalized value of an existing character, authors of profiles of this document have to look at the changes very carefully before they update their normalization tables. Such a change could change the behavior that users see in both updated and unupdated systems. 5: Removed the third paragraph that said profiles SHOULD allow as many characters as possible. 6: In the first sentence of the second paragraph, change "named in the" to "named in a". 6: Before the last paragraph, add: The goal of the requirements in this section is to prevent comparisons between two strings that were both permitted to contain unassigned code points. When two strings X and Y are compared and string X was prepared in a way that permits unassigned code points, a negative result to the comparison is not definitive; it's possible that the strings don't match even though they would match if a more recent version of the profile were used for Y. However, if both X and Y were prepared in a way that permits unassigned code points, something worse can happen: even a positive result for the comparison is not definitive. It is possible that the strings do match even though they would not match if a more recent version of the profile were used (one that prohibits a code point appearing in both X and Y). 6.1: MN: change "because they are never appear" to "because they never appear". 7: Change the paragraph to: The Unicode and ISO/IEC 10646 repertoires have many characters that look similar. In many cases, users of security protocols might do visual matching, such as when comparing the names of trusted third parties. Stringprep does nothing to map similar-looking characters together nor to prohibit some characters because they look like others. B: Remove the comment at the beginning of the appendix. ========== Nameprep ========== Throughout: Carefully check carefully for host->domain. Throughout: Change "name part" to "name label" to match IDNA. Title: Change to "Nameprep: A Stringprep Profile for Internationalized Domain Names" 1: At the end of the first paragraph, add "These processing rules are only intended for internationalized domain names, not for arbitrary text." 1: Removed the second paragraph about the history of the name. 1.1: Add new section. 1.1 Interaction of protocol parts Nameprep is used by the IDNA [IDNA] protocol for preparing domain names; it is not designed for any other purpose. It is explicitly not designed for processing arbitrary free text and SHOULD NOT be used for that purpose. Nameprep is a profile of Stringprep [STRINGPREP]. Implementations of Nameprep MUST fully implement Stringprep. 1.2: Change "[SYMBOLS]" to "[CONTROL CHARACTERS]". 3: Change "there" to "here" in the first paragraph. 3: In the second paragraph, change "this section describe" to "this section describes". 3.2: Add to the beginning: This profile folds case in domain names where possible because the current DNS has case-insensitive matching for domain names. If this profile did not do that for the additional characters being added, it would lead to even greater user confusion. For example, "Abc" matches "abc", but "bc" would not match "bc". 3.2: In the last paragraph, change "This mapping was" to "These mappings were". 5: Change "there" to "here" in the first paragraph. 5: In the third paragraph, change "The collected lists of prohibited code points can be found in Appendix E of this document." to "The collected list of code points prohibited by this profile can be found in Appendix E of this document; note that IDNA prohibits additional characters.". 5: Add paragraph just before 5.1: IMPORTANT NOTE: This profile MUST be used with the IDNA protocol. The IDNA protocol has additional prohibitions that are checked outside of this profile. 5.1: Change "URLs" to "domain names". 5.1: Add the following sentence to the text: "Note that an additional space character (U+0020) is prohibited in IDNA." Remove the first line from the table. 5.2: Add the following sentence to the text: "Note that additional control characters (U+0000 through U+001F, and U+007F) are prohibited in IDNA." Remove the first two lines from the table. 6: Add "in the range 0 to 10FFFF" in the first sentence. 6: Change "the list Appendix F" to "the list in Appendix F". 7: Change the first sentence from "Much of the security of the Internet relies" to "Security on the Internet partly relies". 7: Change the first paragraph to: The Unicode and ISO/IEC 10646 repertoires have many characters that look similar. In many cases, users of security protocols might do visual matching, such as when comparing the names of trusted third parties. This profile does nothing to map similar-looking characters together nor to prohibit some characters because they look like others. 8: Remove [CharModel] and [URI]. Add reference to [IDNA]. 9: Removed this section. D: Change "character" to "code point" throughout the description at the beginning of the section. E: Remove the first two rows (0000-0020 and 007F). E: Merge rows where appropriate. E: At the end, change "pints" to "points". ========== Punycode ========== Changes from draft-ietf-idn-punycode-00.txt to draft-ietf-idn-punycode-01.txt. Throughout "hostname" --> "host name" Capitalize must/should/etc when used in the RFC 2119 sense, which happens only in section 5: "A decoder MUST recognize the letters in both uppercase and lowercase forms..." "An encoder SHOULD output only uppercase forms or only lowercase forms..." Reword to avoid must/should/etc when not used in the RFC 2119 sense: Section 3.2: "because basic code points must be segregated" --> "because basic code points were supposed to be segregated" "should not perform" --> "need not perform" "should instead use division" --> "can instead use division" Section 3.3: "inconvenient when unique encodings are required" --> "inconvenient when unique encodings are needed" "4 must be the last digit" --> "4 is the last digit" Section 4: - Given a set of basic code points, one must be designated as - the delimiter. The base can be no greater than the number of - distinguishable basic code points remaining. The digit-values - in the range 0 through base-1 must be associated with distinct - non-delimiter basic code points. In some cases multiple code - points must have the same digit-value; for example, uppercase - and lowercase versions of the same letter must be equivalent if - basic strings are case-insensitive. + Given a set of basic code points, one needs to be designated as + the delimiter. The base cannot be greater than the number of + distinguishable basic code points remaining. The digit-values + in the range 0 through base-1 need to be associated with + distinct non-delimiter basic code points. In some cases + multiple code points need to have the same digit-value; for + example, uppercase and lowercase versions of the same letter + need to be equivalent if basic strings are case-insensitive. "The initial value of n must be no greater than" --> "The initial value of n cannot be greater than" "must satisfy the following constraints" --> "need to satisfy the following constraints" "They should be chosen empirically." --> "They are best chosen empirically." Section 5: "RFC 952 recommendation" --> "RFC 952 rule" Section 6: "may be omitted" --> "can be omitted" - Some actual programming languages might require explicit - conversion between code points and integers. + In some programming languages, explicit conversion between code + points and integers might be necessary. Section 6.2: "may be omitted" --> "can be omitted" Section 6.3: "any string that required a 27-bit delta" --> "any string that needed a 27-bit delta" Section 6.4: "would probably require integers wider than 32 bits" --> "would probably need integers wider than 32 bits" Appendix B: - Punycode encoders and decoders are not required to support these - annotations, and higher layers need not use them. + Punycode encoders and decoders need not support these + annotations, and higher layers need not use them. Appendix D: "requires wider integers" --> "needs wider integers" "input must be represented" --> "input is represented" "caller must pass" --> caller passes" "may be output" --> "it can receive" "array must hold" --> "array holds" "means the corresponding Unicode character should be forced" --> "suggests that the corresponding Unicode character be forced" "means it should be forced" --> "suggests that it be forced" "return value may be" --> "return value can be" "may contain garbage" --> "might contain garbage" "array must have room" --> "array needs room" "may be a null pointer" --> "can be a null pointer" "indicates that the corresponding Unicode character should be forced" --> "suggests that the corresponding Unicode character be forced" "must be in the range" --> "needs to be in the range" "requires the Punycode string to be followed" --> "needs the Punycode string to be followed" Title "Punycode version 0.3.3" --> "Punycode: An encoding of Unicode for use with IDNA" Boilerplate Removed: - Please send comments to the author at amc@cs.berkeley.edu, or to - the idn working group at idn@ops.ietf.org. A non-paginated (and - possibly newer) version of this specification may be available at - http://www.cs.berkeley.edu/~amc/idn/ Abstract "Internationalized Domain Names [IDN] [IDNA]" --> "Internationalized Domain Names in Applications [IDNA]" "encoding" --> "transfer encoding syntax" "instance Bootstring" --> "instance of Bootstring" 1. Introduction "The IDNA draft" --> "[IDNA]" Pushed features list down to section 1.1 Features. "ratio of extended string length to basic string length" --> "ratio of basic string length to extended string length" ". This comes for free because it makes the encoding more efficient on average." --> "(although the main purpose is to improve efficiency, not readability)." Added: + 1.2 Interaction of protocol parts: + + Punycode is used by the IDNA protocol [IDNA] for converting domain + labels into ASCII; it is not designed for any other purpose. It is + explicitly not designed for processing arbitrary free text. 2. Terminology Changed key-words paragraph to quote RFC 2119 exactly: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Bootstring description Before section 3.1 added: + Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the + algorithms for sample inputs. + + The following sections describe the four techniques used in + Bootstring. "Basic code point segregation" is a very simple + and efficient encoding for basic code points occurring in the + extended string: they are simply copied all at once. "Insertion + unsort coding" encodes the non-basic code points as deltas, and + processes the code points in numerical order rather than in order of + appearance, which typically results in smaller deltas. The deltas + are represented as "generalized variable-length integers", which use + basic code points to represent nonnegative integers. The parameters + of this integer representation are dynamically adjusted using "bias + adaptation", to improve efficiency when consecutive deltas have + similar magnitudes. Clarified section 3.2: > The remainder of the basic string (after the last delimiter if there > is one) represents a sequence of nonnegative integral deltas as > generalized variable-length integers, described in section 3.3. The > meaning of the deltas is best understood in terms of the decoder. > > The decoder builds the extended string incrementally. Initially, > the extended string is a copy of the literal portion of the basic > string (excluding the last delimiter). - Each delta causes the decoder to insert a code point into the - extended string according to the following procedure. + The decoder inserts non-basic code points, one for each delta, + into the extended string, ultimately arriving at the final decoded + string. - There are two state variables: a code point n, and an index i that - ranges from zero (which is the first position of the extended - string) to the current length of the extended string (which refers - to a potential position beyond the current end). The decoder - advances the state monotonically (never returning to an earlier - state) by taking steps only upward. Each step increments i, except - when i already equals the length of the extended string, in which - case a step resets i to zero and increments n. For each delta (in - order), the decoder takes delta steps upward, then inserts the - value n into the extended string at position i, then increments i - (to skip over the code point just inserted). (An implementation - should not take each step individually, but should insead use - division and remainder calculations to advance by delta steps all at - once.) It is an error if the inserted code point is a basic code - point (because basic code points must be segregated as described in - section 3.1). + At the heart of this process is a state machine with two state + variables: an index i and a counter n. The index i refers to + a position in the extended string; it ranges from 0 (the first + position) to the current length of the extended string (which refers + to a potential position beyond the current end). If the current + state is , the next state is if i is less than the + length of the extended string, or if i equals the length of + the extended string. In other words, each state change causes i to + increment, wrapping around to zero if necessary, and n counts the + number of wrap-arounds. + + Notice that the state always advances monotonically (there is no + way for the decoder to return to an earlier state). At each state, + an insertion is either performed or not performed. At most one + insertion is performed in a given state. An insertion inserts the + value of n at position i in the extended string. The deltas are + a run-length encoding of this sequence of events: they are the + lengths of the runs of non-insertion states preceeding the insertion + states. Hence, for each delta, the decoder performs delta state + changes, then an insertion, and then one more state change. (An + implementation need not perform each state change individually, but + can instead use division and remainder calculations to compute the + next insertion state directly.) It is an error if the inserted code + point is a basic code point (because basic code points were supposed + to be segregated as described in section 3.1). > The encoder's main task is to derive the sequence of deltas that > will cause the decoder to construct the desired string. It can do > this by repeatedly scanning the extended string for the next code > point that the decoder would need to insert, and counting the number - of steps the decoder would need to take, mindful of the fact that - the decoder will be stepping over only those code points that have - already been inserted. + of state changes the decoder would need to perform, mindful of the + fact that the decoder's extended string will include only those + code points that have already been inserted. > Section 6.3 "Encoding procedure" gives a precise algorithm. 5. Parameter values for Punycode "initial_n = 0x80" --> "initial_n = 128 = 0x80" Clarified input restrictions: - In Punycode, code points are Unicode code points [UNICODE], that - is, integers in the range 0..10FFFF, but not D800..DFFF, which are - reserved for use by UTF-16. + Although the only restriction Punycode imposes on the input integers + is that they be nonnegative, these parameters are especially + designed to work well with Unicode [UNICODE] code points, which + are integers in the range 0..10FFFF (but not D800..DFFF, which are + reserved for use by the UTF-16 encoding of Unicode). 6.2 Decoding procedure Made the clamping code not look buggy anymore: - let t = tmin if k <= bias, tmax if k >= bias + tmax, or - k - bias otherwise + let t = tmin if k <= bias {+ tmin}, or + tmax if k >= bias + tmax, or k - bias otherwise - The assignment of t, where t is clamped to the range tmin through - tmax, does not handle the case where bias < k < bias + tmin, but - that is impossible because of the way bias is computed and because - of the constraints on the parameters. + In the assignment of t, where t is clamped to the range tmin through + tmax, "+ tmin" can always be omitted. This makes the clamping + calculation incorrect when bias < k < bias + tmin, but that cannot + happen because of the way bias is computed and because of the + constraints on the parameters. "The statement enclosed in braces" --> "The full statement enclosed in braces" 6.3 Encoding procedure Made the clamping code not look buggy anymore (same fix as for section 6.2). 7. Punycode example strings --> Punycode examples Pushed strings down into 7.1 Sample strings. Added sections 7.2 and 7.3: + 7.2 Decoding traces + + In the following traces, the evolving state of the decoder is + shown as a sequence of hexadecimal values, representing the code + points in the extended string. An asterisk appears just after the + most recently inserted code point, indicating both n (the value + preceeding the asterisk) and i (the position of the value just after + the asterisk). Other numerical values are decimal. + + Decoding trace of example B from section 7.1: + + n is 128, i is 0, bias is 72 + input is "ihqwcrb4cv8a8dqg056pqjye" + there is no delimiter, so extended string starts empty + delta "ihq" decodes to 19853 + bias becomes 21 + 4E0D * + delta "wc" decodes to 64 + bias becomes 20 + 4E0D 4E2D * + delta "rb" decodes to 37 + bias becomes 13 + 4E3A * 4E0D 4E2D + delta "4c" decodes to 56 + bias becomes 17 + 4E3A 4E48 * 4E0D 4E2D + delta "v8a" decodes to 599 + bias becomes 32 + 4E3A 4EC0 * 4E48 4E0D 4E2D + delta "8d" decodes to 130 + bias becomes 23 + 4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D + delta "qg" decodes to 154 + bias becomes 25 + 4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D + delta "056p" decodes to 46301 + bias becomes 84 + 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 * + delta "qjye" decodes to 88531 + bias becomes 90 + 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587 + + Decoding trace of example L from section 7.1: + + n is 128, i is 0, bias is 72 + input is "3B-ww4c5e180e575a65lsy2b" + literal portion is "3B-", so extended string starts as: + 0033 0042 + delta "ww4c" decodes to 62042 + bias becomes 27 + 0033 0042 5148 * + delta "5e" decodes to 139 + bias becomes 24 + 0033 0042 516B * 5148 + delta "180e" decodes to 16683 + bias becomes 67 + 0033 5E74 * 0042 516B 5148 + delta "575a" decodes to 34821 + bias becomes 82 + 0033 5E74 0042 516B 5148 751F * + delta "65l" decodes to 14592 + bias becomes 67 + 0033 5E74 0042 7D44 * 516B 5148 751F + delta "sy2b" decodes to 42088 + bias becomes 84 + 0033 5E74 0042 7D44 91D1 * 516B 5148 751F + 7.3 Encoding traces + + In the following traces, code point values are hexadecimal, while + other numerical values are decimal. + + Encoding trace of example B from section 7.1: + + bias is 72 + input is: + 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587 + there are no basic code points, so no literal portion + next code point to insert is 4E0D + needed delta is 19853, encodes as "ihq" + bias becomes 21 + next code point to insert is 4E2D + needed delta is 64, encodes as "wc" + bias becomes 20 + next code point to insert is 4E3A + needed delta is 37, encodes as "rb" + bias becomes 13 + next code point to insert is 4E48 + needed delta is 56, encodes as "4c" + bias becomes 17 + next code point to insert is 4EC0 + needed delta is 599, encodes as "v8a" + bias becomes 32 + next code point to insert is 4ED6 + needed delta is 130, encodes as "8d" + bias becomes 23 + next code point to insert is 4EEC + needed delta is 154, encodes as "qg" + bias becomes 25 + next code point to insert is 6587 + needed delta is 46301, encodes as "056p" + bias becomes 84 + next code point to insert is 8BF4 + needed delta is 88531, encodes as "qjye" + bias becomes 90 + output is "ihqwcrb4cv8a8dqg056pqjye" + + Encoding trace of example L from section 7.1: + + bias is 72 + input is: + 0033 5E74 0042 7D44 91D1 516B 5148 751F + basic code points (0033, 0042) are copied to literal portion: "3B-" + next code point to insert is 5148 + needed delta is 62042, encodes as "ww4c" + bias becomes 27 + next code point to insert is 516B + needed delta is 139, encodes as "5e" + bias becomes 24 + next code point to insert is 5E74 + needed delta is 16683, encodes as "180e" + bias becomes 67 + next code point to insert is 751F + needed delta is 34821, encodes as "575a" + bias becomes 82 + next code point to insert is 7D44 + needed delta is 14592, encodes as "65l" + bias becomes 67 + next code point to insert is 91D1 + needed delta is 42088, encodes as "sy2b" + bias becomes 84 + output is "3B-ww4c5e180e575a65lsy2b" 8. Security considerations '"nameprep"' --> 'Nameprep' 9. References Updated references: - [IDNA] Patrik Faltstrom, Paul Hoffman, Adam M. Costello, - "Internationalizing Host Names In Applications (IDNA)", 2001-Nov-19, - draft-ietf-idn-idna-05. + [IDNA] Patrik Faltstrom, Paul Hoffman, Adam M. Costello, + "Internationalizing Domain Names In Applications (IDNA)", + 2002-###-##, draft-ietf-idn-idna-07. - [NAMEPREP] Paul Hoffman, Marc Blanchet, "Stringprep - Profile for Internationalized Host Names", 2001-Sep-27, - draft-ietf-idn-nameprep-06. + [NAMEPREP] Paul Hoffman, Marc Blanchet, "Nameprep: A Stringprep + Profile for Internationalized Domain Names", 2002-###-##, + draft-ietf-idn-nameprep-08. Removed reference [IDN] (working group), which is no longer cited. B. Mixed-case annotation Clarified applicability to IDNA: + Note, however, that mixed-case annotation is not used by the + ToASCII and ToUnicode operations specified in [IDNA], and therefore + implementors of IDNA can disregard this appendix. Reworded the preceeding sentence to make it flow better: - The encoded string can, however, use mixed case as an annotation - telling how to convert the original folded string into a mixed-case - string for display purposes. + The encoded string can use mixed case as an annotation telling how + to convert the folded string into a mixed-case string for display + purposes. Clarified relationship with the rest of the spec with a new second-to-last paragraph: + These annotations do not alter the code points returned by decoders; + the annotations are returned separately, for the caller to use or + ignore. Encoders can accept annotations in addition to code points, + but the annotations do not alter the output, except to influence the + uppercase/lowercase form of ASCII letters. D. Punycode sample implementation Removed version number and date, cite the draft name instead. Changed clamping code to look like the pseudocode: - t = k <= bias ? tmin : k - bias >= tmax ? tmax : k - bias; + t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */ + k >= bias + tmax ? tmax : k - bias; ========== Major technical changes ========== Bidirectional display: Martin Duerst suggested an addition to nameprep to solve the problem of differently-ordered strings having the identical display. The change was only partially specified, and no examples were given. The proposed solution would involve tables derived from the Unicode standard. Hebrew points: Jonathan Rosenne asked that Hebrew points be mapped out in nameprep because the are optional in Hebrew. Off-list comments pointed out that points are not optional in Yiddish, and that some people would want to have points in their names to look more traditional. The proposed solution would involve tables derived from the Unicode standard. Korean syllables: Soobok Lee and Kent Karlsson asked that we not use NFKC due to its incompleteness and incorrectness with respect to some combining syllables. The proposed changes either change NFKC in a way that does not conform to the Unicode standard or use a different normalization scheme altogether. Near-instant updating: Eric hall suggested that Nameprep be augmented to support near-instant updates of all systems. This would involve a static format for the tables in the documents, a method for end entities to know where to get the updates from, and a tranfer method. Traditional-Simplified Chinese: Lee Ming Tseng, Jan Ming Ho, and Kenny Huang published a draft (draft-tseng-idn-piidna-00.txt) which proposes to prohibit all Chinese, Japanese, and Korean Han characters from plane 0 after nameprep. The purpose is to allow time for someone to come up with an IETF solution to the Traditional-Simplified translation problem; the prohibition on the specified Han characters would be lifted after that time. "Unneeded" characters: A few people suggested adding unneeded characters to the prohibited list in nameprep. None gave specific lists of characters, although "punctuation" and "symbols" were mentioned many times. Whole domain names: Kent asked that all the documents be changed to deal with full domain names instead of name parts. This would allow additional "full stop" characters to be handled and would change the bidirectional properties of names. From owner-idn@ops.ietf.org Thu Mar 7 19:33:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04692 for ; Thu, 7 Mar 2002 19:33:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16j7yf-0006Nz-00 for idn-data@psg.com; Thu, 07 Mar 2002 16:11:17 -0800 Received: from smtp21.singnet.com.sg ([165.21.101.201]) by psg.com with esmtp (Exim 3.35 #1) id 16j7ye-0006Nt-00 for idn@ops.ietf.org; Thu, 07 Mar 2002 16:11:16 -0800 Received: from jamessonyviao (bb-165-21-94-186.singnet.com.sg [165.21.94.186]) by smtp21.singnet.com.sg (8.12.2/8.12.2) with SMTP id g280APgA032259; Fri, 8 Mar 2002 08:10:25 +0800 Message-ID: <004001c1c635$9ad4d3d0$0301000a@jamessonyviao> From: "James Seng" To: "Doug Ewell" , References: <200203041207.HAA20726@ietf.org> <008001c1c398$41cbb8c0$a1424244@anhmca.adelphia.net> Subject: Re: [idn] I-D ACTION:draft-ietf-idn-punycode-01.txt Date: Fri, 8 Mar 2002 08:10:07 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The diff and changes are already describe in the summary which Marc posted a few days ago, just in case anyone wonders what happened to this. -James Seng ----- Original Message ----- From: "Doug Ewell" To: Sent: Tuesday, March 05, 2002 12:18 AM Subject: Re: [idn] I-D ACTION:draft-ietf-idn-punycode-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Internationalized Domain Name Working > Group of the IETF. > > > > Title : Punycode version 0.3.3 > > Author(s) : A. Costello > > Filename : draft-ietf-idn-punycode-01.txt > > Pages : > > Date : 01-Mar-02 > > When an announcement like this comes in, it would be really nice for the > abstract to mention what has changed since the last version. No need > for lengthy explanations or complicated expressions, just something > simple like "The conformance rules have been clarified" or "Some > spelling and grammatical errors were cleaned up." This would save time > when perusing the new version. > > -Doug Ewell > Fullerton, California > > > From owner-idn@ops.ietf.org Sun Mar 10 23:17:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20267 for ; Sun, 10 Mar 2002 23:17:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16kGxz-00043F-00 for idn-data@psg.com; Sun, 10 Mar 2002 19:59:19 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.35 #1) id 16kGxy-000439-00 for idn@ops.ietf.org; Sun, 10 Mar 2002 19:59:18 -0800 Received: (qmail 13697 invoked by uid 1001); 11 Mar 2002 03:58:13 -0000 Date: 11 Mar 2002 03:58:13 -0000 Message-ID: <20020311035813.5586.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <85930000.1015261835@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Marc Blanchet writes: > We will be sending the documents for IESG consideration for Proposed > Standard on March 11th 2002. That's outrageous. IDNA has received strong written objections from at least fifteen regular WG participants and _hundreds_ of other people. IDNA will cause a tremendous amount of damage, including bounced email, web link failures, widespread user confusion, and massive costs---much higher than necessary---for software development and deployment. You say that you are obliged to ignore all these objections because the IDN WG has to _do something_. But the IETF procedures don't say ``It's okay to make an incredibly destructive modification to the Internet protocol suite if you have to _do something_.'' I hope that the IDN WG can settle on a safe course of action. However, until that happens, we will have to stick to the status quo. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Sun Mar 10 23:31:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20638 for ; Sun, 10 Mar 2002 23:31:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16kHHa-0004Jh-00 for idn-data@psg.com; Sun, 10 Mar 2002 20:19:34 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16kHHa-0004Jb-00 for idn@ops.ietf.org; Sun, 10 Mar 2002 20:19:34 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id UAA30505; Sun, 10 Mar 2002 20:19:20 -0800 Message-Id: <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 10 Mar 2002 20:19:07 -0800 To: "D. J. Bernstein" From: Dave Crocker Subject: Re: [idn] WG last call summary Cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu In-Reply-To: <20020311035813.5586.qmail@cr.yp.to> References: <85930000.1015261835@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 03:58 AM 3/11/2002 +0000, D. J. Bernstein wrote: >That's outrageous. Hyperbole and sweeping, undocumented assertions are outrageous. Forwarding specifications that have been carefully responsive to the problem that the group was tasked with solving... now that is NOT outrageous. It's what supposed to happen in the IETF and what has, in fact, been done in IDN. >IDNA will cause a tremendous amount of damage, Such false claims have been dealt with repeatedly. Continuing to make a false claim does not make it true. >You say that you are obliged to ignore all these objections because the >IDN WG has to _do something_. He did not say that. Hence there is no need to respond to the derivative assertions from that falsehood. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; (new)fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Mar 11 01:45:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22015 for ; Mon, 11 Mar 2002 01:45:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16kJRJ-0006Es-00 for idn-data@psg.com; Sun, 10 Mar 2002 22:37:45 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16kJRI-0006Em-00 for idn@ops.ietf.org; Sun, 10 Mar 2002 22:37:44 -0800 Received: from MASTER ([203.229.225.40]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2B6bGN18856; Mon, 11 Mar 2002 15:37:16 +0900 Message-ID: <03c901c1c8c7$10201670$2b19fea9@temp> From: "Soobok Lee" To: "D. J. Bernstein" , Cc: , , References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> Subject: Re: [idn] WG last call summary Date: Mon, 11 Mar 2002 15:36:22 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "D. J. Bernstein" To: Cc: ; ; Sent: Monday, March 11, 2002 12:58 PM Subject: Re: [idn] WG last call summary > Marc Blanchet writes: > > We will be sending the documents for IESG consideration for Proposed > > Standard on March 11th 2002. > > That's outrageous. IDNA has received strong written objections from at > least fifteen regular WG participants and _hundreds_ of other people. > IDNA will cause a tremendous amount of damage, including bounced email, > web link failures, widespread user confusion, and massive costs---much > higher than necessary---for software development and deployment. > > You say that you are obliged to ignore all these objections because the > IDN WG has to _do something_. But the IETF procedures don't say ``It's > okay to make an incredibly destructive modification to the Internet > protocol suite if you have to _do something_.'' I agree with you. I believe IESG+IAB wouldn't be a rubber stamp this time. > > I hope that the IDN WG can settle on a safe course of action. However, > until that happens, we will have to stick to the status quo. > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Tue Mar 12 13:45:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00989 for ; Tue, 12 Mar 2002 13:45:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16kr0O-000F4b-00 for idn-data@psg.com; Tue, 12 Mar 2002 10:28:12 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.35 #1) id 16kr0N-000F4V-00 for idn@ops.ietf.org; Tue, 12 Mar 2002 10:28:11 -0800 Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2CIS6418435; Tue, 12 Mar 2002 10:28:06 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20020311035813.5586.qmail@cr.yp.to> References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> Date: Tue, 12 Mar 2002 10:27:59 -0800 To: "D. J. Bernstein" , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] WG last call summary Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 3:58 AM +0000 3/11/02, D. J. Bernstein wrote: >You say that you are obliged to ignore all these objections because the >IDN WG has to _do something_. You are lying again, Dan. Marc never said that, and you know it. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu Mar 14 16:37:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01856 for ; Thu, 14 Mar 2002 16:37:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lceu-000AnU-00 for idn-data@psg.com; Thu, 14 Mar 2002 13:21:12 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16lcet-000AnO-00 for idn@ops.ietf.org; Thu, 14 Mar 2002 13:21:11 -0800 Received: (qmail 14451 invoked by uid 1001); 14 Mar 2002 21:19:39 -0000 Date: 14 Mar 2002 21:19:39 -0000 Message-ID: <20020314211939.7658.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Once again: IDNA has received strong written objections from at least fifteen regular WG participants and _hundreds_ of other people. Here are some typical quotes from IDNA proponents explicitly refusing to take these objections into account: * ``Just protesting doesn't count, if an alternative or fix isn't included''; * ``the Chair's responsibility ... is to move work along ... discouraging discussion of problems ... for which realistic solutions ... have not been proposed''; * ``unless you have a TC/SC solution which you willing to contributed to the group, I consider this discussion closed''; * ``You have only repeated problems that we already knows. You have not demonstrated any solution which is technical possible now.'' These responses are all missing the point. When a user objects to IDNA, saying--for example---that IDNA will produce ``conflicts and chaos for Internet users of Han characters,'' you can't dismiss his objection by saying that you believe that the other proposals are even worse. As I commented before, the IETF procedures don't say ``It's okay to make an incredibly destructive modification to the Internet protocol suite if you have to _do something_.'' Until the IDN WG settles on a safe course of action, we will have to stick to the status quo. I also summarized why people are objecting to IDNA: ``IDNA will cause a tremendous amount of damage, including bounced email, web link failures, widespread user confusion, and massive costs---much higher than necessary---for software development and deployment.'' Crocker asserts that ``such false claims have been dealt with repeatedly.'' Let's go back to the videotape: * IDNA co-author Adam Costello claimed in an IDN message on Sun, 27 May 2001 21:30:52 +0000 that, under IDNA, ``nothing will actually break (mail will get through, web pages will load, etc).'' * After the IDN WG identified several serious interoperability problems in the IDNA architecture---the result being that mail would bounce, web links would fail, etc.---I challenged Costello's ``nothing will actually break'' claim. * In an IDN message on Thu, 19 Jul 2001 04:31:48 +0000, Costello admitted that IDNA _would_ break things, and that his previous claim was wrong: ``I overstated it. I was wrong. Sorry.'' (Naturally, he continued by saying that even more things would be broken by another proposal.) I recently asked a simple question about how IDNA is supposed to work, from a programmer's perspective: under UNIX, if LANG is en_US.UTF-8, should the MH/NMH ``show'' mail-displaying program convert names from the IDNA character set to UTF-8? Costello, aware that a ``yes'' answer would cause interoperability problems and that a ``no'' answer would mean that users see gobbledygook instead of non-ASCII glyphs, ignored the question. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Thu Mar 14 19:20:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05643 for ; Thu, 14 Mar 2002 19:20:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lfDD-000EWy-00 for idn-data@psg.com; Thu, 14 Mar 2002 16:04:47 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16lfDC-000EWs-00 for idn@ops.ietf.org; Thu, 14 Mar 2002 16:04:46 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16lfDB-0000ul-00 for ; Thu, 14 Mar 2002 16:04:45 -0800 Date: Fri, 15 Mar 2002 00:04:45 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] WG last call summary Message-ID: <20020315000445.GA2188@nicemice.net> Reply-To: IETF idn working group References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> <20020314211939.7658.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020314211939.7658.qmail@cr.yp.to> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk I have removed ietf@ietf.org, iesg@ietf.org, and iab@isi.edu from the Cc: list. I assume that if they want to hear from me, they'll contact me. "D. J. Bernstein" wrote: > I recently asked a simple question about how IDNA is supposed to work, > from a programmer's perspective: under UNIX, if LANG is en_US.UTF-8, > should the MH/NMH ``show'' mail-displaying program convert names from > the IDNA character set to UTF-8? Costello...ignored the question. I ignored it because you had already asked the exact same question using "dig" instead of "show" and I'd already answered that question. It's easy to see that no matter what we do, things will break: For a long time, domain names have in practice contained only ASCII characters. There is bound to be software that breaks when fed non-ASCII domain names. If a program outputs non-ASCII domain names that are fed to unprepared software, things will break. If a program encodes non-ASCII domain names using ASCII characters, and those encoded names are seen by humans, that is another form of breakage. Programs can often guess which form of output is preferrable, but as you correctly point out, they cannot always know for sure. Therefore, there is no way to completely prevent breakage, except to stick with ASCII-only domain names. If this were considered a show-stopper, the working group could have conceded defeat and disbanded long ago. Instead, it chose to push ahead and attempt to minimize (not eliminate) breakage and maximize interoperability and incremental deployability. I probably shouldn't have bothered to write this. It's not really constructive, and we've been over all this before. Don't count on me to return your next volley. AMC From owner-idn@ops.ietf.org Thu Mar 14 19:31:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05803 for ; Thu, 14 Mar 2002 19:31:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lfVt-000EmK-00 for idn-data@psg.com; Thu, 14 Mar 2002 16:24:05 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16lfVt-000EmC-00 for idn@ops.ietf.org; Thu, 14 Mar 2002 16:24:05 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id QAA21356; Thu, 14 Mar 2002 16:24:04 -0800 Message-Id: <5.1.0.14.2.20020314161904.021c0030@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Mar 2002 16:23:52 -0800 To: IETF idn working group From: Dave Crocker Subject: Re: [idn] WG last call summary Cc: idn@ops.ietf.org In-Reply-To: <20020315000445.GA2188@nicemice.net> References: <20020314211939.7658.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> <20020314211939.7658.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:04 AM 3/15/2002 +0000, Adam M. Costello wrote: >For a long time, domain names have in practice contained only ASCII >characters. There is bound to be software that breaks when fed >non-ASCII domain names. If a program outputs non-ASCII domain names >that are fed to unprepared software, things will break. If a program In fact the elegence of IDNA is that it continues to pass around ascii characters to all but a very limited portion of the system. With respect to DNS, the only software that must deal with the extended character set(s) are: 1. The module that inputs the string to be stored, 2. The module that inputs the string to be looked up 3. The module that output a string Changes to #1 and #2 are only required when the input string is not ascii. Changes to #3 are required only if presentation in the extended character set are required. Failure to change #3 breaks nothing. Failure to change #1 or #2 does not break anything, though of course it limits the available character sets to the legacy ASCII-only world. As to non-DNS software that interface with DNS, note that making a change to any of the DNS modules requires that the programmer pay attention to the environment it is used in. Other than that, there are no breakage risks. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Thu Mar 14 21:03:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07841 for ; Thu, 14 Mar 2002 21:03:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lgmn-000Ftl-00 for idn-data@psg.com; Thu, 14 Mar 2002 17:45:37 -0800 Received: from smtp21.singnet.com.sg ([165.21.101.201]) by psg.com with esmtp (Exim 3.35 #1) id 16lgml-000Ftf-00 for idn@ops.ietf.org; Thu, 14 Mar 2002 17:45:35 -0800 Received: from jamessonyviao (bb-165-21-154-170.singnet.com.sg [165.21.154.170]) by smtp21.singnet.com.sg (8.12.2/8.12.2) with SMTP id g2F1jHvD032546; Fri, 15 Mar 2002 09:45:17 +0800 Message-ID: <004301c1cbc2$e4badcf0$0a01000a@jamessonyviao> From: "James Seng" To: "D. J. Bernstein" , Cc: , , References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> <20020314211939.7658.qmail@cr.yp.to> Subject: Re: [idn] WG last call summary Date: Fri, 15 Mar 2002 09:44:06 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since some of them are my response which is taken out of context, it is my duty to clarify any misleading statements. > Once again: IDNA has received strong written objections from at least > fifteen regular WG participants and _hundreds_ of other people. The email protests from Taiwan is not against the current set of drafts but the lack of handling of TC/SC within it. The problem of TC/SC is not solved in IDNA either. If it were to be done, it is either nameprep or punycode or both or another draft. Therefore, it is misleading to suggest the problem exist in or the protest is directed at IDNA particularly. > * ``Just protesting doesn't count, if an alternative or fix isn't > included''; (1) IETF progress with internet drafts. A proactive participation in IETF includes writing I-Ds that contributes to the work. Saying "I disagree with it" without explaining why and proposed alternative solution or fix is not constructive. > * ``the Chair's responsibility ... is to move work along ... > discouraging discussion of problems ... for which realistic > solutions ... have not been proposed''; This is John's statement taken out of context in an exchange Deng Xiang have with me. But I do not see anything wrong with it - it is the chairs responsibility to move forward *any* drafts that have rough consensus within the group. > * ``unless you have a TC/SC solution which you willing to contributed > to the group, I consider this discussion closed''; See (1) > * ``You have only repeated problems that we already knows. You have > not demonstrated any solution which is technical possible now.'' See (1) > These responses are all missing the point. When a user objects to IDNA, > saying--for example---that IDNA will produce ``conflicts and chaos for > Internet users of Han characters,'' you can't dismiss his objection by > saying that you believe that the other proposals are even worse. This is misleading, reading far too much. No one say other proposals are even worse. The statements you quoted above basically: - Stop repeating about your problem, we all know it by now. - None of the draft written on the problem have reach wide acceptence and therefore no rough consensus to move it forward > As I commented before, the IETF procedures don't say ``It's okay to make > an incredibly destructive modification to the Internet protocol suite if > you have to _do something_.'' Until the IDN WG settles on a safe course > of action, we will have to stick to the status quo. Once again, Marc did not say "we have to _do something_". You probably hear it in your dream. -James Seng From owner-idn@ops.ietf.org Thu Mar 14 21:14:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08318 for ; Thu, 14 Mar 2002 21:14:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lh6b-000GGi-00 for idn-data@psg.com; Thu, 14 Mar 2002 18:06:05 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16lh6a-000GGa-00 for idn@ops.ietf.org; Thu, 14 Mar 2002 18:06:04 -0800 Received: (qmail 27586 invoked by uid 1001); 15 Mar 2002 02:04:58 -0000 Date: 15 Mar 2002 02:04:58 -0000 Message-ID: <20020315020458.15214.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> <20020314211939.7658.qmail@cr.yp.to> <20020315000445.GA2188@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Adam M. Costello writes: > If this were considered a show-stopper, the working group could have > conceded defeat and disbanded long ago. Interoperability failures _are_ a show-stopper. Imagine looking a user in the eye and explaining to him why you screwed up his email delivery. The whole point of IDNA was the promise of immediate IDN deployment. You should have stopped pushing IDNA last July, when we discovered that the deployment plan was inherently broken. You now attempt to defend IDNA by attacking other proposals. This is the ethically bankrupt ``We have to _do something_'' argument once again. If every proposal before the IDN WG is harmful, then the IDN WG will have to adopt _none_ of the proposals. The IETF procedures do not say ``It's okay to make an incredibly destructive modification to the Internet protocol suite if you have to _do something_.'' How many times do I have to say this before it sinks in? (In fact, there are proposals that _don't_ break anything. I could easily shred your ``no matter what we do, things will break'' claim. But this doesn't matter right now.) IDNA is harmful. Therefore, IDNA must not move forward. Once again: IDNA has received strong written objections from at least fifteen regular WG participants and _hundreds_ of other people. The merits of other proposals are simply not relevant. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Thu Mar 14 21:22:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08471 for ; Thu, 14 Mar 2002 21:22:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lhDr-000GNj-00 for idn-data@psg.com; Thu, 14 Mar 2002 18:13:35 -0800 Received: from smtp-server3.tampabay.rr.com ([65.32.1.41]) by psg.com with esmtp (Exim 3.35 #1) id 16lhDq-000GNd-00 for idn@ops.ietf.org; Thu, 14 Mar 2002 18:13:34 -0800 Received: from e0g0l1 (242685hfc26.tampabay.rr.com [24.26.85.26]) by smtp-server3.tampabay.rr.com (8.12.2/8.12.2) with SMTP id g2F2DHoh000917; Thu, 14 Mar 2002 21:13:17 -0500 (EST) Message-ID: <003101c1cbc3$0d77c9a0$1a551a18@tampabay.rr.com> From: "William Blackwood" To: "D. J. Bernstein" , Cc: , , References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> <20020314211939.7658.qmail@cr.yp.to> Subject: Re: [idn] WG last call summary Date: Thu, 14 Mar 2002 20:45: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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernstein's misrepresentations of fact and quotes are frequent and well documented. Bernstein lacks credibility. Best to just ignore Bernstein's senseless drivel. ----- Original Message ----- From: D. J. Bernstein To: Cc: ; ; Sent: Thursday, March 14, 2002 4:19 PM Subject: Re: [idn] WG last call summary > Once again: IDNA has received strong written objections from at least > fifteen regular WG participants and _hundreds_ of other people. > > Here are some typical quotes from IDNA proponents explicitly refusing to > take these objections into account: > > * ``Just protesting doesn't count, if an alternative or fix isn't > included''; > > * ``the Chair's responsibility ... is to move work along ... > discouraging discussion of problems ... for which realistic > solutions ... have not been proposed''; > > * ``unless you have a TC/SC solution which you willing to contributed > to the group, I consider this discussion closed''; > > * ``You have only repeated problems that we already knows. You have > not demonstrated any solution which is technical possible now.'' > > These responses are all missing the point. When a user objects to IDNA, > saying--for example---that IDNA will produce ``conflicts and chaos for > Internet users of Han characters,'' you can't dismiss his objection by > saying that you believe that the other proposals are even worse. > > As I commented before, the IETF procedures don't say ``It's okay to make > an incredibly destructive modification to the Internet protocol suite if > you have to _do something_.'' Until the IDN WG settles on a safe course > of action, we will have to stick to the status quo. > > I also summarized why people are objecting to IDNA: ``IDNA will cause a > tremendous amount of damage, including bounced email, web link failures, > widespread user confusion, and massive costs---much higher than > necessary---for software development and deployment.'' Crocker asserts > that ``such false claims have been dealt with repeatedly.'' Let's go > back to the videotape: > > * IDNA co-author Adam Costello claimed in an IDN message on Sun, 27 > May 2001 21:30:52 +0000 that, under IDNA, ``nothing will actually > break (mail will get through, web pages will load, etc).'' > > * After the IDN WG identified several serious interoperability > problems in the IDNA architecture---the result being that mail > would bounce, web links would fail, etc.---I challenged Costello's > ``nothing will actually break'' claim. > > * In an IDN message on Thu, 19 Jul 2001 04:31:48 +0000, Costello > admitted that IDNA _would_ break things, and that his previous > claim was wrong: ``I overstated it. I was wrong. Sorry.'' > (Naturally, he continued by saying that even more things would be > broken by another proposal.) > > I recently asked a simple question about how IDNA is supposed to work, > from a programmer's perspective: under UNIX, if LANG is en_US.UTF-8, > should the MH/NMH ``show'' mail-displaying program convert names from > the IDNA character set to UTF-8? Costello, aware that a ``yes'' answer > would cause interoperability problems and that a ``no'' answer would > mean that users see gobbledygook instead of non-ASCII glyphs, ignored > the question. > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > From owner-idn@ops.ietf.org Thu Mar 14 22:16:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10061 for ; Thu, 14 Mar 2002 22:16:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16li5N-000HC0-00 for idn-data@psg.com; Thu, 14 Mar 2002 19:08:53 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16li5L-000HBu-00 for idn@ops.ietf.org; Thu, 14 Mar 2002 19:08:52 -0800 Received: (qmail 9125 invoked by uid 1001); 15 Mar 2002 03:07:49 -0000 Date: 15 Mar 2002 03:07:49 -0000 Message-ID: <20020315030749.17206.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> <20020314211939.7658.qmail@cr.yp.to> <004301c1cbc2$e4badcf0$0a01000a@jamessonyviao> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk James Seng writes: > The email protests from Taiwan is not against the current set of drafts Liar. The people you're talking about wrote in response to your Last Call for IDNA. They told you that adopting IDNA would ``damage Internet community in China and Taiwan'' and that adopting IDNA would cause ``conflicts and chaos for Internet users of Han characters.'' I agree that these objections are based on particular deficiencies in the basic IDNA design decisions, and that other proposals with the same deficiencies would receive the same objections. So what? People are telling you that IDNA will damage the Internet community. You are saying that other proposals will damage the Internet community too. Don't you realize how stupid this sounds? The bottom line, once again, is that at least fifteen regular WG participants and _hundreds_ of other people have written messages to the IDN mailing list in opposition to IDNA. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Thu Mar 14 22:36:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11554 for ; Thu, 14 Mar 2002 22:36:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16liL8-000HTG-00 for idn-data@psg.com; Thu, 14 Mar 2002 19:25:10 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16liL7-000HSX-00 for idn@ops.ietf.org; Thu, 14 Mar 2002 19:25:09 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id DA6CFFFC07; Fri, 15 Mar 2002 11:23:31 +0800 (SGT) Message-ID: <007501c1cbd0$c57882d0$dd00a8c0@jamessonyviao> From: "James Seng" To: "D. J. Bernstein" , Cc: , , References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> <20020314211939.7658.qmail@cr.yp.to> <004301c1cbc2$e4badcf0$0a01000a@jamessonyviao> <20020315030749.17206.qmail@cr.yp.to> Subject: Re: [idn] WG last call summary Date: Fri, 15 Mar 2002 11:23:21 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > James Seng writes: > > The email protests from Taiwan is not against the current set of drafts > > Liar. Really? Do I need to response to this futher then? I mean, for what I say, to you is just a lie. *laugh*. Life would be so much better if everyone who disagree with you is a liar isn't it :-) -James Seng From owner-idn@ops.ietf.org Thu Mar 14 23:42:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12874 for ; Thu, 14 Mar 2002 23:42:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ljOK-000IV1-00 for idn-data@psg.com; Thu, 14 Mar 2002 20:32:32 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.35 #1) id 16ljOJ-000IUt-00 for idn@ops.ietf.org; Thu, 14 Mar 2002 20:32:31 -0800 Received: from [] (modemcable151.132-130-66.que.mc.videotron.ca [66.130.132.151]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g2F4tVa58426 for ; Thu, 14 Mar 2002 23:55:31 -0500 (EST) Date: Thu, 14 Mar 2002 23:31:48 -0500 From: Marc Blanchet To: idn@ops.ietf.org Subject: [idn] next steps and meeting Message-ID: <159160000.1016166708@localhost> X-Mailer: Mulberry/2.2.0b2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA12874 Few notes: - The co-chairs will be sending tomorrow to the ADs the request to advance the documents. - There is a current time slot for idn next week in Minneapolis. The chairs believe there is no need to meet. We will then resend back the slot to the secretariat for reallocation. Marc. ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-idn@ops.ietf.org Fri Mar 15 00:09:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13259 for ; Fri, 15 Mar 2002 00:09:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ljjS-000Ipc-00 for idn-data@psg.com; Thu, 14 Mar 2002 20:54:22 -0800 Received: from smtprelay2.dc3.adelphia.net ([24.50.78.5]) by psg.com with esmtp (Exim 3.35 #1) id 16ljjR-000IpW-00 for idn@ops.ietf.org; Thu, 14 Mar 2002 20:54:21 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.170]) by smtprelay2.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GT00AJ00.M14; Thu, 14 Mar 2002 23:54:19 -0500 Message-ID: <005a01c1cbdd$3d756800$aa424244@anhmca.adelphia.net> From: "Doug Ewell" To: Cc: "D. J. Bernstein" References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> <20020314211939.7658.qmail@cr.yp.to> <004301c1cbc2$e4badcf0$0a01000a@jamessonyviao> <20020315030749.17206.qmail@cr.yp.to> Subject: Re: [idn] WG last call summary Date: Thu, 14 Mar 2002 20:52: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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > Liar. Nice! And so professional, too. > The people you're talking about wrote in response to your Last > Call for IDNA. They told you that adopting IDNA would ``damage Internet > community in China and Taiwan'' and that adopting IDNA would cause > ``conflicts and chaos for Internet users of Han characters.'' Nobody was ever able to explain to me, anyway, how providing Chinese domain names in Han characters, but not mapping them between TC and SC, could possibly cause more damage, conflict, and chaos than forcing the Chinese to use ASCII, as the current system does. > The bottom line, once again, is that at least fifteen regular WG > participants and _hundreds_ of other people have written messages to the > IDN mailing list in opposition to IDNA. Identically worded chain letters don't count. It's the same thing when you write to your congressperson: they throw out the Xeroxed ones immediately. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Fri Mar 15 12:47:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05784 for ; Fri, 15 Mar 2002 12:47:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lveJ-0000y1-00 for idn-data@psg.com; Fri, 15 Mar 2002 09:37:51 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "D. J. Bernstein" Cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary Message-Id: Date: Fri, 15 Mar 2002 09:29:03 -0800 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit dan, for those of us out here who are mono-lingual honkeys, easily confused when we cross a county line, blah blah blan, could you give one *simple* *concrete* example of the failure mode you fear? and try not to use adjectives. thanks. randy From owner-idn@ops.ietf.org Fri Mar 15 14:38:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08050 for ; Fri, 15 Mar 2002 14:38:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lxPS-0002mS-00 for idn-data@psg.com; Fri, 15 Mar 2002 11:30:38 -0800 Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by psg.com with esmtp (Exim 3.35 #1) id 16lxPR-0002mM-00 for idn@ops.ietf.org; Fri, 15 Mar 2002 11:30:37 -0800 Received: from zetnet.co.uk (bts-0019.dialup.zetnet.co.uk [194.247.48.19]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g2FJUWZ12231 for ; Fri, 15 Mar 2002 19:30:32 GMT Message-ID: <3C924BD9.B13113F3@zetnet.co.uk> Date: Fri, 15 Mar 2002 19:30:33 +0000 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] Stop bickering and address the technical problems with IDNA (was: WG last call summary) References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> <20020314211939.7658.qmail@cr.yp.to> <004301c1cbc2$e4badcf0$0a01000a@jamessonyviao> <20020315030749.17206.qmail@cr.yp.to> <007501c1cbd0$c57882d0$dd00a8c0@jamessonyviao> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- James Seng wrote: > Dan Bernstein wrote: > > James Seng writes: > > > The email protests from Taiwan is not against the current set of drafts > > > > Liar. > > Really? Do I need to response to this futher then? > I mean, for what I say, to you is just a lie. *laugh*. It's completely ridiculous to claim that the protests were not against the current set of IDN drafts. Regardless of their technical merit, they were clearly directed at the current set of drafts. Claiming that they were not directed at IDNA specifically would be a red herring even if it were true: the last call is for all of the documents. There were objections on other issues as well, which you seem to have completely ignored. I'll talk about those in another post. It's obvious that several of the IDNA proponents have a personality clash with Bernstein, and it's also obvious that this is harming the standards process in this WG. *GET OVER IT*, and at least attempt to address his technical objections. Bernstein: *STOP INSULTING PEOPLE*; you're just giving them an excuse to ignore those objections. - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPJGstzkCAxeYt5gVAQHIugf/Y0gCoOPpjVqAksc9HCsI1d4dQBDhFU6I RdBQwYDJqNrzDlaT/E8J2AlVLuXOZ1iI/zW5JNplDB9eaAt/HnRKT6ld7uFYHt8f MBgIlJHBhpfH2kqgpOKuaTJlUfcMXGmIHsQuymxMfihrSfTCO5wvabb9HAMr9Z1J 6PgVYkivVxfh3HkzoDzapImAfgIA8X3TnzFKwazOM14+gk/tVUe2NGh6M4zllivG HM1nf6pJympV4DRUbKRwTix0elBVdKqmr2WDNN5xogRJoWDgMRdJTERm9fUGLWib lAwj1PrzssXMRTZfO9YcSMrTV7uzE6G4L/MLFDjI3QLOXOwHtf7mhA== =LD8R -----END PGP SIGNATURE----- From owner-idn@ops.ietf.org Fri Mar 15 16:09:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10446 for ; Fri, 15 Mar 2002 16:09:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lyl8-0003pX-00 for idn-data@psg.com; Fri, 15 Mar 2002 12:57:06 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.35 #1) id 16lyl7-0003pR-00 for idn@ops.ietf.org; Fri, 15 Mar 2002 12:57:05 -0800 Received: (qmail 7081 invoked by uid 1001); 15 Mar 2002 20:56:02 -0000 Date: 15 Mar 2002 20:56:02 -0000 Message-ID: <20020315205602.13559.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Randy Bush writes: > could you give one *simple* *concrete* example of the failure mode you > fear? I assume that by ``failure mode'' you're referring specifically to interoperability problems. Here's another example. The ezmlm-list program takes a local mailing-list name on its command line and sends the subscriber list to stdout. People use this program in two ways: (1) Displaying the results on the screen, for human consumption. For example, the ezmlm-list output is often piped to the standard ``less'' pager: ezmlm-list ~/sos | less (2) Feeding the results to another program. For example, people have shell scripts along the lines of #!/bin/sh ezmlm-list ~/sos | ( while read sub do echo ... | qmail-inject -- "$sub" done ) to send personalized email to all the subscribers. Under the IDNA deployment plan, names in the IDNA character encoding will start showing up in subscription lists immediately. Those names will be displayed as gobbledygook. The ezmlm-list author will be forced to have ezmlm-list convert addresses to the local character encoding. However, if ezmlm-list converts from the IDNA character encoding to the local character encoding, then the script shown above will break. Mail will bounce. That's an interoperability disaster. What is the ezmlm-list author supposed to do? How do we make IDNA work without encountering this failure? ``Disable the conversion by resetting LANG inside the shell script,'' you say? Yes, we could change the shell script to eliminate the problem. But that isn't under the control of the ezmlm-list author, and the IDNA deployment plan doesn't wait for it. Deliberately screwing up a user's email, and then telling him how to fix the problem, is not interoperability. It's sabotage. ``Upgrade qmail-inject to support IDNA,'' you say? Yes, I could change qmail-inject to convert addresses to the IDNA character encoding, and that would make the script work if the local character set is Unicode (encoded as UTF-8, presumably). But the IDNA deployment plan doesn't wait for that either. There is, of course, no safe order of package upgrades if IDNA is deployed immediately. For example, addresses are copied from web browsers to mail programs, and from mail programs back to web browsers. It's possible to eliminate the interoperability failures by upgrading _everything_, or by ugprading _nothing_. The problem is the transition. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Fri Mar 15 16:22:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10753 for ; Fri, 15 Mar 2002 16:22:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lz0q-00041B-00 for idn-data@psg.com; Fri, 15 Mar 2002 13:13:20 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "D. J. Bernstein" Cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary Message-Id: Date: Fri, 15 Mar 2002 13:07:15 -0800 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > It's possible to eliminate the interoperability failures by upgrading > _everything_, or by ugprading _nothing_. The problem is the transition. so, it sounds like the problem is not the proposed standard in question, but the lack of a transition plan without holes. shades of ipv6! so it sounds as if the wg is missing a work item. randy ps: i find your arrogant mail robots sufficiently annoying and abusive of my time that i will no longer be corresponding with you. oddly, we all think we're more important than everybody else. of course, none of us are. From owner-idn@ops.ietf.org Fri Mar 15 17:10:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11945 for ; Fri, 15 Mar 2002 17:10:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lzkq-0004a6-00 for idn-data@psg.com; Fri, 15 Mar 2002 14:00:52 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16lzkp-0004a0-00; Fri, 15 Mar 2002 14:00:51 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA31037; Fri, 15 Mar 2002 14:00:50 -0800 Message-Id: <5.1.0.14.2.20020315135529.0377ddb8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Mar 2002 13:59:55 -0800 To: Randy Bush From: Dave Crocker Subject: Re: [idn] WG last call summary Cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 01:07 PM 3/15/2002 -0800, Randy Bush wrote: >so it sounds as if the wg is missing a work item. Well, no, not really. The example given had nothing to do with Internet protocols, but rather with how to transition the software on a computer system to support a richer set of characters. That is, of course, an interesting problem, but it is not part of IETF scope. The transition issues for IDNA that actually pertain to Internet protocol behavior have been described repeatedly and are identical with the kind of changes that were required to adopt MIME. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Fri Mar 15 18:06:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13172 for ; Fri, 15 Mar 2002 18:06:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16m0dv-0005Iz-00 for idn-data@psg.com; Fri, 15 Mar 2002 14:57:47 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16m0du-0005IN-00 for idn@ops.ietf.org; Fri, 15 Mar 2002 14:57:46 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16m0du-0003R5-00 for ; Fri, 15 Mar 2002 14:57:46 -0800 Date: Fri, 15 Mar 2002 22:57:46 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] WG last call summary Message-ID: <20020315225745.GB12326@nicemice.net> Reply-To: IETF idn working group References: <20020315205602.13559.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020315205602.13559.qmail@cr.yp.to> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk ATTENTION all participants in this thread: Please think twice before you Cc ietf@ietf.org, iesg@ietf.org, and iab@isi.edu. They are probably getting annoyed with us by now. Once again, I've removed those addresses from the Cc field. "D. J. Bernstein" wrote: > The ezmlm-list program takes a local mailing-list name on its command > line and sends the subscriber list to stdout. The documentation for ezmlm-list says "ezmlm-list prints...one address per line." Clearly this is structured output designed to be machine-readable, so IDNA rule 1 applies (domain labels in generic domain name slots must contain only ASCII characters). The output is also intended to be human-readable, so IDNA rule 2 also applies (ACE labels should be hidden from users). But the IDNA spec says that when rules 1 and 2 both apply, rule 1 takes precedence. So ezmlm-list will not perform ACE-decoding, and the IDNs will appear as ACE gobbledygook. There are options available to both the user and the ezmlm-list author. For the user, the output of ezmlm-list is already ill-suited for display, because it's usually too long. That's why the user usually pipes it through a pager. Similarly, the user can pipe it through a program that performs ACE-decoding. This works without any changes to ezmlm-list. The ezmlm-list author, meanwhile, can add an option to ezmlm-list that changes the output format from "one address per line" to "one address per line possibly containing IDNs using the local charset". When this option is used, the output contains internationalized domain name slots, not generic domain name slots, so IDNA rule 1 no longer applies, and rule 2 can assert itself, and ezmlm-list will perform ACE-decoding. The output format can be selected by a combination of compile-time default, system-wide config file, user config file, environment variables, and/or command-line switches. (Another option available to the ezmlm-list author is to change the output format without making it selectable, which would be an incompatible change. That's probably not a good idea.) AMC From owner-idn@ops.ietf.org Fri Mar 15 19:55:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15000 for ; Fri, 15 Mar 2002 19:55:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16m2L1-0000cc-00 for idn-data@psg.com; Fri, 15 Mar 2002 16:46:23 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16m2L0-0000cS-00 for idn@ops.ietf.org; Fri, 15 Mar 2002 16:46:22 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 30339; Fri, 15 Mar 2002 18:45:43 -0600 Message-ID: <3C9295CC.774EAB36@ehsco.com> Date: Fri, 15 Mar 2002 18:46:05 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dave Crocker CC: Randy Bush , idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <5.1.0.14.2.20020315135529.0377ddb8@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave Crocker wrote: > The transition issues for IDNA that actually pertain to Internet > protocol behavior have been described repeatedly and are identical > with the kind of changes that were required to adopt MIME. I can see why you'd want to say that, but it's a poor analogy. MIME imposed structure on unstructured data by using a subset of values, and specifically limiting itself to particular technologies. I mean, even RFC2047 only allowed some particular kinds of data (mostly unstructured) to be extended, and marked structured data as off-limits. Conversely, IDNA modifies structured data-elements, and applies to all technologies. Resistance is futile, you will be transliterated. A much better analogy for IDNs in general is IPv6, where every participating protocol, data-element and application that uses the previous data-format has to be modified if it wants to use the new data-format. But since IDNA seeks to avoid these costs, in the end, the protocols, data-elements and applications don't actually obtain any real benefits from internationalization; it's all just a facade, taped onto the surface of the Internet, sometimes in harmful ways given the artifacts of mandatory transliteration. In this regard, the best analogy would be what IPv6 *DIDN'T* do: pass IPv6 inside of IPv4 options and call the work finished. That's pretty much what IDNA does. As for breakage, it will undoubtedly occur, including in those places that Dan mentions, but it will also happen inside protocols and namespaces. Message-IDs will absolutely get corrupted and reinserted into the messaging system, Kerberos and NetBIOS will get broken and then get panic fixes, etc. > The example given had nothing to do with Internet protocols, but rather > with how to transition the software on a computer system to support a > richer set of characters. That is, of course, an interesting problem, > but it is not part of IETF scope. Dan's argument is actually the easiest to deal with, since it can be addressed with the judicious and cautious use of "MAY" along with the appropriate warnings. Extending all known data-structures which happen to make use of DNS domain names as key elements is the larger problem, and it is certainly within the scope of the IETF. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri Mar 15 21:01:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15621 for ; Fri, 15 Mar 2002 21:01:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16m3MZ-0001Hd-00 for idn-data@psg.com; Fri, 15 Mar 2002 17:52:03 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16m3MY-0001HX-00 for idn@ops.ietf.org; Fri, 15 Mar 2002 17:52:02 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16m3MJ-0003t0-00 for ; Fri, 15 Mar 2002 17:51:47 -0800 Date: Sat, 16 Mar 2002 01:51:47 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] WG last call summary Message-ID: <20020316015146.GD12326@nicemice.net> Reply-To: IETF idn working group References: <5.1.0.14.2.20020315135529.0377ddb8@127.0.0.1> <3C9295CC.774EAB36@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C9295CC.774EAB36@ehsco.com> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk Once again I have removed ietf@ietf.org, iesg@ietf.org, and iab@isi.edu from the Cc list. "Eric A. Hall" wrote: > IDNA modifies structured data-elements IDNA is built around the core principle of *not* modifying existing structured data elements. IDNA requires that all domain names in existing structured data elements continue to be ASCII-only. Non-ASCII domain names may appear only in new structured data elements and in unstructured text and displays. AMC From owner-idn@ops.ietf.org Fri Mar 15 21:52:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16996 for ; Fri, 15 Mar 2002 21:52:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16m3xT-00005S-00 for idn-data@psg.com; Fri, 15 Mar 2002 18:30:11 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16m3xR-00003Q-00 for idn@ops.ietf.org; Fri, 15 Mar 2002 18:30:09 -0800 Received: (qmail 20921 invoked by uid 1001); 16 Mar 2002 02:21:34 -0000 Date: 16 Mar 2002 02:21:34 -0000 Message-ID: <20020316022134.9331.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Randy Bush writes: > so, it sounds like the problem is not the proposed standard in question, > but the lack of a transition plan without holes. shades of ipv6! No. IDNA is being proposed as something that new sites can use _right now_. In contrast, nobody is telling sites that they can rely on IPv6 for complete Internet service today. More importantly, IDNA is a set of changes without a long-term strategy. In contrast, specifying the desired final architecture is an explicit part of the IPv6 project; there are many documents along these lines, separate from the transition documents. There certainly isn't IDN WG consensus on IDNA as the long-term IDN solution. In fact, many of us suspect that there's consensus on the following statement, which implies that IDNA is merely temporary: The long-term IDN solution will encode Unicode characters as UTF-8 on the wire. The IDN WG chairs have repeatedly refused to run a straw poll on this statement, never mind actually settling all the other important details of what we're really trying to achieve! If we were faced with a document proposing IDNA as a long-term solution, I'd agree that the interoperability issues were only with the transition plan. It _is_ possible to make a world of multiple character encodings work correctly, even though it's remarkably bad software engineering. Of course, the lack of interoperability is only one of IDNA's problems. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Fri Mar 15 22:09:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17212 for ; Fri, 15 Mar 2002 22:09:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16m4RG-0000PO-00 for idn-data@psg.com; Fri, 15 Mar 2002 19:00:58 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16m4RF-0000PI-00; Fri, 15 Mar 2002 19:00:57 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2G30bt20565; Fri, 15 Mar 2002 22:00:37 -0500 (EST) Message-Id: <200203160300.g2G30bt20565@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Eric A. Hall" cc: Dave Crocker , Randy Bush , idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary In-reply-to: (Your message of "Fri, 15 Mar 2002 18:46:05 CST.") <3C9295CC.774EAB36@ehsco.com> Date: Fri, 15 Mar 2002 22:00:37 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > > The transition issues for IDNA that actually pertain to Internet > > protocol behavior have been described repeatedly and are identical > > with the kind of changes that were required to adopt MIME. > > I can see why you'd want to say that, but it's a poor analogy. > > MIME imposed structure on unstructured data by using a subset of values, > and specifically limiting itself to particular technologies. I mean, even > RFC2047 only allowed some particular kinds of data (mostly unstructured) > to be extended, and marked structured data as off-limits. more precisely, RFC 2047 was intended only for human-readable text, because at the time we hadn't figured out how to solve the various problems associated with having multiple representations of machine-readable text. today we have a much better idea for how to do that. I agree with Dave that IDNA is very similar to things we did with MIME in both the header and the message body, and I think the experience with MIME will be a good predictor of experience with IDNA. Keith From owner-idn@ops.ietf.org Fri Mar 15 23:00:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19044 for ; Fri, 15 Mar 2002 22:59:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16m5HJ-00014S-00 for idn-data@psg.com; Fri, 15 Mar 2002 19:54:45 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16m5HJ-00014J-00 for idn@ops.ietf.org; Fri, 15 Mar 2002 19:54:45 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 30359; Fri, 15 Mar 2002 21:54:06 -0600 Message-ID: <3C92C1F3.20D16DBB@ehsco.com> Date: Fri, 15 Mar 2002 21:54:27 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Keith Moore CC: Dave Crocker , Randy Bush , idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <200203160300.g2G30bt20565@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > because at the time we hadn't figured out how to solve the various > problems associated with having multiple representations of > machine-readable text. > > today we have a much better idea for how to do that. At least IDNA only has one conversion form. Still, the point is valid that something as precise and scope-limited as 2047 only worked well within the scope it was intended for, namely presentation of unstructured header fields within a specific service. I mean, I don't know of any email clients that perform 2047 encoding on search string input, do you? > I agree with Dave that IDNA is very similar to things we did with MIME > in both the header and the message body The notion of transliterate-for-display-so-we-don't-upgrade is similar, but the scopes are completely different. If you are using a 2047-capable email client, copy-n-paste between From: and To: is practically guaranteed to work out. But all IDN approaches introduce copy-n-paste between web browsers, email clients, WHOIS clients, ad nauseum. That also introduces all kinds of other issues, like, "is that i18n URL I copied actually a legal URL? [not today, no]" That's why this is closer to IPv6 than MIME. Just to be clear, my position on this subject remains that IDNA is a necessary and useful transfer encoding for legacy systems that need access to i18n domain name data, but that the mandatory transliteration of all domain names as any kind of solution to the problem is just reckless. These problems won't go away until they are accepted and designed for. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri Mar 15 23:56:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20163 for ; Fri, 15 Mar 2002 23:56:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16m698-0001eh-00 for idn-data@psg.com; Fri, 15 Mar 2002 20:50:22 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16m697-0001eb-00; Fri, 15 Mar 2002 20:50:21 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2G4o3t21033; Fri, 15 Mar 2002 23:50:03 -0500 (EST) Message-Id: <200203160450.g2G4o3t21033@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Eric A. Hall" cc: Keith Moore , Dave Crocker , Randy Bush , idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary In-reply-to: (Your message of "Fri, 15 Mar 2002 21:54:27 CST.") <3C92C1F3.20D16DBB@ehsco.com> Date: Fri, 15 Mar 2002 23:50:03 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > > because at the time we hadn't figured out how to solve the various > > problems associated with having multiple representations of > > machine-readable text. > > > > today we have a much better idea for how to do that. > > At least IDNA only has one conversion form. Still, the point is valid that > something as precise and scope-limited as 2047 only worked well within the > scope it was intended for, namely presentation of unstructured header > fields within a specific service. I mean, I don't know of any email > clients that perform 2047 encoding on search string input, do you? No, but that would be a really lousy way to implement searching for non-ASCII text in message headers. If I were implementing such a search function, I'd build an index of decoded and canonicalized header text rather than trying to match the query string against the 2047 encoding. > > I agree with Dave that IDNA is very similar to things we did with MIME > > in both the header and the message body > > The notion of transliterate-for-display-so-we-don't-upgrade is similar, > but the scopes are completely different. If you are using a 2047-capable > email client, copy-n-paste between From: and To: is practically guaranteed > to work out. But all IDN approaches introduce copy-n-paste between web > browsers, email clients, WHOIS clients, ad nauseum. Copy and paste is also an issue for 2047. The only difference is that since 2047 doesn't apply to addresses, but only to human-readable text, a transliteration bug is less likely to cause your mail to go to the wrong address. But such bugs do sometimes cause names or subjects to be garbled. But there are copy-and-paste issues even for ASCII URLs, due to %-encoding (if you're copying from a poorly "decoded" form of the URL) and line wrapping. Perhaps in hindsight URLs could have been designed differently. But with so many people writing so many implementations of things that handle URLs, subtleties tend to get overlooked by large numbers of implementors. That's also the worst problem with doing IDNs, but it would exist no matter what scheme were chosen. Keith From owner-idn@ops.ietf.org Sat Mar 16 09:08:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03785 for ; Sat, 16 Mar 2002 09:08:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mEeL-0007r0-00 for idn-data@psg.com; Sat, 16 Mar 2002 05:55:09 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16mEeK-0007qt-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 05:55:08 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id FAA26648; Sat, 16 Mar 2002 05:55:08 -0800 Message-Id: <5.1.0.14.2.20020316055059.02c87420@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 16 Mar 2002 05:54:58 -0800 To: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu From: Dave Crocker Subject: Re: [idn] WG last call summary In-Reply-To: <200203160450.g2G4o3t21033@astro.cs.utk.edu> References: <(Your message of "Fri, 15 Mar 2002 21:54:27 CST.") <3C92C1F3.20D16DBB@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk >No, but that would be a really lousy way to implement searching for >non-ASCII text in message headers. If I were implementing such Indeed. The reference to searching nicely underscores that this entire thread pertains to local implementation issues, rather than having anything at all to do with the DNS. The DNS does not have searching. And with respect to the comparison with MIME, IDNA lays a specialized character format onto an existing string environment, thereby requiring change only for participants that which to enjoy the new feature. It requires no change to the infrastructure and has no impact on non-participating DNS entities. That is the architectural basis for comparing IDNA to MIME. In other words, folks, this entire thread is caused by misunderstandings of the difference between protocol and implementation. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sat Mar 16 09:19:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03966 for ; Sat, 16 Mar 2002 09:19:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mEsN-00082H-00 for idn-data@psg.com; Sat, 16 Mar 2002 06:09:39 -0800 Received: from nod.reston.mci.net ([166.60.6.38]) by psg.com with esmtp (Exim 3.35 #1) id 16mEsM-00082A-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 06:09:38 -0800 Received: from vint.wcom.com ([68.5.48.223]) by shoe.reston.mci.net (PMDF V6.1-1 #39689) with ESMTPA id <01KFF8N1TPW690MURA@shoe.reston.mci.net> for idn@ops.ietf.org; Sat, 16 Mar 2002 09:09:37 -0500 (EST) Date: Fri, 15 Mar 2002 13:13:27 -0500 From: vint cerf Subject: Re: [idn] WG last call summary In-reply-to: <005a01c1cbdd$3d756800$aa424244@anhmca.adelphia.net> X-Sender: vcerf@shoe.reston.mci.net To: Doug Ewell , idn@ops.ietf.org Cc: "D. J. Bernstein" Message-id: <5.0.2.1.2.20020315130807.02652198@shoe.reston.mci.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> <20020314211939.7658.qmail@cr.yp.to> <004301c1cbc2$e4badcf0$0a01000a@jamessonyviao> <20020315030749.17206.qmail@cr.yp.to> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT with regard to the operation of registries, it occurs to me that TC/SC equivalences create a signficant burden on registration - will any registration of a sequence of such characters result in the implicit registration of a potentially large equivalence class of strings made up of substitutions of SC for TC or TC for SC in all possible combinations? What about the matching question? Will a canonical form be required that is in some sense the "generator" of the equivalence class of all variations in TC/SC spellings? Apologies if the above is overly cryptic. I do not claim to be fully cognizant of all the debate that has occurred on this subject, so perhaps this problem has already been dealt with - assuming the terse description above is sufficiently understandable to describe a known (and solved?) problem. Vint Cerf At 08:52 PM 3/14/2002 -0800, Doug Ewell wrote: >Nobody was ever able to explain to me, anyway, how providing Chinese >domain names in Han characters, but not mapping them between TC and SC, >could possibly cause more damage, conflict, and chaos than forcing the >Chinese to use ASCII, as the current system does. From owner-idn@ops.ietf.org Sat Mar 16 10:56:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05139 for ; Sat, 16 Mar 2002 10:56:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mGSo-00095B-00 for idn-data@psg.com; Sat, 16 Mar 2002 07:51:22 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16mGSn-000955-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 07:51:21 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2GFpKt16503; Sat, 16 Mar 2002 10:51:20 -0500 (EST) Message-Id: <200203161551.g2GFpKt16503@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary In-reply-to: (Your message of "16 Mar 2002 02:21:34 GMT.") <20020316022134.9331.qmail@cr.yp.to> Date: Sat, 16 Mar 2002 10:51:20 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > There certainly isn't IDN WG consensus on IDNA as the long-term IDN > solution. In fact, many of us suspect that there's consensus on the > following statement, which implies that IDNA is merely temporary: > > The long-term IDN solution will encode Unicode characters as UTF-8 on > the wire. I doubt we'd reach consensus on that either, since many of us suspect that the following statement is closer to the truth: The on-the-wire encoding of IDNs is irrelevant; what matters is the behavior experienced by users. Keith From owner-idn@ops.ietf.org Sat Mar 16 12:34:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06617 for ; Sat, 16 Mar 2002 12:34:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mHac-0009oN-00 for idn-data@psg.com; Sat, 16 Mar 2002 09:03:30 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16mHab-0009nY-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 09:03:29 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 30450; Sat, 16 Mar 2002 11:01:32 -0600 Message-ID: <3C937A80.A9CF488F@ehsco.com> Date: Sat, 16 Mar 2002 11:01:53 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Keith Moore CC: "D. J. Bernstein" , idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <200203161551.g2GFpKt16503@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > I doubt we'd reach consensus on that either, since many of us suspect > that the following statement is closer to the truth: > > The on-the-wire encoding of IDNs is irrelevant; what matters is the > behavior experienced by users. Obviously. It's a question of getting there, however. The final, ultimate argument in this logic-chain is that native representation of the data in the protocol message is the ultimate design solution, since it means less implementation work, fewer errors introduced by wayward codecs, highest reusability by other services, etc. Managed facades are not long-term solutions to anything, and in fact, tend to introduce as many problems as they try to fix. Obviously, direct encapsulation is harder with some services than others. That doesn't mean that direct encapsulation should not be the ultimate design target, it only means that some protocols will have to use a patch (like IDNA) until they can either be extended or replaced. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Mar 16 13:12:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07180 for ; Sat, 16 Mar 2002 13:12:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mI6C-000ABj-00 for idn-data@psg.com; Sat, 16 Mar 2002 09:36:08 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16mI6B-000A9z-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 09:36:07 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 30451; Sat, 16 Mar 2002 11:34:14 -0600 Message-ID: <3C93822B.23CA2C25@ehsco.com> Date: Sat, 16 Mar 2002 11:34:35 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dave Crocker CC: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <(Your message of "Fri, 15 Mar 2002 21:54:27 CST.") <3C92C1F3.20D16DBB@ehsco.com> <5.1.0.14.2.20020316055059.02c87420@127.0.0.1> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Dave Crocker wrote: > The reference to searching nicely underscores that this entire thread > pertains to local implementation issues, "Searching" in the context of RFC2047 doesn't just apply to local issues. Consider that IMAP SEARCH and NNTP XPAT both provide protocol mechanisms to search server-based data. However, I don't know of any clients that convert "ë" to "=EB" for those searches. That's partly a local issue, but it is also a protocol issue, and in the end it is also a service-wide issue. At some point, somebody has to say "okay we either mandate back-end conversion to allow for unencoded searches or we mandate encoded search behavior." Globally, it is a user-interaction issue, where the facade failed, due to the lack of direct integration. This same kind of issue will apply equally to searches for an "ë" that is embedded into a domain name component of an email address, and which has been ACE-encoded. There are multiple secondary considerations here as well. Searching for a single "ë" that has been encoded with ACE is not as simple as searching for an "=EB" sequence with 2047, for example. I dare say that substring searches are likely to prove impossible with ACE-encoded strings. Anyway, clearly these aren't just local implementation issues. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Mar 16 13:31:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07445 for ; Sat, 16 Mar 2002 13:31:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mIBF-000AFo-00 for idn-data@psg.com; Sat, 16 Mar 2002 09:41:21 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16mIBE-000ADz-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 09:41:20 -0800 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA00339; Sat, 16 Mar 2002 09:39:35 -0800 Message-Id: <5.1.0.14.2.20020316093357.03148fb8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 16 Mar 2002 09:38:22 -0800 To: "Eric A. Hall" From: Dave Crocker Subject: Re: [idn] WG last call summary Cc: idn@ops.ietf.org In-Reply-To: <3C937A80.A9CF488F@ehsco.com> References: <200203161551.g2GFpKt16503@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:01 AM 3/16/2002 -0600, Eric A. Hall wrote: >Obviously. It's a question of getting there, however. Not necessarily. UTF-8 is an encoding. IDNA uses an encoding. Neither is a "native" representation of the semantics. Given the tiny length of the strings involved, the relative differences between UTF-8 and the approach taken in IDNA is essentially irrelevant. Note that we are approaching the 10th anniversary of MIME, which involves much larger strings, and there is still no strong pressure for system-wide use of "pure" binary encoding. It exists and is used, but it is not the dominant encoding method, nor are users particularly aware of when it is being used. d/ ps. after this many years, it has become amusing to watch anyone make a firm prediction about the world's technical future. ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sat Mar 16 13:32:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07459 for ; Sat, 16 Mar 2002 13:32:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mIH6-000AKk-00 for idn-data@psg.com; Sat, 16 Mar 2002 09:47:24 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16mIH5-000AJF-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 09:47:23 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 30466; Sat, 16 Mar 2002 11:46:12 -0600 Message-ID: <3C9384F9.1C3C6C8D@ehsco.com> Date: Sat, 16 Mar 2002 11:46:33 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dave Crocker CC: idn@ops.ietf.org Subject: Re: [idn] WG last call summary References: <(Your message of "Fri, 15 Mar 2002 21:54:27 CST.") <3C92C1F3.20D16DBB@ehsco.com> <5.1.0.14.2.20020316055059.02c87420@127.0.0.1> <5.1.0.14.2.20020316094102.01b27f30@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave Crocker wrote: > Neither of them have anything to do with the DNS. IDNA isn't just about DNS. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Mar 16 13:33:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07491 for ; Sat, 16 Mar 2002 13:33:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mIUj-000AWA-00 for idn-data@psg.com; Sat, 16 Mar 2002 10:01:29 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.35 #1) id 16mIUi-000AV5-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 10:01:28 -0800 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E78766238F; Sat, 16 Mar 2002 18:59:57 +0100 (CET) Date: Sat, 16 Mar 2002 11:56:01 -0600 From: Harald Tveit Alvestrand To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@ISI.EDU Subject: Re: [idn] WG last call summary Message-ID: <1108844013.1016279761@localhost> In-Reply-To: <20020316022134.9331.qmail@cr.yp.to> References: <20020316022134.9331.qmail@cr.yp.to> X-Mailer: Mulberry/2.2.0b2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 16. mars 2002 02:21 +0000 "D. J. Bernstein" wrote: > There certainly isn't IDN WG consensus on IDNA as the long-term IDN > solution. In fact, many of us suspect that there's consensus on the > following statement, which implies that IDNA is merely temporary: > > The long-term IDN solution will encode Unicode characters as UTF-8 on > the wire. > If this was reformulated as The long-term IDN solution will not use DNS it would have my vote. From owner-idn@ops.ietf.org Sat Mar 16 13:39:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07626 for ; Sat, 16 Mar 2002 13:39:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mIUj-000AWC-00 for idn-data@psg.com; Sat, 16 Mar 2002 10:01:29 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.35 #1) id 16mIUi-000AUn-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 10:01:28 -0800 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4EDB6622B1; Sat, 16 Mar 2002 18:59:53 +0100 (CET) Date: Sat, 16 Mar 2002 11:52:02 -0600 From: Harald Tveit Alvestrand To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary Message-ID: <1108604909.1016279522@localhost> In-Reply-To: <20020315205602.13559.qmail@cr.yp.to> References: <20020315205602.13559.qmail@cr.yp.to> X-Mailer: Mulberry/2.2.0b2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 15. mars 2002 20:56 +0000 "D. J. Bernstein" wrote: > Under the IDNA deployment plan, names in the IDNA character encoding > will start showing up in subscription lists immediately. Those names > will be displayed as gobbledygook. The ezmlm-list author will be forced > to have ezmlm-list convert addresses to the local character encoding. > > However, if ezmlm-list converts from the IDNA character encoding to the > local character encoding, then the script shown above will break. Mail > will bounce. That's an interoperability disaster. under the scenario dan presents: 1) upgrading the qmail-inject program to support encoding will do no harm. Anything that will be changed by encoding was an illegal email address under the old rules. 2) upgrading both ezmlm-list and qmail-inject does no harm in the scenario given. thus, I think the defensive behaviour for ezmlm-list is to implement a switch: ezmlm-list --yes-I-have-really-upgraded-the-thing-that-will-read-this-to-understand-em ail-addresses-with-utf-8-characters-in-them given that in the endgame of essentially all programs being upgraded to undestand UTF-8 email addresses, this switch will be a bother, it should probably be capable of being specified in a configuration file, so that it can be left on and negated when needed. 3) contrary to some beliefs, watching gobbledygook is not known to cause permanent damage in human beings. So not upgrading anything does not cause much harm either. 4) yes, I do agree that specifying this level of behaviour is out of scope for the IETF. Harald From owner-idn@ops.ietf.org Sat Mar 16 13:43:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07684 for ; Sat, 16 Mar 2002 13:43:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mIH5-000AKi-00 for idn-data@psg.com; Sat, 16 Mar 2002 09:47:23 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16mIH4-000AJF-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 09:47:22 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 30459; Sat, 16 Mar 2002 11:45:29 -0600 Message-ID: <3C9384CE.F9E9171A@ehsco.com> Date: Sat, 16 Mar 2002 11:45:50 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dave Crocker CC: idn@ops.ietf.org Subject: Re: [idn] WG last call summary References: <200203161551.g2GFpKt16503@astro.cs.utk.edu> <5.1.0.14.2.20020316093357.03148fb8@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave Crocker wrote: > UTF-8 is an encoding. IDNA uses an encoding. Neither is a "native" > representation of the semantics. If all of the inputs and outputs are using UTF-8, then UTF-8 on-the-wire is about as close as you can get to a direct representation. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Mar 16 13:46:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07714 for ; Sat, 16 Mar 2002 13:46:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mIFP-000AJ2-00 for idn-data@psg.com; Sat, 16 Mar 2002 09:45:39 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16mIFO-000AHZ-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 09:45:38 -0800 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA00461; Sat, 16 Mar 2002 09:43:54 -0800 Message-Id: <5.1.0.14.2.20020316094102.01b27f30@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 16 Mar 2002 09:43:43 -0800 To: "Eric A. Hall" From: Dave Crocker Subject: Re: [idn] WG last call summary Cc: idn@ops.ietf.org In-Reply-To: <3C93822B.23CA2C25@ehsco.com> References: <(Your message of "Fri, 15 Mar 2002 21:54:27 CST.") <3C92C1F3.20D16DBB@ehsco.com> <5.1.0.14.2.20020316055059.02c87420@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:34 AM 3/16/2002 -0600, Eric A. Hall wrote: >Dave Crocker wrote: > > > The reference to searching nicely underscores that this entire thread > > pertains to local implementation issues, > >"Searching" in the context of RFC2047 doesn't just apply to local issues. >Consider that IMAP SEARCH and NNTP XPAT Neither of them have anything to do with the DNS. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sat Mar 16 17:10:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09981 for ; Sat, 16 Mar 2002 17:10:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mM8V-000DUd-00 for idn-data@psg.com; Sat, 16 Mar 2002 13:54:47 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16mM8V-000DTJ-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 13:54:47 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2GLr0t07850; Sat, 16 Mar 2002 16:53:00 -0500 (EST) Message-Id: <200203162153.g2GLr0t07850@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Eric A. Hall" cc: Keith Moore , idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary In-reply-to: (Your message of "Sat, 16 Mar 2002 11:01:53 CST.") <3C937A80.A9CF488F@ehsco.com> Date: Sat, 16 Mar 2002 16:53:00 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > > I doubt we'd reach consensus on that either, since many of us suspect > > that the following statement is closer to the truth: > > > > The on-the-wire encoding of IDNs is irrelevant; what matters is the > > behavior experienced by users. > > Obviously. It's a question of getting there, however. > > The final, ultimate argument in this logic-chain is that native > representation of the data in the protocol message is the ultimate design > solution, since it means less implementation work, fewer errors introduced > by wayward codecs, highest reusability by other services, etc. Managed > facades are not long-term solutions to anything, and in fact, tend to > introduce as many problems as they try to fix. Every single one of the above arguments is highly dubious. First, it's naive to assume that UTF-8 will be the native representation on everybody's platform - it has a number of nice properties but it's far from clear that everybody is going to drop what they're doing now to support it. Second, the portion of IDNA that does ASCII encoding is such a trivial bit of code that the number of failures introduced by that code will pale in comparison to those introduced by the other code needed to handle 10646 (normalization, etc) which would be needed no matter what encoding were used. Third, your statement about "managed facades" is a gross over-generalization. Numerous examples demonstrate that transition issues are often paramount in determining whether a new technology can succeed. Simplicity is often a virtue, but IDN is inherently complex - it reflects the tremendous variety in the world's languages and writing systems. And blind faith in some vague notion of cleanliness is a poor substitute for engineering analysis. Having said that, I'm all for having an alternate method to do UTF-8 queries on-the-wire, provided it produces consistent results with the IDNA queries, with similar efficiency and reliability. But the need to allow incremental upgrade of legacy application components strongly compels IDNA, and the incremental benefit of a native UTF-8 query interface beyond that of IDNA does not appear to justify the additional complexity. Nor does it justify delaying approval of IDNA. Most of the problems that are anticipated with IDNA - including the various kinds of transcription problems - will occur no matter what encoding is used for on-the-wire queries. Keith From owner-idn@ops.ietf.org Sat Mar 16 19:37:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12034 for ; Sat, 16 Mar 2002 19:37:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mOHH-000F5l-00 for idn-data@psg.com; Sat, 16 Mar 2002 16:11:59 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16mOHG-000F4Y-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 16:11:58 -0800 Received: (qmail 9093 invoked by uid 1001); 17 Mar 2002 00:09:25 -0000 Date: 17 Mar 2002 00:09:25 -0000 Message-ID: <20020317000925.19128.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <20020316022134.9331.qmail@cr.yp.to> <200203161551.g2GFpKt16503@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Users suffer every day from the current character-encoding mess. Anyone who ventures beyond ASCII is faced with endless trouble. There's no theoretical obstacle to making multiple character encodings work---make sure that there is, implicitly or explicitly, a perfectly clear character encoding for every byte stream; make sure that every copy and comparison includes all necessary conversions---but in practice this is a disaster. It's too much work to specify the encodings. It's far too much work to program all the necessary conversions. Look at IDNA. Yet another character encoding. An amazingly unclear specification of which byte streams are supposed to use that encoding. Massive redeployment of, at a minimum, every web browser in the world. And that's just for domain names! Is every worldwide identifier---for example, mailbox names---supposed to have its own massive upgrade? UTF-8 offers a way out of this mess. We do _one_ upgrade to make sure that UTF-8 works everywhere. For example, RFC 2277, IETF Policy on Character Sets and Languages, requires UTF-8 support in all protocols. Then we convert all stored data to UTF-8. Then, finally, we can drop support for the other character encodings. Do we want programmers in twenty years to be faced with the same mess that we have today? Or do we want them focusing on positive features for the users? Keith Moore writes: > The on-the-wire encoding of IDNs is irrelevant; what matters is the > behavior experienced by users. Everything is judged by the user experience, yes, but you are clearly incorrect in saying that the encoding is irrelevant. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Sat Mar 16 20:17:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12932 for ; Sat, 16 Mar 2002 20:17:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mOyQ-000Fc6-00 for idn-data@psg.com; Sat, 16 Mar 2002 16:56:34 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16mOyP-000FbT-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 16:56:33 -0800 Received: (qmail 29578 invoked by uid 1001); 17 Mar 2002 00:52:02 -0000 Date: 17 Mar 2002 00:52:02 -0000 Message-ID: <20020317005202.8134.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <20020315205602.13559.qmail@cr.yp.to> <1108604909.1016279522@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Harald Tveit Alvestrand writes: > 3) contrary to some beliefs, watching gobbledygook is not known to cause > permanent damage in human beings. Internationalized domain names are a failure if non-ASCII glyphs don't appear on the screen. Have you completely lost sight of the goal here? The interoperability problems begin when IDNA gobbledygook is converted to the local character encoding for display. If the result is copied to another program---through pipes, copy-and-paste, whatever---then that program's lookups will fail. Mail will bounce, web links will fail, etc. The conversions I'm talking about are specified in the IDNA documents. They will produce interoperability problems visible on the wire. You are incorrect in saying that this is outside the IETF's scope. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Sat Mar 16 21:07:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13972 for ; Sat, 16 Mar 2002 21:07:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mPi7-000GA8-00 for idn-data@psg.com; Sat, 16 Mar 2002 17:43:47 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16mPi6-000G8i-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 17:43:46 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 30539; Sat, 16 Mar 2002 19:41:52 -0600 Message-ID: <3C93F475.5F26AAF8@ehsco.com> Date: Sat, 16 Mar 2002 19:42:13 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Keith Moore CC: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <200203162153.g2GLr0t07850@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > First, it's naive to assume that UTF-8 will be the native > representation on everybody's platform Clarification. I did not say anything about UTF-8 on platforms, but instead cited native representation in protocol messages. However, if UTF-8 is the encoding of choice for a particular protocol's data or message formats, then we know that UTF-8 is also going to be incorporated into the necessary supporting functions at the participating end-points. This doesn't mean that the whole box has to use UTF-8. Frankly, I don't even think that's relevant. Instead, it is a question of whether or not the related components (searching, as in the previous example) will be likely to deal with UTF-8, rather than having to selectively graft an exraneous encoding into select portions of that service in order to provide simple functionality (as with 2047 and searching, again). But this is also entirely irrelevant. By your argument that the transfer encoding is irrelevant, I would like to hear your arguments as to how, say, using EBCDIC to pass ASCII data around could possibly be seen as reasonable design. Of course the native encodings are always best. The fact that most of the apps are heading towards UTF-8 should tell us that we should be designing for a long-term support infrastructure that provides the data in the format it is going to be used in. Furthermore, whenever the remaining services get upgraded or replaced, they should be able to use something a little better than the best technology that 1968 money can buy. > Second, the portion of IDNA that does ASCII encoding is such a trivial > bit of code that the number of failures introduced by that code will > pale in comparison to those introduced by the other code needed to > handle 10646 (normalization, etc) which would be needed no matter what > encoding were used. Getting new problems in addition to shared problems is hardly an argument in your favor. You've already conceded that 2047 has some problems with transliteration goofiness, and that restricting it to unstructured data limits the real damage that is caused. Are we to believe that extending structured data with mandatory transliteration will not cause the problems you thankfully avoided? > Numerous examples demonstrate that transition issues are often > paramount in determining whether a new technology can succeed. I agree that transitional services are important. I also think that the evidence shows that end-station layering works well when existing formats are used as carriers for *subsets*, and when it is targeted to a specific usage. That isn't what's being done here, though. Instead, well-known and commmonly-used data-types will get *extended* into broader and incompatible forms by default, and it will happen purposefully and accidentally. This is not transitional probing, it is knowing that stuff will break and doing it anyway. Cripes, why do we have to do it all in a big-bang? Can't we start with the transfer encoding (no required upgrades for anything), incrementally add transliteration where we know it will be safe and robust (some upgrades), and then add UTF-8 for those newer services that can make use of it (some more upgrades)? What is the problem with this? > Simplicity is often a virtue, but IDN is inherently complex - it > reflects the tremendous variety in the world's languages and > writing systems. And blind faith in some vague notion of > cleanliness is a poor substitute for engineering analysis. That's almost a fair shot. I do put a bunch of faith into transparent data-types and structures. Dunno about "blind". ASCII is always best when it's encoded as ASCII, after all. > reliability. But the need to allow incremental upgrade of > legacy application components strongly compels IDNA, and the > incremental benefit of a native UTF-8 query interface beyond > that of IDNA does not appear to justify the additional complexity. The complexity required for a direct UTF-8 name-resolution service in conjunction with simple passthru-everywhere is minor in comparison to the complexity of transliterate-everywhere. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Mar 16 22:33:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17289 for ; Sat, 16 Mar 2002 22:33:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mR7A-000HEf-00 for idn-data@psg.com; Sat, 16 Mar 2002 19:13:44 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16mR79-000HDj-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 19:13:43 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16mR5g-0006py-00 for ; Sat, 16 Mar 2002 19:12:12 -0800 Date: Sun, 17 Mar 2002 03:12:12 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] WG last call summary Message-ID: <20020317031212.GA25841@nicemice.net> Reply-To: IETF idn working group References: <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> <20020314211939.7658.qmail@cr.yp.to> <004301c1cbc2$e4badcf0$0a01000a@jamessonyviao> <20020315030749.17206.qmail@cr.yp.to> <5.0.2.1.2.20020315130807.02652198@shoe.reston.mci.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.0.2.1.2.20020315130807.02652198@shoe.reston.mci.net> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk vint cerf wrote: > it occurs to me that TC/SC equivalences create a signficant burden on > registration - will any registration of a sequence of such characters > result in the implicit registration of a potentially large equivalence > class of strings made up of substitutions of SC for TC or TC for SC > in all possible combinations? What about the matching question? Will > a canonical form be required that is in some sense the "generator" of > the equivalence class of all variations in TC/SC spellings? It's up to the registries how to handle this. One approach is to prohibit mixed TC/SC labels. When someone tried to register such a name, registrars could suggest the pure TC and SC equivalents. If many registries adopt the same rules for which labels are allowed, applications could assist users who type disallowed labels, offering pure TC and SC suggestions. Another approach would be to define equivalence classes and register whole classes as a unit. Implementation tricks could be played to use computation in the DNS servers instead of large tables, if desired. This would cause each host to have many names, which would help some things and complicate others. These two approaches could be combined: You register a whole class (so that no one else can use any name in the class), and then it's your choice whether the DNS servers answer for all members of the class, or only for a few select members of the class. This might be the best of both worlds. And of course another approach would be to do nothing, and allow each TC/SC variant to be registered independently. AMC From owner-idn@ops.ietf.org Sat Mar 16 22:36:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17316 for ; Sat, 16 Mar 2002 22:36:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mRFt-000HLF-00 for idn-data@psg.com; Sat, 16 Mar 2002 19:22:45 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16mRFt-000HKD-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 19:22:45 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2H3Kut09298; Sat, 16 Mar 2002 22:20:57 -0500 (EST) Message-Id: <200203170320.g2H3Kut09298@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Eric A. Hall" cc: Keith Moore , idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary In-reply-to: (Your message of "Sat, 16 Mar 2002 19:42:13 CST.") <3C93F475.5F26AAF8@ehsco.com> Date: Sat, 16 Mar 2002 22:20:56 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > This doesn't mean that the whole box has to use UTF-8. Frankly, I don't > even think that's relevant. Instead, it is a question of whether or not > the related components (searching, as in the previous example) will be > likely to deal with UTF-8, rather than having to selectively graft an > exraneous encoding into select portions of that service in order to > provide simple functionality (as with 2047 and searching, again). again, the effort to get the ASCII encoding right is trivial compared to the effort required to do string comparisons in a way that's effective for searches. > But this is also entirely irrelevant. By your argument that the transfer > encoding is irrelevant, I would like to hear your arguments as to how, > say, using EBCDIC to pass ASCII data around could possibly be seen as > reasonable design. it would be quite reasonable for applications that already had a deeply-wired assumption that character strings were in EBCDIC. Which is why on BITNET and related networks, the applications generally exchanged data in EBCDIC even between ASCII-native hosts. > Of course the native encodings are always best. utter hogwash. first, there is no single "native" encoding of UCS, second; there's no encoding of IDNs that is native to the vast majority of deployed applications. > The fact that most of the apps are heading towards UTF-8 should tell us > that we should be designing for a long-term support infrastructure that > provides the data in the format it is going to be used in. again, that's hogwash, because it completely ignores issues associated with transitioning existing apps and/or with maintaining multiple interfaces to DNS. > Furthermore, > whenever the remaining services get upgraded or replaced, they should be > able to use something a little better than the best technology that 1968 > money can buy. that's like saying that now that we have automobiles, we should completely rearrange all of those cities that were designed on a walking scale, that we should change the width of roads so that they're more appropriate for motor-driven vehicles than horse-driven vehicles, etc. the fact is that once conventions get established, it's often more effecient overall to stick with a convention that is sub-optimal than it is to rebuild everything to be optimized for current conditions - particularly when those conditions will probably change again anyway. (e.g. it's much easier to build mass transit for cities designed on a walking scale...commuting by automobile sucks!) if and when the rest of the protocol uses UTF-8, then the worst that happens is that there's an extra layer of encoding that happens before a DNS query is sent. it's isolated to a single routine. it's not going to hurt enough to matter. and having the client do encoding prior to lookup is less complex than the extra cruft that's required to take advantage of having two kinds of DNS queries without introducing a significant new source of failures or delays. like I said, blind faith in cleanliness is no substitute for analysis. > > Second, the portion of IDNA that does ASCII encoding is such a trivial > > bit of code that the number of failures introduced by that code will > > pale in comparison to those introduced by the other code needed to > > handle 10646 (normalization, etc) which would be needed no matter what > > encoding were used. > > Getting new problems in addition to shared problems is hardly an argument > in your favor. no, but you're ignoring the set of new problems that comes with either a) providing multiple DNS query interfaces or b) failing to provide an ascii-compatible encoding of IDNs that can be tolerating by existing apps but sure enough, if you close your eyes, you can pretend that the room is empty. > > > Numerous examples demonstrate that transition issues are often > > paramount in determining whether a new technology can succeed. > > I agree that transitional services are important. I also think that the > evidence shows that end-station layering works well when existing formats > are used as carriers for *subsets*, and when it is targeted to a specific > usage. That isn't what's being done here, though. Instead, well-known and > commmonly-used data-types will get *extended* into broader and > incompatible forms by default, and it will happen purposefully and > accidentally. This is not transitional probing, it is knowing that stuff > will break and doing it anyway. the alternative is to say that all apps have to be rewritten to take advantage of IDNs, and the likely result is to fragment existing apps into >> 2 non-interoperable enclaves. the IDNA path causes less harm. > Cripes, why do we have to do it all in a big-bang? Can't we start with the > transfer encoding (no required upgrades for anything), incrementally add > transliteration where we know it will be safe and robust (some upgrades), > and then add UTF-8 for those newer services that can make use of it (some > more upgrades)? What is the problem with this? it completely ignores the forces that drive deployment of upgrades. > The complexity required for a direct UTF-8 name-resolution service in > conjunction with simple passthru-everywhere is minor in comparison to the > complexity of transliterate-everywhere. only if you have the luxury of starting from scratch, before any applications are written.` Keith From owner-idn@ops.ietf.org Sun Mar 17 00:44:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19234 for ; Sun, 17 Mar 2002 00:44:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mT4H-000Il4-00 for idn-data@psg.com; Sat, 16 Mar 2002 21:18:53 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16mT4G-000IkM-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 21:18:52 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 30575; Sat, 16 Mar 2002 23:16:59 -0600 Message-ID: <3C9426DF.15CEEBA7@ehsco.com> Date: Sat, 16 Mar 2002 23:17:20 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Keith Moore CC: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <200203170320.g2H3Kut09298@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > > I would like to hear your arguments as to how, say, using EBCDIC > > to pass ASCII data around could possibly be seen as reasonable > > design. > > it would be quite reasonable for applications that already had a > deeply-wired assumption that character strings were in EBCDIC. Mapped to the current topic, you are saying that ~if the current apps were already deeply-wired for IDNA, then it would be reasonable to use. Of course, I would agree with that, if it were anything resembling the current situation. Too bad nothing in the known universe makes any use whatsoever of IDNA or (more importantly) its conversion routines. > > Of course the native encodings are always best. > > utter hogwash. first, there is no single "native" encoding of UCS, You already know that UTF-8 is the implicit default encoding for it here. > second; there's no encoding of IDNs that is native to the vast majority > of deployed applications. Keith, there's no IDNA encodings of IDNs that are native to *any* applications, either current or scheduled. [big snip] > if and when the rest of the protocol uses UTF-8, then the worst that > happens is that there's an extra layer of encoding that happens before > a DNS query is sent. No, the "worst" that happens is that well-known and widely-used data-types get extended by a third-party process, and then get reused. > and having the client do encoding > prior to lookup is less complex than the extra cruft that's required > to take advantage of having two kinds of DNS queries without introducing > a significant new source of failures or delays. There is definitely some transitional pain in getting to direct UTF-8, but it is non-fatal here, there, and in-between. It doesn't rewrite data, it doesn't require a forklift upgrade of the entire Internet for rendering purposes, and the entire Industry would be better off when it was done. None of that can be said for IDNA transliteration. Well, the pain part still applies. > you're ignoring the set of new problems that comes with either > a) providing multiple DNS query interfaces or Also necessary for IDNA sooner or later, mark my words. > b) failing to provide an ascii-compatible encoding of IDNs that can be > tolerating by existing apps To repeat myself for the record, I think that the IDNA transfer-encoding portion is necessary to provide legacy applications with access to resources in the IDN namespace. What I am specifically arguing against is transliteration. It is just foolish to expect that well-known and widely-used data-types can survive being extended beyond their spec and still function as expected. I have even provided you with evidence proof to the contrary. Look, if a private venture were to come out pitching an untested add-on that rewrote every domain name which appeared on screen, the greybeards would trot out to make measured statements cautioning against mangling of well-known datatypes. What's the difference here? Oh, shit, we *ARE* the greybeards! -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sun Mar 17 00:51:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19396 for ; Sun, 17 Mar 2002 00:51:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mTEs-000ItY-00 for idn-data@psg.com; Sat, 16 Mar 2002 21:29:50 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16mTEs-000IsM-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 21:29:50 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id VAA21343 for ; Sat, 16 Mar 2002 21:28:16 -0800 Message-Id: <5.1.0.14.2.20020316194333.020e50b8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 16 Mar 2002 20:08:24 -0800 To: idn@ops.ietf.org From: Dave Crocker Subject: Re: [idn] WG last call summary In-Reply-To: <3C9384CE.F9E9171A@ehsco.com> References: <200203161551.g2GFpKt16503@astro.cs.utk.edu> <5.1.0.14.2.20020316093357.03148fb8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:45 AM 3/16/2002 -0600, Eric A. Hall wrote: > > UTF-8 is an encoding. IDNA uses an encoding. Neither is a "native" > > representation of the semantics. > >If all of the inputs and outputs are using UTF-8, then UTF-8 on-the-wire >is about as close as you can get to a direct representation. If one plus one were three, the result would be odd. Non-sequitors are not overly helpful to technical discussions, Eric. At 12:09 AM 3/17/2002 +0000, D. J. Bernstein wrote: >There's no theoretical obstacle to making multiple character encodings >work Nice to see you admit that. >Massive redeployment of, at a minimum, every web browser in the world. Oh, rather more packages than that need changing. However it's nice to note that for any of them to enter the world of enhanced DNS characters, they would need changing anyhow. So IDNA does not affect this statistic, other than not making it worse. By contrast, a UTF-8 based encoding will be expected to break most of the DNS clients that have not changed. This is a very poor transition strategy. >And that's just for domain names! Is every worldwide identifier---for >example, mailbox names---supposed to have its own massive upgrade? Yes, Dan. Dealing with an installed base is really a hassle. However it beats the alternative of not dealing with that base. >UTF-8 offers a way out of this mess. Well, no. In fact, it creates a much, much more serious transition requirement. It requires a full-system switchover, rather than permitting incremental adoption. At 12:52 AM 3/17/2002 +0000, D. J. Bernstein wrote: >Internationalized domain names are a failure if non-ASCII glyphs don't >appear on the screen. Have you completely lost sight of the goal here? Transition plans that require everyone to switch over all at once ensure that failure, or have YOU lost sight of the goal here, Dan? The issue is how to accomodate the installed base. IDNA permits incremental adoption. Anyone who opts in gets benefit. However no one is required to opt in and those who do not opt in are not penalized with anything worse than ugly strings. From the standpoint of transition schemes for an installed base, this represents the ideal. >The interoperability problems begin when IDNA gobbledygook is converted >to the local character encoding for display. If the result is copied to >another program---through pipes, copy-and-paste, whatever---then that >program's lookups will fail. Dan, you need to talk to the people responsible for inter-process communications within a single system. That ain't the IETF. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sun Mar 17 00:53:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19430 for ; Sun, 17 Mar 2002 00:53:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mTJO-000IxL-00 for idn-data@psg.com; Sat, 16 Mar 2002 21:34:30 -0800 Received: from [211.254.82.194] (helo=spsoft.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16mTJN-000Ivp-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 21:34:29 -0800 Received: (from newcat@localhost) by spsoft.co.kr (8.10.0/8.10.0) id g2H5WtR25252 for idn@ops.ietf.org; Sun, 17 Mar 2002 14:32:55 +0900 Date: Sun, 17 Mar 2002 14:32:55 +0900 From: YangWoo Ko To: IETF idn working group Subject: Re: [idn] WG last call summary Message-ID: <20020317143255.A25200@spsoft.co.kr> References: <20020311035813.5586.qmail@cr.yp.to> <85930000.1015261835@localhost> <20020311035813.5586.qmail@cr.yp.to> <5.1.0.14.2.20020310201119.020bd7c8@127.0.0.1> <20020314211939.7658.qmail@cr.yp.to> <004301c1cbc2$e4badcf0$0a01000a@jamessonyviao> <20020315030749.17206.qmail@cr.yp.to> <5.0.2.1.2.20020315130807.02652198@shoe.reston.mci.net> <20020317031212.GA25841@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: <20020317031212.GA25841@nicemice.net> User-Agent: Mutt/1.3.23i Sender: owner-idn@ops.ietf.org Precedence: bulk On Sun, Mar 17, 2002 at 03:12:12AM +0000, Adam M. Costello wrote: > vint cerf wrote: > > > it occurs to me that TC/SC equivalences create a signficant burden on > > registration - will any registration of a sequence of such characters > > result in the implicit registration of a potentially large equivalence > > class of strings made up of substitutions of SC for TC or TC for SC > > in all possible combinations? What about the matching question? Will > > a canonical form be required that is in some sense the "generator" of > > the equivalence class of all variations in TC/SC spellings? > > It's up to the registries how to handle this. One approach is to > prohibit mixed TC/SC labels. When someone tried to register such a > name, registrars could suggest the pure TC and SC equivalents. > > If many registries adopt the same rules for which labels are allowed, > applications could assist users who type disallowed labels, offering > pure TC and SC suggestions. > > Another approach would be to define equivalence classes and register > whole classes as a unit. Implementation tricks could be played to use > computation in the DNS servers instead of large tables, if desired. > This would cause each host to have many names, which would help some > things and complicate others. > > These two approaches could be combined: You register a whole class (so > that no one else can use any name in the class), and then it's your > choice whether the DNS servers answer for all members of the class, or > only for a few select members of the class. This might be the best of > both worlds. Dear Adam M. Costello, Thanks to Adam for clarification and ideas. That's exactly what some NICs at east Asia are currently working on. Basic idea was already presented at cctld conistituency meeting of last ICANN Ghana meeting. -- /*------------------------------------------------ YangWoo Ko : newcat@spsoft.co.kr ------------------------------------------------*/ From owner-idn@ops.ietf.org Sun Mar 17 00:57:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19510 for ; Sun, 17 Mar 2002 00:57:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mTIT-000IwK-00 for idn-data@psg.com; Sat, 16 Mar 2002 21:33:33 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16mTIT-000IvV-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 21:33:33 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id VAA21449 for ; Sat, 16 Mar 2002 21:32:00 -0800 Message-Id: <5.1.0.14.2.20020316194333.020e50b8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 16 Mar 2002 20:08:24 -0800 To: idn@ops.ietf.org From: Dave Crocker Subject: Re: [idn] WG last call summary In-Reply-To: <3C9384CE.F9E9171A@ehsco.com> References: <200203161551.g2GFpKt16503@astro.cs.utk.edu> <5.1.0.14.2.20020316093357.03148fb8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:45 AM 3/16/2002 -0600, Eric A. Hall wrote: > > UTF-8 is an encoding. IDNA uses an encoding. Neither is a "native" > > representation of the semantics. > >If all of the inputs and outputs are using UTF-8, then UTF-8 on-the-wire >is about as close as you can get to a direct representation. If one plus one were three, the result would be odd. Non-sequitors are not overly helpful to technical discussions, Eric. At 12:09 AM 3/17/2002 +0000, D. J. Bernstein wrote: >There's no theoretical obstacle to making multiple character encodings >work Nice to see you admit that. >Massive redeployment of, at a minimum, every web browser in the world. Oh, rather more packages than that need changing. However it's nice to note that for any of them to enter the world of enhanced DNS characters, they would need changing anyhow. So IDNA does not affect this statistic, other than not making it worse. By contrast, a UTF-8 based encoding will be expected to break most of the DNS clients that have not changed. This is a very poor transition strategy. >And that's just for domain names! Is every worldwide identifier---for >example, mailbox names---supposed to have its own massive upgrade? Yes, Dan. Dealing with an installed base is really a hassle. However it beats the alternative of not dealing with that base. >UTF-8 offers a way out of this mess. Well, no. In fact, it creates a much, much more serious transition requirement. It requires a full-system switchover, rather than permitting incremental adoption. At 12:52 AM 3/17/2002 +0000, D. J. Bernstein wrote: >Internationalized domain names are a failure if non-ASCII glyphs don't >appear on the screen. Have you completely lost sight of the goal here? Transition plans that require everyone to switch over all at once ensure that failure, or have YOU lost sight of the goal here, Dan? The issue is how to accomodate the installed base. IDNA permits incremental adoption. Anyone who opts in gets benefit. However no one is required to opt in and those who do not opt in are not penalized with anything worse than ugly strings. From the standpoint of transition schemes for an installed base, this represents the ideal. >The interoperability problems begin when IDNA gobbledygook is converted >to the local character encoding for display. If the result is copied to >another program---through pipes, copy-and-paste, whatever---then that >program's lookups will fail. Dan, you need to talk to the people responsible for inter-process communications within a single system. That ain't the IETF. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sun Mar 17 02:13:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28466 for ; Sun, 17 Mar 2002 02:13:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mUdx-000K5k-00 for idn-data@psg.com; Sat, 16 Mar 2002 22:59:49 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16mUdw-000K3t-00 for idn@ops.ietf.org; Sat, 16 Mar 2002 22:59:48 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16mUcT-0000HX-00 for ; Sat, 16 Mar 2002 22:58:17 -0800 Date: Sun, 17 Mar 2002 06:58:17 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] WG last call summary Message-ID: <20020317065817.GA867@nicemice.net> Reply-To: IETF idn working group References: <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C9426DF.15CEEBA7@ehsco.com> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > To repeat myself for the record, I think that the IDNA > transfer-encoding portion is necessary to provide legacy applications > with access to resources in the IDN namespace. What I am specifically > arguing against is transliteration. I'm not sure exactly what you mean by transliteration. In IDNA there are two transformations that can be applied to labels: ToASCII, which forces a label to ASCII (performing ACE encoding if necessary), and ToUnicode, which undoes the ACE encoding if present. Are you saying that ToASCII is good, and ToUnicode is bad? I can imagine a world with ToASCII but without ToUnicode. If a non-ASCII name came to you via new protocols that support non-ASCII names directly, then you'd see the human-friendly form. But if the name traversed an old protocol (at any point), you'd see the ACE. I don't see how doing away with ToUnicode would solve any problem. The main danger is non-ASCII names getting accidentally fed to old software. Even without ToUnicode, non-ASCII names would still be out there (being carried around by the new protocols and new applications), and it would still be possible for them to get pasted or piped into old programs. AMC From owner-idn@ops.ietf.org Sun Mar 17 08:52:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01381 for ; Sun, 17 Mar 2002 08:52:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16masQ-000OmB-00 for idn-data@psg.com; Sun, 17 Mar 2002 05:39:10 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16masP-000Om5-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 05:39:09 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2HDd7t19099; Sun, 17 Mar 2002 08:39:07 -0500 (EST) Message-Id: <200203171339.g2HDd7t19099@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary In-reply-to: (Your message of "17 Mar 2002 00:52:02 GMT.") <20020317005202.8134.qmail@cr.yp.to> Date: Sun, 17 Mar 2002 08:39:07 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > Internationalized domain names are a failure if non-ASCII glyphs don't > appear on the screen. Have you completely lost sight of the goal here? by that logic, IDNs are doomed to fail, because regardless of their representation, few existing apps will be able to properly display them. similarly, the entire Internet is a failure because it fails to route packets to networks that don't exist yet. not everyone accepts your criteria for success. actually, it appears that your criteria for success are incompatible with many others' criteria for success - in particular, that existing apps be able to accept IDNs in the spaces that DNS names are currently acceptable. Keith From owner-idn@ops.ietf.org Sun Mar 17 12:03:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06252 for ; Sun, 17 Mar 2002 12:02:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mdtQ-0001Se-00 for idn-data@psg.com; Sun, 17 Mar 2002 08:52:24 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16mdtQ-0001SY-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 08:52:24 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA07719 for ; Sun, 17 Mar 2002 08:52:22 -0800 Message-Id: <5.1.0.14.2.20020316194333.020e50b8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 16 Mar 2002 20:08:24 -0800 To: idn@ops.ietf.org From: Dave Crocker Subject: Re: [idn] WG last call summary In-Reply-To: <3C9384CE.F9E9171A@ehsco.com> References: <200203161551.g2GFpKt16503@astro.cs.utk.edu> <5.1.0.14.2.20020316093357.03148fb8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:45 AM 3/16/2002 -0600, Eric A. Hall wrote: > > UTF-8 is an encoding. IDNA uses an encoding. Neither is a "native" > > representation of the semantics. > >If all of the inputs and outputs are using UTF-8, then UTF-8 on-the-wire >is about as close as you can get to a direct representation. If one plus one were three, the result would be odd. Non-sequitors are not overly helpful to technical discussions, Eric. At 12:09 AM 3/17/2002 +0000, D. J. Bernstein wrote: >There's no theoretical obstacle to making multiple character encodings >work Nice to see you admit that. >Massive redeployment of, at a minimum, every web browser in the world. Oh, rather more packages than that need changing. However it's nice to note that for any of them to enter the world of enhanced DNS characters, they would need changing anyhow. So IDNA does not affect this statistic, other than not making it worse. By contrast, a UTF-8 based encoding will be expected to break most of the DNS clients that have not changed. This is a very poor transition strategy. >And that's just for domain names! Is every worldwide identifier---for >example, mailbox names---supposed to have its own massive upgrade? Yes, Dan. Dealing with an installed base is really a hassle. However it beats the alternative of not dealing with that base. >UTF-8 offers a way out of this mess. Well, no. In fact, it creates a much, much more serious transition requirement. It requires a full-system switchover, rather than permitting incremental adoption. At 12:52 AM 3/17/2002 +0000, D. J. Bernstein wrote: >Internationalized domain names are a failure if non-ASCII glyphs don't >appear on the screen. Have you completely lost sight of the goal here? Transition plans that require everyone to switch over all at once ensure that failure, or have YOU lost sight of the goal here, Dan? The issue is how to accomodate the installed base. IDNA permits incremental adoption. Anyone who opts in gets benefit. However no one is required to opt in and those who do not opt in are not penalized with anything worse than ugly strings. From the standpoint of transition schemes for an installed base, this represents the ideal. >The interoperability problems begin when IDNA gobbledygook is converted >to the local character encoding for display. If the result is copied to >another program---through pipes, copy-and-paste, whatever---then that >program's lookups will fail. Dan, you need to talk to the people responsible for inter-process communications within a single system. That ain't the IETF. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sun Mar 17 16:22:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11060 for ; Sun, 17 Mar 2002 16:22:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mhtd-0005A4-00 for idn-data@psg.com; Sun, 17 Mar 2002 13:08:53 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16mhtc-00059y-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 13:08:52 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 30650 for idn@ops.ietf.org; Sun, 17 Mar 2002 15:08:29 -0600 Message-ID: <3C9505E1.6326AC6C@ehsco.com> Date: Sun, 17 Mar 2002 15:08:49 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] WG last call summary References: <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > Are you saying that ToASCII is good, and ToUnicode is bad? I am saying that legacy applications need access to IDN namespaces, but that modifying well-known and widely-used data-types in order to render domain names in Unicode form is foolish. We have to separate domain names from the data-types that also use them; they do not need to be cojoined. This means that legacy applications, protocols and data-types which use STD13 names must only be presented with the STD13 form of the IDNs. The i18n form of those names must only be presented to the applications, protocols and data-types which can make use of an i18n domain name. Incorporating this distinction into the current concepts isn't all that easy because of the cross-breeding of ideas and objectives in the docs. What I would like to see is for the current IDNA spec to be made into a codec definition with guidance on implementation. This means deleting (or re-scoping) section "3. Requirements" and deleting section "6.4 Avoiding exposing users to the raw ACE encoding", and adding a new section for "Implementation considerations". The new text should essentially state that domain names which are used by applications, protocol messages and data-formats MUST be passed and displayed in LDH form, except where the governing specification has explicitly defined an IDN behavior for the affected domain name, and that the use of ToUnicode is expressly prohibited if the governing specification has not defined how and where that function will be deployed. It should also be stated that the "governing specification" will often be the local software specifications, such as man named.conf, man ping, or whatever (these will govern domain names which are used as connection identifiers, and which are not used for protocol messages or standardized data-types). > I can imagine a world with ToASCII but without ToUnicode. If a > non-ASCII name came to you via new protocols that support non-ASCII > names directly, then you'd see the human-friendly form. But if the name > traversed an old protocol (at any point), you'd see the ACE. That would be true for new protocol messages and/or data-types that had to traverse the old namespace, yes. There would also be an assumption that the new messages and/or data-types provided mechanisms for storing the IDNs in some kind of raw form (eg UTF-8), and that a conversion point was defined which said "do the conversion here". > I don't see how doing away with ToUnicode would solve any problem. The > main danger is non-ASCII names getting accidentally fed to old software. > Even without ToUnicode, non-ASCII names would still be out there (being > carried around by the new protocols and new applications), and it would > still be possible for them to get pasted or piped into old programs. If the sanctity of the existing data-types are preserved, that won't break anything (or as much, anyway), since only the new data-types will be able to use native IDNs. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sun Mar 17 17:08:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11840 for ; Sun, 17 Mar 2002 17:08:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16miim-00069l-00 for idn-data@psg.com; Sun, 17 Mar 2002 14:01:44 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16miil-00069f-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 14:01:43 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA17183; Sun, 17 Mar 2002 14:01:39 -0800 Message-Id: <5.1.0.14.2.20020317135617.020cd9c0@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 17 Mar 2002 13:57:00 -0800 To: "Eric A. Hall" From: Dave Crocker Subject: Re: [idn] WG last call summary Cc: IETF idn working group In-Reply-To: <3C9505E1.6326AC6C@ehsco.com> References: <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 03:08 PM 3/17/2002 -0600, Eric A. Hall wrote: >I am saying that legacy applications need access to IDN namespaces, but IDN uses strings that are entirely compatible with the existing DNS infrastructure. Hence, legacy apps will automatically get the access they need. They need no change. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sun Mar 17 18:04:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12780 for ; Sun, 17 Mar 2002 18:04:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mjWS-00077U-00 for idn-data@psg.com; Sun, 17 Mar 2002 14:53:04 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16mjWR-00077O-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 14:53:03 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 30658 for idn@ops.ietf.org; Sun, 17 Mar 2002 16:52:40 -0600 Message-ID: <3C951E4C.D68468A7@ehsco.com> Date: Sun, 17 Mar 2002 16:53:00 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] WG last call summary References: <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> <3C9505E1.6326AC6C@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Eric A. Hall" wrote: > The new text should essentially state that ... Section 6.2 of draft-hall-dm-idns-00.txt can be partially adapted for this purpose. Excerpted and adjusted: * Protocol transaction data. If a protocol supports UTF-8 encoded internationalized domain names as parameters to commands or responses, UTF-8 encoded IDNs SHOULD be used wherever they are allowed. If UTF-8 is not supported by the protocol, the ACE equivalents of those domain names MUST be used. Protocols that wish to provide UTF-8 encoded domain names as protocol data as extended functionality MUST provide negotiation services which clearly distinguish the IDN encoding to be used. * Structured data-types. Structured data-types that incorporate domain names as key elements (such as URLs and email addresses) MUST be processed according to the rules which govern those data formats. Applications MUST NOT perform ToUnicode conversions against structured data-types unless this conversion has been explicitly prescribed by the governing specifications. In some situations, new data-type formats will be required in order for IDNs to be safely encapsulated. * Unstructured data. Domain names that appear within application output as unstructured data (such as email message bodies or HTML documents that simply reference an IDN, but not as structured data), are subject to the restrictions imposed by the specifications which govern that data, and by the desires of the users who create that data. Generally speaking, it is RECOMMENDED that applications allow users to enter or view domain names in their preferred encoding formats wherever this is allowed, but that any conversions which are subsequently applied to that data should use UCS as the translation intermediary, so that the IDNs are properly converted along with the rest of the application data. > If the sanctity of the existing data-types are preserved, that won't > break anything (or as much, anyway), since only the new data-types > will be able to use native IDNs. clarification: "only the new data-types [or those data-types which have been extended by the governing bodies] will be able to use native IDNs." -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sun Mar 17 22:40:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18646 for ; Sun, 17 Mar 2002 22:40:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mncP-000CFg-00 for idn-data@psg.com; Sun, 17 Mar 2002 19:15:29 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16mncO-000CFa-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 19:15:28 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16mncN-0002T2-00 for ; Sun, 17 Mar 2002 19:15:27 -0800 Date: Mon, 18 Mar 2002 03:15:27 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] WG last call summary Message-ID: <20020318031526.GB8942@nicemice.net> Reply-To: IETF idn working group References: <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> <3C9505E1.6326AC6C@ehsco.com> <3C951E4C.D68468A7@ehsco.com> <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> <3C9505E1.6326AC6C@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C951E4C.D68468A7@ehsco.com> <3C9505E1.6326AC6C@ehsco.com> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > domain names which are used by applications, protocol messages and > data-formats MUST be passed and displayed in LDH form, except where > the governing specification has explicitly defined an IDN behavior for > the affected domain name, and that the use of ToUnicode is expressly > prohibited if the governing specification has not defined how and > where that function will be deployed. Let me make sure I'm understanding you correctly. For a given domain name slot (protocol element, structured data field, function argument, etc), the governing specification says what you may write into that slot, and tells how to interpret what you read out of that slot, but it does not dictate what you may do with the name after you've read it. That depends on what you're going to do with the name next. For example, if an application reads a name from slot X and writes it to slot Y, then it's the specification of slot Y that determines whether ToUnicode can be performed along the way, not the specification of slot X. If the application reads a name from slot X and displays it, then it's the specification of the application itself that determines whether ToUnicode can be performed. Do we agree on all that? If so, then your paragraph quoted above is stipulating the same requirement as rule 1 of IDNA: domain labels written into domain name slots MUST be in ASCII form unless the specification of the slot explicitly provides for non-ASCII labels. > Structured data-types that incorporate domain names as key elements > (such as URLs and email addresses) MUST be processed according to > the rules which govern those data formats. Applications MUST NOT > perform ToUnicode conversions against structured data-types unless > this conversion has been explicitly prescribed by the governing > specifications. This is another form of rule 1 of IDNA. > Generally speaking, it is RECOMMENDED that applications allow users > to enter or view domain names in their preferred encoding formats > wherever this is allowed... This looks an awful lot like rule 2 of IDNA. SHOULD and RECOMMENDED are equivalent according to RFC 2119. From the IDNA draft: 1) Whenever a domain name is put into a generic domain name slot, every label MUST contain only ASCII characters. 2) ACE labels obtained from domain name slots SHOULD be hidden from users except when the use of the non-ASCII form would cause problems or when the ACE form is explicitly requested. When requirements 1 and 2 both apply, requirement 1 takes precedence. Isn't this very close to what you're saying? ("Generic domain name slot" is defined earlier in the draft, and includes any structured-data domain name whose specification does not explicitly provide for IDNs.) IDNA does not explicitly say something like "when using protocols, data formats, and interfaces, you MUST follows the rules governing them", but that goes without saying. AMC From owner-idn@ops.ietf.org Sun Mar 17 22:54:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18902 for ; Sun, 17 Mar 2002 22:54:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mo2G-000Cof-00 for idn-data@psg.com; Sun, 17 Mar 2002 19:42:12 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.35 #1) id 16mo2F-000CoS-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 19:42:11 -0800 Received: from [] (wired-dhcp-181-171.ietf53.cw.net [166.63.181.171]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g2I452a87545; Sun, 17 Mar 2002 23:05:02 -0500 (EST) Date: Sun, 17 Mar 2002 17:41:20 -0500 From: Marc Blanchet To: erik.nordmark@eng.sun.com, narten@us.ibm.com cc: iesg-secretary@ietf.org, idn@ops.ietf.org Subject: [idn] Request to advance draft-ietf-idn-punycode-01.txt to Proposed Standard Message-ID: <1477700000.1016404880@localhost> X-Mailer: Mulberry/2.2.0b3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Internet Area Directors, The chairs of the idn working group, on behalf of the working group, request that the following document be published as a standard-track Proposed Standard: Title : Punycode: An encoding of Unicode for use with IDNA Author(s) : A. Costello Filename : draft-ietf-idn-punycode-01.txt A working group last call on draft-ietf-idn-punycode-00.txt was completed on Feb 11th 2002. Modifications to the document have been made based on comments received. Marc Blanchet / James Seng idn Working Group Co-Chairs From owner-idn@ops.ietf.org Sun Mar 17 22:54:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18915 for ; Sun, 17 Mar 2002 22:54:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mo2I-000Con-00 for idn-data@psg.com; Sun, 17 Mar 2002 19:42:14 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.35 #1) id 16mo2H-000Coh-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 19:42:13 -0800 Received: from [] (wired-dhcp-181-171.ietf53.cw.net [166.63.181.171]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g2I450a87539; Sun, 17 Mar 2002 23:05:00 -0500 (EST) Date: Sun, 17 Mar 2002 17:40:56 -0500 From: Marc Blanchet To: erik.nordmark@eng.sun.com, narten@us.ibm.com cc: iesg-secretary@ietf.org, idn@ops.ietf.org Subject: [idn] Request to advance draft-ietf-idn-nameprep-08.txt to Proposed Standard Message-ID: <1477470000.1016404856@localhost> X-Mailer: Mulberry/2.2.0b3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Internet Area Directors, The chairs of the idn working group, on behalf of the working group, request that the following document be published as a standard-track Proposed Standard: Title : Nameprep: A Stringprep Profile for Internationalized Domain Names Author(s) : P. Hoffman, M. Blanchet Filename : draft-ietf-idn-nameprep-08.txt A working group last call on draft-ietf-idn-nameprep-07.txt was completed on Feb 11th 2002. Modifications to the document have been made based on comments received. Marc Blanchet / James Seng idn Working Group Co-Chairs From owner-idn@ops.ietf.org Sun Mar 17 22:55:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18931 for ; Sun, 17 Mar 2002 22:55:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mo2E-000CoY-00 for idn-data@psg.com; Sun, 17 Mar 2002 19:42:10 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.35 #1) id 16mo2E-000CoR-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 19:42:10 -0800 Received: from [] (wired-dhcp-181-171.ietf53.cw.net [166.63.181.171]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g2I451a87542; Sun, 17 Mar 2002 23:05:01 -0500 (EST) Date: Sun, 17 Mar 2002 17:41:05 -0500 From: Marc Blanchet To: erik.nordmark@eng.sun.com, narten@us.ibm.com cc: iesg-secretary@ietf.org, idn@ops.ietf.org Subject: [idn] Request to advance draft-hoffman-stringprep-01.txt to Proposed Standard Message-ID: <1477570000.1016404865@localhost> X-Mailer: Mulberry/2.2.0b3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Internet Area Directors, The chairs of the idn working group, on behalf of the working group, request that the following document be published as a standard-track Proposed Standard: Title : Preparation of Internationalized Strings ("stringprep") Author(s) : P. Hoffman, M. Blanchet Filename : draft-hoffman-stringprep-01.txt A working group last call on draft-hoffman-stringprep-00.txt was completed on Feb 11th 2002. Modifications to the document have been made based on comments received. Marc Blanchet / James Seng idn Working Group Co-Chairs From owner-idn@ops.ietf.org Sun Mar 17 22:55:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18948 for ; Sun, 17 Mar 2002 22:55:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mo2C-000CoP-00 for idn-data@psg.com; Sun, 17 Mar 2002 19:42:08 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.35 #1) id 16mo2C-000CoJ-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 19:42:08 -0800 Received: from [] (wired-dhcp-181-171.ietf53.cw.net [166.63.181.171]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g2I44xa87533; Sun, 17 Mar 2002 23:04:59 -0500 (EST) Date: Sun, 17 Mar 2002 17:40:38 -0500 From: Marc Blanchet To: erik.nordmark@eng.sun.com, narten@us.ibm.com cc: iesg-secretary@ietf.org, idn@ops.ietf.org Subject: [idn] Request to advance draft-ietf-idn-idna-07.txt to Proposed Standard Message-ID: <1477310000.1016404838@localhost> X-Mailer: Mulberry/2.2.0b3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Internet Area Directors, The chairs of the idn working group, on behalf of the working group, request that the following document be published as a standard-track Proposed Standard: Title : Internationalizing Host Names In Applications (IDNA) Author(s) : P. Faltstrom, P. Hoffman, A. Costello Filename : draft-ietf-idn-idna-07.txt A working group last call on draft-ietf-idn-idna-06.txt was completed on Feb 11th 2002. Modifications to the document have been made based on comments received. Marc Blanchet / James Seng idn Working Group Co-Chairs From owner-idn@ops.ietf.org Mon Mar 18 00:33:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20536 for ; Mon, 18 Mar 2002 00:33:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mpfs-000F1K-00 for idn-data@psg.com; Sun, 17 Mar 2002 21:27:12 -0800 From: Robert Elz To: Dave Crocker cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Mar 2002 23:37:21 +0700 Message-ID: <1983.1016383041@brandenburg.cs.mu.OZ.AU> Sender: owner-idn@ops.ietf.org Precedence: bulk Date: Sat, 16 Mar 2002 05:54:58 -0800 From: Dave Crocker Message-ID: <5.1.0.14.2.20020316055059.02c87420@127.0.0.1> | The DNS does not have searching. The sad thing about this whole debate is that the DNS has nothing to do with it at all. It is touted as "international domain names", which would make you think that the DNS was deeply involved, but it really isn't. Aside from the A==a rule in the DNS, it cares nothing at all about characters or their meanings. All the work here is for the benefit of other protocols, the DNS (which never had a problem with domain names in any char set whatever) is being mangled to make life easier for other protocols that really should have been fixed years ago. So, what the DNS has, or doesn't have, is irrelevant - what is important is what all the protocols that are the users of domain names (every one of them) has, or doesn't have. kre ps: this whole discussion is silly anyway - there's too much potential profit to be made selling domain names in non ascii based countries for anyone to care much about doing things the right way - all that matters is that something be done immediately, so that profit potential can be realised. From owner-idn@ops.ietf.org Mon Mar 18 00:34:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20556 for ; Mon, 18 Mar 2002 00:34:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mphN-000F4Z-00 for idn-data@psg.com; Sun, 17 Mar 2002 21:28:45 -0800 To: Keith Moore Cc: "Eric A. Hall" , idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary In-Reply-To: Your message of "Sat, 16 Mar 2002 22:20:56 EST." <200203170320.g2H3Kut09298@astro.cs.utk.edu> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1624326418P"; Message-Id: Date: Sun, 17 Mar 2002 21:28:45 -0800 micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 17 Mar 2002 19:11:02 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --==_Exmh_-1624326418P Content-Type: text/plain; charset=us-ascii On Sat, 16 Mar 2002 22:20:56 EST, Keith Moore said: > it would be quite reasonable for applications that already had a > deeply-wired assumption that character strings were in EBCDIC. > Which is why on BITNET and related networks, the applications > generally exchanged data in EBCDIC even between ASCII-native hosts. Damn you Keith. I had *almost* managed to repress the joyful memories of trying to debug what happened when a document managed to start off life as ASCII, get translated to EBCDIC for Bitnet, to/from ASCII again for an intermediate hop, back to EBCDIC again for another hop, and then back to ASCII at the tail end of the journey. And yes, that translate count is correct, and that document was... umm... interesting. ;) However, the day-to-day joys of Bitnet ASCII-EBCDIC translation and what it did to uuencode was one of the *primary* motivating reasons why Base64 happened instead of uuencode. Let's not lose sight of that debacle. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-1624326418P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8lTCVcC3lWbTT17ARAk+NAKD3hRsNHw3V4grJFTra+Rfh5KOYvQCePeH5 /ysZh0/m2XiLv83sBN7EihU= =r6lD -----END PGP SIGNATURE----- --==_Exmh_-1624326418P-- From owner-idn@ops.ietf.org Mon Mar 18 00:34:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20559 for ; Mon, 18 Mar 2002 00:34:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mpgI-000F2V-00 for idn-data@psg.com; Sun, 17 Mar 2002 21:27:38 -0800 To: Paul Robinson Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Subject: Re: [idn] WG last call summary In-Reply-To: Your message of "Sun, 17 Mar 2002 19:23:11 GMT." <20020317192311.U32897@iconoplex.co.uk> From: Valdis.Kletnieks@vt.edu Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1632920510P"; Message-Id: Date: Sun, 17 Mar 2002 21:27:38 -0800 micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 17 Mar 2002 19:03:47 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --==_Exmh_-1632920510P Content-Type: text/plain; charset=us-ascii On Sun, 17 Mar 2002 19:23:11 GMT, Paul Robinson said: > That's not actually completely true. Badly written software will break. In > particular throwing up chars to the shell might break things, but that's > particularly specific to a platform. Pipes won't break. Copy and Paste may > depending on OS, and 'from where and to where'. Generally, it won't. If it > does, it's because somebody has written some *really* crusty code that can't > handle ASCII outside 0-127. The IETF shouldn't be in the business of making > sure everythign works with badly written code. Hmm.. so you're saying that *ALL* that code out there that double-checked that things that claimed (possibly implicitly) to be USASCII were in fact in the 0-127 range are "crusty" code? Damn. Sendmail 8.12.3.Beta1 is crusty - it actually bothers checking. What's wrong with this picture? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-1632920510P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8lS7jcC3lWbTT17ARAsYOAJ0Yy6QjopBJ3fYjgCowMg2esntX7wCeLfQJ XRtuBPvUnItDXWc+d1UGM50= =OFa3 -----END PGP SIGNATURE----- --==_Exmh_-1632920510P-- From owner-idn@ops.ietf.org Mon Mar 18 00:35:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20596 for ; Mon, 18 Mar 2002 00:35:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mpfH-000Ezs-00 for idn-data@psg.com; Sun, 17 Mar 2002 21:26:35 -0800 From: Joel Rowbottom Organization: CentralNic Ltd. X-Accept-Language: en-us MIME-Version: 1.0 To: "D. J. Bernstein" CC: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 17 Mar 2002 21:26:35 -0800 Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > UTF-8 offers a way out of this mess. We do _one_ upgrade to make sure > that UTF-8 works everywhere. This is wonderful, right up to the point of character equivalence. E != e != e(acute) yadayada. Or maybe it does...! From owner-idn@ops.ietf.org Mon Mar 18 00:43:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20676 for ; Mon, 18 Mar 2002 00:43:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mpqo-000FLq-00 for idn-data@psg.com; Sun, 17 Mar 2002 21:38:30 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16mpqn-000FLj-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 21:38:29 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 30698 for idn@ops.ietf.org; Sun, 17 Mar 2002 23:38:06 -0600 Message-ID: <3C957D52.5ED14218@ehsco.com> Date: Sun, 17 Mar 2002 23:38:27 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] WG last call summary References: <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> <3C9505E1.6326AC6C@ehsco.com> <3C951E4C.D68468A7@ehsco.com> <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> <3C9505E1.6326AC6C@ehsco.com> <20020318031526.GB8942@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > Let me make sure I'm understanding you correctly. For a given domain > name slot (protocol element, structured data field, function argument, > etc), the governing specification says The fields that are used in a message have different behaviors than the loosely-coupled data-types which appear in multiple messages or in the message payload. > what you may write into that slot, yes for both > and tells how to interpret what you read out of that slot, yes for both > but it does not dictate what you may do with the name after you've > read it. True for message fields, false for the loosely-coupled data-types which are independent of a particular of any particular protocol message (email addresses, Message-ID, URLs, etc). Also true for connection identifiers. > Do we agree on all that? No. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Mar 18 00:51:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20803 for ; Mon, 18 Mar 2002 00:51:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mpyI-000FYD-00 for idn-data@psg.com; Sun, 17 Mar 2002 21:46:14 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16mpyI-000FXv-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 21:46:14 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 0AECAFFC14; Mon, 18 Mar 2002 13:44:39 +0800 (SGT) Message-ID: <003101c1ce3f$f16898f0$dd00a8c0@jamessonyviao> From: "James Seng" To: "D. J. Bernstein" , Cc: , , References: <20020315205602.13559.qmail@cr.yp.to> <1108604909.1016279522@localhost> <20020317005202.8134.qmail@cr.yp.to> Subject: Re: [idn] WG last call summary Date: Mon, 18 Mar 2002 13:44:11 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Harald Tveit Alvestrand writes: > > 3) contrary to some beliefs, watching gobbledygook is not known to cause > > permanent damage in human beings. > > Internationalized domain names are a failure if non-ASCII glyphs don't > appear on the screen. Have you completely lost sight of the goal here? Dan, On 28th May 2001 (oh boy, we been aroud for so long?), I response to you on the similar discussion: See http://www.imc.org/idn/mail-archive/msg02789.html Particularly, it will explain why display of non-ASCII glyphs isnt as simple as "just use UTF-8 and everything is okay". -James Seng From owner-idn@ops.ietf.org Mon Mar 18 01:18:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21197 for ; Mon, 18 Mar 2002 01:18:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mqOz-000G9h-00 for idn-data@psg.com; Sun, 17 Mar 2002 22:13:49 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16mqOy-000G9b-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 22:13:48 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16mqOx-0002xO-00 for ; Sun, 17 Mar 2002 22:13:47 -0800 Date: Mon, 18 Mar 2002 06:13:47 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] WG last call summary Message-ID: <20020318061347.GE8942@nicemice.net> Reply-To: IETF idn working group References: <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> <3C9505E1.6326AC6C@ehsco.com> <3C951E4C.D68468A7@ehsco.com> <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> <3C9505E1.6326AC6C@ehsco.com> <20020318031526.GB8942@nicemice.net> <3C957D52.5ED14218@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C957D52.5ED14218@ehsco.com> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > > For a given domain name slot (protocol element, structured data > > field, function argument, etc), the governing specification...does > > not dictate what you may do with the name after you've read it. > > True for message fields, false for the loosely-coupled data-types > which are independent of a particular of any particular protocol > message (email addresses, Message-ID, URLs, etc). I'm not getting your point at all. Apparently you are concerned that there exist scenarios where ToUnicode ought to be forbidden/discouraged, but the IDNA draft allows/encourages it. Maybe if you described a specific example of such a scenario, I'd start to understand. AMC From owner-idn@ops.ietf.org Mon Mar 18 01:30:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21373 for ; Mon, 18 Mar 2002 01:30:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mqXo-000GMU-00 for idn-data@psg.com; Sun, 17 Mar 2002 22:22:56 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.35 #1) id 16mqXn-000GMO-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 22:22:55 -0800 Received: (qmail 31584 invoked by uid 1001); 18 Mar 2002 06:20:56 -0000 Date: 18 Mar 2002 06:20:56 -0000 Message-ID: <20020318062056.5166.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <20020317005202.8134.qmail@cr.yp.to> <200203171339.g2HDd7t19099@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Let me emphasize that the IDN WG has received public written objections to IDNA from at least fifteen regular WG participants and _hundreds_ of other people. Everyone agrees that the objections together accuse IDNA of causing a tremendous amount of damage, including bounced email, web link failures, widespread user confusion, and more. The IDN WG chairs have nevertheless sent IDNA to the IESG. That's outrageous. It is, within the IETF, the most blatant abuse of power I've ever seen. I'm willing to spend some time discussing the technical issues that led to these objections; but I'd like readers to keep the context in mind. These specifications should never have been sent to the IESG. Now, back to the technical discussion. Keith Moore writes: > not everyone accepts your criteria for success. ``Internationalized domain names are a failure if non-ASCII glyphs don't appear on the screen.'' What kind of idiot would disagree with that? Would you like to explain, Keith, how IDNs can be a success without non-ASCII glyphs appearing on the screen? Paul Robinson asks whether I'm saying that _one_ bad display means that IDNs are a _complete_ failure. Of course not. One bad display means one failure. One billion bad displays mean one billion failures. Obviously the IDNA authors understand the desire to put non-ASCII glyphs on the screen. Why is this obvious? Because the IDNA documents say that the ad-hoc IDNA character encoding ``SHOULD be hidden from users,'' with various exceptions. The documents spend quite a bit of time explaining how to convert strings out of the IDNA character encoding. The problem is that this conversion creates interoperability failures. Mail will bounce. Web pages will fail to load. The same failures would not have occurred with ASCII domain names. These failures are visible on the wire, and are caused by a proposed IETF specification. The assertion that they're outside the IETF's scope is patently absurd. On Sun, 27 May 2001 21:30:52 +0000, IDNA coauthor Adam Costello claimed on the IDN WG mailing list that nothing would actually break. On Thu, 19 Jul 2001 04:31:48 +0000, Costello admitted on the IDN WG mailing list that his claim was wrong. Things will break. To answer another question from Paul: The problem happens when the converted data is fed to _any_ network program that isn't aware of IDNA. It doesn't matter whether that program is an obsolete 7-bit application or a modern 8-bit-clean application; what matters is that the program isn't undoing the IDNA conversion. When I give specific examples of these IDNA interoperability problems, someone inevitably responds that we can fix those examples by turning off the initial IDNA conversion. That is a silly response, for two reasons: * Preventing _all_ the interoperability problems means turning off conversion for _every_ display subject to IDNA-unaware piping, IDNA-unaware copy-and-paste, etc.---and that's a massive failure to achieve the IDN goal. * The proposal on the table, IDNA, does not disable these conversions. It explicitly encourages these conversions. Anyway, while some IDNA proponents obviously want to slither between interoperability failures and display failures, Costello has already admitted that IDNA will cause both types of failures. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Mon Mar 18 02:15:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00012 for ; Mon, 18 Mar 2002 02:15:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mrGk-000HGV-00 for idn-data@psg.com; Sun, 17 Mar 2002 23:09:22 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.35 #1) id 16mrGk-000HGO-00 for idn@ops.ietf.org; Sun, 17 Mar 2002 23:09:22 -0800 Received: (qmail 1637 invoked by uid 1001); 18 Mar 2002 07:08:19 -0000 Date: 18 Mar 2002 07:08:19 -0000 Message-ID: <20020318070819.11492.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <20020317192311.U32897@iconoplex.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Valdis.Kletnieks@vt.edu writes: > Hmm.. so you're saying that *ALL* that code out there that > double-checked that things that claimed (possibly implicitly) to be > USASCII were in fact in the 0-127 range are "crusty" code? > Damn. Sendmail 8.12.3.Beta1 is crusty - it actually bothers checking. Time for some facts. Sendmail, by default, does _not_ enforce the 0-127 restriction for mail message headers. It allows bytes 160-255. Otherwise European users would be dumping Sendmail even more quickly than they are today; ISO 8859-1 Subject lines are extremely popular. Sendmail _does_ discard bytes 128-159 in mail message headers, because it uses those bytes internally for its internal macro handling. Those bytes aren't used in ISO 8859-1, but they are used in UTF-8. See http://pi.cr.yp.to for a concrete example. I sent Allman some email in February 1999 suggesting that he convert 128 -> 255 160 129 -> 255 161 ... 159 -> 255 191 255 -> 255 255 with the opposite conversion on output. There have been several security-fix releases of sendmail since then, so we could have had the 128-159 problem fixed on a huge number of machines. But he ignored the suggestion. Apparently he doesn't care about international users. People proposed more than a decade ago that the IETF require 8-bit-clean mail software. (See, for example, Andre Pirard's ietf-smtp message dated Tue, 19 Feb 91 12:08:00 +0100.) The only objection to this requirement was the claim that 8-bit support would take a long time to be deployed. Paul Vixie said that he had some seven-year-old sendmail binaries, for example, and concluded ``with near-certainty'' that ``any changes to the SMTP spec will take at least a decade to reach 90% of the critical server population.'' In fact, it took less than a decade for every critical server to add support for 8-bit message bodies, even though the IETF _still_ doesn't require this. If the SMTP specification had been changed in 1991 to require transparent 8-bit handling in both the header and the body, we wouldn't have Sendmail's UTF-8 problems today. Sendmail's continued data corruption is an embarrassment to the Sendmail company. The fact that RFC 2821 and RFC 2822 allow this garbage is an embarrassment to the IETF. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Mon Mar 18 03:56:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01212 for ; Mon, 18 Mar 2002 03:56:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16msjq-000JIb-00 for idn-data@psg.com; Mon, 18 Mar 2002 00:43:30 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16msjp-000JIV-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 00:43:29 -0800 Received: (qmail 23712 invoked by uid 1001); 18 Mar 2002 08:42:27 -0000 Date: 18 Mar 2002 08:42:27 -0000 Message-ID: <20020318084227.8446.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <20020315205602.13559.qmail@cr.yp.to> <1108604909.1016279522@localhost> <20020317005202.8134.qmail@cr.yp.to> <003101c1ce3f$f16898f0$dd00a8c0@jamessonyviao> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk James Seng writes: > Particularly, it will explain why display of non-ASCII glyphs isnt as > simple as "just use UTF-8 and everything is okay". Here we go again: IDN WG co-chair James Seng responds to a discussion of IDNA's flaws by attacking another proposal. Think about that for a moment. IDNA has received massive objections because it's horribly destructive. Seng has sent it to the IESG anyway. How does he defend himself? By claiming that other proposals are worse. What Seng fails to do is compare IDNA to the status quo. Sure, the status quo forces sites to stick to ASCII, which is visually unpleasant for many users. But the status quo also gets the mail delivered, makes web links work, avoids the chaos and confusion that IDNA would produce, avoids massive software upgrades and redeployment, etc. Refusing to consider the status quo as an option is another way of saying ``We have to _do something_.'' That's a recipe for the Internet protocol suite to spiral down into a neverending nightmare. That's not how the IETF works. More importantly, in the absence of consensus, the status quo wins. Something is seriously wrong when an internationalization proposal draws objections from hundreds of Chinese-speaking users, for example. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago P.S. If you'd like to see an example of a serious UTF-8 IDN proposal, try http://cr.yp.to/proto/idnc3.html. From owner-idn@ops.ietf.org Mon Mar 18 04:20:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01503 for ; Mon, 18 Mar 2002 04:20:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mtC0-000Jtw-00 for idn-data@psg.com; Mon, 18 Mar 2002 01:12:36 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16mtBz-000Jtq-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 01:12:36 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 30713 for idn@ops.ietf.org; Mon, 18 Mar 2002 03:12:13 -0600 Message-ID: <3C95AF81.9FFE2608@ehsco.com> Date: Mon, 18 Mar 2002 03:12:33 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] WG last call summary References: <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> <3C9505E1.6326AC6C@ehsco.com> <3C951E4C.D68468A7@ehsco.com> <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> <3C9505E1.6326AC6C@ehsco.com> <20020318031526.GB8942@nicemice.net> <3C957D52.5ED14218@ehsco.com> <20020318061347.GE8942@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > > "Eric A. Hall" wrote: > > > > For a given domain name slot (protocol element, structured data > > > field, function argument, etc), the governing specification...does > > > not dictate what you may do with the name after you've read it. > > > > True for message fields, false for the loosely-coupled data-types > > which are independent of a particular of any particular protocol > > message (email addresses, Message-ID, URLs, etc). > > I'm not getting your point at all. Apparently you are concerned that > there exist scenarios where ToUnicode ought to be forbidden/discouraged, > but the IDNA draft allows/encourages it. Maybe if you described a > specific example of such a scenario, I'd start to understand. I don't know how to say this any different than I have been saying it. The ToUnicode step changes well-known and widely-used data-types in such a way that the data no longer conforms to the rules which govern that data. These changes are harmful when the extended data-types are reused, whether by copy-n-paste, program output, direct transcription, or whatever. An example I have already given is Message-ID. Basic functionality will be broken if the structure of the well-known and widely-used Message-ID data-type as defined in STD11 is extended beyond the scope of the governing spec. The extended, STD11-incompatible form will break on search inputs that don't allow those values, it will break if the search input accepts it and passes it to a remote system via an IMAP SEARCH or NNTP XPAT operation, it will break if a user puts it into a news or http URL which gets transliterated and then percent-hacked, and it will break if a user types it into a web URL as a parameter to a server-based search function. That's just search and fetch, nevermind other problems like damage to threading that results from an extended Message-ID which is manually added to See-Also or References, corrupted spam complaints, and the dozens of other common uses for this well-known, widely-used, STANDARDIZED data-type. This does not mean that users with mail systems located in IDN zones cannot generate Message-IDs from those domains, only that they have to continue generating them with LDH domains (via ToASCII). In that scenario, Message-ID would continue to function across all of the services which utilize the format specified in STD11. That is the way it MUST be until that data-type is either extended (after months of rancorous debate, surely), or it is replaced with something else, or the WG in charge of that standard choose to allow for transliteration (THEM, NOT US). Note well: the subsequent rancorous debates are not the problems of this WG anymore than extending the data-types is our within our scope of responsibility. They are smart enough to figure out what they can get away with on a case-by-case basis. Chorus: Implicitly extending all such data-types currently in use on the Internet (as the current draft does) is willfully causing breakage, and goes well beyond the authority of this WG. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Mar 18 04:27:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01625 for ; Mon, 18 Mar 2002 04:27:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mtKD-000K5f-00 for idn-data@psg.com; Mon, 18 Mar 2002 01:21:05 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16mtKC-000K5N-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 01:21:05 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id C018BFFC0A; Mon, 18 Mar 2002 17:19:28 +0800 (SGT) Message-ID: <001601c1ce5d$f3f47850$dd00a8c0@jamessonyviao> From: "James Seng" To: "D. J. Bernstein" , Cc: , , References: <20020315205602.13559.qmail@cr.yp.to> <1108604909.1016279522@localhost> <20020317005202.8134.qmail@cr.yp.to> <003101c1ce3f$f16898f0$dd00a8c0@jamessonyviao> <20020318084227.8446.qmail@cr.yp.to> Subject: Re: [idn] WG last call summary Date: Mon, 18 Mar 2002 17:19:00 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > James Seng writes: > > Particularly, it will explain why display of non-ASCII glyphs isnt as > > simple as "just use UTF-8 and everything is okay". > > Here we go again: IDN WG co-chair James Seng responds to a discussion of > IDNA's flaws by attacking another proposal. Nope. If you read my mail again, you realise that the display problem which you keep banging on occurs for both UTF-8 & punycode or whatever system you come up with. Display problem is problem at a higher level, one that can only be solved by implementation and deployment, not protocol standardisation. If you disagree, then explain how protocol can enforce what the display/render engine do? > Think about that for a moment. IDNA has received massive objections > because it's horribly destructive. Seng has sent it to the IESG anyway. > How does he defend himself? By claiming that other proposals are worse. Nope. The co-chairs believe we have rough consensus within the working group to move forward these documents. The merits of other proposal(s) are irrelevant to the status of the ones we move forward. If and when the other documents have rough consensus, the co-chairs will move them forward likewise. > Refusing to consider the status quo as an option is another way of > saying ``We have to _do something_.'' That's a recipe for the Internet > protocol suite to spiral down into a neverending nightmare. That's not > how the IETF works. Once again, neither Marc or myself have said "we have to _do something_". You hear it in your dream (or nightmare). Repeating it again and again does not make it true, even if you wish it is so. The IETF works by moving documents which have rough consensus. And that is what we are doing here. > More importantly, in the absence of consensus, the status quo wins. > Something is seriously wrong when an internationalization proposal draws > objections from hundreds of Chinese-speaking users, for example. In the absense of rough consensus, yes, status quo wins. But not in this case. The objections from the Taiwanese (non-wg members btw) are noted to the group. See http://www.imc.org/idn/mail-archive/msg05977.html None of them provide any useful technical information to the last call. Neither are the protest within the IETF process as described in RFC2026 Section 6.5. -James Seng From owner-idn@ops.ietf.org Mon Mar 18 06:30:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03258 for ; Mon, 18 Mar 2002 06:30:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mv61-000ML5-00 for idn-data@psg.com; Mon, 18 Mar 2002 03:14:33 -0800 From: Thor Harald Johansen X-X-Sender: Reply-To: Thor Harald Johansen To: James Seng cc: "D. J. Bernstein" , , , , Subject: Re: [idn] WG last call summary In-Reply-To: <003101c1ce3f$f16898f0$dd00a8c0@jamessonyviao> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Date: Mon, 18 Mar 2002 03:14:33 -0800 > On 28th May 2001 (oh boy, we been aroud for so long?), I response to you on > the similar discussion: See > http://www.imc.org/idn/mail-archive/msg02789.html > Particularly, it will explain why display of non-ASCII glyphs isnt as simple > as "just use UTF-8 and everything is okay". I've been silently following this discussion for a while. Why is it that international domain names can't be implemented with some Unicode encapsulating 7-bit encoding? I understand that there will be issues of case sensitivity (for latin alphabets) on servers and incorrect display on old clients, but how many of you type your URLs in mixed case? The transition will go largely unnoticed. It'll be the responsibility of the creator of the domain to make sure his/her site is available, anyway. Have I missed an important point here, or...? -- Thor Harald Johansen From owner-idn@ops.ietf.org Mon Mar 18 08:01:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04490 for ; Mon, 18 Mar 2002 08:01:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mweV-000OHD-00 for idn-data@psg.com; Mon, 18 Mar 2002 04:54:15 -0800 From: Paul Robinson To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Subject: Re: [idn] WG last call summary Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 18 Mar 2002 04:54:15 -0800 On Mar 18, "D. J. Bernstein" wrote: > More importantly, in the absence of consensus, the status quo wins. > Something is seriously wrong when an internationalization proposal draws > objections from hundreds of Chinese-speaking users, for example. Now *that's* a convincing argument. However, the status quo in this case is broken. OK, let me rephrase - it's broken for people in China who don't understand the latin alphabet or who want their e-mail addresses outside of USASCII 0-127. Something *should* be done, but your argument has a hint of 'I never want anything done, ever' about it, which is putting people off. My current understanding is that the majority of debate appears to be about interoperability with legacy applications - to me, it sounds a little like the brain-dead 'we can't roll out IPv6 as it breaks IPv4' argument. In other words, the code re-write and upgrde is going to have to happen sometime. You just appear to want to put it off whilst we all sit around and procrastinate for a while. History has shown this is not a Good Plan. However, the more I start to re-read docs and think about it, the more I am convincing myself that you may be right. -- Paul Robinson From owner-idn@ops.ietf.org Mon Mar 18 08:03:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04533 for ; Mon, 18 Mar 2002 08:03:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mwe5-000OH3-00 for idn-data@psg.com; Mon, 18 Mar 2002 04:53:49 -0800 From: Paul Robinson To: Valdis.Kletnieks@vt.edu Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Subject: Re: [idn] WG last call summary Message-ID: <20020318115717.W32897@iconoplex.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Date: Mon, 18 Mar 2002 04:53:49 -0800 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA04533 On Mar 18, Valdis.Kletnieks@vt.edu wrote: > Hmm.. so you're saying that *ALL* that code out there that double-checked that > things that claimed (possibly implicitly) to be USASCII were in fact in the > 0-127 range are "crusty" code? No. I'm saying that if a piece of software gets input that is unexpectedly 'out of range' and then crashes and burns it is badly written. Sure, checking data is a good thing. Not checking it and letting things 'just break' is stupid. There are 14-year olds in high school in their second class of visual basic programming who know this. To go back to the original argument, trying to put a stop on a standard getting through because it breaks a piece of softwre written some time ago that a small percentage of people use today is a dumb idea. OK, let's take IDNA. How many people are there in China that would benefit from this process? Let's say the population is 2 billion, and it would benefit 5%. That's 100 million people. How many people would be 'hurt' by the example given breaking? Are there 100 million people out there who would be affected? If yes, then the process needs to stop and take that into account. To argue that it's upsetting the existing user base is also flawed - this is not about keeping things cosy for ourselves at a cost to those outside of the Latin alphabet. If somebody can show how this process will break things for the majority of users (in other words using IE 4 and above, with Outlook Express for mail), THEN it would be a good idea to question interoperability. I'm not saying that we should be considering IE and Outlook Express as de facto standards, just as a benchmark to how many people are likely to experience 'breakages' as a result of IDNA things being pushed through. > What's wrong with this picture? There's too much blue in it, and its skewed to the left a little. :-) -- Paul Robinson From owner-idn@ops.ietf.org Mon Mar 18 09:40:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06090 for ; Mon, 18 Mar 2002 09:40:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16my3P-0000KH-00 for idn-data@psg.com; Mon, 18 Mar 2002 06:24:03 -0800 Received: from mauve.mrochek.com ([209.55.107.55]) by psg.com with esmtp (Exim 3.35 #1) id 16my3O-0000K5-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 06:24:02 -0800 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KFHUEK646O005PEC@mauve.mrochek.com> for idn@ops.ietf.org; Mon, 18 Mar 2002 06:23:57 -0800 (PST) Date: Mon, 18 Mar 2002 06:08:25 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: [idn] WG last call summary In-reply-to: "Your message dated Mon, 18 Mar 2002 11:57:17 +0000" <20020318115717.W32897@iconoplex.co.uk> To: Paul Robinson Cc: Valdis.Kletnieks@vt.edu, ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Message-id: <01KFHVGT8YIG005PEC@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20020315205602.13559.qmail@cr.yp.to> <1108604909.1016279522@localhost> <20020317005202.8134.qmail@cr.yp.to> <20020317192311.U32897@iconoplex.co.uk> <200203180003.g2I03mj6006758@foo-bar-baz.cc.vt.edu> <"from Valdis.Kletnieks"@vt.edu> <20020318115717.W32897@iconoplex.co.uk> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > To go back to the original argument, trying to put a stop on a standard > getting through because it breaks a piece of softwre written some time ago > that a small percentage of people use today is a dumb idea. I have very little sympathy for software that breaks when given unexpected input. But this is not the concern. The concern is that there is a bunch of widely used software that prohibits certain inputs. It does so because the standards in effect at the time the software was written said those inputs are illegal. > To argue that it's upsetting the existing user base is also flawed - this is > not about keeping things cosy for ourselves at a cost to those outside of > the Latin alphabet. If somebody can show how this process will break things > for the majority of users (in other words using IE 4 and above, with Outlook > Express for mail), THEN it would be a good idea to question > interoperability. Here's a quote from a message sent by Carl Gutekunst, , to the IDN list on 10-Feb-2000 that directly addresses this: I conducted some experiments with raw 8-bit data in message header fields a year or so ago in response to requests from customers in Japan and China. There were (and are) some native Japanese and Chinese language E-mail clients that quite happily stuff unencoded Shift-JIS, EUC JIS, Big 5, et al into the Subject and the phrase fields (but not the route-addr) of addresses. The results were similar to what we saw with Just-Send-8 a decade ago. As long as the entire end-to-end path had been carefully managed to specifically handle these messages, they would be received and displayed correctly. But if any SMTP relay or client wasn't party to the bilateral agreement, all kinds of damage happened, including RFC2047 conversions, nonsensical character set conversions, seemingly random mangling, 8-bit truncation, and non-deliveries. (And I'm *not* including untagged charset mismatches, which would not be an issue if we used UTF-8 exclusively.) Carl later stated that he tested using sendmail 8.9.3, UofW Imapd 4.5, and Netscape Communicator 4.7. The latter dumped core. I've done similar tests and reached similar conclusions. In short, this proposal DOES break things, so interoperability has to be questioned. Ned From owner-idn@ops.ietf.org Mon Mar 18 11:15:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08627 for ; Mon, 18 Mar 2002 11:15:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mzfh-0002Os-00 for idn-data@psg.com; Mon, 18 Mar 2002 08:07:41 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16mzfg-0002Om-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 08:07:40 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2IG7Ft23962; Mon, 18 Mar 2002 11:07:20 -0500 (EST) Message-Id: <200203181607.g2IG7Ft23962@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary In-reply-to: (Your message of "18 Mar 2002 06:20:56 GMT.") <20020318062056.5166.qmail@cr.yp.to> Date: Mon, 18 Mar 2002 11:07:15 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > Keith Moore writes: > > not everyone accepts your criteria for success. > > ``Internationalized domain names are a failure if non-ASCII glyphs don't > appear on the screen.'' What kind of idiot would disagree with that? anybody with two working brain cells should be able to figure out that IDNs won't be able to be displayed with software that was designed and written before IDNs existed. even if IDNs were bare UTF-8, they still wouldn't be able to be input from software that predated IDNs because such software wouldn't do the appropriate canonicalization/normalization and wouldn't know how to properly compare two IDNs for equivalence. but you know this already. you just choose to ignore it so that you can berate people who don't want to rewrite all applications to suit your whim. Keith From owner-idn@ops.ietf.org Mon Mar 18 11:23:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09423 for ; Mon, 18 Mar 2002 11:23:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mzl7-0002WF-00 for idn-data@psg.com; Mon, 18 Mar 2002 08:13:17 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16mzl6-0002W0-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 08:13:16 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2IGD9t24697; Mon, 18 Mar 2002 11:13:10 -0500 (EST) Message-Id: <200203181613.g2IGD9t24697@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "James Seng" cc: "D. J. Bernstein" , idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary In-reply-to: (Your message of "Mon, 18 Mar 2002 17:19:00 +0800.") <001601c1ce5d$f3f47850$dd00a8c0@jamessonyviao> Date: Mon, 18 Mar 2002 11:13:09 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > The objections from the Taiwanese (non-wg members btw) are noted to the > group. > See http://www.imc.org/idn/mail-archive/msg05977.html > > None of them provide any useful technical information to the last call. > Neither are the protest within the IETF process as described in RFC2026 > Section 6.5. I have to disagree with this. first of all, there's no such thing as a wg member. anybody who contributes to the discussion is as much a member as anyone else. second, this is useful technical input, and the problems with TC/SC equivalence are serious. even if they can't be fixed reasonably with the current DNS protocol, they do have some bearing on the applicability of IDN. third, I don't see why you say these are not within the IETF process, but I find no justification for that statement. if nothing else, the spirit of IETF has always been to consider any constructive input, even if it were not presented in exactly the correct way. Keith From owner-idn@ops.ietf.org Mon Mar 18 11:31:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09853 for ; Mon, 18 Mar 2002 11:31:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mzw8-0002kN-00 for idn-data@psg.com; Mon, 18 Mar 2002 08:24:40 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16mzw8-0002kF-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 08:24:40 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA18457; Mon, 18 Mar 2002 08:24:27 -0800 Message-Id: <5.1.0.14.2.20020318102248.02238080@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Mar 2002 10:23:21 -0600 To: "D. J. Bernstein" From: Dave Crocker Subject: Re: [idn] WG last call summary Cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu In-Reply-To: <20020318084227.8446.qmail@cr.yp.to> References: <20020315205602.13559.qmail@cr.yp.to> <1108604909.1016279522@localhost> <20020317005202.8134.qmail@cr.yp.to> <003101c1ce3f$f16898f0$dd00a8c0@jamessonyviao> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 08:42 AM 3/18/2002 +0000, D. J. Bernstein wrote: >What Seng fails to do is compare IDNA to the status quo. Sure, the this has been done many times. there is no need to repeat just because a participant failed to acknowledge or understand it. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Mar 18 11:40:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10292 for ; Mon, 18 Mar 2002 11:40:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n00o-0002s2-00 for idn-data@psg.com; Mon, 18 Mar 2002 08:29:30 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16n00n-0002rw-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 08:29:29 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2IGTOt26699; Mon, 18 Mar 2002 11:29:24 -0500 (EST) Message-Id: <200203181629.g2IGTOt26699@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Robinson cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Subject: Re: [idn] WG last call summary In-reply-to: (Your message of "Mon, 18 Mar 2002 12:22:51 GMT.") <20020318122251.X32897@iconoplex.co.uk> Date: Mon, 18 Mar 2002 11:29:24 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > In other words, the code re-write and upgrde is going to have to happen > sometime. right. but it's not in our power to tell people when to do the rewrite and upgrade. and insisting that everyone upgrade all applications to accept IDNs before anyone uses IDNs won't work. there's too much demand for IDNs right now, and people are already deploying it. since we don't have the luxury of upgrading everything first, we need a solution that minimizes the harm when IDNs are used with legacy software. Keith From owner-idn@ops.ietf.org Mon Mar 18 11:53:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10702 for ; Mon, 18 Mar 2002 11:53:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n0Fq-0003E8-00 for idn-data@psg.com; Mon, 18 Mar 2002 08:45:02 -0800 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.35 #1) id 16n0Fp-0003E2-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 08:45:01 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.170]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GT6H6Z00.M0E; Mon, 18 Mar 2002 11:44:59 -0500 Message-ID: <006c01c1ce9c$21cd3080$aa424244@anhmca.adelphia.net> From: "Doug Ewell" To: "D. J. Bernstein" Cc: References: <20020317005202.8134.qmail@cr.yp.to> <200203171339.g2HDd7t19099@astro.cs.utk.edu> <20020318062056.5166.qmail@cr.yp.to> Subject: Re: [idn] WG last call summary Date: Mon, 18 Mar 2002 08:44: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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [irrelevant cc: addresses snipped] On Thursday I responded to D.J. "Dan" Bernstein : >> The bottom line, once again, is that at least fifteen regular WG >> participants and _hundreds_ of other people have written messages >> to the IDN mailing list in opposition to IDNA. > > Identically worded chain letters don't count. It's the same thing when > you write to your congressperson: they throw out the Xeroxed ones > immediately. On Sunday, Dan wrote: > Let me emphasize that the IDN WG has received public written objections > to IDNA from at least fifteen regular WG participants and _hundreds_ of > other people. and later: > Something is seriously wrong when an internationalization proposal draws > objections from hundreds of Chinese-speaking users, for example. And Dan accuses *others* of not listening? Let me try again, for what I expect is the last time: HUNDREDS of people who have been told to write a letter, about an issue they may know nothing at all about, and who have been handed the exact text of the letter, such that they merely need to sign their names and send it, does NOT indicate a legitimate technical concern on the part of HUNDREDS of people. It indicates that HUNDREDS of people are capable of following instructions. Dan also wrote: > Everyone agrees that the objections together accuse IDNA > of causing a tremendous amount of damage, including bounced email, web > link failures, widespread user confusion, and more. "Everyone," in this case, meaning the hundreds of lemmings who sent the chain letters. Once again: IDNA can *only* cause anything like these problems if a user manually types an IDN name differently from the way it was originally presented. That means the user must use TC when TC is presented, and SC when SC is presented, just as all of us must currently do with BiCapitalized web pages. I agree that this is not the best solution that the human imagination can admit, but I do NOT agree, nor does the rest of this list, that this constitutes the sort of Armageddon that Dan envisions. Previously I had written: > Nobody was ever able to explain to me, anyway, how providing Chinese > domain names in Han characters, but not mapping them between TC and > SC, could possibly cause more damage, conflict, and chaos than forcing > the Chinese to use ASCII, as the current system does. And still nobody has done so, least of all Dan, who seems more intent than anyone on using this purported "damage, conflict, and chaos" to put a stop to IDNA. I no longer have any interest in reading anything Dan has to say, for or against IDNA. Reading his posts is like listening to a Charmin' Chattie doll who only has four or five things to say and no capacity to listen to others. I will be deleting all of Dan's future messages on sight from now on. Whether the rest of the list chooses to do likewise is entirely up to them. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Mon Mar 18 11:54:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10723 for ; Mon, 18 Mar 2002 11:54:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n0Ix-0003Jr-00 for idn-data@psg.com; Mon, 18 Mar 2002 08:48:15 -0800 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.35 #1) id 16n0Iw-0003Jl-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 08:48:14 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.170]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GT6HCE00.30B; Mon, 18 Mar 2002 11:48:14 -0500 Message-ID: <007501c1ce9c$9604c6c0$aa424244@anhmca.adelphia.net> From: "Doug Ewell" To: Cc: "Thor Harald Johansen" References: Subject: Re: [idn] WG last call summary Date: Mon, 18 Mar 2002 08:47:26 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thor Harald Johansen wrote: > Why is it that > international domain names can't be implemented with some Unicode > encapsulating 7-bit encoding? That's exactly what Punycode is. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Mon Mar 18 15:40:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19293 for ; Mon, 18 Mar 2002 15:40:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n3dY-0006zR-00 for idn-data@psg.com; Mon, 18 Mar 2002 12:21:44 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.35 #1) id 16n3dX-0006zG-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 12:21:43 -0800 Received: from [] (wireless-dhcp-188-239.ietf53.cw.net [166.63.188.239]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g2IKjDT99291 for ; Mon, 18 Mar 2002 15:45:13 -0500 (EST) Date: Mon, 18 Mar 2002 15:22:31 -0500 From: Marc Blanchet To: idn@ops.ietf.org Subject: [idn] reconfirmation: the wg will NOT meet this week Message-ID: <199840000.1016482951@localhost> X-Mailer: Mulberry/2.2.0b3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA19293 I sent a message last thrusday about the fact that the wg will not meet this week. This is a reconfirmation message: we will NOT meet this week. Marc. ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-idn@ops.ietf.org Mon Mar 18 18:08:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24596 for ; Mon, 18 Mar 2002 18:08:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n60z-0009ju-00 for idn-data@psg.com; Mon, 18 Mar 2002 14:54:05 -0800 Received: from a212-113-174-249.netcabo.pt ([212.113.174.249] helo=netcabo.pt) by psg.com with esmtp (Exim 3.35 #1) id 16n60x-0009jm-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 14:54:05 -0800 Received: from mail pickup service by netcabo.pt with Microsoft SMTPSVC; Mon, 18 Mar 2002 22:31:09 +0000 Received: from smtp.netcabo.pt ([192.168.16.2]) by netcabo.pt with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 18 Mar 2002 20:21:58 +0000 Received: from relay.tuxmail.com ([213.63.140.56]) by smtp.netcabo.pt with Microsoft SMTPSVC(5.0.2195.4905); Mon, 18 Mar 2002 20:26:21 +0000 Received: (qmail 23343 invoked from network); 18 Mar 2002 20:30:36 +0000 Received: from unknown (HELO castor.nfsi.pt) (213.63.140.5) by 213.63.140.56 with SMTP; 18 Mar 2002 20:30:36 +0000 Received: (qmail 18113 invoked by alias); 19 Mar 2002 20:10:43 -0000 Delivered-To: alias-sactivex:com-jcb@SACTIVEX.COM Received: (qmail 18110 invoked from network); 19 Mar 2002 20:10:42 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by 213.58.161.5 with SMTP; 19 Mar 2002 20:10:42 -0000 Received: by ietf.org (8.9.1a/8.9.1a) id PAA18922 for ietf-outbound.05@ietf.org; Mon, 18 Mar 2002 15:30:01 -0500 (EST) Received: by ietf.org (8.9.1a/8.9.1a) id MAA11568 for ietf-mainout; Mon, 18 Mar 2002 12:08:17 -0500 (EST) X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05785; Mon, 18 Mar 2002 09:23:56 -0500 (EST) From: ned.freed@mrochek.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KFHUEK646O005PEC@mauve.mrochek.com>; Mon, 18 Mar 2002 06:23:57 -0800 (PST) Date: Mon, 18 Mar 2002 06:08:25 -0800 (PST) Subject: Re: [idn] WG last call summary In-reply-to: "Your message dated Mon, 18 Mar 2002 11:57:17 +0000" <20020318115717.W32897@iconoplex.co.uk> To: Paul Robinson Cc: Valdis.Kletnieks@vt.edu, ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Message-id: <01KFHVGT8YIG005PEC@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20020315205602.13559.qmail@cr.yp.to> <1108604909.1016279522@localhost> <20020317005202.8134.qmail@cr.yp.to> <20020317192311.U32897@iconoplex.co.uk> <200203180003.g2I03mj6006758@foo-bar-baz.cc.vt.edu> <"from Valdis.Kletnieks"@vt.edu> <20020318115717.W32897@iconoplex.co.uk> Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7BIT X-OriginalArrivalTime: 18 Mar 2002 20:26:21.0605 (UTC) FILETIME=[2AD76550:01C1CEBB] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > To go back to the original argument, trying to put a stop on a standard > getting through because it breaks a piece of softwre written some time ago > that a small percentage of people use today is a dumb idea. I have very little sympathy for software that breaks when given unexpected input. But this is not the concern. The concern is that there is a bunch of widely used software that prohibits certain inputs. It does so because the standards in effect at the time the software was written said those inputs are illegal. > To argue that it's upsetting the existing user base is also flawed - this is > not about keeping things cosy for ourselves at a cost to those outside of > the Latin alphabet. If somebody can show how this process will break things > for the majority of users (in other words using IE 4 and above, with Outlook > Express for mail), THEN it would be a good idea to question > interoperability. Here's a quote from a message sent by Carl Gutekunst, , to the IDN list on 10-Feb-2000 that directly addresses this: I conducted some experiments with raw 8-bit data in message header fields a year or so ago in response to requests from customers in Japan and China. There were (and are) some native Japanese and Chinese language E-mail clients that quite happily stuff unencoded Shift-JIS, EUC JIS, Big 5, et al into the Subject and the phrase fields (but not the route-addr) of addresses. The results were similar to what we saw with Just-Send-8 a decade ago. As long as the entire end-to-end path had been carefully managed to specifically handle these messages, they would be received and displayed correctly. But if any SMTP relay or client wasn't party to the bilateral agreement, all kinds of damage happened, including RFC2047 conversions, nonsensical character set conversions, seemingly random mangling, 8-bit truncation, and non-deliveries. (And I'm *not* including untagged charset mismatches, which would not be an issue if we used UTF-8 exclusively.) Carl later stated that he tested using sendmail 8.9.3, UofW Imapd 4.5, and Netscape Communicator 4.7. The latter dumped core. I've done similar tests and reached similar conclusions. In short, this proposal DOES break things, so interoperability has to be questioned. Ned From owner-idn@ops.ietf.org Mon Mar 18 19:39:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27428 for ; Mon, 18 Mar 2002 19:39:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n7WL-000BKw-00 for idn-data@psg.com; Mon, 18 Mar 2002 16:30:33 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16n7WK-000BKq-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 16:30:32 -0800 Received: (qmail 23211 invoked by uid 1001); 19 Mar 2002 00:29:29 -0000 Date: 19 Mar 2002 00:29:29 -0000 Message-ID: <20020319002929.13911.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Paul Robinson writes: > Something *should* be done, but your argument has a hint of > 'I never want anything done, ever' about it, which is putting people off. I have put a huge amount of effort into evaluating the costs of various IDN proposals. Please read http://cr.yp.to/proto/idnc3.html before you make any more comments about what I'm trying to do. I have been trying to fix obsolete 7-bit IETF specifications for years. I have been advocating for a year that the IDN WG _immediately_ declare 7-bit software to be obsolete. See the DRUMS archives for more examples. I have a detailed web page, http://pi.cr.yp.to, tracking 8-bit bugs in a variety of programs. I've spent quite a bit of time talking to other implementors about this. It has been more than three years since I suggested an easy Sendmail fix to Eric Allman. You may be aware that I'm the author of the mail software with the Internet's largest increase in SMTP-server deployment over the past 18 months (reaching #2 in total deployment, behind only Sendmail), and the DNS software with the Internet's largest increase in domain-name deployment over the past 18 months (reaching #2 in total deployment, behind only BIND). My programs relay 8-bit data without trouble, even though certain people obviously don't understand why this is important. I want internationalized domain names (and mailbox names and so on) to work. But I can't support the IDNA proposal; IDNA is a disaster. I also can't accept having _any_ protocol move forward over so many objections. Even the strongest desire to _do something_ is less important than the requirement to obtain consensus for any change. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Mon Mar 18 21:30:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29441 for ; Mon, 18 Mar 2002 21:30:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n91o-000D1y-00 for idn-data@psg.com; Mon, 18 Mar 2002 18:07:08 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16n91n-000D1s-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 18:07:07 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16n91m-0006iy-00 for ; Mon, 18 Mar 2002 18:07:06 -0800 Date: Tue, 19 Mar 2002 02:07:06 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] WG last call summary Message-ID: <20020319020705.GA24725@nicemice.net> Reply-To: IETF idn working group References: <3C9505E1.6326AC6C@ehsco.com> <3C951E4C.D68468A7@ehsco.com> <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> <3C9505E1.6326AC6C@ehsco.com> <20020318031526.GB8942@nicemice.net> <3C957D52.5ED14218@ehsco.com> <20020318061347.GE8942@nicemice.net> <3C95AF81.9FFE2608@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C95AF81.9FFE2608@ehsco.com> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > The ToUnicode step changes well-known and widely-used data-types in > such a way that the data no longer conforms to the rules which govern > that data. ToUnicode does not change any data type. ToUnicode does not apply to email address, or URIs, or message-IDs. It applies to IDNs (including traditional ASCII domain names). In order to get any interaction between a message-ID and ToUnicode, you first need to extract the domain name from the message-ID. Then when you apply ToUnicode, you get an IDN, not an internationalized-message-ID. If you want to have a message-ID again, you need to insert the IDN back into a message-ID structure, which invokes rule 1 and requires the IDN to be forced back to ASCII (via ToASCII). That's the story when machines are talking to machines. When it's machines talking to humans, it's a different story: When a mail program displays a message header, it's not necessarily a real RFC 822 message header on the screen. The mail program doesn't promise to speak RFC 822 to the human user. What's on the screen is a rendering. The program might omit certain fields that are required, and might include non-ASCII characters (converted from RFC 2047 encoding). It might let me type non-ASCII characters into the Subject line of an outgoing message. When I instruct the program to send a message, the program will take care to send an actual RFC 822 message, doing whatever encoding is necessary. I might try to cut & paste the message from the screen into sendmail, but I wouldn't be very surprised if that didn't work. The program might let me type non-ASCII characters into a search query, and it will find messages with matching headers or matching bodies, even if they use quoted-printable and base64 encoding. (Mutt does all this correctly, by the way.) > An example I have already given is Message-ID. Basic functionality > will be broken if the structure of the well-known and widely-used > Message-ID data-type as defined in STD11 is extended beyond the scope > of the governing spec. The extended, STD11-incompatible form will > break on search inputs that don't allow those values, it will break > if the search input accepts it and passes it to a remote system > via an IMAP SEARCH or NNTP XPAT operation, it will break if a user > puts it into a news or http URL which gets transliterated and then > percent-hacked, and it will break if a user types it into a web URL as > a parameter to a server-based search function. That's just search and > fetch, nevermind other problems like damage to threading that results > from an extended Message-ID which is manually added to See-Also or > References, corrupted spam complaints, and the dozens of other common > uses for this well-known, widely-used, STANDARDIZED data-type. IDNA does not extend the message-ID type. Message-IDs continue to be ASCII-only, just as they always have been. IDNA-aware applications, as a user-interface courtesy, will usually render them using non-ASCII characters (when they contain ACE labels), and allow users to enter them using non-ASCII characters. But an IDNA-aware program knows that message-IDs are really ASCII-only, and will apply ToASCII as needed. Everything you and I have said about message-IDs applies equally to email addresses (which is not surprising, since message-IDs and email addresses are syntactically the same). Email addresses continue to be ASCII-only, but for email addresses containing ACE labels, it will be helpful for user interfaces to display/accept non-ASCII characters. So any internationalized program that deals with mail and human users is going to have to deal with the conversion. If it can cope with email addresses, then it can cope with message-IDs in exactly the same way. > Implicitly extending all such data-types currently in use on the > Internet (as the current draft does) We have found the crux of our disagreement. I maintain that IDNA does *not* extend or alter any data types. It defines one new data type (IDN), and defines a correspondence between IDNs and ASCII domain names, to be used for user interfaces and for gatewaying between old & new protocols/interfaces. But it does not extend any existing types. Any existing type that contains ASCII domain names continues to contain ASCII domain names. AMC From owner-idn@ops.ietf.org Mon Mar 18 21:50:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00904 for ; Mon, 18 Mar 2002 21:50:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n9TF-000DcI-00 for idn-data@psg.com; Mon, 18 Mar 2002 18:35:29 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16n9TE-000Dc3-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 18:35:28 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id A5467FFC08; Tue, 19 Mar 2002 10:33:50 +0800 (SGT) Message-ID: <056001c1ceee$ad303300$dd00a8c0@jamessonyviao> From: "James Seng" To: "Keith Moore" Cc: "D. J. Bernstein" , , , , References: <200203181613.g2IGD9t24697@astro.cs.utk.edu> Subject: Re: [idn] WG last call summary Date: Tue, 19 Mar 2002 10:34:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > The objections from the Taiwanese (non-wg members btw) are noted to the > > group. > > See http://www.imc.org/idn/mail-archive/msg05977.html > > > > None of them provide any useful technical information to the last call. > > Neither are the protest within the IETF process as described in RFC2026 > > Section 6.5. > > I have to disagree with this. > > first of all, there's no such thing as a wg member. anybody who > contributes to the discussion is as much a member as anyone else. I meant to say they are not subscriber of the wg. (btw, it is not funny to get 353 bounce mails, sorting them out and manually replying to each of them.) > second, this is useful technical input, and the problems with > TC/SC equivalence are serious. even if they can't be fixed > reasonably with the current DNS protocol, they do have some > bearing on the applicability of IDN. It is useful technical input on the first time. By the 353th time, someone got to ask what else are they contributing? > third, I don't see why you say these are not within the IETF process, > but I find no justification for that statement. if nothing else, > the spirit of IETF has always been to consider any constructive input, > even if it were not presented in exactly the correct way. It is a protest and appeal against the last call. The IETF process specify the exact process to do so in RFC2026 Section 6.5. -James Seng From owner-idn@ops.ietf.org Mon Mar 18 21:51:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00916 for ; Mon, 18 Mar 2002 21:51:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n9Wb-000Dgj-00 for idn-data@psg.com; Mon, 18 Mar 2002 18:38:57 -0800 From: Thor Harald Johansen Reply-To: Thor Harald Johansen To: Keith Moore cc: Paul Robinson , , , , Subject: Re: [idn] WG last call summary In-Reply-To: <200203181629.g2IGTOt26699@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-idn@ops.ietf.org Precedence: bulk Date: Mon, 18 Mar 2002 18:38:57 -0800 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id VAA00916 > right. but it's not in our power to tell people when to do the rewrite > and upgrade. and insisting that everyone upgrade all applications to > accept IDNs before anyone uses IDNs won't work. there's too much demand > for IDNs right now, and people are already deploying it. since we don't > have the luxury of upgrading everything first, we need a solution that > minimizes the harm when IDNs are used with legacy software. This could be done by alternative means of accessing the sites the IDNs in question are refering/pointing to. People who want IDNs also have the responsibility of not forcing people to use these to access their servers. IDNs in e-mails would pose no real problem, as anyone replying in a legacy client to an account on an IDN adressed mail erver would see the encapsulated encoding, and reply to the encoded address. When he then upgrades his client, he would either change to typing the addresses unencoded or just continue typing in the encoded IDNs (and the new client would see this and refrain from doing any conversion). The hypothetical Norwegian web page 'www.søråsen.no' could have an alternate representation (a separate domain) of 'www.sorasen.no' or 'www.soeraasen.no' for people with old clients. The domain's owner could also simply give the encoded address to the users of the site, and the new clients would decode these. The user would then learn the easier way of typing, or (if the IDN was in a non-latin alphabet and he would lack the proper keyboard map to type it) just type in the encoded version. -- Thor Harald Johansen thorhj@yahoo.com From owner-idn@ops.ietf.org Mon Mar 18 21:51:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00922 for ; Mon, 18 Mar 2002 21:51:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n9Wk-000Dgy-00 for idn-data@psg.com; Mon, 18 Mar 2002 18:39:06 -0800 Date: Mon, 18 Mar 2002 14:38:38 -0600 To: "D. J. Bernstein" From: Pete Resnick Subject: Re: [idn] WG last call summary Cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: On 3/18/02 at 6:20 AM +0000, D. J. Bernstein wrote: >``Internationalized domain names are a failure if non-ASCII glyphs >don't appear on the screen.'' What kind of idiot would disagree with >that? I'm one of those kind of idiots. I expect that there will be many applications that won't put non-US-ASCII glyphs on the screen at the get-go. The three criteria for success (for me) are: 1. Applications, if they are properly coded, *can* display non-US-ASCII glyphs. 2. All of the new domain names can appear (in some form) in legacy applications without breaking those applications. 2. All applications, legacy or otherwise, are able to resolve new domain names. If there exists an domain name (and I'm referring to the logical entity, not some particular glyph representation of it) that a legacy application can't address, that's a failure. That is to say, balkanization during the transition is a failure of the protocol. Inability to display non-US-ASCII glyphs by legacy applications is not a failure. >Obviously the IDNA authors understand the desire to put non-ASCII >glyphs on the screen. To what is this a response? Has anyone claimed that it is *undesireable* to display non-US-ASCII glyphs? >* Preventing _all_ the interoperability problems means turning off >conversion for _every_ display subject to IDNA-unaware piping, >IDNA-unaware copy-and-paste, etc.---and that's a massive failure to >achieve the IDN goal. I cannot disagree more; this is not a massive failure. Unless of course MIME has also been a massive failure to send around binary attachments. In the same way, if I use an e-mail client that decodes base64 into binary and pipes the output to a program that expects US-ASCII input, I've done something broken. If I decode IDNA names and pipe them to a program that expects US-ASCII domain names, I have again done something broken. And in IDNA, we do MIME one better: The undecoded IDNA names are usable, even if they aren't pretty. A base64 encoded file is near useless to anything without decoding. >* The proposal on the table, IDNA, does not disable these >conversions. It explicitly encourages these conversions. Textual support? 6.1 and 6.4 seem to give lots of reasons not to do the conversions. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From owner-idn@ops.ietf.org Mon Mar 18 21:54:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00993 for ; Mon, 18 Mar 2002 21:54:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n9WH-000Dfq-00 for idn-data@psg.com; Mon, 18 Mar 2002 18:38:37 -0800 To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Subject: Re: [idn] WG last call summary In-Reply-To: Your message of "Mon, 18 Mar 2002 11:57:17 GMT." <20020318115717.W32897@iconoplex.co.uk> From: Valdis.Kletnieks@vt.edu Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_2050924116P"; Message-Id: Date: Mon, 18 Mar 2002 18:38:37 -0800 micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 18 Mar 2002 14:36:57 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --==_Exmh_2050924116P Content-Type: text/plain; charset=us-ascii On Mon, 18 Mar 2002 11:57:17 GMT, Paul Robinson said: > > Hmm.. so you're saying that *ALL* that code out there that double-checked that > > things that claimed (possibly implicitly) to be USASCII were in fact in the > > 0-127 range are "crusty" code? > No. I'm saying that if a piece of software gets input that is unexpectedly > 'out of range' and then crashes and burns it is badly written. Sure, > checking data is a good thing. Not checking it and letting things 'just > break' is stupid. There are 14-year olds in high school in their second > class of visual basic programming who know this. OK.. Thanks for the clarification. The distinction is important, because: On Mon, 18 Mar 2002 06:08:25 PST, ned.freed@mrochek.com said: > I have very little sympathy for software that breaks when given unexpected > input. But this is not the concern. The concern is that there is a bunch of > widely used software that prohibits certain inputs. It does so because the > standards in effect at the time the software was written said those inputs are > illegal. And let's remember - currently, if it's *not* ascii and *not* RFC2047-encoded, it is *illegal* in email headers and *IF* it works, it only does so either *BY ACCIDENT* or *BY MUTUAL PRIVATE AGREEMENT*. As such, I have to insist that *any* IDN proposal be required to be backwards transparent to the current 2821/2822/2045-2049 standards the same way that MIME/ESMTP was required to be backwards transparent to the then-existing 821/822 infrastructure. On the other hand, I *will* accept an IDN proposal that looks as ugly to non-upgraded software as 2047-encoding does to a non-2047 capable MUA. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_2050924116P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8lkHZcC3lWbTT17ARAiW7AKCL7f4MOZjre9YKWnTFc24q77PDlQCgntUR ix1DagGcjin5z4bXxDj/Izg= =ARzo -----END PGP SIGNATURE----- --==_Exmh_2050924116P-- From owner-idn@ops.ietf.org Mon Mar 18 21:54:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01008 for ; Mon, 18 Mar 2002 21:54:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n9em-000DvY-00 for idn-data@psg.com; Mon, 18 Mar 2002 18:47:24 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16n9el-000DvS-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 18:47:23 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id SAA11967 for ; Mon, 18 Mar 2002 18:47:22 -0800 Message-Id: <5.1.0.14.2.20020318204222.0208fe88@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Mar 2002 20:44:15 -0600 To: idn@ops.ietf.org From: Dave Crocker Subject: Re: [idn] WG last call summary In-Reply-To: <20020319002929.13911.qmail@cr.yp.to> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:29 AM 3/19/2002 +0000, Dan wrote: >I have put a huge amount of effort into evaluating the costs of various >IDN proposals. Please read http://cr.yp.to/proto/idnc3.html before you >make any more comments about what I'm trying to do. The link goes to a really delightful document. It's best line is: "In contrast, IDNC3 does not allow IDN registration until all relevant software has been upgraded and tested." All relevant software? That means all modules that might provide or receive this new type of string. I believe the current count of such modules is perhaps 100 million. That means the scheme cannot be used until all 100 million modules are changed. Nevermind that they will never all be upgraded. By the time they are, there will be another 100 million to upgrade. So to the extent that one might wonder whether Dan is entirely ignoring the pragmatic issues in transitioning a large installed base, we now have explicit text that makes clear the answer is yes. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Mar 18 22:13:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01418 for ; Mon, 18 Mar 2002 22:13:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16n9wa-000EMA-00 for idn-data@psg.com; Mon, 18 Mar 2002 19:05:48 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16n9wZ-000ELp-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 19:05:47 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2J35ft18010; Mon, 18 Mar 2002 22:05:41 -0500 (EST) Message-Id: <200203190305.g2J35ft18010@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "James Seng" cc: "Keith Moore" , "D. J. Bernstein" , idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary In-reply-to: (Your message of "Tue, 19 Mar 2002 10:34:59 +0800.") <056001c1ceee$ad303300$dd00a8c0@jamessonyviao> Date: Mon, 18 Mar 2002 22:05:40 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > It is useful technical input on the first time. > By the 353th time, someone got to ask what else are they contributing? of course once should be sufficient. some people don't realize that we don't do voting. > It is a protest and appeal against the last call. The IETF process specify > the exact process to do so in RFC2026 Section 6.5. perhaps, but this isn't a justification for ignoring valid concerns. Keith From owner-idn@ops.ietf.org Mon Mar 18 22:48:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03051 for ; Mon, 18 Mar 2002 22:48:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nARH-000EuQ-00 for idn-data@psg.com; Mon, 18 Mar 2002 19:37:31 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.35 #1) id 16nARH-000EuJ-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 19:37:31 -0800 Received: (qmail 31021 invoked by uid 1001); 19 Mar 2002 03:32:28 -0000 Date: 19 Mar 2002 03:32:28 -0000 Message-ID: <20020319033228.9732.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Pete Resnick writes: > Inability to display non-US-ASCII glyphs by legacy > applications is not a failure. Go sell a Greek user an ``internationalized domain name'' with a delta, Pete. Then tell him that most of his correspondents will see the delta as incomprehensible gobbledygook rather than a delta. See what he says. Of course, display failures are not as intolerable as interoperability failures. But they're still failures. The IDNA proposal, in attempting to limit these display failures, creates interoperability failures that would not have occurred with ASCII domain names. IDNA coauthor Adam Costello has already admitted this. Surely you agree that bounced mail is serious! ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Mon Mar 18 22:58:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03258 for ; Mon, 18 Mar 2002 22:58:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nAaS-000F5l-00 for idn-data@psg.com; Mon, 18 Mar 2002 19:47:00 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16nAaR-000F5c-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 19:46:59 -0800 Received: (qmail 30741 invoked by uid 1001); 19 Mar 2002 03:45:56 -0000 Date: 19 Mar 2002 03:45:56 -0000 Message-ID: <20020319034556.5958.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <20020318115717.W32897@iconoplex.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Valdis.Kletnieks@vt.edu writes: > As such, I have to insist that *any* IDN proposal be required to be > backwards transparent to the current 2821/2822/2045-2049 standards Putting UTF-8 into email headers right now would trigger a serious Sendmail bug, so of course I don't encourage anyone to do that. However, the Sendmail bug should be fixed as soon as possible. Do you disagree with this? Furthermore, the IETF specifications that allow 7-bit software should be fixed as soon as possible. Do you disagree with this? Or do you want these bugs to continue to plague programmers in 10 years? 20 years? 50 years? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Mon Mar 18 23:06:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03498 for ; Mon, 18 Mar 2002 23:06:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nAl2-000FJB-00 for idn-data@psg.com; Mon, 18 Mar 2002 19:57:56 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.35 #1) id 16nAl1-000FJ5-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 19:57:55 -0800 Received: (qmail 22331 invoked by uid 1001); 19 Mar 2002 03:56:53 -0000 Date: 19 Mar 2002 03:56:53 -0000 Message-ID: <20020319035653.14533.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] WG last call summary References: <20020319002929.13911.qmail@cr.yp.to> <5.1.0.14.2.20020318204222.0208fe88@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Dave Crocker writes: > I believe the current count of such modules is perhaps 100 million. If you're frightened of the upgrade in http://cr.yp.to/proto/idnc3.html, you should be terrified of the much larger upgrade in IDNA---even if we don't count the IDNA-USERNAME upgrade, the IDNA-to-UTF-8 upgrade, etc. Of course, you're also ignoring the fact that most of the IDNC3 work is being done anyway. Many modules already work with UTF-8, and new UTF-8 support is appearing all the time. > By the time they are, there will be another 100 million to upgrade. Wrong. IDNC3, just like RFC 2277, requires UTF-8 support in everything. The bulk of the work is fixing old stuff, not new stuff. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Mon Mar 18 23:09:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03548 for ; Mon, 18 Mar 2002 23:09:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nAol-000FP7-00 for idn-data@psg.com; Mon, 18 Mar 2002 20:01:47 -0800 Received: from spider.nic-se.se ([212.247.3.67]) by psg.com with esmtp (Exim 3.35 #1) id 16nAok-000FOv-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 20:01:46 -0800 Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id g2J413w17967; Tue, 19 Mar 2002 05:01:03 +0100 (CET) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Tue, 19 Mar 2002 05:01:03 +0100 (CET) From: Mats Dufberg To: "D. J. Bernstein" cc: Subject: Re: [idn] WG last call summary In-Reply-To: <20020319034556.5958.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Mar 19, 2002, 03:45 (-0000) D. J. Bernstein wrote: > Putting UTF-8 into email headers right now would trigger a serious > Sendmail bug, so of course I don't encourage anyone to do that. Putting UTF-8 into the mail header is against the mail protocol, and you know that. Any bug in sendmail is irrelevant. If your want to change the mail standard, write a draft. That draft will NOT be processed in the IDN group. > However, the Sendmail bug should be fixed as soon as possible. Do you > disagree with this? That discussion should be taken with those working on sendmail, not any IETF group. Those who are dissatisfied wiht sendmail use something else. > Furthermore, the IETF specifications that allow 7-bit software should be > fixed as soon as possible. Do you disagree with this? Write a draft. > Or do you want these bugs to continue to plague programmers in 10 years? > 20 years? 50 years? IETF has nothing to do with bugs in programs, just bugs in protocols. You know that. And how long will you plague us with your complaints about sendmail? 10 years? 20 years? -- Stick to what is relevant! Mats ---------------------------------------------------------------------- Mats Dufberg ---------------------------------------------------------------------- From owner-idn@ops.ietf.org Mon Mar 18 23:22:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03863 for ; Mon, 18 Mar 2002 23:22:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nAuM-000FXe-00 for idn-data@psg.com; Mon, 18 Mar 2002 20:07:34 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16nAuL-000FXU-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 20:07:33 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 31044 for idn@ops.ietf.org; Mon, 18 Mar 2002 22:07:10 -0600 Message-ID: <3C96B982.38C4EBBA@ehsco.com> Date: Mon, 18 Mar 2002 22:07:31 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] WG last call summary References: <3C9505E1.6326AC6C@ehsco.com> <3C951E4C.D68468A7@ehsco.com> <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> <3C9505E1.6326AC6C@ehsco.com> <20020318031526.GB8942@nicemice.net> <3C957D52.5ED14218@ehsco.com> <20020318061347.GE8942@nicemice.net> <3C95AF81.9FFE2608@ehsco.com> <20020319020705.GA24725@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > When a mail program displays a message header, it's not necessarily a > real RFC 822 message header on the screen. The mail program doesn't > promise to speak RFC 822 to the human user. 822 defines data-types which are used by multiple protocols. Nothing "speaks" 822. Rather, several distributed functions exchange data which has been formatted according to the rules specified in 822. In many places, the data can leave the messaging network entirely and then be freely reinserted. It is at this juncture that the mandatory conversion causes the breakage to occur. When you give somebody your email address, do you give them the human-friendly rendering of "Adam Costello" or do you give them the 822 email address? Will this change with IDNA? Wouldn't you stick with the 822-compliant form, knowing that the sacrosanct 822 encoding is going to work? It will only take a couple of retransmissions before you figure out that the personal-address-exchange protocol only functions with the 822 form. We know that this will happen, experience and evidence tells us so, why not skip it altogether? > The program might omit certain fields that are required, and > might include non-ASCII characters (converted from RFC 2047 encoding). > It might let me type non-ASCII characters into the Subject line of an > outgoing message. When I instruct the program to send a message, the > program will take care to send an actual RFC 822 message, doing whatever > encoding is necessary. 2047 avoids structured data-types specifically for the reasons I mention. When 2047 breaks, delivery still occurs. And when it does break, it is somewhat noticable. > We have found the crux of our disagreement. I maintain that IDNA does > *not* extend or alter any data types. Call it "replaces" if you wish, it is the same effect. The data being presented to the user is not the Message-ID that has always been presented in the same manner, those things which look URLs aren't actually URLs anymore, and so forth. Yep, that is exactly the problem. It should be pointed out here that removing the mandatory transliteration gives the collective Internet more options, not fewer options. Removing it means that those data-types which should be extended (probably email addresses) will be extended by the authoritative source if they can be fixed at all, thereby improving all of the uses for that data-type, and forcing the agents that use those data-types to think about the ramifications of those changes, and how they can provide the necessary support (SMTP, IMAP, News, and the associated messaging system parts). I mean, which would you rather have, vendors doing it different ways because there is no guidance, or having the vendors get together to decide on a common way because the standard is being changed? Conversely, if a data-type cannot be changed, well, thank goodness that this WG didn't break anything that depends on it. :/ Meanwhile, those data-types which *should not* be extended (such as Message-ID, among others) will not be extended by either us or the controlling body, meaning that no unnecessary breakage will ever occur with those data-types. Cumulatively, this flexibility equates to smoother deployment in the short run and deeper benefits in the long run. This should not be considered a set-back. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Mar 18 23:34:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04530 for ; Mon, 18 Mar 2002 23:34:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nBD2-000Fx4-00 for idn-data@psg.com; Mon, 18 Mar 2002 20:26:52 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16nBD1-000Fwe-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 20:26:51 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id NAA22648; Tue, 19 Mar 2002 13:26:35 +0900 Message-ID: <022901c1cefe$27713470$a303a8c0@bruce> From: "Bruce Thomson" To: "Mats Dufberg" , "IETF idn working group" References: Subject: Re: [idn] WG last call summary Date: Tue, 19 Mar 2002 13:25:51 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > IETF has nothing to do with bugs in programs, just bugs in protocols. You > know that. And how long will you plague us with your complaints about > sendmail? 10 years? 20 years? -- Stick to what is relevant! No, this WG has come up with a proposal which is targeted specifically at circumventing bugs in legacy implementations. If it was only a question of choosing an ideal specification and ignoring bugs, "just send UTF" would be a clear winner. Dan's comments here are perfectly relevant. Or are you saying that IDNA is needed merely because this WG doesn't have access to the particular protocols that need to be changed to do this thing right? Bruce From owner-idn@ops.ietf.org Tue Mar 19 00:00:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05208 for ; Tue, 19 Mar 2002 00:00:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nBa2-000GPq-00 for idn-data@psg.com; Mon, 18 Mar 2002 20:50:38 -0800 Received: from spider.nic-se.se ([212.247.3.67]) by psg.com with esmtp (Exim 3.35 #1) id 16nBa2-000GPk-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 20:50:38 -0800 Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id g2J4oLJ20882; Tue, 19 Mar 2002 05:50:21 +0100 (CET) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Tue, 19 Mar 2002 05:50:20 +0100 (CET) From: Mats Dufberg To: Bruce Thomson cc: IETF idn working group Subject: Re: [idn] WG last call summary In-Reply-To: <022901c1cefe$27713470$a303a8c0@bruce> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Mar 19, 2002, 13:25 (+0900) Bruce Thomson wrote: > > IETF has nothing to do with bugs in programs, just bugs in protocols. You > > know that. And how long will you plague us with your complaints about > > sendmail? 10 years? 20 years? -- Stick to what is relevant! > > No, this WG has come up with a proposal which is targeted specifically > at circumventing bugs in legacy implementations. Dan's complain was about the restriction that mail headers only may contain ASCII (7 bit). Move that to an appropriate wg. > If it was only a question of choosing an ideal specification and > ignoring bugs, "just send UTF" would be a clear winner. I do not agree. There is a specification of a host name, which sets the limit on DNS (for host names) to a-z, 0-9 and '-'. The ACE solution is also better because it breaks less systems during transition. > Or are you saying that IDNA is needed merely because this WG > doesn't have access to the particular protocols that need to be > changed to do this thing right? We have a reality, and changing to a new model will require a transition. A good protocol will respect those two factors. IETF's task is not to repair software bugs or remove limitations set by the software authors, but when writing new protocol, the IETF has to respect the reality and to a cerain extent, the effects on currently installed programs. If we would create DNS from nothing today, we would do it differently. In that case, UTF-8 would be a good candidate for the coding scheme. But we already have DNS, and that fact connot be neglected. Mats ---------------------------------------------------------------------- Mats Dufberg ---------------------------------------------------------------------- From owner-idn@ops.ietf.org Tue Mar 19 00:22:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05924 for ; Tue, 19 Mar 2002 00:22:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nBua-000Go9-00 for idn-data@psg.com; Mon, 18 Mar 2002 21:11:52 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16nBuZ-000Gnl-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 21:11:51 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16nBuX-0007Ka-00 for ; Mon, 18 Mar 2002 21:11:49 -0800 Date: Tue, 19 Mar 2002 05:11:49 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] WG last call summary Message-ID: <20020319051149.GB24725@nicemice.net> Reply-To: IETF idn working group References: <200203170320.g2H3Kut09298@astro.cs.utk.edu> <3C9426DF.15CEEBA7@ehsco.com> <20020317065817.GA867@nicemice.net> <3C9505E1.6326AC6C@ehsco.com> <20020318031526.GB8942@nicemice.net> <3C957D52.5ED14218@ehsco.com> <20020318061347.GE8942@nicemice.net> <3C95AF81.9FFE2608@ehsco.com> <20020319020705.GA24725@nicemice.net> <3C96B982.38C4EBBA@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C96B982.38C4EBBA@ehsco.com> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > When you give somebody your email address... Wouldn't you stick with > the 822-compliant form, knowing that the sacrosanct 822 encoding is > going to work? If I'm giving the address to people familiar with Latin letters, then I'd stick to the 822 form. If I'm giving the address to someone very unfamiliar with Latin letters, so much so that the probability that they fail to copy the address correctly exceeds the probability that their mail program cannot handle non-ASCII characters, then it would make sense to give them non-ASCII characters. > > I maintain that IDNA does *not* extend or alter any data types. > > Call it "replaces" if you wish, it is the same effect. The data being > presented to the user is not the Message-ID that has always been > presented in the same manner, those things which look URLs aren't > actually URLs anymore, and so forth. People commonly pass around things that are not URLs, like "www.example.com", and yet most browsers transform it into a correct URL "http://www.example.com/". It will be a similar story when people start passing around non-ASCII strings to be entered into browsers. > It should be pointed out here that removing the mandatory > transliteration gives the collective Internet more options, not fewer > options. I think "mandatory" is an overstatement. The IDNA draft says "ACE labels obtained from domain name slots SHOULD be hidden from users except when the use of the non-ASCII form would cause problems or when the ACE form is explicitly requested." I think that leaves sufficient room for application designers to exercise their own good judgement. That said, I wouldn't really care if it instead said "ACE labels obtained from domain name slots MAY be displayed to users as equivalent non-ACE labels." (And similar softening of the various recommendations that follow from it in section 6.) I don't think such a change is necessary, but I wouldn't object to it. You'll probably still face resistance from others though. AMC From owner-idn@ops.ietf.org Tue Mar 19 00:25:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06037 for ; Tue, 19 Mar 2002 00:25:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nBpj-000GiJ-00 for idn-data@psg.com; Mon, 18 Mar 2002 21:06:51 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16nBpi-000Gi8-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 21:06:50 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id OAA22810; Tue, 19 Mar 2002 14:06:46 +0900 Message-ID: <023201c1cf03$c455bf90$a303a8c0@bruce> From: "Bruce Thomson" To: "Mats Dufberg" , "IETF idn working group" References: Subject: Re: [idn] WG last call summary Date: Tue, 19 Mar 2002 14:06:02 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mats Dufberg: > We have a reality, and changing to a new model will require a transition. > A good protocol will respect those two factors. > I agree. > IETF's task is not to repair software bugs or remove limitations set by > the software authors, but when writing new protocol, the IETF has to > respect the reality and to a cerain extent, the effects on currently > installed programs. > Right. > If we would create DNS from nothing today, we would do it differently. In > that case, UTF-8 would be a good candidate for the coding scheme. But we > already have DNS, and that fact connot be neglected. > Perhaps you mean sendmail, not DNS? DNS is already 8-bit clean and works fine with UTF. Sendmail and various other apps apparently don't, and that's what Dan was referring to. That's why I couldn't understand why you said he was off the subject. He is right that this whole project is about the tradeoffs in costs of fixing things and costs incurred when things break. Where you disagree is on the resolution of those tradeoffs. Bruce From owner-idn@ops.ietf.org Tue Mar 19 00:36:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06287 for ; Tue, 19 Mar 2002 00:36:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nCAy-000H8O-00 for idn-data@psg.com; Mon, 18 Mar 2002 21:28:48 -0800 Received: from spider.nic-se.se ([212.247.3.67]) by psg.com with esmtp (Exim 3.35 #1) id 16nCAx-000H8F-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 21:28:47 -0800 Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id g2J5SXA13559; Tue, 19 Mar 2002 06:28:33 +0100 (CET) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Tue, 19 Mar 2002 06:28:32 +0100 (CET) From: Mats Dufberg To: Bruce Thomson cc: IETF idn working group Subject: Re: [idn] WG last call summary In-Reply-To: <023201c1cf03$c455bf90$a303a8c0@bruce> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Mar 19, 2002, 14:06 (+0900) Bruce Thomson wrote: > Perhaps you mean sendmail, not DNS? DNS is already 8-bit clean and works > fine with UTF. No, I'm talking about DNS. -- No, I don't agree with your statement about DNS. -- Hey, should we repeat the entire discussion aobut DNS, from which most of us came to the conclusion that ACE was the best solution? :-) > Sendmail and various other apps apparently don't, and that's what Dan > was referring to. That's why I couldn't understand why you said he was > off the subject. The mail protocol sets a limit to 7 bits (independently of any bugs in sendmail). Is the mail protocol a topic of this working group? Mr. Bernstein has a hang on some bugs in sendmail (or are they just limitations due to the design), and he repeats that i every second mail. He should discuss those bugs with the sendmail people, and possibly with those who have installed his own MTA. It does not belong to any of the IETF mail lists I belong to. > He is right that this whole project is about the tradeoffs in costs of > fixing things and costs incurred when things break. Where you disagree > is on the resolution of those tradeoffs. I do not agree with your conclusion. Mats ---------------------------------------------------------------------- Mats Dufberg ---------------------------------------------------------------------- From owner-idn@ops.ietf.org Tue Mar 19 01:00:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06761 for ; Tue, 19 Mar 2002 01:00:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nCWh-000Hb0-00 for idn-data@psg.com; Mon, 18 Mar 2002 21:51:15 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16nCWg-000Hau-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 21:51:14 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id OAA23040; Tue, 19 Mar 2002 14:51:10 +0900 Message-ID: <024101c1cf09$f81d2740$a303a8c0@bruce> From: "Bruce Thomson" To: "Mats Dufberg" , "IETF idn working group" References: Subject: Re: [idn] WG last call summary Date: Tue, 19 Mar 2002 14:50:26 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mats Dufberg wrote: > > He is right that this whole project is about the tradeoffs in costs of > > fixing things and costs incurred when things break. Where you disagree > > is on the resolution of those tradeoffs. > > I do not agree with your conclusion. > Really? I was hoping that we could at least agree on this. OK, let me analyze the factors that might possibly be relevant to our decision. 1. Cost vs. benefits (including time to market, etc.) 2. The fact that many people want to do it a particular way. 3. Our sense that a particular solution is more elegant or nice. 4. Special interest groups. 5. The structure of the IETF decision-making process that mandates that we do things in a way not dictated by 1 through 4. Have I left out any possibilities here? I am just trying to say that number 1 is the main determining factor and probably has led to us being where we are now. And that the final specification will logically be justifiable in these terms. Bruce From owner-idn@ops.ietf.org Tue Mar 19 02:04:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12798 for ; Tue, 19 Mar 2002 02:04:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nDQ0-000Iej-00 for idn-data@psg.com; Mon, 18 Mar 2002 22:48:24 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.35 #1) id 16nDPz-000Ied-00 for idn@ops.ietf.org; Mon, 18 Mar 2002 22:48:23 -0800 Received: (qmail 16658 invoked by uid 1001); 19 Mar 2002 06:47:20 -0000 Date: 19 Mar 2002 06:47:20 -0000 Message-ID: <20020319064720.24734.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] WG last call summary References: <1983.1016383041@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Robert Elz writes: > All the work here is for the benefit of other protocols, the DNS > (which never had a problem with domain names in any char set whatever) > is being mangled to make life easier for other protocols that really > should have been fixed years ago. Exactly. The IDNA documents claim, in attempting to justify IDNA's archaic 7-bit character encoding, that 8-bit names would break DNS servers. There is not a shred of evidence for that claim. See the message from the BIND company to the IDN mailing list dated Mon, 12 Mar 2001 11:39:29 +1100. The real problems are the 8-bit bugs in some HTTP clients, some SMTP clients, and Sendmail. See http://pi.cr.yp.to. DNS is not the issue. Of course, IDNA demands an upgrade from every client in the world, including clients that already work fine with UTF-8: the MacOS X version of Internet Explorer 5.1, for example, and many UNIX programs running under the UTF-8 xterm. Even worse, we're going to have to go through _another_ massive upgrade for mailbox names and for every other internationalization target. How much pain is the IETF willing to inflict upon the universe before admitting that 7-bit software is obsolete? Is it really so hard to understand how much the users will benefit from settling on UTF-8? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Tue Mar 19 06:31:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19604 for ; Tue, 19 Mar 2002 06:31:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nHOG-000NX2-00 for idn-data@psg.com; Tue, 19 Mar 2002 03:02:52 -0800 Received: from 213.234.81.127.adsl.toe.tiscali.no ([213.234.81.127] helo=nebula.lan) by psg.com with esmtp (Exim 3.35 #1) id 16nHOE-000NWt-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 03:02:51 -0800 Received: from localhost (flax@localhost) by nebula.lan (8.11.4/8.11.4) with ESMTP id g2JB64E31184; Tue, 19 Mar 2002 12:06:05 +0100 Date: Tue, 19 Mar 2002 12:06:04 +0100 (CET) From: Thor Harald Johansen X-X-Sender: Reply-To: Thor Harald Johansen To: "D. J. Bernstein" cc: , , , Subject: Re: [idn] WG last call summary In-Reply-To: <20020319034556.5958.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > Furthermore, the IETF specifications that allow 7-bit software should be > fixed as soon as possible. Do you disagree with this? > Or do you want these bugs to continue to plague programmers in 10 years? > 20 years? 50 years? I'm having trouble understanding why we're still using these old protocols. Does a standardized transparent (in the "binary" sense of the word) mail protocol with built-in support for multi-part messages exist? Then why isn't it being implemented all over the place? It would make things a whole lot simpler: no UTF-8 or MIME encoding of international characters would be nessecary (use Unicode), binary attachments would take up significantly less space and Unicode IDNs could easily be supported. -- Thor Harald Johansen From owner-idn@ops.ietf.org Tue Mar 19 06:45:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19743 for ; Tue, 19 Mar 2002 06:45:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nHoU-000O0a-00 for idn-data@psg.com; Tue, 19 Mar 2002 03:29:58 -0800 Received: from [211.254.82.194] (helo=spsoft.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16nHoT-000O01-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 03:29:57 -0800 Received: (from newcat@localhost) by spsoft.co.kr (8.10.0/8.10.0) id g2JBTBk17377; Tue, 19 Mar 2002 20:29:11 +0900 Date: Tue, 19 Mar 2002 20:29:11 +0900 From: YangWoo Ko To: Thor Harald Johansen Cc: "D. J. Bernstein" , idn@ops.ietf.org Subject: Re: [idn] WG last call summary Message-ID: <20020319202911.B16970@spsoft.co.kr> References: <20020319034556.5958.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-idn@ops.ietf.org Precedence: bulk [I removed iesg, iab, ...] (Short term) solution on Internet tends to be widespread as legacy which will hardly obsoleted without fundamental flaws which prevent users from using it anymore. On Tue, Mar 19, 2002 at 12:06:04PM +0100, Thor Harald Johansen wrote: > > Furthermore, the IETF specifications that allow 7-bit software should be > > fixed as soon as possible. Do you disagree with this? > > > Or do you want these bugs to continue to plague programmers in 10 years? > > 20 years? 50 years? > > I'm having trouble understanding why we're still using these old > protocols. Does a standardized transparent (in the "binary" sense of the > word) mail protocol with built-in support for multi-part messages exist? > Then why isn't it being implemented all over the place? > > It would make things a whole lot simpler: no UTF-8 or MIME encoding of > international characters would be nessecary (use Unicode), binary > attachments would take up significantly less space and Unicode IDNs could > easily be supported. > -- > Thor Harald Johansen -- /*------------------------------------------------ YangWoo Ko : newcat@spsoft.co.kr We Invent Enterprise Software Solutions and Make You Secure & Powerful. ------------------------------------------------*/ From owner-idn@ops.ietf.org Tue Mar 19 07:46:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20571 for ; Tue, 19 Mar 2002 07:46:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nItQ-000PNQ-00 for idn-data@psg.com; Tue, 19 Mar 2002 04:39:08 -0800 Received: from fermat.nation.liu.se ([130.236.242.26]) by psg.com with esmtp (Exim 3.35 #1) id 16nItP-000PNK-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 04:39:07 -0800 Received: from localhost (mag@localhost) by fermat.nation.liu.se (8.11.6/8.11.6) with ESMTP id g2JCd3L12228 for ; Tue, 19 Mar 2002 13:39:04 +0100 Date: Tue, 19 Mar 2002 13:39:03 +0100 (CET) From: C C Magnus Gustavsson To: idn@ops.ietf.org Subject: [idn] Another solution? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk I've been thinking about a not yet mentioned (AFAIK) solution for a while but dismissed it as too ambitious. Yet, the longer we keep going without getting there, the more reasonable it seems to me. I suppose the respons will be "too much work, too late" but it could be worth considering at least. We could consider wiping the slate clean and design a new protocol. (Bear with me just a little while longer.) Let's call it e g INS (for Internet Name System or International Names System) to distinguish it from DNS and ask IANA to assign, say, port 40 for it's use. We would not only be able to introduce non-ASCII domain names using UTF-8 in a nice, clean fashion and in accordance with RFC 2277. We could double (or triple) the maximal allowed length for domain names and have four times the number of flags. We could introduce a version number in the protocol to make future changes easier and use experience with EDNS to make it easier to expand in the future if needed. We could replace SRV records (RFC 2782) with a cleaner and better solution, introducing QSERV and QPROTO fields in the queries. And so on. All in all, we could clean up and improve the current DNS standard significantly. It seems we have a golden opportunity here. Nobody will use a new protocol to get SRV records or longer domain names, but perhaps to get international domain names. Does something like this really have to take that long time to get consensus on, especially compared to the time already used without reaching consensus so far? If we stick to basic DNS principles and simply change the format of RRs, I think we already have a pretty good idea (gained from the past years) about what needs to be done; as long as we are careful and don't try to build a completely new system but focus on cleaning up the old one. In contrast to IPv6, this could very well be used in parallell with the old one and handled by the same software. Magnus From owner-idn@ops.ietf.org Tue Mar 19 07:47:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20585 for ; Tue, 19 Mar 2002 07:47:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nIu7-000PNh-00 for idn-data@psg.com; Tue, 19 Mar 2002 04:39:51 -0800 Received: from 213.234.81.127.adsl.toe.tiscali.no ([213.234.81.127] helo=nebula.lan) by psg.com with esmtp (Exim 3.35 #1) id 16nIu6-000PNb-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 04:39:50 -0800 Received: from localhost (flax@localhost) by nebula.lan (8.11.4/8.11.4) with ESMTP id g2JCgbG31614; Tue, 19 Mar 2002 13:42:37 +0100 Date: Tue, 19 Mar 2002 13:42:37 +0100 (CET) From: Thor Harald Johansen X-X-Sender: Reply-To: Thor Harald Johansen To: YangWoo Ko cc: Thor Harald Johansen , "D. J. Bernstein" , Subject: Re: [idn] WG last call summary In-Reply-To: <20020319202911.B16970@spsoft.co.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > (Short term) solution on Internet tends to be widespread as legacy > which will hardly obsoleted without fundamental flaws which prevent > users from using it anymore. Of course, but such a transition would go unnoticed if done correctly. Example: A special SMTP handshake wich would be ignored by old implementations (servers or clients) and acted upon by newer software. The end user wouldn't notice anything but an improvement in performance on some servers. When the special handshake would go into effect, the sockets on both sides would go from being line-based to becoming transparent. The protocol could be based on single byte commands, length dwords and such, to allow for content independent encapsulation with a non-existant encoding overhead. New servers would use Unicode for internal representation of the plain text content of messages. Whenever mail would be exchanged with an old server, one way or the other, the new server would do the nessecary encoding/decoding and/or encapsulation. The first servers to be upgraded would barely use the new protocol. The handshake would simply not generate a reply at any server or client. This has to be expected and accepted during the transition from one protocol to another. The effect of the new protocol would be the gradual improvement in effective bandwidth usage on the Internet. Another idea would be the addition of compression. One (or the implementation) could choose to compress individual message parts, individual messages or the entire content of the inbox of a mail account. This would also improve bandwidth usage, and have a noticable effect on servers exchanging large amounts of mail. I can only see advantages. -- Thor Harald Johansen From owner-idn@ops.ietf.org Tue Mar 19 12:44:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28728 for ; Tue, 19 Mar 2002 12:44:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nNQS-000BYw-00 for idn-data@psg.com; Tue, 19 Mar 2002 09:29:32 -0800 Received: from med31.ndl.net.nu ([216.133.64.31] helo=Thinkpad) by psg.com with esmtp (Exim 3.35 #1) id 16nNQR-000BYq-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 09:29:31 -0800 Received: from Thinkpad.mail.nic.nu ([127.0.0.1]) by Thinkpad with Microsoft SMTPSVC(6.0.2600.1); Tue, 19 Mar 2002 12:29:22 -0500 Message-Id: <5.1.0.14.2.20020319122742.04367598@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Mar 2002 12:29:21 -0500 To: Mats Dufberg , Bruce Thomson From: "J. William Semich" Subject: Re: [idn] WG last call summary Cc: IETF idn working group In-Reply-To: References: <023201c1cf03$c455bf90$a303a8c0@bruce> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Mar 2002 17:29:22.0335 (UTC) FILETIME=[9BAD22F0:01C1CF6B] Sender: owner-idn@ops.ietf.org Precedence: bulk Correct for RFC 1035 and the BIND 9 implementation of it at least. Bill Semich .NU Domain On Mar 19, 2002, 14:06 (+0900) Bruce Thomson wrote: >DNS is already 8-bit clean and works fine with UTF. From owner-idn@ops.ietf.org Tue Mar 19 13:28:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29726 for ; Tue, 19 Mar 2002 13:28:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nO90-000CHj-00 for idn-data@psg.com; Tue, 19 Mar 2002 10:15:34 -0800 Received: from bach.iis.sinica.edu.tw ([140.109.18.167]) by psg.com with esmtp (Exim 3.35 #1) id 16nO8z-000CHc-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 10:15:33 -0800 Received: from newage (newage.iis.sinica.edu.tw [140.109.18.183]) by bach.iis.sinica.edu.tw (8.11.1/8.11.1) with SMTP id g2JIlcG48339; Wed, 20 Mar 2002 02:47:39 +0800 (CST) (envelope-from cdns@bach.iis.sinica.edu.tw) Message-ID: <012a01c1cf73$68a161c0$b7126d8c@twnet.iis.sinica.edu.tw> From: "cdns-jwlin" To: "Pete Resnick" Cc: , , References: Subject: Re: [idn] WG last call summary Date: Wed, 20 Mar 2002 02:25:11 +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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit For people who don't know Han, there is not differet between the ACEs and Hans. But the case is not suitable for us who use Chinese or other non-ASCII glyphs. There is much different to see a Han or a ACE!! Your criteria for success are too low for us. ----- Original Message ----- From: "Pete Resnick" To: "D. J. Bernstein" Cc: ; ; ; Sent: Tuesday, March 19, 2002 4:38 AM Subject: Re: [idn] WG last call summary > On 3/18/02 at 6:20 AM +0000, D. J. Bernstein wrote: > > >``Internationalized domain names are a failure if non-ASCII glyphs > >don't appear on the screen.'' What kind of idiot would disagree with > >that? > > I'm one of those kind of idiots. I expect that there will be many > applications that won't put non-US-ASCII glyphs on the screen at the > get-go. The three criteria for success (for me) are: > > 1. Applications, if they are properly coded, *can* display non-US-ASCII > glyphs. > 2. All of the new domain names can appear (in some form) in legacy > applications without breaking those applications. > 2. All applications, legacy or otherwise, are able to resolve new > domain names. If there exists an domain name (and I'm referring to > the logical entity, not some particular glyph representation of it) > that a legacy application can't address, that's a failure. > > That is to say, balkanization during the transition is a failure of > the protocol. Inability to display non-US-ASCII glyphs by legacy > applications is not a failure. > > >Obviously the IDNA authors understand the desire to put non-ASCII > >glyphs on the screen. > > To what is this a response? Has anyone claimed that it is > *undesireable* to display non-US-ASCII glyphs? > > >* Preventing _all_ the interoperability problems means turning off > >conversion for _every_ display subject to IDNA-unaware piping, > >IDNA-unaware copy-and-paste, etc.---and that's a massive failure to > >achieve the IDN goal. > > I cannot disagree more; this is not a massive failure. Unless of > course MIME has also been a massive failure to send around binary > attachments. In the same way, if I use an e-mail client that decodes > base64 into binary and pipes the output to a program that expects > US-ASCII input, I've done something broken. If I decode IDNA names > and pipe them to a program that expects US-ASCII domain names, I have > again done something broken. And in IDNA, we do MIME one better: The > undecoded IDNA names are usable, even if they aren't pretty. A base64 > encoded file is near useless to anything without decoding. > > >* The proposal on the table, IDNA, does not disable these > >conversions. It explicitly encourages these conversions. > > Textual support? 6.1 and 6.4 seem to give lots of reasons not to do > the conversions. > > pr > -- > Pete Resnick > QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > > > > From owner-idn@ops.ietf.org Tue Mar 19 14:43:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01908 for ; Tue, 19 Mar 2002 14:43:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nP6U-000DHk-00 for idn-data@psg.com; Tue, 19 Mar 2002 11:17:02 -0800 Received: from spider.nic-se.se ([212.247.3.67]) by psg.com with esmtp (Exim 3.35 #1) id 16nP6T-000DHS-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 11:17:01 -0800 Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id g2JJGiL09021; Tue, 19 Mar 2002 20:16:44 +0100 (CET) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Tue, 19 Mar 2002 20:16:44 +0100 (CET) From: Mats Dufberg To: Bruce Thomson cc: IETF idn working group Subject: Re: [idn] WG last call summary In-Reply-To: <024101c1cf09$f81d2740$a303a8c0@bruce> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Mar 19, 2002, 14:50 (+0900) Bruce Thomson wrote: > > > He is right that this whole project is about the tradeoffs in costs of > > > fixing things and costs incurred when things break. Where you disagree > > > is on the resolution of those tradeoffs. > > > > I do not agree with your conclusion. > > > > Really? I was hoping that we could at least agree on this. OK, let me > analyze the factors that might possibly be relevant to our decision. I was probably too harsh. :-) Yes, we all (?) agree that any solution will be a compromise based on different factors such as the ones you mention: > 1. Cost vs. benefits (including time to market, etc.) > 2. The fact that many people want to do it a particular way. > 3. Our sense that a particular solution is more elegant or nice. > 4. Special interest groups. > 5. The structure of the IETF decision-making process that mandates > that we do things in a way not dictated by 1 through 4. 6. The current use of current protocol. 7. The strictness of current protocol. Mats ---------------------------------------------------------------------- Mats Dufberg ---------------------------------------------------------------------- From owner-idn@ops.ietf.org Tue Mar 19 14:57:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02279 for ; Tue, 19 Mar 2002 14:57:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nPPi-000Db1-00 for idn-data@psg.com; Tue, 19 Mar 2002 11:36:54 -0800 Received: from spider.nic-se.se ([212.247.3.67]) by psg.com with esmtp (Exim 3.35 #1) id 16nPPh-000Dav-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 11:36:53 -0800 Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id g2JJaZK10031; Tue, 19 Mar 2002 20:36:36 +0100 (CET) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Tue, 19 Mar 2002 20:36:35 +0100 (CET) From: Mats Dufberg To: "J. William Semich" cc: Bruce Thomson , IETF idn working group Subject: Re: [idn] WG last call summary In-Reply-To: <5.1.0.14.2.20020319122742.04367598@mail.nic.nu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Mar 19, 2002, 12:29 (-0500) J. William Semich wrote: > Correct for RFC 1035 and the BIND 9 implementation of it at least. (...) > On Mar 19, 2002, 14:06 (+0900) Bruce Thomson wrote: > > >DNS is already 8-bit clean and works fine with UTF. If you by DNS only consider the transport in DNS packets, DNS can handle any 8 bit codes. Only ASCII characters are defined, which means that high octetts are are undefined. If you by DNS include host name restrictions, restrictions in other protocols, current usage and display, the set of allowed characters is far more restricted. My conclusion is that DNS is not 8 bit clean. One problem of DNS is that the defintion of the protocol is strict, and that the usage has not been reflected into the protocol. Mats ---------------------------------------------------------------------- Mats Dufberg ---------------------------------------------------------------------- From owner-idn@ops.ietf.org Tue Mar 19 17:56:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07130 for ; Tue, 19 Mar 2002 17:56:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nSF0-000GIg-00 for idn-data@psg.com; Tue, 19 Mar 2002 14:38:02 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.35 #1) id 16nSEz-000GIU-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 14:38:01 -0800 Received: from ns.jck.com ([209.187.148.211] helo=Klensin-VAIO.ietf53.cw.net) by bs.jck.com with esmtp (Exim 3.35 #1) id 16nSEp-00001s-00; Tue, 19 Mar 2002 22:37:52 +0000 Date: Tue, 19 Mar 2002 17:37:48 -0500 From: John C Klensin To: "J. William Semich" , Mats Dufberg , Bruce Thomson cc: IETF idn working group Subject: Re: [idn] WG last call summary Message-ID: <2057226.1016559468@localhost> In-Reply-To: <5.1.0.14.2.20020319122742.04367598@mail.nic.nu> References: <5.1.0.14.2.20020319122742.04367598@mail.nic.nu> X-Mailer: Mulberry/2.2.0b3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Tuesday, 19 March, 2002 12:29 -0500 "J. William Semich" wrote: > Correct for RFC 1035 and the BIND 9 implementation of it at > least. Well, we can keep repeating this until it becomes true, water flies uphill, and other convenient things happen. However, a careful reading of RFC 1035 is illuminating: (i) It requires that all character strings (explicitly including labels and domain names, not just "host names") be compared in a case-insensitive manner (section 2.3.3). As this working group has discovered multiple times now, case-insensitivity is not precisely defined for many non-ASCII scripts. And, in particular, there is no simple operation (i.e., not requiring mapping tables) that implements case-insensitive mapping for arbitrary UTF-8 strings. (ii) While it provides that "non-alphabetic codes must match exactly" (end of section 3.1), it would be quite a stretch to argue that the characters of, say, Greek are "non-alphabetic". In any event, one can't just put binary information in there without knowing whether it is to be compared case-insensitively (whatever that means) or absolutely. And RFC 1034 strongly implies that binary information can be used only with new RR types (or, presumably, with new Classes, not in the existing RR types and classes. john From owner-idn@ops.ietf.org Tue Mar 19 20:44:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09938 for ; Tue, 19 Mar 2002 20:44:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nUuT-000Iik-00 for idn-data@psg.com; Tue, 19 Mar 2002 17:29:01 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16nUuT-000Iie-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 17:29:01 -0800 Received: (qmail 13501 invoked by uid 1001); 20 Mar 2002 01:25:48 -0000 Date: 20 Mar 2002 01:25:48 -0000 Message-ID: <20020320012548.20688.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] WG last call summary References: <5.1.0.14.2.20020319122742.04367598@mail.nic.nu> <2057226.1016559468@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk John C Klensin writes: > Well, we can keep repeating this until it becomes true, water > flies uphill, and other convenient things happen. There is no excuse for 8-bit failures under the DNS specifications. More importantly, there is no evidence of 8-bit failures in real DNS servers. > As this working group has discovered multiple times now, > case-insensitivity is not precisely defined for many non-ASCII > scripts. RFC 1034 says ``case-insensitive manner, assuming an ASCII character set.'' The obvious interpretation, and the interpretation universally adopted by DNS cache implementors, is that (1) bytes 65-90 are treated identically to bytes 97-122 respectively and (2) there are no other equivalences. If the wording isn't clear enough for non-implementors, perhaps it could be improved, but that wouldn't justify your false claims that DNS has problems with 8-bit names. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Tue Mar 19 21:50:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11883 for ; Tue, 19 Mar 2002 21:50:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nW0G-000Jex-00 for idn-data@psg.com; Tue, 19 Mar 2002 18:39:04 -0800 From: "jw-lin" To: "Doug Ewell" Cc: Subject: Re: [idn] WG last call summary Date: Wed, 20 Mar 2002 02:18:29 +0800 MIME-Version: 1.0 Content-Type: text/plain; Message-Id: charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-idn@ops.ietf.org Precedence: bulk ----- Original Message ----- From: "Doug Ewell" To: "D. J. Bernstein" Cc: Sent: Tuesday, March 19, 2002 12:44 AM Subject: Re: [idn] WG last call summary > Let me try again, for what I expect is the last time: > > HUNDREDS of people who have been told to write a letter, about an issue > they may know nothing at all about, and who have been handed the exact > text of the letter, such that they merely need to sign their names and > send it, does NOT indicate a legitimate technical concern on the part of > HUNDREDS of people. It indicates that HUNDREDS of people are capable of > following instructions. > We are not only capable of clicking a buttom on the web page. We are not robots. We've read the page carefully. Please don't think it was a joke to do that. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-idn@ops.ietf.org Tue Mar 19 21:50:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11895 for ; Tue, 19 Mar 2002 21:50:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nW0X-000Jf8-00 for idn-data@psg.com; Tue, 19 Mar 2002 18:39:21 -0800 From: Paul Robinson To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Subject: Re: [idn] WG last call summary Message-ID: <20020319204407.M32897@iconoplex.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Date: Tue, 19 Mar 2002 18:39:21 -0800 On Mar 19, "D. J. Bernstein" wrote: > Paul Robinson writes: > > Something *should* be done, but your argument has a hint of > > 'I never want anything done, ever' about it, which is putting people off. > > I have put a huge amount of effort into evaluating the costs of various > IDN proposals. Please read http://cr.yp.to/proto/idnc3.html before you > make any more comments about what I'm trying to do. I stand by my original statement. Something should be done, but your document make you look like a typical whiner - you point out all the problems, but offer no solutions to some of the problems you raise. The solutions you do offer will take at least 4 years IMHO to be effective, and your phase 2 will actually INTRODUCE more problems, as well as allowing the continuation of other problems you raise. > You may be aware that I'm the author of the mail software with the > Internet's largest increase in SMTP-server deployment over the past 18 > months (reaching #2 in total deployment, behind only Sendmail), and the > DNS software with the Internet's largest increase in domain-name > deployment over the past 18 months (reaching #2 in total deployment, > behind only BIND). My programs relay 8-bit data without trouble, even > though certain people obviously don't understand why this is important. I know who you are. I know your software. I have spent many hours looking at your code. It's why I'm suspicious of anything you ever write or say. Don't get me wrong, I'm not lacking in respect for some of the things you've done, but I think you're shooting yourself in the foot with the way you'er going about this. I don't want to have an argument with you, but you're approaching this from the wrong angle. All very wrong. It's what you do, and it makes sense to you, but shouting at everybody THAT THEY'RE ALL WRONG AND IT MUST ALL STOP RIGHT NOW OR ELSE THE WORLD WILL END AND MAIL WILL BREAK is not the way to get IDNA fixed. Perhaps expanding out IDNC3 to something more than 'these pieces of software need to be 8-bit clean and then we start registration' might be somewhere to head next... > I want internationalized domain names (and mailbox names and so on) to > work. But I can't support the IDNA proposal; IDNA is a disaster. I also > can't accept having _any_ protocol move forward over so many objections. > Even the strongest desire to _do something_ is less important than the > requirement to obtain consensus for any change. Don't you understand that to get what you want, all Unix boxen have to be *completely* 8-bit OK, all MS boxen have to be *completely* 8-bit OK and a good 20% of sites out there will just have to shut down ops permanently? How are you proposing to display alpha-ol.com on a VT100? Had you not considered (and excuse me if I'm being dumb here), that just modifying a DNS resolver to understnad PunyCode might just be a nice short cut? That perhaps, just maybe, software that recognises e-mail addresses as being any continuous text with @ in them, and URLs as beginning http:// is going to be able to just throw a string down to a resolver that knows that it's doing? And that maybe replacing the DNS resolver on all the machine s out there to be able to do lookups with PunyCode might be a TAD more realistic than trying to get EVERYTHING, EVERYWHERE to be good with 8-bit? I must be missing something here... I've *got* to be missing something here... please, somebody tell me what it is... -- Paul Robinson From owner-idn@ops.ietf.org Tue Mar 19 21:50:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11907 for ; Tue, 19 Mar 2002 21:50:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nW11-000JhG-00 for idn-data@psg.com; Tue, 19 Mar 2002 18:39:51 -0800 Date: Tue, 19 Mar 2002 20:57:33 +0000 From: Paul Robinson To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Subject: Re: [idn] WG last call summary Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: On Mar 19, "D. J. Bernstein" wrote: > Go sell a Greek user an ``internationalized domain name'' with a delta, > Pete. Then tell him that most of his correspondents will see the delta > as incomprehensible gobbledygook rather than a delta. See what he says. OK, scenario 1: You tell him that although it's gobbledygook to people without greek alphabet support, it will still work. It's not convenient, but it WILL work. Guaranteed. For his business colleagues and friends in Greece, who DO have the latest and greatest software, it will display as a delta. His ISP hasn't had to upgrade, and everybody in the world can use his domain - eventually they will see it as a delta as well, but for now they see it as an encoded string they can still use no problem. Scenario 2: Oops, sorry, our mistake, it's NOT gobbledygook, it's prefectly fine. For everybody in Greece. Unfortunately, his bank in the UK can't understand his e-mail address because the S/360 coders haven't got time to upgrade all the systems and applications software. His family won't be able to send him mail through systems that are running proprietary or legacy mail applications because they don't understand this 8-bt stuff. When he's abroad, his website and e-mail address may be useless. But it's OK, because it's a CLEAN implementation and a great protocol, and everybody else will catch up sometime in the next 4-10 years. Until then, he has to get a 'normal' domain to see himself over. > Of course, display failures are not as intolerable as interoperability > failures. But they're still failures. And they are failures for OS developers and application developers. Not the IETF. Not for the IDNA WG. Not for anybody who wants to get IDNs through. Not for the people who don't want to have to re-write the MTA on the PDP they have running in the back office. Not for people who want to have to deal with another SMTP spec change. The only problem as I see it, is that until software that deals with IDN knows how to display PunyCode properly, people will see some crap on the screen. What you are proposing IS introducing an interoperability failure, which through your own admission is worse than a display failure. > Surely you agree that bounced mail is serious! Which of these is easier to implement: 1. An updated DNS resolver 2. Making every piece of software and display device that might ever have to deal with IDNs capable of handling UTF-8? If you were IT director of a large firm, and you had a choice as to which to roll out, which would you choose? -- Paul Robinson From owner-idn@ops.ietf.org Tue Mar 19 23:35:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14718 for ; Tue, 19 Mar 2002 23:35:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nXc4-000L2t-00 for idn-data@psg.com; Tue, 19 Mar 2002 20:22:12 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16nXc3-000L2k-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 20:22:11 -0800 Message-ID: <006e01c1cfc7$216ede00$0f01a8c0@EDMON15> From: "Edmon Chung" To: References: Subject: [idn] Is ACE really "IDN"? Date: Tue, 19 Mar 2002 23:24:29 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I guess the fundamental question is whether ACE is really "IDN"? Is not ACE just an ugly mask slapped on to the DNS to allow clients to fake out the user in that they are getting a multilingual domain name, but in fact, all they got from the DNS operators is a string of uninteligible ASCII characters? Also remember that with the introduction of ACE, we are effectively creating an "alternative system" to the DNS! Cause now we are saying that (for the following example imagine, xx--ace = a multilingual label ) - xx--ace is NOT really xx--ace as you see it, but it really is - OR is the same as xx--ace Either way, it means that we have fundamentally changed the concept of a "unique" DNS name. All the while risking that the solution is not even solving the IDN problem. So what do you tell the customer they got? An ASCII String? or a Multilingual Domain name? Or do you say its a Buy one Get one Free?! Here is my thought: ACE is an easier route for server operators (transport), and therefore is a good intermediary solution towards IDN for servers; Just use 8-bit is an easier route for users and client apps (display), and therefore is a good intermediary solution towards IDN for clients. Why cant we go both routes and layout a roadmap for an eventual convergence with a protocol change that utilizes 8bit data? Edmon ----- Original Message ----- From: "Paul Robinson" To: ; ; ; Sent: Tuesday, March 19, 2002 3:57 PM Subject: Re: [idn] WG last call summary > On Mar 19, "D. J. Bernstein" wrote: > > > Go sell a Greek user an ``internationalized domain name'' with a delta, > > Pete. Then tell him that most of his correspondents will see the delta > > as incomprehensible gobbledygook rather than a delta. See what he says. > > OK, scenario 1: > > You tell him that although it's gobbledygook to people without greek > alphabet support, it will still work. It's not convenient, but it WILL work. > Guaranteed. For his business colleagues and friends in Greece, who DO have > the latest and greatest software, it will display as a delta. His ISP hasn't > had to upgrade, and everybody in the world can use his domain - eventually > they will see it as a delta as well, but for now they see it as an encoded > string they can still use no problem. > > Scenario 2: > > Oops, sorry, our mistake, it's NOT gobbledygook, it's prefectly fine. For > everybody in Greece. Unfortunately, his bank in the UK can't understand his > e-mail address because the S/360 coders haven't got time to upgrade all the > systems and applications software. His family won't be able to send him mail > through systems that are running proprietary or legacy mail applications > because they don't understand this 8-bt stuff. When he's abroad, his website > and e-mail address may be useless. But it's OK, because it's a CLEAN > implementation and a great protocol, and everybody else will catch up > sometime in the next 4-10 years. Until then, he has to get a 'normal' domain > to see himself over. > > > Of course, display failures are not as intolerable as interoperability > > failures. But they're still failures. > > And they are failures for OS developers and application developers. Not the > IETF. Not for the IDNA WG. Not for anybody who wants to get IDNs through. > Not for the people who don't want to have to re-write the MTA on the PDP > they have running in the back office. Not for people who want to have to > deal with another SMTP spec change. The only problem as I see it, is that > until software that deals with IDN knows how to display PunyCode properly, > people will see some crap on the screen. What you are proposing IS > introducing an interoperability failure, which through your own admission is > worse than a display failure. > > > Surely you agree that bounced mail is serious! > > Which of these is easier to implement: > > 1. An updated DNS resolver > 2. Making every piece of software and display device that might ever have to > deal with IDNs capable of handling UTF-8? > > If you were IT director of a large firm, and you had a choice as to which to > roll out, which would you choose? > > -- > Paul Robinson > > > > From owner-idn@ops.ietf.org Tue Mar 19 23:35:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14731 for ; Tue, 19 Mar 2002 23:35:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nXWD-000KxL-00 for idn-data@psg.com; Tue, 19 Mar 2002 20:16:09 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16nXWC-000KxF-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 20:16:08 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id NAA27068; Wed, 20 Mar 2002 13:15:49 +0900 Message-ID: <02cd01c1cfc5$cad86210$a303a8c0@bruce> From: "Bruce Thomson" To: "Paul Robinson" , "IETF idn working group" References: Subject: Re: [idn] WG last call summary Date: Wed, 20 Mar 2002 13:14:55 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (Deleting ccs to iesg, etc. I really don't think we should be bombarding their inbox.) > If you were IT director of a large firm, and you had a choice as to which to > roll out, which would you choose? > Frankly, if I was the IT director of a large firm, I wouldn't roll it out in the near future, in either scenario. There's just too much missing that won't be filled in for a few years. We need a transition period in which the multilingual-capable people of the world who also like to try out leading-edge technology play around with it for their own amusement, presumably while using legacy domains for their main mail/websites. e-mail itself only went mainline within the past very few years. Before that, people would say things like, "well, I would like to use e-mail maybe, but if I pass out my e-mail address on my business card, I would have to check my mail every day and I can't be bothered." The pioneers played with it (some quite profitably, no doubt) for years and the mainstream benefitted much much later. This is reasonable and natural. Look at where IPv6 and multicast are, reasonably well defined but quite a ways away from being commonplace. Do you really expect idns to be different? That's why I tend to take a different view from "if I was the IT manager". Unlike that manager, we are making something that we will have to live with for a long time, and the idea that we can have a relatively quick, painless transition for the mainstream customer is probably getting more credibility than it deserves. Bruce From owner-idn@ops.ietf.org Tue Mar 19 23:51:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15097 for ; Tue, 19 Mar 2002 23:51:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nXnO-000LFA-00 for idn-data@psg.com; Tue, 19 Mar 2002 20:33:54 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.35 #1) id 16nXnN-000LF1-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 20:33:53 -0800 Received: (qmail 6101 invoked by uid 1001); 20 Mar 2002 04:32:51 -0000 Date: 20 Mar 2002 04:32:50 -0000 Message-ID: <20020320043250.20715.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: [idn] I don't want to be facing 8-bit bugs in 2013 References: <20020319204407.M32897@iconoplex.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Paul Robinson writes: > You tell him that although it's gobbledygook to people without greek > alphabet support, it will still work. It's not convenient, but it WILL > work. Guaranteed. False. IDNA does _not_ work. IDNA causes interoperability failures. Mail will bounce, for example, in situations where ASCII domain names would have worked fine. IDNA coauthor Adam Costello has admitted this. > And that maybe replacing the DNS resolver on all the machines out > there to be able to do lookups with PunyCode might be a TAD more > realistic than trying to get EVERYTHING, EVERYWHERE to be good with > 8-bit? Here you are assuming that the only problem is the DNS resolver---that the conversion between the local character encoding and the IDNA character encoding can be handled entirely by the DNS resolver. That assumption is false. Consider, for example, an MTA configured to accept mail for pi.cr.yp.to, with a Greek pi. The MTA compares the incoming domain name to pi.cr.yp.to. That doesn't involve the resolver. People who say that IDN is purely a DNS issue are confused. > Making every piece of software and display device that might ever have > to deal with IDNs capable of handling UTF-8? Here you're being simultaneously inconsistent and shortsighted. Fixing bad displays is part of the cost of IDNs. In the context of UTF-8, you agree with me that this is a cost; in the context of IDNA, you ignore the cost completely. In fact, the cost of fixing UTF-8 displays is much _smaller_ than the cost of fixing IDNA displays. UTF-8 has been around for many years, has built up incredible momentum (as illustrated by RFC 2277), and already works in a huge number of programs. The extra programs hurt by IDNA aren't just UTF-8-aware clients. Fixing the IDNA display failures also means changing web servers, mail servers, DNS servers, etc., so that the sysadmin can put a properly displayed IDN into his server configuration files. Think about the above pi.cr.yp.to example again. > The solutions you do offer will take at least 4 years IMHO to be > effective Let's suppose 4 years is right, and let's compare the results to IDNA after 4 years. IDNC3 requires 8-bit fixes to some widely deployed programs, certainly. But IDNA needs _much larger_ changes in _many more_ programs. So, after the same 4 years, only a fraction of the IDNA work will be done. IDNA will still have an incredible number of display failures, plus the interoperability failures and all the other IDNA problems. Even worse, IDNA doesn't do _anything_ to fix the other half of the email problem. Do you seriously believe that Chinese users will be satisfied with email addresses where the domain part can contain Chinese characters but the box part is still required to be ASCII? It's obvious how to fix this with UTF-8; how, pray tell, do we fix it with IDNA? I presume that you're not one of the 7-bit-forever crackpots. How do you propose migrating from IDNA to UTF-8? This is much more costly than moving directly to UTF-8, because it needs a compatibility period during which everyone supports two different encodings of the same character. Doesn't it bother you that the IDNA documents don't discuss this at all? What makes your position particularly shameful is the fact that people proposed requiring 8-bit transparency _eleven years ago_. If it hadn't been for Paul Vixie et al. making your ``it'll take years!'' argument back then, we would have had 8-bit transparency today. Do you want to be facing the same stupid bugs in another eleven years? > Until then, he has to get a 'normal' domain to see himself over. Correct. Your example Greek user has an ASCII domain name that's always displayed with an ASCII d instead of the truly desirable Greek delta. Now, please explain why the same user should prefer a domain name that's _occasionally_ displayed with the desired delta but _usually_ displayed as incomprehensible gobbledygook. Your answer, of course, will be something like this: ``The gobbledygook is a temporary problem. In twenty years, after the massive IDNA upgrade is complete, everyone will see a delta!'' In short, you're looking at the long-term IDNA benefits (never mind the interoperability failures and all the other problems) but refusing to look at the long-term UTF-8 benefits. Inconsistent once again. > Something should be done, but your document make you look like a > typical whiner - you point out all the problems, but offer no > solutions to some of the problems you raise. False. http://cr.yp.to/proto/idnc3.html explains how IDNC3 offers solutions to every one of the IDNA problems that it points out: * interoperability failures; * inconsistent displays of the same name; * unnecessary implementation and deployment costs; * multiple semantically similar names; * identical displays of different names; and * typing failures. Each solution is listed right next to the problem, so I can't imagine how you missed this. > What you are proposing IS introducing an interoperability failure, False. Every step in http://cr.yp.to/proto/idnc3.html preserves interoperability. > How are you proposing to display alpha-ol.com on a VT100? There are several options. One option is to work around the hardware limitations in software, displaying something like | /\/ /\ | /^ /\ /\ /\ \/\ \/ | * \_ \/ | | | Another, much more popular, option is to move your email reading, web browsing, etc. from your 1970s-vintage VT100 to a graphics terminal. Have you considered the VT340, for example? Or an IBM PC, model 5150? > a good 20% of sites out there will just have to shut down ops permanently Get a grip, Paul. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Wed Mar 20 02:28:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25589 for ; Wed, 20 Mar 2002 02:28:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16naIz-000Nna-00 for idn-data@psg.com; Tue, 19 Mar 2002 23:14:41 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16naIy-000NnK-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 23:14:40 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2K7LCR02069; Wed, 20 Mar 2002 14:21:15 +0700 (ICT) From: Robert Elz To: Masataka Ohta cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 In-Reply-To: <200203200532.OAA00306@necom830.hpcl.titech.ac.jp> References: <200203200532.OAA00306@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Mar 2002 14:21:12 +0700 Message-ID: <2067.1016608872@brandenburg.cs.mu.OZ.AU> Sender: owner-idn@ops.ietf.org Precedence: bulk Date: Wed, 20 Mar 2002 14:32:41 +0859 () From: Masataka Ohta Message-ID: <200203200532.OAA00306@necom830.hpcl.titech.ac.jp> | IDNA does _not_ work, because Unicode does not work in International | context. This argument is bogus, and always has been. If (and where) unicode is defective, the right thing to do is to fix unicode. That is, it isn't the principle of a single encoding of all characters that anyone is objecting to here, it is that some specific characters have been implemented incorrectly ("merged" with others) as I understand it. I'm not competent to decide how important this problem is, and this is not the forum to debate it anyway (so please don't reply just to tell me how significant the problem is, nor why). Do that with whoever maintains unicode. If you can't get enough of the unicode experts to agree that there's a problem that needs fixing, then by definition, there isn't. That's just the same way as the IETF works (whether the unicode group actually work this way or not - if not, they should...) - that a few people believe something is broken is irrelevant if they can't demonstrate that well enough to sway others to agree with them. So, stop arguing against unicode (10646) - just fix any problems it has. kre From owner-idn@ops.ietf.org Wed Mar 20 02:32:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25644 for ; Wed, 20 Mar 2002 02:32:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16naR6-000NvJ-00 for idn-data@psg.com; Tue, 19 Mar 2002 23:23:04 -0800 From: Erkki Kolehmainen To: "'Masataka Ohta'" , "D. J. Bernstein" Cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: [idn] RE: I don't want to be facing 8-bit bugs in 2013 Date: Wed, 20 Mar 2002 09:07:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; Message-Id: charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-idn@ops.ietf.org Precedence: bulk Re attached: The use of local character sets (encoding) is doomed for particularly = ww information interchange. Local font crafting is quite another issue. With the newly introduced capability in the UCS (ISO/IEC 10646) and Unicode to predefine = sequences for decomposed characters, font manufacturing is likely to also improve. Sincerely, _____________________________________________ Erkki I. Kolehmainen TIEKE Tietoyhteiskunnan kehitt=E4miskeskus ry TIEKE Finnish Information Society Development Centre Salomonkatu 17 A 10, FIN-00100 HELSINKI, FINLAND Tel: +358 9 4763 0301, Fax: +358 9 4763 0399=20 http://www.tieke.fi =20 -----Original Message----- From: Masataka Ohta [mailto:mohta@NECOM830.HPCL.TITECH.AC.JP] Sent: Wednesday, March 20, 2002 7:34 AM To: D. J. Bernstein Cc: idn@ops.ietf.org; ietf@ietf.org; iesg@ietf.org; iab@isi.edu Subject: Re: I don't want to be facing 8-bit bugs in 2013 D. J. Bernstein; > Paul Robinson writes: > > You tell him that although it's gobbledygook to people without = greek > > alphabet support, it will still work. It's not convenient, but it = WILL > > work. Guaranteed. >=20 > False. IDNA does _not_ work. IDNA causes interoperability failures. IDNA does _not_ work, because Unicode does not work in International context. > People who say that IDN is purely a DNS issue are confused. It's purely a cultural issue. > In fact, the cost of fixing UTF-8 displays is much _smaller_ than the > cost of fixing IDNA displays. UTF-8 has been around for many years, = has > built up incredible momentum (as illustrated by RFC 2277), and = already > works in a huge number of programs. In international context, it is technically impossible to properly display Unicode characters. There is no implementation exist. While some implementations work in some localized context, local character set serves better for the context. Masataka Ohta - This message was passed through ietf_censored@carmen.ipv6.cselt.it, = which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio. From owner-idn@ops.ietf.org Wed Mar 20 02:32:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25662 for ; Wed, 20 Mar 2002 02:32:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16naQn-000Nun-00 for idn-data@psg.com; Tue, 19 Mar 2002 23:22:45 -0800 From: Masataka Ohta Message-Id: <200203200532.OAA00306@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) To: idn-data@psg.com Date: Tue, 19 Mar 2002 23:22:45 -0800 id OAA00306; Wed, 20 Mar 2002 14:32:42 +0900 Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 In-Reply-To: <20020320043250.20715.qmail@cr.yp.to> from "D. J. Bernstein" at "Mar 20, 2002 04:32:50 am" To: "D. J. Bernstein" Date: Wed, 20 Mar 2002 14:32:41 +0859 () CC: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idn@ops.ietf.org Precedence: bulk D. J. Bernstein; > Paul Robinson writes: > > You tell him that although it's gobbledygook to people without greek > > alphabet support, it will still work. It's not convenient, but it WILL > > work. Guaranteed. > > False. IDNA does _not_ work. IDNA causes interoperability failures. IDNA does _not_ work, because Unicode does not work in International context. > People who say that IDN is purely a DNS issue are confused. It's purely a cultural issue. > In fact, the cost of fixing UTF-8 displays is much _smaller_ than the > cost of fixing IDNA displays. UTF-8 has been around for many years, has > built up incredible momentum (as illustrated by RFC 2277), and already > works in a huge number of programs. In international context, it is technically impossible to properly display Unicode characters. There is no implementation exist. While some implementations work in some localized context, local character set serves better for the context. Masataka Ohta From owner-idn@ops.ietf.org Wed Mar 20 02:33:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25674 for ; Wed, 20 Mar 2002 02:33:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16naQa-000NuX-00 for idn-data@psg.com; Tue, 19 Mar 2002 23:22:32 -0800 From: Masataka Ohta Message-Id: <200203200532.OAA00306@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) To: idn-data@psg.com Date: Tue, 19 Mar 2002 23:22:32 -0800 id OAA00306; Wed, 20 Mar 2002 14:32:42 +0900 Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 To: "D. J. Bernstein" Date: Wed, 20 Mar 2002 14:32:41 +0859 () CC: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idn@ops.ietf.org Precedence: bulk D. J. Bernstein; > Paul Robinson writes: > > You tell him that although it's gobbledygook to people without greek > > alphabet support, it will still work. It's not convenient, but it WILL > > work. Guaranteed. > > False. IDNA does _not_ work. IDNA causes interoperability failures. IDNA does _not_ work, because Unicode does not work in International context. > People who say that IDN is purely a DNS issue are confused. It's purely a cultural issue. > In fact, the cost of fixing UTF-8 displays is much _smaller_ than the > cost of fixing IDNA displays. UTF-8 has been around for many years, has > built up incredible momentum (as illustrated by RFC 2277), and already > works in a huge number of programs. In international context, it is technically impossible to properly display Unicode characters. There is no implementation exist. While some implementations work in some localized context, local character set serves better for the context. Masataka Ohta From owner-idn@ops.ietf.org Wed Mar 20 02:44:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25797 for ; Wed, 20 Mar 2002 02:44:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nadg-000OBh-00 for idn-data@psg.com; Tue, 19 Mar 2002 23:36:04 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16nadf-000OBb-00 for idn@ops.ietf.org; Tue, 19 Mar 2002 23:36:04 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16nadf-0000de-00 for ; Tue, 19 Mar 2002 23:36:03 -0800 Date: Wed, 20 Mar 2002 07:36:03 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: [idn] DNS is just one of many protocols that use domain names Message-ID: <20020320073603.GB13542@nicemice.net> Reply-To: IETF idn working group References: <006e01c1cfc7$216ede00$0f01a8c0@EDMON15> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006e01c1cfc7$216ede00$0f01a8c0@EDMON15> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk C C Magnus Gustavsson wrote: > We could consider wiping the slate clean and design a new protocol. > Let's call it e g INS (for Internet Name System or International Names > System) to distinguish it from DNS... Edmon Chung wrote: > Is not ACE just an ugly mask slapped on to the DNS... > > Why cant we go both routes and layout a roadmap for an eventual > convergence with a protocol change that utilizes 8bit data? You are both focusing too much on DNS. DNS is just one of many protocols that carries domain names. Others include SMTP, RFC 822, IMAP, HTTP, URIs, SSL certificates, and on and on... The problem of how to stuff non-ASCII characters into domain names applies equally to every protocol that uses domain names; DNS isn't really that special. Making DNS accomodate non-ASCII characters in domain names doesn't solve the problem for any other protocol. Each one would need to be updated. And the harder part of the problem is not how to preserve the characters, but how to compare the labels: knowing that e-with-acute is the same as e followed by combining-acute. Simply making protocols 8-bit clean doesn't give you that. > Is not ACE just an ugly mask slapped on to the DNS to allow clients > to fake out the user in that they are getting a multilingual domain > name, but in fact, all they got from the DNS operators is a string of > uninteligible ASCII characters? Yes! (Except that it can be slapped onto any protocol, not just DNS.) > Cause now we are saying that (for the following example imagine, > xx--ace = a multilingual label ) > - xx--ace is NOT really xx--ace as you see it, but it really is > - OR is the same as xx--ace It's the latter: is the same as xx-ace (they are equivalent domain labels). > Either way, it means that we have fundamentally changed the concept of > a "unique" DNS name. It's not a fundamental change. Even now, foo and Foo and FOO are equivalent labels, even though they are not identical strings. Software needs to be slightly clever when comparing labels for equivalence. IDNA does not introduce a fundamental change, but merely an evolutionary one: the cleverness needed to compare IDN labels is greater, because now and xx--ace are equivalent, but it's the same fundamental concept. > So what do you tell the customer they got? An ASCII String? or a > Multilingual Domain name? Or do you say its a Buy one Get one Free?! I'm sure registrars will put all sorts of marketing spin on it, but I'd say you got one domain name which can be represented by a variety of strings, some of which are ASCII-only and some of which aren't. AMC From owner-idn@ops.ietf.org Wed Mar 20 06:08:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27777 for ; Wed, 20 Mar 2002 06:08:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ndc5-0001Oy-00 for idn-data@psg.com; Wed, 20 Mar 2002 02:46:37 -0800 Received: from fermat.nation.liu.se ([130.236.242.26]) by psg.com with esmtp (Exim 3.35 #1) id 16ndc4-0001Os-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 02:46:36 -0800 Received: from localhost (mag@localhost) by fermat.nation.liu.se (8.11.6/8.11.6) with ESMTP id g2KAkYk20270 for ; Wed, 20 Mar 2002 11:46:34 +0100 Date: Wed, 20 Mar 2002 11:46:34 +0100 (CET) From: C C Magnus Gustavsson To: IETF idn working group Subject: Re: [idn] DNS is just one of many protocols that use domain names In-Reply-To: <20020320073603.GB13542@nicemice.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Wed, 20 Mar 2002, Adam M. Costello wrote: > You are both focusing too much on DNS. DNS is just one of many > protocols that carries domain names. Others include SMTP, RFC 822, > IMAP, HTTP, URIs, SSL certificates, and on and on... Yes, I know. Considering how many times this mantra has been repeated on the list, it seems unlikely anyone wouldn't be aware of it. ;-) I get the feeling we've been here before. I hope you don't mind me saying so, but as soon as anyone suggests anything but ACE you claim this person is focusing too much on DNS. I think we all see the advantages of ACE, but I'm not so sure everyone see the drawbacks. > Each one would need to be updated. Yes, or at least looked over; that's the unfortunate reality. The real question is whether it's worth it or not, and I suppose that's what the discussions in this wg with few exceptions have always been about. I wrote some time ago, when this list was recently set up (and quoting Linus Torvalds) that when some things need to be fixed, they really need to be fixed. We have come a long way since but I still see this as one such case. Perhaps even more so. We then had the choice between a quick and dirty fix that wouldn't solve all the problems and a more painful solution that would be better in the long run. We still do. In this matter, I have to agree with Dan Bernstein, Dan Oscarsson and others; I still really think we should do it right from the beginning. We have a five story building on quick sand here and I'm not so sure we should add another five stories on top of it without partially tearing down the old one to build a more solid foundation first. You can hardly claim my suggestion will break anything. It will take more effort and more time for sure and my suggestion is obviously the most ambitious. But it will solve the largest number of problems as well. Again, the question is: Is it worth it? I take it yours and Mats Dufbergs answer is "no" but I'm not so sure about the rest of the wg. This is not going to be an easy change-over for the Internet no matter what solution we choose, so why not do the foundation right? This is, as said, a golden opportunity to fix a number of other old problems. > And the harder part of the problem is not how to preserve the > characters, but how to compare the labels: knowing that e-with-acute > is the same as e followed by combining-acute. Simply making protocols > 8-bit clean doesn't give you that. Yes. That's exactly my point. This effort has taken many years. By now we have to realize that it's not going to be an easy solution. So, are we sure we don't want to do it right? $100 is expensive for a pizza but when buying a house for $150,000, adding $1000 isn't much. Magnus From owner-idn@ops.ietf.org Wed Mar 20 09:22:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00168 for ; Wed, 20 Mar 2002 09:22:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nghf-0004Gx-00 for idn-data@psg.com; Wed, 20 Mar 2002 06:04:35 -0800 Received: from mail8.wlv.netzero.net ([209.247.163.58]) by psg.com with smtp (Exim 3.35 #1) id 16nghf-0004Gr-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 06:04:35 -0800 Received: (qmail 27166 invoked from network); 20 Mar 2002 14:04:30 -0000 Received: from dialup-65.58.51.236.dial1.cleveland1.level3.net (HELO EDMON15) (65.58.51.236) by mail8.wlv.netzero.net with SMTP; 20 Mar 2002 14:04:30 -0000 Message-ID: <005501c1d018$7b13eb20$ec333a41@EDMON15> From: "Edmon Chung" To: "IETF idn working group" References: <006e01c1cfc7$216ede00$0f01a8c0@EDMON15> <20020320073603.GB13542@nicemice.net> Subject: Re: [idn] DNS is just one of many protocols that use domain names Date: Wed, 20 Mar 2002 09:06:47 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Adam, Your argument seems to be a bit odd... From: "Adam M. Costello" > You are both focusing too much on DNS. DNS is just one of many > protocols that carries domain names. So imagine you are teaching a kid to play soccer, and he totally missed a kick... What you just said is the same as telling him, you are focusing too much on the ball, there are many other players in your team, and there are the opponents as well, you need to look at them or you wont be able to kick the ball! Of course we understand that there is a big implication, all the more reason to focus on DNS and make it right first. Then we can consider the other protocols. Just like in my example, you need to teach the kid how to kick the ball right before you teach him strategies of the game. > > Cause now we are saying that (for the following example imagine, > > xx--ace = a multilingual label ) > > - xx--ace is NOT really xx--ace as you see it, but it really is > > - OR is the same as xx--ace > > Either way, it means that we have fundamentally changed the concept of > > a "unique" DNS name. > > It's not a fundamental change. Even now, foo and Foo and FOO are > equivalent labels, even though they are not identical strings. Software > needs to be slightly clever when comparing labels for equivalence. Again this is quite a stretch in your argument. I am fairly confident that there will be no dispute in saying that foo=FOO and xx--ace= is a totally different concept! If you think that xx--ace= is not fundamentally changing the concept of name matching in DNS, then what is the difference of saying "dog"= is equivalent?! This is a very dangerous road you are taking. > > So what do you tell the customer they got? An ASCII String? or a > > Multilingual Domain name? Or do you say its a Buy one Get one Free?! > > I'm sure registrars will put all sorts of marketing spin on it, but I'd > say you got one domain name which can be represented by a variety of > strings, some of which are ASCII-only and some of which aren't. So you are effectively endorsing the buy one get one free approach... Edmon From owner-idn@ops.ietf.org Wed Mar 20 11:26:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04019 for ; Wed, 20 Mar 2002 11:26:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nijp-0006Zi-00 for idn-data@psg.com; Wed, 20 Mar 2002 08:14:57 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.35 #1) id 16nijo-0006Zc-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 08:14:56 -0800 From: Masataka Ohta Message-Id: <200203201557.AAA02490@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA02490; Thu, 21 Mar 2002 00:57:19 +0900 Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 In-Reply-To: <2067.1016608872@brandenburg.cs.mu.OZ.AU> from Robert Elz at "Mar 20, 2002 02:21:12 pm" To: Robert Elz Date: Thu, 21 Mar 2002 00:57:18 +0859 () CC: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idn@ops.ietf.org Precedence: bulk Kre; > | IDNA does _not_ work, because Unicode does not work in International > | context. > > This argument is bogus, and always has been. If (and where) unicode > is defective, the right thing to do is to fix unicode. Unicode is not usable in international context. There is no unicode implementaion work in international context. Unicode is usable in some local context. There is some unicode implementaion work in local contexts. However, the context information must be supplied out of band. And, the out of band information is equivalent to "charset" information, regardless of whether you call it "charset" or not. > So, stop arguing against unicode (10646) - just fix any problems it has. Fix is to supply context information out of band to specify which Unicode-based local character set to use. With MIME, it is doable by using different charset names for different local character set. See, for example, RFC1815. As for IDN, it can't just say "use charset of utf-7" or "use charset of utf-8". IDN can say "for Japanese, use charset of utf-7-japanese". Or, if you insist not to distinguish different local character sets by MIME charset names, IDN can say "use charset of utf-7, but, for Japanese, use Japan local version of utf-7" and somehow specify how a name is used for Japanese. Anyway, with the fix, there is no reason to prefer Unicode-based local character sets, which is not widely used today, than existing local character sets already used world wide. Masataka Ohta From owner-idn@ops.ietf.org Wed Mar 20 13:38:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09616 for ; Wed, 20 Mar 2002 13:38:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nkj3-0009lX-00 for idn-data@psg.com; Wed, 20 Mar 2002 10:22:17 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.35 #1) id 16nkj2-0009lD-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 10:22:16 -0800 From: Masataka Ohta Message-Id: <200203201808.DAA02905@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id DAA02905; Thu, 21 Mar 2002 03:07:54 +0859 Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 In-Reply-To: from John Stracke at "Mar 20, 2002 12:10:23 pm" To: John Stracke Date: Thu, 21 Mar 2002 03:07:53 +0859 () CC: ietf@ietf.org, idn@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idn@ops.ietf.org Precedence: bulk John; > >Anyway, with the fix, there is no reason to prefer Unicode-based > >local character sets, which is not widely used today, than existing > >local character sets already used world wide. > > Of course there is. What do you do when someone wants to combine charsets > from different nations? For example, say a Japanese man named Ohta married > a Mexican woman whose paternal surname was Col_n. Their child's full surname, if they lived in Mexico, would be "Ohta y Col_n". If that child wants to spell their surname correctly, they can't use a > just-European or just-Japanese character set; they probably need Unicode. While marrying wih a Mexican woman is, if my wife and children allow, an fascinating idea, I'm saying, with your example (actually, European and Japanese contexts happen to be compatible, but to follow your example, let's assume they are not), the child must say european-local-unicode and japanese-local-unicode at the same time, which is impossible. Just saying "unicode" is not enough to display "Ohta y Col_n" with japanese local unicode-based character set. Unicode is not useful in international context. Masataka Ohta From owner-idn@ops.ietf.org Wed Mar 20 14:02:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10156 for ; Wed, 20 Mar 2002 14:02:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nlBN-000AK7-00 for idn-data@psg.com; Wed, 20 Mar 2002 10:51:33 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.35 #1) id 16nlBN-000AK1-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 10:51:33 -0800 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2AE1561E98; Wed, 20 Mar 2002 19:51:28 +0100 (CET) Date: Wed, 20 Mar 2002 12:29:10 -0600 From: Harald Tveit Alvestrand To: Masataka Ohta Cc: idn@ops.ietf.org, ietf@ietf.org Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 Message-ID: <8505119.1016627350@localhost> In-Reply-To: <200203201557.AAA02490@necom830.hpcl.titech.ac.jp> References: <200203201557.AAA02490@necom830.hpcl.titech.ac.jp> X-Mailer: Mulberry/2.2.0b3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit dropping a few mailing lists off the CC: --On 21. mars 2002 00:57 +0859 Masataka Ohta wrote: > Unicode is usable in some local context. Agreed. Note that "some" is changing to "many" as time goes on. > > There is some unicode implementaion work in local contexts. > > However, the context information must be supplied out of band. Agreed. > > And, the out of band information is equivalent to "charset" > information, regardless of whether you call it "charset" or > not. Do not agree. for most values of what we currently have registered as "charset", it is not sufficient to identify the context. Therefore, depending on "charset" to identify context is not only useless, but actively harmful. My opinion, which I stated in RFC 1766, and have found no reason to change. The IETF rough consensus seemed to agree at the time. Harald From owner-idn@ops.ietf.org Wed Mar 20 14:10:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10501 for ; Wed, 20 Mar 2002 14:10:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nlI4-000AUe-00 for idn-data@psg.com; Wed, 20 Mar 2002 10:58:28 -0800 Received: from 213.234.81.127.adsl.toe.tiscali.no ([213.234.81.127] helo=nebula.lan) by psg.com with esmtp (Exim 3.35 #1) id 16nlI2-000ATs-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 10:58:27 -0800 Received: from localhost (flax@localhost) by nebula.lan (8.11.4/8.11.4) with ESMTP id g2KJ1hU01770; Wed, 20 Mar 2002 20:01:44 +0100 Date: Wed, 20 Mar 2002 20:01:43 +0100 (CET) From: Thor Harald Johansen X-X-Sender: Reply-To: Thor Harald Johansen To: Masataka Ohta cc: John Stracke , , Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 In-Reply-To: <200203201808.DAA02905@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > Just saying "unicode" is not enough to display "Ohta y Col_n" with > japanese local unicode-based character set. > Unicode is not useful in international context. Most disagreements would disappear if all parties had identical information in their posession. I belive that Unicode would cope with such a situation. If your transmission medium supports 8-bit characters, I see no problem in transmitting groups of octets representing Unicode glyphs over that same medium, if proper information about this is provided in a header. The last time I checked, UTF-? was a method of encapsulating the full Unicode character set in a medium capable of carrying less bits. -- Thor Harald Johansen thorhj@yahoo.com From owner-idn@ops.ietf.org Wed Mar 20 14:29:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11355 for ; Wed, 20 Mar 2002 14:29:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nlZH-000Avs-00 for idn-data@psg.com; Wed, 20 Mar 2002 11:16:15 -0800 Received: from kruuna.helsinki.fi ([128.214.205.14]) by psg.com with esmtp (Exim 3.35 #1) id 16nlZG-000AvX-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 11:16:15 -0800 Received: from localhost (ssyreeni@localhost) by kruuna.Helsinki.FI (8.11.6/8.10.1) with ESMTP id g2KJG7402773; Wed, 20 Mar 2002 21:16:07 +0200 (EET) X-Authentication-Warning: kruuna.Helsinki.FI: ssyreeni owned process doing -bs Date: Wed, 20 Mar 2002 21:16:07 +0200 (EET) From: Sampo Syreeni To: Masataka Ohta cc: Subject: Re: [idn] Re: I don't want to be facing 8-bit bugs in 2013 In-Reply-To: <200203201557.AAA02490@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, 21 Mar 2002, Masataka Ohta wrote: >Unicode is not usable in international context. Come, now. My understanding has been that that's precisely the context where Unicode is supposed to be used. Why have Unicode in the first place if not for multilingual text? >There is no unicode implementaion work in international context. How's that? I would tend to see current browser and office suite work as such, at the very least. >Unicode is usable in some local context. If I understand correctly, you're opposed to Unification and the external protocols for language tagging it necessitates if we insist on absolute typographical correctness of text with unified ideographs. HTML and XML/XHTML provide precisely such tagging, as do Unicode language tag characters in the context of protocols with no external language indication facilities. Also I seem to remember that East Asian Unicode text is legible even when printed in a font not designed for the particular "local context", as you put it. Where's the problem? >There is some unicode implementaion work in local contexts. Well, considering that UTF-8 is the encoding of choice for some past, much present and all future IETF and W3C work, and that Microsoft's products seem to be heading for UTF-16, I'd say that is a colossal understatement. >However, the context information must be supplied out of band. Not must, but rather must provided that the text is meant for human consumption *and* exact typography of variant characters is a requirement. Unicode was never meant to solve the latter part -- it does not encode font information, for instance. >And, the out of band information is equivalent to "charset" information, >regardless of whether you call it "charset" or not. Absolutely not. Unicode's characters are perfectly well defined even if they are not correctly printed. What we're indicating here are differences between languages and preferred renderings of a given piece of Unicode text. You should think about this in the context of rendering to speech, perhaps that will help you see the fine distinctions involved. After all, one cannot even *attempt* such renderings from text written in pure Latin-1 without external language indication. Why should graphic rendering be any different? >Fix is to supply context information out of band to specify which >Unicode-based local character set to use. No. The fix is to indicate the language the document is in, or perhaps encode font information explicitly. Provided such meticulous attention to the appearance of the text is warranted in a given application, anyway. >See, for example, RFC1815. Yes, you seem to have objected to Unicode, before. The trouble is, not a whole lot of people agree with RFC1815. For a reason, I daresay. >As for IDN, it can't just say "use charset of utf-7" or "use charset of >utf-8". Of course you can. UTF-8 and UTF-7 are bona fide character sets -- the characters they define are unique and well-defined. You're confusing renderings of characters with characters themselves, a common mistake with Unicode. (But of course you already know that.) >Anyway, with the fix, there is no reason to prefer Unicode-based local >character sets, which is not widely used today, than existing local >character sets already used world wide. Of course there is -- my local character set cannot represent Arabic, Japanese, English and Finnish, with correct punctuation and other typographic pedantries, in the same document. Hell, it cannot do that even in separate documents, unless I use Unicode. The latter on the other hand works perfectly, with no loss of information. Your line of thinking is what has lead to e.g. i-mode employing JIS or Latin-1, and making the current incarnation of that technology useless to Central European, Chinese, African, Indian, and a probably a whole lot of other, user communities. Just think about what something like this would do in an IDNA context, and you'll understand why Unicode is a Good Idea. Besides, if you look at a Chinese user typing in the name of a Japanese site, I would say unification makes the procedure considerably more forgiving. Don't you? I'd say local variants will full support are Bad, a unified coding with local profiles is Good. Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From owner-idn@ops.ietf.org Wed Mar 20 17:07:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16752 for ; Wed, 20 Mar 2002 17:07:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16no0M-000EXu-00 for idn-data@psg.com; Wed, 20 Mar 2002 13:52:22 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.35 #1) id 16no0L-000EXo-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 13:52:22 -0800 From: Masataka Ohta Message-Id: <200203202137.GAA03665@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA03665; Thu, 21 Mar 2002 06:37:17 +0900 Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 In-Reply-To: <8505119.1016627350@localhost> from Harald Tveit Alvestrand at "Mar 20, 2002 12:29:10 pm" To: Harald Tveit Alvestrand Date: Thu, 21 Mar 2002 06:37:15 +0859 () CC: idn@ops.ietf.org, ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idn@ops.ietf.org Precedence: bulk Harald; > wrote: > > > Unicode is usable in some local context. > > Agreed. Note that "some" is changing to "many" as time goes on. Irreleant, because some contexts are not compatible. The point here is that there can be no universal context. > > There is some unicode implementaion work in local contexts. > > > > However, the context information must be supplied out of band. > > Agreed. Then, how can you provide the information with IDN? > > And, the out of band information is equivalent to "charset" > > information, regardless of whether you call it "charset" or > > not. > > Do not agree. > for most values of what we currently have registered as "charset", it is > not sufficient to identify the context. That is a problem of current and past charset reviewers including you. > Therefore, depending on "charset" to identify context is not only useless, > but actively harmful. Agreed. ISO 2022 escape sequence is the way to go. > My opinion, which I stated in RFC 1766, and have found no reason to change. It was already denied by real world examples. Masataka Ohta From owner-idn@ops.ietf.org Wed Mar 20 19:21:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20066 for ; Wed, 20 Mar 2002 19:21:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nq2G-000HXd-00 for idn-data@psg.com; Wed, 20 Mar 2002 16:02:28 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.35 #1) id 16nq2F-000HXX-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 16:02:28 -0800 From: Masataka Ohta Message-Id: <200203202343.IAA04391@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA04391; Thu, 21 Mar 2002 08:43:28 +0900 Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 In-Reply-To: <621574AE86FAD3118D1D0000E22138A9383EE5@TIEKE1> from Erkki Kolehmainen at "Mar 20, 2002 09:07:56 am" To: Erkki Kolehmainen Date: Thu, 21 Mar 2002 08:43:28 +0859 () CC: "D. J. Bernstein" , idn@ops.ietf.org, ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idn@ops.ietf.org Precedence: bulk Erkki I. Kolehmainen; > The use of local character sets (encoding) is doomed for particularly ww > information interchange. Interestingly enough, ww information interchange is working very well with local character sets. The reason is because only people sharing a language, a scripting system and a character encoding system join each exchange, regardless of whether it is ww or intranational. For example, ww IETF communication is with English, Latin script and ASCII. Introduction of ISO-8859-1 or Unicode does not make IETF use Finnish. Your attempt to put ISO-8859-1 characters is not acceptable for me and your mail is filtered to be pure ASCII by my mailer, which is fair because many of us have no way to input non-ASCII ISO-8859-1 characters. Masataka Oha From owner-idn@ops.ietf.org Wed Mar 20 21:09:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21709 for ; Wed, 20 Mar 2002 21:09:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nrsK-000Jy5-00 for idn-data@psg.com; Wed, 20 Mar 2002 18:00:20 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16nrsH-000JxU-00; Wed, 20 Mar 2002 18:00:17 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 72C7EFFC09; Thu, 21 Mar 2002 09:58:36 +0800 (SGT) Message-ID: <012601c1d07c$10d4fb00$dd00a8c0@jamessonyviao> From: "James Seng" To: "Masataka Ohta" , "Erkki Kolehmainen" Cc: "D. J. Bernstein" , , , References: <200203202343.IAA04391@necom830.hpcl.titech.ac.jp> Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 Date: Thu, 21 Mar 2002 09:59:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit While the discussion of the use of various character set is interesting topic, one which is also of interest to IDN WG, such prolonged discussion are better carried out in a forum which is dedicated to this, such as intloc-discuss@ops.ietf.org, a list which is formed to talk about the generic problem of I18N and L10N in IETF, and not IDN. Please bring it over to the other list and when/if there is a conclusion, please keep the IDN informed. Thanks. -James Seng ----- Original Message ----- From: "Masataka Ohta" To: "Erkki Kolehmainen" Cc: "D. J. Bernstein" ; ; Sent: Thursday, March 21, 2002 7:44 AM Subject: Re: I don't want to be facing 8-bit bugs in 2013 > Erkki I. Kolehmainen; > > > The use of local character sets (encoding) is doomed for particularly ww > > information interchange. > > Interestingly enough, ww information interchange is working very > well with local character sets. > > The reason is because only people sharing a language, a scripting > system and a character encoding system join each exchange, regardless > of whether it is ww or intranational. > > For example, ww IETF communication is with English, Latin script and > ASCII. Introduction of ISO-8859-1 or Unicode does not make IETF use > Finnish. > > Your attempt to put ISO-8859-1 characters is not acceptable for me > and your mail is filtered to be pure ASCII by my mailer, which is > fair because many of us have no way to input non-ASCII ISO-8859-1 > characters. > > Masataka Oha > From owner-idn@ops.ietf.org Wed Mar 20 21:10:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21747 for ; Wed, 20 Mar 2002 21:10:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nrui-000K36-00 for idn-data@psg.com; Wed, 20 Mar 2002 18:02:48 -0800 Date: Wed, 20 Mar 2002 14:27:34 -0500 From: Theodore Tso To: Masataka Ohta Cc: John Stracke , ietf@ietf.org, idn@ops.ietf.org Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: On Thu, Mar 21, 2002 at 03:07:53AM +0859, Masataka Ohta wrote: > While marrying wih a Mexican woman is, if my wife and children allow, > an fascinating idea, I'm saying, with your example (actually, European and > Japanese contexts happen to be compatible, but to follow your > example, let's assume they are not), the child must say > european-local-unicode and japanese-local-unicode at the same time, > which is impossible. > > Just saying "unicode" is not enough to display "Ohta y Col_n" with > japanese local unicode-based character set. > > Unicode is not useful in international context. You're making assertions based on local implementation decisions. It is possible to have implementations that use a unicode font that is fully populated. It may not look very nice, and it may offend japanese eyes if the chinese variants of the han-unified characters are used, or chinese eyes if the japanese variants of the han-unified characters are used in said universal font, but it would at least be recongizeable and readable by all. (BTW, it's this kind of nonsense and parochialism which has sometimes caused some folks to claim, "it would be easier if we could just all teach them English.") - Ted From owner-idn@ops.ietf.org Wed Mar 20 21:10:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21767 for ; Wed, 20 Mar 2002 21:10:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nrvN-000K4W-00 for idn-data@psg.com; Wed, 20 Mar 2002 18:03:29 -0800 To: ietf@ietf.org Cc: idn@ops.ietf.org Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "John Stracke" Date: Wed, 20 Mar 2002 12:10:23 -0500 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA21767 >Anyway, with the fix, there is no reason to prefer Unicode-based >local character sets, which is not widely used today, than existing >local character sets already used world wide. Of course there is. What do you do when someone wants to combine charsets from different nations? For example, say a Japanese man named Ohta married a Mexican woman whose paternal surname was Colón. Their child's full surname, if they lived in Mexico, would be "Ohta y Colón". If that child wants to spell their surname correctly, they can't use a just-European or just-Japanese character set; they probably need Unicode. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |I imagine the wages of sin *are* death, but by the time they take| |taxes out it's just sort of a tired feeling. --Paula Poundstone | \=================================================================/ From owner-idn@ops.ietf.org Wed Mar 20 21:12:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21829 for ; Wed, 20 Mar 2002 21:12:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nrux-000K3X-00 for idn-data@psg.com; Wed, 20 Mar 2002 18:03:03 -0800 Date: Wed, 20 Mar 2002 21:22:05 +0000 From: Paul Robinson To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 Message-ID: <20020320212205.A606@iconoplex.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk On Mar 20, "D. J. Bernstein" wrote: > False. IDNA does _not_ work. IDNA causes interoperability failures. Mail >... with the current DNS resolvers in place... OK, others have pointed out failures with things like SSL/HTTPS (which is broken in several interesting way anyway from the point of view of scalability and long-term usefullness), but even then I can see work arounds. All of them are more preferable to throwing away every serial console in the world because a greek delta doesn't display properly on it and therefore has a 'display failure'. > That assumption is false. Consider, for example, an MTA configured to > accept mail for pi.cr.yp.to, with a Greek pi. The MTA compares the > incoming domain name to pi.cr.yp.to. That doesn't involve the resolver. Well, funnily enough I have to tell my MTA about .co.uk domains AND .com domains as well, even though the bit in front of them is IDENTICAL. If I register the .net I have to tell it about that as well. They're different domains. If I buy an IDN with a Greek letter in it, I'm going to have to tell my MTA about that. If think that by adding a new domain to your config you shouldn't have to tell your MTA about that, you're obviously not a very experienced admin. > Now, please explain why the same user should prefer a domain name that's > _occasionally_ displayed with the desired delta but _usually_ displayed > as incomprehensible gobbledygook. Until he fixes his machine to have proper Greek alphabet support. However, when it comes over to my PDP-8 it appears as gobbledygook. But it still works. Sure, that's REAL broken. > In short, you're looking at the long-term IDNA benefits (never mind the > interoperability failures and all the other problems) but refusing to > look at the long-term UTF-8 benefits. Inconsistent once again. The IETF is about the long-term. It not about the next 2 years. Even I know that. You should certainly know that. > * interoperability failures; That don't exist. Or the ones that do can be given work-around far simpler than replacing every piece of equipment in th eknown universe and updating every piece of software ever written. Ever. > * inconsistent displays of the same name; That don't matter. > * unnecessary implementation and deployment costs; The fact you're suggesting that what *I'm* proposing and what the IDNA is proposing requires unnecessary implementation and deployment costs, quite frankly, makes me snort my coffee up my nose. > * multiple semantically similar names; OK, let's not allow uppercase Greek Alpha. Does that fix one of your problems? Sheesh. > * identical displays of different names; and Not a problem for the IETF. Not even a problem for users. In Greece A means Alpha. In the US it means 'Ay'. If you're a Greek in New York, you might have problems. You're going to have problems anyway, but at least with IDNA PunyCode is your friend. > * typing failures. We get those anyway. It's why slahdot.org exists. > False. Every step in http://cr.yp.to/proto/idnc3.html preserves > interoperability. Fixing half a dozen pieces of software and then just allowing every mand and his dog to register special Bernsteinised-domains? Right. I see. > There are several options. One option is to work around the hardware > limitations in software, displaying something like > > | > /\/ /\ | /^ /\ /\ /\ > \/\ \/ | * \_ \/ | | | *ROFL* # cat Mail/inbox | utf8decode | figlet That's how I like to read my mail in the morning! Seriosuly man, I'm sat here on a customer's site in the middle of the South Atlantic looking forward to an 18 hour RAF flight home to the UK, and I'm crying with laughter. You really have cheered me up. That was so off-the-wall and unexpected - to propose IDNs to be displayed as ASCII art - that I'm going to be smiling and giggling to myself for days. You have confirmed what I should have known - you're stark raving insane. Quite, quite, quite mad. Fantastic. > Another, much more popular, option is to move your email reading, web > browsing, etc. from your 1970s-vintage VT100 to a graphics terminal. > Have you considered the VT340, for example? Or an IBM PC, model 5150? You're proposing the abondonment of legacy hardware when there is no need. That costs money. Serious money. If I have my hostname setup as pi.alpha-ol.com and I need to gain access over the serial port at boot with a VT100, the option of anything else is not available. > > a good 20% of sites out there will just have to shut down ops permanently > > Get a grip, Paul. I'm not the one proposing we turn the world into one great big ASCII art factory. Anyway, I'm going to be away from mail for a few days due to travelling around - don't think I'm giving up on you yet though. :-) Seriously... ascii art... hehehe... -- Paul Robinson From owner-idn@ops.ietf.org Wed Mar 20 22:01:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23332 for ; Wed, 20 Mar 2002 22:01:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nsjG-000LTE-00 for idn-data@psg.com; Wed, 20 Mar 2002 18:55:02 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16nsjF-000LSs-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 18:55:02 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16nsjB-0002ni-00 for ; Wed, 20 Mar 2002 18:54:57 -0800 Date: Thu, 21 Mar 2002 02:54:57 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: [idn] usability of Unicode Message-ID: <20020321025456.GA10246@nicemice.net> Reply-To: IETF idn working group References: <2067.1016608872@brandenburg.cs.mu.OZ.AU> <200203201557.AAA02490@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203201557.AAA02490@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk Masataka Ohta wrote: > Unicode is not usable in international context. I think you mean that Unicode doesn't work very well for displaying free-form text, unless you have more meta-information about the text, and you may be right. But for text used as identifiers, Unicode is extremely useful, for testing whether two identifiers are the same. Suppose there are 100 charsets in use around the world. Many of them have characters in common, so two identifiers that use different charsets might still contain the same characters in the same order. To test for that, do we write 10,000 comparison algorithms to handle all possible combinations? Of course not. We write 100 transcoding algorithms to convert each charset to Unicode, plus one normalization algorithm for Unicode. AMC From owner-idn@ops.ietf.org Wed Mar 20 22:02:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23354 for ; Wed, 20 Mar 2002 22:02:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nseg-000LL9-00 for idn-data@psg.com; Wed, 20 Mar 2002 18:50:18 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16nseg-000LL3-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 18:50:18 -0800 Message-ID: <020901c1d083$74b55aa0$ec333a41@EDMON15> From: "Edmon Chung" To: Cc: References: Subject: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever Date: Wed, 20 Mar 2002 21:52:34 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit An underlying question we must ask ourselves from all the discussions that have sprung up every now and then is: Do we wish to 1. eventually move the DNS towards UTF8/16 OR 2. do we want to stay with ASCII(ACE) for the rest of our lives? If the answer is 1. then the IDN solution should take it into concern. If it is 2. then perhaps the IETF should revise some of its internationalization policies. I can see an arguement coming that says there is no draft on this, but if we dont even get this fundamental question figured out, how can there be a collective or meaningful effort towards a solution that makes most sense?? Edmon PS. Perhaps we should have a show of hands or something about the real "DIRECTION" that PEOPLE want to see with the internationalization of the Domain Names. From owner-idn@ops.ietf.org Wed Mar 20 22:19:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23594 for ; Wed, 20 Mar 2002 22:19:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nsyK-000LrT-00 for idn-data@psg.com; Wed, 20 Mar 2002 19:10:36 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16nsyJ-000LrM-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 19:10:36 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id TAA15117; Wed, 20 Mar 2002 19:10:27 -0800 Message-Id: <5.1.0.14.2.20020320210727.026ab590@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Mar 2002 21:07:55 -0600 To: "Edmon Chung" From: Dave Crocker Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever Cc: , In-Reply-To: <020901c1d083$74b55aa0$ec333a41@EDMON15> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 09:52 PM 3/20/2002 -0500, Edmon Chung wrote: >An underlying question we must ask ourselves from all the discussions that >have sprung up every now and then is: and as luck would have it, the working group has asked itself that question many times, so we need not pursue it again. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Wed Mar 20 22:24:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23775 for ; Wed, 20 Mar 2002 22:24:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nt5b-000M2j-00 for idn-data@psg.com; Wed, 20 Mar 2002 19:18:07 -0800 Received: from rwcrmhc53.attbi.com ([204.127.198.39]) by psg.com with esmtp (Exim 3.35 #1) id 16nt5b-000M2c-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 19:18:07 -0800 Received: from c1340594a ([12.234.212.162]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020321031806.FQFO2951.rwcrmhc53.attbi.com@c1340594a>; Thu, 21 Mar 2002 03:18:06 +0000 Message-ID: <006601c1d087$0a354470$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Masataka Ohta" , "Robert Elz" Cc: , , , References: <200203201557.AAA02490@necom830.hpcl.titech.ac.jp> Subject: Re: [idn] Re: I don't want to be facing 8-bit bugs in 2013 Date: Wed, 20 Mar 2002 19:18:14 -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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > Unicode is not usable in international context. ... It would not be worth replying to these threadworn and repeated assertions by Mr. Ohta, except that some members of this list may not be that familiar with Unicode. Clearly Unicode is being used successfully in a huge variety of products in international contexts. For more information on the CJK repertoire (which is the part Mr. Ohta objects to), see http://www.unicode.org/unicode/faq/han_cjk.html. Mark ————— Γνῶθι σαυτόν — Θαλῆς [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: "Masataka Ohta" To: "Robert Elz" Cc: ; ; ; Sent: Wednesday, March 20, 2002 07:58 Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 > Kre; > > > | IDNA does _not_ work, because Unicode does not work in International > > | context. > > > > This argument is bogus, and always has been. If (and where) unicode > > is defective, the right thing to do is to fix unicode. > > Unicode is not usable in international context. > > There is no unicode implementaion work in international context. > > Unicode is usable in some local context. > > There is some unicode implementaion work in local contexts. > > However, the context information must be supplied out of band. > > And, the out of band information is equivalent to "charset" > information, regardless of whether you call it "charset" or > not. > > > So, stop arguing against unicode (10646) - just fix any problems it has. > > Fix is to supply context information out of band to specify which > Unicode-based local character set to use. > > With MIME, it is doable by using different charset names for > different local character set. > > See, for example, RFC1815. > > As for IDN, it can't just say "use charset of utf-7" or "use charset > of utf-8". > > IDN can say "for Japanese, use charset of utf-7-japanese". > > Or, if you insist not to distinguish different local character sets by > MIME charset names, IDN can say "use charset of utf-7, but, for > Japanese, use Japan local version of utf-7" and somehow specify > how a name is used for Japanese. > > Anyway, with the fix, there is no reason to prefer Unicode-based > local character sets, which is not widely used today, than existing > local character sets already used world wide. > > Masataka Ohta > > From owner-idn@ops.ietf.org Wed Mar 20 22:54:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25118 for ; Wed, 20 Mar 2002 22:54:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ntYJ-000MoF-00 for idn-data@psg.com; Wed, 20 Mar 2002 19:47:47 -0800 Received: from spider.nic-se.se ([212.247.3.67]) by psg.com with esmtp (Exim 3.35 #1) id 16ntYI-000Mo9-00 for idn@ops.ietf.org; Wed, 20 Mar 2002 19:47:46 -0800 Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id g2L3lTI08891; Thu, 21 Mar 2002 04:47:29 +0100 (CET) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Thu, 21 Mar 2002 04:47:29 +0100 (CET) From: Mats Dufberg To: Edmon Chung cc: Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever In-Reply-To: <020901c1d083$74b55aa0$ec333a41@EDMON15> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Mar 20, 2002, 21:52 (-0500) Edmon Chung wrote: > An underlying question we must ask ourselves from all the discussions that > have sprung up every now and then is: > Do we wish to > > 1. eventually move the DNS towards UTF8/16 OR > 2. do we want to stay with ASCII(ACE) for the rest of our lives? No, we do not have to ask that question now. The group moved the four drafts to the decision of IESG. The drafts has not defined any end transfer from ACE to anything else. If the drafts are accepted as RFC:s, anyone can raise the question of updating some other solution by submitting a draft. Right now, we can do nothing but wait for the decision by the IESG. Mats ---------------------------------------------------------------------- Mats Dufberg ---------------------------------------------------------------------- From owner-idn@ops.ietf.org Thu Mar 21 02:56:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06501 for ; Thu, 21 Mar 2002 02:56:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nxDb-0001ri-00 for idn-data@psg.com; Wed, 20 Mar 2002 23:42:39 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.35 #1) id 16nxDa-0001rc-00; Wed, 20 Mar 2002 23:42:39 -0800 From: Masataka Ohta Message-Id: <200203210727.QAA05914@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA05914; Thu, 21 Mar 2002 16:27:24 +0900 Subject: [idn] Unicode is so flawed that 7 or 8 bit encoding is not an issue In-Reply-To: <012601c1d07c$10d4fb00$dd00a8c0@jamessonyviao> from James Seng at "Mar 21, 2002 09:59:36 am" To: James Seng Date: Thu, 21 Mar 2002 16:27:23 +0859 () CC: Erkki Kolehmainen , "D. J. Bernstein" , idn@ops.ietf.org, ietf@ietf.org, intloc-discuss@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idn@ops.ietf.org Precedence: bulk James; Trying to reply your mail, my mailer says: [Charset Windows-1252 unsupported, skipping...] so, could you learn not to Microsoft centric and to use proper charset for the International discussion of IETF? > While the discussion of the use of various character set is interesting > topic, one which is also of interest to IDN WG, such prolonged discussion > are better carried out in a forum which is dedicated to this, such as > intloc-discuss@ops.ietf.org, a list which is formed to talk about the > generic problem of I18N and L10N in IETF, and not IDN. I believe IDN, or bogosity of it, worthes attracting generic attention of IETF. > Please bring it over to the other list and when/if there is a conclusion, > please keep the IDN informed. As you could have seen, on IETF mailing list, Harald and I have, at least, agreed that, if you use unicode based encoding, local context (or locale) must be carried out of band I think Harald's language tag is highly semantical and is not useful for purely lexical (not even syntactic) issues such as charset disambiguation or space elimination for format=flowed. For example, the follwing Japanese text in Romaji script: IDN tte zenzen dame follows, as you can easily guess, usual folding rules for Latin-based scripts. But, anyway, the discussion so far in IETF list is enough to deny IDN. I'm happy to discontinue the thread, then. Masataka Ohta PS I have found a theory to deny PKI and to explain why public key cryptograpy is not so polular dispite the efforts of ISO, which will destory entire business of a company or companies owing several important TLDs. So, don't bother to say that there are so many so-called-international- but-actuallly-local domain names registered. From owner-idn@ops.ietf.org Thu Mar 21 03:16:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06863 for ; Thu, 21 Mar 2002 03:16:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nxZ6-0002Yh-00 for idn-data@psg.com; Thu, 21 Mar 2002 00:04:52 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.35 #1) id 16nxZ5-0002Yb-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 00:04:51 -0800 From: Masataka Ohta Message-Id: <200203210748.QAA06034@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA06034; Thu, 21 Mar 2002 16:47:58 +0859 Subject: Re: [idn] Re: I don't want to be facing 8-bit bugs in 2013 In-Reply-To: <006601c1d087$0a354470$8900a8c0@c1340594a> from Mark Davis at "Mar 20, 2002 07:18:14 pm" To: Mark Davis Date: Thu, 21 Mar 2002 16:47:58 +0859 () CC: Robert Elz , idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idn@ops.ietf.org Precedence: bulk Mark; As my mailer says; [Charset utf-8 unsupported, skipping...] you should learn that Unicode is not usable in international context of IETF. > > Unicode is not usable in international context. > ... > > It would not be worth replying to these threadworn and repeated > assertions by Mr. Ohta, except that some members of this list may not > be that familiar with Unicode. Clearly Unicode is being used > successfully in a huge variety of products in international contexts. That is not so totally untrue. There do exist some Unicode products valuable in international contexts, because they are useful in some (or many) local contexts. However, as Harald and I agreed, such products need local context information OOB to work properly. Then, the problem is that some local contexts are mutually exclusive. There is no instance of Unicode-based-local-character-set internationally useful. Some product using unicode may be usable in multiple local context, if the context information is given OOB, and the product is valuable in international market. However, unicode, still, is not usable in international context unless OOB information, which, thanks to poor charset reviewing, essentaily is yet another charset designaiton, is attached. Masataka Ohta From owner-idn@ops.ietf.org Thu Mar 21 08:04:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09831 for ; Thu, 21 Mar 2002 08:04:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o1nD-0009JU-00 for idn-data@psg.com; Thu, 21 Mar 2002 04:35:43 -0800 Received: from citadel.cequrux.com ([192.96.22.18]) by psg.com with esmtp (Exim 3.35 #1) id 16o1nC-0009JM-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 04:35:42 -0800 Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id OAA27992 for ; Thu, 21 Mar 2002 14:35:38 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 27818; Thu Mar 21 14:33:41 2002 Date: Thu, 21 Mar 2002 14:33:37 +0200 From: Alan Barrett To: idn@ops.ietf.org Subject: [idn] Re: Unicode is not usable in international context. Message-ID: <20020321123337.GK371@apb.cequrux.com> References: <2067.1016608872@brandenburg.cs.mu.OZ.AU> <200203201557.AAA02490@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203201557.AAA02490@necom830.hpcl.titech.ac.jp> Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, 21 Mar 2002, Masataka Ohta wrote: > Unicode is not usable in international context. [...] Unicode is > usable in some local context. [...] However, the context information > must be supplied out of band. Let me see if I can understand this argument about Unicode and local context. I am an English speaker who can't tell the difference between the Chinese character that appears as the second character of the Chinese word for the city that I call "Beijing", and the Japanese character that appears as the second character of the Japanese word for the city that I call "Tokyo". I believe that (as used in the city names) both characters mean something like the English word "capital". Say there's a Chinese character that looks (to uneducated western eyes) like a box with three legs and a hat, and a Japanese character that looks (to uneducated western eyes) like a box with three legs and a hat. Say the Chinese character looks slightly different from the Japanese character, but a Chinese person can easily recognise the Japanese character and understand its meaning in context, and a Japanese person can easily recognise the Chinese character and understand its meaning in context. As far as I understand, Unicode would say that these are not two different characters, but just different display forms of the same unified character (or whatever the correct technical terms are). Display software would have to have out of band knowledge to help it choose between the Chinese and Japanese display forms. As far as I understand, absence of out of band knowledge could lead to the hypothetical Unicode character being displayed as if it were , even if the author's intent was to display . As far as I understand, Masataka Ohta considers this to be a fatal flaw in Unicode. I hope he will correct me if I have misunderstood his objection. I don't know enough to tell whether the difference between corresponding Chinese and Japanese characters is analogous to a font difference or a spelling difference, but the "ignorant westerner can't tell the difference" test biases me towards the "font difference" side. If they are analogous to spelling differences, then I would say that unifying the different characters was probably an error in Unicode, but that IDN should not try to undo that unification. Either way, I think that IDN should document the potential problem but not try to fix it. (In contrast, I think I have learned enough by following the past months of discussion to tell that the differences between Traditional and Simplified Chinese are analogous to spelling differences, and so IDN should not try to unify them.) --apb (Alan Barrett) From owner-idn@ops.ietf.org Thu Mar 21 10:25:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13643 for ; Thu, 21 Mar 2002 10:25:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o4Js-000DwQ-00 for idn-data@psg.com; Thu, 21 Mar 2002 07:17:36 -0800 Received: from unknown-raq-customer.dca1.superb.net ([207.228.240.63] helo=www.wordnic.com) by psg.com with esmtp (Exim 3.35 #1) id 16o4Js-000DwH-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 07:17:36 -0800 Received: from [64.109.213.3] (adsl-64-108-77-182.dsl.lgnnmi.ameritech.net [64.108.77.182]) by www.wordnic.com (8.9.3/8.9.3) with ESMTP id JAA28187; Thu, 21 Mar 2002 09:17:25 -0600 Mime-Version: 1.0 X-Sender: tedd1@sperling.com Message-Id: In-Reply-To: References: Date: Thu, 21 Mar 2002 10:17:26 -0500 To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org From: tedd Subject: Re: [idn] WG last call summary Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA13643 >On Mar 19, "D. J. Bernstein" wrote: > >> Go sell a Greek user an ``internationalized domain name'' with a delta, >> Pete. Then tell him that most of his correspondents will see the delta >> as incomprehensible gobbledygook rather than a delta. See what he says. Okay, I'm not Greek, but as the registered owner of .com, I'll tell you*. I expect that some windoze users will display it (.com) as a box dot com; mac users will display it as a delta dot com; and everyone else will display it as a bq--eida.com (RACE), or dq--uuyg.com (DUDE), or zq---h9g.com (AMZ_C), or punycode, or whatever -- AND, they will continue to do so until they have the appropriate software on their machines to handle the conversion. That's what I expect. On the other hand, I do not expect that the IDN will eventually produce something that will transparently produce the appropriate glyphs on millions of users machines. In my mind, that's simply not possible because I think it requires that every machine on this planet have a complete copy of UNICODE installed and available. Granted, I am clueless about a lot of this IDN stuff and I may be "hubris" (as Mr. Paul Hoffman once informed me) in my offering my opinion to the "Gods of the Internet", but I do think I see the distinction between which side of the modem one is on and what responsibility lies in each camp. >OK, scenario 1: > >You tell him that although it's gobbledygook to people without greek >alphabet support, it will still work. It's not convenient, but it WILL work. >Guaranteed. For his business colleagues and friends in Greece, who DO have >the latest and greatest software, it will display as a delta. His ISP hasn't >had to upgrade, and everybody in the world can use his domain - eventually >they will see it as a delta as well, but for now they see it as an encoded >string they can still use no problem. ><-snip> >If you were IT director of a large firm, and you had a choice as to which to >roll out, which would you choose? > >-- >Paul Robinson I would vote for scenario 1. Besides, IMHO (in my hubris opinion) that's the only way it's going to work. tedd * The Greek version of "delta" registers a internal error -- it's the Math language set that provides an acceptable "delta". -- http://sperling.com From owner-idn@ops.ietf.org Thu Mar 21 11:31:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15937 for ; Thu, 21 Mar 2002 11:31:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o5FM-000FrA-00 for idn-data@psg.com; Thu, 21 Mar 2002 08:17:00 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.35 #1) id 16o5FL-000Fr4-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 08:16:59 -0800 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35044623D1; Thu, 21 Mar 2002 17:16:55 +0100 (CET) Date: Thu, 21 Mar 2002 09:51:56 -0600 From: Harald Tveit Alvestrand To: Masataka Ohta , Mark Davis Cc: idn@ops.ietf.org, ietf@ietf.org Subject: Re: [idn] Re: I don't want to be facing 8-bit bugs in 2013 Message-ID: <85471431.1016704316@localhost> In-Reply-To: <200203210748.QAA06034@necom830.hpcl.titech.ac.jp> References: <200203210748.QAA06034@necom830.hpcl.titech.ac.jp> X-Mailer: Mulberry/2.2.0b2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 21. mars 2002 16:47 +0859 Masataka Ohta wrote: > However, as Harald and I agreed, such products need local > context information OOB to work properly. apologies for indicating too strong an agreement.... we agree that for many functions that users would like software to perform (sorting being an obvious example), context information is needed to work properly. > > Then, the problem is that some local contexts are mutually exclusive. > > There is no instance of Unicode-based-local-character-set > internationally useful. I assert that for many functions (such as non-high-quality text display) in many locales, having information in Unicode-based character sets are useful without OOB information. Thus, Unicode is internationally useful - but we are deluding ourselves if we claim that it solves ALL problems. > > Some product using unicode may be usable in multiple local context, > if the context information is given OOB, and the product is valuable > in international market. > > However, unicode, still, is not usable in international context unless > OOB information, which, thanks to poor charset reviewing, essentaily is > yet another charset designaiton, is attached. We disagree on this point. I assert that the fact that charset does not give the required information is by DESIGN of the charset mechanism, not by "poor review". As a citizen of a continent where > 10 nations use the same character set (ISO 8859-1), but where locale requirements vary across the continent, I believe that separation of those concerns was a correct engineering decision. Just to make it clearer where Ohta and I agree, and where we disagree..... Harald From owner-idn@ops.ietf.org Thu Mar 21 11:50:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16975 for ; Thu, 21 Mar 2002 11:50:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o5Zp-000GYc-00 for idn-data@psg.com; Thu, 21 Mar 2002 08:38:09 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16o5Zo-000GYW-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 08:38:08 -0800 Message-ID: <02a501c1d0f7$192c07a0$ec333a41@EDMON15> From: "Edmon Chung" To: "Meritt James" , "Dave Crocker" Cc: , References: <5.1.0.14.2.20020320210727.026ab590@127.0.0.1> <3C99E960.6E090465@bah.com> Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever Date: Thu, 21 Mar 2002 11:40:22 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Meritt James" > Ah, but was there an implementable ANSWER? THAT is the question! > Here is a simple architecture/roadmap possibility: 1. IDNA user-end plugin - this plugin does all the heavy lifting to encode and decode ACE and display it properly for the user - servers does not upgrade. Even administration side is kept as is, allowing leakage for administrators - IDNA plugins must also be able to decode IDN(UTF8)/EDNS [This I will call UDNA for this discussion] 2. UDNA DNS Server upgrade - DNS servers will now accept both ACE and IDN(UTF8)/EDNS requests and provide consistent responses - IDNA plugins continue to send in ACE but will start to see UDNA responses 3. UDNA for clients & everywhere - IDNA plugins begin to obsolete, new versions of application software comes with UDNA built in. - In case DNS servers are not upgraded yet, clients will continue to use the IDNA plugin which will work fine with the new UDNA application. - Other applications/servers upgrade to UDNA to accept UTF8 domains, administrators might continue to see ACE leakage if the client still uses IDNA to send requests, but UDNA requests will be viewable and manageable in UTF8 4. UDNA - Slowly but certainly, we will move towards full UTF8 because administrators will likely want to deal with UTF8 than ACE, especially for say those admins in China who are dealing with IDNs frequently. You should be able to find holes in it, but it is whether the general concept is workable that is important. If so, THEN, we can work on refining the concept and putting it into a draft. And one of the key things is that UDNA MUST be included in an IDNA plugin to start with for the entire system to be able to move out of ACE and into UTF8 completely eventually. That is why we cannot and should not leave it out for now. Thoughts everyone? Edmon ----- Original Message ----- > Dave Crocker wrote: > > > > At 09:52 PM 3/20/2002 -0500, Edmon Chung wrote: > > >An underlying question we must ask ourselves from all the discussions that > > >have sprung up every now and then is: > > > > and as luck would have it, the working group has asked itself that question > > many times, so we need not pursue it again. > > > > d/ > > > > ---------- > > Dave Crocker > > TribalWise, Inc. > > tel +1.408.246.8253; fax +1.408.850.1850 > > -- > James W. Meritt CISSP, CISA > Booz | Allen | Hamilton > phone: (410) 684-6566 > From owner-idn@ops.ietf.org Thu Mar 21 11:55:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17207 for ; Thu, 21 Mar 2002 11:55:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o5dD-000GhO-00 for idn-data@psg.com; Thu, 21 Mar 2002 08:41:39 -0800 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.35 #1) id 16o5dC-000GhB-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 08:41:38 -0800 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH2VCdP/qtkd4HNnxkMElCseQOgZ4SJj3sg=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id GWFJ7WES; Thu, 21 Mar 2002 11:39:58 EST To: apb@cequrux.com Cc: idn@ops.ietf.org Date: Thu, 21 Mar 2002 08:54:46 -0800 Subject: Re: [idn] Re: Unicode is not usable in international context. Message-ID: <20020321.085446.-290675.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.5 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > (In contrast, I think I have learned enough by following the past > months of discussion to tell that the differences between Traditional > and Simplified Chinese are analogous to spelling differences, and so > IDN should not try to unify them.) > Hi, Alan Barrett: It is great to hear you have such an impression from the past months discussion on the list. This shows that the communication of TC/SC problem in IDN has marked the differences in our understanding of the real world problem, and this list is not dominated by Chinese and Korean users at all. As a Chinese user with limited education in Han character culture, but has been interested in computation in Chinese character processing in the past decades, I like to post a different picture for your reference. Chinese characters are larger character set than that of Latin (20,000+ vs. 52 minus those ancient symbols) and demonstrates much larger range of symbolic representation phenomenon of human languages. These phenomenon shall be and has to be classified into different levels to be handled by a computational process, otherwise there is no way you can see any characters on a computer screen. The problem of Chinese character processing or we call it "Chinese information processing" in the 1970's and "dictioary lookups" dated from centries ago, was faced with this classification problem started from Qin dynasty, when our ancestors tryed to communicate among different kingdoms. Now, We are still faced with the same problem on how to classify these characters to make it properly handled in IDN. To generalizing and call TC/SC is analogous to spelling differences is wrong, because they are equivalent in NAMEs as ONE unit of screen display, while spelling difference in Latin are equivalent in NAMEs as MORE THAN ONE unit of display, such as "color" vs. "colour". This difference makes the whole processing of computer- human text interface into two different category as we are discussed on this list. To follow the basic concept of ONE display unit on our screen, we are discuss allowing one unit of display to be extented from 52 ASCII characters to 50,000 USC characters. 1. Do we need all 50,000 USC identifiers for IDN? Do we need 50,000 x 3 characters as some Latin users trying to do? No, we do not need so many identifiers. That is the idea of defining equivalent character sets comes in. That is the gist of TC/SC must be in IDN debate. 2. Can we handle more than 50,000 characters? Yes. It is one level above in localized user interface to deal with. 3. Let us say that by using equivalent character set, we have dropped 50,000 down to 30,000 USC symbols, can we separate USC character's language context to avoid DNS level confusion? a). Some say, we don't care, that is not IDN problem, that is other group's problem. We only want IDN passes DNS without glitches. b). Some say, we care, USC code point gives that symbol back. The only viable solution is to use UTF8 or UTF16 to retain the original glyph. Your position may be consistent with a). I think we are different in how to divider Chinese characters into different levels for processing. People agree with b), have not taken the problem of look-alike symbols across different language boundary seriously as it may sound, in addition to other comments already repeated here. c). The Chinese group wants TS/SC in IDN rooted in experences in Chinese character processing and usage in the last three decades. I am not deny that some of them also somewhat like the idea of b). For internet stability and security maintenance, the only identities cannel has to be in DNS. Without character's language context, it is impossible to separate Greek/Cryllic/ Latin/Armenian characters consistently cross many levels of processing of different user applicantions, and the best examples are CUT & PASTE. The DNS has to have language context information for machines, the users as well as system administrators - that is transparently in the form of language tags, not some hidden tags just for machines. It has to be an integral part of a name label to function correctly through all the cut&paste operations. Sorry, that I shall stop here, since this discussion is far out of the group's scope, my posting right can be taken away soon. Regards, Liana Ye From owner-idn@ops.ietf.org Thu Mar 21 12:46:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19468 for ; Thu, 21 Mar 2002 12:46:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o6R6-000IMx-00 for idn-data@psg.com; Thu, 21 Mar 2002 09:33:12 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16o6R4-000IMm-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 09:33:11 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2LHduJ03626; Fri, 22 Mar 2002 00:39:58 +0700 (ICT) From: Robert Elz To: Masataka Ohta cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: [idn] Re: I don't want to be facing 8-bit bugs in 2013 In-Reply-To: <200203201557.AAA02490@necom830.hpcl.titech.ac.jp> References: <200203201557.AAA02490@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Mar 2002 00:39:56 +0700 Message-ID: <3624.1016732396@brandenburg.cs.mu.OZ.AU> Sender: owner-idn@ops.ietf.org Precedence: bulk Date: Thu, 21 Mar 2002 00:57:18 +0859 () From: Masataka Ohta Message-ID: <200203201557.AAA02490@necom830.hpcl.titech.ac.jp> Otha-san | Anyway, with the fix, there is no reason to prefer Unicode-based | local character sets, which is not widely used today, than existing | local character sets already used world wide. Let's assume that local char sets, and an explicit indication of which to use is adequate for this purpose (as Harald has said, and I agree, that's not sufficient for all purposes, but for stuff like domain names, file names, etc, I suspect it is). Then, let's take all the MIME names of those charsets, and number them, 0, 1, 2, 3, ... (as many as it takes), that's a 1::1 mapping, after all the mime charset names are in ascii, we wouldn't want to keep that. Then, rather than labelling whole names with a charset, we'll label every individual character, so if, by some strange chance, ascii (or 8859-1) happened to be allocated number 0, then 'A' would be 0-65. This way we can mix and match names with characters from any random character set (it may be a little less efficient than one label per name but that's OK, assume we'll pay that price for the flexibility). No, we'll just list all the possible characters in all the char sets, with their char set numbers attached, in one big table. What we have at that point is (essentially) 10646 - unicode. Just up above you said this works (throwing in some redundant labelling cannot cause it to stop working, nor can altering the labels from ascii to binary numerals). Of course, a large fraction of the char sets that we just listed in a big table contain ascii as a subset,so we end up with dozens of versions of A (it's in 8859-1 8859-2 ... tis-620 (Thai) ...). All of those A's are in all respects identical, keeping them will do no more than cause interoperability problems. So let's go through and squash all the duplicates. and then renumber everything to be a bit more compact (the renumbering is a 1::1 operation that alters nothing important). Having done that, we have exactly 10646 (or can have, if we picked the right character sets for our initial big list of everything, gave them the appropriate char set numbers, and compressed the number spaces in just the right way). Again, you said above, this works. The only place in all of this where there's any possibility of a problem is in the "squash all the duplicates" - if some characters that are duplicates aren't removed, or some that aren't are treated as if they are. If this happened, then there'd be a bug in the actual character tables (too many, or too few) - but this doesn't alter the principle of the thing. If there is a bug like this (which I am not able to judge) then someone should get it fixed. Whether or not there is a bug, the unicode/10646 approach is clearly the most flexible way, and is perfectly adequate for, labelling things using whatever characters anyone wants to use - internationally or locally. There is simply no way to rationally claim that a local char set, plus label, is adequate and unicode is not. kre From owner-idn@ops.ietf.org Thu Mar 21 15:15:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24021 for ; Thu, 21 Mar 2002 15:15:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o8bm-000MOW-00 for idn-data@psg.com; Thu, 21 Mar 2002 11:52:22 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16o8bl-000MOQ-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 11:52:21 -0800 Message-ID: <031f01c1d112$3b6229b0$ec333a41@EDMON15> From: "Edmon Chung" To: "Dave Crocker" Cc: , References: <5.1.0.14.2.20020320210727.026ab590@127.0.0.1> <3C99E960.6E090465@bah.com> <02a501c1d0f7$192c07a0$ec333a41@EDMON15> Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever Date: Thu, 21 Mar 2002 14:54:36 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dave You seem to be repeating my words in a slightly different "tone" ----- Original Message ----- From: "Dave Crocker" > the answer was that it is not happening now and we need to make a > transition that is independent of converting to utf-8 native. > My answer > >And as I recall, the answer to the question is, allow me to summarize "we > >will wait and see". There has never been a definitive answer or decision on > >this as yet. What is the difference. Please enlighten me. The result is still "it is not happening now", but the question is "will it happen in eventually", you have not answered the question. If it IS, then we should start working NOW. That is my point. If we collectively decide that it is NEVER going to happen and we will stay with ACE FOREVER, then, we should stop here and live happily ever after with ACE. But if the general direction or consensus is to move towards UTF8 eventually, then, we should start the work now. Edmon From owner-idn@ops.ietf.org Thu Mar 21 15:37:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24568 for ; Thu, 21 Mar 2002 15:37:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o93p-000Ni4-00 for idn-data@psg.com; Thu, 21 Mar 2002 12:21:21 -0800 Received: from inergen.sybase.com ([192.138.151.43]) by psg.com with esmtp (Exim 3.35 #1) id 16o93p-000Nhu-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 12:21:21 -0800 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id MAA07795 for ; Thu, 21 Mar 2002 12:20:59 -0800 (PST) Received: from smtp1.sybase.com (localhost [127.0.0.1]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id MAA12439 for ; Thu, 21 Mar 2002 12:21:19 -0800 (PST) Received: from olympus-dublin.sybase.com (olympus-dum.sybase.com [10.22.97.110]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id MAA12223; Thu, 21 Mar 2002 12:21:11 -0800 (PST) Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140]) by olympus-dublin.sybase.com (8.10.2+Sun/8.10.2) with ESMTP id g2LKK8b10533; Thu, 21 Mar 2002 12:20:08 -0800 (PST) Received: (from kenw@localhost) by birdie.sybase.com (8.8.8+Sun/8.8.8) id MAA11214; Thu, 21 Mar 2002 12:20:05 -0800 (PST) Date: Thu, 21 Mar 2002 12:20:05 -0800 (PST) From: Kenneth Whistler Message-Id: <200203212020.MAA11214@birdie.sybase.com> To: apb@cequrux.com Subject: Re: [idn] Re: Unicode is not usable in international context. Cc: idn@ops.ietf.org, kenw@sybase.com X-Sun-Charset: ISO-8859-1 Sender: owner-idn@ops.ietf.org Precedence: bulk Liana's response to Alan Barrett's questions wondered off into advocacy of language identity coding in name labels, so let me take another crack at the specific questions here. > On Thu, 21 Mar 2002, Masataka Ohta wrote: > > Unicode is not usable in international context. [...] Unicode is > > usable in some local context. [...] However, the context information > > must be supplied out of band. > > Let me see if I can understand this argument about Unicode and local > context. I am an English speaker who can't tell the difference between > the Chinese character that appears as the second character of the > Chinese word for the city that I call "Beijing", and the Japanese > character that appears as the second character of the Japanese word > for the city that I call "Tokyo". I believe that (as used in the city > names) both characters mean something like the English word "capital". Correct. The character you are talking about is U+4EAC in Unicode. It was borrowed into Japan from China roughly during the Tang dynasty period of China (along with thousands of others, as Buddhist monks and other travelers brought the Chinese writing system to Japan). > Say there's a Chinese character that looks (to uneducated western eyes) > like a box with three legs and a hat, and a Japanese character that > looks (to uneducated western eyes) like a box with three legs and a hat. > Say the Chinese character looks slightly different from the Japanese > character, but a Chinese person can easily recognise the Japanese > character and understand its meaning in context, and a Japanese person > can easily recognise the Chinese character and understand its meaning in > context. This is definitely and absolutely the case for this character. It is a very common use character (after all, it appears in the names of the capital cities of both countries), and is recognized by all literate speakers of either Japanese or Chinese. > As far as I understand, Unicode would say that these are not two > different characters, but just different display forms of the same > unified character (or whatever the correct technical terms are). Two glyphs used to display the same character, yes. > Display software would have to have out of band knowledge to help it > choose between the Chinese and Japanese display forms. Partly correct. As a character by itself, this would be true. However, it is also possible to apply heuristics on rather short strings of Japanese or Chinese characters to determine which language is involved. The heuristics would, however, tend to fail on short name labels as in URL's that might consist only of Han characters (= kanji in Japanese). But as others have pointed out, even determination of which *language* is involved doesn't determine what presentation is preferable to an end user. The general preference in Japan is to use Japanese-specific fonts, *even for the display of Chinese*. If you look at Japanese newspapers, they don't switch over to Chinese style fonts when citing the names of Chinese officials or Chinese placenames, for example. The issue is one of locale-based determination of typographical preferences in use, rather than language-based determination of which glyph to pick. > As far as I understand, absence of out of band knowledge could lead to > the hypothetical Unicode character a box with three legs and a hat> being displayed as if it were character that looks a bit like a box with three legs and a hat>, even > if the author's intent was to display bit like a box with three legs and a hat>. It is true that if you guess wrong, or don't have appropriate context, you can end up picking a Chinese style font for display when a user would have preferred a Japanese style font, or vice versa. The usual fix for that is to let the user set their preferences and then for the software to honor them rather than just guessing. But even then, this is not usually a problem. The average Watanabe Jiroo will usually have just Japanese fonts installed on his machine -- that is what he prefers and uses. The average Li Jianping will usually have just Chinese fonts installed on his machine -- that is what he prefers and uses. The question will only come up for people who have set up multilingual options on their machines, with both Japanese-style and Chinese-style fonts installed. And one other issue: the terms "CJK character", "Chinese character", and "Japanese character" are really all just different English translations of the *same* words (kanji in Japanese, han4zi in Mandarin Chinese), so in part the misunderstandings that arise about this topic result from mistaken presuppositions about the validity of the distinctions between the English translations of the terms. > As far as I understand, Masataka Ohta considers this to be a fatal flaw > in Unicode. I hope he will correct me if I have misunderstood his > objection. I can't speak for Ohta-san about his perception of the fatality of the "flaw" here, but he seems to be claiming basically that Unicode plain text doesn't provide you unambiguous indication of the context for choosing appropriate display, whereas ISO 2022-style code switching gives you in-band context, since you are explicitly switching between, say EUC-JP and EUC-CN, so you are picking between two distinct encodings associated with different countries (and languages). However, contrary to Ohta-san's implicit claims, having 2022 contexts doesn't solve your problem any better than before. Suppose I have an ISO 2022 stream of the following sort (schematically): ... tookyoo to beijing ... (for "Tokyo and Beijing", where I deliberately switch to EUC-CN and use the byte values from EUC-CN to encode the Chinese city name). Now how do I display that to a user? If I just blindly follow the 2022 context clues and switch to a Chinese font every time I encounter an EUC-CN stretch of text, and then display that to a Japanese end-user, I will get exactly the opposite of what I claimed above is Japanese typographical usage and end-user preference: i.e., just display everything, including the Chinese names, with Japanese fonts. So all this discussion about Unicode deficiencies and 2022 context superiority is just smoke and mirrors. Use of 2022 code-switching contexts don't help out with the *real* problem, which is to determine end-user preferences for styles. > > I don't know enough to tell whether the difference between corresponding > Chinese and Japanese characters is analogous to a font difference or > a spelling difference, but the "ignorant westerner can't tell the > difference" test biases me towards the "font difference" side. In this particular case, we are talking about a style difference for the *same* character. This is not even slightly in doubt. For an exhibit of the issue, see The Unicode Standard, Version 3.0, p. 631 for U+4EAC. The main code charts are printed with a commercial *Chinese* font, so you can see Chinese stylistic details in it. Then you can compare that with the same character printed on p. 927 of the standard, where you see the Shift-JIS index to Han characters, printed with a commercial *Japanese* font, so you can see Japanese stylistic details in it. U+4EAC is located on that page at 0x8B9E, its encoding in Shift-JIS. The main systematic difference between the glyphs in these two instances is in the very top stroke on the "hat". The Chinese style shows a "dian" stroke, a kind of teardropped shape that results from the calligraphic tradition of making a "dot" by lightly laying the brush down with the tip at the upper-left, and then pressing down a bit to create the heavier rounded part of the stroke. The Japanese style glyph instead shows a short vertical stroke that results from the calligraphic tradition of making a vertical stroke by starting with a dot, then lifting up the brush a bit and moving it slightly directly down. You can see that this is simply a systematic stylistic choice made in this Japanese font (and similarly in other Japanese fonts which follow this typographic tradition) by examining the hats on other characters on the same page: look at 0x8B9C, 0x8B9D, and also look at analogous top strokes on different components: 0x8B71, 0x8BF3, for example. There are other stylistic differences that can be noted between the commercial Chinese and Japanese fonts, but these are down at the level of detail that one would be concerned with, for example, in comparing an Arial font with a Helvetica font for Latin characters, for example. > If they > are analogous to spelling differences, then I would say that unifying > the different characters was probably an error in Unicode, Not an error. > but that IDN > should not try to undo that unification. Either way, I think that IDN > should document the potential problem but not try to fix it. Not a problem to be documented or fixed. > (In contrast, I think I have learned enough by following the past > months of discussion to tell that the differences between Traditional > and Simplified Chinese are analogous to spelling differences, and so IDN > should not try to unify them.) They are systematic differences yes, and should not be, and are not unified in the character encoding. Comparing them to spelling differences in English gets the quibblers a-quibbling, however, so is probably not the best analogy to use. Incidentally, to put the whole Chinese-style versus Japanese-style issue in context, the amount of variation noted across the various Arabic typographic traditions easily exceeds the kind of variation we are talking about in the East Asian typographic traditions for the presentation of Han characters. But nobody is rabblerousing that Unicode is fatally flawed because it only encoded a single Arabic character repertoire to meet the needs of all the Arabic styles and all the languages, from Moroccan Arabic to Yemeni Arabic, to Persian, to Urdu, to Uighur in China, to Malay that are represented using the Unicode encoded characters. In fact, eminent participants in Arabic font foundries are telling us that Unicode is precisely the correct technological foundation on which to build sophisticated Arabic rendering and display support for all those communities. Or if the "ignorant westerner[s] who can't tell the difference" would like an example closer to home, consider the variant forms of Roman and Fraktur "A"'s in use (a recent topic on the Unicode discussion list). Cf. the following German and Swiss newspaper mastheads: _A_nzeiger für Harlingerland Gießener _A_nzeiger Frankfurter _A_llgemeine Zeitung All of these are LATIN CAPITAL LETTER A, as are the various Roman-style "A"'s on the same pages -- although they *easily* exceed the level of structural difference that usually characterizes Chinese versus Japanese stylistic differences for the same characters. From the *encoding* context (all of these would be represented by ISO/IEC 8859-1, Latin-1), one cannot tell which glyph is correct in which context. Yet it would be a clear and obvious mistake to use the Fraktur style "A" from the Harlingerland newspaper to present the name of the Frankfurter Allgemeine Zeitung -- this thing is almost a trademarked font style, like the font that Woody Allen uses for all his movies. ;-) The fact that Unicode alone (or 8859-1 alone) as a character encoding does not provide sufficient context for international use of "A" while preserving all the font style differences is wholly beside the point. In fact, the "A" gets used exactly as it should, to convey the *character* identity, and then font distinctions are used to carry all the rest of the stylistic differences for presentation to end users. --Ken P.S. Sorry for the bandwidth somewhat off-topic. I'll go back to lurking again. ;-) P.P.S. My apologies in advance to Ohta-san for using some 8859-1 characters in this text, which he may reject with his boiler-plate comment: [Charset XXX unsupported, skipping...] If his Japanese email client can't handle 8859-1 characters for a discussion of German, even though my email client is 8859-1 based and can, I'd consider that an argument *for* switching to a Unicode-enabled email client. :-) From owner-idn@ops.ietf.org Thu Mar 21 16:56:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26818 for ; Thu, 21 Mar 2002 16:56:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oAN8-0003CT-00 for idn-data@psg.com; Thu, 21 Mar 2002 13:45:22 -0800 Received: from postman.incentivesystems.com ([66.152.247.37]) by psg.com with esmtp (Exim 3.35 #1) id 16oAN7-0003CH-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 13:45:21 -0800 To: ietf@ietf.org Cc: idn@ops.ietf.org Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 21 Mar 2002 16:55:22 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/21/2002 04:55:29 PM, Serialize complete at 03/21/2002 04:55:29 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk Edmon Chung wrote: >If we collectively decide that it is NEVER going to happen and we >will stay with ACE FOREVER, then, we should stop here and live happily ever >after with ACE. But if the general direction or consensus is to move >towards UTF8 eventually, then, we should start the work now. That does not follow. A UTF-8 transition would take a very long time (your idea about "plugins" is nonsense; there is no plugin architecture that can solve this problem for every app--probably not even for any app), so we need a good ACE solution for at least the next 5-10 years. Starting on a UTF-8 plan would consume resources that could better go into making the ACE solution work. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |"Music is not a noun, it's a verb." --John Perry Barlow | \========================================================/ From owner-idn@ops.ietf.org Thu Mar 21 17:21:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27430 for ; Thu, 21 Mar 2002 17:21:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oAie-0004f3-00 for idn-data@psg.com; Thu, 21 Mar 2002 14:07:36 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16oAid-0004eo-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 14:07:36 -0800 Message-ID: <037e01c1d125$1d886e00$ec333a41@EDMON15> From: "Edmon Chung" To: , "John Stracke" Cc: References: Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever Date: Thu, 21 Mar 2002 17:09:45 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John Stracke" > That does not follow. A UTF-8 transition would take a very long time > (your idea about "plugins" is nonsense; there is no plugin architecture > that can solve this problem for every app--probably not even for any app), > so we need a good ACE solution for at least the next 5-10 years. Starting > on a UTF-8 plan would consume resources that could better go into making > the ACE solution work. This is not true. A plugin could be "non-nonsensibly" created to intercept all domain requests and responses and doing the encode and decode for ACE accordingly. This is all we need to make ACE work. Leaking issues will be left out both for administrators to see and diagnose as well as to incent them to upgrade later to UTF8 compliant programs. Edmon From owner-idn@ops.ietf.org Thu Mar 21 17:25:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27532 for ; Thu, 21 Mar 2002 17:25:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oAkd-0004o4-00 for idn-data@psg.com; Thu, 21 Mar 2002 14:09:39 -0800 Received: from postman.incentivesystems.com ([66.152.247.37]) by psg.com with esmtp (Exim 3.35 #1) id 16oAkd-0004nx-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 14:09:39 -0800 To: ietf@ietf.org Cc: idn@ops.ietf.org Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 21 Mar 2002 17:19:41 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/21/2002 05:19:47 PM, Serialize complete at 03/21/2002 05:19:47 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk >A plugin could be "non-nonsensibly" created to intercept >all domain requests and responses and doing the encode and decode for ACE >accordingly. This is all we need to make ACE work. Provably false: well-coded applications know the limitations of domain names, and do not even attempt to make requests for non-ASCII names. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |"She gets kidnapped. He gets killed. But it turns out okay." --| |_Princess Bride_ poster | \===============================================================/ From owner-idn@ops.ietf.org Thu Mar 21 17:41:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28118 for ; Thu, 21 Mar 2002 17:41:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oB6T-0006IC-00 for idn-data@psg.com; Thu, 21 Mar 2002 14:32:13 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16oB6R-0006I4-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 14:32:11 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2LMW6t17451; Thu, 21 Mar 2002 17:32:07 -0500 (EST) Message-Id: <200203212232.g2LMW6t17451@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Edmon Chung" cc: ietf@ietf.org, idn@ops.ietf.org Subject: [idn] Re: Moving Towards UTF8 vs ASCII(ACE) Forever In-reply-to: (Your message of "Wed, 20 Mar 2002 21:52:34 EST.") <020901c1d083$74b55aa0$ec333a41@EDMON15> Date: Thu, 21 Mar 2002 17:32:06 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > Do we wish to > > 1. eventually move the DNS towards UTF8/16 OR > 2. do we want to stay with ASCII(ACE) for the rest of our lives? it's a false dichotomy. first, there are probably some purposes for which identifiers (including DNS names) should stay ASCII (and not even 10646 encoded as ASCII) for the forseeable purpose. there are other purposes for which IDNs are useful. second, "ASCII for the rest of our lives" is a mischaracterization. IDNA allows applications to accept and present IDNs in native form, without requiring all applications and infrastructure to upgrade before IDNs can be used. IDNA is designed to maximize the rate at which IDNs can be deployed. users don't care whether IDN queries are encoded on the wire. they only care about whether IDNs work for them. IDNA puts the user in a position to determine whether IDNs work for him - a UTF-8 everywhere approache forces him to wait for everybody else to adopt IDNs before he can use them. Keith From owner-idn@ops.ietf.org Thu Mar 21 17:41:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28136 for ; Thu, 21 Mar 2002 17:41:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oB2c-000620-00 for idn-data@psg.com; Thu, 21 Mar 2002 14:28:14 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16oB2b-00061q-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 14:28:14 -0800 Message-ID: <038c01c1d128$01764630$ec333a41@EDMON15> From: "Edmon Chung" To: , "John Stracke" Cc: References: Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever Date: Thu, 21 Mar 2002 17:30:27 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John Stracke" > Provably false: well-coded applications know the limitations of domain > names, and do not even attempt to make requests for non-ASCII names. First of all, I disagree with the "well-coded" part because I believe a well-coded application will do the dns request as is and allow the dns response to determine the validity of a domain name. Secondly, if this is the case, then the plugin should be intercepting the input to the app and not the output. It is still a possibility. The precise issue we are discussing is how well we need to make ACE. Do we accept leakages and work on UTF8 solution so that we will reach there sooner, or we spend 5-10 yrs figuring out ACE and then spend the next 50 years whining about it and moving it to UTF? Edmon From owner-idn@ops.ietf.org Thu Mar 21 17:48:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28341 for ; Thu, 21 Mar 2002 17:48:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oBBx-0006aW-00 for idn-data@psg.com; Thu, 21 Mar 2002 14:37:53 -0800 Received: from postman.incentivesystems.com ([66.152.247.37]) by psg.com with esmtp (Exim 3.35 #1) id 16oBBw-0006aK-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 14:37:53 -0800 To: ietf@ietf.org Cc: idn@ops.ietf.org Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 21 Mar 2002 17:47:54 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/21/2002 05:48:01 PM, Serialize complete at 03/21/2002 05:48:01 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk >> Provably false: well-coded applications know the limitations of domain >> names, and do not even attempt to make requests for non-ASCII names. > >First of all, I disagree with the "well-coded" part because I believe a >well-coded application will do the dns request as is and allow the dns >response to determine the validity of a domain name. Nope. You can almost certainly give your user a better error message if you validate the input yourself. For that matter, a well-designed application will not even make it possible to enter anything but ASCII in an input field (whatever) for a domain name. Basic rule of usability: making user mistakes impossible is better than catching them after the fact. >Secondly, if this is >the case, then the plugin should be intercepting the input to the app and >not the output. It is still a possibility. No, because that input is highly application-specific. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Diplomacy: The art of letting someone else have your way| \========================================================/ From owner-idn@ops.ietf.org Thu Mar 21 18:31:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29829 for ; Thu, 21 Mar 2002 18:31:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oBrV-00091F-00 for idn-data@psg.com; Thu, 21 Mar 2002 15:20:49 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16oBrU-000918-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 15:20:48 -0800 Message-ID: <009301c1d12f$4d1403f0$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Keith Moore" , "Edmon Chung" , "Jim Lam" Cc: , References: <200203212232.g2LMW6t17451@astro.cs.utk.edu> Subject: Re: [idn] Re: Moving Towards UTF8 vs ASCII(ACE) Forever Date: Thu, 21 Mar 2002 18:22:40 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Keith Moore" To: "Edmon Chung" Cc: ; Sent: Thursday, March 21, 2002 5:32 PM Subject: [idn] Re: Moving Towards UTF8 vs ASCII(ACE) Forever > second, "ASCII for the rest of our lives" is a mischaracterization. > IDNA allows applications to accept and present IDNs in native > form, without requiring all applications and infrastructure to > upgrade before IDNs can be used. IDNA is designed to maximize > the rate at which IDNs can be deployed. > I totally disagree with this, how can the deployment of IDNA speed up the rate of IDN deployment, given that IDNA has to upgrade all client applications or OS with a plug-in and deploying server-side solution for example at one ISP, or TLD will serve users in the 1000s. > users don't care whether IDN queries are encoded on the wire. > they only care about whether IDNs work for them. IDNA puts the > user in a position to determine whether IDNs work for him - > a UTF-8 everywhere approache forces him to wait for everybody > else to adopt IDNs before he can use them. That's why without a hybrid approach, IDN will never work. Especially IDNA, it has leakage(user cares because the ACE name is not the name they want to pay for!!), requires a plug-in, or future change in the application(which means not working nowadays even if we decide to deploy this). My own thinking is that the R&D effort of adding the ACE conversion to future applications is the same as making protocol change in future application. However, if you look at the transitional stage, using IDNA MUST require a plug-in, using a hybrid system will make the transition smoother, where most of the existing system works without plug-in and if future applications sends out new protocol will work as well. If you look at this as a simple math equation of what you get now and what you get in the future: Methods Now Future ACE+IDNA ~(x/100M)% 100% Hybrid ~95%* 100% (where x is the number of net user willing to install client plug-in, and roughly around 100M net users nowadays) *(from our official test results) At least you can get an average of (100+95)/2% throughout the deployment for Hybrid Systems, whereas using ACE in order to achieve the same result, can anyone of you tell me what x needs to be: 95M!! I thought we are engineers and scientists and this should be obvious enough and scientific enough to prove why we need a hybrid system to make the deployment of IDN more smooth(and Think for the users!!). David Leung Chief Technology Officer Neteka Inc. T: (416) 971-4302 http://w!.neteka.com From owner-idn@ops.ietf.org Thu Mar 21 19:04:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00821 for ; Thu, 21 Mar 2002 19:04:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oCO6-000BOW-00 for idn-data@psg.com; Thu, 21 Mar 2002 15:54:30 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.35 #1) id 16oCO5-000BOO-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 15:54:29 -0800 Received: (qmail 29054 invoked by uid 1001); 21 Mar 2002 23:50:07 -0000 Date: 21 Mar 2002 23:50:07 -0000 Message-ID: <20020321235007.20246.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk John Stracke writes: > For that matter, a well-designed application will not even make it > possible to enter anything but ASCII in an input field (whatever) for a > domain name. That's incredibly bad design. You're violating the basic principles of information hiding articulated by Parnas in the early 1970s. Instead of isolating the name-existence decision in one place (the DNS server's database), you're spreading the decision across a huge number of programs on a huge number of machines. Changing a decision becomes extremely expensive. We're seeing the economic consequences of this in BIND's res library. That library is the most widely used UNIX DNS-lookup mechanism, and is one of the largest sources of UTF-8 failures; see http://pi.cr.yp.to. It has to be fixed on a huge number of machines. (Note that this cost, together with the other costs of making UTF-8 IDNs work, is only a tiny fraction of the costs of making IDNA work.) If you think that the 8-bit problems in res are an example of people agreeing with your design ideas, you're mistaken. The change was made in a panic in 1996, when CERT announced that several programs had security flaws based on careless use of DNS PTR results. Of course, anyone who thinks about the problem for a moment can see that unusual DNS A _input_ has no relevance to the security issue, but people in a security-related panic often don't stop to think about the damage they're causing. > Basic rule of usability: making user mistakes impossible is > better than catching them after the fact. You obviously aren't achieving that goal. You're catching typos if and only if they involve non-ASCII characters. What about ASCII typos? What is the basis for your assertion that the no-such-name message should, as a matter of UI design, be different between these two situations? Even worse, what about ASCII typos that produce valid domain names? Basic rule of usability: Have the computer copy the data so that the user doesn't have an opportunity to make a mistake. Saves time, too. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Thu Mar 21 19:29:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01084 for ; Thu, 21 Mar 2002 19:29:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oCmc-000DKz-00 for idn-data@psg.com; Thu, 21 Mar 2002 16:19:50 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16oCmb-000DKn-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 16:19:49 -0800 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id QAA23945; Thu, 21 Mar 2002 16:19:34 -0800 Message-Id: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Mar 2002 18:11:43 -0600 To: "D. J. Bernstein" From: Dave Crocker Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever Cc: idn@ops.ietf.org In-Reply-To: <20020321235007.20246.qmail@cr.yp.to> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:50 PM 3/21/2002 +0000, D. J. Bernstein wrote: >ohn Stracke writes: > > For that matter, a well-designed application will not even make it > > possible to enter anything but ASCII in an input field (whatever) for a > > domain name. > >That's incredibly bad design. A UI that actually enforces the syntactic rules of the underlying service? Yes, indeed, that is truly a terrible idea. It would be much better to let users enter strings that are not valid so that some time in the future -- they can never be sure when -- the user's string will be found to be invalid and cause an error return to the user -- again, sometime later. Absolutely a superior outcome! d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Thu Mar 21 19:45:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01406 for ; Thu, 21 Mar 2002 19:45:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oCy6-000EHt-00 for idn-data@psg.com; Thu, 21 Mar 2002 16:31:42 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.35 #1) id 16oCy4-000EHL-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 16:31:40 -0800 Received: (qmail 1678 invoked by uid 1001); 22 Mar 2002 00:30:37 -0000 Date: 22 Mar 2002 00:30:37 -0000 Message-ID: <20020322003037.31068.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: [idn] 7 bits forever! References: <020901c1d083$74b55aa0$ec333a41@EDMON15> <200203212232.g2LMW6t17451@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Keith Moore writes: > IDNA is designed to maximize the rate at which IDNs can be deployed. I hereby declare that cs.utk.edu is an IDN. We will now spend twenty years trying to convince all application programs to display it as the international picture of an ostrich with his head in the sand. Look, Keith, we've deployed an IDN in zero time! Infinite rate! You didn't even have to touch your DNS records! Boy, I'm glad that, when you faced the much smaller problem of non-ASCII subject lines back in 1991, you and your buddies decided to ``maximize the rate'' of deployment by inventing your own encoding mechanisms, rather than giving in to the demands of 8-bit transparency. Oh, sure, we still have quite a few display failures eleven years later, and users in Europe are constantly sending raw ISO 8859-1 in violation of your 7-bit requirement, and sendmail still has problems with UTF-8, and now we're facing years of IDNA pain followed by years of IDNA-MAILBOX pain, but you were able to _instantaneously_ deploy Quoted-Printable back in 1991, and that's what matters! Brilliant! Even better, your incisive design decisions mean that billions of people will be able to continue using their 36-bit computers, which, as you know, are incapable of processing character data in units other than 7 bits, because 36 is not divisible by 8, but it is divisible by 7, um, well, except for the remainder of 1, but who's counting? The point is, Keith, THANK YOU! You've made all our lives so much better! I hope someday you can travel to Taiwan and meet some of your fans. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Thu Mar 21 20:10:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01834 for ; Thu, 21 Mar 2002 20:10:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oDO3-000GQM-00 for idn-data@psg.com; Thu, 21 Mar 2002 16:58:31 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16oDO2-000GQ8-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 16:58:30 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 31783; Thu, 21 Mar 2002 18:58:08 -0600 Message-ID: <3C9A81B3.89C5DB65@ehsco.com> Date: Thu, 21 Mar 2002 18:58:27 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Keith Moore CC: ietf@ietf.org, idn@ops.ietf.org Subject: [idn] Re: Moving Towards UTF8 vs ASCII(ACE) Forever References: <200203212232.g2LMW6t17451@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > it's a false dichotomy. > > first, there are probably some purposes for which identifiers > (including DNS names) should stay ASCII (and not even 10646 > encoded as ASCII) for the forseeable purpose. Agreed. Well-known data-types such as Message-ID are actually harmed if they exist in multiple forms (this also includes the transliterated form that results from IDNA). This is why implementation is a per-WG effort, not a global mandate. However, the infrastructure (in the broadest sense) should support native IDNs in order to facilitate the most effective scoping for any WG. > a UTF-8 everywhere approache forces him to wait for everybody > else to adopt IDNs before he can use them. lol, speaking of false dichotomies -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Mar 21 22:35:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06826 for ; Thu, 21 Mar 2002 22:35:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oFbj-0001Mw-00 for idn-data@psg.com; Thu, 21 Mar 2002 19:20:47 -0800 Received: from wireless-dhcp-188-118.ietf53.cw.net ([166.63.188.118] helo=localhost.localdomain) by psg.com with esmtp (Exim 3.35 #1) id 16oFbi-0001Mp-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 19:20:46 -0800 Received: (from newcat@localhost) by localhost.localdomain (8.11.3/8.11.3) id g2M3Kcq01269; Fri, 22 Mar 2002 12:20:38 +0900 X-Authentication-Warning: localhost.localdomain: newcat set sender to newcat@spsoft.co.kr using -f Date: Fri, 22 Mar 2002 12:20:38 +0900 From: YangWoo Ko To: Dave Crocker Cc: "D. J. Bernstein" , idn@ops.ietf.org Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever Message-ID: <20020322032033.GC940@spsoft.co.kr> References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, Mar 21, 2002 at 06:11:43PM -0600, Dave Crocker wrote: > At 11:50 PM 3/21/2002 +0000, D. J. Bernstein wrote: > >ohn Stracke writes: > >> For that matter, a well-designed application will not even make it > >> possible to enter anything but ASCII in an input field (whatever) for a > >> domain name. > > > >That's incredibly bad design. > > > A UI that actually enforces the syntactic rules of the underlying service? > > Yes, indeed, that is truly a terrible idea. > > It would be much better to let users enter strings that are not valid so > that some time in the future -- they can never be sure when -- the user's > string will be found to be invalid and cause an error return to the user -- > again, sometime later. > > Absolutely a superior outcome! in that sense, current design of ms ie is very bad. it just sends non ldh input to their seach engine ! -- /*------------------------------------------------ YangWoo Ko : newcat@spsoft.co.kr ------------------------------------------------*/ From owner-idn@ops.ietf.org Thu Mar 21 23:35:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08709 for ; Thu, 21 Mar 2002 23:35:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oGdA-0006Ao-00 for idn-data@psg.com; Thu, 21 Mar 2002 20:26:20 -0800 Received: from wireless-dhcp-188-118.ietf53.cw.net ([166.63.188.118] helo=localhost.localdomain) by psg.com with esmtp (Exim 3.35 #1) id 16oGd9-0006Ad-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 20:26:19 -0800 Received: (from newcat@localhost) by localhost.localdomain (8.11.3/8.11.3) id g2M4QNM01879 for idn@ops.ietf.org; Fri, 22 Mar 2002 13:26:23 +0900 X-Authentication-Warning: localhost.localdomain: newcat set sender to newcat@spsoft.co.kr using -f Date: Fri, 22 Mar 2002 13:26:23 +0900 From: YangWoo Ko To: idn@ops.ietf.org Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever Message-ID: <20020322042622.GA1853@spsoft.co.kr> References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: <20020322032033.GC940@spsoft.co.kr> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk On Fri, Mar 22, 2002 at 12:20:38PM +0900, YangWoo Ko wrote: > On Thu, Mar 21, 2002 at 06:11:43PM -0600, Dave Crocker wrote: > > At 11:50 PM 3/21/2002 +0000, D. J. Bernstein wrote: > > >ohn Stracke writes: > > >> For that matter, a well-designed application will not even make it > > >> possible to enter anything but ASCII in an input field (whatever) for a > > >> domain name. > > > > > >That's incredibly bad design. > > > > > > A UI that actually enforces the syntactic rules of the underlying service? > > > > Yes, indeed, that is truly a terrible idea. > > > > It would be much better to let users enter strings that are not valid so > > that some time in the future -- they can never be sure when -- the user's > > string will be found to be invalid and cause an error return to the user -- > > again, sometime later. > > > > Absolutely a superior outcome! > > in that sense, current design of ms ie is very bad. > it just sends non ldh input to their seach engine ! i withdraw above wrong statement. yves corrected me that "if the address looks like a domain name, ie first does a dns lookup of the domain name after encoding it in UTF-8" thanks to yves. i am still worndering what "looks like a domain name" means. -- /*------------------------------------------------ YangWoo Ko : newcat@spsoft.co.kr ------------------------------------------------*/ From owner-idn@ops.ietf.org Thu Mar 21 23:55:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09052 for ; Thu, 21 Mar 2002 23:55:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oGxO-0007gC-00 for idn-data@psg.com; Thu, 21 Mar 2002 20:47:14 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16oGxN-0007g0-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 20:47:14 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id NAA02286; Fri, 22 Mar 2002 13:47:07 +0900 Message-ID: <038101c1d15c$972f9940$a303a8c0@bruce> From: "Bruce Thomson" To: "YangWoo Ko" , "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever Date: Fri, 22 Mar 2002 13:46:54 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IE feature that translates domain names to UTF-8 is nice, but it's still some bugs and is not production level code. > > yves corrected me that "if the address looks like a domain name, > ie first does a dns lookup of the domain name after encoding it > in UTF-8" > > thanks to yves. > > i am still worndering what "looks like a domain name" means. > > -- > /*------------------------------------------------ > YangWoo Ko : newcat@spsoft.co.kr > ------------------------------------------------*/ > > From owner-idn@ops.ietf.org Fri Mar 22 09:36:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22567 for ; Fri, 22 Mar 2002 09:36:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oLvz-0001dn-00 for idn-data@psg.com; Fri, 22 Mar 2002 02:06:07 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16oLvy-0001dg-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 02:06:07 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2MA5qA15457 for ; Fri, 22 Mar 2002 19:05:56 +0900 Message-ID: <0a9f01c1d189$00baa040$2b19fea9@temp> From: "Soobok Lee" To: "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> Subject: Re: [idn] URL encoding in html page Date: Fri, 22 Mar 2002 19:04:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Bruce Thomson" To: "Soobok Lee" ; "IETF idn working group" Sent: Friday, March 22, 2002 6:29 PM Subject: Re: [idn] URL encoding in html page > > What if all the html viewable text is in english, but, only the href url contains > > legacy (korean) encoded hostnames? chinese visitors would see clean english homepage, > > but fail to click through the korean link. > > > Well, that could happen, but a META tag would solve that so easily. Personally > I often use a simple text editor to deal with HTML, and would find it easier to > use legacy encodings or UTF-8 than cut-and-paste ACE from somewhere. > Of course the user could do it either way and it would work. Yes. Charset META tags help. But, many homepages have assumptions on the main audience's default char encodings and very often omit the META tag for the encoding like : Moreover, IDN url would be used in a pure FRAMESET document that defines frame URLs and contains no viewable texts. Such FRAMESET documents often omit charset META tags. (look into the html source of http://www.freeway.co.kr/ ) AFIAK, 99.99999% of korean homepages have implicit/explicit legacy korean encoding (KS_C_5601-1987 or euc-kr). So do most japanese/chineses homepages. UTF8/UCS-2 encodings are rarely used in global WEB publishing. Legacy encodings will dominates even in the future, because it is compact and inexpensive. IF we want to make IDN truly internationally interoperable, all IDN-aware webbrowsers/applications should contain libaries of all kinds of legacy-to-Unicode conversion routines. It will burden too much memory load on handheld devices like PDA. Moreover, legacy encodings are revised separately from unicode. We may face with as toughest versioning problems as we did in stringprep/nameprep versioning problems for newly added unicode points. How to guarantee stability and intergrity of IDN operations in the all combinations of numerous kinds and versions of iDN-aware applications and legacy encodings? Soobok Lee From owner-idn@ops.ietf.org Fri Mar 22 09:36:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22578 for ; Fri, 22 Mar 2002 09:36:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oLMf-000Pme-00 for idn-data@psg.com; Fri, 22 Mar 2002 01:29:37 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16oLMe-000PmY-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 01:29:36 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id SAA03713; Fri, 22 Mar 2002 18:29:31 +0900 Message-ID: <03b201c1d184$09260760$a303a8c0@bruce> From: "Bruce Thomson" To: "Soobok Lee" , "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> Subject: Re: [idn] URL encoding in html page Date: Fri, 22 Mar 2002 18:29:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > What if all the html viewable text is in english, but, only the href url contains > legacy (korean) encoded hostnames? chinese visitors would see clean english homepage, > but fail to click through the korean link. > Well, that could happen, but a META tag would solve that so easily. Personally I often use a simple text editor to deal with HTML, and would find it easier to use legacy encodings or UTF-8 than cut-and-paste ACE from somewhere. Of course the user could do it either way and it would work. > MS IE 6.0 already know IDNA or UDNS? Otherwise , do you mean that IE determines > the encoding correctly if charset tags are present in appropirate section > in html pages ? > Right, except for the base URL bug I mentioned, it works fine. > Is HTTP/1.2 being planned for IDN HOST: values ? > If not, HTTP/1.2 HOST: values should not contain any legacy/utf8 encoding. > Well, depending on how you want it to work, version 1.1 might be OK. It allows %-escaped UTF-8 I believe. And the Apache web server takes it OK. Of course if the browser sent ACE that would work too, and doesn't exactly violate 1.1, but in that case you have to make sure that all your virtual site definitions at the server are in ACE or that the server does the translation. Would using ACE here be a change to the HTTP spec, or would an out-of-band agreement be OK? Bruce From owner-idn@ops.ietf.org Fri Mar 22 09:36:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22608 for ; Fri, 22 Mar 2002 09:36:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oKWj-000Ljw-00 for idn-data@psg.com; Fri, 22 Mar 2002 00:35:57 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16oKWi-000Ljn-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 00:35:57 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2M8ZgA14750 for ; Fri, 22 Mar 2002 17:35:42 +0900 Message-ID: <0a3d01c1d17c$6523cf00$2b19fea9@temp> From: "Soobok Lee" To: "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> Subject: Re: [idn] URL encoding in html page Date: Fri, 22 Mar 2002 17:34:19 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Bruce Thomson" To: "Soobok Lee" ; "IETF idn working group" Sent: Friday, March 22, 2002 5:14 PM Subject: Re: [idn] URL encoding in html page > Encodings of anything on an HTML page are an issue as well. Various > methods are already defined for the codeset to be determined, so > whether UTF-8, legacy encodings, or ACE are used, there shouldn't > be a problem. If uses a different encoding for the URL from the rest > he will have a problem, What if all the html viewable text is in english, but, only the href url contains legacy (korean) encoded hostnames? chinese visitors would see clean english homepage, but fail to click through the korean link. > but that's no different than if he tried to mix > two different legacy encodings in his text without intervening META > tags. > > By the way idns in HTML already work pretty well, except that IE can't handle > an idn in its base for relative URLS (unless of course you specify > explicit ACE in your BASE directive). Until Microsoft fixes this, just > use absolute URLs. MS IE 6.0 already know IDNA or UDNS? Otherwise , do you mean that IE determines the encoding correctly if charset tags are present in appropirate section in html pages ? > > IDNA probably doesn't need to make a recomendation here. What is more > critical is how the browser sends the data in the HTTP headers. Is HTTP/1.2 being planned for IDN HOST: values ? If not, HTTP/1.2 HOST: values should not contain any legacy/utf8 encoding. Soobok Lee > > Bruce > > > > > If a simple HTML page contains the following tag, > > .com>Hello World! > > in which, maybe in a native legacy encoding or utf8 encoding, it is easy to imagine that > > some vistors who click that link may be led to wrong sites or nowhere. > > > > When encoding is not specified by HTML charset tags and > > the author and visitors have different default char encodings, > > interoperability problems will surge on , no matter which architure we > > choose between IDNA and UTF8-based IDN. IDN-non-aware and even IDN-aware > > Web Browsers would not be able to decide which encoding was used by the author. > > > > IDNA-non-aware browsers will always fail to resolve native encoded Web Hostmaname in the URL, > > even when the html page has specified its charset encoding in the section. > > In this case, IDNA backward compatibility cannot save the old browser from failures, > > without dns/webserver workarounds for on-the-fly native-to-ACE heuristic encodings. > > > > With LDH-only URL, we had no such problems and headaches. > > > > someone may argue that the html URL should have to contain ACEed URL like this: > > > > Hello World! > > > > Should IDNA recommend all HTML authors to use such ACEed URL for backward compatilbility > > and error-free fast deployment? > > > > > > > > > > > > From owner-idn@ops.ietf.org Fri Mar 22 09:36:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22623 for ; Fri, 22 Mar 2002 09:36:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oKD0-000K1R-00 for idn-data@psg.com; Fri, 22 Mar 2002 00:15:34 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16oKCz-000K1I-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 00:15:33 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id RAA03244; Fri, 22 Mar 2002 17:15:03 +0900 Message-ID: <039b01c1d179$a25b6070$a303a8c0@bruce> From: "Bruce Thomson" To: "Soobok Lee" , "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> Subject: Re: [idn] URL encoding in html page Date: Fri, 22 Mar 2002 17:14:48 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Encodings of anything on an HTML page are an issue as well. Various methods are already defined for the codeset to be determined, so whether UTF-8, legacy encodings, or ACE are used, there shouldn't be a problem. If uses a different encoding for the URL from the rest he will have a problem, but that's no different than if he tried to mix two different legacy encodings in his text without intervening META tags. By the way idns in HTML already work pretty well, except that IE can't handle an idn in its base for relative URLS (unless of course you specify explicit ACE in your BASE directive). Until Microsoft fixes this, just use absolute URLs. IDNA probably doesn't need to make a recomendation here. What is more critical is how the browser sends the data in the HTTP headers. Bruce > > If a simple HTML page contains the following tag, > .com>Hello World! > in which, maybe in a native legacy encoding or utf8 encoding, it is easy to imagine that > some vistors who click that link may be led to wrong sites or nowhere. > > When encoding is not specified by HTML charset tags and > the author and visitors have different default char encodings, > interoperability problems will surge on , no matter which architure we > choose between IDNA and UTF8-based IDN. IDN-non-aware and even IDN-aware > Web Browsers would not be able to decide which encoding was used by the author. > > IDNA-non-aware browsers will always fail to resolve native encoded Web Hostmaname in the URL, > even when the html page has specified its charset encoding in the section. > In this case, IDNA backward compatibility cannot save the old browser from failures, > without dns/webserver workarounds for on-the-fly native-to-ACE heuristic encodings. > > With LDH-only URL, we had no such problems and headaches. > > someone may argue that the html URL should have to contain ACEed URL like this: > > Hello World! > > Should IDNA recommend all HTML authors to use such ACEed URL for backward compatilbility > and error-free fast deployment? > > > > > > From owner-idn@ops.ietf.org Fri Mar 22 09:36:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22630 for ; Fri, 22 Mar 2002 09:36:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oJyv-000Ie3-00 for idn-data@psg.com; Fri, 22 Mar 2002 00:01:01 -0800 Received: from smtprelay2.dc3.adelphia.net ([24.50.78.5]) by psg.com with esmtp (Exim 3.35 #1) id 16oJyu-000Idr-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 00:01:00 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.61]) by smtprelay2.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GTD7LJ00.T5H; Fri, 22 Mar 2002 03:00:56 -0500 Message-ID: <009601c1d177$71137ae0$3d424244@anhmca.adelphia.net> From: "Doug Ewell" To: "IETF idn working group" Cc: "Soobok Lee" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> Subject: Re: [idn] URL encoding in html page Date: Thu, 21 Mar 2002 23:59:05 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Soobok Lee wrote: > someone may argue that the html URL should have to contain ACEed > URL like this: > > Hello World! > > Should IDNA recommend all HTML authors to use such ACEed URL > for backward compatilbility and error-free fast deployment? It certainly seems like a sensible approach. Users wouldn't have to see the ACE (unless they go poking around in the HTML source), and any browser, even old versions, would be able to resolve it. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Fri Mar 22 09:36:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22641 for ; Fri, 22 Mar 2002 09:36:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oJg4-000HqC-00 for idn-data@psg.com; Thu, 21 Mar 2002 23:41:32 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16oJg3-000Hph-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 23:41:31 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id DC65FFFC0E; Fri, 22 Mar 2002 15:39:48 +0800 (SGT) Message-ID: <05d701c1d174$de044d80$dd00a8c0@jamessonyviao> From: "James Seng" To: "Soobok Lee" , "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> Subject: Re: [idn] URL encoding in html page Date: Fri, 22 Mar 2002 15:40:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a good question, one which is related to IDN & URL. Check this out: http://www.i-d-n.net/draft/draft-masinter-url-i18n-07.txt -James Seng > Hello World! > > Should IDNA recommend all HTML authors to use such ACEed URL for backward compatilbility > and error-free fast deployment? From owner-idn@ops.ietf.org Fri Mar 22 09:36:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22655 for ; Fri, 22 Mar 2002 09:36:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oJRU-000HGK-00 for idn-data@psg.com; Thu, 21 Mar 2002 23:26:28 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16oJRT-000HGA-00 for idn@ops.ietf.org; Thu, 21 Mar 2002 23:26:28 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2M7QDA14287 for ; Fri, 22 Mar 2002 16:26:13 +0900 Message-ID: <09df01c1d172$b01508d0$2b19fea9@temp> From: "Soobok Lee" To: "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> Subject: [idn] URL encoding in html page Date: Fri, 22 Mar 2002 16:25:04 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If a simple HTML page contains the following tag, .com>Hello World! in which, maybe in a native legacy encoding or utf8 encoding, it is easy to imagine that some vistors who click that link may be led to wrong sites or nowhere. When encoding is not specified by HTML charset tags and the author and visitors have different default char encodings, interoperability problems will surge on , no matter which architure we choose between IDNA and UTF8-based IDN. IDN-non-aware and even IDN-aware Web Browsers would not be able to decide which encoding was used by the author. IDNA-non-aware browsers will always fail to resolve native encoded Web Hostmaname in the URL, even when the html page has specified its charset encoding in the section. In this case, IDNA backward compatibility cannot save the old browser from failures, without dns/webserver workarounds for on-the-fly native-to-ACE heuristic encodings. With LDH-only URL, we had no such problems and headaches. someone may argue that the html URL should have to contain ACEed URL like this: Hello World! Should IDNA recommend all HTML authors to use such ACEed URL for backward compatilbility and error-free fast deployment? From owner-idn@ops.ietf.org Fri Mar 22 09:36:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22663 for ; Fri, 22 Mar 2002 09:36:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oJPT-000H9W-00 for idn-data@psg.com; Thu, 21 Mar 2002 23:24:23 -0800 From: "Meritt James" Organization: Booz | Allen | Hamilton X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Crocker CC: Edmon Chung , ietf@ietf.org, idn@ops.ietf.org Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 21 Mar 2002 23:24:23 -0800 Content-Transfer-Encoding: 7bit Ah, but was there an implementable ANSWER? THAT is the question! Dave Crocker wrote: > > At 09:52 PM 3/20/2002 -0500, Edmon Chung wrote: > >An underlying question we must ask ourselves from all the discussions that > >have sprung up every now and then is: > > and as luck would have it, the working group has asked itself that question > many times, so we need not pursue it again. > > d/ > > ---------- > Dave Crocker > TribalWise, Inc. > tel +1.408.246.8253; fax +1.408.850.1850 -- James W. Meritt CISSP, CISA Booz | Allen | Hamilton phone: (410) 684-6566 From owner-idn@ops.ietf.org Fri Mar 22 10:05:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23298 for ; Fri, 22 Mar 2002 10:05:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oQIh-000Idm-00 for idn-data@psg.com; Fri, 22 Mar 2002 06:45:51 -0800 Received: from foo-bar-baz.cc.vt.edu ([128.173.14.103]) by psg.com with esmtp (Exim 3.35 #1) id 16oQIg-000Idc-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 06:45:51 -0800 Received: from foo-bar-baz.cc.vt.edu (valdis@localhost [127.0.0.1]) by foo-bar-baz.cc.vt.edu (8.12.2/8.12.2) with ESMTP id g2MEibm8030349; Fri, 22 Mar 2002 09:44:37 -0500 Message-Id: <200203221444.g2MEibm8030349@foo-bar-baz.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: "D. J. Bernstein" Cc: idn@ops.ietf.org, ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: [idn] Re: 7 bits forever! In-Reply-To: Your message of "Fri, 22 Mar 2002 00:30:37 GMT." <20020322003037.31068.qmail@cr.yp.to> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <200203212232.g2LMW6t17451@astro.cs.utk.edu> <20020322003037.31068.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1007797489P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 22 Mar 2002 09:44:37 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --==_Exmh_-1007797489P Content-Type: text/plain; charset=us-ascii On Fri, 22 Mar 2002 00:30:37 GMT, "D. J. Bernstein" said: > Boy, I'm glad that, when you faced the much smaller problem of non-ASCII > subject lines back in 1991, you and your buddies decided to ``maximize > the rate'' of deployment by inventing your own encoding mechanisms, > rather than giving in to the demands of 8-bit transparency. Oh, sure, we The MIME and ESMTP working groups had *quite* a bit of infighting on that topic. There was a large contingent that wanted to declare "just send 8 bit" the standard. Re-reading RFC1428 and realizing that at the time, there were a *LARGE* number of systems that broke badly if they were handed 8 bit data. You can't blame Keith for that one - there were a LARGE number of people involved. And there was a basic non-negotiable design goal for MIME that had to be followed: A MESSAGE HAD TO GET THERE INTACT EVEN IF IT PASSED THROUGH A NON-MIME-AWARE SYSTEM. This is in all-caps because it's important. For instance, RFC2047-style header encoding happened because you could *NOT* trust that all the systems between here and there were 8-bit-clean (in fact, an 8-bit-clean system was a rarity) - and if the third or fourth system that the mail passed through happened to be non-MIME, it might do something nasty (like fold characters in 128-255 down into the lower half, or bounce the message because it was invalid RFC822 because RFC822 *clearly* says ASCII, and non-ASCII is therefor illegal). Let's take as an example the "native language" encoding of my name: From: Valdis Kl=?iso8859-4?Q?=BA?=tnieks (That's a "small e with macron", Unicode 0113). If you have a *better* suggestion than 2047-encoding of how to pass that character in an e-mail header *that will survive passing through an intermediary system that enforces strict RFC822*, please clue us in.... Why is this important? Well.. think about this message. I may have an 8-bit-clean mailer. You may have one. But neither of us has the authority to make sure that the software at ietf.org is able to deal. Those who think the DNS is being overly strict in enforcing ASCII in domain names are invited to consider the following: 1) RFC1035 says this in section 3.1: Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions. Name servers and resolvers must compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII with zero parity. Non-alphabetic codes must match exactly. RFC2181, section 11, re-iterates that the DNS is codeset-agnostic. So what do you know... the DNS spec is already using an N-bit-clean length-data encoding. So obviously there's some Very Evil Restriction that makes it not allow non-ASCII. And the favorite whipping boy here is BIND, which by default restricts it (you can put 'check-names off;' for a zone in the named.conf file, and you can put 'options no-check-names' in your resolv.conf). 2) Why does it get restricted? Consider the parsing issues involved if you have a domain name that uses raw Unicode and embeds the character known as "Malayalam Letter UU". A hint why this is Very Bad are available at http://www.unicode.org/charts/PDF/U0D00.pdf And of course, the true bugbear here is that you can create a domain name that contains Malayalam Letter UU, and it will work Just Fine with all the Neat New Software you've installed. However, you have to deal with the reality that 90% of the users are going to try to contact your site using either a web browser or an email client shipped by one vendor - and that vendor hasn't shipped a version compatible with Your New Neat Stuff. So if you use some New Method that breaks that software, you're not going to be talking to many people.... Hmm... maybe "backwards compatability" and "dont break existing users" *are* important after all..... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-1007797489P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8m0NVcC3lWbTT17ARAp5jAJ0XIOSBmHeO+9XN8WDAev/qaV4M+QCfdiuB PgL3PDClqOENHVu1ItWpxnI= =iWl8 -----END PGP SIGNATURE----- --==_Exmh_-1007797489P-- From owner-idn@ops.ietf.org Fri Mar 22 10:29:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23677 for ; Fri, 22 Mar 2002 10:29:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oQnp-000L7t-00 for idn-data@psg.com; Fri, 22 Mar 2002 07:18:01 -0800 Received: from rwcrmhc54.attbi.com ([216.148.227.87]) by psg.com with esmtp (Exim 3.35 #1) id 16oQno-000L7j-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 07:18:00 -0800 Received: from c1340594a ([12.234.212.162]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020322151759.VUFC1214.rwcrmhc54.attbi.com@c1340594a>; Fri, 22 Mar 2002 15:17:59 +0000 Message-ID: <009c01c1d1b4$c6a2efd0$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Soobok Lee" , "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <0a9f01c1d189$00baa040$2b19fea9@temp> Subject: Re: [idn] URL encoding in html page Date: Fri, 22 Mar 2002 07:18:09 -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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Compliant browsers already have to handle Unicode, since NCRs (e.g. ሴ ) are always Unicode code points. All XML parsers also have to handle Unicode (UTF-8 and UTF-16). > Legacy encodings > will dominates even in the future, because it is compact and > inexpensive. While I do expect the transition to Unicode to take some time, once some of the older browsers die off it may shift more rapidly than we think. Mark ————— Γνῶθι σαυτόν — Θαλῆς [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: "Soobok Lee" To: "IETF idn working group" Sent: Friday, March 22, 2002 02:04 Subject: Re: [idn] URL encoding in html page > > ----- Original Message ----- > From: "Bruce Thomson" > To: "Soobok Lee" ; "IETF idn working group" > Sent: Friday, March 22, 2002 6:29 PM > Subject: Re: [idn] URL encoding in html page > > > > > What if all the html viewable text is in english, but, only the href url contains > > > legacy (korean) encoded hostnames? chinese visitors would see clean english homepage, > > > but fail to click through the korean link. > > > > > Well, that could happen, but a META tag would solve that so easily. Personally > > I often use a simple text editor to deal with HTML, and would find it easier to > > use legacy encodings or UTF-8 than cut-and-paste ACE from somewhere. > > Of course the user could do it either way and it would work. > > Yes. Charset META tags help. But, many homepages have assumptions on the main audience's > default char encodings and very often omit the META tag for the encoding like : > > > Moreover, IDN url would be used in a pure FRAMESET document that defines frame URLs > and contains no viewable texts. Such FRAMESET documents often omit charset META tags. > (look into the html source of http://www.freeway.co.kr/ ) > > AFIAK, 99.99999% of korean homepages have implicit/explicit > legacy korean encoding (KS_C_5601-1987 or euc-kr). So do most japanese/chineses homepages. > UTF8/UCS-2 encodings are rarely used in global WEB publishing. Legacy encodings > will dominates even in the future, because it is compact and inexpensive. > > IF we want to make IDN truly internationally interoperable, all IDN-aware webbrowsers/applications > should contain libaries of all kinds of legacy-to-Unicode conversion routines. It will burden > too much memory load on handheld devices like PDA. > > Moreover, legacy encodings are revised separately from unicode. We may face with as toughest > versioning problems as we did in stringprep/nameprep versioning problems for newly added unicode points. > How to guarantee stability and intergrity of IDN operations in the all combinations of numerous kinds and versions of iDN-aware > applications and legacy encodings? > > Soobok Lee > > > From owner-idn@ops.ietf.org Fri Mar 22 10:33:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23834 for ; Fri, 22 Mar 2002 10:33:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oQy1-000LuQ-00 for idn-data@psg.com; Fri, 22 Mar 2002 07:28:33 -0800 Received: from citadel.cequrux.com ([192.96.22.18]) by psg.com with esmtp (Exim 3.35 #1) id 16oQxy-000Lu7-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 07:28:31 -0800 Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id RAA24578 for ; Fri, 22 Mar 2002 17:28:24 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 24490; Fri Mar 22 17:27:33 2002 Date: Fri, 22 Mar 2002 17:27:33 +0200 From: Alan Barrett To: idn@ops.ietf.org Subject: Re: [idn] Re: Unicode is not usable in international context. Message-ID: <20020322152733.GD25517@apb.cequrux.com> References: <20020321.085446.-290675.0.liana.ydisg@juno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020321.085446.-290675.0.liana.ydisg@juno.com> Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, 21 Mar 2002, liana Ye wrote: > To generalizing and call TC/SC is analogous to spelling > differences is wrong, because they are equivalent > in NAMEs as ONE unit of screen display, while spelling > difference in Latin are equivalent in NAMEs as MORE > THAN ONE unit of display, such as "color" vs. "colour". People have posted cases where the number of TC characters that make up a word is different from the number of SC characters that make up the same word. People have also posted cases where the number of characters remains the same but the mapping depends on context. People have stated that conversion between TC and SC requires a dictionary of words, rather than a table of characters. All these show that TC/SC is analogous to a spelling difference. I don't clain that TC/SC conversion or equivalence is not a problem. Neither do I claim that the potential confusion between and is not a problem. Neither do I claim that the potential confusion between English "theatre" and American "theater" or English "lift" and American "elevator" are not problems. But I believe that all these problems are outside the scope of IDN. --apb (Alan Barrett) From owner-idn@ops.ietf.org Fri Mar 22 11:26:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25197 for ; Fri, 22 Mar 2002 11:26:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oRkC-000Pv3-00 for idn-data@psg.com; Fri, 22 Mar 2002 08:18:20 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16oRkC-000Put-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 08:18:20 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2MGIFA18420; Sat, 23 Mar 2002 01:18:15 +0900 Message-ID: <0c0001c1d1bc$feb9f0a0$2b19fea9@temp> From: "Soobok Lee" To: "Mark Davis" , "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <0a9f01c1d189$00baa040$2b19fea9@temp> <009c01c1d1b4$c6a2efd0$8900a8c0@c1340594a> Subject: Re: [idn] URL encoding in html page Date: Sat, 23 Mar 2002 01:16:59 +0900 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit ----- Original Message ----- From: "Mark Davis" To: "Soobok Lee" ; "IETF idn working group" Sent: Saturday, March 23, 2002 12:18 AM Subject: Re: [idn] URL encoding in html page > Compliant browsers already have to handle Unicode, since NCRs (e.g. > ሴ ) are always Unicode code points. All XML parsers also have > to handle Unicode (UTF-8 and UTF-16). Right, Already. MS IE and NEtscape already have been supporting UNICODE from serveral year ago, but still most homepages are in legacy encodings. MS WORD (already unicode based) have features to produce (from unicode-based .doc files) legacy encoded .html files for web publishing Korean/Japanese/Chinese texts in UTF8 are 50% bigger than legacy ones. 50% more disk space and bandwidth will be required. Each Cyrillic alhpabet in legacy code occupy one octet, while in UTF8, it requires 3 octets. 200% more space is needed. I cannot imagine the entire Russians make transition to UTF8. Legacy encnodings are more space efficient than UNICODE. legacy-to-legacy conversions like BIG5->KSX1001 are really being implemented as two steps of BIG5->UNICODE and UNICODE->KSX1001. UNICODE are actively used as such intermediate encodings, but still not be used and entered directly by end users so actively. Rather, UNICODE may be a hub to facilitate interchange of informations in different legacy encodings or font sharing for differently legacy-encoded chars. I regard UNICODE as a substrate (not as a competitor) upon which legacy encodings are built. > > > Legacy encodings > > will dominates even in the future, because it is compact and > > inexpensive. > > While I do expect the transition to Unicode to take some time, once > some of the older browsers die off it may shift more rapidly than we > think. I am not UNICODE expert nor character expert. But, everyday, i feel the strong inertia toward legacy encodings in our local language communties. language-tagging-enabled text format like HTML will lengthen the lifespan of legacy encodings by great amounts and allow legacy-coded HTML texts are internationally interchanged without problems. Soobok Lee > > Mark > ————— > > Γνῶθι σαυτόν — Θαλῆς > [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] > > http://www.macchiato.com > > ----- Original Message ----- > From: "Soobok Lee" > To: "IETF idn working group" > Sent: Friday, March 22, 2002 02:04 > Subject: Re: [idn] URL encoding in html page > > > > > > ----- Original Message ----- > > From: "Bruce Thomson" > > To: "Soobok Lee" ; "IETF idn working group" > > > Sent: Friday, March 22, 2002 6:29 PM > > Subject: Re: [idn] URL encoding in html page > > > > > > > > What if all the html viewable text is in english, but, only the > href url contains > > > > legacy (korean) encoded hostnames? chinese visitors would see > clean english homepage, > > > > but fail to click through the korean link. > > > > > > > Well, that could happen, but a META tag would solve that so > easily. Personally > > > I often use a simple text editor to deal with HTML, and would find > it easier to > > > use legacy encodings or UTF-8 than cut-and-paste ACE from > somewhere. > > > Of course the user could do it either way and it would work. > > > > Yes. Charset META tags help. But, many homepages have assumptions > on the main audience's > > default char encodings and very often omit the META tag for the > encoding like : > > > > > > Moreover, IDN url would be used in a pure FRAMESET document that > defines frame URLs > > and contains no viewable texts. Such FRAMESET documents often omit > charset META tags. > > (look into the html source of http://www.freeway.co.kr/ ) > > > > AFIAK, 99.99999% of korean homepages have implicit/explicit > > legacy korean encoding (KS_C_5601-1987 or euc-kr). So do most > japanese/chineses homepages. > > UTF8/UCS-2 encodings are rarely used in global WEB publishing. > Legacy encodings > > will dominates even in the future, because it is compact and > inexpensive. > > > > IF we want to make IDN truly internationally interoperable, all > IDN-aware webbrowsers/applications > > should contain libaries of all kinds of legacy-to-Unicode conversion > routines. It will burden > > too much memory load on handheld devices like PDA. > > > > Moreover, legacy encodings are revised separately from unicode. We > may face with as toughest > > versioning problems as we did in stringprep/nameprep versioning > problems for newly added unicode points. > > How to guarantee stability and intergrity of IDN operations in the > all combinations of numerous kinds and versions of iDN-aware > > applications and legacy encodings? > > > > Soobok Lee > > > > > > From owner-idn@ops.ietf.org Fri Mar 22 11:39:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25616 for ; Fri, 22 Mar 2002 11:39:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oRrp-0000XD-00 for idn-data@psg.com; Fri, 22 Mar 2002 08:26:13 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16oRro-0000X4-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 08:26:12 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 31850; Fri, 22 Mar 2002 10:25:51 -0600 Message-ID: <3C9B5B20.1E672650@ehsco.com> Date: Fri, 22 Mar 2002 10:26:08 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Valdis.Kletnieks@vt.edu CC: idn@ops.ietf.org, ietf@ietf.org, iab@isi.edu Subject: [idn] Re: 7 bits forever! References: <020901c1d083$74b55aa0$ec333a41@EDMON15> <200203212232.g2LMW6t17451@astro.cs.utk.edu> <20020322003037.31068.qmail@cr.yp.to> <200203221444.g2MEibm8030349@foo-bar-baz.cc.vt.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [cc trimmed] Valdis.Kletnieks@vt.edu wrote: > Why is this important? Well.. think about this message. I may have > an 8-bit-clean mailer. You may have one. But neither of us has the > authority to make sure that the software at ietf.org is able to deal. WRT to your comments in particular, I agree that SMTP has the most difficulties. However, as stated, if something cannot be extended it can still be replaced. And in the meantime, IDNA should be there as a fallback position for these kinds of protocols. I mean, considering all of the problems that SMTP has -- sender forgeries, relay forgeries, lack of end-to-end integrity, and of course a lack of support for i18n email addresses -- it seems likely to be a candidate for replacement for other reasons anyway. That doesn't mean that the IDN tail should wag SMTP, but if SMTP cannot be upgraded, well, add that to the list of other things that SMTP doesn't do very well. In this regard, the IDN issue is just one of many that need to be considered (i18n mailbox names being another). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri Mar 22 12:33:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26864 for ; Fri, 22 Mar 2002 12:33:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oSjJ-0004qf-00 for idn-data@psg.com; Fri, 22 Mar 2002 09:21:29 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.35 #1) id 16oSjI-0004qU-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 09:21:28 -0800 Received: (qmail 22245 invoked by uid 1001); 22 Mar 2002 17:20:25 -0000 Date: 22 Mar 2002 17:20:24 -0000 Message-ID: <20020322172024.19557.qmail@cr.yp.to> Mail-Followup-To: ietf@ietf.org, iesg@ietf.org, iab@isi.edu, idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: ietf@ietf.org, iesg@ietf.org, iab@isi.edu Subject: Re: [idn] Re: 7 bits forever! References: <020901c1d083$74b55aa0$ec333a41@EDMON15> <200203212232.g2LMW6t17451@astro.cs.utk.edu> <20020322003037.31068.qmail@cr.yp.to> <200203221444.g2MEibm8030349@foo-bar-baz.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Valdis.Kletnieks@vt.edu writes: > you could *NOT* trust that all the systems > between here and there were 8-bit-clean I'm not saying that Quoted-Printable had no short-term benefits for its short-term costs. I'm saying that, viewed from our long-term perspective eleven years later, the failure to require 8-bit transparency was an amazingly stupid decision. If Keith Moore, Dave Crocker, Paul Vixie, et al. hadn't been so blind, they would have required 8-bit transparency for the long term, and then evaluated the costs and benefits of short-term 7-bit kludges in that framework. Probably the result would have been long-term 8-bit with no short-term kludges. Conceivably it would have been long-term 8-bit plus optional short-term Quoted-Printable. Either way, it would have been vastly better than what actually happened. Do you want to be having this discussion again in twenty years, with 8-bit problems still not fixed? > there were a *LARGE* number of systems that broke badly if they > were handed 8 bit data. Let's look at the facts. John Klensin claimed in an ietf-smtp message dated 26 Feb 91 08:40:04-EST that there were mail servers ``not robust against that particular form of misbehavior.'' Robert Ullmann publicly asked for proof of this claim. Klensin dodged the question. Similarly, Keith Moore claimed in a comp.mail.mime message, message ID 199710102108.RAA13469@spot.cs.utk.edu, that ``core-dumping was a commonly observed failure mode in the early 1990s.'' I publicly asked for proof of this claim. Moore dodged the question. Mail servers discarding characters? Yes. Mail servers stripping the 8th bit? Yes. Mail servers crashing? Not a single shred of evidence. Similarly, expanding from mail to all protocols: Rick Wesson claimed in an IDN WG message dated Sun, 24 Dec 2000 16:44:39 -0800 that ``there is a lot of embedded systems out there that would crash-and-burn if they received a reply in utf8.'' I asked for proof: Can you please identify the systems, explain how they use domain names, and say what exactly you mean by ``crash-and-burn''? We need this information if we're going to accurately assess the cost of upgrading the world to support IDNs. Naturally, Wesson dodged the question. I will readily agree that there has been an unverified report of a UTF-8 crash of an obsolete version of the Netscape mailer under Solaris. If that report is accurate then those users will have to upgrade. > BIND, which by default restricts it [ ... ] > Why does it get restricted? [ bogus rationalization snipped ] The actual history, as I mentioned in another message, is as follows. People discovered several years ago that sendmail would blindly feed DNS PTR results to the shell, so attackers could take over the computer by putting some special characters, such as |<>, into PTR records. The BIND people panicked and disabled all non-letter-digit-hyphen characters at every spot they could think of in their DNS client library. This isn't an 8-bit issue; it does just as much damage to underscores. > Let's take as an example the "native language" encoding of my name: > From: Valdis Kl=?iso8859-4?Q?=BA?=tnieks Wow. How do you pronounce that? ``Hi, I'm Valdis Klee-kwals-question- mark-iso-eighty-eight-fifty-nine-dash-four-question-mark-kyoo-question- mark-equals-bah-question-mark-equal-stun-ieks''? Have you considered changing your name? In all seriousness: Wouldn't you like to see a world where the same character encoding is used for the name and the address and the message body and so on, so that simple copying doesn't screw up the display? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Fri Mar 22 13:17:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27858 for ; Fri, 22 Mar 2002 13:17:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oTTE-0008VC-00 for idn-data@psg.com; Fri, 22 Mar 2002 10:08:56 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.35 #1) id 16oTTD-0008V0-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 10:08:55 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2MI8nt01544; Fri, 22 Mar 2002 13:08:49 -0500 (EST) Message-Id: <200203221808.g2MI8nt01544@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Eric A. Hall" cc: Valdis.Kletnieks@VT.EDU, idn@ops.ietf.org, ietf@ietf.org, iab@isi.edu Subject: [idn] Re: 7 bits forever! In-reply-to: (Your message of "Fri, 22 Mar 2002 10:26:08 CST.") <3C9B5B20.1E672650@ehsco.com> Date: Fri, 22 Mar 2002 13:08:49 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > I mean, considering all of the problems that SMTP has -- sender forgeries, > relay forgeries, lack of end-to-end integrity, and of course a lack of > support for i18n email addresses -- it seems likely to be a candidate for > replacement for other reasons anyway. That doesn't mean that the IDN tail > should wag SMTP, but if SMTP cannot be upgraded, well, add that to the > list of other things that SMTP doesn't do very well. In this regard, the > IDN issue is just one of many that need to be considered (i18n mailbox > names being another). if you can somehow solve the PKI problem, you can make SMTP immune to forgeries and have it provide end-to-end integrity. so far, nobody has managed to do this. if you can somehow figure out a way for anybody to type in a mailbox in any language on any keyboard, you can solve the i18n mailbox problem. until then, there's very marginal value in replacing SMTP. even then, it would probably be easier to upgrade SMTP than to replace it. Keith From owner-idn@ops.ietf.org Fri Mar 22 13:31:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28199 for ; Fri, 22 Mar 2002 13:31:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oTes-0009SB-00 for idn-data@psg.com; Fri, 22 Mar 2002 10:20:58 -0800 Received: from rwcrmhc54.attbi.com ([216.148.227.87]) by psg.com with esmtp (Exim 3.35 #1) id 16oTer-0009S3-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 10:20:57 -0800 Received: from c1340594a ([12.234.212.162]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020322182055.BZNI1214.rwcrmhc54.attbi.com@c1340594a>; Fri, 22 Mar 2002 18:20:55 +0000 Message-ID: <018001c1d1ce$550602d0$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Soobok Lee" , "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <0a9f01c1d189$00baa040$2b19fea9@temp> <009c01c1d1b4$c6a2efd0$8900a8c0@c1340594a> <0c0001c1d1bc$feb9f0a0$2b19fea9@temp> Subject: OT - Re: [idn] URL encoding in html page Date: Fri, 22 Mar 2002 10:21:05 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017C_01C1D18B.468894E0" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_017C_01C1D18B.468894E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From my experience talking with customers in the field, the main reason that people are not serving up UTF-8 pages is not the bandwidth, it is the fact that there are still some browsers out in the field that do not yet handle it correctly. While they are dying off fairly quickly, it is not quite at the point where people are willing to write them off. As far as size goes, it is worthwhile looking at some data samples. The following are from a page on the Unicode site that is translated into different languages, so it has essentially the same information on each page. Size Page 8882 s-chinese.html 8946 t-chinese.html 9347 esperanto.html 9498 maltese.html 9739 icelandic.html 9833 czech.html 9944 welsh.html 10064 danish.html 10109 swedish.html 10127 polish.html Size Page 10219 interlingua.html 10221 italian.html 10297 spanish.html 10308 portuguese.html 10312 lithuanian.html 10329 german.html 10376 romanian.html 10401 korean.html 10506 french.html Size Page 10726 japanese.html 10953 hebrew.html 11192 arabic.html 13292 greek.html 13870 russian.html 13892 persian.html 14549 hindi.html 15337 georgian.html 15853 deseret.html So the best case is about 50% of the worst case. Some of this is due to the encoding, and some is due to different languages just using different numbers of characters. However, when you look at web pages in general use, the amount of text (in bytes) is really swamped by graphics, Javascript, HTML code, and so on. So fundamentally, even the variations above are not that important in practice. BTW This is getting way off topic. Mark ————— Γνῶθι σαυτόν — Θαλῆς [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: "Soobok Lee" To: "Mark Davis" ; "IETF idn working group" Sent: Friday, March 22, 2002 08:16 Subject: Re: [idn] URL encoding in html page > > ----- Original Message ----- > From: "Mark Davis" > To: "Soobok Lee" ; "IETF idn working group" > Sent: Saturday, March 23, 2002 12:18 AM > Subject: Re: [idn] URL encoding in html page > > > > Compliant browsers already have to handle Unicode, since NCRs (e.g. > > ሴ ) are always Unicode code points. All XML parsers also have > > to handle Unicode (UTF-8 and UTF-16). > > Right, Already. > MS IE and NEtscape already have been supporting UNICODE > from serveral year ago, but still most homepages are in legacy encodings. > MS WORD (already unicode based) have features to produce (from > unicode-based .doc files) legacy encoded .html files for web publishing > > Korean/Japanese/Chinese texts in UTF8 are 50% bigger than legacy ones. > 50% more disk space and bandwidth will be required. > Each Cyrillic alhpabet in legacy code occupy one octet, while in UTF8, > it requires 3 octets. 200% more space is needed. > I cannot imagine the entire Russians make transition to UTF8. > Legacy encnodings are more space efficient than UNICODE. > > legacy-to-legacy conversions like BIG5->KSX1001 are really being implemented > as two steps of BIG5->UNICODE and UNICODE->KSX1001. UNICODE > are actively used as such intermediate encodings, but still not be used and entered > directly by end users so actively. Rather, UNICODE may be a hub to facilitate interchange > of informations in different legacy encodings or font sharing for differently legacy-encoded chars. > > I regard UNICODE as a substrate (not as a competitor) upon which legacy encodings are built. > > > > > > Legacy encodings > > > will dominates even in the future, because it is compact and > > > inexpensive. > > > > While I do expect the transition to Unicode to take some time, once > > some of the older browsers die off it may shift more rapidly than we > > think. > > I am not UNICODE expert nor character expert. But, everyday, i feel > the strong inertia toward legacy encodings in our local language communties. > language-tagging-enabled text format like HTML will lengthen the lifespan > of legacy encodings by great amounts and allow legacy-coded HTML texts > are internationally interchanged without problems. > > Soobok Lee > > > > > Mark > > ————— > > > > Γνῶθι σαυτόν — Θαλῆς > > [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] > > > > http://www.macchiato.com > > > > ----- Original Message ----- > > From: "Soobok Lee" > > To: "IETF idn working group" > > Sent: Friday, March 22, 2002 02:04 > > Subject: Re: [idn] URL encoding in html page > > > > > > > > > > ----- Original Message ----- > > > From: "Bruce Thomson" > > > To: "Soobok Lee" ; "IETF idn working group" > > > > > Sent: Friday, March 22, 2002 6:29 PM > > > Subject: Re: [idn] URL encoding in html page > > > > > > > > > > > What if all the html viewable text is in english, but, only the > > href url contains > > > > > legacy (korean) encoded hostnames? chinese visitors would see > > clean english homepage, > > > > > but fail to click through the korean link. > > > > > > > > > Well, that could happen, but a META tag would solve that so > > easily. Personally > > > > I often use a simple text editor to deal with HTML, and would find > > it easier to > > > > use legacy encodings or UTF-8 than cut-and-paste ACE from > > somewhere. > > > > Of course the user could do it either way and it would work. > > > > > > Yes. Charset META tags help. But, many homepages have assumptions > > on the main audience's > > > default char encodings and very often omit the META tag for the > > encoding like : > > > > > > > > > Moreover, IDN url would be used in a pure FRAMESET document that > > defines frame URLs > > > and contains no viewable texts. Such FRAMESET documents often omit > > charset META tags. > > > (look into the html source of http://www.freeway.co.kr/ ) > > > > > > AFIAK, 99.99999% of korean homepages have implicit/explicit > > > legacy korean encoding (KS_C_5601-1987 or euc-kr). So do most > > japanese/chineses homepages. > > > UTF8/UCS-2 encodings are rarely used in global WEB publishing. > > Legacy encodings > > > will dominates even in the future, because it is compact and > > inexpensive. > > > > > > IF we want to make IDN truly internationally interoperable, all > > IDN-aware webbrowsers/applications > > > should contain libaries of all kinds of legacy-to-Unicode conversion > > routines. It will burden > > > too much memory load on handheld devices like PDA. > > > > > > Moreover, legacy encodings are revised separately from unicode. We > > may face with as toughest > > > versioning problems as we did in stringprep/nameprep versioning > > problems for newly added unicode points. > > > How to guarantee stability and intergrity of IDN operations in the > > all combinations of numerous kinds and versions of iDN-aware > > > applications and legacy encodings? > > > > > > Soobok Lee > > > > > > > > > > > > ------=_NextPart_000_017C_01C1D18B.468894E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
From my experience talking with = customers in the=20 field, the main reason that people are not serving up UTF-8 pages is not = the=20 bandwidth, it is the fact that there are still some browsers out in the = field=20 that do not yet handle it correctly. While they are dying off fairly = quickly, it=20 is not quite at the point where people are willing to write them=20 off.
 
As far as size goes, it is worthwhile = looking at=20 some data samples. The following are from a page on the Unicode site = that is=20 translated into different languages, so it has essentially the same = information=20 on each page.
 
Size Page
8882 s-chinese.html
8946 t-chinese.html
9347 esperanto.html
9498 maltese.html
9739 icelandic.html
9833 czech.html
9944 welsh.html
10064 danish.html
10109 swedish.html
10127 polish.html
Size Page
10219 interlingua.html
10221 italian.html
10297 spanish.html
10308 portuguese.html
10312 lithuanian.html
10329 german.html
10376 romanian.html
10401 korean.html
10506 french.html

 
Size Page
10726 japanese.html
10953 hebrew.html
11192 arabic.html
13292 greek.html
13870 russian.html
13892 persian.html
14549 hindi.html
15337 georgian.html
15853 deseret.html

 

So the best case is about 50% of the worst case. Some of this is due = to the=20 encoding, and some is due to different languages just using different = numbers of=20 characters. However, when you look at web pages in general use, the = amount of=20 text (in bytes) is really swamped by graphics, Javascript, HTML code, = and so on.=20 So fundamentally, even the variations above are not that important in=20 practice.

BTW This is getting way off=20 topic.
 
Mark
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
 
=CE=93=CE=BD=E1=BF=B6=CE=B8=CE=B9 = =CF=83=CE=B1=CF=85=CF=84=CF=8C=CE=BD =E2=80=94 = =CE=98=CE=B1=CE=BB=E1=BF=86=CF=82
[For transliteration, see=20 http://oss.software.ibm.com/cgi-bin/icu/tr]
 
----- Original Message -----
From: "Soobok Lee" <lsb@postel.co.kr>
To: "Mark Davis" <mark@macchiato.com>; = "IETF idn=20 working group" <idn@ops.ietf.org>
Sent: Friday, March 22, 2002 = 08:16
Subject: Re: [idn] URL encoding in html = page

>
> ----- Original Message -----
> From: "Mark = Davis"=20 <mark@macchiato.com>
> To:=20 "Soobok Lee" <lsb@postel.co.kr>; = "IETF idn=20 working group" <idn@ops.ietf.org>
> Sent:=20 Saturday, March 23, 2002 12:18 AM
> Subject: Re: [idn] URL = encoding in=20 html page
>
>
> > Compliant browsers already have = to=20 handle Unicode, since NCRs (e.g.
> > &#x1234; ) are always = Unicode=20 code points. All XML parsers also have
> > to handle Unicode = (UTF-8 and=20 UTF-16).
>
> Right, Already.
> MS IE and = NEtscape =20 already have been supporting  UNICODE
> from serveral year = ago, but=20 still most homepages are in legacy encodings.
> MS WORD (already = unicode=20 based) have features to produce  (from
> unicode-based .doc=20 files)   legacy encoded .html files  for web = publishing
>=20
> Korean/Japanese/Chinese texts in UTF8 are 50% bigger than = legacy=20 ones.
> 50% more disk space and bandwidth  will be = required.
>=20 Each Cyrillic alhpabet in legacy code occupy one octet, while in = UTF8,
>=20 it requires 3 octets. 200% more space is needed.
> I cannot = imagine the=20 entire Russians make transition to UTF8.
> Legacy encnodings are = more=20 space efficient than UNICODE.
>
> legacy-to-legacy = conversions like=20 BIG5->KSX1001 are really being implemented
> as two steps of=20 BIG5->UNICODE  and UNICODE->KSX1001. UNICODE
> are = actively=20 used  as such intermediate encodings, but still not  be  = used and=20 entered
> directly by  end users so actively. Rather, = UNICODE =20 may be a hub to facilitate  interchange
> of informations in=20 different legacy encodings or  font sharing for differently = legacy-encoded=20 chars.
>
> I  regard UNICODE as a substrate (not as a=20 competitor) upon which legacy encodings are built.
>
> = >
>=20 > > Legacy encodings
> > > will dominates even in the = future,=20 because it is compact and
> > > inexpensive.
> = >
>=20 > While I do expect the transition to Unicode to take some time, = once
>=20 > some of the older browsers die off it may shift more rapidly than=20 we
> > think.
>
> I am not UNICODE expert nor = character=20 expert. But, everyday, i  feel
> the strong inertia toward = legacy=20 encodings in our local language communties.
> = language-tagging-enabled=20 text format like HTML will lengthen the lifespan
> of legacy = encodings by=20 great amounts  and allow legacy-coded HTML texts
> are=20 internationally interchanged without problems.
>
> Soobok=20 Lee
>
> >
> > Mark
> > = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
>=20 >
> > =CE=93=CE=BD=E1=BF=B6=CE=B8=CE=B9 = =CF=83=CE=B1=CF=85=CF=84=CF=8C=CE=BD =E2=80=94 = =CE=98=CE=B1=CE=BB=E1=BF=86=CF=82
> > [For transliteration, see = http://oss.software.ibm.com/cgi-bin/icu/tr]
> >
> > http://www.macchiato.com
>=20 >
> > ----- Original Message -----
> > From: = "Soobok Lee"=20 <lsb@postel.co.kr>
> > To:=20 "IETF idn working group" <idn@ops.ietf.org>
> > Sent: Friday, March 22, 2002 02:04
> = >=20 Subject: Re: [idn] URL encoding in html page
> >
> = >
>=20 > >
> > > ----- Original Message -----
> > = > From:=20 "Bruce Thomson" <bthomson@fm-net.ne.jp>
> > > To: "Soobok Lee" <lsb@postel.co.kr>; = "IETF idn=20 working group"
> > <idn@ops.ietf.org>
> > > Sent: Friday, March 22, 2002 6:29 = PM
> >=20 > Subject: Re: [idn] URL encoding in html page
> > = >
> >=20 >
> > > > > What if all the html viewable text is = in=20 english, but, only the
> > href url contains
> > > = >=20 > legacy (korean) encoded hostnames?  chinese visitors would = see
>=20 > clean english homepage,
> > > > > but fail to = click=20 through the korean link.
> > > > >
> > > = >=20 Well, that could happen, but a META tag would solve that so
> > = easily.=20 Personally
> > > > I often use a simple text editor to = deal with=20 HTML, and would find
> > it easier to
> > > > = use legacy=20 encodings or UTF-8 than cut-and-paste ACE from
> > = somewhere.
>=20 > > > Of course the user could do it either way and it would=20 work.
> > >
> > > Yes. Charset META tags help. = But, many=20 homepages  have assumptions
> > on the main = audience's
>=20 > > default char encodings and very often omit the  META tag = for=20 the
> > encoding like :
> > >   <meta=20 http-equiv=3D"Content-Type" content=3D"text/html;
> >=20 charset=3Deuc-kr">
> > >
> > > Moreover, IDN = url would=20 be used in a pure FRAMESET document that
> > defines frame = URLs
>=20 > > and contains no viewable texts. Such FRAMESET documents often=20 omit
> > charset META tags.
> > >  (look into = the html=20 source of http://www.freeway.co.kr/ )
>=20 > >
> > > AFIAK, 99.99999% of korean homepages have=20 implicit/explicit
> > > legacy korean encoding = (KS_C_5601-1987 or=20 euc-kr). So do most
> > japanese/chineses homepages.
> = > >=20 UTF8/UCS-2 encodings are rarely used in global WEB publishing.
> = >=20 Legacy encodings
> > > will dominates even in the future, = because it=20 is compact and
> > inexpensive.
> > >
> > = > IF=20 we want to make IDN truly internationally interoperable, all
> = >=20 IDN-aware webbrowsers/applications
> > > should contain = libaries of=20 all kinds of legacy-to-Unicode conversion
> > routines. It will = burden
> > > too much memory load on handheld devices like=20 PDA.
> > >
> > > Moreover, legacy encodings are = revised=20 separately from unicode. We
> > may face with as = toughest
> >=20 > versioning problems as we did in stringprep/nameprep = versioning
>=20 > problems for newly added unicode points.
> > > How to=20 guarantee  stability and intergrity of IDN operations in = the
> >=20 all combinations of  numerous kinds and versions of = iDN-aware
> >=20 > applications and legacy encodings?
> > >
> > = >=20 Soobok Lee
> > >
> > >
> > >
> =
>
> ------=_NextPart_000_017C_01C1D18B.468894E0-- From owner-idn@ops.ietf.org Fri Mar 22 13:57:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28799 for ; Fri, 22 Mar 2002 13:57:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oU5w-000Ba8-00 for idn-data@psg.com; Fri, 22 Mar 2002 10:48:56 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16oU5v-000Ba2-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 10:48:55 -0800 Message-ID: <005501c1d1d2$843f1ab0$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: , Subject: Fw: [idn] URL encoding in html page Date: Fri, 22 Mar 2002 13:51:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Any one of you that are interested in seeing how URL links on page working can goto http://www.neteka.com/MLTest/ If the page is set to the proper charset, there should be no problem clicking the link. If you are saying that some user may set the improper charset so that the links won't work, that is total non-sense because if the user cannot view what is on the page or cannot UNDERSTAND what is on the page(the chinese viewing a Korean page sample), then why is that user ending up looking at that webpage... If UTF8 or 8 bit DNS are implemented properly... links should not be a problem, and there is no need to change the browser behaviour so that it will hide ACE and show IDN on the UI, what happen if someone really wants to put something looks like an ACE on their page then we need another escape sequence for that?? David Leung Chief Technology Officer Neteka Inc. T: (416) 971-4302 http://w!.neteka.com > ----- Original Message ----- > From: "Soobok Lee" > To: "IETF idn working group" > Sent: Friday, March 22, 2002 5:04 AM > Subject: Re: [idn] URL encoding in html page > > > > > > ----- Original Message ----- > > From: "Bruce Thomson" > > To: "Soobok Lee" ; "IETF idn working group" > > > Sent: Friday, March 22, 2002 6:29 PM > > Subject: Re: [idn] URL encoding in html page > > > > > > > > What if all the html viewable text is in english, but, only the href > url contains > > > > legacy (korean) encoded hostnames? chinese visitors would see clean > english homepage, > > > > but fail to click through the korean link. > > > > > > > Well, that could happen, but a META tag would solve that so easily. > Personally > > > I often use a simple text editor to deal with HTML, and would find it > easier to > > > use legacy encodings or UTF-8 than cut-and-paste ACE from somewhere. > > > Of course the user could do it either way and it would work. > > > > Yes. Charset META tags help. But, many homepages have assumptions on the > main audience's > > default char encodings and very often omit the META tag for the encoding > like : > > > > > > Moreover, IDN url would be used in a pure FRAMESET document that defines > frame URLs > > and contains no viewable texts. Such FRAMESET documents often omit charset > META tags. > > (look into the html source of http://www.freeway.co.kr/ ) > > > > AFIAK, 99.99999% of korean homepages have implicit/explicit > > legacy korean encoding (KS_C_5601-1987 or euc-kr). So do most > japanese/chineses homepages. > > UTF8/UCS-2 encodings are rarely used in global WEB publishing. Legacy > encodings > > will dominates even in the future, because it is compact and inexpensive. > > > > IF we want to make IDN truly internationally interoperable, all IDN-aware > webbrowsers/applications > > should contain libaries of all kinds of legacy-to-Unicode conversion > routines. It will burden > > too much memory load on handheld devices like PDA. > > > > Moreover, legacy encodings are revised separately from unicode. We may > face with as toughest > > versioning problems as we did in stringprep/nameprep versioning problems > for newly added unicode points. > > How to guarantee stability and intergrity of IDN operations in the all > combinations of numerous kinds and versions of iDN-aware > > applications and legacy encodings? > > > > Soobok Lee > > > > > > > From owner-idn@ops.ietf.org Fri Mar 22 14:19:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29208 for ; Fri, 22 Mar 2002 14:19:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oUSm-000DTv-00 for idn-data@psg.com; Fri, 22 Mar 2002 11:12:32 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16oUSl-000DTo-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 11:12:31 -0800 Received: from [68.52.224.13] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 31907; Fri, 22 Mar 2002 13:12:10 -0600 Message-ID: <3C9B821C.D9AFCE5D@ehsco.com> Date: Fri, 22 Mar 2002 13:12:29 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Keith Moore CC: Valdis.Kletnieks@VT.EDU, idn@ops.ietf.org, ietf@ietf.org, iab@isi.edu Subject: [idn] Re: 7 bits forever! References: <200203221808.g2MI8nt01544@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > if you can somehow solve the PKI problem, you can make SMTP immune to > forgeries and have it provide end-to-end integrity. so far, nobody > has managed to do this. I am of the opinion that a new messaging framework -- including the protocol and the data-format -- is going to be pretty much required for all of the interrelated problems to be solved. Once the mental committment to a new design model is made, most of the problems can be redefined as solvable. In this regard, many of the current problems are due to the current model. So change the model. > if you can somehow figure out a way for anybody to type in a mailbox > in any language on any keyboard, you can solve the i18n mailbox problem. Certainly backwards-compatible access methods should be defined for the mailbox names, just as they are necessary for the domain name. > until then, there's very marginal value in replacing SMTP. even then, > it would probably be easier to upgrade SMTP than to replace it. I think that depends on the approach. If we are only allowed to think of ways to extend the current model into new territory while preserving 100% backwards compatibility, we can abort right now. If instead we try to build a new mail system that provides backwards compatibility ONLY when communicating with a legacy system, it is much more feasible. For example, let's say that a new message-transfer service is defined that uses a new message structure, so that the e2e issues can really be dealt with properly. In the new environement, perhaps the protocol only exchanges multipart/container entities, and these have subordinate parts of message/trace, message/headers and message/body, while ~From and ~To and other 822-like headers are stored in the message/headers entity. Mapping this to a legacy system is straightforward in principle: if the new transport is not available on the destination, have the agent combine portions of the message/headers entity with portions of the message/trace entity, perform whatever conversions are needed, and then send the message/body part over SMTP (possibly performing additional conversions such as line-folding or base64). So, yes, we still have to coexist with legacy systems, but 100% compatiblity at all times is no longer the root design objective. By redefining the design criteria, we are liberated from the design constraints that are imposed by SMTP. [I know there are plenty of flaws in the above. This is not a proposal, but rather an argument to redefine the design criteria.] -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri Mar 22 14:50:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00087 for ; Fri, 22 Mar 2002 14:50:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oUsN-000FXf-00 for idn-data@psg.com; Fri, 22 Mar 2002 11:38:59 -0800 Received: from foo-bar-baz.cc.vt.edu ([128.173.14.103]) by psg.com with esmtp (Exim 3.35 #1) id 16oUsM-000FXT-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 11:38:58 -0800 Received: from foo-bar-baz.cc.vt.edu (valdis@localhost [127.0.0.1]) by foo-bar-baz.cc.vt.edu (8.12.2/8.12.2) with ESMTP id g2MJcDm8002590; Fri, 22 Mar 2002 14:38:13 -0500 Message-Id: <200203221938.g2MJcDm8002590@foo-bar-baz.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: "David Leung (Neteka Inc.)" Cc: ietf@ietf.org, idn@ops.ietf.org Subject: Re: Fw: [idn] URL encoding in html page In-Reply-To: Your message of "Fri, 22 Mar 2002 13:51:02 EST." <005501c1d1d2$843f1ab0$0301a8c0@davidvaio> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1153343128P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 22 Mar 2002 14:38:13 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --==_Exmh_1153343128P Content-Type: text/plain; charset=us-ascii On Fri, 22 Mar 2002 13:51:02 EST, "David Leung (Neteka Inc.)" said: > If the page is set to the proper charset, there should be no problem > clicking the link. If you are saying that some user may set the improper > charset so that the links won't work, that is total non-sense because if the > user cannot view what is on the page or cannot UNDERSTAND what is on the > page(the chinese viewing a Korean page sample), then why is that user ending > up looking at that webpage... 1) There have been many times when I've been searching for something, and found what I needed on a page that had *SOME* English and *SOME* Korean. Just because there may be some characters on the page that I can't decode does not mean the page is totally useless to me. Your mail showed up tagged as ks_c_5601-1987 - if you had put some Korean characters in your signature, they may or may not have rendered correctly. But I still understood your message enough to see the link to 'w!.neteka.com'. 2) Babelfish. Can of worms there. Enough said. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1153343128P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8m4glcC3lWbTT17ARAhbHAKD+M2foqVF7TZTSKLZyO2vr8+O1hwCg3iE4 yT7bNEEooRzOqI6AaOC7Cm4= =1jnx -----END PGP SIGNATURE----- --==_Exmh_1153343128P-- From owner-idn@ops.ietf.org Fri Mar 22 14:55:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00148 for ; Fri, 22 Mar 2002 14:55:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oUuu-000Fjv-00 for idn-data@psg.com; Fri, 22 Mar 2002 11:41:36 -0800 Received: from hermes.xerox.com ([212.137.33.205] helo=hermes.eurgw.xerox.com) by psg.com with esmtp (Exim 3.35 #1) id 16oUut-000Fjk-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 11:41:35 -0800 Received: from eurodns4.eur.xerox.com (eurodns4.eur.xerox.com [13.202.66.50]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id TAA03141 for ; Fri, 22 Mar 2002 19:41:32 GMT Received: from eurdubmg02.eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurodns4.eur.xerox.com (8.10.2/8.10.2) with ESMTP id g2MJfAZ12725 for ; Fri, 22 Mar 2002 19:41:11 GMT Received: from apollo.eurgw.xerox.com (unverified) by eurdubmg01.eur.xerox.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 21 Mar 2002 16:53:36 +0000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by apollo.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id QAA19674 for ; Thu, 21 Mar 2002 16:53:35 GMT Received: by ietf.org (8.9.1a/8.9.1a) id LAA16247 for ietf-outbound.06@ietf.org; Thu, 21 Mar 2002 11:40:02 -0500 (EST) Received: by ietf.org (8.9.1a/8.9.1a) id LAA15365 for ietf-mainout; Thu, 21 Mar 2002 11:17:30 -0500 (EST) X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15354 for ; Thu, 21 Mar 2002 11:17:24 -0500 (EST) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35044623D1; Thu, 21 Mar 2002 17:16:55 +0100 (CET) Date: Thu, 21 Mar 2002 09:51:56 -0600 From: Harald Tveit Alvestrand To: Masataka Ohta , Mark Davis Cc: idn@ops.ietf.org, ietf@ietf.org Subject: Re: [idn] Re: I don't want to be facing 8-bit bugs in 2013 Message-ID: <85471431.1016704316@localhost> In-Reply-To: <200203210748.QAA06034@necom830.hpcl.titech.ac.jp> References: <200203210748.QAA06034@necom830.hpcl.titech.ac.jp> X-Mailer: Mulberry/2.2.0b2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 21. mars 2002 16:47 +0859 Masataka Ohta wrote: > However, as Harald and I agreed, such products need local > context information OOB to work properly. apologies for indicating too strong an agreement.... we agree that for many functions that users would like software to perform (sorting being an obvious example), context information is needed to work properly. > > Then, the problem is that some local contexts are mutually exclusive. > > There is no instance of Unicode-based-local-character-set > internationally useful. I assert that for many functions (such as non-high-quality text display) in many locales, having information in Unicode-based character sets are useful without OOB information. Thus, Unicode is internationally useful - but we are deluding ourselves if we claim that it solves ALL problems. > > Some product using unicode may be usable in multiple local context, > if the context information is given OOB, and the product is valuable > in international market. > > However, unicode, still, is not usable in international context unless > OOB information, which, thanks to poor charset reviewing, essentaily is > yet another charset designaiton, is attached. We disagree on this point. I assert that the fact that charset does not give the required information is by DESIGN of the charset mechanism, not by "poor review". As a citizen of a continent where > 10 nations use the same character set (ISO 8859-1), but where locale requirements vary across the continent, I believe that separation of those concerns was a correct engineering decision. Just to make it clearer where Ohta and I agree, and where we disagree..... Harald From owner-idn@ops.ietf.org Fri Mar 22 15:05:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00486 for ; Fri, 22 Mar 2002 15:05:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oV75-000Glu-00 for idn-data@psg.com; Fri, 22 Mar 2002 11:54:11 -0800 Received: from postman.incentivesystems.com ([66.152.247.37]) by psg.com with esmtp (Exim 3.35 #1) id 16oV74-000Gln-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 11:54:10 -0800 To: idn@ops.ietf.org, ietf@ietf.org Subject: Re: Fw: [idn] URL encoding in html page MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 22 Mar 2002 15:04:11 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/22/2002 03:04:22 PM, Serialize complete at 03/22/2002 03:04:22 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk >If you are saying that some user may set the improper >charset so that the links won't work, that is total non-sense because if the >user cannot view what is on the page or cannot UNDERSTAND what is on the >page(the chinese viewing a Korean page sample), then why is that user ending >up looking at that webpage... Robots. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Brought to you by the letter Q. | \========================================================/ From owner-idn@ops.ietf.org Fri Mar 22 15:12:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00600 for ; Fri, 22 Mar 2002 15:12:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oVDK-000HHi-00 for idn-data@psg.com; Fri, 22 Mar 2002 12:00:38 -0800 Received: from hermes.xerox.com ([212.137.33.205] helo=hermes.eurgw.xerox.com) by psg.com with esmtp (Exim 3.35 #1) id 16oVDJ-000HHT-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 12:00:37 -0800 Received: from eurodns4.eur.xerox.com (eurodns4.eur.xerox.com [13.202.66.50]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id UAA08711 for ; Fri, 22 Mar 2002 20:00:35 GMT Received: from eurdubmg02.eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurodns4.eur.xerox.com (8.10.2/8.10.2) with ESMTP id g2MK0RZ20018 for ; Fri, 22 Mar 2002 20:00:29 GMT Received: from hermes.eurgw.xerox.com (unverified) by eurdubmg01.eur.xerox.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 21 Mar 2002 19:23:39 +0000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id TAA10077 for ; Thu, 21 Mar 2002 19:23:38 GMT Received: by ietf.org (8.9.1a/8.9.1a) id OAA21778 for ietf-outbound.06@ietf.org; Thu, 21 Mar 2002 14:10:01 -0500 (EST) Received: by ietf.org (8.9.1a/8.9.1a) id NAA20703 for ietf-mainout; Thu, 21 Mar 2002 13:24:57 -0500 (EST) X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f Received: from www.wordnic.com (unknown-raq-customer.dca1.superb.net [207.228.240.63] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13332; Thu, 21 Mar 2002 10:17:28 -0500 (EST) Received: from [64.109.213.3] (adsl-64-108-77-182.dsl.lgnnmi.ameritech.net [64.108.77.182]) by www.wordnic.com (8.9.3/8.9.3) with ESMTP id JAA28187; Thu, 21 Mar 2002 09:17:25 -0600 Mime-Version: 1.0 X-Sender: tedd1@sperling.com Message-Id: In-Reply-To: References: Date: Thu, 21 Mar 2002 10:17:26 -0500 To: ietf@ietf.org, iesg@ietf.org, iab@ISI.EDU, idn@ops.ietf.org From: tedd Subject: Re: [idn] WG last call summary Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA13333 Content-Transfer-Encoding: 8bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit >On Mar 19, "D. J. Bernstein" wrote: > >> Go sell a Greek user an ``internationalized domain name'' with a delta, >> Pete. Then tell him that most of his correspondents will see the delta >> as incomprehensible gobbledygook rather than a delta. See what he says. Okay, I'm not Greek, but as the registered owner of .com, I'll tell you*. I expect that some windoze users will display it (.com) as a box dot com; mac users will display it as a delta dot com; and everyone else will display it as a bq--eida.com (RACE), or dq--uuyg.com (DUDE), or zq---h9g.com (AMZ_C), or punycode, or whatever -- AND, they will continue to do so until they have the appropriate software on their machines to handle the conversion. That's what I expect. On the other hand, I do not expect that the IDN will eventually produce something that will transparently produce the appropriate glyphs on millions of users machines. In my mind, that's simply not possible because I think it requires that every machine on this planet have a complete copy of UNICODE installed and available. Granted, I am clueless about a lot of this IDN stuff and I may be "hubris" (as Mr. Paul Hoffman once informed me) in my offering my opinion to the "Gods of the Internet", but I do think I see the distinction between which side of the modem one is on and what responsibility lies in each camp. >OK, scenario 1: > >You tell him that although it's gobbledygook to people without greek >alphabet support, it will still work. It's not convenient, but it WILL work. >Guaranteed. For his business colleagues and friends in Greece, who DO have >the latest and greatest software, it will display as a delta. His ISP hasn't >had to upgrade, and everybody in the world can use his domain - eventually >they will see it as a delta as well, but for now they see it as an encoded >string they can still use no problem. ><-snip> >If you were IT director of a large firm, and you had a choice as to which to >roll out, which would you choose? > >-- >Paul Robinson I would vote for scenario 1. Besides, IMHO (in my hubris opinion) that's the only way it's going to work. tedd * The Greek version of "delta" registers a internal error -- it's the Math language set that provides an acceptable "delta". -- http://sperling.com From owner-idn@ops.ietf.org Fri Mar 22 15:15:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00644 for ; Fri, 22 Mar 2002 15:15:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oVHG-000HcN-00 for idn-data@psg.com; Fri, 22 Mar 2002 12:04:42 -0800 Received: from hermes.xerox.com ([212.137.33.205] helo=hermes.eurgw.xerox.com) by psg.com with esmtp (Exim 3.35 #1) id 16oVHF-000Hc9-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 12:04:42 -0800 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id UAA09155 for ; Fri, 22 Mar 2002 20:04:38 GMT Received: from eurdubmg02.eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurodns2.eur.xerox.com (8.10.2/8.10.2) with ESMTP id g2MK4DD20330 for ; Fri, 22 Mar 2002 20:04:18 GMT Received: from hermes.eurgw.xerox.com (unverified) by eurdubmg01.eur.xerox.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 21 Mar 2002 19:33:36 +0000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id TAA10576 for ; Thu, 21 Mar 2002 19:33:33 GMT Received: by ietf.org (8.9.1a/8.9.1a) id OAA22183 for ietf-outbound.06@ietf.org; Thu, 21 Mar 2002 14:20:02 -0500 (EST) Received: by ietf.org (8.9.1a/8.9.1a) id NAA20722 for ietf-mainout; Thu, 21 Mar 2002 13:25:33 -0500 (EST) X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f Received: from neteka.com ([66.48.4.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16134 for ; Thu, 21 Mar 2002 11:38:03 -0500 (EST) Message-ID: <02a501c1d0f7$192c07a0$ec333a41@EDMON15> From: "Edmon Chung" To: "Meritt James" , "Dave Crocker" Cc: , References: <5.1.0.14.2.20020320210727.026ab590@127.0.0.1> <3C99E960.6E090465@bah.com> Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever Date: Thu, 21 Mar 2002 11:40:22 -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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Meritt James" > Ah, but was there an implementable ANSWER? THAT is the question! > Here is a simple architecture/roadmap possibility: 1. IDNA user-end plugin - this plugin does all the heavy lifting to encode and decode ACE and display it properly for the user - servers does not upgrade. Even administration side is kept as is, allowing leakage for administrators - IDNA plugins must also be able to decode IDN(UTF8)/EDNS [This I will call UDNA for this discussion] 2. UDNA DNS Server upgrade - DNS servers will now accept both ACE and IDN(UTF8)/EDNS requests and provide consistent responses - IDNA plugins continue to send in ACE but will start to see UDNA responses 3. UDNA for clients & everywhere - IDNA plugins begin to obsolete, new versions of application software comes with UDNA built in. - In case DNS servers are not upgraded yet, clients will continue to use the IDNA plugin which will work fine with the new UDNA application. - Other applications/servers upgrade to UDNA to accept UTF8 domains, administrators might continue to see ACE leakage if the client still uses IDNA to send requests, but UDNA requests will be viewable and manageable in UTF8 4. UDNA - Slowly but certainly, we will move towards full UTF8 because administrators will likely want to deal with UTF8 than ACE, especially for say those admins in China who are dealing with IDNs frequently. You should be able to find holes in it, but it is whether the general concept is workable that is important. If so, THEN, we can work on refining the concept and putting it into a draft. And one of the key things is that UDNA MUST be included in an IDNA plugin to start with for the entire system to be able to move out of ACE and into UTF8 completely eventually. That is why we cannot and should not leave it out for now. Thoughts everyone? Edmon ----- Original Message ----- > Dave Crocker wrote: > > > > At 09:52 PM 3/20/2002 -0500, Edmon Chung wrote: > > >An underlying question we must ask ourselves from all the discussions that > > >have sprung up every now and then is: > > > > and as luck would have it, the working group has asked itself that question > > many times, so we need not pursue it again. > > > > d/ > > > > ---------- > > Dave Crocker > > TribalWise, Inc. > > tel +1.408.246.8253; fax +1.408.850.1850 > > -- > James W. Meritt CISSP, CISA > Booz | Allen | Hamilton > phone: (410) 684-6566 > From owner-idn@ops.ietf.org Fri Mar 22 15:32:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01123 for ; Fri, 22 Mar 2002 15:32:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oVXF-000Ity-00 for idn-data@psg.com; Fri, 22 Mar 2002 12:21:13 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16oVXE-000Itr-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 12:21:13 -0800 Message-ID: <008e01c1d1df$64f38e40$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Eric A. Hall" , Cc: , , References: <020901c1d083$74b55aa0$ec333a41@EDMON15> <200203212232.g2LMW6t17451@astro.cs.utk.edu> <20020322003037.31068.qmail@cr.yp.to> <200203221444.g2MEibm8030349@foo-bar-baz.cc.vt.edu> <3C9B5B20.1E672650@ehsco.com> Subject: Re: [idn] Re: 7 bits forever! Date: Fri, 22 Mar 2002 15:23: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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Why is this important? Well.. think about this message. I may have > > an 8-bit-clean mailer. You may have one. But neither of us has the > > authority to make sure that the software at ietf.org is able to deal. > > WRT to your comments in particular, I agree that SMTP has the most > difficulties. However, as stated, if something cannot be extended it can > still be replaced. And in the meantime, IDNA should be there as a fallback > position for these kinds of protocols. > > I mean, considering all of the problems that SMTP has -- sender forgeries, > relay forgeries, lack of end-to-end integrity, and of course a lack of > support for i18n email addresses -- it seems likely to be a candidate for > replacement for other reasons anyway. That doesn't mean that the IDN tail > should wag SMTP, but if SMTP cannot be upgraded, well, add that to the > list of other things that SMTP doesn't do very well. In this regard, the > IDN issue is just one of many that need to be considered (i18n mailbox > names being another). > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > I agree that IDNA should be there as transition to protocol like SMTP, however if IDN is going to be used on other protocols like SMTP, etc... these protocol has to be changed according to the long-term strategy for IDN, so we should look at IDN as the root for all the other problems and solve it first, in terms of using ACE or UTF8 for long-term, then we can have a clear picture of how to upgrade the other protocols, eg: for SMTP we can add extra ESMTP syntax that can handles both i18n mailboxs as ACE or UTF8. David Leung Chief Technology Officer Neteka Inc. T: (416) 971-4302 http://w!.neteka.com From owner-idn@ops.ietf.org Fri Mar 22 15:39:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01224 for ; Fri, 22 Mar 2002 15:39:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oVew-000Jcb-00 for idn-data@psg.com; Fri, 22 Mar 2002 12:29:10 -0800 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.35 #1) id 16oVev-000JcT-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 12:29:09 -0800 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH2VCdP/qtkd4iRSzuW5byT8M98zOzQqLZA=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id GWJJK3XB; Fri, 22 Mar 2002 15:26:51 EST To: apb@cequrux.com Cc: idn@ops.ietf.org Date: Fri, 22 Mar 2002 12:42:09 -0800 Subject: Re: [idn] Re: Unicode is not usable in international context. Message-ID: <20020322.124209.-286659.1.liana.ydisg@juno.com> X-Mailer: Juno 4.0.5 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-79,81-122 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > People have posted cases where the number of TC characters that make > up a word is different from the number of SC characters that make up > the same word. People have also posted cases where the number of > characters remains the same but the mapping depends on context. You are talking about combinations of glyphs, we call them words or Labels in IDN context. A label may contain only one character sometimes, and it is easier for us to discuss without have to show the glyphs on our screen here on this list. This may be the reason for the above confusion. Let me try to elaborate a little on Chinese character processing, I mean one glyph at a time as in Unicode table. There are 20,000+ often used symbols worldwide as they are collected in Plane 0 of UCS. Mainland China use about 7,000 reguarly, Taiwan uses 13,000 reguarly. We call these are frequently used characters. Among these frequently used characters, there are always semantic differences among any two given characters, due to history and locality of the usage, as you can image. This posts the necessity of organization works in characters and thus dictionary editing, or standard works through out Chinese writen language histroy. Especially when computer comes along. The first classification is certainly those semanticly distinct and writen form distinct characters. Many semanticly distinct but form similar characters are in the carefully explained category in education sector as well as in written language critics, which can be analogies to Latin spelling checking as an educational activity, but not as an equivalent symbol set concern which is discussed here on this list. This is certainly a spelling checking feature as input concerns. The second classification are those semanticly overlap but not the same. We translated the category for these character as synonymies or "same meaning characters". But they are not thesaurus, thesaurus are introduced into China in recent years only. These are not the subject for any unification or mix. The correct usage in a text has to be differenciated within context, thus word dictionaries are used to help, this is an AI feature in an Editor software. The third classificantion of characters are semanticly "identical" but has many different forms, especially through the long history of keeping these characters. The majority of characters in UCS beyong the above 20,000 frequently used characters are belong to this category. And the majority of TC/SC also belong to this category. As I have said, if you want to find the details of something different you will always be successful among these characters. This third classification is what we are concerning in preference of display and possible inclusion of more character forms beyong the frenquently used character set or exclusion of them from such an equivalent set, which has addressed by Japanese users. Notice, that I said the majority of TC/SC belongs to this category. This is what you have heard some user do not agree with this "identical" classification. This is the matter of life that the Han user community has to be precise about which symbol in which set. So that they can have a standard to work from. Excluding this equivalent set from the basic [nameprep] profile is definitly marking the failure of IDN and causes more "trademark" conflicts on the way. > People have stated that conversion between TC and SC requires a > dictionary of words, rather than a table of characters. All these > show that TC/SC is analogous to a spelling difference. Correct. This is to deal with the small number (on the scale of 10 vs. 2000) of TC/SC in input and display level, which should not over take the face that TC/SC has to be equivalent identifiers in [nameprep]. As the matter of using characters as identifiers in IDN, the job we have to be concerned is to reduce these semantic "identical" characters from whatever number down to a "no trademark confilct" level of clearance to be viable symbol set which we can permit in IDN for identifier matching. In this sense, it is like case-insensitive treatment of Latin symbols. Yes, we do want uppercase too, but on identifier level, they are the same! > I don't clain that TC/SC conversion or equivalence is not a problem. I hope that the above explaination has shown a feasible solution to this problem to your satisfaction. > Neither do I claim that the potential confusion between CAPITAL LETTER ALPHA> and is > not a problem. This is a problem of IDN. This problem is opposite with TC/SC equivalence. Because of these symbols are picked up/ pasted/ typed from a mixture of applications and user interfaces, anyone of them can be the bad guy hidden from someone's eye, and the machines only know about bits. If you add more forms of encoding, such as UTF8/16 or input keystroke sequences, then the problem can escalate quickly. The solutions that I can think of at this moment would be two: 1. Unification of symbols like CJK unification with equivalent symbol set defined; 2. Transparent language tag to enforce each label to be consistent with its tag through out the system include DNS. If we work out CJK in IDN problem, then this will be a piece of cake at the end of our IDN banquet :-) > Neither > do I claim that the potential confusion between English "theatre" > and American "theater" or English "lift" and American "elevator" > are not problems. But I believe that all these problems are > outside the scope of IDN. Correct, this problem is outside the scope of IDN. Regards, Liana Ye From owner-idn@ops.ietf.org Fri Mar 22 15:56:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01564 for ; Fri, 22 Mar 2002 15:56:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oVtR-000Kn2-00 for idn-data@psg.com; Fri, 22 Mar 2002 12:44:09 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16oVtR-000Kmt-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 12:44:09 -0800 Message-ID: <009d01c1d1e2$9415b830$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "D. J. Bernstein" , Cc: , , References: <020901c1d083$74b55aa0$ec333a41@EDMON15> <200203212232.g2LMW6t17451@astro.cs.utk.edu> <20020322003037.31068.qmail@cr.yp.to> <200203221444.g2MEibm8030349@foo-bar-baz.cc.vt.edu> <20020322172024.19557.qmail@cr.yp.to> Subject: Re: [idn] Re: 7 bits forever! Date: Fri, 22 Mar 2002 15:46:00 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Valdis.Kletnieks@vt.edu writes: > > you could *NOT* trust that all the systems > > between here and there were 8-bit-clean > > there were a *LARGE* number of systems that broke badly if they > > were handed 8 bit data. > > Let's look at the facts. John Klensin claimed in an ietf-smtp message > dated 26 Feb 91 08:40:04-EST that there were mail servers ``not robust > against that particular form of misbehavior.'' Robert Ullmann publicly > asked for proof of this claim. Klensin dodged the question. > > Similarly, Keith Moore claimed in a comp.mail.mime message, message ID > 199710102108.RAA13469@spot.cs.utk.edu, that ``core-dumping was a > commonly observed failure mode in the early 1990s.'' I publicly asked > for proof of this claim. Moore dodged the question. > > Mail servers discarding characters? Yes. Mail servers stripping the 8th > bit? Yes. Mail servers crashing? Not a single shred of evidence. > > Similarly, expanding from mail to all protocols: Rick Wesson claimed in > an IDN WG message dated Sun, 24 Dec 2000 16:44:39 -0800 that ``there is > a lot of embedded systems out there that would crash-and-burn if they > received a reply in utf8.'' I asked for proof: > > Can you please identify the systems, explain how they use domain > names, and say what exactly you mean by ``crash-and-burn''? We need > this information if we're going to accurately assess the cost of > upgrading the world to support IDNs. > > Naturally, Wesson dodged the question. > > I will readily agree that there has been an unverified report of a UTF-8 > crash of an obsolete version of the Netscape mailer under Solaris. If > that report is accurate then those users will have to upgrade. > > > BIND, which by default restricts it > [ ... ] > > Why does it get restricted? > [ bogus rationalization snipped ] > > The actual history, as I mentioned in another message, is as follows. > > People discovered several years ago that sendmail would blindly feed DNS > PTR results to the shell, so attackers could take over the computer by > putting some special characters, such as |<>, into PTR records. The BIND > people panicked and disabled all non-letter-digit-hyphen characters at > every spot they could think of in their DNS client library. > > This isn't an 8-bit issue; it does just as much damage to underscores. I totally agree on what DJ Bernstein said, I have been look for proofs everywhere to see how 8bit characters can "crash-and-burn" things, but wasnt sucessful in finding any proof. Core-dumping is the result of bad software design, and not from 8bit chars, if you claims that 8bit chars will crash certain software, why? because you haven't allocate enough memory for the variables that will be fed with 8bits, but I cannot find a variable type that represents 7bits and 8bits differently, char? short? maybe on some VERY VERY LEGACY system there maybe?! If attackers found ways of using 8bits to crash systems or gain control of systems, that is usual because hackers and attackers exploit security holes in softwares, and it should be considered as a security hole and not an IDN problem!! Moreover it should be the issues of FBI and the law enforcers and not the issues of using IDN as 8bit or not...;> > > Let's take as an example the "native language" encoding of my name: > > From: Valdis Kl=?iso8859-4?Q?=BA?=tnieks > > Wow. How do you pronounce that? ``Hi, I'm Valdis Klee-kwals-question- > mark-iso-eighty-eight-fifty-nine-dash-four-question-mark-kyoo-question- > mark-equals-bah-question-mark-equal-stun-ieks''? Have you considered > changing your name? > > In all seriousness: Wouldn't you like to see a world where the same > character encoding is used for the name and the address and the message > body and so on, so that simple copying doesn't screw up the display? 100% agree why can't we use 8bits with new ESMTP commands and MIME header that retains the names as is!! David Leung Chief Technology Officer Neteka Inc. T: (416) 971-4302 http://w!.neteka.com From owner-idn@ops.ietf.org Fri Mar 22 16:15:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01911 for ; Fri, 22 Mar 2002 16:15:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oWFr-000MXW-00 for idn-data@psg.com; Fri, 22 Mar 2002 13:07:19 -0800 Received: from foo-bar-baz.cc.vt.edu ([128.173.14.103]) by psg.com with esmtp (Exim 3.35 #1) id 16oWFq-000MXO-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 13:07:18 -0800 Received: from foo-bar-baz.cc.vt.edu (valdis@localhost [127.0.0.1]) by foo-bar-baz.cc.vt.edu (8.12.2/8.12.2) with ESMTP id g2ML6Pm8003631; Fri, 22 Mar 2002 16:06:25 -0500 Message-Id: <200203222106.g2ML6Pm8003631@foo-bar-baz.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: "David Leung (Neteka Inc.)" Cc: "Eric A. Hall" , Keith Moore , idn@ops.ietf.org, ietf@ietf.org, iab@isi.edu Subject: Re: [idn] Re: 7 bits forever! In-Reply-To: Your message of "Fri, 22 Mar 2002 16:03:15 EST." <00c701c1d1e4$fd580f80$0301a8c0@davidvaio> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <3C9B821C.D9AFCE5D@ehsco.com> <00c701c1d1e4$fd580f80$0301a8c0@davidvaio> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1160740408P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 22 Mar 2002 16:06:25 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --==_Exmh_1160740408P Content-Type: text/plain; charset=us-ascii On Fri, 22 Mar 2002 16:03:15 EST, "David Leung (Neteka Inc.)" said: > Why do we have to be able to type the mailbox in any language on any > keyboard? For myself, I have two email address one chinese and one english, > if I want to send email to the chinese I will use my chinese one that better > represents my name, and if I send email to english only people I will use > the english one... No one is required to initiate an email to a people using Which works well until you want to send a note to people in both groups, and somebody hits "reply all". -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1160740408P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8m5zRcC3lWbTT17ARAqkOAJ46PnQqe9pY014SOeUeysDy4Jb21ACggzyF sdG/HUqaOiP+RWeoYeVq1pA= =xKem -----END PGP SIGNATURE----- --==_Exmh_1160740408P-- From owner-idn@ops.ietf.org Fri Mar 22 16:17:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01940 for ; Fri, 22 Mar 2002 16:17:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oWA7-000MCC-00 for idn-data@psg.com; Fri, 22 Mar 2002 13:01:23 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16oWA6-000MC3-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 13:01:22 -0800 Message-ID: <00c701c1d1e4$fd580f80$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Eric A. Hall" , "Keith Moore" Cc: , , , References: <200203221808.g2MI8nt01544@astro.cs.utk.edu> <3C9B821C.D9AFCE5D@ehsco.com> Subject: Re: [idn] Re: 7 bits forever! Date: Fri, 22 Mar 2002 16:03:15 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > if you can somehow figure out a way for anybody to type in a mailbox > > in any language on any keyboard, you can solve the i18n mailbox problem. > > Certainly backwards-compatible access methods should be defined for the > mailbox names, just as they are necessary for the domain name. Why do we have to be able to type the mailbox in any language on any keyboard? For myself, I have two email address one chinese and one english, if I want to send email to the chinese I will use my chinese one that better represents my name, and if I send email to english only people I will use the english one... No one is required to initiate an email to a people using their i18n email address, just like if you don't speak Japanese why try to talk to the Japanese with Japanese?! i18n email address is only for people that their native language is not english to represents their name better in their own community!! Or else I think this IDN problem will eventually need everyone to go back to language schools to learn every language in teh world : > > > until then, there's very marginal value in replacing SMTP. even then, > > it would probably be easier to upgrade SMTP than to replace it. > > I think that depends on the approach. If we are only allowed to think of > ways to extend the current model into new territory while preserving 100% > backwards compatibility, we can abort right now. If instead we try to > build a new mail system that provides backwards compatibility ONLY when > communicating with a legacy system, it is much more feasible. > > For example, let's say that a new message-transfer service is defined that > uses a new message structure, so that the e2e issues can really be dealt > with properly. In the new environement, perhaps the protocol only > exchanges multipart/container entities, and these have subordinate parts > of message/trace, message/headers and message/body, while ~From and ~To > and other 822-like headers are stored in the message/headers entity. > > Mapping this to a legacy system is straightforward in principle: if the > new transport is not available on the destination, have the agent combine > portions of the message/headers entity with portions of the message/trace > entity, perform whatever conversions are needed, and then send the > message/body part over SMTP (possibly performing additional conversions > such as line-folding or base64). > > So, yes, we still have to coexist with legacy systems, but 100% > compatiblity at all times is no longer the root design objective. By > redefining the design criteria, we are liberated from the design > constraints that are imposed by SMTP. I totally agree on this too!! I think adding ESMTP commands and new MIME headers can 100% achieve this, by allow compliant new mail systems to be able to handle 8bits and for existing mail systems it will be able to fallback to ACE for transport(SMTP, etc) but still maintains the MIME header as displayable 8bits, this will serve both the future and backward compatibility. David Leung Chief Technology Officer Neteka Inc. T: (416) 971-4302 http://w!.neteka.com From owner-idn@ops.ietf.org Fri Mar 22 16:39:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02291 for ; Fri, 22 Mar 2002 16:39:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oWUV-000NkE-00 for idn-data@psg.com; Fri, 22 Mar 2002 13:22:27 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16oWUU-000Nk7-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 13:22:26 -0800 Message-ID: <012101c1d1e7$f4c92cc0$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: Cc: "Eric A. Hall" , "Keith Moore" , , , References: <200203221808.g2MI8nt01544@astro.cs.utk.edu> <3C9B821C.D9AFCE5D@ehsco.com> <00c701c1d1e4$fd580f80$0301a8c0@davidvaio> <200203222106.g2ML6Pm8003631@foo-bar-baz.cc.vt.edu> Subject: Re: [idn] Re: 7 bits forever! Date: Fri, 22 Mar 2002 16:24:29 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit That's right "Reply All" means the email program will "Reply All" for you, so why do you need to type the i18n email address by yourself with your keyboard!! : ) BTW, I am always seeing your email as an attachment... is this the same for other in the mailing list? If so Valdis can you please fix the way how you send out email first : > David Leung Chief Technology Officer Neteka Inc. T: (416) 971-4302 http://w!.neteka.com ----- Original Message ----- From: To: "David Leung (Neteka Inc.)" Cc: "Eric A. Hall" ; "Keith Moore" ; ; ; Sent: Friday, March 22, 2002 4:06 PM Subject: Re: [idn] Re: 7 bits forever! From owner-idn@ops.ietf.org Fri Mar 22 16:49:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02530 for ; Fri, 22 Mar 2002 16:49:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oWkb-000P0u-00 for idn-data@psg.com; Fri, 22 Mar 2002 13:39:05 -0800 Received: from foo-bar-baz.cc.vt.edu ([128.173.14.103]) by psg.com with esmtp (Exim 3.35 #1) id 16oWka-000P0e-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 13:39:04 -0800 Received: from foo-bar-baz.cc.vt.edu (valdis@localhost [127.0.0.1]) by foo-bar-baz.cc.vt.edu (8.12.2/8.12.2) with ESMTP id g2MLcJm8004257; Fri, 22 Mar 2002 16:38:19 -0500 Message-Id: <200203222138.g2MLcJm8004257@foo-bar-baz.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: "David Leung (Neteka Inc.)" Cc: idn@ops.ietf.org, ietf@ietf.org, iab@isi.edu Subject: Re: [idn] Re: 7 bits forever! In-Reply-To: Your message of "Fri, 22 Mar 2002 16:24:29 EST." <012101c1d1e7$f4c92cc0$0301a8c0@davidvaio> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <3C9B821C.D9AFCE5D@ehsco.com> <00c701c1d1e4$fd580f80$0301a8c0@davidvaio> <200203222106.g2ML6Pm8003631@foo-bar-baz.cc.vt.edu> <012101c1d1e7$f4c92cc0$0301a8c0@davidvaio> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1162145768P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 22 Mar 2002 16:38:19 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --==_Exmh_1162145768P Content-Type: text/plain; charset=us-ascii On Fri, 22 Mar 2002 16:24:29 EST, "David Leung (Neteka Inc.)" said: > That's right "Reply All" means the email program will "Reply All" for you, > so why do you need to type the i18n email address by yourself with your > keyboard!! : ) I don't need to *type* the Chinese address. But if my MUA and MTA can't even *find* the Chinese address, that causes much Very Bad JuJu. > BTW, I am always seeing your email as an attachment... is this the same for > other in the mailing list? If so Valdis can you please fix the way how you > send out email first : > RFC2440. It's even a Proposed Standard. If it's causing interoperability problems, something probably needs to be done. I suspect if the *main* text/plain is being flagged as an attachment, your MUA doesn't have even minimal support for RFC1847 multipart/signed and is downgrading to multipart/mixed. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1162145768P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8m6RLcC3lWbTT17ARAnQyAJ4pw5bKazIkp7nlLejoWtt1dmttcACgkdUP kblBtNp9vO6+fF5BLw+MQjs= =MnLf -----END PGP SIGNATURE----- --==_Exmh_1162145768P-- From owner-idn@ops.ietf.org Fri Mar 22 17:15:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03020 for ; Fri, 22 Mar 2002 17:15:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oX9A-0001DT-00 for idn-data@psg.com; Fri, 22 Mar 2002 14:04:28 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16oX99-0001DL-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 14:04:27 -0800 Message-ID: <013c01c1d1ed$d19546c0$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: Cc: , , References: <200203221808.g2MI8nt01544@astro.cs.utk.edu> <3C9B821C.D9AFCE5D@ehsco.com> <00c701c1d1e4$fd580f80$0301a8c0@davidvaio> <200203222106.g2ML6Pm8003631@foo-bar-baz.cc.vt.edu> <012101c1d1e7$f4c92cc0$0301a8c0@davidvaio> <200203222138.g2MLcJm8004257@foo-bar-baz.cc.vt.edu> Subject: Re: [idn] Re: 7 bits forever! Date: Fri, 22 Mar 2002 17:06:27 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 22 Mar 2002 16:24:29 EST, "David Leung (Neteka Inc.)" said: >> That's right "Reply All" means the email program will "Reply All" for you, >> so why do you need to type the i18n email address by yourself with your >> keyboard!! : ) > >I don't need to *type* the Chinese address. > >But if my MUA and MTA can't even *find* the Chinese address, that causes >much Very Bad JuJu. Well I thought I was talking about the needs of user to user their KEYBOARD to TYPE in i18n email, and not the MUA or MTA being able to send or transport the mail properly to the designate mailbox... I though this discussion was started because some one said there will be a need for users to have "KEYBOARDS" capable to type in all languages in order to use i18n email, and I never said all MUA and MTA can transport or deliver those email properly, if you see my other posting on this list you will see that I mentioned that in order to make i18n email to work there MUST be a protocol change on SMTP and also MIME header changes... I never said that all MUA and MTA in the world will MAGICALLY work :> >> BTW, I am always seeing your email as an attachment... is this the same for >> other in the mailing list? If so Valdis can you please fix the way how you >> send out email first : > > >RFC2440. It's even a Proposed Standard. If it's causing interoperability >problems, something probably needs to be done. I suspect if the *main* >text/plain is being flagged as an attachment, your MUA doesn't have even >minimal support for RFC1847 multipart/signed and is downgrading to >multipart/mixed. The MUA that I am using is just Outlook... I dont need to built my own MUA to read email : ) David Leung Chief Technology Officer Neteka Inc. T: (416) 971-4302 http://w!.neteka.com From owner-idn@ops.ietf.org Fri Mar 22 18:06:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03821 for ; Fri, 22 Mar 2002 18:06:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oXtb-0005EW-00 for idn-data@psg.com; Fri, 22 Mar 2002 14:52:27 -0800 Received: from pheidippides.md.chalmers.se ([129.16.237.91]) by psg.com with esmtp (Exim 3.35 #1) id 16oXtZ-0005EM-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 14:52:26 -0800 Received: from chalmers95a69n (dynamic-193-214.dialup.chalmers.se [129.16.193.214]) by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g2MMqKh14857; Fri, 22 Mar 2002 23:52:20 +0100 (MET) From: "Kent Karlsson" To: Cc: Subject: RE: [idn] Re: 7 bits forever! Date: Fri, 22 Mar 2002 23:48:07 +0100 Message-ID: <000a01c1d1f3$a354b420$d6c11081@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200203221444.g2MEibm8030349@foo-bar-baz.cc.vt.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Let's take as an example the "native language" encoding of my name: > > From: Valdis Kl=?iso8859-4?Q?=BA?=tnieks > > (That's a "small e with macron", Unicode 0113). I don't know what you mean by "native language encoding". The encoding here used 8859-4 with QP, but that is no more "native" nor more "language" than e.g. (most e-mail programs put the encoding outermost) =?utf-16be?Q?Valdis_Kl=01=13tnieks?= (with QP, the encoding reference is of importance only to the QP'd parts, the rest is 7-bit ASCII; technically, that's ok, even though UTF-16 is not an ASCII compatible extension; the entire string should after decoding be represented in either of the Unicode encodings; indeed, technically, the encoding named may be an EBCDIC one, though the non-QP parts are ASCII; by 'technically', I here mean registration policy aside). > If you have a *better* suggestion than 2047-encoding of how > to pass that > character in an e-mail header *that will survive passing through an > intermediary system that enforces strict RFC822*, please clue > us in.... Well, an encoding independent *and* universal method would have been better (like character references in HTML and XML). But MIME slightly predates 10646/Unicode... > 1) RFC1035 says this in section 3.1: > > Although labels can contain any 8 bit values in octets that > make up a > label, it is strongly recommended that labels follow the preferred > syntax described elsewhere in this memo, which is compatible with > existing host naming conventions. Name servers and resolvers must > compare labels in a case-insensitive manner (i.e., A=a), > assuming ASCII > with zero parity. Non-alphabetic codes must match exactly. One would like to think that the (implicit!) restriction to ASCII was in order to reserve the rest for some then unknown "international" extension. But maybe thinking so would be too kind... > 2) Why does it get restricted? Consider the parsing issues > involved if you > have a domain name that uses raw Unicode and embeds the character > known as "Malayalam Letter UU". A hint why this is Very Bad > are available > at http://www.unicode.org/charts/PDF/U0D00.pdf No, I don't see what you mean. I particular I don't know what you mean by "raw Unicode" (do you mean "in UTF-8"? UTF-16 is not compatible with 7-bit ASCII, so you cannot mean that). And even more in particular, I don't see why you have singled out U+0D0A at all. Do you mean that the glyph is similar to another glyph? Parsing by whom? A program (that sees the codes) or a human (preferably one who reads Malayalam fluently)? Neither should have any trouble, as far as I can see. (That most people on this planet cannot read Malayalam is beside the point, so you cannot mean that, do you.) That 0x0D 0x0A is CR LF in ASCII is of course totally irrelevant (see above), unless you do the most huge blunder imaginable ;-) (directly mixing ASCII and UTF-16), and you don't do THAT, do you... /kent k From owner-idn@ops.ietf.org Fri Mar 22 19:02:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04554 for ; Fri, 22 Mar 2002 19:02:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oYq9-00093S-00 for idn-data@psg.com; Fri, 22 Mar 2002 15:52:57 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16oYq8-00093J-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 15:52:56 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16oYq7-00008O-00 for ; Fri, 22 Mar 2002 15:52:55 -0800 Date: Fri, 22 Mar 2002 23:52:55 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] URL encoding in html page Message-ID: <20020322235255.GC31712@nicemice.net> Reply-To: IETF idn working group References: <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03b201c1d184$09260760$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee wrote: > If a simple HTML page contains the following tag, > .com>Hello World! > in which, maybe in a native legacy encoding or utf8 encoding, it > is easy to imagine that some vistors who click that link may be led to > wrong sites or nowhere. Very easy to imagine indeed, because the HTML spec says that the href attribute must contain a URI, and the URI spec says that the host must contain only ASCII letters, digits, hyphens, and dots (or it may be a bracket-enclosed IPv6 address literal). > Should IDNA recommend all HTML authors to use such ACEed URL for > backward compatilbility and error-free fast deployment? Not necessary, since the HTML and URI specs already limit the host to ASCII letters, digits, hyphens, and dots. > Is HTTP/1.2 being planned for IDN HOST: values ? Bruce Thomson replied: > Well, depending on how you want it to work, version 1.1 might be OK. > It allows %-escaped UTF-8 I believe. HTTP 1.1 says that the Host: header field must contain the part of the URI (that is, [:] ), and the URI spec forbids %-escapes in . > Would using ACE here be a change to the HTTP spec No. ACE host labels are honest-to-goodness valid ASCII host labels, so you can use them wherever traditional ASCII host labels are allowed. You don't need any special permission or invitation. AMC From owner-idn@ops.ietf.org Fri Mar 22 19:54:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05056 for ; Fri, 22 Mar 2002 19:54:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oZZB-000Cjv-00 for idn-data@psg.com; Fri, 22 Mar 2002 16:39:29 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16oZZ9-000Cin-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 16:39:27 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2N0dFA21632; Sat, 23 Mar 2002 09:39:15 +0900 Message-ID: <0d7a01c1d202$fd52bcb0$2b19fea9@temp> From: "Soobok Lee" To: "Mark Davis" , "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <0a9f01c1d189$00baa040$2b19fea9@temp> <009c01c1d1b4$c6a2efd0$8900a8c0@c1340594a> <0c0001c1d1bc$feb9f0a0$2b19fea9@temp> <018001c1d1ce$550602d0$8900a8c0@c1340594a> Subject: Re: OT - Re: [idn] URL encoding in html page Date: Sat, 23 Mar 2002 09:38:02 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D76_01C1D24E.6CFA4E70" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0D76_01C1D24E.6CFA4E70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Dear Mark, UNICODE wil get more and more popularity as time goes by. But, that does not mean that legacy encodings will disappear or will be obsoleted by UTF8. There are at least 2 reasons why legacy encodings will be forever. 1. most legacy codes are standardized by local *governmants* that are best qualified to find and reflect local communities's character needs. For example, Korean GOV has been constantly revising its KSX100? local legacy codes to include new Graphic characters and new rarely-used Chinese letters , even before UNICODE decided to include them. In other words, legacy codes are under control of their language communites. But UNICODE are not, and has its own schedules and principles and motivations. It may be *politically* impossible for legacy codes to be obsoleted by UNICODE. Can we imagine Korean Gov publish its laws and rules documents in UNICODE, not in KSX100x ? 2. legacy encodings are already internationally interoperable in popular HTML/MIME contents. There is no reason why KSX100x-encoded homepage owners/message senders should abandon legacy encodings and make transitions into UTF8 at the cost of additional space and operational inefficiency now and even in the forseeable future. I believe UNICODE is now everywhere and will be everywhere even in the future. In the same time, UNICODE has provided legacy encodings/codes with more opportunities to be interoperable with minimum costs. Soobok Lee ----- Original Message ----- From: Mark Davis To: Soobok Lee ; IETF idn working group Sent: Saturday, March 23, 2002 3:21 AM Subject: OT - Re: [idn] URL encoding in html page From my experience talking with customers in the field, the main reason that people are not serving up UTF-8 pages is not the bandwidth, it is the fact that there are still some browsers out in the field that do not yet handle it correctly. While they are dying off fairly quickly, it is not quite at the point where people are willing to write them off. As far as size goes, it is worthwhile looking at some data samples. The following are from a page on the Unicode site that is translated into different languages, so it has essentially the same information on each page. Size Page 8882 s-chinese.html 8946 t-chinese.html 9347 esperanto.html 9498 maltese.html 9739 icelandic.html 9833 czech.html 9944 welsh.html 10064 danish.html 10109 swedish.html 10127 polish.html Size Page 10219 interlingua.html 10221 italian.html 10297 spanish.html 10308 portuguese.html 10312 lithuanian.html 10329 german.html 10376 romanian.html 10401 korean.html 10506 french.html Size Page 10726 japanese.html 10953 hebrew.html 11192 arabic.html 13292 greek.html 13870 russian.html 13892 persian.html 14549 hindi.html 15337 georgian.html 15853 deseret.html So the best case is about 50% of the worst case. Some of this is due to the encoding, and some is due to different languages just using different numbers of characters. However, when you look at web pages in general use, the amount of text (in bytes) is really swamped by graphics, Javascript, HTML code, and so on. So fundamentally, even the variations above are not that important in practice. BTW This is getting way off topic. Mark ————— Γνῶθι σαυτόν — Θαλῆς [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: "Soobok Lee" To: "Mark Davis" ; "IETF idn working group" Sent: Friday, March 22, 2002 08:16 Subject: Re: [idn] URL encoding in html page > > ----- Original Message ----- > From: "Mark Davis" > To: "Soobok Lee" ; "IETF idn working group" > Sent: Saturday, March 23, 2002 12:18 AM > Subject: Re: [idn] URL encoding in html page > > > > Compliant browsers already have to handle Unicode, since NCRs (e.g. > > ሴ ) are always Unicode code points. All XML parsers also have > > to handle Unicode (UTF-8 and UTF-16). > > Right, Already. > MS IE and NEtscape already have been supporting UNICODE > from serveral year ago, but still most homepages are in legacy encodings. > MS WORD (already unicode based) have features to produce (from > unicode-based .doc files) legacy encoded .html files for web publishing > > Korean/Japanese/Chinese texts in UTF8 are 50% bigger than legacy ones. > 50% more disk space and bandwidth will be required. > Each Cyrillic alhpabet in legacy code occupy one octet, while in UTF8, > it requires 3 octets. 200% more space is needed. > I cannot imagine the entire Russians make transition to UTF8. > Legacy encnodings are more space efficient than UNICODE. > > legacy-to-legacy conversions like BIG5->KSX1001 are really being implemented > as two steps of BIG5->UNICODE and UNICODE->KSX1001. UNICODE > are actively used as such intermediate encodings, but still not be used and entered > directly by end users so actively. Rather, UNICODE may be a hub to facilitate interchange > of informations in different legacy encodings or font sharing for differently legacy-encoded chars. > > I regard UNICODE as a substrate (not as a competitor) upon which legacy encodings are built. > > > > > > Legacy encodings > > > will dominates even in the future, because it is compact and > > > inexpensive. > > > > While I do expect the transition to Unicode to take some time, once > > some of the older browsers die off it may shift more rapidly than we > > think. > > I am not UNICODE expert nor character expert. But, everyday, i feel > the strong inertia toward legacy encodings in our local language communties. > language-tagging-enabled text format like HTML will lengthen the lifespan > of legacy encodings by great amounts and allow legacy-coded HTML texts > are internationally interchanged without problems. > > Soobok Lee > > > > > Mark > > ————— > > > > Γνῶθι σαυτόν — Θαλῆς > > [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] > > > > http://www.macchiato.com > > > > ----- Original Message ----- > > From: "Soobok Lee" > > To: "IETF idn working group" > > Sent: Friday, March 22, 2002 02:04 > > Subject: Re: [idn] URL encoding in html page > > > > > > > > > > ----- Original Message ----- > > > From: "Bruce Thomson" > > > To: "Soobok Lee" ; "IETF idn working group" > > > > > Sent: Friday, March 22, 2002 6:29 PM > > > Subject: Re: [idn] URL encoding in html page > > > > > > > > > > > What if all the html viewable text is in english, but, only the > > href url contains > > > > > legacy (korean) encoded hostnames? chinese visitors would see > > clean english homepage, > > > > > but fail to click through the korean link. > > > > > > > > > Well, that could happen, but a META tag would solve that so > > easily. Personally > > > > I often use a simple text editor to deal with HTML, and would find > > it easier to > > > > use legacy encodings or UTF-8 than cut-and-paste ACE from > > somewhere. > > > > Of course the user could do it either way and it would work. > > > > > > Yes. Charset META tags help. But, many homepages have assumptions > > on the main audience's > > > default char encodings and very often omit the META tag for the > > encoding like : > > > > > > > > > Moreover, IDN url would be used in a pure FRAMESET document that > > defines frame URLs > > > and contains no viewable texts. Such FRAMESET documents often omit > > charset META tags. > > > (look into the html source of http://www.freeway.co.kr/ ) > > > > > > AFIAK, 99.99999% of korean homepages have implicit/explicit > > > legacy korean encoding (KS_C_5601-1987 or euc-kr). So do most > > japanese/chineses homepages. > > > UTF8/UCS-2 encodings are rarely used in global WEB publishing. > > Legacy encodings > > > will dominates even in the future, because it is compact and > > inexpensive. > > > > > > IF we want to make IDN truly internationally interoperable, all > > IDN-aware webbrowsers/applications > > > should contain libaries of all kinds of legacy-to-Unicode conversion > > routines. It will burden > > > too much memory load on handheld devices like PDA. > > > > > > Moreover, legacy encodings are revised separately from unicode. We > > may face with as toughest > > > versioning problems as we did in stringprep/nameprep versioning > > problems for newly added unicode points. > > > How to guarantee stability and intergrity of IDN operations in the > > all combinations of numerous kinds and versions of iDN-aware > > > applications and legacy encodings? > > > > > > Soobok Lee > > > > > > > > > > > > ------=_NextPart_000_0D76_01C1D24E.6CFA4E70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Dear = Mark,
 
UNICODE wil get = more and more popularity as=20 time goes by.
But, that does not = mean that legacy encodings=20 will disappear or will be obsoleted by UTF8.
There are at least = 2 reasons why legacy=20 encodings will be forever.
 
 1.  = most legacy codes are=20 standardized by local *governmants* that are best qualified=20 to
       find=20 and reflect  local=20 communities's character needs.
      For example,=20 Korean GOV has been constantly revising its KSX100? local legacy=20 codes
        to=20 include new Graphic characters and new rarely-used Chinese letters = , even=20 before
       =20 UNICODE decided to include them.
      In other words,=20 legacy codes are under control of  their language communites. = But=20 UNICODE
        are=20 not, and has its own schedules and principles and=20 motivations.
      It may be=20 *politically* impossible for legacy codes to be obsoleted by=20 UNICODE.
      Can we=20 imagine  Korean Gov publish its laws and rules documents in = UNICODE, not in=20 KSX100x ?
 
 2. legacy = encodings are=20 already  internationally interoperable in popular HTML/MIME=20 contents.
     There is no reason=20 why  KSX100x-encoded homepage owners/message=20 senders 
       should=20 abandon legacy encodings and make transitions into=20 UTF8    at the cost=20 of additional
       space and operational = inefficiency    now=20 and even in the forseeable future.
 
 I believe = UNICODE is now everywhere=20 and  will be everywhere even in the future. In the same=20 time,
  UNICODE has = provided legacy=20 encodings/codes with more opportunities to be interoperable=20 with
    = minimum=20 costs.
 
 Soobok = Lee
 
----- Original Message = -----
From: Mark = Davis=20
Sent: Saturday, = March 23, 2002 3:21 AM
Subject: OT - Re: = [idn] URL encoding in html=20 page

From my experience talking with = customers in the=20 field, the main reason that people are not serving up UTF-8 pages is = not the=20 bandwidth, it is the fact that there are still some browsers out in = the field=20 that do not yet handle it correctly. While they are dying off fairly = quickly,=20 it is not quite at the point where people are willing to write them=20 off.
 
As far as size goes, it is worthwhile = looking at=20 some data samples. The following are from a page on the Unicode site = that is=20 translated into different languages, so it has essentially the same=20 information on each page.
 =20
Size Page
8882 s-chinese.html
8946 t-chinese.html
9347 esperanto.html
9498 maltese.html
9739 icelandic.html
9833 czech.html
9944 welsh.html
10064 danish.html
10109 swedish.html
10127 polish.html
Size Page
10219 interlingua.html
10221 italian.html
10297 spanish.html
10308 portuguese.html
10312 lithuanian.html
10329 german.html
10376 romanian.html
10401 korean.html
10506 french.html

 
Size Page
10726 japanese.html
10953 hebrew.html
11192 arabic.html
13292 greek.html
13870 russian.html
13892 persian.html
14549 hindi.html
15337 georgian.html
15853 deseret.html

 

So the best case is about 50% of the worst case. Some of this is = due to the=20 encoding, and some is due to different languages just using different = numbers=20 of characters. However, when you look at web pages in general use, the = amount=20 of text (in bytes) is really swamped by graphics, Javascript, HTML = code, and=20 so on. So fundamentally, even the variations above are not that = important in=20 practice.

BTW This is getting way off=20 topic.
 
Mark
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
 
=CE=93=CE=BD=E1=BF=B6=CE=B8=CE=B9 = =CF=83=CE=B1=CF=85=CF=84=CF=8C=CE=BD =E2=80=94 = =CE=98=CE=B1=CE=BB=E1=BF=86=CF=82
[For transliteration, see=20 http://oss.software.ibm.com/cgi-bin/icu/tr]
 
----- Original Message -----
From: "Soobok Lee" <lsb@postel.co.kr>
To: "Mark Davis" <mark@macchiato.com>; "IETF idn=20 working group" <idn@ops.ietf.org>
Sent: Friday, March 22, 2002 = 08:16
Subject: Re: [idn] URL encoding in = html=20 page

>
> ----- Original Message -----
> From: = "Mark Davis"=20 <mark@macchiato.com>
> To:=20 "Soobok Lee" <lsb@postel.co.kr>; = "IETF idn=20 working group" <idn@ops.ietf.org>
> Sent:=20 Saturday, March 23, 2002 12:18 AM
> Subject: Re: [idn] URL = encoding in=20 html page
>
>
> > Compliant browsers already = have to=20 handle Unicode, since NCRs (e.g.
> > &#x1234; ) are = always=20 Unicode code points. All XML parsers also have
> > to handle = Unicode=20 (UTF-8 and UTF-16).
>
> Right, Already.
> MS IE and = NEtscape  already have been supporting  UNICODE
> from = serveral year ago, but still most homepages are in legacy = encodings.
>=20 MS WORD (already unicode based) have features to produce  = (from
>=20 unicode-based .doc files)   legacy encoded .html files  = for web=20 publishing
>
> Korean/Japanese/Chinese texts in UTF8 are = 50%=20 bigger than legacy ones.
> 50% more disk space and = bandwidth  will=20 be required.
> Each Cyrillic alhpabet in legacy code occupy one = octet,=20 while in UTF8,
> it requires 3 octets. 200% more space is=20 needed.
> I cannot imagine the entire Russians make transition = to=20 UTF8.
> Legacy encnodings are more space efficient than = UNICODE.
>=20
> legacy-to-legacy conversions like BIG5->KSX1001 are really = being=20 implemented
> as two steps of BIG5->UNICODE  and=20 UNICODE->KSX1001. UNICODE
> are actively used  as such=20 intermediate encodings, but still not  be  used and = entered
>=20 directly by  end users so actively. Rather, UNICODE  may be = a hub to=20 facilitate  interchange
> of informations in different = legacy=20 encodings or  font sharing for differently legacy-encoded = chars.
>=20
> I  regard UNICODE as a substrate (not as a competitor) = upon=20 which legacy encodings are built.
>
> >
> > = >=20 Legacy encodings
> > > will dominates even in the future, = because=20 it is compact and
> > > inexpensive.
> >
> = >=20 While I do expect the transition to Unicode to take some time, = once
>=20 > some of the older browsers die off it may shift more rapidly than = we
> > think.
>
> I am not UNICODE expert nor = character=20 expert. But, everyday, i  feel
> the strong inertia toward = legacy=20 encodings in our local language communties.
> = language-tagging-enabled=20 text format like HTML will lengthen the lifespan
> of legacy = encodings=20 by great amounts  and allow legacy-coded HTML texts
> are=20 internationally interchanged without problems.
>
> Soobok = Lee
>
> >
> > Mark
> > = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
>=20 >
> > =CE=93=CE=BD=E1=BF=B6=CE=B8=CE=B9 = =CF=83=CE=B1=CF=85=CF=84=CF=8C=CE=BD =E2=80=94 = =CE=98=CE=B1=CE=BB=E1=BF=86=CF=82
> > [For transliteration, see = http://oss.software.ibm.com/cgi-bin/icu/tr]
> >
> > http://www.macchiato.com
>=20 >
> > ----- Original Message -----
> > From: = "Soobok Lee"=20 <lsb@postel.co.kr>
> >=20 To: "IETF idn working group" <idn@ops.ietf.org>
> >=20 Sent: Friday, March 22, 2002 02:04
> > Subject: Re: [idn] URL = encoding in html page
> >
> >
> > = >
> >=20 > ----- Original Message -----
> > > From: "Bruce = Thomson"=20 <bthomson@fm-net.ne.jp>
>=20 > > To: "Soobok Lee" <lsb@postel.co.kr>;=20 "IETF idn working group"
> > <idn@ops.ietf.org>
> >=20 > Sent: Friday, March 22, 2002 6:29 PM
> > > Subject: = Re: [idn]=20 URL encoding in html page
> > >
> > >
> = >=20 > > > What if all the html viewable text is in english, but, = only=20 the
> > href url contains
> > > > > legacy = (korean)=20 encoded hostnames?  chinese visitors would see
> > clean = english=20 homepage,
> > > > > but fail to click through the = korean=20 link.
> > > > >
> > > > Well, that = could=20 happen, but a META tag would solve that so
> > easily.=20 Personally
> > > > I often use a simple text editor to = deal=20 with HTML, and would find
> > it easier to
> > > = > use=20 legacy encodings or UTF-8 than cut-and-paste ACE from
> >=20 somewhere.
> > > > Of course the user could do it = either way=20 and it would work.
> > >
> > > Yes. Charset = META tags=20 help. But, many homepages  have assumptions
> > on the = main=20 audience's
> > > default char encodings and very often = omit=20 the  META tag for the
> > encoding like :
> >=20 >   <meta http-equiv=3D"Content-Type"=20 content=3D"text/html;
> > charset=3Deuc-kr">
> > = >
>=20 > > Moreover, IDN url would be used in a pure FRAMESET document=20 that
> > defines frame URLs
> > > and contains no = viewable texts. Such FRAMESET documents often omit
> > = charset META=20 tags.
> > >  (look into the html source of http://www.freeway.co.kr/ )
>=20 > >
> > > AFIAK, 99.99999% of korean homepages have=20 implicit/explicit
> > > legacy korean encoding = (KS_C_5601-1987 or=20 euc-kr). So do most
> > japanese/chineses homepages.
> = >=20 > UTF8/UCS-2 encodings are rarely used in global WEB = publishing.
>=20 > Legacy encodings
> > > will dominates even in the = future,=20 because it is compact and
> > inexpensive.
> > = >
>=20 > > IF we want to make IDN truly internationally interoperable,=20 all
> > IDN-aware webbrowsers/applications
> > > = should=20 contain libaries of all kinds of legacy-to-Unicode conversion
> = >=20 routines. It will burden
> > > too much memory load on = handheld=20 devices like PDA.
> > >
> > > Moreover, legacy = encodings are revised separately from unicode. We
> > may = face with=20 as toughest
> > > versioning problems as we did in=20 stringprep/nameprep versioning
> > problems for newly added = unicode=20 points.
> > > How to guarantee  stability and = intergrity of=20 IDN operations in the
> > all combinations of  numerous = kinds=20 and versions of iDN-aware
> > > applications and legacy=20 encodings?
> > >
> > > Soobok Lee
> > = >
> > >
> > >
>
>
>=20 ------=_NextPart_000_0D76_01C1D24E.6CFA4E70-- From owner-idn@ops.ietf.org Fri Mar 22 20:19:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05290 for ; Fri, 22 Mar 2002 20:19:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oa4H-000Fan-00 for idn-data@psg.com; Fri, 22 Mar 2002 17:11:37 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16oa4G-000Fae-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 17:11:36 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2N1BUA21865 for ; Sat, 23 Mar 2002 10:11:30 +0900 Message-ID: <0d9101c1d207$7ef78800$2b19fea9@temp> From: "Soobok Lee" To: "IETF idn working group" References: <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <20020322235255.GC31712@nicemice.net> Subject: Re: [idn] URL encoding in html page Date: Sat, 23 Mar 2002 10:10:17 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Adam M. Costello" To: "IETF idn working group" Sent: Saturday, March 23, 2002 8:52 AM Subject: Re: [idn] URL encoding in html page > Soobok Lee wrote: > > > If a simple HTML page contains the following tag, > > .com>Hello World! > > in which, maybe in a native legacy encoding or utf8 encoding, it > > is easy to imagine that some vistors who click that link may be led to > > wrong sites or nowhere. > > Very easy to imagine indeed, because the HTML spec says that the href > attribute must contain a URI, and the URI spec says that the host must > contain only ASCII letters, digits, hyphens, and dots (or it may be a > bracket-enclosed IPv6 address literal). > Right! Under Current URI and HTTP spec, native-encoded IDN hostnames are just illegal inputs and they should be passed to some exception handling mechanisms , for example, search engines like search.netscape.com or auto.search.msn.com. > > Should IDNA recommend all HTML authors to use such ACEed URL for > > backward compatilbility and error-free fast deployment? > > Not necessary, since the HTML and URI specs already limit the host to > ASCII letters, digits, hyphens, and dots. We experts already knew this. But, many ML.com registrants don't know about this poor destiny of ML.com. They want to use native ML.com in their HTML homepage. If we want to have interoperable URI supporting native IDN, we should revise URI spec and HTTP spec BOTH. But, native IDN supports accompany potential legacy code versioning and code interoperablility problems. Would anyone provide indepth analysis on this caveat ? Soobok Lee From owner-idn@ops.ietf.org Fri Mar 22 22:17:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07239 for ; Fri, 22 Mar 2002 22:17:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16obsw-000Prw-00 for idn-data@psg.com; Fri, 22 Mar 2002 19:08:02 -0800 Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by psg.com with esmtp (Exim 3.35 #1) id 16obsv-000PrE-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 19:08:01 -0800 Received: from zetnet.co.uk (bts-0802.dialup.zetnet.co.uk [194.247.51.34]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g2N37ts04277 for ; Sat, 23 Mar 2002 03:07:55 GMT Message-ID: <3C9BBE8A.6CFDB0ED@zetnet.co.uk> Date: Fri, 22 Mar 2002 23:30:18 +0000 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! References: <020901c1d083$74b55aa0$ec333a41@EDMON15> <200203212232.g2LMW6t17451@astro.cs.utk.edu> <20020322003037.31068.qmail@cr.yp.to> <200203221444.g2MEibm8030349@foo-bar-baz.cc.vt.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Valdis.Kletnieks@vt.edu wrote: > Those who think the DNS is being overly strict in enforcing ASCII in > domain names are invited to consider the following: > > 1) RFC1035 says this in section 3.1: > > Although labels can contain any 8 bit values in octets that make up a > label, it is strongly recommended that labels follow the preferred > syntax described elsewhere in this memo, which is compatible with > existing host naming conventions. That's a recommendation about what names should be chosen for hosts, *not* about what names should be accepted by applications in domain name fields. If the purpose of RFC 1035 and RFC 2181 allowing 8-bit was not that at some point the 8th bit would be *used*, then what on earth was it? > Name servers and resolvers must > compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII > with zero parity. Non-alphabetic codes must match exactly. > > RFC2181, section 11, re-iterates that the DNS is codeset-agnostic. > > So what do you know... the DNS spec is already using an N-bit-clean > length-data encoding. So obviously there's some Very Evil Restriction > that makes it not allow non-ASCII. And the favorite whipping boy here > is BIND, which by default restricts it (you can put 'check-names off;' > for a zone in the named.conf file, and you can put 'options no-check-names' > in your resolv.conf). > > 2) Why does it get restricted? Consider the parsing issues involved if you > have a domain name that uses raw Unicode and embeds the character > known as "Malayalam Letter UU". A hint why this is Very Bad are available > at http://www.unicode.org/charts/PDF/U0D00.pdf What are you talking about? There's nothing about U+0D0A that makes it any different from any other character (hint: its UTF-8 encoding is *not* 0x0D 0x0A, if that's what you meant). - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPJu+XzkCAxeYt5gVAQEqLgf+NpZf2v9AE4EE5VO3XaxVOsMjEo/BlcNm faOAfZjtPl7us0mJYa3yAKWB0VE28GrzuHh14INYDhBbsxqk/eXsPLm1ieldvq9y IFpZhkv2Bk/BDma1/BBpZ089k2+TSR29Y+RsDJkfXdHzvzqoBz5W7TtdERR3tlP1 bORaGNblI3L4AXtvEbSfPsQ9ZyiO6aAbqK+QtdOnZ08I4MOJ0qJ0hxnIFDgs+yqT /+2L9vZqWHIGJ+S9ajcgXIqc+RClmQhaYnlPKG1DmN0DVVTjwRlizacI60CnpguD +Ys6ANjSIh7k4JhXYWu7efdIe0cm1iFya8Hxk8fyLx4I+qy3v4SWeQ== =y6PN -----END PGP SIGNATURE----- From owner-idn@ops.ietf.org Fri Mar 22 23:24:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08592 for ; Fri, 22 Mar 2002 23:24:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ocw7-000605-00 for idn-data@psg.com; Fri, 22 Mar 2002 20:15:23 -0800 Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by psg.com with esmtp (Exim 3.35 #1) id 16ocw6-0005zv-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 20:15:22 -0800 Received: from zetnet.co.uk (bts-0743.dialup.zetnet.co.uk [194.247.50.231]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g2N4FJs20834 for ; Sat, 23 Mar 2002 04:15:19 GMT Message-ID: <3C9BCE57.8FCD31D2@zetnet.co.uk> Date: Sat, 23 Mar 2002 00:37:43 +0000 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! References: <000a01c1d1f3$a354b420$d6c11081@chalmers95a69n> Content-Type: text/plain; charset=UTF-8 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA08592 -----BEGIN PGP SIGNED MESSAGE----- Kent Karlsson wrote: > Valdis KlÄ“tnieks wrote: > > Let's take as an example the "native language" encoding of my name: > > > > From: Valdis Kl=?iso8859-4?Q?=BA?=tnieks > > > > (That's a "small e with macron", Unicode 0113). > > I don't know what you mean by "native language encoding". The encoding > here used 8859-4 with QP, but that is no more "native" nor more > "language" than e.g. (most e-mail programs put the encoding outermost) > > =?utf-16be?Q?Valdis_Kl=01=13tnieks?= This is a good demonstration of how poorly specified and generally broken RFC2047 is. It's as clear as mud about whether ASCII characters are interpreted as themselves, or converted to bytes and then reinterpreted as the specified charset, here UTF-16 (as would normally be the case for a transfer encoding syntax in any other context): # (3) 8-bit values which correspond to printable ASCII characters other # than "=", "?", and "_" (underscore), MAY be represented as those # characters. The problem is "which correspond to": does this mean in the specified charset, or in ASCII? I would say in ASCII, which implies that the values are bytes and are reinterpreted as UTF-16. This makes the string invalid because there are an odd number of bytes, but if we remove the final 's' it represents: U+5661 U+6C64 U+6973 U+204B U+6C01 U+1374 U+6E69 U+656B or 噡汤楳â‹æ°á´æ¹©æ•« I would not be surprised if *some* implementations interpreted the spec as you've described, and *some* the way I've described, though. Blech. - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPJvNXTkCAxeYt5gVAQHxhQgAzq5I+B+uuDKyi1MLx0b3zpBMlAKcsO9D vqmacVnpHoJMAAe00XYaXO1Zd1ZTX/r4GA68N8HOLnR2POO1ilzlvO4+x9Gx0GM4 jkeSn34Egldr+B0nVHvon/elDRICBKvQJlIfukld4nNzwLhKQNbZn5W90EQryOrP 9Nd95xpzNsrz61cWmKaG6DaEvS8nRYgPd6r13jiMIry8xfrkR5ZSP2RWGBvf2iK9 wXWX6v7cy4C5F2cq+ihaAOuzl2WJjF/biALFjk2ITpWir0Go5tWlGwLztE33AL+v Xein3WezCyag2YV6Eq6CtY8gs65cDiCzzdnAay9dhohnklDA7Rw7vA== =NZ/G -----END PGP SIGNATURE----- From owner-idn@ops.ietf.org Sat Mar 23 01:21:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10024 for ; Sat, 23 Mar 2002 01:21:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oeaH-000Fha-00 for idn-data@psg.com; Fri, 22 Mar 2002 22:00:57 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16oeaG-000Fh0-00 for idn@ops.ietf.org; Fri, 22 Mar 2002 22:00:56 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id PAA06681 for ; Sat, 23 Mar 2002 15:00:54 +0900 Message-ID: <042001c1d230$09da01f0$a303a8c0@bruce> From: "Bruce Thomson" To: "IETF idn working group" References: <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <20020322235255.GC31712@nicemice.net> Subject: Re: [idn] URL encoding in html page Date: Sat, 23 Mar 2002 15:00:30 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > Would using ACE here be a change to the HTTP spec > > No. ACE host labels are honest-to-goodness valid ASCII host labels, so > you can use them wherever traditional ASCII host labels are allowed. > You don't need any special permission or invitation. Well the HTTP spec doesn't forbid the characters used in ACE, to be sure. But you are tunnelling a new form of information through the legacy protocol, right? As an implementor of a web server, how do I know how to interpret the "host:" field in the HTTP header? If I see something that looks like ACE, I suppose I would need to decode it to the original UTF-8 to compare with my virtual domain definitions. As a WG member, I could probably figure out that I need to do that, but I don't see where that is implied by the specification. Bruce From owner-idn@ops.ietf.org Sat Mar 23 09:32:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21942 for ; Sat, 23 Mar 2002 09:32:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16omDr-000Lvz-00 for idn-data@psg.com; Sat, 23 Mar 2002 06:10:19 -0800 Received: from unknown-raq-customer.dca1.superb.net ([207.228.240.63] helo=www.wordnic.com) by psg.com with esmtp (Exim 3.35 #1) id 16omDq-000Lvt-00 for idn@ops.ietf.org; Sat, 23 Mar 2002 06:10:18 -0800 Received: from [64.109.213.103] (adsl-64-109-213-103.dsl.lgnnmi.ameritech.net [64.109.213.103]) by www.wordnic.com (8.9.3/8.9.3) with ESMTP id IAA07951; Sat, 23 Mar 2002 08:10:11 -0600 Mime-Version: 1.0 X-Sender: tedd1@sperling.com Message-Id: In-Reply-To: <012101c1d1e7$f4c92cc0$0301a8c0@davidvaio> References: <200203221808.g2MI8nt01544@astro.cs.utk.edu> <3C9B821C.D9AFCE5D@ehsco.com> <00c701c1d1e4$fd580f80$0301a8c0@davidvaio> <200203222106.g2ML6Pm8003631@foo-bar-baz.cc.vt.edu> <012101c1d1e7$f4c92cc0$0301a8c0@davidvaio> Date: Sat, 23 Mar 2002 09:10:13 -0500 To: , , From: tedd Subject: Re: [idn] Re: 7 bits forever! [X-idn] Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk >BTW, I am always seeing your email as an attachment... is this the same for >other in the mailing list? If so Valdis can you please fix the way how you >send out email first : > > >David Leung >Chief Technology Officer >Neteka Inc. >T: (416) 971-4302 >http://w!.neteka.com David: What you are receiving from Valdis Kletnieks is a PGP signature block (see below). Some people don't realize that their email appears on the receiving-end as attachments. For example, from just this morning email, I have three unknown documents (Untitled, Untitled 1, Untitled 2) on my computer that I have to delete from this exchange. I would like to know how to stop this, but I am sure in doing so, I would also be forced to stop all attachments -- which I don't want. tedd --- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8m4glcC3lWbTT17ARAhbHAKD+M2foqVF7TZTSKLZyO2vr8+O1hwCg3iE4 yT7bNEEooRzOqI6AaOC7Cm4= =1jnx -----END PGP SIGNATURE----- -- http://sperling.com From owner-idn@ops.ietf.org Sat Mar 23 13:26:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24015 for ; Sat, 23 Mar 2002 13:26:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oq2G-00097E-00 for idn-data@psg.com; Sat, 23 Mar 2002 10:14:36 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.35 #1) id 16oq2F-000977-00 for idn@ops.ietf.org; Sat, 23 Mar 2002 10:14:35 -0800 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 16oq28-000Dtg-00; Sat, 23 Mar 2002 18:14:28 +0000 Date: Sat, 23 Mar 2002 13:14:11 -0500 From: John C Klensin To: tedd cc: idn@ops.ietf.org, ietf@ietf.org, iab@ISI.EDU Subject: Re: [idn] Re: 7 bits forever! [X-idn] Message-ID: <60992099.1016889251@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0b3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Saturday, 23 March, 2002 09:10 -0500 tedd wrote: >> BTW, I am always seeing your email as an attachment... is >> this the same for other in the mailing list? If so Valdis can >> you please fix the way how you send out email first : > >> >> David Leung >> Chief Technology Officer >> Neteka Inc. >>... > David: > > What you are receiving from Valdis Kletnieks is a PGP > signature block (see below). Some people don't realize that > their email appears on the receiving-end as attachments. For > example, from just this morning email, I have three unknown > documents (Untitled, Untitled 1, Untitled 2) on my computer > that I have to delete from this exchange. > > I would like to know how to stop this, but I am sure in doing > so, I would also be forced to stop all attachments -- which I > don't want. Tedd (and others), "Stopping this" is actually very easy (at least in principle) and involves four steps: (i) You get yourself a MIME-competent mail reader. Readers and systems that break a multipart message into a bunch of files and spread them across your system (without an easy way to deal with them as a single message entity) are actually no more MIME-competent than ones that don't recognize MIME headers and structure at all. (ii) You install it. (iii) You stop trying to read or process mail with software that has not been upgraded to conform to decade-old standards and conventions. (iv) You spend a bit of time contemplating this experience any time someone tells you (or you tell someone else) how rapidly a change in the interpretation of a string or format or protocol option will be propagated across the network. You also spend some additional time contemplating how much such un-upgraded software will confuse users when it does seemingly-incomprehensible things without explanation. And, if external constraints on your system environment don't permit you to install an upgraded mail system, you contemplate what _that_ means relative to dissemination of changed/upgraded software if a WG assumes that will happen. The fourth is recommended even for those who have already gotten past the first three stages. john From owner-idn@ops.ietf.org Sat Mar 23 15:48:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25035 for ; Sat, 23 Mar 2002 15:48:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16os9n-000Aaa-00 for idn-data@psg.com; Sat, 23 Mar 2002 12:30:31 -0800 Received: from foo-bar-baz.cc.vt.edu ([128.173.14.103]) by psg.com with esmtp (Exim 3.35 #1) id 16os9n-000AaQ-00 for idn@ops.ietf.org; Sat, 23 Mar 2002 12:30:31 -0800 Received: from foo-bar-baz.cc.vt.edu (valdis@localhost [127.0.0.1]) by foo-bar-baz.cc.vt.edu (8.12.2/8.12.2) with ESMTP id g2NKUDm8012651; Sat, 23 Mar 2002 15:30:14 -0500 Message-Id: <200203232030.g2NKUDm8012651@foo-bar-baz.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Kent Karlsson Cc: idn@ops.ietf.org Subject: Re: [idn] Re: 7 bits forever! In-Reply-To: Your message of "Fri, 22 Mar 2002 23:48:07 +0100." <000a01c1d1f3$a354b420$d6c11081@chalmers95a69n> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1597391128P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sat, 23 Mar 2002 15:30:13 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --==_Exmh_1597391128P Content-Type: text/plain; charset=us-ascii On Fri, 22 Mar 2002 23:48:07 +0100, Kent Karlsson said: > I don't know what you mean by "native language encoding". The encoding > here used 8859-4 with QP, but that is no more "native" nor more > "language" than e.g. (most e-mail programs put the encoding outermost) I meant "the e with macron as my last name had for hundreds of years in the part of Europe where my ancestors lived, not the e without a macron that got substituted when my parents got off the boat in the US just because US English doesn't have a macron." > No, I don't see what you mean. I particular I don't know what you > mean by "raw Unicode" (do you mean "in UTF-8"? UTF-16 is not > compatible with 7-bit ASCII, so you cannot mean that). And even more > in particular, I don't see why you have singled out U+0D0A at all. > Malayalam is beside the point, so you cannot mean that, do you.) That > 0x0D 0x0A is CR LF in ASCII is of course totally irrelevant (see above), > unless you do the most huge blunder imaginable ;-) (directly mixing > ASCII and UTF-16), and you don't do THAT, do you... I don't do that. But that's the sort of thing you're going to have to worry about when people start cut-n-pasting between updated applications and non-updated ones. Hint: How many postings have there been on Bugtraq about IIS and zillions of CGI scripts failing because they didn't handle CRLF encoded in unexpected ways, or other similar failings (shell metacharacters escaped as %nnn, etc)? There be nasty dragons here, and I suspect that a lot of people are trying to minimize them. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1597391128P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8nOXVcC3lWbTT17ARAu1SAKCl+sgzuHAzqbpgi6YfzUdmwtgoLACdH2gz oUJVZgQ2VKCOJFoXb2Zyxxk= =Sa+M -----END PGP SIGNATURE----- --==_Exmh_1597391128P-- From owner-idn@ops.ietf.org Sat Mar 23 18:05:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26252 for ; Sat, 23 Mar 2002 18:05:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ouOo-000C3J-00 for idn-data@psg.com; Sat, 23 Mar 2002 14:54:10 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16ouOn-000C3D-00 for idn@ops.ietf.org; Sat, 23 Mar 2002 14:54:09 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16ouOm-0003Gt-00 for ; Sat, 23 Mar 2002 14:54:08 -0800 Date: Sat, 23 Mar 2002 22:54:08 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] URL encoding in html page Message-ID: <20020323225408.GA12276@nicemice.net> Reply-To: IETF idn working group References: <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <20020322235255.GC31712@nicemice.net> <042001c1d230$09da01f0$a303a8c0@bruce> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <042001c1d230$09da01f0$a303a8c0@bruce> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk Bruce Thomson wrote: > Well the HTTP spec doesn't forbid the characters used in ACE, to be > sure. But you are tunnelling a new form of information through the > legacy protocol, right? Sort of. The ACE label has always been a valid host label. The ACE label itself is not a new form of information. What's new is that this traditional ASCII host label is now considered to be equivalent to a non-ASCII label. But even if you don't know that, you can still treat it as a traditional ASCII host label (which it is), and everything will work, except that humans looking at it won't find it meaningful. > As an implementor of a web server, how do I know how to interpret the > "host:" field in the HTTP header? If I see something that looks like > ACE, I suppose I would need to decode it to the original UTF-8 to > compare with my virtual domain definitions. No, you wouldn't. If you don't know anything about IDNs, then in your mind all host names are ASCII, so you would do an ASCII comparison between the Host: field (which is ASCII) and your virtual domain definitions (which are also ASCII), and that would work just fine. On the other hand, if you know about IDNA, then your virtual domain definitions might be non-ASCII, but you know that the proper way to compare two domain names is to convert both to ASCII and then do an ASCII comparison. (That's IDNA rule 3.) In neither case do you need to decode the ACE. The only time you'd have a reason to do that is when you're trying to hide the ACE from humans. AMC From owner-idn@ops.ietf.org Sun Mar 24 08:16:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13400 for ; Sun, 24 Mar 2002 08:16:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16p7GF-0000l9-00 for idn-data@psg.com; Sun, 24 Mar 2002 04:38:11 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16p7GE-0000l3-00 for idn@ops.ietf.org; Sun, 24 Mar 2002 04:38:10 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2OCbrA09990 for ; Sun, 24 Mar 2002 21:37:54 +0900 Message-ID: <12c401c1d330$8e7110b0$2b19fea9@temp> From: "Soobok Lee" To: "IETF idn working group" References: <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <20020322235255.GC31712@nicemice.net> <0d9101c1d207$7ef78800$2b19fea9@temp> Subject: Re: [idn] URL encoding in html page Date: Sun, 24 Mar 2002 21:36:43 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Soobok Lee" > > Not necessary, since the HTML and URI specs already limit the host to > > ASCII letters, digits, hyphens, and dots. > > We experts already knew this. But, many ML.com registrants don't know about this > poor destiny of ML.com. They want to use native ML.com in their HTML homepage. > > If we want to have interoperable URI supporting native IDN, we should revise > URI spec and HTTP spec BOTH. But, native IDN supports accompany potential > legacy code versioning and code interoperablility problems. > Would anyone provide indepth analysis on this caveat ? > Even if we stay with current HTTP/1.1 which allows only ASCII host: header values, still we could revise URI spec to allow native (utf8 or legacy encoding) IDN in URI. 1) With IDNA and HTTP/1.1 , the web browser can encode Native IDN in URI into ACE one , and then open HTTP 1.1 session into the ACEed hostname with ACE host: value. 2) With IDNA and revised HTTP with utf8 host support, the web browser can encode utf8 IDN in URI into ACE one, and then open HTTP session into ACE hostname with utf8 host: value. 3) With UTF8-based IDN and revised HTTP with utf8 host support, it can check whether the native IDN is in utf8, and, if not, convert the iDN into utf8 , and then open HTTP session into utf8 webhost with utf8 host: value. 2) and 3) may be infeasible due to HTTP's lack of capability negotiation feature like that of ESMTP, because the new web browser with native IDN URI support can't decide whether the web server supports native IDN or supports only ASCII(ACE) host in HOST: value before trying that twice with both forms of host: value (utf8 first, and then ACE if needed). Using ACE host: value is always safe in 1) and 2). BTW, in 1) and 2), we cannot avoid legacy versioning problems because most ACE conversion would be done by "ACE(NFKC(CaseFold(legacy-to-Unicode(native label))))". Most homepages in east asia are in legacy encodings and that monopoly (near 100%) won't change in the forseeable future. new legacy codes may be created after IDN-aware browsers are distributed. old legacy codes may get new code points for newly added characters. If IDN-aware browsers/applications are not upgraded with new legacy-to-Unicode mappings, they will occasionally fail to convert legacy-encoded IDN into UNICODE one. That kind of IDN failure had never seen in LDH DNS. Soobok Lee From owner-idn@ops.ietf.org Sun Mar 24 09:50:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14098 for ; Sun, 24 Mar 2002 09:50:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16p908-0001lB-00 for idn-data@psg.com; Sun, 24 Mar 2002 06:29:40 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16p908-0001l5-00 for idn@ops.ietf.org; Sun, 24 Mar 2002 06:29:40 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2OETSA10794 for ; Sun, 24 Mar 2002 23:29:28 +0900 Message-ID: <12ee01c1d340$251586e0$2b19fea9@temp> From: "Soobok Lee" To: "IETF idn working group" References: <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <20020322235255.GC31712@nicemice.net> <0d9101c1d207$7ef78800$2b19fea9@temp> <12c401c1d330$8e7110b0$2b19fea9@temp> Subject: Re: [idn] URL encoding in html page Date: Sun, 24 Mar 2002 23:28:13 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Soobok Lee" To: "IETF idn working group" Sent: Sunday, March 24, 2002 9:36 PM Subject: Re: [idn] URL encoding in html page > > ----- Original Message ----- > From: "Soobok Lee" > > > Not necessary, since the HTML and URI specs already limit the host to > > > ASCII letters, digits, hyphens, and dots. > > > > We experts already knew this. But, many ML.com registrants don't know about this > > poor destiny of ML.com. They want to use native ML.com in their HTML homepage. > > > > If we want to have interoperable URI supporting native IDN, we should revise > > URI spec and HTTP spec BOTH. But, native IDN supports accompany potential > > legacy code versioning and code interoperablility problems. > > Would anyone provide indepth analysis on this caveat ? > > > > > Even if we stay with current HTTP/1.1 which allows only ASCII host: header values, > still we could revise URI spec to allow native (utf8 or legacy encoding) IDN in URI. > > 1) With IDNA and HTTP/1.1 , the web browser can encode Native IDN in URI into ACE one , and > then open HTTP 1.1 session into the ACEed hostname with ACE host: value. > > 2) With IDNA and revised HTTP with utf8 host support, the web browser can encode > utf8 IDN in URI into ACE one, and then open HTTP session into ACE hostname with utf8 host: value. > > 3) With UTF8-based IDN and revised HTTP with utf8 host support, it can check whether > the native IDN is in utf8, and, if not, convert the iDN into utf8 , and then open > HTTP session into utf8 webhost with utf8 host: value. > > > 2) and 3) may be infeasible due to HTTP's lack of capability negotiation feature like that of ESMTP, s/and 3)// :-) In 3), the webserver surely support native utf8 host: value. > because the new web browser with native IDN URI support can't decide whether the web server supports > native IDN or supports only ASCII(ACE) host in HOST: value before trying that twice with both forms > of host: value (utf8 first, and then ACE if needed). Using ACE host: value is always safe in 1) and 2). > > BTW, in 1) and 2), we cannot avoid legacy versioning problems because > most ACE conversion would be done by "ACE(NFKC(CaseFold(legacy-to-Unicode(native label))))". > Most homepages in east asia are in legacy encodings and that monopoly (near 100%) won't change > in the forseeable future. > > new legacy codes may be created after IDN-aware browsers are distributed. > old legacy codes may get new code points for newly added characters. > If IDN-aware browsers/applications are not upgraded with new legacy-to-Unicode mappings, > they will occasionally fail to convert legacy-encoded IDN into UNICODE one. > That kind of IDN failure had never seen in LDH DNS. > > Soobok Lee > > > > > > > From owner-idn@ops.ietf.org Mon Mar 25 10:43:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15170 for ; Mon, 25 Mar 2002 10:43:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pWGm-000FZ8-00 for idn-data@psg.com; Mon, 25 Mar 2002 07:20:24 -0800 Received: from rwcrmhc52.attbi.com ([216.148.227.88]) by psg.com with esmtp (Exim 3.35 #1) id 16pWGl-000FZ2-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 07:20:23 -0800 Received: from c1340594a ([12.234.212.162]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020325152021.KVVQ1147.rwcrmhc52.attbi.com@c1340594a>; Mon, 25 Mar 2002 15:20:21 +0000 Message-ID: <013801c1d410$9c0ce2e0$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Soobok Lee" , "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <0a9f01c1d189$00baa040$2b19fea9@temp> <009c01c1d1b4$c6a2efd0$8900a8c0@c1340594a> <0c0001c1d1bc$feb9f0a0$2b19fea9@temp> <018001c1d1ce$550602d0$8900a8c0@c1340594a> <0d7a01c1d202$fd52bcb0$2b19fea9@temp> Subject: Re: OT - Re: [idn] URL encoding in html page Date: Mon, 25 Mar 2002 07:20:34 -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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit It is of course possible that some areas do not accept it, much as the United States has not accepted the metric system (except for scientific work, and the important realm of soft-drink bottles). It is difficult to predict the speed of adoption of any technology, but I suspect you will be surprised at the situation in 5 or 10 years. Mark ————— Γνῶθι σαυτόν — Θαλῆς [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: "Soobok Lee" To: "Mark Davis" ; "IETF idn working group" Sent: Friday, March 22, 2002 16:38 Subject: Re: OT - Re: [idn] URL encoding in html page > Dear Mark, > > UNICODE wil get more and more popularity as time goes by. > But, that does not mean that legacy encodings will disappear or will be obsoleted by UTF8. > There are at least 2 reasons why legacy encodings will be forever. > > 1. most legacy codes are standardized by local *governmants* that are best qualified to > find and reflect local communities's character needs. > For example, Korean GOV has been constantly revising its KSX100? local legacy codes > to include new Graphic characters and new rarely-used Chinese letters , even before > UNICODE decided to include them. > In other words, legacy codes are under control of their language communites. But UNICODE > are not, and has its own schedules and principles and motivations. > It may be *politically* impossible for legacy codes to be obsoleted by UNICODE. > Can we imagine Korean Gov publish its laws and rules documents in UNICODE, not in KSX100x ? > > 2. legacy encodings are already internationally interoperable in popular HTML/MIME contents. > There is no reason why KSX100x-encoded homepage owners/message senders > should abandon legacy encodings and make transitions into UTF8 at the cost of additional > space and operational inefficiency now and even in the forseeable future. > > I believe UNICODE is now everywhere and will be everywhere even in the future. In the same time, > UNICODE has provided legacy encodings/codes with more opportunities to be interoperable with > minimum costs. > > Soobok Lee > > ----- Original Message ----- > From: Mark Davis > To: Soobok Lee ; IETF idn working group > Sent: Saturday, March 23, 2002 3:21 AM > Subject: OT - Re: [idn] URL encoding in html page > > > From my experience talking with customers in the field, the main reason that people are not serving up UTF-8 pages is not the > bandwidth, it is the fact that there are still some browsers out in the field that do not yet handle it correctly. While they are > dying off fairly quickly, it is not quite at the point where people are willing to write them off. > > As far as size goes, it is worthwhile looking at some data samples. The following are from a page on the Unicode site that is > translated into different languages, so it has essentially the same information on each page. > Size Page > 8882 s-chinese.html > 8946 t-chinese.html > 9347 esperanto.html > 9498 maltese.html > 9739 icelandic.html > 9833 czech.html > 9944 welsh.html > 10064 danish.html > 10109 swedish.html > 10127 polish.html > Size Page > 10219 interlingua.html > 10221 italian.html > 10297 spanish.html > 10308 portuguese.html > 10312 lithuanian.html > 10329 german.html > 10376 romanian.html > 10401 korean.html > 10506 french.html > > > Size Page > 10726 japanese.html > 10953 hebrew.html > 11192 arabic.html > 13292 greek.html > 13870 russian.html > 13892 persian.html > 14549 hindi.html > 15337 georgian.html > 15853 deseret.html > > > > > So the best case is about 50% of the worst case. Some of this is due to the encoding, and some is due to different languages just > using different numbers of characters. However, when you look at web pages in general use, the amount of text (in bytes) is really > swamped by graphics, Javascript, HTML code, and so on. So fundamentally, even the variations above are not that important in > practice. > > BTW This is getting way off topic. > > Mark > ————— > > Γνῶθι σαυτόν — Θαλῆς > [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] > > http://www.macchiato.com > > ----- Original Message ----- > From: "Soobok Lee" > To: "Mark Davis" ; "IETF idn working group" > Sent: Friday, March 22, 2002 08:16 > Subject: Re: [idn] URL encoding in html page > > > > > > ----- Original Message ----- > > From: "Mark Davis" > > To: "Soobok Lee" ; "IETF idn working group" > > Sent: Saturday, March 23, 2002 12:18 AM > > Subject: Re: [idn] URL encoding in html page > > > > > > > Compliant browsers already have to handle Unicode, since NCRs (e.g. > > > ሴ ) are always Unicode code points. All XML parsers also have > > > to handle Unicode (UTF-8 and UTF-16). > > > > Right, Already. > > MS IE and NEtscape already have been supporting UNICODE > > from serveral year ago, but still most homepages are in legacy encodings. > > MS WORD (already unicode based) have features to produce (from > > unicode-based .doc files) legacy encoded .html files for web publishing > > > > Korean/Japanese/Chinese texts in UTF8 are 50% bigger than legacy ones. > > 50% more disk space and bandwidth will be required. > > Each Cyrillic alhpabet in legacy code occupy one octet, while in UTF8, > > it requires 3 octets. 200% more space is needed. > > I cannot imagine the entire Russians make transition to UTF8. > > Legacy encnodings are more space efficient than UNICODE. > > > > legacy-to-legacy conversions like BIG5->KSX1001 are really being implemented > > as two steps of BIG5->UNICODE and UNICODE->KSX1001. UNICODE > > are actively used as such intermediate encodings, but still not be used and entered > > directly by end users so actively. Rather, UNICODE may be a hub to facilitate interchange > > of informations in different legacy encodings or font sharing for differently legacy-encoded chars. > > > > I regard UNICODE as a substrate (not as a competitor) upon which legacy encodings are built. > > > > > > > > > Legacy encodings > > > > will dominates even in the future, because it is compact and > > > > inexpensive. > > > > > > While I do expect the transition to Unicode to take some time, once > > > some of the older browsers die off it may shift more rapidly than we > > > think. > > > > I am not UNICODE expert nor character expert. But, everyday, i feel > > the strong inertia toward legacy encodings in our local language communties. > > language-tagging-enabled text format like HTML will lengthen the lifespan > > of legacy encodings by great amounts and allow legacy-coded HTML texts > > are internationally interchanged without problems. > > > > Soobok Lee > > > > > > > > Mark > > > ————— > > > > > > Γνῶθι σαυτόν — Θαλῆς > > > [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] > > > > > > http://www.macchiato.com > > > > > > ----- Original Message ----- > > > From: "Soobok Lee" > > > To: "IETF idn working group" > > > Sent: Friday, March 22, 2002 02:04 > > > Subject: Re: [idn] URL encoding in html page > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Bruce Thomson" > > > > To: "Soobok Lee" ; "IETF idn working group" > > > > > > > Sent: Friday, March 22, 2002 6:29 PM > > > > Subject: Re: [idn] URL encoding in html page > > > > > > > > > > > > > > What if all the html viewable text is in english, but, only the > > > href url contains > > > > > > legacy (korean) encoded hostnames? chinese visitors would see > > > clean english homepage, > > > > > > but fail to click through the korean link. > > > > > > > > > > > Well, that could happen, but a META tag would solve that so > > > easily. Personally > > > > > I often use a simple text editor to deal with HTML, and would find > > > it easier to > > > > > use legacy encodings or UTF-8 than cut-and-paste ACE from > > > somewhere. > > > > > Of course the user could do it either way and it would work. > > > > > > > > Yes. Charset META tags help. But, many homepages have assumptions > > > on the main audience's > > > > default char encodings and very often omit the META tag for the > > > encoding like : > > > > > > > > > > > > Moreover, IDN url would be used in a pure FRAMESET document that > > > defines frame URLs > > > > and contains no viewable texts. Such FRAMESET documents often omit > > > charset META tags. > > > > (look into the html source of http://www.freeway.co.kr/ ) > > > > > > > > AFIAK, 99.99999% of korean homepages have implicit/explicit > > > > legacy korean encoding (KS_C_5601-1987 or euc-kr). So do most > > > japanese/chineses homepages. > > > > UTF8/UCS-2 encodings are rarely used in global WEB publishing. > > > Legacy encodings > > > > will dominates even in the future, because it is compact and > > > inexpensive. > > > > > > > > IF we want to make IDN truly internationally interoperable, all > > > IDN-aware webbrowsers/applications > > > > should contain libaries of all kinds of legacy-to-Unicode conversion > > > routines. It will burden > > > > too much memory load on handheld devices like PDA. > > > > > > > > Moreover, legacy encodings are revised separately from unicode. We > > > may face with as toughest > > > > versioning problems as we did in stringprep/nameprep versioning > > > problems for newly added unicode points. > > > > How to guarantee stability and intergrity of IDN operations in the > > > all combinations of numerous kinds and versions of iDN-aware > > > > applications and legacy encodings? > > > > > > > > Soobok Lee > > > > > > > > > > > > > > > > > > > From owner-idn@ops.ietf.org Mon Mar 25 11:15:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17433 for ; Mon, 25 Mar 2002 11:15:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pWgv-000FwF-00 for idn-data@psg.com; Mon, 25 Mar 2002 07:47:25 -0800 From: David Frascone To: "David Leung \(Neteka Inc.\)" Cc: Valdis.Kletnieks@vt.edu, idn@ops.ietf.org, ietf@ietf.org, iab@isi.edu Subject: Re: [idn] Re: 7 bits forever! Message-ID: <20020325154317.GJ4284@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012101c1d1e7$f4c92cc0$0301a8c0@davidvaio> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-idn@ops.ietf.org Precedence: bulk Date: Mon, 25 Mar 2002 07:47:25 -0800 I get his messages as properly signed PGP attachments. Seems like your mail user agent is having trouble with it. Might I suggest an upgrade to a more "clueful" mail client? Personally, I use mutt (http://www.mutt.org) -Dave On Friday, 22 Mar 2002, David Leung (Neteka Inc.) wrote: > That's right "Reply All" means the email program will "Reply All" for you, > so why do you need to type the i18n email address by yourself with your > keyboard!! : ) > > BTW, I am always seeing your email as an attachment... is this the same for > other in the mailing list? If so Valdis can you please fix the way how you > send out email first : > > > David Leung > Chief Technology Officer > Neteka Inc. > T: (416) 971-4302 > http://w!.neteka.com > ----- Original Message ----- > From: > To: "David Leung (Neteka Inc.)" > Cc: "Eric A. Hall" ; "Keith Moore" ; > ; ; > Sent: Friday, March 22, 2002 4:06 PM > Subject: Re: [idn] Re: 7 bits forever! > > > > -- David Frascone Famous last words - Don't worry, I can handle it. From owner-idn@ops.ietf.org Mon Mar 25 13:12:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23549 for ; Mon, 25 Mar 2002 13:12:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pYj9-000Hlx-00 for idn-data@psg.com; Mon, 25 Mar 2002 09:57:51 -0800 Received: from dove.cc.ncu.edu.tw ([140.115.17.111]) by psg.com with esmtp (Exim 3.35 #1) id 16pYj4-000HlZ-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 09:57:50 -0800 Received: from LocalHost ([140.115.67.81]) (authenticated tsenglm (0 bits)) by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g2PHvTU09863 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 26 Mar 2002 01:57:29 +0800 (CST) Message-ID: <006901c1d425$e4c24560$5143738c@me.ncu.edu.tw> From: =?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= To: "\"Yves Arrouye\"" , References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> Subject: [idn] Web navigation for IDN resolving Date: Tue, 26 Mar 2002 01:52:53 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Yves Arrouye: The following is the message from Mr. YangWoo Ko (newcat@spsoft.co.kr), but something is not the same in our IE environments. > yves corrected me that "if the address looks like a domain name, > ie first does a dns lookup of the domain name after encoding it > in UTF-8" > > thanks to yves. > > i am still worndering what "looks like a domain name" means. > As I know in Taiwan and China Area, the input Chinese character string with non-protocol-head in Chinese Domain name form typed into input bar of IE , the browser will intercept these string and convert it to a UTF-8 %nn string as one of parameters to auto.search.msn.com , then it will be passed to Realname's server. The server of Realname will convert the dotted IDN domain name to an UTF-8 form and re-post it in the input bar with an error reply to hold it in client. The server of Realname never to do dns lookup and not try to re-direct the client browser to do dns lookup in replied UTF-8 form. That is very strange , why MicroSoft/Realname do not support UTF-8 IDN resolving as she have proposed ? In win2K system , the IE can not display all UTF-8 string in input bar of IE , but it can passed it to resolver and resolve it correctly. Although we know the cross visiting of different native language based web server will caused some problems in relative addressed gif file downloaded correctly from visited web server, but it is work well in win2K. So, why RealName server suspend the redirection of client with re-post UTF-8 IDN to stop win2K to do further resolving in client ? Can you help me to understand it ? L.M.Tseng From owner-idn@ops.ietf.org Mon Mar 25 13:55:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26302 for ; Mon, 25 Mar 2002 13:55:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pZS6-000IKz-00 for idn-data@psg.com; Mon, 25 Mar 2002 10:44:18 -0800 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.35 #1) id 16pZS5-000IKt-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 10:44:17 -0800 Received: (qmail 23332 invoked by uid 104); 25 Mar 2002 18:44:16 -0000 Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.825756 secs); 25 Mar 2002 18:44:16 -0000 Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; 25 Mar 2002 18:44:15 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:1389]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <437658@heaven.internal.realnames.com> for ; Mon, 25 Mar 2002 10:39:09 AM -0800 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 10:43:56 -0800 Message-ID: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> From: Yves Arrouye To: "'tsenglm@????.??.tw'" , "\"Yves Arrouye\"" , idn@ops.ietf.org Subject: RE: [idn] Web navigation for IDN resolving Date: Mon, 25 Mar 2002 10:40:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idn@ops.ietf.org Precedence: bulk > As I know in Taiwan and China Area, the input Chinese character > string > with non-protocol-head in Chinese Domain name form typed into input bar > of > IE , the browser will intercept these string and convert it to a UTF-8 %nn > string as one of parameters to auto.search.msn.com , then it will be > passed > to Realname's server. The server of Realname will convert the dotted IDN > domain name to an UTF-8 form and re-post it in the input bar with an error > reply to hold it in client. > The server of Realname never to do dns lookup and not try to re- > direct > the client browser to do dns lookup in replied UTF-8 form. The DNS lookup happened *before* the string was URL-encoded and passed to Autosearch, which only happen after a failure. Please refer to draft-arrouye-idn-ie5-resolution-00.txt. RealNames *does* provide resolution services for IDNs on a contractual basis, and so far we resolve .com, .org, .net, and .jp. IDNs typed with these TLDs will resolve using an ACE. YA From owner-idn@ops.ietf.org Mon Mar 25 15:53:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03095 for ; Mon, 25 Mar 2002 15:53:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pb92-000Jq8-00 for idn-data@psg.com; Mon, 25 Mar 2002 12:32:44 -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.35 #1) id 16pb90-000Jpo-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 12:32:43 -0800 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.2/8.12.2) with ESMTP id g2PKWOKY016445; Mon, 25 Mar 2002 21:32:24 +0100 To: C C Magnus Gustavsson Cc: idn@ops.ietf.org Subject: [idn] Re: Another solution? References: In-Reply-To: (C C Magnus Gustavsson's message of "Tue, 19 Mar 2002 13:39:03 +0100 (CET)") From: Simon Josefsson Date: Mon, 25 Mar 2002 21:33:02 +0100 Message-ID: Lines: 25 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk C C Magnus Gustavsson writes: > We could consider wiping the slate clean and design a new protocol. > (Bear with me just a little while longer.) Let's call it e g INS (for > Internet Name System or International Names System) to distinguish it > from DNS and ask IANA to assign, say, port 40 for it's use. We would > not only be able to introduce non-ASCII domain names using UTF-8 in a > nice, clean fashion and in accordance with RFC 2277. We could double > (or triple) the maximal allowed length for domain names and have four > times the number of flags. We could introduce a version number in the > protocol to make future changes easier and use experience with EDNS to > make it easier to expand in the future if needed. We could replace SRV > records (RFC 2782) with a cleaner and better solution, introducing > QSERV and QPROTO fields in the queries. And so on. All in all, we > could clean up and improve the current DNS standard significantly. I think many people have been thinking about this. However, people seems to fear that designing a new protocol would increase the speed of namespace fragmentation. foo.com would be available in DNS and not in INS and vice versa. I believe the "namespace fragmentation" argument is a poor one -- namespace fragmentation isn't a protocol issue, it is a political issue. Put pressure on organizations handling the namespace to not fragment it and they won't fragment it. If the pressure isn't there, they will continue to do whatever they can get away with. From owner-idn@ops.ietf.org Mon Mar 25 20:28:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10441 for ; Mon, 25 Mar 2002 20:28:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pfUk-000O3X-00 for idn-data@psg.com; Mon, 25 Mar 2002 17:11:26 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16pfUj-000O2y-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 17:11:26 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2Q10OA25937; Tue, 26 Mar 2002 10:00:24 +0900 Message-ID: <032f01c1d461$6efac910$2b19fea9@temp> From: "Soobok Lee" To: "Yves Arrouye" , "'tsenglm@????.??.tw'" , "\"Yves Arrouye\"" , References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> Subject: Re: [idn] Web navigation for IDN resolving Date: Tue, 26 Mar 2002 09:59:06 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Yves Arrouye" To: "'tsenglm@????.??.tw'" ; ""Yves Arrouye"" ; Sent: Tuesday, March 26, 2002 3:40 AM Subject: RE: [idn] Web navigation for IDN resolving > > As I know in Taiwan and China Area, the input Chinese character > > string > > with non-protocol-head in Chinese Domain name form typed into input bar > > of > > IE , the browser will intercept these string and convert it to a UTF-8 %nn > > string as one of parameters to auto.search.msn.com , then it will be > > passed > > to Realname's server. The server of Realname will convert the dotted IDN > > domain name to an UTF-8 form and re-post it in the input bar with an error > > reply to hold it in client. > > The server of Realname never to do dns lookup and not try to re- > > direct > > the client browser to do dns lookup in replied UTF-8 form. > > The DNS lookup happened *before* the string was URL-encoded and passed to > Autosearch, which only happen after a failure. In MS IE 5.0 or later, this is true only for these two kinds of url inputs: try dns lookup first 1) with explicit http: prefix http://www..com http://.com 2) without http: prefix www..com In these two cases, IEs try dns lookup for IDN hostname regardless of whether it is in utf8 or legacy encoding. IE does *not* try dns lookup for this third kind of url input without http: prefix 3) hostnames begin with non-ASCII char .com ..com IN this case, those inputs are treated as invalid inputs and passed into auto.search.msn.com for MSN search/Realnames keyword lookups. This IE's heuristic may be confusing to someone, but, that is not a error and just attempts to be loyal to both user expectations and ASCII only URI spec. IMO, 1) and 2) dns lookup should also have been prohibited and should be passed to search engines for IDNA or UTF8 conversions, because in most cases, they are in legacy encodings and make troubles like legacy code confusion/collisions on DNS servers without appropirate conversions. Netscape has different heuristic. Netscape passes any chars(including !?#$,,,) into dns lookups. Soobok Lee > Please refer to > draft-arrouye-idn-ie5-resolution-00.txt. RealNames *does* provide resolution > services for IDNs on a contractual basis, and so far we resolve .com, .org, > .net, and .jp. IDNs typed with these TLDs will resolve using an ACE. > > YA > From owner-idn@ops.ietf.org Mon Mar 25 20:29:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10458 for ; Mon, 25 Mar 2002 20:29:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pfRg-000Nyu-00 for idn-data@psg.com; Mon, 25 Mar 2002 17:08:16 -0800 Received: from saturn.sun.com ([192.9.25.2]) by psg.com with esmtp (Exim 3.35 #1) id 16pfRf-000Nyo-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 17:08:15 -0800 Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20858; Mon, 25 Mar 2002 17:08:12 -0800 (PST) Received: from we-gotmail.red.iplanet.com (gotmail-a.red.iplanet.com [192.18.73.248]) by dm-usca19-13.red.iplanet.com (8.10.2+Sun/8.10.2/IPLANET,v1.1) with ESMTP id g2Q18aU22861; Mon, 25 Mar 2002 17:08:37 -0800 (PST) Received: from sun.com (h-192-18-127-177.red.iplanet.com [192.18.127.177]) by we-gotmail.red.iplanet.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTPS id <0GTK006FQ35M2E@we-gotmail.red.iplanet.com>; Mon, 25 Mar 2002 17:08:11 -0800 (PST) Date: Mon, 25 Mar 2002 17:11:44 -0800 From: "A. Vine" Subject: Re: [idn] URL encoding in html page To: Soobok Lee Cc: IETF idn working group Message-id: <3C9FCAD0.1080701@sun.com> MIME-version: 1.0 Content-type: text/html; charset=x-windows-949 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, fr, de, it, ru, ja User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <0a9f01c1d189$00baa040$2b19fea9@temp> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT
FYI, browsers and many other apps already have massive conversion libraries.
IF we want to make IDN truly internationally interoperable, all IDN-aware webbrowsers/applications
should contain libaries of all kinds of legacy-to-Unicode conversion routines. It will burden
too much memory load on handheld devices like PDA.

Moreover, legacy encodings are revised separately from unicode. We may face with as toughest
versioning problems as we did in stringprep/nameprep versioning problems for newly added unicode points.
How to guarantee  stability and intergrity of IDN operations in the all combinations of  numerous kinds and versions of iDN-aware
applications and legacy encodings?

Soobok Lee


From owner-idn@ops.ietf.org Mon Mar 25 20:42:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10716 for ; Mon, 25 Mar 2002 20:42:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pfgT-000OFa-00 for idn-data@psg.com; Mon, 25 Mar 2002 17:23:33 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16pfgS-000OFT-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 17:23:32 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2Q1NIA26234; Tue, 26 Mar 2002 10:23:18 +0900 Message-ID: <036c01c1d464$a1a0e9a0$2b19fea9@temp> From: "Soobok Lee" To: "A. Vine" Cc: "IETF idn working group" References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <0a9f01c1d189$00baa040$2b19fea9@temp> <3C9FCAD0.1080701@sun.com> Subject: Re: [idn] URL encoding in html page Date: Tue, 26 Mar 2002 10:21:56 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0362_01C1D4B0.0E30B410" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0362_01C1D4B0.0E30B410 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: A. Vine To: Soobok Lee Cc: IETF idn working group Sent: Tuesday, March 26, 2002 10:11 AM Subject: Re: [idn] URL encoding in html page FYI, browsers and many other apps already have massive conversion libraries. Yes. But, legacy encodings are often revised or there may be new born legacy encoding. What and how much does that affect the stable operation of IDN in networks of various versions of IDN-aware applications? That is my questions on which I still has no answer. Soobok Lee IF we want to make IDN truly internationally interoperable, all IDN-aware webbrowsers/applications should contain libaries of all kinds of legacy-to-Unicode conversion routines. It will burdentoo much memory load on handheld devices like PDA.Moreover, legacy encodings are revised separately from unicode. We may face with as toughestversioning problems as we did in stringprep/nameprep versioning problems for newly added unicode points.How to guarantee stability and intergrity of IDN operations in the all combinations of numerous kinds and versions of iDN-awareapplications and legacy encodings?Soobok Lee ------=_NextPart_000_0362_01C1D4B0.0E30B410 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
 
----- Original Message ----- =
From: A. = Vine
Sent: Tuesday, March 26, = 2002 10:11 AM
Subject: Re: [idn] URL = encoding in html=20 page

FYI, browsers and many other apps already have massive = conversion=20 libraries.
 
Yes. But, = legacy encodings are often=20 revised or there may be new born legacy encoding.
What and how = much does that=20 affect the stable operation=20 of  IDN  in networks of various versions of =
IDN-aware=20 applications?
That is my=20 questions  on which I still has no answer.
Soobok = Lee
IF we want to make IDN truly = internationally=20 interoperable, all IDN-aware webbrowsers/applications
should contain libaries of all kinds of legacy-to-Unicode =
conversion routines. It will burden
too much memory load on handheld =
devices like PDA.

Moreover, legacy encodings are revised =
separately from unicode. We may face with as toughest
versioning =
problems as we did in stringprep/nameprep versioning problems for newly =
added unicode points.
How to guarantee  stability and intergrity of =
IDN operations in the all combinations of  numerous kinds and versions =
of iDN-aware
applications and legacy encodings?

Soobok =
Lee


= ------=_NextPart_000_0362_01C1D4B0.0E30B410-- From owner-idn@ops.ietf.org Mon Mar 25 20:49:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10827 for ; Mon, 25 Mar 2002 20:49:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pfvO-000OXt-00 for idn-data@psg.com; Mon, 25 Mar 2002 17:38:58 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16pfvN-000OVv-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 17:38:57 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2Q1SwA26268; Tue, 26 Mar 2002 10:28:58 +0900 Message-ID: <037901c1d465$6c9b0a50$2b19fea9@temp> From: "Soobok Lee" To: "Soobok Lee" , "Yves Arrouye" , "'tsenglm@????.??.tw'" , "\"Yves Arrouye\"" , Subject: Re: [idn] Web navigation for IDN resolving Date: Tue, 26 Mar 2002 10:27:41 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Soobok Lee" > Netscape has different heuristic. Netscape passes any chars(including !?#$,,,) into dns lookups. Netscape Nevigator 4.7 passes URL inputs to its default search engine (search.netscape.com) if the url inputs contains any *SPACE*. I don't know whether other delimiters also trigger such exception handling behavior. It passes other single-worded url inputs that have any chars in any legacy encodings directory to dns servers. I had no information about the behaviour of Netscape Nevigator 6.0 or later. From owner-idn@ops.ietf.org Mon Mar 25 21:12:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11376 for ; Mon, 25 Mar 2002 21:12:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pgLx-000P3G-00 for idn-data@psg.com; Mon, 25 Mar 2002 18:06:25 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16pgLw-000P3A-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 18:06:24 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id LAA19828; Tue, 26 Mar 2002 11:06:18 +0900 Message-ID: <04d001c1d46a$b273cd00$a303a8c0@bruce> From: "Bruce Thomson" To: "Soobok Lee" , "IETF idn working group" References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <032f01c1d461$6efac910$2b19fea9@temp> Subject: Re: [idn] Web navigation for IDN resolving Date: Tue, 26 Mar 2002 11:05:25 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In MS IE 5.0 or later, > this is true only for these two kinds of url inputs: try dns lookup first > > 1) with explicit http: prefix > > http://www..com > http://.com > > 2) without http: prefix > > www..com > > In these two cases, IEs try dns lookup for IDN hostname regardless of whether it is in utf8 or legacy encoding. > > IE does *not* try dns lookup for this third kind of url input without http: prefix > With IE 6, I find that it's doing the DNS lookup in all three cases. Bruce From owner-idn@ops.ietf.org Mon Mar 25 22:27:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13466 for ; Mon, 25 Mar 2002 22:27:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16phVS-0000DN-00 for idn-data@psg.com; Mon, 25 Mar 2002 19:20:18 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16phVR-0000DH-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 19:20:17 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2Q3K2A27287; Tue, 26 Mar 2002 12:20:02 +0900 Message-ID: <04db01c1d474$f0b0d4a0$2b19fea9@temp> From: "Soobok Lee" To: "Bruce Thomson" , "IETF idn working group" References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <032f01c1d461$6efac910$2b19fea9@temp> <04d001c1d46a$b273cd00$a303a8c0@bruce> Subject: Re: [idn] Web navigation for IDN resolving Date: Tue, 26 Mar 2002 12:18:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Bruce Thomson" > > With IE 6, I find that it's doing the DNS lookup in all three cases. > I have not tested with Japanese or English version of MS IE 6.0. I have only Korean MS IE 6.0 (version 6.0.2600.00), and find it does not try dns lookup for ".com" and "..com" and just sends them into auto.search.msn.com. ( I had a debugging session with my name servers ). the auto.search.msn.com/realnames receives those search queries and converts them into ACE ones and answers with redirection requests for http://bq--???.mltbd.com. For other TLDs like ".cc", the search engine responds with "not found" error pages. From owner-idn@ops.ietf.org Tue Mar 26 02:43:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26714 for ; Tue, 26 Mar 2002 02:43:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16plNC-0003qm-00 for idn-data@psg.com; Mon, 25 Mar 2002 23:28:02 -0800 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.35 #1) id 16plNB-0003qf-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 23:28:01 -0800 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g2Q7Rx813053 for ; Tue, 26 Mar 2002 08:27:59 +0100 (MET) Received: from trab.se ([131.115.48.20]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g2Q7Rvk13022; Tue, 26 Mar 2002 08:27:57 +0100 (MET) Message-ID: <3CA022FD.20126C6F@trab.se> Date: Tue, 26 Mar 2002 08:27:57 +0100 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: mag@lysator.liu.se, simon+idn@josefsson.org, idn@ops.ietf.org Subject: Re: [idn] Re: Another solution? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >I think many people have been thinking about this. However, people >seems to fear that designing a new protocol would increase the speed >of namespace fragmentation. foo.com would be available in DNS and not >in INS and vice versa. I believe the "namespace fragmentation" >argument is a poor one -- namespace fragmentation isn't a protocol >issue, it is a political issue. Put pressure on organizations >handling the namespace to not fragment it and they won't fragment it. >If the pressure isn't there, they will continue to do whatever they >can get away with. Instead of designing a new protocol we could do as John Klensin has proposed: use a separate class or some other method so that the non-ASCII names exist in the same DNS world but invisible for the old world. Backward compatible need not mean that old software must be able to handle or see new things. The important is that all old things still works as before. Why not require that all protocols over IPv6 MUST use UTF-8? All software need to be rewritten to handle IPv6, we not require them to use UTF-8 in protocols? Dan From owner-idn@ops.ietf.org Tue Mar 26 02:50:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26803 for ; Tue, 26 Mar 2002 02:50:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16plYS-00041X-00 for idn-data@psg.com; Mon, 25 Mar 2002 23:39:40 -0800 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.35 #1) id 16plYR-00041R-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 23:39:39 -0800 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g2Q7dc816608 for ; Tue, 26 Mar 2002 08:39:38 +0100 (MET) Received: from trab.se ([131.115.48.20]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g2Q7dbk16600 for ; Tue, 26 Mar 2002 08:39:37 +0100 (MET) Message-ID: <3CA025B9.B329C70A@trab.se> Date: Tue, 26 Mar 2002 08:39:37 +0100 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] URL encoding in html page Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: >> As an implementor of a web server, how do I know how to interpret the >> "host:" field in the HTTP header? If I see something that looks like >> ACE, I suppose I would need to decode it to the original UTF-8 to >> compare with my virtual domain definitions. > >No, you wouldn't. If you don't know anything about IDNs, then in your >mind all host names are ASCII, so you would do an ASCII comparison >between the Host: field (which is ASCII) and your virtual domain >definitions (which are also ASCII), and that would work just fine. This is only in the mind of a IETF hacker. In the mind of the common man, a host name is a name composed of letters, digits and some more characters. Any letters, not just English letters. The limitation to English letters is an artificial limit and accepted by common man. When entering host names, it does not matter where, common man will use native character set using any letters used in native language. The same applies to URLs or URIs. The can contain any letter. Today lots of people use non-ASCII letters in URLs, embedd them in links in HTML, enter them in browsers. Quite often they work as expected. Common man cannot understand why IETF does not take the easy route and change its artficial and incomprehensible limits in character allowed. Just update the current RFC to allow any character outside the ASCII range. It time everybody face the facts: if you define an RFC restricting things to ASCII where is is natural to allow any letter, people will ignore the RFC and use any letter anyway. There is so much talk about backward compatibility - but you only think about ASCII. There is a lot of inofficial use of non-ASCII in URLs, host names and other places. We must support them also. Dan From owner-idn@ops.ietf.org Tue Mar 26 02:58:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26885 for ; Tue, 26 Mar 2002 02:58:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16plgC-0004Bj-00 for idn-data@psg.com; Mon, 25 Mar 2002 23:47:40 -0800 Received: from mail.telia.se ([131.115.15.18] helo=mailc.telia.se) by psg.com with esmtp (Exim 3.35 #1) id 16plgC-0004Bd-00 for idn@ops.ietf.org; Mon, 25 Mar 2002 23:47:40 -0800 Received: from mailc.telia.se (localhost [127.0.0.1]) by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g2Q7lcG26548 for ; Tue, 26 Mar 2002 08:47:38 +0100 (MET) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g2Q7lbR26544 for ; Tue, 26 Mar 2002 08:47:37 +0100 (MET) Message-ID: <3CA02799.9D38246C@trab.se> Date: Tue, 26 Mar 2002 08:47:37 +0100 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] UCS/UTF-8 is needed for interoperability Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There have been much talk about UTF-8 as the solution with mind set on the client. But the most important thing is that if we are going to make it easy to interoperate between systems we must agree on the format of data in the protocols. Today it is a mess filled with lots of formats. Just look at e-mail and MIME - just the code needed to decode or encode a e-mail header is big and complex. That is why it is so difficult to make programs use e-mail. Think how easy it would have been if all header lines had used UTF-8! We need ONE format for character data. UCS encoded as UTF-8 normalised form C is the best choice. Locally in a system you will still use a local character set. But think how easy the code will be: - One library to handle the conversion between UCS and local charcter set that can be used by all programs. - Much simplified parsing, no embedded character set switches. Dan From owner-idn@ops.ietf.org Tue Mar 26 05:21:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28512 for ; Tue, 26 Mar 2002 05:21:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pnwl-0006kS-00 for idn-data@psg.com; Tue, 26 Mar 2002 02:12:55 -0800 Received: from [140.115.17.111] (helo=dove.cc.ncu.edu.tw) by psg.com with esmtp (Exim 3.35 #1) id 16pnwk-0006jb-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 02:12:54 -0800 Received: from LocalHost ([140.115.67.77]) (authenticated tsenglm (0 bits)) by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g2QACIU06671 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 26 Mar 2002 18:12:21 +0800 (CST) Message-ID: <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> From: =?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= To: , References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> Subject: Re: [idn] Web navigation for IDN resolving Date: Tue, 26 Mar 2002 18:09:33 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Yves Arrouye: Thanks your descriptions. I think this message from Mr. YangWoo Ko (newcat@spsoft.co.kr) is the key point: I am still wondering what "looks like a domain name" means > > The DNS lookup happened *before* the string was URL-encoded and passed to > Autosearch, which only happen after a failure. The ASCII Domain Name (even without dot) will be put to do DNS lookup first, but IDN domain name will not . The IDN will be intercepted to auto.search.msn.com directly without doing DNS lookup. That means the IDN input with native coded string without http:// protocol head will be interpreted as "not a legal domain name" by IE. The server of Realname can not found these IDN in non contract supporting, so it is an error for Realname or IDN resolving, but the return error cause the halting of browser will disturb the further regular processing of these UTF-8 IDN. That is my understanding of these strange processing to IDN . L.M.Tseng From owner-idn@ops.ietf.org Tue Mar 26 07:16:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29519 for ; Tue, 26 Mar 2002 07:16:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ppiR-0008Zo-00 for idn-data@psg.com; Tue, 26 Mar 2002 04:06:15 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.35 #1) id 16ppiQ-0008Zi-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 04:06:14 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2QC4tA31055; Tue, 26 Mar 2002 21:04:59 +0900 Message-ID: <07cf01c1d4be$4886c0b0$2b19fea9@temp> From: "Soobok Lee" To: "Dan Oscarsson" , References: <3CA02799.9D38246C@trab.se> Subject: Re: [idn] UCS/UTF-8 is needed for interoperability Date: Tue, 26 Mar 2002 21:03:42 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dan Oscarsson" > We need ONE format for character data. I agree. Legacy coded identifiers cannot ensure stable IDN operations. >UCS encoded as UTF-8 normalised > form C is the best choice. I take very conservative position from this point. NFC is not mature. I have long lists of NFC corrections to be made. only new normalization can solve it. "new bag for new wine". If we think UTF8 solutions as long terms solutions, there is no reason why we stick with old NFC. Moreover, we should sync IDN standardization with additions of all *MODERN* scripts which should also be debugged and stabilized. after that, we could freeze the unicode version for IDN. This may be bad news for some commercial driving forces of IDN, because that means the lucrative IDN (+solutions) market is still far from them. > > Locally in a system you will still use a local character set. > But think how easy the code will be: > - One library to handle the conversion between UCS and local charcter > set The conversion to utf8 should be made on direct user inputs and should also give immediate/interactive responses regarding to any unsuccessful conversions if any. That is crucial for identifier security and stability. The DNS is the most crucial kernel component of the INTERNET *OPERATING SYSTEM*. That is why most paranoid and conservative criticisms of IDN efforts are always justified and welcomed. :-) Soobok Lee > that can be used by all programs. > - Much simplified parsing, no embedded character set switches. > > Dan From owner-idn@ops.ietf.org Tue Mar 26 10:08:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05469 for ; Tue, 26 Mar 2002 10:08:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16psNU-000BTu-00 for idn-data@psg.com; Tue, 26 Mar 2002 06:56:48 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.35 #1) id 16psNT-000BTo-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 06:56:47 -0800 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id GAA06400; Tue, 26 Mar 2002 06:55:43 -0800 Message-Id: <5.1.0.14.2.20020326064728.0376d268@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Mar 2002 06:48:53 -0800 To: Dan Oscarsson From: Dave Crocker Subject: Re: [idn] UCS/UTF-8 is needed for interoperability Cc: idn@ops.ietf.org In-Reply-To: <3CA02799.9D38246C@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 08:47 AM 3/26/2002 +0100, Dan Oscarsson wrote: >We need ONE format for character data. UCS encoded as UTF-8 normalised >form C >is the best choice. Since these sorts of discussions are outside the scope of this working group, they should move to a different discussion venue and so they can focus on formulating a working group with an appropriate charter. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Tue Mar 26 10:25:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06428 for ; Tue, 26 Mar 2002 10:25:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16psgx-000BtD-00 for idn-data@psg.com; Tue, 26 Mar 2002 07:16:55 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16psgx-000Bt6-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 07:16:55 -0800 Message-ID: <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> From: "Edmon Chung" To: "tsenglm@­pºô¤¤¤ß.¤¤¤j.tw" , , References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> Subject: Re: [idn] Web navigation for IDN resolving Date: Tue, 26 Mar 2002 10:18:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit This is a rather interesting and serious observation. Does it not therefore mean that RealNames/MS is effectively hijacking all IDN requests through an IE browser? ----- Original Message ----- From: "tsenglm@­pºô¤¤¤ß.¤¤¤j.tw" To: ; Sent: Tuesday, March 26, 2002 5:09 AM Subject: Re: [idn] Web navigation for IDN resolving > Dear Yves Arrouye: > Thanks your descriptions. I think this message from Mr. YangWoo > Ko (newcat@spsoft.co.kr) is the key point: > I am still wondering what "looks like a domain name" means > > > > > The DNS lookup happened *before* the string was URL-encoded and passed to > > Autosearch, which only happen after a failure. > The ASCII Domain Name (even without dot) will be put to do DNS > lookup first, but IDN domain name will not . The IDN will be intercepted to > auto.search.msn.com directly without doing DNS lookup. That means the IDN > input with native coded string without http:// protocol head will be > interpreted as "not a legal domain name" by IE. > The server of Realname can not found these IDN in non contract > supporting, so it is an error for Realname or IDN resolving, but the return > error cause the halting of browser will disturb the further regular > processing of these UTF-8 IDN. That is my understanding of these strange > processing to IDN . > > L.M.Tseng > > > From owner-idn@ops.ietf.org Tue Mar 26 10:45:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07400 for ; Tue, 26 Mar 2002 10:45:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pt16-000CN2-00 for idn-data@psg.com; Tue, 26 Mar 2002 07:37:44 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.35 #1) id 16pt15-000CMw-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 07:37:43 -0800 Received: from [192.168.31.8] (classic.viagenie.qc.ca [206.123.31.136]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g2QG29T99849 for ; Tue, 26 Mar 2002 11:02:09 -0500 (EST) Date: Tue, 26 Mar 2002 10:38:23 -0500 From: Marc Blanchet To: idn@ops.ietf.org Subject: [idn] iesg confirmation Message-ID: <352700000.1017157103@classic.viagenie.qc.ca> X-Mailer: Mulberry/2.2.0b4 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA07400 Hi, just to say that the IESG secretariat had confirmed that we are on the IESG list. http://www.ietf.org/IESG/request.html (search for idn and stringprep inside the page) Marc. ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-idn@ops.ietf.org Tue Mar 26 10:59:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08132 for ; Tue, 26 Mar 2002 10:59:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ptGG-000ClX-00 for idn-data@psg.com; Tue, 26 Mar 2002 07:53:24 -0800 Received: from lobo.nic.cc ([206.253.214.247] helo=mail.enic.cc) by psg.com with esmtp (Exim 3.35 #1) id 16ptGF-000ClR-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 07:53:23 -0800 Received: from algernon.lan.enic.cc (tailback [206.253.214.252]) by mail.enic.cc (Postfix) with ESMTP id 3A23B6A92A; Tue, 26 Mar 2002 07:53:23 -0800 (PST) Subject: Re: [idn] Web navigation for IDN resolving From: Dan Ebert To: Soobok Lee Cc: Bruce Thomson , IETF idn working group In-Reply-To: <04db01c1d474$f0b0d4a0$2b19fea9@temp> References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <032f01c1d461$6efac910$2b19fea9@temp> <04d001c1d46a$b273cd00$a303a8c0@bruce> <04db01c1d474$f0b0d4a0$2b19fea9@temp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 26 Mar 2002 07:53:26 -0800 Message-Id: <1017158006.1360.5.camel@algernon.lan.enic.cc> Mime-Version: 1.0 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If you prepend the http:// (i.e. "http://.cc") you can usually get past the "not found" error pages. I have found the sending behaviour to vary depending both on the version of Windows (98/2000 etc., and the language) and the version of the browser. I have also observed that the UTF-8 sent by IE is not always correct (but still looks like UTF-8). Dan Ebert. On Mon, 2002-03-25 at 19:18, Soobok Lee wrote: > > ----- Original Message ----- > From: "Bruce Thomson" > > > > With IE 6, I find that it's doing the DNS lookup in all three cases. > > > > I have not tested with Japanese or English version of MS IE 6.0. > I have only Korean MS IE 6.0 (version 6.0.2600.00), and find it does not try dns lookup for ".com" > and "..com" and just sends them into auto.search.msn.com. ( I had a debugging session with my name servers ). the > auto.search.msn.com/realnames receives those search queries and converts them > into ACE ones and answers with redirection requests for http://bq--???.mltbd.com. > > For other TLDs like ".cc", the search engine responds with "not found" error pages. > > > > -- Dan Ebert eNIC Corporation ---------------------------------------------------------- "Entropy isn't what it used to be." From owner-idn@ops.ietf.org Tue Mar 26 11:21:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09275 for ; Tue, 26 Mar 2002 11:21:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ptZx-000DDD-00 for idn-data@psg.com; Tue, 26 Mar 2002 08:13:45 -0800 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.35 #1) id 16ptZx-000DD7-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 08:13:45 -0800 Received: (qmail 18279 invoked by uid 104); 26 Mar 2002 16:13:44 -0000 Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.822179 secs); 26 Mar 2002 16:13:44 -0000 Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; 26 Mar 2002 16:13:43 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:3067]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <442067@heaven.internal.realnames.com> for ; Tue, 26 Mar 2002 8:08:18 AM -0800 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 08:13:05 -0800 Message-ID: <7FC3066C236FD511BC5900508BAC86FE9199E1@trestles.internal.realnames.com> From: Yves Arrouye To: "'Bruce Thomson'" , Soobok Lee , IETF idn working group Subject: RE: [idn] Web navigation for IDN resolving Date: Tue, 26 Mar 2002 08:09:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idn@ops.ietf.org Precedence: bulk > With IE 6, I find that it's doing the DNS lookup in all three cases. Yes it is (so was 5 IIRC). People who want the definitive answer should get a packet filter and look on the wire. That is the easiest way to be certain. YA From owner-idn@ops.ietf.org Tue Mar 26 11:37:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10305 for ; Tue, 26 Mar 2002 11:37:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pto5-000DYp-00 for idn-data@psg.com; Tue, 26 Mar 2002 08:28:21 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16pto4-000DYj-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 08:28:20 -0800 Message-ID: <000d01c1d4e3$69b72700$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Edmon Chung" , =?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= , , References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> Subject: Re: [idn] Web navigation for IDN resolving Date: Tue, 26 Mar 2002 11:29:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit From our testing results, we found out the same thing too... and worst of all the new IE6 will DROP all IDN that is not within the locale set in the regional setting of the OS. i.e. if you set the locale to Japanese, ONLY characters contain in the Japanese range will work and all the others will be DROPPED, try setting the regional settings to say Korean or some other locale and if you have "Chinese".tw the new IE will only sent .tw!! We have try to replace the url.dll and urlmon.dll with the previous IE5 dlls and it works again, we have pinpoint the functions inside these dlls and send a bug fix report to MS but they still have not fix it yet... I think this will prohibit the expand of IDN in China and Taiwan. David Leung Chief Technology Officer Neteka Inc. T: (416) 971-4302 http://w!.neteka.com ----- Original Message ----- From: "Edmon Chung" To: "tsenglm@­pºô¤¤¤ß.¤¤¤j.tw" ; ; Sent: Tuesday, March 26, 2002 10:18 AM Subject: Re: [idn] Web navigation for IDN resolving > This is a rather interesting and serious observation. Does it not therefore > mean that RealNames/MS is effectively hijacking all IDN requests through an > IE browser? > > ----- Original Message ----- > From: "tsenglm@­pºô¤¤¤ß.¤¤¤j.tw" > To: ; > Sent: Tuesday, March 26, 2002 5:09 AM > Subject: Re: [idn] Web navigation for IDN resolving > > > > Dear Yves Arrouye: > > Thanks your descriptions. I think this message from Mr. > YangWoo > > Ko (newcat@spsoft.co.kr) is the key point: > > I am still wondering what "looks like a domain name" means > > > > > > > > The DNS lookup happened *before* the string was URL-encoded and passed > to > > > Autosearch, which only happen after a failure. > > The ASCII Domain Name (even without dot) will be put to do DNS > > lookup first, but IDN domain name will not . The IDN will be intercepted > to > > auto.search.msn.com directly without doing DNS lookup. That means the > IDN > > input with native coded string without http:// protocol head will be > > interpreted as "not a legal domain name" by IE. > > The server of Realname can not found these IDN in non contract > > supporting, so it is an error for Realname or IDN resolving, but the > return > > error cause the halting of browser will disturb the further regular > > processing of these UTF-8 IDN. That is my understanding of these strange > > processing to IDN . > > > > L.M.Tseng > > > > > > > > From owner-idn@ops.ietf.org Tue Mar 26 11:46:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11074 for ; Tue, 26 Mar 2002 11:46:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ptwf-000Dm0-00 for idn-data@psg.com; Tue, 26 Mar 2002 08:37:13 -0800 Received: from smtp12.singnet.com.sg ([165.21.6.32]) by psg.com with esmtp (Exim 3.35 #1) id 16ptwe-000Dl9-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 08:37:12 -0800 Received: from jamescompaq (bb-165-21-94-32.singnet.com.sg [165.21.94.32]) by smtp12.singnet.com.sg (8.12.2/8.12.2) with SMTP id g2QGaYZs010002; Wed, 27 Mar 2002 00:36:34 +0800 Message-ID: <004901c1d4e2$23605de0$0701000a@jamescompaq> From: "James Seng/Personal" To: "Edmon Chung" , =?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= , , References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> Subject: Re: [idn] Web navigation for IDN resolving Date: Wed, 27 Mar 2002 00:20:25 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit While it is an interesting observation, the discussion of (right or wrong) behavior of specific commerical/non-commerical software are better done outside this wg. The discussion of the how URL is to be encoded and how Host: field are to be handled is probably more relevant so lets get back to that. -James Seng ----- Original Message ----- From: "Edmon Chung" To: "tsenglm@­pºô¤¤¤ß.¤¤¤j.tw" ; ; Sent: Tuesday, March 26, 2002 11:18 PM Subject: Re: [idn] Web navigation for IDN resolving > This is a rather interesting and serious observation. Does it not therefore > mean that RealNames/MS is effectively hijacking all IDN requests through an > IE browser? > > ----- Original Message ----- > From: "tsenglm@­pºô¤¤¤ß.¤¤¤j.tw" > To: ; > Sent: Tuesday, March 26, 2002 5:09 AM > Subject: Re: [idn] Web navigation for IDN resolving > > > > Dear Yves Arrouye: > > Thanks your descriptions. I think this message from Mr. > YangWoo > > Ko (newcat@spsoft.co.kr) is the key point: > > I am still wondering what "looks like a domain name" means > > > > > > > > The DNS lookup happened *before* the string was URL-encoded and passed > to > > > Autosearch, which only happen after a failure. > > The ASCII Domain Name (even without dot) will be put to do DNS > > lookup first, but IDN domain name will not . The IDN will be intercepted > to > > auto.search.msn.com directly without doing DNS lookup. That means the > IDN > > input with native coded string without http:// protocol head will be > > interpreted as "not a legal domain name" by IE. > > The server of Realname can not found these IDN in non contract > > supporting, so it is an error for Realname or IDN resolving, but the > return > > error cause the halting of browser will disturb the further regular > > processing of these UTF-8 IDN. That is my understanding of these strange > > processing to IDN . > > > > L.M.Tseng > > > > > > > > > From owner-idn@ops.ietf.org Tue Mar 26 11:47:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11324 for ; Tue, 26 Mar 2002 11:47:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ptwP-000Dl1-00 for idn-data@psg.com; Tue, 26 Mar 2002 08:36:57 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16ptwO-000Dkv-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 08:36:56 -0800 Message-ID: <001301c1d4e4$52dde3b0$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Dan Oscarsson" , References: <3CA02799.9D38246C@trab.se> Subject: Re: [idn] UCS/UTF-8 is needed for interoperability Date: Tue, 26 Mar 2002 11:36:04 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > There have been much talk about UTF-8 as the solution with mind > set on the client. > > But the most important thing is that if we are going to make > it easy to interoperate between systems we must agree on the > format of data in the protocols. > Today it is a mess filled with lots of formats. Just look at > e-mail and MIME - just the code needed to decode or encode > a e-mail header is big and complex. That is why it is so difficult > to make programs use e-mail. Think how easy it would have been > if all header lines had used UTF-8! I agree with that. We can use EDNS or something similar to denote that it is UTF8 : ) > We need ONE format for character data. UCS encoded as UTF-8 normalised > form C > is the best choice. > > Locally in a system you will still use a local character set. > But think how easy the code will be: > - One library to handle the conversion between UCS and local charcter > set > that can be used by all programs. > - Much simplified parsing, no embedded character set switches. Or we can even have ACE in zone file and the DNS generate the UTF8 in memory... David Leung Chief Technology Officer Neteka Inc. T: (416) 971-4302 http://w!.neteka.com From owner-idn@ops.ietf.org Tue Mar 26 11:52:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11663 for ; Tue, 26 Mar 2002 11:52:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pu3E-000Dxs-00 for idn-data@psg.com; Tue, 26 Mar 2002 08:44:00 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16pu3D-000Dxm-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 08:43:59 -0800 Message-ID: <001901c1d4e5$51725050$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Dan Oscarsson" , References: <3CA025B9.B329C70A@trab.se> Subject: Re: [idn] URL encoding in html page Date: Tue, 26 Mar 2002 11:43:11 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >> As an implementor of a web server, how do I know how to interpret the > >> "host:" field in the HTTP header? If I see something that looks like > >> ACE, I suppose I would need to decode it to the original UTF-8 to > >> compare with my virtual domain definitions. > > > >No, you wouldn't. If you don't know anything about IDNs, then in your > >mind all host names are ASCII, so you would do an ASCII comparison > >between the Host: field (which is ASCII) and your virtual domain > >definitions (which are also ASCII), and that would work just fine. > > This is only in the mind of a IETF hacker. Totally agree!! If we use ACE as the URL links then all web designers in the world needs to be retrained for ACE conversion... school has to start offering a course on ACE compression and decompress in their Comp Sci or Engineering program : )) > In the mind of the common man, a host name is a name composed of > letters, digits and some more characters. Any letters, not just English > letters. > The limitation to English letters is an artificial limit and accepted by > common man. When entering host names, it does not matter where, common > man > will use native character set using any letters used in native language. > > The same applies to URLs or URIs. The can contain any letter. Today > lots of people use non-ASCII letters in URLs, embedd them in links in > HTML, > enter them in browsers. Quite often they work as expected. > Common man cannot understand why IETF does not take the easy route and > change its artficial and incomprehensible limits in character allowed. > Just update the current RFC to allow any character outside the ASCII > range. RFC should be updated according to new things, so if they said RFC doesn't allow URL/URI with non-ascii, so how about IPv6 back before IPv6 came out, I dont think URL/URI link can allow IPv6 representation as well... > It time everybody face the facts: if you define an RFC restricting > things to ASCII where is is natural to allow any letter, people will ignore the > RFC and use any letter anyway. There is so much talk about backward > compatibility - but you only think about ASCII. There is a lot of > inofficial use of non-ASCII in URLs, host names and other places. > We must support them also. As far as i know a lot of Chinese, Japanese or Korean websites are using CJK in their URI for directories... If you look at big5.com, they have been offering Chinese URI in the directory level for a long time! David Leung Chief Technology Officer Neteka Inc. T: (416) 971-4302 http://w!.neteka.com From owner-idn@ops.ietf.org Tue Mar 26 12:58:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16350 for ; Tue, 26 Mar 2002 12:58:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pusX-000FEl-00 for idn-data@psg.com; Tue, 26 Mar 2002 09:37:01 -0800 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.35 #1) id 16pusW-000FEf-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 09:37:01 -0800 Received: (qmail 24963 invoked by uid 104); 26 Mar 2002 17:37:00 -0000 Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.824705 secs); 26 Mar 2002 17:37:00 -0000 Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; 26 Mar 2002 17:36:59 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:2468]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <442637@heaven.internal.realnames.com> for ; Tue, 26 Mar 2002 9:32:03 AM -0800 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 09:36:50 -0800 Message-ID: <7FC3066C236FD511BC5900508BAC86FE9199E5@trestles.internal.realnames.com> From: Yves Arrouye To: "'tsenglm@????.??.tw'" , idn@ops.ietf.org Subject: RE: [idn] Web navigation for IDN resolving Date: Tue, 26 Mar 2002 09:33:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idn@ops.ietf.org Precedence: bulk [Please stop Cc:ing my hotmail address. Replying to this email should be enough for that; if replying to other messages, please check the To: header. Thanks.] > Ko (newcat@spsoft.co.kr) is the key point: > I am still wondering what "looks like a domain name" means Something like "has a period and no space." YA From owner-idn@ops.ietf.org Tue Mar 26 19:01:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00579 for ; Tue, 26 Mar 2002 19:01:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16q0Xs-000Lcx-00 for idn-data@psg.com; Tue, 26 Mar 2002 15:40:04 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16q0Xr-000Lcm-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 15:40:03 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16q0Xq-0004ME-00 for ; Tue, 26 Mar 2002 15:40:02 -0800 Date: Tue, 26 Mar 2002 23:40:02 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] URL encoding in html page Message-ID: <20020326234002.GB15408@nicemice.net> Reply-To: IETF idn working group References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001901c1d4e5$51725050$0301a8c0@davidvaio> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk "David Leung (Neteka Inc.)" wrote: > If we use ACE as the URL links then all web designers in the world > needs to be retrained for ACE conversion. Either the web designer uses an HTML editor, in which case the editor should know the HTML syntax rules and convert to/from the local charset as needed, or the web designer uses a text editor, in which case the web designer is taking responsibility for knowing and obeying the HTML/URI syntax rules, one of which is that href and src attributes contain only ASCII characters. Maybe future HTML/URI specs will allow non-ASCII characters in href and src attributes, but it's not obvious how to do that without breaking deployed browsers, and that discussion is for another forum. AMC From owner-idn@ops.ietf.org Tue Mar 26 19:14:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00856 for ; Tue, 26 Mar 2002 19:14:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16q0pa-000Lun-00 for idn-data@psg.com; Tue, 26 Mar 2002 15:58:22 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16q0pZ-000Luh-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 15:58:21 -0800 Message-ID: <013f01c1d522$858a1cf0$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> Subject: Re: [idn] URL encoding in html page Date: Tue, 26 Mar 2002 19:01:17 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > "David Leung (Neteka Inc.)" wrote: > > > If we use ACE as the URL links then all web designers in the world > > needs to be retrained for ACE conversion. > > Either the web designer uses an HTML editor, in which case the editor > should know the HTML syntax rules and convert to/from the local charset > as needed, or the web designer uses a text editor, in which case the web > designer is taking responsibility for knowing and obeying the HTML/URI > syntax rules, one of which is that href and src attributes contain only > ASCII characters. So now IDN is a larger scope than we expected, not just browser software needs to upgrade, even html editor like Dreamweaver, etc needs to upgrade... interesting idea... I am wondering how many companys will be affected by this if even HTML editors or text editors need to upgrade, and what about if they are using an editor and really wants to but something like "bq--xxxx" on the page, should the editor shows the local encoding on the interface and keep the ACE in the backend or people are not able to put anything that looks like an ACE domain on homepage anymore... > Maybe future HTML/URI specs will allow non-ASCII characters in href and > src attributes, but it's not obvious how to do that without breaking > deployed browsers, and that discussion is for another forum. I guess this is simiilar to say that if some one put a IPv6 link on the page and will break some browsers that follows old specs, upgrading an RFC document so that URI can contains non-ASCII is not that hard of a thing... Hmm... also I am still wondering what kind of variable definition will treat 7bits and 8bits differently and will cause a overflow... : ) From owner-idn@ops.ietf.org Tue Mar 26 20:09:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01949 for ; Tue, 26 Mar 2002 20:09:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16q1ka-000Mu7-00 for idn-data@psg.com; Tue, 26 Mar 2002 16:57:16 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16q1kZ-000Mu1-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 16:57:15 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16q1kZ-0004a4-00 for ; Tue, 26 Mar 2002 16:57:15 -0800 Date: Wed, 27 Mar 2002 00:57:15 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] URL encoding in html page Message-ID: <20020327005714.GC15408@nicemice.net> Reply-To: IETF idn working group References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013f01c1d522$858a1cf0$0301a8c0@davidvaio> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk "David Leung (Neteka Inc.)" wrote: > So now IDN is a larger scope than we expected, not just browser > software needs to upgrade, even html editor like Dreamweaver, etc > needs to upgrade... It should not be surprising that any software that deals with domain names as such (as opposed to text in general) might need to be upgraded in order to allow characters in domain names that used to be forbidden. > I am wondering how many companys will be affected by this if even HTML > editors or text editors need to upgrade, HTML editors need to upgrade if they want to fully support IDNs. Text editors don't, because they don't deal with domain names as such, they just deal with text. > and what about if they are using an editor and really wants to put > something like "bq--xxxx" on the page, should the editor show the > local encoding on the interface and keep the ACE in the backend or > people are not able to put anything that looks like an ACE domain on > homepage anymore... An HTML editor knows HTML syntax, so it knows the difference between the host field of a URI in the src attribute of an IMG tag, versus text in the content of a P element. The former is subject to strict syntax rules because it's a protocol element, while the latter is just text, regardless of whether it happens to contain substrings that look like domain names. AMC From owner-idn@ops.ietf.org Tue Mar 26 22:39:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06400 for ; Tue, 26 Mar 2002 22:39:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16q49N-000PQZ-00 for idn-data@psg.com; Tue, 26 Mar 2002 19:31:01 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16q49M-000PQT-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 19:31:00 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16q49L-0004ue-00 for ; Tue, 26 Mar 2002 19:30:59 -0800 Date: Wed, 27 Mar 2002 03:30:59 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: [idn] IRIs ought to use internationalized *host* names Message-ID: <20020327033059.GA18099@nicemice.net> Reply-To: IETF idn working group References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004901c1d4e2$23605de0$0701000a@jamescompaq> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk James Seng/Personal wrote: > The discussion of the how URL is to be encoded and how Host: field are > to be handled is probably more relevant so lets get back to that. Okay. Eventually this message will arrive at the following proposal: Proposed repertoire for internationalized *host* labels: All characters in classes L (letter), M (mark), and N (number) are allowed, and U+002D (hyphen-minus) is also allowed. Everything else is forbidden. The IRI proposal (draft-masinter-url-i18n-08) calls for the host labels to be ASCII LDH only, just like in URIs. When converting an IRI to a URI, you have to convert the path components from the local charset to Unicode, then do Unicode normalization, UTF-8 encoding, and %-escaping. But you don't do anything to the host labels because they're already LDH. I suspect that the reason the IRI proponents don't internationalize the host field is that they don't yet have an official IDN spec to point at. When they do, I suspect they'll want to revise their proposal so that the host field can use the local charset. This raises the question of what characters should be allowed in host labels. Since URIs do not allow arbitrary ASCII labels, only host labels restricted to LDH characters, one would expect, analogously, that IRIs would not allow arbitrary IDNs containing the exotic symbols and punctuation allowed by Nameprep, but would allow only host labels restricted to a selected set of characters, Which characters should be allowed in internationalized host labels? This is an interesting question in its own right, and it's possible that the IESG will demand an answer. The Unicode character database classifies each character as belonging to exactly one of the following broad classes: L: letter M: mark N: number P: punctuation S: symbol Z: separator C: other We can start by examining which of these classes of ASCII characters are allowed in ASCII host labels. L: 52 exist, all are allowed M: 0 exist N: 10 exist, all are allowed P: 23 exist, only hyphen-minus is allowed S: 9 exist, none are allowed Z: 1 exists, it is not allowed C: 33 exist, none are allowed We can trivially extend these results to form a simple rule covering the entire Unicode repertoire, except that we have no precedent for class M. Since characters in class M tend to be things like diacritics, they should be allowed. So the proposed rule is: All characters in classes L (letter), M (mark), and N (number) are allowed, and U+002D (hyphen-minus) is also allowed. Everything else is forbidden. Notice that there is no conflict with Nameprep, because Nameprep does not prohibit any characters in classes L, M, or N. If we were to adopt this definition of internationalized host name, it would best be understood as an amendment of ToASCII step 3 (which checks host name restrictions if applicable), tightening substep 3a from: (a) Verify the absence of non-LDH ASCII code points; that is, the absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. to: (a) Verify that the sequence contains only host code points; that is, U+002D (hyphen-minus) and code points classified as L (letter), M (mark), or N (number). See appendix ? for an enumeration of host code points. Or maybe the enumeration would go in Nameprep, or in a separate document that defines internationalized host names. Getting back to IRIs and URIs: I propose that conversion of an IRI to URI involve applying ToASCII to each host label. This would allow conversion of any IRI to a URI without changing the syntax of URIs. In contrast, the method proposed in draft-ietf-idn-uri-01 would change the URI syntax. AMC From owner-idn@ops.ietf.org Wed Mar 27 03:02:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18705 for ; Wed, 27 Mar 2002 03:02:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16q8A1-0003Jw-00 for idn-data@psg.com; Tue, 26 Mar 2002 23:47:57 -0800 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.35 #1) id 16q8A0-0003Jq-00 for idn@ops.ietf.org; Tue, 26 Mar 2002 23:47:56 -0800 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g2R7lss28017 for ; Wed, 27 Mar 2002 08:47:54 +0100 (MET) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g2R7lsN28013 for ; Wed, 27 Mar 2002 08:47:54 +0100 (MET) Message-ID: <3CA17929.72D92BD0@trab.se> Date: Wed, 27 Mar 2002 08:47:53 +0100 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] URL encoding in html page Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >From: "Adam M. Costello" Adam M. Costello wrote: >> So now IDN is a larger scope than we expected, not just browser >> software needs to upgrade, even html editor like Dreamweaver, etc >> needs to upgrade... > >It should not be surprising that any software that deals with domain >names as such (as opposed to text in general) might need to be upgraded >in order to allow characters in domain names that used to be forbidden. It is the IETF hacker talking again. The common man do not think non-ASCII letters are forbidden. In general you can all expect when soon non-ASCII domain names are officially allowed, there will be lots of places where people will enter names using non-ASCII. They will expect them to be allowed in HTML documents in href field and in img src field. It does not matter that some have decided to restrict the definition of "URL" to ASCII, people will and already do, expect non-ASCII to be allowed in both host and path part of URL, in native character set without ACE or %-encoding!! Especially as it works in many places already today. It is important that existing RFCs like the one for the URL, imediately be updated to allow non-ASCII letters. And do not use the IETF hacker language and call it IRI, for the common man it will be a URL and URI. People will not ACE encode host names in URLs, people will not %-encode paths in URLs. They will do like they do today: use native character set of the HTML document. Ignoring reality does not work. Dan From owner-idn@ops.ietf.org Wed Mar 27 03:32:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19092 for ; Wed, 27 Mar 2002 03:32:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16q8lz-00047Q-00 for idn-data@psg.com; Wed, 27 Mar 2002 00:27:11 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16q8ly-00047C-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 00:27:10 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 81B59FFC06 for ; Wed, 27 Mar 2002 16:25:19 +0800 (SGT) Message-ID: <072101c1d568$f6e8ede0$dd00a8c0@jamessonyviao> From: "James Seng" To: "IETF idn working group" References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> <20020327033059.GA18099@nicemice.net> Subject: Re: [idn] IRIs ought to use internationalized *host* names Date: Wed, 27 Mar 2002 16:25:28 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Okay. Eventually this message will arrive at the following proposal: > > Proposed repertoire for internationalized *host* labels: All > characters in classes L (letter), M (mark), and N (number) are > allowed, and U+002D (hyphen-minus) is also allowed. Everything else > is forbidden. Hmm, the last discussion on this topic of hostname have been summaried by Eric Hall - http://www.imc.org/idn/mail-archive/msg05182.html If we want to go near this slippery slope, lets start from there. > When converting an IRI to a URI, you have to convert the path components > from the local charset to Unicode, then do Unicode normalization, UTF-8 > encoding, and %-escaping. But you don't do anything to the host labels > because they're already LDH. Correct. But I think IRI could be NFC-UTF-8, %-escaped even for host labels. This is consistent with the CharMod of HTML. When IRI is used and that applications have to look up the host names, then it can apply Nameprep-Punycode before it hits the stub resolver. To be more precies, lets look how browser can implementation IRI with IDNA. - On the IRL bar -> IRL are likely to be in font encoding. Which font encoding would depend on the OS capability to render the font, ranging from locale to UTF-8. (This is why the confusing behavior of some browsers) - Internally, the applications would process IRL in NFC-%-escape-UTF-8. - For DNS resolution, host name would be extract from IRL in NFC-%-escape-UTF-8 which will be converted to Nameprep-Punycode before doing gethostbyname() The two issues I could see would be: 1. For proxy look up, does the browser send IRI in NFC-%-escape-UTF-8? Or should it send out as NFC-%-escape-UTF-8 except hostname in Nameprep-Punycode? Or just UTF-8? 2. For "Host:" field in HTTP negiotation, does it send "Host:" in Nameprep-Punycode or does it send in NFC-%-escape-UTF-8? Or just UTF-8? I believe for backward compatibility, browser sending both in Nameprep-Punycode and not NFC-%-escape-UTF-8. Am I going off tangent here? > Which characters should be allowed in internationalized host labels? > This is an interesting question in its own right, and it's possible that > the IESG will demand an answer. My believe is what is allowed in host labels is a topic for the zone administrator to decide. .CN have a different set compared to .SG compared to .COM compared to say IBM.COM. Each zone administrator have to decide what to allow and what not to allowed. > Getting back to IRIs and URIs: I propose that conversion of an IRI > to URI involve applying ToASCII to each host label. This would allow > conversion of any IRI to a URI without changing the syntax of URIs. In > contrast, the method proposed in draft-ietf-idn-uri-01 would change the > URI syntax. I like this idea. If this is done (i.e. IRI goes thru ToASCII for host label), then we basically saying for proxy and Host:, you should start from URI not IRI. -James Seng From owner-idn@ops.ietf.org Wed Mar 27 04:05:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19952 for ; Wed, 27 Mar 2002 04:05:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16q9Hc-0004bs-00 for idn-data@psg.com; Wed, 27 Mar 2002 00:59:52 -0800 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.35 #1) id 16q9Hb-0004ba-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 00:59:51 -0800 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g2R8xns25513 for ; Wed, 27 Mar 2002 09:59:49 +0100 (MET) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g2R8xnN25509; Wed, 27 Mar 2002 09:59:49 +0100 (MET) Message-ID: <3CA18A05.561C49B1@trab.se> Date: Wed, 27 Mar 2002 09:59:49 +0100 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org, jseng@pobox.org.sg Subject: Re: [idn] IRIs ought to use internationalized *host* names Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >> Getting back to IRIs and URIs: I propose that conversion of an IRI >> to URI involve applying ToASCII to each host label. This would allow >> conversion of any IRI to a URI without changing the syntax of URIs. In >> contrast, the method proposed in draft-ietf-idn-uri-01 would change the >> URI syntax. > >I like this idea. > >If this is done (i.e. IRI goes thru ToASCII for host label), then we >basically saying for proxy and Host:, you should start from URI not IRI. > All fields should use an URI with all characters encoded using UTF-8. No ToASCII, no %-encoding. Pure UTF-8. Web servers have to update their software so it can handle that instead of updating them to handle ACE and %-encoded values. Why make it more complex than needed? Dan From owner-idn@ops.ietf.org Wed Mar 27 04:20:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20145 for ; Wed, 27 Mar 2002 04:20:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16q9Vf-0004rX-00 for idn-data@psg.com; Wed, 27 Mar 2002 01:14:23 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16q9Vd-0004qt-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 01:14:22 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 7E014FFC06; Wed, 27 Mar 2002 17:12:31 +0800 (SGT) Message-ID: <076601c1d56f$8ed7d480$dd00a8c0@jamessonyviao> From: "James Seng" To: "Dan Oscarsson" , References: <3CA18A05.561C49B1@trab.se> Subject: Re: [idn] IRIs ought to use internationalized *host* names Date: Wed, 27 Mar 2002 17:12:39 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit URI, according to RFC2396, is already %-escape encoded. If you just want UTF-8 no escaping, then you are either (a) not talking about URI or (b) trying to change URI definition. Personally, I prefer (a). I would love to see a IRI which is NFC-UTF-8 only without %-escaping. URI can do ToASCII & %-escaping for backward compatibility if they wish. -James Seng ----- Original Message ----- From: "Dan Oscarsson" To: ; Sent: Wednesday, March 27, 2002 4:59 PM Subject: Re: [idn] IRIs ought to use internationalized *host* names > > > > >> Getting back to IRIs and URIs: I propose that conversion of an IRI > >> to URI involve applying ToASCII to each host label. This would allow > >> conversion of any IRI to a URI without changing the syntax of URIs. In > >> contrast, the method proposed in draft-ietf-idn-uri-01 would change the > >> URI syntax. > > > >I like this idea. > > > >If this is done (i.e. IRI goes thru ToASCII for host label), then we > >basically saying for proxy and Host:, you should start from URI not IRI. > > > > All fields should use an URI with all characters encoded using UTF-8. > No ToASCII, no %-encoding. Pure UTF-8. Web servers have to update their > software > so it can handle that instead of updating them to handle ACE and > %-encoded values. > Why make it more complex than needed? > > Dan > From owner-idn@ops.ietf.org Wed Mar 27 04:35:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20476 for ; Wed, 27 Mar 2002 04:35:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16q9jp-00056j-00 for idn-data@psg.com; Wed, 27 Mar 2002 01:29:01 -0800 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.35 #1) id 16q9jo-00056Y-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 01:29:00 -0800 Received: by rap.rap.dk (Postfix, from userid 500) id 5D45A2DDF; Wed, 27 Mar 2002 10:28:59 +0100 (CET) Date: Wed, 27 Mar 2002 10:28:59 +0100 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: IETF idn working group Subject: Re: [idn] IRIs ought to use internationalized *host* names Message-ID: <20020327092859.GA7784@rap.rap.dk> References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> <20020327033059.GA18099@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020327033059.GA18099@nicemice.net> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk On Wed, Mar 27, 2002 at 03:30:59AM +0000, Adam M. Costello wrote: > James Seng/Personal wrote: > > Which characters should be allowed in internationalized host labels? > This is an interesting question in its own right, and it's possible that > the IESG will demand an answer. That is indeed a good question. The same question has been put forward for programming languages that can use full ISO 10646 (Unicode) in their variable names, and ISO has developed a list of characters that then are recommended for use in identifiers. This generally consist of letters, digits and characters that can be used in normal words in any language of the world. The specification is available in annex A of ISO/IEC TR 10176. Leading Unicode people participated in creating this list, which is freely available. Get it via http://www.dkuug.dk/jtc1/sc22/wg20 Kind regards Keld From owner-idn@ops.ietf.org Wed Mar 27 08:42:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27431 for ; Wed, 27 Mar 2002 08:42:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qDUg-0008wu-00 for idn-data@psg.com; Wed, 27 Mar 2002 05:29:38 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qDUg-0008wn-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 05:29:38 -0800 Message-ID: <017601c1d593$bfabca20$6501a8c0@EDMON15> From: "Edmon Chung" To: "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> Subject: Re: [idn] URL encoding in html page Date: Wed, 27 Mar 2002 08:31:47 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Adam M. Costello" > "David Leung (Neteka Inc.)" wrote: > > So now IDN is a larger scope than we expected, not just browser > > software needs to upgrade, even html editor like Dreamweaver, etc > > needs to upgrade... > > It should not be surprising that any software that deals with domain > names as such (as opposed to text in general) might need to be upgraded > in order to allow characters in domain names that used to be forbidden. > (the keyword in this extract is "ANY". ANY software that deal with domain names in a "human friendly form" will need to be upgraded. That means almost all applications that use domain names isnt it? cause domain names were supposedly devised to be a "human friendly" name) This is a revealing point you have pointed out Adam. While you and some ACE "everywhere" advocates maintain that ACE "everywhere" requires the least upgrade, this seems to jump back out at yourselves that afterall, it is not as small a job as it was advertised. This and that together, if we are going to need an overhaul what is the point of going back to ASCII and not move forward to a more advanced schema? Edmon From owner-idn@ops.ietf.org Wed Mar 27 10:06:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01533 for ; Wed, 27 Mar 2002 10:06:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qEtA-000AXB-00 for idn-data@psg.com; Wed, 27 Mar 2002 06:59:00 -0800 Received: from pheidippides.md.chalmers.se ([129.16.237.91]) by psg.com with esmtp (Exim 3.35 #1) id 16qEt9-000AX5-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 06:58:59 -0800 Received: from chalmers95a69n (dhcp226-180.cs.chalmers.se [129.16.226.180]) by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g2REwuh10198 for ; Wed, 27 Mar 2002 15:58:56 +0100 (MET) From: "Kent Karlsson" To: "'IETF idn working group'" Subject: RE: [idn] IRIs ought to use internationalized *host* names Date: Wed, 27 Mar 2002 15:54:05 +0100 Message-ID: <000601c1d59f$3ee66f10$b4e21081@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: <20020327092859.GA7784@rap.rap.dk> Importance: Normal Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-idn@ops.ietf.org > [mailto:owner-idn@ops.ietf.org]On Behalf Of > Keld Jørn Simonsen ... > that then are recommended for use in identifiers. This generally > consist of letters, digits and characters that can be used in > normal words in any language of the world. I guess you mean 'orthographies of any language'... But even so, that is not quite true, since that annex only aims for what 10646 calls "level 2" (some combining characters are not included), not "level 3" (any combining characters are allowed). So, e.g. Lithuanian, just to take one example, is not covered by it. Java, XML, Unicode rec., and IDN 'identifiers' already aim for level 3. /kent k > The specification is > available in annex A of ISO/IEC TR 10176. Leading Unicode people > participated in creating this list, which is freely available. > Get it via http://www.dkuug.dk/jtc1/sc22/wg20 > > Kind regards > Keld > From owner-idn@ops.ietf.org Wed Mar 27 10:39:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02815 for ; Wed, 27 Mar 2002 10:38:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qFRI-000B7B-00 for idn-data@psg.com; Wed, 27 Mar 2002 07:34:16 -0800 Received: from rwcrmhc53.attbi.com ([204.127.198.39]) by psg.com with esmtp (Exim 3.35 #1) id 16qFRH-000B74-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 07:34:15 -0800 Received: from c1340594a ([12.234.212.162]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020327153414.BEXV2951.rwcrmhc53.attbi.com@c1340594a>; Wed, 27 Mar 2002 15:34:14 +0000 Message-ID: <007d01c1d5a4$e2607690$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: =?utf-8?Q?Keld_J=C3=B8rn_Simonsen?= , "IETF idn working group" References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> <20020327033059.GA18099@nicemice.net> <20020327092859.GA7784@rap.rap.dk> Subject: Re: [idn] IRIs ought to use internationalized *host* names Date: Wed, 27 Mar 2002 07:34:28 -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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Thanks, Keld. For those interested, there is an updated version of the recommended characters for programming language identifiers on: http://www.unicode.org/Public/3.2-Update/DerivedCoreProperties-3.2.0.t xt The derivation is listed in comments in that file: # Derived Property: ID_Start # Characters that can start an identifier. # Generated from Lu+Ll+Lt+Lm+Lo+Nl # Derived Property: ID_Continue # Characters that can continue an identifier. # Generated from: ID_Start + Mn+Mc+Nd+Pc # NOTE: Cf characters should be filtered out. The meaning of the abbreviations is on: http://www.unicode.org/Public/3.2-Update/UnicodeData-3.2.0.html#Genera l%20Category (However, it was long ago agreed that IDN should be more inclusive, rather than than more strictly follow programming language restrictions (see the archives). Of course, it is in keeping with the tenor of this group to endlessly revisit old issues...) Mark ————— Γνῶθι σαυτόν — Θαλῆς [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: "Keld Jørn Simonsen" To: "IETF idn working group" Sent: Wednesday, March 27, 2002 01:28 Subject: Re: [idn] IRIs ought to use internationalized *host* names > On Wed, Mar 27, 2002 at 03:30:59AM +0000, Adam M. Costello wrote: > > James Seng/Personal wrote: > > > > Which characters should be allowed in internationalized host labels? > > This is an interesting question in its own right, and it's possible that > > the IESG will demand an answer. > > That is indeed a good question. The same question has been put forward > for programming languages that can use full ISO 10646 (Unicode) in > their variable names, and ISO has developed a list of characters > that then are recommended for use in identifiers. This generally > consist of letters, digits and characters that can be used in > normal words in any language of the world. The specification is > available in annex A of ISO/IEC TR 10176. Leading Unicode people > participated in creating this list, which is freely available. > Get it via http://www.dkuug.dk/jtc1/sc22/wg20 > > Kind regards > Keld > > From owner-idn@ops.ietf.org Wed Mar 27 10:40:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02914 for ; Wed, 27 Mar 2002 10:40:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qFOb-000B4Q-00 for idn-data@psg.com; Wed, 27 Mar 2002 07:31:29 -0800 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.35 #1) id 16qFOa-000B4K-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 07:31:28 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2RFV7A10929 for ; Thu, 28 Mar 2002 00:31:16 +0900 Message-ID: <0fd701c1d5a4$43d54e10$2b19fea9@temp> From: "Soobok Lee" To: "IETF idn working group" References: <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> <20020327033059.GA18099@nicemice.net> Subject: Re: [idn] IRIs ought to use internationalized *host* names Date: Thu, 28 Mar 2002 00:29:54 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Adam M. Costello" > The Unicode character database classifies each character as belonging to > exactly one of the following broad classes: > > L: letter > M: mark > N: number > P: punctuation > S: symbol > Z: separator > C: other May I add this? U: unassigned code points. > > We can start by examining which of these classes of ASCII characters are > allowed in ASCII host labels. > > L: 52 exist, all are allowed > M: 0 exist > N: 10 exist, all are allowed > P: 23 exist, only hyphen-minus is allowed > S: 9 exist, none are allowed > Z: 1 exists, it is not allowed > C: 33 exist, none are allowed U: indefinite, all are allowed . > > We can trivially extend these results to form a simple rule covering the > entire Unicode repertoire, except that we have no precedent for class > M. Since characters in class M tend to be things like diacritics, they > should be allowed. So the proposed rule is: > > All characters in classes L (letter), M (mark), and N (number) are > allowed, and U+002D (hyphen-minus) is also allowed. Everything else is > forbidden. U should be also allowed in addition to L,M,N. But in later version of unicode , U may be partitioned into L' ~ C' and smaller U'. Soobok Lee From owner-idn@ops.ietf.org Wed Mar 27 11:34:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05982 for ; Wed, 27 Mar 2002 11:34:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qGDt-000Bvy-00 for idn-data@psg.com; Wed, 27 Mar 2002 08:24:29 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.35 #1) id 16qGDs-000Bvs-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 08:24:28 -0800 Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2RGOQm26492 for ; Wed, 27 Mar 2002 08:24:26 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3CA17929.72D92BD0@trab.se> References: <3CA17929.72D92BD0@trab.se> Date: Wed, 27 Mar 2002 08:22:46 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] URL encoding in html page Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 8:47 AM +0100 3/27/02, Dan Oscarsson wrote: >It is important that existing RFCs like the one for the URL, imediately >be >updated to allow non-ASCII letters. And do not use the IETF hacker >language >and call it IRI, for the common man it will be a URL and URI. >People will not ACE encode host names in URLs, people will not >%-encode paths in URLs. They will do like they do today: use native >character >set of the HTML document. Ignoring reality does not work. Quite true. The proposal to allow anyone to enter host names in URLs using any native encoding scheme, certainly ignores the reality that every DNS server would have to have equivalents for every name in every conceivable encoding scheme. Similarly, the proposal to allow people to enter host names in URIs using only UTF-8 ignores the reality that many people enter text in many different encoding schemes and often have no idea what scheme they are using at the moment (the text on the screen appears the same regardless of the encoding scheme). --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Wed Mar 27 12:18:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09445 for ; Wed, 27 Mar 2002 12:18:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qGrL-000CYP-00 for idn-data@psg.com; Wed, 27 Mar 2002 09:05:15 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qGrK-000CYJ-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 09:05:15 -0800 Message-ID: <002c01c1d5b1$77369cc0$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Dan Oscarsson" , References: <3CA17929.72D92BD0@trab.se> Subject: Re: [idn] URL encoding in html page Date: Wed, 27 Mar 2002 12:04:30 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >> So now IDN is a larger scope than we expected, not just browser > >> software needs to upgrade, even html editor like Dreamweaver, etc > >> needs to upgrade... > > > >It should not be surprising that any software that deals with domain > >names as such (as opposed to text in general) might need to be upgraded > >in order to allow characters in domain names that used to be forbidden. > > It is the IETF hacker talking again. The common man do not think > non-ASCII > letters are forbidden. So I think my Chinese name, or some Japanese, or Korean or any ones' name that is non-ASCII should be forbidden in the internet world too : > > In general you can all expect when soon non-ASCII domain names are > officially > allowed, there will be lots of places where people will enter names > using non-ASCII. They will expect them to be allowed in HTML documents > in > href field and in img src field. It does not matter that some have > decided > to restrict the definition of "URL" to ASCII, people will and already > do, > expect non-ASCII to be allowed in both host and path part of URL, in > native > character set without ACE or %-encoding!! Especially as it works in many > places > already today. That's right ACE or % escaped is like making displayable 16bits unicode or 8bits UTF8 falling back to 7bits ASCII, and on the UI of most of the applications or OS are moving towards the support of Unicode already. So I think that URL should be displayable and should move towards non-ASCII and should not move back to 7bits ASCII(actually 5bits ACE)... kind of stepping backwards to make new things happen : ) > It is important that existing RFCs like the one for the URL, imediately > be > updated to allow non-ASCII letters. And do not use the IETF hacker > language > and call it IRI, for the common man it will be a URL and URI. > People will not ACE encode host names in URLs, people will not > %-encode paths in URLs. They will do like they do today: use native > character > set of the HTML document. Ignoring reality does not work. I think so too... what do they mean by the RFC only allow URL to have non-ASCII letters, RFC is written by "HUMANS" and we can update them anytime if we "WANT" to... think about the creation of IPv6 and all the RFCs that requires to update when back then there is only IPv4... so should we say that IPv6 format cannot be used and should somehow come up with an "Algorithm" to convert the IPv6 into something that looks like IPv4.... : > From owner-idn@ops.ietf.org Wed Mar 27 12:27:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09978 for ; Wed, 27 Mar 2002 12:27:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qGzV-000CgJ-00 for idn-data@psg.com; Wed, 27 Mar 2002 09:13:41 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qGzU-000CgD-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 09:13:40 -0800 Message-ID: <004801c1d5b3$2c168460$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Edmon Chung" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> Subject: Re: [idn] URL encoding in html page Date: Wed, 27 Mar 2002 12:16:43 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ----- Original Message ----- > From: "Adam M. Costello" > > "David Leung (Neteka Inc.)" wrote: > > > So now IDN is a larger scope than we expected, not just browser > > > software needs to upgrade, even html editor like Dreamweaver, etc > > > needs to upgrade... > > > > It should not be surprising that any software that deals with domain > > names as such (as opposed to text in general) might need to be upgraded > > in order to allow characters in domain names that used to be forbidden. > > > (the keyword in this extract is "ANY". ANY software that deal with domain > names in a "human friendly form" will need to be upgraded. That means > almost all applications that use domain names isnt it? cause domain names > were supposedly devised to be a "human friendly" name) Edmon... I think it means every "human readable" UI has to be downgrade not upgrade... we should have something readable that converts to something unreadable so that web-designer dont know what they are putting in as URL : ) > This is a revealing point you have pointed out Adam. While you and some ACE > "everywhere" advocates maintain that ACE "everywhere" requires the least > upgrade, this seems to jump back out at yourselves that afterall, it is not > as small a job as it was advertised. > > This and that together, if we are going to need an overhaul what is the > point of going back to ASCII and not move forward to a more advanced schema? I always think of IDN this way, we need to upgrade software anyways but there is two approach... ACE or UTF8... ACE will work with "EXISTING" systems but ALL client end(browser, MUA, etc) and SOME server(Apache, etc) end software actually needs to upgrade in order to be able to recognize IDN and convert it to ACE back and forth, unless we want to say that www.ietf.org that we are using nowadays is IDN already : ) On the other hand, we see a lot of applications is moving towards the support of UTF8/Unicode on the client side, and this is going to be the future anyways... so why not just upgrade the server software, with one server software upgraded it will serve many many users... I dont understand why no one see this simple math : ) From owner-idn@ops.ietf.org Wed Mar 27 13:16:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13220 for ; Wed, 27 Mar 2002 13:16:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qHiX-000DOq-00 for idn-data@psg.com; Wed, 27 Mar 2002 10:00:13 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qHiW-000DOh-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 10:00:12 -0800 Message-ID: <007a01c1d5b9$aadf9510$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: , "Paul Hoffman / IMC" References: <3CA17929.72D92BD0@trab.se> Subject: Re: [idn] URL encoding in html page Date: Wed, 27 Mar 2002 13:03: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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > At 8:47 AM +0100 3/27/02, Dan Oscarsson wrote: > >It is important that existing RFCs like the one for the URL, imediately > >be > >updated to allow non-ASCII letters. And do not use the IETF hacker > >language > >and call it IRI, for the common man it will be a URL and URI. > >People will not ACE encode host names in URLs, people will not > >%-encode paths in URLs. They will do like they do today: use native > >character > >set of the HTML document. Ignoring reality does not work. > > Quite true. The proposal to allow anyone to enter host names in URLs > using any native encoding scheme, certainly ignores the reality that > every DNS server would have to have equivalents for every name in > every conceivable encoding scheme. I think how the name is being display in the HTML or UI can be a seperate issue of how it is going to be resolve at the backend, we can have IDNA with ACE in the name lookup functions instead of the interface where users can see the ACE... should we treat that as a leakage as well? > Similarly, the proposal to allow people to enter host names in URIs > using only UTF-8 ignores the reality that many people enter text in > many different encoding schemes and often have no idea what scheme > they are using at the moment (the text on the screen appears the same > regardless of the encoding scheme). However this will happen for IDNA as well, IDNA with ACE ASSUMES that all input are going to be in Unicode, however if user is inputting BIG5 or GB or any local encoding, you have to specify it on the IDNA client's setting before it can properly convert that to Unicode and to ACE anyways... so IDNA and ACE is "ignoring the reality" too!! But for newer OSes and applications I can see that there is more support for UTF8 and local encoding is slowly being replaced... I think there should be support for local encoding for the TRANSITIONAL period to make the deployment of IDN smoother before users can move toward using UTF8. From owner-idn@ops.ietf.org Wed Mar 27 19:12:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00382 for ; Wed, 27 Mar 2002 19:12:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qNEO-000J5p-00 for idn-data@psg.com; Wed, 27 Mar 2002 15:53:28 -0800 Received: from smtp22.singnet.com.sg ([165.21.101.202]) by psg.com with esmtp (Exim 3.35 #1) id 16qNEN-000J5i-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 15:53:27 -0800 Received: from jamescompaq (bb-203-125-132-81.singnet.com.sg [203.125.132.81]) by smtp22.singnet.com.sg (8.12.2/8.12.2) with SMTP id g2RNrLRh007585; Thu, 28 Mar 2002 07:53:21 +0800 Message-ID: <003401c1d5e8$4ed51180$0701000a@jamescompaq> From: "James Seng/Personal" To: "David Leung \(Neteka Inc.\)" , "Edmon Chung" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> Subject: Re: [idn] URL encoding in html page Date: Thu, 28 Mar 2002 07:37:05 +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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Edmon... I think it means every "human readable" UI has to be downgrade not > upgrade... we should have something readable that converts to something > unreadable so that web-designer dont know what they are putting in as URL > : ) UTF-8 does not imply "human readable". It means it is encoded in UTF-8. Dont continue confuse folk display and encoding. But I agree that ACE is one form of "downgrading" but the target is for machine readability, not human. > > This is a revealing point you have pointed out Adam. While you and some > ACE > > "everywhere" advocates maintain that ACE "everywhere" requires the least > > upgrade, this seems to jump back out at yourselves that afterall, it is > not > > as small a job as it was advertised. In IETF, when face with two proposals, we do engineering trade-off. Therefore, no one actually say it is "a small a job". Most say IDNA is a easier task. > ACE will work with "EXISTING" systems but ALL client end(browser, MUA, etc) > and SOME server(Apache, etc) end software actually needs to upgrade in order > to be able to recognize IDN and convert it to ACE back and forth, unless we > want to say that www.ietf.org that we are using nowadays is IDN already : ) > > On the other hand, we see a lot of applications is moving towards the > support of UTF8/Unicode on the client side, and this is going to be the > future anyways... so why not just upgrade the server software, with one > server software upgraded it will serve many many users... I dont understand > why no one see this simple math : ) You point out the cruial pros & cons over the ACE vs UTF-8. The differ in opinion is the last part with you dont understand. My take? If it were up to me, why stick to UTF-8? I'll say lets do one single upgrade to 128bit, lets called it UTF-128, just in case. -James Seng From owner-idn@ops.ietf.org Wed Mar 27 20:40:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01660 for ; Wed, 27 Mar 2002 20:40:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qOkq-000Kpl-00 for idn-data@psg.com; Wed, 27 Mar 2002 17:31:04 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qOkp-000Kpf-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 17:31:03 -0800 Message-ID: <026301c1d5f8$84046210$6501a8c0@EDMON15> From: "Edmon Chung" To: "James Seng/Personal" , "David Leung \(Neteka Inc.\)" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> Subject: Re: [idn] URL encoding in html page Date: Wed, 27 Mar 2002 20:33: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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Its good to here from you James saying that it is smarter to upgrade to UTF8 than to downgrade to ACE. Although we are not requiring your UTF128 just yet, but I absolutely agree that the IDN protocol should provision for such upgrades. Using IDN/EDNS with versioning, we can provision this. Glad you are back on the right track James! Edmon ----- Original Message ----- From: "James Seng/Personal" > > Edmon... I think it means every "human readable" UI has to be downgrade > not > > upgrade... we should have something readable that converts to something > > unreadable so that web-designer dont know what they are putting in as URL > > : ) > > UTF-8 does not imply "human readable". It means it is encoded in UTF-8. > Dont continue confuse folk display and encoding. No one is trying to confuse. What we mean is that all application that displays domain names intended for human reading will have to be changed. And this is a very large number of applications. > > But I agree that ACE is one form of "downgrading" but the target is for > machine readability, not human. > > > > This is a revealing point you have pointed out Adam. While you and some > > ACE > > > "everywhere" advocates maintain that ACE "everywhere" requires the least > > > upgrade, this seems to jump back out at yourselves that afterall, it is > > not > > > as small a job as it was advertised. > > In IETF, when face with two proposals, we do engineering trade-off. > > Therefore, no one actually say it is "a small a job". Most say IDNA is a > easier task. > > > ACE will work with "EXISTING" systems but ALL client end(browser, MUA, > etc) > > and SOME server(Apache, etc) end software actually needs to upgrade in > order > > to be able to recognize IDN and convert it to ACE back and forth, unless > we > > want to say that www.ietf.org that we are using nowadays is IDN already > : ) > > > > On the other hand, we see a lot of applications is moving towards the > > support of UTF8/Unicode on the client side, and this is going to be the > > future anyways... so why not just upgrade the server software, with one > > server software upgraded it will serve many many users... I dont > understand > > why no one see this simple math : ) > > You point out the cruial pros & cons over the ACE vs UTF-8. The differ in > opinion is the last part with you dont understand. > > My take? If it were up to me, why stick to UTF-8? I'll say lets do one > single upgrade to 128bit, lets called it UTF-128, just in case. > > -James Seng > > > From owner-idn@ops.ietf.org Wed Mar 27 20:55:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01999 for ; Wed, 27 Mar 2002 20:54:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qP0e-000L7I-00 for idn-data@psg.com; Wed, 27 Mar 2002 17:47:24 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16qP0b-000L76-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 17:47:23 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 5EE9AFFC03; Thu, 28 Mar 2002 09:45:25 +0800 (SGT) Message-ID: <006101c1d5fa$43822ef0$dd00a8c0@jamessonyviao> From: "James Seng" To: "Edmon Chung" , "David Leung (Neteka Inc.)" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <026301c1d5f8$84046210$6501a8c0@EDMON15> Subject: Re: [idn] URL encoding in html page Date: Thu, 28 Mar 2002 09:45:33 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edmon, Please dont put words into my mouth. > Its good to here from you James saying that it is smarter to upgrade to UTF8 > than to downgrade to ACE. This is not what I say. > Although we are not requiring your UTF128 just yet, but I absolutely agree > that the IDN protocol should provision for such upgrades. I did not say this either. > Using IDN/EDNS > with versioning, we can provision this. I have not say this either. > Glad you are back on the right track James! I am sorry to see you are on the wrong track. -James Seng From owner-idn@ops.ietf.org Wed Mar 27 22:00:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03855 for ; Wed, 27 Mar 2002 22:00:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qQ0S-000MFo-00 for idn-data@psg.com; Wed, 27 Mar 2002 18:51:16 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16qQ0Q-000MFf-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 18:51:14 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id A0B7AFFC03 for ; Thu, 28 Mar 2002 10:49:20 +0800 (SGT) Message-ID: <00e501c1d603$3168c400$dd00a8c0@jamessonyviao> From: "James Seng" To: "IETF/IDN WG" Subject: [idn] Fw: Unicode 3.2 Released Date: Thu, 28 Mar 2002 10:49:28 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit fyi ----- Original Message ----- From: "Mark Davis" To: ; ; Sent: Thursday, March 28, 2002 10:46 AM Subject: Unicode 3.2 Released > Unicode 3.2 has been released! The data files and documentation are final > and posted on the Unicode site. For details, see UAX #28, Unicode 3.2 at > . > > Unicode 3.2 adds 1,016 additional characters, and now includes the most > extensive set of characters for mathematical and technical publishing yet > defined. Encodings for four indigenous scripts of the Philippines have been > added to the repertoire, as well as new special characters such as the Word > Joiner, Grapheme Joiner, and Variation Selectors. A number of characters are > also added for interoperating with JIS X 0213:2000. > > Unicode 3.2 has also updated a number of conformance issues, including > tightening of the definition of UTF-8, when to replace ZWNBSP (BOM) with > Word Joiner, and clarifications of the use of Combining Marks, Hangul > Syllables, and Conjoining Jamo. Case Mappings (formerly UTR#21) is now part > of the Unicode Standard. Additional explanatory material has been added for > decomposition and for specific characters and scripts; in particular, > clarifications and charts have been added to the Khmer script block to > better explain the encoding. > > New properties have been added to the Unicode Character Database. These > include: recommended UCD property names and property value names; an exact > specification of when variation selectors can be used; when each character > was added to the Unicode Standard; grapheme cluster information, ideographic > description categories; code points that are ignorable by default, and > deprecated characters. > > Unicode 3.2 is fully synchronized with International Standard ISO/IEC > 10646-1:2000, with its Amendment 1, and with ISO/IEC 10646-2:2001. > > Please note that while all of the online data files and documentation for > the Unicode 3.2 have been updated, it will take a few days to complete the > rollup of all of the revised pdf code charts on the website. Charts for the > specific additional characters for Version 3.2 can, however, already be > accessed via the links in UAX #28. > > Also note that material on default grapheme clusters has been moved from > the beta version of Unicode 3.2 into a new proposed draft UTR #29: Text > Boundaries at . > > Mark > > From owner-idn@ops.ietf.org Wed Mar 27 23:06:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05875 for ; Wed, 27 Mar 2002 23:06:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qQxZ-000NPs-00 for idn-data@psg.com; Wed, 27 Mar 2002 19:52:21 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16qQxY-000NPm-00 for idn@ops.ietf.org; Wed, 27 Mar 2002 19:52:20 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16qQxX-0007yJ-00 for ; Wed, 27 Mar 2002 19:52:19 -0800 Date: Thu, 28 Mar 2002 03:52:19 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] IRIs ought to use internationalized *host* names Message-ID: <20020328035219.GA29824@nicemice.net> Reply-To: IETF idn working group References: <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> <20020327033059.GA18099@nicemice.net> <0fd701c1d5a4$43d54e10$2b19fea9@temp> <7FC3066C236FD511BC5900508BAC86FE9199C0@trestles.internal.realnames.com> <000f01c1d4ae$56a77e60$4d43738c@me.ncu.edu.tw> <008701c1d4d9$7e3ddde0$6501a8c0@EDMON15> <004901c1d4e2$23605de0$0701000a@jamescompaq> <20020327033059.GA18099@nicemice.net> <072101c1d568$f6e8ede0$dd00a8c0@jamessonyviao> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007d01c1d5a4$e2607690$8900a8c0@c1340594a> <0fd701c1d5a4$43d54e10$2b19fea9@temp> <072101c1d568$f6e8ede0$dd00a8c0@jamessonyviao> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk This message contains responses to both James Seng and Soobok Lee. James Seng wrote: > My believe is what is allowed in host labels is a topic for the zone > administrator to decide. .CN have a different set compared to .SG > compared to .COM compared to say IBM.COM. Zone administrators can always impose their own restrictions, but that still leaves us with the question of what the IRI spec should say about what characters are allowed in the host field of IRIs. The historic precedent is that ASCII punctuation and symbols are allowed in ASCII *domain* names, but not in ASCII *host* names, and not in the host field of URIs. Should IRIs be more loose and allow non-ASCII punctuation and symbols in the host field (while continuing to disallow ASCII punctutation and symbols)? Or should IRIs try to apply an old tradition to a new situtation, and disallow punctuation and symbols? Soobok Lee wrote: > > L: letter > > M: mark > > N: number > > P: punctuation > > S: symbol > > Z: separator > > C: other > > May I add this? > > U: unassigned code points. I see your motivation. The classes I listed are all the ones mentioned in the Unicode character database, but of course the database covers only assigned code points. All code points not mentioned in the database are unassigned, and we could view that as another class. > U should be also allowed in addition to L,M,N. ToASCII and Nameprep already take an input flag indicating whether unassigned code points are to be allowed or prohibited. My proposal wouldn't change that. AMC From owner-idn@ops.ietf.org Thu Mar 28 03:21:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18389 for ; Thu, 28 Mar 2002 03:21:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qUt1-0001MS-00 for idn-data@psg.com; Thu, 28 Mar 2002 00:03:55 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16qUsx-0001LW-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 00:03:51 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id B3B151401; Thu, 28 Mar 2002 17:03:49 +0900 (JST) Message-Id: <4.2.0.58.J.20020328162839.033d4858@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 28 Mar 2002 16:30:25 +0900 To: "Bruce Thomson" , "Soobok Lee" , "IETF idn working group" From: Martin Duerst Subject: Re: [idn] URL encoding in html page In-Reply-To: <039b01c1d179$a25b6070$a303a8c0@bruce> References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 17:14 02/03/22 +0900, Bruce Thomson wrote: >Encodings of anything on an HTML page are an issue as well. Various >methods are already defined for the codeset to be determined, so >whether UTF-8, legacy encodings, or ACE are used, there shouldn't >be a problem. If uses a different encoding for the URL from the rest >he will have a problem, but that's no different than if he tried to mix >two different legacy encodings in his text without intervening META >tags. Just to avoid further misunderstandings: Any single HTML document is in a single encoding. Mixing encodings is not possible. Using multiple tags to try to do this won't work. Regards, Martin. #-#-# Martin J. Du"rst, I18N Activity Lead, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org/People/D%C3%BCrst From owner-idn@ops.ietf.org Thu Mar 28 03:21:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18402 for ; Thu, 28 Mar 2002 03:21:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qUt1-0001MQ-00 for idn-data@psg.com; Thu, 28 Mar 2002 00:03:55 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16qUsx-0001LV-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 00:03:51 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 4811B135E; Thu, 28 Mar 2002 17:03:49 +0900 (JST) Message-Id: <4.2.0.58.J.20020328152641.02f7c7a8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 28 Mar 2002 15:29:42 +0900 To: "Soobok Lee" , "A. Vine" From: Martin Duerst Subject: Re: [idn] URL encoding in html page Cc: "IETF idn working group" In-Reply-To: <036c01c1d464$a1a0e9a0$2b19fea9@temp> References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> <039b01c1d179$a25b6070$a303a8c0@bruce> <0a3d01c1d17c$6523cf00$2b19fea9@temp> <03b201c1d184$09260760$a303a8c0@bruce> <0a9f01c1d189$00baa040$2b19fea9@temp> <3C9FCAD0.1080701@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:21 02/03/26 +0900, Soobok Lee wrote: >>Yes. But, legacy encodings are often revised or there may be new born >>legacy encoding. >>What and how much does that affect the stable operation of IDN in >>networks of various versions of >>IDN-aware applications? > >Answering just for the Web case: > >An old browser will not understand a new encoding. So it won't be >able to display the page, nor it won't be able to resolve natively >encoded domain names. To use a new encoding, people will have to >upgrade to a new browser version. > >Regards, Martin. #-#-# Martin J. Du"rst, I18N Activity Lead, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org/People/D%C3%BCrst From owner-idn@ops.ietf.org Thu Mar 28 03:21:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18414 for ; Thu, 28 Mar 2002 03:21:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qUt1-0001MO-00 for idn-data@psg.com; Thu, 28 Mar 2002 00:03:55 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16qUsx-0001LU-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 00:03:51 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id BFB241406; Thu, 28 Mar 2002 17:03:49 +0900 (JST) Message-Id: <4.2.0.58.J.20020328163544.033e4ee8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 28 Mar 2002 16:38:23 +0900 To: IETF idn working group , IETF idn working group From: Martin Duerst Subject: Re: [idn] URL encoding in html page In-Reply-To: <20020327005714.GC15408@nicemice.net> References: <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 00:57 02/03/27 +0000, Adam M. Costello wrote: >An HTML editor knows HTML syntax, so it knows the difference between >the host field of a URI in the src attribute of an IMG tag, versus text >in the content of a P element. The former is subject to strict syntax >rules because it's a protocol element, while the latter is just text, >regardless of whether it happens to contain substrings that look like >domain names. HTML defines href or source as CDATA, which means just about 'anything goes'. And as I have said in another mail, I don't think that HTML editors do a lot of checks. Checks may occur as part of link checking, but that's not on the syntax level, where http://www.xyz.no-such-tld would be allowed. Regards, Martin. #-#-# Martin J. Du"rst, I18N Activity Lead, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org/People/D%C3%BCrst From owner-idn@ops.ietf.org Thu Mar 28 03:21:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18427 for ; Thu, 28 Mar 2002 03:21:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qUt0-0001ML-00 for idn-data@psg.com; Thu, 28 Mar 2002 00:03:54 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16qUsx-0001LT-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 00:03:51 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 34751D90; Thu, 28 Mar 2002 17:03:49 +0900 (JST) Message-Id: <4.2.0.58.J.20020328151716.02f54948@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 28 Mar 2002 15:28:05 +0900 To: Dan Oscarsson , idn@ops.ietf.org From: Martin Duerst Subject: Re: [idn] URL encoding in html page In-Reply-To: <3CA17929.72D92BD0@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 08:47 02/03/27 +0100, Dan Oscarsson wrote: >It is important that existing RFCs like the one for the URL, imediately >be >updated to allow non-ASCII letters. And do not use the IETF hacker >language >and call it IRI, for the common man it will be a URL and URI. You are referring to http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-08.txt Internationalized Resource Identifiers (IRI). As a co-author, I have to tell you that the draft became quite a bit easier to write and read when introducing the distinction between URIs and IRIs. And I expect the same benefit for other specifications that reference this work. So I wouldn't want to change back to the terminology used in earlier drafts. However, I agree with you that in common use, people will most probably call everything an URI or URL, and that should work out fine. Regards, Martin. #-#-# Martin J. Du"rst, I18N Activity Lead, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org/People/D%C3%BCrst From owner-idn@ops.ietf.org Thu Mar 28 03:23:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18457 for ; Thu, 28 Mar 2002 03:23:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qUt1-0001MP-00 for idn-data@psg.com; Thu, 28 Mar 2002 00:03:55 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16qUsx-0001LX-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 00:03:51 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id A726513F4; Thu, 28 Mar 2002 17:03:49 +0900 (JST) Message-Id: <4.2.0.58.J.20020328153022.033d1fe0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 28 Mar 2002 16:28:01 +0900 To: IETF idn working group , idn@ops.ietf.org From: Martin Duerst Subject: Re: [idn] URL encoding in html page In-Reply-To: <20020326234002.GB15408@nicemice.net> References: <001901c1d4e5$51725050$0301a8c0@davidvaio> <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 23:40 02/03/26 +0000, Adam M. Costello wrote: >"David Leung (Neteka Inc.)" wrote: > > > If we use ACE as the URL links then all web designers in the world > > needs to be retrained for ACE conversion. > >Either the web designer uses an HTML editor, in which case the editor >should know the HTML syntax rules and convert to/from the local charset >as needed, I don't know exactly what you mean by 'convert to/from'. Many HTML editors these days work in Unicode internally, and convert to whatever encoding the author chooses on input/output. This conversion is independent of HTML syntax, except for the use (or not) of numeric character references (&#xHHHH;,...), and the charset information. Some HTML editors may work in a local encoding throughout, and then they don't do any conversion. You seem to imply that the HTML editor is checking or should check the URI syntax, and that they could be upgraded to add a legacy encoding->Unicode->ACE conversion. First, I'm not aware of HTML editors actually doing such syntax checks. Second, there is the very fundamental problem that they won't be able to do such checks. If you enter hppt:something, should the editor tell you this is an error? It has no idea whether hppt is a legal URI scheme or not. Similarly, even if the HTML editor does the very limited checks that RFC 2396 allows, this doesn't get it very far. For example, while http: uses generic URI syntax, mailto: uses opaque syntax, so there is no general way to know where in an URI there is a domain name. This includes the case that a domain name is sent as a parameter. >or the web designer uses a text editor, in which case the web >designer is taking responsibility for knowing and obeying the HTML/URI >syntax rules, one of which is that href and src attributes contain only >ASCII characters. > >Maybe future HTML/URI specs will allow non-ASCII characters in href and >src attributes, but it's not obvious how to do that without breaking >deployed browsers, and that discussion is for another forum. HTML 4 already says what a browser should do if it finds an non-ASCII character in an URI. Please see http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.1 Appendix B.2.1: Non-ASCII characters in URI attribute values (this is supported by all major browsers in newer versions) Further information, e.g. on other W3C specs, see also: http://www.w3.org/International/O-URL-and-ident.html Of course this doesn't solve the problem of how to handle IDNs in URIs automatically, but it provides a clear direction. Regards, Martin. #-#-# Martin J. Du"rst, I18N Activity Lead, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org/People/D%C3%BCrst From owner-idn@ops.ietf.org Thu Mar 28 04:13:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18428 for ; Thu, 28 Mar 2002 03:21:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qUt1-0001MU-00 for idn-data@psg.com; Thu, 28 Mar 2002 00:03:55 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.35 #1) id 16qUsz-0001Lt-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 00:03:53 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id CB7B01407; Thu, 28 Mar 2002 17:03:49 +0900 (JST) Message-Id: <4.2.0.58.J.20020328163902.034c2330@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 28 Mar 2002 17:03:42 +0900 To: "James Seng" , "Soobok Lee" , "IETF idn working group" From: Martin Duerst Subject: Re: [idn] URL encoding in html page In-Reply-To: <05d701c1d174$de044d80$dd00a8c0@jamessonyviao> References: <5.1.0.14.2.20020321180947.02fd5b00@127.0.0.1> <20020322032033.GC940@spsoft.co.kr> <20020322042622.GA1853@spsoft.co.kr> <038101c1d15c$972f9940$a303a8c0@bruce> <09df01c1d172$b01508d0$2b19fea9@temp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 15:40 02/03/22 +0800, James Seng wrote: >This is a good question, one which is related to IDN & URL. > >Check this out: http://www.i-d-n.net/draft/draft-masinter-url-i18n-07.txt please check out the latest version, at http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-08.txt We are currently working on an update, please send in your comments as soon as possible. Also, please have a look at http://www.ietf.org/internet-drafts/draft-ietf-idn-uri-01.txt for the link between the work on IRIs and on IDN. Please note that this draft is a WG draft, and of course any comments are appreciated. Please note that the current version of the draft doesn't say anything about ACE, and the main reason for this is that I didn't want to put in too much as long as it was not clear which ACE would be used. Regards, Martin. #-#-# Martin J. Du"rst, I18N Activity Lead, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org/People/D%C3%BCrst From owner-idn@ops.ietf.org Thu Mar 28 09:14:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26620 for ; Thu, 28 Mar 2002 09:14:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qaSC-0007kM-00 for idn-data@psg.com; Thu, 28 Mar 2002 06:00:36 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qaSB-0007kG-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 06:00:36 -0800 Message-ID: <030f01c1d661$37ce18f0$6501a8c0@EDMON15> From: "Edmon Chung" To: "James Seng/Personal" , "David Leung \(Neteka Inc.\)" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> Subject: Re: [idn] URL encoding in html page Date: Thu, 28 Mar 2002 09:02:35 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi James, I am sorry if I offended you in any way shape or form with my little playful note. However, please explain further your intentions on the comments if not that you agree ACE is downgrade, UTF8 is a slight upgrade and your UTF128 is a great upgrade? Edmon ----- Original Message ----- From: "James Seng/Personal" > But I agree that ACE is one form of "downgrading" but the target is for > machine readability, not human. > > My take? If it were up to me, why stick to UTF-8? I'll say lets do one > single upgrade to 128bit, lets called it UTF-128, just in case. > > -James Seng > > > From owner-idn@ops.ietf.org Thu Mar 28 09:50:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28379 for ; Thu, 28 Mar 2002 09:50:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qb5Q-0008az-00 for idn-data@psg.com; Thu, 28 Mar 2002 06:41:08 -0800 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.35 #1) id 16qb5P-0008as-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 06:41:08 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2SEetA20631; Thu, 28 Mar 2002 23:40:56 +0900 Message-ID: <177f01c1d666$64adbb00$2b19fea9@temp> From: "Soobok Lee" To: , Cc: Subject: [idn] questions about new unicode 3.2 addition for hangul compatibilit jamo handling Date: Thu, 28 Mar 2002 23:39:39 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="text/plain"; boundary="----=_NextPart_000_177C_01C1D6B1.D3F4DD40" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_177C_01C1D6B1.D3F4DD40 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Congratulation on the birth of Unicode 3.2. :-) I found the following addition which is useful for correct handling of hangul compatibility jamo. But, i suspect it does not help IDN nameprep, while it will clearly help ordinary hangul text applications. The U+200B and U+FFEF ( <--- U+2060 by NFKC) in ACE-encoded label should *NOT* be resubmitted into another nameprep process again! But, in most cases , for example, copy & paste of URL, IDN-aware applications would apply the nameprep map-out process (1st step) on U+200B or U+FFEF in decoded ACE label and apply the next nameprep NFKC step on bare (without those zero-width spaces) hangul conjoining jamo sequences and make as similar unintended combined syllables as without this new unicode 3.2 addition. In summary, if nameprep adopts this addition, it may enable correctly-rendered hangul jamo labels to be encoded and rendered and registered, but, those labels may undergo some errors in ACE-decode-and-re-encode process in copy&paste operations in IDN-aware operations. I read the following document just now. I don't know whether stringprep/nameprep will adopt Unicode 3.2. If i have some misunderstang in the above analysis, please correct me. Soobok Lee http://www.unicode.org/unicode/reports/tr28/#10_4_hangul 10.4 Hangul (addition) Hangul Compatibility Jamo When Hangul compatibility jamo are transformed with a compatibility normalization form, NFKD or NFKC, the characters are converted to the corresponding conjoining jamo characters. Where the characters are intended to remain in separate syllables after such transformation, they may require separation from adjacent characters. This can be done by inserting any non-Korean character. a.. U+200B ZERO-WIDTH SPACE is recommended where the characters are to allow line-break. b.. U+2060 WORD JOINER can be used where the characters are not to break across lines. For example, the table below illustrates how two Hangul compatibility jamo can be separated in display, even after transforming with NFKD or NFKC. Separating Jamo Characters Original NFKD NFKC Display 3131 314F 1100 1161 AC00 3131 200B 314F 1100 200B 1161 1100 200B 1161 ------=_NextPart_000_177C_01C1D6B1.D3F4DD40 Content-Type: application/octet-stream; name="refglyph?24-3131" Content-Location: http://www.unicode.org/cgi-bin/refglyph?24-3131 Content-Transfer-Encoding: base64 R0lGODlhEwAuAPMAAP////zzBf9kAt0IBvIIhEYApQAA1AKr6h+3FABkEVYsBZBxOsDAwICAgEBA QAAAACH5BAEAAAAALAAAAAATAC4AAwRYEMhJq7046827/2AojkzIlOBpop+asp7blkxj37ijN4Db 7LaT68GTbYg9mAZpXBaVmQcNipEmPdZmdIrldhwS7UasIWeE6LRauGq/3DN4jFqmn0f4vL4TAQAh /jVjbGlwMmdpZiBsaWIgMC43LjIgYnkgWXZlcyBQaWd1ZXQgPHBpZ3VldEBpYS5lcGZsLmNoPgA7 ------=_NextPart_000_177C_01C1D6B1.D3F4DD40 Content-Type: application/octet-stream; name="refglyph?24-314F" Content-Location: http://www.unicode.org/cgi-bin/refglyph?24-314F Content-Transfer-Encoding: base64 R0lGODlhEwAuAPMAAP////zzBf9kAt0IBvIIhEYApQAA1AKr6h+3FABkEVYsBZBxOsDAwICAgEBA QAAAACH5BAEAAAAALAAAAAATAC4AAwRqEMhJq7046827/2AojkzIlBPjNNpZMcqDWq71sFddyZhO 8bnZT0jxTYA0ogT5UgKYRSc0JXUCjBIFiogFOFaPW/SyOvm6Dita7Uz32mxy3OIOmu/pu76d6bas fYBvJoJBhIcghSOLjI0SEQAh/jVjbGlwMmdpZiBsaWIgMC43LjIgYnkgWXZlcyBQaWd1ZXQgPHBp Z3VldEBpYS5lcGZsLmNoPgA7 ------=_NextPart_000_177C_01C1D6B1.D3F4DD40 Content-Type: application/octet-stream; name="refglyph?24-1100" Content-Location: http://www.unicode.org/cgi-bin/refglyph?24-1100 Content-Transfer-Encoding: base64 R0lGODlhEwAuAPMAAP////zzBf9kAt0IBvIIhEYApQAA1AKr6h+3FABkEVYsBZBxOsDAwICAgEBA QAAAACH5BAEAAAAALAAAAAATAC4AAwRYEMhJq7046827/2AojkzIlOBpop+asp7blkxj37ijN4Db 7LaT68GTbYg9mAZpXBaVmQcNipEmPdZmdIrldhwS7UasIWeE6LRauGq/3DN4jFqmn0f4vL4TAQAh /jVjbGlwMmdpZiBsaWIgMC43LjIgYnkgWXZlcyBQaWd1ZXQgPHBpZ3VldEBpYS5lcGZsLmNoPgA7 ------=_NextPart_000_177C_01C1D6B1.D3F4DD40 Content-Type: application/octet-stream; name="refglyph?24-1161" Content-Location: http://www.unicode.org/cgi-bin/refglyph?24-1161 Content-Transfer-Encoding: base64 R0lGODlhEwAuAPMAAP////zzBf9kAt0IBvIIhEYApQAA1AKr6h+3FABkEVYsBZBxOsDAwICAgEBA QAAAACH5BAEAAAAALAAAAAATAC4AAwRpEMhJq7046827/2AojkzIlBPjNNpZMcqDWq71sFddyZhO 8bnZT0jxTYA0ogT5UgKYRSc0JXUCjBIFiogFOFaPW/SyOnGdDms33UOr3W3yW94229P2PDrTbVn5 f3EgfYAmgUEmI4qLjB0RACH+NWNsaXAyZ2lmIGxpYiAwLjcuMiBieSBZdmVzIFBpZ3VldCA8cGln dWV0QGlhLmVwZmwuY2g+ADs= ------=_NextPart_000_177C_01C1D6B1.D3F4DD40 Content-Type: application/octet-stream; name="refglyph?24-AC00" Content-Location: http://www.unicode.org/cgi-bin/refglyph?24-AC00 Content-Transfer-Encoding: base64 R0lGODlhGAAuAPMAAP////zzBf9kAt0IBvIIhEYApQAA1AKr6h+3FABkEVYsBZBxOsDAwICAgEBA QAAAACH5BAEAAAAALAAAAAAYAC4AAwSKEMhJq7046827/2AojmSZMSaDcs7jNJXqNc8Tr55NyZ8+ 8SeKT8Jj1BzIWg0mGQKAjJcKZRTeNA2HdYe7PLpOoIVWCXd3D+ZEl22IKQ6FRVlTvCW0M8BsMer3 V2hqZYETdhl8RA5/a4FRHHwMg4iFHWZTmJmYX5ogWlwgk3cgjCamp6ipqqusrSYRACH+NWNsaXAy Z2lmIGxpYiAwLjcuMiBieSBZdmVzIFBpZ3VldCA8cGlndWV0QGlhLmVwZmwuY2g+ADs= ------=_NextPart_000_177C_01C1D6B1.D3F4DD40 Content-Type: application/octet-stream; name="refglyph?24-200B" Content-Location: http://www.unicode.org/cgi-bin/refglyph?24-200B Content-Transfer-Encoding: base64 R0lGODlhGQAuAPMAAP////zzBf9kAt0IBvIIhEYApQAA1AKr6h+3FABkEVYsBZBxOsDAwICAgEBA QAAAACH5BAEAAAAALAAAAAAZAC4AAwS8EMhJq7046827/2AojmQ5MibAoObqqiuMvrTLOE5z53sD NLkfTuhYOUpFVmnlI+luE8Zj+tA9VldAVpI8VhwPybVRlVKSFjIrxwZWmBRpU3h9BCWMp1c8F4en cV1RVFUSCkcOCoEvJC59eEoaenF2hSqEX0ZnPlCXfGeMEmQ8eFdSkY5vQGGXOI+TE0NaM6wWgoNT TWYXSTa+v8A2JbAjSUBWZbkAYGFkY3YxLZEn0yLRS9Uh140p3d7f4BEAIf41Y2xpcDJnaWYgbGli IDAuNy4yIGJ5IFl2ZXMgUGlndWV0IDxwaWd1ZXRAaWEuZXBmbC5jaD4AOw== ------=_NextPart_000_177C_01C1D6B1.D3F4DD40-- From owner-idn@ops.ietf.org Thu Mar 28 15:38:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14152 for ; Thu, 28 Mar 2002 15:38:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qgTl-000H0f-00 for idn-data@psg.com; Thu, 28 Mar 2002 12:26:37 -0800 Received: from smtp12.singnet.com.sg ([165.21.6.32]) by psg.com with esmtp (Exim 3.35 #1) id 16qgTk-000H0Z-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 12:26:36 -0800 Received: from jamescompaq (bb-165-21-94-167.singnet.com.sg [165.21.94.167]) by smtp12.singnet.com.sg (8.12.2/8.12.2) with SMTP id g2SKQUZs003702; Fri, 29 Mar 2002 04:26:30 +0800 Message-ID: <005d01c1d694$9181eec0$0701000a@jamescompaq> From: "James Seng/Personal" To: "Edmon Chung" , "David Leung \(Neteka Inc.\)" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 04:10: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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I meant exactly what I said: ACE is a "downgrade" for machine read. Downgrade here have the same meaning as base64/qp is used to "downgrade" mail when 8BITMIME is not supported. It does not mean it is better or worst. UTF-8 is another encoding of Unicode and plainly just UTF-8. I did not make any comment to say UTF-8 is better or worst. You read too much. I didnt say that "UTF-128" is better than "UTF-8" is better than ACE either. UTF-128 is just plainly UTF-128. You jumped too quickly into conclusion. If we going to have a flag to change everything to 8-bit clean, why stop at 8-bit? 8-bit does not even have the basic bit to support ISO10646. You need some encoding mechanism to translate ISO10646 to 8-bit, aka, UTF-8. So why not make all 128bit (or more) clean? -James Seng ----- Original Message ----- From: "Edmon Chung" To: "James Seng/Personal" ; "David Leung (Neteka Inc.)" ; "IETF idn working group" Sent: Thursday, March 28, 2002 10:02 PM Subject: Re: [idn] URL encoding in html page > Hi James, > I am sorry if I offended you in any way shape or form with my little playful > note. > However, please explain further your intentions on the comments if not that > you agree ACE is downgrade, UTF8 is a slight upgrade and your UTF128 is a > great upgrade? > Edmon > > ----- Original Message ----- > From: "James Seng/Personal" > > But I agree that ACE is one form of "downgrading" but the target is for > > machine readability, not human. > > > > My take? If it were up to me, why stick to UTF-8? I'll say lets do one > > single upgrade to 128bit, lets called it UTF-128, just in case. > > > > -James Seng > > > > > > > > > From owner-idn@ops.ietf.org Thu Mar 28 16:13:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15567 for ; Thu, 28 Mar 2002 16:13:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qh2q-000HlG-00 for idn-data@psg.com; Thu, 28 Mar 2002 13:02:52 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qh2p-000HlA-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 13:02:51 -0800 Message-ID: <00b301c1d69c$761d52c0$0301a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "James Seng/Personal" , "Edmon Chung" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> Subject: Re: [idn] URL encoding in html page Date: Thu, 28 Mar 2002 16:06:41 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I meant exactly what I said: ACE is a "downgrade" for machine read. > Downgrade here have the same meaning as base64/qp is used to "downgrade" > mail when 8BITMIME is not supported. It does not mean it is better or worst. > > UTF-8 is another encoding of Unicode and plainly just UTF-8. I did not make > any comment to say UTF-8 is better or worst. You read too much. UTF8 was there for the first place is to make the transition from 8 bits to 16/32 bits Unicode smoother, so the existing 8 bits system will be able to use it. Same as base64 is to downgrade the 8bits into ASCII to make the transition smoother... So should we say that a good design should have fallback(downgrade) for TRANSITIONAL period only. Then a good IDN design should be able to use ACE as the fallback for old system, BUT SHOULD also be able to step forward to use 8/16/32 bits or even more bits when needed. So we should not say that ACE should be a long term solution for IDN, it should ONLY be a TRANSITION solution that allows the LONG TERM solution of using UTF8 or 16/32 bits Unicode to work. > I didnt say that "UTF-128" is better than "UTF-8" is better than ACE either. > UTF-128 is just plainly UTF-128. You jumped too quickly into conclusion. > > If we going to have a flag to change everything to 8-bit clean, why stop at > 8-bit? 8-bit does not even have the basic bit to support ISO10646. You need > some encoding mechanism to translate ISO10646 to 8-bit, aka, UTF-8. > > So why not make all 128bit (or more) clean? More bits is good, but when we plan for things more than we need, then it should be considered to be a waste of resource. So why do we need 128bits now(i dont think the combined total of characters in all languages in the world would require that much, not unless we want to include scripts from oter planets : > ), whereas we need 8/16/32 bits for Unicode, so why not design a system able to accept ACE as a fallback and also 8/16/32 bits? If you can justify why designing a system that can handle ASCII as a fallback and can automatically support 8/16/32 bits Unicode is not a good design, then I think my thinking is wrong. From owner-idn@ops.ietf.org Thu Mar 28 19:09:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19684 for ; Thu, 28 Mar 2002 19:09:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qjga-000LB4-00 for idn-data@psg.com; Thu, 28 Mar 2002 15:52:04 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16qjgZ-000LAx-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 15:52:03 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16qjgX-00020N-00 for ; Thu, 28 Mar 2002 15:52:01 -0800 Date: Thu, 28 Mar 2002 23:52:01 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] URL encoding in html page Message-ID: <20020328235201.GA6665@nicemice.net> Reply-To: IETF idn working group References: <001901c1d4e5$51725050$0301a8c0@davidvaio> <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <4.2.0.58.J.20020328153022.033d1fe0@localhost> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <4.2.0.58.J.20020328163544.033e4ee8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4.2.0.58.J.20020328153022.033d1fe0@localhost> <4.2.0.58.J.20020328163544.033e4ee8@localhost> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Martin Duerst wrote: > HTML defines href or source as CDATA, which means just about 'anything > goes'. href and src are defined in the DTD as %URI; which in turn is defined as CDATA, but section 6.4 of the HTML spec says: This specification uses the term URI as defined in [URI] URIs are represented in the DTD by the parameter entity %URI;. [URI] links to RFC-2396. So the href and src values are indeed constrained by RFC-2396, even though this constraint cannot be expressed in the DTD. > > Either the web designer uses an HTML editor, in which case the > > editor should know the HTML syntax rules and convert to/from the > > local charset as needed, > > I don't know exactly what you mean by 'convert to/from'. I mean that HTML editors should know that only a certain set of ASCII characters are allowed in the href and src attributes, and if the user tries to put other characters in there, the HTML editor should convert the string to something that conforms to the HTML spec (if it knows how to do such a conversion without changing the intended meaning) or at least it should alert the user that they are violating the HTML spec. Wouldn't you agree that an HTML editor that puts non-ASCII characters into href and src attributes, in plain violation of the HTML spec, without even alerting the user, is not quite living up to the name "HTML editor"? Because the thing it's editing isn't really HTML anymore. > You seem to imply that the HTML editor is checking or should check > the URI syntax, and that they could be upgraded to add a legacy > encoding->Unicode->ACE conversion. Regardless of whether today's HTML editors already check URI syntax, they could be upgraded to convert IRIs input by the user into URIs in the document, and that conversion could involve ToASCII. > If you enter hppt:something, should the editor tell you this is an > error? No, because it's not an error. A warning might be helpful, or might be annoying, just like spell-checking. > Similarly, even if the HTML editor does the very limited checks that > RFC 2396 allows, this doesn't get it very far. For example, while > http: uses generic URI syntax, mailto: uses opaque syntax, so there is > no general way to know where in an URI there is a domain name. This > includes the case that a domain name is sent as a parameter. True, the editor can't be expected to know the syntax for every URI scheme. For the ones it does know, it can fully check the syntax. For any URI that begins with / or scheme:/, it can check the generic URI syntax (which is quite detailed). For opaque URIs with unknown schemes, it can at least check for characters disallowed in all URIs. I think that gets you pretty far in practice. The vast majority of opaque URIs could also be handled if the editor knows just a few schemes (mailto, and maybe news and telnet). > HTML 4 already says what a browser should do if it finds a > non-ASCII character in an URI. Please see > http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.1 > Appendix B.2.1: Non-ASCII characters in URI attribute values > (this is supported by all major browsers in newer versions) It says: Although URIs do not contain non-ASCII values (see [URI], section 2.1) authors sometimes specify them in attribute values expecting URIs (i.e., defined with %URI; in the DTD). For instance, the following href value is illegal: ... We recommend that user agents adopt the following convention for handling non-ASCII characters in such cases: 1. Represent each character in UTF-8 (see [RFC2279]) as one or more bytes. 2. Escape these bytes with the URI escaping mechanism (i.e., by converting each byte to %HH, where HH is the hexadecimal notation of the byte value). This procedure results in a syntactically legal URI (as defined in [RFC1738], section 2.2 or [RFC2141], section 2) that is independent of the character encoding to which the HTML document carrying the URI may have been transcoded. RFC-1738 section 2.2 seems to say that %HH escapes are allowed in the host part of a URI, but the BNF in section 5 clearly prohibits %HH escapes in the host part. And RFC-2396, which is a normative reference of the HTML spec and which updates RFC-1738, is unambiguous in its prohibition of %HH escapes in the host part. Therefore, it is not true that "this procedure results in a syntactically legal URI". I suggest that the procedure be ammended so that it does result in a syntactically legal URI. That would not be a serious change in the HTML spec, because the procedure doesn't even apply to valid HTML, it applies only to invalid HTML. AMC From owner-idn@ops.ietf.org Thu Mar 28 19:18:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19842 for ; Thu, 28 Mar 2002 19:18:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qju9-000LRb-00 for idn-data@psg.com; Thu, 28 Mar 2002 16:06:05 -0800 Received: from med31.ndl.net.nu ([216.133.64.31] helo=Thinkpad) by psg.com with esmtp (Exim 3.35 #1) id 16qju8-000LRU-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 16:06:04 -0800 Received: from Thinkpad.mail.nic.nu ([127.0.0.1]) by Thinkpad with Microsoft SMTPSVC(6.0.2600.1); Thu, 28 Mar 2002 19:05:46 -0500 Message-Id: <5.1.0.14.2.20020328184520.056f9e70@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Mar 2002 19:05:45 -0500 To: "Dan Oscarsson" , From: "J. William Semich" Subject: Re: [idn] URL encoding in html page In-Reply-To: <002c01c1d5b1$77369cc0$6701a8c0@davidvaio> References: <3CA17929.72D92BD0@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 29 Mar 2002 00:05:46.0492 (UTC) FILETIME=[79DB3BC0:01C1D6B5] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA19842 For anyone on the list who would like to see how Verisign's ML.com domain name registrations can work right now in a lightweight URL-based system (which is what most users want right now anyway - not "domain names") using any local, UTF8 or ACE encoding, I've set up a demonstration of all of the multilingual domain names registered by Verisign under .com up until Nov., 2001, which currently resolve as bq--??.mltbd.com in the Verisign name servers. These will all work as ML URLs under the .com.nu domain. So the domain name alingsås.com, which was registered by Register.com for one of its customers, and which currently resolves as the ACE domain name bq--abqwy2lom5z6k4y.mltbd.com to the Register.com "parked" page, will also resolve to the same parked page if the URL http://alingsås.com.nu/ is used, whether that URL is encoded as UTF-8 UNICODE or ISO-8859-1. The same holds true for the domain name l’esprit.com which was registered for a customer by WorldNames and which points to the WorldNames parked page either as bq--ed7wygp7mx7xh73q75zp62p7oq.mltbd.com or as http://l’esprit.com.nu/. Also try the NetSol customer's URL, http://wörterbuch.com.nu/ . I'm not reproducing any Asian, Arabic or similar URLs here for obvious reasons, but anyone on the list who knows of an Asian, etc., .com domain name that was registered before November, 2001, should feel free to test the system using any local encoding as the URL (not just ACE and not just UTF-8). Note that the RealNames/Microsoft "error" based search tool does not get into the act with these URLs, since there's no error for it to respond to. These also all will work for hypertext links on a Web page, using local language encoding or UTF-8, and can also be saved as "favorites" in IE. Bill Semich .NU Domain From owner-idn@ops.ietf.org Thu Mar 28 22:07:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23370 for ; Thu, 28 Mar 2002 22:07:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qma6-000OiS-00 for idn-data@psg.com; Thu, 28 Mar 2002 18:57:34 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16qma5-000OiM-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 18:57:33 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id LAA00500; Fri, 29 Mar 2002 11:57:25 +0900 Message-ID: <0c3d01c1d6cd$676a3d20$a303a8c0@bruce> From: "Bruce Thomson" To: "James Seng/Personal" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 11:57:03 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > So why not make all 128bit (or more) clean? > > -James Seng > Granted, such 128-bit characters might be useful. This would allow various organizations to define their own characters sets. Space in the global character encoding space would be allocated in the same way as IP address space is allocated under IPv6. But to conserve file space, it would probably be best to allow intermixing of 128-bit characters with ASCI text. UTF-8 continues to be the way to do this, since it just a compression scheme that does not really depend on the fact that Unicode is currently limited to 32 bits. It could just as easily be extended to work with much larger character sets. Bruce From owner-idn@ops.ietf.org Thu Mar 28 22:22:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23603 for ; Thu, 28 Mar 2002 22:22:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qmso-000P97-00 for idn-data@psg.com; Thu, 28 Mar 2002 19:16:54 -0800 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.35 #1) id 16qmsn-000P8z-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 19:16:53 -0800 Received: from cnnic.net.cn ([159.226.7.66]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with ESMTP id GTPT5500.V06; Fri, 29 Mar 2002 11:17:29 +0800 Message-ID: <3CA3DC3F.17C36B98@cnnic.net.cn> Date: Fri, 29 Mar 2002 11:15:11 +0800 From: "Sun Guonian" Reply-To: sun@cnnic.net.cn Organization: CNNIC X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN,zh-TW MIME-Version: 1.0 To: James Seng/Personal CC: "David Leung (Neteka Inc.)" , Edmon Chung , IETF idn working group Subject: Re: [idn] URL encoding in html page References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> Content-Type: text/plain; charset=UTF-8 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA23603 James Seng/Personal wrote: ... > > you can justify why designing a system that can handle ASCII as a fallback > > and can automatically support 8/16/32 bits Unicode is not a good design, > > then I think my thinking is wrong. > > The question is really why 8/16/32 bit Unicode is better than 5bit (ACE)? I think the former is based on character and the latter is based on string. Maybe it is a advantage of the former for design many Applications. > > 8 is not neccessary better than 5 just like 32 is not neccessary better than > 8. It is all engineering trade off. > > So what is the advantage of moving towards more bits? And how much more is > enough? > > ps: I am not agreeing or disagreeing with a transition. I reserved my > judgement later. > > -James Seng -- ****************************************************** * China Internet Network Information Center (CNNIC) * * Sun Guonian No.4, S.4 Street * * Zhong Guan Cun * * Phone: +86-10-62619750 ext. 3016 Haidian District * * Email: sun@cnnic.net.cn Beijing * * http://www.cnnic.net.cn/ P.O.Box: 100080 * * Öйú»¥ÁªÍøÂçÐÅÏ¢ÖÐÐÄ Ëï¹úÄî * ****************************************************** From owner-idn@ops.ietf.org Thu Mar 28 22:50:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25369 for ; Thu, 28 Mar 2002 22:50:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qnGD-000Pgv-00 for idn-data@psg.com; Thu, 28 Mar 2002 19:41:05 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16qnGC-000PgV-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 19:41:04 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id MAA00683 for ; Fri, 29 Mar 2002 12:41:03 +0900 Message-ID: <0c4c01c1d6d3$801fb650$a303a8c0@bruce> From: "Bruce Thomson" To: "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> <3CA3DC3F.17C36B98@cnnic.net.cn> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 12:40:41 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The question is really why 8/16/32 bit Unicode is better than 5bit (ACE)? ACE and UTF-8 are just compression algorithms that squeeze larger Unicode characters. ACE is more efficient than UTF, although more complex. But the claim to fame that UTF-8 has is that it is a standard that idn can reference, and it is coming into widespread use elsewhere. So moving to UTF-8 long term seems like such an obvious choice is surprises me that it even gets debated. Of course, Punycode is a nice compression method... Maybe we should take it to the Unicode forum and suggest that it be the next version of UTF-8? But if that doesn't happen, it should logically be phased out. Bruce From owner-idn@ops.ietf.org Thu Mar 28 22:58:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23371 for ; Thu, 28 Mar 2002 22:07:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qmbL-000OkR-00 for idn-data@psg.com; Thu, 28 Mar 2002 18:58:51 -0800 Received: from smtp21.singnet.com.sg ([165.21.101.201]) by psg.com with esmtp (Exim 3.35 #1) id 16qmbK-000Ojv-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 18:58:50 -0800 Received: from jamescompaq (bb-165-21-94-167.singnet.com.sg [165.21.94.167]) by smtp21.singnet.com.sg (8.12.2/8.12.2) with SMTP id g2T2wh6J031713; Fri, 29 Mar 2002 10:58:43 +0800 Message-ID: <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> From: "James Seng/Personal" To: "David Leung \(Neteka Inc.\)" , "Edmon Chung" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 10:42:24 +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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > UTF8 was there for the first place is to make the transition from 8 bits to > 16/32 bits Unicode smoother, so the existing 8 bits system will be able to > use it. Same as base64 is to downgrade the 8bits into ASCII to make the > transition smoother... Agree. Spend more time to think of this and why arguments on ACE vs UTF-8 is really irrelevant except religious prejudice. > So should we say that a good design should have fallback(downgrade) for > TRANSITIONAL period only. Then a good IDN design should be able to use ACE > as the fallback for old system, BUT SHOULD also be able to step forward to > use 8/16/32 bits or even more bits when needed. Maybe. > So we should not say that ACE should be a long term solution for IDN, it > should ONLY be a TRANSITION solution that allows the LONG TERM solution of > using UTF8 or 16/32 bits Unicode to work. The best way is to write a draft, explain how you wish to transit from the IDNA to a long term solution (The closest I seen is UDNS). Then gather the rough consensus so we can move it forward. IMHO, the problem of moving away from ACE to a long term solution is a smaller one compared to the problem of what is the long term solution. > More bits is good, but when we plan for things more than we need, then it > should be considered to be a waste of resource. Read: IPv6. > So why do we need 128bits > now(i dont think the combined total of characters in all languages in the > world would require that much, not unless we want to include scripts from > oter planets : > ), whereas we need 8/16/32 bits for Unicode, so why not > design a system able to accept ACE as a fallback and also 8/16/32 bits? If How many new han ideograph are created every day? How many ancient scripts not encoded yet (e.g. Linear B)? Or how about a new 128bit character table whereby allocation can be allocated to 2^64 different locale, each locale get 64bit of space to put their own encoding? (I know, sound much like IPv6). Are you in the position to predict the future? My best *guess* is ISO10646 will get slowly get adoption over the next 20 years. I *guess* UTF-8 will get more popular in the next 10 years. I *guess* compressed bitstream (i.e. 1bit) ISO10646 will see some more adoption in certain place where space is a constraint. I also *guess* there will be some initative to do locale-based table (vs script based) but they will be faced with huge barrier. But I could only guess... > you can justify why designing a system that can handle ASCII as a fallback > and can automatically support 8/16/32 bits Unicode is not a good design, > then I think my thinking is wrong. The question is really why 8/16/32 bit Unicode is better than 5bit (ACE)? 8 is not neccessary better than 5 just like 32 is not neccessary better than 8. It is all engineering trade off. So what is the advantage of moving towards more bits? And how much more is enough? ps: I am not agreeing or disagreeing with a transition. I reserved my judgement later. -James Seng From owner-idn@ops.ietf.org Fri Mar 29 00:25:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26700 for ; Fri, 29 Mar 2002 00:25:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qohe-0001bX-00 for idn-data@psg.com; Thu, 28 Mar 2002 21:13:30 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16qohd-0001bR-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 21:13:29 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16qohc-0002oG-00 for ; Thu, 28 Mar 2002 21:13:28 -0800 Date: Fri, 29 Mar 2002 05:13:28 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] URL encoding in html page Message-ID: <20020329051327.GA9491@nicemice.net> Reply-To: IETF idn working group References: <3CA17929.72D92BD0@trab.se> <5.1.0.14.2.20020328184520.056f9e70@mail.nic.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5.1.0.14.2.20020328184520.056f9e70@mail.nic.nu> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit "J. William Semich" wrote: > So the domain name alingsås.com, which was registered by Register.com > for one of its customers, and which currently resolves as the ACE > domain name bq--abqwy2lom5z6k4y.mltbd.com to the Register.com > "parked" page, will also resolve to the same parked page if the URL > http://alingsås.com.nu/ is used, whether that URL is encoded as UTF-8 > UNICODE or ISO-8859-1. Depending on your resolver. On my Debian GNU/Linux system, "dig" can successfully look up alingsås.com.nu, and so can "host" (which warns that the name is illegal but prints the IP address anyway). But the resolver won't have it: > ping alingsås.com.nu ping: unknown host alingsås.com.nu I tried adding "options no-check-names" to /etc/resolv.conf, but that had no effect. I then tried changing it to "options no-check-names debug", but I got no debugging messages. I don't know what's going on with the resolver. I'm using glibc 2.2.5. By the way, when I tried the URL with various browsers, netscape 4.x and mozilla passed the host name straight through and ran into the resolver problem, but w3m followed the unfortunate recommendation in the HTML spec and converted the URL to http://alings%E5s.com.nu/, and of course that lookup failed. > These also all will work for hypertext links on a Web page That depends on how the browser handles hrefs containing non-ASCII. This is invalid HTML, so there's no telling what will happen. The HTML spec recommends that the browser convert the non-ASCII bytes to %HH escapes, but I think that makes the host name lookup even more likely to fail (unless the browser unescapes the host name just before doing the lookup). AMC From owner-idn@ops.ietf.org Fri Mar 29 00:31:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26775 for ; Fri, 29 Mar 2002 00:31:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qopm-0001oX-00 for idn-data@psg.com; Thu, 28 Mar 2002 21:21:54 -0800 Received: from smtprelay2.dc3.adelphia.net ([24.50.78.5]) by psg.com with esmtp (Exim 3.35 #1) id 16qopl-0001oQ-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 21:21:53 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.98]) by smtprelay2.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GTPYWG00.N1K; Fri, 29 Mar 2002 00:21:52 -0500 Message-ID: <003701c1d6e1$9c16a540$62424244@anhmca.adelphia.net> From: "Doug Ewell" To: "James Seng/Personal" Cc: References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> Subject: Re: [idn] URL encoding in html page Date: Thu, 28 Mar 2002 21:21:35 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng wrote: > How many new han ideograph are created every day? How many ancient scripts > not encoded yet (e.g. Linear B)? > ... > Are you in the position to predict the future? How far into the future? Linear B is planned for Unicode 4.0 -- look for it about 18 months from now -- and I hate to say this, but Linear B fits into a single 256-character block. And the number of other ancient scripts that experts know enough about to encode is not that great. Sorry, but there simply aren't MILLIONS of characters waiting to be encoded. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Fri Mar 29 00:33:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26794 for ; Fri, 29 Mar 2002 00:33:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qorS-0001r6-00 for idn-data@psg.com; Thu, 28 Mar 2002 21:23:38 -0800 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.35 #1) id 16qorR-0001r0-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 21:23:37 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.98]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GTPYZB00.90V; Fri, 29 Mar 2002 00:23:35 -0500 Message-ID: <003c01c1d6e1$d914f6e0$62424244@anhmca.adelphia.net> From: "Doug Ewell" To: "IETF idn working group" Cc: "David Leung \(Neteka Inc.\)" , "James Seng/Personal" , "Edmon Chung" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> Subject: Re: [idn] URL encoding in html page Date: Thu, 28 Mar 2002 21:23:19 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Leung (Neteka Inc.) wrote: > More bits is good, but when we plan for things more than we need, > then it should be considered to be a waste of resource. So why do > we need 128bits now(i dont think the combined total of characters > in all languages in the world would require that much, not unless > we want to include scripts from oter planets : > ), whereas we need > 8/16/32 bits for Unicode, so why not design a system able to accept > ACE as a fallback and also 8/16/32 bits? If you can justify why > designing a system that can handle ASCII as a fallback and can > automatically support 8/16/32 bits Unicode is not a good design, > then I think my thinking is wrong. Is my memory faulty, or wasn't it the CJK users who complained the loudest that UTF-8 was unfairly discriminatory because it required 3 bytes for each CJK character, and that some sort of compression (such as now provided by Punycode) was essential to the success of IDN? -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Fri Mar 29 00:35:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26817 for ; Fri, 29 Mar 2002 00:35:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qos2-0001sg-00 for idn-data@psg.com; Thu, 28 Mar 2002 21:24:14 -0800 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.35 #1) id 16qos1-0001sZ-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 21:24:13 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.98]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GTPZ0C00.H10; Fri, 29 Mar 2002 00:24:12 -0500 Message-ID: <003e01c1d6e1$ef815220$62424244@anhmca.adelphia.net> From: "Doug Ewell" To: "IETF idn working group" Cc: "James Seng/Personal" , "Bruce Thomson" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <0c3d01c1d6cd$676a3d20$a303a8c0@bruce> Subject: Re: [idn] URL encoding in html page Date: Thu, 28 Mar 2002 21:24:01 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bruce Thomson wrote: > But to conserve file space, it would probably be best to allow > intermixing of 128-bit characters with ASCI text. UTF-8 continues > to be the way to do this, since it just a compression scheme that > does not really depend on the fact that Unicode is currently > limited to 32 bits. It could just as easily be extended to work > with much larger character sets. This is not even close to true. UTF-8 is very much dependent on the 32-bit architecture of Unicode, and in fact is constrained to 31-bit code points. A quick check of the "10xxxxxx 10xxxxxx..." chart in RFC 2279, or in the Unicode Standard or ISO/IEC 10646, will confirm that. And the word "currently," as used to refer to either the 21-bit or the 32-bit limit of Unicode/10646, is being used way too cavalierly. Unicode is not going to be expanded beyond U+10FFFD, and nobody can think of a non-whimsical reason why it should be. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Fri Mar 29 00:50:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26936 for ; Fri, 29 Mar 2002 00:50:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qpCK-0002Ru-00 for idn-data@psg.com; Thu, 28 Mar 2002 21:45:12 -0800 Received: from h00045aed6116.ne.client2.attbi.com ([24.218.221.112] helo=Thinkpad) by psg.com with esmtp (Exim 3.35 #1) id 16qpCK-0002Ro-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 21:45:12 -0800 Received: from Thinkpad.mail.nic.nu ([127.0.0.1]) by Thinkpad with Microsoft SMTPSVC(6.0.2600.1); Fri, 29 Mar 2002 00:45:11 -0500 Message-Id: <5.1.0.14.2.20020329004421.04c6cba0@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 29 Mar 2002 00:45:10 -0500 To: IETF idn working group From: "J. William Semich" Subject: Re: [idn] URL encoding in html page In-Reply-To: <20020329051327.GA9491@nicemice.net> References: <5.1.0.14.2.20020328184520.056f9e70@mail.nic.nu> <3CA17929.72D92BD0@trab.se> <5.1.0.14.2.20020328184520.056f9e70@mail.nic.nu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Mar 2002 05:45:11.0968 (UTC) FILETIME=[E4A04200:01C1D6E4] Sender: owner-idn@ops.ietf.org Precedence: bulk try the links in various encodings on these pages .... http://www.worldnames.net/pages/demo.cfm Bill At 12:13 AM 3/29/2002, Adam M. Costello wrote: > > These also all will work for hypertext links on a Web page > >That depends on how the browser handles hrefs containing non-ASCII. >This is invalid HTML, so there's no telling what will happen. The HTML >spec recommends that the browser convert the non-ASCII bytes to %HH >escapes, but I think that makes the host name lookup even more likely to >fail (unless the browser unescapes the host name just before doing the >lookup). > >AMC From owner-idn@ops.ietf.org Fri Mar 29 01:04:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27109 for ; Fri, 29 Mar 2002 01:04:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qpKk-0002gI-00 for idn-data@psg.com; Thu, 28 Mar 2002 21:53:54 -0800 Received: from h00045aed6116.ne.client2.attbi.com ([24.218.221.112] helo=Thinkpad) by psg.com with esmtp (Exim 3.35 #1) id 16qpKf-0002fE-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 21:53:50 -0800 Received: from Thinkpad.mail.nic.nu ([127.0.0.1]) by Thinkpad with Microsoft SMTPSVC(6.0.2600.1); Fri, 29 Mar 2002 00:53:48 -0500 Message-Id: <5.1.0.14.2.20020329004541.056e3c90@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 29 Mar 2002 00:53:48 -0500 To: IETF idn working group , idn@ops.ietf.org From: "J. William Semich" Subject: Re: [idn] URL encoding in html page In-Reply-To: <20020329051327.GA9491@nicemice.net> References: <5.1.0.14.2.20020328184520.056f9e70@mail.nic.nu> <3CA17929.72D92BD0@trab.se> <5.1.0.14.2.20020328184520.056f9e70@mail.nic.nu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_906173==_" X-OriginalArrivalTime: 29 Mar 2002 05:53:48.0921 (UTC) FILETIME=[18C10690:01C1D6E6] Sender: owner-idn@ops.ietf.org Precedence: bulk --=====================_906173==_ Content-Type: text/plain; charset="us-ascii"; format=flowed This lookup, using the HTML spec "alings%E5s.com.nu", works fine for me using IE - the system supports the html encoding just as it supports UTF-8, ACE or ISO-8859-X. Not sure what w3m is doing in this case. (see attached screen shot) Bill At 12:13 AM 3/29/2002, Adam M. Costello wrote: > w3m followed the unfortunate recommendation in the HTML >spec and converted the URL to http://alings%E5s.com.nu/, and of course >that lookup failed --=====================_906173==_ Content-Type: image/png; name="alings%E5s.PNG"; x-mac-type="504E4766"; x-mac-creator="6D646F73" Content-Disposition: attachment; filename="alings%E5s.PNG" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABAAAAAMACAIAAAA12IJaAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA/45JREFU eF7sfQe8HLX1tZ32z5eQAklICJAESAIECOXR0ojpHQIEAoFASIKBQOjV9N4x3TwMtnHv3Qbcbdyw H2AwmGpMNc1gmumw3913n6+vJY1G0tTdvfuTn2dnNdLVkWbmHOlKan/hhRe2y+vTvn1796wyipxR slAu95TdY3ol6xVZbKCm6A6Fe0yvuvCKLDZgxQkO0oCVt4l7k3CPmV1LExukAUsDNhJC91vDPWZJ bmR3ApxTTBAAuX0u8vlc7PO5xPlzqc/nMp/P5c6fK3w+V/p8rnL+XO3zucbnc63z5zqfz/U+n84+ nxucPzf6fG7y+dzs/LnF53Orz+c2508Xn8/tPp9m588dPp+uPp87nT93+Xy6+Xy6+3x6OH/u9vn0 9Pn0cv709vn08fn0df708/n09/kMcP4M9PkM8vkMdv4M8fkM9fkM8/kMd/6M8PmM9PmMcv6M9vmM 8fmMdf7c4/O51+dzn/NnnM9nvM9ngvNnos9nks9nsvNnSi1/2uXG/iEjH/5/kQ//v9iZ/1/iw/8v 9eH/lznz/8t9+P8VPvz/Smf+f5UP/7/ah/9f48z/r/Xh/9f58P/rffh/Z2f+f4MP/7/Rh//f5Mz/ b/bh/7f48P9bnfn/bT78v4sP/7/dmf83+/D/O3z4f1dn/n+nD/+/y4f/d/Ph/92d+X8PH/5/tw// 7+nM/3v58P/ePvy/jzP/7+vD//v58P/+zvx/gA//H+jD/wc58//BPvx/iA//H+rD/4c58//hPvx/ hA//H+nM/0f58P/RPvx/jDP/H+vD/+/x4f/3OvP/+3z4/zgf/j/emf9P8OH/E334/yRn/j8Z+X8l 6NOhQ4eg6ypwYcJ88XIRADZFIAIAdYIIABQJIgBQJIgAQJEgAoBEgggA1AkiAFAniABAnSACAHVC IwiAx+bN9grQJ44CwOsqiIwXkgBIcnmMAOB+SMnHCtxHALBI7oMAWY8AKBAbhUHZRgDQ5qgxgUJG ANAkGiKQEQAaJUgyAoCoGkcGGmEEgN+bUcMC9TQCoDyLYKzAZQQAr3IZAVDSdxwHaAQBgMjYBwQK FABoHowVZDcCgFm4DAXkKQCUFkujBDICgAMFMgKAAwVZjwCEEfGSCgCg/j9e7TuXH/cXCttsvA7q AV0JWErOI9e6AOC8Xy8yCAALDvZf4ULwC4q63OgFhJGVnzjdr0UBgDYbhUHDugAhJqQQdKIfIAD0 lgZSIX8XIDSD+whZXIAwMkVAro8nY92B8hEAxvuXRgnScgHCXLiPEAgAPGlRAhjBRQBQHLxEFwDG 8ygA8Cc6UADBOOQChL/aPYJK5QKEBqMA4MdcEiQXAJiy4iDk4gKEF1oEAEbg8sDXBQhTKJsAIMaP 5okAUByERACIAOCPYj6AYB4BGNiz+ZgDtjvnn7s83vPEV0df9NqYiyHcde6hcHLHrTeIEgCxQwT1 JABQDCCseEwUP3YogLi+MhkAU1NORs0BwMgiAIzCoJ7mAGBFpygAIDV9ZABOigBAnRA8BwBrivsF 8TMNKAD4sABpAxEAKBKi5gCIALBMCbDPARABYJwbIAKgtgRA1Po/ROItLkB4Laf7cKyctAmAzX69 1h5/2PiKY/daNPjs+T3+19yxadBZuww+e9dpnQ97fkint8dfOabzMRBhhy3X53Qf8xMBgDjkIwCM wqDWRwAsTkENOwKgeAclHAEwsn/UA+4aoJA5AHhzlX8EQJkYQBogUwEQ6wWEZuQ8AqD4BaEN9SEA ohyBko8AGIWBjACgKhABgBOFZRIwThQu1SRghXbHfo2aA5BcAHANQKkZ9cOKEYD1f/7jjdf7af9L j3jz3sseuO3ft/5r0+sP3fDaQ9Y/esuvdGxq1+N/v7/3sgOmXn/owoFnfjLz5kd6n8l9gewCgH7l IwB4ks5wsOAkfqU5AAqUynn4ShFoMoByCZ0PWwUIU9Nd//n5wkcAeJFBCeBX/QDPR80B0H+FM3wS MEagMwrOcB5d/PE8HfBjPgcAoxHv51/pmGehyADlJ/wKcYwjADwyRMCvdABzfCkCrQuklI4mAeN5 ZU4wncQD8O/nl9sXBbLMAcBE+AgATxb0AH7VD/A87+znX5WioQsQnOTjAEoc+gnPgwzgEbgqUC6M WggIo/FflQuJ7ivn4Sv5/9BPUY5AyrXkDoTn4StFoBEAfgkMCOBXfWQgiusbBwG4AFBMUrQB/hq1 EJD+q9EFiGdBEUAA4Hk6oK+6NsCfkrgApSsAFNDIOwjPw1ceQVkRSPmJVgFS0lRWB+K/Km4/+JPi DsTjK0pA+Qm/Grk+/4mO+eVRYgDjwK88Mjn8KCWFr/ATngRHIP4r+gXpZ8DzB08aXYDoJ36hMhNA sYF+RXLPf6WvNBqgXGtUAhhHXIDEBcgoDGplDoDehQ+tmp+0TwLmjF9n/5CUYQQA4i0cfsmns26Z dM3B3Y7b9o6jt7z8gHWA9yvhtn9v9uyAM14Yes4Vf98kRQGA960uBpDo46866ee8n54OSPTxqyIG 8Gu9CgAsMo0AECAkAPRfjRoAL6SfKB2F8eNX/FX5iQsA/tTmqoDH4b3+GB/P0LX4FWg9niENYPyK EXQBgJHpPCVOAoCbigIAzyhiAEk//mQXABCBSD/Gt2gAdwGASdE4AJlNAkD/lTr4SQzgVXQej5Hf wzEd0DGeV36Cr0T68Vf8yo/hK/B7OGPUABiTfsKvCumP+uo4BwDT1Ek/5/2EIUbDr0T36de0BAAm SKRf+Qrn8UwSAYAp0LAAFYHzfsXXv+QCAIugk37O+4n0Y2TLVyT6GE0RA/pXzvIhvj4HgOClVYDw DGkA41c46SgAICaRfkzKqAHIDIX0R30lAQAX0mQASkQ5A19dBABcTqsAYVLE8i1fLXSfawMaAcCk dA2gnJdJwDIJmCuB8gsAS9+/uwCAu0BJh25qPDALgDFXHvrgHUe/PvaSj2fcNOGqv2HHvxIGnbXz 0/1Ou/PYrY0CQMmGMqMD4wgA/qpMD8CTOvtXJAFFi10FCGPmIwCMOHC/IPscAP3y2EnAeAlEM7oA 4a/KckB4MlYDkDE648eflBVC8aTO9ZVhAYqg+Pzg5VwAUATk/RhBFwPKr4oAwKuiTuKvym4AlpOO AkCh+5hglAZwFACYiOIFRCf1X9GxBwIeKIzfIgDwKmVWAJ3EA8URiE4qv1r2AcCYGAGPlUnA/KQS wUUA4CUQk08CxpNE9JX5wfirwvWNJ/VlQDGa3QUI4xi7/BVJECwAMAvFKQhP8hEAzvjpV/1kGUYA 0DxlQjCdpAPe648n4Qwd8F919q9IArwKT5K3D56MEgDKMqAYGTQAHfAxATzpKAAgGmf8eK2uAeg8 n+aLJ/EMP+Zn+FRgjGM84yIAaHAAeT+mFrUiEP2KB4rrP53kv0bN98XzGFNGAGQEoEZHANISAHAX GPv+8QYxC4BRlx/S0txx3l3/Bdd/YPkvDT+vpfloLgCGnbv77Fv/1eukP52z/wa/XOuHJ554Ijn9 U7rGaQD0a84CAPPlwSgAlDh8iIB8fjBOaV2A0LzUBQAmCyIBD5QufzqpOwjFCgC8Vvf45+eVOCIA QCQgJjUhANBUHAFwcQHC+HUmALBQKAmQ3+MZuwCAXy0bgWEKllWAMELZBABaFbYKEF4rAgBJP6JR owIAjeeBdIIIANkIDLcLqNGNwPS2bT+jzwGIcv6xzOI1riIaMgKAAuDOY7e5eN+1+57a4am+pz7Z 55RHuh0H4aydfzDi/D1hAkC/07Y/Za9fbbvxOkcddRTQkdIKAMSdDwvQmbp0AcLS1YoAoLtCBIDL PgAIFw4R4HHJBYAyNwAMdhcAxicmqgL8yWsSMF6S8wiAUgRlGVDLK4GrgvoQAEphg5cBtYBGLkBw ICMAKAzKOQKAlchHA+gMHtgFgLENKF5AGEdGAGQEoHZHAPR2rquCTOYAoAC4/4Z/TL72EPgLxw91 Pea5QWfhGWD/A87Y8YTdf7nT1hsedthh559/PjhUlVMA6OyfzwoQAYC+QIiS3QWI4uBBiiMA4gKk +ALVkwuQMjEAG0/sHACF3+sbAtSKALAvA4qliF0RqD4EQFrLgCJoUXsC0K8iAEorAHT2zx2EXASA rALExwdkFaCSrwJkdOZRyL37CIDxQuNOwLrnj+sqQIfvsulxf9lq3A1HvTLygpdHnP9M/9NBA4DP T9djtpp+4+HQ9w/sf7ffb3TooYcC+588ebL7MqBoPcTPxwVIBACn+HwVIH2GgH0tIFIIRP1RBhhn APOTsS5A7pOAG2EOAN3eRhmAv6Y4AsAnBvBjywxgZVowmhQ1B8B4njv6K7N+LXMAuAxwFAAYTZkh kOIcAKqsFOcApLsKEFpYNhcg2h0sYBlQEQC1PgdABMAYh4+4ANWNC1CwAHC/0CIAFMHgtA8ARvrr n39zyb+2H3rZP14cdi4JANgN4JQ9f7XTNhsefPDBnTp12nPPPRVff6L4UVsBYAR9nR88E/Wr4ypA EM3o7aMvCZrPJOB89gFA0Gh+MH61rALkPgmYnP7tAsBlFSBa8VOfBAxnaKkf+zKgtAqQMvcXi6ws CoRnAlYBUiYB21cB0ucB0y1HP8EZx1WAOMXXNYDyK361rALEHYR0rq8sBARJURw41tcAVZb+5EqA awAuCRRtgD/FCgDjPGC81ssFCC+hJUHxq2UVIH2TYLwkahUg/qvLMqAQBy+JXfYnrUnA+qqg1DhT mQQM04IxQT4/mG8DrBzr4wCoATARx52AMTIfBKAzdGAcAdDnAUP8LFYBipoErM8Dpuqov0nAUDTj KkBYZN3/B0/6rgKkz/eVScCWMQHZCKy2NgKj50PUgd0FyOtydSdglAF/3vTnXU/bu1en/XAEoNN+ G2y7yTqHH344sP8dd9wxaidgY8aKmxDGsZB+/qv7PgDKKkCKJVm4AOmFpX0AjDi4rwIUvBMwz9e4 D4DvCACND8R2+VPW+j4AXANgNL4PgKIBMILLKkB8TjBexeVB2D4AURqASmdc9xN/5ZIAz7jvA4Dx o7yAlF/5cp/wk3EfANIAigDgawHpmwHrOwErLTn5PgCYoHEEgCsEnq8+CIC/Rq0CxH/lcShNoxjg MoAW/sdLlH0A6KTjCACKBLxKofi8mPouAcGrAGHfP0/cuA9A8CpAyPuVtoFfiesrX40awJgCnOSS QGf8/Cr8Fc9EzQFAVcCvgq8Z7QNAy4BaSD9YQr/mLAD4up9gBt8HQF/0M2wZUFopCAE3Mn76iQ4C 9gGAa2UZUEdHIBEAIgD4A9C2EzDxdZABP1v9u8MvOejKQ3/7y7V+9O9//xso7KxZs2K3+7VEUNb6 tH8l9u9yELsMaEYbgfF1gWI7/imCQvHtX41rgEadVLr5LV+jnH+M55W1Pu1flV5/y1fLvr/6Ty47 AWMrj9oILGoZUJ33R51RBEDUVzTDvvMX/xXjW6YB8J/0nYAtZ3SWb9EAugCIOoMGO+4HbFkFSP9J d/2POhO17ZfxvN7Nbzmjr/fPSb9FACgDAsrXWL//JJOAY3cCxgip7ASsLwwKZ5Q9vyxf7V3+yq9R fv/G88rmX5avyoZf9q9Rm/4azzvuBIytyCgAgncCJjchPgnYfsyX+4w9Nu7/RSexRMoyoFELgCrn lem/ytr//FfZCVh2AuZrBJVqJ+AAbtyhQwdYxifsQnIBSnK5OgKgpIUDArDiJzBO0JEBOfFLRACg BhABgKogoQAguq+sEOruAoSSoFgB4MX+QQkkFwDc54c6BmgjMBcZUN8CgFN8S/e/PgIgAsBFBjSg AMAWpewL5s7+lX0AonYCrmkBgBAp+/7qwkAEgAiAcgoAoPI5f1AABGeKl8cIgISMX7m81gUAsSV9 QwA4IyMAODKQ5wgAH9jCvn/8xLoAQWSK04ACwDgy4EL9+RyAOh4BUNqVMh+AvtoZf6YjAGQheAo5 dv87jgAoZTf29+snXai/sgyoixKomxEABVUQAyIAaBxAdwHiYiB2BEDBVpYBlWVA818GFPl0zX1E ANjWBTUS/aiTIgDyFwBRfkFGARB1MnUBgK5B7i5AENPR/yetEYCEAsCR+mO0OnAB0p2C8EwhAkCf G5CuACA3IUfqj9FEACiTgGN9gepMACgOQo7OPxjN6AJkPGkfAVB+HenzGeX8Ge3zcVj7Z0UUWQWo dlcBqjnq3zYCoKhn+SoICAKCgCAgCAgCgoAgIAgIAnWMQLs6LpsUTRAQBAQBQUAQEAQEAUFAEBAE FARWEgDGPQiUk4KgICAICAKCgCAgCAgCgoAgIAjULgKqAJgxY8bzkZ8phx22BxRV2VesdgsvlgsC goAgIAgIAoKAICAICAJZIAALfbp/cGFQ9w/ER5vdL4GYdJUqAID8w5xIWPTzyy8XKOHFmV0O3q1p pw02mHbccYN32glkQBhYsDRQ2IW+V+WWkcUwtKEMlviiV8fxjZvT1WJ5C2lXhWRqrx0xqRZbr9gs CAgCgkDdIwCE27GMuEWXb3wSAF65YGSDAJg7d+SsWX3Hjbv1kEN25WGvDr9de/Xv/ny11Q7ZfPN9 f/7zqMyi9gmml3Qqb2uX3Yj1HAOyxoyUwhpP8jhK1gH5OtalkmmAqQEZZXSJcc3Z1PPKri4U+1Ox 3G6tb1lSQdg3Ux0HJYWor+4ZuccMrhTjnRWr/IOzkwsFAUFAEBAE6gABX0KvxNc98wkTFAwpC4Av v3yiUmk55pi/7bHHHp9//vmH7NOxY8enhhx0yqGbWLr/Y1/GsRFcqtwlEd93tjHfMAHAawiOXax1 KbU9TkJTkxuQVgqZwpVR4qk0Nl8Ag8sSfGEqjdlRALijkaQ4jrn41m8OJjlaLtEEAUFAEBAEikIg fwGge+nzM1w2GEYAUABssMEGIAA+++yzt5d/YInWk485qM+lO9jnAES9+eg8P6AuSd+6seTCuzkx WYysn3fJlK6N4vTGZJXCKgbwpBQEeLl8OUSwqYpy0CslqoxGqIPrVEFYB9zScmIRppbAzbM3FZfm EWWz0Xilcl1wtt8svi3EYm1sFevXBle03siNzZ63ZztWsQ2DPwf0Y5eK1qF2qZqoZumSo8QRBAQB QUAQqHUEkgsAjgDvfIf3S9QIAGfpCmPnV+kC4MmP3pn1wZv3br3ZRigA3njjDZgZfP/99//ud7/r dORmN5+1/RprrBEwAmDkxLH8KarujdRHOankSErAqz3FsmqeWlSOOsPWjbHj42Kz3VQjOI5UTC9j bGphaBvJmYKeAgXnWFEijRuj1xHP1J6XpRaiuLh71bs0aQWftASAV21GNTOXJhpFxO0CwN5KqXJj S2HMxdHsKAFgf+YYa98xR4kmCAgCgoAgUOsIBAsAo/OPowAA0PjlCoWLnAT86KP95/Q5fXLnI076 67YoAGBa8Jprrvmd73zna1/7GqQIJ2FHVbsAwNcefYysJerF6VjZShY6KXHhfC55RfFyO12Lukrh mhbxEMDt7KbG0iMj+dYhskCdsE4V+h71NUoA6GA61pGlUlxaCLfT0uxjq752BYAXSvanQVpcX7/9 ebsNu7kCnjlp3REBCMslgoAgIAgIAoUjUJQAIA2gU6ZIAfCd73xrlW/937e/+fX/+/pXUQAsWbJk Uetn++23B97/yCOPxAoAI+I6PTXqBMfacmFLSo6cEzjmEkUjlPNhasdCDgIISqypRvqCV+FHJ7IW ahslJ5LUqbsA0HOJAtNYOuKgsem4txM9pl0pOWbN23CsunC31k5MLZYbW757vkoV2+m+HUCeqYvB PE7A/aVfQgka27zdpADE5BJBQBAQBASBmkMgiQDghaUeff4atUwC9h4BUJBFAfDiiy9utdVWG264 4SqrrHLKKac888wzaQmAJBVpfIVbWCBxPt9MdY7Ck3LMMYou6ySGCFZCjmKnVkYQLBTHkWwF2Oxi SRK2qosKTqmjWLtvI7GUwqXqLY3ThdoGWJsE0qh24mWGXi6XM1F3hwtK2QkA39r3AkoiCwKCgCAg CNQuAikKAAUEeKmlOQfAKABef/31QYMG9Wv9zJs3LyMB4MsdYwUAdssp1Mo3FyIcOkUz8pWoHF1Y oHJtpqYaiZQLAyNUFYFhZ2C+t64LPaUasWStqyBeoS6V4m55FC12ycVYhCidaWzY7nYaxYa7kZaW 42WDY2NTbsCo3GObn7ElBBjML3FXHXRVwE3tZaREFgQEAUFAECgVAlwAWNb0xLcb3wdA8bTXHe+j BEDgKkBGAfDKK68ce+yxR7Z+Ro0alZYAwNLSx7fC+LUKJdJJqpGtOuYY9c7mfN2SI7EEY2H1k0mY irupOiDuZ2ILHlynUTzJyK0VzI0UlrcxY+J2/B1bCE/ZmKBj1RvviFi0fY00CoComzHKckqE33q+ lhir1YthG+87Y/NLcltZEFNw0HNRHlO+EEl8QUAQEAQEgZpGIIkAUASDggO8X9LcB8AoAGgZUDyI FQA1XVVifBgCUdojLLV6ukqQqafa9C2L1L4vYhJfEBAEBIF6QiDYBSgWhGwFwG677bZs2TJYBYh/ 5s+fb58DEGu0RKg/BIToRNWpIFN/rd29RFL77lhJTEFAEBAE6g8BEADKULDlK7oAecVHxMKuWmkf AAX6P/7xjw888EBv7XP++edblgGtv/qTEhkRMPqHCFYKAkIBG7lJSO03cu1L2QUBQUAQAE6f6QcR 9s0Cr7IJAH2+QtS6QlLHgoAgIAgIAoKAICAICAKCgCBQEwjYBEBNFECMFAQEAUFAEBAEBAFBQBAQ BAQBdwREAFTHQSQIAoKAICAICAKCgCAgCAgCDYJAO/fZBhJTEBAEBAFBQBAQBAQBQUAQEARqHYF2 MHdYPoKAICAICAKCgCAgCAgCgoAg0CAIiAuQ+P8IAoKAIFBLCMjiQg0yQC/FFAQEAUEgOwRWCABU PPhq4cep5w1ZuO+MkHruLglmamGmibuUTuIIAqkgkGlLlsQtdSQCIJUGLIkIAoKAINDICKwkAAAI EgB0nDo6mb7aU7E2UwszTTyV4ksigoALApm2ZElcBIBLI5Q4goAgIAgIAmEIiAAwDP3XLvkIawRy lSAQgEDt3ia1azlWk4wABDRXuUQQEAQEAUGAI+AhAL62/MOvh3PwNurYsePIkSMdkTW+fZuaOlqC Y8r2RPiv9gRd+AGhEXUQlYVL4vq1lUrgbI1UuEIqiUChACvHqqRoetZpGeNrSTnjF7g3X1hLdoSx XhPv2BHWXQi8ly03hSOqEk0QEAQEAUFAEEAE/ARAS3MTBKJxyH1XX311PFhrrbXOPPPMWGSjBABN uwamDsfI1/EgNk2MQJcol+NXnn4qAgATbGmpQNnhfx4sTNeL2SBXaGkG41vQZjgDXx0BwTWqEs64 SCURNBjbiaPxEA2zVhi/fsY9wWJjIllP0QZ9r+4UE49NKnnTsmRRqsSxm8Ox6UZZjvcyCQBFCTS3 a8YQCzveFy7RJI4gIAgIAoKAIBCFQIgAqLR0RCZXqTTDX+j+33vvvakj/Lbbbgug15zuE1kPEABR 1F9JP8BC5ZLW4lfZvyIA2lUXVm1JSwAg9W/9W62pAPZPHNpIpmNvDP1yL/6NtIl/EK7YfDn7pxwV Y1wSKVUc4utglXLMz7iLBK4oUlEXVF8uuFk4OlRxu3YXxoa0bhMXa3kcL3WBRsJt+MYbb7g03ajE kfErf9Eqov6OGkAEgG+NS3xBQBAQBAQBBQE/AQDvPxgBAAFQDZVmFADwGTLgBnABAuqPSqCpqcki A6JGAPSOf+xih/Mu710omDEF/WTskIILP4gSADgO4MtsFJa8EmNuZf+YrG/ff3L6HpWCCwVBNtmx YzOE5uYWCKiXHDWAJeswMcObvmOLinpeKPVV1GMlWABY2hv/KVgnGwUA3MsgCfhf39vEXh3uteBy g2Nqrbd59dZrvSTm1sZLLIkj+29NxzwQJALAvRIlpiAgCAgCgkASBDwEwIo3oiYA4DW5yiqrwFBA a1dZtYsX3IGizIoSABYXoEpLm9KwF9XoAkQqgiuBYGaDnAA/fARg+Zk2RyBfZkM8Y2VXojaugOMA yBss7IEKlQp1TpgIZ/9hGsDFABcdotd1Vcc6D0QYm0qrsGnTM75awr2D3/3G1n2B7AMCEe2tKlyp BcaWyz4C4FJ9vreJsSqrtbmkAoFuzFjcHAWAjlIsJlECoPXObfP+xw4CfgYNdmT/mEVsGSWCICAI CAKCgCBgQSBUALR2/9MIAL16gffDB75efvnlvgLAMoW3yoBbmmNlgPskYPuL3M4PsLDE/4BKwrHC FXyZDV4OMyiqpHL5dAIoNQbi/XTGiK0L5eJxMk0Ex230D44DKOezs8RIGZuhKTkPRFgEAKbjQgox EaT+Rkcg4ut24h5F9OH8lClToJ3g3wvB+8Y630Bvb8bKCtbJremv9OHp0w++twm3BxNE6g8VgYEr AYvxLgIgjP1HCQDo+8eA9zIazy10Z/8iAOSNLggIAoKAIJAcAT8BUH0psu5/FADY1wvuKfB3yrNT 4O8RRxwR8PbFlyIS/eaOTRg6NrWDsIIKL5cBUemnkkgUP+CJwzFqAGT/+sdL/+hsgw0FVIuP3v80 FTgVxmycHOyrIqISQQGgz40GAaCct7BASNzdHpe5zlhrbWQxgQbg6VjsT35/KikAq1eINX6F8wQU CgDUAJbbRK8aHLvjf9MSAJBs3znvUMBcMCOv2wQj472mUH/SACgD8K4MSJxnwRsqPehi69SiLmgO AOEcm1rUnR52oVwlCAgCgoAgIAggAh4CwEhz6b0IcwDgGAVAAG+Iov4oAEgGoDaIyiKVRMB44ytc TxxZYPWvs4W2xFdeR4j7/NBUYGQkFlrjTpejaIpXCpZESADwYQ1sQlg0mC4SO2Ea4XL8xAoAasCt cxLaOu/xpO/jAKsetUTA5ZSd78xdFAAIe2tfcttfFAC+IwDKulWKAEBhH6DkkaPzbn7O/vE4lgFb RDghz0k/6Tr8FR9HAQKA2gO2Omyu+JSjM2Gw8FWACB9KSkYAfO9BiS8ICAKCgCCQBAEPAaBkA68u XAAUX5PJBUCbu0trHz/n/XRMIwNJCizXCgKCgCAgCAgCgoAgIAgIAuki0KFDh3QTzDS1RAIAe3l1 F6CwEQDy8yGPfy4DiP1jn5nREUJOCgKCgCAgCAgCgoAgIAgIAjkjAGS4gQRAFiMA3Okf5wPAGc7+ cXpxrL9HprJJEhcEBAFBQBAQBAQBQUAQEAQQgcYSAFmMACDpp9EAoP8K+xcBIDebICAICAKCgCAg CAgCgkB5EGgsAZDiCABUIU6/o5kAeEDLAcFPQP1pdVEaAfjWL/+bZvjVf79dDce1hV8ft0pbOH6V Xx+/yvrHf2dF+N93Nvjfd3nY8ITvbnjC9yj85oTv/ebE71PY6MTvb3Tiqhud1BY2PmnVjU9arRpO roZN2sIPNjn5B5uc8oPftoUf/vaUatj0VAw/grAZhtMgrA5hcwqn/3jz03+8BQ9n/KRppbDGlmes seWZFH661Zmt4SwMa25N4ew1tz57zW3OXmtF6LTWtp3W5uF35/yMh9+f8/Pfn9sW/nDuz/9w7i+q 4bxq+GNbWOeP563zx/PX+VNbWPdP51fDdhdgWA/DnyFcCOGXGDpguAjCryBsT+HiX29/8a93WBHW 3+Hi9Xe8hMIGO16ywU4QLsWwIYSdMVxWDbtc9psV4fLf7Hr5RjzsdsXGPOx+xSa7X7ki7HHlJntc +ds9rmoLe1712z2v2rQarq6Gvaphs7ZwzWZ7V8PmFPa5dvN9rt2Cwr7XbrHvdRCaMPwFw/VbQthv Rdhqv+u32r8zha3377z1ARBuoLDNX29oDTdi2PZACjdte+BNvzuIh5t//7eVwh8OvmWlcMgtfzzk 1hXh77f+qRpuawuH3rZdW+iy3WHV8GcK/7j9z62hA4bDITRD2B7DERju2AHDP9vCjv+8Y8d/dt3x yBVhpyO77vSvOyns/K87d/43hLsw7ALhPxi6QdgVwlEUuu92VPfdOrJwdI/deTimxx7H3L0iHHv3 ntXQsy38t+debaHXXv/ttddx1bB3W+i99/HVsA+F//XZ53999qVwQp99T+j7Fwon9v3LiX33q4Z+ 1XBSW9j/pH77n9R//5PbwgEn9z/gFAgDMPwVwqkYBkI4EMJpFAYdeNqgg07nYfDfzlgpHHzmEB4O OWvIIWcNpfD3s4e2hmFtodOwQ9vC8EM7DT/0nOGHrQgjDjt3xD8onDfiH+eNPJzC+SMPr4ZRR2C4 oC3884JR/7xg9D8vbAtHXji6Gi4ag+FfGC6GMBbCvzFcguEeCP+BcCmFe4+69N6jLlsROl52X8fL V4SjL7/v6CvGrQhXjjumGsa3havGH9sWJhx71YRjr57w3xVh4n+vmXgcD9dOOp6H6yYdf93k/1G4 fvL/rp98QjVMqYbO1XBiW5h64g3VcBKFG6ed1BpOxnAThPshnALhZgrTT715+qm3rAin3TLjtFtX CqffNpOHM7rMPKPLLApn3j6rNczGcFYzhQfOan7g7Dt4mHN21zmdeLhz7jk83DX33GpoqYZu1XBe W3jwvO5t4fzuD1ZDj4cwXIDhbggPQ7gQQ08M8y7C0KstXNzrkWrovSJc0vvRS/qsCJf2efTSvvMp XNZ3/mX9IDyG4XII/TE8Xg0DHr9iRVhwxcAFV/Iw6ImreBj8xNXV8GRbGPLkNW3hqWuGPHXN0Gq4 ti08fe2wariOwvBnrhv+zPUURjxz/YhnO1MY+Wznalh4A4ZRbeHGUc/dOHpFuGn0czeNWUTh5jGL bh4L4XkMt0C4B8MLGG69l8KLt9774m338fBSl3ErhdvHv3T7+JdXhAkvN1fDK21h4it3tIXFd0xc fMekxV0pTH616+RX76Qw5dU7p7x2F4Wpr91VDa93wzCtLXSf9kY13N8Wetz/Ro/73+wxvS3cPf3N apixhELPGUt6zoTwFoZeEGZheBtCbwizKSztM3tpnwdWBH2tiBo6IyMAK5YBDZgDQJdwGUACQGH/ 3AVIYf+w5gzqBMvHJhhEAFRlgAgApgFEAIgAEAGAGkAEgAgAEQAiAEQAsFWtUaU0ogCAEYAePXrD qAdsAgCrAMEaoMHLgCqagWQALvrJ+/4xZtQIAAgAy7QPWP0RPgceeGCkBhABIAJARgBoEEBGAKqD ADICsHwQQASACAARACIAshQAYdN2Yept8IXI4BNe3nACgJx2aHl1xyXVLRvlGGWAzv6dBMBn71S0 gAIAzkdqABEAIgBEAIgAEBcg9AISFyBxARIXIHEBytEFKGB9F/S8D76QBIDvXALMt0FHAHzBovju AsCSRfwIQCv7b9exBQIpAeD98Gla/jGMA0QIAFSHhcwBIGEqcwDqbA4A73KQOQA4EyCLOQCI8+4y B0DmAMgcAJoGIHMAqtMAZA7A8mkApZkDEMzjgy8UAbDCqQbYOfWv43HqIVMBADuiIumnAOy/qWPl 3XffhYOW1g8MAoCnkHkQwE0AIKXIYRIw5EKTgOFYJgEv1wDVScBYCzgV2DgJGCPgJGA8Ls8kYLSH TwLGM5ZJwBiBf3AesH0SMMZfPhW4mEnAaINlErBeNDqTfBIwJiUCQCYByyTgFfOARQCIACjlJGB4 VvtyTn0EoJ31wzujqQs/OF8ZAfATCSIAqgsBua0CBI1SBEDUKkDEEY0CgH6tGwGACwFhudxXAaoh ASAjALIK0H9gCSBZBWj5WkCyCpCsAtRoqwAFE3F+YXIBgCkoUkQ5WQ8uQFCGmvtEzQGA7v+O0L0P ffwtLU1N1dCxUoGhAOz+h79vtH5wECDJCEDrYqA5LQNKRFZcgBQXIC8BULZlQNF4rxEAEQBhy4DK CIAsA9q6GKgsA8pWApURABkBqOsRgKhhBE7rOYNXhAdJCEpHPxMlAGqIUbezDL6X9iejAAD239wM hL+Z+/2DBmjX0qYBkP3D59VXF4AG0AWAUt7qVgDL9wHAn2gOAH5FFyA8pgP8Wt0NgO0DwFOG7n/8 ivsAKJnyfQCUn7gAUH5q3Q3AvA8Aj8n3AVBSoH0A8DysBMojrLVNdR8AfmZt0z4AGAE2AeAxaR8A PKnsA4Anw/YBgAuh7x9TUFyA4AzsA4A/RY0AcCNxHwA8s9FuV9BP1Q0BWpcB5ZHhmO8DoPzE9wFQ foJNAHAfAOU8TABQzsBX2gpA2QcAY9IIAH4FLyCewvKtAG7Sk6V9AJSf2nYDOOQWPA9bAVAE2AQA j/90aNsBflX2AVASpH0AdBv0fQAwTtQIAP6q7AOAJ2EfgOUH3XlG1Q0Blm8CgOe5C5BiUnUrgNZN APA87ANAEVq3AqiuAqRcQvsA4HnYB4AiwCYAsg+A7AMg+wDIPgC4FYDsA+C1DwA8SFNxAUooAOBy zvh19g8RogSA8rIo81d1jMMX+qLiUyuhibzVBUBbmsHdX5kDgF+J+gP7NwoArKRvLZ8DgF/dBQBE hl3AcCMwvJYEAH6FXcBwIzBqDSAA8JhvBAZfcSMw/Ik2AsOvOAeg7ZhtBAZnjAIAY9J2YHCMu4Dh edoIDL/iRmBkHm0ERmdoIzA8o28ERjFpIzA8gxoAj0siANCY1u3AqhuBwTEJACoFHKAAwDNte4Ht 0SYGUAPgT3wjMPiKG4HhT7QRGH6ljcDwa/IRALKWNgLDM60aoLoRGH5V5gDgSRADyPvxa/V4uQCg ZOGABAAc00ZgGIE2Amv7unwjMPxKG4Hh19g5ABYXIEyBRgDwK24ERqbSRmB4JkoA4K97LN8IDL9y AUAJwgEKADxDG4HhV9wIjEfGYxEAshGYbAQmG4HJRmBhG4HBI9SXVRrnACQXAFwDGD2C6sEFyBfr ksSnVoICANg/7BrW1LGFBACu/IPOP8D+4QB4v30EoJoUmwSMr3PcCbjtePk2wPhVGQEgAcA0wIkY s7ofMNsJGE8aBYBlJ2C8yigAjCMAGJ9vBowjAHgeDvhOwHiSBADfCRh/4jsB45koAQDsn+8EjJGz EwArBgGW7wQM2eFOwJi1PgKA55dvBrxiJ2A8DyMAfCdgPKnsBIwnjQIARwAwgrITMJ7EnYDbjtlO wHgmdidgjKaPAPCdgDFOlADAX3EogLYBxpMkANo2A16+DwD+CiMAfCdgPAkaoO1g5Z2A8STuBNx2 HL0TMEYwfmgSMP4K2wAvP2jbCRi/7grbALOdgPEk7gTcdty6ChAeV/cDZjsB40k+AsB3AsZflZ2A 8SQJANkJWHYClp2AZSdg3A9YdgJOshMwPFd9SWZ2AkAZB1AMEwHgN/3Xt17dlwE94ogjwP+nXVN1 BADDlNZPdSZAdUygOXYEAIWETkFyEACY6WqbnAxBEQC6PSQA8KdW6o9BdQHCCLUrAJSy/6rDRfoc AFwCCGOuX5wAQAM23fNqYP8iADrAOMDhtyMmXgIgdhIwNYld/tMNAh8BEAFw8JlDKBxy1pBDzhpK QeYAyByATrQAKB7IHACZAyBzANhC/kbhoUwmFgFQGONXoKfaQuJ+4YXtWmf9dkTGzwNn/5YRAOQW OY8AWOYAoD3kAgQTAPAMCABFA8DJuhQAv/zzhb/sgOEiCBYBwDUAKoHcRgB+u2ebFxBx01oRAIq+ wq9JRgCMCdaNADCWTkYAjrhgFIR/VsPof17YFsQFSFyAxAVIXIBq3QUoeA5Aij3dWSelzgEwvufK dtI4CRioPygB2pYYeD8GIv04/dc4B6CN/efuAgQCoDoBYOOTOcIwBwC/wkyAKAHwo81Og8Cvqr8R AC8BAJOAEQ0cB8hTAIAGgDkAvC5q0QVInwRc9QJK4AJEk4DdXYBqaARAnwT8lxP6tgWZBHzhaJkE LJOAZRKwTALuNfOt1hnAEN6G0BvCbApL+8xe2ueBFcG4IZdxQU9jTzy8gvmKPQnnACRZBShr1p5i +gYBkGLq2SVFlc138wUNUJ0K3PrhS3+i9z+xf30ScOECAP1/2ni/swBYHeYBb94mA1AAYAo/3uJ0 CHictQsQ5vKz35/z89+3Lf6T/xwA3AegWAFQ9f/Zc7nrfw3OASi/AMD6LckcABEAR5xf7fuXEYCT bphaDTdOkzkAMgdA5gD0nLGk50wIb2EoUABYtgIgXhq7DKjCYOtwHwBdS5V/EVPjCAAogRQFAHXo JpwDANN/MamoVYBwBCBWAJA96P+DIwB2AfDjLc5QNAB8dVwFyH0SsLsAWGflhYDW/dP5VKgky4CG 7QSMWRtXAVImAceuAoQjAIoAyHkVoNbNgG/EAOv/YOncVwFasRAQWwbUfQSAzwOuTgDIYA5AG/v/ 910gAEgDZLQKECwDyicB66sAAftHe8QFSASACIALez58Yc95VfYPoVdbEBcgcQFKRQC4dCLrk4Bd rlLW8YTnueNVRv2AJ9ES33QKjF8/y4DSckC03j/1+ivd/5ZlQImSwiYAeJxcAJAGwAQd9wEgS/DA cQ4ARsYRABAA0P3P0/HaB0BZBjRqFSBM32UEAATAOn9cQfrhKtIA+QsAoP4cGWUfAL4KUBb7ABhX AWr6y0q7Aej7AChNAr7CWkB40iIAYAFQfmHUPgAQhy8D6rUKUHUx0H+0zfrledEyoNsf0bYQEP4a tQ+AXkA4A6sA4fk89wFQBIC+DwDYw5cBlVWAZA6AjACIAJARgNRHAFzIsQgAF5SMcepnDsCK9UBh ly+Hj9dOwKv8+vhqWL4MaMKdgJHQ4EZgfARAXwWIzwGQnYCVVYCw798yAgALgGLYEMLOGC6rhury /xRWLAOKMkAfAVixBujuV26yRzXwjcD4CACtAtS6FcA1yjKgtBEYrgS6xb4QroMAG4FVw18wXL8l hP1WBGUjsK3377z1ARBuoNDK/lcaAaCNwGAQYPkOAHhQXfqTB1oGlFyA2qg/TABgcwBgK4BqWHkZ UGUjMNAAEGgEgM8BAAHQGu7YAcM/28KO/7xjx392Bdd/Cjsd2XWnf91JYed/3UnLgCoCwL4KEN8I DBcD5RuBKcuA0kZgsBJotftfGwEAAaAsA0ouQFUZcAKE5RMA4EDmAMgcgJumyRwAmQMgcwDCXIAC nFCg3x04VdiFNPcgyeV1MgIAIAaLiTwvJDv5HADcEACYveNHuVbZB4DvBJxEACDdV1yAgP2LAIAR AOj7x7Aehj9DuBBCdQZw3CpAIgBQA4gAgPtLWQZUBIAsA3rsVROOvXpC6wKgGCb+95qJx/Fw7aTj ebhu0vHXTf4fhesn/+/6ySdUw5Rq6FwNJ7aFqSfeUA1t/j8yB0BcgFp3AJARgOQjAEDlc/6gAAjO FC+vEwEQoIHyvyRqDoCB0LcuEuoR2EZgaQkAxQWo2ve/UZX9iwAQASAjADICcMApAyD8FcKpGAZC OBDCaRQGHXjaoINO52Hw385YKfBNAOBY9gGosn8RAF3ndKIg+wAMeeoaCEOr4dq28PS1w6rhOgrD n7lu+DPXUxjxzPUjnu1MYeSznath4Q0YRrWFG0etYP+yEVjCScDIp2su1IkAyLMXP0leUSMAHlzf KAyyEQDKTsAiANaBvn8MMgIgLkDJXIB2Papba1hpJ2AZAZARABEAK9g/yAARACIAJr96J4Upr95Z yo3Aao7619UIQBJSnue1teKqlCcmkpcgIAgIAoKAICAICAKCQP4IyCpAOW0VTAIgfwckyVEQEAQE AUFAEBAEBAFBQBDgdFSWAc1DA3DEjasHyklBQBAQBAQBQUAQEAQEAUEgIwRA/9SPAMgIo3ST5ZOA Ofr5j/g0SI7pVl+BqUFraZAqk2IKAoKAICAICAINggBSwfw/9SYAaqK5KCMANWFz7RpZNzMuRADU biMUywUBQUAQEAQEASMCIgACGoZhIzBIpeROXTICEFDTSS4RAZAEPblWEBAEBAFBQBAQBLJDIEAA fP7Z5x8vef3j999PMm5QhyMAUKR2Jf6IAMjuLjKmLAIgZ8AlO0FAEBAEBAFBQBBwRMBdAHz55Zcf Drn+k36nf37D7pWrt//iuI2XnLr34tF9P/v4kwAlULcCIACLfC4RAeB4S6QVTQRAWkhKOoKAICAI CAKCgCCQLgLuAuDTd9/+8qodKzdsX7ltt8rVO1T++5uP/rbOc3ut+XzPG19+86XPP//ci8eKAPCC K4XIIgDSvXNiUxMBEAuRRBAEBAFBQBAQBASBQhBwFwCfPDy+csPOVQHQZY/KRX+o/Gf99/7680V7 rblk1qST79rvhOa/jHt4yBvvvPHRJ5+98f6rcxaPun/hCAttrX8BwKcEpMDfEychAiDnG0wEQM6A S3aCgCAgCAgCgoAg4IiAhwAYfHnlll0qN+1YuW2PyllbfnnEr5bs/7On9lnn1ddfPPDqDQ7u/Ouj 7t7ozHFbXDRr68sf3uaKR7YZ/0SfxhUArbC2UHBHOTHPj0wgRQEAMx0cm1cq0XLOLhWbOdppJVhU OlmvAlRU/RaVb1H1KPkKAoKAICAICAKEgCM1/eKLLz698aDKzTtVbt2lcuOulZN++/mh672679oL zzho6oLRB1z1q8Nu2+B/Q3574cytL3toW2D/lz649aI3nm1QAdDG/luaKhQqLXxA4IjlnxTpPrAZ e2ruAkCfyYzNhQhTiswpKi9+i+r5BhugX5hFodD4qBEAlyInfEKlWyiLADBOevc1Prg2lYwslWs0 Ka18fcsr8QUBQUAQEAQEgcIRcBQAn776fOXaHSs37VC5Y6/qwbHVCQAv7rPW4r633DTm7AOv+fU/ u2546tjNLpmzDXb/XzVrr88//8JLAJR8FU0yDwoVuQwosnCg97z733jc0rHpa1/7mg6QzqgcRUK6 AsDeLlNkTi5J+RI7i/EpJhV761oEQOy1aUVwgTc2L5cRgCQZJbnWKBTppD3ltPKNBVAiCAKCgCAg CAgCZUPAUQB8PGfkFz3/9s5Nf3lr8PlvdT/lveO2XnbQLxbttdbSBY8cdet2fwP/n54bnT2x6bIH t71iXlUA9H0kZn8xfQ5AiVfQXGEaduw6CADe/W86tggAR8avRMtBABh74gmbsJYdRcKU1oCJY2T+ k2+mLiMAevr8qqhj3RJfAeCYb1Q0PG8ByoibS/WFCQB7dkYYXYwJU3dRxuiNyrdFSXxBQBAQBAQB QaAWEXAUAIsWvdZy/0MjHn6nx8y3u096Yca8F9+cNGrhOYcvevWp/a/61d9vXv+/AzY5f/pWl7f6 /0CY/dw9dh6rC4Aw3pvzVSECoKVjOwwrPIJamrwEgELu6avCkhELfpLOIBklSsrR11uthZQr/NLe /+pyPxjzUk4ahYdL4sY4djZvzDofAaCDqecbZZ4vYiSlKNOoSocIAQIgFkZi3pyCuxgTIADs4HDh xK0KbmByoSAgCAgCgoAgUH4EXATABx9/ccyA104Z91mnqV+eOnbZAZ3nbX/G6IPOH/HIM68//8az R3fZ/og7NjxpxKYXPwD+P9te+eg2l879/ZL33mxsAQAzgFs6AuMn3g8HzW0aAM9HugAZ/YL4SRQA RlUQdRI5kLsAUKQF5/1GxhbMnJSMdGKqM8XgvJRSKOm4ZM3jWBgzZpRkDoCieXQJZFFiLogZCxv1 tMpfAIQ9N/W25F6nCbVHmMFylSAgCAgCgoAgUBQCLgJgzsIPTr/vo9Mnfnne9Mpxg5fsfeXsP586 fJuje42Z8ewjoy9//rGpEx8dcdu0UzrP+MfNs/4z4MFrW56cAruGiQCoTgJGAYAjAE1NKwYBvOYA eHH9KKngJQCMzVFnpUad4NWU8x8BsAsYoyBRLnFkz0lcgLIQAFGiTukC16svHwGAIMcaY2ldelui mrIIWuWqWF3n1bwlsiAgCAgCgoAgUE4EXARAjxlvQd//GZO/PO/+L4+8+4XdL5ryxxMGbdvx7pcX v37vBetNu/RnC/vttmz+ZR8tuvXjRed98sSubz1xe6xnTr27ALERAGT/0P2/XAAUMAKQgwtQWPsu oQCwiJ+0RgD0LKJoqCI2jNGiiK9xKCCqmizENzcBkLAb3iIAYus0YdZhjV+uEgQEAUFAEBAEikIg VgB88eWX545ectbUytnTKp0mfXrwbU/sdM59vz+u3yEXDH/tyQljO631wNU/W9J/vcoDG1Ue27jy 5EZfPvGbt156WAQAuAC1LQOK1J93/+fvApSDAAjrOo0VALxLWOkXT3LPOJJFHi3qOMoMrxEAJXHH fKPGInSgYpVD4QLAF95YEWUf6on9NUnrkmsFAUFAEBAEBIGSIxArAF5759OTRr1zxuQK+P+cOuaD /a57sMPpo7Y9pnfn/g/MH3X+feeu9cgNP1828leVhzeuLNi48tRGS2dv/dlnn4sAaJsDgDMB9L/B cwCQECtzAIwnKQ7Gh4boPgfA0mOq9CuTc0VYQ1d8MzhzJepv5P1cGARkbe81NxbKl6F6CQBEVS8y RxuLyRGjMwoCRjmhX6hkGgVjwAiA0U7LSaVoARWqAxXbUEk+GZEJs0GuEgQEAUFAEBAEagKBWAEw ccF750z99NwZlVse/+Ls+97Z+4pZfzppyNZH3T3z0ZenXL/9xAvXfvr2X3w2fv3Ko5tUntgIBMCS eSfEsn+IUP8uQEDx7cFrHwDiKJz6208i76f47gKgJhpu+Y2MEgDlt1yx0EUA1FyhyGDL0EftFkos FwQEAUFAEBAE7AjECoAJ85d0mfr8wJmLps17adJDL94yfP5eZw37wzE933r9hdGd1r7/0rVfvnvd L6dvWHlsE2D/VQHwdL9GFwDA7B0/LkilFcddAOi98tmRpDzzUnqgs+739RIAOePg9Vj03Qk4u9Zi N9uIYawxsRG8sJLIgoAgIAgIAoJATSAQKwB0/vnJp59Pf/iFl+aNGHN2dQLA2wPXq8zdCP1/Pp2/ 0btvPu9CWet5BMCl/PnHcRcANdFwy2+klwAoc3FkBKDMtSO2CQKCgCAgCAgCAQgECADkrp98/OHj E5rn3Lzt+6PXrzy++RdP/fat2Zs+M+WYL76IWQAULxcBkLcEEAEQcHskuUQEQBL05FpBQBAQBAQB QUAQyA6BYAGA/PWzTz9d/GzLi/NHvbRg8ntL33IntSIA3LFKJ6YIgOzuImPKIgByBlyyEwQEAUFA EBAEBAFHBBIKgGBu2nACoCigqYZEADjeEmlFEwGQFpKSjiAgCAgCgoAgIAiki0BRvLThBECsVGpq 6mgJsZfHRhABkO6dE5saNPG6+cQWViIIAoKAICAICAKCQA0hIAIgljnzCMii2ykVjH29ACWtvKkn Ggs0sH+6Co9RD+CBl5XGyLoAqBt6KgURBAQBQUAQEAQEAUFAEPBCAKfk5v8hFwnIukOHDskpbg4p hAuAWOM43SfGn6kAiDVJIggCgoAgIAgIAoKAICAICAJpIdBwLkAuIwBRHf9w3rhrmFdliAtQDQ3M iamCgCAgCAgCgoAgIAjUHwINJwBiyXqMC1BLM24uFpUO3wXJ0QWo/lqVlEgQEAQEAUFAEBAEBAFB oLQINJwAcBwBiJoH3NLcsdLSDMEiA1ADRCkEGQEo7c1QWsP4XVpaI8UwQSA5AtLUk2MoKQgCgoAg 4IJAwwmA2BEAiNBG7luJfnPHJgwdm9pBAAGAgWSAniAXAHRMIwMiAFzaZYPEmXPP8G7HHjXokvPt 5XVlRY880G/ojKu7zry4ec7FXVuu7zG37+CZjz3yQB2A+Wj39o/OmVAHBZEipNPU582eef+c4UPn 9u83d/x9cx59KJ1G/tCcmVcMeFYJc2bN9Ko132l8XolLZEFAEBAE0kKg4QRA7AhA1b3HRP1RAJAM QG1g9AXSBQANCMCBowAY99Dw42YctfXEpq3vadp6bNMR9x3SY2aXtGq9kHQemnv/xHGjRwwbOHRw PwhjRg6ZeX9WlO6Wye/pL3I6c9qFI+c9NMcFhLTS4XktGXvOB2OPeXPWDQvnjZ15V5fm9u1f+sdm KbCiRx7o0nt212ELJj/5Vsu7n05769Ohj791dd8F13e9v9Y1wLTBFy2ac+3Y2/ZxqTKJUx4EHpxz /7CVP488OCOFpj5v9qQJcwcPnrb4uT6fvN710WlD+vRumTMrHQ0ATwmlTwfOeEHqKwBoFQ6vXPTI j/b+gWMIy+jmoZ2PuvSIefNmh10uVwkCgkDZEGg4ARA7AgCcnvfxc95PxzQy4CgAKFMXATB73oTD 7z9kj7m73fj0pX2fvfbG+cddOHfff03+7TYjfvKnAVsPmdmrbG0o1p5HH5o57p6R994z6oHZ01vm zrp/2qQJ4+8ZMXxw3z53D+jX84EZk2JT8I1w04SliPnnn3/+6aeffvTRR8uWLXv33ffeeOudeU+/ DgLg5oGPznPoNUwrHbJ/6aiTK0N2q4w7sDLrX5UH/vPJsP0WnbHpa8dukZwV9R82u8vwJ6DIb39S mf1upd/TldGLKzOXVa7uv6Bb7ym+AJYq/oy7mipv95ja5ZelsioLY+Y/PX/sS2O7vdblkqcv+M+c E3cff9w59zw39+GWvr0nn9NpYK+7B2WRaUZpIvNveapl+JSxU+fOv/fee6dPnz5o4IAZ08ZbcnQZ 7Kqy/0HTPlnatfJml8qLt1WeuHXJjG6De029d+zc5GXBQYBX3qvw4KUBUADEvmggAsVMbjakAOy/ UllWqbxnDxDNJbsnF8yedN/tTz3+EER+/JEHuk/p22Pq5TcMPnuzvf7UvVdPlxQkjiAgCJQcgYYT AFhgy18SAFEygLP/yy+/3NEFCKPFCgBg/1tPabroibOGPH/77U+ceflDh5424w/HT9sUwxETN1zv ztWHTE9ZA6BVGQVg/yOGDpw5Y+q8h+fOmjlt8qRxY8eMGDVyKIZhQwfe1bXL7OkT0839xnvf+LL1 Q7UDRx9+Wnn/k8qjLywDAXBgv7du6BVPF9JKB0u3dOxplaG7V8YfVJn976oAuPeAysCdv+y6zZtX /+7xacMSsqIberaMffKtZ96r3PdCZeLSyuR3K/cvq0z9oDL48bcuu2NWuvC6pJZio6oKgBcOAS+g B6cPd8m6RuPMWTTvoqfP7br44uHv3H37y5ed/MgOW45as/1Fize9cdGplwy9+OJ7dt75yu53Tc6i dClWFpp3/9RJV4296rfXrr/eDav97NLvrXHOT/7W86Ke0+b37jegZ8+e06eOiypFrACosv+B0z55 q2vltdsqi26tPH5L5aGbKy03fTLl+pn9B4NH0INznAb3LDAC3X/0tQoPYQIgtqbSFwBfvlSpLLIH FwHw5IKHP/t00Weffnz0dVPOvmLACYOuu/aRQfe9NO6mCf13P+Omzfc9J7ZoEkEQEATKj0DDCYDY jhkSANzpH52C4IzC/lMXAIdPO+SSBWf0ePri6x89utPsnXs/feGHn703eOFVpAGOmrzxr25ce3aL 6jzDVx/ybXapv/65AfeNHTFj+pQ5D8yYNnUikn5QAiQA4ACGAu64/ZZY3wCvQnUe9coXrR+sbmL/ byyrPPTcByAAMMSmmVY6Tz405b1Rx1dG7FWZdEhlzlGVmUdW7tm/0m+Hz+/Y5rMFo5c8eM+E0//y 4MQRwawILrz4jpbpSz+d8Gpl6vuVB2FHvEplQaXyeKXywPufXnS7wTuCN5gsGkBaac6Z2KsqAB75 3pLx35w0wDZZQilRWgbwSqE0U098/sIn/jZ99zMf26vHa1dP+HDM+A+mnPLofluP/v3/u753+/OP XPuw3a+4YtbBBw898sipd3VV2TMWXGk8xpNRDSzdcs24f9JBXQ78yS2rbNrvJ3t02aX7zO6Tn5p8 58PDOk++r8fMZ5rvvOvWW24Oa+rA/lsG960sbvniqUGfPTXgowdv+mjm1QuGXT95wKhRvcYP7j6p ubmludsjsfe1PQLQ/SmLKjwECAB3R6AUXYAqXzxaqbTYg4sAmD+/5dEPXnnwo0//ftuHB5449m+3 n3f+tAG3tow7Y+jI7U8ftdlB3RIiLJcLAoJAGRBoOAEQOziruADRrF+g/y7sH7v5udM/XxHIPgIw 7sHhf5q0xa2Pn3pxywEnT9+611PnIX+d9HJvEgDHTfvtn/utefagk/X3PZ3xZSe+8d0b7oNzpkEf PwgA8PkZM3o40P1nnl7w1pLXXnxhIdcAvXp2GzV8oHuysTGvHQrdYNXPZ19UPho/7J03l772QWXx 4qUvzX34qSWVabMrw4dXTj0/vjsZ0gEnIkzqpBkntweH/eb2PZ4cBn8fec01HWD/Hw07rDJy78rk v1fZ//2HV0bvW+m7/Wddtv748dGfffHlW8s+fmTC2MFnHN8y1ewdEdstSgKg/zOVye9Vqf/Llcqb lcorlcojyz69qFkVAEa+GIuqV4TgRjWl/9nT+p0CpJ9CZdnMyoNfrTy98bCrtuHnZw690MjOvewM ixxcuqjsLpv82Pr9/3zYrKaLnjr6hhcuuu2lO45uWbzOgMpXbzmn/WXtf3XE7tdf/+wxx0zdf/+7 d931IheuHyYAwtBQrjrx5v+tfsMq+07ZAPr+4cb5qLUdznzvvb8c8vcTLm3uMeXBm266CeYCGfOy NHWY9dur55zFT8xYuRPn40pl6XuLp3704sgxd3YfPOqpYAFAs8wnTZgKjH/IgsrMlyrzXq08/OIy +Dpx/FhHcBTqT64+NOysR3BM2R6t6gL0+cRKZZQ9uAgAyGjf/562+eHX//3kAU/Mb5kxd+bGf99v 93Ov2eGMrhsffO+2f015CDqV4ksigoAg4ItAwwmA2BEAiICrAJELEB7QckDwE3T8G/v+if2TBuBi INYF6LgpR3WcufOZszoA3Sf2/9IHT54+848oAI6eusmhk3998KRfbnn9bxwFgHFkQDnJ2Uwss9H7 WS2XjL935D1jq4Ho/sQJ977+2sukAUaOGDJ82CAQCV1vv8XSdo3daZb4V/d/Cqh/lf3PnlzZsv1n B2/+6tOLPvnb5l90WPXJRxY9tLgC4ZRzh8beLdV0PvuMs3/UACgAILikU6X7EKYeVmX/0/5RGbVP pdd2H9+2DbH/xe98uPCN96dPmtXnitvnTr9ft8pFAFzfc97A+W+NeqUy85MKTGNcAuIHvJ4qlYnP vnVVt3gBwNUjVbHlJFY6Z5nGRqUnFYv57B6/qyy+qPLBoGpH5mdPVz56qPLCUZV536m8sEPlk/EV cHL4YEjl9asqr10xufn3LgJAvwWMDT4qmlJGKjWdt99iseXFCNvf+eL/u3zw5iPW2Gvy+n+9f6P9 ps75/djK/93xRftrd29/bvtNjz382msXTrhvKrD/Lbc82njv64WiM7EPAR4TEzde4lIWmPi71vk/ QfY/7OFhoEKfr1Qefu+9/f/+98NOvOjelyvTl1Zuvu3Obneae5EtTR2YPXTwvzxv8vJnOIzvgb/7 25XK4soXCybfO3nk5EVzF7/HBYDXw4oczJ55+klg/FNX/jz88MNjx46dMsk2gQHxcRQAJAyiRgB8 H3pVAfBp70ql2R4cBcC0qXcNH3xJc/O5D8+tPpFGjh218V5Hb7zPOYed3PepBfNcWoLEEQQEgZIj 0HACIHYEgBQClwEkAOzs30VdQIOgJ77ytttmWNOJ92/J2T92/495oQuEEc/fOnjRTftPXHeXcWv/ 8MJvOgoAnSFZen9j2b9ODuyXDBrQe/SoYbyzH45hHjAIAAgvPP8sfB06ZMDgQf2uv+4q+62iv1Yt Q+dX3P3oB59UILzzUeXDc48EDYDh7bOOBMoOHXsQTuw0OPbmhHQ++eQT0ADf774qdPzDMAJ2/6MA mP2yazrz7rmrMrdjdQRg+J6Vnn/66JatP3pszBdfVvv+X3/vo+fefP+JV9978MV3RtzzyIA+hmVS XARA38Gzrx3w5PRllfs/rDxVqbxeqUDXKHx6jH3qljvVKRZRtaacN0bTqT/yRb1BeglLuhx42AP9 91pyX/vKC3+uvP73yrObVx76RuWJdStLjqx8cUvlk8srL+60eMw3R16x/sx7VloXy6X1kvFc2+j2 G8vIo+mMmW4NJTUXq+CS9S978qtnzF31zqa1+m36s/7brXr3C1+75eP2lw1vf+H32p/efrP/HHHR RS0Q7fbbeh926AVeAsBYp1EVbanx2JsFI8yYNoEEwH1PTX6uUukzefLpnTr9frvtQQbc9cDi18YN u6NL1wH9zQ54dgHw7OL3Bgxe0DJ37icfv135/Pklr7Q82jKl5f5x942cOGzyovmVyv0rCwBFycTW xYL5LSOWf1paWhYtWrRkyZKlS5e+9dZbr7322uLFi8eMGTNndvxCRryzP2oEIFYAGLWE5aFXFQAf da980cUeYgXAU89OWvjK+M8+ffqzTxfPfurx6/pM//dtV1w27fJRj950y+hz9znlH9vtt98T8+Mn UDk2GIkmCAgCRSHQcALAhaPzOCQDcNFPS9+/Y8o2ATC4Cdj/BXN2tyS187i1/nDvT9a67ttGvmXv cNXZTxRriW2O9ozo8oH9ewHFnzplAjJ+PYAGGDSw74D+vW+95YbYTEkDID6W+Jd2nQPUHwJ6/kDH P7D/z/+86rxnlgL1n/p8ZdoLlf+d2T82R0jnvWVVAQDpYOAjADNeck3ntkGPDJ3z+EfD/lrp/vv3 b9pm6YQbYX7yOx9+wtn/zEVvT35mSbc7DcQoVgC8ef+1s6bed1Hn+64f9MSwBW+1fPDpY8s+hb7/ u8c+dXNP81YASucobwkKOY6lm1ECgF8Yy72UXIDcz+2x/iezvlGZ/8PKQ9+sPP+nygdnQ9fme88d MfHmn4/vpbrA6VTPzmWVe8GFJYcJgNg2hhF+eeqs9v+e3f6UJ9pf0tz+pu+1v+b37S+Y2f6MXu3P aN/+2Pab/v0fp556D0QbMnDE3FnTjDVC5inixKVoUXrG2CosJQLqj+GYh7Y+uuUPcNDh1l3Obr72 H//4x386XXvC5c0Q3p04rMstXQYPuteYjl0ALG71bRvfsnjgoFn3jRw/fvKiR55a8viipd26Pzxt ybI5X1TGv7DSCADZj609ti569er1zDPPPPLII4899hgIgZdeegnYP/wF3o8fWMjo+uuvt6dDU3vt 0wBcBABk5P7QqwqAd7tUlnW2h1gB8NGnr9338OTPPn37s08/nLVw2Tl9B3ZuuXXMK8PHPHLnDaOu P+KKc3c+5vjt//GvBY9VFwiSIAgIArWLQMMJAPcRAF0GJGf/SFsjRwD6VgUAHwFY9tm70OsPodfC 63suvO6uZ6/Z6p4fbTZ2tVXP+kYUCVDe2TrPi+2sdWzNLi/Ufn162AXAY/MfBvbfv1+va66+3CVf qj575ItuvR/5OrB/8PwB9v/JnuvA3w8O3HzGgqXjF1YgHHdan9gcIZ2l73+MgTTA9JeWQoDu/4nP uaYDAmD04o/vnrN4Yu8bBnXvTux/6JSnruk8ptP5A+AA2P+YBW8ECIClE8/58p6/zrvmb316dO3e b/rld865qHnOJV3ndu798J29pztuAsD7vHmbUSgUEamoLmSCNDZCLPgQ4f5e/6i8eHLl8TWrQwGf 31D59JqWvr+BacHGa6MapEXquHfk67eVERmeoCPpxHT+cP7M9nuNaH/Y1PbHPNj+jB3an9N+zdO3 POi8p/5x6iO7HHfNH/Y+/YQTRkUhFsX4LXUaVTu6/V6lOKTbQfuO3vjfc7Y47antL3p132Mf2vGo 4RdN/6gy/MVqGPxcZearlVc/rfQZOrXbXf0CBMAzlQqsdAsT3Me2LJ4w88U3WvXAokrloSXLeg1/ aszLnw9+xCAASBrFNjkQAM8+++zTTz8NGuCpp54CDYC8/8knn5w3b96MGTN69+6digDAlwtJhVhF EdvlASlUBcAb11XevtIe7AJg1qMT/3bNnNuGXv7epx+89emnvZ7r9eAn8259fMiMD2f2fWjwVaN7 HnHdrX8578at9z5l21MmPLXg4VhIJYIgIAiUFoGGEwCO/fTZRbMIgCOGHHLE+A1RA9y9fAbw5MWD dxu/9k7j1vzdvatvPvYHG435/s9Gfnu909dyEQAunX/0dnQh9L7tePiQ/uDfjy5A4OcDAb7CkqA4 FDD/0YeA/cNuAL17db/+2isdE7f3/WMiF1w/4eX3KhBg1i90/6PnzxtnHPneXzef/OjS0U9VIBx7 Uvxq1pDOa0s/gkAd/3AA1H/cc0tHPlmBZfcd06mOALzwUb+nl/V49P2uD74Hff9vvv/xojc/APZ/ 9NHNEAZMemLsE28Mm/+arwBYOvlcYP9zz9+z93mX3DM8fL1/pUec14VLKzKqSksiLnU9bfjV7y1Z VHns15VFf6i8B+vtTq68c+J7D/7m3juPchcAdqabigCwl8Xxtrr13ke+tmPf9jv2b7/bkPYHXLrT qZ0efnjZK69Uxoyp9OhROfrosR07Rm4CwLPQj40GOMKiyB6XWkMNcMHLe136xoHbdN7lnter+1HA 1JRBz1UGPl1dh3fWq0sGDZozsH/fAAHwUOsCN9DZ32fwgic/+Rwmu8OqN3AS+v5HP7aka58FXSe+ FTwJGOwBATBo0CD4O3fuXNAATzzxBGiAgQMHdu7c+brWT+8R3QIEAPcC4qTfUQDwV4alCqoC4OXL Kq9dbA92AXDn2G7bnzCkc/9Or376SfeWGePfeaDT6Al3PTtywtLpdz4w7MLh/Q7r3P0vF3fbaq+T /3jciEnTClhf2KURShxBQBBwQaDhBEDYCECKesAiAO6e0mXb3j+hyb63LjgT8x30/B1bjP3hpmNX W3fUKmuP/NYPunxj/3P38hUAUX23JAD4gUvTcYlz/5T77u5xJ7B/nOwLAoCzf+j479O7B7D/27vc 3HzbjS4JOsY576qxC9+uQIA1f3DWL3j+gNsPsn8g7hCO/l/8YnaQzstvLYOAAuC73VbtteBhEAA/ 7bkOCgDHdEAAVNn//Cr7v2XmO8D+n1/ywdOvv0cCoNf4BcD++z682EsAtLL/A2adsxew/37dJj3q sLVZFKUzCgD9ZJ4jALAWUGVJ98r81RdNbBpz8x6Ln5pcWTYK1gOdeP2qYQJA6cyO4s0WSawLhlh1 5CgAINPDb5i75i6DvvGHHj/e99wbb1w6bVplzpzqclVdu35xwgkT99gjUiF7CQBLnRoL7jUCgPWy 1w07d1q09/pXrjvmlaX3vloZ8nwFFqca/2LlrQ+r3f+39xkxePDcWRFbf9hdgGB+y/g3P+8xcMH0 VoefWZ9Wpi2rwKZ/Y1+rjjD0nLakOlE4wTKgQP0/+OCDV155BXr9m5ubr7zyShj1BfY/YMCA8ePH w75mF198cSECwOW5VxUAC8+tPH+OMfBNgl1Se/yp+ceNvv73xw3c/rRrrn9w2N1PjL303sEn9Rn0 t+uG7n3J8N8d3n3L/c7Yr1N4j4OLDRJHEBAEMkWg4QRALJVvauroGGKTMkawCAD4abvmrf96zy8P mfQrnOx75fyTIJFJr41Zf/T3oON/jRHf/O7Qr6529HfHTVaXsMT3NH2o0fAznL4Yz2ehAXr26Iod /zjZF5z+se8fO/5hAVBQCJddcsHsGWnuBdbpkuFA/SHAbj7E/sHtB9n/gMeq4aj/3hF7a0E6C1// AAIfAYDjTQduDwLAPZ05sx7ocd9zyP47T30b2P8zr7//0EvvgAA49tiuJ5zQo8f4J4H992h52V0A LJl2+Zej/xLA/kkD2BuMQisV6q/zWiW1qD7mWMwxAkwFrjL+BU2P9lsdu/xhE4BnW4ZUlg5bPGUz 44YAUVTbsanraBjLqNxZeMvY7zvHIkO0ToOf2frExw44euaVV74JHf99+lTuuqty2WXPH3547z33 XGnNU56mpeB6Xcc+GZRLAp4Js+dM2OSCDS/qclnvWQtmLq08//rSD88/8s2PK4+9u6xLv2H33LNo 0ACz/w/kZRcAQxZV7r7nxaFzXifSP3BhpdeCSrd5X3ad9n7zqMXNXR9KKABg90DQADDrF1z/R48e DQMCXbt2Pf/880899VTQA/B12rRpdg2gzwFQRgDIn8d9BMClCVUFwOOnVBacbAzw67IlAx7upQ4d R6U8/aEZ/+p3zcb79dv70jMund7v5rmDzxra/5huAw64ZuSel9yz9b8G7t3xxscef8zFMIkjCAgC 5USg4QRA7AgAsn98RtMxnqHzyrGXErALgHEzh69z1Y92Gbs2TvYFn58D7v/Tb+9Zc62R/2+1YV// 1pD23zim/eV32LZDKls7mzNr8q03dx44oA9O9oVlQGEQADv+e959V4/uXS+5+Pxhg83+AMFlOevC QbiRJ2f/Y59uY/+9H630erTy76Nvi00f0nn61fch4PL/sBXAZgO3P3z8RX0fWzp0QTURx3Qgo5YH Zt81dD6w/yvvW/LsG+/Pe/ndOS8sBQFw7rlDL730ni5DH7m6x4zOt40Zd49BCBlZ0eSenWZ12sO3 7z+2yCWJAKT/vYU33X/Ld8ERiEwC7//ZQ86ufPb8qBt3LYmdqZsxu2XOTSPmnnXmxE6d5l1wwRNn nDH7P/8Zus8+1154fnPqeWWXIOz1C7t9wXr/N915d7cx47rdM67nmEl9+k8dPvyxu7p2teRrFwB3 jH/rroFPDVpY6f1EpfsjX3advqx5zGvN/WFzsYdhD+B7x86FvQISFgoGAXAcADQA9PqPGjVqn30O PProo4H9z5o1C2YC4KwAexGoFPRqwMc+/4pqJ3Z+v3txqgJg3nGVR443Bvj14V4/dk9twaNznnii utznk0892rHftScNvulfXbsd3LnXThcM//3pY3/7zzGTZyTdcM3dGIkpCAgCWSDQcAIglqwT1+ek Xz/JxUBsmsqjn7zYjU//oZN6bXrJhuvd/h2Y7Pvr0d8Fn58fD/+/VYZ+5Zs3tl/t39+tLfaPTXbm tPG33dy5+fZbwOcHO/6B+kPH/y03d77kovNSZ/+Q4xnn9kUBgEv1w3I9MGF33MIKdNsDce/TStz/ +Z/I7UjpToN05r/4HgRIZ/yipcHpYILzWmbddMe0S0a8hux/xIxFXXs+2L3btDGjZk+dZFtb0NhO hgzqd8OFfp4/WTxBMkoTdmUCDUBLs1MucH7GsMui5gFnZEz+yT74wMzTTxt40EF37rffTTvtdAGw f33xn/yt8soR1o8f2L/3bbc2d+06sHfv+26/fUi/PsPH3RO53TUmbhcA0LvfdfK7SPrv6vHwkEFz x983B4bXvAyLjTx31mSUAffff3/Pnj0vu/TOwYNn0EJAsZfbF//Rf3WZ1BSbKUQAiv9U3zWjwkM9 fuqSiDHOtEdn9Zgy4ohb7vjHDb2vGTxz+LT5Tz4uSwDJCkiCQM0j0HACwGUEIKrvnw8IZCcA8BF8 eb/zNzl9g2/996vfPOqrXz+i/c8P/+kR5x+ie/4EP9Pzv3D0iEE3XHfVpZdccPFF511wfqdLLz7/ rjtuTdfzhwp1+lm9YsPhR8YvPBqbCERwSYejfWf3Cd17TerRbZSd9PNLUuwmzL/eJUdBwB0BuwC4 666WjEi/bmHLA9OmTqquVQp/7V3++rVeXUJpCQB3kCWmICAICAJKhws8ezt06OD77CokPlgO+arr OuOTFIoBTrHBZhldgHSPILsA4G7BiiVoemx3l7ROQYAQEAEgjaFBEJCm3iAVLcUUBASBwhGQEQBV KTjOAIZosC+YUWYo8kP5KgKg8EYvBggCgoAgIAgIAoKAINDICDScAHAZGcDdfystzRBgA2AMHZva QWhp7ogBf9U1gHHwAU/iXxEAjXy/SdkFAUFAEBAEBAFBQBAoHIGGEwCxcwCiqD8KAJIBqA1SEQC+ k8YkviAgCAgCgoAgIAgIAoKAIJAEAe6RLnMAKsDpeR8/5/10TCMDqQgAl0EJiSMICAKCgCAgCAgC goAgIAikgkCDjgBgsY1/SQBEyQDO/mGfSKUaGtMFKIkAlWsFAUFAEBAEBAFBQBCorUWxan3RgoYT ALGyiQQAd/pHj384o7B/EQDoxAbNCAaP5CMICAKCgCAgCAgCgkAAAnyGZOH+8S4GiACIZdRZRMB2 ErIMqMscAN73T7N+gf7Hsn8satQqQHU8CRgFQBY1LWkKAoKAICAICAKCQA0h4MKelThAIUQABOCW 5BIZATDcU7gKEMkAPKDlgOAn6PjX+/55QlH7AMD5ulwFSARADT2axVRBQBAQBAQBQSA7BJDnuH+Q QhgFwJOPtSx549XPP//cltqX6o9vLXkNLkxCjl2ulREA9ypOMWaGIwBkJZcBJABc2L+9nCIAUmwH kpQgIAgIAoKAICAIlAoB3758iwAA9v/sW8+edt9pRw4/8qCBB+3Td5/de+2+Y48dd75755177rzL 3bv88a4/bXXHVlveseUWt2/+m1s2/MV1v9iq81aPvvQoXOhC4pPEEQFQSKsLFwC+5pIMwEU/Y/v+ Y9PPQgDgwIIxWH5K0u6Va/URgCsGPKuEKwc9d2mvBaddOHLhwoXLli2LBUoiCAKCgCAgCAgCgkDN IZCiAICynzn+zBtm33DLnFsum3bZGePPOPGeE48dfezRI48+esTRR4086pDBBx044IB9+/5ljz57 dOjRoen2pl9e9cvNL9gcBg1SJDnGpFIXAGkRNnRCQZv5sc7cAF48WUN+HOECIHYOgPFOQxmQnP0j 1hxxOtabl6XalMjlFABfaKNyUFgQACf3mj1jxgzRADX3TBeDBQFBQBAQBASBWATSFQAdR3bsMrfL HQ/ecdX0q86ZeM6p9516wtgTjh0FGqDjP4cdfvCgv+3f/y/79Nt7z9577nT3Ttvese2G12y4+vGr W8hVWsJAFwAJyVhaAkDh/VFkUuYAxLbklCM4CgCu3mIba8I2F5t+bATjCAAC99o7H018YvHFY+ZB GPvk6ydfNHLSnMoOt74sGiDlhiXJCQKCgCAgCAgCJUAgXQFwyOBDgPpfN/O6CydfeMq9pxw3+rij Rhx1xNAjxjw9Bsq6/4D99uq75y69dtm+x/Z/uOsPWzVvtdG1G61x4hoNLgBcNEDDCYCwEYAUb6jG EQCH3DaBB8Dwz+Pe/vf/7vzvcV0hnHfRoFtvvZUDa9xCIS3ko5Zm0tPP1Iy0iiPpCAKCgCAgCAgC 5UQgXQFwQP8DOk3sdN6k806575RjRh1z5NAjDxv0j4P7H0xl36n3Ttvdvd223bZtuqNp8y6bb3Ld Jj875WdlEwCxHalI2V2iucRx8QJqOAEQe7egt4+yxS98BaQ6duw4cuTI2BTsEVIRAHyVIWVwx/gT tir6iVqPfoZH422RJ6s3PmUE4PZpjwP1v+X1z497v/KnuV/+4b6lB946BWD539TFLyz58P1PKjAI 0On8fo4CgDPyYHYeIACC81IaAEIXJXX0+oKYxpMJG55cLggIAoKAICAI5IBAugIAJv6C3//J9518 3Jjj/j3s34cOOuyg/gfu12+/vfvtTWXZ6u6tf9tt0427brJJl99ucn2kALAzGRdizeOEuQApfEwh Wjx9dw6mu4VzL5IoXdFwAiB2BKB1AdAmCKQBUA+svvrqeLDWWmudeeaZwbeQiwBQasv+latGvZp5 U7PMHOBtRW9/sQZwAYDsf+4bHzYNWPjrq6dB2KD74k17vrnnRUMBtCUfVpYsq0ycUzntrF65CQB3 9o/kO7hyLeMJlKyLMenakGJxJClBQBAQBAQBQcC9o9OFVVtWAYKMtu267f799z940MF/H/T3gwce fED/v+7X7y979917976779h3R7Jk/bs3/FWPX63Xfb11b1n3x6f8RB8BiGUyLqamIgCiLIkSA6lb jqVoOAEQe9+SAKi0dFw+FNAMB9D9v/fee9P4wG233RablDFCQgFgVHLE8vXmG/WTRSpEJWK5N0gA vPn+x8D+oeAXDJ3185O73T19MRz/5pzpOw78cqsbnzrtltHPvPHxy+9Vxs2pnHhKN6MAIIGO6Ol9 4TyCEpkuUZCP4tw8cbpEYer4Vc9IMUyxNio1XWAYuX6UADCWl+dlQU8xCWNys6PUi54mjylaJew5 IFcJAoKAIFCvCCgjAMb3uMKko/YBAIhgYZ+9+ux14IAD/zbwb7ASKHgE7dNv3z367rFL31069Ouw bb9tCca1+/xs7bvXXvu2tX5wmjoJ2Mid0AZunpcGSDICYOyQJSMzYvxKpg0nAFxGAFADgACohkoz BOT9QwbcAC5AQP1RCTQ1NQXIgPoWAMT+m0a/s96Nj+7ed/F+fV/ZovOTTbcvAQ2w61l9xj/00jNv Ve5pqRzz3y66AOBsUiHiCrnn/FVh1ToljRIARiKrCwDdKmOCduNJSNjFiVH26MImtowWpRFF/Y1p Opa9Xl9jUi5BQBAQBAQBXwR0FyBFA+hM1CIANr51Y1j1f99++7qYsUafNX58+49XO+37EDnKncZy 3qITjM7PjrnYPTXoV8xdt8HLKncN03ACwKUBQZyq/48mAODkKqusAkMBmAi6A+l8TmnoSoRYAWDU ylG6kPSrsdEorUpp9HpGFjVsl8jcBQj6/vec+smv73zlZ/+8Qwkd/nMVCID5r1dGt1SO/PcNdheg WAFgpO96/bqwf06XdQGgZxQrAJRLFPavU3AOb1QRdIJuRyCq4EahoguGKAnhiKfjjSbRBAFBQBAQ BOoMAV0A8I52I5NOTQD0XWN1EACn16oAQDJgdMQgnuBO8e0xG04AxI4AELmn7n8aASD/H+D98IGv sDOA8b7lDC9AAFiccKJaRoAAcGlDluz08Tsoad+JD58/77PNB7634W1VAQAuQC2vVHjoP/Ml+Dr8 wcqhh11TuAAwSrVgAYCM2VL1ugww0m6LhrGkr8sDEQB19k6V4ggCgoAgUBMIGAVAFEuB8/Y5ADQC AM4/fx3w1/0H7L9P/31277f7rv133W7g9lsO3pIwWWPwGmv0/cmPuvz4+2fYBABn0grJMXKeKLKU mwuQ0V/IhcKJAPC+X5TufxQAUNNV16CW6vGUZ6fA3yOOOCIqaYUF0ldsW3AV1opxGzk75y65ANjz ytF/6vH0n88a0XTnks1vfWuzU0eCBtjiygcx7Hb8VaMffWf6i5UhD1YOOuiKHASApbs6lh8rfB3r 2nLSsT/eLjCi9KRyPpbu69JCyZcXRz82nnEsu/f9JhcIAoKAICAI1BECUQLAwqQtIwC/vvnX23Xb bvdeu+/bd9/9+u+3b/999+q31279d9ut/64dBm5HsK05fM0fD/vxD/v9cNUuq377lG8T0eKOEoof hK5JSiIALGLJ/pOXKpARAPWeo25+5QAFAMwBIAFguVuNAgBP2gWApfHRT7pgjf3JLir47WFUw7ES mVyAQAB0GzZ18Nj7f3P84D/c/ga4/v95wEcnTH8TwoY7H3HLPQvGPfPZ5EWVQQ9W9t//kowEACfH jgKA15edoOskmKs7ahIWgu4iAIxmG8tlpPUW+q4IA680LWWvozeXFEUQEAQEAUEgEQLpCoCfd/75 Nl232bHHjnv03gMW/9mz7567991tl34779h/e7LyFyN+vsbINX4w/AffHfDdVW5b5f9O/j9FAERx /Vh6Y6HU2Y0AKKIliZGO9uvbuSZqAVlejK1LdZPC+oZi6PQr2BhaADS5AEAbkgsAbMf0UZq18aco XaFEpjbHE7ecpIZFTee8hz67pO90KObuV0/f4h+d193pv7/eqeMGfzp0z+Ov7D76yanzPnzgiS/n PFkZ8JCHAEDOypkuN5v/pBNfiwCgZBVe6yIALNfq9iicO7Y4VAoqJtcVSvoKg1cu4UAZxUmAAIgq e/AtJhcKAoKAICAI1BMC6QqANa5dY9Mum8IuvzveveOuvXbdpfcusPPXDn06EGK/GvSrtYesvfrw 1b837HvfGvDtb9z6ja+e+FVdACjciXiRkQi5dKUbBYDOT+xs3tIDy9ldsJEiAFbcWVhh9r/8Pmxd 7ae6HqjuAmS5XXWWRkzLLgBc2lwJ45AA+OiTz4c9/s6Zoxad3v+52Qu+6HPfCz3veW7UjCUzH/98 5uOfPfBkBdg/CoADD7pcGQHwevy5aDw7+/fKzh7ZxZgUs5OkBAFBQBAQBASB0iKQrgD40dU/Ai+g LW7f4vd3/X677ttt12O7P/b44+/v/n3vx3oDAhv02vAXfdZZY8Aaqw1cbZVBq3yjzze+etNXv3L8 V4wCIF36ZPTiTjeLTFNrOBcg3xsm5xGA2MrWxaXeWx+bSOoR9MGjgw+5KjaIAPBtjRJfEBAEBAFB QBAoOQLpCoDvXfq9ta9de8ObNtzsts22vH3LrZq32qJ5i83v2AIkwW/u+M26d6370+5r/vDuH363 73e/2fv/ffWur7a/qn37Y9qLAIhleg0nABxXAaK7S0YAYtsQul3BDB7lkQT8PvYT/BQrvNPd6F0T XBy5UBAQBAQBQUAQqA8EUhQAX375xYZXbvjDC3641sVrrXvFur++8tfrX7X+r6761S+v+SWEda9Z b42bf/LDm370vVu/961bv/31m77+lWu+2v6c9r849RciAGLJW8MJAN+7q2wjALE1WkiEGpo+4tsA JL4gIAgIAoKAICAIuCOA3YJen6hVgN5a8tq8F+ZteM6G3z36u6sdv9oPjv/Bj47/0erH/eBHJ67+ k1PWWPO0NVc/+0c/7PTDVc/43v879f999eSvf+W49r847RcPL3oYLsyaDokLkHuTSDEmysuQScD5 jABYilrfcwBSrGNJShAQBAQBQUAQEARqDgFg8wEf47jBk4+1LHnj1SgEvoABgi8///TLz7/4/HP4 92VrPDgH7B8uFAFgR0BGAGLuLBwB6NGjNyAFmwDAMqCwCQDuAxB2T9arAMj6TpP0BQFBQBAQBAQB QaCOEcjBbydF9GQEIIwGJ7wqvxEAMNS4M0BwAepSAASjIRcKAoKAICAICAKCgCCACKRI0LNOSgRA IY02XAAUYi7PVBEAXk5yElkQEAQEAUFAEBAEBAFBQBBIjgAprhqayRkuAHznAKQuGLgASD1xSVAQ EAQEAUFAEBAEBAFBQBBwQQDHSRpCALjAkWkcGQFIrlklBUFAEBAEBAFBQBAQBASBJAjICECmhF9N XBEAATPl5RJBQBAQBAQBQUAQEAQEAUEgGAGdjubKhkMzC3cBCs0xtetqFPHUyi8JCQKCgCAgCAgC /gh8IZ96R8C/UcgV4QjUKB0NFwBhcwD4QkDhYLdeWaOIJyy1XC4ICAKCgCAgCPgiUO+MV8q3EgK+ zUPiJ0GgRulouADwBQupf6WlmULbmbiE2rVrZ4xSo4jHFbchfm957I17Z7x47d3zeIAzi156J8/y R5kBluRphuRVFAJL3/kQ6trYFKFtFGWVe75wv+j24xkomns6yWOW6lYqlTHJsY1NAWvcEvC5KgS5 oRCIbTYSIUUEapSOhgsA9xEATv2bOza1NHfEgEogVgaIAEixmRaYFLyVge5v/pfB7Zqa7WHX48ZA zIwYDLwLIXHIItYMMPXkq2cGE0G4EHIJCI4qKCBlBFZvA16mJrncXVlhHdlDcGMGM6Bm3ZuiY40E 2+N1Id5HLg0YWnh93Eou+JTwvs6ttcc+yvCubyj6K4V1uWskTloINJwAcAFOof7A/iF0bGoHQZcB xgSR/SsaAL7Cp0YRd8GtzuLAi9CFbOmvMWBpKXIvd9qkWALGBwgSKHXsi9kYwcjRlSaRbuJeqemN 0/1yQNKxbQMIseg5JkXRQFK6JGvMF5i0O5/zNcwxvqN+NtoPt1KK9ud8K9nxydmYErb22DtFBEAD 6gHHp4pESwWBGqWjGY4AkMMP8n6i/igASAbAIAD8VI1s+ugCgMRAjSKeSmurlUSwazn2/WSP4EKI 7YAEKxDFMC9L3ImCkgsgFlu/wUTWWAQvU5MIACipI4YuBYxFiUdwSTC2oULVBI8IeVmr670wCa2U CGRAwoG1Qm6lKOgKMcbrZsmntce225oWANAHBI3/G1+5HUrRgDw+uMhJHjhyrS8CNUpHwwVALEDA 6bmrD+f9dIzsP0oA8I5/OhYBEIt8SSKkQrnw3QYvgGDiAqQn9gXpHgEooKMlXkRBMSC2BoNlVeEC AErqAqBL44lFCSNAdsFwBQ/RONrmEs0FCvcGDDGDhwKKupWMKBVljO99nUNrj639mhYA/+04Fdg/ BpDfYYQYR8DCrq3Rq1yeLRInLQQaTgDgHADLXxIAUTLAzv4hcREAabXO/NNJ9/UcpgFSZ36kRly6 gX2JAn+Lx6Yf+8qPilAGAQBtI7ZBurDe2EQgAiAZjJXlQseeXRcL7XFSv4+wUL72F3srKRAVa4zv fZ1Da49t4TUtAKB0JAACSDwNIARcW6PUH81O/vCRFNwRaDgBEAsNCQDu9I8Tf+FMLPtHAcA/mKOM AMQiX3gEF/YW+9LSI3iNAwBLSMVrIsrOWI7uSxR4RnZ+lnrKXgnqrcvrcixmbCe0SxOKbecZsf8w Dh1rrR7BBYSA+8jX/sJvJY5M4caUsLXHtoGaFgAAOAoAfP57kfJ3x41LIh688ipb5IAHjlwSjEDD CYDYVYAUFyCa9Qv035H9K5WhzAeoUcSDW1itXJgpa3Hxj0egMmX/+Ma1T1AOIAr0IrcXM0mvcBlG AHA8x96eXVqRPYWsmaKLjElyzyZpP7GMECPEitiS3Eocxlq8r7Nu7bHVXdMCAIg1PGnDnH+4+5CM ACR5HMm1dgRqlI5mOAcA8MJVgMgFCA9oTnDUxF+lp59w59MAZBWgct6Q8KSOfRsljODivZCEIrub Z3+vJyRwFtfhJByoJAIg1gsluQBI1+/f2Cq8hqR8b9gktezYhmOJKdhchluJoCuDMWH3tf2plbC1 x1Z3sACAC3kgDg0HwK2VWbm4Eiucx2Ah3PBwg6qEOLjOMlB8JSNMGVJQzisjALiuF1qCy+NCwHzx J5w9jAGjKVbhTiBoDEZQsqBkyRIoJmoSzNp3UCK3gQLfB47ET4JAwwmA2BEAQpPLABIAdvbvUhM1 irhL0Wo3Tj6sy45P2Bs69iVqjGB5ryc0I8pJBt43YaZaHD+8TNXB97qcG28ROQkpUbBJvti6eHgH 3M4uxfc11bcBg9m5wRgrCMtjTDAm2bX22JYQLACIPXMnHGLVQH+JzkIWSmT4isOkCuXVY8JNpF8L V/H+e4zAUzPmiJ5CSND1NFEGkD1A7rlCoPhc2Oi5oCyhyHoBc6P49owCHjtySTACNUpHsx0B4GiS DLAs+umFfo0i7lXG2ooc8GqE5y9oBt/OTnt3mm9q6JESYIbdESgADf4ij2KWCZMtzwgAFNbCnl0Y cNTdEaaRcNOxgMbjssyL743sawbtmOZ7IdSCxbaA1LK4ldDCkhgTfANm1NoBmTwFgNKnjhxUZ+qc fHPvHe6UbyTodNIuACBNignF50k5CgCaWoDXKolAZWHRYuWKCADfh1tdxq9ROhouANxHAHQZkEoL qFHEUyl7ORPxekMDZeE+9HDsPnpgcV1wIY78famYgWPTsS/UHJh6VBl9zVPKUioBALZFDXS41GPU XeByLYdFwcR38wq7HA24Vb386PTc0TnBvQ0nqYJ8biXA0KtEYFU57+skUFsaUmxdB48AoN+LQo65 U41CkRefcw7yZk6vkZHjR+lxB+Wg98FjpuQCxHMntk2DBpg4PLdJhNAZSER3AUI1AvG5fiCvHh4f Y5KrT5RcEQEQ8Iirv0tqlI6GC4DCq7BGES8ct4wM8OoYi+oMc2e3UfMXvURIlBm+bMM4G9gLEOMr 3JisVwH1ZMsmAKJ0jksVGFuyV/c/cgVjOu5N0cWT3uumcyk71qxlFi+ufmihhkCRIaO0pppkeiv5 dv9nakyS+zr11o7tKjsBYGTtUApoOYADcl9ixpzoK/33GJP3pvPIygCC4tnCSTmxbX4JJBvFwqMm AXNL+KwAPrDAnYWU4QJ0JYKTYVOT7a47af3q9cyRyAkRqFE6Gi4AwkYAEqLML69RxFNEoFRJuRMm eF0lpx3JiSy8VyxmuA9HRLmyJCEK+EY3du7GvuztEZLjpre6hCU1muRCgo3t3+VCgiiqRxZS9lpE yJJOwE3qfivZEzeOJOCOSLFWedVpqW6lUhnjqMBdGm0hIwC6AMCnN5FUzpjR/x4i4F/eZY49+tzX n8YKlP54uMpFACj5og+PPvM4SgBwUUEGw0l+nksURQCQg1BaZD2LdGLvcYmQIgI1SkfDBUCK2IUl VaOIhxW2/Fe5E1O7y4TLuxAf2TomXqzdboaXGwbYE0CLY/vy9cVALeDEphYlKsByL7YXUNLYtqEr MZdmYLwpHHFALxH7beViAxYt3anA7s3YvhAtlA6LAJjgcivujxF3G4xKlWeU/FYqlTFeN4ux5afY 2hHn2Psr2AVIFwBI5emjd40bXWWQMSvd9jwdfpWLAEAHIUtemIiLALBMRYgqZhZ8PfU03W92iZkc gRqlo+ECQEYAkjeauknB66UYO2ky9n2GEXT0HC+MulxJ0It26L2qsZjEdvTqIsdySWxqZRYAOoGO Rc/YALy4ZmxHuLs3UayW8LrT3RsetBC7BoAixIoEo22lupVKZYxLy7QbnFZrp4qLxSdFAcAdZhQW jq5BxoCuMi4CAMriKAAwGnfmISpPnjkuAiDKZi51oqY0pM7aU0zQ65kjkRMi0HACICFeyS+vUcST F7yEKbj3lbpQJUcCpPRoer2YXcxwL5SxDzjWntgIkKxSxqjubXz1xvKAqM5aF0so8SxGACBxhY67 mKRb4giCowKE9C1NETDHtXeQQKR4Vzq2f6oRtMGrg99urQv4PPfYsnvVi8KPS2UMlNTLnqhbMpXW XogA0Ffij5oDoHNZTta5g41C4l0EAC7zDwEFCU7VJUvIRSdKAPhuEMYFAJ8bkCJfTz2p2LtSIqSI QI3S0bxHAHAxUPwkRL9GEU9Y6nJe7k5ZXJwlHDuzlZeoF8lwYWzAqFwoNcbRFUUsUYAIsbhxOy3d 24CYY/GNBY81leMQIABc3HKU4Q4Xk3RLYvH0oq2QPsBFFB/ZRuy4QfI71LH9GxsnWIuNIazjH413 bEuWMSUFhCS3UqmMcREAubX2HAQAVJyyWD7eAnzSLfebV3rNoYWgXz7KBmVtftx4i08MQAZPVBji 67nT4jx8wVDFVYnM4EQfLUHBoPToU3Fw5g/2p9DSQLgXGNc5cEYZCUmdvidPMPmDSFJwR6BG6Wi4 AHCHBmO2kf6W5sry4CgDaANgJccaRdwXt5qI706UXfiT4ytf4bLu5E/vb44C2b1cukdKLIWFCLEl 5brCEtklqQJdgGKLqdvm4n6j15oL98K8XIRoUbeeI1wujRPVi68YKNWtVCpjXASAY/Xxx1dYa89B AET5x/NecL6kJs4D1hf3pHED+44BigCIiqxoCZQZxp0HdHVBliuXwFflDKoIPQVdeCQn60lSQI0E dmLHASVV1OOrMfOtUToaLgDc5wBw6g+7gMFmwBhQCcTKABEAJb+jXN5eRFZcBADSWRrhxW4bCHYn Bxc+ZPFjMYLsRT58XZKwULFmk2GWjmEcEI9NqigXIHo5xVrI54fERtarLPYSiuAyBFTUfefVX+5Y ZOzUjJ1+g0V2TBOjOaIUfCuVyhgXAZBbay+JAFA61BXNANXHhwv4gv18PwG+Kj9RWEcBoOTIl+hR xhxw+U5MHzv7oxQOJVJ+AYAqBe5u1F0iAByfSOlGazgB4AKfQv2B/UPo2NQOgi4DjAki++cagM7U KOIuuNVWHBcWS29x385IdygKJwq+fr0YP9ZsSjYqJo4SlFkAgIWO03N5x3wsMkrb8GqHLkLUve2l HtN9KCMWJSUCIBwrA7zSdCy7lwDgtVMqY1wEQD6tncMeCxHK3YBuZuwX14PuAIN9ELQAKDnSGDOF y5Gt0sKdxlWAkNQqAak5CgkI8BV5POaoG8bzIscesop+RQOwK50rFoxgDAF4ZnQJdBmAzeTghLk4 3pgSLRUEapSOZjgCUPXyb+3jR95P1B8FAMkAjBA1JcAoAPBkjSKeSmsrVSJexCsjyx35Jb4pXWYA o52OrBqTVTqVY2FBlhNLjJATW3qFMV9HU40937Gmcoah16DL5XCVo2s7kb9YEpyuAABkcFJvWEi3 YTvWZizzi4pgGQAp1a1UKmOwikvS2vMRABkRViVZ3k8PLTafTHPIBUk5PLqVmdOUNZzH6QRRESgF GrVQth7DaRLGsqT7RJLU7AjUKB0NFwCxDQI4PXf14byfjkkeGAWA3vEPmdLJGkU8Freai+BFVjIq nctbmchQqQRALHo4O9Y+AaAmBIAjmaPZwLHSSGlLsUhyNqyPAHhdrhPr1Bt2rP4JZv94YdQsiFLd SqUyxksAZN3aa1cA4FgBUV7FKahW1tix6wdotzQGgo5MCk3HUuNtiCMYvOA4lkKjIjisQc5IFBOi 0cCFbk/qTyRJ0IJAjdLRcAGAcwAsf0kARMkAO/vnXJ8fiwAo233oxZwyMr4WiQJyUBeHbyATFjaM kDrWQlEjADhBIpbT87GU2Mj1LQBcGkYWGqBUt1KpjHEXADm09toVAOTZjxRZ8cJ/d9y4HPrmM80C mboy25jze2zVpArgK4LAZy/wuQdgrTIdAs4Q+1dmTsscgIw4howA+AFLAoA7/aNTEJyJZf9I+vkH sxcB4FcN2cd2pJ5eUwZ9ra5FokCd0LE0zoIwjWY41kJRAgAL615N0EMW6zJU3wIASufYixzbfiwR 9JEQ9zrKwZuuVMa4C4AcWnuNCgCFtirsvw66/5Gpw62BQxxE7qloljN8Ci8xfjgA0HBmOfX3g8LE 8zIC4EsVMorfoCMAFjQVFyCa9Qv035H9K4kr8wFqFPGM2l+ByTpSTxEACg8j7hXLdC194UToHWuh WAHgPgiA61rYqW3dCwAoIK7xl4Tix16rzAkuFeculTG+AiDT1l6jAgA0rXFtH5xDlWnHfMLEF59z zhOrrw5/IUQlReQenXbgg+WFoO+EQFONicfz+Q84RAABfkXxQKMl8GzEBLlIEBegAikQZF2jdDTc BcgFblwFiFyA8IDmBNv3AtNX/xQB4IJ5/nFiiZp9CmkqBnv5S5RqDgAU3wvAKBXhmEjhAsC9V7vB XYD4feFYubFc3xhBaRKlupVKZUyAAMiutdeoAOA8Fee/Rs1hTcjX070cqD8PURogdosA7v5EFuon +axo4P3A9flmC3AGxQNlZ9ROqbxYJRFHBBpOAPjuA8BHACzL/jjCXbuSy72AtRLTq5cuu0K5sx+a ZhprTGzfvGVeaSwsNALgzhIsc08dOWLhAiCh4LGISUcE+DSDFEl2bFtKGAEaiVcBk9wOSa6NKmbw rVQqY6B0sfc1GMwdq9KqNUv7iYUI7/p0OXHjpAbTEhQBAF/1uQq6b48CESfxnLLzrn28hDtK4WAC JY5jAnAGhJNdbyR84MjlXgg0nADwQgci02hAKuxfBIAv/tnFd3kj0isqdg3yYDtj34IBAxGxndCp CAAocpibh+M+wdzIMgiA4PIqVaw0Fa92qOOQkKgFt1vfC8FOr2bpcl8oe9i5XEJxHO33spkT6FIZ EyAAMmrtHPZYiEQAJJEr6PwTOwhAHfl8Li/Pl5N4WgSJd/bTSZIENCuAEic3IT4lwFg6xxtToqWC QMMJAPcRAI5v7L6/7pVRo4i7F7BWYnp1YOuTDvVi0p4mEBmCo2bwYhiOaXrxcl8+yqHw6h+l9z1n sY78tSQCwIusR/EbBXCvdqgvgukIoKMxOdy8gGFaYkBpFaW6lUplTJgAyKK1iwBIwum9rjUKAH0E IFYAGH399cU9+UAB+UfxKQFoPImEqLkTOTyCJAtCoEbpaLZzADJtHzWKeKaYFJV4bBcURXARAJb3 JTz1aJ8mJSkvDu1iBoDpXi7drSj2rc9tiI1stIR33Dry15IIAMDWi9gZi6+39iT15QhgeQQALz60 BLAf1xR3B4FiKnKoVLdSqYwJEwAZtXZqALE1LiMAXoxfd93RRwD0rbuM/v3ovYNuPMY+e3TjgRqk BGmggDr7ubcPRuMiAecZ6/YURQYaM98apaPhAiBsBCDFxlGjiKeIQHmScidzUdsP8bI4UjGFxHtx aCMP9u3C5+9dvVyx9nD74fEd+xbXIwSAVh4BEFZkux+XezuEdODF6XIHOdaLS1IJ4+DIWGzTxY2W HM3GaMq0+NimyxOPtceRNEepkVIZ41gWvX8hi9ZOzQkppiVgU09Cghv8WmUagHGzAu64D4wcpzjj EkCIHvF4ZYsAmtSL0fS1fShlfS1R3HDAOAiQ8Gkjl3shUKN0NFwAeKGTReQaRTwLKApP051wuEzA daRxylvW6xXrYkbCrsdY4qLY79t3q5A2xyoojwCARutos3unu1eCLszVfRWaLO5BpPvQDpU7QnHZ N2bt5RCltKVS3UqlMiZYAGTR2n2bXIOT+OTFB95Pa3fqqUFD1fc1U+YDELnHITuk70rnPSWC4wZG bx8+JiAuQL43Qhbxa5SOhgsAGQHIohnVaJruPAnInJ2+uL/vdawclQMSSrsXkLsZmJpujK8A8NIb kKPCXx25b6kEAIDmK3vsIwBe7RCH3e13nCOqxgYQcC+TW78dFsd1bN1blJ5gqW6lUhkTe19bni3p tnbfBpacAUsKsQjAEwN7/aN4ObQf3NULIuh+O+gyBEoDHmX0K62XyuPjSYs9vs1D4idBoOEEQBKw Urm2RhFPpewlTMT93WanL46sxZiIO13T3R4USL2SMvo1xRKFJC5Muo5yNLhsAsCXstsFgK+isDdF LxGYyi3pfhO5DF84NgldTPp2V9thdDcDLDHeSl4pZG1M7H1tEQCpt3be6qBzmk8CARyQYlKcWPIq EeoJgVSeSJKIIwI1SkfzHgHAVYBSWQuoRhF3bE81F82RuCOBi6Iv7m/6qBS8XJ+jEnF5x/OMjGMa sYnoQxBexocplrIJACiFV8uJFQC+qUVNSgE65U7H0xoB8DLergHQIcGxRRmTcrzWfkfH3gVKLlHD g+UxxqVEltFFryqObe30ELA8OcmYemK3UpZYBGqOQtS0wTVKR8MFgG9ttZH+lubK8uAoA5QtgeEr fmoUcV/caiW+l88xdvXx3infmYtRMzjdJQS+XKGfjCfla4ZlJCGWKOgswd3VQe/mdCx4CQWAV0d7 LCXybYeQIBBlgIWaAbrnejHOtASAbw8xWA73ETQkfiuhH5E7+wfjjXeTLwjZ3Uq+IxLF3teWEQAo SLqtHd8OsTWFj5pYyigR6gmBWmEO9WFnjdLRcAHgPgeAU3/YBYy2BEYlECsDdAGALaZGEa+P5m4s RUDnFi3r6cW3LEsJeXV8UqZhZuDlUX2WAQIg9kVOBus83vHaEgoAaEuxWBmbR9StFNAOvZqflzG+ 97u7CExuM6YQNSG+PLcS8mYvSUNFw1WDA7AKvq/tAiD11u547xjdzeuJ70pZFAR8nzwSPwkCNUpH wwWAC1gK9Qf2D6FjUzsIugwwJojsn2sAOq5RxF1wq9E4wZ1bvq9n+wKOjm9E30yN8S1uGLFm6CMA sZeQDTo7qWkBAA0+gKVF3Sa5tcPY4YiAG9m9DaTSgCGRJG04LRvsZiCMeSKTEBP7AgPptnbHGwdK JBS5oRAIePjIJcEI1CgdDRcAsSMAwP6xjx95P1F/FAAkAzBCNbLpIwIguEUWcqEjDU3CG1x2Esin Dxi6JC3LyMTyFSNLcERGr1xH5Ms5AgDFCXDdsbRwRzQc0XaJluLtlk/rtXf/U3HyMcZ+K5XKmNj7 OnYEIN3W7tI40SeqoeivFDbFJ5IkFYtAwwmAWESA02M3P8oAzvvpmOSBUQAYO/5lDkAs8sVGyJQx OBIFQCDAYcDxVUrREg5EGAWAS39ekhWQSisAoMp8Wbu9nbsg6Vvjlvgp3nRh7i5hZXHZDa3wW4lj W7gxqQiAtFq7izHUMIQTNxQCKT6RJKlYBBpOAOAIgOUvCYAoGWBn/5B4lADAyqhRxGNbUq1HyJS+ uGyBhABmaga8U2OZU+y72SgAXEiwkcS7XBjlaBFrqt3XxeXyWKcIrDUveme/U7JuAArhTve29Z0N HMb+HSslayRjbyWObeHGlKq1uxgjAqCheD8VNt0nkqRmR6BG6Wi4C1BsgyABwJ3+aTQglv2jAOAf zFHmAMQiX3iELF7SQA3d2X/WGsDFkth3s5F+uTC/JGu2lHkEAGotFjQvt/vU26FlVCH1my7AJ8pL BthXEVWKkzqSltkssUgWa4xLE3VUVi5JEVBGWNynu8DzszF5cMOWOvY+kggpIqALADhTE6FKqhVD 4RScgd59ZQUejpfLHADe90+zfsEZyJH9K9WjzAeoUcmVYpsrc1LwZkrRFyiA/ZMGSNEMeBmDJY4d lrFv9yiWYO8Fj1qzpT5GAKDW3F13XNo/tEP3BO0EGurLIs9cjPGN47sXgaMACLub0r2jvW4lHbcC jYm9r13mAFCJ3BtnVONxHDSDx2DDUuHGLLjv00biJ0GgpuloiABwAQtXASIZgAc0Jzhq4i+mrGsP EQAumJcqjsvLMpa1wDvSMtfWpbypmOGyUAk3JjbTKAFgVyxRc6DrRgC493y7VD3GcQTH0hRpzCeK b7kb4xszufG8XJBakrsptlXH3s4YwWv8IQqxQoxxydRxBADKlby1OzYPyKgxeXDDltr3OSPxkyBQ uyMAYHmIAIgdASA0uQwgAWBn/y41UdOSy6WA9REnYGst4hBA/d1fpXa4kpgB9gDtduz4JzNiiUJU 0exv9Cjm5MgDSu4C5MXXvW4QqL6wsSBlx7oonL2M8Y0cbHyK1J9szv9WssCVvzGx97XXCIC7OrWA EDuMgHd9w1Lhxiy470NG4idBoOEEgC9YJAMsi356pSkCwAuuYiPDIxheQrEvKuQruL+pi599QKHc zQBLwODgHtNYohAlAOydggm3QK4JAQDV6uLYEFD7gB4g4JJ4lOqL8roOMMb3Eq+biN9KaaloxeDc biUXoHIzJva+9hUAyVs7NAzLo5Vu+cbkwQ1bape7RuKkhUDDCQD3EQAOcey+v+71IQLAHatSxYQ3 KLyT8IXNA57MiPfrCEBGFjMy4kylqohGNgZ4PLZDkJoFNsLgKoDWa7QfJSsE+NV3zCqJMeW5lRr2 vtaVrTKC2rBUuDELHnw7y4UBCOh0FBhyTXygsCEuQAEYpXuJCIB08ZTUBAFBQBAQBGoaAVS2xv6L xuTBDVvqmm7GNWe8TkeVRSzL+TV8GdCwEYAU61UEQIpgSlKCgCAgCAgCdYyAQoVxEKlh+XHdF7yO W3IJi1Y4HQ1YcrRDhw7hAqDwOigc8cIRKIkByrof8FJBh1RuHjrOei39gS74aZUx3dTSsqqc6aBv CdqGc15Td4iyJ4seLMnBcTeeFzlhvk+svjoEYyLvjhu3+JxzEqaf0eX6DWK/Z/V7POH9Tpdnfasa 00+xAaRbQVH3Aj/viBinvDQh3siDsXJxzgne/l50OewqlyyMKWPxFWuxQjFNKo5LFlFxUklET5zu siS2Ga9Ntx1KanYECqejaID7B3rwEwkAGQFwx7q+Y8KTEWdVwl84ho4lnRzgyQIFAOQetYBmfddO QOnwLZuRAIBaIH/xqPkevloxqozuAoAXOQAxuATIPfJ++BvF8uF8lDYIyzTFq3QSab9n7QIg4H4v VgAkbwAp1gVPKupe4OcDBAA+rqOYfXIBgC+CWFKLvUWx0ShCrACgfDEmXojzfNxzsYuihOno4zD4 Zkw3WUgtowYpyRoRKIkAcB8HSCoACm8HhSNeOALlMUDpLMT3Bz7ckfTj6ivYrYub+ETpAbqK3mq4 0h8yeJzXSKnBGQh4CV+uEePzOXBIOuFamiJpNICnjO8S4sHGBDEjMABLRPHJJIXjchwUk9A2JRdK R5/QiZdTInqOOs76Gewn4wDCMco5OI/WYlXyjOCYryWP0ZDzwbGeC65iiUXDXagwQSwUfMVfsXlg 3yTVjp6aUnDMl9c1XULtULlTsLyUhVJkHhkoO3bbw19i+fSVnyHeT7+CGXCMgWJiNCw4agaKDycp O6W6UTnAX4JduRZSo7woEW4nFopgV9oh3r8ICCHJ41DjpKrX73GOG79WqV8ejTc/6h3gdNbSqvlC YWg2b5b0xCDE9AcLWaI0AP2BE2sz3kT4LEKc8YmkPxCoZvU41LCj7gUyQ7lH9Loz2qDQaLgTkXfy 20HpMqfbH87TXYw4UxVj1zsmRU9XvLvpDLUrTJ8edLjgm8J9dXv0O5rMRguR31Pz1h9iaJ6xsArs GI0aLb5W4Aw2eJ2m87bHS0cXolX4mOJYkbXYeOAn/qzjlUVvN14EfBvyUiu2lYceNIIlhdNRboCL DEgqAMJGAHAVoFTWAioc8UZo1o5lRAJBr3B8VtJii/Cc4hHwV3q1KLyBRhKIB+DbDv/iPriYGmUB J4mzIlPB+JgRMgBKTbFNIehKyhDZkiAvIxqAgwxEp/Cksu8SWkJrfUJ8fBPrZvN09A2AkUxjasYc eUmRl+AZRBIrCzPlAOIZDPiKwgMCEy9XKBFBQTF5Lpg+bwOULK6qiTwADvgSqAi+bjMvOF6ObB7t hEuowSA+eJKzPbwEo1EZqcg8MvrzEE3HAzwDWRMLx5NY0eQCRBfCAaoISg2+0rVKavgV9QZ++IVc S9B55JSUOD9QxiKoCog24d7G1OypzVAzVtoJNXL9HtdBRqao1C+PRs2Pngn8VrW0arqQ355kG91K dNdju8IhSjpJlihtXn/guNhMjyDdbP1GNhYNWyBaiLcY3Yl4L9BHOc8v5E9IulOwZRJBpCzojuN3 ECe7XADQIw5xhmhoLd2zeIYeZUhqlUIhYcVo9EjhzJWQoTsaftXvaL1CkVsb72ji7niVUljdQqXR YmEpEW4tb2kYTWl7dAbR4+mgGYQG/URPLWNqSlvipRYBwO+RnI8Lp6N5CwBffNtIf0tzZXlwlAH6 lsCYdeGI+yJQx/GNAoDezfArj4BvYlQFCjnmqoDe00gfITXiiJSafoCZctaC/I9Sw+c4t81IXPgl 9gQpZTogiqzAghnRi40YJ720FLMRDfgLWOneMpwz6TniOwx7odAwPMAskBlEVRBBRBFwaUW0E6mz DhokCFkYc9EhotTofYarl0CyHDRjarzgGJmqGA1DnmepYiSmPCNeZF40TsfJgUfh/UTukbXTUABd C+cVbQDR9NQwWRISZIaiKOhaaBVkCeZLPkjKAS8R1gXJaawI4w3C8aF7kIByvI/0+uXGKPc7Vp/9 PoJLsLoVS6CJQkAtpDQAPpDF0+eW8AagP3BcbAaz8SbVb0b9RjY+IvRnlPEBotwjxrozps8JIubF 6SM9MYwCAKkzclzEh6KReqSbkcsGyogItELTUSfQB74qtyfmqFhrzIKf5Hxdz5oXVreQhjRJ5EQJ AHqYY9vTTaW2h/YT4Ci8sTHjgf7EtqRGLwUUVPhVBAC/T3M+LpyO5i0A3EcAOPWHXcBgM2AMqARi ZYAIgJybskt2yrOGd2MY3x88Ar6ciJXqHSrUdYQPTf1dZREAEB+Hqmn8QUlNfxkorx98HPN87QmS ecqLBMtIqVEu1EXEOxqNZvPucDSJf/Q3HM9RqRF8T1AEPKC3EVdoyquO3qloDFGZKNCMuaCpNCbA 88WXHNqD9IJbbkmNv02pXFENhluLDh6UKQJr7N6D88iq8XKlix0dbJQxAX4J77nHFPBMbGpKRXMb +LVwTAbwfCm+fiGWFOkUNT8FNIKCVwS1bbLN/T5S6peXzkjj7PcRSlCqcd6wISP0O1faOTIkOKk8 CqLuJv2B424ztSV+M+o3Mi+C/sAxVkHUHYflxUqkC43p8xSMZbSQdd4YlKqHhqQ8yuwCgDQhCgl0 sKGP8fbUrU0oADhoeqnhV0ifMFSw1SsCUnBse3AtSSm4Cp0hsQHoT2xjS7a/FLhtLu9xiZMWAqUV AEDUjR5BSV2AXIBTqD+wfwgdm9pB0GWAMUFk/1wD0HHhiLsgUK9xFI7iJQDwnU2k0P3lqnQb84cm NwDfK7zT2viO5K8QssFIeuwJRgkASBO7mZU3HPb9EJmmy425YAcSUiilj8fYxUU58oIgUPwMdpfi ew6JkfEFzyPAMTE5pUQ6ZUdWTbkgRUAzEGoOPn/lKy9Co8284DwdiIwQ2Qkcef5EFZk3SOT3eIb4 NHa9Ky5AhAm/hDr1MRFdTiAhUFJTbi5KEIcaeDqKAKBflQP9FsNKp3ZovEGM9wIArkim2PtIqV/3 +50qmlo19ZICaLwZoMc28jBeFhxmVNqbLmYgAk8tFQGg3P7KjawXLbYKOG7K8zZKAEQ9gqLuEV8B EPUoswsAuAqqCRuS8iQBw4y3Z84CgOCl4VOlhfC68Gp7eCE+SLGtGgUAPSqp4NSS8YkR9VLghtUr 9yhnuaLoKC3/n7XZxhEA2olM1wBJBUDsCACwf+zjR95P1B8FAMkAjFCNbPqIAMi63YSlr3AUdwEA j1R8+vNnK6VG6eCrhXe9QHy9Y8z49KRnK43PGl+uscSFM3tlyJsnqAsATFlRIBwxJF44LQyVACao 5ILpQMHxpYiUnT46D9Y1D0IN13KfXXwDYV4WAYDShaOEZmCluNARzAXrCHudiT4q+eo9YRCZenMx R8XxAA2gkXTuooDIUIMh1YGX0K9oA6ezulrjlB3777nDD3n54wRclB/kxkPEnRKhFMA2PTXO5vkx xdTToZ8oX+MBrywibdjkqF3p5E8XSNR3SzDyJmRsEngJr18ejZoB1SO/s/T7CFMjxzY4RkuohdAZ 7FrGFsvdvfiDRb+bsAEo7Udp7XabCRB+M+o3svEREVUFdC+QJVQRyj2i9M3bH0EImvERqqSDdxCa pzy3jY8yuwDAxOEvdgoY+zXoycNvT35HG98UPF96+NtfHLy96aU2Nnil2cS2Pf1FQwMmHH+0RHli Q+JKS45qS8pTDlILe7PLVWEIGAWAsec6LP3Yq3QBoOxDrGiApAIg1iDg9NzVh/N+OiZ5YBQARvhk BCAW+RwiKC9FdwEAF5ILkE5q4VfqHaHXIXVVEl3TX1o6WUGiAH/528uduOgvhqgEdQGAIgdfjTpd 1m3Atzi+fnguxNWIweuUBc8Yc8RXBb5U8C1LZwgWowAgwOGAv72UWlboCL6qjbkgd0djsBIpWW45 +QNgZIROt5krH96c6HKyH9NRXo2UIHdJ4kXmIPPufDCVvICwi506+Ok8nFRoOn5F/MkpCLv8janx lPVc4EKsbuVazNdlBMDIeIwneXXzpoh4Gjmi3iSM9UvReOVCTSkDOHqrpjOoJ5Hu80SwEXJrqVnq DxZe0bwB6A8cHtNus/Fm1G9k4w2rCwBIjd8L3Ax+Xr8w9hHEH0305KE7yFi5/HlC95QuOahGoh68 1CNATycjvMbbk9/ReoXqDyu8/fkTQy+sjh7VFz648EGkPHb0Z11U29MFAL+z+LH+xNZbst6W9PTR thxogGRBCJRNACjsH79yDZBUAOAIgOUvCYAoGWBn/1GePyIAynDX8Ud2wDEf0FQup+F+fh5P6vOc orLGnrwAw1JMEGxQ+uxj7TGa7V5wPUcdZzwTC44xGr6rXGqBX05dVsiNSMVxNMhZiDNIQi/WZuxg tieo/KqXIjYXTAEX8MFjLg+4fz/lxSPjSXL40VOzNA/ADZJSbNYTj21gSSIYb0zHBPX6xQu5/oxq k0qrRjOUfHXb9CdGrP28AVgeOC42g3n6zajfyI6PiKhosZfHRiAY9TvIWLOO94i9VfDuDGT5Snww Rr899SbkVaHK7a83IcUGMMDx6e3S9hxvE3w+KLYZm6LLS6EMPKFxbIgSAOQCFDWXNS2I9BEAY8qk AZIKgFi7SQBwp390CoIzsewfBYAOnwiAWORziOD+RJOY9YEADdz7Foc6/HA421FC+OZSSHxyAaKD Qsyo3UyjOi/LXKJatLlUeNKTBA/QO1E+qSOQAw2QLNxHALLGqnSrACkuQDTrF+i/I/tXIFPmA8gk 4KyblCX91J9WkmDJEQAeD9QndujAWAr0RcZQ8mJ6mYcd8zgBgIYFvFJo8Mip9CjnjGEt2pwzRPbs sEsbnwaOveylsr9WjCmQHjRg1mVzAYrdCyzzEQBoBLgKELkA4QHNCY6a+IutRx8xoTM4LCACoAFv MymyICAICAKCgCAgCAgC5UGgnKsAWWRAUgEQuwoQ1Q2XASQA7OzfpV5FALigJHEEAUFAEBAEBAFB QBAQBDJCoHA6mrcLkC+OJAMsi356pVk44l7WSmRBQBAQBAQBQUAQEAQEgTpDoHA6mrcAcB8B4DUd u++ve7MoHHF3UyWmICAICAKCgCAgCAgCgkD9IVA4HQUDjEt/Wk526NABza760/MApzC5rJcuStIO Ckc8ifE1d62yIpN8FQQEgYQI1NxDQAwWBAQBQUAQ0BEonI4Cmw/4hAuAsBGAFJtO4YinWJbyJ5WQ 68jlgoAgYFzXuPz3vlgoCAgCgoAgYEGgcDpKBmD3vddfGQGQth2DQBt3Wb6ZK+3qKgeCgCDgjUDr 7SQPHUFAEBAEohDYYfsdBJxaQaBwAeDF+Lm1cGGIAJARgFppmqnYKQLAm+SJWBIEohDwFADvTZny yvnnw983X1vidTtPeOCVVZd/LrroIrwWEtFPGpPFaF45SuQSIuDrHFy2+AjpgvkPNU649OJLRQCU 8FaKMqlwAeDb68/jhwiAwuumcMQLRyBPA0QAiAAQBFJDwFkAAFl/6Jvf5AFkgPuNP2HCBOL6ROVB CYgAcMewDmLimt81+sEXPQqAxnEjFAFQW/ddGehogAbIew4ArgKUylpAZUC8ttpoEmtFAKRG/qRf XBBwFgDQ8a8IAPjqPg6gCAC8MEoAwK8QnyduHwGAyDDCYH+qQASIpcfR81LiWCIY04wyJjYjypfH NF7lnhQOsyhgJnn8JrwWBUDCRIq6XARAUchLvu4IFE5HA9g/lC5cALhDgzHbSH9Lc2V5sMsArvUp LzpJpuPiRTX9gPNFspD4IgBEAAgCqSHgLAB09g9n3AcBFAEA1J/7/wC/R78g5SScRxnABQAeY3wu IeCkUQYocfBCSoSGIHQxYzeGJ4tPQu7mRJYruVeNnDABT5IrFB7rMfkZKppRNen4oNpxH2PJ52Fe 0+9HEQD5NBLJJQkChQsATondj8MFgPscAE79YRcw2AwYAyqBKBnAJ8kZj8uAeJIWU1vXigBIjfxJ /7cgkLsAIO5LBzqhh59IMHC+TowWT1Kcaif38jkGytOMSDzRbnRAIt6vZMQvJwuNxnAjsYsd01Qy IgrOz3NrMXH+60q8f7nrFBc8StZGgaTIDEzTfcQmo5eCCICa8x0SF6CM7oWMki2cjpZxBECh/sD+ IXRsagdBlwFKxYgAyKilhiUrAkAEgCCQGgLJBIA7oSQOTdwXKSn/ig8EdFkhEmzssMeYPM4Knm3y Baq65bA0iTHzbnLqj+fPJYsxfGhCSZzEABzwzn4CgRuAERRtw6/ix6QxlPjGEQCl+9+9ssKezHSV ZV0pEQAiABK2LrncjkDhAgDMC9AAGY4AAPvHPn7k/UT9UQCQDMAI1cgrf0QAlOqWEwGQGvmT/m9B wFkAgLeP4gUEswLcnww69yXOykcAeF87P08d9pwBKyfbftIEAEUjQuwoAOzGYNmNvf76eWXIgtN3 8gWKIv12AcAHNBSTdBem2JkS7hUaFZM7x+px6lUAcPGDCOhnjNQfo4WpAp2o6OB7GWM0Q0YAkt8U eaZQuAAIYP+kGTJZBQg4PXf14byfjkkeGAVA1DQArNfCEc+zeRWelwgAEQCCQGoIuAkA7DzmGgDZ v3unMhcAUb37xJsVdxd+npN4zoyRUuuzXSm+MpcgqiudP9+MvklkjMK2uWEuIwCcnesDEamMAGAF AemH1BSsMnqMKwxSBEAsuQ8WAMqF/KvlpwClIQIgo5slo2TLQEcDNEDSEQCcCWD8SwIgSgZY2D/e wLyq6CsdlAHxjBpTCZMVAZAa+ZP+b0EgTgAQ6TdyfRwTcNkWgAsA7g6kkH7i3MSPuQsQMlri7ivS Wdm9hz+1uADwHQGINYaMj50DoI8AoGLhrjsuIwAUh5edm7HCFYpNNVbmA2T0VKfOZnwzKn3PmGnd jwAYCYOFdocJAONVCubKaEAA9cdLRABkdL9klGzhdDSA/QMU4QIgFkcSANzpH52C4Iyd/YsAiIU3 5wgxAmCzO9tJEAQEAQWBoI3A+NKfusOPPiBgeRRwAUCEFePrHe10htxjdKLM/ebJyUd3ceEd7VwM uIwAKD70RmN4OpZVgCwCAH8iPaCPfugDHdypiV/LceOahCOc3eNaEQDGjOpbAJDy4bTBKISM7JzT ekLP3XFIB1zvu+RnjH4NurQQAZDdLZNFyoULAGLzXkogXADErgKkuADRrF+g/7HsXwRAFm00SZoi AEThCALeCAQJAGDP3O9fGQQI3hTMfvsHrFtfneFr3QcgNkKUSWHGOHpG0fo/vs9DtEq5KnijA9/c o+JbCCVd0pgCQGHVOtHnbgV8/EQ5tnfqU7L27HgiLqMEIgDSukHySadwAeDF+xW1kMkcAMgDVwEi FyA8oDnBut8/rypFgut3V+GI59OwSpKLCABv8ifd4YJAkACAWz5qEECZE1ySh0OtmEHjITiOUTef WA3QmALACIs+MsDPOHJ9PWVFS/CvLjpEH3AQAVBbt2cZ6GiABshwBIDqj8sAEgB29u9S92VA3MXO +ogjAkAEgCDgjUCoAFAGAegZwoWB+3ZgxkfQCrf11s16k/irKNeiTw752NCinHgSO9ExR4pDbjzU i6+s0gNfk6+lg5bAx3GsoIYe3XYN0AgCwNgTr9egXQAo8e29kIpyiCL6xlZkVB08OxEANXT38Q71 ovalDWD/ZHZWIwC8CkkGGBf9DKhsEQABoAVfklwANB0y/Mwb50A48PSJRKRW3a7XTkePhZ+8qZWp d9k9NchUD3B5KmZIIoJAGwKhAkAZBECuH6UKAm5qvg8An/iru7i4JE7O8UisObnX18REKq8wfj6J tpoCkxB8CoGLMUnijB8/fuHChUlSKPBaiwZoTAHg0vVulA3GCQBE2XVVYB9DUMwwjh7ICECBN04q WZeBjgZogDxGAHQZUDeIp1KQmkgkiQAAYj1+9iu8mC0L3kS2DSwczsOvqVBG99SMmMPlqZghiQgC yQWATveTdP8r7viWycF4a9hc26OX/EfXGi4AFPrOZ9bqE4KVXn/jFF5+51555ZUHHnig5fkJEcgZ I/Yx29LS0tTUBAmCDMDIHTt2RCMhHTzT3NyMZ+DAeAZi7rTTTrF5pRiBE1NIVu/hhpMiABQXHU7K eV3EeufzCy1pigtQii28JpIqXAAEsH8ANlwAFF4rhSNeOAJ5GpBEAFzZ7ZHqu3PwE0D6IcABfEXS 707ZXTile2oInTIIICMALiBLHA8EEowAQPtUGD+f/ut+7xsXyaE+e+UAdQI/SV46/KSSO/+pmgJz 7zF6B6FO0MUARqaf0OeH7FEyha56eCgBa7dAAXGIzdsRe/vttyFrYP9A+iFZ+IriYeDAgXgGDiAp OIDz+BN81c9ALpAORHavoIQxRQAoffNR5F4/b/ThoeqIGgdQ6itKM1jMiJUZEEFcgBLeFzlfXgY6 GqABwgVA7CpAWVdAGRDPuozlST9YAKy71wAoxcKX3uNuP2+/+zGcBM8fouwdL5mOJ0Et8JigFvA8 pADuQ/QTXEijCgPHPQe56HICCD38BEFn9m1PZ5MfEeQCeek5gmGQI2QEwxfcEg86KJNiGw2BZAJA GQQgAeDuws7X7+fr39Mx+sQTTSe2DQd8Xy3ktfQxCgDuxkN9+bybH6+iM8ryoNw8UgL8EiVTYOGo FuADne7rLv/geThDJB4iwOMLyD2ch1hGJx8QEhDnzDPPBE4PF8IlcIDd/MDmkffDr7xnF77qZyA+ ZGQfl0j9qa47pShZ1OsIQBRHr4PzIgBSv00yTbBwOhrA/gGQcAGQKZouiReOuIuRdRMnWAAAswcQ gMdzoozUH132kWojq0auj5ME4Fc4idcSKUfmDZfDeYgMpBz4PRxDTEUA4OUQxzjBAOtF5+40OgEZ ocCA9DEafYWTIgBE9jghkEwAQEtTlv0BDaDvDGB5yHBWzQl9lAtQlDCALJS+fJ4p/qS4++PQgUUA 8LkHEI3vsUX6AXNR9ACeBJJNzjYoAJCpw3nqoScXIDgPcYjKGxFDNg8fcARCDVB9yLz9NnwFA0A2 QApcAMBX/QxcApmCMTk/+ZVOZSV3EQA1JwlEAOR8ByXMrgx0NEADhAsAGQFI2GJq6/JgAQBc2cKY UQAATcdOenQWQnqtXAgRQCdATPgJST9ICyRhQPQh8PEEEg8UR6FrCD5wegpwOeoKPliBQwEoIVAA wBkcbZAgCMQjkFgAQJPjnj9w7N79D9dyAUBMmrx0qAdd8b3hnf1KX74xd+PlXADwFYFILZA9lsvx PlX0AJ5E/q0cY1c9eubAXy4A0I8fIxifvTgDGHr9KQ4MC0DWIADQ0chxBMBr4kGKbwESJ3qaIgBE AKTY0iQpHYHCBUAA+4dShAuAwhtB4YgXjkCeBmQqAGgSMCf9SLiB2RNHx/EB1AxVWqAt2kMORTh0 gJGNLA1/VQSArlV0e6TvP571ijoiBNIQAF5b/yrPhOARAEwHpAItmmnshm+7E1t/48dE2RUFEvUV L+fr9NOin7j9lr48EbjmBwsAIPpA07kvEA4OkFcP+v/gaAB6/+N0AtQG9jkA8CtclefDOTYvEQAi AGIbiURIgkAZ6GiABggXAGEjALgYKH6SwE3aBQpQ1MKrCe2vrcuDBQD480BJyZEG6SN0zEMgFyCL AADCrU/VReh0JkraAKQCcveo9YWMKbgIAFkpSASABwJpCABoqzQb2Kv7Hy6MmgMQ5QKkLAmq99Yb n1pcGyhbCpiXAV2+ny73OFL0A2WkmErnkaDjVxoNcBwBoCECXhwg+kDcISmcN4zuPfTBcYPYVYDw QhAnpXq8w8saX5Q1GhDMBfMfqjkeH2ywuACV6g6KNaZwARDA/olF57cPQKWlmUKsDFBunjbStvxs 4YjHtol6ihAsAIDlAx0nJx907se+fPClUdbt4RQc3YHIhweuQjGAPj/wEzn3g+M+RKbUyO8fxxCM lN0oAFCrcM2AKeCcBEtqHoxQescbCoGUBECSJ4lxFSDLMqD2VYBiBQBEUGYL8H59xZmH6xMuAMhl CE5GCQBctyfd9XaA39uXFYqtCLAKHpUJE4nNpTEjACduqLDD9js0ZkXXYqnLQEcDNEAeIwBtRL+V +sMuYLAZMAZUAlEyABknbwr4lc6XAfFabKlhNgcLAPLmB9YOTBoCTe1Vpu0qfv+4fBCwedAAQOLR 7x8nE+PEYkgHzqNmwLkBipywrApqFAAkLVBpYMo4vVgEgIicEARKIACwqQON9ho9iNoHIOzpUTWg db/h4MuNFwL7j3LoTzcj99RKaJK78WWOCWy4AUOZa0Rs4wgUTkcD2D/YHy4AXKpfof7A/iF0bGoH QZcBSoIiAFwQzi1OEgFAzJ6shQ5740ZgihMOqAWchosf3EkAeRiOD+AH4uBogM74cVUffRAAL9Qp Hc0exgjQ6085yghACANuqP5+vbClEQC5PSgkI0FAEBAEGg2BwgUAAB6gAcIFQOwcgKqX//Jef079 UQCQDMBhAX1KgC4A2kjb8pGBMiDeOK08oQBAzx/05vfdbyvqKkzQuMpnQqqKCwrJaj8JYZTL24kA aJxHpJRUEBAEGhWBwuloAPsnzZDJHADg9NzVh/N+Okb2HyAAgI8WjnhDNfXkAkDooCDQcAhYBUDw BEG5UBAQBAQBRwQaiqgUVdgy0NEADZB0BADHAYx/SQBEyQAL+6+6Z2hzAGQEoKjGTdUR2aNZm54e NCgRMC7RcFw21SrOH3kc1bEPGeE8cgzp1K8IAEeSItEEAUEgGwQKpA2Nk3XhAiCA/ec0AsCd/tEp CM7Y2b9RAMgk4AJvJ5cRAPTgVz7goA/zd1NjVKnSUFo2FGxOaCHOEMCPsvYo/ZQwi3QoqQOAOMca P3xbtBQN0JEPrgve6iwWUi1Q7ehnjEmBYTDhBCJHbSpng0VcgAp8ZknWgkBjIxDVi9rYqGRS+sIF ALF5LyWQdATAgqXiAkSzfoH+x7J/EQCZNNIEiQYLAMoTZICv93+KjNOYVDDp1FPjAgCKzMlizQkA XHCJPrgKarqhhgQAqYKQPeBEACR45silgoAgkAQBEQBJ0PO6tnAB4MX7FbWQyRwAyANXASIXIDxA p3+j37+CuDIghr/SycIR92oftR7ZVwDgJru0Iy8WX9kOLF1OGZAauIXQZsAJJxMrAgA6zpXlg6D4 NTECgKuv8g8uvZpu0JEPFmOOIwDYiw8BDvi6rlBSGhMA2UbtgcpLNSsCoNYfYmK/INBQCIgAyK26 y0BHAzRAhiMABD2XASQAZCfg3JpmKhn5CgDiT0AouQxQWBT8SswMiKbuZQHxMeCyPBAHCBkICYoJ B/AVTsJPCsOG+HAh/orMT+nMxggYcM0ffga+EiOECPbhC0UAAOZUUuMIAKQGiWNx0HjcGpnz7CRl h3SgsJQ+FTCWxxOfxs3a4IN7LGAA4o5WKTWF2yZQkQOQjxIAsUlxAYC7xSktBC0HgxXLdRcgKgUW BC+hhWghPhYcgKU2yfHE+Cu1MRkBSOXpI4kIAoKAPwIiAPwxC7yicAEQwP6hqOECwBcnkgEuff8u iReOuIuRdRMnWAAgqyYcuE859zWnCKAWOA+m88DjiZLiSSD0uMw//3BhYASfO+jbHVGUKQ20I5iR QxOb5LwZRYUuAIBGK2VBUwEcvvZocNkBQF2QQGouXuyk1njt0IW8Knk18c3djNUKubsjT0LOJSle TcqIEx+7CJgDYMQQTlKz4Y0Z0MD6WglkEQB18wSUgggCtYaACIDcaqwMdDRAA4QLgNh9AIzQR+37 G1BPZUA8wOwavSSJAAASzN3KkeNCRylBgf2mxN441eZwAd/SORlE5rQPORkwbLyQNhLmUoEoml0A wOWQMmfqFm947ihCNiMB1QUApYkjG5zCcs4aVnaeo7L7MiRod+gn3NBZi+zkvltUlboqgMRTQR4F gGNSigAAG8AwspyMTFEAgG00LEB4klZZaRhHBECNPu/EbEGg9hEQAZBbHRZORwPYP4ATLgByQzYq o8IRLxyBPA1IKAA4S0N6xz0rsE+d03HibVRGUgU8KfLn5vwek0LnH3JKgZNcb+g5olXcBkyc93nz 1JRxAM7yuTGQoCIA0KcF4tj7p7nBXmXnyoq60olM28cxaH9lxJ8XhHgtpU9J4VUovVJBnurCpRL1 pgVmUEFIugQIAKxivdmgdxCep2EN1EXqLBcRAHk+pCQvQUAQYAiIAMitOZSBjgZogHABEDYCkGJ9 lAHxFItT8qTSFQBRrFrpO3dk7RCNs0BOzXG9eXTO9hUAxJ6NFNAiACBT6oEGlmycA0AKBB3KdTkU XHbO2mkWgeIob/RiIlVGTv9cDnHxQ9biYA5+JTGGiaeCvEtSxqony6ks6QoArmABBLP/D+AgAqDk zzUxTxCoXwREAORWt4XT0QD2LyMAuTWPms8ooQDgrju43ZKRVdNJ6lh1Ye1GAYDrzBhxJy7ruBil rwBQ7KHLSVEAX9RnLyg9ysECIKrUuhmKDKCufSD0pBzoKj50QJwbfbcwDs1eSBF5l6TsAgAMw2Km LgAoX6hKPOazpduwFQFQ808+KYAgUKsIiADIreYKFwDE5r2UgIwA5NZCajujJAKA/E8AAnIUyVQA 8BzRD576aCHfHAQA7yFWmDdYQj3oOEUBqLNOT1MRACA59BC1nFGUJiH7ieLTAA4UBK8ieZAi8o5J FSUAaJwHKpHPgV5JVokAqO3HnlgvCNQwAiIAcqu8wgWAF+9X1EJW+wBkin7hiGdaurIlHiwAgMYR 34VC6c795Apv9AvSdYJxvUiFBerO6/kLAO6Lj6XAEQC+sg1NIaV5zHypnLCyk/s7XM65Pi4JCkBF CQDjwkS8HXIvIGXVI/opReQdkzIKAAKZlEnqIwB8pgGiZJhgLQKgbA8ysUcQaBgERADkVtVloKMB GiDvEQBcBSiVtYDKgHhuzavwjHwFAPAtCJaNwIjeAe9ESsqZHHU2h5FgxeNISTyfEQDudsIFAC8m yiEuaZILAK6jSFxRFjx93ldNjFlx5Yc4VImWJVz1Xc+gyFiJwbMvHCtRTx+MIZuprpMLAEgTh1MI Nw61wf9H5gAU/tgSAwSBBkZABEBulV84HQ1g/zQOkMcIQBvpb2muLA92GWDcBhgshvNYqYUjnlvb KkNGvgJAtxnIKO975iyNnCjwKr6SepgA4KQQE4e/NBCRmwDgTixQEH2hITiJxDTFEQBlkIGvnQog RG14TIt76hE4mPxX4yKhKSLvmBT53yOG8Jd7WOnKhCSQLgmMgwn6nAounEjH6sKpGk1GAMrw8BIb BIGGREAEQG7VXgY6GqAB8hgB4NQfdgGDzYAxoBKIkgFE9LEK6asIgNzaNM8oWACgmzjvNyX+pM+F hciKH0WYAIAsuAMJJAvMlc4QBcxuEjCVkTvkEAhANPl+YSB4qAOexkOC5wBg1pCXMvwCpY5i/+Qf ZVwklPdzc5qrrBlKRU4ReZekkLXDX8XZDMrCyxs8AqAkW30WLd8XGQ5I45mxFQFQyNNKMhUEBIFW 1qTwKEElIwQKFwAB7B+gCBcALjgq1B/YP4SOTe0g6DJASVBvuHhGBIAL8qnHcREAyqoyjl9xvUgI fBNcx2vt0XC5oSjWm0oWwYlQqYNTcLkQEYAQ5ffvkkhAnBSR900KqjuLtoTJ6kii/ODOUSvBJQIg 9SeRJCgICAJuCIgAcMMphViFCwBi815KIFwAxO4DAOwf+/iR9xP1RwFAMgAjVCOv/LELAPi1DIin 0HBqJInsBEAAv5RLBIFiEUDHKhpV4NOjsxAA744fT+Hzt9+ukWeGmCkICAJFIiACIDf0C6ejXrxf UQuZzAEATs9dfTjvp2OSB14CALVB4Yjn1rbKkJEIgGIZp+ReKgT4LWnbXDmlEYCFBx748plnvnrl lQuamkQAlOF5KDYIAuVHQARAbnVUBjoaoAGSjgDgOIDxLwmAKBlgYf+QpowA5NZ2XTISAVAqAirG FIsArqlqX1Y1ySTgtwcOBK7/9E47YWhp1w7YP9ynD6+66vx118WTEAFP6p83m5sxzscLF0bd3aAo IILxVzgPv8JPy1pa4BhSo2hwho4pmssDxD0OGs8zomvhJyg1oAEB4gBK7slaYurFTCVZSUQQKBYB EQC54V+4AAhg/wBOuACIRZYEAHf6R6cgOGNn/7ECgEyHAkAABdKhQ4dYkyRCMAIiAIplnJJ7TSIQ OgIAXf7I3YHjPt+xI/j/4J0L3f9A+oGd4zgAsGHjHU0sOUohwFWoK4yXI72GnyBf0h54CdcMFC34 qWK8EGyGlKnIFAfPY6ZUwFQ0gFLMdIsjqQkCRSEgAiA35AsXAJwSux+HCwCXOQC8759m/QL9j2X/ ugCQVYBya8rGjGIEQBTRkfOCgCCgIxC3OgfybNAANAigHCCzN3bhw1XAkkE2wF8YLlBuZ+jtRm6t CwA4j/3uUcweByUsDyKcqGCMAFbBT7r/El7C+/ujBACMfoBhFBNGA0AI8ewgcYsBUYZFFceYFJZC H52w5Fvsc1tyb2QERADkVvuFC4DSjQAA9LgKEMkAPKA5wbrfP6+tNsa5/D/6SVYByq1NG6pDyJwg IAgkR8BNAMTe6UY6DrQYiDJQVWD/nDET6YeTSOVpBIAiwxm8XB8BwN53DEimuU6Anngk6BDggDrm UbcAWcdf+U+YEQWwFol1lADgWevI0PgAyh7i6DiCgXIIpRGMrtDlcIwDLHygg6zlSYG6gMhkLRQK xQxkZCx4bN1JBEEgawREAGSNMKVfuAAASwI0QIYjAAQNlwEkAOzs36XayoC4i531EUdGACI3dUpO ByWFRkMgSwEA9Bddg5Bhozc/EWtgscB3kRCTAKBpBvATetfoAgAZNiQOB+ieRNHgK5BguBB4P85e gK8YB9110F+fUoDzQLKRi8N5yBRNBassAoD4NyQI8bnzDxxjapAU0nca+kAjyVQ8RtuAwcMxGkAC AEUClgUNRijQQjgDkfE8WgsZoapBCcTVRX08+aUUtYuACIDc6q5wOhrA/kkzZLIKkAI9yQDjop8B 9VQ44gE21+4lIgBEAAgCqSGQmQCADmnisnhMVBh5OTnh4PgA8WAaTEAGbJwDQOfxOaaQY2LkyKdR eCDhJvcbPuwA5nGPIEotagQAIuPlFGg8AYrGnZ1QD6A9GJkMQOGBDlQoFeCACwAk+lQW+IozLojx Y9kxGp6HrC2TrWv3mS+W1zoCIgByq8Ey0NEADZDHCACvg6h9fwPqqQyIB5hdo5eIAEiN/DVab7eU N3QOQOyzQncBIv8fvBa7842e/cTF9SmwvgJAn06g9LhTQRQBAJ3oqEMwYHGiBAAmAlQbvf/xQmTw XBXQMbJ8LoHgK1B2Gh9A/x9FAOhloQh6LgAdjUuAPXy6dmzdSQRBIGsERABkjTClXzgdDWD/YHy4 AMgN2aiMCke8cATyNEAEgAgAQSA1BDIbAeB8mggr0lyl/75YAcC9hnAcwFEA8IceFhYFDEgdnIlL QfFTogvR/Qmvwp5+LoEsAgD5PQ9gOa7LxIcmfGcb5/kYl7waCgERALlVdxnoaIAGCBcAsasAZQ19 GRDPuozlSV8EQGrkT3rEBYFsBAD6/PANBJCYYjc5ugDRI0VxASLn9WAXICK+ugsQZUr0Wunm55ka RwCAqeMGCLoAgFLrLkAwSqDoCroQzUPffTypuwDRHGIg/UYXIDASxQNYTv4/aLll6dXyPM/FkkZA QARAbrVcOB0NYP8yApBb86j5jEQAiAAQBFJDIBsBoPj/4EMHvYBoSit2Y5PjCsahScA4hTfKBQgY M7rde00ChtR0AYC++JAvGAMJ8nm6RgEAbB4VC25/hpsik500pThqErDy/MWkSPMYJwHTZF9UHThu oEwCxjkAiAmhyvdNq/nnvhSglhEQAZBb7RUuAIjNeykBGQHIrYXUdkYiAFIjf9L/LQhkIwD0PnJ4 6NCSNXwSLdBZxR2ffIeImitd4/CVFu4k93rqkjcunUnSQhcA9BMRaDAAJ/JGzQHAXRG4Iz6UgqYR 80VFlWVA9ZkSmAUxdcsyoCAzMAtlCjKkied5wSFNWnOpth/3Yn1dICACILdqLFwAePF+RS3ksQpQ 6jVROOKpl6jMCYoAEAEgCKSGQDYCwOUBAs4t+j5WeCHw4NjVbHAnrKiM0D/exQyMg7uS6buDWVKg 3b70q/CnqNK5W4V035gUFl9HCQvuVRAveySyIBCAgAiAANDCLikDHQ3QAHmPAOAqQKmsBVQGxMPa Si1eJQIgNfIn/d+CQHECoBYfPmKzICAIBCAgAiAAtLBLCqejAewfShouAHxhaiP9Lc2V5cEuA6J2 AqZ8C0fcF4Gaji8CQARAAAI13ebDjN9h+x3igRIBEAauXCUICALOCIgAcIYqacQy0NEADRAuANxX AeLUH3YBg82AMaASiJIB0HZ5nShfSbtAASCAMR06dEhah3J9NAI1JACgMcgnUwSgmcRz3NZufoi5 YP5DjRMuvfjSPAWAcf17OSkICAJ1gEByPiICIDmGjikULgAC2H/mIwAK9Qf2D6FjUzsIugxQgNYZ P53BZl044o4toz6i1ZYAADUon4wQaOszcHPjQQGgjObV8decBYA+vbU+njZSCkFAEEiOgAiA5Bg6 plAGOhqgATIcAQD2j338yPuJ+qMAIBmAEaqRV/5ECQA6XwbEHRtHHUSrOQFQB5iXswgiACwCJi0B AOvbxM7HheYhAqCc94hYJQiUAQERALnVQuF0NID9ZzsCAJyeu/pw3k/HJA9EAOTWUsMyEgEQhlv9 XSUCIAcBAEvZALmPDbLkfP3dX1IiQSAtBEQApIVkbDqFCwBi815KIOkIAM4EMP4lARAlAyzsH9KU EYDYNpdnBBEAeaJd5rxEAOQgAMrcAMQ2QUAQqAkERADkVk2FCwAv3q+ohUz2ASABwJ3+0SkIztjZ vwiA3BquY0YiAByBqvtomQoABT2i2ng+lckDLkm5xDEak5YLUN23IimgICAIZI2ACICsEab0CxcA Cqd31ANJRwAs+CouQDTrF+h/LPvXBQCfAYyZlgHx3JpX4RmJACi8CkpiQHYCQKHd/GswI9dpum9S XvFFAJSklYoZgoAgIAIgtzZQOB11ZPxGnZDJCADkhKsAkQsQHtCcYN3vn9eW8ubWfyoc8dzaVhky EgFQhloogw0ZCQAjz6aTXizcPlDgm5RXfBEAZWiiYoMgIAgAAiIAcmsGZaCjARogwxEAgp7LABIA dvbvUm1lQNzFzvqIIwKgPuoxeSnyFACKCxAZzym+UqLYnzihjyL3ivBw1wAiAJI3MElBEBAEUkFA BEAqMLokUjgdDWD/UK5wAeACCo9DMsC46KdvamQ6FACCbAQWAKDXJS4CoI0nLV8hvtoDwY5XsLcE EVz2n5LG4FWzvpGLFQDcFVA5dvxJIffG4QIXkZDDHICV90L0rahyxdfLkmLpICklBBQ+RXsCcq/v S1KpoCiI3CvOGFO3zT1Bo0l0ecJ0kjcJEQDJMXRMoXABwCmx+3G4AHDfCViXAY6Y2qOVAfFUClIT ifgKAIXu8zIiiQ+LIAKg8NZSoADg7zP92C4AjIMJUc5CIgBcmpkvv+Hxfa+125OpunCBQuIUWEHu bSlKAGRUfe6GZWZA9QmXUeKSLEegcDpa9hGA1JtL4YinXqIyJ+giAIjWK/y+jU4x3p8kQqwGkBGA TBtSCQWAUl6jNhABkHqr8KUWIgBSr4JaSTBThebeDkUA1EqDqTk7y0BHAzRA3iMAKdZrGRBPsTgl TypAACDL56pAUQhhEUQAFNtU8hQA1BMf1SXPzxuXDbCsAuR4rSWanni6cwAUXwL0VeAf8l6wn8Sr lL+xSfH4eDk3QM/aaIymzVZY4mLzcvDb4iomUQoWfhmlOoz28+yC0daxKvaGLUPusRXEm7qCPFW6 scVSw6a6i6o4Jaal8Sg/6c3esem6K5OM6khcgDICVk+2cDoawP6hFOECIDdkozIqHPHCEcjTAC8B 0PYsZn4+1Yfvyp4/eGalJ6lbBBEAedZ71JMuthaouhfMf8i+LI/SN2/8uvztvmJE29cFiFKISkqf PWwfSchzDoBCQRRazJmNke9GMRhFYOhsOzaCkUVZeI+RwUfZrCeuczuF9llovQtKPDUdDaM9jieL vWcLz53qJUo32pu03g4VweByR7g3nqjELWYYW5cIgMIbXm4GlIGOBmiAcAEQNgcgxfooA+IpFqfk STkKAKNvD7F/3ft/xetz+czg2BRIXURxUHEByrQtZTQCYOysihUDuoerzuMZRVP1gzJtwEWK2MVM piMAFkpqJ+KWXnAX5qQ0J7sq4EzI2A4tncHuHD3KJEc6bmRmAWrHnk6mt2FtJR47AqAXJ2F1xLZS 4y1jaVdRN5GlyYkAqK1WmsTawuloAPuH8oYLgCRgpXJt4YinUopaScRXACjr/3CyrjB4ndDbI4gA KLbNZCoAHMcKShutjgUA78Q1ygY9QmkFACoNpUs4lnEaC6inY0y82Hu28NzdBUBsM7NLVsfLOSAW mh6rnHld28cHCqkCcQHKDfYy0NEADRAuAMJGAHAxUPwkrJsyIJ6wCDV0ubsAcHQOyS6ajABk2q5E AFjkR70KACMTiu0TLbMAcOy4NaoCx3IhO5SPEYfYHvpYPWapwSh+7ztiEysA7PdF4bUvAiC3u69w OhrA/gGccAHgi2wb6W9priwPATKAv3oLR9wXgZqOLwKgpqsvReNFAJRQAHixJXtXZWxS7tTNkSi7 q4soRuXYwRxbNHvvsp1xxsKS4j1Yc0kFVJBjZXF14d6Q0hoB4EbKCEDNNcsUDS4DHQ3QAOECwH0E gFN/2AUMNgPGgErASwZwl98yIJ5iAyp5UiIASl5BuZknAqAkAgCpDwaF0CgndWLkexXlpfAtJWU9 Wb1ZRvXCWkyK7YYnHOyA2K2NZfCOaEfVS253aAkzslSQsfXG0noOcmwj5LkbG2SUeUZFwW2Lui90 JVlIpcgIQG6wF05HA9g/gBMuAFyQVag/sH8IHZvaQdBlgOnOXPGqXX5HrXjXFY64CwJ1E0cEQN1U ZcKCiADITQAkrCnj5VGd6FnkJWkKAoJAgQiIAMgN/DLQ0QANEC4AYkcAql7+rX38yPuJ+qMAIBmA EfQpAcr6HvhVRgBya9BKRrUlAKBZS8gOgeqdyFZtshxDTPdlQEs7tdfdsBTnAOi9knKmRhEo6qFd knxrtNbSMrvAWhABkBv4hQuAAPaf7QgAcHru6sN5Px2TPHAXAPQyLhzx3NpWGTKqIQFQBrjq3gZ3 AQCcuKHCDtvvEA9O6+1USCMpKNtCyiqZCgINjYAIgNyqvwx0NEADJB0BwHEA418SAFEywML+sbNf +cgIQG6tWc+ohgRAPP1y672WdJIjAGy4AUM8bsUJgAKfIZK1ICAI5ImACIDc0C5cAASw/5xGALjT PzoFwRk7+1e4PtWiuADl1qCVjEQAxLM60RWCgCMCIgCKepBJvoJAwyAgAiC3qi5cABCb91ICSUcA LPgqLkA06xfofyz71wWAzAHIrSkbMxIBIAJAEEgNAREAxT7OJHdBoAEQEAGQWyUXLgC8eL+iFtop 8wXxZ3DsSeioiqsAkQsQHtCc4Ni9wLgLEFYkP1M44rm1rTJkJAIgNfLn2Eks0eoYATcBYF/dUn8s 2JfLDPD+1y9xOcMGbM2PLqVcsfEtJY261rjyo4vxGCcAqzI8pctpgzvsEX1PMcVySd8LmbqpfREA XvWeJHIZ6GiABshwBIDQ5DKABEAs+4+tjDIgHmtk3UQQASACQBBIDQFnAaA8QBypiTGa47U8R32N dp0cW5J1NCOAwCG/jzI16if34gRgVTeP+tQL4g57gQKgLmtcBEDqjTkqwcLpaAD7h7KECwBfZEkG GBf99E2NTMexCxis6NChQ0AicokjAiIAUiN/ddyxLUVzRKBGBIBC9/XecTttylQAGG2L6rw3jo1Y ilOXdNDxUZ9FNI5nKq3IIlOj2oC9XHVZ4yIAsmjMxjQLFwCcErsfhwuA2H0AjDB57ftrr7wyIJ5b 8yo8IxEAIgAEgdQQSCwAdEbFeY/yq92tBXvTowiQO3XT06F8jdbqzzQeXy+CoyV21ZEkkcIfwrVr gCPs2IaV1mhsRe4CwNi8lZP6V0w/KmuysOSyQQRAbrdM4XS07CMAqddE4YinXqIyJygCIDXy59hJ LNHqGAFnAUDUxMiKOE0xCgAiKFEUP5aaO1K3KEHCDaDnW5TkiIrML3QvspEjBhSnzI/lWrEtAHZj 041Sd8ptYm9IUW3V2Mz0pGLvqfJUigiA3OqiDHQ0QAPkPQKQYn2UAfEUi1PypEQAiAAQBFJDwFkA KI8FR2YTy6SNT5uo7kzqB1UYUpR4cM89StW4p2zhZ1GdxL7FKfmTuVbM84XdqxWF3Sb2FsIVtVFd KxFKWBEiAHKrlMLpaAD7B3DCBUBuyEZlVDjihSOQpwEiAFIjf3XcsS1Fc0SgTAKA955ahEFsJ66e TuzwQmx3PnIsl5SNfFHv0yXSFlucPJ+ujZCXowBwqesoum/swo9qA1HiM5brO7bqMtSpCIDcaqEM dDRAA4QLgLA5ACnWRxkQT7E4JU9KBIAIAEEgNQRKIwBc2IwjddOfYLG+Fo4CwCVlEQClf4NUDQzQ XbFNVB+5Chg9iG2r7mmWpyJEAORWF4XT0QD2LyMAuTWPms9IBEBq5M+xk1ii1TEC5RMASoeoeyer QuK9OlB9BUAUy7f05iqkU7c26kzNP7LLVwALU/dtRbxwvgIgIdfnjVDPulSoiwDIrToKFwDE5r2U QN4jALgKUCprAZUB8dyaV+EZiQAQASAIpIaAswAwOsAQW6Jfo5g00l8lmk7u9T5+XwHAM6Jro7KO KlQUtdLtd6GSllK7XF74I7f+DIiF3asV8WZmaa7GZmBsUbq8jBp8IMEpAqD+WmlYiQqno168X1EL We0EzKFsI/0tzZXlwS4D+Ka/RiFbOOJhDaVGrxIBkBr5q+OObSmaIwJuAqBGnxVitiDQIAiIAGiQ io4tZhnoaIAGyGMEgFN/2AUMNgPGgEogSgbAK9IOehkQj20WdRNBBIAIAEEgNQQcBIDSTS5f80eg bp7exRYk/4rLOcdi4bXkLi5AuVVN4XQ0gP3TOEBWIwAK9Qf2D6FjUzsIugzQRvHMAgCFAfwtHPHc 2lYZMhIBkBr5c+wklmh1jICDACjDXS82CAKCgI6A3aeuPIiJAMitLspARwM0QIYjAMD+sY8feT9R fxQAJAMwQjXyyp+oEQBq02VAPLfmVXhGIgBEAAgCqSEgAqDwJ5oYIAjUOwIiAHKr4cLpaAD7z3YE ADg9d/XhvJ+OSR4YBYAyDQDrkoRB4Yjn1rbKkJGHANjyznYYmrq22/KOdlt1rwY8s3X3dlvfrYSv NTV/d5PrIMDBV7bqttrGV6+33hnrrNfp+5ve8N1Nb/z9T/+1/4//usn6Z2yw4TlwcOK3tz3t+3/c Zt3jvrnF7a1ZNEsQBGoPAREAZXioiQ2CQF0jIAIgt+otAx0N0ABJRwBwNwDjXxIAUTLAwv450Y8a GSgD4rk1r8IzchMAXatcv0rxe7ex/K26f2PrXhDwKxD6tX59/q9+ftKGax8PAcg9UPmdf/Hv07+1 FYRd1z4Cvl7y7U0mtG8/+ivfAqJ/8g86jPvWanNXX2PMD9bp/62fwsHjG2307M/W6Pb99UEkVNMU AVD7CDQdNmSnY0dDgAOq0FW376GfxF8pPkRYd59+vA3AV7wKA/+Vn4djPSklAl5LZsCvcJxaexMB UPgTTQwQBOodAREAudVw4XQ0gP3nNALAnf7RKQjO2Nm/CIDcGq5jRk4CYMs7v7NFF6DmwOw3WvcU 6MJf8zeXQbc9BOi/3/rXJwOnv/mrP+31tR8M/MZqo1f54YxVf3TvN1edsNqPnvntJhCmfucH8PWZ X62z7JjDl+y764yv/78Z7b/69lFHfHTD1a/+5DuPf6U9HFcemP7R2SeCKvjzqge127Z3aoSsNmk0 0tM0iWkROIx/4GVqhETN4QBPwq9KLS98+V2K3zxkAf/1zJse4O2ZfgXNoPYjtJaUZ61EgKQgApkB v5JtKbQ6ZwFgWQbU8c51iRa34IJLGn5xUskxuSu2vvKjvRgp5uiHl8QWBPwREAHgj1ngFYULAGLz Xkog6QiABS3FBYhm/QL9j2X/IgACm2FmlzkIgK7glnPU6rtBV/3or3//7m+sAf33V/5om7nfWuWB /1ul67fXg/PQef/GX/cGBv/+eWcCra/cNxK4/kvr/vTdS84HZv/aLtsBy19y7L+/fOO1ZdOmPLHe Oo9+59vvTRj/0dNPP7jW2iAGXr3iCijfsm7NoBN2/M4+rQKgawpsrAjWm9zsjpdNo9pOnlqBKXAW 3rLgTbQkSgAoVB7EgEUA0K+KMKg+XtwEAIgrAjlNoeUmACzrpnsRaHtk/NUrwbDHTLpZRK3R7mWb y8r0K+4ytixFcFmCL/Qql0QWBJBExa6mKEClgkDhAsCL9ytqIdtVgMgFCA9oTrDu989rQpkAQO1Y 5gCk0l59E4kVAODBD73+0De/7G97fXztpS/vtiNQ9vk/+tGHV10CYcE3vw7k/o0jDv3yyccrH7wP FP+Lt98GG9689RaI80qnc+D4jRtvnNO+/SsXXQTH8OtTe+/12Abrf9gy5/377oNRgn7tvr7wwL9+ +e47HzTfAgJg++/t3+AC4O13PwagBo5fiH3VtRuUbnil610ZAdCpPHccivoVUFIavC4AICMeQF9h nExUltuLWQRA1GPKi7hbnnXu6bjHtD9aRQD4vnokfjACIgCCofO9sHABoHB6Rz2Q4QgAIYiLgfIR AOOyP7WIuK/NtRs/VgBA9/+hP9p7wWrf+XxQ3y8/+QS68IG+A+l/d+iQZXPmPLbGGkDunz/mmOpP c+YAlX9y098u2Habll9tADrhqT/+ARj/shkzHv7hD16/9lpECZTA07vt9unM+9+4+ZZB3/sh+A6B m9AXL74AIwAgM4wC4Myb9l/48g+h46Nlwc8PPLMjEriOlx02/oEN4S+nyMrJVbfv3DzkT2+/+y24 duD4pqbDOmHkK3vsCtfiV/gLx3BGp9pwHgKd51/xmAdMTTkJloMNZC3/1ZgjEVPFLwX946PEQJgT iz3NqLygv5xTc4s+UQQACBt05cdmoAgAGCKAkxAH9Q98ruzxMCVOAoDchFBOYEzuO6QLgCgL8Spl qCGp3AoVAFgQ3RHFeIbHtPDOqBEAo7uL40lKk/vY4LVUBH7Af+JlxCLoH/fiWAzmiXODfXOMqhEl fR1no22G0sopQSAIAREAQbCFXFS4AHBk/FA2PWZWIwAcSJIBqbB/XgwoD8xC7tChQ0i9yTVuCLgI APD1B7d+EADVJL/4Ahg8EHqg7x8+9BBM3gUBAIT+83ffBaIPB0D6IUD8Ue3aTV/rF8vG3/v5e++B MHjzjq6gED594YX3xo559ZprPn9o7uvnn9fz2z+BycHgEfTlomc+69ejTQD8rj/nYUCUgS0AiQf2 DAcQUAMAt4Zj+Luyr8hKJ0EwQBwQD3gAiay7z2VI0+HrTseeBMf4E2kDnhpmR2f4VzzmAVPDM0j0 UXiAAiFreXwuLVgWK6oNKfKBZ44nTgwH1IGNTBr7tquMRBsrQEoNfeT4E/jNw1d0d7GnSalhyki1 kYIDKQcbdPd9I28mAUAHYAxoACwhT4ROgpFoJ3w4NScBQL/C5aQl6KRiOaYD11LgSgmtciyLqzBw EwBVO1tJs7372egMY2Tb+r0e5UgTlSaloFN5tBY/Fq5PEVxiGsvOMzKWKNY2l6yVlGMlh2O57Lbp xZEzgkAwAiIAgqHzvbBwAQAGB2iAPEYAOJRR+/76ws1LKwIgAD3fS2IFALgAwRo+QM3BuR/66b9Y 9iGQ+Of+feRrnTu/P3Uq9PeDAIAu/89efx1+Aor/0eOPf3bfmId33uvmr/4AJgyA6z+YBKQfnP7B IwjcgeDyT15+BRr1C389ALr/YXgBxgreu/XGt8+qOhopIwDA15E0I0FH0g+U3UUAwGgAsn/sg4cR APiK/e4kAIwqwsj4idzjr4o2MF5CxkdZq9NK4spA34FtAzNG9g8Ullg7HMCFSH+p81tPCkkzXI4/ EXGPTbPKw5gnPRcAmJ0jaaaycAceMB6bKE+EIoC84VMgaKiBR6AWDvggAjx9brl+L3CvqmIFANmm UOEoPurLL10EALfBSLj1CMn1g3umikmxJbLbFgus/ckZi78xgu/TWOILAi4IiABwQSmVOIULgAD2 Tyw6jxGAVFDmiRSOeOolKnOCjgIAnPU/7HzVskmToCMf6DsQfWD/8BWoPyzuOX+rbeAkCADwCwJh AFT+wd9sdvFXfnldu5/C4j/gBQQOQhChOj6w/fZV9g+fWVPn/XazM7+yIQwvwHziN848DQLMCf7n Kh1aZwC3TQJGEo+MHwLIAKDs2OsfOwIAXe/E+Fu7vTvCJegyhAIAU4B++qj+XWT5mCNGpgEB5Scc WFCEAQoATB8vh3wxKcVziRuArQX7qpHaUl84dnUjdea+NEYXIOpWB86NkRUqj5ka04wSAJAI0G5f FyDIncQAKRYuAOhXMJUUAhlMOCAsOLJBH7A/TADgVSlPtHAeAYhitwpPpYGCWALKE+RXKUMN7m4w SiKYfnkEgCMysbzcMgKA5bUAaNEkUUMcZX4XiG21goAIgNxqqgx0NEAD5D0CkGJ9lAHxFItT8qQc BQAs7gkjADABABg8uAAB14dyffbEggW77gKzeIHuf/rsQujaB+cfGBAAlx6YMwBr/IMAgDVAQRVU I7/+OqgF8B2Cub9VTEYNnPiLDQ9cZWdYXwhmEsOgwcf3T321aWOQBP+32a20FxjxZlMPd4wLELF8 U0d7VQCgiw6EKDrOPXbomBN9Oon+PyQAuAsQjjmQfsBLjP4/y1NYIQCUXmpiulwAWOg4zpEFioyd 5bgEvkuaUQKAxhOiJBM/T7QeV+4nRya8I0gA8AV5lJuF1g6igkNSWBb6wIiBXQBEbSBQoADQSWcs v4+NoAgABUk7D/ZSBZSy3SR3qRBgeazBum3uIwAB5VKkkQ5Ryd8CYl5tISACILf6KpyOBrB/ACdc AOSGbFRGhSNeOAJ5GhArAICLwyZfsMA/LPEJjvsgAGB5n6WDBsFkAPAIgiV9QADAlN+P5z8KZ97s 2RPkAfyF4YL52+3Y5avfgwtfPuo/OBUYZg+DPICe/s8XPVe58DRQCLCxAGwTBi5AsKAQCAwYLoAt gcHpyCIAqK89dgQAfX5okgA4AqEvEI0AwK84SgBuQkZGi2QdyD0GfQSAfqKUid/jrGUi+mgtZIeX GKcchAkACxdHdxpg3tDvTmQ6iQCwOP/wvbq4fgAD+GgGtW1Kivv86C0fRQsXAHyIAOKDfrALgCh8 0GBlxzEXYWOL4zYC4CsAeHdyVK9zLOnEC915eVRMO7d2ZM+WDnJLt7qxjO45Rj1XY3N0wd9LoeX5 hJe86g8BEQC51WkZ6GiABggXALj7b4GfMiBeYPFzztpLAFTef/f5jscAiX9u152qJP79d2EyALgA wVpA4OUPa4BW3nkbpvNCqEwcs2ivPWEaAMzxhV0CYCbA2/vsBn5E3b++KswPhi0CYAsw2Pd3tY2v /ulGV173nU0gTZABcADbihH7B6YFRBkpNTJsZOHcqcYyCZhPGKA+eFAFJACwbx6ZunEQgDN+6t3n Pf06F6RLaAIAWm6fbMDTwQbg7gJk4aNAjqnfnXxdXNyKME10tuGOQxYBYGHh5KHEvXcoKVrKE515 IPBJvTx3goXuEVQ17i5AVBwcCcGQlPTz6dduAgCJuO5eQuc501WIu8JWLVpCeZJwhqrzbzKGX6Wf JGOizIjlwZR1VJc8B0cxxm6bgipGVkpt0QBGTaJbq5htqURLAXN+yEt2dYaACIDcKrRwOhrA/gGc cAGQG7JRGRWOeOEI5GlAvABo6go0HXb5hX0AwHH/pX8cBl3+E772/97/339g3Z7F++4Ox7Aj2At/ 2PqNv+0H24G9uFMHcAQCZx5w6Af3no02PBtoPYwD3PmNtcHdf5P1z4C/p39rK9hNDLj+17a8C+j+ ehtftPPqf4fRABADX9mqGxcARNZhGgAtBsqdaoC+09qaCs8G5k0LgMIleIwrCPFVgJCaGwcBYgWA vgwov4QPQVAudInLMqDuE3ajWCyRaerqtqRJu3HBVcDLaf4xkeyEAoDv9oVJGTfk4icxGh8BQO6O 9wguFRomAFaQ7BQ3W3AWAHne4ynmlSKpTTGpFAsoSQkC5UdABEBudVQGOhqgAcIFQNgIAK4ClMpa QGVAPLfmVXhG8QJgyzthKwDg6+DW/96m68LKnkDrgcHDij3QtQ9uPPAVOP3FX98Q+vvB6R/m/p7Q fhNw5YflfYDQw65ea/7msg3XPn6d9TpBOvAVPHy+u+mN1eOt765yfQhb965u/oVh6+4KlwUeTwuA Ar0m3qx41Vc7+7SOdhhAwA5+HDegbn4uAEgn0A4DZECsAOCTBPgyoJgCjlegtNCtjZoGgE2Ces0d l+yMEgDoMEP+PxgtKk3OrXEZIrg2xREASJ88+JHZGxcFosEHhII7+SjeRLggUm0JAKXvX77WPQKF P+TFgDpDQARAbhVaOB0NYP8ATrgA8EW2jfS3NFeWB7sMiNoJmPItHHFfBGo6voMAuAN65aGTHkg/ rtr5481vgAB99od/60/Qbf+dLbpAR/6P178cKD6EH29wOYwYfHeT66pzebfqXg1A62FpfwjI+OFv G9e/u4224kmICQcR3bHgUQN8mlztvdw2QAbQJF2vC8sTGWeyBtiDDNu41k1UmtBP77jOT4A9dX6J jADEPQ2NvkZxF8nvgoAgsAIBEQC5tYYy0NEADRAuANxHADj1h13AaEtgVAJRMgDarr3yyoB4bs2r 8IziBUCVkXcFav79TW+AHv02Wt9K5au9+FXuvpzlr+jFv7uN0Let5onLerat7FnnFDBFf5JkSVG/ OHjy4P5fEjJHoN4FQOHPKzFAEBAERADk1gYKp6MB7D/zEQCF+gP7h9CxqR0EXQYoVWUUAHgSm3Xh iOfWtsqQkZsAaNUA2HNPnfRwYO2zT4tscTebOjtOCyJjOrC6DrjZgDe/dOdnivNKiYsAKMNDTWwQ BOoaAREAuVVvGehogAbIcAQA2D/28SPvJ+qPAoBkAEaoRl75EyUA6HwZEM+teRWekbMAaNUAOBqw oi9ZOvWlW10QYAiIACj8iSYGCAL1joAIgNxquHA6GsD+sx0BAE6P3fwoAzjvp2OSB0YBoEwDwL5/ qtHCEc+tbZUhIx8BIFRPEBAErAiIACjDQ01sEATqGgERALlVbxnoaIAGSDoCgDMBjH9JAETJAAv7 V7g+1aIIgNwatD4gU32aiIO4ICAIJEdABEBRDzLJVxBoGAREAORW1YULgAD2n9MIAHf6p9EAO/sX AZBbw3XMSEYARPwIAqkhIALA8bkj0QQBQSAUAREAoch5X1e4ACA276UEko4AWHBSXIBo1i84A8Wy fxEA3g0w4wtEAKRG/pL3H0sKtY6ACICMn1eSvCAgCIgAyK0NFC4AvHi/ohaqK+rwgD+DY49xJq47 prgKELkA4QHNCdb9/nnKllWAMFrhiLvjUAcxRQCIABAEUkNABEAdPBOlCIJAuREQAZBb/ZSBjgZo gAxHAAh6LgNIANjZv0u1lQFxFzvrI44IgNTIX633Xov9yREQAVAfj0UphSBQYgREAORWOYXT0QD2 T93oWY0AcPRJBhgX/Qyop8IRD7C5di8RASACQBBIDQERALX7KBTLBYEaQUAEQG4VVQY6GqAB8hgB 0GVAKrVSBsRTKUhNJCICIDXyl7z/WFKodQREANTEU0+MFARqGQERALnVXuF0NID95zoCkHpNFI54 6iUqc4IiAEQACAKpISACoMwPO7FNEKgLBEQA5FaNZaCjARog7xGAFOujDIinWJySJyUCIDXyV+u9 12J/cgREAJT8eSfmCQK1j4AIgNzqsHA6GsD+ZQQgt+ZR8xmJABABIAikhoAIgJp/IkoBBIGyIyAC ILcaKlwAEJv3UgIyApBbC6ntjEQApEb+kvcfSwq1joAIgNp+HIr1gkANICACILdKKlwAePF+RS3k sQpQ6jVROOKpl6jMCeKj5NWXxkgQBOoYAXlllvkpJLYJAoKAOwLyNHPHKmHMMtDRAA2Q9wgALgaK nzpAPGERauhyEQB1zHqlaISAvDJr6KEkpgoCgoAFAXma5dY8ChcAAeyfxgHyGAFoI/0tzZXlIVYG tLmdLP9PqcvCEc+tbZUhIxEAwpIbAQF5ZZbhaSM2CAKCQHIE5GmWHEPHFMpARwM0QB4jAJz6wy5g sBkwBlQCUTJAb7twhldGGRB3bBx1EE0EQCPQXymjvDLr4GElRRAEBAFAQJ5muTWDwuloAPvPfARA of7A/iF0bGoHQZcBSlXZBQD8WjjiubWtMmQkAkDIcSMgIK/MMjxtxAZBQBBIjoA8zZJj6JhCGeho gAbIcASg6uXf2sePvJ+oPwoAkgEYQZ8SYG+7IgAc22Va0UQANAL9lTLKKzOtJ4ak05gIXNiQH0td f/nZlxA+Wv7Br/m0DXma5YMzdaUDn4YAd0CHDh0yug+iShTA/rMdAQBOz119OO+nY5IHdgFAkwGw 8Pi1DJIrt+ZVeEYiAIQcNwIC8sos/FEjBtQ0Ash+GuqDVET/IO9/+623Ibz66muLX1oMf6tf3/0Y zucgA+RpltutpNNRFAOpB0uJAjRA0hEAuNvBIONfEgBRMsDC/onlU2l5UxYBkFuzVvBvBAooZWxk BLxemR8vXPjqFVdAWNbSkv8tKTkKAiVEAAVACQ3LziRdALRR/3c/XvjcwmkPPzd66vyuw2d27jsR wn333gcnUQlkLQO8nmbZ4dMIKRcuAALYf04jANzpH52C4Iyd/YsAKNs9IyMAjUyLG6fs7q9MpP4Y Fh1++JvNzZ+//XbZbluxRxDIGQERAMj+geIT9b+s273HXtv/r6ffjAGOUQZkrQHcn2Y5N5L6y64M DikBGiDpCIClIhUXIJr1C/Q/lv1bBAC16TIgXn/tOKpEIgAahwQ3ckkdX5lA+t8dPx4ZP44DPL3T TvBXv31ePuMM+IkHiOYiFfBCxyeMS4JKUqBYIP2osQv49bHf/KalfXsIEA2+OlqSMBrkBQVPmIhc XiACIgCQ/UOvPwSg/sD4N/jLFd/f/lQIcIDH2x91PtcAGdWX49Mso9wbKtnC6WgA+892BABSx1WA yAUID2hOcOxeYOT6z+cAiAAo5L4SAdDItLhxyu7yygTGD13+eBsC80YxABQZTup8GhgtcGgg06gB kFXD3y/eecd+I+OFLjc7RDNqD/u1cAlcCJbr0fAnMBLHN9DmgCxcjFfioN4IuFAuKQkCDS4AoPsf +vXR5wd6+oHut9voQB5QCcAZ0AAPzH6gOg7w7scZzQdweZqVpNnUuhmFCwBi815KIMMRAKpRLgNI AMSy/9gGUQbEY42smwgiABqHBDdySV1emdBFzdkw6AGgyPhX7ylHHs95Np7hMUFFQARFPOgCALKA aDplN7JzSI3GKPhTCPOCMxYBgB3/NKqAguftgQN5Ovb0jVnj5byYWCI+fEECANPXn59R+Uadr5sn cK0UpMEFAHT/z3ziOfD1N7J/VAIoACBcf/PNoAFguACuyqJ+XZ5mWeTbgGkWTke9eL+iFvLbCRgF QHL2zwtA6y41YLPLrcgiABqZFjdO2V1emUDNkRATlwU2D8fYX67ckroAQOZNMfErOdsQG+YCAE7i VwqoH4Ai85PEsMl7R1EacBXFhyJEjQBgHCP/RgYflT5II24POfOgnYAYjoSgnTwyySEUAGibMlQS la9yXjyIcnspGDNqZAGA3f/Y9w8d/P37939z6ZPjZw2Fv/AVAh7DXzgGAfDHnfciR6AsBgFcnmbF tpa6yb1wAaBwekc9kMcIAK/jqH1/A9pBGRAPMLtGLxEB0DgkuJFL6vLKBIqJnf3cEQjuaxcBgAMF yIbhEmTkKAaQJVOaXABwsg58F5kxXIJ980iaSVHATzgiAbIBSTYcQ2RwOsILIWtSAkaWz/k3pKD0 /Uelz8sCeWExMWssGpYICTpGhozgJzyPMZH343k0g7RBVL50HqsAUsOk5FMIAiIAcL4v/AWuD539 cAwH8HfmoonQ5Y8d/6ABUACASIBBAJwNnHp9uTzNUs+0MRMsnI46Mn6jTshjBCD1ZlE44qmXqMwJ igBoZFrcOGV3eWUCIUYiq6z8A+xT4cpwRys990Rw8WbHWQF04yNfx+kBXAAAo+WeM/wn5NbE/qmv HdMEDUCcG82mmJiXUQCQSuHd+WiAJX1yLsKsuYsRjVQQy+FFgJRpOjLmiCnwolnyxUugLoT3l+EN 0sgCAKf/AteHDn5i+UD0cQQA/6L3/0cfLYWDb3z/1+gFBFsEiAAoQ+sNtqEMdDRAA+Q9AhCMr35h GRBPsTglT0oEQOOQ4EYuqYsAIHaOjB+IL04FNjqfINOFzmwcH8COcLrZOcOmYyTlyhwA7Nvm8XWW TLRbSRZzVJz+LXMAMGV0auKZ2tOHXwENKCl3EMKyKIMbcEbBgQNC+HABwB2lqHQYU/c7ClgTKa3H 75lnnvnd730HWtGOO+z44IMPppUsJDjeNCMC0odcIFPMCDK98sorHTM9quNREDAyXAVZkMFw/qCD DtLTARsgmj39BhcAQOWB38PcX+z4xwV/kPrrIwAoANALSASAY7stZ7TC6WgA+wckwwVA4dVQOOKF I5CnASIAGpkWN07ZHQUAOeUD34XAPXCUu1KZA8AdY5AHwxmc2ksB+SsXAMhxgQRjJ7dlBIAmGPAE sfPeVwBQQSBT5NyQpiV9HGGgpZD0EQA+QSJMAEAKernATnTHIuGRz4JF+uP3jtu7APuHv0CUgUAD HU/rEW0RAMDdKSMvAYDWknKALEhIrLvuuvCrCADH6qONwIDEiwBwBK3OopWBjgZogHABgLv/Fvgp A+IFFj/nrEUANA4JbuSSOgoAvPuQEJMXvtEFRREAygxgxQUIE8TEOctX6DIyXbJBdwHiSwxBgigA FBegqEnA6JSvcGg0Blfa4X75qCswfWXIgqev+ClBZF4EdAHCsQJeUt0FyFguuIqQxwkSfIwlz+ck cHGgzuDPzTOFryAGoF0B28bueToDJyE+9rvDT0jl4S+cgfM4jICpITuHFCAMGjiI0scueWq0EB86 7/FaGgqgQQnq78fLIWWIhqlBsnBtU1MTHC9cuBDOw1/dcswOhwvIcrAWIpNJMgIAnf24zo8yCRg8 /sH1H5x/4C8cQ/c/HwHIYjFQr6dZnndK/eVVOB0NYP/V5/C82dXHC/zHA/4Ad3LseF+BFVk44gWW Pf+sRQA0Mi1unLIHvDKhwx7oLDr56DemIgCwN538/vlcWDwm8sr5NM0bpqmxJABoTjD8hEMHGBlS o8jIrXE+AISlw4eTR40+B4D6+2HYAbvbcfyBbI5KHxk/dtIr6esCACPgZF9MEGc+RAmAqHIRniBv +ABF/k9IpM5IvoFJA+1GWkyeNkCUgWfDXxwfQGZPAwUoHuAvXIVSASLAGSTokCb65OgDC8oIACoQ 5OgQHzrywRg4AwEOFAchSA3MQ8aP5B6O0ZIoy0lawLVokjLs0OACAOcAoKM/zAMGJQBcH1yA4K+y IQCwfzhJLkBQQakvBBTwNCvkxqmDTMtARwM0QLgACBsBwFWAUlkLqAyI10HDdSyCCIDGIcGNXNKw VybxXd37XBEAcLspXe/chR0iG5cBBcpOju842QC+Urc3ub4gm7cs04mDAMjmLZOAcRCATyQAm2nn sqj0+dRhuBxt5suVKgKJrzWkLAOKDyVFNkTly9c2RVFR4BwAMBuYNHBoYNvA47GXHY6BJUOgQQCI A8wbzgDVRgceot1GP3tyAeJ0H1EyugBRIpQFz4ue+SAPUGMg40f/JaD16AukW85ti5oP0MgCAJcB hY5/5Pq46CcEXPyHB+z+FwHgSD/KH61wOhrA/qu9KrmNALSR/pbmyvLgIgNofFMfiygc8fI3yhQt FAHQyLS4ccoeJgCocz3M+xzXz7HTVuDfljj6tllwRt+WGB4IuPeWy5MBrYrKNCp9iO++Gk/Ubl8W 86LyLcNGYOg2g8Yj9UeWrMzfBcJNnjxE3+mAE2vyrkkiACzTgrHvn/ryce4v2aZbLgLA2DJpDgAK AJjRi4MAUYGzf1wGFGYOiAuQy0OptHHKQEcDNEC4AHAfAeDUH3YBg73AMKASsMgAhfQrX8uAeGmb Y+qGiQBoHBLcyCUNEwBwu1FHfrHdz6nf+JKgOwLoRg/8Hogyet6jGz06/KALEI4PoKMO8G8cHFA6 8skFCLvksTMeVYRxBAB99+FD3jjE1DEvVCa6CxBcAifJqwcsx/ZP7kmK5ZgseiWRbJA5ACQAABZc CRQW9tF9flAPEPs/6aST0f9nwfyHcB8AcQFyv9fKFrNwOhrA/jMfAVCoP7B/CB2b2kHQZYBSo3qX P0XAh1ThiJetCWZqjwiARqbFjVP2YAFArvN8omqmt6QkXjYEgMZBJzo2ISDWSNmNk4CBqUMc5OtI 3zmzhwtxLgEty2MRADTxwCgA4CSfBKxMUMZ8KXEctaA1hYyTgHESAhYQJznIHAAuAKqDAO9+DIMA 0LVPM32R9FOA88T+s+v+R91o4VFlu31q2p4y0NEADZDhCACwf+zjR95P1B8FAMkAjFCNvPInquHS +TIgXtNN1st4EQCNQ4IbuaQur0zuHC/HgoDXg7TuIzfyHACsXOjLR0cgIPdA9LkMIOoP8gD6/tvY fzbd/yIA8rzXCqejAew/2xEA4PTc1YfzfjomeSACIM/GGpCXCIBGpsWNU3YXARB1++CCPMoqmQH3 mlwiCNQuAiIAYBCAawAg+kD3wdsHA1F/8PwBZyEYLshiCzBsP0meZrXbAguxvHABQGzeSwkkHQHA mQDGvyQAomSAhf1j26WKxHaMZ2QEoJD2LQKgcUhwI5c04SsTF88JmwpcyH0tmQoC6SIAZEBZVbwR vioYcg0ARB96+kEGYJc/BDhTnfW7vOM/ddd/hTilW7+SmhGBwgWAF+9X1EIm+wCQAOBO/+gUBGfs 7F8RACRnRQAUdfuJAGhkWtw4ZU8oAOD2NK69U9RtK/kKAoJAIQgArcf5AED0ge6DRxAEOKBe/+x4 vwiA/Gu8cAFQzAiABWjFBYhm/QL9j2X/nPHz1iwCIP+WTXUB3KhxiKCUtDERSC4AirpDJV9BQBAo FQKoAXA0gH9yoP78rV0qTOrVmMIFQOlGAKCmcRUgcgHCA5oTrPv9642DnH/4ixmPC0e8XpuysVwy AtCYhLjRSi0CoKEea1JYQaCOEZCnWW6VWwY6GqABks4BcMGXywASAC7s3554GRB3KX59xBEB0GhU uDHLK6/M+nheSSkEAUFAnma5tYHC6WgA+wdwwgWAL7IkA4yLfvqmRqbjBKMGXHkgALEkl9gFgDJQ Q1+BROajHBQDsiavaRWKA5Xc5uSp8XK5lDEqjsu12DaSlzrdFOSVmeQpIdcKAoJAeRCQp1ludVG4 AOCU2P04XAC47wTM68Cy769vVZUBcV+baze+O6VTWJ3jhQlpnC9zTTG7JEklp+w89+Sp+cIYLABy FmzudSSvzNp9RonlgoAgwBGQp1lu7aFwOlr2EYDUa6JwxFMvUZkTdOTxejTHC90pmjGmkks+maZl cyrWUiKppOY4dBMsABA6GQEo8y0vtgkCgkBNIyACILfqKwMdDdAAeY8ApFgfZUA8xeKUPClHWmkR AFE/Gbm7y0m985vOuFyuMGYko15GEos1Xss7ue2iJdba2KS45ZZefP0ni3CKtSoqUx1G3f7U5UpC Maa0nJLfjGKeICAICAKxCIgAiIUorQiF09EA9k+eQpnsA5AWslHpFI541gUsVfoJBYBOkY081f2k QvgciayRARNhNRppFBX2dBQGHNtNbjHeMSlfAcC73qMEg3LegoNj5TqOKqRF5cPSkVdmqR47Yowg IAgEIyBPs2DofC8sAx0N0AAyAuBb0Q0aP6EAUDrLo3gtdRVH9e7HkmnHjCzE2mUQIJY0GwviOGTh KGZ8U0tSLo5qbNm9sA2j6dldJa/MBn3ASbEFgbpDQJ5muVVp4QIggP3LCEBuzaPmM8pIAEQ5hxi7 2C2s2pE0+5JXl551e5oJFQsfnUhY/CiIXDBJCwfHVpQdv49NWV6ZNf+okgIIAoJAKwLyNMutIRQu AIjNeymBvEcAcBWgVNYCKgPiuTWvwjNypG5R3cz2jnmdlnGy65J1RgLAhRxHxVF6zY0+S1z/wLGO kqPbjJKO0aQkZUnr2lj+XXgEeWUW/qgRAwQBQSAVBORplgqMLokUTke9eL+iFvKYA9BG+luaK8uD XQZA21VwV84UjrhLs6ibOC4s3MhWvbijF3N1dBPyMsDRfSU2TRdVYJQEOob2pKIUgn4VCYy0yshH JwLSLJzrGw1wfGXCw0kJAXe69oQLSEMuWYEA1UhRoEiFIvL63WFEJgu4skizqOaUPF/Hp1nyjCSF MtDRAA2QxwgAp/6wCxhsBowBlUCUDBABUKqbKnUBoDi3EBvjndn2k7oA4OMGUb8qacYOTcR20tvF gBE3+0n9VyMmxoJYSscFgO5ZlBAHxWbjV8cmVKwwcHxl6jxDmEexzyuOf551kWdexSLsnrsjJo7R YvNNK53YjGouguPTrObKVUKDCxcAAeyfxgGyGgFQqD+wfwgdm9pB0GWAvb+/tV+hbUwAm3XhiJew FWZnUk2wt2K5o+ReBwg4vjJFAGT3qAlIucDqEPap15cjJo7RYttDWunEZlRzERyfZjVXrhIaXAY6 GqABMhwBAPaPffzI+4n6owAgGYARqpFX/sgIQKlauQiAOmC3UoRYBBxfmRbGGdUVrTuoUEw8wAj8 Y/RpcT9ZqgdIpsbYKWAU8hxwBXxjjeg1q6TsWKFY13X8cakODoL7LUO3CYdaqUcC1qXe67gWsM9U 51H1XeSiSle4AAhg/9mOAACn564+nPfTMckDowBQvC+Uplw44kU1tULyFQEQyx0lQh0g4PjKJG5h ofWxFEchMXhfKyQy+GQhT4miMrUwTiO5jKL+KdaIXo/GxItCLNN89bvDiEZaTT2qirkSoPvImGmm aBSYuOPTrEAL6ybrMtDRAA2QdATgwgsvhCo0/iUBECUDLOwfxavSOMQFqMC7RQRAHbBbKUIsAo6v TJ1xurMZIy8JOKlfUuDzodisAwSAET33SkwrZrG4ZZR7KtURO0giVRBbfY5Ps9h0JEIsAoULgAD2 D4UKFwCxiJAA4E7/6BQEZ+zs3yIASAYUjngsAvUUQQRALHeUCHWAgOMr01cAtD7QVCefWAbDe1I5 YeUd2LxrM5Yz1dMTiZclFcaJdUR4BkiygMvrskZSqY6oRPSbwmsEoKFks+PTrC4bYc6FKgMdDdAA 4QIAe/0tH8UFiGb9Av2PZf8iAHJuvrHZiQCoA3YrRYhFwPGVGSAALIQylsEYb08jQ2pMDeBbHUbA RQDEvgUcI2QnAGLvFNFgKwtjmQPg2GaTRitcAASwfyhzuABwAQxXASIXIDygOcG637/SdpUsxAXI BfOM4ogAiOWOEqEOEMhIANiJi9Ca5E+tWE4fy++VCDqVTKua9AGc5MUvVQqpCwBjXQRw/ahGUir0 UjTG8WmWYo4Nm1ThAoDYvJcSCBcAsSMA1BS4DCABYGf/Ls2oDIi72FkfcUQA1AG7lSLEIuD4yuR+ CBaHHIVwKDHtDAb5qCXxlbtLDDHr48njXgojXEYYY9UCRnCpWR7HsUK50nAvXQ3F1O8O443gflJv 6rFqzaveawhbL1Mdn2ZeaUpkIwKF01Ev3q+ohaz2AeBIkQwwLvoZ0KoKRzzA5tq9RARALHeUCHWA gLwya/cZlaLlWXtSZZ1+ilBIUrWLgDzNcqu7MtDRAA2QxwiALgNSqZUyIJ5KQWoiEREAdcBupQix CLi8Mo0dnKU6WROPlLSMLBXyXsakhUCp0vFCoPDIpYIudWNcnmapZ9qYCRZORwPYP40D5DECkHqz KBzx1EtU5gTdBQD4hsV+oKSxVEwiCAL5IyCvzDI/hXKzLaMe+ignpdzKJRk1FALyNMutustARwM0 QN4jACnWRxkQT7E4JU/KSwB0sH6w4vLndpKjIBCLgLwyS/4gEvMEAUHAEQF5mjkClTxa4XQ0gP3L CEDyem+UFHwFgAUXXQBA4rHMzBIh4eX2lLHgPIuE2VGCsZDymGSkPfeEtiWphfq4Vl6ZjfJEk3IK AvWOgDzNcqvhwgUAsXkvJSAjALm1kNrOKJatEv8D/x8YAKgDAaCQafqakGQ7Xh6Qu3sd1QdZz6IU 8sqs7eeUWC8ICALLEZCnWW5toXAB4MX7FbUgcwByaye1mpE7uawbAaDwy2IFgMsIgHsdZUGd6yNN x1emfaHDrG/yjDzUszY7u/SjVmUVoLLDPDZlXimxkWMjGKvSuO5qbFKNE8HxadY4gGRX0sIFQG2M AOBioPhJWBllQDxhEWrocndyGSwA9CzojOKBY/TJib08yo0Hz8c6+RgFAHnpKASdG6McG4ky9/bR 7eGXhJUiathBtx+hiEXYvT3UljBwfGX6Mkuv+F6RM32GlMcSezFrxc5MK6tUiSs1kryC7AKgVGUv jzGOT7PyGFy7lhROR8s+AtBG+luaK8uDXQZwSsSbBZ0vHPHabawBlrsTvjABoNNrfiaKfCO5NDJs /fIw6qx3vXsZo0TWib59nCGKiyuKhb7ayxiVF0/NmIKvnqkt0q/oKyhs7A3iEGWlNLzie0WONTVJ hPJYIgIgST3mfG0WZD2LNHOGJf/sRADkhnkZ6GiABshjDgCn/rALGGwGjAGVgEUGGJuvCIDc2rSu u1yIXZgAsPBsnewS71cOXIiswpV1vmvsLI+ixe5mYwpK4npeRtmjlysqHeN5Y4liUY0FMyoFl0ZS 2jiOr0wLM8af0P8BP/rij8YzPCZPPyoyxlfyMp7kxlhMijW7kCePS6ZR1aG4iIThEIWYsWZdrK37 OLG60d7+OeCElaWpU5uPuiN4w461rZ5qx/FpVk9FLqoshQuAAPYPWIULABegFeoP7B9Cx6Z2EHQZ oCeoN186AweFI+6CQN3E4X3AdvaWtQDgnej5CAAXtm0fFnBh20ocS6Z6XRhzNw4LKL3delW6S50G FwBEYhQ2o1B/YjMKlVHOG6/izEZnOTpf15mTuzGxMcv8KFPqQoc6tnSKWtNrx5imsU7LDFQ+ttlJ tiJu3RutIue87gijqMgHjQJzEQGQG/hloKMBGiBcAADPs4Nb9fJv7eNH3k/UHwUAyQCMYJwSIAIg t+Ybm1FJBIA7PbXE5J3xsSMA9k563xEAFyccXdUYO+OVsQJdF4kACBhncHxlxo4AuDBII4NRSD+/ MS0EyCUp/fLYq2qlu9RxBEAXY4603pi+kcjGPkgbIYJx/MqOYRSYjo3WMZrl5qrLenF8mtVl2XMu VOECIID9A0ThAiAWX+D03NWH8346JnngIgCU1lw44rEI1FOEAgUAz9roIWNXBYrlxsg6jzey8GDX oygubjEmdthBVybGLnljtLCRE8tVAVS7nJc4vjITCgDeY62zUiVxS+SozlRjz7TSya0PXNjZcJmf ZsECwLEiosirfnmZUcrNNhe95NL83AWqCABj5To+zXJrGHWcURnoaIAGCBcAOAJg+UsCIEoG2Nl/ 681f/bDXEu/lFBegXO8mLwEArcoewHTFF4WqVj+v+8bwLnz81evyKLpvzEhPXGHtjgLD2GHPLTFm pJfLS8DokkDXFXrNumdqURfl5PexVjm+MhMKAP3Wje0BNZKhYAHgaEB9jwC4oxfLaHN9Fpc+s4DO /tj2b68sEQAiAIq9LQoXAAHsP6cRAO70j05BcCaW/UcJAKrmwhEvtsHlnLu7AHA0LJaKxXqru6fg zlPdY7rnXmzM+itRpnjmLADsxEUh/Xpkdwrr3pkaFdPxvi4kWtgIgDIkgpa7QxrFWQtBoGyZ6qNY rCOv7RAHASywuzdaRwHAcywbYlnY4/g0yyLrRkuzDHQ0QAMkHQGwVLPiAkSzfoH+u7B/RQDoTbkM iDdOK3cXAFnws4Qs1v1y95hZFDOLNOuvRFmgpAzFxN7X3PfDxZlBYR7KJTrvVMglfk1LAGBSukl2 ihaLSYERwgQA4RBLNI2IRZ0sEIdSZc3vEcUwanteAsDSaF3SUW6iUmGVkTEiADICVk+2cDoawP6h FOECwAVZXAWIXIDwgOYE2/cC4x4RihjArAtH3AWBuolT9wKg2AJmQWrrr0RZoKSkKa/MunlkSUEE AR2BKK1Yl1jJ0yy3ai0DHQ3QAOECIHYVIIKeywASALITcG5NM5WMhE3mwD4li8IRcHllGrv/6/tk Ks+QjBIpD/IZFbC2ki1PdVgsqS1Ig611eZoFJy4XcgQKFwAB7D/zEQAOEMmAqEU/fdtT4Yj7GlzT 8UUAFM5NxYAcEJBXZk0/psR4QcCIgO4+1AhAydMst1ouAx0N0AB5jADoMiCVWikD4qkUpCYSEQGQ A/uULApHQF6ZNfE4EiMFAUEgFgF5msVClFaEwuloAPvPdQQgLaApncIRT71EZU5QBEDh3FQMyAEB eWWW+SkktgkCgoA7AvI0c8cqYcwy0NEADZD3CEBClPnlZUA8xeKUPCm7AFi27INGCzvusGMOfFSy yBkBeWWW/EEk5gkCgoAjAvI0cwQqebTC6WgA+5cRgOT13igpiADgCufSiy8VAZAzNc8nO69XZtRC h8ZFPBvlSVFEOfWlXQIWezFeEpBOEQCUK0/f6nBHXqrDq6a9nmZeKUtkBYHCBQCxeS8lICMA0pKd EHARAHzl1vo+FgGQDx3PPxf3V6bCRewkRoiL01MmNJIv4zTmE7uWfKh1DXedb3W4C4CGgzJZgd2f ZsnykauLX5Xei/craqEdXMwD/gwLfUIDKm3dlkFylRac1A0TAcAljQiA/Kl5Pjk6vjIdKYuRU6Z+ b0qCvoxTBECmbca3OhzvpkxtrsvEHZ9mdVn2nAtVBjoaoAHyHgHAxUDxk7CGyoB4wiLU0OUiAEQA 5EPBi83F8ZVp7xihPUeVlcjpfm/MRQmze9zZGacRbf2kUmtoLT+Znf11lrJvdRhBtpykqsFK5B+5 s1ZGo/o8q7PWVc7iFE5HA9g/jQPkMQLQRvpbmivLg10GcL7V+iBWP4UjXs6GmJFVIgBEABRLzfPJ PUUBQPSRH1iOM7pzGyFZRWhxXsj5j93JJ+pXGcbxbUIB1aGDbKxExxpU7jJf++smvuPTrG7KW2BB ykBHAzRAHiMAnPrDLmCwGTAGVAIWGcCbr9KU4WsZEC+wweWcdSoCwLhSUPBsAUwt+PIkF4oLUD50 PP9cHF+ZCq1U+h2NbIZ3/+d889Z9dpYuZ6MAUPqMqUdZORC1FtZyfKsjuUjTKy7M8jq7yvFpVmel LqQ4hdPRAPaf+QiAQv2B/UPo2NQOgi4D9GqzCAAyHacuwHSFDh06FFLxDZJpigKAM+9MSXx2iYsA yJ+a55Oj4yvTOK5u4f3iqJDpc9LOOHmHNJdhsbJNBEBYreUjAOzVGmZ5nV3l+DSrs1IXUpzCBQCn xO7HGY4AVL38W/v4kfcT9UcBQDIAIxinBIgAKKQpGzMVASAuQPlQ8GJzcXxlJhQAMhqQ7pPNkXEa YXcfrhFvasdac6yOAH8ed3csqaxW+SpzABzbbNJohQuA0o0AAKfnrj6c99MxyQMRAEkbYMbX5yMA yEdIHyXg7kP4q9LBr0TQ49Ml3HFI8Upy9AuSEYBiaXp2ubu/MvVOfZ1f2imO0sGc8R1cz8kHM067 o7mMAIQ1muDq4IDb/YLcvYbCilAfV7k/zeqjvAWWonAB4N7rz2MmHQEA3xtIzviXBECUDLCzf0W/ 6k25DIgX2OByzjoHAaDwcuLiOl/XBQAXA3SsKwQ9zTA3IREA2VHwYlP2emUanRCMJIYTTYygnMn5 dq6z7CyMMwptwt84AhCr3OoMwHSL41sdjj5auh7TbyK5s3hVej3N0m0DjQPHJSgAAIgTSURBVJZa 4XS0vCMA3OkfnYLgTCz7FwFQqlsoRQFg7HQ3dudHdfNHCQBlTrBRFSjXigAolnCXLXd5ZZbqsSPG CAKCQDAC8jQLhs73wsIFQDEjABaYFBcgmvUL9N+F/dsFALTsMiDu20pqN36KAiDWgYc7AkUJg1gX ICVC1AJEIgDKRsGLtcfllck7LFM5rt3HQhksT6UK3BMpQ5HLbIM7kjnELDNQOdjm8jTLwYxGyKJw Olq6EQCodVwFiFyA8IDmBNv3AuPe2CQG+MnCEW+EZk1lTF0AGAm67oLvLgC4rsChAMsIAPcFClhL VFyAiqXp2eUur8yGeqxJYQWBOkZAnma5VW4Z6GiABkg6B8AFXy4DSADITsAu0JUnThYCgHP0VFyA LO49junrCsR4RgRAdhS82JTllVmeZ45YIggIAkkQkKdZEvS8ri1cAASwf/Iaym8nYBQAydk/mS77 AHg10+DImQoA3mGvLwSke+/EOhHpowEkNpT0xQWoWMJdttzllRn8iJALBQFBoFQIyNMst+ooXABw Sux+nMcIAK8Dy76/vlVVBsR9ba7d+KkIAMf+dUu0ML6ePF8lBRkBKBtxT8seeWXW7jNKLBcEBAGO gDzNcmsPhdPRso8ApF4ThSOeeonKnGCBAsDFlT91im9PUARAWoS7bOk4vjLtCx2mdSNHLUYpmxwp CAsgaTW5FNOJWiQXsuBrsCZfD1efTBxWivprRY5PszC45CqOQBnoaIAGyHsEIMVGUwbEUyxOyZMq UAAo3js5c32ZA1A2jp6pPY6vzJwFAD0c6o+jpPLcE1hSgTHFRJQaid23K0nWad2MAa0o4JIkJfW9 1vFp5pusxNcRKJyOBrB/KEW4ACi8ERSOeOEI5GlAsQKgDKSf2yAjAJmy8AITd3xlpsU57LdwPrnk +RjJKK+S87CMSl3aZI3VoQ9npVVrad0mAfYEXJJnrTk+zfI0qV7zKgMdDdAA4QIAd/8t8FMGxAss fs5ZiwAQAVAgL88ta8dXpp1zkE+C0nPPvR10z4eoqyARzE6JoMfP+ZlQnuwUcumFLcHLccaiudRj VEzj5eVBLFNL/n977wFuS1Vn+577bvftVp++a3c/vd3P1622EWwUT7fQhvYIiK0o0iItknwYDiCK qChJFAmHKChB3IIkSXIASYecM7hJKlxAURQRTERFBZrzxj7j8PfPnBVm1aq01hrrq29/a9eaNcNv zqoaY4aqAgOQOV0nGB9IqT6f/4KT0U6c0mqKm4Ed4s/i+BQuzXyrqIsjT7ya9ZjDiUm6dzlaQ/0D fn0D0HvN9U68dwJdZkAGQAagMxXeY0KJt8xYx8QdnIGk8AGKe0MLfi1OpcsLwqDSGoVtQTV55ecV ZCANAwmYKRwHhavtzBQYgEydXXruxBWRbgASIw+UfWbVJ+70ZWwbtQxAv4Qt9SHI0RoeoL4BqDcC wKcANfIsoCEQH0jj6yAbpQYAs2Kmalt9tdV71KlKuiUC6QYgOOkSdUYgDhKPSjQMHVwHhplEIsY8 1Zh5eGbgUq2fKVUzBfEwSTaSq0YMQDrJzFGFYhuW3mCK20Zme2iEYSORJF7NGklryiPpXY7WUP+o svoGoGp9Lxf9szNLn9qKbYB1uOYl1DvxqgTGOnyxAYAansKtJQ2qaHskkHjLLJ11EOiPPKEQdF2b lMk7vDj8WF9hRsl86cBIADbFhjFMXo34GPL0bnz4KGUco2MbNwDFJAv8Vcp5FzuNejbPN5iBVFbi 1WwguR3rbAxBjtbwAPUNQPoIgJf+eAsY3gXGjU6gwAag+Ra0iSEQH+smWynzxQagR8WmpEWgQQKJ t8w2DEB8PhZ0/E9bp3LxxarUANQQeaUqML1vuNKVdgICN24AEmu/4AxKsXzpwwJxcwqSHsjpmXg1 m4Am13sRepejNdQ/oNU3ACnEA+kP9Y9t4fx52GIbkHX2LjcAdALBmEDvxFMITEwYGYAGVaaiGiyB xFtmqwYgRfcPfO5Bx9e9dOlWL2S9o0plYseUukwuOEGK3VQNvL4s3Y8AlBpOGYAuG9sQ0hqCHK3h AeobgNIRAKh/9vFT95v0pwEwG8AAc4Gjj40ABHdl7h8C8SG0vG7yIAMwWM2qjDVIYHQDwL5GbpkS sGB/3lF5giMI382lYICppAiymJVVU15fvh0yYvwDJNZBlmK8TLTA32aeO3k7U/xV7ENSmoFPMThb 4zO0OEAHnAuSSLya9ZvJyUi9dzlaQ/2bip6Hg/3GHyDxiyfhFNccNL2f6uN1v303e1BqAJ7u+GUA uj5rZAAaVJmKarAEdMvs+sqi9ERABNohoKtZO1wzYu3dAJiar+QERh0B4DhA5l8zAHk2oFj9L3Ph T5sC5By/DEBnDXt5QjIAg9WsyliDBFJumb5rczjfu74iDCa94VRBcU4GA6zdjIxLdXSQz3ZBJ8Se cjVLiEZBygn0bgAq6f7ALbQ7AuAn/XNSEPaUqn8ZgPJG12EIGYAGVaaiGiwB3TI7vKgoKREQgRYJ 6GrWItynR927AehnBKCAbzAFyFb9Qv6nqH8ZgM7abkpCMgCD1azKWIMEdMtMuRoojAiIwPAJ6GrW WR31bgAGNwIA9HwKkE0B4hdbE5w5798qzD/zJ1iKoEXAnTXroDoaVFqKSgQGSEC3zO6vLUpRBESg DQK6mrVBNTPO3g3A4EYADJO3AWYAitV/SrUNgXhKPicjjEYABqhWlaXGCeiWORnXK5VCBERAV7PO 2kDvcnSIIwCevtmAvId+Vq2q3olXzfBYh5cBaFxrKsIBEki8ZcYrCEvPbj2ysxTRKAGCGnFDl6PE mn3sQJ7y3nzBmogxc3FtExHPxSHylUgmXs0qxanAGgGYI1D6HoBMTAXv/a3asGQAqhIbJbwMwADV qrLUOIHEW2YsRIqliYTLKBef0mMLqkPkS+m1FKAN8m3E2VLxhxBt4tVsCFkd9zz0LkeHPgLQeAX3 TrzxEg05QhmAxrWmIhwggcRbpgzAoC5WMgCDqg5mpg2x3kacA0TXVJYSr2ZNJTfN8QxBjtbwAKO+ B6DHKh8C8R6L33HSMgADVKvKUuMEEm+ZxQbAZkGYEvLzf4JfTSpZnAUBgnTjkIxt2qYbFehC/hQD SYScebivqYLIWxLBHV/5aycXt1UPJD5HLKHSE6F2lqbtwMSr2bRhaaO8vcvRGuofHOobgDYgVoqz d+KVcjvugWUAGteainCABBJvmYldzoFSDBRhIHTiftPiAD4PcULTpj7zbE9gvWpALqjE4sinzYYF 97hMs5rHP27Mpc173G+pHeQ/8WrWQU4mPokhyNEaHqC+Aai3BqDBdjAE4g0WZ+BRyQAMUK0qS40T SLxlmtzM60gOhE6xQM/UOkF3aWb/aHzRyItq4JeXBrMXyO5SHVmjamoc0mABxyWqzBGAghZrgy3F Jm1cij+EfCZezYaQ1XHPQ+9ytIb61wjAuLe67vIvA9C41lSEAySQeMss0NmBN4idgA+QqXVKA8RH eXsQH97dZWIwKdXQ6DWsQvohgwHTXUaKDUBeIw9GvQKDHcTZXWHGM6XEq9l4Fm5Yue7dAJiar+QE uh4B4FOAGnkW0BCID6sNtpkbGYABqlVlqXECibfMAnGTqVEy9Wjcqe97/f3ZXCo0M6Nq83owrLhj 5jIAvddQ4jkS1FT6mdJ7AYefgcSr2fALMvwc9i5HK+n+wC3Mw8F+48+Y5BO8gneUalgu+mdnlj61 FdsAtl3fgv0efO+d+Cg0xu5YGYDGtaYiHCCBxFtmPXET6PtikeoDlxqA0qjG7oJTKcNNGYAYI3ug +Sn4kvfrNPdYp5wjHm/e2ZF3IlRqIdMZOPFqNp1wmi31EORoDQ/QxQiAl/54CxheBsyNTqDABsTq 39fZEIg324aGHJsMwADVqrLUOIHEW2aB4qReKVY2Bb+mHG4XijihzMOHfGFpKm9+SkmmX4r1ZWYt pO8sFqzMgwyAb6u+ro1zXmWVnghNtZwJjifxajbBBDorWu9ytIb6B5z6BiCFbCD9of6xLZw/D1ts A+IIZQBSIHcTRgagca2pCAdIQLfMbq4nA0wlU6yPqOBHPHyAlJSlMSKgq1lnldW7ATA1X8kJ1DcA pU8BgvpnHz91v0l/GgCzAQwwFzj6yAB01nxLE5IBGKBaVZYaJ5Byyww6mwf+b+mpPe4BBs5/2jxA B9Ux7i22s/ynXM06y8xkJ9S7Aaik+wO30MoaAGh6P9XH6377bvag1AAsGxB82qd34pPdoIPSyQA0 rjUV4QAJ6JY5VZc1X9gGRwAyp2ZNLVgVvC8Cupp1Rn4IcrSGBxh1BIDjAJl/zQDk2YBi9W+KP7MK tQi4s5bNhGQABqhWlaXGCeiW2fGFRcmJgAi0REBXs5bAxtH2bgBqqH8bB2h3BMBP+uekIOwpVf+B AUBTfnpvjZ4C1FnblgFY0rjQVITDJKBbZqeXFSUmAiLQGgFdzVpDG0bcuwEwNV/JCYw6AlDAN5gC ZKt+If9T1L8MQGdtNyUhjQAMU7AqV80S0C0z5WqgMCIgAsMnoKtZZ3XUuwGopPsDt9DKCADS4FOA bAoQv9ia4Mx5/1Zhfr4/d2oNQGetOU5IBqBZoanYhklAt8weLzJKWgREoEECupo1CLM4qt4NwOBG AIyXtwFmAIrVf0q1DYF4Sj4nI4wMwDAFq3LVLAHdMifjeqVSiIAI6GrWWRvoXY4OcQTA0zcbkPfQ z6pV1Tvxqhke6/AyAM0KTcU2TAK6ZY71ZUqZFwERCKZRCEgHBIYgR2t4gBbXAGRCL3jvb9VKGgLx qnke3/AyAMMUrMpVswRkAMb3GqWci4AIeAK6mnXWHnqXozXUv80aamsNQKv0eyfeaumGFrkMQLNC U7ENk4BumUO78ig/IiAC9QjoalaPW42jhiBHa3iArkcAapDNO2QIxBsszsCjkgEYpmBVrpoloFvm wC9Eyp4IiEAiAV3NEkGNHqx3OVpD/WsEYPR6n5YYZACaFZqKbZgEdMucliuayikCk05AV7POarh3 A2BqvpIT0AhAZy1kvBOSARimYFWumiWgW+Z4X6eUexEQgacI6GrWWVvo3QBU0v2BW9AagM7aybgm JAPQrNBUbMMkoFvmuF6hlG8REIGnE9DVrLMW0bsBGI8RAD4FqJFnAQ2BeGfNq/eEZACGKViVq2YJ 6JbZ+6VGGRABEWiEgK5mjWBMiaR3OTr0EYDlon92ZulTW6kNsFf/ZlZA78RTmsXEhJEBaFZoKrZh EtAtc2IuWSqICEw5AV3NOmsAQ5CjNTxAF2sAvPTHW8DwMmBudAIpNkAGoLN2nJeQDMAwBaty1SwB 3TJ7v9QoAyIgAo0Q0NWsEYwpkfRuAGqof5s11NYagED6Q/1jWzh/HrbYBhRIT/5kAwL4YllHsbHt vPPOCxYsSKknhalHQAagWaGp2IZJQLfMetcHHSUCIjA0ArqadVYjvRsAL4nTv7c4AgD1zz5+6n6T /jQAZgMYYC5wzodyn3/tg3+HQLyz5tV7QjIAwxSsylWzBHTL7P1SowyIgAg0QkBXs0YwpkTSuxwd 3AgANL2f6uN1v303eyADkNLIegwjA9Cs0FRswySgW2aPFxklLQIi0CABXc0ahFkcVe8GIL3X34cc dQQAc28QXeZfMwB5NiBF/Vvfv0YAOmvKmQnJAAxTsCpXzRLQLbPf64xSFwERaIqArmZNkSyNp3cD MNwRAD/pn5OCsCdR/csAlLY8BRABERABERABERABEeiFQO8GoJ8RgALWwRQgW/UL+Z+u/mUAemnN caJ+Bba+i4AIiIAIiIAIDJ/AQCTEZGejdwMwuBEA1DefAmRTgPjF1gQXzPun7g8GsPQUoB5PoeFf 5pRDERABERABERCBQCz1qBymJOneDcDgRgCs4r0NMANQrP5TGs0QiKfkczLCaDbhZNSjSiECIiAC IjANBHTX7qyWe5ejQxwB8PTNBhQ/9DO9wnonnp7VCQipS8kEVKKKIAIiIAIiMCUEdNfurKKHIEdr eIBRnwJUlW/pe3/TIxwC8fTcjntIXUrGvQaVfxEQAREQgekhoLt2Z3Xduxytof4Bp74B6IxsXkK9 E++dQJcZ0KWkS9pKSwREQAREQARGIaC79ij0Kh07BDlawwPUNwB89n+PnyEQ77H4HSetS0nHwJWc CIiACIiACNQmoLt2bXRVD+xdjtZQ/xoBqFrL0xtel5LprXuVXAREQAREYNwI6K7dWY31bgBMzVdy AhoB6KyFjHdCupSMd/0p9yIgAiIgAtNEQHftzmq7dwNQSfcHbmEeDvYbf8YkHzSgzghWTah34lUz PNbhdSkZ6+pT5kVABERABKaKgO7anVX3EORoDQ/Q9QgAnwLUyLOAhkC8s+bVe0JtXErmzZvRJgIi IAIi0DGBNm4o8+Yv1NYBgfS6a+OunZ76VIXsXY7WUP82DtDFCMBy0T87s/SprdgGZLZdv7N34lPV vtu4lHR8z1NyIiACIiACINDGzQvad3bevBG3G575zDvXXfdXMzN//OlP28jkuMcJyOlFaOOunZ76 VIUcghyt4QG6GAHw0h9vAcPLgLnRCeTZABmAQZ0/bVxKdCcWAREQARHonkAbN5cRDcAtK6549zbb PHLppW3kbWLilAEYZlX2bgBqqP/WRwAC6Q/1j23h/HnYYhsQ1CuXH/hFCMGe3okPsyG2lKtWDUBL eVa0IiACIiACJOBtRhtMahuA/73KKvfuscfvb7utjVxNWJwyAMOs0CHI0RoeoMURAKh/9vFT95v0 pwEwG8AAc4Gf/pEBGFRDlwEYVHUoMyIgAiJQicAADQCk/3377afZPun1KAOQzqrLkL0bgBrqv90R AGh6P9XH6377bvYgzwDYIIANBdiX3ol32bx6T0sGoPcqUAZEQAREoDaBQRkATPhBr7+kf9XalAGo Sqyb8EOQozU8wKgjAHwfcOZfMwB5NqBA/ZvulwHopvmWpiIDUIpIAURABERgsAQGYgBuet7zMNf/ 0RtvHCyoIWdMBmCYtdO7Aaih/jsaAfCT/jkpCHuK1b83AJnfoUd7Jz7MhthSrmQAWgJbNdobbvj5 hRfeyq3qsd2H/9GPHjjssCt33HEJtn33vfCBB37ffR6Y4nhxa5YSsJ988g2sBWyolGbjV2xjQWAI BuCHa6/94OmnjwWuYWZSBmCY9TIEOVrDA4w6AlBQGcEUIFv1C/lfqv5lAIbWymUABlIjq62277x5 C7kVZ6l3kwDpb1nllx5NSzq3gVR0U9mA8/mf//PTviLgAZqKfDrjQTM2NwVnNS4Q+jUA33vxizHn 54kHZD5Hai8yACPha+3g3g1ADfUPGPUNQApJPgXIpgDxi60Jjuf9+zjzXkKsNQAp5BsPIwPw9Ma5 XIJDVjaOujjCRCG78sq7UfPhS8c5ZHLoZg7Uf6ljaTWfidxazUMvkb/oRTsOx4b1QqDBRCH9Y57w V2NhA3o0AOj4f/i88xqsiKmNSgZgmFXfuwEwNV/JCdQ3AJz3n/LxNsAMQLH6T4l2CMRT8jkZYWQA xsgAQKZ4zddLvzu6SC0P73nPQew07fFcmE4D4FsCrCB0KiZiaQpQvXaIsZTY09qeXs6ySgXpxQDg xV6Y8a/FvpVqqiCwDEBTJJuNp3c5Wkn3B26huzcB0wCMrv59AVByuJEFCxY0W6OK7emSd84CNMvE bkjNRttBbHbXH+YIAOZ826wPfOll5j1Ev1HqTHFCoqFGuGECkm8JjRuAgrQ6aIGJSUDuWy0EQBJj SAn26U+fbNhTwo9pGBtVA1KMA8DQ+rlVaPADL1f3BgDTfvBO34FjGa/syQAMs756NwCBpk/0A12M APgKy3vvb41KHQLxGtke00M0AjBGIwDIKjR3vys+GxfcKSeO7/AOBhwaz09BWilZ7SaMH4dpr4u6 cbbdwKmUiu/+N1MdOO1KEXYfuGMDgGf83794cffFnOwUZQCGWb+9y9FExZ/pE7oYAWi82non3niJ hhyhDMB4GYDe21IvolAGIKh3GYCmTgQ/4INxFYu2l3Zer1BdGoA71lzzkUsvrZdPHVVAQAZgmM1j CHK0hgfoegSgwcobAvEGizPwqGQAahsATLzeYIPDbI5EwSRsdNvjVwuJo+LFhZmCwz/kkT3f9pQS m/hhj+PEF6gZm7aRmQrHEHxm+PhIH0lei2XSfq0k9/geaHSdIirMmmBh8QX/BlOV/LNWkGHEwMCZ awkYGGXxs7OYLgl4bihIafGJ1OoC35EHFrk0rUwyHh3HZ9KbhIGKH+Jp0fIna2koIJMwIPjJaFgO UUyPIm+aEKoGjcGygagYMq+uCx42amNTROqbAfbE09XYDq1cTNoHCxq2D8kmx8x72pmT4nwbQ0lT nlrrRwD6Wm2ffuPozABgye/vrrsuPWMKmU5ABiCdVZche5ejNdQ/+NQ3AF3CzUyrd+K9E+gyAzIA NQwAJEX8zBAKMqiuoPqwJ3OJIWIw6RkIWcYADecPpDKLVymYFgweCsmQkE0+P/ETPBEGB9qxBYsf 8hZKmnBH5Jl5wE4vQH3vtQ+fmbQPHGSA4b0UjnPoi19Qa2au8spYgMXzzyx+LL7zCuUtkC9XZrSZ NAAExfST2i0Ydvr2hpB59ZV5eOmiWD9KE2cYe3zqBSeFLSwpbtiIIU4FOfceAN/9khUrQvHjfXCU J5DpS7u8RJem1Y0BgPrXS75K66J2ABmA2uhaPXAIcrSGB6hvANKfAtQS9yEQb6loA4xWBqCqAYif vx5IMS86fdd1LC69KgpGAIJUTEQWGIA88Wo99IGjyAxf2wBkWovYwIB2nvxtwwAgA1Z8r+rwPXAO 7P4fxQAUPEnGD/j4JgETGGTDKrrY2MRpkV7QbLDTO1Wvjwvqq9hv5C05CB5RlZfDwNkirSCT1gyq EmCKptcDHY+y+wYQGBK7CMRHDfCiHWSpAwOAmT/q+2+1JcgAtIq3duS9y9Ea6h+FrW8AapNq6sDe iTdVkLGIRwagqgHwMgL9i5BcnPfiZRMFnxfc7AVHSIT3vZI2wcDLnUDG+T7IYgOA2KDDkIqPzQYl vBbMy3mBAeALyHzxuQddtth88TlRhHNCfLcrO3cDnY0UAQpwMqep4BAk4R96AwHNdNmj7EtaXHz2 B+Nw62PGF2MCSqVpZZ7RgU7ldBdE5WsZqfBYr5LNKCKwUbWQQbQsNTiAEr54F4GdMQ0vcONHBmXW FyuXB+bVNVtXJofAAJBD4DntWJQCBcwbF2KwuGY9KLYrztr3BbQG7JuZJYRMWkMNBsdYqCDRXh60 VfXG0YEBGOVh/3seeQ7UrW3bHrB8jHTm5Mv8/jW22N8XfPbWu+zX575l64AJAvNXO8pSefHaO9z/ 0O8Q/vxrb/XxF6QVRO4zvN624cOOLGnk6s6f/YrH2iH4UrX6GF4GoB63to8aghyt4QHqG4B6IwB8 ClAjzwIaAvG2W9Vw4pcB8HURy+ugpvwzQ4LJwV7r8NGBXgIGk/69jI6FrBfTgUwpNgDWO+vzSUnk 9Vmg8gt+ihtqMFLBAF6BBZOg/GQPyjWvzAr8hk86cRFwQfHjeqTGNSVtOSlIK/O09UD8KlIE9j8x b9YkTOgzTt8fz5D+2HgWimeYWerATZnPYTHz6osG1YqZWdd51668VuTPgnj0ACmyIvzhMQE70J9l vvF4c8sc5gl9752CsvjIg9lEw7lixznpwACMUvzAAMzfaHfGtnD3bxaIcvgE/+uJ58/6PAQGAG4B cpzh8Z0haxsA5NAnTTthH0s6037IAIzSVAZ4bO9ytIb6B8b6BqBqHSwX/bMzS5/aim0AFWfw7Hm/ s3fiVQmMdXgZAF99pQag+PnrpkIo70yCBGoPP3nBFy9mtWzEnZTFBqCgLIk5L1XkmaKw4OUA/s3B LI4Xr4lvWk00AKVVCdR5E9wbMQDBpcDXMr1Bymx+hvSc437oTAPgqzhvPhIygMgTX+ZQ2wB4x5KZ VS5rzqMRGwADm9cSgqwWv9vL4ASLImq0zCFc/MfLAEA3U1Kjq77AAAS/wi0UGACT7F5/ewOA2CDc bbNRiLj60KkfjBtgpCLPACAknYlGAIZwIrSRhyHI0RoeoL4BSB8B8NIfbwHDu8C40Qnk2QAZgDaa ae04ZQBKVaMPkKlmLECgQgrsRKxjMmc8x08gqW0AEnNezwAUK8Ugz8U5yWzJoxuAYG53wQz12iMA 1Nb+E0dVsE7AfqJ6LkaaybBgDYNPtzTyvPZcfJHJ4xZntXS5yOgGIJiPVLo8hkWr0TJrX3gbPHDs DAAkdayz/RQg+9X69YNZQH4EwMS3jS2QrTcA6R3zNjHJkg5mAfkRABgABIOfkQFosD0PKqreDUAN 9Q+A9Q1ACv1A+kP9Y1s4fx622AYEEbLv3+vOYE/vxFMITEwYGYBKBiDu0/WHW48mhbsNCMTS0HfW shc8mHycNwhQ2wAk5ryeAfDTKoJeVd8Xy9lBNWTW6AYgmCYO5lwJYNgbGQEIuurjURc/1x8cMrcC +WuNLZOhn8HCZ4NmboikoL58e25pBMBOE3xBDlne4ilAlqvEEQBUhD9T8lAEr7LmIhBuYzH7n1jG xQCYdEZ3PnU21HM8mx8l8nra+uP9LCA/ET8zQGAAEB5xcgt69INbOeQ+I/Qzl/wsoDhpFEcGYGIU UVCQIcjRGh6gvgEoHQGA+mcfP3W/SX8aALMBDDAX+OkfGYBBnSoyAJUMgJ/QAvniVYLXZJzr4mWW nxThnzIOmRIoUeypvQi4oCyZbzxl+Mw1lHmtNFMUencRWAgf3p4xb+IsnhSeme7oBiBvRo0p8kYM gJ+yhVr2E9NZy75JePWJwFw5bcWvMQIQz7ay2LjM2v719cX1Kvw0tQagYAqQr0q/XMS7l9FHAFCW YD6elREnQt6rAPhiAWQ+MLGDumLHmRkXA+DX6XIBANR2pgGwKT0YCrDvfhZQ0A0fLAgmorw1AMFq Y88TQp9RcSWxWQvvGXyGLYCtZ0gfagjqUYuAh3mW9W4Aaqh/kKxvAEqrAZreT/Xxut++mz3IMwBI JZgLZEq0d+KlBCYpgAyAr03/yBoosHhD4ODpLlAMfCOYn2ZAARFMREYYhET44Gk8zEAg+DJfArDs rJl7+Ak2E6x5SrE4JPKQmfN6IwCB2EUkfKqPzxtSpF+qMQIQuBf/1KDE4vtao/7jNPSYUkFamSd+ MHcL/zJ7vpaNqtfofGYR4kR4BvbPp69hABBV4DlZTFuHDQisgrz6YjbMKnhofAxR4FI8kMQpQMEy ep4pIODXAzRiAAKTAw7U90wofitCcA4mWtMh3AvGyAAE3eeQy7EBsPk/UOHAa6uB/SygTAMADQ3R bzVSwwDY/B+aDfMefhaQJY0RCT9DycYN6jUJGYB63No+aghytIYHqG8AOAJQ8NcMQJ4NKFD/1P2s MxmAtttuSvwyAJkGIG/SMMVT8ZuS8rpa4zj9k0ZiweeFsj3VcRQDUPoGA+8r8hpPnjAtjtw/lbKG AUBm4gWjVNWJBqD0HQje+eSllWIA4loOHjlfPAPe+uPrGYDixomcmK4tri9OS8tcVZynjBMNAKIt Pn0AsBEDENihuF6CRzYtuyUtd9f4Ej95KeVy2kuYMTIAwROB8MSe2AAEjwfNfBaQNwCmwv1jeVAR 3gBA0ONfbvaYoLiyggcTZT4LyJJGVHFWNQLQyynQXqK9G4Aa6h806huAUpRmAPykf04Kwp5i9e8N QPyd3qB34qUEJimADEBVA0APkPmGL3Sgxo+1sf7dQIIgBj+DKFPw+Z1Qb77/uMYIAHIO2Rf0WCNX mX3VVQ1AXuQ0FX5ORT0DEOvmSgYA2ctcIxs8H5Olzkur1ADE0jazpzmzSXBCvCVRzwAUNM6gFgrq y1pmpp0Y3QCgMcSgfCNsygCw0mM7l3meIrBnrhEAa4qVOqfjc8TPjw+ezIPAsQGwWfjB03jwr80C 8gYAcXrhboMANRYBey+R9ywgbwB8/jUCMEm6yMoyBDlawwPUNwApawB837+t+oX8L1X/MgBDO0lk AHyN2BLAvC8+MOQ4lKKtLyyeN8zpE9z4RrCgJdjbl7zy8E9Jx36/SNGSyzwQkVsR4oxhj2WGjiUe WMhrqHnJWXjOsWb8+BKss0Sw2kstPXAwZMyVig+eVmXMm2UmoJSZVqkBIPYaTQK1EDSJYs6lDH3+ UdKCxunry9ZGByeFlahAFvu26is9L6txIwwW4JaeET6VAlzIGMqVWAQ2D60B8A2gQQMwd6l56qVg VPOBAfAz7+2pnfZIUJsFFBzlnylkU/yrPgYUU3qYNy5N5hY/CygwAEja2waNAAxN4YyYn94NQA31 jyLXNwApvPgUILMB/GJrguN5/0+7mjw1BShISGsAUsg3HkYGoHGkQ44QSijWcAVLbIdcloHkrbir fiCZVDYmmMAYTQHyip8rawMpb5Nq/FJdk+b23P143CAeBKj6IrDMhbz+fWR8FlBgALDHz2uSAZiw E613A2BqvpITqG8ASkcArIK9DTADUKz+UxrHEIin5HMywsgATEY9ppTC1l+ij9P6m9GNGr+WOCU2 hSEBGQC1hH4JjJcBMLmMvvPYAOQ9Tqd43ADxxIMAVQ2AjTP4RQI+ksCx+AXHmW8iq9QqKg2ztHHX rpTb6QncuxytpPsDtzAPB/uNP0PiBy/iHaU6zQZkPvSzRsy9E6+R5/E9pI1Lid2QxhfL5OU8ePAL p+YHU7H9EyEnj0BLJZIBaAmsok0kMHADkFiKKQ8mAzDMBjAEOVrDA3QxAuArLO+9vzUqdQjEa2R7 TA+RARjTiquabRiAePmvX5fsH0lUNfJpDi8DMM21P4SyD9wAYOYMH7/jX6c1BG6JeWDmOV7R3kcG oD22o8Tcuxytof5R3voGYBRYjRzbO/FGSjEukcgAjEtNNZJPzALCM158xz+ekYKOf//o0kYSmp5I 8JR9eABu01NqlXQ4BAZrAPxTPu1dXXkTbIKn7nCCTd7z/rlCoHSST14AzPbBTKRiQ4Jfg6eC4ij/ NmJkwPKMKUDWHuJFAilNRQYghVL3YYYgR2t4gPoGIH0NQEuVMQTiLRVtgNHKAAywUuIslT71xR+S 9zyWgZc0MduljyEaYDH9o4HG6PmSAySpLMUEhmkAIPQzn6qJneYBChR8qwaAwt2r9oAq1L9N6897 Hqg3AAhjy39lACbpJO1djtZQ/+Bf3wD0Xnm9E++dQJcZkAHoknbttCo9O39Mn+qTl20+HdLQdTbl Jki3Xt3Fj9LXQEE9kp0d5Z+LmvnE3s5ykpjQMA2Aranl8/v943TgAdj7XvCkTpoEPwJgj+bEF8RW fHgcAEdBo2PzGeO63vjj+/55oDcztvzXewMECJY1+1XCpVWpEYBSRL0EGIIcreEB6hsAjQD00s76 SlQGgOT924Lip4AXPycHU2hsMn1LTxCfWgNg5PGFNdWNAYjTrXeGxi+Ma/sVs95H5b3QmnnIfDMa DsG5AMh4e4B/NUFKtJkvp8vLwwBHQjDOlrlOpu0qq9e07KgBGgD/ilx7e5dX1VTepe/q8gYgplR6 eGYA/1DRzKd2+gcKwS0w3cwSBYMDnJikEYAR2/OgDu/dANRQ/wBY3wD0Tr934r0T6DIDMgCk7YUa pI+vAv/+XagZzPkOKsgkDt4w2lLdTacBCERnwQtim8WemW69JKxtQFWjOxlb28I3RakXGwCfZzO0 KdGOtQGIH5PlrcuQPcAADUCs9XH6eOVNV+AFOvZwua3vOA/e+Busx/WHWwc/NL3162caAJ+3TAOQ qfX9G8rMFdiLw8wJ4FgZgHqXymEeNQQ5WsMD1DcA9UYA+BSgRp4FNATiw2yLbeRKBoBU8YYsu98H T8OEHwieluMrwguj2Bs0VWXTaQCgyWxkBl/YId3BCEBmuki66npfe/EC2g8cZlONoTieFKUeGwCM eHAdM0ysb+3maVOibdAAwCnZ0uqWRtUCjKhc73zwb7BWvpvqq5HKAA1AINxZqECvB3t8b7pByFwE bKo9bwlB5suAg956vvE3cx1w3ou94hzaHssn4lxv2xnu1xSgGo15aIf0LkdrqH8wrG8AqlbActE/ O7P0qa3YBmQqTr+zd+JVCYx1eBkAVh80n9c9vk79DB+GwZiABfC6AS6ipcYwnQYAMIEaZcdmzDsw AJnp1vAevSzGSE80r1FBcPsZcRyySI+2Bqj4rKnU4Bs56eIiBwXpxofUKIsMQOZUnAKDgfCQ7P55 RB57DQPgrYitFpABqNGYh3bIEORoDQ9Q3wCkjwB46Y+3gOFlwNzoBPJsgAzAoJq4DIBVh1eWNk8j MAY0AH6OkO8mbK9mK+mhSlqtvTxXjTkx290YgMzMV006sURVQRWHT0+0oFF5W8vhgvRox9QA2ICD H6updN41W4/psQ3QAPhpNvboTD8FqGCRrp+W40cAuIQXmwnrvBlEmU8ZQlTWN891yXmE/RQg5hMf PwXIHh9kxgMBgmeGagQgvQEPOWTvBqCG+gfP+gYgpTIC6Q/1j23h/HnYYhsQRMiXEPtXEQd7eiee QmBiwsgAWFX6qT425RdTEfwUf363qQ7eHsSv0cWAAMSECQvE74cOkK51byM5PzXcPzWShxQIEXRM 2tQU5AGp+OlMeXOXfRLBwIXPlX8/gE8IhUKicZ8oe+ux+QPzihmcRJkSM44wU4WjCBYyKDIyiT2s BfLxa1vzTuQgXf7rp8dYgKBOGSHx+oUlSJ2H+BRLkQbobGJMwTub05X6MA0Aysj6svMOGIkuWD5R en4ZamBEvXuJnzhY57OR0mx6uS8M0AAMcxEwRLx1z+fN/0EN1lgETIcQPPY0fQTgiQce0FOAejl3 ShMdghyt4QHqG4DSEQCof/bxU/eb9KcBMBvAAHOBn/6RAShtc10GkAHwKsE0h0l8m/+Dnn7fLUo1 4O2BHxaAsAvmUlvMfp1AnlaLlVmeVvNZ8jOY7XueAfArm4O1y94IUccXvEUYoLwwigFSDZfmJy9Y HGFsALzhQXjzHshYPH2LT7kp1X9BunmPssH+zEW9vr6CY9neEpF6dH6OCuLMu0ok0i5wlYihxylA mc/hIUNrzInnFxFlniOIDc2+eFZP4N+6vCxXSmuABgD5L3gMqC2iLX2MT/pTgBBn8XNCObBQugKY 5IsfA2pvBfYjADjKD3FUGgG4d489ZAAqtfnOAvduAGqof8CpbwBKyULT+6k+Xvfbd7MHeQYAqQRO wMYEeideSmCSAsgA+Nr0qp37TQlBfHihSZXpJYL1BAdTqGPtaHMMRjQAecrGp5hnAJB5L469ILZJ TSg7paqf5hQXB7+aB+jeAAS0vfr32cb3YE1nsfhr1QCkIy1YeptiANCerdvbf+Gx3qU0sgjYvFCB iA/G0OJSlBqA9PMrOEPjposWntcM/KmNYJnjPAO5EQzTAFR9EVjmA3nSDUDmMoDYYCBXFtJ8SFyP VV8EZjFkrn4ubif3L1580/OeJwMwkLMpyMYQ5GgND1DfAHAEoOCvGYA8G1Cg/k33ywAMpLnLAPiK 8JIaasYrfgoF8wMU8WYYfCe6F5oQ2TgQgg/C1PeqUnCPYgCCh5NCzCEV7Az6vAsMQOaDj/yDazhY 4ZmgaMw5/vpi2rBGxwYg0IK+sF7dmivwfdvFj+UJCoIDsfkicw+2zJkhfHOzH0tBcgxfCWlgANDM UBbOd0oxAHkDF7EByAzp9XGBFbFjGzEAfNNz8FheoqMKTz+/fAvnY1hRWYjfnyP2fgnP0zeeApMw mGv4jHmANrJUSZv6DEBtB4/xwb/WfY6QDY4AJBoAJOqzZOsTMj1AMK0fhiGY1ROMACASlK7SIuCH zzvvf6+yyixuw/Nzx/TivLVx126j5UxAnL0bgBrqH9jrG4DSOjMD4Cf9c1IQ9hSrf28A8r73TryU wCQFaONS0urdqFX4XuVA1JoKMX1v0oGyIJ7Y43cG2iIW3KMYgMwVC4Tj9U2BUvQGBgWhuvJyP/A8 QT8owvtndDLpjg2A91SBoA+smjUbrywL2lJmQZpaBOy5+a7lGGkwBShlGnqKUmfBC+YpocHXeBFY IwYgzpufZFXp/Mob40ISBa/28wt7hq/+l510AzUArEr0pvP5/ZnP3Gz1et5I5MHLBxqJk5H87rrr 7lhzTah/GYAGqTYb1RDkaA0PUN8ApKwB8H3/tuoX8r9U/S+7Ws0tAn5KLmR8HwLxZtvQkGOTAQhq x8QZJIJ18FsPt5/0n/nUoHgCvY8/GDEYxQB4cRPMT0ifBR67CMsh3Uvxk+zjGVAdGwBLLlD/PtsF 0/cLZgG1ZwAqIQ0cacqVxB9iww42XmGjEIEB4FBGwfuw0xsVYq7qlOJy5S16qXR+WXHiN/T5E9kv WEdOajBPqZf2wgzcALRX8LGO+dEbb/zh2mtT/csADLYqe5ejNdQ/YNY3ACk1wacAmQ3gF1sTHM/7 93F6A5C5v3fiKQQmJowMQFCVmctGbYp85lNBOVeen4Inq8TCaBQDUKCxvMQsHgHwxYFIihc5FMu+ uLB9GYBgsCWlFzxv/e5TfRNzq06x2XLwGro2k14lpJVkN3OefkjxWnNf8ErR1gCVbgAqnV+ZrbGU UjrAgdwFZAAGUhHp2UDfv1f/MgDp6DoOOQQ5WsMD1DcApSMAVgHeBpgBKFb/KZU3BOIp+ZyMMDIA QT36rkEKCK/vA3HDAP6ZjHnPBWIqfnihQFSlPAXI974HPdkpjwG1Uvt4/BpozjbxKw3iR096s8Tw HRsAP5HDDwJ4Y2PP37QHdxY/wbNtA1AJaQ0xmn5I3MyCQQDfNZ4ebasGoNL5Ze05OIWRQz+SEDwS ChBswGTIa3/tFJYBGK978SOXXmozfzQCMPC6612O1lD/QFrfAFStD7MBmQ/9rBqbZR0FwAY3smDB ghqR6JBEAjIAAai4jz8Qvl46UO8Gz7w3EQzZ4Sdte71FtepFle/D9kKcE6Bjreaz4XMYPGGmeAQg yEPmjJo4MyTmM29TLPx8Gyu79xiJq1ctWOwo/NBHwSLgzPXZyDYOSXkVQHtTgJCHdKSVZHdcL8W1 n9mb7hW2b8CVctLeFCBvn0rPr7yGF/icWOXzXQSlz4pNvMa2HUwGoG3CDcaPZ/5w1W+waRFwg5Ab jKp3A+Alcfr3+gYgfQTAU85772+NmhgC8RrZHtNDZADiigueehlMEQ4ev2PLZy0e3y/OxZR8Y5EX x9Zn73dScwSPQcwzAIGIwVE4FlkN3j9QagCQ7fgpn37ZpXcakFxYDoFf8dfPF7d3IPjMgwNCBgVv 1gAg83kvAfBCFjlBrYEY8slso8iVHgPKyvU1y+n1KE5BJ3GeaE5HWkl2N2IAAn9i9RX4vcyni9qs Id8M8kIGp1VwGnpEqCykjj1slunnV7AUBFWG1oJ4/DkSj2t5X5Ry+vR+5ZcB6L0KEjPwq5mZ7734 xbH61xSgRIDdB+tdjg59BKDxKumdeOMlGnKEMgBx7QRPR4kfveIFRPwYwdKnvHvpE+jjeMVqngFA tuPZSvHhKQomiCdeMVmcST/3pjRLjRsAcMh7aGNxtv2L2+I2kDkCEA/+FC8kKJDviUh7MQCBp6LD SVxWQZKl7wEAt+KWmbmMm4dUOr+KG6R/hYW1gcC9DPnqzbzJAAy/jv7405/evc02NzzzmZnqXwZg sDU4BDlawwN0PQLQYP0NgXiDxRl4VDIAcQUVPGqQgf2zMv2bfS0qaJRMhceFtj7FTDUTPG8+0Li+ ez54vYCtSTD9mmIAgsGETGWMeII30XJ1RBx/XHBfnDYMQKA4/eNKM7Md10KiAcisLF8dQTyl631L kfZiAAKe7Nfv2AAgxbghWeNJP78QD864zNdyI/7Mx6pqBCBoxpVmpwz8ftdL9vCw/2DJr6YA9VIR NRLtXY7WUP8oZn0DUINRs4f0TrzZ4gw8NhmAzAoqXgXolwkWPJodXaecTMytYM4JJ5Ngg/jmZBXL gC3GDfb4bPPNUDycqVRdxeg1et6cFuTEEiqeIc159r7UKfnJXHxpBxo9viiKm3dcthNffBGCbBfo dY80Ttd+tcpCAYtjK11OWoq0NIa49aYfwreVcQuasf+JZfTRetTBd+bH11Fe4JT1tb4hoe3FmUw8 v3hG2JnIN4IVXJnZzrUGgIhkAGrfxJ944IF799gjb9qPtwGVILdx165dxsk+cAhytIYHqG8A6q0B aLARDIF4g8UZeFRtXErG90VgA6+slrJX/FyalhJVtCIgAo0Q0BSgRjA2HsmDp59e2vGvpwA1jr3Z CHuXozXUPwjUNwDN4qsRW+/Ea+R5fA+RARjfumsq5wUvTG0qCcUjAiLQEgEZgJbA1o4WL/nCjP+b nve8vBn/mgJUm23HBw5BjtbwAPUNQL0RAD4FqJFnAQ2BeMeNrMfkZAB6hN9v0pjEj7nRfnp0vPy3 3xwqdREQgVICMgCliDoLgMW+mPNzy4orpkt/vQm4s9qpkVDvcrSG+u90BGC56J+dWfrUVmwDMhWn 7cSX3onXaCXje4gMwPjW3Yg5z3vi0IjR6nAREIEuCcgAdEk7Ly1I//v22y/zGf8pZkBrAIZQiXEe hiBHa3iALkYAvPTHW8DwMmBudAJ5NkAGYFANXQZgUNXRWWYw798v/OUz+ztLXQmJgAg0RUAGoCmS 9eL5/W23ode/tvTXCEA97N0c1bsBqKH+Wx8BCKQ/1D+2hfPnYYttQFBPUJzYw7/8+D0aAeimWXv4 vi4aSd3fkPRdBERABESgGwKNXMDDW/b8hW1EOwFxPnLppZjrX2PCj9YAjEvt924ATM1XcgItjgBA /bOPn7rfpD8NgNkABpgL/PSPDMCgmn6rIwDd3POUigiIgAiIAAi0cXOpNDuljQwMLU7M9sE7fe9c d92CF3ulTPvRY0CHVrNxfno3AJV0f+AW5ubT+40/Y5nvKJ2+0PR+qo/X/fbd7EGeAQg6/v2/vRMf fqNsMIcyANINIiACIjAZBBq8NfxplHj+QngAbW0TSK+7Nu7a6alPVcghyNEaHmDUEQA+CyjzrxmA PBtQoP5N6MsADOQs0qVkIBWhbIiACIiACIhAKQHdtUsRNRWgdwNQQ/3bOEC7IwB+0j8nBWFPsfr3 BiDzu9YANNVwE+PRpSQRlIKJgAiIgAiIQO8EdNfurAp6NwCm5is5gVFHAAr4BlOAbNUv5H+p+pcB 6KzhJiakS0kiKAUTAREQAREQgd4J6K7dWRX0bgAq6f7ALbQyAoA0+BQgmwLEL7YmOJ7372srb/mB LQ7unXhnbWsICelSMoRaUB5EQAREQAREIIWA7toplBoJMwQ5WsMDtDgCYFi9DTADUKz+U6pkCMRT 8jkZYXQpmYx6VClEQAREQASmgYDu2p3Vcu9ytIb6t3GAtkYAPH2zAZkP/axRT70Tr5Hn8T1El5Lx rTvlXAREQAREYNoI6K7dWY0PQY7W8ABdjADENqCRWhkC8UYKMhaR6FIyFtWkTIqACIiACIgACOiu 3Vkz6F2O1lD/nY4ANF4TvRNvvERDjlCXkiHXjvImAiIgAiIgAp6A7tqdtYchyNEaHqDrEYAG62MI xBsszsCj0qVk4BWk7ImACIiACIiAEdBdu7PG0LscraH+NQLQWfMY+4R0KRn7KlQBREAEREAEpoaA 7tqdVXXvBsDUfCUnoBGAzlrIeCekS8l4159yLwIiIAIiME0EdNfurLZ7NwCVdH/gFrp4ClDjNdE7 8cZLNOQIdSkZcu0obyIgAiIgAiLgCeiu3Vl7GIIcreEBuh4B4MNA+RmxboZAfMQijNHhvJToIwIi IAIiIAIiMC4ExkhmjG9We5ejNdS/jQN0MQKwXPTPzix9aiu2AZnm1e/snfj4NtYaOR+Xi53yKQIi IAIiIAIioBGAGlKn3iFDkKM1PEAXIwBe+uMtYHgZMDc6gTwbIANQryHqKBEQAREQAREQAREQgW4I 9G4Aaqj/1kcAAukP9Y9t4fx52GIbENQTDAD28C8/fg++9068m4alVERABERABERABERABIZJYAhy tIYHaHEEYG6W/7I+fup+k/40AGYDGCBeEiADMMyGrlyJgAiIgAiIgAiIgAiQQO8GoIb6t2y3sgYA mt5P9fG6376bPcgzAEHHv/+3d+Jq+iIgAiIgAiIgAiIgAtNMYAhytIYHGHUEYOedd0atZ/41A5Bn AwrUvwl9GYBpPqlUdhEQAREQAREQAREYMoHeDUAN9d/RCICf9M9JQdhTrP69Acj8rjUAQz4ZlDcR EAEREAEREAERmAYCvRsAU/OVnMCoIwAFVRtMAbJVv5D/pepfBmAazpnpKeP9998/MzOz55574m9e qe+8807/Kw5BeHxmZ2ftEIThTnzhTkZrnzhyBjj//PPtJ3yPcxIHi/cgBmagjYpDcj6TlgSKDxRt pBjHaRiJCH9ZXqPtDznynHtte+h3T/Cna2996OTLflWa25/96g84NjNYYgylSWQGOPHEE1Ec/OWv KGBegyz4KSVp3yYz6aVEUiMM0oqTy2xXmZEjpAX2RQjavIcTt1s72Y2zb8w89QqadHyO83Dbz4z5 QgWXDtZscI7jPIrzg2z4nT5McPoXXLhKq8kfy4zZJ71t5DXIzBovzVKXAdq7ZnZZCqVVTKB3A1BJ 96MsPnwrawCQBp8CZFOA+MXWBBe/C8w//8ejt/29E9cpIQIpBHBbnT9/PoUC7nxrrLFGfPtnGPzE CBHguc997otf/GLsQYPnHRSH4zuC4YNfaQwQgAfyE+Rn4cKFCMlIeKdHVPiOPdiPXxneB2Nafo+P k3lIKXViGNwd11tvPZQlzwAAQrqAS0w0LxgSAkwqfvDhd3zJzMD8hbMb7X7rFvvf8Zatb1x7h+/R AyTKdwTD4ZnZSIyhRkl9nbLq2RozoxrRALChsnECYLrOq1EufwjKFYh1JJ3YYnGCIKt2uJ1TLIJP xXNDsCBFhOeZy1PPDvSnHsJkegCe+CjFtttuGzQ81Agj5MdUdXDpCM5xxMMMIMXMWkBa5gEsTOZ1 w6JKryPkGSVCbpE0r1c8oVgEUEppG8gMLw6ZJiSu8fTsdROy8WtmN9lWKpUIDEGO1vAALY4AGD5v A8wA6E3AlZqXAo8pAdz/eLOnaMBf3AgD1YWduBdCB9t+7mGRcXuGgkEMCGCSHTdjRItfEQw3V9xj /EABD6T0oXhFeEaOOy7vo/wVR+GDLxQH+Im3ZH+gJ8+bGYIhNuoG5IpfmEMLjDBI1LohWXzkn7oH f/GdIgA/4V8EZsZ8SOyklKT4QEI4hIaBufVJMGnmzRJCWZgQIyd8xoNjLRtGD/tJzASc7QlaIBQ8 xDp2QvrDCez+zbvwHd3/B5z8M3w5f/Z+eINtZ+689a7f8UD8hD0IhvBmAPAd4RmSsVkM/IKBAvyK 74gHYbDZaAN/YroMie+WXJBb1jKLyUpkxyRbBfaTEv5aSyBzEuav7CEmOsYfVKslau0He+ijfLNn VISMekGFWkV4/c0w1jCQNM8RNhifN+xnL7jZZssJUqfjZb+7nYaB/mbMzGqAjin6nQUGwNgiPJLw mtvcBVV+ppzl4Sx4oNcRnrVDVW38g0sH9vOcwhdeOvCFkHmInRE8bZEWLzUWJvO6gQApYj1AhwxT 5VuWAs9pwINT25oWArDUPNlZKLsIBDWOsrAerWj87q0L6CGMXUOMBnNuDZJtkrkNaqr0GsKj7EBv AKwUcVZ9zgOM+nf4BHo3ADXUP6jWNwBVq8RsQOZDP6vGZllHAbBhFfKCBQtqRKJDhkDgoovuec5z jlh33fMSM3PffY8mhuw9GK74/PCOQqViMovZ4ywXf2tkPxlCUhhRTvEOQVVBWYNjKW741jyzB1Zq 07X4CYcHfVFUNsEtmdH6Az1DxsA+OSoVxkwB4TNgXX04hPYDXygxEZj3YH7hHssMu/xNNSIVykfc yPETb+eULD4JZpKCAGGoG7CHX9i5i7+Wf+7Br/jC/k7G4A0A9lP45o0AULLjA7mPcQB8oSiHCoc9 wE4ocvyL/VDwCIA9tApmAKj+8S+++BgYFSLhLCN8oUPA4fiCX+1Axs+BCMSMyUW+vuw7WNExLs/w MhFpVU+LxQpivdhPNEKkBOwGky3HV5ZPl7WGCMmZPbjWE2/2AF8QA5Jme2Bg0rYwbBgck0E8bAYU uJY35J9nFqvb1xdCMir8StvM1hX0Z5vrC7Q+UjQr7mHSODEP/hCKe3yQHzMqcy1kWfFNuKM9542K 4Fia3kB3sgb5K/7yDI0vHdjJ6wa+8HQIMslKJBbmgcx9QYLrBkvKEmW2roKdbDZWFpYCyeHD7Fmd Bqc2jmITtZOdvhHZZmvEv77GrYXw0kSnFJCkt0GczBWybdcHegaGZwthMyMo371SfA2xy5RdIa3l Yw87g+Ks0hzygpY5NFQVu8J3TKB3A4Dy1vAA9Q0An/xT9ZP33t+q8fjSygDUoDeoQ7bc8gp0K//5 nx/60EN/LM3YPvvcvOqq3y4NNpAAlEG8uFuWuDPIoUku7Oe4gcl6KhjchHj7pwSnnOK9HF8QgHdT BOP91eLnrYg7TYSZLPDp8hYYHOjz6WOgYuAtmd7GzyfmzYzH4gvz6bOdZwDMYPBGaELQen9N0vkk mBDCUNhRA1nesIcq0+swUzy+UAhmHc80DLYnqC8bAcB+E/TeAECU418qcqh2jgzgXz8CgD1wC+y8 56QgxsAvkPtM1NKyXyn3eSACcAwhyKH/N6hl/uR3orD8l9LWfsK/RBpXPSuCbjBQLWyl/MSHW51S jbHi0EgQ0pqQhbFqQhJIiIqQR1nefG79iRZkm04GO+k0YlyBmp8jH1mFgFt8CGUrJaaZruDUy6sp akQOzoCA9wCIgSaHnQLelmRWLi8XpGEw/RnhR73snPIZs+tG3Fri/FNw4+NbAnay48P8EhOyj9W+ +X9mlb4rzwCYJ2QbYCTWMOwLmXvtjp9YI1ThngYvRwjPFuKRGj2WuvQawuozpAxPmBa5uQt+sUES n9uC01k/DY1A7waghvoHw/oGoPcK6J147wQmJgO33HL/W95yBpR9aYkWLrwM19KVVlpcGnIgAair 2KVE2YHbAzvygxzGd3HcDKjmqbDt9sMbDO9k/obBeyG723nHpS63XlV2gFnXI3vmfB8nA8QHWlZj FYif7B7mSxTcQQnBnAnH8fGBlGHR/I2cPbssoBeC7Nw1nRETC9SYzy0DZ+Y/UZwF9eUNgIl1E+jo 7Icix9oAKHWIfpoBi8EbBqh8jA+wmx8BvAGgE8AnNgAcHEA8HIUI4o8bv3UG8yf2nnrdTP/GjlUE iCV1JjoGs8qydAPNhP3+cG8AsJ/tje3WDENgANizzmEKmzcStBnfijJbrMWZV+NB+/GTYfLadnAI lSUD47ulyKjsbPVWJ4jZXEpBzEH+4xOB6tO8UHHBmZCvsuC6wRxm2gzLPBoYz+hiCWuRsELpcHgd 8Kc2L5L42FwdOxCtFDtt/YBvAza2gKhsBCCv4oI2yWZvEEoNgJ1HhGw1gi/0XdzDQuELhxrs5Aqy yqFUdvr4bpT4RNaeYRIYghyt4QHKDQDn2FTaMBunUvjagdEUNAWoy/PhjjsenJm5ldvdd/8WHfaH H37bzTf/hnnAzJyjj75jl12ux9+gLx//nnTSjxAYR1199S98JEuW/MT+tbIgGHYiPLwBYsOx+Akh V1gBs1pnXvCCY5gBhmfkSBc7bXbQr3/9e4sWKSLY8cf/EDF0ictuEtTxvCvgnhdMP+CvvAHgC4f1 eRfxs1l4a6Fk5xeqCt47eQv3d18ONHPaDKPlvZY6mN1OSMhLK/ayBwd6YryZcQKDv1kyG3n3Wpvn gzzbhB/OKCATZgzfDY710fpuMw6gI3UEZu8gb6j4zkhsj6VIjAhAl1LbALC/0BfQJDi1OxQ/frUR AE7Wx4af2MdPNY/9fgoQdnJkAH8rGQDGgwP50CEzAHE+mWfWMsdA6Ak9QEJmT226AYgry/jkGQBk z/crWzCb6M+BGsTDTlPrxmbFUV5bx3amAYjn9ph/5kQjRG5fLMMUajaDiCIeTLxhtsAsAs9EfsFP PCl4WmGPnZLYydiQW/YCmNq2dmsxs3cfcVLg+m4CTlTD4bwmsCDxpQM7OVPILDf28CLAVNgdwM5v ZozTjSxM5nVjruluuy3tOs+1eh8vrPHdpvfEpzZtHq8JSIsHItscUqC54qWANc6mwosn27k/2fGd lw5r+Uzarg/U8aMbAMTDngs2HsuGXdUJ32f129/+tvkcM7f18Oqovgj0bgBqqH+wSjIAlZhyOj7j bfXTO/FWSzfMyKHFcb/jdtBB33/+84/GF/bc4yfM47df8dPlly/v8vzxjx9+6UtP4E+Y5zN//skW 7Nxz715zzSX2L0sNmf6MZ3zDdlqXvw+JnTgWgbF+4IUvPM4C40DkBPthS2wnphi98Y2n4V/E0D1Y 6irOgbHblc8GduJWYR8qMKp8CmvTAbjVYY8JIN5mcCejYuCd0j68/wXR8pbJ8KZoLRIK6+DAIE6a BMRgSotmIOi48nd69uf5RCk0KYkoRCjmkCXuseJQLZEJtZF1HFoSdqcnaoThPAocgp/IJ28eC8Mg QHHD8MVhSOh1bujmt0d/UuhD90Og4yd0/1PfYw/288FBGBCwEQAuHmAw/IpgiSMAHFVg6ojfDECc TysX2BIF4LDqLTAhc3Y45Yv9ZCI79k5xZVlaJqTids42TBFpXyhAg7yx3n1/P/fYSRQbAPrGoDbZ JFAia4ds5z5v/kxhYELIaxgshT8LmBlEi5+YB8p9xoO/1jitbec1PITk6c8D+TFvgJgpgrEz89IR lIUnjp2tdmGxXPEEtDCZ1425Bv/Uo8xKT5aCU8m3T5pSXrWCU9uGMVlAhOGBFPe8CLBEvsbpvjJP dmtpdgllC7TrA/NswXw+g8Zc3IkAknbBoWHz4f0Z57NqbcZqtoChfhoggSHI0RoeINUApHfSewOQ flS9kGgHGgHo8mRAVzon4WD7678+il9gAKD1oezx/ctf/h4U+TvecTa+wwNwHID/Ylt//Qsw1cd0 OaJCBz8OwZQe7mRZ6BDQoz87+ytEbgYAIdH3z6R5LLr5mQ38izwwb8gJfsL4AP7lr5bVXgwAC8Uh 6UB2dFl37aXFLsP0+HnTJQrryUs/XCFFYFIJcFCFPdy21GH0wlKVZsZjg3IFYXj5yoth9OzFMUBz W/eEOsXbIKw4myXQuwGoIaGtp77oPQC+YClpyAA027AGGJspeAwCUOJvvPFF2Ilufkh2bKee+mOG wcwczMnhd4RhWQK5jz3bbHO1NwDs6YfWh2FAElDzBoE/2RoAWAIqfjgTpIu/HIXYfvtrg7Q23fQS mzI0QKTjmyX2kgaDD6XF4SpG9ub6bs7SAxVABCaYgPVw45zyQ3+jF5md6EE8HJSwXonMMDzE5qiM npOUGJBVuz7QEaUcpTAi0BeBIRiASmX3Ql0GoBK6aQ9Mse570/2sHrMH+LLTTt+BKOcezMgnuE98 4kov92MDgJUGQYToy+exgQGw4QifKL5jzMEbAIwAPPbYf017tan8TROwWUBD+9J0QRWfCIiACIhA LoGBGICUPno/a2akKUDopYjT0wjAxJ8lVNsQ91ZS0+UcAbANne5YAMDwmNLD8DYjyA4PRgBwFGLA lB508L/73edychHX7wYGgAdi3n+QLiyENwBYADDxlaICioAIiIAIiIAIdE9g6gwAVxrJAHTf1HpM EfN5ILUp6NGRj+/sWedMfSh1PGkHe6C/8VYvKH4+k4eP7oFMRzDr/sceFgSBOYMIGyJ89NHHKevR u4/DMcWIC4j5ICD4AXxHjz6fAoR1wOYuEBJLAhAV5v9g1hD+RWw8Fu8NwPeUlwzUY4vIueqg3uHj chQfcjL83PIZLIn5RMiq85cSYx49WKWCjJ7c6DEUw4xnmPQFPw/suLRwLmgevb4shhELXq8erRYa Lw7L1VK0I2LPy1U9hiNmRoc3RWC6DIA9Z0AGoKkGNBbxUOj7jRIfoh+KP/gJshtqHr9Cpvun+thD e1jk4Nk+eHqPDQhYhDiE8h3DDraTTwHye/gTpg8hV+YNgvBtcMZzhxYtuhErFtqIvJs4uRg3My3M waXu5xOEes9PaQZS1hXwiatUCZ0VKs4534fg9/uKSClIKY0uA9iDQeNE48faIExBeIthRG2a16Qz XV/B86DimmoKbMGpl5dE8Fya0XOS8iCsglQK6tGuHvHh1rwTi1O1ChKjHZ1eQRkzSx08UJjSP74Q VS3v6AVRDLUJTJEB8E8ZkwGo3WLG8UCoanTM+813q+NXPHCTffDosPfT7iHrsRPK3p4jhNW6JIB5 Pj5C9KPjWOzB8l/8harGgejaZ2A4CgwsYD+Oskf+owMeMSMkhhegxek60CUfZNUvJm4WPgYxsOHx R3G0lC/8a93S/JcPDfSHsEsMfxEAPzEMu/p8PLx/MCSfM00t5ZPATvxrKqcgNh7Ox/AxOT6F0HLI 1XjMlY0AIA8+fsu5FSqvjLbf8hZklUAy8+N7PRkPARolPnSPwoJFCBY4GisusmTSCM8vFn+QJV8v Vl8BgaA6girLrHo+lTJ42IsveGlBrBkwV0EtW1Ytb76MfCC97QnCEK892jWOOWhvTMt6MYP2wEph Sa0lWxjWYMDTUrSHwOS1KBxur9tjNiw2/uubCr4jXet7tqbOqvc62PMJaiqPs+XEqFoZmZDxtPMo aOq+pcVnChHxEf5sUQGT4kqMIzRQQcGDR/oW4y2ud7t6MJi/aMQGIK5i7uHFx58sAWGPwi4s8eM7 idcuC54223PexbYA9V577WVlJE8G9g7TXxyCVPAvn68aXIiC8mZeJO0E15feCUyRAUBRNQLQe4Mb rwxgJQAzDMPAEQCMD/ReBL65DBucg9kJ5AovIIPNgJPhvCN88AU+BBOQsBQBIfETrA6Lg+cL8Xvm h3dW3Lr4+GrKazw0EzqPD9T3R/EOxyf08wk5fD40DmE8OIR7eF/k24J486C64lt++Gxs3looNTJj 87nyuhNH8UC+F8lub6YS8IXP4fbxcw+Lhuzx36CM3M9XgDHncVYJJNDBHoURYwzUQywmn3BPjEid D7bH/oAPjvIGAMGYTz7oMLN0Vi9MPQ7jq8PCFFd9igEoLgjp5dWygSJtlBEhWUbWFPbzpapExDBs KgRuz3cK2o9VPdubT4hNGn99e/AGgK2I5aLoQXjbYymy7bGAfElZ3lkTVK7Fxhca8OOfN89EC86L mE9QUwENSyWmahz4GhCiRnH4Gi9+gqZuLS04U3juIDDDA2PMpKAS41PPg7JTG6cG38nl69RfWzLx Wj3G9e6vHvFFg7WQVxw7y9hWvQEwcc+qzCtd0DitCbFtBNfbgottJmpefrfeemsro71/MBgT8BcH 5pwZxn5WmV3P7ULkm1zeRdLqSF96JzBdBsA8gEYAem95w88A1D9m7UP3Y3IOV/RiQwd/vznHs0qR K4xIoPMewxFc0wxxD2fChwhB8SOffJ0ZxiWYbQwj8J1iKAgCc0Ezvuc9ZYh3Vt5QeemnsMa/8SPw KSzwE0Ut+7N59/Xx2Dsy6Q2obxiGrzjlTQV/2ZNXHBtz5bsA2X3FOy4/vE9bGPoQShkkxFsp9/Ao pog9iCcY5WBnmIm2IKvWJCwtRsVIgieC00SRJ9/8lZmZmI/VBTPM6vCl45tEmTeWjvVin5gAA/vC plS9Kae44DHVvIrOq2WLMy4j8sluXarJmAMLwqqP2w+9BH/yWLwQ9O3BGoZxpjKz8GztlqKVFNlg +2eDoblFYJ8uHQIOoeFk5bLF2sd+Yh35cvmmZW0gk0/euWmpxEfZeYEvdr6DedA9zCoIWlp8pvjr BttnwCSoaF+JJO9PPQ+KBacx9qKZFVGKt6De7erBS1NwWrGa7MIYFMf0NC9Q/mQJDEBe6QIDEFx4 /fU2bgZ+TyZqO9+tjHY9REFsOJHt3AIz5zyn8Ne+xCeplTfvIulbuL73S2BoBgAP44k/Xq438BhQ tGAZgH6b3VikDqkdvKzXP0Go3SLccgsmx+DdwkEqmDUE1c53GGPqDt45ACeA7xT0mLCE73zGKLOK MBy1wFx/vuUAZgYehisNsMo5rxReWNt9ztRkcLsNpDZ1Dz6BQGew4HbILkZ8qLl5O0H8nOxOSZQZ W2wAED9uvbiZIc5MAxBbAttjuUI2sBORs3+LfNiRBjWGLFFBBlk1jMbNA7RUGIy3W+xEGBoe9vfH mUE2PB/THLw3szosISsycfkILXsxAV8dDJZS9cVHlRaE9PJq2XIbl5HNg3LQDEDAwQoetx9UKIeG aPPihOKcx3nw8GM9Z++CZRXgrzkBfPfqyo61JGIVa8NEdAjMXty0bE8pH382+eIHVI0D2VLR+jMi aCcWPj5TgvPdDIDlhL3IeZUYR+jPAhacLZ8nkX1S8Fq6cb17AnbhCk4rbwB8cYLzPSZgVVlcOpYl PtyfxQyT1zDi5udj8/nk9Y1DPfF54ZmTNj70V5knKWsz7yLpk9D3fgkMzQAgP4EBIB9T7A0YgMxn juoxoP02xMGmzsfy2AM6u8jn1VcvfcYz0L80t+20k0+RK49taQF/wiOM/Nwk9vRzpIKjARD6GM3g GmX/HXvyihOrQKpV3K35xfcZB7d/BMCv7DZjPDYXgt23vD3YfQtfOPQMYUdZxi493h3j2HisNwA2 UsGE7BbF2Lw8wk+8LTEPwY0fegvZRgAU06sxxsD9lOxBVg2jhWTmreC+S49dqtSv1KPsWC1QITY0 T5gIXHDfRWyBo7Ds8ShPIMUAxFVPoekbjxU8pSCkl1fLQW59DSLzrFPO88nkYBmI2w8TJXZrhD6S uAqqGgBaC8pBf7Jwildw1rAslmhsAPArJ2z4cYa4aXkTGPOx/uPgbDLOMVUvfxGMwxcpNR6fKbS7 HGSwc5Z7jEmBAYgjtHPfGgbiYTDvr6xQBXiLDUAwFhSfVqXFoXHyJwvPX2TYBj+DC4svHSsIh9uF l4H99dZfYeKLrV2rY9RseGaDeUJ5V+zPC3+9tSlAyJi/kgQuFIfEF0lezP11Q9/7JTBAA+A9AOE0 PAIgA9Bvm1PqJQTQlUX1j+2FL7TAnM+DQYngcLoCvq8A03swRICND/fk24s5YsCnmvrvnCaU+YkN AILxJgFFQjliH9+ThIu+72FlPJywYfPaTXvhtsT+fmoj+9c0cWZsTJd3X94OrSuO2UNC7NG0jnaK RQuMQzgZIxB89C0IzP6woIzMJ++acVYZ2OeHGeD9MoDMeQXYSVXEm2KsPgM+VgXUl8RoNWWZB4Gg dJZ6TCDFAMRVj/hZy3HMyE9pQViuvFq2OOMyUk2ydsitQDsinqD92L9cdBEnNKIBYLnYSDgnnuiY Zz9/BvuNIZqrOVhvFJk96j9+t+wFTcvaQMzH11RAw4ofHxUYAISMm7Fv6v4KwPPRzhQca6e/OZyA SXElxhFaPP4yhWB+ECAFb4EBsKtHwWmVVxwjwwl+vgqQIuH4BTABrsAH0j/wOhn0FLBerGrii23c /Pz5bmVka0T8eVPjEIC54loLVi7Spb0JLkRW3vgimWlxg2uj/u2SwDANAD0AOQRyXSMAXTYPpdUH AfT6mwFYaSXLAefz4BUBtocPDuI8Jap5PvAUi4Pxne8y4+uE+R1rBjCgYfvhFtp+07C/Q/eBUmmK QHcEIIY4goQkqba7S7u1lFAcGwJqLRFFnEsgtuh5QWtfbLl6KqW5cvESM8CF3aq5sSYwWAPgM6YR gLFuY8p8RQIPPbT0jW+c8wDPf/5STAd66sPefXb2Y1YSnijKJ3hyBADLfDE1CGYA6wEo6/HSMezH k3/wHTOC8B0vPcB3ThnCgIC95Lhi/ioE59BzhQMUVATGloCNSLA32s9IGdsyLX+NRjB8Mb7FGbuc 20Sa0pzXvthy4VPQ/Z+ZHFfRcASAU4BKc6UAQyYwZANQOlUnXMsL0Bw7wEhTvJggc32x37lgwYIa R5VGGwTonfiQm6Py9icCsAHRB4/+hMSHDYDKhwfg75D+WOYLcY+Of/+QIiwAwJJfrP1FGP8da4Wx TgALANp7x7DqUQREQAREQAREYMgEepejeT39meqf+pxCHVSLDAACDfPTO/EhN0flTQREQAREQARE QAREoG0CvcvRtgxAnoEYwn6OVJibabuOFb8IiIAIiIAIiIAIiIAIGIEhGICqk2hKRgAGXru9Ex84 H2VPBERABERABERABESgVQK9y9F683SKpgANoY+/OA8aAWi1TStyERABERABERABERCBAgKxARi+ fmYOUaiMNQClbxJutnhVBy8QvnfLpfNBBERABERABERABERgmgmMtRwNDQAe/pP5sR73ZtW/PXEo L93M/WNNfJpPFZVdBERABERABERABCaDwPiOACDnoQHI0/dtG4CqvsLyw0caTUZLUilEQAREQARE QAREQATGgoAMwNx0otqbvXOgUgwyAGNxbiiTIiACIiACIiACIjCRBGQAnqb+/aSdFE0vAzCRZ4UK JQIiIAIiIAIiIAITTCA2AJUmtPcYGJXS5BQglmTp7Ixt3FNsA2IDsK37lE5J0hSgCT61VDQREAER EAEREAERGCaBTANQ49k2HR+S/RSgUsGdGcBL/5mF87nNziykEyj2AIEBgPj31Yx/M1NEGO6XARjm WaFciYAIiIAIiIAIiMAEE8gzAAMvcjMGIJb+C+fP4wYDQA+QbgCWq//Z+UttW7rUDwist+yjpwAN vG0peyIgAiIgAiIgAiIw2QSKDUDKDJ9e+DRmANjNz15/U//8wv3pBgDivpTF7ML5MgCllBRABERA BERABERABESgPQKlBqAw6dm5afOYi8/58x1+GjMA1tMPue8NgLmCagbAd/8v++4tFP6VAeiwkSgp ERABERABERABERCBDAIpBmCNNdZYNr1lNtggmZdL/5mZpQvnvneGuGEDwDk/HA2wvv/S7n97ERgn 9C8fAZhFPJD+c39BBOzwfWZmBl/wrwxAZ01ECYmACIiACIiACIiACGQSSDEApvuLZwR1SbhhAwDd z6EA2gDOCKr6FKCnDMDyNQBPqf+5f89f9oEHeO5zn6spQF02FKUlAiIgAiIgAiIgAiIQEKhqAILD lz05E5o57P63SUGBZ8DhsYuId5ZWUwMGwOeDup8GwNR/6Qrg4hEAxI+Of1P/MABwCJxQhOLpKUCl dawAIiACIiACIiACIiACbRBINwCcw4I83O8+NADxGoDAAMQ5Dw6puoqgGQNgK4CZvBmAZaUqXwGc YwD+NALAjn/7yAC00YIVpwiIgAiIgAiIgAiIQCUCoxgA3/0fLAAYDwMQrAC2MYHEFcClIwDwTF79 00JpBKBSA1VgERABERABERABERCBZgkkGIBZmx5vIwDBNB6o3GID8Cdp/VTuM0cA4mB5hW1mBIAF K1gBvOeee2a+yct2+heBcQ0AlvnahvLw2f+Q/ssHUGZnZACabcGKTQREQAREQAREQAREoBKBUgMQ T+K3GUD8Cf+WGoA4S4OYAmQjAJkrgKH+KxmAgFT8Lx8zKgNQqYEqsAiIgAiIgAiIgAiIQLMEig1A kFY8AkAzMJYGACW3qf/xCuAU9R9MASoeK+CvMgDNNl/FJgIiIAIiIAIiIAIiUJVAPQPg1wG3ZADi VQR+0KCBKUCm1+MVwInqv4YBYKKoJD0FqGpLVXgREAEREAEREAEREIFGCNQzADa9JXEEIHENgC9R dwaAWtyymK7+ZQAaaYKKRAREQAREQAREQAREoEsC9QxA6QhA20VocgQgZepOXhi/CDg9Ho0AtN0+ FL8IiIAIiIAIiIAIiEAeARmAue7/2hsNAP6mfzQFSGejCIiACIiACIiACIhAjwSqGgDO+I8/wWNA 2y7RsEYASp//4wPIALTdOBS/CIiACIiACIiACIhAAYGqBqBA63bJuZoB4GT92t38BfN/NAWoy1pX WiIgAiIgAiIgAiIgAqMTqGQARk+uqRjqGID0WTrpIflm36obKOgpQE01BcUjAiIgAiIgAiIgAiJQ iUCmAagqaHsJj2JWFt+V5uqkBK5XchmASm1UgUVABERABERABERABBokMNYz0isbgHp6vfGjZAAa bMGKSgREQAREQAREQAREoBKB2AA0Lnfbi1AGoFJdK7AIiIAIiIAIiIAIiIAIzM1FD/qj29Prjccs A6AWLAIiIAIiIAIiIAIiIALVCIy3AUhfrTuckGM96apa41JoERABERABERABERCB4RGI5ehwpHJp TuYNj2d5jmQAyhkphAiIgAiIgAiIgAiIQGsExlqOagpQa+1CEYuACIiACIiACIiACEwogfGeAtT4 qoJuIkRb0nsAJvSEUrFEQAREQAREQAREYOgEZAAqv8ZrdJMgAzD000L5EwEREAEREAEREIHJJTDe BqB0lcAAA4z1pKvJPRFUMhEQAREQAREQARGYFgLjvQg45WW9QwsjAzAt55bKKQIiIAIiIAIiIAKD JBDL0aEJ5qL8jD4bp5cYNAVokOeCMiUCIiACIiACIiACU0FgvKcA9SLfR09UBmAqzi0VUgREQARE QAREQAQGSUAGQIuAB9kwlSkREAEREAEREAEREIF2CMgANGAAKlWN1gBUwqXAIiACIiACIiACIiAC zRIYIzmKxQDB7JuhvAgMVVJpXpCFx0OKFixY0GyNKjYREAEREAEREAEREAERKCAwLiMAkMrlBqC4 piG1K8n09MAU9ImPHB0jy6UzRwREQAREQAREQAREYPIIDP8xoKaukwxAnmpnX3u6pq8U0mex9CFK MgCTdxapRCIgAiIgAiIgAiIwRgQG/hhQy17qCEDvBiDFOdAwcNBAU4DG6GxRVkVABERABERABERg AggMfwpQ5REA9sFTYdv3zkYAZAAm4KxQEURABERABERABERggglMoAEw3e+dgAzABDdiFU0EREAE REAEREAERCCdwGQaAN/37yfbpHTP1whTMEiRGRvDawpQejNVSBEQAREQAREQAREQgaYITKYB8Ctx Sw1AIyip5uN1yn4mko1IyAA0wlyRiIAIiIAIiIAIiIAI1CAwgQag0hoA0+I1Ov6DQwoMgNkAfpEB qNFSdYgIiIAIiIAIiIAIiEAjBCbQAGRK+cw1AA2q/+IRABmARhqrIhEBERABERABERABERidwKQZ gIK3ccXvAZABGL0BKQYREAEREAEREAEREIHxIjBRBgASv/gTDA7IAIxXY1VuRUAEREAEREAEREAE RicwUQag6jx+GYDRG5BiEAEREAEREAEREAERGC8CU2QANAVovJqmcisCIiACIiACIiACItAGgYky AAWAtAi4jdajOEVABERABERABERABMaOwKQZgLxZQDIAY9c0lWEREAEREAEREAEREIE2CEysAYDi 92ZgCAbA8oOK1JuA22jNilMEREAEREAEREAERKCUwCQbAO8BahgAe6Jo4tri0heByQCUNkcFEAER EAEREAEREAERaJvAhBsA8wBVDYAdeMkll+DVwikegAag4EUE/ElvAm67TSt+ERABERABERABERCB AgKxHC1VsF0GsOxldq+HuhzlNKXOXLLkfE1vylOAoOGXbXMfSH9+eUrWz+0vcAIMWdraZABKESmA CIiACIiACIiACIhAewQGLkdHMgCm/hMNAAT8svQg4pdrfXqAZQZg+U8FowEyAO01U8UsAiIgAiIg AiIgAiLQFIGJNQC+YIkGwIQ+w/OvDT0scwUIkjsdSAagqUapeERABERABERABERABNojMMkGoNJT gJ6a/DOn76n78cWNAGA20TyuB8jzADIA7TVTxSwCIiACIiACIiACItAUgYkyABTueZ/SNQA2z8cM gFsDsHwKEOcIZXoAGYCmGqXiEQEREAEREAEREAERaI/A5BgA6PvST7CEF1jdouG5GT5+rj87+/lB 3z91P8PIALTXIhWzCIiACIiACIiACIhAqwQmxwCkPKmz1AD4ZQBcDeyWBcsAtNoUFbkIiIAIiIAI iIAIiEAXBGQArqErYE8/Rb/19C9bA7D8Xy4JsAGB2G9oClAXDVZpiIAIiIAIiIAIiIAIjEZgAg0A gXAVr/8eS3b8+vSFwk9T/5wORFdgS4TzVgBz6fCywCWfgRMvy75+FwEREAEREAEREAERGG8CA5ej lj17GqdX7NlP5KSsNwNg3ysZAD/dn73+BbP/GbMMwHifCsq9CIiACIiACIiACEwHARmA5VOA4hk+ 7Ptnl3/xA0BlAKbjZFEpRUAEREAEREAERGASCMgA/MkABEME7PgvmPMThNcIwCScECqDCIiACIiA CIiACEw6ARmAXANQ9bFCMgCTfrKofCIgAiIgAiIgAiIwCQRkAGQAJqEdqwwiIAIiIAIiIAIiIAKJ BGQAZAASm4qCiYAIiIAIiIAIiIAITAIBGQAZgEloxyqDCIiACIiACIiACIhAIgEZABmAxKaiYCIg AiIgAiIgAiIgApNAYNoNAF8X0MimRcCTcEKoDCIgAiIgAiIgAiIw6QSm2gDwRb8Q7qN/9CKwST9T VD4REAEREAEREAERmBAC024A6AFG/8gATMgJoWKIgAiIgAiIgAiIwKQTkAGYm/+DWs6bBeS9QV4Y Hq4pQJN+sqh8IiACIiACIiACIjAJBGQAcg0Apf/SpX/a8l4MLAMwCaeCyiACIiACIiACIiAC00FA BiDbAATSP7ABwVCADMB0nCwqpQiIgAiIgAiIgAhMAgEZgAwDkNnxX+ABZAAm4VRQGURABERABERA BERgOgjIAMgATEdLVylFQAREQAREQAREQASWEZABCA1APPknXgyA0QB8bCKQRgB0NomACIiACIiA CIiACIwLARkAGYBxaavKpwiIgAiIgAiIgAiIQAMEZABkABpoRopCBERABERABERABERgXAjIAJQb AL/8175rCtC4NHHlUwREQAREQAREQAREwBOQAdAiYJ0RIiACIiACIiACIiACU0RABkAGYIqau4oq AiIgAiIgAiIgAiIgA6AXgeksEAEREAEREAEREAERmCICMgDZBgBc4qd/ck/wGmAjuPPOOy97hGjJ Z+DEy7Kv30VABERABERABERABMabwMDlaKCuA+2docX9AcH3WLgHD/LPDEDRnyf9eQiaAP7KAIz3 qaDci4AIiIAIiIAIiMB0EJAByB0BKDAMwU8yANNxsqiUIiACIiACIiACIjAJBGQAZAAmoR2rDCIg AiIgAiIgAiIgAokEZADmDMCImx8BSImK4TlraMGCBYlVpWAiIAIiIAIiIAIiIAIiMDqB2ACkKNgu wxSo68bWAIxYHmYxsTIGbrkSS6FgIiACIiACIiACIiACY0pgLOSorbBtaxFwIwYgPRKNAIzp2aJs i4AIiIAIiIAIiMAEEBj+CIBNlomfwJk9AoB5NfzQN9j3dIFeNSTagSVU+mUsLNcEtGwVQQREQARE QAREQAREIJNALEdLFWxfAVINQFX5Pnp4/6jQ0u8yADoVRUAEREAEREAEREAEeiQQy9FSBdtjgKQp QKML+rZjQH1rEXCPjV5Ji4AIiIAIiIAIiMA0ExiXKUCZmjx7ClDb8n30+GUApvmUU9lFQAREQARE QAREoF8C420A+pqNNEq6mgLUb4tX6iIgAiIgAiIgAiIw5QTGaA1ArLrnjWPlyQCMY60pzyIgAiIg AiIgAiIwMQTGWo5qCtDEtEMVRAREQAREQAREQAREoCMC4z0FaPTp+L3EgLrVIuCOGriSEQEREAER EAEREAEReDoBGYBruvcAMgA6DUVABERABERABERABPoi0NIaAC9xR1kxW3AsktAUoL6ajdIVAREQ AREQAREQAREYVwItjQB4A9BSD7sMwLi2OeVbBERABERABERABESgRwIyAJoC1GPzU9IiIAIiIAIi IAIiIAJdE5ABqGkA8D7k2kMbfnxkwYIFXde50hMBERABERABERABEZhiApNgAKDFg08NaR4L+mKJ LwMwxWeNii4CIiACIiACIiACY0xgQgxADcUfHCIDMMatWFkXAREQAREQAREQARFIJjDJBsAPC1Du U+Vzf7oBiOPxUVmEpWMCFgC1o/cAJDdRBRQBERABERABERABEWiSwMQagECOF0h/7w28K7BD4p15 XqJ01hADyAA02YQVlwiIgAiIgAiIgAiIQBUCE2IA4jUAeQYgb7JQvJAg0QBk2oPMVDQCUKVlKqwI iIAIiIAIiIAIiEArBCbEAMSCu4YByJwUlLfCuNgeyAC00loVqQiIgAiIgAiIgAiIwMgEZACWPwY0 b1VA3qweGYCR254iEAEREAEREAEREAER6IGADEA1A2B+IGWCUN46Y9SzLQIe/flFikEEREAEREAE REAEREAEKhHwchSvpap0bF7gDiQuklj+JJ+CTnqbwJO30tcKUPBcoOKnABX8GhuAYBFwD45PSYqA CIiACIiACIiACIjA0x9KOX4GoJEc14ukeIJQ6QhAvUR1lAiIgAiIgAiIgAiIgAg0QmDnnXceyxGA RgpfL5JMA1DqCmx8pF6iOkoEREAEREAEREAEREAEGiEgA7B8PUA6zdKXf/moLDBA6yMCIiACIiAC IiACIiACQyCgEYDKHiDdLTAkEOsjAiIgAiIgAiIgAiIgAsMh0NSaCMrdpmLLjGf5IuCqElzhRUAE REAEREAEREAEREAExpHAvFbthSIXAREQAREQAREQAREQAREYFAGNALQ+YWkcfaHyLAIiIAIiIAIi IAIiMKkEZABkAERABERABERABERABERgiggsNwCDGpWompmmll1PqsmbwnJVbUIKP0YE/Pk+nIVf yknjBPSs5ym8dKvI00BgCI/rmeY82KX1TwZgTJtdgw9eHVMCynZMQNJhUltFcL5DdE7zdXyCy44G rLN4Us9ilWvKCeDCNeUE+i3+VBgAdmqqqfXb1NpOPbOWJR3axt5X/JkGwMQi611/J4lAXy1N6YqA CLQkoqTK+m1a02IAQFlNrd+m1nbqbMpBLcsAtI29r/gzDcAk6V2VxU5encV9nWVKVwRIIPP2Ojoc qbLRGY4SQ5EBuPXmq7H95tTP/vb4Tf/rpE1/v/ubvj+z/c2zl4+SXnvHFkwBGrHtzl5/zemXXLHT RXdg2+eC7x9x2vl5pdh553k1tqpM1jzugWA758xTZq+5pGo8Pvxaa631heWfz3/iE5+o9FbmUdJt 8FgZgAZhDj+qxBGAbbfddlHZR2MFY0Fg+G1SORSBSSVQKqKe+ZKPJm4eUbMG4LzzvmPbXsfdyG37 7b+DbXSNNJE1m2sAbr3p6l+e/YUnjnjrkwes/F9HvnXpCes/tuXzbnrLMy9cfNTJF33lgusOvvr6 U6757nHn37LLiNKzKawNGoAzLrjgyNPP3f2bZ3zusFM3/MYl219512cuvOuLp1yK7ejzL9/+zJtO OfeizGzXUP84JI/A4Secf9pF1xy0+IpA7h/x3Ye/efPD2PnZC59YZY/bsX1uh8+gfZeShKznByHt O768+93vnpmZufnmmx944Mjzz3/Os5/97NKoBhhABmCAldJelhJHAGAACpY1o9njs956642FAp7O MQGrmvbakmIWAREoJjAWBuDAs65addVNgo0GIFEjTVszKDAAVz347Q8uXfTCpXu8aOni9y09aMGD 7/8/T/23/7Xeh960zXHzv3LV/GO/+86T7l79K9956TlnPU16emVpcpNYg39rs86MZ3QDsOSiC/e/ 5EZsB9z+iy/+4rEtf/H4W2d/u9aNf3jXqXd8eJ/jvvntJdiQ553Ou/WEsy8sMADXXnvQXXddhu2m m44+4YT3eFdw/PH/gZ389dprD+ZPmVG9/Iu3Uffjy3E3PIjt4tseXPrkE37DrzQAm2z0/lMWH1PA k8Q22WSTAw44AHIH3//2b/8W3/nZbbfdLrnkkkcf/fq5577sn/5pXB8IW9sA+BZbu01WPbDfMZZe ilwVUXH49BGA5Qbg8QeXRhsNAPbLAwzfXTTbfhSbCIhAOoFxNwClGikdxSSFzDUAd1x/4e+PX/2J g1/15H7/uHTJpkt3eeVP3/kXX3v7q9665es+/60XffGyZ371nmcf8/izdr7w/zr7zJOMSCzN/Z4h G4DTL7zoyJvu2O+OR7B99ZZfLfzez99286OvPfuhFU/6zWtOvn+V4+7bYLdjsC066tRzL73sO9+5 qsAAQNwD6w9+cM4pp0Bwv8wbgK985aUnn7wxfkKAn/zk8mIDcN5vlkL9P/nEb22DB3jL6Y9je8MO s9yZbgCg/i+99NJ77733/PPP33HHHaGfDn7qc/HFF//qV3ufeuqrX//6cvX/ZxU/nZ0tNQwAGuTz /+rZi7Zcx7ZVXvWiglYam9vaTbp3AxDUix8dMq+eaebzIMQjS0GccYqjtI3KIwDL1P+8hbPYzAlA 9+Mz/6mPdTanqGGWLiVk42EMbOMxVyLQTeqWpVFai44VAREYhcAADUDmhB/O+fGDABwBqGEAMu/R tfvOfGyZ99Di2slUGqVapbTG8w3A1Sf/YY+/emSPv/3Zbi+994DVHln/GTe97s9hAN617Yq7n/0P u88+66v3POsbj/zFbt986/HHHMFkSrNYWy1lipVg54gjADMXX7f7lT8+6zvXY9v1hp++4fSfvGTn JS/d//pXHnnPKw772UpH/vL1x/0C2/s++5XTlpyVh5WCHgYAEh+d/YsWPWe//V549tnbXHbZImzn nPMZ/Lv77s8+/vh1EKDUAMyp/8d/je013/w9Nkr/3z229J6Hl84ZgMd/TfWP7asv+fuvH/KVgrlY IL/GGmuccsopP/zhD3/0ox/dddddt9xyy+GHH/7FL37x0EMP/elPd33yyZWvumreokVz27bbzlVU Xhmh/zfffPM9yj+f33zz9yJwaRNsKkANA7D5uv+24/+35i1Hf+LeM79435JdsH3jcxti5+qve0Vm rhpU7Q1GVQNg3qXNO/mUaON40suVHjLHbO8cvAeA00kDVTpv3s4U/bZB/c9fuPShhx7Cl9llHwwC YKYQnEAlRWtXMx7VmR/wrqMvB9KLT0hpkAojAiLQBoEBGoDMCT+Q/u0ZgOCelX4LK5W+xVHZr3EG 8g4sTZGNJNcAXHrul07YfbMjPr3Jh7fcbsONFm7z+pfs9Y/PfP2H/9fHDnzx3pf+P3t/71nfuP9Z h/z6z3be94PHHvWNAgPgJUXge/J+CvbbzZVFjc0Tww/HANx441Ho5of6P+igFZYs2erCC784O3vo Y4/9/uGHf3nFFV866KAV4QEQAHOBikcAmjUA8+a9/N//fad99jnmoosu+tnPfnb77bcfccQRmP2/ xRZb7L33Cw8+eN5VV6385JOr33PPvN12KzEAl112GQ6/++7bnnzyvszt1tkfX7L40tOP3nGYBuA1 L3vBO97wqj22eOePT9r+e0d+fGbh/MXbrXnS9m+7bP+N7jp5h/vP33PJ/psjwGr//PLYeTZ1bU2/ djSVoo9nCAZgxHIljgBUMgCVdG2g+AM/UMlLVE3XwrMe20trCDH7u9SIbUaHi4AI1COQYgDi1VZY Fsydfn2wz8Aoi4DbMwAmMktZpdzHTbjmxVYaSYEBoCTOFCql0RYZgGO/ffU7Pn/3Wjs9vOiEP3zy oEf+Zf07/nXdLf9lg1fufOIrd73mOfvd9Zdf//1f7HHTc3fbfbuTv7V89nkptUxTEuz0/+Zp/cx4 RjEAXzjlki9d93PgOPCGO7C9/pQfv2ztj63wpnVXfvcWL9luyQpf+/k/HXLvvx7zELaVtjxyj4OO vOqqSzPrkoIeff+Y+bP//i+64op9b7/9TOyBGXj00Qd4Jlx55ZfwE+YC2fKAzKig/m/66T1PPnYf No4A4Fh2///wN0vZ8T97z9JbNvoHbA8vWunclZ97zFGHFrSwefM2hRh69au/8LGPHXDIIaedeeaZ O+ywwworrPA//sf/+Lu/+7s3vOENhx++4913b7PXXkXqH/FD08MAYNzgqKP2+/nPL1i6dDbezjvx vP0+sv9hn1l7aAbg5f/w/Ff949+dsNsHfnXO7td+9UMHf/DV+234yn3f//LN/vn/WDh/3pEff/05 u6976X4b3nnitn+86sCbj5kbCinVzQyQIqlTDLAlF9hdv7/0RKt32fJFSLl2FFx6SjOQRyzlQIZJ WQOABr8Q3fvo45+dnT9/blu4dCmGAtj9j7+/XPbhIMCIIwBdamXfALpMt9+00tuGQoqACDRLINEA xA8CGkcDUHBPz5TaKRqg4JZaerft2gDcfMPsFw781TrbL/3kV5aeeMnSHQ5e+q/veuQt6x352b3e jG3Pr//nHse8/aBvrXnwzPsWLfr8OUv+tAg4T7IboNKiUhl49RO342YNwFVXX/7po+ee7Lnt5Xes dtXvsL1i17P/8a2bM92NvnDYSrtevNJX7/uXQ+/H9rq9b3jrxtsed+Kflj347Pnp/uecs81DD/0i NgAYB8BPPmSeAfivP/6EGw3AH5+YU//3PjKn/q/92VKo/+NuXv4UIKj/d7x9zUW7fb7UAMx1iM7b edVVD4AB4NtDn/e8522wwQbXXnvKffd9Yo89StS/GYCZmQO3337rCy44KtMAYOev7zh+aAYAZbvz 1F0fu/qgi/ZZ//AtV/36Zv+8aN0XQfcH21c/9JoffuuzPzllxz02+KemDECeR491sD/VC45Kv0Jl NokUu5Jy/yjNYUEkKZeCgsNLRwDQzmdmIPhn/Lx/eIB5s8s9ANU/Pvfeeys8QOY64OCC5hUwf7I9 dlHCnuAKFoREoSxMENLPJspU+aX5SfEGPpK4RHEMln9/YGYp2nAITCilNSqMCIhASwRGMQAcBzBv 8HTJlP0mYK/xMvUeIikYAdh448Nsa3YNQCUD4O9xefe70vtggQjxasEylrkzr1VkTwGave76D+/y u//caekuRyw97oKlH/zCf81f7adrbPCus77833685AW3X/DaO69c+cnb/uaSE9Y+/pijrrjkXB97 cIsKEBRQCA70TiCGHsdTewTgosvmnqD/lYtuWP2K36500q+xvfyIe17x1R+98uC7XnXgj//5gDtW OvDe1x78i9d//UFsqx31m5XftnD/Q47KBOplPSb9Ay4NAOb83H//XRgEwIa5QJdfvkeSAfjDD/9r 2UYDAOkPA3DAbptC/X/58t9xEOC/bTaLbcGb37T5wg8WjwD85V9+6FnP2uUZz9j5z/7sC4EB+MAH 3nv55a/ZZZf/ntJhzxGAJ5+8k9L/sceueeSRy3/3uyuxPfHEdeYHhmkAluy54fVf3+wXZ+36hysP uGCv97HjP9gWb/fWO47f5rAtXpdpAOLmzaaY2bAb/6ng6lPpul+QW7MWeSUNTvbMczM+l+PslV74 iktUOgIw9wDQ2RlM9w/WAPBfk/5Q/2YAAv3qNb1djjIVf/BrgYb2utmkrQ9vatv/WnCU9wyBmrcY in1LZgy+7Ja9oOzYn0ejJSdQqZErsAiIQFMEujQAKeq/2ADsttv12CD937bm5u9a69+xbffZT6Y8 Kr347lbp/lsg3EdJJdNUlO6sZgAuvPi7m33xoY13XXrEuUtnzlz6rs2e+Ne3XrDJR1e64JC/uGvJ M5fe+JdLf/gXj9/610cd8ukzTjvpuqsuzovd39jyBH1s72xP/JNXJ0GitQ0A4jn2jLPefOFvV1r8 m5d/4x5sr9r5poJtpdU32XqXgysZgC98AR7gOZgIhA3rARINwK9/8/0nHp3bzAD8zXP+GzZb+4uf aADeu+67SxcB77XX/meccf6BBx665pqhATj55D/faqv/vmDBqu9617tKrxeBAbjuumPf+97/2Gmn HbDde++fZgQN0wCcsej9szMLb/rGRzH1Hyr/7lN3mp3ZzBuAb3/u7dcc/MFvbv2mHd/zipe84G/w TrTEc7UzA1CqrUsD8EwsVuSJ6jwOlnhgXh5Km58FKB4BgPpHRc9fOGsGgE/+4eQfqH98ge4vHQEI NLRX54FSjxVz3rGBrwj0d+aveXra8pB4VOwu8vxDPI5R4CJid5TpPeq5AosqvW0opAiIQLMEEg0A J/zYx/f92yCAz1i8BiBR/RcbgCuvvP2QQ27aaqvZzRYe8OlPfgzbiccfWfWNVcX3sqq/lt5zC1R0 ngiJdX+mEyhoCdkjAEcv/sEHdnjgg59/eNEhv/nknn9c8N7HVl5zrwN2ffa1Rz/rlxc868mbn7X0 9mc+euPzZ76615LTTr7+2ssKEiiuzkyJ37EBuGH2yo0Wf/91Z/52xSPve9nBP8X2ws2OecFr3vma t39wlXdtPn+dz7zqfXuu8L49VtpkP2z/ttm+Czb47Gf3OqzUAPgpQL6/H2uCE6cAXfjdG5949CZs NACY82MbngLEn2gAih9xBZ4bbbTRa1/72he96EVbbbXViSeecfzxZ9sUoI997GP/9m9/v846b9pn n3222WabUgEXGICrr/7maqut9s53vvNTn/rUXnvtcuedZ3EQYMgG4LAtVtnl3f/vcZ9ecPtxn77t 2E/dfPiW2LZ761+f9vm1sADg+G3e8ql3vnTVV73oIx/5yIEHHjgoAxDUTmllJV5TzFdb+MSYh2YA TCx+4AMfwPyfefPnRgC44U0X+MytBJgbE5hJGQFgbIGhYpG9Po41dKbODi5reaMNPrlMxZyZn9Kj MvNc3H9f4C5iv5HoQOp5ALtLNatpFJsIiEAigUQDkLkGwHbSAxQbAOtNsLtS3s0IU4D8VB8/5+dH P/rxqafeeuCBs/vvf8nnd/oyttNOOf7m669MLGx8QwwOLL0/xlfpPK1bnKXieNoyADvut/Nmn1y4 1Y4f/8/N3rvWRp9d+W0XrbHBRifv9+e3ffsZj141p/6X3vmMn13891/76oHnn3O6YS1W80G9FtRu xwbg62de8aYlj/7zSY+8+shfrvjVe7C9cu87Xvne5VPTvvKtS1+76PtvPOG3W938BLYdzvjuWzfd /qgTv11gAPwi4Eceue+2287w21lnbZW4CPiCm7/z+O+uw0YDcPXdcwYA0p8b1D/eDpZoAPCk/wsu uOCQQw7ZeOONV111VcgjWwT80pe+9KMf/ehhhx2GhwLhXQGlLTswAL/5zcVXXXU0bMD3v3/qrbee /vDDlw/fAFz+5Y0v3vf9+ItO4hsO3fxHi7fjHqj/b3129a3e/pI1XvdKWKbPfz5cU1EAp8DfN/XT KGo75foVX01KL5ejZKm0pRWnXjwCAMu9bNXvQip+v3n1XzwCEOt4vyf41SvgTDVcoKft2ui9hF36 zdWk5Cc+qrjnXiMApY1cAURABLo0AIkeAFN69tn7yL32+r5tm2561dVX/+Cuu35y++13Xn/9neee i6c7XLLF5p/DdshB+11zxQWV6jHvDlXvzlXvXlkgHkjJl6j438yyZ48AXHv1RWefe8rJpx93/OKj v3bo/vsfvPv7tnvrQV+df+Pi/+cP1z7zoRv+6sHZvznha2sfefjXL7v4nO/deHWemg8sQewQ8vaw JJmOIm9/7SlA7z/u1pVm7lzhc+etctzDrz30V9hefeC9r/nyvS//+BkrfOrclQ/++Wqn/fZj33/8 oNt+i+1162z57s13OvG0MwoMAB4DileA8TGgeO7nww//giNilR4D+lcbnnXhTVc/8ciV2Ez048vj 95/NbU79r7OEW/kIwF0bXfSTi/D4//POO2/RokULFy58xzvescoqq6D7f+utt/7Sl76Ep6Dsu+++ 73nPe0ob9zIDsPiX/3vxjy/dr2C77Yydh7YIGFW2yZqv3nKdfznvyx+55/Qv/Oy0z//ghM/AA2DO z6Gb/8sVX9kEff9Q///++hU33HDDWP3H51vBuee7EGQAMk+W0pZWwwCYVsbpBumPv/baOuh+bib6 ufw3bw1ArLaDXv9A5Rd4A+bKwpfG7MOPeFTeOEPK/gLHEjucTM8zSn9/fGylm7cCi4AINEigEQPA GUE+V6M8BvTKy6845BAM697FCT/Ydtxxdu+9L8ZO2zZb+MX137cutkMO3r8RA1D7ttWBAQiqOyWr 2QYgiOiii5actOSYE0464qAv7/S1L3983903W7Tr59D9f95Zp37n6rkVtLZZ/5PviMoL4G2DDx/c 8/LUQ5BEbQPwtpPveeOnj3rF6h95xTZLVvnavdj+9dAHVznkgVW+/sCbjn/4PRf+ftvvP7b3db9c dcPPYFt5tfftf8Sxl12eveyh7EVg26S/CAwGANvsrRc//vBFjz949vLt/rNfs92ltr3s9R9Y7W3/ ge0zn/7EWWdkP5houV9aPO+Aiw/4PnrpTz31xBNPxIAAZuxgNAAd/0ceCQ+9F+h98IMfXHHFFUsb zbIXga372Q+//WP/8bribd03r5Cyqripi1TmFSq43LDNvPfNK+z6wbecsvvGP/3258wAYMb4p9Z6 6RqrvHL99dfHA1LXWmutOGPFcGL/bXsq/eTNQ7G/L62sPLYFniQv9UQRn56lmElxYYMMlD4FiB5g binwso9/9Cdn/5v6z3wKUKaiLVD5PnzxsaUxZ/bZ1ztq+en/1GrdTO8RhLHUC7xHHE8imTitUudg pq6pC4XiEQERqEog0QDwYmuf4Pk/zRoAKP5HHnnk4YcfxoSfSy75AbYjj5w94IBL3v7v73nvezZa /30fet9/vn/TD2y4+66fxwaBNPoUoEoCoFiOp9woC8Lwp1Hyw+wlGYCbr78K2zVXXnjWGaec/u3F Jxx39MknHnvR+Utumr2iKtOqzS49/KAMALDiXb8YB8ALAfwCADz+H68Aw08IUPwm4IYNwL/P2+ST mxx//PHQ+tttt90555yDVwIfe+yxeBMwuGFGEPr+qf5L26V1qSZ+Sa/BEUOmGADvOd/86n84dJt3 fXOH/+AIwA7/8YpV/+lFmAQF9b/66quX2k6yCogFOz3M9J8KJHhBJJXoxbUclMUnlFnSRJdSkKsg D5X+RbSlTwFCmKoGIFN521XSIwpGA1J0tle6ger1MZNDugr3d4L4qOJ88lcexTykxBDHGezJLF1m zHnewxOQAah0aiuwCLRBIMUAxAsAMvf47I0yAtCeAQhuf5bhzNui/7X2/S5Pb+RF6C/7xWGKG0OS AWijPTUeZ20DsNqJ9+5+2MlnnnPOwp0OfMV6i7DN3+myNx70o7ed8Mv3nvngh8/48TqLTlhxzQ+s vMb62Lb78tcuuuQCrBvOzD+1/rXXHnTXXZdhw7t+7W1f9o4w7OSv1157cMGbgGEA/uztJz/3ncf7 Ln98f/Ub3vP2tdbeYP31Nt5o/S23+Mhei76IbfEJR1971UXFjQ8tBup28eLFWOyLzn6sAdhpp53w ZdNNN33BC14QK8LGK6jtCNMNgD9j//55zzl11//cc8OVXvKC//tDH/oQ5ke1nc8hxD8B1Z0yAgDU GAGw5/1br3/Q/Z/3HoD4NuBVciXFnKewTSvHMQd+w2II3EKg4POOir1NkP/M+DO9QaZqTyRT7DTy dL/dpYZw7igPIjCFBIZpADDXHzP+v/vdH2DGP7aTT75y773PXGftd+7yhR3xXMTDvn7Q8cccfuG5 p2O78TtXTGGtlRZZBuCaTb91+4f3OZGk1tv3HGyrfXzmVWt94mWrf+gVq2+64r+9b+U1Nlhnyx0O OOpYbBdfev71111pyx4Cvr6zP/17ZiVtvc/J/7j2Qa9880f/dY2N1lt3HWwbbfCfmOv/8S0322/f Rcd98xsnfeubZ5564uUXn4MtsXHzJo0J7jfddNPhhx++xRZb4DXAE6AFCbCGAeCBxIInfu65556l J8xkBJiASk8ZAUCTmHseaNqn6puAM9Wq19mVvge95pWObTYng41tMk49lUIExpHAAA0AFgH76f78 /rY1197qY5ufetJxmJ1+/bWXYpbKONLuLM8yANccedqF6x5289u/dvPGh87uccy52C64+JKjTzx1 j4OO3uPgo7502LEnnnb6hReed9VVl2Jb1vd/bV71pIv+0heBXXHpuYd+7QAY2b322AVfsH3ruCNO WXzMktMXX3XZ+d+94apRmojvJhwlnkEdW9sADKoU3WTG9213k2LjqaSPAEDZJ346074Fowed5WFc PIYBabwJKUIREIFEAgM0AHiuP15++qmtP4aOUds+8fEtvvH1g6698sLEck15MBmAP61gnvKmMO7F lwEY9xqslP/EEYDB6ul4ftG4KPK+8lmpeSiwCIhAgwRKDUC9tEZZA1AvRR3lCWQYAFTJmH4WLFiQ WbtWHNX9BBPIrGW07zFtzMp2KQF/vued+xPc4KenaFoDMD11rZIOk0BLIkoGoN/qDg0A7qNj/emX plIfGoGxbszKfCkBa2+4kOkzwQSGdmFRfkRABEYnIAMwOsNRYggNwChx6VgREAEREAEREAEREAER KCUwwX0W41I01tHTXilcWm0KIAIiIAIiIAIiIAIiIAIiMNYEZAC0GlgEREAEREAEREAEREAEpojA /w+JNSIKFkxc6QAAAABJRU5ErkJggg== --=====================_906173==_-- From owner-idn@ops.ietf.org Fri Mar 29 02:13:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05998 for ; Fri, 29 Mar 2002 02:13:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qqSS-0004I3-00 for idn-data@psg.com; Thu, 28 Mar 2002 23:05:56 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16qqSR-0004Hx-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 23:05:55 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16qqSQ-0003Ck-00 for ; Thu, 28 Mar 2002 23:05:54 -0800 Date: Fri, 29 Mar 2002 07:05:54 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] URL encoding in html page Message-ID: <20020329070554.GB9491@nicemice.net> Reply-To: IETF idn working group References: <5.1.0.14.2.20020328184520.056f9e70@mail.nic.nu> <3CA17929.72D92BD0@trab.se> <5.1.0.14.2.20020328184520.056f9e70@mail.nic.nu> <5.1.0.14.2.20020329004541.056e3c90@mail.nic.nu> <5.1.0.14.2.20020328184520.056f9e70@mail.nic.nu> <3CA17929.72D92BD0@trab.se> <5.1.0.14.2.20020328184520.056f9e70@mail.nic.nu> <5.1.0.14.2.20020329004421.04c6cba0@mail.nic.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5.1.0.14.2.20020329004541.056e3c90@mail.nic.nu> <5.1.0.14.2.20020329004421.04c6cba0@mail.nic.nu> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit "J. William Semich" wrote: > This lookup, using the HTML spec "alings%E5s.com.nu", works fine > for me using IE - the system supports the html encoding just as it > supports UTF-8, ACE or ISO-8859-X. Okay, then w3m is failing for the same reason that netscape and mozilla are failing: my resolver refuses to resolve names with non-LDH labels, even if I put "options no-check-names" in /etc/resolv.conf. "J. William Semich" wrote: > try the links in various encodings on these pages .... > > http://www.worldnames.net/pages/demo.cfm Same story. My resolver refuses to return the address. Curiously, my three browsers apparently try to do three different lookups. All three display the Shift-JIS text correctly, but for the first link, netscape 4.x does a lookup on ÅÐÏ¿½ê.nu, mozilla does a lookup on %e7%99%bb%e9%8c%b2%e6%89%80.nu, and w3m does a lookup on %93o%98^%8F%8A.nu. I haven't checked, but I'm guessing that netscape 4.x converts the host name to euc-jp, mozilla converts it to UTF-8 and then %-escapes it, and w3m leaves it as shift_jis but then %-escapes it. AMC From owner-idn@ops.ietf.org Fri Mar 29 02:21:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06062 for ; Fri, 29 Mar 2002 02:21:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qqcY-0004XI-00 for idn-data@psg.com; Thu, 28 Mar 2002 23:16:22 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qqcY-0004XC-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 23:16:22 -0800 Message-ID: <001e01c1d6f2$22e97740$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: , "James Seng/Personal" Cc: "Edmon Chung" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> <3CA3DC3F.17C36B98@cnnic.net.cn> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 02:19:56 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> > you can justify why designing a system that can handle ASCII as a fallback >> > and can automatically support 8/16/32 bits Unicode is not a good design, >> > then I think my thinking is wrong. >> >> The question is really why 8/16/32 bit Unicode is better than 5bit (ACE)? >I think the former is based on character and the latter is based on string. >Maybe it is a advantage of the former for design many Applications. Totally agree the advantage of the former is to be able to have existing software or software that plans to have Unicode support to be able to work without performing EXTRA ACE conversion!! From owner-idn@ops.ietf.org Fri Mar 29 02:25:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06101 for ; Fri, 29 Mar 2002 02:25:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qqev-0004an-00 for idn-data@psg.com; Thu, 28 Mar 2002 23:18:49 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16qqeu-0004aK-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 23:18:48 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id A4914FFC0E; Fri, 29 Mar 2002 15:16:58 +0800 (SGT) Message-ID: <001201c1d6f1$c01134a0$dd00a8c0@jamessonyviao> From: "James Seng" To: "David Leung (Neteka Inc.)" , Cc: "Edmon Chung" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> <3CA3DC3F.17C36B98@cnnic.net.cn> <001e01c1d6f2$22e97740$6701a8c0@davidvaio> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 15:17:08 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Nameprep? ----- Original Message ----- From: "David Leung (Neteka Inc.)" To: ; "James Seng/Personal" Cc: "Edmon Chung" ; "IETF idn working group" Sent: Friday, March 29, 2002 3:19 PM Subject: Re: [idn] URL encoding in html page > >> > you can justify why designing a system that can handle ASCII as a > fallback > >> > and can automatically support 8/16/32 bits Unicode is not a good > design, > >> > then I think my thinking is wrong. > >> > >> The question is really why 8/16/32 bit Unicode is better than 5bit (ACE)? > > >I think the former is based on character and the latter is based on string. > >Maybe it is a advantage of the former for design many Applications. > > Totally agree the advantage of the former is to be able to have existing > software or software that plans to have Unicode support to be able to work > without performing EXTRA ACE conversion!! > > From owner-idn@ops.ietf.org Fri Mar 29 02:27:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06141 for ; Fri, 29 Mar 2002 02:27:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qqhQ-0004hN-00 for idn-data@psg.com; Thu, 28 Mar 2002 23:21:24 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qqhP-0004hG-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 23:21:23 -0800 Message-ID: <002401c1d6f2$e09d27f0$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Bruce Thomson" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> <3CA3DC3F.17C36B98@cnnic.net.cn> <0c4c01c1d6d3$801fb650$a303a8c0@bruce> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 02:25:16 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > The question is really why 8/16/32 bit Unicode is better than 5bit (ACE)? > > ACE and UTF-8 are just compression algorithms that squeeze larger > Unicode characters. ACE is more efficient than UTF, although more > complex. > > But the claim to fame that UTF-8 has is that it is a standard that > idn can reference, and it is coming into widespread use elsewhere. > > So moving to UTF-8 long term seems like such an obvious choice > is surprises me that it even gets debated. > > Of course, Punycode is a nice compression method... Maybe we should > take it to the Unicode forum and suggest that it be the next version of > UTF-8? > > But if that doesn't happen, it should logically be phased out. That's right if ACE is such a good "compression and encoding" scheme for Unicode, I think Unicode consortium should adopts it as the new UTF-P or UTF:-P, if they already have UTF8 that is widely use nowadays and also will be more use in the future, why not use UTF8 as a long term, and re-inventing the wheel now. From owner-idn@ops.ietf.org Fri Mar 29 02:40:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06271 for ; Fri, 29 Mar 2002 02:40:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qquC-00054t-00 for idn-data@psg.com; Thu, 28 Mar 2002 23:34:36 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qquC-00054n-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 23:34:36 -0800 Message-ID: <003001c1d6f4$ba992ed0$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 02:38:31 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The best way is to write a draft, explain how you wish to transit from the > IDNA to a long term solution (The closest I seen is UDNS). Then gather the > rough consensus so we can move it forward. Sure we happy to come up with a draft to talk about the transition from IDNA to UDNS(or something similar) and submit it... : ) > > More bits is good, but when we plan for things more than we need, then it > > should be considered to be a waste of resource. > > Read: IPv6. So you mean there will be more characters that we will use than IP addresses in the world that everyone knows is running out with IPv4... > > So why do we need 128bits > > now(i dont think the combined total of characters in all languages in the > > world would require that much, not unless we want to include scripts from > > oter planets : > ), whereas we need 8/16/32 bits for Unicode, so why not > > design a system able to accept ACE as a fallback and also 8/16/32 bits? If > > How many new han ideograph are created every day? How many ancient scripts > not encoded yet (e.g. Linear B)? True, those han ideograph are mostly slang words or swear words too, it would be nice if we can have all the words formed with the combination of the "door" in chinese to be able to input on computers... haha : ) > Or how about a new 128bit character table whereby allocation can be > allocated to 2^64 different locale, each locale get 64bit of space to put > their own encoding? (I know, sound much like IPv6). > > Are you in the position to predict the future? I did not try to predict the future, (i think you just did below this :>)... i think you misunderstand my last posting, i only said for now we DONT NEED 128bits to encode ALL characters in the world, USING more than NEEDED is a waste of resources, so we should not say IPv6 is a waste of resource because there is already a need there with IPv4 almost already ran out!! > My best *guess* is ISO10646 will get slowly get adoption over the next 20 > years. I *guess* UTF-8 will get more popular in the next 10 years. I *guess* > compressed bitstream (i.e. 1bit) ISO10646 will see some more adoption in > certain place where space is a constraint. I also *guess* there will be some > initative to do locale-based table (vs script based) but they will be faced > with huge barrier. But I could only guess... I hope there is some analysis behind these "predictions" : ) > > you can justify why designing a system that can handle ASCII as a fallback > > and can automatically support 8/16/32 bits Unicode is not a good design, > > then I think my thinking is wrong. > > The question is really why 8/16/32 bit Unicode is better than 5bit (ACE)? Some existing software is already supporting this, so require less upgrade. The software that are newly released are supporting mostly 8/16bits version of Unicode, like newer OSes, browsers, etc... and I am not saying ACE is bad... I am saying ACE and UTF8 or UCS should be able to co-exists in a system, so transition will be minimal and that should be a good design. From owner-idn@ops.ietf.org Fri Mar 29 02:42:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06292 for ; Fri, 29 Mar 2002 02:42:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qqxQ-000593-00 for idn-data@psg.com; Thu, 28 Mar 2002 23:37:56 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qqxQ-00058x-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 23:37:56 -0800 Message-ID: <004101c1d6f5$2ec49010$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Bruce Thomson" , "James Seng/Personal" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <0c3d01c1d6cd$676a3d20$a303a8c0@bruce> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 02:41:45 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Granted, such 128-bit characters might be useful. This would allow various > organizations to define their own characters sets. Space in the global > character encoding space would be allocated in the same way as > IP address space is allocated under IPv6. > > But to conserve file space, it would probably be best to allow intermixing of > 128-bit characters with ASCI text. UTF-8 continues to be the way to do > this, since it just a compression scheme that does not really depend on the fact > that Unicode is currently limited to 32 bits. It could just as easily be extended > to work with much larger character sets. Agrees, the design of how UTF-8 encodes and decodes can be expanded to support more bits... so that's why UTF8 should be reasonable to be the long term solution for designing i18n applications, including IDN... From owner-idn@ops.ietf.org Fri Mar 29 02:48:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06365 for ; Fri, 29 Mar 2002 02:48:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qr2R-0005Gt-00 for idn-data@psg.com; Thu, 28 Mar 2002 23:43:07 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qr2Q-0005Gm-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 23:43:07 -0800 Message-ID: <004b01c1d6f5$e74e8960$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Doug Ewell" , "James Seng/Personal" Cc: References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> <003701c1d6e1$9c16a540$62424244@anhmca.adelphia.net> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 02:46:55 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > How many new han ideograph are created every day? How many ancient > scripts > > not encoded yet (e.g. Linear B)? > > ... > > Are you in the position to predict the future? > > How far into the future? Linear B is planned for Unicode 4.0 -- look > for it about 18 months from now -- and I hate to say this, but Linear B > fits into a single 256-character block. And the number of other ancient > scripts that experts know enough about to encode is not that great. > Sorry, but there simply aren't MILLIONS of characters waiting to be > encoded. But if we are talking about the future where aliens from other planets join us for the discussion at IETF, then maybe we need to encode all the characters from their planets too!! Also there are billions of stars and planets out there, who knows : ) From owner-idn@ops.ietf.org Fri Mar 29 03:01:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06542 for ; Fri, 29 Mar 2002 03:01:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qrEW-0005ar-00 for idn-data@psg.com; Thu, 28 Mar 2002 23:55:36 -0800 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.35 #1) id 16qrEW-0005aX-00 for idn@ops.ietf.org; Thu, 28 Mar 2002 23:55:36 -0800 Message-ID: <005101c1d6f6$9cc10980$6701a8c0@davidvaio> From: "David Leung \(Neteka Inc.\)" To: "Doug Ewell" , "IETF idn working group" Cc: "James Seng/Personal" , "Edmon Chung" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <003c01c1d6e1$d914f6e0$62424244@anhmca.adelphia.net> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 02:51:59 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > David Leung (Neteka Inc.) wrote: > > > More bits is good, but when we plan for things more than we need, > > then it should be considered to be a waste of resource. So why do > > we need 128bits now(i dont think the combined total of characters > > in all languages in the world would require that much, not unless > > we want to include scripts from oter planets : > ), whereas we need > > 8/16/32 bits for Unicode, so why not design a system able to accept > > ACE as a fallback and also 8/16/32 bits? If you can justify why > > designing a system that can handle ASCII as a fallback and can > > automatically support 8/16/32 bits Unicode is not a good design, > > then I think my thinking is wrong. > > Is my memory faulty, or wasn't it the CJK users who complained the > loudest that UTF-8 was unfairly discriminatory because it required 3 > bytes for each CJK character, and that some sort of compression (such as > now provided by Punycode) was essential to the success of IDN? Dont judge all CJK users to be the same person, I guess you really have faulty memory or even memory leak, that wasnt me!! Also dont view all CJK people to be the same group, this maybe kind of discrimination?! The guy who said that was Soobok Lee(he is Korean and I am Chinese) or someone else!! I am the one that keep saying UTF8 or 16 bit is good and ACE should only be transitional...!! David Leung Chief Technology Officer Neteka Inc. T: (416) 971-4302 http://w!.neteka.com From owner-idn@ops.ietf.org Fri Mar 29 03:17:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06728 for ; Fri, 29 Mar 2002 03:17:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qrSU-0006Ak-00 for idn-data@psg.com; Fri, 29 Mar 2002 00:10:02 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16qrSS-0006AB-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 00:10:00 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id CEFE7FFC0B; Fri, 29 Mar 2002 16:08:10 +0800 (SGT) Message-ID: <012201c1d6f8$e7235350$dd00a8c0@jamessonyviao> From: "James Seng" To: "Bruce Thomson" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> <3CA3DC3F.17C36B98@cnnic.net.cn> <0c4c01c1d6d3$801fb650$a303a8c0@bruce> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 16:08:20 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ACE and UTF-8 are just compression algorithms that squeeze larger > Unicode characters. ACE is more efficient than UTF, although more > complex. UTF-8 does not have any compression. > But the claim to fame that UTF-8 has is that it is a standard that > idn can reference, and it is coming into widespread use elsewhere. Yes, agree it is "coming into widespread'. Until it is widespread, it is only "Coming Soon". or "Coming Soon to your favourite OS RSN(tm)". > So moving to UTF-8 long term seems like such an obvious choice > is surprises me that it even gets debated. Any technical decision have to based on well-founded technical reasons. The transcoding can be bypassed if everything is in UTF-8 is a good argument I can accept. To use UTF-8 just because everyone else is *going to* do so does not sound too conviencing. And "UTF-8 is obvious" is not an argument I can buy. > Of course, Punycode is a nice compression method... Maybe we should > take it to the Unicode forum and suggest that it be the next version of > UTF-8? > > But if that doesn't happen, it should logically be phased out. Lets bring base64 and qp over to Unicode and also %-escaping and other adaptive mechanism out there, then phased them all out! Lets phase out all other local encoding too. The world should only have one and only one encoding! Long live UTF-8, for all fonts, for input, for all protocols, all systems, all software! This the utopia dream of all I18N engineers (myself included). But enough dreaming. Lets get back to ugly reality. *sigh* -James Seng From owner-idn@ops.ietf.org Fri Mar 29 03:39:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06938 for ; Fri, 29 Mar 2002 03:39:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qrol-0006s8-00 for idn-data@psg.com; Fri, 29 Mar 2002 00:33:03 -0800 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.35 #1) id 16qrok-0006s2-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 00:33:02 -0800 Received: from MASTER ([211.197.15.177]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g2T8WiA27656; Fri, 29 Mar 2002 17:32:44 +0900 Message-ID: <1f1601c1d6fc$1cd0e780$2b19fea9@temp> From: "Soobok Lee" To: "Doug Ewell" , "IETF idn working group" Cc: "David Leung \(Neteka Inc.\)" , "James Seng/Personal" , "Edmon Chung" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <003c01c1d6e1$d914f6e0$62424244@anhmca.adelphia.net> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 17:31:24 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Doug Ewell" > Is my memory faulty, or wasn't it the CJK users who complained the > loudest that UTF-8 was unfairly discriminatory because it required 3 > bytes for each CJK character, and that some sort of compression (such as > now provided by Punycode) was essential to the success of IDN? Hmm.. *I* had proposed to kill DUDE and choose ACE-Z (code simplicity does not matter so much). *This WG* decided to drop DUDE and chose ACE-Z. this is the list of supporters of ACE-Z. there are many non-CJK folks here. a.. Adam M. Costello amc@cs.berkeley.edu a.. David C Lawrence tale@nominum.com a.. Makoto Ishisone ishisone@sra.co.jp a.. Rick H Wesson wessorh@ar.com a.. Scott Hollenbeck shollenbeck@verisign.com a.. Soobok Lee lsb@postel.co.kr a.. Yoshiro YONEYA yone@po.ntts.co.jp a.. Yves Arrouye yves@realnames.com a.. James Seng jseng@pobox.org.sg a.. Bright Fulton bright@alldomains.com a.. Yasuhiro Morishita yasuhiro@jprs.jp a.. Zhu Yu yu.zhu@i-dns.net a.. Martin Duerst duerst@w3.org From owner-idn@ops.ietf.org Fri Mar 29 03:45:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07012 for ; Fri, 29 Mar 2002 03:45:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qruL-00073b-00 for idn-data@psg.com; Fri, 29 Mar 2002 00:38:49 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16qruK-00073U-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 00:38:48 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id RAA01992 for ; Fri, 29 Mar 2002 17:38:47 +0900 Message-ID: <0cb301c1d6fd$16071f40$a303a8c0@bruce> From: "Bruce Thomson" To: "IETF idn working group" References: <3CA17929.72D92BD0@trab.se> <5.1.0.14.2.20020328184520.056f9e70@mail.nic.nu> <20020329051327.GA9491@nicemice.net> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 17:38:22 +0900 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit These pages helped me get the resolver going. They might be applicable to Debian as well. http://www.i-dns.net/download/libc-freebsd/readme.txt http://www.i-dns.net/download/libc-linux/readme.txt Bruce > > Depending on your resolver. On my Debian GNU/Linux system, "dig" can > successfully look up alingsås.com.nu, and so can "host" (which warns > that the name is illegal but prints the IP address anyway). But the > resolver won't have it: > > > ping alingsås.com.nu > ping: unknown host alingsås.com.nu > > I tried adding "options no-check-names" to /etc/resolv.conf, but that > had no effect. I then tried changing it to "options no-check-names > debug", but I got no debugging messages. I don't know what's going on > with the resolver. I'm using glibc 2.2.5. > > From owner-idn@ops.ietf.org Fri Mar 29 03:54:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07123 for ; Fri, 29 Mar 2002 03:54:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qs3k-0007J9-00 for idn-data@psg.com; Fri, 29 Mar 2002 00:48:32 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.35 #1) id 16qs3i-0007Iu-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 00:48:31 -0800 Received: from jamessonyviao (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id A0FDCFFC0B; Fri, 29 Mar 2002 16:46:41 +0800 (SGT) Message-ID: <014001c1d6fe$486fac80$dd00a8c0@jamessonyviao> From: "James Seng" To: "David Leung (Neteka Inc.)" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> <003001c1d6f4$ba992ed0$6701a8c0@davidvaio> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 16:46:51 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Sure we happy to come up with a draft to talk about the transition from IDNA > to UDNS(or something similar) and submit it... : ) This is definately more productive :-) Please do so. > So you mean there will be more characters that we will use than IP addresses > in the world that everyone knows is running out with IPv4... The lesson on IPv4/6 is once upon a time, someone sclaim 32 bits is all we need for IP. > True, those han ideograph are mostly slang words or swear words too, it > would be nice if we can have all the words formed with the combination of > the "door" in chinese to be able to input on computers... haha : ) Not all ideograph are slang or swear like in Cantonese. There are about 500+ han ideograph used in Singapore alone that is not inside ISO10646. Of which only 25 is in IRG review. Most of them cannot even be justified under normal process because it is character "created" for some person name. Fortune Teller: "Your fire element is too strong and your water element is lacking. Your bad luck comes from the unbalance Yi-Ching. Lets add some water, 3 dot (water kangxi) to this character of your name". Bingo! A new character is born. But alas, I am just rattling...lets drop this. > I did not try to predict the future, (i think you just did below this :>)... > I hope there is some analysis behind these "predictions" : ) I am guessing, not predicting. My guess about future is as good as anyone else, which is nothing. > Some existing software is already supporting this, so require less upgrade. Some software support UTF-8. No software support Nameprep-UTF-8. Software that deals with IDN using UTF-8 still have to upgrade. But lets not jump ahead. I'll wait for your draft. -James Seng From owner-idn@ops.ietf.org Fri Mar 29 05:29:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08045 for ; Fri, 29 Mar 2002 05:29:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qtPf-0009SE-00 for idn-data@psg.com; Fri, 29 Mar 2002 02:15:15 -0800 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.35 #1) id 16qtPe-0009S8-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 02:15:15 -0800 Received: by rap.rap.dk (Postfix, from userid 500) id B83A74049; Fri, 29 Mar 2002 11:15:14 +0100 (CET) Date: Fri, 29 Mar 2002 11:15:14 +0100 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: Bruce Thomson Cc: IETF idn working group Subject: Re: [idn] URL encoding in html page Message-ID: <20020329101514.GA19488@rap.rap.dk> References: <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> <3CA3DC3F.17C36B98@cnnic.net.cn> <0c4c01c1d6d3$801fb650$a303a8c0@bruce> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c4c01c1d6d3$801fb650$a303a8c0@bruce> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk On Fri, Mar 29, 2002 at 12:40:41PM +0900, Bruce Thomson wrote: > > The question is really why 8/16/32 bit Unicode is better than 5bit (ACE)? > > ACE and UTF-8 are just compression algorithms that squeeze larger > Unicode characters. ACE is more efficient than UTF, although more > complex. > > But the claim to fame that UTF-8 has is that it is a standard that > idn can reference, and it is coming into widespread use elsewhere. > > So moving to UTF-8 long term seems like such an obvious choice > is surprises me that it even gets debated. I think the UTF-8 is the way to go forward too, and I actuallt think this is also IESG policy, viz RFC 2277 and RFC 2130. The UTF-8 RFC 2279 is the only standards track RFC on charsets for the same reason. Citing from RFC 2277, the IESG policy on charactyer sets and language: "Protocols MUST be able to use the UTF-8 charset, which consists of the ISO 10646 coded character set combined with the UTF-8 character encoding scheme, as defined in [10646] Annex R (published in Amendment 2), for all text." I dont mind having an ASCII fallback as we also have it in email, but going into the other encoding forms of ISO 10646 is discouraged by IESG, as they do not want to see a lot of encodings for the same character set, with the possible problems of interoperability. So UCS-2, UCS-4, UTF-16, UTF-16-LE, UTF-16-BE etc are discouraged. Best regards Keld Simonsen From owner-idn@ops.ietf.org Fri Mar 29 06:25:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08592 for ; Fri, 29 Mar 2002 06:25:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16quMw-000B0E-00 for idn-data@psg.com; Fri, 29 Mar 2002 03:16:30 -0800 Received: from kruuna.helsinki.fi ([128.214.205.14]) by psg.com with esmtp (Exim 3.35 #1) id 16quMv-000B08-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 03:16:30 -0800 Received: from localhost (ssyreeni@localhost) by kruuna.Helsinki.FI (8.11.6/8.10.1) with ESMTP id g2TBGID09503; Fri, 29 Mar 2002 13:16:18 +0200 (EET) X-Authentication-Warning: kruuna.Helsinki.FI: ssyreeni owned process doing -bs Date: Fri, 29 Mar 2002 13:16:18 +0200 (EET) From: Sampo Syreeni To: James Seng cc: "David Leung (Neteka Inc.)" , IETF idn working group Subject: Re: [idn] URL encoding in html page In-Reply-To: <014001c1d6fe$486fac80$dd00a8c0@jamessonyviao> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Fri, 29 Mar 2002, James Seng wrote: >> So you mean there will be more characters that we will use than IP >> addresses in the world that everyone knows is running out with IPv4... > >The lesson on IPv4/6 is once upon a time, someone sclaim 32 bits is all we >need for IP. That's a bit different -- nobody's supposed to remember all of the IP's out there. Someone *is*, when it comes to characters. Besides, not too many characters are out there, considering that the largest group, Chinese ideographs, has largely been encoded in Unicode already. (True, there are esoteric ones. Now, after Unicode 3.1 with its CJK Unified Ideographs Extension B, that group is rapidly shrinking, too.) >There are about 500+ han ideograph used in Singapore alone that is not >inside ISO10646. Of which only 25 is in IRG review. Most of them cannot >even be justified under normal process because it is character "created" >for some person name. Then we might argue that such characters are analogous to corporate logos, and *shouldn't* in fact be encoded. Not before the glyphs are in widespread use and some sort of semantic distinction has arisen between them and their progenitors. >Fortune Teller: "Your fire element is too strong and your water element >is lacking. Your bad luck comes from the unbalance Yi-Ching. Lets add >some water, 3 dot (water kangxi) to this character of your name". Bingo! >A new character is born. No. A new *glyph* for the same *character* is born. If the meaning does not change, I would view this as a glyph variant. From there on, it's the person's responsibility to lobby for the inclusion of this character in fonts as an alternative representation. No need for standards organizations to get involved... >Some software support UTF-8. No software support Nameprep-UTF-8. >Software that deals with IDN using UTF-8 still have to upgrade. But lets >not jump ahead. I'll wait for your draft. I too think going directly to UTF-8 would be more elegant than using ACE. However, it is not a panacea, either -- AFAICS, all of the problems with ACE and ideographs comes from the way these characters are used. Not ACE. So this trouble won't be going *anywhere* if we jump to UTF-8. The only thing one would be buying with such a move would be elegance and, perhaps, unlimited host name lengths. Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From owner-idn@ops.ietf.org Fri Mar 29 09:53:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16682 for ; Fri, 29 Mar 2002 09:53:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qxYt-000GhV-00 for idn-data@psg.com; Fri, 29 Mar 2002 06:41:03 -0800 Received: from rwcrmhc53.attbi.com ([204.127.198.39]) by psg.com with esmtp (Exim 3.35 #1) id 16qxYs-000GhP-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 06:41:02 -0800 Received: from c1340594a ([12.234.212.162]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020329144101.GSSL2928.rwcrmhc53.attbi.com@c1340594a>; Fri, 29 Mar 2002 14:41:01 +0000 Message-ID: <009401c1d72f$c8fd6910$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "David Leung \(Neteka Inc.\)" , "Bruce Thomson" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> <3CA3DC3F.17C36B98@cnnic.net.cn> <0c4c01c1d6d3$801fb650$a303a8c0@bruce> <002401c1d6f2$e09d27f0$6701a8c0@davidvaio> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 06:41:17 -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.2600.0000 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit The consortium does not encourage the development of further general-purpose UTFs. Endlessly multiplying such formats just leads to confusion. As to compression formats, once ACE is already defined by an RFC it is better to simply reference that in any Unicode documentation that needs to. Keeping the definition in one place is easier than having two definitions that require synchronization. Mark ————— Γνῶθι σαυτόν — Θαλῆς [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: "David Leung (Neteka Inc.)" To: "Bruce Thomson" ; "IETF idn working group" Sent: Thursday, March 28, 2002 23:25 Subject: Re: [idn] URL encoding in html page > > > The question is really why 8/16/32 bit Unicode is better than 5bit > (ACE)? > > > > ACE and UTF-8 are just compression algorithms that squeeze larger > > Unicode characters. ACE is more efficient than UTF, although more > > complex. > > > > But the claim to fame that UTF-8 has is that it is a standard that > > idn can reference, and it is coming into widespread use elsewhere. > > > > So moving to UTF-8 long term seems like such an obvious choice > > is surprises me that it even gets debated. > > > > Of course, Punycode is a nice compression method... Maybe we should > > take it to the Unicode forum and suggest that it be the next version of > > UTF-8? > > > > But if that doesn't happen, it should logically be phased out. > > That's right if ACE is such a good "compression and encoding" scheme for > Unicode, I think Unicode consortium should adopts it as the new UTF-P or > UTF:-P, if they already have UTF8 that is widely use nowadays and also will > be more use in the future, why not use UTF8 as a long term, and re-inventing > the wheel now. > > > > > From owner-idn@ops.ietf.org Fri Mar 29 09:56:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16841 for ; Fri, 29 Mar 2002 09:56:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qxdT-000Goy-00 for idn-data@psg.com; Fri, 29 Mar 2002 06:45:47 -0800 Received: from smtprelay1.dc3.adelphia.net ([24.50.78.4]) by psg.com with esmtp (Exim 3.35 #1) id 16qxdT-000Goq-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 06:45:47 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.98]) by smtprelay1.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GTQP0900.E6B; Fri, 29 Mar 2002 09:45:46 -0500 Message-ID: <000c01c1d730$654f9180$62424244@anhmca.adelphia.net> From: "Doug Ewell" To: "David Leung \(Neteka Inc.\)" , "James Seng/Personal" Cc: , "Unicode Mailing List" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> <003701c1d6e1$9c16a540$62424244@anhmca.adelphia.net> <004b01c1d6f5$e74e8960$6701a8c0@davidvaio> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 06:45:32 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Leung (Neteka Inc.) mused: > But if we are talking about the future where aliens from other planets join > us for the discussion at IETF, then maybe we need to encode all the > characters from their planets too!! Also there are billions of stars and > planets out there, who knows : ) This is what I mean about listening only to "non-whimsical" arguments about the number of characters that need to be encoded. If Earth does get a visit from space aliens, I suspect character encoding will not be the first problem that needs to be solved. Please, let's not cloud the real issues of character encoding. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Fri Mar 29 10:08:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17489 for ; Fri, 29 Mar 2002 10:08:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qxuX-000HLF-00 for idn-data@psg.com; Fri, 29 Mar 2002 07:03:25 -0800 Received: from smtprelay2.dc3.adelphia.net ([24.50.78.5]) by psg.com with esmtp (Exim 3.35 #1) id 16qxuW-000HL9-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 07:03:24 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.98]) by smtprelay2.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GTQPTN00.877; Fri, 29 Mar 2002 10:03:23 -0500 Message-ID: <005001c1d732$dbe8faa0$62424244@anhmca.adelphia.net> From: "Doug Ewell" To: "David Leung \(Neteka Inc.\)" , "Bruce Thomson" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <00b301c1d69c$761d52c0$0301a8c0@davidvaio> <000b01c1d6cb$5c21aae0$0701000a@jamescompaq> <3CA3DC3F.17C36B98@cnnic.net.cn> <0c4c01c1d6d3$801fb650$a303a8c0@bruce> <002401c1d6f2$e09d27f0$6701a8c0@davidvaio> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 07:03:15 -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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Leung (Neteka Inc.) wrote: > That's right if ACE is such a good "compression and encoding" scheme for > Unicode, I think Unicode consortium should adopts it as the new UTF-P or > UTF:-P, if they already have UTF8 that is widely use nowadays and also will > be more use in the future, why not use UTF8 as a long term, and re-inventing > the wheel now. Punycode is not the invention of Unicode, despite the name. Unicode already has a perfectly good Standard Compression Scheme (see http://www.unicode.org/unicode/reports/tr6/). But it uses non-ASCII bytes, and so SCSU-encoded domain names would probably not pass cleanly in a world that expects ASCII-only, any more than UTF-8 would. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Fri Mar 29 10:13:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17744 for ; Fri, 29 Mar 2002 10:13:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qxyU-000HRj-00 for idn-data@psg.com; Fri, 29 Mar 2002 07:07:30 -0800 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.35 #1) id 16qxyU-000HRd-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 07:07:30 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.98]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GTQQ0H00.K0D; Fri, 29 Mar 2002 10:07:29 -0500 Message-ID: <005b01c1d733$6e58c5a0$62424244@anhmca.adelphia.net> From: "Doug Ewell" To: "David Leung \(Neteka Inc.\)" , "Bruce Thomson" , "James Seng/Personal" , "IETF idn working group" References: <3CA025B9.B329C70A@trab.se> <001901c1d4e5$51725050$0301a8c0@davidvaio> <20020326234002.GB15408@nicemice.net> <013f01c1d522$858a1cf0$0301a8c0@davidvaio> <20020327005714.GC15408@nicemice.net> <017601c1d593$bfabca20$6501a8c0@EDMON15> <004801c1d5b3$2c168460$6701a8c0@davidvaio> <003401c1d5e8$4ed51180$0701000a@jamescompaq> <030f01c1d661$37ce18f0$6501a8c0@EDMON15> <005d01c1d694$9181eec0$0701000a@jamescompaq> <0c3d01c1d6cd$676a3d20$a303a8c0@bruce> <004101c1d6f5$2ec49010$6701a8c0@davidvaio> Subject: Re: [idn] URL encoding in html page Date: Fri, 29 Mar 2002 07:07:22 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Leung (Neteka Inc.) also wrote: > Agrees, the design of how UTF-8 encodes and decodes can be expanded to > support more bits... so that's why UTF8 should be reasonable to be the long > term solution for designing i18n applications, including IDN... Please, everybody, read the definition of UTF-8 before making these claims that it supports an encoding structure wider than 31 bits. (And please read the statements of WG2 and Unicode concerning expansion beyond U+10FFFD.) UTF-8 seems to have taken on a mystical quality whereby it can now provide food for the starving, shelter for the homeless, etc. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Fri Mar 29 17:52:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06861 for ; Fri, 29 Mar 2002 17:52:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16r4yL-0003zB-00 for idn-data@psg.com; Fri, 29 Mar 2002 14:35:49 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16r4yK-0003z5-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 14:35:48 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16r4yJ-0005A6-00 for ; Fri, 29 Mar 2002 14:35:47 -0800 Date: Fri, 29 Mar 2002 22:35:47 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: [idn] phasing out ACE Message-ID: <20020329223547.GB19163@nicemice.net> Reply-To: IETF idn working group Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk There has been much debate about whether ACE should be phased out. Even though people have different views, I don't think we really need to debate this question. On one side are people who think it is both possible and desirable to phase out ACE eventually. On the other side are people who doubt whether it is possible or worth the effort to phase out ACE. I don't recall anyone saying that ACE should live forever even if it were easy and painless to phase out. So the people who favor the phase-out can go ahead and work toward that goal. The others need not bother to stand in the way (because if the goal is unachievable, there's no need to oppose it, and if the goal is not worth the effort, then opposing the goal is likewise not worth the effort). I see only two points of possible contention for this working group: First, should the IDNA spec state that ACE is transitional, or should it state that ACE is the long-term solution, or should it take neither position? By remaining neutral it would not shut the door on either possibility, so this ought to be the least objectionable to the most people. Second, should DNS extensions for native support of IDNs be developed by the idn working group, or the dnsext working group? Phasing out ACE will require upgrades to every IETF standard that uses domain names, and hence will involve many working groups. DNS is just one of many protocols that will need to be upgraded. So perhaps the idn working group should take a coordinating/consulting role, while the new standards are actually produced by other working groups. DNS need not be an exception. AMC From owner-idn@ops.ietf.org Fri Mar 29 19:07:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07971 for ; Fri, 29 Mar 2002 19:07:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16r6Db-0006Bq-00 for idn-data@psg.com; Fri, 29 Mar 2002 15:55:39 -0800 Received: from spider.nic-se.se ([212.247.3.67]) by psg.com with esmtp (Exim 3.35 #1) id 16r6Da-0006Bk-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 15:55:39 -0800 Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id g2TNtOc01153 for ; Sat, 30 Mar 2002 00:55:24 +0100 (CET) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Sat, 30 Mar 2002 00:55:24 +0100 (CET) From: Mats Dufberg To: IETF idn working group Subject: Re: [idn] phasing out ACE In-Reply-To: <20020329223547.GB19163@nicemice.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Mar 29, 2002, 22:35 (-0000) Adam M. Costello On one side are people who think it is both possible and desirable > to phase out ACE eventually. On the other side are people who doubt > whether it is possible or worth the effort to phase out ACE. I don't > recall anyone saying that ACE should live forever even if it were easy > and painless to phase out. ACE is like quoted-printable in mail messages. It is a solution that will cause the least problem for time being, but not the solution that anyone would invent from scratch. > First, should the IDNA spec state that ACE is transitional, or should > it state that ACE is the long-term solution, or should it take neither > position? By remaining neutral it would not shut the door on either > possibility, so this ought to be the least objectionable to the most > people. To state that the ACE solution is transitional, we have to know how and by what it should be replace. When (and if) there is a better solution, we should welcome that to replace ACE. > Second, should DNS extensions for native support of IDNs be developed > by the idn working group, or the dnsext working group? Phasing out > ACE will require upgrades to every IETF standard that uses domain > names, and hence will involve many working groups. DNS is just one > of many protocols that will need to be upgraded. So perhaps the idn > working group should take a coordinating/consulting role, while the new > standards are actually produced by other working groups. DNS need not > be an exception. Replacing ACE with, say, UTF-8, if possible, is a task for an entire new working group. The dnsext working group will possibly close when the DNSsec work is done. As you note, such work will effect several IETF standards. Every such standard must be updated first to be neutral between 7bit ASCII and unicode encoded in UTF-8 (or some other encoding), before DNS can be updated. Mats ---------------------------------------------------------------------- Mats Dufberg ---------------------------------------------------------------------- From owner-idn@ops.ietf.org Fri Mar 29 20:54:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09436 for ; Fri, 29 Mar 2002 20:54:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16r7rJ-0009A8-00 for idn-data@psg.com; Fri, 29 Mar 2002 17:40:45 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.35 #1) id 16r7rI-0009A2-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 17:40:45 -0800 Received: (qmail 29341 invoked by uid 1001); 30 Mar 2002 01:39:41 -0000 Date: 30 Mar 2002 01:39:41 -0000 Message-ID: <20020330013941.15480.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] phasing out ACE References: <20020329223547.GB19163@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Adam M. Costello writes: > There has been much debate about whether ACE should be phased out. > Even though people have different views, I don't think we really need > to debate this question. There are two issues here. 1. Should applications be required to handle UTF-8 properly, in preparation for a UTF-8 world? The lessons of history are helpful at this point. If Keith Moore and his buddies had---with or without Quoted-Printable---required 8-bit-clean mail software in 1991, we wouldn't have sendmail's 8-bit bugs today. If they had thought a little more broadly and fixed other protocols, we would have been able to deploy UTF-8 years ago. Unfortunately, they, like you, didn't consider the long term. I don't know if they were as blatant as you in claiming that shortsightedness was a good thing; but the bottom line is that they, like you, made a decision destined to look really stupid to future users. 2. Should short-term plans be considered in the context of the desired transition to UTF-8? Common sense is helpful at this point. The cost of the long-term move to UTF-8 obviously depends on the choice of short-term plan. Consquently, ignoring the UTF-8 transition will not produce the same cost-benefit analysis as taking it into account. Here is one example of the variation in costs. Suppose we do a massive redeployment of mail-displaying programs etc. to present IDNA names as non-ASCII glyphs. Moving to UTF-8 then requires _another_ massive redeployment of those programs. In contrast, if IDNA were modified to also require proper display of UTF-8, programs dedicated to displays would require only one upgrade. Notice how a small change in the short-term plan provides huge long-term benefits---benefits that you are refusing to take into account. Even better, if we scrap this 7-bit garbage and move directly to UTF-8, _all_ programs will require at most one upgrade---maybe 0.5 on average. But you don't need to think about this possibility to understand why ignoring the long-term plan is stupid. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-idn@ops.ietf.org Fri Mar 29 21:29:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09978 for ; Fri, 29 Mar 2002 21:29:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16r8Xe-000APF-00 for idn-data@psg.com; Fri, 29 Mar 2002 18:24:30 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.35 #1) id 16r8Xd-000AP9-00 for idn@ops.ietf.org; Fri, 29 Mar 2002 18:24:29 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16r8Xd-0005ck-00 for ; Fri, 29 Mar 2002 18:24:29 -0800 Date: Sat, 30 Mar 2002 02:24:29 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] phasing out ACE Message-ID: <20020330022428.GD19163@nicemice.net> Reply-To: IETF idn working group References: <20020329223547.GB19163@nicemice.net> <20020330013941.15480.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020330013941.15480.qmail@cr.yp.to> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk "D. J. Bernstein" wrote: > Suppose we do a massive redeployment of mail-displaying programs etc. > to present IDNA names as non-ASCII glyphs. Moving to UTF-8 then > requires _another_ massive redeployment of those programs. Yes, if a UTF-8 mail header standard is going to appear ever, it would be convenient (not essential, but convenient) if it could appear soon, so that applications would have the option of adding support for IDNA and UTF-8 headers all at once. > In contrast, if IDNA were modified to also require proper display of > UTF-8 UTF-8 in what? In UTF-8 mail headers and SMTP commands that haven't been standardized yet? And in upgraded HTML, HTTP, SSL, etc. standards that haven't been created yet? And on and on... IDNA can't set requirements for all these protocols, because it's way outside the scope and expertise if this working group. By letting IDNA out the door before we've added UTF-8 support to every protocol, we give applications the choice of using IDNs now (and possibly facing two upgrades), or hanging back and waiting to see if UTF-8 versions of their protocols are forthcoming (so they can just do one big upgrade). AMC From owner-idn@ops.ietf.org Sat Mar 30 03:37:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26266 for ; Sat, 30 Mar 2002 03:37:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rE8F-000Kbm-00 for idn-data@psg.com; Sat, 30 Mar 2002 00:22:39 -0800 From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] URL encoding in html page To: "David Leung (Neteka Inc.)" Cc: Edmon Chung , IETF.idn.working.group Message-Id: Date: Sat, 30 Mar 2002 00:22:39 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > ACE will work with "EXISTING" systems but ALL client end(browser, MUA, etc) > and SOME server(Apache, etc) end software actually needs to upgrade in order > to be able to recognize IDN and convert it to ACE back and forth, unless we > want to say that www.ietf.org that we are using nowadays is IDN already : ) > > On the other hand, we see a lot of applications is moving towards the > support of UTF8/Unicode on the client side, and this is going to be the > future anyways... so why not just upgrade the server software, with one > server software upgraded it will serve many many users... I dont understand > why no one see this simple math : ) David, You seem to be assuming that there would be only two entities involved in the application protocol between the endpoints. The world isn't that simple. As an example, the mail I'm responding to contained 8 Received lines when I got it. Thus, assuming the return path have the same number of SMTP hops, if you had nameprepped-UTF-8 in your domain name in the from: line, if any of those 8 relays didn't handle UTF-8 properly, this mail would not have reached you. Thus it isn't just a question of upgrading two pieces of software. Likewise for http. Upgrading my browser wouldn't do much good when there are 2 caching proxies plus a socks host inside sun that look at the http headers, and some number of load balancers (global and local), ssl proxies, and akamai caches, that sit in front of many web servers. Dealing with this type of reality is part of the challenge in the transition to a scheme which uses nameprepped-UTF-8 in application protocols. Erik From owner-idn@ops.ietf.org Sat Mar 30 06:31:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27472 for ; Sat, 30 Mar 2002 06:31:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rGyC-0000GZ-00 for idn-data@psg.com; Sat, 30 Mar 2002 03:24:28 -0800 Received: from spider.nic-se.se ([212.247.3.67]) by psg.com with esmtp (Exim 3.35 #1) id 16rGyB-0000GT-00 for idn@ops.ietf.org; Sat, 30 Mar 2002 03:24:27 -0800 Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id g2UBOCF23884 for ; Sat, 30 Mar 2002 12:24:12 +0100 (CET) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Sat, 30 Mar 2002 12:24:12 +0100 (CET) From: Mats Dufberg To: Subject: Re: [idn] phasing out ACE In-Reply-To: <20020330013941.15480.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Mar 30, 2002, 01:39 (-0000) D. J. Bernstein wrote: > 1. Should applications be required to handle UTF-8 properly, in > preparation for a UTF-8 world? > > The lessons of history are helpful at this point. If Keith Moore and his > buddies had---with or without Quoted-Printable---required 8-bit-clean > mail software in 1991, we wouldn't have sendmail's 8-bit bugs today. If > they had thought a little more broadly and fixed other protocols, we > would have been able to deploy UTF-8 years ago. Stop nagging about the claimed bugs in sendmail. We all know that your MTA is superior to any other know or futur MTA. OK? You had the same problem with mail as with DNS. The mailstandard said that the headers must be seven bit, and you wish for: And the lord said "Be 8 bit" and all installed MTA's were by the wish of the lord 8 bit clean. And the lord saw that mail was good. Contrary to your claim, the path that was taken has proved to be a safe path. The problems we have seen have not been due to bad protocol, but to bad implementations. > Here is one example of the variation in costs. Suppose we do a massive > redeployment of mail-displaying programs etc. to present IDNA names as > non-ASCII glyphs. Moving to UTF-8 then requires _another_ massive > redeployment of those programs. The first move (the introduction of IDN with ACE) will only require replacement of mail clients. And nothing will truely break without replacement. The second move will require the replacement of both servers and mail clients. That step must be taken with care. > Even better, if we scrap this 7-bit garbage and move directly to UTF-8, > _all_ programs will require at most one upgrade---maybe 0.5 on average. And the lord said "Replace 7 bit with 8 bit on the day of rest when nobody uses mail" and holy men did what the lord said, and nobody even noticed the change. Everything was replaced when people were at rest. The holy men saw that the path was good, and praised the lord. Mats ---------------------------------------------------------------------- Mats Dufberg ---------------------------------------------------------------------- From owner-idn@ops.ietf.org Sat Mar 30 13:05:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02770 for ; Sat, 30 Mar 2002 13:05:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rMrI-000Ak0-00 for idn-data@psg.com; Sat, 30 Mar 2002 09:41:44 -0800 Received: from dove.cc.ncu.edu.tw ([140.115.17.111]) by psg.com with esmtp (Exim 3.35 #1) id 16rMrH-000Ajr-00 for idn@ops.ietf.org; Sat, 30 Mar 2002 09:41:43 -0800 Received: from LocalHost ([140.115.5.82]) (authenticated tsenglm (0 bits)) by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g2UHfME20329 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Sun, 31 Mar 2002 01:41:24 +0800 (CST) Message-ID: <000f01c1d811$b7530700$5205738c@LocalHost> From: =?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= To: "Erik Nordmark" Cc: References: Subject: Re: [idn] URL encoding in html page Date: Sun, 31 Mar 2002 01:38:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Erik: Very interesting, Your mail let my mail server to do a specified mail-relay operation , Please see the following Cc: messages. But I found in the IDN mailing list , there are no relay assigned in the mail header. If there existed one technique to specified the relay path , then the UTF-8 domain name can work in this way ! UTF-8 IDN have many compatible problems between client and servers to identify the accepted name of server. The problems may happen in ACE IDN when it is used in the identification of web/mail servers. Because non-ASCII user will confused why the registered native coded-name can be used as the name identification of the servers . That is why a replaced corresponding ASCII URL of RealName will be work more easily. L.M.Tseng ----- Original Message ----- From: "Erik Nordmark" To: "David Leung (Neteka Inc.)" Cc: "Edmon Chung" ; Sent: Saturday, March 30, 2002 4:22 PM Subject: Re: [idn] URL encoding in html page > > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > Sender: owner-idn@ops.ietf.org > Precedence: bulk > > > ACE will work with "EXISTING" systems but ALL client end(browser, MUA, > etc) > > and SOME server(Apache, etc) end software actually needs to upgrade in > order > > to be able to recognize IDN and convert it to ACE back and forth, unless > we > > want to say that www.ietf.org that we are using nowadays is IDN already > : ) > > > > On the other hand, we see a lot of applications is moving towards the > > support of UTF8/Unicode on the client side, and this is going to be the > > future anyways... so why not just upgrade the server software, with one > > server software upgraded it will serve many many users... I dont > understand > > why no one see this simple math : ) > > David, > > You seem to be assuming that there would be only two entities involved > in the application protocol between the endpoints. The world isn't that > simple. > As an example, the mail I'm responding to contained 8 Received lines when I > got it. Thus, assuming the return path have the same number of SMTP hops, if > you had nameprepped-UTF-8 in your domain name in the from: line, if any of > those 8 relays didn't handle UTF-8 properly, this mail would not have > reached > you. Thus it isn't just a question of upgrading two pieces of software. > > Likewise for http. Upgrading my browser wouldn't do much good when > there are 2 caching proxies plus a socks host inside sun that look > at the http headers, and some number of load balancers (global and local), > ssl proxies, and akamai caches, that sit in front of many web servers. > > Dealing with this type of reality is part of the challenge in the transition > to a scheme which uses nameprepped-UTF-8 in application protocols. > > Erik > > > > From owner-idn@ops.ietf.org Sun Mar 31 21:08:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01773 for ; Sun, 31 Mar 2002 21:08:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rr4H-000EOW-00 for idn-data@psg.com; Sun, 31 Mar 2002 17:57:09 -0800 Received: from smtp22.singnet.com.sg ([165.21.101.202]) by psg.com with esmtp (Exim 3.35 #1) id 16rr4G-000EOQ-00 for idn@ops.ietf.org; Sun, 31 Mar 2002 17:57:08 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp22.singnet.com.sg (8.12.2/8.12.2) with SMTP id g311v5Rh013635 for ; Mon, 1 Apr 2002 09:57:05 +0800 Message-ID: <00f101c1d920$85e96190$0501000a@jamessonyviao> From: "James Seng" To: "IETF/IDN WG" Subject: [idn] copy & paste Date: Mon, 1 Apr 2002 09:57:04 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit One of the interesting arguments on IDNA is on copy & paste. Although the general copy & paste problem is out of scope for the group, let me drop a stone into the water. Clipboard mechanism can be either "dumb" (i take what you give me) to "smart" (understanding how to process and tag strings). Assumption: Applications which runs on OS that have smart clipboard are likely able to copy & paste properly since the clipboard can do the neccessary transcoding between different encodings, native, UTF-8, ACE etc between applications. Therefore, we only examine the cases whereby the clipboard is dumb. Case 1: Copy from IDNA Application (A1) to IDNA Application (A2) A1 is going to receive IDN in ACE format and would display the IDN correctly to the user. In order to display the IDN correctly to the user, A1 would display the IDN in some font encoding (not neccessary UTF-8). When copy occurs, the dumb clipboard will recieve it in font encoding and then paste it as-it-is to the A2. A2, occuring to the specification of IDNA, would transcode the font encoding it recieved from the paste to Unicode, then Nameprep it then apply Punycode which will gives us the exactly the same IDN as before. It would also display the IDN correctly. Therefore, resolving works, display works. Case 2: Copy from IDNA Application (A1) to non-IDNA Application (A2) A1 is going to receive IDN in ACE format and would display the IDN correctly to the user. In order to display the IDN correctly to the user, A1 would display the IDN in some font encoding (not neccessary UTF-8). When copy occurs, the dumb clipboard will recieve it in font encoding and then paste it as-it-is to the A2. A2 would take the font encoding and likely either to do name-check and fail or send-as-it-is. Either way, resolving fails, display works on A1 but not A2. Case 3: Copy from non-IDNA Application (A1) to IDNA Application (A2) A1 is going to receive IDN in ACE format but would not display the IDN correctly to the user, ie, it would display ACE to the user. When copy occurs, the dumb clipboard will recieve it in ACE, and then paste it as-it-is to A2. A2, occuring to the specification of IDNA, would transcode the ACE it recieved from the paste to Unicode, then Nameprep it then apply Punycode which will gives us the exactly the same ACE as before. It would also display the IDN properly (altho A1 wouldnt). Therefore, resolving works, display works on A2 but not A1. Case 4: Copy from non-IDNA Application (A1) to non-IDNA Application (A2) A1 is going to receive IDN in ACE format but would not display the IDN correctly to the user, ie, it would display ACE to the user. When copy occurs, the dumb clipboard will recieve it in ACE, and then paste it as-it-is to A2. A2 would take the ACE, thinking it is some valid domain name, continue send-it-as-it-is. It will also not display correctly to the user. Therefore, resolving works, display fail for both A1 & A2. Summary: Case 1: resolving works, display works. Case 2: resolving fails, display works on A1 but not A2. Case 3: resolving works, display works on A2 but not A1. Case 4: resolving works, display fail for both A1 & A2. Is there anything else I missed? -James Seng From owner-idn@ops.ietf.org Sun Mar 31 21:08:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01790 for ; Sun, 31 Mar 2002 21:08:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rr7A-000EUp-00 for idn-data@psg.com; Sun, 31 Mar 2002 18:00:08 -0800 Received: from smtp23.singnet.com.sg ([165.21.101.203]) by psg.com with esmtp (Exim 3.35 #1) id 16rr79-000EUj-00 for idn@ops.ietf.org; Sun, 31 Mar 2002 18:00:07 -0800 Received: from jamessonyviao (bb-203-125-134-191.singnet.com.sg [203.125.134.191]) by smtp23.singnet.com.sg (8.12.2/8.12.2) with SMTP id g31201CP015455 for ; Mon, 1 Apr 2002 10:00:01 +0800 Message-ID: <00fb01c1d920$ee9be6e0$0501000a@jamessonyviao> From: "James Seng" To: "IETF/IDN WG" Subject: [idn] Fw: Moving Towards UTF8 vs ASCII(ACE) Forever Date: Mon, 1 Apr 2002 10:00:00 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit fyi ----- Original Message ----- From: "Donald Eastlake 3rd" To: Sent: Monday, April 01, 2002 12:31 AM Subject: Re: Moving Towards UTF8 vs ASCII(ACE) Forever > There is now a standard way to encode URIs containing arbitrary UNICODE > characters. This is described in RFC 3275 (which is currently a Draft > Standard), in Section 4.3.3.1, and in the corresponding W3C document and > has appeared in other W3C documents, for exampe XML Base. > > Donald > > On 30 Mar 2002, [ISO-8859-1] Claus Färber wrote: > > > Date: 30 Mar 2002 16:13:00 +0200 > > From: "[ISO-8859-1] Claus Färber" > > To: ietf@ietf.org > > Subject: Re: Moving Towards UTF8 vs ASCII(ACE) Forever > > > > Keith Moore schrieb/wrote: > > > second, "ASCII for the rest of our lives" is a mischaracterization. > > > IDNA allows applications to accept and present IDNs in native > > > form, without requiring all applications and infrastructure to > > > upgrade before IDNs can be used. [...] > > > users don't care whether IDN queries are encoded on the wire. > > > > This depends on your definition of "on the wire"; if you want to > > IDNs to just work, you would have to put the ASCII version into > > URIs, too. Users *do* care about URIs. If you put the UTF-8 > > version (%-escaped or maybe even unencoded according to a revision > > of the URI specs) in the URI, they won't work with leagacy > > software anyway (so ACE has no advantages). > > > > Claus > > -- > > ------------------------ http://www.faerber.muc.de/ ------------------------ > > OpenPGP: DSS 1024/639680F0 E7A8 AADB 6C8A 2450 67EA AF68 48A5 0E63 6396 80F0 > > > > > From owner-idn@ops.ietf.org Sun Mar 31 21:51:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03309 for ; Sun, 31 Mar 2002 21:51:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rroQ-000Fxy-00 for idn-data@psg.com; Sun, 31 Mar 2002 18:44:50 -0800 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.35 #1) id 16rroP-000Fxs-00 for idn@ops.ietf.org; Sun, 31 Mar 2002 18:44:49 -0800 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.143]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GTVBMO00.I97; Sun, 31 Mar 2002 21:44:48 -0500 Message-ID: <008e01c1d927$3159b880$8f424244@anhmca.adelphia.net> From: "Doug Ewell" To: "James Seng" , "IETF/IDN WG" References: <00fb01c1d920$ee9be6e0$0501000a@jamessonyviao> Subject: Re: [idn] Fw: Moving Towards UTF8 vs ASCII(ACE) Forever Date: Sun, 31 Mar 2002 18:44:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Donald Eastlake 3rd wrote on the IETF list: > There is now a standard way to encode URIs containing arbitrary > UNICODE characters. This is described in RFC 3275 (which is > currently a Draft Standard), in Section 4.3.3.1, and in the > corresponding W3C document and has appeared in other W3C documents, > for exampe XML Base. So U+00E1 LATIN SMALL LETTER A WITH ACUTE (á), which is 0xC3 0xA1 in UTF-8, is encoded as "%C3%A1" (six bytes) according to RFC 3275. All BMP characters above U+07FF, including all CJK characters, take three UTF-8 bytes and thus nine RFC 3275 bytes. I thought CJK users and others wanted *better* compression. (No, David, I know you're not all the same person. I heard lots of voices saying the same thing.) -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Sun Mar 31 22:36:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04995 for ; Sun, 31 Mar 2002 22:36:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rsVg-000HWD-00 for idn-data@psg.com; Sun, 31 Mar 2002 19:29:32 -0800 Received: from mail.fm-net.ne.jp ([211.15.66.133]) by psg.com with esmtp (Exim 3.35 #1) id 16rsVf-000HW7-00 for idn@ops.ietf.org; Sun, 31 Mar 2002 19:29:31 -0800 Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163]) by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id MAA13709; Mon, 1 Apr 2002 12:29:26 +0900 Message-ID: <0d3501c1d92d$4d8a27a0$a303a8c0@bruce> From: "Bruce Thomson" To: "Doug Ewell" , "IETF idn working group" References: <00fb01c1d920$ee9be6e0$0501000a@jamessonyviao> <008e01c1d927$3159b880$8f424244@anhmca.adelphia.net> Subject: Re: [idn] Fw: Moving Towards UTF8 vs ASCII(ACE) Forever Date: Mon, 1 Apr 2002 12:28:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Doug Ewell wrote: > Donald Eastlake 3rd wrote on the IETF list: > > > There is now a standard way to encode URIs containing arbitrary > > UNICODE characters. This is described in RFC 3275 (which is > > currently a Draft Standard), in Section 4.3.3.1, and in the > > corresponding W3C document and has appeared in other W3C documents, > > for exampe XML Base. > > I thought CJK users and others wanted *better* compression. > They DO want it, but they want it for protocols where there is a severe length limitation on the encoded form. Correct me if I'm wrong but I don't think there's such a restriction on URIs. Presumably any extension to DNS which made Unicode explicity allowed would also allow longer strings? Bruce