Update to clarify combining characters

[JFC Morfin]

>At 23:01 21/04/2014, Eric Brunner-Williams wrote:
>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.

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 
<http://www.rfc-editor.org/ien/ien48.txt>http://www.rfc-editor.org/ien/ien48.txt 
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.'".

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.

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.

These principles are documented in the two following sentences:
- "No explicit network hierarchy is assumed in this model",
- "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".

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.


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.

*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.
- This has been patched one way by the "locale" file;
- 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.

The remaining unsolved IDNA2008 element is its topological location.

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).


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:

1) agreement and help for the creation of the IUCG at 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.
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.


>On 10:10 22/04/2014, Cary Karp said:
>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?)

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.

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".

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).

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.


>At 14:46 22/04/2014, Cary Karp wrote:
>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.

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 
<mailto:vip at icann.org>vip at icann.org where there were 24 mails in 
2013: what is the one to be on? Thank you!

jfc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20140422/1ec9dfc4/attachment-0001.html>