Re: LDAP subentry schema request for last call

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Even if you dismiss my suggestion to align with X.500 subentry,
the LDAPentry I-D still needs work and, IMO, not ready for last
call.

1) Given that LDAPsubentry is NOT X.500 subentry, the I-D must
explicit in defining it's semantics.  As defined, it is not
clear which X.500 subentry semantics apply or which ones don't.
The reader cannot assume X.500 semantics apply unless the
document explicitly states they do apply.

It is not clear of how LDAPsubentries are scoped.  It is not
clear whether or not X.500 placement (at administrative points)
restrictions apply to LDAPsubentries (the I-D uses a MAY).

It is not clear what container restrictions, if any, are
applicable. Can they be contained by the root DSE? 
other non-entry DSEs?  Can a LDAPsubentry contain a
non-LDAPsubentry?  Are there restrictions upon sub-classing
with other 'special' object classes (such as 'alias' and
'referral')?

2) I believe the specification of (objectclass=LDAPsubentry)
filter component is inadequate and that a control should be used
instead.  If a filter component is used, the specification
should state the semantics of filter component when it is
part of an Undefined or FALSE filter component or not
evaluated due to filter evaluation short circuiting.  I think
further overloading the search filter is a really bad idea.
But beyond that, a search filter component is limited to only
search operation operations and the visibility control may be
needed with other operations (such as modify, see below).

I proposed use of a control instead of a filter component.
We have operational experience with similar controls
(ManageDSAit) working well and experience with overloaded
search filter components not working well (previous matched
values I-D).  I believe a control would facilitate
implementation of LDAP-DAP gateways.

But beyond this, a control is usable with any operation.  I
would suspect that visibility control would be needed with
other operations such as modify and/or extended operations.
In particular, note that in X.500 collective attributes
(which an LDAP server may support) are not normally modifiable
unless the subentries control is present.  X.511, 11.3.2:

  The [modify] operation may be used to
modify collective attributes only if the
 service control
subentries
is
TRUE
and if the
object
is the subentry actually
  holding the collective attribute(s) to be modified.

(careful readers might note this sentence conflicts
conflicts
with 7.5(f), but that's another matter)

At 09:55 AM 7/13/00 -0600, Ed Reed wrote:
> With regard to making LDAPsubentry fully
> compatible with the X.500 subentry, it's been pointed out that people
> wanting to use the X.500 subentry should feel free to do so - it's
> incorporated by reference in the base LDAP 
> definitions.

Yes.  So there must be an overwhelming reason why a replacement
is
needed.  I don't think the complexity of the subtree specifier
is
an overwhelming reason.  It would be similar just to grant
vendors
some freedom to implement portions of the specifier (as previously
suggested by another member).

> The purpose of this proposal is to define a
> subset of the X.500 functionality (and extend the structural rules by
> allowing nesting of LDAPsubentries) for use by certain LDAP applications
> which find the subset functionality a useful
> simplification.

I believe the removal of the subtree specifier will require the
introduction of replacement scoping mechanisms/placement
restrictions
with complexity similar to that of the subtree specifier.  And
if
you allow LDAPsubentries to be placed anywhere in the directory,
locating the applicable LDAPsubentry becomes quite complex (for
both clients and servers).


On an editorial note, Section 2:
  ... RFC 2119 [RFC2119]. The sections below reiterate these
definitions
  and include some additional ones. 

The need for alternative and/or additional ones should be
eliminated.
This is an IESG nit:
http://www.ietf.org/ID-nits.html