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

From: Howard Chu <[email-masked]>
Date: Wed, 17 May 2006 19:33:55 -0700

[email-masked] wrote:
> Hi Howard,
> 
> Thanks for your feedback.
> 
> See my responses below:
> 
> That's right.. A silly oversight by me. Ordered Siblings is fine, whilst the
> distinguishedName attribute olcSuffix still break the DN syntax.

For the moment, I think we're going to have live with this. E.g., I can 
define "the ordering-prefix is ignored when validating that a value 
conforms to an attribute's syntax" but that doesn't address the 
interoperability issue.

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

OK

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

It was suggested that the ordering-prefix should be omitted from search 
responses unless explicitly requested (by a control) but there are 
situations where I don't think it makes sense when omitted. E.g., if I 
have multiple hdb databases in my server configuration, I want 
ldapsearch to return:
	dn: olcDatabase={1}hdb,cn=config

	dn: olcDatabase={2}hdb,cn=config

	dn: olcDatabase={3}hdb,cn=config

whether the client understands the X-ORDERED 'SIBLINGS' extension or 
not, otherwise the search responses make no sense (cannot be disambiguated).

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