[vip] Overarching principles used in Devanagari team report

[JFC Morfin]

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