<html>
<body>
At 08:57 16/03/2009, John C Klensin wrote:<br>
<blockquote type=cite class=cite cite="">--On Sunday, March 15, 2009
22:09 +0100 JFC Morfin<br>
<jefsey@jefsey.com> wrote:<br>
> The problem ".fra" has with it, is<br>
> that the proposition is not case-sensitive for the time<br>
> being. But we could make "xs--" to be case
sensitive.<br><br>
Jefsey,<br>
You will never get case-sensitivity with ."fra" in the DNS<br>
unless your intention is to provide an equal-opportunity mess by<br>
encoding everything with a prefix, including basic (undecorated)<br>
Latin characters. That encoding can't be Punycode, since it<br>
won't encode those basic Latin characters.</blockquote><br>
John,<br>
Let me clarify then. <br><br>
We have two different visions ("theories" in Greek) of the same
issue.<br><br>
<b>1. internationalization<br><br>
</b>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:<br><br>
- network _internationalization_ through the choice of Unicode to extend
the ASCII character set.<br>
- ends _localization_ through IDNA<br>
- global entry/language _filtrering_ through tables and
bundling.<br><br>
At character level this is the same as RFC 4647 at language level. So, if
clearly described it is <br>
- suitable for those who can use it : i.e. having or accepting a cultural
equivalence with ASCII/English constraint set.<br>
- interoperable by those who need more.<br><br>
<b>2. multilingualization<br><br>
</b>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). <br><br>
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.<br><br>
<b>3. Practical impact on UTLs <br><br>
</b>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.<br><br>
- As long as you :<br>
-- default to lower cases _before_ the UTL (punycode)<br>
-- 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).<br><br>
- 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. (*)<br><br>
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:<br>
- virtually extending Unicode with majuscules in the protocol as people
do when they type, <br>
- not reducing majuscules to lowercases before the UTL process, <br>
- adding IGNORED and TEMPORARY classes of characters to the UTL (for
possible liaisons additions)<br>
- differentiating that UTL special usage with "xs--", from the
UTL normal usage which is marked with "xn--"<br><br>
This practically means:<br>
- removing case folding to lower case for majuscules before the UTL <br>
- using the same UTL (punycode) which will treat majuscules (I
understand) as upper-cases (i.e. non-ASCII).<br>
- signaling it in using the "xs--" prefix.<br><br>
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.<br><br>
Thank you to tell me where I am confused.<br><br>
(*) 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. <br>
However, the Linux/Windows file names lead me to think this is probably
an important enough issue - including for IRIs and even URIs.<br><br>
<blockquote type=cite class=cite cite="">And that has nothing to do with
ICANN but with the basic<br>
case-insensitive matching rules that go back to the original DNS<br>
design and indeed to the earliest host naming rules on the<br>
ARPANET.</blockquote><br>
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<br><br>
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:<br>
- MultiLateral (for stablity and easier security) i.e. distributed <br>
- MultiLayer (for domain name added value), usage, service, DNS
layers.<br>
- MultiLedger (cross zone application registry governance). <br>
- MultiLingual (polynym, meaning that the same address can be expressed
in different languages)<br>
- MultitechnoLogies (networking, programming, topology, semiotic,
medical, documentation, indexing, Logic, etc.)<br>
- 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. <br><br>
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).<br><br>
jfc<br>
</body>
</html>