[registrars] Re: IETF update

[Rick H Wesson <wessorh@ar.com>]

Bruce,

Many thanks for attending the meetings and providing the synopsis of the
main tech issues all registrars are and will be faced with.

I'll make sure that this note and your last one about the Commerce whois
meeting get placed on our registrar web site (when we get it up ;-)

again, thanks for boiling down the details for us - it is very much
appreciated!

-rick


On Mon, 17 Sep 2001, Bruce Tonkin wrote:

> 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
> >
>