idnits 2.17.1 draft-boreham-numsubordinates-01.txt: -(15): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(17): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding ** The Abstract section seems to be numbered -(33): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(44): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(52): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(84): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(95): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(96): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(111): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(126): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(140): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-boreham-numsubordinates-01', but the file name used is 'draft-boreham-numsubordinates-01' == There are 11 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 52 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...This document...' == Line 15 has weird spacing: '...working docu...' == Line 16 has weird spacing: '...ments of the ...' == Line 21 has weird spacing: '...eted by other...' == Line 25 has weird spacing: '...The list o...' == (35 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (19 April 2004) is 7305 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2252' is defined on line 144, but no explicit reference was found in the text == Unused Reference: 'ITU-X520' is defined on line 148, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-X501' ** Obsolete normative reference: RFC 2251 (ref. 'LDAPv3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-X520' Summary: 11 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT David Boreham, Bozeman Pass Inc. 3 Steve Kille, Isode 4 Individual Submission 19 October, 2003 6 numSubordinates LDAP Operational Attribute 8 draft-ietf-boreham-numsubordinates-01.txt 10 This document expires on 19 April 2004 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. Internet-Drafts are working docu� 16 ments of the Internet Engineering Task Force (IETF), its areas, and its 17 working groups. Note that other groups may also distribute working doc� 18 uments as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 This document decibes an LDAP operational attribute named "numSubordi� 34 nates". The purpose of this attribute is to allow clients to determine 35 efficiently the number of entries immediately below (in the DIT), any 36 particular directory entry. 38 3. Background 40 Experience has shown that where an LDAP client wishes to "browse" the 41 Directory Information Tree (DIT), it is useful to be able to determine 42 how many entries exist which are immediate subordinates of a particular 43 entry. Knowledge of this information allows the client to display UI to 44 the effect that "there are too many entries in this container to dis� 45 play". Only by waiting for some timeout interval would it be possible 46 to come to this conclusion without knowing the subordinate count in 47 advance. Such a timeout leads to poor user experience. Similarly, UI 48 which displays the DIT complete with the content count of each container 50 RFC DRAFT October 2003 52 entry becomes feasible. In addition, easy and efficient access to sub� 53 ordinate count information permits client tools to analyse the DIT, for 54 example to determine where special server indices or precomputed search 55 result sets should be maintained to give optimum performance. 57 The key words "MUST", "SHOULD", and "MAY" used in this document are to 58 be interpreted as described in [Bradner97]. 60 4. Attribute Definition 62 The numSubordinates attribute is defined as follows in RFC2252 then 63 X.520 ASN.1 format: 65 ( 1.3.6.1.4.1.453.16.2.103 NAME 'numSubordinates' 66 DESC 'count of immediate subordinates' 67 EQUALITY integerMatch ORDERING integerOrderingMatch 68 SYNTAX 1.3.6.1.4.1.453.16.2.103 69 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 71 numSubordinates ATTRIBUTE ::= { 72 WITH SYNTAX INTEGER 73 USAGE directoryOperation 74 SINGLEVALUED TRUE 75 NO USER MODIFICATION TRUE 76 ID {dod internet(1) private(4) 77 enterprises(1) isode-consortium(453) 78 ic-dsa(16) ic-dsa-at(2) 103} 79 } 80 Every entry in the DIT MAY have a numSubordinates operational attribute 81 the contents of which indicate how many immediate subordinates that 82 entry has. For example, a leaf entry would have numSubordinates equal to 83 "0". Entry "ou=People, o=ace industry, c=us" in a DIT where the contents 84 of that container comprises 1000 leaf entries, would have numSubordi� 85 nates equal to "1000". 87 Server support for the numSubordinates attribute is on a per-entry 88 basis. That is, the presence of the attribute indicates that its value 89 is correct, while the absence of the attribute indicates nothing other 90 than the lack of support for the attribute. Consequently, absence of the 91 numSubordinates attribute does not imply that there are no subordinates. 93 5. Client-Server Interaction 95 Clients may read the value of the numSubordinates attribute by perform� 96 ing a regular LDAP search operation[LDAPv3], while specifying numSubor� 97 dinates as one of the requested attributes. Note that an operational 98 attribute such as numSubordinates will not be returned to the client 99 unless explicitly requested. 101 RFC DRAFT October 2003 103 Clients can not modify the contents of the numSubordinates attribute. 104 Servers MUST refuse to allow such modifications and SHOULD return the 105 unwilling to perform status code. 107 Servers MUST ensure that the value returned in the numSubordinates 108 attibute to clients is consistent with the view that client has of other 109 server contents. For example, is it NOT permissible to delay updating 110 the numSubordinates count for some container entry until some time after 111 subordinates have been added or deleted. This would lead to the poten� 112 tial for a client to see an inconsistency between the numSubordinates 113 value reported for an entry and the number of entries that same client 114 had added as subordinates. 116 6. Relationship to hasSubordinates 118 The X.500 hasSubordinates operational attribute[ITU-X501] can be 119 regarded as indicating whether numSubordinates has a non-zero value for 120 the same entry. This leads to the potential for optimization in a server 121 implementation, in that it isn't necessary to store both values. 123 7. Security Considerations 125 Any client which is able to read the numSubordinates attribute may be 126 able to discover more about the contents of the DIT than would be possi� 127 ble without access to that attribute. Consequently server implementers 128 are advised to provide an access control mechanism which can be used to 129 restrict access to numSubordinates. For servers which already have an 130 attribute-level access control facility, this might involve no more than 131 ensuring that numSubordinates falls within that existing scheme. 133 8. References 135 [ITU-X501] 136 The Directory: Models. ITU-T Recommendation X.501, 1997, section 137 section 13.4.4. 139 [LDAPv3] 140 Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access Pro� 141 tocol (v3)", Internet Standard, December, 1997. Available as 142 RFC2251. 144 [RFC2252] 145 Wahl et al, Lightweight Directory Access Protocol (v3): Attribute 146 Syntax Definitions. Available as RFC2252. 148 [ITU-X520] 149 The Directory: Selected Attribute Types. ITU-T Recommendation 150 X.520, 1997. 152 RFC DRAFT October 2003 154 [Bradner97] 155 Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement 156 Levels", Internet Draft, March, 1997. Available as RFC2119. 158 9. Authors' Addresses 160 David Boreham Steve Kille 161 Bozeman Pass, Inc. Isode 162 1106 W. Park St #200 5 Castle Business Village 163 Livingston, MT 59047, USA 36 Station Road 164 +1 406 222 7093 Hampton 165 david@bozemanpass.com Middlesex, TW12 2BX, UK 166 +44 (20) 8783 0203 167 S.Kille@ISODE.COM 169 This document expires on 19 April 2004