Re: File binding straw man

[Shon Vella <SVELLA@novell.com>]

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