Re: File binding straw man

[rowley@netscape.com (Pete Rowley)]

Title: Message

Jeff Parham wrote:

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

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.

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

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