DNAv2+ or IDNA2008+

[JFC Morfin]

At 08:57 16/03/2009, John C Klensin wrote:
>--On Sunday, March 15, 2009 22:09 +0100 JFC Morfin
><jefsey at jefsey.com> wrote:
> > The problem ".fra"  has with it, is
> > that the proposition is not case-sensitive for the  time
> > being. But we could make "xs--" to be case sensitive.
>
>Jefsey,
>You will never get case-sensitivity with ."fra" in the DNS
>unless your intention is to provide an equal-opportunity mess by
>encoding everything with a prefix, including basic (undecorated)
>Latin characters.  That encoding can't be Punycode, since it
>won't encode those basic Latin characters.

John,
Let me clarify then.

We have two different visions ("theories" in Greek) of the same issue.

1. internationalization

the IETF current approach is to consider the DNS system and to _add_ 
an _internationalization_ feature to it at user application layer, 
i.e. _outside_ of the protocol on the wire dumb network end to end 
area of forced respect. As a typical internationalization process it includes:

- network _internationalization_ through the choice of Unicode to 
extend the ASCII character set.
- ends _localization_ through IDNA
- global entry/language _filtrering_ through tables and bundling.

At character level this is the same as RFC 4647 at language level. 
So, if clearly described it is
- suitable for those who can use it : i.e. having or accepting a 
cultural equivalence with ASCII/English constraint set.
- interoperable by those who need more.

2. multilingualization

My approach is to include _multilinguistic_ support within the 
network Domain Names area (ML-DNS). At a network presentation layer 
_inside_  the network usage (its practical support is another issue I 
documented).

In order to do that I need a "usage-to-LDH" correspondence code. Let 
name it UTL. It can be anything. The only thing is that it must 
belong to the Network application layer inside the network, not to 
the User application layer above the network.

3. Practical impact on UTLs

Your own UTL is what IDNA2008 is about. Our problem is how much of it 
can we use to stay interoperable and what have we to add.

- As long as you :
-- default to lower cases _before_ the UTL (punycode)
-- do not introduce distortions in the character space that I cannot 
accept, your UTL is as good as any other one for the requirements we 
share (IDNA2003 support, compatibility with IDNA2008).

- as ".fra" our problem is that Unicode does not support the French 
language "majuscules" and proposes casefolding.as a substitute for 
French language "capitalisation" (which differs in France and in 
Switzerland for example) introducing confusing keyboard usage. (*)

However, compatibility with IDNA,  Unicode typographic ability to 
represent "majuscules" in using upper-cases, and IDNA case folding to 
lower case before the UTL, should make possible to workout a ML-DNS 
presentation function handing _every_ domain name usage in:
- virtually extending Unicode with majuscules in the protocol as 
people do when they type,
- not reducing majuscules to lowercases before the UTL process,
- adding IGNORED and TEMPORARY classes of characters to the UTL (for 
possible liaisons additions)
- differentiating that UTL special usage with "xs--", from the UTL 
normal usage which is marked with "xn--"

This practically means:
- removing case folding to lower case for majuscules before the UTL
- using the same UTL (punycode) which will treat majuscules (I 
understand) as upper-cases (i.e. non-ASCII).
- signaling it in using the "xs--" prefix.

This way ML-DNS  for us will be IDNAv2+ or IDNA2008+.. This is 
because we know China and other countries will implement what you guys specify.

Thank you to tell me where I am confused.

(*) This is a good example of the limits of the internationalization 
theory: it provides only one _single_ manner to internationalize the 
network. That manner includes case-folding as possibly mandatory and 
does not support majuscules as such (similar problem to converting 
Linux file names to Windows file names). This means that the IDNA2008 
proposition can only fail the French language majuscule systemic. I 
have no idea if there are other cultural semiotic having the same 
problem, but I suspect there may be similar cases.
However, the Linux/Windows file names lead me to think this is 
probably an important enough issue - including for IRIs and even URIs.

>And that has nothing to do with ICANN but with the basic
>case-insensitive matching rules that go back to the original DNS
>design and indeed to the earliest host naming rules on the
>ARPANET.

You talk of the DNS as an application. I talk of the ML-DNS as a 
service architecture. I call it DNS because Vint asked me not to 
speak of the ML-DNS; but I see here that this lead to confusion since 
the ML-DNS only intends to be an IDNA interoperable DNS manager 
network architecture

I know I should write an I_D on SAS, ML-DNS and their relations to 
the DNS (Semantic Addressing System, and Multi-L-DNS) but this is 
related to many other things (the way to implement them, the 
relations to semiotics, linguistics, IA) I work on in parallel. Just 
to keep things clear, the ML-DNS we consider is a KISS solution that should be:
- MultiLateral (for stablity and easier security) i.e. distributed
- MultiLayer (for domain name added value), usage, service, DNS layers.
- MultiLedger (cross zone application registry governance).
- MultiLingual (polynym, meaning that the same address can be 
expressed in different languages)
- MultitechnoLogies (networking, programming, topology, semiotic, 
medical, documentation, indexing, Logic, etc.)
- totally transparent to the existing DNS (as an application), 
possibly extended though DDDS+ (with added time and environment 
features) extensions of it, and OPES encapsulations.

As such it targets a consistent virtual presentation layer, but does 
not document the way this presentation layer should actually be 
supported in its various environments. In wanting to stay IDNA 
interoperable it should make it complex not to respect IDNA. This way 
it  should help the IDNA deployement and stability).

jfc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090316/920185db/attachment.htm