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

[<andrew.sciberras@eb2bcom.com>]

Hi Howard,

Thanks for your feedback.

See my responses below:

> -----Original Message-----
> From: Howard Chu [mailto:hyc@highlandsun.com] 
> Sent: Friday, 12 May 2006 11:59 PM
> To: andrew.sciberras@eB2Bcom.com
> Cc: Ldapext
> Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt
> 
> Another pass.
> 
> Andrew Sciberras wrote:

 <snip>

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

That's right.. A silly oversight by me. Ordered Siblings is fine, whilst the
distinguishedName attribute olcSuffix still break the DN syntax.

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

Ok, this sounds reasonable to me.

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

I would imagine that the handling of private extensions to well defined
schema elements and attribute type definitions should be implemented in a
way that they can be ignored if unrecognised. This relies on the private
extension not changing the semantics of the protocol though. 

Model's isn't explicit about how clients and severs should handle
unrecognised extensions, but it does state:
- extensions to schema elements must start with "X-"
- Anything starting with "X-" are reserved for private experiments

This leads me to think that any schema extensions are for private use only
and cannot be standardised, which is possibly why BCP doesn't allow for
extensions to be registered. It's obviously fine in this case, since the
draft is Informational and can be perceived as providing information about a
private extension used in an existing implementation. I think the problem is
that clients that do not support the extension, should not be delivered
information that has been modified for the purpose of the extension. 

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


Andrew Sciberras
eB2Bcom


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