<html>
<body>
At 18:31 24/02/2011, John C Klensin wrote:<br>
<blockquote type=cite class=cite cite="">--On Thursday, February 24, 2011
09:31 -0500 Lyman Chapin<br>
<lyman@interisle.net> wrote:<br><br>
> Simon,<br>
> <br>
> I think that many of us expect the case-folding behavior of<br>
> IDNA2003 to be preserved by applications (esp. web browsers)<br>
> at least during the transition to IDNA2008 (e.g., following<br>
> UTS #46,
<a href="http://unicode.org/reports/tr46" eudora="autourl">
http://unicode.org/reports/tr46</a>).<br><br>
And some of us believe that the recommendation of RFC 5895,<br>
which include mapping to lower case (see its Section 2, item 1),<br>
are more appropriate than UTS #46. </blockquote><br>
Let me clarify this also from an IUser point of view, as we initially and
determinedly oppose case-folding. (NB. An IUser is a member of the IUse
emerging community who is interested in the people centric convergent use
of the Internet along with the other (smart or not) available bandwidths
from the world digital ecosystem).<br><br>
1. We accepted John Klensin's proposition<br><br>
During the WG/IDNABis work, we were able to identify that IDNA2008
casefolding, as and where proposed by John Klensin, permitted a clear and
stable response for the Internet bandwidth that we could typically
interface with our own ML-DNS (multi-naming-layer
language/technology/context independent) concept. Such an ML-DNS, as we
explore and work on it, could be documented as another RFC 5895-like
example on the user side of the network side IDNA2008.<br><br>
2. The WG did not care about French<br><br>
This ML-DNS of us addresses our "Projet.FRA"
(<a href="http://a-fra.org/" eudora="autourl">http://a-fra.org</a>) needs
for a Francophone open ontology using its name space as an ontology and a
semantic network, which I reported to the IESG Last Call.
<a href="http://tools.ietf.org/id/draft-iucg-afra-reports-00.txt">
http://tools.ietf.org/id/draft-iucg-afra-reports-00.txt</a>.<br><br>
2.1. we reported it to IESG/LC<br><br>
It emphasizes that IDNA2008 does not support French majuscules (first
letter in a phrase or in an important word) that Unicode does _not_
support either, except as uppercases and, therefore, our obligation to
build a solution on top of IDNA2008. This is because Unicode tables
document a mechanical typography, and registrants need to have their
orthotypography rules (and not tables) supported (orthotypography is the
syntax of the way one writes a language - something that is out of the
IDNA2008 and Unicode scope). French language speakers unwaveringly demand
such a support as well as the other Latin language speakers. To explain:
"Etat" means "State/Government," état" means
"status", etc.<br><br>
That situation calls for:<br><br>
1. a mapping of everything to lowercase so that everything is stable,
clear, and secure. <br>
2. us to add the majuscule information as a metadata that we investigated
in
<a href="http://tools.ietf.org/id/draft-iucg-punyplus-03.txt">
http://tools.ietf.org/id/draft-iucg-punyplus-03.txt</a>. <br><br>
2.2. our position is qualified as "research"<br><br>
The IESG considered our position and our plea for a quick validation of
the IDNA2008 consensual document set (so that we would know the rock to
build upon). IESG also considered our proposition as
"research". Since we have other topics for semantic research on
this project, we are considering different choices with members of the
MAAYA network (linguistic diversity) and will introduce ".fra"
(along with other projects we call "xTLD"s, i.e. experimental
TLDs, once ICANN finishes its gTLD rigmarole, in order to avoid any
unnecessary naming conflicts). We will first document a charter on the
way to use the Internet as its own test bed through an RFC for
information on "intertesting" in gathering different ICANN and
IETF requirements.<br><br>
3. Strength of IDNA2008 and IDNA is weakness<br><br>
Another reason why we pleaded for IDNA2008 to be quickly accepted was
that the AD (once we had completed the WG/LC and IETF/LC) started to
question, and rightly so, the IDNA principle itself. As RFC 6055 partly
also does: will different applications present the same A-label to the
DNS? Our ML-DNS vision addresses that concern because it extends the DNS
and, therefore, utilizes a single Internet DNS Use Interface with
unchanged applications that are transparent to the U-label actually
entered by the Users. <br><br>
3.1. The presentation layer.<br><br>
This is the role of the presentation layer. "The Presentation Layer
is responsible for the delivery and formatting of information to the
application layer for further processing or display." The
Internet presentation layer was virtual. It was introduced by i-DNS and
by IDNA2003 in using the "xx--" ACE prefixes. Yet the idea to
dedicate it to the sole linguistic names at user application layer (i.e.
outside of the network area) was only a patch that the ML-DNS (i.e. on
top of the DNS in the network area) corrects. Applications like browsers
have nothing to do with domain name massaging, we just want them to pass
our entries to the domain name management systems (plural, as we may or
not be using the Internet or the Internet technology, and the DNS or
not).<br><br>
3.2. the IUI<br><br>
However, this introduces the notion of a fringe IUI (Internet Use
Interface) that faces no problem in becoming an "Intelligent Use
Interface" with multiple technologies, and to consider an IUDNS
(intelligent use domain name space) of which the Internet domain space is
a small yet open part, of which the class IN is 1/65,000-th and of which
the ICANN root space is a tiny commercial chunk.<b> <br><br>
</b>4. Technical vs. technico-commercial disagreement<br><br>
IAB RFC 3869 explains as to why the commercial reasons of applications
developers, who are also service providers, such as Microsoft and Google,
and their Unicode consortium, may lead some of their employees to
plea/lobby against common technical interest, for an internet that pays
better rather than works better. The same, paying services or immaterial
goods merchants may prefer a client/server architecture tying users to
their proprietary offer (such as Apple etc., which is another Unicode
consortium leading member).<br><br>
However, some IETF leaders and smart Google people have now swallowed and
are digesting the optional change introduced by IDNA2008 with:<br>
- the "inside" Internet<br>
- encapsulated into an uncoupled peripheral extended (intelligent)
services "IUI" (Internet Use Interface), interfacing the user
universe, <br>
- itself accessing and operating the Internet and other systems of the
world digital ecosystem though their own "IUI" (Intelligent Use
Interface). <br><br>
5. A strictly conformant architectural enhancement<br><br>
This change totally conforms with the Internet architectural
principles:<br><br>
5.1. RFC 1958 principle of constant change: the change is dramatic but
does not require a single bit change in the code. It consists in looking
at the Internet from the outside rather than from the inside.<br><br>
5.1. RFC 3439 principle of simplicity: why give huge and unlimited DNS
responsibility to browsers and applications. Let’s keep it simple. ASCII
just works, let not fix it with complexity (cf. the exemple of this
thread)<br><br>
5.3. the RFC 5890 to RFC 5895 set unlimitedly "multiplies by
division" the power of the Internet in installing an endlessly
diversified intelligent capacity to match external diversity (such as
linguistic diversity) where RFC 1958 and all the IETF culture puts it: at
the fringe. By doing so, it acknowledges that the Internet technology
matches a third fundamental networking principle, the principle of
subsidiarity.<br><br>
6. The IUse community primary targets<br><br>
Based on the ML-DNS/IUI principle, we mainly target seven fringe to
fringe areas:<br><br>
6.1. active/abient content:<br><br>
The internet currently only supports passive content (what I receive is
what was sent). We need active (what I receive is what the sender
intended me to receive) and ambient (what I receive is what corresponds
to my current context) contents to be supported.<br><br>
6.2.smart extended network services:<br><br>
We want to get local slots supported (smart local operative tasks), i.e.
local OPES or peers to the remote connection peers able to uncouple the
client/server interoperations and extend the user's experience of the
used network's technology.<br><br>
6.3. semantic networking:<br><br>
We consider three main communication strata serving <br><br>
- signal/data basic services, <br>
- content (passive [value-added services], active and ambient [extended
services]), <br>
- and semiotic/semantic (facilitation services). Semiotic means the
incorporation of many sources of perception and utterance other than
script and dumb voice and image. Semantic means the exchange of meanings
that can be extracted and processed by the facilitation services along
with the perceived context and the receiving mood and options. Semantics'
coherence is as precise as geometry's correspondance and mathematics
equivalence. Their figures only can be draft, computed or
discussed.<br><br>
6.4. multilingualisation:<br><br>
We consider an anthropobotic society where machines and people
interspeak. This means that several new linguistic disciplines must be
considered:<br><br>
6.4.1. "multilinguistic": as the way several languages may
coexist in use, machines, process, and society, and be treated as equal
(multilingualisation is a layer above Unicode's globalization in the
sense that it could be termed as a specific value added equal
globalization of every natural language). A multilinguistic Internet
would probably focus on a score of languages, and then 150 main languages
in an operational community effort, and a standardized approach for
volunteers and/or local authorities to get other natural languages
(22.500) identified, documented, and supported.<br><br>
6.4.2. mecalinguistic: as the way to manage machines' natural language
and their interinfluence with the language version of the language.
Example: English and MecaEnglish and MecaFrench.<br><br>
6.4.3. metalinguistic: up to now metalanguages were rather limited
depending on the natural language being considered, French being probably
the most metalanguage embedded. However, facilitation is going to call on
ontographies and ontologies that will lead to a generalization of the
mostly French used "metaduction" (what is wrongly termed
"Cartesian") as a simplification of deduction, induction,
abduction, and hypothetico-deduction in front of the apparent networking
complexity (RFC 3439 is a network oriented prerequisite in this
area).<br><br>
6.5. convergence of the digital ecosystem use:<br><br>
The World Summit on the Information Society has clearly defined the
humanity consensual target of a digital societal support being
"people centered, à caractère humain, centrada en la persona".
We assign the IUI the role to provide the user with an equal alternative
basic, value added, extended and facilitated, and stable enough
networking experience with any digital technology and digital
communication network environment.<br><br>
6.6. personal digital empowerment:<br><br>
Through the above, the definition of a user oriented (graphic sign)
international network character set (e.g. Bulgaria IDNccTLD problem), the
establishment of an MDRS (metadata distributed registry system) to be
understood as a distributed personal super-IANA cognition center for the
three strata that we defined and their related services, etc. we want to
ensure the full e-empowerment of every person (we make the difference
between a user in a (de)centralized user (i.e. customer) centric approach
and a person in a person centric distributed and/or intricate
environment. <br><br>
6.7. diktiologies support:<br><br>
Since "diktyos" in Greek means network, diktyology has two
meanings:<br><br>
6.7.1. the science of studying networks, from quarks to the Internet
through to political and commercial lobbies.<br><br>
6.7.2. the multidimensional, diversified, open, and intricate network
equivalent to an ontology. What "Projet.FRA" actually targets
is a Francophone diktyology associated to a diktyography. Some network
level and distributed/intricate integrated semantic web equivalent to be
used and completed by people through the MDRS.<br><br>
7. Market evolution<br><br>
Now, some clever service provider's people will understand where the
market lies for their corporation in this IUse usage evolution, and they
will be the network commercial leaders of tomorrow. Others will not, and
they will see the progressive obsolescence of their market share.
<br><br>
What is interesting is that the coming Brussels talk between ICANN and
GAC may trigger a fast evolution if they obstinately (both sides)
continue to ignore Vint Cerf's proposition, as the WG/IDNABis Chair, that
the user oriented debate in the continuation of IDNA2008 should be
managed by ICANN. I opposed that because ICANN does not represent users,
but that was unnecessary: ICANN is not even interested in the matter
(don’t ask me why), even if it leads to total confusion in their part of
the IUDNS.<br><br>
8. Current situation<br><br>
I/we delayed the introduction of ML-DNS for personal health (in my case)
as well as for strategic reasons, to give time to the IESG, IAB, and
Unicode members to consider where/how these issues should be addressed
and documented, and to permit ICANN to reconsider, due to its new BoD
Members. So far,<br><br>
8.1. IESG and IAB were clear enough, the IUI does not belong to their
"inside" Internet scope (moreover, it will deal with many other
technologies), I am taking this into account to try to structure the IUse
community, using the iucg@ietf.org non-WG mailing list as an open liaison
between the two scopes.<br><br>
8.2. Unicode has not introduced any proposition to support
orthotypographic metadata.<br><br>
8.3. ICANN has continued to enlarge their GAG (gTLD applicant Guide).
<br>
</body>
</html>