Patrick, I just published a new version of the I-D (https://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec-01) that incorporates your suggestions.
Regarding your comments about the matching algorithm, I will channel those to the appropriate person within ICANN. You may see the changes in the following link: https://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-tmch-func-spec-01.txt I appreciate your feedback. If neccesary, I will publish a new version, at the end, publishing a new version is cheap. Regards, Gustavo On 6/7/16, 23:31, "Patrik Fältström" <p...@frobbit.se> wrote: >On 8 Jun 2016, at 0:16, Gustavo Lozano wrote: > >>> Comments (some of this can also be fund in SSAC document SAC-060 23 >>>July >>> 2013): >>> >>> 1. It is not clear how permutations of strings are to be calculated (by >>> whom, and how) in the case confusability risks might arise. For example >>> by the use of language tables or other mechanisms like LGRs. >> >> There are two places where permutations may need to be calculated: >> >> * Trademark registration in the TMDB. In this case, the matching rules >>defined in "Explanatory Memorandum: Implementing the Matching Rules" >> >>(https://newgtlds.icann.org/en/about/trademark-clearinghouse/matching-rul >>es -24sep12-en.pdf) are used by the TMV (i.e. the company receiving the >>trademark registrations) to calculate permutations, if any. >> >> * Domain name registration path. Registries, as described in their >>Registry Agreement, must follow the "IDN Implementation Guidelines" >> >>(https://www.icann.org/resources/pages/implementation-guidelines-2012-02- >>25 -en). Per the Registry Agreement, each Registry may define their >>IDN-variant policies. Section 4.1.3 of the RPM Requirements makes this >>clear to Registry Operators (i.e. >> >>https://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requireme >>nt s-30sep13-en.pdf). > >My view is that this must be explained in detail how it works in the I-D >so that implementors of the I-D "do the right thing" depending on what >role the implementor have. > >>> 2. The term "leftmost" is a bit confusing when talking about labels in >>> DNS. I propose using "first" as in logical order. >> >> We only use A-labels in algorithms in the Internet-Draft; I think >>"leftmost" works, no? > >Well, maybe, but you should clarify this. It is not clear today. > >>> 3. The matching algorithm is not described, who is implementing it etc. >> >> The scope of this Internet-Draft is to define the technical interfaces >>to allow Registrars, Registries, TMV and TMDB to interact. >> >> Regarding the matching algorithms, please see answer to 1 above. > >Noted, but the algorithm used to normalize a string before doing the >matching must be specified or very explicitly referenced via a normative >reference. For example the "remove space" (or something similar) which I >do not understand what it means given "space" is quite undefined (or can >mean multiple things) when using Unicode. > >>> 4. There are no instructions on how to handle cases where the matching >>> algorithm in TMCH is different from matching algorithm one "expect" >>> ("one" as in the trademark holder). >> >> Sorry, I didn't get the question, could you please rephrase? > >The matching algorithm (or rather, the normalization that is defined) for >TMCH is done for english and latin script. Other languages and scripts >might want different normalization algorithms. That might create a >surprise and that should be explained. > > Patrik
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
