<html>
<body>
<br>
Thanks to Ginger Paque, Ian Peter, and S. Subbiah for reminding us all
about this Internet saga. <br><br>
In addition, I just want to remind you, however, that:<br><br>
- USA first operated public Katakana services with KDD (Japan) in 1983,
in using Tymnet and then X.75 protocols.<br>
- ICANN is politically toying with the international community since
there is currently _no_ IDN standard by the IETF yet (not
published).<br>
- the IETF WG/IDNABIS IDNA2008 consensus was found over an "a
minima" consensus concerning the users' side requirements, which
eventually the IESG did not want to even consider.<br>
- the currently IESG approved IDNA2008 architecture is under appeal (next
step is to the IAB) because it is _perfect_ (except that it does not
support Latin languages) on its Network side, however no IESG
disclaimer has ever explained that it is not documented yet, and it is
opposed by the IAB, on its users' side. The IESG response (first step of
the appeal) advised to consider a BoF (proposing a new WG) on the
issue.<br><br>
What ICANN actually does is to pretend that it still controls the
Internet Domain Names (IDNs) in preventing scores of (IDN)gTLDs to be
added to the root. In favoring a few non-ASCII IDNccTLD:<br><br>
- ICANN actually technically (and commercially) discriminates on
the basis of the wrong reasons against structured private projects, in
legal violation with its by-laws.<br>
- behaving like an Internet global Monopoly, it forces LATINgTLDs
projects, like the one I chair (PROJECT.FRA), to find an independent
technical solution (even for testing), since IDNA2008 does not support
yet French's (and the other Latin languages’) orthotypography. <br><br>
This amounts to unfair competion to more than 500 gTLD, LATINgTLD and
IDNgTLD projetcs, and disloyal commercial behavior at the expense of the
entire Internet Community.<br><br>
For those interested, I have provided a more detailed explanation in the
annex.<br>
Cheers.<br>
jfc<br><br>
-----<br><br>
<b>The launch of the ICANN Mad Track<br><br>
</b>The situation is as follows:<br><br>
1. When we started the IETF WG/IDNABIS, I asked (on behalf of several
linguistic mailing lists) if the target was for the Internet to work
better, or also for the users' needs to be addressed. I described these
users' need as an "ML-DNS providing non-ASCII users the same QoS as
the DNS does to ASCII users". <br><br>
1.1. Vint Cerf (Chair of the WG/IDNABIS) was very clear: the charter did
not speak of users, but of making the Internet work better and of being
compatible with former RFCs (IDNA2003).<br><br>
1.2. I then committed, on behalf of a francophone group that is
interested in e-multilinguistics, francophone, and architectural TLD
projects (later on nicknamed “Jefsey’s disciples” by Martin Dürst, or
JEDIs). <br>
<br>
1.2.1. - to support the WG/IDNABIS effort along its charter.<br>
1.2.2. - to build an ML-DNS atop of it.<br><br>
1.3. Unless indicated otherwise, when "we" is used in this memo
it is referring to these @large supported "JEDIs". Their
announced project is to bring to the Internet the additional services
that are necessary to support an semiotic stratum (intersem) that is
interested in meaning, such as the Internet stratum being interested in
content, and the telecom stratum being interested in digital signals.
Their plan includes four experimental "externets" (global
virtual open networks within the world digital ecosystem [WDE]) that are
supported by:<br><br>
1.3.1. Projet.FRA: a francophone zone of which the namespace will serve
as the taxonomy of an open public ontology in order to explore semantic
addressing system (SAS).<br>
1.3.2. Multilinc: a multilinguistics (in the meaning of linguistic
cybernetics) test bed, supporting more than 25,000 linguistic zones.<br>
1.3.3. Perfida: a project to explore RFID applications in order to
investigate the Internet of things vs. the Internet of thoughts
areas.<br>
1.3.4. MDRS (Metadata Distributed Registries System), i.e. the an ISO
11179 conformant metastructure for the Intersem.<br><br>
<br>
2. The WG life has been tense on some occasions. The difficulty was to
determine how to match the linguistic diversity while respecting the
users’ empowerment. This was also the case because it was meant to
exemplify how the Internet architecture supports diversity, and its
"presentation layer" (which is architecturally intrinsic to
multilinguistic support but not documented in the Internet approach).
<br><br>
There were two possibilities here:<br><br>
2.1. - increasing the technical core's capacity (tables, protocols, DNS,
etc.) as the IETF has always done in the past.<br><br>
2.2. - supporting multiplicity, as something intelligent, i.e. at the
fringes. There were three possible fringes then: <br><br>
2.2.1. on the Internet side, i.e. in the protocols. The charter objected
to it, but a technical control of usage was technically very tempting for
some industry leaders and large SSDOs.<br>
2.2.2. on the user side. This was eventually consensually agreed as it
also permitted the last possibility:<br>
2.2.3. in between, i.e. in a new architectural domain that we called IUI
(Internet Use Interface) and that is now to be well identified and
documented, but by whom?<br><br>
<br>
3. IDNA2008 definitely chose to say that it MUST be "multiplicity at
the fringes". This implies that fringes SHOULD do what nameprep did
in IDNA2003. Then, it should require to give at least one example of what
application developers MIGHT do. This “unusual” “MUST/SHOULD/MIGHT” areas
description was carried out as follows:<br><br>
3.1. the IETF WG/IDNABIS consensually defined the IDNA2008 unaltered way
that the Internet DNS will behave. This is stability for the Internet
“intrastructure” (i.e. protocols, parameters, BCPs, etc.) documented (RFC
3935) by the IETF:<br><br>
3.1.1. No change in DNS, and no (mapping) intelligence inside the
Internet to particularly accommodate IDNs. <br>
3.1.2. Independence from Unicode versions. <br><br>
3.2. This provided a stable, proven, reliable, and already deployed quasi
perfect basis.<br><br>
3.2.1. This with the exception, however, that in still being bound to
Unicode it does not support orthotypography [a correct semantic use of
typography]: for example, Latin majuscules metadata is lost.<br>
3.2.2. Consensus could be found because a description of the way users
COULD proceed on the fringes (proving feasibility) was consensually
adopted. This was the "Mapping" document.<br>
3.2.3. We documented
(<a href="http://tools.ietf.org/html/draft-iucg-punyplus-03" eudora="autourl">
http://tools.ietf.org/html/draft-iucg-punyplus-03</a> ) what we MIGHT do
to overcome the lost metadata issue.<br><br>
<br>
4. However, IDNA2008 failed to address IAB's key points
(<a href="http://tools.ietf.org/html/draft-iab-idn-encoding-01">
http://tools.ietf.org/html/draft-iab-idn-encoding-01</a>) because (as
Vint Cerf had initially pointed it out) they are outside of its charter.
The IETF Applications AD raised those points that question the very basic
principle of the IDNA architecture (as being IDN "in
applications" and not, for example, as a single “IDNApplication”).
As a result, that document was not considered by the IESG.<br><br>
This means that the:<br><br>
4.1. Current IDNA concepts do not consider how to prevent resolution
conflicts between different applications on the same machine. <br><br>
4.2. Unpublished, as of yet, IDNA2008 permits developers to address
Asian, and supports Arabic, needs (most of them at least). Usage of IDNA
in other areas (IRIs, etc.) is not completed. <br><br>
4.3. Unpublished, as of yet, IDNA2008 does not address some French,
Latin, and other languages’ orthotypographic needs. This implies that
Project.FRA (and many other linguistic and multilinguistic projects) need
an enhanced operational solution.<br><br>
<br>
5. That solution is a DNS fully transparent, and 100% IDNA conformant,
ML-DNS that we (as Internet Users, members of the Internet Users
Contributing Group – <a href="mailto:iucg@ietf.org">iucg@ietf.org</a>)
have committed ourselves to propose and experiment. To that end, two
additional works are to be carried out. In order to avoid the confusion
that the ccNSO started to introduce concerning a possible future
evolution of IDNA2008, and to emphasize the whole IDNA architectural
stable continuity, we named them IDNA2010 and IDNA2012. <br><br>
5.1. IDNA2010 (<a href="http://idna2010.org/">http://idna2010.org</a>) is
to document the IDNA user's side corresponding to the IDNA2008 Internet
side.<br>
5.2. IDNA2012 is to document the IDNA2008/IDNA2010 adminance (i.e. how
they are to be deployed, maintained, and evolve).<br><br>
<br>
6. We were fully open to Chair, AD, IESG, and other community interests
including ICANN, which did not want to get involved, while Vint Cerf
initially suggested that they might coordinate (we then underlined they
are only a namespace cooperator with Internet Users and Industry DNS
server operators):<br><br>
6.1. We agreed with Vint Cerf to delay the IDNA2010 work in order to
permit IDNA2008 to be clearly approved by the IESG. <br><br>
6.2. We documented with the IESG (which indicated having actively
considered it before approving the IDNA2008 documents as we requested it)
how Project.FRA, and the 22,500 linguistic zones of the Multilinc
multilinguistic test bed, will have to deploy, since they are kept
outside of the ICANN Fast Track experimentation, as every other candidate
(IDN)gTLD. <br><br>
6.3. In this report to the IESG, I explained that I fully supported the
approval of IDNA2008 but that I would appeal against this approval if it
was not put into its whole context in order to give stakeholders time to
consider the practical implications of IDNA together, before ICANN
started its political technically closed Fast Track, no-experimentation,
project. ICANN eventually indicated that they might reassess their
position in the function of the appeal timing.<br><br>
<br>
7. The reasons as to why there are two initial debates to carry out any
decisions to be made is:<br><br>
7.1. IDNA2010 sits outside of the IETF scope. Who is to document it: a
new IETF area? or the iucg@ietf.org mailing list (Internet users
contributing group)? or another SDO? The Web is documented by the W3C,
and IUI is of similar importance.<br><br>
7.2. IDNA2012 will necessarily discuss the governance of the unique
Virtual Root Open Matrix (VROOM) in the context of a non-ICANN centric,
non-Internet centric, but user-centric management of the namespaces with
an entirely new and still unprotected economy of (IDN)gTLDs and a
different context of the net and user centricities.<br><br>
<br>
8. At this stage, the ISOC (IETF) side has not decided yet (through IAB
and a possible appeal to its Chair), but the IESG has already<br><br>
8.1. acknowledged that I:<br><br>
8.1.1. support the publication of the IDNA2008 set of documents, <br>
8.1.2. but wish that the documents had been published along with a
specific complementary warning to the Internet community [by or upon the
guidance of the IAB] ,<br>
8.1.3. asked it would have noted the new architectural opportunities that
are available in IDNA2008, and warned of possible confusion until these
opportunities are properly governed, <br>
8.1.4. deemed necessary a disclaimer indicating that IDNA2008
should not be deployed or tested until coordinated usage documentation is
produced.<br><br>
8.2. in what they found no possible remedial action since the IESG does
not direct the work of the IAB and <br><br>
8.2.1. In rejecting this appeal, which does not suggest remedial action
by the IESG, they actually found the appropriate action, since the next
step of the appeal procedure permits me to obtain the IAB comment that we
think the community needs, whatever this comment may be, in front of the
very large amount of supporting material that I provided in order to
"include a detailed and specific description of the facts of the
dispute." (RFC 2026)<br>
8.2.2. However, at the same time, the IESG observes that the appeal
includes a plea for the Internet community to initiate some work. I,
therefore, suggested the submission of an Internet-Draft and then to
approach an appropriate Area Director to sponsor a BOF Session or sponsor
the publication of the document, along RFC 5434. <br><br>
8.3. The RFC 2026 calendar had so far been strictly respected:<br><br>
8.3.1. ICANN wished to deploy IDNs.<br>
8.3.2. IAB (RFC 4690) indicated that a revision of IDNA2003 was
necessary.<br>
8.3.3. IESG created the WG/IDNABIS to that end by giving the possibility
to adapt its own Charter.<br>
8.3.4. The WG reached a consensus within the limits of a slightly amended
Charter.<br>
8.3.5. That consensus exemplifies a set of fundamental changes in the
Internet overall architecture that is outside the limits of the WG
scope.<br>
8.3.6. IESG approved the consensus while knowing that an appeal would be
carried out concerning the impact of the architectural change that mainly
concerns the IAB and the global community.<br>
8.3.7. IDNA2008 publication is blocked by an appeal that IESG considers
to belong to IAB.<br>
8.3.8. The next step under way is my appeal to IAB.<br>
8.3.9. The IAB response should have permitted the community to know
whether IDNA2008 could be published and tested as it is (disregarding my
concerns), or if a preliminary architectural, technical, governance, or
adminance debate was necessary to preserve the Internet stability, as we
believe, basing our belief on the only community test bed that was
carried out along the ICANN-ICP-3 request and standards
(Project.dot-root), and via our personal daily experience of navigating
the Internet in using our very simple user centric ML-DNS
prototype.<br><br>
8.4. There are two actions to break the respect of that
calendar:<br><br>
8.4.1. The IESG advice above, which was also advised by Applications AD
and the WG/IDNABIS Chair, was to publish a Draft. The reason why we did
not want to publish a Draft is that we might poorly introduce and,
therefore, delay or dangerously confuse what is simply a new reading of
the existing architecture. This is why we consider it more secure to
first obtain the IAB opinion and possible guidance.<br>
8.4.2. The ICANN unilateral decision, in launching Fast Track before any
concerted discussion with the Internet Users' side could be achieved
after such an IAB technical guidance, has forced their de facto allies in
the Internet dominant "ISOCANN enhanced cooperation" to take
sides for what seems to amount to purely political and commercial reasons
or possible lack of technical consideration, in favor of a technically
unstable choice. <br><br>
<br>
9. Because appeals are to be individual, the pressure that is being
imposed on me in this way by ICANN is in violation of the ISOC/IETF
appeal process as well as of the community trust, since Fast Track cannot
refer to any newly published RFC to be tested.<br><br>
Therefore, its consequences only seem to undercut: <br><br>
9.1. a grass-root move based upon a community based open, sound, secure
architecture; and the competitive progress of the namespace that
ICANN is supposed to foster.<br><br>
9.2. a technical solution that will permit the quick, transparent, low
cost, easy to understand deployment of hundreds of (IDN)gTLD candidates
in a new phase of the Internet architecture and growth (that will also
most probably be supported/sponsored by governments). <br><br>
<br>
10. Delaying any further the debate on the ML-DNS, IUI, and their
implications on the management of the namespace structure and economy
would only dramatically increase the risks of confusion.<br><br>
10.1. The only way for us to respond now is to proceed in considering the
ISOCANN enhanced cooperation as the architectural “competitive option”
that they actually chose to be in:<br><br>
10.1. initiating a test project (Fats Track) which can test nothing
new.<br>
10.2. reserving it only to IDNccTLD, delaying (IDNgTLD) for years without
any technical reason.<br>
10.3. barring within IDNccTLDs the most technically demanding ones, i.e.
the LATINcc/gTLDs.<br><br>
10.2. This means for us to focus on the Internet Users' linguistic,
innovative, and semantic much more dynamic Internet Users option.
<br><br>
10.2.1. The harm that a noncontextually and uncooperatively prepared
innovation may create has delayed me for years.<br>
10.2.2. However, we now see that it will most probably not exceed what
would result from a continuation of the sole ISOCANN governance and
adminance of the namespace, under an ICANN inadequate dominance and an
impossible common understanding at this stage without a real
clarification by the IAB contradiction, the WG/IDNABIS could not provide
when the AD demanded it because it is out of the scope of its charter.
<br><br>
<br>
11. “Responsible experimentation is essential to the vitality of the
Internet. Nor does it preclude the ultimate introduction of new
architectures that may ultimately obviate the need for a unique,
authoritative root. But the translation of experiments into production
and the introduction of new architectures require community-based
approaches, and are not compatible with individual efforts to gain
proprietary advantage.”(ICANN – ICP-3)<br><br>
As @large Internet Users, we made all what we could to help a community
cooperation, debate and responsible approach. <br><br>
11.1. <b>france@large</b>, the eldest ALS, was denied the right to join
ALAC, <br><br>
11.2. we were barred from participating in IDNA related ICANN working
groups,<br><br>
11.3. we are now bypassed in our legitimate respect of the ISOC/IETF
appeal procedures. <br><br>
<br>
12. The only responses to such an ICANN unilateral attitude are:<br><br>
12.1. to give a last chance to a practical debate and show where the
responsibility of the coming confusion lies in not interrupting the
ISOC/IETF appeal process, so that the Internet Governance ISOCANN
Enhanced Cooperation cannot claim that it did not know.<br><br>
12.2. to engage in development and experimentation, in as much as ICANN
permits it to the community, along the respect of the
recommendations of ICANN’s ICP-3 document, section “5.
Experimentation”.<br><br>
12.3. to try to reduce the confusion that experimental or commercial
alternatives might introduce, in not documenting our architectural
options before they have been fully experimented; then documenting them
as public domain through the bodies that could emerge to assume their
open adminance and IETF Drafts.<br><br>
jfc<br>
</body>
</html>