ICANN IDN Variant TLDs Issues Project
Coordination Team Meeting, Wednesday, 9 November 2011
Meeting Agenda (and Notes):
- Welcome and Roll Call (start recording)
On the call: Sarmad Hussein, Baher Esmat, Hayley Laframboise, Kim Davies, Vaggelis Seggredakis, Patrick Jones, Andrew Sullivan, Kurt Pritz, Julie Headlund, Vladmimir Shadrunov, Nicholas Ostler, Vaggelis Segredakis, Joseph Yee, Alexey Mykhaylov, Dennis Jennings, Francisco Arias, Neha Gupta, Manal Ismail, Akshat Joshi, Cary Karp, Xiaodong Lee, Panagiotis , Karen Lentz, Leo Vegoda
Apologies: Raymond Doctor, James Seng.
2. December Face-to-Face Meeting (Naela)
- 12 and 13 December 2011 in Marina del Rey, USA
- Visa issues
- Travel and accommodation issues
Meeting is confirmed for 12-13 December in Marina del Rey, California.
12 of the 17 members have confirmed they will attend the meeting in person and 2 more plan to attend remotely.
All team members traveling to MdR for the meeting should have received a welcome email from the ICANN Travel Constituency department to start planning their travel details.
Please respond to this email as soon as you can as we are only a little over 5 weeks away from the meeting
All of those who requested an initiation letter to help with processing the visa should have received the letter from my colleague Halyley.
Action item: Naela to send email to team with the travel contact details
- Actions on variants (Francisco | proposed definitions circulated last week):
Francisco circulated the definition document.
Dennis asked for comments on each.
Francisco led the discussion on each of the definitions:
- Block:
Definition from document Francisco sent:
An administrative action by a registry over a particular string (a potential domain name) rendering such string unavailable for allocation to anyone
Discussion:
This is what is done to avoid anyone else from having the name. this applies to undesired variants, potentially confusing labels or there are sensitivity issues with delegating such a name.
Vladimir: asked if these labels apply to top-level only or lower levels as well? There might be a conflict between these definitions and ones already established in registry agreements concerning the lower levels.
Francisco: Any documents produced in this project should reference previous documents and definitions.
Dennis: it is worth checking the guidebook to make sure that we are not introducing new definitions that differ from what is in the guidebook.
Francisco: there should not be a conflict with the guidebook.
Manal: agreed that the project should be clear that we are working on the top-level, this was agreed from the beginning. The information in registry agreements concerns second level.
- Reserve:
Definition from document Francisco sent:
To set aside a name for potential allocation to a particular entity (TLD registry in the case of the root). The name is not yet allocated, but could be (to that particular entity) if/when certain conditions are met.
Discussion:
This applies to a variant that is not problematic but at the moment it is not decided by the registry but can be activated in the future. Can be reserved for the registry and can be activated in the future.
Sarmad: there is one potential issue with the implementation. There is potentially many variants of many string. The largest chunk of those variants would go to reserve. It may be good to contain the variants via an algorithm to identify them and not via a list because the list would become too long.
Dennis: could we turn this into an issue, and how it is resolved should be noted.
- Allocate:
Definition from document Francisco sent:
It is the first step on the way to activation. The registry makes an administrative association between a string and some entity that requests the string, making the string a potential label inside the zone, and a candidate for activation. Allocation alone does not affect the DNS at all.
Discussion:
Xiaodong Lee: Is this a candidate for activiation or delegation?
Francisco clarified that it is delegation which is one form of activation.
- Delegate:
Definition from document Francisco sent:
The act of entering parent-side NS (name server) records in a DNS zone, thereby creating a subordinate namespace with its own SOA (start of authority) record. See RFC 1034 for detailed discussion of how the DNS name space is broken up into zones.
Discussion:
This definition is better explained in rfc 1054
Sarmad: could last sentence be added as a footnote?
- Mirror
Definition from document Francisco sent:
To activate two or more domain names such that for a namespace starting with one, the namespace starting with the other is isomorphic to the first, subject to the usual DNS loose consistency strictures. Currently, there are two different techniques for this. The first is aliasing: CNAME, DNAME, and other such techniques that redirect a name or a tree, effectively substituting one label for another during DNS lookup. The second is by using provisioning constraints, such that an underlying provisioning system always effects a change in all of the names whenever that change is effected in one of the names.
Discussion:
This is applicable in two areas: DNAME and using provisioning constraints.
Vladimir: useful definition but is there a way to better define isomprphic
Andrew: The problem with mirroring or alternate names is that the basic idea is that the DNS data is the same, but in reality this is hard in DNS b/c of synchronization and caches. The idea is that there are two sets of names and the pairs or two sides should have the same effective Rdata for every name with that root. It is hard to state that while remaining clear about the root.
Manal: definition refers to two techniques. On the second (provisioning), this is hypothetical, is that correct?
Francisco: clarified that we do have such a mechanism, it is currently used in second and lower levels.
Francisco: suggested that we could perhaps mention that this has not been implemented in the root, and probably something could be done before implemented. As well as saying that this has already been implemented in the second level, for example .CAT uses DNAME to mirror IDN names.
Vaggelis: also stated that they are using DNAME, and they have documentation about their experiences.
Manal: is parallel provisioning done manulally or automated?
Francisco: could be automated.
Sarmad: it may be useful to document what is meant by these terms such as dname, cname and parallel provisioning. A second point, there may be other techniques developed. It may be useful to have two different paragraphs, one on definition and one on explanation of techniques used.
Action item: Francisco to look into that.
- Activate
Definition from document Francisco sent:
It is the act of entering parent-side DNS records in a zone (e.g., NS, DNAME, CNAME, NAPTR) making the name entered resolvable in the DNS. Note that delegating a name implies activating it, but activation does not necessarily imply delegation.
Discussion:
Activation does not imply delegation, entering any DNS record while delegation is concerned with adding NS records.
Xiaodong: the definition of delegate is derived from 1035? (not clear). Clarified that adding DNAME record is not delegation.
Action item: Xiaodong will check the Chinese issues report to see if this current definition affects rfc 3743.
4. Selected Terminology (Nicholas | proposed definitions circulated last week):
- Homograph,
- (Approximate) Homoglyph,
- Homoglyphic Distance (character or string level?),
- Visually Confusable Characters,
- Homoglyphic Strings,
- Alloglyphs,
- Synoglyph
Nicholas: there have been some discussions on the list:
There were comments from Cary and Sarmad. Two issues: Cary asked if we are talking about gTLDs only or TLDs more generally is what we are defining policy for. Cary said it does not make sense to have different rules. Andrew explained that we are discussing the root and one policy makes sense.
Action item: Nicholas to adjust the text as appropriate.
Another issue Cary raised whether there can be homoglyphs within a single script. For example, schwa and turned e.
However, when you start talking about two languages that use the same script. It is arguable that abstract characters that underline one language are different than abstract characters used for another.
If you study the definition of abstract character in practice, we are talking about code points. Talking in terms of homoglyphs is confusing. We are talking about the relationship between code points and glyphs.
A related confusion that came up is Sarmad’s suggestion is the relationship between TC and SC as synoglyphs.
Nicholas: on the question whether more linguistic work is needed, the terms are defined adequately. The document is organized in an introduction followed by the definitions. It is not clear how it fits in the current definitions document we have.
Cary: one of the concepts we don’t see here is fonts which is where all of this comes in play. We are fishing around and hopping from one set of terms to another. Don’t see how we can do this without looking on commonly used fonts. There are no absolute relationships. Code points is devoid of any visual identity and visual identity is what we are concerned about.
Nicholas: thinking of variants in terms of homoglyphy is of concern to me.
Sarmad: in a separate discussion and context, recently realized rfc5890 may have a different definition of character. The difference maybe user vs. protocol prespective.
As far as this discussion is concerned, clearly there are three forms: underlying form (abstract character), intermediate (code point), and surface (glyph).
Action item: Dennis asked for this discussion to be taken to the mailing list
5. Lists of Valid Code points and variant derivation logic per script/language (Andrew | discussion in the list):
- We have consensus on the need for it
- Is it script or language based?
Consensus on mailing list exchanges appears to be two techniques:
- complete list of all code points to be accepted and all of the variant rules along with complete consensus. This has the advantage of being a complete list. Disadvantage is the complete consensus.
- build list gradually from individual requests as they come in. Advantages: a descriptive set of procedures, a disadvantage is that new information may come along midstream that will change the rules, may result in contention among the various groups.
Andrew wrote up the approach and sent it to the list. Sarmad already replied. If you have more input on this please send it in.
Action item: Karen will add this text to the draft report.
- Who develops/sanctions the lists?
- Who and how can update the lists?
Sarmad: need to understand that if the list will be based on Unicode and accept that Unicode will change. The list needs to remain maintained. This should be listed as an issue. We should define the process for updating.
The other issue is who develops and sanctions the list, what rigorous process does it go through to make sure it is correct and valid through the community. Should go through the same authentication process as the string acceptance process because in reality this process will be generating variants that could be delegated.
Action item: flag those two points as key issues. How are the lists developed and approved
Xiaodong: agrees that it is an important issue but not very sure that a solution can be easily found.
Dennis: did the JET guidelines take care of this for the Han script?
Andrew: doesn’t see how this is taken care of in the JET guidelines. The proposals we have is intended to say that this is a policy issue that requires community consensus on the list. How do we prevent bad lists, what to do when there is conflict. If there are alternatives, it would be good to share with the list.
Sarmad: suggested a third possibility, which is a hybrid of those two.
Vladimir: Andrew raised issues that should be resolved, but these should be discussed in future phases of the project.
6. Taxonomy of variants (Andrew & Nicholas | discussion in the list):
Andrew sent taxonomy to the list. Andrew had a question about which code points needed to go in which places. Needs feedback from the Arabic team to put in the taxonomy document. Andrew is also going to include the suggestion from Alexey, does not see any harm in adding it.
Manal: one of the suggestions I made was to have the cases as separate categories in #4. Was not sure if this was an agreed change.
Andrew: review of notes did not make it clear to him which code points were optional combining marks and which are not.
Action item: Sarmad, Manal and Andrew will work through this over email. Nicholas would like to be copied on this exchange.
Francisco: on the email from Alexey Mykhaylov, this is going further into the visual similarity issue which we already have a process for in the gTLD and FT processes. It may not need to be included in the taxonomy. I don’t see the benefit of further expanding on this issue in this area.
Dennis: should at least add a footnote where appropriate where processes already exist to deal with such issues.
Nicholas: in the document he provided, the materials we already have are not sufficient to clarify the visual similarity issue.
Panagiotes: dealing with this in our Greek IDN ccTLD application. This issue is one that has to be dealt with.
7. AoB
Manal: an issue about homoglyphs, will share over email.
Akshat: will also comment on visual similarity, will send to the list as well as comments from Raymond Doctor.
Vaggelis: must make sure it is perfectly clear to all participants, what is the scope? For new gTLDs only, second level? For ccTLDs as well? Should be very clear. If ccTLD, we need to ask ccNSO to participate in the report. gTLD application checks are different from ccNSO checks.
