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

[Howard Chu <hyc@highlandsun.com>]

andrew.sciberras@eb2bcom.com 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
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext