Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt

[Pete Rowley <prowley@redhat.com>]

Since this popped up this morning - I did a run through:

"The "X-ORDERED 'SIBLINGS'" extension is used with single-valued

  attributes to maintain the order of all the onelevel children of a

  parent entry.  That is, ordering will be maintained for all the child

  entries whose RDNs are all of the same AttributeType."

Is it the intent that this is to work only on attribute values that are also the RDN?
If so, why the requirement that the attributes be single valued?
If not, do you mean "for example", rather than "that is?" 


"The ordering-prefix may also be used in Modification requests to

  specify which values to delete, and in which position values should
  be added.  When processing deletions and insertions, all of the
  ordinals are recounted after each individual modification."

I think this is unworkable in any situation where multiple clients 
perform operations - clearly there will be race conditions. The only way 
to avoid those race conditions in the delete case is to include the 
value, which makes the ordering element moot. I don't believe there is a 
reasonable method of avoiding race conditions for inserts in the current 
scheme.  Perhaps adding a control with the values either side of the 
insert point would help, at least by notifying the time T2 modifier that 
things have changed.

I also have concerns regarding the use of attribute values to store 
ordering information. This would likely cause issues with clients that 
know nothing of the extension and would make the servers that implement 
it non-compliant since they would store values that happen to look like 
they have ordinals incorrectly. Adding a control that determined when 
values are to be considered to have ordinals and when to return ordinals 
would side step any issues here. This would also help clients to know 
when the extension is supported or not.

Note that "

Since the ordering-prefix is stored with the attribute values, it
  will be propagated to any clients or servers that access the data."


is only a benefit when all servers implement the extension, those that 
do not and that import the data will appear to support the extension, 
and therefore clients may be fooled into relying on incorrect results.

Regards



--
Pete

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext