[registrars] IETF update

[Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au>]

Hello Rick,

Here was what I perceived to be the outcomes of the IETF meetings in London
recently:

Provreg - Registry/Registrar protocol work:
(1) Support for the protocol requirements document to become a formal
Informational RFC
(2) Support for Scott Hollenbeck's EPP protocol proposal to become the base
standard
(3) Support to identify additional protocol procedures in the Eric
Brunner-Williams XRP protocol document, as extensions to Scott's EPP
document to be developed a separate IETF RFC documents - thus ensuring no
overlap
(4) Support to refine the requirements document to avoid requiring (as
opposed to optional) functionality not needed by IP address registries such
as RIPE etc


I attended the DNS extensions and DNS security working groups.
The DNS extensions group seemed to be mainly discussing fine details of
methods of key management for security.  The sense of the DNS security group
was that the IETF work on DNS security was not ready yet for large scale
implementation, and that the drivers from industry were not yet present.
Most of the people involved in DNS security development derive from the USA
military or universities/organisations funded by military.  

I attended sessions on the International Domain Names (IDN) working group.
This group is working on the difficult problem of incorporating character
sets other than the restricted ASCII set used for UNIX hostnames that forms
the basis of domain names in use today.  It turns out that the underlying
DNS standards can incorporate different binary formats for multi-lingual
characters quite easily, but it is the applications such as WWW browsers,
email etc that have the problem.   There are two competing view points.  The
first is that multi-lingual characters should be encoded into an ASCII
format (ie a single chinese character may be made up of 3 ascii characters),
which will allow the domain names to be displayed in software that handles
ASCII without change (although not really comprehensible by end users unless
the software is changed).  This seems to be the view of people from
countries that primarily use ASCII characters to represent their languages
(ie USA and Europe).
The second view is that multi-lingual characters should be encoded in the
UTF-8 binary format (which may have strange effects on some ASCII only
software), which is used in existing software that supports multi-lingual
characters in the text.  This seems to be the view of people from
China/Japan/Korea.  There is limited participation of people representing
countries that use other character sets.  This is probably related to the
relative development of the Internet in those countries.

The outcomes appeared to be:
(1) Acceptance of an ASCII encoded format (generically called ACE) for
multi-lingual domain names 
(2) Identification of a suitable algorithm for converting multi-lingual
characters into ACE
(3) Acceptance of an approach to pre-process names at the end user computers
to handle special cases for case folding etc (e.g in the restricted ASCII
set, upper case and lower case characters map to the same domain name).
This turns out to be a very complex undertaking, and may be slow on some old
computers.
(4) Plans by some to establish a new IETF working group to develop a
standard using UTF-8 which will take longer to deploy in the Internet.

Overall it is a bit early to call what the final outcome will be (probably
require at least another two IETF meetings - December 2001 and March 2002).
This is a very controversial area, and has strong commercial and political
implications.

I attended a birds of feather session on WHOIS in London.  I also attended a
similar session on this topic in San Diego.  The essential issue is whether
it is appropriate to make changes to WHOIS RFC 954 (which will have problems
with backward compatibility), or start with a new standard for WHOIS that
uses a different port (ie a new server port number assignment).
The usual result of these sessions is that a large number of people submit
their wish list for a perfect WHOIS, and then another group decides it is
all too hard and nothing happens.
I found the session useful.  The essential requirements for an improved
WHOIS include:
(1) A standard format for WHOIS data objects
(2) The format should be both human readable and machine readable
(3) A standard protocol for exchanging information
The additional requirements include:
(1) Support for the user to request that some data elements not be made
public
(2) Support for authorisation/authentication to ensure that only authorised
parties can access WHOIS data

The outcome appeared to be:
(1) Establish an IETF working group with a charter to only make changes for
implementation on port 43 (ie compatible with RFC 954)
(2) Establish a separate IETF working group to consider a new WHOIS protocol
that will operate on a different port

I think this will be a good approach, and hope the political discussions
reach this outcome.
Regards,
Bruce Tonkin
>