Annex 7. Projet.FRA report

From IUCG - Internet Users Contributing Group

Jump to: navigation, search

Dear IESG Members,

I understand that there is an IESG conference call on Jan 7 that may discuss IDNA. I had hoped that I could publish a general framework I_D prior to that date on the practical evolution of Internet usage, in turn covering IDNA as a working example. A family emergency has delayed that work by a few days. This mail is expressed within an IDNA perspective. FYI, I chair Project.FRA for a French speaking netspace.

IDNA has been specified as permitting a support of IDNs without any DNS change. I identify five layers in these proceedings, which are:

1. the internet layer
2. the IDNA interface protocol
3. the user implementation of this protocol
4. the impact on the network naming topology
5. the technical and political interinfluence of the resulting changes.

.

Contents


The Internet layer:

The internet is to provide regular Internet transport, network, and DNS LDH resolution services. This is to remain unaffected. This has been respected thus far.


The IDNA interface protocol:

This was controverted between Unicode, the IETF culture, and us. Moreover, the proper support of French is turning out to be the most complex issue due to the use of the same Roman charset as English, while the French key concept of "majuscules" is absent in English and Unicode. The success of IDNA2008 is to have reached a workable consensus between these three positions (however proper French [Latin languages] orthotypography obliges ".FRA" to find an additional way to support them). We designate IDNA2010 a BCP Draft project that would document the various ways IDNA2008 is/can be implemented by Zone Managers. For the time being, the related workon@idna2010.org mailing list is only for the informational purposes of its respective members. Active debate will only be started in coordination with the WG/IDNABIS Chair, so that there is no confusion. To date, there are people of various origins on the list, but none from ICANN.


The user implementation of this protocol

In suppressing Nameprep, IDNA2008 means progress in flexibility. However, this flexibility may lead different applications on the same machine to resolve the same IDN to different IP addresses. This means that there is not only a problem of transition, but also a problem in the architecture of the user's machine in order to address this risk. As initially indicated, I had planned to address this need in full compatibility with IDNA2008 via the ML-DNS approach (cf. infra) I announced, as soon as IDNA2008 would be approved by the IESG. Lisa Dussault preferred raising the question once IDNA2008 was completed but still not yet approved. This provides you with full control over the decision, but you now need to know the resulting upward and downward contexts better.

The simplest and most rewarding solution is an "IDNApplication" that:

1. respects the IDNA architectural principle of U-Labels that are to be dealt with at the user application layer.
2. intercepts all the domain name entries
3. transcodes them before sending them to the DNS in:
  • leaving ASCII domain names unchanged.
  • differentiating the few TLDs supporting IDNA2003 in order to address them specifically.
  • respecting IDNA2008 otherwise.

In this way all applications and protocols will be provided transparently with the same adequately formatted labels. In addition, IDNA2003 transition schemes will be possible at dates that are decides by each of the concerned TLD Managers.

The fastest and easiest ways to deploy this IDNApplication are either:

  • to use an OPES like front-end to existing nameservers (work on this was foreseen but not completed by the WG/OPES)


The impact on the network naming topology

There are three quick (and, therefore, stabilizing) large scale and easy to disseminate deployment strategies:

  • ISP "patching", as is currently and similarly done for Chinese Domain and Key Names.
  • public DNS services, such as Google's PDNS proposition that may help enforce that type of service immediately on a large scale.
  • implementation of non-external-caching DNS servers at the user's machine.


Impact on the virtual root file

This happens while a demand for many more IDNg/ccTLDs than ICANN is prepared to accept in their Root file. In addition, ICANN in Seoul has strategically and commercially favored some non-Roman IDNccTLDs that will enter the NTIA root file through the "Fast Track" experiment; private, civil, and government IDNgTLDs projects that were previously incitated to be planned and to apply will probably be delayed for several years.

The solution for these rebuked TLDs candidates (like .FRA) is very simple: to be declared as ULDs at the user's nameservers (for improved clarity, we call "user level domain"the top level or New.Net style domains that are declared by users). This means, in other words, local root files with all the TLDs and ULDs that each user needs. At a PDNS, this will call for the support of all of them. All of this amounts to acknowledging the need to manage the virtual root file that has already been in use for years (cf. the way Chinese TLDs are declared in top level nameservers).


Impact on the Internet usage architecture

As indicated, the user innovative project (.FRA) introduced by france@large, together with the IUCG early @large participants, committed to document an IDNA2008 extension called ML-DNS (multi-layer). ML-DNS is part of an Internet Usage architectural framework that is able to provide a comprehensive and robust basis to the semiotic strata (Intersem) of which .FRA is interested in order to support intercomprehension facilitation (Internet of the Users and of their thoughts).


Principles

Its principles are:

(1) the strict equivalence (synonymy) of a domain name pile ranging from the UDN (user domain name) to the IDN (Internet Domain Name as documented by IDNA2008)
(2) a generalized extended value IDNA consistent syntax (our rationale is that languages are supported through the presentation layer. If IDNA works, it means that it uses the Internet presentation layer, i.e. in this specific case, the "xn--" presentation).


Requirements

Our .FRA (as many other TLD projects including the Multilinc set of one sociolinguistic per ISO 639-6/LS 640 linguistic entity) requirements are:

  • French (Latin languages) majuscules support (and other similar particularities in other scripts),
  • extension of the Internet passive content support to ambient and active contents,
  • complete access to presentations and classes,
  • a "commuting cloud" of network services open capacity,
  • Unicode TR46 considerations
  • etc.


Interplus

All of this is embodied through the "Interplus" (internet plus plugged layers on the user side), which does not change a single Internet bit and conceptually adds on the user side:

  • two real layers:
  • an interapplication communications overlay.
  • and a pseudo-network service area. Its general purpose is to support network extended services that users may easily "interplug" for an optional "smart network" experience. Software slots may support services such as:
  • ML-DNS nameserver
  • an Application Firewall
  • Virus protection, social network, Intersem metastructural distributed referential services (MDRS)
  • the virtual presentation layer (managed by the ML-DNS along the the "xx--" format, with the "x--" format that is being used for a "Netix" interapplication command set).


The technical and political interinfluence of the resulting changes

ICANN has imposed pressure on the IDNA text finalization in order to match the Seoul date. This led to some transition confusion (now sorted out) between the WG/IDNABIS and the workon@idna2010.org mailing list. Then, the ICANN Seoul announcements were both perceived as an ICANN opposition to the open deployment of IDNA and as a technically premature move, since Fast Track is more of a legal work than a technical test, and there has been no consideration as of yet of IDNA2008 practical implementation and usage issues.

ICANN participants in WG/IDNABIS either did not perceive the stakes or were not entitled to comment. They did not answer the various questions that we raised regarding their position(s) on IDNA2008 and ULDs.

As a result, we may have:


(1) four different works on the way in order to implement IDNA2008:
  • ICANN Guidelines supporting closed committees representing approx. 120 second level zone managers among millions.
  • IUCG workon@idna2010.org open mailing list, targeting an informational BCP for concerted and interoperable implementations of IDNA2008
  • some major Public DNS services unilateral policies
  • idem for some national deployments.

(2) confusion over the namespace, with ULDs popping up here and there without any coordination. Local root dissemination means a heterarchic naming structure. This was foreseen in the ICANN ICP-3 document, but we are the only ones to have run a community test-bed as requested by ICANN. If we want to keep the DNS namespace stable, we need some virtual root cooperative management through an IDNAlliance.
We also have to take into account that:
  • class usage is off-the-shelves of any IDNApplication solution
  • I only describe the simplest thing that I am to deploy as the Project.FRA Chair in order to get the .FRA namespace operational, at NO change whatsoever except for the loading of a slightly enhanced version of Bind on the participating machines. Everyone else can do the same, and many other TLD project may wish and have better funding to do it. There is NO change in any way. This is simply a normal reading of the RFCs from an IDNA2008 point of view. The Internet legacy turns out being still more powerful than expected.


Comments

The decision is yours. You can either approve or delay IDNA2008 and request more information.

  • IMHO, if you do not approve IDNA2008, which is certainly excellent work, you will cast suspicion on the entire IDNA scheme, as ICANN will have to delay Fast Track due to an IESG decision. Furthermore, this would delay what needs to be built over IDNA2008. During that time, people would certainly start building it up over IDNA2003, thereby initiating a terrible mess.
  • this is why we have started building a technical position against IDNA2008 under the terms imposed by ICANN's urgency (lack of consideration of the abovementioned points). If you approve IDNA (as you technically should), I will appeal against your decision (I fully approve) due to its non considered specific context. I will upset many.
    However, my expectation is that it would provide many more people with a four to six month respite in order to better organize and work out an IDNA2010 BCP proposition or start a WG/VIRTUALROOT, in turn preventing the current 500 ICANN TLD candidates (and probably many more) from deploying as uncoordinated and most probably conflicting ULDs. In this case, some will initiate lawsuits against others (this has already started): this will result in an unknown US jurisprudence on TLD and ULD attribution that, by essence, no ULD will respect outside the USA.
Retrieved from "http://www.iucg.org/wiki/Annex_7._Projet.FRA_report"
Personal tools