- vip - lists.icann.org

IDN Variant TLD Program - Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels
by Francisco Arias Sept. 25, 2012

Sept. 25, 2012

Colleagues, ICANN has published the first version for public comment of the proposed LGR process for the root. Note that a second public comment period is planned by November 2012. Your input on the proposed process and the principles that support it are more than welcome: http://www.icann.org/en/news/public-comment/lgr-procedure-24sep12-en.htm Regards, __ Francisco Arias gTLD Registry Technical Liaison ICANN On 9/25/12 10:40 AM, "ICANN News Alert" <communications(a)icann.org<mailto:communications@icann.org>> wrote: News Alert http://www.icann.org/en/news/announcements/announcement-3-24sep12-en.htm ________________________________ IDN Variant TLD Program – Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels 24 September 2012 Forum Announcement: Comment Period Opens on Date: 24 September 2012 Categories/Tags: Top-Level Domains Purpose (Brief): The Internationalized Domain Name (IDN) Variant TLD Program deals with the variant form of top-level domain (TLD) names in different scripts. To enable IDN Variant TLDs in the root, it is necessary to establish the Label Generation Rules (LGR) for the DNS Root Zone. The Label Generation Rules Process is a way to develop and maintain the Label Generation Rules for the Root Zone in respect of IDNA labels. The process must be in place to enable the delegation and management of IDN Variant TLDs. The Label Generation Rules (LGR) Process project team, consisting of global volunteers with expert consultants and ICANN staff, has produced the first public draft of the LGR Process document. The team now seeks community input on the proposed process and the principles that support it. The Label Generation Rules (LGR) Process document will be discussed at a public session at the ICANN meeting in Toronto in October 2012. The session schedule will be available at ICANN Toronto Meeting Website<http://toronto45.icann.org/full-schedule>. Comments received in this Public Comment period as well as community feedback during the Toronto meeting will be incorporated into the final draft and published for second round of Public Comment in November 2012. Public Comment Box Link: http://www.icann.org/en/news/public-comment/lgr-procedure-24sep12-en.htm

1 0

IDN Variant TLD Program Update
by Francisco Arias Aug. 24, 2012

Aug. 24, 2012

Dear colleagues, The below announcement may be of interest for you. We plan to post periodic updates to this list, but also note that the rootLGR mailing list, though closed-posting, has its archives open at: http://mm.icann.org/pipermail/rootlgr/ Regards, __ Francisco Arias gTLD Registry Technical Liaison ICANN >ICANN News Alert > >http://www.icann.org/en/news/announcements/announcement-23aug12-en.htm > >____________________________________ > > >IDN Variant TLD Program Update > >23 August 2012 > >The IDN Variant TLD Program has the following two updates: > > I. Volunteer Team formed to assist the development of the Label >Generation Ruleset Process for the Domain Name System (DNS) Root Zone > > ICANN is pleased to announce the formation of a global volunteer >team, comprised of community experts, who will work with ICANN on the >project to define the Label Generation Ruleset Process for the DNS root >zone. This project is part of the IDN Variant TLD Program (see below) that >is intended to lead to the delegation of IDN Variant TLDs. Delegation of >these types of IDN TLDs is expected to broaden global participation in the >domain name system, but must be accomplished in a way that ensures good >user experience. > > This particular project will develop the process to define >allowed >code points, corresponding exchangeable variant code points, and related >allowed states for IDN Variant TLDs. > > The project requires significant technical expertise and the >individual members of the volunteer team (listed below) possess >capabilities in IDNA, Domain Name System, Linguistics, Unicode and Policy >Development. > > The volunteer team will undertake the work through periodic >teleconference calls and two face-to-face meetings. The first meeting will >be on 29-30 August 2012 in Los Angeles, United States. The second two-day >working session is planned during the ICANN meeting in Toronto, Canada. >There will be an open public session in the Toronto meeting at which ICANN >staff and volunteer team representatives will present an update on the >progress and answer questions. > > The volunteer team is comprised of the following members from 18 >countries and territories: > > Fahd A. Batayneh > Chris Dillon > Neha Gupta > Sarmad Hussain > Akshat Joshi > Daniel Kalchev > Yoav Keren > Dmitry Kohmanyuk > Mahesh Kulkarni > Nadya Morozova > Panagiotis Papaspiliopoulos > Alireza Saleh > Vaggelis Segredakis > James Seng > Vladimir Shadrunov > Syed Iftikhar H. Shah > Will Shorter > Alexei Sozonov > Mirjana Tasic > Joseph Yee > Yoshiro Yoneya > Zhoucai (Joe) Zhang > Linlin Zhou > > Team Observers: > Rinalia Abdul Rahim > Edmon Chung > Raymond Doctor > > II. Updated IDN Variant TLD Program posted > > ICANN has updated the IDN Variant TLD Program Plan ( >http://www.icann.org/en/resources/idn/idn-variant-tld-updated-plan-23aug12 >-en.pdf) >that describes the projects that are intended to lead to the delegation of >IDN variant TLDs. The plan defines the processes that must be in place to >enable the delegation and management of IDN Variant TLDs. > > Two previous versions of the plan have been posted for public >comment ( >http://www.icann.org/en/news/public-comment/idn-variant-tld-revised-progra >m-plan-04may12-en.htm) >and discussed with the community during the ICANN meeting in Costa Rica in >March 2012. This latest version reflects the latest public input. > > The Program follows on from the IDN Variant Issues Project that >completed its work with the publication of the final Integrated Issues >Report ( >http://www.icann.org/en/resources/idn/idn-vip-integrated-issues-final-clea >n-20feb12-en.pdf) >on 20 February 2012. > > Interested members of the community can receive updates and >participate in the discussion of the variant work by subscribing to the >vip(a)icann.org mailing list (https://mm.icann.org/mailman/listinfo/vip) or >by visiting the Community Wiki at: >https://community.icann.org/display/VIP/

1 0

(no subject)
by JFC Morfin Aug. 24, 2012

Aug. 24, 2012

http://www.icann.org/en/resources/idn/idn-variant-tld-updated-plan-23aug12-… Just wanted to know if this list was still active as the one for the concerns above or should I subscribe somewhere else? Best jfc

1 0

FW: Seeking Your Comments on .com IDNs
by Fahd Batayneh July 1, 2012

July 1, 2012

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(a)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(a)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(a)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(a)citc.gov.sa<mailto:azoman@citc.gov.sa>; chenting; jonathan.shea(a)hkirc.hk<mailto:jonathan.shea@hkirc.hk>; member(a)aptld.org<mailto:member@aptld.org> Cc: jian(a)aptld.org<mailto:jian@aptld.org>; sec(a)aptld.org<mailto:sec@aptld.org>; azoman(a)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(a)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(a)hkirc.hk<mailto:jonathan.shea@hkirc.hk>; member(a)aptld.org<mailto:member@aptld.org> Cc: jian(a)aptld.org<mailto:jian@aptld.org>; sec(a)aptld.org<mailto:sec@aptld.org>; azoman(a)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(a)hkirc.hk<mailto:jonathan.shea@hkirc.hk>; Abdulaziz Al-Zoman; member(a)aptld.org<mailto:member@aptld.org> Cc: jian(a)aptld.org<mailto:jian@aptld.org>; sec(a)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(a)hkirc.hk<mailto:jonathan.shea@hkirc.hk>; azoman(a)citc.gov.sa<mailto:azoman@citc.gov.sa>; member(a)aptld.org<mailto:member@aptld.org> Cc: jian(a)aptld.org<mailto:jian@aptld.org>; sec(a)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(a)aptld.org<mailto:member@aptld.org> 抄送： jian(a)aptld.org<mailto:jian@aptld.org>; sec(a)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(a)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.

1 0

Seeking comment: Project 6: Preliminary Discussion Draft Document for User Experience Implication of active TLDs.
by Dennis Chang June 26, 2012

June 26, 2012

Dear friends and colleagues of the IDN Variant Program, Attached is the draft study proposal for examining the user experience implications of active variant TLDs. Also known as the IDN Project 6. We are sending this out in advance of the ICANN Prague session to facilitate fruitful discussions at the session. We invite you to attend the IDN Variant Program session on Thursday, June 29. 11:00 to 12:30. (Prague time) for a brief of the IDN Variant Program followed by P6 discussion. If you'd like to provide your feed-back via email please write to idnp6(a)icann.org Kind Regards, Dennis Chang Executive Program Management Consultant dennis.chang(a)icann.org 213-293-7889 Skype: dennisschang

6 7

Request for support in Seeking User Experience Expert Consultant
by Dennis Chang June 20, 2012

June 20, 2012

Dear friends and colleagues, The IDN Variant Program team requests your support in recruiting a consultant for our IDN Project 6: Examining the User Experience Implications of Active Variant TLDs Attached is the description for the role and application instruction. Please feel free to forward to anyone who may be interested. Kind Regards, Dennis Chang Executive Program Management Consultant dennis.chang(a)icann.org 213-293-7889 Skype: dennisschang

1 0

FW: ICANN News Alert -- Call for Volunteers: Developing the Process for Root IDN Table Creation and Maintenance
by Francisco Arias June 18, 2012

June 18, 2012

The email below may be of interest to you. Regards, __ Francisco. On 6/18/12 1:24 PM, "ICANN News Alert" <communications(a)icann.org> wrote: > ICANN News Alert > <http://www.icann.org/> > News Alert > http://www.icann.org/en/news/announcements/announcement-18jun12-en.htm > > Call for Volunteers: Developing the Process for Root IDN Table Creation and > Maintenance > 18 June 2012 > > * Deadline for responses is 13 July 2012 > > ICANN is seeking volunteers to work on advancing IDN capabilities in the DNS. > The project 2.1 "Root IDN Table Process" part of the IDN Variant TLD Program, > is designed to develop, in consultation with the community, the process to > define: > * allowed code points, > * corresponding variant code points, and > * related allowed states for IDN Variant TLDs. > ICANN is soliciting participation from volunteers with the following areas of > expertise: IDNA, DNS, Linguistics/Unicode, Policy. > > The project team will include additional consultant expertise to help in the > process. > > ICANN has a limited budget to support team meetings such as travel, > accommodation, and other expenses. > General responsibilities for volunteers: > * Contribute to developing the Process for Root IDN Table Creation and > Maintenance > * Research and provide input on issues discussed during meetings > * Attend two face-to-face meetings (likely during the last week of August in > Los Angeles, US, and mid-October 2012 in Toronto, Canada) > * Participate in regular teleconferences (time to be determined) > * Expected time commitment of 2 to 4 hours per week during a 4-month period > IDNA Expertise qualifications: > * Expertise with IDNA and preferably active on internationalization work > * Participation in relevant IDNA working groups > DNS Expertise qualifications: > * Expertise with DNS standards > * Active in related DNS technical fora (e.g., IETF DNSext, DNSop) > Linguistics/Unicode expertise qualifications: > * Expertise in linguistics > * Familiarity with Unicode > Policy expertise qualifications: > * Participation in ICANN's policy development process; or > * Have participated in, at least, one ICANN working group, preferably on IDN > related issues > Selection and Recruitment Process for Case Study Members: > * Indications of interest should be sent to idnvarianttlds(a)icann.org no later > than 13 July 2012. > * Interested experts are invited to submit a résumé (Curriculum Vitae) and an > expression of interest statement demonstrating how they meet the > qualifications for one or more of the areas of expertise specified above. > * The ICANN IDN Variant TLD Program team will select the team members ensuring > a diverse composition of the members in terms of language/script communities > represented. > * Applicants will be notified no later than 30 July 2012. > Background on the IDN Variant TLD Program > On 20 April 2011, ICANN announced the IDN Variant Issues Project to explore > the benefits and risks associated with the potential inclusion of IDN variant > TLDs in the DNS root zone. This project was initiated in response to a 2010 > ICANN Board of Directors resolution > <http://icann.org/en/groups/board/documents/resolutions-25sep10-en.htm#2.5> . > Two phases of the project have been completed to date. > > Phase I involved the formation of six case study teams for the Arabic, > Chinese, Cyrillic, Devanagari, Greek and Latin scripts. These teams were > comprised of community experts with support from ICANN that worked on > identifying issues related to IDN variant TLDs for each particular script, > resulting in the publication in October 2011 of six individual reports > detailing their findings. > > Phase II focused on integrating those six case study reports into the > Integrated Issues Report. To complete this phase, ICANN formed a coordination > team comprised of experts from each of the case study teams. The coordination > team advised ICANN on completing the Integrated Issues Report, which > summarizes and categorizes the various issues related to the identification > and management of IDN variant TLDs. > > The next phase (phase III) outlined in the proposed program plan > <http://icann.org/en/news/public-comment/idn-variant-tld-revised-program-pla… > 04may12-en.htm> includes a number of activities resulting from the issues > identified in the final Integrated Issues Report > <http://icann.org/en/resources/idn/idn-vip-integrated-issues-final-clean-20f… > 12-en.pdf> [PDF, 2.15 MB]. The work is now focused on using the approach > outlined in the Integrated Issues Report to define milestones that must be > completed to manage the implementation of IDN variant TLDs. > > The goal of the program is to define the necessary processes that must be in > place to enable the management of variant TLDs. This incorporates the creation > and maintenance of IDN tables for the root zone, and updating operational > processes as appropriate to allow for the implementation of the IDN variant > TLDs. > > > > Email Market

1 0

Revised IDN Variant TLD Program Plan for next steps
by Francisco Arias May 6, 2012

May 6, 2012

Colleagues, This is to inform you that we have posted a Revised IDN Variant TLD Program Plan for public comment at: http://www.icann.org/en/news/announcements/announcement-2-04may12-en.htm Regards, __ Francisco.

2 2

The public comment period for the VIP plan has been extended
by Francisco Arias March 16, 2012

March 16, 2012

FYI, the public comment period for the VIP plan has been extended: http://www.icann.org/en/news/announcements/announcement-2-16mar12-en.htm __ Francisco

1 0

Re: [vip] Draft on IDN Tables in XML
by Andrew Sullivan March 14, 2012

March 14, 2012

On Wed, Mar 14, 2012 at 10:45:58AM -0400, Ram Mohan wrote: > Kim, > > I am not certain registries would want to use an automated/machine-readable > mechanism for importing tables from other registry IDN implementations. I strongly agree, and would go farther: I think it would be a bad idea for registries to blindly import tables from other registries. But registries are not the only people who may be interested in the variant relationships in a registry. For instance, the anti-abuse community might reasonably want to use those tables as the basis for constructing policies for what domains ought to be expected to be delegated. The anti-abuse community might want to use those tables to detect opportunities for phishing, and to try to produce mitigation strategies. The corollary to using registry policy as the source of sane IDN deployment is that clients need to be able to know what those policies are, and to test actual network behaviour against the policy. In the absence of such tests, the registry policies aren't enough. The only way that applications are going to be able to integrate the expected policies in their applications is if the policies can be expressed in a machine-readable way. If they can't be, then I predict the policies will be "boutique" ones: some applications will work, but others won't. (This is written from the ICANN Universal Acceptance of TLDs session, where I am keenly hoping this application perspective will be expressed.) Best, A -- Andrew Sullivan ajs(a)anvilwalrusden.com

1 0