Re: protocol-22 comments

["Jim Sermersheim" <jimse@novell.com>]

I'll plan to update 4.1.10 to read:
 
>The referral result code indicates that the contacted server cannot or
will not perform the operation and that one or more other servers may be
able to. Reasons for this include:
>
>-	The target entry of the request is not held locally, but the
server has knowledge of its possible existence elsewhere.
>-	The operation is restricted on this server -- perhaps due to a
read-only copy of an entry to be modified.

I'll also update 4.5.3 and 4.5.3.1 (search result references) to
calrify that either referral or soSuchObject is returned depending on
the servers knowledge of the target object.

Finally, I'll remove the original referral instructions from Add since
it was the only other operation to mention returning referrals.

Jim

>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 3/15/04 12:54:19 PM
>>>
Kurt D. Zeilenga writes:
>At 03:40 AM 3/13/2004, Hallvard B Furuseth wrote:

>> I just noticed an error in 4.1.10 (Referral):
>> 
>>> The referral result code indicates that the contacted server does
not 
>>> hold the target entry of the request.
>> 
>> I suggest:
>> 
>> A referral indicates that the contacted server cannot perform the
>> operation, but one or more other servers can.
>
> Right, referrals are be returned when the server chooses to
> refer the operation to another server.

s/cannot/cannot or will not/ in my suggestion?
Then server A can refer to B and C, and the client chooses B which
refers to A and C, so the client detects a loop and gives up even
though
C might be willing to perform the operation. Whether we add "cannot or
will not" or not, maybe the text should alert implementors to this
possibility.

-- 
Hallvard