From IUCG - Internet Users Contributing Group

Jump to: navigation, search

At 23:43 10/03/2010, Russ Housley wrote:
The IESG has received an appeal. It can be found here: http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf

JFC Morfin included these comments in the cover note:

Basically this appeal documents that IDNA2008 enlight capacities and principles that are built in the Internet technology but that were not used. This is a great thing. However the IESG has not included a disclaimer on top of these documents, nor foreseen how and where the necessary IDNA user-side issues are to be discussed and documented. This may lead people like me to unpredictably toy with them without any established Adminance (governance of the tools to be managed by the Governance) arrangement, or organizations like ICANN to engage into inappropriate testing.

The document size is impressive. There are three reasons to that:

the impact on the Internet usage architecture is potentially impressive
the change is not in the technology, but in the way to consider the technology and the way it addresses multiplicity. IDNA2008 is about pople's multilinguization while IDNA2003 was about Unicode's globalization. This is a big change that multilinguists can discuss. However, everyone has to understand it simplifies the complexity of handling multiplicity (RFC 3439 - principle of simplicity) in conformance with RFC 1858 to do it at fringes. RFC 1958 also advises to keep the first solution when it works.
the third reasons is that I do not want to be accused of not having checked my rationale for Interplus and further Intersem work. NB. I call Interplus what I think Internet needs to be able to fully support the Intersem (that the IDNA2008's approaches implifies), and the Intersem is what IDNA2008 introduces: the capacity for brain to brain interintelligibility.

The document is also maintained as a wiki under http://iucg.org/wiki/100310_-_JFCM_Appeal_to_the_IESG.

The IESG plans address this appeal in the next few weeks, and the IESG solicits comments on this appeal from the community. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-27. Exceptionally, comments may be sent to iesg@ietf.org instead.

On behalf of the IESG,
Russ Housley

Dear IESG Members,

You announced on January 11, 2010 that you had approved the IDNA2008 document set, as produced by the WG/IDNABIS, except for the Mapping document:

1. The IDNA2008 documents set introduces a fundamental clarification of the way the Internet architecture meets an external diversity, in this case the linguistic diversity. This significantly extends the Internet architectural paradigm, i.e. the commonly accepted basic set of assumptions that is documented in RFC 1958, RFC 3439, RFC 3935, and IDNA2003. However, the IESG has not warned the Internet community and has not called for IAB documentation concerning:

the set of new architectural opportunities that this new architectural paradigm opens,
the possible confusions that it may introduce until these opportunities are properly governed.

2. In line with this new paradigm, IDNA2008 only documents the Internet side (the protocol) of IDNA. It does introduce it, but it does not document the powerful, yet complex, and possibly versatile, capacities that are allotted to the user's side in order to enable the Internet multiplication that the linguistic diversity requires. Furthermore, the IESG has not published a disclaimer indicating that this makes IDNA2008 too early to deploy, and useless to test, prior to research and coordinated documentary work being engaged, all of which is in a Usage Area that is still to be organized inside or outside the IETF.

.

Not enough precautions being advised

I believe that in these two related occurrences the IESG has failed in its precautionary duty as it results from RFCs (Annex 1. Application of the Precautionary Principle by the IETF) and, moreover:

At the very inception of the WG/IDNABIS, I asked the Chair about his IDNA2008 strategy regarding an ML-DNS (Annex 2. Is IDNA an ML-DNS to be?), which is loosely defined as what the users really need. Further to his response, I committed to the IDNA2008 support in order to obtain a consensual basis towards the further, fully consistent, documentation of such an ML-DNS. The Chair succeeded in obtaining an IDNA2008 consensus that I supported.

Working with the france@large team on multilinguistics as the cybernetics of the linguistic diversity, and the Intersem as the Semiotic Internet that is necessary to support semantic exchanges (Internet of thoughts), I considered the ML-DNS issue through the requirements of the two projects as required by the standardization path, in the foreseeable contexts (Annex 3. A practical innovation and complex deployments strategy), but also the immediate real world consequences of an IDNA2008 approval: Project.FRA of an open francophone ontology using its namespace as its semantic addressing taxonomy, and Multilinc of one naming zone per sociolinguistic relational space. I made sure that the WG/IDNABIS was informed enough of the comments from france@large (Annex 4. Report to the WG/LC), maintained a draft in turn recording the WG/LC issues and some of the responses obtained (Annex 5. WG/LC IDNABIS report), published a Draft to discuss the inability to support exceptions such as the French and Latin languages’ majuscules (Annex 6. Punyplus), and engaged thought with the IUCG in the discussion of an "Interplus" architecture matching the concerns expressed by the Application Area Director on the user side (this architecture is just a possible IDNA2008 application and is, therefore, quoted in this appeal only as an example of the user reading of the IDNA2008 perspective of the Internet technology).
This is in the capacity of the Project.FRA designer that I reported and stated my position to the IESG, just as in how I had initially informed the WG/IDNABIS of the Multilinc project (Annex 7. Projet.FRA report).
I was told by the IESG Chair that: these comments stimulated a significant amount of discussion about the documents from the IDNAbis WG. The IESG approved the documents of which I was most concerned. However, they took my report only as "suggestions" and as "research" on some actions that I had reported that needed to be immediately followed and that I was concerned about.

Why am I appealing as an Internet User?

For decades, I have been a "lead user" of the world digital ecosystem (WDE) international network, or an IETF Internet User in ICANN lingo: an @large. We will see an evolution at the end of this memo: lead users want to emphasize their ability to be fully addressable without resorting to P2P interuser applications. Some translate this in saying that they are "interusers" - this is also related to the Interplus technology and Internet extension that they work on as a result of IDNA2008.

Interest in the Internet

My interest in the Internet is in the basic, valued-added, and extended digital services that I may obtain from it in order to expend my own relational spaces with other people, communities, and machines alike at an intelligent layer. This is why I fully adhere to the WSIS unanimous declaration that the world information society, MUST be "people centered, a caractere humain, centrada en la persona".

I call a basic service a service that concerns the signals carrying the content.
I call a value added service a service that concerns the envelope of the content.
I call an extended service, a service that concerns the semantic of the content.

Therefore, along with the current state of the art, I subsequently actively and innovatively kept enhancing the architecture, ability, and reach of my own international digital continuity as not being decentralized, but rather distributed, i.e.:

centered on my own personal "HSS" (homo sapiens sapiens) semantic processor assisted, surrounded, and protected by all the resources of my own "cybship", and
multicentered on the similar semantic core and digital agent processors of my fellow Internet users.

Importance of IDNA2008

The importance of IDNA2008 results simultaneously from:

its own content enlarges the Internet capacity from the satisfaction of the Unicode standards, to the full cultural and semantic needs of human users.
the lack of documented consensual guidance on the way to securely and stably do it in dramatically enlarged namespaces
the constraints imposed on users by ICANN in its limited namespaces (TLDs and IP addresses), while users will now understand how to evade.

The result:

sets an IDNA stable basis for a multi-layered DNS that matches my local, global, lingual, application, etc. needs in terms of name resolution.
illustrates how the Internet legacy DNS building block is to be used to support the Internet presentation layer.
confirms, in terms of real life operations and usage, the Internet concept of multiplicity: "internet multiplicity is supported at the fringes in using end to end metadata exchanges (cf. RFC 1958: "everything else should be done at the fringes"). Multiplication is supported by fringe metaprocess instantiations.
introduces the Internet presentation layer,
implies a unique virtual DNS root matrix,
leads to global scope user addresses, etc.
has excessively limited considerations of:
- the impact on the user side,
- on the zone manager side,
- and on the transition of the millions of existing users.

This is why:

from the very outset of the WG/IDNABIS, I asked the Chair if the way he intended to respect the Charter would lead to a user or only to a network side satisfactory solution. The response in being the latter, led me to commit to the support of the WG's work and to compatibly extend it to support the needs of the user side, in particular through the Multi-Layer DNS pile.
Experience showed that the Internet side and the User side were not able to be debated in the same WG. Therefore, with the IETF Chair's help, I initiated the iucg@ietf.org non-WG mailing list and engaged in building and supporting the http://iucg.org site. This permitted the exploration of optional, transparent "Intelligent User Interface" (IUI) middleware as a response, on the user side, to:

the IDNA2008 requirements,
the Internet multiplicity needs,
and to actively consider the support of the Intersem (Semiotic Internet) for which I am striving.

In conformance with the rules of appeal:

during the Last Call period and further to the IDNA2008 approval, I have exchanged mails on this matter with:

Vint Cerf, Chair, WG/IDNABIS
Lisa Dussault, Director, Application Area
Russ Housley, Chair, IESG
and sent a position statement where I explained as to why I would need to appeal if the Internet community was not warned and helped to adapt to the changes, opportunities, and risks that would possibly be introduced by the change from IDNA2003 to IDNA2008 in the current context.

I explained the context that we face due to ICANN's real life attitude, and lack of proper architectural information
I announced this appeal as a way to permit a reflection period for the Internet Community
I introduced the kind of non-community debated architectural solution that I would be forced to deploy and that everyone could imitate or enhance without proper order due to a lack of standardization structure, with possible important risks for the naming industry and the Industrial Property protection (this is the reason why I have not published a draft yet. It is, however, documented and actively read on the IUCG site).
I reported that I positively tested its concepts as only being a simple user's reading of the Internet technology in light of IDNA2008, in turn calling for not a single change in the Internet deployed technology, and in a first step only for a punycode extension.
I tried to make people aware that it might imply an unprecedented change in the Internet management, from decentralized to distributed.

like every other protocol, IDNA2003 was designed to support the typographic complexity of scripts in being closely related to Unicode. Based upon field experience, IDNA2008 re-visited it in order to address the spiraling orthotypographic complexity of the human linguistic diversity. This first led to an impasse relating to the mapping of Unicode characters into other Unicode characters prior to the generation of a punycode equivalent string to produce an A-label. This impasse showed the upper limit of the Internet architectural paradigm.

Its consensual resolution introduced a new Internet architectural paradigm where:

an "unusual" but necessary "off the network" operation is to be applied to the user input in order to prepare that user input for use in an "on the network" protocol and to maintain interoperability between the network and usage (natural languages).

this new paradigm expects that the Internet "core" deals with technical internal complexity, while external diversity is addressed at an Internet usage interface (IUI) peripheral level. This could be expressed, from the observation of the IDNA2008 discussion, as the principle that the Internet core is where the IETF can use MUSTs, the IUI is where it can only use SHOULDs, and external usage is where it can only use MAYs.

since the full support of linguistic issues belongs to the "presentation" layer, the Internet "presentation" layer is subsequently evidenced (actually the "xn--" IDNA header means that IDNA uses the Internet "xn" presentation).

The points of appeal

This is why this appeal does not concern the IDNA 2008 document set, as approved by the IESG, which is now of prime stable importance when considering the Internet architecture from a user perspective, but concerns the way the IESG has approved this IDNA2008 document set, while:

not obtaining and inserting a disclaimer from the IAB in turn warning the Internet users community about the architectural consequences of the "unusual" strategy that the IETF adopted in this document set "to insure interoperability" (cf. Mapping document).
not classifying it as an IESG disclaimer warning for the Internet users community about the necessary incompleteness of the new introduced IDNA architecture, when compared to IDNA2003, due to its open nature on the user side.
in spite of the Working Group Summary statement that: "There was an impasse relating to the mapping of Unicode characters into other Unicode characters prior to the generation of a punycode equivalent string to produce an A-label [please see the Definitions document]. This was resolved by introducing the non-normative “mappings” document", wherein that Mapping document was not simultaneously approved, but while it should at least have been acknowledged at the same level as the Rationale document.
in so doing, in not having considered its precautionary duty enough as it results from the IETF mission, and introducing confusion that is to be urgently clarified before its consequences might endanger the entire Internet system architecture and the operational deployment unsuitability for the reasons detailed in this appeal.

Context of the Appeal

To try to best set the context of this appeal, I will try to document it from various points of view.

the Working Group Summary point of view.
the WG/IDNABIS point of view
the point of view of an application side designer.
AD + WG/Chair point of view
ICANN published point of view
the IAB point of view
my own point of view as an Internet/IETF user
the "IDNA2010" BCP work

Working Group Summary point of view

"The initial impetus for the revisiting of the IDNA2003 proposed standards emerged in written form in RFC4690. An informal technical team worked to develop a framework for consideration that was later discussed, edited, and ratified to create the IDNABIS working group in 2008. Readers will note that this is nearly 2010 but the new specifications bear the label IDNA2008 because the work was started in that year. The documents resulting from the IDNABIS Working Group effort have been extensively discussed over a two year period by the WG and by interested parties especially language experts in the Chinese, Japanese and Hangul spaces, speakers of Hebrew, Indic languages as well as a working group of expert Arabic speakers. The WG has had the participation of several Unicode consortium representatives. There was controversy during the development of these documents but a rough consensus has formed around the recommendations.

There was an impasse relating to mapping of Unicode characters into other Unicode characters prior to the generation of a punycode equivalent string to produce an A-label [please see the Definitions document]. This was resolved by introducing the non-normative “mappings” document observing ways in which this aspect of dealing with internationalized domain names might be approached. The principal rationale for re-visiting the IDNA2003 recommendations arose from field experience and a recommendation from the IAB [RFC4690]. A major objective was to re-specify the standard in such a way as to make it independent of changes to the Unicode code set (something that evolves more or less continuously). The method for achieving this is to use the Unicode properties feature (per code-point/character) to determine whether the code point should be allowed, disallowed or used only under certain conditions in domain name labels. There remains the problem of deployment in a world of web servers, browsers and other applications using domain names that may have already implemented the IDNA2003 recommendations.

Implementation tactics for dealing with the old and new specifications may vary. Perfect backward compatibility with IDNA2003 was not possible (without simply replicating it, negating the rationale for the redefinition effort of IDNA2008). This is particularly true of the special characters “esszet” or “sharp-S” used in German and the “final sigma” used in Greek. These were mapped into other valid Unicode characters under IDNA2003 but allowed in IDNA2008 because the Unicode code points for these were introduced in the interim between IDNA2003 and IDNA2008 standardization efforts. Registries have several implementation choices including bundled registration of previously mapped and newly allowed characters or rejection of conflicting new registrations. The treatment of languages that are expressed in Right-to-Left form (see “Bi-Di” document) has been revised relative to IDNA2003 and it is believed that the revision is clearer and more precise in its form and limitations on the use of numeric characters, for example."

The WG/IDNABIS point of view

The WG/IDNABIS has twice approved the Mapping document by rough consensus declared by the Chair. It has resolved its inner impasse (cf. Working Group Summary) on this document. This document states what the WG thinks, and what the approved document set is based upon.

The WG/IDNABIS and the authors of the Mapping document did not want it to be approved as a standard track because "it does not specify the behavior of a protocol that appears 'on the wire'". However, it illuminatingly explains that IDNA2008 "describes an operation that is to be applied to user input in order to prepare that user input for use in an 'on the network' protocol. As unusual as this may be for an IETF protocol document, it is a necessary operation to maintain interoperability".

It makes clear the necessity of a work to be engaged to maintain and serve interoperability on the user side. Without this work, IDNA2008 is not interoperable with the user side.

Point of view of an Application side designer

I asked Patrik Falström, author of one of the documents, about his understanding of the development work to be carried out on the User side, of which he is an acknowledged international expert and a professional designer, as results from IDNA2008 (Annex 8. Mail exchange with Patrik Falström). This shows the opened possibilities on the user side, but also the lack of warranty for identical results as well as simple guidance. This emphasizes the need for an IDNA related BCP by users and user application developers.

AD + WG/Chair point of view

At the end of the LC, the AD posed several pertinent questions that have not been answered yet (Annex 9. AD and Chair point of view), but of which france@large has commented on. The Chair suggested ICANN to be called upon as the representative of the users. I wholly object to this for several reasons:

ICANN only takes care of the administration of addressing and class IN naming tables. It has nothing to do with the edge Internet. A technical disagreement with a linguistic community might lead to a split of the Internet.

ICANN has no legitimacy to represent users. As an example, france@atlarge is the eldest ALS. It was incorporated by French candidates to the ICANN BoD in 2000 to serve the French @large community. However, france@large was denied ALAC membership. INTLNET is a non-profit that I created with Tymnet back in 1978: it was denied to join the non-commercial constituency. For years now, I have been denied the possibility to join the various ICANN IDN WG: I do not object to their right to do this, however, since I do not share their strategic doctrine. However, this implies that they cannot be considered as an open, neutral forum to represent users, ccTLD, IDNccTLD, and IDNgTLDs.

I thank the AD for the questions that she posed. I first objected because what was important to me was to get IDNA2008 adopted after its impasse having been consensually addressed through the still not-adopted Mapping document. I also thank the Chair for insisting that there is a WG consensus supporting that respective Mapping document. I object to the IESG delay in adopting it and in having adopted the rest of the IDNA2008 document set: this leaves pending the question of where the user side of IDNA is to be studied, debated, and documented before one can start testing IDNA2008. This gives the false feeling to ICANN (cf. infra) that they can usefully proceed with their FAST TRACK project, which will probably be matched by the "MY TRACK" counter project by dismayed IDNgTLDs who will haveprematurely used the unique virtual root matrix.

ICANN published point of view

As the Internet User Rod Beckstrom, President and CEO of ICANN, puts it, "One of the most significant innovations in the Internet since its inception is the introduction of top-level Internationalized Domain Names (IDN TLDs)". This is certainly true. However, from the context of his declarations, the Internet User Rod Beckstrom seems to believe that:

this results from the IESG approval of the IDNA2008 document set as a "revised version of the IDNA technical standard"
the transition of which could be:

tested through the sole ICANN Fast Track project, which only involves a few non-Roman IDNccTLDs and neither Roman IDNccTLDs nor innovative IDNgTLDs,
and further on accompanied by the sole ICANN entity, while many TLDs outside of the ICANN zone area may deploy through a unique virtual root matrix.

This is erroneous.

However, this dangerous confusion seems to be shared by several other key stakeholders of the Internet Governance due to the lack of IESG and/or IAB proper guidance. They ignore the fact that the IESG approved IDNA2008 document set:

documents the way the Internet should behave when accessed using IDNs,
does not document the way Internet Users should transition safely and securely from an environment of millions of IDNA2003 IDNs that are already in use today in the unique class IN, to the millions of TLDs in the multiplicity of classes and presentations of the unique virtual root matrix, in which this already engaged transition in turn leads to.

Would Internet Users at large stay under the false impression that IDNA2008 is a comprehensive Internet protocol and proceed anyway as if it was? Could this not have catastrophic consequences for the stability and credibility of the Internet as well as for the entire Internet economy? They ignore the fact that the IDNA2008 document set is a first necessary step on the network side, which is just as necessary as a second step on the users and operators’ side, and possibly a third step in between the network and its users in order to organize their related administration.

The IAB point of view

IAB has explored what can be learned from the current difficulties in implementing Internationalized Domain Names (IDNs) without the intention for this document to influence any current working group charter.

This document spells out recommendations and security considerations (Annex 10. IAB recommendations and considerations) that should be considered by any globalization or multilingualization effort.

The IDNApplication concept that I support consists in respecting the IAD recommendations, and in having a single separate application, on the user side, dedicated to the ML-DNS (multilayer DNS). The problem raised by such an architecture is that it can easily support a unique ASCII/UTF-8 virtual root multiclass matrix.

The point of view of an Internet and IETF deliverables user

This section was reviewed privately and shortly at the IUCG, out of the appeal context.

I am a person

This means that I am centric to the information society. This also technically means that I am a subject operated by a natural semantic processor of the HSS brand (Homo Sapiens Sapiens) whose capacities interact with material and immaterial objects and semiotically relates with other subjects throughout various ecosystems. For example, my body is my interface with the physical ecosystem; it supports my semiophysical capabilities (utterances, gestures, etc.) that include my semiodigital abilities (use of a computer, mobile phone, word processor, mouse, etc.).

I am an Internet user

This means that one of these ecosystems that I belong to is the world digital ecosystem (WDE) of which the Internet is the current main content level communication commodity. My digital self is, therefore, embodied in my "cybship", i.e. the real and virtual elements that are necessary to my online presence and all the various online properties and systems of mine that I may use to navigate and operate in my digital life.

I am an Internet lead user

This means that I am interested in improving my own digital semiotic capacities and the semiotic and behavioral feedback of those of whom I use to interact and relate. This implies:

the best adminance of my, and of the common, investments,
the best governance of my, and of the common, digital and general life,
their most pertinent concertation (usa: concerted cooperation).

This memo only focuses on the adminance part, i.e. how to provide governance with the structural tools that it needs for all of us to best use them.

The adminance of my, and of the common, structural tools calls for stability and the enhancement of what exists:

Stability can be ensured by way of the maintenance of equipment and the governance of its rules of use.
Enhancement results from structural investment innovation.

Innovation can be inventive, incremental, disruptive, or architectural.

Inventive innovation is usually academic.
Incremental innovation in the signal and content communication areas primarily belongs to the ITU and IETF scopes.
Disruptive innovation usually spurs industrial ventures.
Architectural innovation is often a synonym for complexity simplification, something that often results from looking at an established solution set within a new user perspective.

If I consider the current state of my communication capabilities, I can clearly see that I am "half-way through":

Signal and passive content bandwidth and communications are available with half the world being connected (Internet, mobile phones) under stable terms, which might be endangered by some political and commercial interests.
ambient and active content and semantic bandwidth and communications are not available yet.

I can actually perceive an intrinsic architectural differenc e between what I already have and what I am missing.

What I have supports me, as in any other end user, among the growing billions of accessing interchangeable other people or machines, while only being identified through a stable or transient IP address. This unique neutrally shared system works well, but it has a growth problem that is leading to concerns about its most precious feature: neutrality. This is a system matching end to end diversity by growth.
What I am missing will have to successfully support me as a particular interuser, who is calling and being called because he or she is unique throughout the diversity of the billions of interusers. The question is then: could such a multiplicity work? This would be a system addressing diversity by multiplication.

Up to now, Internet technology seems to have supported multiplication (charsets, IP addresses, number of accesses, traffic, root servers, etc. ) by growth. This has been documented in four occurrences, in particular: RFC 1958, RFC 3439, RFC 3935 and US and French laws, IDNA2003. IDNA2008 now supports growth by a multiplications ... I have, with the rest of the multitude, to provide.

RFC 1958

RFC 1958 is based upon the permanent change principle ("Principles that seem sacred today will be deprecated tomorrow. The principle of constant change is perhaps the only principle of the Internet that should survive indefinitely"), and on the guidelines that should, therefore, be revisited upon experience but that seem to remain rather pertinent:

The goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network.
Connectivity is its own reward.
In an ideal situation there should be one, and only one, protocol at the Internet level.
End-to-end functions can best be realized by end-to-end protocols.
Everything else should be done at the fringes.
Nobody owns the Internet, there is no centralized control.
Heterogeneity is inevitable and must be supported by design.
If there are several ways of doing the same thing, choose one.
All designs must scale readily to very many nodes per site and to many millions of sites.
Performance and cost must be considered as well as functionality.
Keep it simple. When in doubt during design, choose the simplest solution.
Modularity is good. If you can keep things separate, do so.
In many cases it is better to adopt an almost complete solution now, rather than to wait until a perfect solution can be found.
Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually.
Be strict when sending and tolerant when receiving.
Be parsimonious with unsolicited packets, especially multicasts and broadcasts.
Circular dependencies must be avoided.
Objects should be self describing (include type and size), within reasonable limits.
All specifications should use the same terminology and notation, and the same bit- and byte-order convention
Nothing gets standardized until there are multiple instances of running code.
Avoid any design that requires addresses to be hard coded.
A single naming structure should be used.
Public (i.e. widely visible) names should be in case-independent ASCII. Specifically, this refers to DNS names.
Addresses must be unambiguous (unique within any scope where they may appear)
Upper layer protocols must be able to identify end-points unambiguously.
Prefer unpatented technology.
Any implementation which does not include all of the required components cannot claim conformance with the standard.
Designs should be fully international, with support for localisation (adaptation to local character sets).
All designs must fit into the IP security architecture.
Confidentiality and authentication are the responsibility of end users and must be implemented in the protocols used by the end users.
Wherever an algorithm is called for in a protocol, the protocol should be designed to permit alternative algorithms to be used and the specific algorithm employed in a particular implementation should be explicitly labeled.
Preference should be given to algorithms which have stood the test of time and which are not unnecessarily inefficient.
To ensure interoperation between endpoints making use of security services, one algorithm (or suite of algorithms) should be mandated to ensure the ability to negotiate a secure context between implementations.

RFC 3439

RFC 3439 documents the Internet as a very large system calling for an absolute respect of the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling. This directly matches our lead user architectural primary concern: simplifying complexity rather than incrementally addressing it or disruptively increasing it.

However, if RFC 3439:

does explains that "optimization can also be considered harmful. [as it] introduces complexity, [as it introduces ] introducing tighter coupling between components and layers" because "much of the non-linearity observed [in] large systems is largely due to coupling."

it does not propose any simplification doctrine based on uncoupling. However, it seems to introduce one when it notes that: "Adding a new Internet service is just a matter of distributing an application to a few consenting desktops who wish to use it."

RFC 3935

RFC 3935 perceives the Internet of Engineers as:

a large, heterogeneous collection of interconnected core and edge systems that can be used for communication of many different types between any interested parties connected to it. The Internet is a truly global network, reaching into just about every country in the world.

which can be matched with the legal operators perception of:

a combination of computer facilities and electromagnetic transmission media, and related equipment and software, comprising the interconnected worldwide network of computer networks that employ the Transmission Control Protocol/Internet Protocol or any successor protocol to transmit information.

and the user perception of "online" services based, by French law, on trust understood, at network level, as stability, predictability, neutrality

A convergent open definition could then be:

all the packet-switched interconnected processors to support trusted public and private online communications and relational services.

You forget about adjencies. This will make your text less readable for Asians.Moreover you quote "bandwidth and communications" several times.

IDNA2003

The widest diversity that the Internet has had to meet up to now is the linguistic diversity (there are around 25,000 sociolinguistic units and languages and IP evolve all the time). Such diversity is addressed in network architectures by the presentation layer. IETF, so far, has documented no presentation layer support for the Internet. The linguistic diversity has, therefore, been met by increasing the character bandwidth (ISO 10646 - Unicode, which now supports nearly 100,000 signs), this is usually called i18n, or internationalization.

A user can be offered five main levels of support for linguistic diversity:

none

Linguistic issues are not considered by technology. This may result from the use of signs, numbers, keys, or nothing like a physical voice.

lingualization

A given natural or coded language is at some stage embedded in the technology. Plurilingualization is possible by using polynyms (synonyms in different languages).

The Internet is lingualized (RFC 3935: The "IETF uses the English language for its work [] because of its utility for working in a global context.").

globalization

A lingualized technology is extended in order to be able to transparently quote any other language.

This calls for at least three features:

support of the typography that is used by every language. This is internationalization. Every existing character should be supported end to end by the medium.
support of the cultural orthotypography (or typographical syntax: what defines the meaning and rightful usage of typographic signs, formats, etc.). This is "localization". Computer localization is documented in "locale" files.
content tagging in order to indicate the orthotypographic conventions of the source. This is the RFC 4645, 5646, and 4647 set.

multilingualization

This means that the technology in turn supports the human orthotypography. This is necessary for any semantic oriented services.

universalization

At this level, sememes (semantic units) are used. They are externalized through the mecasemiotic or mecalanguage (sememes driven, machine semiotic or natural language versions) of each end.

IDNA2003 in being tightly coupled to Unicode and its machine level orthotypography (CLDR project) was rigidly bound to an end to end globalization. Together with the IANA langtags registry, this provided users with a consistent experience of the globalized Internet system, fully supporting the various diversities (speed, protocols, addresses, traffic types, machines typography and orthotypography, languages, etc.) through single corresponding bandwidths.

IDNA2008

IDNA2008 does not change that Internet. To the contrary, because it rightly acknowledges that my semantically driven orthotypographic needs are too complex for a single end to end solution, it proposes to use that globalized Internet as a rock solid, end to end, LDH DNS, intelligence on the fringes, digitally globalized, etc. core tool-kit, together with its RFC 1958/3439 checklists, in turn allowing us, interusers, to build our own Internet usage Interface (IUI) and our own IUI to IUI conventions.

Multiplication no longer has to be supported by bandwidth growth (in this case typographic and orthotypographic bandwidth), but is distributed among the myriad of our user processors. It is up to us to support our human semantic inter-relational protocols, that is to say natural languages.

This acknowledges the RFC 3439 Law of Diminishing Returns, which states that if one factor of production is increased while the others remain constant (such as some mapping at the protocol level, i.e. within the Internet core), the overall returns will relatively decrease after a certain point (IDNA general usability). IDNA2008, in uncoupling IDNA from Unicode versions, acknowledges that "trying to squeeze out" Unicode efficiency in core Internet protocols "past" the ASCII DNS "only adds complexity, and hence leads to less reliable systems".

In addition, brain to brain interintelligibility proceeds from a non-binary simplicity. It became too complex to support it in using global protocols past the passive content layer. The elegance of IDNA2008 is to use the Unicode based punycode algorithm to build an hourglass solution where the entire multilingual name space is robustly and flexibly supported by multiplication at the IUI to IUI layer, over protected end to end legacy ASCII DNS.

However, there is a big "however"

This "however" is that a user guide is missing. As an interuser having to support my language, I need a user guide to inform me as to how to best use the RFC 1958/3439 checklist, at the IUI layer, when having to properly and securely interface the Internet IDNA2008 protocol.

As an interuser, I know that there is now an "Internet tool-kit" permitting me to engage in my second half-way journey towards the brain to brain communications and facilitation services that I strive for:

first in supporting extended network services on my computer side (we understand):

basic services, as transport related,
value-added services, as envelope related,
and extended ones, as content related.

I expect that these extended services will:

not only serve a robust WIRIWIG (what I register is what I get) ML-DNS domain name pile (i.e. all the UTF to ASCII various presentations of the same domain name) depending on the used algorithms and resolution systems.
but also support ambient content (for example, local speed limit) and active content (what you get is what I wanted you to receive, not what I sent).

This is the field of the Interplus proposition - an IUI architecture that has the unfortunate capacity to easily support the Internet presentation layer as a fall-out of IDNA, the French orthotypography that IDNA2008 does not support, the non-administered yet unique DNS virtual root matrix with billions of non-necessarily unique TLDs in all the classes, and a few other possibilities.

then, I will be in a position to enter the semiodigital area of the semantic bandwidth and communication, which we call the Intersem.

This is why some concerted guidance and community assistance would be of great help.

Maybe with an Internet Adminance enhanced cooperation that I could trust,
certainly with an IDNA usage oriented best practice document and forum,

and an IUI architectural research on the best IDNA and Internet Multiplication capacity matching configuration that I should adopt.

Am I wrong if?...

Am I not better off by having a single Internet Multiplication Management System on my PC rather than every application using its own solution brand?

For example, I would prefer one single IDNApplication supporting IDNs rather than different custom modules in my various browsers, mail agent, etc.

If I feel that I should reconsider my entire "cybship" architecture so that it may adapt from sailing in its enlarging river environment in order to navigate the varied weather of the multiple internationalized high seas.

I would like to first adapt my system terminology in order to be relevant:

every system belongs to that system intricacy that the universe is.
the part of that universe that may relate with a system is its exotem.
the interface between a system and its exotem is its peritem.
it is subjective as to how one considers a system from its inside.
perijective from its peritem.
circumjective from it neighborhood.
objective from its exotem.

This would mean that:

the Internet exotem is every system that may immediately, or in the future, relate with the Internet.
the Internet peritem should, therefore, be designed so as to be interoperable with all of its exotem.
by its open definition (communication continuity of the universe digital eco-system), the Internet has an unlimited size (every processor made interoperable by packet switching networks) from nanos to galaxies. In this, it is another "universal", such as the cosmos, life, time, etc.
henceforth, its exotem necessarily includes the "internat(ure)" , the natural ecosystem communication continuity.
since we cannot change the natural simplicity, interoperability with the "internat" calls for the Internet simplicity that is demanded by RFC 3439 to be interoperable with the simplicity of the "natural" diversity. This is what the "Mapping" document alludes to when it refers to the "unusual" need for the IETF to document exotemic particulars in the case of the natural linguistic diversity.

At this stage, IAB guidance is needed. RFC 3439 states that the Internet, as a very large system, is to be based upon the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling. IDNA2008 "unusually" accepts to

uncouple the end to end globally unique core network system
from the user linguistic diversity semantically controlled exotem
introducing a linguistic Internet peritem that is to be built by the myriad of users' own linguistic peritems,

as a simplification of complexity.

This leads one to think that the "Mapping" document, which was necessary to address the IDNA2008 impasse but that the IESG has not approved yet, seems to clearly identify:

the Internet system to where the IETF can use MUSTs
the Internet peritem to where the IETF can use SHOULDs
the Internet exotem to where the IETF can only use MAYs

Guidance is, therefore, needed from the IAB in at least two areas:

Is the Internet Simplicity Principle's simplicity the same as Nature's simplicity (that can be summarized by Maupertuis' universally accepted principle). How do they differ? How do they interoperate? What are the implications?
Does the Internet peritem belong to the IETF scopea?

Other guidance that I will need, as an interuser, is to know about the reproducibility of the IDNA2008 architectural simplification, because there are other areas where "the probability of achieving a stable implementation of an architecture is inversely proportional to its number of components" (RFC 3439). Moreover, complexity is often "software-based, not hardware driven, and therefore had cost curves worse than Moore's Law.", which may lead to situations such as ROAP.

In particular, I need to know if the Amplification Principle constrains or frees the various IDNA2008 deployment strategies. It states that there are non-linearities that occur on a large scale that do not occur on a small to medium scale. IDNA2008, as I see it, still extends the size of the Internet, and multiplies the number of small things. Is this multiplication acting as a catalyst or, to the contrary, as an uncoupling inhibitor of their possibly huge impact amplification? Furthermore, RFC 3439 states that the minimization of interaction contributes to simplicity. It adds: "As a result, consideration of "core vs. end-point" state interaction is crucial when analyzing protocols such as Network Address Translation (NAT), which reduce the transparency between network and hosts.". Will IUIs have a NAT like effect or will the strict polynymy (synonymy in different languages) of the ML-DNS pile (bijective conversion between the various versions of a domain name through its different layers: A-label/U-label) protect users from this?

IDNA2010/IDNA2012 BCP engaged work

After the closure by the IETF WG/IDNABIS of the IDNA2008 work, we now have to validate this new version of IDNA after six years of operations under IDNA2003. Subsequent to full-scale field tests being carried out, users' contributions, ICANN comments, submissions of new gTLDs, and our operational practices, we will need to reach a final consensus in order to operationally consolidate this major evolution of the Internet of users.

It is now up to us to make IDNA2010 an Internet community convergence point.

The plan is to use the real-life Projet.FRA and Multilinc experiments as test beds. These projects have already documented the fact that prior to engaging in commercial services, e.g. to support the French majuscules, some glyphs, and special bidirectional usages, they need an IDNA2010 user side document that has been tested by the community and approved by the IETF.

This is why an IDNA2010 special interest group of the IUCG is currently being created with the target of continuing the work on a finalized IDNA operational and culturally adaptive version.

Because ccNSO started referring to "IDNA2010" as the next version of IDNA2008, I created:

http://idna2010.org as a project of BCP, documenting the implementation of IDNA2008 on the user side.
http://idna2012.org as a project of BCP, documenting the administration and maintenance of the joint operations of IDNA2008 on the Internet side and IDNA2010 on the user side.

In order to not confuse issues, it was agreed with the WG/IDNABIS Chair that the workon@idna2010.org would be frozen until it published a first draft. This appeal is considered as a first Draft.

To permit IESG Members to address the kind of issues involved in the permanent SIG IDNA group (and in some cases the emotional weight involved that belongs to linguistic orthotypography but does not belong to RFCs), here is a documented list of topics for such an "IDNA Internet tool kit" support and information group. (Annex 11. IDNApplication Medley).

100310 - JFCM Appeal to the IESG