DSML 2.0 requirements

[rweltman@netscape.com (Rob Weltman)]

  To kick off the requirements discussion, I'll summarize (and augment) some thoughts that I presented at the phone conference yesterday.

- There are fairly well-established APIs and SDKs for accessing LDAP data for most of the popular programming languages: C/C++, Java, perl, TCL, python, VB. There are many applications that are LDAP-aware and are using these SDKs and APIs. Those applications and their owners are not the target audience for DSML 2.0.

- There are many more applications that are clueless WRT LDAP but which would benefit from access to user (and potentially other) information stored in a directory. XML is the only real contender for a common data format for information exchange across a wide range of application areas, and I expect that most new applications with wide-ranging data interchange requirements (and even many without such strong requirements) are or will be XML-aware. These applications and their owners are the target audience for DSML 2.0.

- DSML 2.0 should make it as painless as possible for non-LDAP-aware applications to access (read/create/update/delete) information which is managed by LDAP servers.

- We discussed the concept of representing each LDAP protocol operation in XML. I am not convinced at this point that such an approach would provide all the benefits to non-LDAP-aware clients that the XML environment makes possible. I don't know how realistic it is, but an ideal XML view of the LDAP world would be as just another XML document, where XLink is used to identify directory entries (roots of subtrees) and XPath to query and extract entries and attributes within a subtree.

- XML/DSML is not a transport protocol. One can anticipate exchanging DSML documents over HTTP, SMTP, and other transports. In many cases a user will want to take advantage of the authentication and privacy provided by the transport layer, and DSML is oblivious to the carrier.

- LDAP deployments generally require some form of authentication (common methods are simple bind with username and password, SASL for mechanisms such as kerberos or digest MD5, and certificate authentication) after establishing a connection and before performing any operations. DSML 2.0 must allow for authentication of the client to the server. This can be accomplished either externally (DSML operates on an authenticated LDAP connection which has been established through some other means) or expressed in DSML as conditions/configuration for the connection.

Rob