<html>
<body>
Dear <a name="OLE_LINK3"></a>John,<br><br>
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<br>
* the 2011 "<b>inside Internet</b>" that the IETF influences
and documents. IANA glossary, PRECIS propositions <br>
* and the 2011 "<b>outside Internet encapsulation</b>" that we,
its users, want to intelligently utilize . ICANN/WG/VIP, IUCG.<br><br>
Actually as the two sides of a smart interface that I call the <b>IUI</b>
as:<br>
* the Internet Use Interface on its Internet side.<br>
* 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.<br><br>
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.<br><br>
----<br><br>
1. <b>My appeals to the IESG and IAB permitted the IETF to answer the
first question</b>. 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. <br><br>
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.<br><br>
----<br><br>
2. The particular<b> IUI architecture</b> that I investigate is in line
with the architecture that I use, support, and have deployed for more
than thirty years. <br><br>
2.1. It is based on my <b>extended systems</b> understanding of:<br><br>
*  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). <br><br>
* 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.<br><br>
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+. <br><br>
2.3. The way IDNA2008 is designed calls for two necessary moves:
<br><br>
* <b>to use the DNS to deliver network oriented metadata</b>, 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.<br><br>
* <b>a total separation from the Unicode typography </b>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.<br><br>
-----<br><br>
3. The danger of what we found and in such architecture is that <b>it
actually is the Internet technology architecture</b>. 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.<br><br>
-----<br><br>
4. My first idea was to use the notoriety of ICANN's plans and Google
Public DNS to <b>experiment</b><a name="OLE_LINK3"></a>  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.<br><br>
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.<br><br>
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.<br><br>
The earthquake is the RFC 5895. It is from there that we need to proceed.
In two directions:<br><br>
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).<br><br>
4.2. to make sure that the "patches" being discussed in
parallel do not conflict and block that innovation.<br><br>
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".<br><br>
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.<br><br>
----<br><br>
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
<a href="http://iucg.org/wiki/Multilingualization_Glossary">
http://iucg.org/wiki/Multilingualization_Glossary</a>. 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.
<br><br>
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.<br><br>
jfc</body>
</html>