[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt
It might be better for the schema to defined like:
( ATTRIBUTE-OID NAME 'orderedValue'
EQUALITY caseIgnoreMatch
SYNTAX ORDERED-VALUES-SYNTAX-OID
X-ORDERED 'SIBLINGS'
X-ORDERED-SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
So that to an unaware client, the syntax is something they
are not familiar with. For an aware client, the
ORDERED-VALUES-SYNTAX-OID is some encoding of something
like:
orderedValue ::= SEQUENCE {
position INTEGER OPTIONAL,
value OCTET STRING
}
where value is of the X-ORDERED-SYNTAX syntax.
At 10:47 AM 8/28/2006, Pete Rowley wrote:
>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
>
>
>
>
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org
>https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext