IDNCANN

[Patrick Suger]

2009/12/30 <nicolas1.krebs3 at netcourrier.com>

> Dear Sir,
> I am afraid I do not understand this.
>

Dear Mr. Krebs,

copy-paste is usefull. Your two mails were addressed on the
iucg at ietf.orgmailing list. Through two successive mails. They will
answer your questions
better than I could. Like Cary, I am just the one who takes notes.
Best regards
Happy new year.

P. Suger.

----

Dear Internet Users,

Uniqueness is first a targeted 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 an exciting 2010!

-----

At 09:17 31/12/2009, xxxx wrote:

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


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091231/f26a6af9/attachment.htm