The case for XLDAP

* XLDAP is to DSML as LDAP itself was to DAP, a quicker, more efficient way to access, modify and maintain the data

There's still one or two issues to bring up from last month's European Identity Conference, which I want to get to this week -- one from a panel I was on and another from one I wasn't on.

Kuppinger-Cole senior analyst Sebastian Rohr inveigled me to sit on his panel "Directory Services in the Cloud" where, among other issues, we explored exchanging directory data in an XML-enabled world. I rashly suggested that Directory Services Markup Language (DSML) was sufficient for this purpose. But I didn't count on Australia's Andrew Ferguson to be lurking behind a screen where I couldn't see him.

Ferguson was a founder of Oz's eB2Bcom and is currently a director of it's spin-off, eNititatives. More to the point, he's a driving force behind the Internet Engineering Task Force's XLDAP proposal.

Ferguson challenged my statement that DSML was sufficient, so I asked him to come up with some evidence. He did.

"DSML vs XLDAP: A comparison of XML-based directory protocols" is a white paper that Ferguson and his colleagues created specifically to show the pros and cons of XML-enabled LDAP. You can get a copy (but you'll need to register first) at the ViewDS Web site. But I can outline the major points.

The paper points out that DSML was created to meet the following objectives:

1. Provide a method that expresses query and update operations, and their results, as XML documents.

2. Allow greater accessibility of directory services to devices that don't support LDAP.

3. Allow greater accessibility of directory services through firewalls.

4. Allow XML programming tools to access directory services without requiring LDAP-specific capabilities.

XLDAP has the same four objectives, but adds "Allow all of the above capability to operate natively with Directory Services that are used to store XML."

Why is this significant? The paper notes:

"On one hand we have DSML, which requires a Base64 encoding of a BER encoding of a value of an ASN.1 type. Unfortunately this requires DSML-enabled clients to understand the ASN.1 type of each LDAP control, be able to BER encode a suitable value and then Base64 encode the value. DSML clients can't get away with using the same value over and over either, because they must be able to decode the BASE64 and BER of the responses they receive... On the other hand, the entire LDAP control is represented in XLDAP in natural and readily accessible XML."

That's it in a nutshell -- XLDAP is to DSML as LDAP itself was to DAP, a quicker, more efficient way to access, modify and maintain the data. Read the paper and see if you don't agree.

From the event calendar:

June 29 -- "Access Change Management Framework: Streamlining Access Delivery While Embedding Governance" (Webinar) with Aveksa's Deepak Taneja and the Burton Group's Ian Glazer. Register at

Learn more about this topic

IETF: No consensus on IPv6 NATs

DNS, net neutrality up for debate at IETF meeting

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2010 IDG Communications, Inc.