INTERNET-DRAFT David Boreham, Netscape Steve Kille, MessagingDirect Ltd. Individual Submission 10 June, 1999 numSubordinates LDAP Operational Attribute draft-boreham-numsubordinates-00.txt 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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: ( 1.3.1.1.4.1.453.16.2.103 NAME 'numSubordinates' DESC 'count of immediate subordinates' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.453.16.2.103 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) numSubordinates ATTRIBUTE ::= { WITH SYNTAX INTEGER USAGE directoryOperation SINGLEVALUED TRUE NO USER MODIFICATION 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 [ITU-X501] The Directory: Models. ITU-T Recommendation X.501, 1997, section section 13.4.4. [LDAPv3] Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access Pro- tocol (v3)", Internet Standard, December, 1997. Available as RFC2251. [RFC2252] Wahl et al, Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions. Available as RFC2252. [ITU-X520] The Directory: Selected Attribute Types. ITU-T Recommendation X.520, 1997. Boreham and Kille [Page 3] RFC DRAFT June 1999 [Bradner97] 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 Steve.Kille@messagingdirect.com This document expires on 9 December 1999 Boreham and Kille [Page 4]