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: moving forward with proposals

On Wed, Jun 20, 2001 at 03:41:30PM -0400, John McGarvey wrote:
> Today, LDAP applications are written to work with specific LDAP servers.
> An application written for one LDAP server implementation may fail to work
> with another, primarily because schema and namespace are not standardized.
> In fact, applications written for the same LDAP server implementation may
> not coexist, or may coexist with minimal reuse of directory data, because
> of different naming assumptions in the applications.

I agree with your assessment of about LDAP applications.  However, I don't
know if seeking the Holy Grail of the universal directory client is
possible given today's technologies.  XML is great, but I don't see it
providing the answer to that problem.  JNDI goes along way in dealing
with this as well, but it is just an API and not a protocol.

> In this context, XDAP is an interesting proposal, as it is independent of
> specific schema, namespace, or directory technologies.  XDAP schema are
> provided for DNS information.  If the XDAP schema were extended to the most
> common directory objects, especially users and groups, and were also
> extended to include create, modify, and delete operations, it could enable
> the creation of fully interoperable directory applications.  On the other
> hand, there are many LDAP operations that can't be performed using XDAP,
> unless it is extended, and there is no bound on the list of extensions
> needed.  At least with the Microsoft and Access360 proposals, the full
> capability of the directory would be accessible.
> I suggest that what is needed is a hybrid proposal, supporting all LDAP
> operations and objects, but also providing, as a mandatory part of the
> standard, operations on a subset of the directory objects, independent of
> specific schema and namespace.  This subset would include search, create,
> modify, and delete on users, groups, and a small list of other object
> classes.  Applications built using this subset would work with any
> directory implementing DSML 2.0.  Intelligence to map between schema and
> namespace differences would reside, not in the client or device, but in the
> DSML gateway.
> Is there interest in this approach?

That is an interesting idea.

Why can't an XDAP-base layer simply define create, modify, and delete the
way it does search?  Then an LDAP-layer would extend the meaning for its
LDAP specific uses?  The important thing that the base accomplishes is
the discussion of different directory types, how to identify them, and
how to issue referrals between them.  The operations such as search,
create, and delete are all specific to the directory type.

> John McGarvey
> (opinions expressed are my own)


Andrew Newton
VeriSign Applied Research

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

Powered by eList eXpress LLC