RE: LDAPSubentries comments review and request for lastcallbyLDAPEXT and LDUP working groups

["Steven Legg" <steven.legg@adacel.com.au>]

Ed,

Ed Reed wrote:
> I think I answered that - because the X.500 refinement mechanism
> is too complex to be easily understood, configured, or implemented,
> much less managed.  A profile of a simpler thing is needed for many
> applications.

Complexity is a relative thing. I find the subtree refinement mechanism
much easier to get my head around than the LDAP access control model.
Anyway, what's the problem with writing a profile for the use of subtree
specifications in LDAP that restricts the possible forms (to one even!) ?

The only proposal I've ever been able to find for an LDAP string
representation of subtree specifications is the long expired
draft-ietf-asid-ldapv3-attributes-03.txt. With this proposal, the
simplest specification is "(####)", which means "the whole subtree".
Can't new subentry classes for LDAP simply require the subtree
specification to be exactly this ?

Since there isn't a normative reference for the LDAP string representation
of subtree specifications I would rather that the string encoding be
defined algorithmically from the ASN.1, i.e. using the generic string
encoding rules from my component matching draft. With those rules
the whole subtree specification is just "{}". An overt description
of the LDAP string representation of subtree specifications could just
mention this form for the unwashed masses, while for those who need to
use it for X.500 interworking, or want to experiment with it in LDAP,
there is a deduceable ABNF for more refined subtree specifications.

Regards,
Steven
 
> 
> =================
> Ed Reed
> Reed-Matthews, Inc.
> +1 801 796 7065
> http://www.Reed-Matthews.COM
> 
> >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 07/19/01 06:40PM >>>
> 
> At 08:29 AM 7/19/2001, Ed Reed wrote:
> >LDAP includes, by reference, X.500 subentries, including refinement
> 
> Then why are we wasting our time with LDAPsubentries?
> X.500 subentries provides a sound approach, an approach
> proven to work for holding subschema, ACIs, and collective
> attributes.  We certainly don't need an second approach,
> especially one which is inconsistent with the X.500 data
> model which implementations "MUST act in accordance with."
> 
> Kurt
> 
> 
> 
>