Re: [iucg] [Idna-arabicscript] Re: Punycode Mixed-case annotation

[JFC Morfin <[e-mail]>]

At 13:32 02/07/2009, Vint Cerf wrote:
>jefsey,
>
>thanks for taking the trouble to prepare this note. It does lay out
>the issues clearly. I think I can report agreement with you in several
>areas.

Dear Vint,

Thank you for this mail. These various exchanges took quite some time 
away from my planned agenda for the Interplus Draft and the 
Project.FRA documents, but they truly help in evaluating how to 
better introduce them.

>First, while the IDNA working group members may not yet have reach
>consensus, there is at least among them, some who would treat the
>mapping on look up as a "should" (for compatibility reasons) but not a
>MUST and distinguish between the basic IDN protocol that preserves the
>A-label/U-label definitions and 1:1 conversion feature as part of
>protocol, and the pre-processing of strings that may be destined for
>lookup in the DNS. Some of the potential preprocessing is not
>specified in any of the documents except to say that by the time a
>look up occurs, it must be in A-label form (including the "xn--") or
>must be a "traditional" ASCII form ("LDH"). One form of preprocessing,
>about which we continue to debate, is to map some of the characters of
>the eventual "lookup" string so as to reduce variance from
>expectations that arise from the IDNA2003 behaviors.

This is the actual point John and Pete made very well. SHOULD and 
COULD can be used in clever ways in order to influence network 
design, usage and management in the way most of this WG feels the 
best. MUST should not be used.

>The DNS itself continues to have the purely ASCII behavior it has
>always had to avoid requiring changes on the domain name server side.

Absolutely. This is mandatory. We should not use scrambling for 
security purposes (moreover, IPv6 random IIDs offer a better 
possibility and pushes for IPv6 implementation). However, we must be 
careful to not harm the network in confusing what a function is 
supposed to do and what it can actually do without being changed but 
in being better used through the evolution of its upper layer context 
and possibilities (which usually means innovation and extended 
possibilities). The less we change the lower layers and the best we 
can use them preserve network consistency.

>Second, I think there is considerable room for innovation and
>standardization at a conceptual "presentation" layer - such a layer
>was not defined in the Internet while some effort to define on was in
>the OSI system. As applications have become increasingly
>internationalized, it is arguable that codifying presentation concepts
>may prove useful. Some might go so far as to suggest re-inventing the
>system of binding strings to internet addresses (what the DNS does).

 From the dot-root community test-bed that I ran a few years ago 
(along the ICANN ICP-3 recommendation), I feel that there is still 
plenty of things to do with the DNS tools in the way that they 
currently are. However, there is also a lot to debate about the best 
way to utilize them.

>While that path was not chosen in the present DNS-IDNA2003-IDNA2008
>sequence, it might be considered in the future and in my opinion, it
>is in these areas (presentation and re-definition) that much of your
>work, jefsey, has relevance.

My concern is that this work shows that many things are already here. 
The Internet has really great potential. These things are not used, 
but they are consistently here. However, this also means that anyone 
freely can take advantage from them . Therefore, the real issue is to 
try to influence some concerted usage vision. After the hardware and 
software, we need to influence the brainware - in openly exploring as 
to how some usage architecture may turn out to be more efficient than others.

This is not network technology or topology any longer but rather 
ideology as Rod Beckstrom would say. We face the concerns expressed 
by IAB in RFC 3869 . We need a review of RFC 3935 because the 
criteria for success are no longer only technical, or even financial, 
but are rather more related to a broad diversity of common, private, 
public, cultural, individual, and personal empowerments that we are 
not used to seeing at that level.

>I am interpreting your message here as arguing not to change the
>existing basic DNS, to confer stability at the server level, and here
>we agree.

ABSOLUTELY.

Maybe I am wrong (and this is what project.fra should help to check), 
but my four leading concerns are that:

- net neutrality is not engaged by "xn--" mapping at the protocol 
level - or it is labeled as an experiment and an alternative 
experiment is organized.

- DNS behavior is not changed, for example by case scrambling. This 
does not prevent additions outside of the nameservers (through OPES, 
for example) in turn assisting in a smooth evolution towards what I 
call the Multilingual Distributed Referential System (including 
"DNS2", local IANA, etc.).

- the ICANN dreamspace documentation complexity. I have no idea (lack 
of time, poor presentation of changes) as to what ICANN may be 
telling the world over IDNA, Fast Track - except that there seem to 
be conflicts ahead that result from misunderstanding and sovereignty 
trespasses.

- nothing has been prepared in order to migrate from a single root to 
a virtual matrix self-deployment, i.e. billions of individual 
rootnameservers running billions of  class/presentation roots. Its 
architecture and adminance (technical and administrative governance) 
are far less a problem (if the DNS protocols remain unchanged) than 
its governance and economy might be.


I know these are not usual concerns for an IETF WG.

- Yet small decisions by this WG will most probably decide of them 
due to the DNS importance in the world life.
- This is why I first tried to explore the IETF precautionary duty 
(http://tools.ietf.org/html/draft-iucg-precaution-00.html)

jfc