idnits 2.17.1 draft-armijo-ldap-control-error-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 (ref. '1') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Asaf Kashi 2 Intended Category: Standards Track Microsoft Corporation 3 March, 2002 4 Expires: September, 2002 6 The LDAP controlError Result Code 8 1. Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. It is filed as , and expires September, 2002. 32 Please send comments to the author. 34 2. Abstract 36 This document defines a controlError result code to be used in 37 LDAPv3 [1] control extension specifications. The purpose of this 38 result code is to let the client know that the operation which 39 returned this result code was not successful due to an attached 40 control and that further information is available in one or more 41 controls attached to the response. 43 3. Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in RFC 2119 [2]. 48 4. Background and Intended Usage 50 LDAPv3 allows for the extension of the protocol through the use of 51 controls. These controls allow existing operations to be enhanced 52 to provide additional functionality for directory operations. 53 Complex controls are being established that are bringing up error 54 conditions not anticipated in the LDAPv3 specifications. 56 This document provides a result code, controlError, which is used to 57 signify a control specific error. The purpose of this result code 58 is to let the client know that the operation which returned this 59 result code was not successful due to an attached control and that 60 further information is available in one or more controls attached to 61 the response. 63 The controlError result code SHOULD be used in a response message to 64 signal that a control specific error condition occurred and 65 additional information is available in the attached control response 66 message. An example of a control specification using this result 67 code can be seen in the VLV control specification. [3] 69 5. The LDAP controlError Result Code 71 The LDAPResult construct as defined in section 4.1.10 of RFC 2251 72 [1] includes a list of valid result codes. The LDAPResult construct 73 is repeated here for readability: 75 LDAPResult ::= SEQUENCE { 76 resultCode ENUMERATED { 77 success (0), 78 operationsError (1), 79 protocolError (2), 80 timeLimitExceeded (3), 81 sizeLimitExceeded (4), 82 compareFalse (5), 83 compareTrue (6), 84 authMethodNotSupported (7), 85 strongAuthRequired (8), 86 -- 9 reserved -- 87 referral (10), -- new 88 adminLimitExceeded (11), -- new 89 unavailableCriticalExtension (12), -- new 90 confidentialityRequired (13), -- new 91 saslBindInProgress (14), -- new 92 noSuchAttribute (16), 93 undefinedAttributeType (17), 94 inappropriateMatching (18), 95 constraintViolation (19), 96 attributeOrValueExists (20), 97 invalidAttributeSyntax (21), 98 -- 22-31 unused -- 99 noSuchObject (32), 100 aliasProblem (33), 101 invalidDNSyntax (34), 102 -- 35 reserved for undefined isLeaf -- 103 aliasDereferencingProblem (36), 104 -- 37-47 unused -- 105 inappropriateAuthentication (48), 106 invalidCredentials (49), 107 insufficientAccessRights (50), 108 busy (51), 109 unavailable (52), 110 unwillingToPerform (53), 111 loopDetect (54), 112 -- 55-63 unused -- 113 namingViolation (64), 114 objectClassViolation (65), 115 notAllowedOnNonLeaf (66), 116 notAllowedOnRDN (67), 117 entryAlreadyExists (68), 118 objectClassModsProhibited (69), 119 -- 70 reserved for CLDAP -- 120 affectsMultipleDSAs (71), -- new 121 -- 72-79 unused -- 122 other (80) }, 123 -- 81-90 reserved for APIs -- 124 matchedDN LDAPDN, 125 errorMessage LDAPString, 126 referral [3] Referral OPTIONAL } 128 This document adds another valid result code, controlError(76). 130 The controlError MUST be defined in any control specification that 131 makes use of the result code. A control specification SHALL define 132 under what conditions the controlError result is to be returned and 133 which control will be attached to the response message. In 134 addition, the control specification SHALL define the control 135 specific errors returned in the attached control. 137 A control specification SHOULD NOT use controlError to represent any 138 condition that can be defined using any existing result code in RFC 139 2251. 141 The controlError result code MUST be defined in control 142 specifications to signify that the client should parse an embedded 143 result code for additional control specific results. 145 In cases where a client receives an LDAP response with the result 146 code of controlError and no attached controls, the response is to be 147 treated as an unknown error condition. 149 6. Security Considerations 151 This document defines an extension to RFC 2251 [1] and has the same 152 security issues. See the security considerations section in [1] for 153 more details. In addition the result code defined in this document 154 is used in other control specifications and as such their individual 155 security considerations must be examined. 157 7. Acknowledgement 159 Michael Armijo of Microsoft co-authored a previous version of this 160 document. 162 8. Author�s Address 164 Asaf Kashi 165 One Microsoft Way 166 Redmond, WA 98052 167 asafk@microsoft.com 169 9. References 171 [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 172 Protocol(v3)", RFC 2251, December 1997. 174 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 175 Levels", RFC 2119, March 1997 177 [3] Boreham et al, "LDAP Extensions for Scrolling View Browsing of 178 Search Results", Internet-Draft, November 2001 179 Work in progress published as: 180 182 10. Full Copyright Statement 184 Copyright (C) The Internet Society (2001). All Rights Reserved. 185 This document and translations of it may be copied and furnished to 186 others, and derivative works that comment on or otherwise explain it 187 or assist in its implementation may be prepared, copied, published 188 and distributed, in whole or in part, without restriction of any 189 kind, provided that the above copyright notice and this paragraph 190 are included on all such copies and derivative works. However, this 191 document itself may not be modified in any way, such as by removing 192 the copyright notice or references to the Internet Society or other 193 Internet organizations, except as needed for the purpose of 194 developing Internet standards in which case the procedures for 195 copyrights defined in the Internet Standards process must be 196 followed, or as required to translate it into languages other than 197 English. 199 The limited permissions granted above are perpetual and will not be 200 revoked by the Internet Society or its successors or assigns. 202 This document and the information contained herein is provided on an 203 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 204 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 205 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 206 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 207 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."