Dear John,
If I supported the IDNA2008 consensus it was because it suited my
vision of the Internet architecture. This was a surprise. This meant
that it was possible to read as the two faces of the same coin
* the 2011 "inside Internet" that the IETF influences and documents.
IANA glossary, PRECIS propositions
* and the 2011 "outside Internet encapsulation" that we, its users,
want to intelligently utilize . ICANN/WG/VIP, IUCG.
Actually as the two sides of a smart interface that I call the IUI as:
* the Internet Use Interface on its Internet side.
* the Intelligent Use Interface on the User's side, because the IUI
can also interface the same user with other technologies that will
converge at the IUI.
As you know this vision of mine raised two main problems:(1) where to
document the IUI and (2) the need to experiment in order to correctly
document it.
----
1. My appeals to the IESG and IAB permitted the IETF to answer the
first question. The IESG proposed for me to run a BOF about what it
considered as research, but the IAB made it clear that the IETF was
concerned but that it was not in its bailiwick.
My evaluation is that the IUI is an "IUser"
(Internet/Intelligent/independent, etc. user) community issue. This
community of identified users, should be liaised with the IETF. I use
the IUCG for that and the help/support/ideas of its small team.
----
2. The particular IUI architecture that I investigate is in line with
the architecture that I use, support, and have deployed for more than
thirty years.
2.1. It is based on my extended systems understanding of:
* the way systems, diversity, complexity, and simplicity are
articulated (much in tune with the three basic principles of the
Internet architecture: constant change (RFC 1958), simplicity (RFC
3439), and subsidiarity (as this results from the IDNA2008
architecture, once addressed the architecturally wrong location of
IDNA in applications instead of at the IUI).
* the particular case of communications where transmitted contents
use static metadata in telecoms, metadata contained in the packet in
datacommunications like the Internet, and separated metadata in what
I call the metacommunications. IDNA2008 the way it implements the
presentation layer in the Internet is at the border with metacoms.
2.2. From experience (Tymnet Extended Services), I think the location
of the metacoms support is to be on the user side so that it is
transparent to the network use. This is the Internet PLUS
architecture, i.e. plugged additional OSEX layers (Extended OSI) on
the user side. This layers can also be faked in a centralized manner,
and result in the "+" approach: e.g. Google+.
2.3. The way IDNA2008 is designed calls for two necessary moves:
* to use the DNS to deliver network oriented metadata, hence by
synergy in order to, most probably, probably use DDDS registries for
intersem (semantic internet layers above) referent data management
and an IPv6 like registry addressing. In any case JTC1/SG32/WG2 is to
be carefully considered and I miss the time for that.
* a total separation from the Unicode typography that is not able to
easily cope with network use requirements and to support human
oriented algorithms. This separation does not need to be repudiation.
However, the Internet MUST be supported by a network/human oriented
universal semiotic system. I think it can start with a graphic
(passive) and then a dynamic sign oriented approach in CLASS 0, as a
common safe support of the other classes above, including the IN class.
-----
3. The danger of what we found and in such architecture is that it
actually is the Internet technology architecture. There is not a
single change in the existing RFCs or in a single bit in the existing
protocols that is needed. However, there are a lot of opportunities
for adjustments and, at the same time, there is major pressure being
imposed on the whole architecture and on in particular on the ML-DNS
(i.e. an IDNA2008 compliant encapsulation of the DNS). This pressure
is the gTLD project of ICANN with its gTLD fee and delays. This may
lead to a lot of individual architectural "tunings" to evade ICANN or
to protect ICANN; in addition to these "adjustments", such as PRECIS.
-----
4. My first idea was to use the notoriety of ICANN's plans and Google
Public DNS to experiment IDNA2008 compliant free gTLDs (like
Projet.FRA). Then to proceed from there on, before anyone could try
to make a business of it. A quick and dirty move to force everyone to
understand where we are, how weak the Internet is IRT the market and
sponsors, make people integrate diversity into their network thinking
process. For personal reasons you know I was not able to dedicate
myself to this. At the same time, I did better explore as to what the
very initial visions of the Internet actually brought. Not only the
"networking group", but others too.
There is a solution I wish to try to revive, if possible in parallel
(partial code integration). However, if that solution has been
disregarded it is probably because of the complication that the IETF
has reached. So the priority for me is to clarify and simplify the
model. You already did a lot with IDNA2008, but it is not enough as
we stayed (Charter) within the IDNA concept. We have to come back to
fundamentals.
The Internet MUST be considered from the outside as a unique and
simple system (service black box) that is able to support several,
and more or less equivalent architectures, on the user side. I agree
with John Day: we miss an Internet OS. To implement it calls for a
clearer and coherent technical culture. The internet tomography is
still to be done.
The earthquake is the RFC 5895. It is from there that we need to
proceed. In two directions:
4.1. to think, accommodate, test, and deploy a simpler, clearer, etc.
Internet of today, i.e. multilingual and semiotic ready (support of
passive [as today] but also active and localized content).
4.2. to make sure that the "patches" being discussed in parallel do
not conflict and block that innovation.
My understanding (bet?) is that, as usual, the single point of
simplicity to obtain this is for everyone to use the same language
and for the concepts underlying that that language to be open enough
so they permit to clearly spell out the "post IDNA2008 possible".
This is why I engaged the IUCG to compile all the data, ideas,
demands, confusion, etc. on multilingualization (i.e. architectural
linguistic neutrality) that are discussed. We are probably still
missing many things currently, but we have compiled 73 dense pages.
----
Your misunderstanding about the way we use wikis (as a quickly
visible to all mailing archives, that can be translated in the
MindMap), has led me to work this afternoon for you. And to build the
next step. This still is NOT a document; this is only a next phase
IUse community working wiki, located at
<http://iucg.org/wiki/Multilingualization_Glossary>http://iucg.org/wiki/Multilingualization_Glossary.
This is rough stuff. My intent is to digest it through a clear
network ontology and model (ontography) and tune it until its
coherent with what the Internet IS and what our IUI MUST be. So that
it can become a reference glossary.
Obviously, there will be parts that do not belong to the IETF area,
but to the IUTF area (the emerging IUse technical TF). That is
because of our IUse center of the world is not your IETF/Unicode
center of the world. However, we need our common world to entually be
unique even if all this takes time to think, adjust; set-up. This is
why I am making the place of that work visible to well-intentioned
people and why I give my deep thanks to those who help.
jfc
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
