Re: resultCode Overloading / New result codes

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:30 PM 3/8/01 -0800, Michael Armijo wrote:
>The requirements of new result codes needs to be discussed so we can progress drafts that either define new result codes, or are waiting on progression of drafts that define result codes.

IIRC, this issue was discussed in the context of both the Control
Error I-D and Cancel Openeration I-D just last month.  I also recall
there were discussions in regards to result code additions in the
context of the LDAP C API I-D which might be of interest.

I'll reiterate my personal opinions below.

>A couple of questions immediately come to mind.  How will new result code values be assigned? 

By extension (not update) of the protocol.   I'd prefer that
such extensions be pursued on the Standard Track so that there
will some community review to reduce chance of conflicts being
published.  Optionally, an IANA registry could be established.

>What effect do new result codes have on existing operations and controls?

Zero.  Only those extensions which are in effect though
appropriate negotiation by the protocol peers have any
impact upon the protocol.  That is, only if the negotiated
extension calls for the return of a "new" result code shall
that "new" result code be returned.

I note though that in the event that an implementation were
to inappropriately return a new result code, all client
implementations are bound by RFC 2251, 4.1.10:
   If a client receives a result code which is not listed above, it is
   to be treated as an unknown error condition.

>I would like to start discussing these issues before the upcoming meet so we can have an updated version of the LDAP Control Error draft and/or the VLV draft as soon as possible.

I suggest we establish a precedence by progressing one or more standard
track documents which define new result codes... 

Kurt