[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC