Comparison (DAML, DirXML, XMLDAP) - Text and MS Word Version

[Gavenraj Sodhi <GSodhi@access360.com>]

Title: Comparison (DAML, DirXML, XMLDAP) - Text and MS Word Version

I did not know the uploading of a PDF will changing to a bin file format.  For the previous file, please open with Adobe Acrobat.  I am also including the Word version under the text below.

Comparison of Technologies Submitted for the DSML 2.0 Specification

Draft

April 4, 2001

Prepared By:

Jeff Bohren, Access360

Introduction
Directory Services Markup Language (DSML) is a proposed standard for representing LDAP in XML. The first version (1.0) of DSML defined how to represent LDAP schema and data, but did not address LDAP operations and protocol issues.

This paper is a summary of three technologies that have been submitted to the DSML organization for consideration as the next generation (2.0) for the DSML standard.

Note: The author of this paper is one of the co-authors of the DAML specification, and is much more familiar with DAML than the other evaluated technologies.

Directory Access Markup Language (DAML), Submitted by Access360
Access360 has offered the DAML specification to DSML.org for consideration as part of the DSML 2.0 specification. The DAML specification was defined by Access360 as the protocol for communication to agents. To be as standards based as possible, the DAML syntax matches the LDAP syntax very closely, but is represented as XML text rather than BER encoded data (which is how LDAP is represented). Also, the DAML specification was designed to leverage the DSML 1.0 specification.

DIR-XML, Submitted by Novell
Novell has submitted a XML specification (NDS-DTD) that is currently part of the Dir-XML product for consideration as part of the DSML 2.0 specification.  The NDS-DTD is designed mainly to support the concept of an LDAP join engine (system that keeps data from 3^rd party data sources synchronized with it's representation in an LDAP directory).

Although some parts of the NDS-DTD could be used independently, the XML definitions assume that this is being used in the Dir-XML product in conjunction with the Novell Directory Server.

XMLDAP, Submitted by iPlanet
iPlanet has submitted the XML schema from the iPlanet XMLDAP Directory Gateway (iXDGW) product to DSML.org for consideration as part of the DSML 2.0 specification. The XMLDAP, unlike DAML and Dir-XML, does not define an XML DTD. Instead, it defines a generic template specification that can be used in conjunction with their product to transform representation of data in XML from one form to another. They then define a default implementation of that transformation language that can transform LDAP like data. The part that is applicable to DSML is the eXstensible Template Language (XTL) with an associate set of tags for representing LDAP.

The transformation mechanism defined in the iXDGW for handling LDAP is designed primarily to support the embedding LDAP operations in a Web Page.  Although this could be used independently for generic LDAP operations, it requires the use of a transformation mechanism that is unnecessary in most cases.

Comparison Matrix

        DAML (Access360)        NDS-DTD (Novell)        XMLDAP (iPlanet)       
LDAP Schema Representation      Yes¹    Yes     No²    
LDAP Data Representation        Yes¹    Yes²    Yes    
Distinguished Names (DNs)       Yes¹    Partial³        Yes    
Bind Request    Yes     Implicit⁴       Implicit⁴      
Bind using SASL Yes     No      No     
Add Request     Yes     Yes     Yes    
Modify Request  Yes     Yes     Yes    
Search Request  Yes     Yes     Yes    
Search Scope Control    Yes     Yes     Yes    
Search Size/Time Limit Control  Yes     No      No     
Recursive Search Filters        Yes     No⁵     Implicit⁶      
Rename Request  Yes     Yes     No     
Move Request    Yes     Yes     No     
Compare Request Yes     No      No     
Extended Request        Yes     No      No     
Message ID      Yes     No      No     
Standard LDAP Error Codes       Yes     No      No     
Incomplete Modifications Returned       Yes     No      No     
Uses DSML 1.0   Yes     No      No     
Matches DSML 1.0 Naming Convention      No      Yes     Yes    
Product Independent     Yes     No⁷     No⁸    
Vendor Independent      Yes     No⁷     Yes    
Protocol Independent    Yes     Yes     Yes    

1.      DAML uses DSML 1.0 syntax for this feature.
2.      No direct support for schema definitions, but LDAP Schemas can also be defined as LDAP data.
3.      The NDS-DTD requires mappings be created between DNs as they are known to both the client and the server.
4.      Instead of being an explicit operation, the bind request is always part of another request. The disadvantage of this is that when doing multiple requests in a single connection, the bind information must be sent with every request, which not required in LDAP.

5.      The NDS-DTD only allows filters to be defined as a flat list of attribute values assertions, rather than a recursive list of filters that LDAP allows.

6.      iXDGW represents search filters as a string, which allows for recursive filter definitions, but puts the onus on the server to parse the filter text to support this.

7.      Although some parts of the NDS-DTD could be used independently, the top-level of the XML definition assumes the use of the Novell Dir-XML product and the Novell Directory Server. Additionally, the way the LDAP operations are represented implies the use of a join engine with features similar to Dir-XML.

8.      Although not explicitly tied to the iXDGW product, the mechanism for defining LDAP operations requires the use of XTL or an equivalent transformation capability.

Conclusions
Of the three technologies considered, only DAML is designed to address the specific issue of representing LDAP schema, data, and operations in XML. The NDS-DTD was designed for use with an LDAP Join Engine and the IPlanet XTL and XTL LDAP tags were designed to combine LDAP operations in Web pages. While these are both useful ideas, they should be considered outside of the scope of the DSML organization.

DAML was also the only one of the three technologies that made use of the DSML 1.0 schema. DAML was designed from the start to be a supper-set of DSML 1.0, and was designed to address the issues that DSML 1.0 did not cover. The DAML specification was not, however, written using the same naming convention (all lower case with hyphens), as was DSML 1.0. This was done to conform to the naming conventions used more frequently in Access360 for defining XML (mixed case, no hyphens).

DAML was designed to support all of the features found in the LDAP V3 specification, as defined in RFC 2251, where as the other technologies only support the most commonly used features. 

DAML was designed to be completely vendor and product neutral. Although it is used by Access360 for enRole server to agent communications, there is nothing in the specification that is tied to that use. There is also nothing in the DAML specification, other than the copyright header, that refers to Access360 or any Access360 products.

Of these three technologies DAML is the closest fit for where DSML is currently focused in the 1.0 specification, and for where DSML will likely be focusing in the 2.0 specification. If the scope of DSML 2.0 is expanded to include other issues besides supporting standard LDAP schema, data, and operations, then one of these other technologies may be more applicable.

<<compare.doc>>

-Gavenraj Sodhi
gsodhi@access360.com

compare.doc