[Ietf-not43] First draft on Relay bags in FIRS

[Peter Gietz]

Eric,


Eric A. Hall wrote:

> on 8/15/2003 11:30 AM Peter Gietz wrote:
> 
> 
>>Eric: You being the only one preferring the URL solution, can you live
>>with this? Or do you see any serious issues?
> 
> 
> Using the control data seems fine to me, with one caveat.
> 
> 
>>Referrals with a Relay Bag MUST be submitted inside the controlValue 
>>field as specified above, without redundantly storing the referrals in 
>>the SearchResultReference construct.
>>If only referrals with Relay Bag are submitted, the server MUST store a 
>>dummy-referral in the SearchResultReference construct. The dummy 
>>referral, which MUST be ignored by the client, is:
>>    ldap:///
>>"
> 
> 
> I don't see the value in omitting the referral data in those cases where
> the relay bag is also provided. That would introduce additional complexity
> for servers (additional logic), mucks with the protocol, and doesn't seem
> to provide any real value since we're talking about a protocol extension
> that the client has to explicitly support in order to request. Remember
> that we have a high probability of changing this as well, and it may be
> necessary to switch to a combination of referral data plus control data,
> and that will be unnecessarily difficult if servers have changed behavior
> to support this draft.
> 
> So in summary, I would be happier if the text just said to ignore the
> referral data if a relay bag is provided, and did not muck with the rest
> of the message contents or protocol.
> 

Isn't that unneccessary redundancy? The client has to go through both 
lists anyway, since referrals without relay bag will only be found in 
the LDAP standard construct.

With your proposal the client has to do the following:

Get the referrels from the LDAPSearchReference construct
for each referral
   check, if the referral is stored in the control as well,
      if so use the relay bag when following the referral
      if not just follow the referral

This means you have to do a search of the referrals found in the relay 
bag data, which might be more costly than in my proposal:

The algorithm for my proposal would be:

Get the referrels from the LDAPSearchReference construct
if first referral equals ldap://
    done with this part of referrals
else
   for each referral
      follow the referral
Get the control data
   for each referral
      follow the referal using the relay bag


The difference in complexity is there but might not mean too much 
performancewise. Thus I don't have very strong feelings, and if the 
group agrees with Eric, I have no big problem following his lines.

Cheers,

Peter



-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: peter.gietz at daasi.de
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________