[apps-discuss] For consideration as an appsawg document: draft-faltstrom-5892bis
jefsey at jefsey.com
Wed Jan 26 17:57:22 CET 2011
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 at 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
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:
>[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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Idna-update