Re: [council] Motion on International Domain Names

["Paul M. Kane" <Paul.Kane@reacto.com>]

Hi Milton

Milton Mueller wrote:

> Voting on this seems to be extremely
> premature. There has been minimal
> discussion. The issues are complex.

Indeed they are cmplex and for that reason I think DNSO Constituencies should have
the opportunity to better understand the ramifications of entering iDNs as SECOND
level domains. You will be meeting in 3 weeks time... why push for the 27th October,
when back-tracking is tooo late!!!
There are a whole host of issues  - some characters (in asian scripts) look idential
but have different meanings in Hangul, Chinese Traditional, Kanjii, Email does not
work, ftp does not work, telnet does not work ... all the killer applications ...
web does work with either a plug-in, configured Browser or a search engine - but
such can work just as well at THIRD level.

> Here is the operational portion of the proposed
> resolution:
>
> "The Names Council therefore calls upon the ICANN
> Board to take the necessary steps to delay the
> transformation of any TLD IDN "testbed"
> into active domain names in the Root until such time
> as the IETF standards be completed"
>
> Would someone care to tell me what steps are
> "necessary" to stop registries that don't have
> contracts with ICANN from offering services?

I think it is prudent for the DNSO to high light and promote GOOD PRACTICE - eg wait
for the standard... but I do recognise that any party that is waiting should be able
to continue to exploit .  I am not a lawyer, but a contract is only worth something
if one is willing to enforce the terms...... Our job on the DNSO is not to be the
policeman saying "STOP" but to encourage the players in the market to think about
the effects of their actions and the preceidents it sets. ICANN is not a global
internet regulator, but the arena for self-regualtion.

> Would someone care to tell me what steps are
> "necessary" to stop registries that DO have
> contracts with ICANN from offering services?

That is up to ICANN but I don't like the term "Stop" <smile> I prefer that any
innovations demonstrate they have the interests of the consumer to heart and that
they build stability and consumer confidence that the name they are purchasing will
WORK as they _expect_ it to.

> Are these "steps" better or worse than the
> proposed problem?

They are giving time for the assessment of the issues, rather than trying to fix a
"testbed experiment" that could go horribly wrong.... therefore they are IMHO much
better!!

>
> Another question you may not have considered:
> what if the IETF standardisation process is
> NEVER completed? IETF recently abandoned
> efforts to standardize instant messaging;
> it gave up on URIs. Some standards just don't
> go anywhere. What then?

This is an excellent point and I agree..... if the IETF abandon their work they do
so because of the technical complications and fulfilling user expectations.  Having
participated in the IETF iDN meeting in August where the encoding system was
provisionally decided (there are some scalling issues and pre-prep to be worked on)
it is clear that many members of the technical community see completion of their
work as being "close" such that application providers can start intergrating iDNs
into their platforms.

Just to re-cap. I support the motion because we want to send a clear message to the
internet community that there is much work to do on iDNs to make them work. I do not
want to damage the roll-out of the new gTLDs (some question if they really do
work!), I do not want to stifle innovation and encourage Verisign and others to
continue work in satisfying the demand for local script name respolution, but above
all I want the iDN service to work and consumer confidence sustained.

Best

Paul

<SNIP>

>
>
> > DRAFT names Council motion on IDN (final version v4).
> > >
> > > 1. Whereas the technical work by the IETF (Internet Engineering Task Force)
> > >    is at the basis of Internet developments, and recognized as
> > >    such by the worldwide community and by ICANN;
> > >
> > > 2. Whereas the IETF IDN (International Domain Names) engineers have
> > >    determined twelve items to be defined  at the technical level before
> > >    the ML (Multi-Lingual) domain names should be used in order to preserve
> > >    globally unique naming in a universally resolvable public name space;
> > >
> > > 3. Whereas only an important but insufficient element in the encoding scheme
> > >    has been published to date by the IETF and that element only as a draft;
> > >
> > > 4. Whereas there cannot be an open competition at an application level
> > >    without all the IDN specifications completed and published;
> > >
> > > 5. Whereas the deployment of IDN space in countries using non ASCII
> > >    characters is an order of magnitude higher than in
> > >    English-speaking countries, because  it impacts on inherent culture;
> > >
> > > 6. Whereas the introduction of IDN names must have careful,
> > >    worldwide coordination across all TLD space to avoid political battles,
> > >    a profusion of encoding prefixes and corresponding confusion;
> > >
> > > 7. Whereas it is critical to understand how the whois accessible
> > >    databases for IDN would function for gTLD and ccTLD alike;
> > >
> > > 8. Whereas the International Treaty Organizations, WIPO and ITU, are
> > >    planning a joint Symposium on Multilingual Domain Names in Geneva,
> > >    December 6 and 7, 2001;
> > >
> > > 9. Whereas the domain name system is a key infrastructure component
> > >    of the Internet and ICANN is committed to preserve the stability
> > >    and security of this worldwide resource;
> > >
> > > The Names Council advises that having multiple and non-interoperable
> > > implementations in the DNS has the potential to be harmful for the
> > > stability and securty of the DNS.
> > >
> > >
> > > --
> >
> >