idnits 2.17.1 draft-armijo-ldap-treedelete-02.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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 153 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations 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.) ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (August 24, 2000) is 8636 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) -- Missing reference section? 'RFC 2251' on line 122 looks like a reference -- Missing reference section? 'RFC 2119' on line 126 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Michael P. Armijo 2 Microsoft Corporation 3 August 24, 2000 4 Expires February, 2001 6 Tree Delete Control 7 draft-armijo-ldap-treedelete-02.txt 9 1. Status of this Memo 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Distribution of this memo is unlimited. It is filed as , and expires on February 24, 2001. 34 Please send comments to the authors. 36 2. Abstract 38 This document defines an LDAPv3 control that deletes an entire subtree 39 of a container entry. This control extends the scope of the LDAPv3 40 delete operation as defined in RFC 2251. This control is beneficial 41 in extending the functionality of the LDAP protocol and may be useful 42 in administration in an LDAP environment. 44 3. RFC Key Words 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119. 50 4. Tree Delete Control 52 The control is included in the DelRequest message as part of the 53 controls field of the LDAPMessage. The controlType is 54 " 1.2.840.113556.1.4.805", the criticality field may be TRUE or FALSE, 55 and the controlValue field is absent. 57 This control allows a client to delete an entire subtree. This can 58 only be done if the authenticated user has appropriate permissions to 59 complete the operation. The server MUST check to see if the 60 authenticated user has appropriate permissions to delete the 61 object and all of its descendants. This control MUST only be used 62 with a DelRequest message. A server MUST ignore the control if used 63 with any other message unless the criticality field is set to True, 64 in which case the entire operation MUST fail and MUST instead return 65 the resultCode unsupportedCriticalExtension as per section 4.1.12 of 66 [RFC 2251]. The server MUST list that it recognizes this control in 67 the supportedControl attribute in the root DSE. 69 4.1 Tree Delete Semantics 71 The tree delete request may be processed as a single atomic transaction 72 or as a sequence of atomic transactions. In the latter case, all the 73 client-visible states produced by tree delete are consistent with the 74 execution of a sequence of normal delete requests. The server SHOULD 75 NOT leave process the objects in a manner that could orphan objects. 77 If a tree delete request fails for any transient reason, it can be 78 retried and, if the retry runs to a successful conclusion, the result 79 is the same as if the initial request had succeeded. The client 80 SHOULD resubmit the delRequest until the server returns a result code 81 of success(0). 83 If a client submits a request to move an object into (or create an 84 object in) or out of the subtree concurrently with the execution of a 85 tree delete request, the effect is undefined. The server is NOT required 86 to lock out such requests. 88 The server MUST NOT chase referrals stored in the tree. If information 89 about referrals is stored in this section of the tree, this pointer 90 will be deleted. 92 4.2 Error Messages with this Control 94 When the Tree Delete Control is invoked, the server MUST check to see 95 if the authenticated user has appropriate permissions to delete the 96 object and all of its descendants. If the user does not have 97 appropriate permissions, an insufficientAccessRights(50) error SHOULD 98 be returned. 100 The server MUST identify all the objects to be deleted before 101 deletions begin. If the server has a problem identifying the objects 102 to delete, the server MAY return an operationsError(1). The operation 103 MAY be retried if this error is returned. If the server is not the 104 authority for any objects in the selected tree the server SHOULD return 105 unwillingToPerform(53). 107 Server implementations may have other restraints on which containers 108 may or may not use the Tree Delete control. If you attempt to delete a 109 container that cannot be deleted due to a platform specific restraint, 110 the server MUST return the error unwillingToPerform(53). The Tree 111 Delete control will not work under these circumstances and the 112 operation SHOULD NOT be retried on this container. 114 If the limit to the number of objects that can be deleted in one 115 operation is reached, the server SHOULD return adminLimitExceeded(11). 116 Objects processed up to the point of the limit SHOULD be deleted. The 117 DelRequest with the Tree Delete Control SHOULD be resubmitted until a 118 successful response is returned to the server. 120 5. References 122 [RFC 2251] 123 M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol 124 (v3)", RFC 2251, December 1997. 1997. 126 [RFC 2119] 127 Bradner, S., "Key words for use in RFCs to Indicate Requirement 128 Levels," 129 RFC 2119, Harvard University, March 1997. 131 6. Authors Address 133 Michael P. Armijo 134 One Microsoft Way 135 Redmond, WA 136 98052 137 USA 139 (425)882-8080 140 micharm@microsoft.com 142 Expires February 24,2001