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

From: Pierangelo Masarati <[email-masked]>
Date: Sat, 26 Aug 2006 18:02:12 +0200

Howard,

a couple of quick short comments (one is editorial: in example (3) of
section 4.3 you issue a modrdn and supply a DN
"olcDatabase={99}ldif,cn=config" as the newrdn field; it should likely
be "olcDatabase={99}ldif" instead).

The other emerged from the improper use of an X-ORDERED 'VALUES'
attribute as naming attribute by an OpenLDAP user
(<http://www.openldap.org/lists/openldap-software/200608/msg00253.html>).
I think attributes with this extension could create problems when used
as naming attributes in a RDN.  I see two possibilities:

1) the distinguished value does not report the ordering portion (if it
does, there could be confusion with X-ORDERED 'SIBLINGS', though); this
approach would make data appear inconsistent to applications that do not
recognize the extension, but at least would prevent the need to rename
an entry if the ordering of a naming attribute changes; for example,
consider an "ov" attribute with the X-ORDERED 'VALUES' extension:

dn: ov=foo,dc=example,dc=com
ov: {0}foo
ov: {1}bar

2) the X-ORDERED 'VALUES' inhibits an attribute from being used to name
an entry.

I favor the second approach; that is, recommend implementors that
implement the X-ORDERED 'VALUES' extension to disallow them as naming
attributes, because it looks simpler and cleaner.  I wouldn't go for the
first approach, unless I'm missing any significant advantage.

Cheers, p.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    [email-masked]
------------------------------------------

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Howard Chu <[email-masked]>
Date: Sat, 26 Aug 2006 15:53:13 -0700

> Howard,

Thanks. Agreed, X-ORDERED 'VALUES' attributes should be prohibited from 
use as naming attributes. I'll revise the draft shortly.

> does, there could be confusion with X-ORDERED 'SIBLINGS', though); 
> this approach would make data appear inconsistent to applications that 
> do not recognize the extension, but at least would prevent the need to 
> rename an entry if the ordering of a naming attribute changes; for 
> example, consider an "ov" attribute with the X-ORDERED 'VALUES' 
> extension:
>
> 2) the X-ORDERED 'VALUES' inhibits an attribute from being used to 
> name an entry.
>
>
> attributes, because it looks simpler and cleaner.  I wouldn't go for 
> the first approach, unless I'm missing any significant advantage.
>
> Cheers, p.
>
>
>    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
>

-- 
  -- 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/

---

From: Pete Rowley <[email-masked]>
Date: Mon, 28 Aug 2006 10:47:43 -0700

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 28 Aug 2006 14:05:43 -0700

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