OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dsml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Another approach to an XML directory service


I find that http://www.research.netsol.com/Projects/xdap_intro.htm works
better than the links given.

ciao,
Christine Tomlinson

> -----Original Message-----
> From: Andrew Newton [mailto:anewton@research.netsol.com]
> Sent: Monday, June 18, 2001 10:31 AM
> To: dsml@lists.oasis-open.org
> Subject: 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/xda
p/
> draft-newton-xdap-00.html
>
http://www.cto.netsol.com/home.php?inc=projects.inc&content=projects/xda
p/
> draft-newton-xdap-domdir-00.html
>
http://www.cto.netsol.com/home.php?inc=projects.inc&content=projects/xda
p/
> 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
> anewton@research.netsol.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC