Subject: [iucg] from unique to multi DNS

From: jefsey <[email-masked]>
Date: Thu, 31 Dec 2009 04:25:45 +0100

At 23:18 30/12/2009, [email-masked] wrote:
> > As Rod Beckstrom put-it, the Internet is going to change for the first time
> > in 40 years. Switching from English ASCII passive content prototyping to
> > full multi-lingual active content services operations. This is not a small
> > thing. We are better to help people prepare for it.
>
>Dear Sir,
>I am afraid I do not understand this.

At 23:20 30/12/2009, [email-masked] wrote:
>I guess that Marie-France Berny was talking about
>"which part of 'unique' are you having trouble understanding?" 
>quoted in 
>http://www.ietf.org/mail-archive/web/ietf/current/msg28487.html (six 
>years ago) and in 
>http://www.ietf.org/mail-archive/web/ietf/current/msg37426.html 
>(four years ago).

Dear Internet Users,

Uniqueness is first a target necessity for a prototype, to find the 
best solution.
Then it becomes robustness.
Then it may become a limitation to be addressed.
RFC 1958 has all of it: " Duplication of the same protocol 
functionality should be avoided as far as possible, without of course 
using this argument to reject improvements."

RFC 1958 also states: "4.2 A single naming structure should be used.".
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.

On an other hand the naming structure of the human language is heterarchical.

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. "Mapping" considers them. And IDNA2008 defines a 
syntax which eventually might allow to address them (but cases like 
French majuscules).

Why is the AD raising questions?

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 :
-  (1) to embed properly the use of the DNS service within the 
application diversity
-  (2) to organise the hierarchical Internet single naming structure 
management in order to support the human heterarchic naming structure.

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.

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 "transition" issue 
that ICANN Guidelines could address, it is an immediate architectural 
issue which defeats the very IDNA principle.

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.

When this WG began, we asked the Chair if his intent was to address 
the users' 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.

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 :

- (1) a user side architecture that permits stability [the IUCG 
proposes one that it names "interplus"]

- (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.

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.

At the same time, we know that ICANN'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.

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 "MYCANN".

Best wishes for a exciting 2010!

jfc

---

From: JFC Morfin <[email-masked]>
Date: Thu, 31 Dec 2009 16:57:38 +0100

At 09:17 31/12/2009, xxxx wrote:
>>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.
>>
>Got you! But what makes this different with TLDA's open roots. They 
>also can support all the 500 ICANN candidate gTLDs.

This private response raises a important point.

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.

TLDA includes the NTIA root file, so it can be labeled as "open". 
However, ICANN has the double concern that:
- they make their living out of taxing Class IN, NTIA root file, 
domain names. TLDA is their commercial competition. ".biz" was used 
by ICANN to challenge the TLDA lack of conflict.
- a very large root file, with 95%+ of erroneous calls and scores of 
millions dependent domain names might go beyond the RSS possible 
machines' capacity.

This makes sense because their technical (IETF), political (GAC), 
economic (ISOC), civil society (IGF), industrial (Unicode 
Consortium), CORE etc. (Registry, registrars), CENTR (ccTLDs),  etc. 
"stakeholders" share the culture of dumb-stupid UIs that:
- 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.
- are to be the applications that support IDNA (possibly in different 
ways, thanks to TR46).

IDNA2008 breaks all that.

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.

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 "down the DNS nameserver side".

This can only be:
- at the 16.5 millions of existing nameservers (this is in opposition 
to the IDNA concept)
- at the user side in embedding a nameserver in their IDNA application.

Then the point is "who are the users?"

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 "Fast 
Track". 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.

2. JEDI ("Jefsey disciples" :-)) 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.

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.

Those who adhere to the "which part of unicity dont you understand" 
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.

Until Seoul there was no real harm in giving people some time to 
think. ICANN made three mistakes:
1. they asked the Chair to speed-up, so the AD could only raise her 
questions quickly endangering the whole process.
2. they do (cf. "Fast Track" and Rod's world tour) as if an 
operational IDNA solution did exist. Fast Track will permit to 
discover it does not (yet).
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.

Happy new year.

jfc