RE: Fix for VLV draft.

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

At 02:06 PM 1/29/01 -0700, Jim Sermersheim wrote:
>>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 1/29/01 12:14:46 PM >>>
>>At 01:30 PM 1/29/01 -0500, John Liang wrote:
>>>So you mean the unsorted entries will be returned but there will
>>>be an error code in the LDAP searchResultDone message.
>>
>>I'm saying that a control TS which overloads the control
>>criticality field is flawed and this flaw should be fixed.
>>I have not yet made any suggestion on how it should be fixed.
>
>I agree. I don't believe the VLV draft overloads the criticality field. I don't think there is anything in the VLV spec that goes against the directions in 2251. That is, if the control is recognized and appropriate, it will be serviced (unless malformed. If it is not recognized or appropriate, it will either be ignored (false criticality), or the operation will fail (true criticality). 

Just for clarity (I think we're agreeing):
  If the control is recognized and appropriate for the operation
  (e.g. it's a search control on a search operation), it will
  be processed.  If the control is malformed, it should be processed
  as a protocol error.

  Though "appropriate"ness can be defined on a per control basis,
  one should be careful to distinguish "appropriate"ness and
  error conditions. "Appropriate"ness should be determined
  before any processing.

>If there is a problem while servicing the control (regardles of criticality), the operation will fail, and a VLVresponse will accompany the SearchResultDone message. If the problem that originated the failure was due to the processing of the VLV control, the virtualListViewResult is used to convey the problem. This is where the current contention lies with the draft.

Thanks for the clarification.