[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

INTERNET-DRAFT                                   David Boreham, Netscape
                                       Steve Kille, MessagingDirect Ltd.
Individual Submission                                      10 June, 1999

               numSubordinates LDAP Operational Attribute


                This document expires on 9 December 1999

1.  Status of this Memo

This document is an Internet-Draft and is in full conformance  with  all
provisions  of Section 10 of RFC2026.  Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and  its
working  groups.   Note  that  other  groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum  of  six  months
and  may  be  updated,  replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."

The   list   of   current   Internet-Drafts   can   be    accessed    at

The list  of  Internet-Draft  Shadow  Directories  can  be  accessed  at

2.  Abstract

This document decibes an LDAP operational attribute  named  "numSubordi-
nates".   The purpose of this attribute is to allow clients to determine
efficiently the number of entries immediately below (in  the  DIT),  any
particular directory entry.

3.  Background

Experience has shown that where an LDAP client wishes  to  "browse"  the
Directory  Information  Tree (DIT), it is useful to be able to determine
how many entries exist which are immediate subordinates of a  particular
entry.  Knowledge of this information allows the client to display UI to
the effect that "there  are  too  many  entries  in  this  container  to
display".   Only by waiting for some timeout interval would it be possi-
ble to come to this conclusion without knowing the subordinate count  in
advance.  Such  a  timeout leads to poor user experience.  Similarly, UI
which displays the DIT complete with the content count of each container

Boreham and Kille                                               [Page 1]

RFC DRAFT                                                      June 1999

entry  becomes  feasible.   In  addition,  easy  and efficient access to
subordinate count information permits client tools to analyse  the  DIT,
for  example  to  determine  where special server indices or precomputed
search result sets should be maintained to give optimum performance.

The key words "MUST", "SHOULD", and "MAY" used in this document  are  to
be interpreted as described in [Bradner97].

4.  Attribute Definition

The numSubordinates attribute is defined  as  follows  in  RFC2252  then
X.520 ASN.1 format:

    ( NAME 'numSubordinates'
      DESC 'count of immediate subordinates'
      EQUALITY integerMatch ORDERING integerOrderingMatch

    numSubordinates ATTRIBUTE ::= {
        WITH SYNTAX             INTEGER
        USAGE                   directoryOperation
        SINGLEVALUED            TRUE
        ID                      {dod internet(1) private(4)
                                enterprises(1) isode-consortium(453)
                                ic-dsa(16) ic-dsa-at(2) 103}
Every entry in the DIT MAY have a numSubordinates operational  attribute
the  contents  of  which  indicate  how many immediate subordinates that
entry has. For example, a leaf entry would have numSubordinates equal to
"0". Entry "ou=People, o=ace industry, c=us" in a DIT where the contents
of that container comprises 1000 leaf entries,  would  have  numSubordi-
nates equal to "1000".

Server support for the  numSubordinates  attribute  is  on  a  per-entry
basis.   That is, the presence of the attribute indicates that its value
is correct, while the absence of the attribute indicates  nothing  other
than the lack of support for the attribute. Consequently, absence of the
numSubordinates attribute does not imply that there are no subordinates.

5.  Client-Server Interaction

Clients may read the value of the numSubordinates attribute by  perform-
ing  a regular LDAP search operation[LDAPv3], while specifying numSubor-
dinates as one of the requested attributes.  Note  that  an  operational
attribute  such  as  numSubordinates  will not be returned to the client
unless explicitly requested.

Boreham and Kille                                               [Page 2]

RFC DRAFT                                                      June 1999

Clients can not modify the contents of  the  numSubordinates  attribute.
Servers  MUST  refuse  to allow such modifications and SHOULD return the
unwilling to perform status code.

Servers MUST ensure that the value returned in the numSubordinates atti-
bute  to  clients  is  consistent with the view that client has of other
server contents.  For example, is it NOT permissible to  delay  updating
the numSubordinates count for some container entry until some time after
subordinates have been added or deleted. This would lead to  the  poten-
tial  for  a  client to see an inconsistency between the numSubordinates
value reported for an entry and the number of entries that  same  client
had added as subordinates.

6.  Relationship to hasSubordinates

The  X.500  hasSubordinates  operational  attribute[ITU-X501]   can   be
regarded  as indicating whether numSubordinates has a non-zero value for
the same entry. This leads to the potential for optimization in a server
implementation, in that it isn't necessary to store both values.

7.  Security Considerations

Any client which is able to read the numSubordinates  attribute  may  be
able to discover more about the contents of the DIT than would be possi-
ble without access to that attribute. Consequently  server  implementers
are  advised to provide an access control mechanism which can be used to
restrict access to numSubordinates.  For servers which already  have  an
attribute-level access control facility, this might involve no more than
ensuring that numSubordinates falls within that existing scheme.

8.  References

     The Directory: Models. ITU-T Recommendation  X.501,  1997,  section
     section 13.4.4.

     Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access  Pro-
     tocol  (v3)",  Internet  Standard,  December,  1997.  Available  as

     Wahl et al, Lightweight Directory Access Protocol (v3):   Attribute
     Syntax Definitions. Available as RFC2252.

     The  Directory:  Selected  Attribute  Types.  ITU-T  Recommendation
     X.520, 1997.

Boreham and Kille                                               [Page 3]

RFC DRAFT                                                      June 1999

     Bradner, Scott, "Key Words for use in RFCs to Indicate  Requirement
     Levels", Internet Draft, March, 1997. Available as RFC2119.

9.  Authors' Addresses

   David Boreham                           Steve Kille
   Netscape Communications Corp.           MessagingDirect
   501 E. Middlefield Road                 The Dome, The Square
   Mountain View, CA 94043, USA            Richmond
   +1 650 937-5206                         Surrey, TW9 1DT, UK
   dboreham@netscape.com                   +44 181 332 9091

   This document expires on 9 December 1999

Boreham and Kille                                               [Page 4]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/