Internet DRAFT - draft-ietf-boreham-numsubordinates

draft-ietf-boreham-numsubordinates









INTERNET-DRAFT				David Boreham, Bozeman Pass Inc.
						      Steve Kille, Isode
Individual Submission					19 October, 2003


	       numSubordinates LDAP Operational Attribute

	       draft-ietf-boreham-numsubordinates-01.txt

		 This document expires on 19 April 2004

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 doc­
uments 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 dis­
play".	Only by waiting for some timeout interval would it  be	possible
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						    October 2003


entry becomes feasible.	 In addition, easy and efficient access to  sub­
ordinate  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.6.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						    October 2003


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
attibute 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						    October 2003


[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
   Bozeman Pass, Inc.		 Isode
   1106 W. Park St #200		 5 Castle Business Village
   Livingston, MT 59047, USA	 36 Station Road
   +1 406 222 7093		 Hampton
   david@bozemanpass.com	 Middlesex, TW12 2BX, UK
				 +44 (20) 8783 0203
				 S.Kille@ISODE.COM


   This document expires on 19 April 2004


































Boreham and Kille						[Page 4]