referencing IDNA2008 (and IDNA2003?)

[J-F C. Morfin]

At 04:18 24/10/2010, jean-michel bernier de portzamparc wrote:
>JFC, Adam,
>This is something that Adam may easily understand: there are now two 
>ways of reading all the RFCs. One is like IDNA2003 (diversity is 
>loosely handled inside the IETF technology) and one is IDNA2008 
>(diversity is handled outside the IETF technology in using it in a 
>very strict, IETF decided common way). These two ways consider the 
>_same_ Internet (not a single bit being changed in the code) in a 
>very _different_ manner. If we used the same language, it would mean 
>that we would use the same terms in a rather different or even 
>opposite way. We would definitely not understand one another any more
.
Dear Jean-Michel,

I took my time before commenting on this, so that people may feel 
more relaxed about the matter. You are correct. On one side there is 
the IETF building the Internet in "influencing those who design, use, 
and manage it for the Internet to work better". On the other side 
there is at least our French Users' Diktyology effort (diktyology is 
the name of the network science) :-) that tries to understand what 
the Internet really is, so that its users can better benefit from the 
way it is designed, used and managed.

However, please remember that this is the IETF side. The IETF comes 
from RFC 1958 through RFC 3439 and progressively up to the RFC 
5890/5895 set. On our own side, we are coming from our need for much 
more than IDNA2008 (the Intersem, the internet of thoughts) and we 
consider that their support by the Internet architecture is implied 
in RFC 1958 and 3439 unless some   unfortunate errors woluld be made. 
However, we may be wrong in our own analysis, which is why, even if 
the IETF has eventually accepted to match some of our requirements, 
they may not accept others. Their job is to make sure that they could 
or could not be accepted based upon what they think their Internet 
technology is and should be.

Please also remember that RFC 3935 states: "The Internet isn't 
value-neutral, and neither is the IETF.  We want the Internet to be 
useful for communities that share our commitment to openness and 
fairness. We embrace technical concepts such as decentralized 
control, edge-user empowerment, and sharing of resources because 
those concepts resonate with the core values of the IETF community. 
These concepts have little to do with the technology that's possible, 
and much to do with the technology that we choose to create."

Our Internet use is not value-neutral either. However, our values are 
those consensually voted on by the users' communities (governments, 
industry, civil society, etc.) of the world at the WSIS (World Summit 
on Information Society) that they ignore because they refused to 
attend (by IETF Chair's clear policy).  Our values also includes the 
respect of the users' pragmatism, authority and liberty like the 
".su" (and many, many others) use of IDNA2008 or French majuscules, 
and many other cases they cannot consider because they cannot fit 
into their architectural scheme. And this is why we need our own 
hacking but not breaking additional other scheme.

Beware: they do not really understand it, and what the ML-DNS can be; 
and they are as much afraid of it as we are from their vision of the 
user interface. The reason why is that we cannot technically dialog 
with them before we have completed its experimentation. This  is due 
to the ISOC copyrights and IAB/IESG. I tried to get an IETF use area 
investigated that could have been granted further on a public domain 
stream. IESG and IAB were not ready for that and may-be this is 
better. Therefore, we will have to set-up our own IUTF/IUSG, using 
the IUCG to liaise with the IETF under an ISOC copyright limited to 
the document presentation, but without any possible claim on the content.

This is not that bad: they still have, and we may share or help, 
their rough consensus, and we will rendezvous on running code.

In the meanwhile, what we can offer for clarification sake in my 
spare time is a public domain conceptual architectural framework 
(ALFA) for them to understand where we think the Internet fits and 
why we are not interested in IETF side's documented "MUST"s until 
they get being respected among the network side's "ARE (period.)"s. 
The same as our own "MUST"s need to get respected by them as their 
own external world "ARE (period.)". This is what I engaged (cf. the 
end of my IAB appeal) and am trying to advance in parallel to our 
live ML-DNs experimentation. .

Our only potential problem are the inconsistencies that IETF may 
document for mid-term reasons while we are interested in short-term 
(operations) and long-term (metastructures). We have such an 
inconsistency in the RFC 2826, a document that definitely needs to be 
expended. We could have had some in RFC 4646 and RFC 5890. We have 
two pending ones with the precautionary principle and the "intertest" 
charter (for securely using the Internet as its own test-bed), and 
may be could we reduce some of the Unicode/Internet through an NUCS 
(networked universal character set).

For everyone to feel at ease, everyone has to accept this parallel: 
the same as IETF does not want and cannot change telecom standards as 
established by the ITU,  IUsers do not want and cannot change the 
IETF standards, words, and definition. This is because the ITU 
standards are not only used by the Internet, and Internet Use words, 
definitions, and the coming standards do not only concern Internet 
users. This is that  uncoupling which permits each telecom, Internet, 
use, and coming semantic stratum to freely progress.

This is why the "I" in ITU, IETF, IUI and IUser, and Intersem 
successively stands for international, internet, intelligent, and 
individual. Today, we are crossing the architectural middle: the IUI 
network use interface. On the Internet side the "I" stands for 
"Internet" and for "Intelligent" on the user side, as in "good 
intelligence". This "good intelligence", i.e. good metanetworking is 
not necessarily easy to get (but has to be) adhered to - in the 
short-term user (operational) range, in the governance (policies) 
middle-term range, and in the adminance (normative) long-term range.

Look at our own changes since we started investigating the ML-DNS and 
the implications that we found regarding things that we never 
considered first. Let us first work, test, and check. Our only 
interest was (as in the RFC 5988 case that we need to check):

- that Adam's Cookies are documented as coherent with the DNS core 
coherence becoming definitive "ARE" we can trust.
- to save time, that they are not limited to HTTP,
- that their management/utilization rules are well defined but also 
open and simple enough so that they can be used for whatever they can 
deliver outside the Internet, and not only for what their Internet 
designers had in mind.

jfc