Re: How to check whether or not an object is a leaf?

Mark Smith <> Tue, 12 December 1995 01:27 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa18957; 11 Dec 95 20:27 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18953; 11 Dec 95 20:27 EST
Received: from by CNRI.Reston.VA.US id aa16833; 11 Dec 95 20:27 EST
Received: from by with local SMTP id <>; Mon, 11 Dec 1995 17:48:39 +0000
Received: from by with Internet SMTP id <>; Mon, 11 Dec 1995 17:47:45 +0000
Received: from by (8.7.2/2.3) with SMTP id LAA26273; Mon, 11 Dec 1995 11:34:33 -0500 (EST)
Message-Id: <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Smith <>
To: Hallvard B Furuseth <>
Subject: Re: How to check whether or not an object is a leaf?
In-reply-to: Your message of "Fri, 08 Dec 1995 15:34:57 +0100." <>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Date: Mon, 11 Dec 1995 11:34:33 -0500

>From:     Hallvard B Furuseth <>
>  To:
> I have a user interface which I do not want to present search/list
> options when it displays leaf objects (specifically, some organizations
> and organizationalUnits).  Now, quipuObjects are leaves if they are
> neither quipuNonLeafObject nor externalNonLeafObject.  But how do I
> recognize a X.500(1993) leaf object?
> Or, if there is currently no way, *please* let's create a convention for
> how to mark leaf objects, even if the mark is only advisory.

Recently I wrote an Internet Draft that proposed using a couple of new
object classes to solve this problem.  It turns out that there is a
proposed draft amendement to the X.500 standards that defines an
operational attribute called "hasSubordinates" that seems to solve the
problem.  At the ASID meeting during last week's IETF meeting everyone
agreed we should use the "hasSubordinates" approach, and my draft will
be ignored.  I have attached a message from Colin Robbins that he sent
in response to the announcement about my original draft.

--- Begin Message ---
I agree with this draft that being able to distinguish between leaf
and non-leaf is required, but wonder if this is the best way of
achieving the effect.

Firstly,  the proposed draft amendment to X.500 on "Minor extensions
to support user requirements" already has a similar mechanism defined.
It defines an operational attribute:

	hasSubordinates ::= {
		USAGE			directoryOperation
		ID			id-oa-hasSubordinates }

This seems to overlap totally with the objectclass definition in the
ID.   However, the non-leaf object class in the ID does add some extra
attributes to non-leafs to describe data about them.

Instead of defining two new object classes, why not use the proposed
standard mechanism (it needs no software modification, so we could
use right now).  Then define numberOfChildren and numberOfDescendants
as new operational attributes to achieve the affect required in the ID?

This approach would be more in line with the X.500(93) way of adding
operation informations (using operational attributes), than using the
X.500(88) mechanism of adding artificial objectClasses.

--- End Message ---