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

From: Howard Chu <[email-masked]>
Date: Thu, 02 Nov 2006 12:12:28 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Howard Chu <[email-masked]>
Date: Thu, 02 Nov 2006 12:23:29 -0800

Howard Chu wrote:
>>> 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 

Reconsidering that. This is no worse than multiple clients performing 
Modify/Replace operations concurrently. Also, it's essential to be able 
to specify the ordinal position when inserting new values into a list, 
or changing an existing value without altering its position.

---

From: Howard Chu <[email-masked]>
Date: Thu, 02 Nov 2006 12:31:49 -0800

> where value is of the X-ORDERED-SYNTAX syntax.
Then again, we could just sidestep all of this schema-extension hassle 
and just define a suite of new syntaxes:

    orderedInteger
    orderedDirectoryString
    orderedOctetString
    orderedDistinguishedName

and so on.

---

From: Pete Rowley <[email-masked]>
Date: Thu, 02 Nov 2006 13:18:35 -0800

Howard Chu wrote:
>>>> 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.
>>>>     
>>
>> 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 
> Modify/Replace operations concurrently. 
In those cases race conditions modify the success of the operation, not 
the resulting state.
> Also, it's essential to be able to specify the ordinal position when 
> inserting new values into a list, or changing an existing value 
> without altering its position.
>
Right, but the point was it is subject to race conditions.

-- 
Pete

---

From: Howard Chu <[email-masked]>
Date: Thu, 02 Nov 2006 13:42:34 -0800

Pete Rowley wrote:
>>> 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.
>>
> In those cases race conditions modify the success of the operation, 
> not the resulting state.

Not sure what you mean here. Modify/replace always succeeds (as far as 
each client knows) and the resulting state is determined by 
last-writer-wins.

> Right, but the point was it is subject to race conditions.

I guess we can punt this and recommend use of the RFC4528 assertion 
control on the modifications when multiple updaters may be active. E.g., 
assert (entryCSN=xxx) representing the entry's CSN value the last time 
we looked at the entry.