Re: [ga] RE: Who'se done it? .org IDNs killed
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.
>Marc Schneiders wrote:
>>On Mon, 23 Jun 2003, at 17:11 [=GMT+0200], Stephane Bortzmeyer wrote:
>>>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
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
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.
- 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
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.
>This message was passed to you via the firstname.lastname@example.org list.
>Send mail to email@example.com 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 firstname.lastname@example.org list.
Send mail to email@example.com to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html