From owner-idn-reg-policy Tue Mar 25 09:31:20 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PHVKZ25308 for idn-reg-policy-bks; Tue, 25 Mar 2003 09:31:20 -0800 (PST) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PHVIg25300 for ; Tue, 25 Mar 2003 09:31:18 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 25 Mar 2003 09:31:09 -0800 To: idn-reg-policy@imc.org From: Paul Hoffman / IMC Subject: New Internet Draft on registering IDNs Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings. I have just submitted a new Internet Draft that gives suggestions on how to register IDNs. You can find a link to the draft at the web site for this mailing list at . Comments are, of course, welcome. This document is different than the JET document in many ways. It is meant to be generic and usable by anyone, not just registries using CJK characters. It also attempts to make the registry policy easier and more predictable from the outside. I have heard that other folks will also be preparing Internet Drafts on this issue, so it will be good to see what the differences are. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Tue Mar 25 09:31:21 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PHVLQ25309 for idn-reg-policy-bks; Tue, 25 Mar 2003 09:31:21 -0800 (PST) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PHVJg25304 for ; Tue, 25 Mar 2003 09:31:19 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 25 Mar 2003 09:30:13 -0800 To: idn-reg-policy@imc.org From: Paul Hoffman / IMC Subject: Starting the list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings. There are now more than 50 people on this list, so it is a good time to make it active. The web site for this mailing list at . The main purpose of this list it to have an open discussion about the needs of registries when dealing with IDNs. There will be an active discussion of this at IDNConnect at the end of May, so this list can give attendees a lot of preparatory material to think about. More information on IDNConnect can be found at ; registration will start soon. BTW, if anyone has suggestions for other useful information to put on the web site, please let me know. I would like to restrict the list of documents to those that have been submitted and Internet Drafts so that there are no possible copyright issues. However, if there are other documents such as presentations that should be listed, I can add links to them. Please let me know off-line, not on the mailing list. Thanks! --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Wed Mar 26 02:50:26 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QAoQ127688 for idn-reg-policy-bks; Wed, 26 Mar 2003 02:50:26 -0800 (PST) Received: from twnic.net.tw (twnic.net.tw [211.72.210.250]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QAoOg27678; Wed, 26 Mar 2003 02:50:24 -0800 (PST) Received: from twnic.net.tw (pc138.twnic.net.tw [211.72.211.138]) by twnic.net.tw (8.12.8/8.12.8) with ESMTP id h2QAoOwi028104; Wed, 26 Mar 2003 18:50:24 +0800 Message-ID: <3E818686.6010307@twnic.net.tw> Date: Wed, 26 Mar 2003 18:52:54 +0800 From: Erin Chen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Paul Hoffman / IMC CC: idn-reg-policy@imc.org Subject: Re: New Internet Draft on registering IDNs References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi! Paul and dear all, Thanks Paul for propose draft-hoffman-idn-reg-00.txt . I have expressed some of my opinions, and I would like to know others comments. ----------cut------------- 2.3 Table for a zone that has no language restrictions A registry that does not restrict the number of languages will probably allow a much wider range of characters to be used in names. At the same time, that registry cannot easily use character variants because variants for one language will be different from the variants used in a different language. To handle conflicting variants among languages, the registry can choose to have no variants for any base characters, or can choose to have variants for a subset of the languages that are expressible in the characters allowed. -----------cut------------ A registry that does not restrict the number of languages here means the registry would possible offer the registration service for the languages which have overlapped variants. For the purpose of decrease confusion, cybersquating and DRP, so, how to let such registration result consist with the principle described in 2.2 is very important. ---------cut-------------- The table would look like: U+2200 U+2201|U+0043 U+2237|U+003AU+003A U+2202|U+0064;U+03B4 ---------cut-------------- As the table format describe in the document, the tabel would look like: U+2200 U+2201|U+0043 U+2237|U+003A:U+003A U+2202|U+0064:U+03B4 Isn't it? --------cut------------ Option 3 is likely to cause the most confusion with users because including some variants will cause a name to be found, bout using other variants will cause the name to be not found. ---------cut----------- I think the option 3 is a combination case of option 1 and option 2. If option 1 and option 2 is possible for implement. So implement option 3 would also possible for implement. The result would be the combination result of option 1 and option2. The key point has to consider is whether and which language has the requirements of allocate some variant labels for resolution and block other variant labels for prevent later registration at the same time. ---------cut--------- If the registry chose option 3, it must use an unspecified method to keep the elements in the registration bundle cohesive. This option SHOULD NOT be used except under carefully-controlled circumstances. ---------cut---------- I know the intention of this document is for the generic purpose not like IDN Admin Guideline just forcus on CJK characters. So, I suppose that, it is natural that a generic principle should comprise the specific language requirement like CJK Guideline has explain. At least does not just mention how impossible/difficult for registry choice option 3. Why need "Allocate some labels and block some other labels" ? That's because the variants could be seperate into 2 categories. One for allocate and one for block with a base domain name label. The allocated labels would put in the zone file for the same destination resolution with the base domain name. However the blocked labels would prevent the latter registration from others. So, if th registry make more explain to the public about his registration policy regard the variant table very clearly, and when user register a domain name let user recognize about what labels have been allocated and what labels have been blocked, that would be improve the user experience. ----------cut------------ $ORIGIN example.com. pale IN NS x.example.com. pale IN NS y.example.com. pa1e IN DNAME pale.example.com. ----------cut------------- As I know DNAME is support by BIND9 not BIND8, is it possible to let the users know if do not use DNAME the would have possible serious delegation problem? Such as there might be too much zone file have to maintain bye users, user has to keep the variant labels setting consistent. Erin Chen, TWNIC Paul Hoffman / IMC wrote: > > Greetings. I have just submitted a new Internet Draft that gives > suggestions on how to register IDNs. You can find a link to the draft > at the web site for this mailing list at > . Comments are, of course, welcome. > > This document is different than the JET document in many ways. It is > meant to be generic and usable by anyone, not just registries using > CJK characters. It also attempts to make the registry policy easier > and more predictable from the outside. I have heard that other folks > will also be preparing Internet Drafts on this issue, so it will be > good to see what the differences are. > > --Paul Hoffman, Director > --Internet Mail Consortium From owner-idn-reg-policy Wed Mar 26 08:16:09 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QGG9R23159 for idn-reg-policy-bks; Wed, 26 Mar 2003 08:16:09 -0800 (PST) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QGG7g23155 for ; Wed, 26 Mar 2003 08:16:07 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3E818686.6010307@twnic.net.tw> References: <3E818686.6010307@twnic.net.tw> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 26 Mar 2003 08:16:08 -0800 To: idn-reg-policy@imc.org From: Paul Hoffman / IMC Subject: Re: New Internet Draft on registering IDNs Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 6:52 PM +0800 3/26/03, Erin Chen wrote: >Thanks Paul for propose draft-hoffman-idn-reg-00.txt . >I have expressed some of my opinions, and I would like to know others >comments. Yes, it would be great to have more comments here. >----------cut------------- >2.3 Table for a zone that has no language restrictions > >A registry that does not restrict the number of languages will probably >allow a much wider range of characters to be used in names. At the same >time, that registry cannot easily use character variants because >variants for one language will be different from the variants used in a >different language. To handle conflicting variants among languages, the >registry can choose to have no variants for any base characters, or can >choose to have variants for a subset of the languages that are >expressible in the characters allowed. >-----------cut------------ > >A registry that does not restrict the number of languages here means the >registry would possible offer the registration service for the languages >which have overlapped variants. For the purpose of decrease confusion, >cybersquating and DRP, so, how to let such registration result consist with >the principle described in 2.2 is very important. It would be great if you could suggest some wording about how such a registry would work. I can't think of any way it could, but that doesn't mean it is impossible. >---------cut-------------- >The table would look like: >U+2200 >U+2201|U+0043 >U+2237|U+003AU+003A >U+2202|U+0064;U+03B4 >---------cut-------------- > >As the table format describe in the document, the tabel would look like: >U+2200 >U+2201|U+0043 >U+2237|U+003A:U+003A >U+2202|U+0064:U+03B4 >Isn't it? Your second change (to "U+2202|U+0064:U+03B4") is correct. The first one is not, however. The text above said: >- allows the PROPORTION character (U+2237) which has one variant which > is the string COLON (U+003A) COLON (U+003A) The way to show a string is to append all the characters together with no delimiters between them. >--------cut------------ >Option 3 is likely to cause the most confusion with users because >including some variants will cause a name to be found, bout using >other variants will cause the name to be not found. >---------cut----------- > >I think the option 3 is a combination case of option 1 and option 2. >If option 1 and option 2 is possible for implement. So implement >option 3 would also possible for implement. The result would be >the combination result of option 1 and option2. We fully agree. The JET document shows a way that it can be implemented. I very purposely tried not to say "it can't be done", just "it will cause the most confusion for users". > The key point >has to consider is whether and which language has the requirements >of allocate some variant labels for resolution and block other variant >labels for prevent later registration at the same time. Right. Unfortunately, the current draft of the JET document is silent about these requirements, and from talking to some JET members, I haven't heard any good description of why Chinese needs both. In fact, I remember many long conversations with CNNIC and TWNIC people a few years ago where they all said that just blocking (with no allocating) was fine. Maybe opinions in the Chinese language community have changed since then, but I haven't seen any written down in the JET document yet. Maybe the next version will cover this clearly. >---------cut--------- >If the registry chose option 3, it must use an unspecified method to >keep the elements in the registration bundle cohesive. This option >SHOULD NOT be used except under carefully-controlled circumstances. >---------cut---------- > >I know the intention of this document is for the generic purpose not like >IDN Admin Guideline just forcus on CJK characters. Exactly. >So, I suppose that, it is natural that a generic principle should comprise >the specific language requirement like CJK Guideline has explain. At least >does not just mention how impossible/difficult for registry choice option 3. I never said "impossible" because I am sure it is not impossible. I trust the JET people's analysis that it can be done. >Why need "Allocate some labels and block some other labels" ? That's >because the variants could be seperate into 2 categories. One for allocate >and one for block with a base domain name label. My apologies, but I don't understand that. The fact that it *could* be done does not explain why it is needed. Could you be clearer on the *need*? It would be helpful in this document (and in the JET document) if the actual need is clearly stated. >The allocated labels would put in the zone file for the same destination >resolution with the base domain name. However the blocked labels >would prevent the latter registration from others. > >So, if th registry make more explain to the public about his >registration policy >regard the variant table very clearly, and when user register a domain name >let user recognize about what labels have been allocated and what labels have >been blocked, that would be improve the user experience. True, but it would only help a little bit. Telling the users what has been done does not let them predict what will happen. If a registry says "we have mapped these characters to these other ones for this language reason", users will understand that; if a registry says "we have blocked these characters for this language reason", users will understand that. But I don't know how many users will understand "we have mapped some of them but blocked other ones even though the language reason is the same". If there is a good language reason for differentiating the two cases, that would be wonderful. >----------cut------------ > $ORIGIN example.com. > pale IN NS x.example.com. > pale IN NS y.example.com. > pa1e IN DNAME pale.example.com. >----------cut------------- >As I know DNAME is support by BIND9 not BIND8, is it possible to >let the users know if do not use DNAME the would have possible serious >delegation problem? Such as there might be too much zone file have to >maintain bye users, user has to keep the variant labels setting consistent. I don't understand your question. Why would there be "serious delegation problems"? Having "too many zone files" is not a problem if the users have the tools to manage them. If the users don't have the tools, then the additional zones would give bad information, but that will be fixed when users complain. This isn't any different than the current DNS when people make mistakes that affect users. The big point is that the effects can only affect the owner of the registration bundle, and that a cybersquatter can't cause the problems. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Wed Mar 26 12:25:14 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QKPE908255 for idn-reg-policy-bks; Wed, 26 Mar 2003 12:25:14 -0800 (PST) Received: from holodoc.allard.nu (postfix@holodoc.allard.nu [212.112.184.131]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QKPBg08249; Wed, 26 Mar 2003 12:25:12 -0800 (PST) Received: from iis.se (as2-6-1.nvik.s.bonet.se [217.215.75.3]) by holodoc.allard.nu (Postfix) with ESMTP id 2D65496D3; Wed, 26 Mar 2003 21:25:14 +0100 (CET) Message-ID: <3E820CB0.1000605@iis.se> Date: Wed, 26 Mar 2003 21:25:20 +0100 From: Staffan Hagnell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC Cc: idn-reg-policy@imc.org Subject: Re: New Internet Draft on registering IDNs References: <3E818686.6010307@twnic.net.tw> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: What happens when the Allocation all labels policy is used and the input label contains several characters with equivalents? E.g. if there 6 base characters with one variant" each in the input label, will the owner of the registration have to keep 2 raised to 6 = 64 zones? Best regards - Staffan Hagnell Paul Hoffman / IMC wrote: > > At 6:52 PM +0800 3/26/03, Erin Chen wrote: > >> Thanks Paul for propose draft-hoffman-idn-reg-00.txt . >> I have expressed some of my opinions, and I would like to know others >> comments. > > > Yes, it would be great to have more comments here. > >> ----------cut------------- >> 2.3 Table for a zone that has no language restrictions >> >> A registry that does not restrict the number of languages will probably >> allow a much wider range of characters to be used in names. At the same >> time, that registry cannot easily use character variants because >> variants for one language will be different from the variants used in a >> different language. To handle conflicting variants among languages, the >> registry can choose to have no variants for any base characters, or can >> choose to have variants for a subset of the languages that are >> expressible in the characters allowed. >> -----------cut------------ >> >> A registry that does not restrict the number of languages here means the >> registry would possible offer the registration service for the languages >> which have overlapped variants. For the purpose of decrease confusion, >> cybersquating and DRP, so, how to let such registration result >> consist with >> the principle described in 2.2 is very important. > > > It would be great if you could suggest some wording about how such a > registry would work. I can't think of any way it could, but that > doesn't mean it is impossible. > >> ---------cut-------------- >> The table would look like: >> U+2200 >> U+2201|U+0043 >> U+2237|U+003AU+003A >> U+2202|U+0064;U+03B4 >> ---------cut-------------- >> >> As the table format describe in the document, the tabel would look like: >> U+2200 >> U+2201|U+0043 >> U+2237|U+003A:U+003A >> U+2202|U+0064:U+03B4 >> Isn't it? > > > Your second change (to "U+2202|U+0064:U+03B4") is correct. The first > one is not, however. The text above said: > >> - allows the PROPORTION character (U+2237) which has one variant which >> is the string COLON (U+003A) COLON (U+003A) > > The way to show a string is to append all the characters together with > no delimiters between them. > > >> --------cut------------ >> Option 3 is likely to cause the most confusion with users because >> including some variants will cause a name to be found, bout using >> other variants will cause the name to be not found. >> ---------cut----------- >> >> I think the option 3 is a combination case of option 1 and option 2. >> If option 1 and option 2 is possible for implement. So implement >> option 3 would also possible for implement. The result would be >> the combination result of option 1 and option2. > > > We fully agree. The JET document shows a way that it can be > implemented. I very purposely tried not to say "it can't be done", > just "it will cause the most confusion for users". > >> The key point >> has to consider is whether and which language has the requirements >> of allocate some variant labels for resolution and block other variant >> labels for prevent later registration at the same time. > > > Right. Unfortunately, the current draft of the JET document is silent > about these requirements, and from talking to some JET members, I > haven't heard any good description of why Chinese needs both. In fact, > I remember many long conversations with CNNIC and TWNIC people a few > years ago where they all said that just blocking (with no allocating) > was fine. Maybe opinions in the Chinese language community have > changed since then, but I haven't seen any written down in the JET > document yet. Maybe the next version will cover this clearly. > >> ---------cut--------- >> If the registry chose option 3, it must use an unspecified method to >> keep the elements in the registration bundle cohesive. This option >> SHOULD NOT be used except under carefully-controlled circumstances. >> ---------cut---------- >> >> I know the intention of this document is for the generic purpose not >> like >> IDN Admin Guideline just forcus on CJK characters. > > > Exactly. > >> So, I suppose that, it is natural that a generic principle should >> comprise >> the specific language requirement like CJK Guideline has explain. At >> least >> does not just mention how impossible/difficult for registry choice >> option 3. > > > I never said "impossible" because I am sure it is not impossible. I > trust the JET people's analysis that it can be done. > >> Why need "Allocate some labels and block some other labels" ? That's >> because the variants could be seperate into 2 categories. One for >> allocate >> and one for block with a base domain name label. > > > My apologies, but I don't understand that. The fact that it *could* be > done does not explain why it is needed. Could you be clearer on the > *need*? It would be helpful in this document (and in the JET document) > if the actual need is clearly stated. > >> The allocated labels would put in the zone file for the same destination >> resolution with the base domain name. However the blocked labels >> would prevent the latter registration from others. >> >> So, if th registry make more explain to the public about his >> registration policy >> regard the variant table very clearly, and when user register a >> domain name >> let user recognize about what labels have been allocated and what >> labels have >> been blocked, that would be improve the user experience. > > > True, but it would only help a little bit. Telling the users what has > been done does not let them predict what will happen. If a registry > says "we have mapped these characters to these other ones for this > language reason", users will understand that; if a registry says "we > have blocked these characters for this language reason", users will > understand that. But I don't know how many users will understand "we > have mapped some of them but blocked other ones even though the > language reason is the same". If there is a good language reason for > differentiating the two cases, that would be wonderful. > >> ----------cut------------ >> $ORIGIN example.com. >> pale IN NS x.example.com. >> pale IN NS y.example.com. >> pa1e IN DNAME pale.example.com. >> ----------cut------------- >> As I know DNAME is support by BIND9 not BIND8, is it possible to >> let the users know if do not use DNAME the would have possible serious >> delegation problem? Such as there might be too much zone file have to >> maintain bye users, user has to keep the variant labels setting >> consistent. > > > I don't understand your question. Why would there be "serious > delegation problems"? Having "too many zone files" is not a problem if > the users have the tools to manage them. If the users don't have the > tools, then the additional zones would give bad information, but that > will be fixed when users complain. This isn't any different than the > current DNS when people make mistakes that affect users. The big point > is that the effects can only affect the owner of the registration > bundle, and that a cybersquatter can't cause the problems. > > --Paul Hoffman, Director > --Internet Mail Consortium From owner-idn-reg-policy Wed Mar 26 14:28:49 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QMSn813219 for idn-reg-policy-bks; Wed, 26 Mar 2003 14:28:49 -0800 (PST) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QMSjg13211; Wed, 26 Mar 2003 14:28:45 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3E820CB0.1000605@iis.se> References: <3E818686.6010307@twnic.net.tw> <3E820CB0.1000605@iis.se> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 26 Mar 2003 14:28:50 -0800 To: Staffan Hagnell From: Paul Hoffman / IMC Subject: Re: New Internet Draft on registering IDNs Cc: idn-reg-policy@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:25 PM +0100 3/26/03, Staffan Hagnell wrote: >What happens when the Allocation all labels policy is used and the >input label contains several characters with equivalents? > >E.g. if there 6 base characters with one variant" each in the >input label, will the owner of the registration have to keep 2 >raised to 6 = 64 zones? Exactly right. If this wasn't clear from the draft, please suggest some wording to make it more so. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Wed Mar 26 23:33:25 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2R7XPr08304 for idn-reg-policy-bks; Wed, 26 Mar 2003 23:33:25 -0800 (PST) Received: from holodoc.allard.nu (postfix@holodoc.allard.nu [212.112.184.131]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2R7XMg08298; Wed, 26 Mar 2003 23:33:23 -0800 (PST) Received: from iis.se (as2-6-1.nvik.s.bonet.se [217.215.75.3]) by holodoc.allard.nu (Postfix) with ESMTP id 0BE0D96D3; Thu, 27 Mar 2003 08:33:21 +0100 (CET) Message-ID: <3E82A944.6040703@iis.se> Date: Thu, 27 Mar 2003 08:33:24 +0100 From: Staffan Hagnell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC Cc: idn-reg-policy@imc.org Subject: Re: New Internet Draft on registering IDNs References: <3E818686.6010307@twnic.net.tw> <3E820CB0.1000605@iis.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Well, my point is that the "Allocation all labels" policy could be a bit messy for the owner. Therefore it would be proper to have some sort of information about that, for example: If the input label contains several characters that have equivalents, the owner could end up having to take care of large number of zones. For instance, if DIGIT ONE is a variant of LATIN SMALL LETTER L, the owner of the domain name llllll.com will have to manage 64 zones. -Staffan Paul Hoffman / IMC wrote: > > At 9:25 PM +0100 3/26/03, Staffan Hagnell wrote: > >> What happens when the Allocation all labels policy is used and >> the input label contains several characters with equivalents? >> >> E.g. if there 6 base characters with one variant" each in the >> input label, will the owner of the registration have to keep 2 raised >> to 6 = 64 zones? > > > Exactly right. If this wasn't clear from the draft, please suggest > some wording to make it more so. > > --Paul Hoffman, Director > --Internet Mail Consortium From owner-idn-reg-policy Thu Mar 27 06:34:39 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2REYdd18370 for idn-reg-policy-bks; Thu, 27 Mar 2003 06:34:39 -0800 (PST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2REYbg18362; Thu, 27 Mar 2003 06:34:37 -0800 (PST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h2REYMNn1202586; Thu, 27 Mar 2003 15:34:22 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1055) id C5468110F0; Thu, 27 Mar 2003 15:34:25 +0100 (CET) Date: Thu, 27 Mar 2003 15:34:25 +0100 From: Stephane Bortzmeyer To: Paul Hoffman / IMC Cc: idn-reg-policy@imc.org Subject: Re: New Internet Draft on registering IDNs Message-ID: <20030327143425.GA11197@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 25, 2003 at 09:31:09AM -0800, Paul Hoffman / IMC wrote a message of 16 lines which said: > Greetings. I have just submitted a new Internet Draft that gives > suggestions on how to register IDNs. You can find a link to the draft > at the web site for this mailing list at > . Comments are, of course, > welcome. Well, to summary, I find it quite good, much simpler and more understandable than draft-jseng-idn-admin-02, specially for non-CJK countries. > A "string" is an ordered set of one or more characters. > > This document discusses characters that have equivalent or > near-equivalent characters or strings. The "base character" is the Shouldn't we use "code point" instead of "character"? > If the base character has more than one variant, the variants > are separated by a colon (":", ASCII 0x3A). Strings are given without > any intervening spaces ... > U+2202|U+0064;U+03B4 ^ Isn't it a typo? > A registry has three options for how to handle the case where > the registration bundle has more than one label. The policy options are: > > 1) Allocate all labels to the same registrant, making > the zone information identical to that of the input label. > > 2) Block all labels so they cannot be registered in the > future. > > 3) Allocate some labels and block some other labels. This entire scheme does not discuss financial issues. For instance, in Option 1, it will mean that a registrant will get more labels than he paid for. The registry will not be happy :-) In Option 2, OTOH, it means that there is no option for the registrant to activate some variants. Do you think this case (all variants are blocked and some are allocated to the same registrant, if he chooses so and if he pays, may be a smaller price than a "real" domain) is covered by Option 3? If so, I suggest to rewrite it to make it clearer. > Option 3 is likely to cause the most confusion with users because > including some variants will cause a name to be found, bout using > other variants will cause the name to be not found. If the variants actually allocated are choosen by the registrant, it is up to her to minimize confusion. From owner-idn-reg-policy Thu Mar 27 06:53:30 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RErUa20241 for idn-reg-policy-bks; Thu, 27 Mar 2003 06:53:30 -0800 (PST) Received: from [63.202.92.152] (adsl-63-202-92-156.dsl.snfc21.pacbell.net [63.202.92.156]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RErQg20228; Thu, 27 Mar 2003 06:53:26 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3E82A944.6040703@iis.se> References: <3E818686.6010307@twnic.net.tw> <3E820CB0.1000605@iis.se> <3E82A944.6040703@iis.se> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 27 Mar 2003 06:53:20 -0800 To: Staffan Hagnell From: Paul Hoffman / IMC Subject: Re: New Internet Draft on registering IDNs Cc: idn-reg-policy@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:33 AM +0100 3/27/03, Staffan Hagnell wrote: >Well, my point is that the "Allocation all labels" policy could be a >bit messy for the owner. Therefore it would be proper to have some >sort of information about that, for example: > >If the input label contains several characters that have >equivalents, the owner could end up having to take care of large >number of zones. For instance, if DIGIT ONE is a variant of LATIN >SMALL LETTER L, the owner of the domain name llllll.com will have to >manage 64 zones. Sounds fine (with a slight rewording to "llllll.example.com"). I'll add a parallel warning under the blocking section with a different example. If the input label contains characters that have equivalents, Internet users who don't know what the base characters used in the registration will not know what character to type in to get a DNS response. For instance, if DIGIT ONE is a variant of LATIN SMALL LETTER L, and LATIN SMALL LETTER L is a variant of DIGIT ONE, the user who sees "pale.example.com" will no know whether to type a "1" or a "l" after the "pa" in the first label. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Thu Mar 27 07:46:26 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RFkQe25059 for idn-reg-policy-bks; Thu, 27 Mar 2003 07:46:26 -0800 (PST) Received: from [63.202.92.152] (adsl-63-202-92-156.dsl.snfc21.pacbell.net [63.202.92.156]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RFkNg25054; Thu, 27 Mar 2003 07:46:23 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20030327143425.GA11197@nic.fr> References: <20030327143425.GA11197@nic.fr> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 27 Mar 2003 07:46:20 -0800 To: Stephane Bortzmeyer From: Paul Hoffman / IMC Subject: Re: New Internet Draft on registering IDNs Cc: idn-reg-policy@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:34 PM +0100 3/27/03, Stephane Bortzmeyer wrote: >Well, to summary, I find it quite good, much simpler and more >understandable than draft-jseng-idn-admin-02, specially for non-CJK >countries. Thanks! > > A "string" is an ordered set of one or more characters. >> >> This document discusses characters that have equivalent or >> near-equivalent characters or strings. The "base character" is the > >Shouldn't we use "code point" instead of "character"? Character is more understandable, and I don't see any place in the document where a character wouldn't be considered its code point, but I'm open to changing it. > > If the base character has more than one variant, the variants >> are separated by a colon (":", ASCII 0x3A). Strings are given without >> any intervening spaces >... >> U+2202|U+0064;U+03B4 > ^ > Isn't it a typo? Yes. > > A registry has three options for how to handle the case where >> the registration bundle has more than one label. The policy options are: >> >> 1) Allocate all labels to the same registrant, making >> the zone information identical to that of the input label. >> >> 2) Block all labels so they cannot be registered in the >> future. >> >> 3) Allocate some labels and block some other labels. > >This entire scheme does not discuss financial issues. Correct. It would be unwise to predict how registries will act on this, especially over time. > For instance, in >Option 1, it will mean that a registrant will get more labels than he >paid for. The registry will not be happy :-) That's not necessarily true. Registries can decide whether or not to charge more for names with bundles. Note that in option 2 and 3, the registry is prevented from making money, so they might charge for bundles regardless of which option they choose. >In Option 2, OTOH, it means that there is no option for the registrant >to activate some variants. Right. > Do you think this case (all variants are >blocked and some are allocated to the same registrant, if he chooses >so and if he pays, may be a smaller price than a "real" domain) is >covered by Option 3? That wasn't my intention, but it is an interesting thought. My intention for option 3, which is what is discussed in the JET document, is that the registry decides using the table which names are allocated and which are blocked. >If the variants actually allocated are choosen by the registrant, it >is up to her to minimize confusion. You are proposing something different: the registry allows the registrant to pick which names from the bundle go in either category. It will still have the same problem of option 3, namely typical users of the DNS won't be able to predict what they should type, but it sounds "nicer" than option 3. What do other folks on this list think of that idea? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Thu Mar 27 15:11:57 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RNBvC19770 for idn-reg-policy-bks; Thu, 27 Mar 2003 15:11:57 -0800 (PST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RNBpg19760; Thu, 27 Mar 2003 15:11:51 -0800 (PST) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HCF00B0FK9SJQ@firewall.wcom.com>; Thu, 27 Mar 2003 23:08:16 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HCF00701K9R8B@dgismtp02.wcomnet.com>; Thu, 27 Mar 2003 23:08:16 +0000 (GMT) Received: from vint.wcom.com ([166.50.135.56]) by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HCF0058UK9MZX@dgismtp02.wcomnet.com>; Thu, 27 Mar 2003 23:08:15 +0000 (GMT) Date: Thu, 27 Mar 2003 14:40:47 -0300 From: "vinton g. cerf" Subject: Re: New Internet Draft on registering IDNs In-reply-to: X-Sender: vcerf@pop.wcomnet.com To: Paul Hoffman / IMC , Stephane Bortzmeyer Cc: idn-reg-policy@imc.org Message-id: <5.2.0.9.2.20030327163511.02533da0@pop.wcomnet.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; charset=us-ascii References: <20030327143425.GA11197@nic.fr> <20030327143425.GA11197@nic.fr> Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: paul, et al, the alternative of allowing the registrant to adjust the subset that is registered from the "bundle" has the nice property that it is the registrant's choice (and responsibility) for the resulting ease of use or lack thereof. I am not sure what to say about the economic position to be taken and perhaps this could be best left to the TLD operator. Excessive "greed" if you will pardon the use of the word, might prove to be a poor business choice, so there might be some balance between a single price regardless of the size of the selected bundle subset and a price equal to registering N distinct SLDs. Intuition is hard to rely on here since the properties of different languages and chosen rules for "equivalence" will lead to quite a variety of different cases, I would think. Vint (p.s. I am particpating in this discussion as an interested party but I hope no one misunderstands any of my opinions as representative of the ICANN board or its IDN committee) At 07:46 AM 3/27/2003 -0800, Paul Hoffman / IMC wrote: >You are proposing something different: the registry allows the registrant to pick which names from the bundle go in either category. It will still have the same problem of option 3, namely typical users of the DNS won't be able to predict what they should type, but it sounds "nicer" than option 3. > >What do other folks on this list think of that idea? Vint Cerf SVP Architecture & Technology WorldCom 22001 Loudoun County Parkway, F2-4115 Ashburn, VA 20147 703 886 1690 (v806 1690) 703 886 0047 fax From owner-idn-reg-policy Thu Mar 27 17:23:36 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2S1NaL28744 for idn-reg-policy-bks; Thu, 27 Mar 2003 17:23:36 -0800 (PST) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2S1NRg28734; Thu, 27 Mar 2003 17:23:27 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.2.0.9.2.20030327163511.02533da0@pop.wcomnet.com> References: <20030327143425.GA11197@nic.fr> <20030327143425.GA11197@nic.fr> <5.2.0.9.2.20030327163511.02533da0@pop.wcomnet.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 27 Mar 2003 17:23:24 -0800 To: "vinton g. cerf" , Stephane Bortzmeyer From: Paul Hoffman / IMC Subject: Re: New Internet Draft on registering IDNs Cc: idn-reg-policy@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:40 PM -0300 3/27/03, vinton g. cerf wrote: >the alternative of allowing the registrant to adjust the subset that >is registered from the "bundle" has the nice property that it is the >registrant's choice (and responsibility) for the resulting ease of >use or lack thereof. Indeed. Novice registrants could start with "let me handle the most likely name and block the rest", and then migrate to fuller use when they are ready. Within a few years, when registrant-level bundle handlers are common, users will probably mostly go towards all-resolving. In thinking about this more, there are some downsides as well: - Much more of a hassle for the registry because now they have to manage the individual elements of the bundle manually instead of automatically - Much less predictable to DNS users of the zone > I am not sure what to say about the economic position to be taken >and perhaps this could be best left to the TLD operator. Right. RFCs usually don't talk about economics. > Excessive "greed" if you will pardon the use of the word, might >prove to be a poor business choice, so there might be some balance >between a single price regardless of the size of the selected bundle >subset and a price equal to registering N distinct SLDs. I think any registry reading this document (or the JET document, or others) will be able to quickly figure out the costs associated with the work they are taking on. We don't need to list it for them any more than BGP documents talk about the financial aspects of routing choices. >Intuition is hard to rely on here since the properties of different >languages and chosen rules for "equivalence" will lead to quite a >variety of different cases, I would think. Which is exactly the reason this document is more generic than the JET document. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Fri Mar 28 08:51:31 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SGpVe07228 for idn-reg-policy-bks; Fri, 28 Mar 2003 08:51:31 -0800 (PST) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SGpTg07223 for ; Fri, 28 Mar 2003 08:51:29 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 28 Mar 2003 08:51:28 -0800 To: idn-reg-policy@imc.org From: Paul Hoffman / IMC Subject: Updates to the web site Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have updated the web site for this discussion () with pointers to two more documents: - Japanese characters in Internationalized Domain Name label (draft-yoneya-idn-jpchar) - Chinese Domain Name Consortium (CDNC) Status Update for IDN, a PowerPoint presentation made at the ICANN meeting in March, 2003 When there is any concrete documents from ICANN about the IDN registration policy discussions this week, I will post them. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Mon Mar 31 04:59:24 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VCxOJM013593 for ; Mon, 31 Mar 2003 04:59:24 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VCxOH9013592 for idn-reg-policy-bks; Mon, 31 Mar 2003 04:59:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from sina.sharif.edu (sina.Sharif.AC.IR [194.225.40.9]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VCx9JM013471; Mon, 31 Mar 2003 04:59:12 -0800 (PST) Received: from bamdad.org (IDENT:root@bamdad.org [81.31.160.190]) by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id h2VCugF26734; Mon, 31 Mar 2003 17:26:50 +0430 Received: from localhost (roozbeh@localhost) by bamdad.org (8.11.6/8.11.6) with ESMTP id h2VD5ia07732; Mon, 31 Mar 2003 17:36:01 +0430 X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs Date: Mon, 31 Mar 2003 17:35:44 +0430 (IRST) From: Roozbeh Pournader X-X-Sender: roozbeh@gilas.bamdad.org To: Paul Hoffman / IMC cc: Stephane Bortzmeyer , Subject: Re: New Internet Draft on registering IDNs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 27 Mar 2003, Paul Hoffman / IMC wrote: > At 3:34 PM +0100 3/27/03, Stephane Bortzmeyer wrote: > >Well, to summary, I find it quite good, much simpler and more > >understandable than draft-jseng-idn-admin-02, specially for non-CJK > >countries. > > Thanks! I guess Stephane really means LGC (Latin, Greek, Cyrillic, ...) countries. The requirements of Indic, Hebrew and Arabic scripts in IDN may prove to be more complex than CJK. roozbeh From owner-idn-reg-policy Mon Mar 31 06:10:23 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VEANJM017935 for ; Mon, 31 Mar 2003 06:10:23 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VEAN3E017934 for idn-reg-policy-bks; Mon, 31 Mar 2003 06:10:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from sina.sharif.edu (sina.Sharif.AC.IR [194.225.40.9]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VEAFJM017927 for ; Mon, 31 Mar 2003 06:10:17 -0800 (PST) Received: from bamdad.org (IDENT:root@bamdad.org [81.31.160.190]) by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id h2VEAFF19664 for ; Mon, 31 Mar 2003 18:40:15 +0430 Received: from localhost (roozbeh@localhost) by bamdad.org (8.11.6/8.11.6) with ESMTP id h2VEJuL08310 for ; Mon, 31 Mar 2003 18:49:56 +0430 X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs Date: Mon, 31 Mar 2003 18:49:56 +0430 (IRST) From: Roozbeh Pournader X-X-Sender: roozbeh@gilas.bamdad.org To: IDN registration policy list Subject: Comparison of hoffman-idn-reg and jseng-idn-admin Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: With a personal and an Arabic script mindset, this is just a basic comparison: I like hoffman-idn-reg, since it's short and provides a solution for simple Latin-like scripts. I can point someone not very technical to the I-D and have him understand it. I also like it, since it sometimes tries not to be ignorant, and mentions things like: A registry MUST NOT blindly combine multiple tables which have overlapping equivalences. Instead, the registry MUST carefully analyze every instance in the combined table where a base character has one or more different variants and select the desired set of variants for the base character. (But unfortunately doesn't suggest any guidelines when doing so.) Unfortunately, the list ends here. Specifically, there are fetures that are *required* for Arabic but are missing in the language of the tables. hoffman-idn-reg has some chance to become better, but it needs to address these areas: 1. Mandatory equivalences as opposed to secondary/variant equivalences. This feature is necessary for defining equivalences between European and Arabic-Indic digit shapes in Arabic labels, for example. Many software platforms like MS Windows have features that will automatically change the shape of European digits to Arabic-Indic ones in an Arabic context. Also, some Arabi countries only use one form of the digit set (and only have this set on their keyboards), while others use the other (and only have that set on their keyboards). This is some feature that *all* Arabic script zones *require*, contrary to optional features like reservation of a label with very similiar characters that may create cybersquatting problems and *may* be solved by just limiting the repretoire to a shorter list of characters. 2. Clear language about conflict resolution. There needs to be some clear guidelines or recommendations about the times that two registered labels come into an intersection regarding the variant labels associated to them. This will happen with almost any multi-language Arabic-script zone (e.g. U+0649 vs U+064A vs U+06CC). 3. Clear language with specific guidelines and real-life examples for merging tables for different languages/locales. 4. Better syntax for the table. Don't you agree that a U+ABCDU+BCDAU+CDAB syntax is unreadable? Why can't one use a space? Having said all that, I still recommend helping to make the language of jseng-idn-admin more understandable to a western mindset (and possibly making it two I-Ds, one general and one CJK-only), than trying to make hoffman-idn-reg a second jseng-idn-admin. jseng-idn-admin is much better and clearer in all the above four points, and even provides an exact algorithm for point 3. roozbeh From owner-idn-reg-policy Mon Mar 31 07:28:11 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VFSBJM022271 for ; Mon, 31 Mar 2003 07:28:11 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VFSBda022270 for idn-reg-policy-bks; Mon, 31 Mar 2003 07:28:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VFRsJN022229; Mon, 31 Mar 2003 07:27:55 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 31 Mar 2003 07:27:41 -0800 To: Roozbeh Pournader From: Paul Hoffman / IMC Subject: Re: New Internet Draft on registering IDNs Cc: Stephane Bortzmeyer , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 5:35 PM +0430 3/31/03, Roozbeh Pournader wrote: >I guess Stephane really means LGC (Latin, Greek, Cyrillic, ...) countries. >The requirements of Indic, Hebrew and Arabic scripts in IDN may prove to >be more complex than CJK. Indeed. That's the reason we need much more scrutiny of the different proposals. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Mon Mar 31 08:08:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VG8DJM026331 for ; Mon, 31 Mar 2003 08:08:13 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VG8DLD026330 for idn-reg-policy-bks; Mon, 31 Mar 2003 08:08:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VG86JM026320; Mon, 31 Mar 2003 08:08:11 -0800 (PST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h2VG7rMn1260031; Mon, 31 Mar 2003 18:07:53 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id E41F3110F0; Mon, 31 Mar 2003 18:07:56 +0200 (CEST) Date: Mon, 31 Mar 2003 18:07:56 +0200 From: Stephane Bortzmeyer To: Paul Hoffman / IMC Cc: idn-reg-policy@imc.org Subject: Re: New Internet Draft on registering IDNs Message-ID: <20030331160756.GA15352@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 25, 2003 at 09:31:09AM -0800, Paul Hoffman / IMC wrote a message of 16 lines which said: > Greetings. I have just submitted a new Internet Draft that gives > suggestions on how to register IDNs. There is a big problem with the bundle approach described in this draft, a problem I discovered while trying to implement it. I designed a table, as specified in the draft, for the French language (for multi-lingual countries or for multinational domains like '.eu', the problem will be worse). My table may be too large, allowing all Latin-1 (ISO-8859-1) characters, even those not used in French but it is still too small for the entire European Union. With this table, I experience a dramatic explosion. Many domains generate a bundle of several thousands of names, sometimes more. If I implement Option 1 of the draft ("Allocate all labels to the same registrant, making the zone information identical to that of the input label."), my zone file will explode :-) The problem, as I see it, is that the draft uses variant tables which work on a per-character basis, without any concern that not all combinations mean something. Most of the words in a bundle have no meaning in French and there is no real reason to keep them. I understand that there is no easy option (using a dictionary will not work since many domain names are not in any dictionary). Did anyone try a bundle approach on his zone? Here is the table, for those interested. It is simply "accent-insensitive". I regard any composed character as a variant of the plain character. # Variant table for the French language # See Internet-Draft draft-hoffman-idn-reg-00 # # Designed at AFNIC # Stephane Bortzmeyer # $Id$ # a-z # a U+0061|U+00E0:U+00E1:U+00E2:U+00E3:U+00E4:U+00E5 U+0062 U+0063 U+0064 # e U+0065|U+00E8:U+00E9:U+00EA:U+00EB U+0066 U+0067 U+0068 # i U+0069|U+00EC:U+00ED:U+00EE:U+00EF U+006A U+006B U+006C U+006D U+006E # o U+006F|U+00F2:U+00F3:U+00F4:U+00F5:U+00F6:U+00F8 U+0070 U+0071 U+0072 U+0073 U+0074 # u U+0075|U+00F9:U+00FA:U+00FB:U+00FC U+0076 U+0077 U+0078 U+0079 U+007A # 0-9 U+0030 U+0031 U+0032 U+0033 U+0034 U+0035 U+0036 U+0037 U+0038 U+0039 # - (hyphen) U+002D # Ligature oe U+0153|U+006FU+0065 From owner-idn-reg-policy Mon Mar 31 08:52:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VGqwJM028756 for ; Mon, 31 Mar 2003 08:52:58 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VGqww3028755 for idn-reg-policy-bks; Mon, 31 Mar 2003 08:52:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from sina.sharif.edu (sina.Sharif.AC.IR [194.225.40.9]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VGqpJM028751 for ; Mon, 31 Mar 2003 08:52:53 -0800 (PST) Received: from bamdad.org (IDENT:root@bamdad.org [81.31.160.190]) by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id h2VGqpF04280 for ; Mon, 31 Mar 2003 21:22:51 +0430 Received: from localhost (roozbeh@localhost) by bamdad.org (8.11.6/8.11.6) with ESMTP id h2VH2aE09757 for ; Mon, 31 Mar 2003 21:32:36 +0430 X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs Date: Mon, 31 Mar 2003 21:32:36 +0430 (IRST) From: Roozbeh Pournader X-X-Sender: roozbeh@gilas.bamdad.org To: IDN registration policy list Subject: Comparison of hoffman-idn-reg and jseng-idn-admin Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: With a personal and an Arabic script mindset, this is just a basic comparison: I like hoffman-idn-reg, since it's short and provides a solution for simple Latin-like scripts. I can point someone not very technical to the I-D and have him understand it. I also like it, since it sometimes tries not to be ignorant, and mentions things like: A registry MUST NOT blindly combine multiple tables which have overlapping equivalences. Instead, the registry MUST carefully analyze every instance in the combined table where a base character has one or more different variants and select the desired set of variants for the base character. (But unfortunately doesn't suggest any guidelines when doing so.) Unfortunately, the list ends here. Specifically, there are fetures that are *required* for Arabic but are missing in the language of the tables. hoffman-idn-reg has some chance to become better, but it needs to address these areas: 1. Mandatory equivalences as opposed to secondary/variant equivalences. This feature is necessary for defining equivalences between European and Arabic-Indic digit shapes in Arabic labels, for example. Many software platforms like MS Windows have features that will automatically change the shape of European digits to Arabic-Indic ones in an Arabic context. Also, some Arabi countries only use one form of the digit set (and only have this set on their keyboards), while others use the other (and only have that set on their keyboards). This is some feature that *all* Arabic script zones *require*, contrary to optional features like reservation of a label with very similiar characters that may create cybersquatting problems and *may* be solved by just limiting the repretoire to a shorter list of characters. 2. Clear language about conflict resolution. There needs to be some clear guidelines or recommendations about the times that two registered labels come into an intersection regarding the variant labels associated to them. This will happen with almost any multi-language Arabic-script zone (e.g. U+0649 vs U+064A vs U+06CC). 3. Clear language with specific guidelines and real-life examples for merging tables for different languages/locales. 4. Better syntax for the table. Don't you agree that a U+ABCDU+BCDAU+CDAB syntax is unreadable? Why can't one use a space? Having said all that, I still recommend helping to make the language of jseng-idn-admin more understandable to a western mindset (and possibly making it two I-Ds, one general and one CJK-only), than trying to make hoffman-idn-reg a second jseng-idn-admin. jseng-idn-admin is much better and clearer in all the above four points, and even provides an exact algorithm for point 3. roozbeh From owner-idn-reg-policy Mon Mar 31 09:16:47 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHGkJM029447 for ; Mon, 31 Mar 2003 09:16:47 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VHGkrA029446 for idn-reg-policy-bks; Mon, 31 Mar 2003 09:16:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from sina.sharif.edu (sina.Sharif.AC.IR [194.225.40.9]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHGdJM029440 for ; Mon, 31 Mar 2003 09:16:41 -0800 (PST) Received: from bamdad.org (IDENT:root@bamdad.org [81.31.160.190]) by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id h2VHGdF12323 for ; Mon, 31 Mar 2003 21:46:39 +0430 Received: from localhost (roozbeh@localhost) by bamdad.org (8.11.6/8.11.6) with ESMTP id h2VHQOP10001 for ; Mon, 31 Mar 2003 21:56:24 +0430 X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs Date: Mon, 31 Mar 2003 21:56:24 +0430 (IRST) From: Roozbeh Pournader X-X-Sender: roozbeh@gilas.bamdad.org To: IDN registration policy list Subject: Comparison of hoffman-idn-reg and jseng-idn-admin Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: With a personal and an Arabic script mindset, this is just a basic comparison: I like hoffman-idn-reg, since it's short and provides a solution for simple Latin-like scripts. I can point someone not very technical to the I-D and have him understand it. I also like it, since it sometimes tries not to be ignorant, and mentions things like: A registry MUST NOT blindly combine multiple tables which have overlapping equivalences. Instead, the registry MUST carefully analyze every instance in the combined table where a base character has one or more different variants and select the desired set of variants for the base character. (But unfortunately doesn't suggest any guidelines when doing so.) Unfortunately, the list ends here. Specifically, there are fetures that are *required* for Arabic but are missing in the language of the tables. hoffman-idn-reg has some chance to become better, but it needs to address these areas: 1. Mandatory equivalences as opposed to secondary/variant equivalences. This feature is necessary for defining equivalences between European and Arabic-Indic digit shapes in Arabic labels, for example. Many software platforms like MS Windows have features that will automatically change the shape of European digits to Arabic-Indic ones in an Arabic context. Also, some Arabi countries only use one form of the digit set (and only have this set on their keyboards), while others use the other (and only have that set on their keyboards). This is some feature that *all* Arabic script zones *require*, contrary to optional features like reservation of a label with very similiar characters that may create cybersquatting problems and *may* be solved by just limiting the repretoire to a shorter list of characters. 2. Clear language about conflict resolution. There needs to be some clear guidelines or recommendations about the times that two registered labels come into an intersection regarding the variant labels associated to them. This will happen with almost any multi-language Arabic-script zone (e.g. U+0649 vs U+064A vs U+06CC). 3. Clear language with specific guidelines and real-life examples for merging tables for different languages/locales. 4. Better syntax for the table. Don't you agree that a U+ABCDU+BCDAU+CDAB syntax is unreadable? Why can't one use a space? Having said all that, I still recommend helping to make the language of jseng-idn-admin more understandable to a western mindset (and possibly making it two I-Ds, one general and one CJK-only), than trying to make hoffman-idn-reg a second jseng-idn-admin. jseng-idn-admin is much better and clearer in all the above four points, and even provides an exact algorithm for point 3. roozbeh From owner-idn-reg-policy Mon Mar 31 12:00:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VK0RJM006093 for ; Mon, 31 Mar 2003 12:00:27 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VK0R8t006091 for idn-reg-policy-bks; Mon, 31 Mar 2003 12:00:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from mail-aubervilliers.netaktiv.com (soyouz.netaktiv.com [80.67.162.6]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VK0EJM005962; Mon, 31 Mar 2003 12:00:25 -0800 (PST) Received: by mail-aubervilliers.netaktiv.com (Postfix, from userid 10) id 3D4E523EBF; Mon, 31 Mar 2003 22:00:07 +0200 (CEST) Received: from sources.org (stephane@localhost [127.0.0.1]) by ludwigV.sources.org (8.12.3/8.12.3/Debian -4) with ESMTP id h2VJuD6v006142; Mon, 31 Mar 2003 21:56:13 +0200 Message-Id: <200303311956.h2VJuD6v006142@ludwigV.sources.org> X-Mailer: exmh version 2.5 07/13/2001 (debian 2.5-1) with nmh-1.0.4+dev To: Paul Hoffman / IMC Subject: Re: New Internet Draft on registering IDNs From: Stephane Bortzmeyer Cc: idn-reg-policy@imc.org Organization: NIC France Date: Mon, 31 Mar 2003 21:56:13 +0200 Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 25, 2003 at 09:31:09AM -0800, Paul Hoffman / IMC wrote a message of 16 lines which said: > Greetings. I have just submitted a new Internet Draft that gives > suggestions on how to register IDNs. There is a big problem with the bundle approach described in this draft, a problem I discovered while trying to implement it. I designed a table, as specified in the draft, for the French language (for multi-lingual countries or for multinational domains like '.eu', the problem will be worse). My table may be too large, allowing all Latin-1 (ISO-8859-1) characters, even those not used in French but it is still too small for the entire European Union. With this table, I experience a dramatic explosion. Many domains generate a bundle of several thousands of names, sometimes more. If I implement Option 1 of the draft ("Allocate all labels to the same registrant, making the zone information identical to that of the input label."), my zone file will explode :-) The problem, as I see it, is that the draft uses variant tables which work on a per-character basis, without any concern that not all combinations mean something. Most of the words in a bundle have no meaning in French and there is no real reason to keep them. I understand that there is no easy option (using a dictionary will not work since many domain names are not in any dictionary). Did anyone try a bundle approach on his zone? Here is the table, for those interested. It is simply "accent-insensitive". I regard any composed character as a variant of the plain character. # Variant table for the French language # See Internet-Draft draft-hoffman-idn-reg-00 # # Designed at AFNIC # Stephane Bortzmeyer # $Id$ # a-z # a U+0061|U+00E0:U+00E1:U+00E2:U+00E3:U+00E4:U+00E5 U+0062 U+0063 U+0064 # e U+0065|U+00E8:U+00E9:U+00EA:U+00EB U+0066 U+0067 U+0068 # i U+0069|U+00EC:U+00ED:U+00EE:U+00EF U+006A U+006B U+006C U+006D U+006E # o U+006F|U+00F2:U+00F3:U+00F4:U+00F5:U+00F6:U+00F8 U+0070 U+0071 U+0072 U+0073 U+0074 # u U+0075|U+00F9:U+00FA:U+00FB:U+00FC U+0076 U+0077 U+0078 U+0079 U+007A # 0-9 U+0030 U+0031 U+0032 U+0033 U+0034 U+0035 U+0036 U+0037 U+0038 U+0039 # - (hyphen) U+002D # Ligature oe U+0153|U+006FU+0065 From owner-idn-reg-policy Mon Mar 31 12:43:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VKh4JM010780 for ; Mon, 31 Mar 2003 12:43:04 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VKh45F010779 for idn-reg-policy-bks; Mon, 31 Mar 2003 12:43:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VKh1JN010775; Mon, 31 Mar 2003 12:43:01 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200303311956.h2VJuD6v006142@ludwigV.sources.org> References: <200303311956.h2VJuD6v006142@ludwigV.sources.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 31 Mar 2003 12:42:46 -0800 To: Stephane Bortzmeyer From: Paul Hoffman / IMC Subject: Re: New Internet Draft on registering IDNs Cc: idn-reg-policy@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:56 PM +0200 3/31/03, Stephane Bortzmeyer wrote: >The problem, as I see it, is that the draft uses variant tables which >work on a per-character basis, without any concern that not all >combinations mean something. Most of the words in a bundle have no >meaning in French and there is no real reason to keep them. > >I understand that there is no easy option (using a dictionary will not >work since many domain names are not in any dictionary). Exactly right. Either the system is automatic (no human intervention) and can create many unnecessary alternatives, or it is human-controlled and error-prone. In the latter case, what happens if the human who is reviewing all the names disagrees with the registrant about which names "make sense"? What if a reviewer misses some "sensible" variants and a different registrant grabs them? >Did anyone try a bundle approach on his zone? Asian registries have done so. But they have very different script variant issues than European registries. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Tue Apr 1 16:50:48 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h320omJM003656 for ; Tue, 1 Apr 2003 16:50:48 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h320olkH003655 for idn-reg-policy-bks; Tue, 1 Apr 2003 16:50:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from nicemice.net (arwen.CS.Berkeley.EDU [128.32.132.165]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h320olJM003649 for ; Tue, 1 Apr 2003 16:50:47 -0800 (PST) Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 190WSo-0008N3-00 for ; Tue, 01 Apr 2003 16:50:50 -0800 Date: Mon, 31 Mar 2003 21:04:43 +0000 From: "Adam M. Costello" To: IDN registration policy list Subject: initial thoughts Message-ID: <20030331210443.GB15622@nicemice.net> Reply-To: IDN registration policy list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The following message was originally sent last Friday, but never made it to the list. AMC Registration policy was on my mind today, so I wrote up my thoughts, then looked at the list archive and Paul's draft for the first time. Apparently Paul and I think very much alike on this topic (probably because we'd seen the same earlier documents). Here's what I wrote: ---begin--- What policies ought a registry have before it starts admitting IDNs? 1. A policy defining what labels are admissible. This could be a set of allowed characters, or could be more complicated (for example, it could involve sequences of characters). The policy should allow only those strings for which the registry has sufficient expertise to define a sensible grouping policy (see below). The set of admissible labels can start small and gradually be expanded as the registry develops (or borrows) expertise. 2. A policy defining how labels are grouped. With traditional ASCII domain names, you register one name, and you get one name. If you register color.com, that doesn't prevent someone else from registering c010r.com or colour.com. For IDNs, it may be prudent to partition the set of admissible labels into groups (every admissible label belongs to exactly one group), where the group is the unit of registration; that is, registering any label in the group allocates the entire group, so that no one else may register any label in the same group. This policy could be implemented by defining a function that maps a label to a group identifier, which could be a canonical member of the group. The function might work by applying ToUnicode, then Nameprep, then some custom mappings of individual characters or sequences of characters, then ToASCII. 3. A policy defining how lookups behave with respect to groups. Does a lookup return the same resource records no matter which member of the group is queried? Or does the lookup fail except for particular members of the group chosen by the registrant (or by the registry)? All of the above policies need to be unambiguously specified and publicly available, so that registrants know what they're buying. I think those three things are all that is needed. In particular, I don't think it would be helpful to associate a language tag (or tags) with a registration; I think that would just raise unnecessary questions and controversies. ---end--- That's very close to Paul's draft, but there are a few slight differences: Paul's draft assumes that the policies can focus on single characters, and disregard sequences of characters. I wonder if that might not be powerful enough for some registries. We both propose partitioning the set of admissible labels into groups (bundles). Paul imagines a function that constructs the entire group given any member of the group, while I imagine a function that computes a group identifier given any member of the group, where the group identifier could be a single member of the group arbitrarily chosen to stand for the whole group. Either kind of function implies the same partition of the space, and both functions would use the same tables, but I think the group-id function might be easier to describe and understand. The group-construction function might be useful internally by the registry, if the registry needed to enumerate the group, but that doesn't really scale. That brings us to an issue I neglected to address: If the registry (or the registrant) decides that all members of the group should be visible, how will that work? Will it scale? The combinatorics are exponential. I think the only way it would work well is if the authoritative DNS servers (both the registry's servers that delegate the name, and the registrant's servers that provide the data for the name) include support for the grouping. I guess you would supply the tables to the DNS server, and it would perform the group-id computation whenever a request comes in, then look for the group-id in the zone database. This would require a standard machine-readable format for describing the grouping policy for a zone. Without that support in the DNS server, I think the sensible approach is for the registrant to choose individual member(s) of the group to be visible, and let the others be invisible (blocked). Registries could come up with a pricing plan, maybe the normal registration fee for a group with one visible member, and a small additional fee for each additional visible member. You could also imagine that the registry, rather than the registrant, chooses which member(s) will be visible, but I think it would be difficult for registries to come up with rules that would please everyone; it would probably be easier to let the registrant choose, and simply store the list. AMC From owner-idn-reg-policy Tue Apr 1 18:20:53 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h322KrJM007170 for ; Tue, 1 Apr 2003 18:20:53 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h322KruS007168 for idn-reg-policy-bks; Tue, 1 Apr 2003 18:20:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from nicemice.net (arwen.CS.Berkeley.EDU [128.32.132.165]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h322KpJM007158 for ; Tue, 1 Apr 2003 18:20:52 -0800 (PST) Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 190Xrz-00008g-00 for ; Tue, 01 Apr 2003 18:20:55 -0800 Date: Wed, 2 Apr 2003 02:20:55 +0000 From: "Adam M. Costello" To: IDN registration policy list Subject: Re: Comparison of hoffman-idn-reg and jseng-idn-admin Message-ID: <20030402022055.GB30135@nicemice.net> Reply-To: IDN registration policy list References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Roozbeh Pournader wrote: > 1. Mandatory equivalences as opposed to secondary/variant > equivalences. This feature is necessary for defining equivalences > between European and Arabic-Indic digit shapes in Arabic labels, for > example. > > This is some feature that *all* Arabic script zones *require* I'm not sure what you mean by "mandatory" and "require". Suppose I create the names .nicemice.net and .nicemice.net on the DNS server for nicemice.net (which I control), and suppose these two names are the same except that one uses ASCII digits and the other uses the corresponding Arabic-Indic digits, and suppose I associate different resource records with these names. Should there be a standard that prohibits me from doing this? Or suppose I register .com, which allocates an entire bundle of names (including .com) that no one else can register. Should the registry for .com be able to offer me the choice of whether .com is visible (equivalent to .com) or invisible (no such domain)? Or should the registry for .com be required to make .com visible and equivalent to .com, regardless of my preference? What would you think of this model: The Arabic-speaking community develops a best-practice recommendation regarding equivalences of names that should resolve to the same resource records, and TLDs can opt to support those equivalences, and can advertise their voluntary conformance in order to attract Arabic registrants. By the way, I'd like to point out that trying to make names automagically appear to be equivalent is a much trickier task than merely preventing registration of too-similar names to different registrants. The latter task involves the registry database only, not the DNS servers, nor any other servers or applications. But automagic equivalence potentially depends on the cooperation of anything that compares domain names. For example, HTTP servers compare the requested host name with host names in their config files in order to decide which virtual server to present, web browsers compare host names with user-entered lists to decide whether to accept images and cookies from a given site, and mail servers compare recipient domain names with domain names in their config files in order to decide whether the mail is local. It might be easier to handle this sort of thing more manually, at least in the beginning. For example, if contains four digits, it's one of 16 equivalent names. But really only two of them have any chance of being used. A registrant could select those two names to be visible, and leave all others invisible. They could then manually configure their web server and their mail server to recognize those two names. > 2. Clear language about conflict resolution. There needs to be > some clear guidelines or recommendations about the times that two > registered labels come into an intersection regarding the variant > labels associated to them. The whole point of having bundles is so that two registered labels cannot be variants of each other. Whichever one was registered first blocks the other from being registered. Now this does suggest a new sort of problem that hasn't existed before: bundles that are too big. Currently, the problem is that bundles are too small (just one name), so that registering a name doesn't prevent someone else from registering a confusingly similar name. The opposite problem would be bundles that are too big, where registering one name prevents someone else from registering another name that's different enough to be considered distinct under trademark law (or whatever rules are relevant to the dispute). It might happen that registrant X has a trademark on nameX, and registrant Y has a trademark on nameY, so both registrants are equally "entitled" to their respective names, but the two names are in the same bundle, so only one of the registrants can have their name. I guess this is not so different from cases where two companies have trademarks on the same name in different markets, but only one of them can have the name in .com. AMC From owner-idn-reg-policy Tue Apr 1 18:25:36 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h322PaJM007314 for ; Tue, 1 Apr 2003 18:25:36 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h322PaSY007313 for idn-reg-policy-bks; Tue, 1 Apr 2003 18:25:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h322PWJN007305; Tue, 1 Apr 2003 18:25:33 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <200303311956.h2VJuD6v006142@ludwigV.sources.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 1 Apr 2003 18:05:18 -0800 To: Stephane Bortzmeyer From: Paul Hoffman / IMC Subject: Re: New Internet Draft on registering IDNs Cc: idn-reg-policy@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A followup on my own message, because I believe what I said was wrong. I said: >Either the system is automatic (no human intervention) and can >create many unnecessary alternatives, or it is human-controlled and >error-prone. That's too simplistic. Human-controlled systems that decide what is and is not a variant are error-prone, but human-controlled systems that decide which labels from an automatically-created bundle are not. This ties into Vint's suggestion the other day about non-automatic partitioning the labels in the bundle between allocated and blocked. In this scenario, the registry can say many different things, such as "your bundle contains 1024 entries, and..." - you can choose which five to put in the zone; the other 1019 will be blocked - we have chosen the five that we will put in the zone, and the 1019 that will be blocked - you can put as many as you want in the zone, and it will cost you US$10 per name per year to do so; the rest will be blocked for free - because your bundle has 1024 names, the base bundle cost is five times higher than if you had chosen a name that only had 128 names; plus, you must pay... ... and so on. I will cover this additional scenario in my next draft. More comments on this are welcome! --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Tue Apr 1 18:25:37 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h322PaJM007316 for ; Tue, 1 Apr 2003 18:25:36 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h322Pa18007315 for idn-reg-policy-bks; Tue, 1 Apr 2003 18:25:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h322PWJP007305 for ; Tue, 1 Apr 2003 18:25:34 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 1 Apr 2003 18:25:34 -0800 To: idn-reg-policy@imc.org From: Paul Hoffman / IMC Subject: Re: Comparison of hoffman-idn-reg and jseng-idn-admin Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:56 PM +0430 3/31/03, Roozbeh Pournader wrote: > A registry MUST NOT blindly combine multiple tables which have > overlapping equivalences. Instead, the registry MUST carefully analyze > every instance in the combined table where a base character has one or > more different variants and select the desired set of variants for the > base character. > >(But unfortunately doesn't suggest any guidelines when doing so.) Correct. I think that if I give a few suggestions for guidelines, it will lead readers to think that the problem is simple, which it is not. Either we list lots and lots, or none. I will add a note about why I have done none; see below. >Unfortunately, the list ends here. Specifically, there are fetures that >are *required* for Arabic but are missing in the language of the tables. And therefore it will be added. (Note to the list: I doubt that Arabic is the only language that I missed. If you know of others, please speak up!) >1. Mandatory equivalences as opposed to secondary/variant equivalences. >This feature is necessary for defining equivalences between European and >Arabic-Indic digit shapes in Arabic labels, for example. Very good point! This is a registry-specific early mapping step that must be done. I think it should be done before the variants are checked in the table; do folks here agree? >2. Clear language about conflict resolution. There needs to be some clear >guidelines or recommendations about the times that two registered labels >come into an intersection regarding the variant labels associated to them. >This will happen with almost any multi-language Arabic-script zone >(e.g. U+0649 vs U+064A vs U+06CC). I am unclear on how this differs from point #1. If any of those three characters are supposed to only be represented by one of them in names, then the registry-specific early mapping step will take care of them. Or is that not what you are referring to? Please be more specific. >3. Clear language with specific guidelines and real-life examples for >merging tables for different languages/locales. Currently, I believe that there are three possibilities: - the merging is trivially easy because there is no overlap - the merging is a policy decision by the registry at the time of table-making as to which language "wins" for the overlapping characters - it is impossible to register without knowing the supposed language of the registration I can add more discussion of that, but the third option is not "merging", it is forcing the problem on the registrant (who might be sly and use it as a way to make the bundle contain things that the registry might not have intended). From my reading of the JET document, they call the third option "merging" when in fact it is just the opposite: it prevents merging by pointing at one table. >4. Better syntax for the table. Don't you agree that a U+ABCDU+BCDAU+CDAB >syntax is unreadable? Why can't one use a space? Spaces as separators in tables cause problems going through gateway programs. I'm happy to add an inter-character separator of "-". --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Wed Apr 2 03:10:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32BAeJM020363 for ; Wed, 2 Apr 2003 03:10:40 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32BAet8020361 for idn-reg-policy-bks; Wed, 2 Apr 2003 03:10:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by above.proper.com (8.12.9/8.11.6) with SMTP id h32BAcJM020340 for ; Wed, 2 Apr 2003 03:10:39 -0800 (PST) Message-ID: <01c701c2f908$52fef390$8c7a4b0a@neteka.inc> From: "Edmon Chung" To: References: <200303311956.h2VJuD6v006142@ludwigV.sources.org> Subject: Framework for IDN Operations Date: Wed, 2 Apr 2003 06:09: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-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I have just submitted 2 drafts on a flexible framework for managing character equivalence. More importantly driving towards a generic structure that can be incorporated into a provisioning protocol. Charprep: http://www.ietf.org/internet-drafts/draft-chung-idnop-charprep-00.txt Describes a framework for publishing: - codepoint inclusion table - character equivalence tables based on a given script Zoneprep: http://www.ietf.org/internet-drafts/draft-chung-idnop-zoneprep-00.txt Describes a framework that categorizes Reserved Variants and Zone Variants into different types: Primary Domain: originally submitted domain Reserved Variants (RV): - Normal RV: blocked from registration and can be activated as Zone variant by client - Restricted RV: blocked from registration and cannot be activated - Automatic ZV: automatically included as a zone variant - Suggested RV: suggested by the registry to be reserved by the client Zone Variants (ZV): - Normal ZV: can have its own delegation NS as well as hosts (function as a unique domain) - Same NS: must have same delegation NS as primary domain - Alias Only: is aliased to the primary domain Based on the Charprep/Zoneprep framework, I have also drafted an EPP mapping that introduces a new IDN object (that contains the set/bundle/package of IDN variants for a give primary domain/domain object): http://www.ietf.org/internet-drafts/draft-chung-idnop-epp-idn-00.txt I think this IDNOP framework provides a good generic structure that can accomodate different needs of different registries, while still maintaining a standard architecture. For example, registries can just choose to make the entire RV set Restricted RV, then it is the same as saying that all variants will simply be blocked. Or registries may choose to make all RVs into Automatic ZV, which effectively puts all RVs into the zonefile. Or there could be a mixture including Normal RVs that can be activated later. I am also drafting an IDNOP Guideline that describes a set of best practices for domain registries for implementing/launching IDNs, more specifically, on the following topics: 1. Character Equivalence Preparation Policies (and provisioning protocol considerations) 2. Sunrise and/or land-rush Management (including grandfathering of existing registered domains) 3. DNS Resolution Considerations (Zone file preparations, DNS request expectations management, and IDNA client considerations) 4. Domain Dispute Resolution Considerations Any thoughts or comments will be great. Edmon From owner-idn-reg-policy Wed Apr 2 05:47:32 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32DlWJM003571 for ; Wed, 2 Apr 2003 05:47:32 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32DlW4J003570 for idn-reg-policy-bks; Wed, 2 Apr 2003 05:47:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from grappa.isoc.org.il (root@grappa.isoc.org.il [132.70.9.72]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32DlTJM003555; Wed, 2 Apr 2003 05:47:30 -0800 (PST) Received: from BENNYPC (benny-pc.isoc.org.il [192.114.22.72]) by grappa.isoc.org.il (8.9.3p2/8.9.0) with ESMTP id QAA29249; Wed, 2 Apr 2003 16:47:23 +0300 From: "Benny Lipsicas" To: "'Paul Hoffman / IMC'" , Subject: RE: Comparison of hoffman-idn-reg and jseng-idn-admin Date: Wed, 2 Apr 2003 16:52:35 +0200 Message-ID: <00c101c2f927$82afdf40$481672c0@BENNYPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>Unfortunately, the list ends here. Specifically, there are fetures that >>are *required* for Arabic but are missing in the language of the tables. >And therefore it will be added. (Note to the list: I doubt that >Arabic is the only language that I missed. If you know of others, >please speak up!) Since it's my first post - I'll introduce myself: Benny Lipsicas, ".il" registry administrator. The language in question is Hebrew. One feature that may be of importance to us is the ability to prevent certain characters from appearing anywhere else but at the end of the label (i.e. it can only be the last char of a label), and we have another issue, which I'm not certain is in the scope of this list, any label in Hebrew needs to be written RTL, and if i'm not mistaken, this technically prevents the mixing of Hebrew and non-Hebrew chars in the same label. From owner-idn-reg-policy Wed Apr 2 07:59:38 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FxcJM014159 for ; Wed, 2 Apr 2003 07:59:38 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32FxcOG014158 for idn-reg-policy-bks; Wed, 2 Apr 2003 07:59:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FxXJN014144; Wed, 2 Apr 2003 07:59:33 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <00c101c2f927$82afdf40$481672c0@BENNYPC> References: <00c101c2f927$82afdf40$481672c0@BENNYPC> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 2 Apr 2003 07:59:26 -0800 To: "Benny Lipsicas" , From: Paul Hoffman / IMC Subject: RE: Comparison of hoffman-idn-reg and jseng-idn-admin Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 4:52 PM +0200 4/2/03, Benny Lipsicas wrote: >The language in question is Hebrew. One feature that may be of >importance to us is the ability to prevent certain characters from >appearing anywhere else but at the end of the label (i.e. it can only be >the last char of a label), and we have another issue, which I'm not >certain is in the scope of this list, any label in Hebrew needs to be >written RTL, and if i'm not mistaken, this technically prevents the >mixing of Hebrew and non-Hebrew chars in the same label. The latter issue is definitely handled by the IDNA standard. Could you explain the reason for the first issue (that a particular character has to be the last character in the label)? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn-reg-policy Wed Apr 2 12:52:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KqRJM001164 for ; Wed, 2 Apr 2003 12:52:27 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KqR7A001162 for idn-reg-policy-bks; Wed, 2 Apr 2003 12:52:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KqPJM001143 for ; Wed, 2 Apr 2003 12:52:25 -0800 (PST) Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h32KqKsx017302; Wed, 2 Apr 2003 15:52:26 -0500 Message-Id: <4.2.0.58.J.20030402145707.03cc9c18@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 02 Apr 2003 15:00:31 -0500 To: Roozbeh Pournader , IDN registration policy list From: Martin Duerst Subject: Re: Comparison of hoffman-idn-reg and jseng-idn-admin In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 21:56 03/03/31 +0430, Roozbeh Pournader wrote: >4. Better syntax for the table. Don't you agree that a U+ABCDU+BCDAU+CDAB >syntax is unreadable? Why can't one use a space? What about using Unicode (UTF-8) directly? What about defining an XML format for the tables? This would allow to publish tables in ASCII-only contexts but also easily view them in a browser with a simple stylesheet. As some of the drafts say, registries should only accept characters for which they have expertize on, which usually means that they can (and want to!) see them directly. Regards, Martin. From owner-idn-reg-policy Wed Apr 2 12:52:34 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KqXJM001182 for ; Wed, 2 Apr 2003 12:52:33 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KqXhk001181 for idn-reg-policy-bks; Wed, 2 Apr 2003 12:52:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KqWJM001173; Wed, 2 Apr 2003 12:52:32 -0800 (PST) Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h32KqKt9017302; Wed, 2 Apr 2003 15:52:27 -0500 Message-Id: <4.2.0.58.J.20030402154656.035a9988@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 02 Apr 2003 15:52:09 -0500 To: Paul Hoffman / IMC , Staffan Hagnell From: Martin Duerst Subject: Re: New Internet Draft on registering IDNs Cc: idn-reg-policy@imc.org In-Reply-To: References: <3E82A944.6040703@iis.se> <3E818686.6010307@twnic.net.tw> <3E820CB0.1000605@iis.se> <3E82A944.6040703@iis.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 06:53 03/03/27 -0800, Paul Hoffman / IMC wrote: >If the input label contains characters that have equivalents, Internet >users who don't know what the base characters used in the registration >will not know what character to type in to get a DNS response. For >instance, if DIGIT ONE is a variant of LATIN SMALL LETTER L, and LATIN >SMALL LETTER L is a variant of DIGIT ONE, the user who sees >"pale.example.com" will no know whether to type a "1" or a "l" after the >"pa" in the first label. I think there are various different situations. There are cases where it's totally unclear what to type in. There are cases where it's quite clear what to type in. There are cases where it would be clear what to type in, but the user isn't able to type the characters in question, and falls back to something else. Also, in some cases, it is easy for the owner of the 'bundle' to make sure users know what to type in. In other cases, it may be difficult. Regards, Martin. From owner-idn-reg-policy Wed Apr 2 12:52:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KqRJM001169 for ; Wed, 2 Apr 2003 12:52:27 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KqRHq001165 for idn-reg-policy-bks; Wed, 2 Apr 2003 12:52:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KqOJM001139 for ; Wed, 2 Apr 2003 12:52:25 -0800 (PST) Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h32KqKt1017302; Wed, 2 Apr 2003 15:52:26 -0500 Message-Id: <4.2.0.58.J.20030402150335.035b1fc8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 02 Apr 2003 15:07:03 -0500 To: IDN registration policy list , IDN registration policy list From: Martin Duerst Subject: Re: Comparison of hoffman-idn-reg and jseng-idn-admin In-Reply-To: <20030402022055.GB30135@nicemice.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 02:20 03/04/02 +0000, Adam M. Costello wrote: >Now this does suggest a new sort of problem that hasn't existed before: >bundles that are too big. Currently, the problem is that bundles are >too small (just one name), so that registering a name doesn't prevent >someone else from registering a confusingly similar name. The opposite >problem would be bundles that are too big, where registering one name >prevents someone else from registering another name that's different >enough to be considered distinct under trademark law (or whatever rules >are relevant to the dispute). It might happen that registrant X has a >trademark on nameX, and registrant Y has a trademark on nameY, so both >registrants are equally "entitled" to their respective names, but the >two names are in the same bundle, so only one of the registrants can >have their name. I guess this is not so different from cases where two >companies have trademarks on the same name in different markets, but >only one of them can have the name in .com. The danger of bundles being too big can easily happen for European languages, with a bundle that defines that all accented versions of a character are treated as the same as the base character. In that case, Paul's approach (also described by Adam) of using equivalence classes won't scale. What may work is that an accented character blocks the base character, but not characters with a different accent. But this no longer can be described with equivalence classes. Regards, Martin. From owner-idn-reg-policy Wed Apr 2 12:52:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KqRJM001170 for ; Wed, 2 Apr 2003 12:52:27 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KqRQI001166 for idn-reg-policy-bks; Wed, 2 Apr 2003 12:52:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KqPJM001142; Wed, 2 Apr 2003 12:52:25 -0800 (PST) Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h32KqKt5017302; Wed, 2 Apr 2003 15:52:27 -0500 Message-Id: <4.2.0.58.J.20030402151053.0321e328@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 02 Apr 2003 15:16:42 -0500 To: Paul Hoffman / IMC , "Benny Lipsicas" , From: Martin Duerst Subject: RE: Comparison of hoffman-idn-reg and jseng-idn-admin In-Reply-To: References: <00c101c2f927$82afdf40$481672c0@BENNYPC> <00c101c2f927$82afdf40$481672c0@BENNYPC> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 07:59 03/04/02 -0800, Paul Hoffman / IMC wrote: >At 4:52 PM +0200 4/2/03, Benny Lipsicas wrote: >>The language in question is Hebrew. One feature that may be of >>importance to us is the ability to prevent certain characters from >>appearing anywhere else but at the end of the label (i.e. it can only be >>the last char of a label), and we have another issue, which I'm not >>certain is in the scope of this list, any label in Hebrew needs to be >>written RTL, and if i'm not mistaken, this technically prevents the >>mixing of Hebrew and non-Hebrew chars in the same label. > >The latter issue is definitely handled by the IDNA standard. Could you >explain the reason for the first issue (that a particular character has to >be the last character in the label)? Some Hebrew characters (kaf, mem, nun, peh, tsadi) have different forms when appearing at the end of a word (label). The Greek sigma is another example. In Unicode, this is handled by having separate codepoints for the final forms. This is in contrast to e.g. Arabic, where there are much more contextual forms, and shaping is handled on display, and there is only one codepoint per character. So a registry registring Hebrew would want to make sure that e.g. a kaf in the middle of a label is always U+05DB, but at the end of the label is always U+05DA. I'm not sure what should happen with labels that consist of more than one word, whether simple concatenation would be acceptable (and a final letter could help seeing the word boundary) or whether a hyphen or other, similar character would be used to concatenate words. Regards, Martin. From owner-idn-reg-policy Wed Apr 2 12:52:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KqRJM001163 for ; Wed, 2 Apr 2003 12:52:27 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KqQEg001159 for idn-reg-policy-bks; Wed, 2 Apr 2003 12:52:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KqOJM001140; Wed, 2 Apr 2003 12:52:25 -0800 (PST) Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h32KqKt3017302; Wed, 2 Apr 2003 15:52:27 -0500 Message-Id: <4.2.0.58.J.20030402150927.03cdd948@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 02 Apr 2003 15:09:51 -0500 To: Paul Hoffman / IMC , idn-reg-policy@imc.org From: Martin Duerst Subject: Re: Comparison of hoffman-idn-reg and jseng-idn-admin In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 18:25 03/04/01 -0800, Paul Hoffman / IMC wrote: >>4. Better syntax for the table. Don't you agree that a U+ABCDU+BCDAU+CDAB >>syntax is unreadable? Why can't one use a space? > >Spaces as separators in tables cause problems going through gateway >programs. I'm happy to add an inter-character separator of "-". What 'gateway programs'? Regards, Martin. From owner-idn-reg-policy Wed Apr 2 13:19:22 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32LJLJM002921 for ; Wed, 2 Apr 2003 13:19:21 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32LJLwO002920 for idn-reg-policy-bks; Wed, 2 Apr 2003 13:19:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32LJKJM002906; Wed, 2 Apr 2003 13:19:20 -0800 (PST) Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h32LJMsj026422; Wed, 2 Apr 2003 16:19:22 -0500 Message-Id: <4.2.0.58.J.20030402161258.0291df10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 02 Apr 2003 16:19:14 -0500 To: Paul Hoffman / IMC , idn-reg-policy@imc.org From: Martin Duerst Subject: Re: New Internet Draft on registering IDNs In-Reply-To: References: <3E818686.6010307@twnic.net.tw> <3E818686.6010307@twnic.net.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn-reg-policy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 08:16 03/03/26 -0800, Paul Hoffman / IMC wrote: >Right. Unfortunately, the current draft of the JET document is silent >about these requirements, and from talking to some JET members, I haven't >heard any good description of why Chinese needs both. In fact, I remember >many long conversations with CNNIC and TWNIC people a few years ago where >they all said that just blocking (with no allocating) was fine. Maybe >opinions in the Chinese language community have changed since then, but I >haven't seen any written down in the JET document yet. Maybe the next >version will cover this clearly. This is just a wild guess, but it may have to do with the fact that even in Taiwan, simplified characters are sometimes used. The most often cited example is the 'tai' in Taiwan (U+53F0). This is clearly a simplified character, but it is often used. While in general, combinations of simplified and traditional variants can just be blocked, this is a case where just blocking would not work. >True, but it would only help a little bit. Telling the users what has been >done does not let them predict what will happen. If a registry says "we >have mapped these characters to these other ones for this language >reason", users will understand that; if a registry says "we have blocked >these characters for this language reason", users will understand that. >But I don't know how many users will understand "we have mapped some of >them but blocked other ones even though the language reason is the same". >If there is a good language reason for differentiating the two cases, that >would be wonderful. 'language reason' may be the same or different. It may be the same language, but a different reason. Also, in some cases, it may appear very natural to people understanding the language to read 'we have mapped A, B, and C, and blocked D, E, and F'. A very simplistic example would be French, with somebody registering e-acute. If the system replied 'we have mapped e (without any accent) and blocked e-grave, e-circumflex, and e-diaeresis, that would make sense to somebody understanding French. The e without accent can be used as an equivalent for e-acute, and is therefore mapped, but the other accented variants are never equivalents, and may be blocked just because they would otherwise interfere with the e without accent. [I don't claim that this is the right thing to do for French.] Regards, Martin. From owner-idn-reg-policy Wed Apr 2 14:43:03 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32Mh3JM006638 for ; Wed, 2 Apr 2003 14:43:03 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32Mh375006637 for idn-reg-policy-bks; Wed, 2 Apr 2003 14:43:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-idn-reg-policy@mail.imc.org using -f Received: from nicemice.net (arwen.CS.Berkeley.EDU [128.32.132.165]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32Mh1JM006633 for ; Wed, 2 Apr 2003 14:43:02 -0800 (PST) Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian))