Re: LDAPEXT status and last calls

[Jim Sermersheim <JIMSE@novell.com>]

>>> Tim Howes <howes@netscape.com> 12/1/98 12:43:05 PM >>>
...
>- Drafts that are ready for WG last call:
...
>        draft-ietf-ldapext-sorting-01.txt (proposed)

I just wanted to bring an issue up regarding the server side sorting request control one more time.  The draft addresses the issue of what happens when a sort key is a multi-valued attribute (sec 4.2) by stating that behavior is unspecified.  If it's not too much trouble, could it be amended to allow specification?  I can think of three ways of specifying the behavior, the first is to allow it in the control value, something like this:

SortKeyList::= SEQUENCE OF SEQUENCE {
     attributeType    AttributeDescription,
     orderingRule      [0] MatchingRuleId OPTIONAL,
     reverseOrder      [1] BOOLEAN DEFAULT FALSE,
     whichMultiValue   [2] ENUMERATED DEFAULT min {
          min     (0),  - - smallest value used
          max     (1),  - - largest value used
          any     (2),  - - arbitrary value used } }

This should allow existing implementations to work.

The other two (somewhat more kludgey) ways wouldn't involve changing the control value.  One is, define a set of special Matching Rules, that only make sense when used in this control.  They would specify min, max, any (and any future requirements).  The other is to do something similar but use the options part of the AttributeDescription, i.e. "cn;max" and so on.

With this, it seems like there needs to be a way of flagging the attribute value that was used.  In other words, If you get a set of entries back, sorted by some multi-valued attribute, and want to display them in a sorted fashion, you need to know which attribute value was used.  To solve this, it could be specified that the value used, always be the first in that attribute, or there could be a way of specifying that the entry is returned with only a single value in the attribute used as a sort key.  I guess that would look like this:

SortKeyList::= SEQUENCE OF SEQUENCE {
     attributeType    AttributeDescription,
     orderingRule      [0] MatchingRuleId OPTIONAL,
     reverseOrder      [1] BOOLEAN DEFAULT FALSE,
     whichMultiValue   [2] SEQUENCE OPTIONAL {
          restrictValues   [0] BOOLEAN DEFAULT FALSE,
          value            [1] ENUMERATED DEFAULT min {
               min     (0),  - - smallest value used
               max     (1),  - - largest value used
               any     (2),  - - arbitrary value used } } }

Is this too much change?  If so, will leaving the draft as it stands now, restrict a solution in the future?

Jim