dsml message

Subject: Re: File binding straw man

From: rowley@netscape.com (Pete Rowley)
To: Jeff Parham <jeffparh@windows.microsoft.com>
Date: Tue, 09 Oct 2001 16:16:16 -0700

The tool writes and reads valid LDIF files which are identical, however it is the LDIF format which lends itself to this duality not the invention of the tool. The key difference is in not distinguishing between whether the file is to be used for input or output. Extrapolating: this difference in input file from output file means the client must be more complex (than if this transform were not necessary) in order to perform an operation such as transfering a set of entries from one server to another. This might be a compromise which is deemed acceptable (given that the dsml document can do more than just represent data and so *reduces* complexity in some cases), but nonetheless it is a compromise over the LDIF format.

Jeff Parham wrote:

4AEE3169443CDD4796CA8A00B02191CD0320BE17@win-msg-01.wingroup.windeploy.ntdev.microsoft.com">

Thanks for raising that point.  The capability to generate an LDAP
search and produce a valid LDIF import file is most often provided by a
command-line tool.  Though this command-line tool is in many cases the
same tool that can be used to import the file, the ability to export a
file that can be used for import is not really a feature of LDIF -- it's
a feature of the tool.  (Note that LDIF provides no capability for
expressing searches, for example.)

In DSML 2, this feature could be implemented in the same way -- as a
feature of the tool.  This feature might be even easier to implement
with DSML 2, given that one could write a transformation of a
DsmlBatchResponse containing SearchResponse elements into a
corresponding DsmlBatchRequest.  There's no standard language an LDIF
app writer can use to make the analogous transformation of LDAP messages
into an LDIF file.

Alternatively, the transformation could be per
formed externally to the
DSML 2 tool.

In any case, as far as I can tell LDIF offers no advantages over the
DSML 2 file binding in this regard.  (But please chime in if I've missed
something.)

-J

-----Original Message-----
From: Shon Vella [mailto:SVELLA@novell.com] 
Sent: Tuesday, October 09, 2001 3:45 PM
To: rowley@netscape.com
Cc: dsml@lists.oasis-open.org
Subject: Re: File binding straw man


I have the same concern as Pete. We should at least talk about this
issue.

Shon Vella
Software Engineer, Consultant
svella@novell.com
Novell, Inc., the leading provider of Net services software
www.novell.com

Pete Rowley <rowley@netscape.com> 10/08/01 08:24PM >>>



Jeff Parham wrote:

Below is a straw man for the file binding -- comments welcome.

One of the useful features of LDIF is that pulling entries from a server

and creating a file will create an input that can be used to load that 
set of entries into a server.  Distinguishing between input and output 
in a file binding seems limiting, making a translation to necessary. 
 Though I can quite see why that is less than trivial to avoid.

Thanks,

-J

----

7. File Binding

The file binding is intended to be an alternative to the LDAP Data
Interchange Format (LDIF) described by RFC 2849 (
http://www.ietf.org/rfc/rfc2849.txt?number=2849 ). Its primary
advantages over LDIF are:

* Use of XML, which is more natural for many clients to generate
and to parse than LDIF. Also benefits from the comparative
wealth of tools.
* Formalization of output on error conditions, such as in the
event the directory server is unavailable or the directory
server returns an LDAP error.

With the file binding, the DSML 2 "server" is a command-line program,
as is typical for LDIF. The client that invokes the "server"
program runs on the same computer as the server, and the input and
output of the server
are files consisting of DSML 2 documents. The
DSML 2 server uses LDAP, another DSML 2 transport, or some other
mechanism to communicate with the directory service, which may be
running on the same computer or a different computer.

The top-level document for the input file is an element of type
DsmlBatchRequest with name dsmlBatchRequest. The top-level document
for the output file is an element of type DsmlBatchResponse with name
dsmlBatchResponse.

The file binding accepts DsmlValue elements that utilize the anyURI
indirection. The contents of the URIs are evaluated by
the command-line program. A minimal implementation supports URIs of
type file, which are evaluated using the security context associated
with the process running the command-line program. Individual
implementations may support additional URI types.

[Jeff Parham] The file URI type seems to be the most critical. If wechoose to mandate support for other URI types, we need to determine
under what security context the URIs are evaluated. For example, if a

an ftp URI type is specified, what credentials are used to establish
the ftp session? (The same questions can be asked of the SOAP binding

URI types.) In LDIF, only file URIs were mandated -- it seems
reasonable that one could assume all platforms could support accessing

files using the security context of the LDIF program, which doesn't
seem true for other, inherently less federated transports.

By default the file binding authenticates to the directory using the
user identity with which the command-line program was invoked.
Individual implementations may support or require specification
of explicit credentials on the command line.

[Jeff Parham] Do we want to take interoperability to the level of
defining the name and mandatory command-line options for the program?

I'm guessing not but would like to know others' opinions.

-- Pete Rowley Developer Netscape Directory Server

References:

RE: File binding straw man
From: Jeff Parham <jeffparh@windows.microsoft.com>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC