Subject: [iucg] IDNA confusion

From: jefsey <[email-masked]>
Date: Tue, 30 Jun 2009 15:29:30 +0200

Marie France,
I will comment in Franglish sor you can quote it to who you want. It 
will follows a metatechnic line that your interlocutors will not be 
familiar with. So, I will detail some aspects.

I am tied with familly obligations, hence late on my promise to 
documents project .fra (more than one month). I apologize for that to 
everyone, friends and foes alike because it does not help their debate.

>On Mon, Jun 29, 2009 at 07:21:22PM +0200, Marie-France Berny wrote:
> > 2009/6/29 Andrew Sullivan <[email-masked]>
> > > Please don't hijack this thread.
> > ????
>
>I mean that the thread was talking about one thing, and you have
>introduced a different topic.  It appears you're doing so unwittingly,
>but I want not to conflate these two topics.

I understand Andrew's fear. However, he himself acknowledges that he 
does not know if, from your point of view, this is or not the same topic.

This very well identifies that the problem is not in the detail but 
in the architectural point of view. This should therefore be out of 
the WG concerns, except that the solution I agree and Vint disagree 
with is already documented in the WG Charter. No mapping at protocol level.

> > > The mapping of lower-case non-ASCII characters with respect to upper-case
> > > apparently-ASCII characters is _not_ the same question as the effects of
> > > lower- and upper-case ASCII across the U-label/A-label boundary.

Yes it is.

In this case this is because the DNS casefolding obeys a particular 
orthotypography that conflicts with the French language orthotypography.

The way Andrew describes the problem, you cannot solve this. The way 
they build and understand the internet (all the interoperable 
coputers via IETF packet switch networks - USC and RFC 3935) you 
cannot. The way we observe their internet as part of the online 
public communications and services ecosystem (French legal 
definition) the solution is built-in.

This is the very common situation of our time that Edgar Morin has 
identified as "complex thinking", i.e. bottom/up (inductive) top/down 
(deductive) assisted reasoning. This problem is discussed with for 
centuries (Aristoteles, Vinci, Descartes, Kant, Wienner, Von 
Bertalanffy, Von Foerster, etc. ) with some recent progresses. The 
way it is eventually addressed in here (due to the practical daily 
global impact of IDNs) will most probably influence its resolution 
everywhere in science, politics, society, culture, etc.

This is why there is a direct opposition between us and Unicode for 
years. French speakers, and Unicoders do not understand this problem 
the same way as others. The reason why is that the very purpose assigned :
- to Unicode is to suppress the problem through globalization, i.e. 
English internationalization, localization and language filtering.
- to the French language 470 years ago, on August 10: precisely to 
address that problem in being the language of the Law, i.e. the 
pregnancy of the social system saillances, if to speak as René Thom.

> > I am sorry. I have not the slightest idea of what you are talking about. I
> > read an attempt to come to a quick conclusion regarding punycode and where
> > to carry mapping. Or am I wrong?
>
>Wrong, I'm afraid.  The specific question was about ASCII characters
>that _remain ASCII_ when using Punycode to transform the label.  So
>for instance, in
>
>    abcdé
>
>and
>
>    ABCDé
>
>the 'abcd' and 'ABCD' parts are not, strictly speaking, touched by
>Punycode.

Correct in their reading, and along Unicode's confusion between 
"capitales" and "majuscules". Unicode supports an International 
English able to quote foreign scripts and languages. By 
simplification we all have accepted it to some extend so one could 
use the English/DNS orthotypography instead of adding French (and 
others) orthotypography considerations to a prototype system.

The result is that the French "a", "A" etc. are considered as a 
single casefoldable character, while they are not.

This is not a DNS, nor a punycode issue, this is a Unicode issue. 
This means that the DNS is not concerned, punycode is to be informed, 
and Unicode is to be completed.

>Under IDNA2003 there's a simple answer for this, because of
>the way it works.  Under IDNA2008, the earliest proposals did no
>mapping at all, and we haven't settled what mapping if any will
>happen.  Therefore, there is a question about what to do with these
>particular cases.

This is already solved by the presentation layer. The issue is not 
how to address the problem, but how  the Internet architecture does 
already address it.

I accept that the impact on the Internet may be important. However, 
we tried to keep the things smooth, abiding by the Charter, 
documenting how we would extend IDNA on an as needed bassis. Most of 
the informed people supported us. When we have been attacked again, 
we had no choice but to start documenting how the presentation 
layers, and extended services, work in the Internet architecture, in 
order to try to reduce the number of alternative usages we saw being 
investigated.

> > As far as I understand, there is one clarification missing. It is what do
> > you define as "global" in here. Are French (and possibly Persian, and
> > probably many others...) included?
>
>Yes, in the sense that there is one giant domain name system under
>which everything has to fit, because the whole system is a tree
>structure with one root.

This is the way IETF understands the Internet. This has to be 
respected as much as possible because this is what insures the 
current economic and politic stability of the Internet. But the 
Internet architecture is built to support billions of (class and 
presentations) roots. The only possibility to keep things stable (at 
least to give time to understand the issue and fairly document it to 
politicians) is to present the current namespace as the semantic name 
space default, and to support IDNs in it. Project .fra should also 
give some time since it will be presented as a test-bed other 
language may benefit from and participate in.

>(I'll leave aside for the moment the
>possibility of "alternate roots", since every actual example of that
>is in fact just a change of the servers holding the "unique root", and
>not a change to the principle that there is a spot where the namespace
>starts.)

This is technically correct (except that TLD conflicts will introduce 
pollution), but do not takes into accound private, class, and 
presentation roots. We need to consider the virtual root matrix, as 
our dot-root experimentation documented it years ago, when we 
responded to the ICP-3 call for a community test-bed. However, at 
that time we discussed national matrices. Today we are speaking of 
individual matrices.

>If you mean, "Will it support French, Persian, English, Chinese,
>Arabic, and any other language Unicode supports in ways that are
>completely natural to the readers and writers of those languages?" the
>answer is, "No, and that was never the goal."

Correct. This is our goal, this is not their goal. This was made very 
clear by Vint and James Seng. This is why we introduced the ML-DNS 
and promised to protect compatibility. What they did not understand 
is that "ML" does not stand specifically for "multilingual" but for 
"multi-layer" and as a result for "multi-ledger".

In so doing they are constraning the Internet capacity (try to 
lock-out the presentation layer).

>As several people have
>said several times, the goal is not to be able to write literature in
>the DNS.  The goal is just to internationalize the DNS, subject to the
>limitations of the existing DNS.

Correct: this is their goal. There are two misunderestandings in this goal:
- nobody talks of litterature, but of orthotypography, i.e. to 
respect the semantic implied by the typography.
- no one ever wanted to internationalize the DNS nor to change it. 
The goal is to "internationalize" (we want to "globalise") the domain names.

>One of those limitations turns out to be the (in my opinion
>unfortunate) DNS property that it is case-preserving but
>case-insensitive.

This is a DNS feature. We have to accept it if we want to use the DNS.
Actually it turns to be fortunate, because it simplifies the 
numbering (0-Z) of the domain name labels.

>As a historical fact, ExAmPlE.org, example.org,
>EXAMPLE.org, EXAMPLE.ORG, and example.ORG are all "equivalent" for the
>matching rules.  On my interpretation, the DNS server ought to return
>an answer to any of those queries with the name as it appears in the
>zone file, but some do other things (such as return a pointer to the
>question section, which means you get back the form as you asked it).

This is exactly what permits to use and trust the DNS.

>What you are asking is, I'm sure, a completely natural extension of
>that principle in your view: you want école.fra to match ECOLE.FRA.

No. We want école.fra to match école.fra at the application layer 
(this is IDNA, not the DNS) and nothing else. The same as for every 
other non ACC

>The problem is that this doesn't work the same way, because ecole.fra
>and ECOLE.FRA also match each other, so now we have an ambiguous
>combination.  And that's only in the case where you actually know the
>label is "in French" -- already an extremely complicated problem,
>since we don't have a universally agreed-upon authority as to what
>language any given word is in.  (You can't learn it from the DNS
>without either an additional query or special processing on the server
>side, both of which rules are, as far as I understand, antirequisites
>for the current work.)

The DNS belongs to the service layer. What we discuss here belongs to 
the presentation layer. The relation between them is punycode.

>Note that, in some contexts in English, it would be very surprising
>that case didn't matter.  If case were not important in English, then
>we would have lost them some time ago (also, a signficant body of
>poetic work would be affected).  This is not a battle between people
>who speak English and whose every natural impulse is accommodated
>vs. everyone else.  It's just a matter of finding the set of
>compromises that will fit within the compromises that were already set
>when the DNS became successful.

As you fully understand, this is nothing of this kind. It is the 
technical capacity of the system to support people's specs or people 
to accept systems constraints. Who is the master, who is the slave 
(this is the way people will feel about it). Actually this is a pure 
RFC 3869: the merchant or the user. If mapping is made by the user, 
the merchant has no more control on him/her/

>All of the above said, as far as I know the mapping document is still
>open for comment.  If you know some way by which these mappings are
>achievable, I'm sure everyone would love to hear them.

We gave them the IUCG url. This does not speak to them. They need 
three things :

- an I_D based documentation (I am late in folding all your contributions)
- some runing code (we miss developpers)
- a visible community test-bed, this is the project-fra (it 
progresses - I hope we have a good meeting in it on July 7th in Paris 
- anyone interested ?)

On our side we need time, work and money. The project rendez-vous 
should be in october. Three months, a well documented work list for a 
few of us, and different funding sources (we already have a part-time 
professionnal facilitator [Laure-Emmanuelle] and a document publisher 
[Ségolène])

However, if they do not want to go on the IUCG or if the notes there 
are not clear enough, let remind them:

1. we comprehend genralized communications as made of three strata : 
telecoms, datacoms and metacoms.

2. as lead users we are interested in the Intersem, semantic, 
multilingual and semiotic international usage network for the people. 
So it addresses the metacoms needs.

3. the current datacoms stratum technologies do not offer the service 
pile we need to support the metacoms stratum. We therefore document 
the Interplus (pluggable layers users' systemic) Internet pile 
extension. The untouched Internet and the Interplus makes the 
Internet Plus we need. We document the Interplus so the Internet pile 
is unchanged. We are not particularly interested in IDNA, but for the 
user convenience it will be simpler to use IDNA when appropriate and 
benefit from its work.

The only thing we need is the Internet to stay neutral (i.e. it could 
be replaced by another technology transparently to the Interplus and 
to the users). This means not to confuse apping at Network (protocol) 
and User (off-protocol) applications layers.

jfc