Re: Changes to {C}LDAP ASN.1

Tim Howes <tim@terminator.rs.itd.umich.edu> Sat, 20 November 1993 07:01 UTC

Message-Id: <199311200531.AAA22101@terminator.rs.itd.umich.edu>
To: Simon E Spero <ses@tipper.oit.unc.edu>
cc: osi-ds@cs.ucl.ac.uk
Subject: Re: Changes to {C}LDAP ASN.1
In-reply-to: Your message of "Thu, 18 Nov 93 15:23:57 EST." <9311182024.AA01407@tipper.oit.unc.edu>
Date: Sat, 20 Nov 93 00:31:34 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tim Howes <tim@terminator.rs.itd.umich.edu>

> From:    Simon E Spero <ses@tipper.oit.unc.edu>
> To:      ldap@umich.edu, osi-ds@cs.ucl.ac.uk

> As promised, here are my changes to the LDAP asn for "cldap++". 

Hi Simon.  Thanks for posting this.  It looks interesting.  I've
got a few questions.

> 	3) Add new protocolOp grouped Request and grouped Response; 
> 	   There are several situations, mostly to do with multicast, when 
>            it's useful to be able to ship binding information with another
> 	   request whilst using CLDAP. a grouped request just wraps a 
> 	   sequence of ldapMessages into one message.

Can you explain in a little more detail what this is for?

> 	4) Add optional bindingTarget to the BindRequest. This value is of 
> 	   type URL; the URL specifies a server to execute the requests against.
>            This makes it easier to handle referrals in a hetrogeneous director
> 	   mesh, as gatewaying becomes simpler. 

So this is a clue for the LDAP server to know where to go for the info?

> 	5) Add new value to scope enumeration: namedHierarchy (3). 
> 	   Add new element to searchRequest - hierarchyName.
> 	   Add new enumerated type "sendReferrals" indicating relative 
> 		preferences for referrals vs chaining.

I don't really get the namedHierarchy and hierarchyName stuff.  It's
for when you want to search a centroid instead of the ldap (x500)
directory, right?  How does the ldap server translate the attribute type
into a centroid location, or does it hold it locally, or is it specified
in a bindingTarget URL?

> 	   I would like to change the definition of search response to allow
> 	   multiple values to be returned; is there a reason why this is
> 	   restricted to a single object?

Multiple values (entries) are allowed to be returned, they just come
back in separate messages.  Do you mean you want to be able to combine
multiple search entry responses in a single response?  The reason it
was split up the way it was is to allow streaming of the results (client
can start processing the first part of a large result before the whole
thing comes in).  We could have allowed it either way, but we wanted
to make it simple and picked one (that allowed the streaming functionality).
I didn't find the one entry at a time thing a hardship when implementing.
Our ldap api lets the caller specify whether the results are wanted one
at a time, or all at once.                                 -- Tim

Changes to {C}LDAP ASN.1 Simon E Spero
Re: Changes to {C}LDAP ASN.1 Tim Howes
Re: Changes to {C}LDAP ASN.1 Simon E Spero
Re: Changes to {C}LDAP ASN.1 Steve Kille