Subject: Re: subentries comments

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 05 Dec 2001 15:42:39 -0800

At 07:21 AM 2001-12-05, Rob Byrne - Sun Microsystems wrote:
>Couple of comments on
>http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-subentry-01.txt.
>
>1.  I think it's good to promote the chop scoping rules--we are seeing
>more and more requests for complicated scoping for admininstrative
>data.  The problem I want to point out is that in our implementation we
>are used to allowing arbitrary LDAP filters for this kind of selection
>of entries, so I'm concerned that the restriction of being able to
>select only on objectclass could be a problem for us taking up this
>definition of subentries.  Could we relax this restriction to make
>specificationFilter a general LDAP filter ?  Any other possibilites ?

The goal of this I-D is to introduce X.500 subentry semantics
to LDAP.  Hence, where extension to the semantics is desired, I
believe these extensions should be first specified as X.500
extensions and then subsequently introduced into LDAP.  I believe
there are a number of means to extend these semantics in X.500.

>2. In the subentries control I think, for usability, it would be very
>nice to have in addition the option to retrieve normal and subentries at
>the same time, as opposed to one or the other.

Again, aim is to model the X.500 semantics.

---

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Thu, 06 Dec 2001 14:41:50 +0100

Kurt,

If the goal is to faithfully transfer x500 semantics as is to LDAP then I
think the draft needs to be clearer about that.  For example, it could be
renamed  from "Subentries in LDAP" to "X500 Subentries in LDAP" or
"Representation of X500 Subentries in LDAP".  And again,  the text in the
abstract that says "This document adapts X.500 subentries mechanisms for use
with LDAP." could say something like "This document transfers X.500
subentries mechanisms to LDAP , keeping the same fundamental semantics".

A line like "LDAP subentries SHALL behave in accordance with X.501 unless
noted otherwise in this specification." appears superfluous if you state the
"transfer the semantics" goal clearly--there should by definition be no
behavioural differences.  If you keep this line then that leaves the door
open for differences, so I think the reader would appreciate a section that
listed any differences or explicitly stated that the differences were not in
semantics but just schema, for example.

I wonder if the guy who was tracking LDAP/x500 correspondance would have
some input here on the possibility of an extension to the x500 subentry
definitions...do you have his email handy ?

Rob.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 06 Dec 2001 06:25:30 -0800

At 05:41 AM 2001-12-06, Rob Byrne - Sun Microsystems wrote:
>think the draft needs to be clearer about that.

The goal is to the LDAP mechanisms to act in accordance with X.500
semantics, as should all LDAP mechanisms.  LDAP is, after all, a
protocol for accessing an X.500 directory.

>For example, it could be
>renamed  from "Subentries in LDAP" to "X500 Subentries in LDAP" or ...

I think it superfluous to insert X.500 here as LDAP is an access
protocol to an X.500 directory.

>And again,  the text in the

We don't transfer mechanism, we adapt them while maintaining the
consistent semantics.  That is, the LDAP access to subentries uses
different mechanisms than DAP, but both are semantically consistent.

My co-author and I will, however, consider making a clarification in
this area as obviously the present wording caused some confusion.

>behavioural differences.

Mechanisms differ, semantics are consistent.  This statement is
consistent with that which applies to all of LDAP [RFC 2251, s3.3].

>If you keep this line then that leaves the door
>open for differences,

The extension door is always open.   It's the goal of this
document to detail how a core component of the X.500 data
model can be accessed using LDAP.  Our intent is not to
extend this component, just to provide access to it.  This
gives the I-D a narrow focus which allows it to be progressed
much faster than if we opened the LDAP-specific enhancement
door.

>so I think the reader would appreciate a section that

There are certainly mechanism differences, DAP and LDAP
are quite different protocols.  However, the semantics of
each (as they apply to this part of the data model) are
quite consistent.  I've noted a one difference in the
last paragraph of section 1.  It exists for consistency
with the LDAP "core" specification due to how it handles
subschema subentries.

Kurt

---

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Thu, 06 Dec 2001 16:58:06 +0100

Kurt,

You point out below that in fact you have introduced a difference, namely in the
retrieval behaviour when no control is attached.  This difference and the
subsequent control definition means that you have failed to reproduce a
behaviour that exists with x500 subentries, namely the ability to recover both
normal and subentries in one request.  I think that will be very painful for
manageability.

How about changing the meaning of TRUE in the controlValue to mean "retrieve
both normal and subentries" ?  It's still not exactly the same as x500 but it
seems "usefully closer" to me.

Rob.

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 7 Dec 2001 13:57:09 +1100

Rob,

Rob Byrne wrote:
> retrieval behaviour when no control is attached.

The last paragraph in section 1 needs rewording. The detailed
description in section 3 is correct.

In DAP, if the ServiceControls.options is absent then subentries
are not visible to one-level and subtree search operations and
list operations. In LDAP, if the subentries control is absent
then subentries are not visible to subtree and one-level searches.
The means are different but the semantics are the same.

Note that the sense of the LDAP control is the reverse of the
subentries bit in ServiceControls.options. The value FALSE for
the control is equivalent to the subentries bit being set.

The only behavioural difference is that an LDAP base object search
without the subentries control sees both entries and subentries
while a DAP base object search without ServiceControls.options does
not see subentries (but should, in my opinion). However, a DAP read
operation sees both. If gateways translate LDAP base object searches
without the control into DAP reads the behaviour is the same.  

>  This 
> difference and the
> normal and subentries in one request.

It isn't possible in X.500 to retrieve both entries and subentries
in the same request. The LDAP control is consistent with that.

> I think that will be 
> very painful for

I haven't found it to be so.

> seems "usefully closer" to me.

This would require splitting some LDAP search operations into
two DSP chained search operations. I want to avoid that complication.

Regards,
Steven

---

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Fri, 07 Dec 2001 11:02:04 +0100

> in the same request. The LDAP control is consistent with that.

Steven,

Thanks for the clarification.

> I haven't found it to be so.

Mmm...what you haven't had you don't miss :-), or maybe it's that in x500
you can always use the read operation.  In our implementaion of
"subentries", we can get both and I think not being able to do that is
unpleasant.

> two DSP chained search operations. I want to avoid that complication.

Ok, but I'm taking the same point of view for LDAP clients.

I understand your goal in this draft is to just get the x500 functionality
into LDAP and that's ok.  The thing that concerns me is how easy it will be
subsequently to make extensions (or whatever) that in my opinion will make
subentries that are good for LDAP, notably the filter and retrieval points
I've been making.

Cheers,
Rob.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 07 Dec 2001 07:21:23 -0800

>subentries that are good for LDAP, notably the filter and retrieval points

I believe that such extensions can easily be made but are more
appropriately defined in separate documents.

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 21 Dec 2001 11:22:54 +1100

Rob,

Rob Byrne wrote:
> you can always use the read operation.

Neither. Our clients for regular users hide the administrative details
from view. The users never need to see the subentries so user searches
never ask for them. Even when the client needs to fetch subschema
information it can do so without asking for subentries because subschema
operational attributes have collective attribute semantics and therefore
can be read from any regular entry in the scope of the subschema area.

Our administrative clients mostly hide the details subentries from view
also. Most actions are couched in terms of the administrative point entries
instead. The client code then works out what that means in terms of the
X.500 administrative model. That code always knows whether it is looking
for subentries or regular entries. We haven't had a situation where we
need to search for both simultaneously.

Regards,
Steven