[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

Kurt D. Zeilenga wrote: 
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.

This would be in lieu of defining a new control that hides/exposes the ordering prefixes?

Looks like I never replied to the other post either:
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?"

For X-ORDERED 'SIBLINGS' yes, this is only intended to work on attributes that are the RDN. The actual requirement that I meant to express is that a single attribute cannot have both properties. I'll fix the language here. 

"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.

That's a good point. I only envisioned using this for configuration info that doesn't change frequently and isn't changed by more than one entity. If it turns out that this is just a cute idea that's more trouble than it's worth we can just drop it, since the basic goal of preserving ordering is still generally applicable. 
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.

Right.

Presumably if we follow Kurt's suggestion, the data cannot be imported into an unaware server since it will not support the specified syntaxes, so that problem would disappear. Using a control, such that unaware directory agents can touch the data, would seem to be inviting corruption (or at least misuse) of the data. 

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/


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