FYI… This discussion was initiated by Dr. Abdul-Aziz Al-Zoman of .sa on several mailing lists. Discussions have been extensive these past couple of days on the APTLD Members mailing list. Fahd A. Batayneh From: Seo, June [mailto:jseo@verisign.com] Sent: Sunday, July 01, 2012 3:31 AM To: Seo, June Cc: Fahd Batayneh; member@aptld.org Subject: Re: Seeking Your Comments on .com IDNs Just for clarifications, Fahd. ICANN, in principle, is a community based organization and the community consists of very diverse stakeholder groups. Verisign's outreach efforts on various groups have been to seek their feedbacks, and I would not agree with your suggestion that we must exclude certain groups like GAC. In addition, while Verisign is willing to, as it always has been, listen to various community feedbacks and concerns, and address those in a balanced way, I would not agree with you that new gTLD applications are to be a consensus building process with particular expert groups, ccTLD registries and even ICANN staff as you suggested below. June On Jul 1, 2012, at 8:06 AM, "Seo, June" <jseo@verisign.com<mailto:jseo@verisign.com>> wrote: Noted your points. As I mentioned below in my response, we’ve outreached not only ccTLD registries and GAC but also various stakeholder groups/IDN experts in our past IDN Software Developer’s Consortium meetings at least in 3 different occasions. The participants of those meetings also included a number of ICANN staff members. June From: Fahd Batayneh [mailto:Fahd.Batayneh@NITC.gov.jo]<mailto:[mailto:Fahd.Batayneh@NITC.gov.jo]> Sent: Saturday, June 30, 2012 7:59 PM To: Seo, June Cc: member@aptld.org<mailto:member@aptld.org> Subject: RE: Seeking Your Comments on .com IDNs Thank you June for a detailed explanation. You mentioned in point 7 – and I will quote - that “These stakeholder groups we’ve outreached and debriefed so far include a number of registrars, GAC members and ccTLD registries (some of them are also on this APTLD mailing list) located in the APAC and Middle East regions as well as some members of IP community participating in various community activities in ICANN.” In my humble opinion, VeriSign Inc. must have outreached those deeply involved in the technicalities of IDNs, and not just GAC and/or ccTLD members. Let us not forgot that each and every one of us understands IDNs to a certain level of expertise. Thus, outreaching GAC members (politicians) must not have been an option, and outreaching ccTLD members (especially those away from the technicalities of running registries) is – again – not the right way to approach. I must say that VeriSign Inc. were aiming IDN bullets at the wrong audience. While I am not against VeriSign Inc. – as a firm - in any of the IDN applications they have submitted, but I think they should have outreached respective communities directly, and they should have contacted IDN experts within these communities. Since ICANN has regional directors, VeriSign Inc. could have reached these communities in cooperation with ICANN regional directors. I think it is still not too late for VeriSign Inc. to address concerns of worried IDN communities – such as the Arabic community and the Chinese community – as means to reach to a mutual consensus on the way forward. Fahd A. Batayneh From: Seo, June [mailto:jseo@verisign.com]<mailto:[mailto:jseo@verisign.com]> Sent: Thursday, June 28, 2012 10:58 PM To: azoman@citc.gov.sa<mailto:azoman@citc.gov.sa>; chenting; jonathan.shea@hkirc.hk<mailto:jonathan.shea@hkirc.hk>; member@aptld.org<mailto:member@aptld.org> Cc: jian@aptld.org<mailto:jian@aptld.org>; sec@aptld.org<mailto:sec@aptld.org>; azoman@citc.gov.sa<mailto:azoman@citc.gov.sa> Subject: RE: RE: Seeking your comments on com-IDNs Dear Dr. Al-Zoman, Thank you again for sharing your concerns in great details. Verisign is keenly aware of the evaluation criteria you highlighted below and highly value them as well. At the same time, we are also very committed to operating as a best-in-class IDN registry as stated in our application by enhancing user experience bridging the current 2nd-level only IDN implementation to the fully internationalized navigation experience while minimizing user confusions and associated security risks as much as possible. I hope the following descriptions on our IDN gTLD approach will help you and other APTLD members understand what Verisign is planning on with those IDN gTLDs being applied for in conjunction with the existing .COM name space. 1. Name Space Relationship Between “.COM” and “Transliterations of .COM” as IDN gTLDs All .COM transliterations being applied for by Verisign won’t be really independent new domain space but resolution capabilities of a single registration. Only the current and future registrants of domain names in the .COM name space will be allowed to turn on (or activate) the transliterations of .COM as a resolution feature complimentary/supplementary to the exiting .COM. 2. Benefits to the Brand Owners As Verisign will allow only .COM registrants to activate the transliterations of .COM and won’t allow any 3rd party registrations directly in the transliterations of .COM name spaces independent of the .COM, this will bring great benefits to brand owners. For example, only the registrant of “Nike.com” (illustration purpose only as an example) will be allowed to turn on “Nike.<.COM Transliterations>.” This means brand owners, as .COM registrants, will have their interests already protected as no one else will be able to register “Nike.<.COM Transliterations>” as brand new domain names independent of “Nike.com.” A brand owner for any single .com registration regardless of script will be the only one that can activate the resolution in the DNS for a subsequent COM transliteration. For those brand owners who do not have 2nd-level domain names registered under .COM and feel their brands and intellectual properties infringed or compromised by someone else will have to pursue dispute resolutions only in one TLD space of .COM, instead of every single one of the 10 .COMs (.COM plus 9 transliterations of .COM). The same principle and benefits will also apply in the 3 transliterations of .NET in conjunction with .NET. 3. Enhanced Usability with Least Confusability As “Nike.com” and “Nike.<.COM Transliterations>” (again illustration purpose only in using the Nike example here) will belong to the single registrant, not to multiple parties as name spaces independent of each other, this will not only enhance usability but also reduce or even eliminate confusability. The end users can append either .COM or a transliteration of .COM to access a Web site being managed by a single party. This allows more user choices in accessing the same domain name by providing them with fully internationalized navigation experience with assurance and confidence not to end up with some other sites they do not intend to reach in use of one of 10 COM sting choices including ASCII. When it comes to bi-directional scripts like Arabic, the end users can type the domain name in one direction all the way through and will be able to reach the same destination under a single registration in .COM. 4. Audible Confusability between .COM and Transliterations of .COM In case a registrant in .COM does not activate a subsequent transliteration of .COM (the right side of the dot/the left side of the dot in Arabic case in IDN) in association with his/her domain name in .COM, the end users may not get to a site when they choose to append a transliterated COM in the Nike example. Yet, the end users at least won’t end up with a site which is not operated by “Nike.com” in this example eliminating the scenario of your concern, for instance, on audible confusability as illustrated in your phone conversation/radio ad examples. Again, Verisign’s approach is designed to address exactly these concerns of potential security or stability risks while it will give more choices to the registrants in .COM by enabling them with friendlier navigation experience for their users while preventing exploitation and unintended use the same domain names by 3rd parties along with internationalized extensions of .COM. 5. User Familiarity of “كوم” (Arabic Transliteration of COM) While “كوم” has no semantic meaning as you pointed out below in your message, our analysis and observation indicate that “كوم” - as a phonetic sound of “COM” in association with each other - is fairly widely being used in business practices and commonly recognized. For example as a data point to support this understanding of ours, a search on Google for the transliteration of COM in Arabic yields over 52 million entries on Arabic web sites. We also have identified a number of high-profile examples and showcases by established brands using “كوم” in association with “COM.” This makes us think that this string choice in Arabic is the natural candidate for the Arabic community and will contribute to enhancing the user experience. If you are interested, I will be happy to share those examples we have found in real business practices with you. 6. Technical Implementation in DNS All resolutions for each of the ten COMs for a single registration will point to the same NS record. The DNAME approach mentioned by Bill constructs maps entire trees and turns on the new gTLD strings for everyone even when they are unwanted. The registration process that is being planned will have a CNAME effect but activated as part of the registration within the same zone. 7. Verisign’s Community Outreach Efforts and Next Steps Verisign already has been outreaching a number of stakeholder groups in the script communities of the internationalized strings being applied for in order to debrief them on our planned approaches and user benefits. These stakeholder groups we’ve outreached and debriefed so far include a number of registrars, GAC members and ccTLD registries (some of them are also on this APTLD mailing list) located in the APAC and Middle East regions as well as some members of IP community participating in various community activities in ICANN. We will be happy to set up an individual meeting to do the same with your organization as well as the GAC members representing Saudi Arabia. Verisign has also publicly shared our IDN gTLD approach described in this message in the past IDN Software Developer’s Consortium meetings at least in 3 different occasions including the ones in Hong Kong in February 2011 around the APTLD/2011 APRICOT event, in San Francisco in March 2011 around the ICANN 40 meeting and in Singapore in June 2011 also around the ICANN 41 meeting, and I believe some of the APTLD members who participated in those IDN SDC meetings have been already debriefed and aware of this. I’ve already volunteered to participate in the WG being formed within the APTLD and look forward to having more discussions. Thanks and Regards, June <image001.gif> June (Jeongjun) Seo / 서정준 / 徐廷準 Director of Account Management & Business Development for APAC jseo@Verisign.com<mailto:jseo@Verisign.com> m: US) +1-571-214-5887 t: US) +1-703-948-3245 12061 Bluemont Way Reston, VA 20190 USA VerisignInc.com<http://www.verisigninc.com/> <image002.gif> From: Abdulaziz Al-Zoman [mailto:azoman@citc.gov.sa]<mailto:[mailto:azoman@citc.gov.sa]> Sent: Wednesday, June 27, 2012 3:23 PM To: Seo, June; chenting; jonathan.shea@hkirc.hk<mailto:jonathan.shea@hkirc.hk>; member@aptld.org<mailto:member@aptld.org> Cc: jian@aptld.org<mailto:jian@aptld.org>; sec@aptld.org<mailto:sec@aptld.org>; azoman@citc.gov.sa<mailto:azoman@citc.gov.sa> Subject: RE: RE: Seeking your comments on com-IDNs Dear June and all, Thanks for your comments ... The user benefits of fully internationalized navigation experience SHOULD NOT be in the cost of user confusability and security. The applied-for IDN gTLD string that are based on Transcription of dot-com (as it is presented in the application file) will cause a very serious users confusion and security (to the Arabic-speaking community). In the ICANN new gTLD Application Guide Book you will find the following texts (these are just examples) to show that string similarity is a Big Concern: Section 1.1.2.5 Page (1-9): "There are two main elements of the Initial Evaluation: 1. String reviews (concerning the applied-for gTLD string). String reviews include a determination that the applied-for gTLD string is not likely to cause security or stability problems in the DNS, including problems caused by similarity to existing TLDs or reserved names. Section 2.2 Page (2-4) 2.2 Initial Evaluation The Initial Evaluation consists of two types of review. Each type is composed of several elements. String review: The first review focuses on the applied-for gTLD string to test: · Whether the applied-for gTLD string is so similar to other strings that it would create a probability of user confusion; · Whether the applied-for gTLD string might adversely affect DNS security or stability; and Section 2.2.1.1 Page 2-5 2.2.1.1 String Similarity Review This review involves a preliminary comparison of each applied-for gTLD string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings. Note: In this Applicant Guidebook, “similar” means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone. The visual similarity check that occurs during Initial Evaluation is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity. This similarity review will be conducted by an independent String Similarity Panel. ----------------------------- عبدالعزيز بن حمد الزومان Abdulaziz H. Al-Zoman From: Seo, June [mailto:jseo@verisign.com]<mailto:[mailto:jseo@verisign.com]> Sent: Wednesday, June 27, 2012 2:49 AM To: chenting; jonathan.shea@hkirc.hk<mailto:jonathan.shea@hkirc.hk>; Abdulaziz Al-Zoman; member@aptld.org<mailto:member@aptld.org> Cc: jian@aptld.org<mailto:jian@aptld.org>; sec@aptld.org<mailto:sec@aptld.org> Subject: RE: RE: Seeking your comments on com-IDNs Thank you for all of your comments, suggestions and also sharing your concerns. I second Cherie’s suggestion. Some of the confusability scenarios raised here may not be unique or isolated cases only for IDNs. Depending upon the business rules and the registration policy of the proposing registries, I strongly believe the user benefits of fully internationalized navigation experience (the the right side of the dot or the left side of the dot in Arabic case) would far outweigh some of the potential concerns. Many of the usability issues also can be addressed through market awareness, education and eventually adoption as well as some policy considerations focusing on enhancing user experience by bridging the current 2nd-level only IDN implementations by gTLD registries and some of ccTLDs. Thanks, June From: chenting [mailto:chenting@cnnic.cn] Sent: Wednesday, June 27, 2012 1:03 AM To: jonathan.shea@hkirc.hk<mailto:jonathan.shea@hkirc.hk>; azoman@citc.gov.sa<mailto:azoman@citc.gov.sa>; member@aptld.org<mailto:member@aptld.org> Cc: jian@aptld.org<mailto:jian@aptld.org>; sec@aptld.org<mailto:sec@aptld.org> Subject: Re: RE: Seeking your comments on com-IDNs Dear Jonathan: We are glad to take this opportunity to forward our community input about new gTLDs. The application of IDN will directly influence the ultimate user experiences of various language communities. Based on our accumulated user experience research result up to now, the Chinese IDN “.com” causes no significant vulnerability and risks to the Internet users. Nevertheless, a more important concern from our part is about the paired delegation of domain names in both simplified and traditional Chinese Characters. In conclusion, considering the diversed demand of different language community, we suggest APTLD may establish a working group to discuss about this topic instead of a rushing conclusion. Many thanks! Cherie 2012-06-27 ________________________________ chenting ________________________________ 发件人： Jonathan Shea 发送时间： 2012-06-26 18:29:42 收件人： 'Abdulaziz Al-Zoman'; member@aptld.org<mailto:member@aptld.org> 抄送： jian@aptld.org<mailto:jian@aptld.org>; sec@aptld.org<mailto:sec@aptld.org> 主题： RE: Seeking your comments on com-IDNs Dear Abdulaziz and APTLD members, Understanding that this particular new gTLD-related issue and potentially more that will be coming are of concern to the APTLD community, I suggest the following process for APTLD to identify and confirm community-wide issues and provide comments to ICANN on behalf of the community 1. Jian Zhang, our GM, will monitor discussions and judge if a particular issue is likely of concern to the many of APTLD members. 2. If an issue is likely community-wide, our GM will draft a comment ASAP for members' review. The draft comment will be circulated via email to APTLD members for comments and feedback within one week. If the draft comment is not by itself onctroversial (e.g. no objections or concerns expressed by many members), this comment will be posted to ICANN by the APTLD Secretariat. Otherwise, that draft comment is likely not valid community-wide and we will not proceed to send it. Of course, it may be possible that after some modifications, a comment which is initially wrong may become valid community-wide. 3. There are no hard-and-fast rules to determine which comment is or is not a valid one for the APTLD community. The GM will decide based on the feedback received from members. So if you do not agree with a draft comment proposed by the GM, you should voice out right away. We will rely on Jian Zhang to start the ball rolling. Also, you should still post comments directly to ICANN while APTLD is doing so. In this particular case, I noted that Abdulaziz has already posted his comment on the new gTLD comment page. Regards, Jonathan Shea HKIRC ________________________________ From: Abdulaziz Al-Zoman [mailto:azoman@citc.gov.sa] Sent: Tuesday, June 26, 2012 1:19 AM To: member@aptld.org<mailto:member@aptld.org> Subject: Seeking your comments on com-IDNs Dear All, I would like to seek your feedback and comments in the following issue. I think it is going to bring to our (APTLD) user communities some confusion and security risks as it is mainly targeting our languages. There are 12 applied-for IDN gTLD strings by one Applicant who currently operates the .COM gTLD (All of us know it). All the 12 IDN gTLDs are basically Transliteration of "com" in 12 different languages Namely (I hope I will not have problem in displaying correcly all the IDN TLDs): ком קוֹם كوم कॉम नेट คอม コム<http://gtldresult.icann.org/application-result/applicationstatus/viewstatus:...> 大拿<http://gtldresult.icann.org/application-result/applicationstatus/viewstatus:...> 点看<http://gtldresult.icann.org/application-result/applicationstatus/viewstatus:...> 點看<http://gtldresult.icann.org/application-result/applicationstatus/viewstatus:...> 닷넷<http://gtldresult.icann.org/application-result/applicationstatus/viewstatus:...> 닷컴 Here is my feeling about the danger of approving such TLD (with respect to my Language the Arabic): This applied-for IDN gTLD string (كوم) will cause a very serious users confusion and security. It has no meaning in the Arabic language but rather it is the Transcription (http://en.wikipedia.org/wiki/Transcription_(linguistics) ) form of the existing gTLD (com) and hence they both possess the same phonetic sound (ˈkɑːm). Therefore, the applied-for IDN gTLD string (كوم) is confusingly similar to an existing TLD (i.e., .com). They (the applied-for and the existing gTLDs) are having similar phonetic sound. This will lead to a serious usability problem that will result in user’s confusability and domain name phishing activities that are considered one of the high security risks in the Internet. Hearing a website address (through for example a phone, radio, etc) that ends with the phonetic sound (ˈkɑːm) by an Arabic-speaking user will cause him/her to bewilder about the correct website whether it’s under the Latin TLD (.com) or the Arabic IDN TLD (.كوم). Thus, it may direct the user to the wrong website. To illustrate this problem consider the following example. An Arabic-speaking user hears a web site address from a local radio station and it sounds like (jɑːˈhuː (dot) ˈkɑːm). He/she will not be able to figure out whether the domain name is : yahoo.com<http://yahoo.com> Or ياهو.كوم (In Arabic it sounds like yahoo.com<http://yahoo.com>) Additionally, cyber-squatters will find the applied-for IDN gTLD string (كوم) a very good playground field for their unlawful activities. Many existing registered domain names under “.com” (there are more than 103 Million domain names as of June 2012 statistics from http://www.dailychanges.com/) will be vulnerable for phishing activities. To illustrate this security problem, cyber-squatters will be able to register IDN domain names that sound similar to the Ascii domain names under ".com", e.g: (All the following Arabic examples sound like the corosponding ascii domains under .com) ياهو.كوم to resemble yahoo.com<http://yahoo.com> قوقل.كوم to resemble google.com<http://google.com> فيسبوك.كوم to resemble facebook.com<http://facebook.com> ساب.كوم to resemble sabb.com<http://sabb.com> (a well know Bank in Saudi Arabia) سامبا.كوم to resemble samba.com<http://samba.com> (a well know Bank in Saudi Arabia) ارامكو.كوم to resemble aramco.com<http://aramco.com> (a well know Oil company) … etc Hence, to protect Arabic-Speaking businesses and users in the cyberspace, I strongly request not to accept this application. I would appeicate hearing from everyone his/her feedback and comments Thanks ----------------------------- عبدالعزيز بن حمد الزومان Abdulaziz H. Al-Zoman ----------------------------------------------------------------------------------- Disclaimer: This message and its attachment, if any, are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender immediately and delete this message and its attachment, if any, from your system. You should not copy this message or disclose its contents to any other person or use it for any purpose. Statements and opinions expressed in this e-mail are those of the sender, and do not necessarily reflect those of the Communications and Information Technology Commission (CITC). CITC accepts no liability for damage caused by this email.
