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

[Andrew Newton]

Peter Gietz wrote:
> 
> the bag:
> 1.) is of unrecognized format (permanent failure): protocolError (2)
> 2.) contains unacceptable data (permanent failure): unwillingToPerform
>    (53)
> 3.) contains data that means processing is refused at this time
>     (transient failure): busy (51)
> 
>
[...snip...]
> If I hear no protest, I will align the draft along these lines.
> We could additionally specify apropriate errorMessages the server should 
> return along with the error code, which may contain FIRS specifics 
> without breaking the LDAP protocol.

As I said, interoperability would be aided by errors specific to the 
bags.  If current errors have overloaded meanings then how is a client 
to distinquish between them and how is a server operator to know which 
one to use?  Would the definitions in 2251 be deprecated?

> If people insist in defining new error codes for FIRS, we may want to 
> return them in a dedicated FIRS control and not in the resultCode field.

I'm not sure how this is better, but I'll take your word for it.

>> Finally, a question.  Is this one bag per referral or one bag per 
>> response/result set?
> 
> 
> 
> No, and this has implications for the relay bag: The searchresponse can 
> include an unlimited number of referrals but only one controlValue. That 
> is why I sort of asumed that the Relay Bag contains only general 
> information about the referring server and about what that server has to 
> say about the client (authentication status, etc.).
> 
> If the Relay bag has also to contain information about the referred to 
> server, we would have a problem here.

Perhaps creating a syntax for the controlValue that partitions the value 
as Strings of octets (or however it was defined) per referral, with each 
related to the referral either by key or index.

-andy