[Tmch-iag] N3, N4 and N5 Comments

Sat Mar 10 02:02:36 UTC 2012

Hi Hong,

See my comments below regarding IDN variants.

On 3/8/12 10:42 PM, "Hong Xue" <hongxueipr at gmail.com<mailto:hongxueipr at gmail.com>> wrote:

1) Identical Match Rules

Identical match shall take into account the variant characters. It may need Rule E to specifically address rules for variant issues.

Actually variant characters are not limited to IDNs. ICANN Variant Issue Project covers Latin character variants as well, such as harbour v. harbor. VIP final report has been published and now subject to pubic comments.

While it is true that the VIP report touched on the type of variants you mention, it warns strongly about them. The Latin case study ream that wrote a report that was the base for the final report that you mention, recommended against any type of variants for the Latin script.

5) Should Registry or TMCH generate character mapping rule sets?

I strongly believe Registry or TMCH should adopt and implement the character variant tables at IANA repository. Such practice is highly consistent with the IDN guidelines and reflects the consensus of a certain language community. It would be really chaotic if many different tables are used by the registry or TMCH for a given character set.

Just want to clarify that the IDN variant tables at IANA are the tables the registries decide to publish and IANA is merely a repository for them. As far as I can tell there are no "official" tables for specific languages or scripts. As of now, each registry decides which IDN variant tables to use.

I get your point and understand it. I'm not arguing against it, but merely explaining the status quo.

Regards,

__

Francisco.

Hong

--
Dr. Hong Xue
Professor of Law
Director of Institute for the Internet Policy & Law (IIPL)
Beijing Normal University
http://www.iipl.org.cn/<http://iipl.org.cn/>
19 Xin Jie Kou Wai Street
Beijing 100875 China

On Thu, Mar 8, 2012 at 3:25 AM, Dana Robinson <dana at techlawllp.com<mailto:dana at techlawllp.com>> wrote:
IAG,

Regarding N3 and N4:

The comments by Mr. McElwaine are good.  I also agree with the comments recently posted by Brian Winterfeldt and Keith Barritt.

Regarding N5:

Issue 1 Applying the Identical Match Rules

Tom Barrett's comments are worth looking at.  Do we have an existing basis that only allows @ and & to be spelled out?  Other symbols and punctuation are used by trademark owners as part of their mark, and may wish to spell those out, rather than omit them or replace them with hyphens.  Can we give the applicant the choice?

Rule B

It would seem that an applicant should be entitled to choose the language that it desires for spelling out its special characters.  If the mark includes &, this is spelled out "a-n-d" in English, and "y" in Spanish.  If we required a Spanish applicant to use "y" but the mark was actually otherwise an English word, then it could lead to an odd result for the applicant.  Thus, it would seem that the applicant should be able to choose the spelling and then indicate the language of the spelling being selected, or if the system is intended to be automated so that the applicant cannot choose the spelling, then all UN languages need to have a drop down so that if you choose & and then choose "Spanish" you end up with "y" as the spelling.

Is there a reason that the applicant should not be able to claim multiple translations of a symbol like &?  Could the owner of fictional trademark X & Y claim "xyy" as well as "xandy"?

Rule C

Is there a reason that we cannot 1) allow the applicant to choose which variation(s) they wish to result from their dropped characters; and 2) allow the applicant to claim more than one variation?  If there is a fee for each claim, then there is an incentive for the applicant to be reasonable in the number of variations, and this allows a trademark owner to adequately cover for the "missing" characters from their trademark with different dashes or lack thereof.

Issue 2: Registry Character Mappings

It would seem overly complicated to have each registry providing its mapping to the TMCH, as described under option (b).

Thus, option (a) seems to be the best, and also allows a registry to adopt mapping rules that might be suited to the intended or native language of the registry.

Yours,

Dana

--
Dana Robinson,
Partner
TechLaw LLP
P.O. Box 1416
La Jolla, CA 92038
858-488-2545<tel:858-488-2545>
Fax: 858-777-3347<tel:858-777-3347>

**** CONFIDENTIAL INFORMATION ***** CONFIDENTIAL INFORMATION *****

This e-mail transmission and any attachments contain confidential information from attorney Dana Robinson and/or TechLaw LLP, which may be protected by the attorney client privilege and/or the work product doctrine. If you are not the intended recipient, you may not read, copy or use this information. Please notify the sender immediately by reply e-mail and delete this message.
IRS Circular 230 Legend: If any advice concerning U.S. Federal tax issues is contained in this communication or attachments, such advice is not intended to be used and cannot be used for the purpose of avoiding penalties under the Internal Revenue Code or promoting, marketing or recommending to another party any transaction or matter addressed herein.

_______________________________________________
tmch-iag mailing list
tmch-iag at icann.org<mailto:tmch-iag at icann.org>
https://mm.icann.org/mailman/listinfo/tmch-iag

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tmch-iag/attachments/20120309/94b3e3c9/attachment.html 