Re: [apps-discuss] For consideration as an appsawg document: draft-faltstrom-5892bis
JFC Morfin <jefsey@jefsey.com> Wed, 26 January 2011 16:54 UTC
Return-Path: <jefsey@jefsey.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81E33A681F; Wed, 26 Jan 2011 08:54:22 -0800 (PST)
X-Quarantine-ID: <82PeCo-qenLi>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char FC hex): To: "Martin J. D\374rst" <duerst@it[...]
X-Spam-Flag: NO
X-Spam-Score: -102.355
X-Spam-Level:
X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82PeCo-qenLi; Wed, 26 Jan 2011 08:54:20 -0800 (PST)
Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id ACC323A6826; Wed, 26 Jan 2011 08:54:20 -0800 (PST)
Received: from 53.39-225-89.dsl.completel.net ([89.225.39.53]:49182 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from <jefsey@jefsey.com>) id 1Pi8gD-0004Fy-AL; Wed, 26 Jan 2011 08:57:14 -0800
Message-Id: <7.0.1.0.2.20110126100411.05880f78@jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 26 Jan 2011 17:57:22 +0100
To: "Martin J. D�rst" <duerst@it.aoyama.ac.jp>, Barry Leiba <barryleiba@computer.org>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <4D3FC90B.3000205@it.aoyama.ac.jp>
References: <AANLkTi=dTc7vbCT5=Ph+m5oareisS133F2dRO3azz5wR@mail.gmail.com> <4D3FC90B.3000205@it.aoyama.ac.jp>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_1157263527==.ALT"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage2.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: info@incsa.org, "idna-update@alvestrand.no" <idna-update@alvestrand.no>, iucg@ietf.org, apps-discuss@ietf.org, iutf@iutf.org
Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-faltstrom-5892bis
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2011 16:54:23 -0000
Dear Barry, Thie http://tools.ietf.org/html/draft-faltstrom-5892bis draft proposes to reverse and publish an IETFconsensus in a one line sentence located in a security section. As you will understand it from the debate on the former WG/IDNABis mailing list, the agreement that Martin refers to was mostly found among the Unicode Members of this list, the proposed Draft restoring to a large extent the IETF dependence on Unicode that was severed by IDNA2008, as per its charter. The underlaying technical issue is not to be neglected, but Unicode is not the solution: even if it may simplify the engineering task, it has been denied by usage and this has resulted in IDNA2008. This question has led to the inclusion of the <http://incsa.org/>http://incsa.org (heavy but eventually necessary) project in the IUse community technical area. FYI, the IUse community is emerging from the introduction of the principle of subsidiarity in the Internet architecture by IDNA2008 (what the proposed I_D would repel) and is present within the IETF through a part of the Members of the iucg@ietf.org non-WG mailing list. Its IUTF (Intelligent Use Task Force) area was confirmed by the answers of the IESG and IAB to my appeals: IESG and IAB acknowledged the importance of this area (the IESG had partly qualified as research from my report and I_D, when approving IDNA2008) but did not agree and inform the IETF that it was something of specific importance within the IETF scope. Furthermore, in being people centered (cf. WSIS declarations), the IUTF area spans every technology, service, and use of the world digital ecosystem networks, and is not limited to the Internet. However, the IUse emerging community adheres to the Internet stratum architectural principles of permanent change as documented by RFC 1958, of simplicity as documented by RFC 3439, and subsidiarity as implied by RFC 5890 to 5895. These principles add to the IETF cardinal principles of Open process, Technical competence, Volunteer Core, Rough consensus and running code, and Protocol ownership as documented by RFC 3935. At this time, the IUse emerging community is discussing, for its own use, the cardinal principle of Multi-Consensus and living mode due to the topology of its IUI (Intelligent Use Interface) Internet encapsulating scope. We will also most probably add the principle of precaution of which the I_D was integrated in my IESG appeal. As the initial facilitator of the IUse community, my present health problems have created a delay for us in concerting our organization and relations with the IGF, @larges, Civil Society, consumers, and standardization bodies, which we hope to overcome before this summer. In addition, we have the exploration, development, and initial testing of the ML-DNS logic. I want to emphasize that the idea I initially explored with Lisa Dussault was to consider our concerns as matters belonging to the Application Area: the IUI concept, inherited from IDNA2008 and illustrated by RFC 5895, is only a milestone for me towards the Intersem stratum, the Semiotic Internet, and of the semantic facilitation services (Internet of thoughts). The borderline was difficult to determine. Initially, John Klensin provided a good definition: the separation between what belongs to scripts and what belongs to languages. However, this is inadequate because diversity is everywhere and not only in languages, and even in languages the separation is between orthotypography and meaning. In addition, a people centric approach, as is necessary in linguistic diversity (and as per the general international consensus), implies UIs with many technologies/services within many cultural/political contexts. The solution was, therefore, the IUI middle area being dedicated to the robust and stable Use of the Internet on the inner side, and to a modular Interfacing with the users' diversity on the outer side. This permits us to stay within what we call the "Internet PLUS" (plugged layers on the user side) content oriented domain, i.e. still outside of the semantic stratum. However, that fringe to fringe Internet Plus addition to the network hourglass, is where an Intelligent Internet experience (not network) can be provided (not imposed on) to users. To clarify this, we use my 25 year old terminology: ITU documents signal-based basic services, IETF documents passive content oriented value-added services, IUTF is to document active content extended services, and the step above will be semantic facilitation services. (N.B. active content is when the received content is designedly not equal to the sent content; facilitation's purpose is brain to brain intercomprehension). Fringe to fringe, active content extended services are obviously for interoperating with layer seven applications. The same, it will have to interoperate with the above layers on the user side. This points us towards a new principle that we need now to fully understand and document, which is uncoupling. This results from the fact that introducing the IUI does not call for a single bit level change in the Internet technology, nor a single coma in RFCs. It only results from a different reading of the RFCs: instead of reading them as documenting a single global decentralized or possibly decentralized system, we read them as documenting the _uncoupled_ parts of an intricate network. We use a proper (distributed relational spaces) and figuratively (virtual topology) image: "the networks of the network of networks". This is why the "IETF consensus is that it is important IDNA standard is aligned with the Unicode Standard" is in definite, clear opposition with the above. Unicode covers the typographic area, the IETF the networking area, and IDNA2008 documents the way the networking area handles orthotypography. Unicode provides codes to ISO 10646 that multiple (including non-Internet) digital technologies - that are also used by Internet users - use to support the users' orthotypographies, while there is a major operating non-resolved issue, which is the impact of homography. This is why we need to protect the IDNA2008 consensus we found. This implies that your sentence would be appealed. We are at the beginning of a running code and a live testing effort based upon the IDNA2008 consensus. It probably represents a tremendous power growth capacity for the Internet (by what is called "multiplication by division"), and we cannot permit it to be confused, nor that people start building astray upon that confusion at this rather young stage. The BCP009 process must apply when documenting an "IETF consensus". This consensus must really be an IETF consensus, with an open debate, IAB guidance (IDNA specifics, and there are others on their agenda), Last Call, IESG decision, and Internet Users community support. This is not the case, at least yet. You realize that I would be the appellant: I am not sure that I can handle the workload, and I am not sure that the workload would really help the IETF because this is a point that was already addressed in a WG charter, correctly open in RFC 5892 and that should be consensually accepted by the regular IETF and IAB work on the matter, along with IUTF testing and Internet Community (users, manufacturers, operators, TLD managers) practical decisions within the coming two years. There is nothing to say more, except Patrick or someone else find sometimes that RFC 5892 turns incorrect or if someone explore, document and propose a compatible alternative to Unicode that would better fit the people's needs in a network environment which certainly differs from a typesetter workshop. Best, jfc At 08:11 26/01/2011, Martin J. Dürst wrote: >Hello Barry, > >[cc (former) IDNA WG mailing list] > >The current -01 draft of this document was reviewed and discussed >extensively on the (former) IDNA WG mailing list last December >(see >http://www.alvestrand.no/pipermail/idna-update/2010-December/thread.html). >In my understanding, there was quite some agreement on what needed >to be fixed, and these fixes were mostly editorial, although some of >them on a very hight level. > >I have nothing against making that draft a working item of the Apps >WG (hopefully being done with it very quickly, because it has >already been discussed extensively on the IDNA list), but I'd prefer >to do this in a way that avoids having to send in the same comments >twice. My preference would be to have the authors integrate the >comments from the IDNA list and then take the draft up here, because >I think it will make it easier for reviewers here to review the draft. > >Regards, Martin.
- [apps-discuss] For consideration as an appsawg do… Barry Leiba
- Re: [apps-discuss] For consideration as an appsaw… Barry Leiba
- Re: [apps-discuss] For consideration as an appsaw… Martin J. Dürst
- Re: [apps-discuss] For consideration as an appsaw… JFC Morfin