FW: DSML 2.0 requirements

[James Tauber <JTauber@bowstreet.com>]

-----Original Message----- 
From: Andy Harjanto 
Sent: Sunday, September 10, 2000 6:18 AM 
To: 'dsml@lists.oasis-open.org' 
Subject: RE: DSML 2.0 requirements 


[Resend] 

-----Original Message----- 
From: Andy Harjanto 
Sent: Thursday, September 07, 2000 10:40 PM 
To: 'Rob Weltman'; 'dsml@lists.oasis-open.org' 
Subject: RE: DSML 2.0 requirements 


Rob, thanks for the meeting minutes. 


I like the idea of moving away from defining new APIs, security, and general
RDBMS access. 

But IMHO, we should focus DSML 2.0 on a well-bounded set of requirements.
The primary goals should be: 

        (1) Enable a wider variety of clients to reach directories 

        (2) Enable clients to leverage XML programming paradigms to 
            store and process directory data 

The primary non-goal should be: 

        (3) Enable clients that were designed to process other sources of
XML 
            data to also reach directories 

The non-goal (3) was a core design principle of DSML 1.0. It a) makes it
easy to achieve a design that exposes the full information available from
the directory, rather than "dumbing down" to some hypthetical common
denominator, and b) bounds the problem to allow us to make progress far more
quickly. We must not abandon this core principle.

The clear consequences of our goals and non-goals are: 

        (A) DSML 2.0 specifies a protocol, not an API set. Standard
protocols, 
            not API sets, are what give reach. 

        (B) DSML 2.0 is capable of expressing all LDAP operations (modify,
add, 
            delete, modrdn, search) with full fidelity, including controls
and extended 
            operations. 

Though I like XPath very much, I don't see it as a way to add value to DSML
2.0. There is no 1-1 mapping between LDAP query sematics and XPATH. We could
consume months attempting to find the "best" mapping to use, and still end
up subtracting value by hiding some directory capabilities from the client.
Let's maintain our focus and we'll get a useful specification soon. Later we
could develop a DSML 3.0 with more ambitious goals if there is demand for
that.



-----Original Message----- 
From: Rob Weltman [ mailto:rweltman@netscape.com
<mailto:rweltman@netscape.com> ] 
Sent: Tuesday, September 05, 2000 6:01 PM 
To: 'dsml@lists.oasis-open.org' 
Subject: Re: DSML 2.0 requirements 


  We discussed this message and the email discussion which followed, along
with other requirements, in the DSML phone conference today (9/5/2000).
These are the notes I took:

- There was agreement that the goal of DSML 2.0 is not to supplant existing
LDAP protocol/API/SDK usage, but to make directory data accessible to the
community of developers and applications that are or will be XML-aware.

- There was agreement that the goal of DSML 2.0 is to support access to LDAP
data sources and not to be a generalized framework for access to other types
of data sources (e.g. RDBMS).

- We should look into accessing a directory as a DOM, using XPath and other
standard XML tools. Accessing the virtual contents of a directory as a DOM
is to be distinguished from the XML serialization of directory data (as in
DSML 1.0).

- For establishing authentication and also for establishing a connection to
an LDAP server, Processing Instructions (PIs) were suggested. That is more
for the specification than for the requirements document, though.

- The following were raised as requirements and non-requirements: 

  - It is not a requirement that DSML 2.0 be backwards compatible with DSML
1.0 

  - It is a requirement that there be some way to determine the version of
DSML being used (but the means to determine it will be defined in the
specification)

  - It is a requirement that it be possible to perform all LDAP operations
and pass all LDAPv3 additional information (controls, extended operations)


  James wasn't on the line for these discussions, but hopefully the above
(and below) will provide material to start writing the formal requirements
document, and also to continue the discussion per email.

Rob 



Rob Weltman wrote: 

>   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