idnits 2.17.1 draft-sermersheim-ldap-subordinate-scope-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 233. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 239. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2251, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2251, updated by this document, for RFC5378 checks: 1996-03-14) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7222 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) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2255 (Obsoleted by RFC 4510, RFC 4516) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 3383 (Obsoleted by RFC 4520) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J;. Sermersheim 2 Internet-Draft Novell, Inc 3 Updates: 2251 (if approved) July 2004 4 Expires: December 30, 2004 6 Subordinate Subtree Search Scope for LDAP 7 draft-sermersheim-ldap-subordinate-scope-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 30, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 The Lightweight Directory Application Protocol (LDAP) specification 43 supports three scope values for the search operation -- namely: 44 baseObject, singleLevel, and wholeSubtree. This document introduces 45 a subordinateSubtree scope which constrains the search scope to all 46 subordinates of the named base object. 48 Discussion Forum 49 Technical discussion of this document will take place on the IETF 50 LDAP Extensions mailing list . Please send 51 editorial comments directly to the author. 53 1. Overview 55 There are a number of reasons which have surfaced for introducing a 56 Lightweight Directory Application Protocol (LDAP) [RFC3377] 57 SearchRequest.scope [RFC2251] which constrains the search scope to 58 all subordinates of the named base object, and does not include the 59 base object (as wholeSubtree does). These reasons range from the 60 obvious utility of allowing an LDAP client application the ability to 61 exclude the base object from a wholeSubtree search scope, to 62 distributed operation applications which require this scope for 63 progressing search sub-operations resulting from an nssr DSE type 64 reference. 66 To meet these needs, the subordinateSubtree scope value is 67 introduced. 69 The subordinateSubtrees cope is applied to the SearchRequest.scope 70 field, the type and alternately the type of the 71 LDAP URL [RFC2255] and may be applied to other specifications which 72 include an LDAP search scope. A mechanism is also given which allows 73 LDAP Directory Server Agents (DSA)s to advertise support of this 74 search scope. 76 2. Application to SearchRequest.scope 78 A new item is added to this ENUMERATED type. The identifier is 79 subordinateSubtree and the number is 4. 81 A DSA which receives and supports the subordinateSubtree 82 SearchRequest.scope constrains the search scope to all subordinate 83 objects. 85 A DSA which receives but does not support the subordinateSubtree 86 SearchRequest.scope returns a protocolError resultCode in the 87 SearchResultDone. 89 3. LDAP URL applications 91 The LDAP URL [RFC2255] specification allows the conveyance of a 92 search scope. This section intoduces two ways in which the 93 subordinateScope search scope may be conveyed in an LDAP URL. One 94 way is by allowing a new "subord" scope in the part. Another 95 way is through the introduction of an LDAP URL extension. The LDAP 96 URL extension method is preferred for its criticality semantics. 98 3.1 Application to LDAP URL 100 A new value of "subord" is added. Using the type 101 from LDAP URL [RFC2255], the ABNF is as follows: 103 scope /= "subord" 105 Implementations processing but which do not understand or support the 106 "subord" of an LDAP URL raise an appropriate error. 108 3.2 Application to LDAP URL 110 An LDAP URL mechanism is introduced here. The 111 is IANA-ASSIGNED-OID.1 or the descriptor 'subordScope', and the 112 exvalue is omitted. The extension may be marked as either critical 113 or non-critical. 115 If supported, the subordScope extension overrides any value set in 116 the field. 118 4. DSA Advertisement of support 120 A DSA may advertise its support of the subordinateSubtree item in the 121 SearchRequest.scope by inclusion of IANA-ASSIGNED-OID.2 in the 122 'supportedFeatures' attribute of the root DSE. 124 5. Security Considerations 126 This specification introduces no security concerns above any 127 associated with the existing wholeSubtree search scope value. 129 As with the wholeSubtree search scope, this scope specifies that a 130 search be applied to an entire subtree hierarchy. Implementations 131 should be aware of the relative cost of using or allowing this scope. 133 6 Normative References 135 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory 136 Access Protocol (v3)", RFC 2251, December 1997. 138 [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, 139 December 1997. 141 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 142 Protocol (v3): Technical Specification", RFC 3377, 143 September 2002. 145 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 146 Considerations for the Lightweight Directory Access 147 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 149 Author's Address 151 Jim Sermersheim 152 Novell, Inc 153 1800 South Novell Place 154 Provo, Utah 84606 155 USA 157 Phone: +1 801 861-3088 158 EMail: jimse@novell.com 160 Appendix A. IANA Considerations 162 Registration of the following values is requested [RFC3383]. 164 A.1 LDAP Object Identifier Registrations 166 It is requested that IANA register upon Standards Action an LDAP 167 Object Identifier in identifying the protocol elements defined in 168 this technical specification. The following registration template is 169 provided: 171 Subject: Request for LDAP OID Registration 172 Person & email address to contact for further information: 173 Jim Sermersheim 174 jimse@novell.com 175 Specification: RFCXXXX 176 Author/Change Controller: IESG 177 Comments: 178 2 delegations will be made under the assigned OID: 179 IANA-ASSIGNED-OID.1 subordScope LDAP URL extension 180 IANA-ASSIGNED-OID.2 subordinateScope Supported Feature 182 A.2 LDAP Protocol Mechanism Registrations 184 It is requested that IANA register upon Standards Action the LDAP 185 protocol mechanism described in this document. The following 186 registration templates are given: 188 Subject: Request for LDAP Protocol Mechanism Registration 189 Object Identifier: IANA-ASSIGNED-OID.1 190 Description: subordScope LDAP URL extension 191 Person & email address to contact for further information: 193 Jim Sermersheim 194 jimse@novell.com 195 Usage: Extension 196 Specification: RFCXXXX 197 Author/Change Controller: IESG 198 Comments: none 200 A.3 LDAP Descriptor Registrations 202 It is requested that IANA register upon Standards Action the LDAP 203 descriptors described in this document. The following registration 204 templates are given: 206 Subject: Request for LDAP Descriptor Registration 207 Descriptor (short name): subordScope 208 Object Identifier: IANA-ASSIGNED-OID.1 209 Person & email address to contact for further information: 210 Jim Sermersheim 211 jimse@novell.com 212 Usage: URL Extension 213 Specification: RFCXXXX 214 Author/Change Controller: IESG 215 Comments: none 217 Intellectual Property Statement 219 The IETF takes no position regarding the validity or scope of any 220 Intellectual Property Rights or other rights that might be claimed to 221 pertain to the implementation or use of the technology described in 222 this document or the extent to which any license under such rights 223 might or might not be available; nor does it represent that it has 224 made any independent effort to identify any such rights. Information 225 on the procedures with respect to rights in RFC documents can be 226 found in BCP 78 and BCP 79. 228 Copies of IPR disclosures made to the IETF Secretariat and any 229 assurances of licenses to be made available, or the result of an 230 attempt made to obtain a general license or permission for the use of 231 such proprietary rights by implementers or users of this 232 specification can be obtained from the IETF on-line IPR repository at 233 http://www.ietf.org/ipr. 235 The IETF invites any interested party to bring to its attention any 236 copyrights, patents or patent applications, or other proprietary 237 rights that may cover technology that may be required to implement 238 this standard. Please address the information to the IETF at 239 ietf-ipr@ietf.org. 241 Disclaimer of Validity 243 This document and the information contained herein are provided on an 244 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 245 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 246 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 247 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 248 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 249 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 251 Copyright Statement 253 Copyright (C) The Internet Society (2004). This document is subject 254 to the rights, licenses and restrictions contained in BCP 78, and 255 except as set forth therein, the authors retain all their rights. 257 Acknowledgment 259 Funding for the RFC Editor function is currently provided by the 260 Internet Society.