[governance] Friday morning... (Arabic Domain Name) Some

[JFC Morfin]

Thanks to Ginger Paque, Ian Peter, and S. Subbiah for reminding us 
all about this Internet saga.

In addition, I just want to remind you, however, that:

- USA first operated public Katakana services with KDD (Japan) in 
1983, in using Tymnet and then X.75 protocols.
- ICANN is politically toying with the international community since 
there is currently _no_ IDN standard by the IETF yet (not published).
- 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.
- 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.

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:

-  ICANN actually technically (and commercially) discriminates on the 
basis of the wrong reasons against structured private projects, in 
legal violation with its by-laws.
-  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.

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.

For those interested, I have provided a more detailed explanation in the annex.
Cheers.
jfc

-----

The launch of the ICANN Mad Track

The situation is as follows:

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

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

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

1.2.1. - to support the WG/IDNABIS effort along its charter.
1.2.2. - to build an ML-DNS atop of it.

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:

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).
1.3.2. Multilinc: a multilinguistics (in the meaning of linguistic 
cybernetics) test bed, supporting more than 25,000 linguistic zones.
1.3.3. Perfida: a project to explore RFID applications in order to 
investigate the Internet of things vs. the Internet of thoughts areas.
1.3.4. MDRS (Metadata Distributed Registries System), i.e. the an ISO 
11179 conformant metastructure for the Intersem.


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

There were two possibilities here:

2.1. - increasing the technical core's capacity (tables, protocols, 
DNS, etc.) as the IETF has always done in the past.

2.2. - supporting multiplicity, as something intelligent, i.e. at the 
fringes. There were three possible fringes then:

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.
2.2.2. on the user side. This was eventually consensually agreed as 
it also permitted the last possibility:
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?


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:

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:

3.1.1. No change in DNS, and no (mapping) intelligence inside the 
Internet to particularly accommodate IDNs.
3.1.2. Independence from Unicode versions.

3.2. This provided a stable, proven, reliable, and already deployed 
quasi perfect basis.

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.
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.
3.2.3. We documented 
(http://tools.ietf.org/html/draft-iucg-punyplus-03 ) what we MIGHT do 
to overcome the lost metadata issue.


4. However, IDNA2008 failed to address IAB's key points 
(<http://tools.ietf.org/html/draft-iab-idn-encoding-01>http://tools.ietf.org/html/draft-iab-idn-encoding-01) 
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.

This means that the:

4.1. Current IDNA concepts do not consider how to prevent resolution 
conflicts between different applications on the same machine.

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.

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.


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 – 
<mailto:iucg at ietf.org>iucg at ietf.org) 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.

5.1. IDNA2010 (<http://idna2010.org/>http://idna2010.org) is to 
document the IDNA user's side corresponding to the IDNA2008 Internet side.
5.2. IDNA2012 is to document the IDNA2008/IDNA2010 adminance (i.e. 
how they are to be deployed, maintained, and evolve).


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):

6.1. We agreed with Vint Cerf to delay the IDNA2010 work in order to 
permit IDNA2008 to be clearly approved by the IESG.

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.

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.


7. The reasons as to why there are two initial debates to carry out 
any decisions to be made is:

7.1. IDNA2010 sits outside of the IETF scope. Who is to document it: 
a new IETF area? or the iucg at ietf.org mailing list (Internet users 
contributing group)? or another SDO? The Web is documented by the 
W3C, and IUI is of similar importance.

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.


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

8.1. acknowledged that I:

8.1.1. support the publication of the IDNA2008 set of documents,
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] ,
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,
8.1.4. deemed necessary  a disclaimer indicating that IDNA2008 should 
not be deployed or tested until coordinated usage documentation is produced.

8.2. in what they found no possible remedial action since the IESG 
does not direct the work of the IAB and

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

8.3. The RFC 2026 calendar had so far been strictly respected:

8.3.1. ICANN wished to deploy IDNs.
8.3.2. IAB (RFC 4690) indicated that a revision of IDNA2003 was necessary.
8.3.3. IESG created the WG/IDNABIS to that end by giving the 
possibility to adapt its own Charter.
8.3.4. The WG reached a consensus within the limits of a slightly 
amended Charter.
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.
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.
8.3.7. IDNA2008 publication is blocked by an appeal that IESG 
considers to belong to IAB.
8.3.8. The next step under way is my appeal to IAB.
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.

8.4. There are two actions to break the respect of that calendar:

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


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.

Therefore, its consequences only seem to undercut:

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.

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


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.

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:

10.1. initiating a test project (Fats Track) which can test nothing new.
10.2. reserving it only to IDNccTLD, delaying (IDNgTLD) for years 
without any technical reason.
10.3. barring within IDNccTLDs the most technically demanding ones, 
i.e. the LATINcc/gTLDs.

10.2. This means for us to focus on the Internet Users' linguistic, 
innovative, and semantic much more dynamic Internet Users option.

10.2.1. The harm that a noncontextually and uncooperatively prepared 
innovation may create has delayed me for years.
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.


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)

As @large Internet Users, we made all what we could to help a 
community cooperation, debate and responsible approach.

11.1. france at large, the eldest ALS, was denied the right to join ALAC,

11.2. we were barred from participating in IDNA related ICANN working groups,

11.3. we are now bypassed in our legitimate respect of the ISOC/IETF 
appeal procedures.


12. The only responses to such an ICANN unilateral attitude are:

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.

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

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.

jfc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igcaucus.org/pipermail/governance/attachments/20100509/33459f92/attachment.htm>
-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance

Translate this email: http://translate.google.com/translate_t