rescodes last call comments

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

It's my general opinion that this work is not progressable in
it's current form.  Below I will provide a number of comments
which demonstrate the need for additional work.  I also note,
due to time constrainsts, I was not able to fully review
all sections of the specifications.  It is likely that other
sections need work as well.

First, a couple of general comment:

I am also concerned that this document creates a third definition
of result codes.  We need one.  I believe this document should
not be progressed as a separate document.  It should be incorporated
into a yet to be drafted RFC2251bis document.  This document
would not only clarify rescode definitions and usage, but clarify
the relationship to X.500 rescodes.

As an update to RFC 2251, I find the language quite unclear as 
what sections it updates.  The document needs to more exacting
in its language (or better yet, incorporated directly into
a 2251bis document).

I would also like to include as part of my last call comments
resent discussions regarding compare results.  I believe this
draft should address issues outlined in that discussion.

some Section by section comments:

1.1:

The document refers to X.500 specifications, but like RFC 2251,
fails to state which X.500 specifications are MUSTs.  In also
doesn't clarify how implementators are to handle conflicts
between RFC 2251 and X.500 nor itself and RFC 2251 and X.500.
If this document does not change the MUST X.500 clause, then
X.500 requirements must be treated as overruling any MAY or
SHOULD.  That is, the MUST X.500 has higher precedence than
any MAY or SHOULD within this document (or 2251).

1.1 suggests that MUST X.500 means there are two types of
LDAP servers.  This, I feel, is a dangerous assertion.  There
should only be one type of LDAP server, one that implements the
LDAP protocol per the specification.  I believe the statement
more implies that LDAP servers may behave differently in many
respects, but must provide the same interface.  This document
clarifies the interface, it should alter or disallow any
behavior not allowed by RFC 2251.

1.1 states:
   Unless the server
   implements X.500 style access controls LDAP-only servers should only
   return noSuchObject when the target entry is not found until such
   time that similar access controls are defined for LDAP only servers.

I believe that an LDAP server may return noSuchObject even when
the server holds the object regardless of whether it implements
X.500 access controls.  That is, there is no difference of interface.

In general, I find the 1.1 fogs more issues than it is intended
to clarify.  I suggest axing most of this section.

Section 5.

This document states: "LDAP v3 [RFC2251] defines the following result
message for return from the server to the client...".  This leaves
the definitive version of LDAPResult in RFC 2251.  This means that
this document cannot "provide a central, unified source for these
definitions" as any specification needing to update LDAPResult
would likely have to update 2251 and this specification.  However,
I would object to moving the definitive version of LDAPResult out
of 2251 (or its successor).


Section 5.1.4:

s/set of URLs/sequence of URIs representing references/

5.2.1.1 other(80)

This result code should be used to indicate an implementation
specific error condition.  Clients are likely not able to
take corrective action when this result code is returned.

5.2.2.4.7 busy(51)
5.2.2.4.9 unwillingToPerform(53)

Should provide statement regarding difference between unwillingToPerform
and busy.  That difference being that busy indicates the server
is temporarily unwilling to perform the operation.


5.2.2.1.3 inappropriateMatching(18)

Under what circumstance can this resultCode be returned
by an LDAPv3 search operation?

This resultCode is generally returned compare and modify
where the operation requires an equality matching rule and
none is provided by the attribute type.

5.2.2.1.4 constraintViolation(19)

Can this be returned by compare when the asserted value
violates a constraint?

5.2.2.1.6 invalidAttributeSyntax(21)

compare should be allowed to return this result code when
the inserted value violates syntax.

5.2.2.2.1 noSuchObject(32)
   If the LDAP server is a front end for an X.500 DSA then noSuchObject
   may also be returned if discloseOnError is not granted for an entry
   and the client does not have permission to view or modify the entry.

This should be genericized... any LDAP server may do that.


5.2.2.3.6 invalidCredentials(49)
   This error code is returned if the DN or password used in a simple
   bind operation is incorrect, or if the DN or password is incorrect
   for some other reason, e.g. the password has expired.

typo.. or if the DN AND passward ARE CORRECT...

5.2.2.4.1 operationsError(1)

This result code should be used to indicate that request
cannot be processed due to improper sequencing with other
requests.  This may be returned by non-bind requests when
a multi-step bind is in progress.  The client should
complete the outstanding sequenced operation and then
may reissue the failed request.

5.2.2.4.2 protocolError(2)

Note that certain malformed requests result should result
in a notice of disconnect and not a protocolError response.
Note also that protocolError(2) may be returned as the
result of a bind when the server does not support the
requested protocol version.