xn--p1ai
J-F C. Morfin
jfc at morfin.org
Fri Feb 25 16:25:39 CET 2011
At 18:31 24/02/2011, John C Klensin wrote:
>--On Thursday, February 24, 2011 09:31 -0500 Lyman Chapin
><lyman at interisle.net> wrote:
>
> > Simon,
> >
> > I think that many of us expect the case-folding behavior of
> > IDNA2003 to be preserved by applications (esp. web browsers)
> > at least during the transition to IDNA2008 (e.g., following
> > UTS #46, http://unicode.org/reports/tr46).
>
>And some of us believe that the recommendation of RFC 5895,
>which include mapping to lower case (see its Section 2, item 1),
>are more appropriate than UTS #46.
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).
1. We accepted John Klensin's proposition
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.
2. The WG did not care about French
This ML-DNS of us addresses our "Projet.FRA" (http://a-fra.org) 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.
<http://tools.ietf.org/id/draft-iucg-afra-reports-00.txt>http://tools.ietf.org/id/draft-iucg-afra-reports-00.txt.
2.1. we reported it to IESG/LC
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.
That situation calls for:
1. a mapping of everything to lowercase so that everything is stable,
clear, and secure.
2. us to add the majuscule information as a metadata that we
investigated in
<http://tools.ietf.org/id/draft-iucg-punyplus-03.txt>http://tools.ietf.org/id/draft-iucg-punyplus-03.txt.
2.2. our position is qualified as "research"
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.
3. Strength of IDNA2008 and IDNA is weakness
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.
3.1. The presentation layer.
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).
3.2. the IUI
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.
4. Technical vs. technico-commercial disagreement
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).
However, some IETF leaders and smart Google people have now swallowed
and are digesting the optional change introduced by IDNA2008 with:
- the "inside" Internet
- encapsulated into an uncoupled peripheral extended (intelligent)
services "IUI" (Internet Use Interface), interfacing the user universe,
- itself accessing and operating the Internet and other systems of
the world digital ecosystem though their own "IUI" (Intelligent Use
Interface).
5. A strictly conformant architectural enhancement
This change totally conforms with the Internet architectural principles:
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.
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)
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.
6. The IUse community primary targets
Based on the ML-DNS/IUI principle, we mainly target seven fringe to
fringe areas:
6.1. active/abient content:
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.
6.2.smart extended network services:
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.
6.3. semantic networking:
We consider three main communication strata serving
- signal/data basic services,
- content (passive [value-added services], active and ambient
[extended services]),
- 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.
6.4. multilingualisation:
We consider an anthropobotic society where machines and people
interspeak. This means that several new linguistic disciplines must
be considered:
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.
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.
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).
6.5. convergence of the digital ecosystem use:
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.
6.6. personal digital empowerment:
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.
6.7. diktiologies support:
Since "diktyos" in Greek means network, diktyology has two meanings:
6.7.1. the science of studying networks, from quarks to the Internet
through to political and commercial lobbies.
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.
7. Market evolution
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.
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.
8. Current situation
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,
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 at ietf.org non-WG mailing list as an
open liaison between the two scopes.
8.2. Unicode has not introduced any proposition to support
orthotypographic metadata.
8.3. ICANN has continued to enlarge their GAG (gTLD applicant Guide).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20110225/9a2f18e3/attachment-0001.html>
More information about the Idna-update
mailing list