INTERNET-DRAFT Michael P. Armijo Microsoft Corporation February, 2001 Expires: August, 2001 Result Code for LDAP Controls 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 documents 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. Distribution of this memo is unlimited. It is filed as , and expires on August 5, 2001. Please send comments to the author. Abstract The purpose of this document is to create a new result code specific to LDAP controls and to define guidelines for the use of this result code. 1. Background and Intended Usage LDAPv3 [1] allows for the extension of the protocol through the use of controls. These controls allow existing operations to be enhanced to provide additional functionality for directory operations. Complex controls are being established that are bringing up error conditions not anticipated in the LDAPv3 specifications. This document provides a result code that can be used to signify a control specific error. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. 2. The LDAP Control Result Code The LDAPResult construct as defined in section 4.1.10 of RFC 2251 [1] includes a list of valid result codes. The LDAPResult construct is repeated here for readability: LDAPResult ::= SEQUENCE { resultCode ENUMERATED { success (0), operationsError (1), protocolError (2), timeLimitExceeded (3), sizeLimitExceeded (4), compareFalse (5), compareTrue (6), authMethodNotSupported (7), strongAuthRequired (8), -- 9 reserved -- referral (10), -- new adminLimitExceeded (11), -- new unavailableCriticalExtension (12), -- new confidentialityRequired (13), -- new saslBindInProgress (14), -- new noSuchAttribute (16), undefinedAttributeType (17), inappropriateMatching (18), constraintViolation (19), attributeOrValueExists (20), invalidAttributeSyntax (21), -- 22-31 unused -- noSuchObject (32), aliasProblem (33), invalidDNSyntax (34), -- 35 reserved for undefined isLeaf -- aliasDereferencingProblem (36), -- 37-47 unused -- inappropriateAuthentication (48), invalidCredentials (49), insufficientAccessRights (50), busy (51), unavailable (52), unwillingToPerform (53), loopDetect (54), -- 55-63 unused -- namingViolation (64), objectClassViolation (65), notAllowedOnNonLeaf (66), notAllowedOnRDN (67), entryAlreadyExists (68), objectClassModsProhibited (69), -- 70 reserved for CLDAP -- affectsMultipleDSAs (71), -- new -- 72-79 unused -- other (80) }, -- 81-90 reserved for APIs -- matchedDN LDAPDN, errorMessage LDAPString, referral [3] Referral OPTIONAL } This document adds another valid result code, controlError(x). 3. Use of the LDAP Control Result Code The controlError result code can be returned when an operation has failed due to an error caused by an attached control. The controlError SHOULD NOT be used to represent any condition that can be defined using any existing result code in RFC 2251. The controlError MUST be defined in any control specification that makes use of the result code. The scenario of when the controlError result code may be returned and the exact behavior of the client with particular controls MUST be defined in any control specification that refers to this result code. The controlError result code MAY be defined in control specifications to signify that the client should parse an embedded result code for additional control specific results. 4. Security Considerations This document defines an extension to RFC 2251 [1] and has the same security issues. See the security considerations section in [1] for more details. 5. References [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol(v3)", RFC 2251, December 1997. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 6. Authors Address Michael P. Armijo One Microsoft Way Redmond, WA 98052 micharm@microsoft.com Expires August, 2001