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

From: Barry Leiba <[email-masked]>
Date: Tue, 25 Jan 2011 21:15:44 -0500

This document was one we discussed at IETF 79 in Beijing, and the
chairs and ADs recommend that the appsawg working group adopt, review,
and discuss it.

The document deals with bringing IDNAbis (IDNA 2008) up to the Unicode
6.0 level.  At issue are three particular code points that have been
reclassified by Unicode 6.0.

While we discussed the document in Beijing, it has changed since then,
in that its recommendation is very different to the version that was
posted at the time.  This is the abstract from the -01 version, posted
in December:

   This document specifies IETF consensus related to and changes made to
   Unicode when version 6.0 was released on Oct 11 2011.  The consensus
   is that no update is needed to RFC 5892 based on the changes made in
   Unicode 6.0.

The appsawg chairs will be looking for objections to accepting this as
a working group document; please make such objections by 4 Feb.  In
any case, please review the document and comment on it.  We'd like to
see whether the applications area supports the consensus claim made in
the abstract above, or does not... so please post comments either way.

Barry, appsawg chair

---

From: Barry Leiba <[email-masked]>
Date: Tue, 25 Jan 2011 21:20:01 -0500

> chairs and ADs recommend that the appsawg working group adopt, review,

Sorry; I meant to include a link to the document:
http://tools.ietf.org/html/draft-faltstrom-5892bis

Barry

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 26 Jan 2011 16:11:07 +0900

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.

> the abstract above, or does not... so please post comments either way.

[in a later mail]

> Barry, appsawg chair
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: JFC Morfin <[email-masked]>
Date: Wed, 26 Jan 2011 17:57:22 +0100

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 [email-masked] 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:
>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.