OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dsml message

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


Subject: RE: File binding straw man


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




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


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


Powered by eList eXpress LLC