I fully agree with all the observations of Edmon. Edmon: [For the Sunrise process, it would be optimal but not critical for the TMCH to also implement IDN Variants, and it could be as simple as including them into the SMD, again based on a very simple algorithm that needs to be implemented by the TMCH.] Hong: for sunrise process, if ICANN resists to any technical adjustment to TMCH, it should, at least, allow the relevant IDN registries to either delegate or reserve the IDN domain name variants (e.g. "example" in TMCH record should be able to link up to the variants "EXAMPLE" although it is not in TMCH records). Otherwise, those registries would have to have a second-round sunrise for the same strings. The current Requiments even deprive the registries' discretion in sunrise registration, which is not consistent with the reply that "relying on registries to handle variant issues". How can they handle with tied hands? It is even worse with trademark claims. Under the current interpretation, if only "example" is in the TMCH record, anyone applies for domain names in its IDN variant forms like "EXAMPLE", "exaMPle", "eXample" would not be notified and the TM holder won't be notified either, which would completely fail the whole purpose of trademak claims. Why should the TM holders submit to a useless database and registries pay to a useless service? Of course, the final harm would be done to the IDN users/consumers who are confused by the counterfeit or pirate sites at the IDN variants domain names of a trademark that should have been protected under the TMCH design. The gaps ICANN asked us to identify are huge. But if ICANN wishes to listen to the pertienent language community, the solution would be widely available. For example, it has been proposed at the Chinese community to develop a simple but efficient "Chinese Interface" attached to the TMCH database to enable the registries that "handle" the variant characters to use. It would not only fix the gaps but enhance the IDN registeries' choice. In any case, refusing to change or adjustment cannot be the solution. P.s. the IDN WG meeting normally conflicts with ccNSO council meeting in the afternoon. I hope another time slot be found. Hong On Tue, Jul 9, 2013 at 8:53 AM, Edmon <edmon@isoc.hk> wrote:
Thanks Olivier for the note and the arrangements. We will remain flexible for both.
In terms of preparing for the discussion, below are some thoughts I have on the topic. Others on the WG please provide your thoughts as well as we prepare for the meeting.
1. "rely on registries to handle variant issues"... the issue will more likely be at registrars especially the inconsistency it will have interfacing with the TMCH and the Registry if IDN Variants are implemented at the registry and not the TMCH. This ultimately leads to confusion of the registrant, which negatively impacts consumer trust.
2. The GNSO has deliberated on the issue of IDN and RPM (Rights Protection Mechanisms) and believe they should be included in the same processes. In addition the GNSO IDN WG has indicated " Agreement that measures must be taken to limit confusion and collisions due to variants"
3. All IDN Variant implementation and tables from registries MUST have been submitted (to TAS) as part of their application. ICANN already has all the information necessary to provide the TMCH for implementation.
4. "There is no widely accepted definition of what constitutes a “variant” to a trademark." This is an irrelevant statement because we are not talking about a "variant" to a "trademark" but an IDN Variant to an intended domain.
5. " Given that marks from all jurisdictions can coexist in the TMCH, the TMCH cannot “block” submission of a record based on an existing TMCH record." That is correct and it is not the intent to ask for "blocking" any submissions, the example was provided to demonstrate the importance and the prevalence of such undertaking in the context of TM. What is being asked is that the TMCH be technically aware of IDN Variants, not to "block" submissions based on IDN Variants (which the TMCH is not tasked to do anyway as correctly identified).
6. " Domain Name Matching Rules", in the example it is clearly indicated that "EXAMPLE" matches "example" in a strict "matching", they would NOT match (one is in Capital letters and one in small letters) the reason they match is because some additional "mapping" is applied. That is the case for English and Latin based marks. I presume similar handling is provided for accented characters or even for Greek/Cyrillic?... The question therefore is why is the same not implemented for Chinese and other IDN languages for which IDN Variants are required.
7. " This was also generally considered to be unworkable, as it essentially would mean multiple customized versions of the services, which would reduce efficiencies and drive up cost." This statement is unfounded. One implementation is sufficient which could take multiple tables. And for Chinese, I believe simple study of the applications would show identical tables across applicants. Such studies can easily be done, but have not been done and premature conclusions drawn from misunderstanding.
8. An IDN Variant is NOT "registered" as a separate domain. That is perhaps the biggest misunderstanding about IDN Variants. They are considered atomic to the applied for domain. No transaction is being conducted. Again, a simple study of the applications ICANN already has would I believe reveal that it is much less complex than what some claim the IDN Variants handling to be.
All the TMCH has to implement is a simple algorithm (connected to IDN Tables submitted already) in its process for responding to registry requests for the claims process. For the Sunrise process, it would be optimal but not critical for the TMCH to also implement IDN Variants, and it could be as simple as including them into the SMD, again based on a very simple algorithm that needs to be implemented by the TMCH.
The situation it seems right now (at least from my vantage point) is there is resistance from the TMCH to make any technical adjustments even when they are in reality relatively simple ones and we are forced with "work around" solution as described, which are wasteful of Internet resources. That is not "doing it right" in my view.
Edmon
-----Original Message----- From: idn-wg-bounces@atlarge-lists.icann.org [mailto: idn-wg-bounces@atlarge- lists.icann.org] On Behalf Of Olivier MJ Crepin-Leblond Sent: Tuesday, July 9, 2013 5:53 AM To: idn-wg@atlarge-lists.icann.org Subject: [IDN-WG] Fwd: Response to the ALAC Statement on TMCH and IDN Variants
Dear IDN WG members,
please be so kind to find the Board New gTLD Program Committee's reply regarding the ALAC Statement on the Trademark Clearinghouse and IDN Variants which we submitted at the end of May.
I note that the response suggests that a small group meets with select Board members. I have suggested that those Board members come to the A-Large IDN WG meeting on Wednesday afternoon. Failing that, I have asked that Gisella & her counterpart on Board Support would look for a suitable slot for a meeting.
Kind regards,
Olivier
-------- Original Message -------- Subject: Response to the ALAC Statement on TMCH and IDN Variants Date: Mon, 8 Jul 2013 11:01:08 -0700 From: Cherine Chalaby <cherine.chalaby@icann.org> To: Olivier MJ Crepin-Leblond <ocl@gih.com>
Dear Olivier,
On behalf of the New gTLD Program Committee (NGPC), I thank you for providing the ALAC Statement on the Trademark Clearinghouse (TMCH) and IDN Variants, dated 30 May 2013. The NGPC appreciates the attention the ALAC has given to this topic and has reviewed the statement carefully.
Variants are a complex topic, and the current approach with variants in TMCH is to leave variants out of TMCH itself, and rely on registries to handle variant issues. There are good reasons for taking such an approach and the NGPC believes that the current direction is appropriate.
Registries have their own policies for variants (whether to reserve, allocate, etc.). If, however, there are any specific gaps in behavior with respect to trademarks, variants, and TMCH, it would be helpful to identify them and raise them in the appropriate venues . We encourage ALAC to identify any such issues.
To encourage discussion and explore specific potential gaps in more detail, it may be helpful to have a small group of interested parties (from ALAC, staff, and selected board members) meet in Durban. The goal of such a meeting would be to identify specific gaps in the area of trademarks and IDN variant names where additional work might be appropriate.
Please find attached the full response of the NGPC to the ALAC Statement.
All the best,
Cherine
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3204/6473 - Release Date: 07/08/13
_______________________________________________ IDN-WG mailing list IDN-WG@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/idn-wg
IDN WG Wiki: https://community.icann.org/display/atlarge/At-Large+IDN+Policy
-- Professor Dr. Hong Xue Director of Institute for the Internet Policy & Law (IIPL) Beijing Normal University http://www.iipl.org.cn/ 19 Xin Jie Kou Wai Street Beijing 100875 China