Re: [apps-discuss] For consideration as an appsawg document: draft-faltstrom-5892bis

JFC Morfin <> Wed, 26 January 2011 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (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
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-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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 82PeCo-qenLi; Wed, 26 Jan 2011 08:54:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id ACC323A6826; Wed, 26 Jan 2011 08:54:20 -0800 (PST)
Received: from ([]:49182 by with esmtpa (Exim 4.69) (envelope-from <>) id 1Pi8gD-0004Fy-AL; Wed, 26 Jan 2011 08:57:14 -0800
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 26 Jan 2011 17:57:22 +0100
To: "Martin J. D�rst" <>, Barry Leiba <>
From: JFC Morfin <>
In-Reply-To: <>
References: <> <>
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Cc:, "" <>,,,
Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-faltstrom-5892bis
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Jan 2011 16:54:23 -0000

Dear Barry,

Thie 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 
<> (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 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 

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.


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