Fw: DSML 2.0 requirements

["dugan(ibm)" <dugan@austin.ibm.com>]

My comments below.

-M
----- Original Message -----
From: Rob Weltman <rweltman@netscape.com>
To: <dsml@lists.oasis-open.org>
Sent: Wednesday, August 30, 2000 1:46 PM
Subject: DSML 2.0 requirements


>   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.

I'd like to suggest that most of the programs written in these languages
will either produce dsml or parse it using their "native" directory support
to process dsml. I'm uncertain how we can state that the programmers in
these languages would not be a target for 2.0; I'd anticipate that this
group would be a big target  audience since the bulk of dsml processors
would probably fall out from this group.

>
> - 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.

Perhaps allow "power" applications to perform the functions they need to do
(ie, ldap controls,
extensions)? If the spec is too weak a large group of developers will
probably abandon it since
it won't satisfy their needs.

>
> - 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.

I'm unclear why it can't do both. A directory agnostic piece that non-LDAP
aware apps can take advantage of and perhaps a directory specific component
for apps that need access to all of the underlying directory's features.

>
> - 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
>
>