Subject: [Ietf-not43] changes to ldap-whois

From: ehall at ehsco.com (Eric A. Hall)
Date: Sat May 10 11:11:53 2003

New drafts in the ldap-whois collection will be coming out over the next
few days, but I wanted to give a heads-up on the changes.

First and foremost, the specs have been extended to fully accommodate
internationalized domain names as application data. Wherever possible,
server operators will be required to normalize the domain names they store
in their databases and clients will be required to normalize the domain
names they generate from input, with the normalized forms being used for
comparison operations. Wherever possible, the UTF-8 form is given
preference, although there are a couple of problem areas in LDAP which
prevent this from happening everywhere (specifically the domainComponent
and mail attributes). This decision path is a result of analysis regarding
the i18n and l10n issues in LDAP-WHOIS and IRIS (the root analysis is at
http://www.ehsco.com/misc/i18n-crisp%5b3%5d.pdf if you are interested).

Secondarily, I've defined a contact-lookup feature which takes an email
address as input, with the client mapping this address to a fully-qualifed
distinguished name (EG, mapping the input address of [email-masked] to
cn=[email-masked],cn=inetResources,dc=example,dc=com). This approach
imposes namespace rules on entries, but only those entries which are to be
publically accessible (these entries can also exist as referral sources
which point to some other canonical entry).

The third major change is the creation of a generic "resource
record" object class which is subordinate to the domain name resource
object class. This specifically solves the problem of finding nameservers
associated with domains, while also allowing nameservers to be located
with the existing domain lookup function, and also allows other kinds of
resource record data to be stored in the directory. These entries can also
exist as referral sources which point to other canonical entries.

I've settled on Federated Internet Registry Service (FIRS) as the name.
This conveys that the service is not just queries and lookups but that it
is an entire application. Thanks for all the suggestions.

Several other tweaks and mods are also being incorporated, but those are
the major ones. Drafts will be coming over the next few days.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/