Another approach to an XML directory service

Hello,

Let me introduce myself.  My name is Andy Newton, and I work for VeriSign.
With our experience in DNS and whois, we have been doing a lot of thinking
about directory services.

In February, we submitted three drafts to the IETF on an idea we call XDAP.
I'm attaching the text to this e-mail to further the discussion on the
scope, limits, and possibilities of DSML.  I also think that OASIS may be
a better forum to express these ideas.  XDAP is not an LDAP-centric service,
but I thought it might be a good idea to mention it given some of the talk
about SOAP, SAML, etc..

You can also find the HTML version on the web:
http://www.cto.netsol.com/home.php?inc=projects.inc&content=projects/xdap/draft-newton-xdap-00.html
http://www.cto.netsol.com/home.php?inc=projects.inc&content=projects/xdap/draft-newton-xdap-domdir-00.html
http://www.cto.netsol.com/home.php?inc=projects.inc&content=projects/xdap/draft-newton-xdap-ipdir-00.html

Here is a brief summary of the drafts:

XDAP itself is a light framework for specifying search and access operations,
and for expressing search continuations and entity references.  It utilizes
XML namespaces and XML schemas to accomplish this.  We have provided two
directory service "applications" that use XDAP.  DOMDIR is an XDAP directory
service for querying DNS domain name registration data, and IPDIR is an XDAP
directory service for querying IP network administration data.  We even
thought of publishing a draft on using DSML on top of XDAP.

Our motivations behind XDAP:

Before attempting XDAP, we seriously looked at LDAP to build a better "whois".
And while we readily admit that LDAP is by far more feature rich than the
whois protocol, we found it did not solve all of the problems associated with
domain names and IP addresses, especially as it would relate to IP registries
and routing administration.

You can find our work on this at http://www.ldap.research.netsol.com/ .

Briefly, here are some of the goals we were after with XDAP, mostly gained
from our learning experience with LDAP:

o The strict naming hierarchy of LDAP does not apply to all types of directory
  services.  This is especially true when dealing with IP networks divided
  on class-less boundaries (CIDR).  Therefore, the ability to specify the
  hierarchy based on the application of the service is desirable.

o Though LDAP provides for a structured query grammar, some searches are
  deemed expensive or not allowed at all for business reasons (there is a
  terrible amount of third-party data-mining that goes on in the whois
  circles).  Once we disabled some LDAP searches, it became clear that not
  only did we have to publish which searches were allowed, but special
  clients talking LDAP would have to be created to correctly search the
  service.  Therefore, it makes sense to expressly define the searches
  allowed per type of directory application.

o One of our biggest headaches with LDAP deals with referrals, which we
  made a central theme to our project to deal with the differences between
  the data stored in a domain registry and the various client domain
  registrars.  It seems no two LDAP clients (command line clients at least)
  act the same way in dealing with LDAP referrals.  In addition, because
  LDAP specifies that referrals are always returned if in scope regardless
  of the search filter, we encountered situations where a search against
  an LDAP server would produce only referrals due to time and result limits.
  Our conclusion was that there is a difference between a search continuation
  and an entity reference.  Also, the specified directory application should
  be able to determine when they are in or out of scope.

Anyway, I hope this provokes discussion and that you consider some of the
ideas presented here.

-andy

-- 
Andrew Newton
VeriSign Applied Research