<html>
<body>
<blockquote type=cite class=cite cite="">At 23:01 21/04/2014, Eric
Brunner-Williams wrote:<br>
Obviously, what ICANN gTLD registry operators do is governed by contacts
between they and ICANN, and what ccTLD registry operators is also
governed, in part, by desires for consistency, but below (or outside) of
these namespaces with _local_ (not pervasive to all levels of the tree)
restrictions on labels, what resolves is a local question -- local
in the sense of both the FQDN, the RRSet associated, and the resolvers to
which query(s) are made.</blockquote><br>
I tend to think that the whole internet project's success depends on its
consistency, i.e. that it developed with many constraints but without
contradiction with its
<a href="http://www.rfc-editor.org/ien/ien48.txt">
http://www.rfc-editor.org/ien/ien48.txt</a> seed. This model, however,
suffers from an inconsistency that I call the "bug" (for
"being unilaterally global") that seems to root in the word
"loose" in: its thrid paragraph: "The term 'local' is used
in a *loose* sense, here, since it means 'peculiar to the particular
network' rather than 'a network of limited geographic
extent.'".<br><br>
The term *loose* is something that depends on semantic imagination and
that politicians like, but that lawmakers and engineers dislike. However,
this term seems to translate something perfectly clear (and, therefore,
built-in in the French context of the catenet concept). In the French
language, the word "global" has usually gone beyond its
"limited geographic extent" meaning. It stands for what IEN 48
wants to be prepared for, and is (I understand) sometimes described in
English as "wholity" (as in the whole is larger than the sum of
its parts). It is conceptual rather than geographical: local is then what
is “peculiar to the [local] particulars”, i.e. documented by the
"locale" file.<br><br>
This is why I submit that limitations introduced by the English language
to Louis Pouzin's catenet concept conceived in the French language
context have been further consolidated as constraints by the IETF, in
opposition to the IEN 48 catenet model principles. <br><br>
These principles are documented in the two following sentences:<br>
- "No explicit network hierarchy is assumed in this
model",<br>
- "A very important aspect of this model is that no a priori
distinction is made between a host/network interface and a
gateway/network interface". <br><br>
The Loc/ID welding, that Louis Pouzin has always objected, is not
consistent with: "The host/network interfaces are assumed to be
unique to each network. Thus, no assumptions about common network
interfaces are made." A community at the “local gateway” interface
has been assumed to be so tight as to melt the host and interface
together in a topological unicity. <br><br>
<br>
In here, we are hit by this same difficulty, which has prevented the
second IEN 48 multitechnology (and implied multilinguistics) motivation
from being accomplished, and also led to the "status quo"
strategy. <br><br>
*Lose locality* was supposed to be supported at the local gateway
"host/network interface", i.e. on both "halves" of
the host/network gateway/interface (remember no distinction must be made
between the two). This means, topologically, this has to happen at the
missing OSI presentation layer six and both ways. <br>
- This has been patched one way by the "locale" file; <br>
- we still missed the "netlocale" equivalent to permit the host
to adapt to what is "peculiar to the particular network" and
"unique to each network". This is now provided in part by
IDNA2008.<br><br>
The remaining unsolved IDNA2008 element is its topological location.
<br><br>
The "unusual" (the term it uses, in that it documents an over
the end issue) RFC 5895 has exemplified the solution in line with RFC
1122, 1958, and 3439. I accepted it because it permits us to read the
internet as an "inter-interface" network, what I call the
"interplus", i.e. inter-presentation layer on the user side.
You may remember that my opposition to Vint was that he wanted to retain
the IDNA2008 layer six functionalities only on the network side - may be
in reaction to IDNA2003 which located them in the very applications (as
do today's APPS or the W3C).<br><br>
<br>
However, one could not venture into my proposed intelligent use inteface
(IUI) without the IETF making sure that (1) it was consistent with the
whole set of RFCs [there are several WGs on that] and (2) how this would
be documented since that IUI could interface the Host (unleashed from/or
through the internet) with multiple technologies documented by their own
SDO that the IAB would have to liaise with. This second point has
resulted in Russ Housley's:<br><br>
1) agreement and help for the creation of the IUCG@IETF mailing list, to
try to make informed users (IUsers) speak and contribute about their host
and beyond the host technical needs. i.e. in the "unusual" area
of RFC 5895.<br>
2) RFC 6852 which certainly prepares a "global" (French
meaning) internet, but the IUCG cannot endorse yet because it does not
include an MS convergence process in case of discordance (concepts,
protocols, parameters, uses) between what they call "global
communities". This is what the NTIA asks ICANN to document.
<br><br>
<br>
<blockquote type=cite class=cite cite="">On 10:10 22/04/2014, Cary Karp
said:<br>
I had always assumed that the trailing order of combining marks was
imposed directly by Unicode and that this simply cascaded into IDNA. Can
that constraint actually be overridden in any situation that would be
trapped by a new contextual rule in 5892? (If new rules are going
to be added, there are a few others that might be suggested. Is that
topic now open for discussion?) </blockquote><br>
This is a very important question that also affects the variants. The
"inter-IUI"/Interplus catenet model implies that "no a
priori distinction is made between a host/network interface and a
gateway/network interface". This cascades to the host/human
interface. At the H/H stratum, IDNA2008 appears as a
"netlocale", i.e. how the "center of the information
society" (the person) is to digitally deal with its different
internet supported relational spaces (in our case, through the physical
host/human interface: the Unicoded (or not) keyboard and screen.
<br><br>
We, therefore, have to be careful at locating constraints (every solution
implies constraints) at a place of least nuisance (Harald cited the
"principle of least astonishment"). My own rule was: “no
gateway trespassing MUST”. <br>
<a name="_GoBack"></a><br>
Therefore, I would aswer: no. You might remember that I was very opposed
to whatever could block the support of French majuscules, as also an
example of orthotypographic support (which can be a very broad matter). I
still wish to experiment their support at the IUI level in a more
generalized digital and semiotic environment before determining what
belongs to end to end (if any) and to fringe to fringe (what I am, [and
others seem to be] now engaging). <br><br>
Much will depend on the work on the ML-DNS (Multi-Ledger DNS) I had said
at the begining of IDNA2008. But this is another issue that calls for a
series of I_D I might introduce after the Sao Paulo meeting. The
considerations regarding the cost to support of a language may then
totally change. This is line with my ".fra" project.<br><br>
<br>
<blockquote type=cite class=cite cite="">At 14:46 22/04/2014, Cary Karp
wrote:<br>
A lot of energy is being focused on that in ICANN's VIP program, to which
anyone with immediate interest in that discuss should probably
refer.</blockquote><br>
A lot of energy is spent in different fora to attain some consistency in
the digital multilinguistics area. I have not noted yet, in those I
follow, a real degree of convergence. I am on
<a href="mailto:vip@icann.org">vip@icann.org</a> where there were 24
mails in 2013: what is the one to be on? Thank you!<br><br>
jfc<br>
</body>
</html>