Re: Changes to {C}LDAP ASN.1

[Simon E Spero <[e-mail]>]

   Tim Howes <[e-mail]> writes:
>
>> 	3) Add new protocolOp grouped Request and grouped Response; 
>Can you explain in a little more detail what this is for?

This is to allow binding with CLDAP, so that that connectionless messages
can still be authenticated. CLDAP at the moment uses just anonymous binds, and
whilst not forbidding modification requests, discourages them. 

  There are several applications where there may be changes requests issued
several times a second (for example, when using the directory to manage a 
caching file store with name->location mapping. LDAP connections may be too
heavy for this; this seemed to be the simplest way of handling things. 
  The other alternative was to have a boundRequest which carried a 
bindRequest and one other message. However, that doesn't solve the problems 
of multiple results.



>> 	   mesh, as gatewaying becomes simpler. 
>So this is a clue for the LDAP server to know where to go for the info?

A very strong suggestion... The reason for suggesting this change is 
to handle some of the problems that may occur when dealing with referrals that
might point to hetrogenous directory servers. For example, if the client gets
a referral to a server that only supports Fat DAP, allowing the client to 
specify a gatewaying machine makes things easier. This change isn't 
strictly necessary, as the client could re-issue the request in chainonly mode;
this has the effect of requiring all servers to be able to dereference  
everything they issue referrals to.
 
>
>> 	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 should have used IA5String instead of  AttributeType ... sorry.

The namedHierachy bits are related to centroids, but not functionally 
independent; either can work without the other, but some synergy is lost. 
The named hierachies allow each directory server to be part of many
different directory "trees"; the effect is to let searching be constrained in
ways that help reduce the resulting cost-path to the objects found. 

 For example, the value "topology"  signifies a network relationship between 
two servers; if I search with the scope set  to "topology", then I should not
be offered referrals to servers only reachable via other hiearachies. This
is pretty hard to show without a slide... 

 Take the case of UNC, MCNC Concert,  Sun East (RTP), and Sun HQ.

Assume that Concert is manages the  Triangle Area  server; If someone at UNC
or Sun East searches for the nearest West Indian deli, the MCNC is obviously
the right server to move up to when doing a bottom up search if there are 
no matches on the local server. When a person at UNC starts looking for a 
copy of gnu-emacs, MCNC would also be the best upwards link. However, 
since  Sun East is on Sun's private network, moving towards MCNC would give
highly sub-optimal results (packets might have to cross the country twice).



>
>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
>I didn't find the one entry at a time thing a hardship when implementing.

It's not really a problem when doing LDAP plain and simple, but for CLDAP
it becomes a little trickier, as one can no longer use the message id to 
detect duplicate responses, etc.

Simon