<div class="gmail_quote">2009/12/30  <span dir="ltr">&lt;<a href="mailto:nicolas1.krebs3@netcourrier.com">nicolas1.krebs3@netcourrier.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Dear Sir,<br>
I am afraid I do not understand this.<br></div></blockquote><div><br>Dear Mr. Krebs,<br><br>copy-paste is usefull. Your two mails were addressed on the <a href="mailto:iucg@ietf.org">iucg@ietf.org</a> mailing list. Through two successive mails. They will answer your questions better than I could. Like Cary, I am just the one who takes notes.<br>
Best regards<br>Happy new year.<br><br>P. Suger.<br><br>----<br><br>Dear Internet Users,<br><br>
Uniqueness is first a targeted necessity for a prototype, to find the best solution.<br>
Then it becomes robustness.<br>
Then it may become a limitation to be addressed.<br>
RFC 1958 has all of it: &quot; Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements.&quot;<br><br>
RFC 1958 also states: &quot;4.2 A single naming structure should be used.&quot;.<br>
The Internet uses a single naming structure. For Information RFC 2826 adds that this single naming structure should use a single root file. The US Government decided it should be managed by ICANN.<br><br>
On an other hand the naming structure of the human language is heterarchical.<br><br>
Until now it has been accepted that IDNA was a linguistic extension of the Internet naming structure that would support human languages at user application level. IDNA2003 was consistent with that view through the Nameprep constraints. However, objections discussed a long ago stand. &quot;Mapping&quot; considers them. And IDNA2008 defines a syntax which eventually might allow to address them (but cases like French majuscules).<br>
<br>
Why is the AD raising questions?<br><br>
This is because IDNA is _not_ an extension of the Internet naming structure. It is a support of the human language naming structure at user applications level that takes advantage from the DNS resolution service. This leaves us with two unresolved problems :<br>

-  (1) to embed properly the use of the DNS service within the application diversity<br>
-  (2) to organise the hierarchical Internet single naming structure management in order to support the human heterarchic naming structure.<br><br>
Up to now, the envisioned solution to (2) was to curb the human language heterarchy as a first level of the single physical root. Hence the UNICODE/ICANN/GAC/UK madness about IDNA 3166 and RFC 4647. That madness was addressed for the RFC4646 and killed by an ISO vote.<br>
<br>
IDNA2008 definitely buries that possibility. This is because with IDNA URLs are not directly resolved by the DNS, they are pre-resolved by the user application architecture that Lisa asks to be clarified (this means to address problem (1)). The first question is: how will we make sure that two applications on the same machine resolve the same name in the same IP address. It is not only a &quot;transition&quot; issue that ICANN Guidelines could address, it is an immediate architectural issue which defeats the very IDNA principle.<br>
<br>
Then, once this is addressed, we need to document how we will make this application architecture to depend on a single root namespace, while that user side architecture can access and/or manage roots the way they want.<br>
<br>
When this WG began, we asked the Chair if his intent was to address the users&#39; needs or to fulfill the Charter. James Seng answered it was not to address the users needs. The Chair confirmed. We said we would complete the task after the Charter would be full filed and IDNA2008 approved by the IESG. When some of us objected what could impeach such a completion they were banned. This lead to the IUCG.<br>
<br>
Now, the Chair has declared the Charter has been full filed. The AD has forwarded the Document set to the IESG (except the Mapping document which permits IDNA2008). So we are left with the two main issues :<br><br>
- (1) a user side architecture that permits stability [the IUCG proposes one that it names &quot;interplus&quot;]<br><br>
- (2) a community management of the IDN namespace that insure this permitted stability. This was foreseen by ICANN (ICP-3 document). We (IUCG leaders) have been the only ones to carry the requested testing. From this community experimentation we know that the only concept that matches the DNS required hierarchy and the language heterarchy is a Virtual Root. We also know that it cannot be managed in the way the NTIA physical root is managed and supported by ICANN. The Virtual Root can include millions of TLDs.<br>
<br>
Because, no one else carried the ICANN ICP-3 requested testing, and because we (our dot-root test-bed) did not have the budget capacity to carry a true intertesting of the necessary intergovernance of the unique internet namespace, we do not have a solution.<br>
<br>
At the same time, we know that ICANN&#39;s war declaration to IDNgTLDs (Fast Track TLD only being introduced in the root file) puts an enormous pressure on us. This is because the Internet Plus (to use the existing internet along the Interplus concepts) permits to access our .FRA, Multilinc and .PERFIDA domain names, the 500 ICANN candidate (IDN)gTLD, and much more at everyone decision and for free.<br>
<br>
The problem they have to address - without any charter and any IDNA guidance - is an Internet Adminance (technical administration governance) where everyone is his own &quot;MYCANN&quot;.<br><br>
Best wishes for an exciting 2010!<br><br>-----<br><br>At 09:17 31/12/2009, xxxx wrote:<br>
<blockquote type="cite" class="cite" cite=""><blockquote type="cite" class="cite" cite="">At the same time, we know that ICANN&#39;s war declaration to IDNgTLDs (Fast Track TLD only being introduced in the root file) puts an enormous pressure on us. This is because the Internet Plus (to use the existing internet along the Interplus concepts) permits to access our .FRA, .Multilinc and .PERFIDA domain names, the 500 ICANN candidate (IDN)gTLD, and much more at everyone decision and for free.<br>
<br>
The problem they have to address - without any charter and any IDNA guidance - is an Internet Adminance (technical administration governance) where everyone is his own &quot;MYCANN&quot;.</blockquote><br>
Got you! But what makes this different with TLDA&#39;s open roots. They also can support all the 500 ICANN candidate gTLDs.</blockquote><br>
This private response raises a important point.<br><br>
The difference is that TLDA, TLDA, etc. maintain physical root files. We are talking today of the transition from physical to virtual root file. This means from a decentralized unique naming structure obeying the icann centric paradigm to a distributed unique naming structure obeying the cosmological principle.<br>
<br>
TLDA includes the NTIA root file, so it can be labeled as &quot;open&quot;. However, ICANN has the double concern that:<br>
- they make their living out of taxing Class IN, NTIA root file, domain names. TLDA is their commercial competition. &quot;.biz&quot; was used by ICANN to challenge the TLDA lack of conflict.<br>
- a very large root file, with 95%+ of erroneous calls and scores of millions dependent domain names might go beyond the RSS possible machines&#39; capacity.<br><br>
This makes sense because their technical (IETF), political (GAC), economic (ISOC), civil society (IGF), industrial (Unicode Consortium), CORE etc. (Registry, registrars), CENTR (ccTLDs),  etc. &quot;stakeholders&quot; share the culture of dumb-stupid UIs that:<br>

- do not support classes (however ICANN alluded to them in ICP-3). Our recently deceased friend Francis Muguet had succeded in initiating an ITU study on them.<br>
- are to be the applications that support IDNA (possibly in different ways, thanks to TR46).<br><br>
IDNA2008 breaks all that.<br><br>
Because it demands different applications (namely IE, Firefox, Chrome, Opera) to behave the same (like IDNA2003) but in using different codes and no more the same Nameprep. This allows - for example - Unicode to discuss with browser developpers how they can compete as being Unicode conformant. While, Unicode does not even support French majucules. This is why I suggest for years that IDNA be a Unicode application.<br>
<br>
Anyway, IDNA2008 + Unicode, put a perpetually punybrowser/hacker algorithm cacophonic transition at the core of the Internet. While it was to reduce it. This breaks the architectural unicity and MUST be corrected. To do that, IDNA2008 must be used outside UIs. Not _in_ applications, but _as_ an application. The question is where. From experience and logic we can say &quot;down the DNS nameserver side&quot;.<br>
<br>
This can only be:<br>
- at the 16.5 millions of existing nameservers (this is in opposition to the IDNA concept)<br>
- at the user side in embedding a nameserver in their IDNA application.<br><br>
Then the point is &quot;who are the users?&quot;<br><br>
1. The Chair keeps thinking in the pre-IDNA2008 way and says: ICANN. This make sense. However ICANN knows about legal contracting, not about network technical architectural innovation. They also contracted with at most 0,0000001% of the involved zone managers, even including the ccTLDs they drag into the ccNSO through &quot;Fast Track&quot;. Obviously some of the zone managers under ICANN contract have very large static domain name tables. But will that continue to be the same criteria in a post-IDNA namespace usage and economy.<br>
<br>
2. JEDI (&quot;Jefsey disciples&quot; :-)) show that their usage of the Fellowship Optimisation through Revised Continuities and Extensions (FORCE) works well! It only means to use a punyplused version of BIND on IDNA users machines and remove IDNA support from bowsers.<br>
<br>
This has changed the root of unicity. It is no more content unicity from a unique network name server system, it is network unicity from content unicity through a unique IDNAlliance. Also remember that LISP and IDv6 may remove part of the addressing rigidity.<br>
<br>
Those who adhere to the &quot;which part of unicity dont you understand&quot; joke show they have not understood what unicity is. We all are part of the naming virtual unicity. Now how do we build and protect it is the question. It is no more imposed by stakeholders. It has to be worked out by all of Internet Fellows. At the end of the day we may have billion ULDs (our user based TLD equivalent) supporting much more services than static IP address resolution. This has to work.<br>
<br>
Until Seoul there was no real harm in giving people some time to think. ICANN made three mistakes:<br>
1. they asked the Chair to speed-up, so the AD could only raise her questions quickly endangering the whole process.<br>
2. they do (cf. &quot;Fast Track&quot; and Rod&#39;s world tour) as if an operational IDNA solution did exist. Fast Track will permit to discover it does not (yet).<br>
3. they divided and opposed the concerned parties (IDNg/ccTLDs) while we all have to ally to protect our common interests and reshape our economy.<br><br><br></div></div><br>