idnits 2.17.1 draft-armijo-ldap-dirsync-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 248 lines 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 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 19 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 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). -- 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 1999) is 9020 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: 'RFC 2119' is defined on line 209, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) == Outdated reference: A later version (-04) exists of draft-ietf-ldapext-authmeth-03 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Michael P. Armijo 2 Status: Informational Microsoft Corporation 3 February 1999 4 Expires August 1999 6 Microsoft LDAP Control for Directory Synchronization 7 draft-armijo-ldap-dirsync-00.txt 9 1. Status of this Memo 11 This memo provides information for the Internet community. It does not 12 specify an Internet standard of any kind. Distribution of this memo is 13 unlimited. 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 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 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any time. 24 It is inappropriate to use Internet-Drafts as reference material or to 25 cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 2. Abstract 35 This document defines an LDAP Control for Directory Synchronization. 36 This control allows a client to request changes from a directory since 37 the last Directory Synchronization Control was run. This control is 38 implemented by the Active Directory feature of Microsoft Windows 39 2000 Server. It is intended that other members of the Internet 40 community be able to use this control if desired. 42 3. Overview 44 Many organizations today store information on multiple directories. 45 For example, e-mail accounts and related information might be stored in 46 one directory; information about files and networking in another; 47 certain data, such as financial or human resource data in yet another 48 directory. Such an environment is referred to as a mixed-directory 49 environment. 51 The LDAP Control for Directory Synchronization provides a method for 52 dissimilar directories to share pertinent information. 54 4. Directory Synchronization Control 56 This control MUST only be used with a SearchRequest message. A 57 server MUST ignore the control if used with any other message 58 unless the criticality field is set to True, in which case the 59 entire operation MUST fail and MUST instead return the resultCode 60 unsupportedCriticalExtension as per section 4.1.12 of [RFC 2251]. 61 The server MUST list that it recognizes this control in the 62 supportedControl attribute in the root DSE. 64 The replication control is included in the searchRequest and 65 searchResultDone messages as part of the server controls field of 66 the LDAPMessage. The structure of this control is as follows: 68 Repl Control ::= SEQUENCE { 69 controlType 1.2.840.113556.1.4.841 70 controlValue replControlValue 71 criticality TRUE 72 } 74 The replControlValue in the SearchRequest is an OCTET STRING wrapping 75 the BER-encoded version of the following: 77 realReplControlValue ::= SEQUENCE { 78 parentsFirst integer 79 maxAttributeCount integer 80 cookie OCTET STRING 81 } 83 parentsFirst: Setting parentsFirst to one ensures that all parents of 84 the children come before their children. 86 maxAttributeCount: This specifies the maximum number of attributes to 87 return. This can be used to limit the amount of data returned. 89 cookie: The cookie is an implementation specific opaque OCTET STRING 90 that is updated by the directory during each search request. It allows 91 the Dirsync control to read changes incrementally from the directory. 92 The very first time the control is created, the cookie should be 93 encoded as a NULL string with 0 length. 95 The replControlValue in the SearchResponse is an OCTET STRING wrapping 96 the BER-encoded version of the following: 98 realReplControlValue ::= SEQUENCE { 99 flag integer 100 maxAttributeCount integer 101 cookie OCTET STRING 102 } 104 flag: If flag is set to a non-zero value, it implies that is more 105 data to retrieve. 107 maxAttributeCount: This specifies the maximum number of attributes to 108 return. This can be used to limit the amount of data returned. 110 cookie: This is the opaque cookie returned by the server to be used by 111 the client in subsequent searches. 113 5. Client Server Interaction 115 The LDAP Directory Synchronization control allows a client to request 116 changes made to a directory replica since a state of that replica 117 identified by an opaque "cookie." 119 A typical client (dirsync agent) will work on a schedule to read 120 changes from a supplier directory and write changes to a consumer 121 directory. On this schedule the client will wake up, read the opaque 122 cookie from a file, then enter a loop passing the current cookie to 123 the supplier server and receive changes back. It computes updates 124 to perform to the consumer directory based on the changes, and makes 125 these updates. When these updates are committed it writes the new 126 cookie to the file, and goes around the loop again if the setting of 127 the 'flag' returned by the supplier states that there is additional 128 information to be retreieved. If not it exits the loop and sleeps 129 until the next scheduled cycle. 131 When the control is initally run the client should send the 132 cookie encoded as a NULL string with 0 length. 134 The server will respond to each Directory Synchronization search 135 request with the changes since the last control was run (based on 136 the cookie provided by the client) and a cookie to be stored and used 137 by the client during the next synchronization cycle. The client MUST 138 consider the cookie to be an opaque structure and not make any 139 assumptions about its internal organization or value. The client may 140 reuse older cookies, however this search request may result in changes 141 being reported that have already been received by the client. 143 In the case of a complete server failure, a client may pass a cookie 144 generated by one directory server to a different directory server 145 hosting the same directory partition. This may result in the new 146 server reporting changes already reported by the old server. The 147 new server MAY report a full synchronization (all objects and 148 attributes in the search request). The client MUST be able to handle 149 changes already reported being returned again. 151 The directory server SHOULD limit use of this control to entities 152 explicitly granted permission to use this control. The directory 153 server SHOULD return objects and attributes based on the filters of 154 the search request and based on the permissions of the authenticated 155 entity. 157 Server implementations may have other restraints on which containers 158 or objects may or may not use the Directory Synchronization control. 159 If a client attempts to run the Directory Synchronization control on 160 an object or container that does not support the control, the server 161 SHOULD return the error unwillingToPerform(53). 163 5.1 Interpretation of Advanced Directory Operations 165 Certain directory changes and operations are not defined in an LDAP 166 search response. The Directory Synchronization control will interpret 167 these operations using defined object attributes. The directory 168 synchronization client MUST understand and support these operations. 170 If an object is deleted it will be returned in the search response 171 message with the 'isDeleted' attribute set to value 1. The client 172 MUST interpret this as an object deletion and MUST perform the proper 173 opertation on the consumer directory. 175 isDeleted 176 (1.2.840.113556.1.2.48 NAME 'isDeleted' 177 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7) 179 If an object is moved or renamed the attribute 'RDN' will be returned 180 with the value set to the new object name. The client MUST interpret 181 this as an object rename and perform the proper operation on the 182 consumer directory. 184 RDN 185 (1.2.840.113556.1.4.1 NAME 'RDN' 186 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15) 188 6. Security Considerations 190 This document details a method for retreiving information from a 191 directory server using an LDAP control. Server implementations utilizing 192 this control SHOULD implement security mechanisms as defined in 193 Authentication Methods for LDAP [AuthMeth]. 195 Each implementation should take appropriate measures to insure that only 196 authorized entities can utilize this control. 198 7. References 200 [RFC 2251] 201 M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol 202 (v3)", RFC 2251, December 1997. 1997. 204 [AuthMeth] 205 M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authentication 206 Methods for LDAP". INTERNET-DRAFT, Work In Progress. 207 draft-ietf-ldapext-authmeth-03.txt 209 [RFC 2119] 210 Bradner, S., "Key words for use in RFCs to Indicate Requirement 211 Levels," 212 RFC 2119, Harvard University, March 1997. 214 8. Authors Address 216 Michael P. Armijo 217 One Microsoft Way 218 Redmond, WA 219 98052 220 USA 222 (425)882-8080 223 micharm@microsoft.com 225 Internet-Draft 226 Expires August 1999