100606 - JFCM Appeal to the IAB

From IUCG - Internet Users Contributing Group

Jump to: navigation, search

Dear IAB Members,

This appeal concerns the response that I received on April 7, 2010 from the IESG to the post-IDNA2008 appeal that I filed on March 10, 2010. This memo documents:

  • the root of the difficulty,
  • the background of this appeal,
  • the points that are appealed,
  • and what their disregard would imply.


IDNA2008 is a replacement for IDNA2003 on the network side. There is, so far, no replacement on the user side and, therefore, there is no administrative and no operational cooperation framework as yet. The WG/IDNABIS “Mapping” document clearly illustrates the beginning of work still to be done on the user side. That work is engaged but is now hampered by the incertitude created by:

  • pertinent points raised by the AD, but outside of the WG/IDNABIS Charter.
  • an IAB, still uncompleted, I_D on IDNA.
  • the AD/IESG non-explained killing of the “Mapping” document.
  • the IESG qualification of “research” regarding undefined parts of that engaged work.
  • and the lack of a clarification through an IESG disclaimer prefacing the IDNA2008 document set.

.

Contents


My basic agreement and disagreement with the IESG

On January 7, 2010, I received a mail from Russ Housley, Chair of the IESG. This mail was copied to the IESG, the IUCG (Internet Users Consulting Group), and the mailing list that is working on the IDNA2010 BCP Draft (cf. further), Vint Cerf, WG/IDNABIS Chair, Patrik Falström, Pete Resnick, and John Klensin. Its text stated:

"JFC:
"Thanks for your IETF Last Call comments. Your comments stimulated a significant amount of discussion of the documents from the IDNAbis WG. The IESG approved the documents that you are most concerned with on their telechat today. The announcement of this action will come out next week.
"I think it is important to point out that some of your suggestions are beyond the scope of the IDNAbis WG charter, and in fact, some of them are research.
"Best regards,
"Russ"

This last call comment is now published as http://tools.ietf.org/html/draft-iucg-afra-reports-00.


This mail shows that we fully agree on the first point, i.e. the correctness of IDNA2008, the urgency of its publication, and its importance for the Internet.

It also indicates that we may have a basic difference of point of view that can be a misunderstanding or a disagreement (IESG: "it is an important point").

  • The IESG seems to perceive as "research suggestions" undefined parts of what we conceive as general Internet architectural concepts that we made sure IDNA2008 would respect. They are part of the WG/IDNABIS consensus. These concepts belong to the general network and Internet architectural culture and it was necessary to call on them to address the new core issues, such as lingualisation (presentation layer), Internet linguistic bias, size of the linguistic diversity, current IAB and pertinent AD objections to IDNA (outside of the WG scope) etc. and, at this stage, to solidify the Internet architectural consistency and dramatically extend its capacities.
  • This difference of point of view may explain why the key WG/IDNABIS consensual "Mapping" document was killed by the AD and not presented to the IESG. This document for Information illustrated that IDNA2008 calls for a lot of complementary work along the lines that it quotes and de facto raised the question of who should carry it and where (IETF or not). In this way it plainly informed the Community. Several efforts have already engaged in that work.

This is why the community needs to be informed of the existence of a gap, and of the exact extend of this gap, between the IDNA consensus and the IETF position. There can be good reasons for a temporary gap, such as:

  • to protect ICANN against the possibilities and opportunities open by IDNA2008,
  • simply wait for a confirmation by way of the results of the IAB investigations on IDNA,
  • prepare new, adequate community support for what one may now call the "RFC1958/RFC3439/IDNA2008" Internet architecture.

This need for the Internet community to be informed rightly justified this appeal.


I am an Internet lead user

I am an Internet lead user, with long delayed needs in the support of the linguistic diversity, extended services (ambient, active, and meta content), and semantic Internet areas. This lead-usership is a broad part due to the Internet innovation pace: I mostly refer to concepts that were operationally proven in my international network managerial capacity of the mid-1980s. The main difference is that the K$250 configurations that I sold to monopolies can now be powerfully replaced by free software on $250 private computers.


There has been for decades a proven general architecture that permits these needs to be addressed and that is transparent to the Internet protocols and codes, matches the WSIS (World Summit on Information Society) consensus for a "people centered, a caractere humain, centrada en la persona" human society assisted by its digital ecosystem, and that has been attempted on the Internet under different forms (p2p, Web 2.0, etc.). I spent years at the IETF and throughout the Internet Governance seeking to ensure it is not being blocked by private or public short-term interests (cf. IAB's RFC 3869) until it could harmlessly fit the people's Internet technology. I approved IDNA2008 because it uses and respects architectural principles that permit the Internet to be optionally and transparently encapsulated in such architecture that we can now freely explore, document, develop, and deploy.


This approach was in line with RFC 5434, which states: "The best description and [earliest] understanding of an actual problem usually comes from the [lead user], customer, operator, or deployer of a technology. They are the ones that most clearly understand the difficulties they have (that need addressing) and they are the ones who will have to deploy any proposed solution. Thus, it is critical to hear their voice when formulating the details of the problem statement. Moreover, when evaluating the relative merits of differing solution approaches".

RFC 5434 also states: "When a WG finishes an effort, the WG's output will only be useful if it actually solves a real, compelling problem faced by the actual user of the technology (i.e., the customer or operator)".

1. I see that IDNA2008 helps in solving, and clearly illustrates how to solve, the real, compelling problem that the Internet technology faced in order to permit me and other users of the technology to encapsulate the Internet in our own innovations.
2. This is why this appeal is also a community alert that is not to be accused of having inconsiderably introduced a ten times, NAT equivalent issue without having informed enough.

We had a problem, and this problem has been solved as long as the IETF is concerned. Therefore,
  • Either, the IAB responds to this appeal and provides guidance in the continuation of the IESG only partial publishing, without a disclaimer, of the IDNA2008 document set.
  • or Internet users can continue, on their own, the work of building a distributed network atop the decentralized Internet along their understanding of the "RFC1958/RFC3439/IDNA2008" Internet architecture. This will probably result in an architectural competition with ICANN, industry, and some Governments.


Background

My simple objective was for IDNA use to not be constrained and the WG/IDNABIS Charter to be respected (mapping at the protocol level and Unicode severance).


relations with the WG

From the WG/IDNABIS onset, I asked about the real target of the WG:

  • either only a strict conformance to RFCs and the respect of the Charter,
  • or also to progress towards an eventual satisfaction of the Users in using the Charter's capacity to reform itself.

The answer by the former WG/IDNA Chair, fully supported by the WG/IDNABIS Chair, was to stay within the scope of the Charter. Even though the Chair had the Charter modified during the WG process, it was not enough to enclose the entire IDNA scope.

My answer as an Internet user was a published commitment to support the WG/IDNABIS debate and to further investigate, test, and document an "ML-DNS" encapsulation from a user's point of view. I only described the ML-DNS (Multi-Layer DNS) as a solution providing every user in his/her own language [or a specific interapplication] the same QoS as the DNS does for English speakers using ASCII scripts.


relations with the IETF leadership

I maintained an open dialog with the AD. Relations were more difficult with the WG Chair until the IESG Chair's authorized the iucg@ietf.org, a non-WG independent mailing list to welcome user’s inputs to the IETF process and possibly document Internet Use architecture. I should note here that the formal description of this Internet Use architecture is delayed until the IAB has commented on the IESG presentation of IDNA2008, because we do not, and we have no ambition to, direct the Internet architecture. This Internet use architecture includes the ML-DNS, SHOULD be 100% IDNA2008 compliant (IDNA2008 is consensually characterized by no MUST for the users), and MUST not interfere with the existing RFCs and Internet codes.


relation with IESG

As the Chair of Projet.FRA for a francophone space and being involved in Multilinc, which is a project for testing multilinguality (interaction between linguistic spaces and userships), I sent a Last Call report that was (cf. above) "intensely discussed" at the IESG. This report explains and documents the decisions that I will (I have) take(n) should ICANN (or others) engage in confusion through projects that are supposed to implement IDNA2008 without two preliminary types of works that I, and to some extend AD, “Mapping” and IAB preliminary work, deem necessary:

  • IDNA2010: how to implement IDNA2008 on the user side. I assisted the creation of the workon@idna2010.org mailing list. We agreed to keep it low profile until IAB guidance.
  • IDNA2012: how to administer IDNA2008/IDNA2010 within the world digital ecosystem convergence.

(NB. The IDNA2010 and IDNA2012 terms were selected in order to evidence that there will be no IDNA2010 as a next version of IDNA2008, as the ccNSO started to imply).


reasons for an appeal

As I did commit in this last report, I appealed the IESG decision. This was for a three reasons:

  • without at least publishing a disclaimer explaining the IDNA2008 architectural footprint and the incompleteness of the new IDNA work, IESG killed the consensual WG/IDNABIS "Mapping" document that gathered enough indications to make everyone understand it (and obtain my support towards the final consensus).
  • if respected, the calendar of the Internet appeal procedure should ensure that the community would get enough time at proper level (IESG, IAB, ICANN, IUCG, IGF, ISO) to dig into the issue, and to obtain an IAB authoritative guidance. This, I did hope, would technically block inadequately supported ill-informed projects, such as a too early ICANN's Fast Track.
  • since I am protected by IESG/IAB (RFC 3683) from directly facilitating an IETF/Last Call debate on the issue, this was the only way for me to proceed in order to:
  • alert the Internet technical community on IDNA architectural conflicts between IDNA2003 and IDNA2008, and of the remaining work to be accomplished within the IDNA2010 framework, as evidenced by the IAB’s current work and the AD’s post-LC questions.
  • have recorded what I understood IDNA2008 to have meant when I and other Francophone Members of the WG/IDNABIS decided to join its rough consensus.
  • keep the debate at the architectural level where it belongs, and not to confuse it with the particular solution that we are working on.

    Referring here to this solution is just to show that there is already a real need since, for a few lead users, it was worth fighting for and working out a solution. This also shows that a solution is achievable. This way, we think that we are just in advance on the situation as described by the RFC 5434: "The purpose of the BOF is almost never to show that there are already proposed solutions, but to demonstrate that there is a real problem that needs solving, a solution would be beneficial to the community, it is believed that a solution is achievable, and there is a critical mass of community support to actually put in the real work of developing a solution."

    However, because we are users and not engineers or standardizers (except to internally document our own grassroots solutions), we do not want to be confronted with another ten years of delays. We cannot afford it. Our contribution as users will, therefore, remain at the level of experimentation reports, suggestions to WG, and filtering when our (intended) practices could be harmed.


Appeal concerning the IESG response

On April 7, 2010, I received a response from the IESG to the appeal that I had filed on March 10, 2010, which stated:

"The IESG received an appeal from JFC Morfin on 10 March 2010. The text of this appeal can be found at the following URL: http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf".

I will split this response into seven sections that I will comment on and appeal successively. Since the purpose of this appeal is to call the attention of the IAB to the necessity of an authoritative introduction to the post-IDNA2008 Internet architecture as now published by the IESG, I will in the last section of this appeal document my own understanding, in case one or several of these appeals are disregarded without an IAB clarification.


Preliminary comment

My appeal to the IAB concerns the seven parts mentioned hereinabove. They will be considered and appealed, for easier reading, one by one in the IESG order. However, this appeal is a working appeal, mostly due to IESG and IAB having impeached me from proceeding otherwise, and to make sure that any project competing with or complementing those of ICANN is subject to the same technical context and calendar, so experience can be commonly shared from different perspectives. This is why they should not be considered and answered independently ,nor without carefully considering all four parts of my appeal to the IESG (in the way that the IESG acknowledged them). This is why the content of the appeal to the IESG (http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf) is certainly a key part of this appeal to the IAB.


Our need to understand the IETF mood

I certainly understand that looking through my IESG appeal might be perceived as a cumbersome and time-consuming task. However, my appeal is not to propose any alternative, but rather to make sure that better explanations are given for everyone to understand the IDNA2008 document set and the implications of the way IESG publishes it without the “Mapping” document and a disclaimer explaining which parts of the user understanding may be qualified of “research” and if some parts of this research belong to the IETF scope, in the same manner. Therefore, my only possibility was:

  • to quote a significant panel of significantly different understandings and positions, including by IAB.
  • to give my own understanding of a bare complete publication of the IDNA2008 set (including the Informational "Mapping" explanation). This understanding is not a final position. However, it must be made clear that:
  • it is why I consensually supported IDNA2008.
  • I have been working on and transparently using for several months a rewarding manner (I call the Interplus) to access and use the Internet that is based on most of it and what I consider as its implications and consequences.
  • I do not see any reason as to why this Interplus method, and/or similar other methods, would not significantly become of use and how this could not create substantial operational confusion in the Internet, unless it is properly administered in a concerted manner between engineers, service providers, and active/lead users.

To show why such a disclaimer was necessary, I fully documented the different positions and rationales, including all those not supporting my own positions.

  • This is firstly due to the nature of my positions, which substantially extend the legacy reading of the Internet architecture. As such, they are positions and not propositions because they do not change the Internet.
  • This is also because such a reading may definitely "influence those who design, use, and manage the Internet", which is collectively (RFC 3935) the role of the IETF. I considered it to be safer to not confuse one major community question with a minor dispute on my own views that may only be an incorrect or elliptic individual response.


Community alert

Today, I am taking full advantage from the IESG response to exemplify the kind, nature, and necessity of the debate created by the conflict between the WG/IDNABIS Charter's scope that has been reviewed by the IAB, and the architectural principles of IDNA, as they have been highlighted by the IAB I_D and the questions of the AD.

  • by kind, I intend to emphasize that the topic is broad and necessitates an "unusual" approach that is adapted to an "unusual" scope where "off-the-rope" protocols are to be documented. ("unusual" is the key concept I perceive in the AD/IESG killed "Mapping" document).
  • by nature, I mean that what is at stake is the entire Internet architectural fundamental principle as in the possible direct conflict with RFC 3935, i.e. the very mission of the IETF, due to an extension of the understanding of the nature of the Internet. What does making the "Internet work better" mean and along which criteria? Is the Internet better when decentralized, distributed, or both?
  • by necessity, I would like to use this case to illustrate the need to use enough precaution in the IETF debates and IESG decisions when dealing with hidden architectural issues and/or highly innovative users' concerns or needs.

This is why I appealed the IAB against the IESG's disrespect of its precautionary duty as documented in my http://tools.ietf.org/html/draft-iucg-precaution-00 I_D, the text of which is quoted in my IESG appeal and I will upgrade from the IDNA2008 experience.


Main and immediate motive

The main motive of my appeal is to address the fact that no one can now understand from the IETF as to how they want to be addressed the reported, immediate problems, which others and I face in the application of IDNA. This means that what I am currently working on and investing in (to address the needs that I reported, which are or will be the problem of many that may adopt it) is being done in a way that may now turn not be adequate; however, I was a part of the consensus.

This appeal is, therefore, to avoid wasting my and other people’s time. Its outcome will help others and us to decide on our position concerning our own projects. It should also help ICANN, their stakeholders, and the community better understand how to make these experimentations useful for the Internet community, in respecting ICANN own ICP-3 recommendations (equally open to all, by the community, reversibility of tested innovation, non-commercial, not impeding the existing operating usage, etc.).


IESG: 1. Too large amount of supporting material

<IESG>

Mr. Morfin submitted an appeal accompanied by a very large amount of supporting material. Before addressing the content of the appeal, the IESG wants to inform the community that an appeal with such a large amount of material is not helpful to anyone. RFC 2026 requires all appeals to "include a detailed and specific description of the facts of the dispute." Clearly a significant amount of time was needed to generate the appeal and supporting material, and the overwhelming amount of material made evaluation more difficult than necessary. Any individual making an appeal to the IESG is strongly encouraged to provide a clear, concise, and focused text that includes a description of the action already taken, the reasons for the disagreement with the action taken, and their preferred remedy.

</IESG>


IESG acknowledges that I submitted an appeal accompanied by a very large amount of supporting material. This was to respect the RFC 2026 requirement for appeals to "include a detailed and specific description of the facts of the dispute.", on at least three fundamental Internet architectural evolutions that were necessary to get IDNA2008 functioning:

  • Introduction of the Internet presentation layer.
  • Resolution of diversity by intelligent multiplication rather than by capacity growth as in the past.
  • User-centricity at the core of the Internet experience through the concept of an Internet Use Interface (IUI) that seems to result from a consensus oriented reading of the WG/IDNABIS and IAB possibly looking diverging positions.

My appeal is that the IESG has failed in its precautionary duty in not introducing a disclaimer, advisably based on an IAB response to a guidance request, when it did not approve the WG/IDNABIS "Mapping" document for information serving to illustrate some of the consequences for the Internet Usership. This prevents regular and also involved readers like me to understand what to do in order to best match IDNA2008.


In such a case:

  • a detailed and specific description of the facts can only be the most neutral compilation of the seemingly contradicting serious facts, positions, and concerns as expressed by concerned experts and the IAB.
  • The preferred remedy was to spend a significant amount of time to generate the appeal and supporting material in order to give readers all of the significant material that would in turn enable them to make a personal and documented evaluation in a case certainly more difficult than usual. The WG consensus produced a document that the AD did not forward to the IESG, which was based upon the acknowledgment that IDNA2008 made an “unusual” case for the IETF. In such an instance, I did not feel that an individual submission of mine would do better, or would be better accepted, when a WG consensual I_D document has not been.


==>> Point of Appeal
 I appeal against the IESG position that: "It is therefore a violation of RFC 2026 to publish an appeal with such a large amount of material because that is not helpful to anyone."


IESG: 2. The scope of the appeal

<IESG>

During the community discussion of the appeal, Mr. Morfin characterized his own appeal text as follows:

Appeal comes in four layers.

1. 20 lines which describes the appeal.
2. 7 pages that document why I appeal, how, and on what.
3. 13 pages that present positions by different persons or authorities that comfort my concern and the existing IETF context
4. annexes, for those interested in particular issues.

This appeal concerns most of the Internet architecture, the least that can be done is to permit serious people to consider if I am right or wrong without having to carry again work made by many. This also permits to put in public domain propositions that some might want to consider private for commercial or strategic development and to get poor quick comments to decrease hacker's interest.

Anyway, my personal real purpose of this appeal is that no one can claim I did not report the IETF and put in public domain what they may further consider as a mess."

</IESG>


The IESG has perceived the purpose and structure of this appeal well, with the threefold exception that:

a. it qualifies as “opportunities” a considerable change in the reading of the Internet architectural standards. This is not an opportunity; this is a fact of potential major transitional consequences.


b. The appeal is also to make it plain to everyone that I introduced my responses to this change only after having warned everyone concerned of their impact and the lack of an existing response to their possible consequence.


c. It confuses the concerned topic. When I say: “the IESG should have asked the IAB to explain it to everyone.", I am neither talking about Internationalization, nor of an IDNA2008 issue in particular, I am talking about:
i. the new fundamental architectural general qualities that the Internet technology is supposed to display in order to remain consistent with IDNA2008.
ii. The consequences of these new qualities in domains other than Internationalization.


==>> Point of Appeal

I can only repeat this boldly: IDNA2008 supports linguistic diversity. It does this by applying newly used Internet network principles that are necessary to support diversity as such: these underlying principles to support any diversity should be further studied, confirmed, and documented.


IESG: 3. Relations with Unicode

<IESG>

Mr. Morfin supports the approval of the IDNA2008 set of documents. In a recent email message, Mr. Morfin confirmed this position by saying, "IDNA2008 is, firstly, an improvement in clarifying the relation between Unicode and the Internet."

</IESG>


I certainly claim that this split is a major improvement. However, this was not a published direct target of the Charter. This statement in an IESG official response tends to make it an IETF position.

I am certainly happy about it. However, this is (I believe) the kind of statement that the IESG should clarify in a disclaimer or leave users to confirm in discussing the "Mapping" principles. This would have clarified the current proposition of a WG/NEWPREP Charter as partly an IDNA2008 follow-up. For this reason, I am uncertain about the meaning and intent of their proposed charter (cf. the last part of my I_D http://tools.ietf.org/html/draft-iucg-afra-reports-00).

As a result, the IESG response seems even more confusing because of its initial lack of a disclaimer. At this stage, I do not know,

  • if the IESG approves or not of my reading of IDNA2008
  • as far as it helps clarifying the relations between the Unicode consortium and the Internet community,
  • in general or in this specific case only; and what are the consequences of this clarification in other similar cases?

I also would like to emphasize that my mother tongue is the French language and that there may be subtleties that I do not grasp. This is important because the WG/IDNABIS consensus is only limited by some disagreements from Unicode consortium leaders or due to limitations of the Unicode strategy in supporting orthotypography and the related metadata (IDNA2008 does NOT support the French orthotypography at application level, because Unicode is using upper cases to visually support Latin majuscules).

Basically, it seems to result from IDNA that in the User interface case:

  • Unicode covers the entire typography area. Its job is to take care of every possible character.
  • IDNA should permit the support of linguistic orthotypography to correctly carry the semantic intent of registrants. In every language.
  • The IETF or IETF Users should propose a network oriented multiscriptural, multilingual, non-confusable, universal sign table that permits the prevention of homographic problems in a universal manner. For example, the sign "6" and Cyrillic "b" being graphically considered as the same in a universal visual indexing. For example: Brazil and Bulgaria alphacodes in ASCII and Cyrillic. This should be coordinated by the ISO3166/MA.


==>> Point of Appeal

IDNA2008 uses IDNA2008 character tables and bases on them its understanding of mapping. As a result, the IDNA2003 nameprep was removed. The Internet consistency rule (cf. RFC 1958.3.2) leads one to think that these tables should be used as a common basis for all the Internet similar cases. Is this an area for "work" or an area for "research"?


IESG: 4. IESG should have called upon IAB

<IESG>

Mr. Morfin also wants the IAB, not the IESG, to issue an architectural statement. In a recent email message, Mr. Morfin confirmed this position by saying, "IESG should have asked IAB to explain it to everyone."

</IESG>


RFC 2026 states that "If (a) the IESG recommends that the document be brought within the IETF and progressed within the IETF context, but the author declines to do so, or (b) the IESG considers that the document proposes something that conflicts with, or is actually inimical to, an established IETF effort, the document may still be published as an Experimental or Informational RFC. In these cases, however, the IESG may insert appropriate "disclaimer" text into the RFC either in or immediately following the "Status of this Memo" section in order to make the circumstances of its publication clear to readers."

This is not exactly the case of the IDNA2008 document set. However, the IDNA2008 document set deals with an architectural situation that is described as "unusual" by the WG/IDNABIS consensual "Mapping" document that was proposed, for the reason above, as informational. The IESG refused to consider it (AD killed the text). This definitely means that some conflict does exist between the positions of the WG (author) and the position of the IESG.

We are also in an additional situation where the IAB and the AD have raised objections to the very architecture that is retained by the Charter that was approved by the IESG (IDN in Application). These objections may boil down to this: the same IDN, IRI, or URL U-label may resolve differently, depending on the application, even on the same user machine. This matter seems to belong to the application area on the user side. We are again in the gray area that was undocumented by the IESG when not approving the "Mapping" document.

Note:

Could an explanation simply be that there is a conflict between the Charter and the IESG after the IAB I_D and WG/IDNABIS contribution? To make IDNA possible, one had to extend the Internet architecture with still unused concepts and to kill the IDNA concept as used in IDNA2003. This may most probably be the conclusion of the IAB I_D. This is a normal consequence of IDNA2008: the WG has exemplified principles that IAB was to document, and that Lead Users are begging to be acknowledged, based on their experience.


==>> Point of Appeal

RFC 2026 states that an IESG disclaimer may be inserted when there is a conflict between an author and the IESG. I understand that by similitude, when there is a conflict between the IESG the assigned Charter to a better understanding of the issue at hands, it belongs to the IAB to comment on in a disclaimer.


IESG: 5. IESG does not direct the work of the IAB

<IESG>

It should be clear that the IAB is studying Internationalization. The IETF 76 Technical Plenary was focused on this topic. An architectural statement on Internationalization in general or IDNA2008, in particular, will be published by the IAB if, and only if, the IAB chooses to do so. The IESG does not direct the work of the IAB and has no ambition to do so.

</IESG>


The RFC 3965 paradigm is that the IETF should influence those who design, use, and manage the Internet so that it works better, not along a technology that could be, but rather along a technology meeting the core values of the IETF (shared, decentralized, end to end, etc.). The disregarded "Mapping" document that permitted the WG consensus (Francophones could not have supported IDNA2008 otherwise) emphasizes the "unusual" architectural case of IDNA2008, having to standardize after the ends. I support that IDNA2008, because it is an "unusual" case has fundamentally changed and opened the IETF proposition.

Hopefully, the IESG and IAB are working hand in gloves when defining Charters, which means:

  • the issue at hand is not Internationalization (actually it would be "globalisation" vs. "globalization" to be exact).
  • IESG in approving IDNA2008 has already directed the future work of IAB because the 1983 and IDNA2008 Internets are two different things, even if the IDNA2008 Internet was entirely in the 1983 Internet. This will permit interoperability and transition.

Why is the IDNA2008 Internet different from the 1983 Internet?

There are many reasons why. I will pick one. In the OSI model, linguistic support belongs to the presentation layer.

The main IDNA2008 documents are authored by someone who documented that he adheres to this point of view. However, the Internet has no documented support of a presentation layer. This means that, if the WG/IDNABIS reached a consensus, it actually uses and documents the support of the presentation layer. This is actually the case: IDNs are supported by the "xn" Internet presentation.

This has two consequences:

  • the definition, documentation, and organization of the presentation layer are necessary before we can solidly proceed.
  • IDNA is not an addition to a user application but rather the implementation of a network-wide layer. IDNinA is, therefore, an incorrect concept, since a network layer SHOULD be uniformly supported network wide. IDNApplication is a possible response; there may be others.

I will now point out a more general example of the two Internets paradigmatic difference in considering the three strata that one may observe in communications: physical, content, and semiotics, and each of their two main substrata:

  • physical telecommunications:
1.1. signal
1.2. data
  • logical datacommunications:
2.1. passive content
2.2. ambient and active content
  • semiotical metacommunications:
3.1. brain: inter-semantics
3.2. mind: inter-comprehension.

The IESG's response considers Internationalization as the "linguistic diversity"'s linguistic support. This still favors a special relation with the Unicode typographic area that the WG/IDNABIS Charter meant to remove its dependence on.

IDNA2008 considers the "linguistic diversity"'s diversity support, even if it still remotely uses Unicode/IS0 10646 (use of the code points) there is no special relation with the Unicode consortium and members’ positions, nor with any linguistic particular. This means that users can stably look elsewhere for services that Unicode does not support, such as metadata for linguistic orthotypography, logos, compacted strings, etc. More generally IDNA will support in the same manner any application, encryption, etc. diversity. This is a big general progress.

In a more systematic manner, the architectural change can be analyzed as follows:

  • from 1.1. to 2.1.: network development is mainly achieved by capacity growth.
  • from 2.2. onwards: network development will be mainly achieved by intelligence multiplication.

In the specific case of the network of networks robustly dump and end to end Internet, intelligence is deported at its periphery (fringes). It, therefore, means that we have entered the area of the extended “edge to edge” network architecture in making a clear split between what the Internet is and what "unusual" means: the extended people’s networks of the network of networks.

This should be at least worth a disclaimer to avoid confusion in adapting the world digital ecosystem, as in FAST TRACK or NEWPREP. The "IDNA" system that users will get will be multiple (which certainly does not have to mean "messy"). The stringpreps diversity (including the IDN ones - plural of diversity) must be simplified and made interoperable.


==>> Point of Appeal

IDNA2008 uses a new architectural paradigm to address the support of the linguistic diversity (additional principles, distributed part of the network, smart peripheral interface, metacontent for metaprocesses, etc.). In being new, this paradigm differs from the RFC 3965 IETF paradigm. However, in approving IDNA2008, the IESG has endorsed that new paradigm, and in not approving the "Mapping", it has confused the meaning of this approval.

The IESG has not mentioned the change of paradigm. It has not documented why it does not permit the community to become aware of this change and debate or experiment if the old and the new paradigms are interoperable and how they should be integrated/transitioned.


IESG: 6. No remedial action suggested

<IESG>

The appeal does not suggest remedial action by the IESG, and in finding no appropriate action, the appeal is rejected.

</IESG>


The IESG response states that the appeal does not suggest remedial action by the IESG, and this is why, by the finding of no appropriate action, the appeal has been rejected.

Actually, the IESG has actually initiated (but not completed) four actions:

  • In rejecting the appeal: they permitted me to bring the appeal to the IAB level where it eventually belongs.
  • In advising a BOF, they suggest an IETF approach that I could support, should the IAB (1) decide that the user-centricity and IUI (Internet Use Interface) belong to the IETF scope and (2) suggest a proper IETF area to address user side architecture issues.
  • In advising me to publish a Draft, they have in a way asked me to publish the missing IAB disclaimer. I prefer to follow the procedure and leave the IAB to decide first as to what is the best strategy to document, in what I consider as a new Internet architectural paradigm.
  • In advising a BOF, they advise a consensual work on these issues. This is also a good thing, even if after ten years it might be too slow to prevent the consequences of the users’ current impatience, now the principles of the responses that they needed have been definitely unleashed.


==>> Point of Appeal

If we do not want the appeal procedure to become the only and usual way for me and Internet Users to object harm we may be done or to call for IAB guidance, it could be of use to institutionalize a review process mechanism, a disclaimer attachment ability, or a "user comment" section in RFCs. Working on this would seem to be a part of the IESG duty of precaution and the respect of the spirit of RFC 5434 (to pay real pre and post attention to what users have to say).


IESG: 7. To consider a BOF

<IESG>

The IESG observes that the appeal includes a plea for the Internet community to initiate some work. To this end, Mr. Morfin should consider submitting an Internet-Draft and then approaching an appropriate Area Director to sponsor a BOF Session or sponsor publication of the document. Please review RFC 5434, Considerations for Having a Successful Birds-of-a-Feather (BOF) Session, for assistance on initiating work in the IETF.

</IESG>


As documented in my appeal, the work suggested has already been engaged in a form that is adequate from my Internet User point of view:

  • a permanent IETF list (iucg@ietf.org) has been set-up to permit Internet Users to contribute to the IETF work, even while a very few of them can:
  • because they are more active persons than speculative IETF engineers,
  • because they are interested in an Internet that works precisely as they need it in their own trade, rather than “better” in general,
  • because they are not paid for that but they are in fact paying with their time (and sometimes their own money to get help for introducing contributions in readable English, sites, calls)
  • etc.
  • this list has already engaged work on the matter and has led to the creation of a specialized sub-list (workon@idna2010.org) where around 40 people are waiting for IESG to clarify their position and, therefore, for IAB guidance. Their first delayed ambition is to discuss their own roadmap.


These participants have three main problems:

  • my Projet.FRA report listed the practical problems that they face. They thought IDNA2008 permitted them to address their needs in full interoperability. They need an IAB confirmation.
  • they know that there will be an extensive problem of adminance (DNS root transition, IDv6 management, Classes and Presentations administration, etc.) that will have to be addressed in spite of what they perceive as a dangerous (for all) procrastination of the "ISOCANN enhanced cooperation" . Up to now, they have tried in vain to wake it up.
  • where and who is to document the user side architecture and standards? Is it at the IETF or not? If it is under the IETF umbrella, which area is to be picked or created in the IETF, since every area is concerned, and since what is to be documented and standardized does seat outside the IETF part of the Internet?


In order to help understand this complex issue, I will quote and comment on the RFC 5434 list of BOF goals, which are:

  • there is a problem that needs solving, and the IETF is the right group to attempt solving it.
    I just do not know. I/we have Internet Users' unsatisfied needs and we believe we have a solution to address them, which should now be interoperable with the "RFC1958/RFC3439/IDNA2008" Internet the way we contributed to the IDNA2008 work. We are interested in guidance, help, and better propositions.
  • there is a critical mass of participants willing to work on the problem (e.g., write drafts, review drafts, etc.).
    We do not have such a mass. However, we are working on an open source practical solution and we can report our findings, experimentation, etc. This may help in raising that mass. However, we will run pure "intertesting", i.e. we will use the Internet as a test-bed, as we did for the "dot-root" open community DNS test-bed along the ICANN ICP-3 rules some years ago. There is no possibility to control its possible expansion. We can certainly try to work in common with whoever would like an "intertest" charter to reduce the risks of mutual confusion or pollution. I am in particular concerned by the transition to the Virtual root matrix when ICANN has built so much over its defaulting approach.
  • ‘’The scope of the problem is well defined and understood, that is, people generally understand what the WG will work on (and what it won't) and what its actual deliverables will be.
    The scope of the problem is rather generally defined as:
  • what we think that we should have for a long time to support our trades, relations, operations, etc.
  • what the next major technology steps towards mind to mind intercomprehension facilitation will need. At this stage, we think that we have identified features like: orthotypography, global scope sub-addressing, ambient and active contents (contextual information and delivery of the content that the sender demanded to generate) support, ONES (open network edge systems - networked OPES), metadata registries integration, a universal network sign code, etc.
  • there is agreement that the specific deliverables (i.e., proposed documents) are the right set.
    This is not the case: we know that we need answers and stable IETF deliverables that we can act and build upon. We have an architectural framework that we are going to test first and then document, unless the IAB position and documents dissuade us from the idea that it is a correct approach.

    At our level, for example, we do not need RFCs; we need updated complete manual, probably as a wiki with an adequate "create a Book" ability.
  • it is believed that the WG has a reasonable probability of having success (i.e., in completing the deliverables in its charter in a timely fashion).
    We are quite certain that a WG is not - for us - a solution that we can participate in very much. That is mostly the case because we are not sponsored IETF engineers and we cannot wait another ten years.

    On another hand, WG/IDNABIS shown that Internet Users can contribute and help reaching a satisfactory for all consensus.


==>> Point of Appeal

We need the IAB to give the Internet technical community the necessary guidance to answer our needs or to help us in addressing them, in confirming that IDNA2008 necessitates works:

  • on the userside (IDNA2010)
  • and from an administrative network/userside framework (IDNA2012).

This work will probably result in experimentations and in several coordinated BOF by those who are competent in leading the IETF and who have the necessary budget to sustain them.


My understanding of IDNA2008

In case this appeal is disregarded, I will understand thereby that the IAB does not object to the following understandings of IDNA2008:

  • IDNA2008 supports the linguistic diversity of IDNs in a way that is completely coherent with the Internet architecture as defined by RFC 1958 and 3439 and, therefore, serves as an example of reference (paradigm) for the support of every other diversity in Internet use.
  • it does not directly do it in addressing architectural points such as those raised by the IAD current draft on IDNs, by the Application AD after the IETF/LC, and by Francophones and other non-English speakers concerning the lack of orthotypographical support that is necessary for any proper semantic referencing.
  • it does it in permitting to address the "unusual" (cf. consensual WG/IDNABIS Mapping document) need to discuss "off-the-rope" protocols (to be delegated to an undefined Usage), providing an illustration of the way the Internet architecture supports that kind of architectural need.


  • this means that one can now read RFC 1958/3439-IDNA2008 as an Internet architectural culture that can be simplified along the following systemic:
a. as every system, the Internet implies:
  • an endotem: legacy Internet, i.e. protocols on the system ropes as documented by the IETF
  • a peritem: Internet Use Interface, i.e. protocols off the system ropes to be documented with users
  • an exotem: every possible usage of the Internet.
b. these three areas correspond to the three maximum strength requirements in the specification areas that are defined in RFC 2119:
  • MUST for the endotem,
  • SHOULD for the peritem,
  • MAY for the exotem.
c. In reference to the RFC 3439 principle of simplicity, it is understood that the Internet:
  • usage growth is to be supported by the endotem increase of its capacities managed by its adminance (administration, maintenance, operations, and specifications)
  • usage diversity is to be supported by the peritem multiplication of its facilities managed by its adminance but also controlled by its governance (usage politics).
  • network development results from the technological support that is brought to the governance and adminance, especially in new areas.
  • network specialization is supported through the topological organization of shared resources in using classes and presentations (externets)



d. IDNA2008 documents the endotem capacity to support Internet Domain Names (IDN) presented:
  • directly by the Internet exotem made of users and users applications,
  • once facilitated on, and by, the Internet Use Interface (IUI) of its peritem. This facilitation may include the transparent support of:
  • non-Internet endotem supported orthotypographic and users' idiotem needs
  • Multi-Layer DNS to support the various name spaces, stringpreps, and semantic addressing of the digital ecosystem
  • the Internet presentation layer
  • other user to user interapplication and security oriented services
  • uncoupled local sub-addressing with a global exposure (IDv6: the use side of the IPv6 under IPv6 or not)
  • Multilayer ML-DNS unique virtual root matrix and usage based netcentricity supported by a user located IDNApplication replacing the IDNinA concept.
  • extended services to ambient and active content.
e. IDNA2008 permit to uncouple the Internet multilinguistic system from the Unicode typographic system. It retains Unicode/ISO 10626 as a character set encoding. This leaves the need for an Internet character set (ICS) that can provide a phishing proof unique multilingual/multiscriptural sorting and indexing order in order to obtain a fool proof unique system for every naming and referencing registry.
Retrieved from "http://www.iucg.org/wiki/100606_-_JFCM_Appeal_to_the_IAB"
Personal tools