At 16:24 21/09/2011, Naela Sarras wrote:
Dear colleagues,
During a meeting of the Devanagari Case Study Team meeting last week, the team adopted a set of overarching principles that they will include in their Case Study Issues report. We are sharing this section of the report with the other case study teams in case they find it useful for their respective reports.
Thank you Naela, and to the Devenagari Case Study Team. This list of principles based upon one Case study is important. Some questions in a technical deployment and use perspectives (mecalanguages and IUI [intelligent use interface]).
1.1. Unicode is acceptable, if only because no other relevant global coded character set is available. Accepting Unicode includes accepting its normalization model and their stability policy with reference to normalization.
- the only universally accepted reference throughout the digital ecosystem is ISO. In this case it is ISO 10646, the Unicode and ISO 10646 tables being identical. Does this makes a difference? - we hope from this VIP an help in order to define an internet or digital convergence usage(orthotypographic) oriented algorithm to apply to these standards (variances, phishing, security, etc.)
1.2. IDNA2008, including its interpretation of Unicode properties and the version evolution model, are acceptable.
- subject to the algorithm above.
1.3. The DNS, including its restrictions on exact lookup (known item search), the absence of language-specific information and language-specific or script-specific lookup or matching mechanisms, and aliases that do not carry context or that can point from anywhere in the DNS tree, is acceptable.
This position is important. It means that in the Devenagary case no specific orthotypography need is to be supported at the IUI or UI level ?
1.4. TLD names are limited to "letters" alone. Digits and Hyphens as well as ZWJ U+200C, ZWNJ U+200D will not be permitted within a TLD label.
Is this Digit prohibition specific to the Devanagari case?
1.5. The contents of the DNS are about mnemonics, not about "words" or longer statements in particular languages. The fact that something can be written in a particular language, or even looked up in its dictionary, does not imply an entitlement to have that string appear in the DNS.
Is this a political, technical or linguistic position?
1.6. Any domain name tree may have subordinate zones with separate, administratively-distinct, registration and maintenance and administrative arrangements.
This seems to be of the DNS essence. Is there some specific requirement in this area due to the Devanagari case?
1.7. This issues report is limited to IDN variant TLD's alone (with specific reference to Devan gar ) and may not apply to registration under subordinate zones, although the issues discussed in the report could provide gainful insights into the functioning of those subordinate zones.
One important issue which has not been considered by IDNA2008 because it belongs to orthotypography rather than to the DNS, is naming inheritance. This would mean that some consistency constraints at the TLD level SHOULD propagate upward to other name levels (or may be the other way around that the use of some labels should constraint the lower level labels, including the TLD?). E.g.: in the case of the Project.FRA, non roman characters are by essence non acceptable. To fully understand this, one must differentiate what belongs to the DNS software environment and what belongs to the Human political and semantical environment. This means that five layers should at least be considered (independently from classes and presentations): 1. what the DNS can support 2. what IDNA supports 3. what an Intelligent Use implies 4. what the Registry accepts 5. what the Users expect. It seems that IDNA2008 has adequately wed the two first layers and left the mapping issues to the IUI. The Registry policy participates to the registry offering and can be discussed with/by ICANN. As long as IDNA (as an architecture) remains bound to multiples applications at the user's machine, and no IUI standradization and documentation orgnanisation has not emerged, this ultimate and most important layer in the variance support remains out of any standardization or contract rule. Thank you for your attention. jfc