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

[Howard Chu <hyc@highlandsun.com>]

Another pass.

Andrew Sciberras wrote:
> Hi Howard,
>
> I am curious as to what the intended publication status of this draft 
> will be (i.e. experimental, informational, etc)?

Informational.

> I would have concerns about the proposed strategy if this was a  
> Standards Track document.
> The main concerns that I have about the draft in its current form are that:
>
> 1. *Values that do not conform to the syntax*
> I agree with your statement in 2.2 that:
> "Using this extension on an attribute requires that ordering-prefix is a 
> legal value of the LDAP syntax of that attribute."
>
> This statement is broken for Ordering Siblings and EXAMPLE_AT.2. A 
> Distinguished Name is not allowed to start with a curly brace '{'.

Actually Ordered Siblings is fine since the prefix precedes the RDN 
value, not the RDN type.

> 3. Interoperability Problems
> This functionality will cause severe problems between client and server 
> interoperability. A likely case that can exist, is when we have a server 
> that implements x-ordering, and a client that doesn't.
> When the client gets results back, it will most likely reject (or fail 
> to decode) any DN value that contains ordering information. Any values 
> that are returned with ordering information will be treated as-is. This 
> will cause the ordering information to be treated as part of the 
> attribute value, which may cause problems with the client.
> I cannot see any way of informing an unaware client that the ordering 
> data in the value have special semantics.
>
> A bigger problem is that a client cannot indicate that they don't want 
> additional ordering information prepended to values. An x-ordering aware 
> client, who doesn't care about ordering, will need to read schema and 
> identify which attributes have been subjected to ordering data, and then 
> remove it.

As I see it there are three possible outcomes:
  1) the client is totally unaware of schema - in this case the client 
treats everything as blobs, and doesn't care.
  2) the client is schema-aware, but doesn't recognize the x-ordering 
schema extension - in this case, the client should probably treat the 
attribute as unrecognized. It seems that the ldapbis-models doc doesn't 
really address what to do about unrecognized extensions.
  3) the client is schema-aware and recognizes the schema extension - 
then it should just deal with it. I.e., it is as much a property of the 
attribute as "numericString may only contain digits 0-9".

> 4. Modification of AttributeTypeDescription is inappropriate and 
> incomplete.
> Section 3.1 states:
> " The "X-ORDERED" schema extension is added to an 
> AttributeTypeDescription to signify the use of this ordering mechanism."
>
> Whilst this is acceptable in LDAP, the X- extension is intended for 
> private extensions and should not be standardized. The consequence of 
> updating the Attribute Type Description in a doc like this is that any 
> LDAP server that supports this extension will not be able to encode the 
> value in any encoding other than the LDAP specific string encoding (i.e. 
> you wont be able to BER or GSER encode an attributeTypeDescription value).

I obviously misunderstood you the last time around. The original goal 
here was not standards track, thus the X- extension. If there's 
sufficient interest in a generally usable ordering feature, then we can 
explore that path.

Looking at the current BCP64 draft, there's no procedure for registering 
new schema definition elements.
> I think that a better implementation of this functionality would ensure 
> that the functionality is only exercised if the client supports the 
> functionality and it requests its usage. I think its pointless 
> advertising a feature which indicates an uncontrollable change in the 
> semantics of the protocol, as clients should refuse to work with any 
> LDAP server that contains unknown features since they cannot establish 
> how the protocol has changed.
>
> Possibly the solution should incorporate the usage of controls or ldap 
> attribute options.

The use of attribute options was another possibility that we'd 
considered in the past. It's awkward, since items with different tagging 
options are actually separate attributes. E.g.
	attr-foo;x-order0: first value
	attr-foo;x-order1: second value

It also does not give a client the choice to use the feature or not. 
Also it precludes the Ordered Siblings capability, since attributes in 
RDNs cannot have any options.

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