ICANN/GNSO
DNSO and GNSO Mailling lists archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] RE: Who'se done it? .org IDNs killed


Dear Marc,
In MdR 2000 James (I think it was him?) was extremely brilliant in 
presenting i-DNs/Minc problematic. This led us all to think of IDN in an 
open manner. This makes us "feel" that RFC 3490 (also in part an opus by 
James) is not the first attempt at IDNs.

At 16:36 25/06/03, James Seng wrote:
>Actually, RFC3490 and other related RFCs are indeed the first set of RFCs 
>on IDN from the IETF.
>-James Seng
>
>Marc Schneiders wrote:
>>On Mon, 23 Jun 2003, at 17:11 [=GMT+0200], Stephane Bortzmeyer wrote:
>>>>Stability?
>>>
>>>Stability between standards: if RFC 3490 is one day updated or
>>>replaced by another, we expect that the registrants of RFC3490 domains
>>>will be offered some form of free upgrade. We expect that they will
>>>not loose anything just because IETF evolved.
>>>
>>>But there is no reason to guarantee any stability between experiments
>>>and the real stuff.
>>
>>I find this an arbitrary distinction with no basis in reality. 3490 is not
>>the first RFC about IDN, is it? Why make this particular text into some
>>sort of law and paradigm? Whether it leads to something in real internet
>>life remains to be seen, as with all RFCs for new protocols or new
>>enhancements.

This was the argument at the IETF to close the text. Temporary and 
experimental usually lasts. And then new solutions are added. This is why I 
feel the ACE label creates a problem because it introduces a new 
underlaying naming hierarchy in the DNS, and this has not been discussed as 
such.

today binary: "xn--" and "no xn--". Next "x1--" etc.
Some national filtering applications are already investigated.

>>>That's what experiments are for. (ICP-3 gives
>>>details about that, although this document is not often quoted because
>>>the pro-domo speech of ICANN is annoying.)
>>
>>ICP-3 has indeed even less value as a 'law'.

ICP-3 defines very precises conditions for experimentation.
- non-profit
- reversible
- at the global community initiative
- does not affect real operations

This is what the dot-root test bed project tries to respect. I doubt IDNA 
can be just that.

But, please. IDNA is the only one we have for a real need.  I opposed James 
a lot, before, on this. Now we have this and we have to manage with it. The 
risk was that ICANN imposed positions while we have no experience, adding 
to the problem.

I read the Guidelines as a disengagement of ICANN as giving responsibility 
to the Registrars? Among the risks now, IMHO we have:

- ICANN keeping guidelines binding instead of BPs: this
   would lead to lingual SLDs and national TLDs opposing
   ICANN. Please respect National independence and
   do not call for Sovereign States to enter the debate.

- a registration mess. This should be solved through a
   semi GPL universal solution (like for Bind). One solution
   is adopted so: contracts, FAQ, services etc are universal
   and texts easily available in languages and registrants
   made familiar with a unique look and feel. But each
   country/language may need modules adapted to its own
   ruleset and management procedures. This will call for
   some quick development support and homogeneity. It
   will probably best served/supported if a software company
   does it - may be with a Registrars/Resellers Club in
   background. IMHO the cost could be easily footed through
   a small share on registrations. This would permit every
   Registrar to ask for specifics and so to help developed
   and tested the whole service.

- the need for an evolution. The problem of IDNs is that
   they extend the DNS character set to Unicode. They do
   not support internetted language networks. Please
   remember, Vint Cerf, Bob Khan, Louis Pouzin reminded
   it not long ago at IETF. Internet is about internetting:
   technologies, networks, today languages. It we continue
   doing it in a virtual star network way, with ICANN at the
   core, we will have the same problems with IDN as we have
   with DNS, IP addresses, ccTLDs, @large, etc.

   MDN (multilingual DNs, with MLTLD)  is a service Gov and
   operators want. But the real users demand is for "vernacular"
   names. That is not only the way the people speak or write,
   but also the way they leave with names. Users expect the
   network to technically work and to support a naming space,
   a space of trust, and a service space. VDNs must address
   that demand.

IDN are not _the_ response, but they are a step ahead.
Because when you think of it, many things we need will
probably be better identified through their support.
jfc


















>--
>This message was passed to you via the ga@dnso.org list.
>Send mail to majordomo@dnso.org to unsubscribe
>("unsubscribe ga" in the body of the message).
>Archives at http://www.dnso.org/archives.html
>
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/03

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html




<<< Chronological Index >>>    <<< Thread Index >>>