<html>
<body>
<br>
Dear Barry,<br><br>
Thie
<a href="http://tools.ietf.org/html/draft-faltstrom-5892bis" eudora="autourl">
http://tools.ietf.org/html/draft-faltstrom-5892bis</a> 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
<a href="http://incsa.org/">http://incsa.org</a> (heavy but eventually
necessary) project in the IUse community technical area.<br><br>
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.<br><br>
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.<br><br>
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.<br><br>
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. <br><br>
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.<br><br>
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. <br><br>
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).<br><br>
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".<br><br>
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. <br><br>
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.<br><br>
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. <br><br>
Best,<br>
jfc<br><br>
<br>
At 08:11 26/01/2011, Martin J. Dürst wrote:<br>
<blockquote type=cite class=cite cite="">Hello Barry,<br><br>
[cc (former) IDNA WG mailing list]<br><br>
The current -01 draft of this document was reviewed and discussed
extensively on the (former) IDNA WG mailing list last December<br>
(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.<br><br>
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.<br><br>
Regards, Martin.</blockquote><br>
</body>
</html>