[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: protocol: compare operation
At 11:18 AM 1/6/2004, Jim Sermersheim wrote:
>Right, I'm not arguing that we shouldn't allow values other than comperTrue or compareFalse.
I took you statement as an argument for allowing compareFalse when
the assertion was Undefined. This, I think, is incorrect. LDAP
has, as X.511 does, provide a mechanism to distinguish FALSE from
Undefined.
>In fact the draft already points out the scenarios that can cause an attribute error (or security error) just as X.511 does. X.511 does not mention the possibility of innapropriateMatching being returned.
>
>It seems to me that X.511 is underspecified.
And likewise LDAP. We should be clear that compareTrue means
the assertion was TRUE, compareFalse means that the assertion
was FALSE, and in all other cases, including when the assertion
was Undefined, a result code other than compareTrue or compareFalse.
>Are there multiple implementations that return innapropriateMatching when the attribute in the AVA has no equality match rule?
I believe there are multiple implications which act as I describe.
Whether they return inappropriateMatching in this particular
case, or some error code, I am less sure of.
I think it is far more important to state when compareTrue
(when True), compareFalse (when Undefined), else error (including
when Undefined) then it is to state which particular error codes
should be returned when. I rather give server implementations the
freedom to select "the most appropriate" error result code and
just provide general descriptions of each error code.
Kurt