From 70597ef0afe457f1d07960c33520579eecec382f Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Wed, 28 Aug 2002 03:03:32 +0000 Subject: [PATCH] Trim drafts --- .../draft-ietf-ldapext-ldapv3-vlv-xx.txt | 625 -------- doc/drafts/draft-ietf-ldup-lcup-xx.txt | 1298 ----------------- doc/drafts/draft-weltman-ldapv3-proxy-xx.txt | 351 ----- doc/drafts/draft-zeilenga-ldap-cancel-xx.txt | 395 ----- .../draft-zeilenga-ldap-collective-xx.txt | 507 ------- .../draft-zeilenga-ldap-subentry-xx.txt | 619 -------- 6 files changed, 3795 deletions(-) delete mode 100644 doc/drafts/draft-ietf-ldapext-ldapv3-vlv-xx.txt delete mode 100644 doc/drafts/draft-ietf-ldup-lcup-xx.txt delete mode 100644 doc/drafts/draft-weltman-ldapv3-proxy-xx.txt delete mode 100644 doc/drafts/draft-zeilenga-ldap-cancel-xx.txt delete mode 100644 doc/drafts/draft-zeilenga-ldap-collective-xx.txt delete mode 100644 doc/drafts/draft-zeilenga-ldap-subentry-xx.txt diff --git a/doc/drafts/draft-ietf-ldapext-ldapv3-vlv-xx.txt b/doc/drafts/draft-ietf-ldapext-ldapv3-vlv-xx.txt deleted file mode 100644 index 34ae435306..0000000000 --- a/doc/drafts/draft-ietf-ldapext-ldapv3-vlv-xx.txt +++ /dev/null @@ -1,625 +0,0 @@ - -Internet-Draft D. Boreham, Bozeman Pass -LDAPext Working Group J. Sermersheim, Novell -Intended Category: Standards Track A. Kashi, Microsoft - -Expires: Nov 2002 May 2002 - - - LDAP Extensions for Scrolling View Browsing of Search Results - - -1. 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. - - This document is intended to be submitted, after review and revision, - as a Standards Track document. Distribution of this memo is - unlimited. - Please send comments to the authors. - - -2. Abstract - - This document describes a Virtual List View control extension for the - Lightweight Directory Access Protocol (LDAP) Search operation. This - control is designed to allow the "virtual list box" feature, common - in existing commercial e-mail address book applications, to be - supported efficiently by LDAP servers. LDAP servers' inability to - support this client feature is a significant impediment to LDAP - replacing proprietary protocols in commercial e-mail systems. - - The control allows a client to specify that the server return, for a - given LDAP search with associated sort keys, a contiguous subset of - the search result set. This subset is specified in terms of offsets - into the ordered list, or in terms of a greater than or equal - comparison value. - - - Boreham et al Internet-Draft 1 - - LDAP Extensions for Scrolling View May 2002 - Browsing of Search Results - -3. Conventions used in this document - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are - to be interpreted as described in RFC 2119 [Bradner97]. - - -4. Background - - A Virtual List is a graphical user interface technique employed where - ordered lists containing a large number of entries need to be - displayed. A window containing a small number of visible list entries - is drawn. The visible portion of the list may be relocated to - different points within the list by means of user input. This input - can be to a scroll bar slider; from cursor keys; from page up/down - keys; from alphanumeric keys for "typedown". The user is given the - impression that they may browse the complete list at will, even - though it may contain millions of entries. It is the fact that the - complete list contents are never required at any one time that - characterizes Virtual List View. Rather than fetch the complete list - from wherever it is stored (typically from disk or a remote server), - only that information which is required to display the part of the - list currently in view is fetched. The subject of this document is - the interaction between client and server required to implement this - functionality in the context of the results from a sorted LDAP search - request. - - For example, suppose an e-mail address book application displays a - list view onto the list containing the names of all the holders of e- - mail accounts at a large university. The list is sorted - alphabetically. While there may be tens of thousands of entries in - this list, the address book list view displays only 20 such accounts - at any one time. The list has an accompanying scroll bar and text - input window for type-down. When first displayed, the list view shows - the first 20 entries in the list, and the scroll bar slider is - positioned at the top of its range. Should the user drag the slider - to the bottom of its range, the displayed contents of the list view - should be updated to show the last 20 entries in the list. Similarly, - if the slider is positioned somewhere in the middle of its travel, - the displayed contents of the list view should be updated to contain - the 20 entries located at that relative position within the complete - list. Starting from any display point, if the user uses the cursor - keys or clicks on the scroll bar to request that the list be scrolled - up or down by one entry, the displayed contents should be updated to - reflect this. Similarly the list should be displayed correctly when - the user requests a page scroll up or down. Finally, when the user - types characters in the type-down window, the displayed contents of - the list should "jump" or "seek" to the appropriate point within the - list. For example, if the user types "B", the displayed list could - center around the first user with a name beginning with the letter - "B". When this happens, the scroll bar slider should also be updated - to reflect the new relative location within the list. - - Boreham et al Internet-Draft 2 - - LDAP Extensions for Scrolling View May 2002 - Browsing of Search Results - - - This document defines a request control which extends the LDAP search - operation. Always used in conjunction with the server side sorting - control [SSS], this allows a client to retrieve selected portions of - large search result set in a fashion suitable for the implementation - of a virtual list view. - - -5. Client-Server Interaction - - The Virtual List View control extends a regular LDAP Search operation - which must also include a server-side sorting control [SSS]. Rather - than returning the complete set of appropriate SearchResultEntry - messages, the server is instructed to return a contiguous subset of - those entries, taken from the sorted result set, centered around a - particular target entry. Henceforth, in the interests of brevity, the - sorted search result set will be referred to as "the list". - - The sort control MAY contain any sort specification valid for the - server. The attributeType field in the first SortKeyList sequence - element has special significance for "typedown". - - The desired target entry and the number of entries to be returned, - both before and after that target entry in the list, are determined - by the client's VirtualListViewRequest control. - - When the server returns the set of entries to the client, it attaches - a VirtualListViewResponse control to the SearchResultDone message. - The server returns in this control: its current estimate for the list - content count, the location within the list corresponding to the - target entry, any error codes, and optionally a context identifier. - - The target entry is specified in the VirtualListViewRequest control - by one of two methods. The first method is for the client to indicate - the target entry's offset within the list. The second way is for the - client to supply an attribute assertion value. The value is compared - against the values of the attribute specified as the primary sort key - in the sort control attached to the search operation. The first sort - key in the SortKeyList is the primary sort key. The target entry is - the first entry in the list with value greater than or equal to (in - the primary sort order), the presented value. The order is determined - by rules defined in [SSS]. Selection of the target entry by this - means is designed to implement "typedown". Note that it is possible - that no entry satisfies these conditions, in which case there is no - target entry. This condition is indicated by the server returning the - special value contentCount + 1 in the target position field. - - Because the server may not have an accurate estimate of the number of - entries in the list, and to take account of cases where the list size - is changing during the time the user browses the list, and because - the client needs a way to indicate specific list targets "beginning" - - Boreham et al Internet-Draft 3 - - LDAP Extensions for Scrolling View May 2002 - Browsing of Search Results - - and "end", offsets within the list are transmitted between client and - server as ratios---offset to content count. The server sends its - latest estimate as to the number of entries in the list (content - count) to the client in every response control. The client sends its - assumed value for the content count in every request control. The - server examines the content count and offsets presented by the client - and computes the corresponding offsets within the list, based on its - own idea of the content count. - - Si = Sc * (Ci / Cc) - - Where: - Si is the actual list offset used by the server - Sc is the server's estimate for content count - Ci is the client's submitted offset - Cc is the client's submitted content count - The result is rounded to the nearest integer. - - If the content count is stable, and the client returns to the server - the content count most recently received, Cc = Sc and the offsets - transmitted become the actual server list offsets. - - The following special cases exist when the client is specifying the - offset and content count: - - an offset of one and a content count of non-one (Ci = 1, Cc != 1) - indicates that the target is the first entry in the list. - - equivalent values (Ci = Cc) indicate that the target is the last - entry in the list. - - a content count of zero, and a non-zero offset (Cc = 0, Ci != 0) - means the client has no idea what the content count is, the server - MUST use its own content count estimate in place of the client's. - - Because the server always returns contentCount and targetPosition, - the client can always determine which of the returned entries is the - target entry. Where the number of entries returned is the same as the - number requested, the client is able to identify the target by simple - arithmetic. Where the number of entries returned is not the same as - the number requested (because the requested range crosses the - beginning or end of the list, or both), the client must use the - target position and content count values returned by the server to - identify the target entry. For example, suppose that 10 entries - before and 10 after the target were requested, but the server returns - 13 entries, a content count of 100 and a target position of 3. The - client can determine that the first entry must be entry number 1 in - the list, therefore the 13 entries returned are the first 13 entries - in the list, and the target is the third one. - - A server-generated context identifier MAY be returned to clients. A - client receiving a context identifier SHOULD return it unchanged in a - subsequent request which relates to the same list. The purpose of - - - Boreham et al Internet-Draft 4 - - LDAP Extensions for Scrolling View May 2002 - Browsing of Search Results - - this interaction is to enhance the performance and effectiveness of - servers which employ approximate positioning. - - -6. The Controls - - Support for the virtual list view control extension is indicated by - the presence of the OID "2.16.840.1.113730.3.4.9" in the - supportedControl attribute of a server's root DSE. - -6.1. Request Control - - This control is included in the SearchRequest message as part of the - controls field of the LDAPMessage, as defined in Section 4.1.12 of - [LDAPv3]. The controlType is set to "2.16.840.1.113730.3.4.9". The - criticality SHOULD be set to TRUE. If this control is included in a - SearchRequest message, a Server Side Sorting request control [SSS] - MUST also be present in the message. The controlValue is an OCTET - STRING whose value is the BER-encoding of the following SEQUENCE: - - VirtualListViewRequest ::= SEQUENCE { - beforeCount INTEGER (0..maxInt), - afterCount INTEGER (0..maxInt), - CHOICE { - byoffset [0] SEQUENCE { - offset INTEGER (0 .. maxInt), - contentCount INTEGER (0 .. maxInt) }, - greaterThanOrEqual [1] AssertionValue }, - contextID OCTET STRING OPTIONAL } - - beforeCount indicates how many entries before the target entry the - client wants the server to send. afterCount indicates the number of - entries after the target entry the client wants the server to send. - offset and contentCount identify the target entry as detailed in - section 4. greaterThanOrEqual is an attribute assertion value defined - in [LDAPv3]. If present, the value supplied in greaterThanOrEqual is - used to determine the target entry by comparison with the values of - the attribute specified as the primary sort key. The first list entry - who's value is no less than (less than or equal to when the sort - order is reversed) the supplied value is the target entry. If - present, the contextID field contains the value of the most recently - received contextID field from a VirtualListViewResponse control. The - type AssertionValue and value maxInt are defined in [LDAPv3]. - contextID values have no validity outwith the connection on which - they were received. That is, a client should not submit a contextID - which it received from another connection, a connection now closed, - or a different server. - - -6.2. Response Control - - - Boreham et al Internet-Draft 5 - - LDAP Extensions for Scrolling View May 2002 - Browsing of Search Results - - This control is included in the SearchResultDone message as part of - the controls field of the LDAPMessage, as defined in Section 4.1.12 - of [LDAPv3]. - - The controlType is set to "2.16.840.1.113730.3.4.10". The criticality - is FALSE (MAY be absent). The controlValue is an OCTET STRING, whose - value is the BER encoding of a value of the following SEQUENCE: - - VirtualListViewResponse ::= SEQUENCE { - targetPosition INTEGER (0 .. maxInt), - contentCount INTEGER (0 .. maxInt), - virtualListViewResult ENUMERATED { - success (0), - operationsError (1), - unwillingToPerform (53), - insufficientAccessRights (50), - busy (51), - timeLimitExceeded (3), - adminLimitExceeded (11), - sortControlMissing (60), - offsetRangeError (61), - other (80) }, - contextID OCTET STRING OPTIONAL } - - targetPosition gives the list offset for the target entry. - contentCount gives the server's estimate of the current number of - entries in the list. Together these give sufficient information for - the client to update a list box slider position to match the newly - retrieved entries and identify the target entry. The contentCount - value returned SHOULD be used in a subsequent VirtualListViewRequest - control. contextID is a server-defined octet string. If present, the - contents of the contextID field SHOULD be returned to the server by a - client in a subsequent VirtualListViewRequest control. - - The virtualListViewResult codes which are common to the LDAP - searchResponse (adminLimitExceeded, timeLimitExceeded, busy, - operationsError, unwillingToPerform, insufficientAccessRights) have - the same meanings as defined in [LDAPv3], but they pertain - specifically to the VLV operation. For example, the server could - exceed an administration limit processing a SearchRequest with a - VirtualListViewRequest control. However, the same administration - limit would not be exceeded should the same SearchRequest be - submitted by the client without the VirtualListViewRequest control. - In this case, the client can determine that an administration limit - has been exceeded in servicing the VLV request, and can if it chooses - resubmit the SearchRequest without the VirtualListViewRequest - control. - - insufficientAccessRights means that the server denied the client - permission to perform the VLV operation. - - - Boreham et al Internet-Draft 6 - - LDAP Extensions for Scrolling View May 2002 - Browsing of Search Results - - If the server determines that the results of the search presented - exceed the range specified in INTEGER values, it MUST return - offsetRangeError. - -6.2.1 virtualListViewError - - A new LDAP error is introduced called virtualListViewError. Its value - is 76. - [Note to the IESG/IANA/RFC Editor: the value 76 has been suggested by - experts, had expert review, and is currently being used by some - implementations. The intent is to have this number designated as an - official IANA assigned LDAP Result Code (see draft-ietf-ldapbis-iana- - xx.txt, Section 3.5)] - - If the server returns any code other than success (0) for - virtualListViewResult, then the server SHOULD return - virtualListViewError as the resultCode of the SearchResultDone - message. - - -7. Protocol Example - - Here we walk through the client-server interaction for a specific - virtual list view example: The task is to display a list of all 78564 - people in the US company "Ace Industry". This will be done by - creating a graphical user interface object to display the list - contents, and by repeatedly sending different versions of the same - virtual list view search request to the server. The list view - displays 20 entries on the screen at a time. - - We form a search with baseDN "o=Ace Industry, c=us"; search scope - subtree; filter "objectClass=inetOrgPerson". We attach a server sort - order control to the search, specifying ascending sort on attribute - "cn". To this base search, we attach a virtual list view request - control with contents determined by the user activity and send the - search to the server. We display the results from each search in the - list window and update the slider position. - - When the list view is first displayed, we want to initialize the - contents showing the beginning of the list. Therefore, we set - beforeCount = 0, afterCount = 19, contentCount = 0, offset = 1 and - send the request to the server. The server duly returns the first 20 - entries in the list, plus the content count = 78564 and - targetPosition = 1. We therefore leave the scroll bar slider at its - current location (the top of its range). - - Say that next the user drags the scroll bar slider down to the bottom - of its range. We now wish to display the last 20 entries in the list, - so we set beforeCount = 19, afterCount = 0, contentCount = 78564, - offset = 78564 and send the request to the server. The server returns - - - Boreham et al Internet-Draft 7 - - LDAP Extensions for Scrolling View May 2002 - Browsing of Search Results - - the last 20 entries in the list, plus the content count = 78564 and - targetPosition = 78564. - - Next the user presses a page up key. Our page size is 20, so we set - beforeCount = 0, afterCount = 19, contentCount = 78564, offset = - 78564-19-20 and send the request to the server. The server returns - the preceding 20 entries in the list, plus the content count = 78564 - and targetPosition = 78525. - - Now the user grabs the scroll bar slider and drags it to 68% of the - way down its travel. 68% of 78564 is 53424 so we set beforeCount = 9, - afterCount = 10, contentCount = 78564, offset = 53424 and send the - request to the server. The server returns the preceding 20 entries in - the list, plus the content count = 78564 and targetPosition = 53424. - - Lastly, the user types the letter "B". We set beforeCount = 9, - afterCount = 10 and greaterThanOrEqual = "B". The server finds the - first entry in the list not less than "B", let's say "Babs Jensen", - and returns the nine preceding entries, the target entry, and the - proceeding 10 entries. The server returns content count = 78564 and - targetPosition = 5234 and so the client updates its scroll bar slider - to 6.7% of full scale. - - -8. Notes for Implementers - - While the feature is expected to be generally useful for arbitrary - search and sort specifications, it is specifically designed for those - cases where the result set is very large. The intention is that this - feature be implemented efficiently by means of pre-computed indices - pertaining to a set of specific cases. For example, an offset - relating to "all the employees in the local organization, sorted by - surname" would be a common case. - - The intention for client software is that the feature should fit - easily with the host platform's graphical user interface facilities - for the display of scrolling lists. Thus the task of the client - implementers should be one of reformatting up the requests for - information received from the list view code to match the format of - the virtual list view request and response controls. - - Client implementers should note that any offset value returned by the - server may be approximate. Do not design clients > which only operate - correctly when offsets are exact. - - Server implementers using indexing technology which features - approximate positioning should consider returning context identifiers - to clients. The use of a context identifier will allow the server to - distinguish between client requests which relate to different - displayed lists on the client. Consequently the server can decide - more intelligently whether to reposition an existing database cursor - - Boreham et al Internet-Draft 8 - - LDAP Extensions for Scrolling View May 2002 - Browsing of Search Results - - accurately to within a short distance of its current position, or to - reposition to an approximate position. Thus the client will see - precise offsets for "short" repositioning (e.g. paging up or down), - but approximate offsets for a "long" reposition (e.g. a slider - movement). - - Server implementers are free to return status code unwillingToPerform - should their server be unable to service any particular VLV search. - This might be because the resolution of the search is computationally - infeasible, or because excessive server resources would be required - to service the search. - - Client implementers should note that this control is only defined on - a client interaction with a single server. If a server returns - referrals as a part of its response to the search request, the client - is responsible for deciding when and how to apply this control to the - referred-to servers, and how to collate the results from multiple - servers. - - -9. Relationship to "Simple Paged Results" - - These controls are designed to support the virtual list view, which - has proved hard to implement with the Simple Paged Results mechanism - [SPaged]. However, the controls described here support any operation - possible with the Simple Paged Results mechanism. The two mechanisms - are not complementary; rather one has a superset of the other's - features. One area where the mechanism presented here is not a strict - superset of the Simple Paged Results scheme is that here we require a - sort order to be specified. No such requirement is made for paged - results. - - -10. Security Considerations - - Server implementers may wish to consider whether clients are able to - consume excessive server resources in requesting virtual list - operations. Access control to the feature itself; configuration - options limiting the featureÆs use to certain predetermined search - base DNs and filters; throttling mechanisms designed to limit the - ability for one client to soak up server resources, may be - appropriate. - - Consideration should be given as to whether a client will be able to - retrieve the complete contents, or a significant subset of the - complete contents of the directory using this feature. This may be - undesirable in some circumstances and consequently it may be - necessary to enforce some access control. - - - - - Boreham et al Internet-Draft 9 - - LDAP Extensions for Scrolling View May 2002 - Browsing of Search Results - - Clients can, using this control, determine how many entries are - contained within a portion of the DIT. This may constitute a security - hazard. Again, access controls may be appropriate. - - Server implementers SHOULD exercise caution concerning the content of - the contextID. Should the contextID contain internal server state, it - may be possible for a malicious client to use that information to - gain unauthorized access to information. - - -11. Acknowledgements - - Chris Weider, Anoop Anantha, and Michael Armijo of Microsoft co- - authored previous versions of this document. - - -12. References - - - [LDAPv3] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory - Access Protocol (v3)", Internet Standard, RFC 2251, - December, 1997. - - [SPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP - Control Extension for Simple Paged Results Manipulation", - RFC2696, September 1999. - - [SSS] Wahl, M., Herron, A. and T. Howes, "LDAP Control - Extension for Server Side Sorting of Search Results", - RFC 2891, August, 2000. - - [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - - - - - - - - - - - - - - - - - - Boreham et al Internet-Draft 10 - - LDAP Extensions for Scrolling View May 2002 - Browsing of Search Results - -13. Authors' Addresses - - David Boreham - Bozeman Pass, Inc - +1 406 222 7093 - david@bozemanpass.com - - Jim Sermersheim - Novell, Inc - 1800 South Novell Place - Provo, Utah 84606, USA - jimse@novell.com - - Asaf Kashi - Microsoft Corporation - 1 Microsoft Way - Redmond, WA 98052, USA - +1 425 882-8080 - asafk@microsoft.com - - -14. Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. The limited permissions granted above are perpetual and will - not be revoked by the Internet Society or its successors or assigns. - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE - INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." - - - - - - - - - Boreham et al Internet-Draft 11 \ No newline at end of file diff --git a/doc/drafts/draft-ietf-ldup-lcup-xx.txt b/doc/drafts/draft-ietf-ldup-lcup-xx.txt deleted file mode 100644 index 109f599e5e..0000000000 --- a/doc/drafts/draft-ietf-ldup-lcup-xx.txt +++ /dev/null @@ -1,1298 +0,0 @@ - - -Internet Draft R. Megginson, Editor -Document: M. Smith -Category: Proposed Standard Netscape - Communications Corp. - O. Natkovich - Yahoo - J. Parham - Microsoft Corporation - June 2002 - - - LDAP Client Update Protocol - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [1]. - - 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. - -1. Abstract - - This document defines the LDAP Client Update Protocol (LCUP). The - protocol is intended to allow an LDAP client to synchronize with the - content of a directory information tree (DIT) stored by an LDAP - server and to be notified about the changes to that content. - - -2. Conventions used in this document - - In the protocol flow definition, the notation C->S and S->C - specifies the direction of the data flow from the client to the - server and from the server to the client respectively. - - 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 - [KEYWORDS]. - - -3. Overview - - - - - The LCUP protocol is intended to allow LDAP clients to synchronize - with the content stored by LDAP servers. - - The problem areas addressed by the protocol include: - - - mobile clients that maintain a local read-only copy of the - directory data. While off-line, the client uses the local copy of - the data. When the client connects to the network, it - synchronizes with the current directory content and can be - optionally notified about the changes that occur while it is on- - line. For example, a mail client can maintain a local copy of the - corporate address book that it synchronizes with the master copy - whenever the client gets connected to the corporate network. - - - applications intending to synchronize heterogeneous data stores. - A meta directory application, for instance, would periodically - retrieve a list of modified entries from the directory, construct - the changes and apply them to a foreign data store. - - - clients that need to take certain actions when a directory entry - is modified. For instance, an electronic mail repository may want - to perform a "create mailbox" task when a new person entry is - added to an LDAP directory and a "delete mailbox" task when a - person entry is removed. - - The problem areas not being considered: - - - directory server to directory server synchronization. The IETF is - developing a LDAP replication protocol, called [LDUP], which is - specifically designed to address this problem area. - - There are currently several protocols in use for LDAP client server - synchronization. While each protocol addresses the needs of a - particular group of clients (e.g., on-line clients or off-line - clients) none satisfies the requirements of all clients in the - target group. For instance, a mobile client that was off-line and - wants to become up to date with the server and stay up to date while - connected can't be easily supported by any of the existing - protocols. - - Several features of the protocol distinguish it from LDUP - replication. LCUP is designed such that the server does not need to - maintain state information on behalf of the client. The clients are - responsible for storing the information about how up to date they - are with respect to the server's content. LCUP design avoids the - need for LCUP-specific update agreements to be made between client - and server prior to LCUP use. The client decides when and from where - to retrieve the changes. LCUP design requires clients to initiate - the update session and "pull" the changes from server. - - LCUP operations are subject to administrative and access - control policies enforced by the server. - - - -Megginson, et. al. Proposed Standard - Expires: December 2002 2 - - - - A part of the DIT which is enabled for LCUP is referred to as an - LCUP Context. A server may support one or more LCUP Contexts. - -4. Protocol Specification - - This section describes the protocol elements and the protocol flow. - -4.1 Universally Unique Identifiers - - Distinguished names can change, so are therefore unreliable - as identifiers. The server SHOULD assign a Universally Unique - Identifier (or UUID for short) to each entry as it is created. This - identifier will be stored as an operational attribute of the entry, - named `entryUUID'. The entryUUID attribute is single valued. A - consistent algorithm for generating such universally unique - identifiers may be standardized at some point in the future. - The definition of the entryUUID attribute type, written using the - BNF form of AttributeDescription described in RFC 2252 [RFC2252] is: - - ( OID-To-Be-Specified - NAME `entryUUID' - DESC `universally unique entry identifier' - EQUALITY caseIgnoreMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 - SINGLE-VALUE - NO-USER-MODIFICATION - USAGE directoryOperation ) - -4.2 LCUP Cookie Value - - The LCUP protocol uses a cookie to hold the state of the client's - data with respect to the server's data. The LCUP Cookie is a value - of the following ASN.1 type: - - LCUPCookie ::= SEQUENCE { - scheme LDAPOID, - value OCTET STRING OPTIONAL - } - - scheme - this is the OID which identifies the format of the value. - The scheme OID, like all object identifiers, MUST be unique for a - given cookie scheme. The cookie value may be opaque or it may be - exposed to LCUP clients. For cookie schemes that expose their - value, the preferred form of documentation is an RFC. It is - expected that there will be one or more standards track cookie - schemes where the value format is exposed and described in detail. - - value - this is the actual data describing the state of the - client's data. This value may be opaque, or its value may have - some well-known format, depending on the scheme. The cookie value - MUST be included except when a client has no stored state; i.e., - when the client is requesting a full synchronization. When the - server sends back a cookie, the cookie value MUST be present. - - -Megginson, et. al. Proposed Standard - Expires: December 2002 3 - - - - Further uses of the LCUP Cookie value are described below. - -4.3 Additional LDAP Result Codes defined by LCUP - - The LDAP result code names and numbers defined in the following - table are to be replaced with IANA assigned result code names and - numbers per draft-ietf-ldapbis-iana-xx.txt. - - lcupResourcesExhausted (TBD) the server is running out of - resources - lcupSecurityViolation (TBD) the client is suspected of malicious - actions - lcupInvalidCookie (TBD) invalid cookie was supplied by the - client - both/either the scheme - and/or the value part was invalid - lcupUnsupportedScheme (TBD) The scheme part of the cookie is a - valid OID but is not supported by - this server - lcupClientDisconnect (TBD) client requested search termination - using the LDAP Cancel extended - operation request [CANCEL] - lcupReloadRequired (TBD) indicates that client data needs to - be reinitialized. This reason is - returned if the server does not - contain sufficient information to - synchronize the client or if the - server's data was reloaded since the - last synchronization session - - The uses of these codes are described below. - -4.4 Client Update Control Value - - A client initiates a synchronization session with a server by - attaching a clientUpdate control to an LDAP searchRequest message. - The client SHOULD specify entryUUID in the attributes list in the - searchRequest message. The search specification determines the part - of the directory information tree (DIT) the client wishes to - synchronize with, the set of attributes it is interested in and the - amount of data the client is willing to receive. The clientUpdate - control contains the client's synchronization specification. The - controlType field for the clientUpdate control is - ClientUpdateControlOID (to be assigned). The controlValue is an - OCTET STRING, whose contents are the bytes of the BER encoding of - the following: - - - - - - - - - - -Megginson, et. al. Proposed Standard - Expires: December 2002 4 - - - - ClientUpdateControlValue ::= SEQUENCE { - updateType ENUMERATED { - synchronizeOnly (0), - synchronizeAndPersist (1), - persistOnly (2) }, - sendCookieInterval INTEGER OPTIONAL, - cookie LCUPCookie OPTIONAL - } - - updateType - specifies the type of update requested by the client - - synchronizeOnly - the server sends all the data needed to - synchronize the client with the server, then closes the - connection - - synchronizeAndPersist - the server sends all the data needed to - synchronize the client with the server, then leaves open the - connection, sending to the client any new added, modified, or - deleted entries that satisfy the search criteria. - - persistOnly - the server does not synchronize the data with the - client but leaves open the connection and sends over any new - added, modified, or deleted entries that satisfy the search - criteria. - - sendCookieInterval û (optional) the server SHOULD send the cookie - back in the entryUpdate control value for every - sendCookieInterval number of SearchResultEntry PDUs returned to - the client. For example, if the value is 5, the server SHOULD - send the cookie back in the entryUpdate control value for every 5 - search results returned to the client. If this value is absent, - zero or less than zero, the server chooses the interval. - - cookie - a value that represents the current state of the client's - data. If a cookie is provided, the server MUST use the enclosed - scheme throughout the duration of the LCUP session or until an - LCUP context boundary is crossed, since a new cookie may be - required in that case. If the value or scheme part of the cookie - is invalid, the server MUST return immediately with a - SearchResultDone message with the resultCode set to the value of - lcupInvalidCookie. If the scheme part of the cookie is a valid - OID, but is not supported, the server MUST return immediately - with a SearchResultDone message with the resultCode set to the - value of lcupUnsupportedScheme. - - If the cookie is omitted, the server MAY use any scheme it - supports. - -4.5 Entry Update Control Value - - In response to the client's synchronization request, the server - returns one or more SearchResultEntry PDU that fits the client's - specification. Each SearchResultEntry PDU also contains an - entryUpdateControl that describes the LCUP state of the returned - -Megginson, et. al. Proposed Standard - Expires: December 2002 5 - - - - entry. To represent a deleted entry, the server attaches an - entryUpdate control to the corresponding SearchResultEntry. The - SearchResultEntry corresponding to a deleted entry MUST contain a - valid DN and SHOULD contain a valid UUID but, to reduce the amount - of data sent to the client, it SHOULD not contain any other - attributes. - - Furthermore, the server may elect to periodically return to the - client the cookie that represents the state of the client's data. - This information is useful in case the client crashes or gets - disconnected. The client MAY specify how often to receive the cookie - by the use of the sendCookieInterval in the clientUpdate control - value (see above). If the client does not specify a value, the - server will determine the interval. - - The controlType field for the entryUpdate control is - EntryUpdateControlOID (to be assigned). The controlValue is an - OCTET STRING, whose contents are the bytes of the BER encoding of - the following: - - EntryUpdateControlValue ::= SEQUENCE { - stateUpdate BOOLEAN, - entryDeleted BOOLEAN, - cookie LCUPCookie OPTIONAL - - } - - stateUpdate - if set to TRUE, indicates that the entry to which the - control is attached contains no changes and it is sent only to - communicate to the client the new cookie. In this case, the - entryDeleted field MUST be ignored and the cookie field MUST - contain the updated cookie. This feature allows updating the - client's cookie when there are no changes that effect the - client's data store. Note that the control MUST be attached to a - valid SearchResultEntry, which should contain a valid LDAPDN in - the objectName field, and MAY contain an entryUUID attribute, but - SHOULD NOT contain any other attributes. The server MAY send the - entry named by the baseObject from the client's search request. - - entryDeleted - if set to TRUE, indicates that the entry to which - the control is attached was deleted. The server MAY also set - this to TRUE if the entry has left the client's search result - set. As far as the client is concerned, a deleted entry is no - different than an entry that has left the result set. - - cookie - the LCUP cookie value that represents the current state of - the client's data. - -4.6 Client Update Done Control Value - - When the server has finished processing the client's request, it - attaches a clientUpdateDone control to the SearchResultDone message - and sends it to the client. However, if the SearchResultDone message - contains a resultCode that is not success or lcupClientDisconnect, - -Megginson, et. al. Proposed Standard - Expires: December 2002 6 - - - - the clientUpdateDone control MAY be omitted. The controlType field - for the clientUpdateDone control is ClientUpdateDoneControlOID (to - be assigned). The controlValue is an OCTET STRING, whose contents - are the bytes of the BER encoding of the following: - - ClientUpdateDoneControlValue ::= SEQUENCE { - cookie LCUPCookie OPTIONAL - } - - cookie - the LCUP cookie value that represents the current state of - the client's data. Although this value is OPTIONAL, it MUST be set - in the ClientUpdateDoneControlValue if the SearchResultDone - resultCode is success or lcupClientDisconnect. This provides a - good "checksum" of what the server thinks the state of the client - is. If some error occurred, either an LDAP search error (e.g. - insufficientAccessRights) or an LCUP error (e.g. - lcupUnsupportedScheme), the cookie MAY be omitted. - - If server resources become tight, the server can terminate one or - more search operations by sending a SearchResultDone message to the - client(s) with a resultCode of lcupResourcesExhausted. Unless the - client sets the updateType field to persistOnly, the server attaches - a clientUpdateDone control that contains the cookie that corresponds - to the current state of the client's data. A server set policy is - used to decide which searches to terminate. This can also be used as - a security mechanism to disconnect clients that are suspected of - malicious actions, but if the server can infer that the client is - malicious, the server should return lcupSecurityViolation instead. - -4.7 Client Initiated Termination - - If the client needs to terminate the synchronization process and it - wishes to obtain the cookie that represents the current state of its - data, it issues an LDAP Cancel operation [CANCEL]. The server - responds immediately with a LDAP Cancel response [CANCEL]. The - server MAY send any pending SearchResultEntry PDUs if the server - cannot easily abort or remove those search results from its outgoing - queue. The server SHOULD send as few of these remaining - SearchResultEntry PDUs as possible. Finally, the server sends the - message SearchResultDone with the clientUpdateDone control attached. - - If the client is not interested in the state information, it can - simply abandon the search operation or disconnect from the server. - -4.8 Protocol Flow - - The client server interaction can proceed in three different ways - depending on the client's requirements. Protocol flows beginning - with an asterisk (*) are optional or conditional. - - If the client's intent is not to synchronize data but to trigger - actions in response to directory modifications, the protocol - proceeds as follows: - - -Megginson, et. al. Proposed Standard - Expires: December 2002 7 - - - - C->S Sends a search operation with a clientUpdate control attached. - The search specification determines the part of the DIT the - client wishes to synchronize with and the set of attributes it - is interested in. The updateType field of the control value - should be set to persistOnly. - *S->C If there is an error (invalid search scope, invalid cookie) - the server returns the appropriate error codes and terminates - the request (SearchResultDone message with optional - clientUpdateDone control) - S->C Sends change notification to the client for each change to the - data within the client's search specification. Each - SearchResultEntry may have an entryUpdate control attached. - *S->C If the server starts to run out of resources or the client is - suspected of malicious actions, the server SHOULD terminate - the search operation by sending to the client a - SearchResultDone message with optional clientUpdateDone - control attached. The resultCode in the SearchResultDone - mesasge SHOULD be set to lcupResourcesExhausted or - lcupSecurityViolation depending on the reason for termination. - *C->S If the client receives lcupResourcesExhausted error from the - server, it MUST wait for a while before attempting another - synchronization session with the server. It is RECOMMENDED - that clients use an exponential backoff strategy. - C->S The client terminates the search. The client can do this by - abandoning the search operation, disconnecting from the - server, or by sending an LDAP Cancel operation. - *S->C If the server receives the LDAP Cancel op, it will immediately - send back the LDAP Cancel response - *S->C If the server sent the LDAP Cancel response, the server MAY - send any pending SearchResultEntry PDUs in its outgoing queue - *S->C If the server sent the LDAP Cancel response, after the server - sends the response and any pending SearchResultEntry PDUs, the - server sends the SearchResultDone message with the - clientUpdateDone control attached. The resultCode in the - SearchResultDone message will be either lcupClientDisconnect - or some LDAP error code (not success). - S->C Stops sending changes to the client and closes the connection. - - If the client's intent is to synchronize with the server and then - disconnect, the protocol proceeds as follows: - - C->S Sends a search operation with the clientUpdate control - attached. The search specification determines the part of the - DIT the client wishes to synchronize with, the set of - attributes it is interested in and the amount of data the - client is willing to receive. If this is the initial - synchronization session, the client either does not provide a - cookie or provides a cookie with no value; otherwise, the - cookie field of the control is set to the cookie received from - the server at the end of the last synchronization session. If - the scheme field of the cookie was provided, the server MUST - use that scheme throughout the duration of the LCUP session or - until an LCUP boundary is crossed, since the server will - usually require a different cookie in that case anyway. (Note - -Megginson, et. al. Proposed Standard - Expires: December 2002 8 - - - - that the client can synchronize with different servers during - different synchronization sessions.) The updateType field of - the control value is set to synchronizeOnly. - *S->C If there is an error (invalid search scope, invalid cookie) - the server returns the appropriate error codes and terminates - the request (SearchResultDone message with optional - clientUpdateDone control) - *S->C If no cookie is specified in the clientUpdate control, or if - the value field of the cookie is empty, the server sends all - data that matches the client's search specification followed - by the SearchResultDone message with a clientUpdateDone - control attached. The control contains the cookie that - corresponds to the current state of the client's data. If - synchronization was successful, the resultCode in the - SearchResultDone message should be success. - *S->C If an invalid cookie is specified, the server sends the - SearchResultDone message with the resultCode set to - lcupInvalidCookie. - *S->C If a valid cookie is specified and the data that matches the - search specification has been reloaded or the server does not - contain enough state information to synchronize the client, - the server sends a SearchResultDone message with the - resultCode set to lcupReloadRequired. - *S->C If the cookie is valid and the client is up to date, the - server sends a success response to the client. - S->C If the cookie is valid and there is data to be sent, the - server sends the modified entries to the client. Each - SearchResultEntry contains the attributes requested by the - client in the search specification regardless of whether they - were modified. An entryUpdate control with the entryDeleted - field set to TRUE MUST be attached to every deleted entry. The - server may also periodically attach an entryUpdate control to - the entries sent to the client to indicate the current state - of the client's data. In that case, the cookie field of the - control represents the state of the client's data including - the entry to which the control is attached. Once all the - changes are sent successfully, the server sends a - SearchResultDone with the clientUpdateDone control attached. - The control contains the cookie that represents the current - state of the client's data. The resultCode in the - SearchResultDone message is set to success. If the resultCode - is not success, the server may OPTIONALLY attach the - clientUpdateDone control to the SearchResultDone message. - The client stores the cookie received from the server until - the next synchronization session. - *C->S If the resultCode in the SearchResultDone message is set - lcupReloadRequired, the client clears its data store and - repeats the synchronization process by sending the search - operation with clientUpdate control that contains no cookie, - or that contains a cookie with no value field. - - If the client's intent is to be synchronized with the server and - stay notified about data modifications, the protocol proceeds as - follows: - -Megginson, et. al. Proposed Standard - Expires: December 2002 9 - - - - - C->S The client behaves exactly as in the previous case except it - sets the updateType field in the control value to - synchronizeAndPersist. - S->C The server behaves exactly as in the previous case except the - connection is kept open after the initial set of changes is - sent to the client. A SearchResultDone message is not sent to - the client; instead, the server keeps sending changes to the - client. - *S->C If the server starts to run out of resources or the client is - suspected of malicious actions, the server SHOULD terminate - the search operation by sending to the client a - SearchResultDone message with the resultCode set to - lcupResourcesExhausted or lcupSecurityViolation depending on - the reason for termination. - *C->S If the client receives lcupResourcesExhausted error from the - server, it MUST wait for a while before attempting another - synchronization session with the server. We recommend - exponential backoff strategy. - C->S Sends an LDAP Cancel operation to the server to terminate the - synchronization session. - S->C Responds with an LDAP Cancel response, followed optionally by - SearchResultEntry PDUs, followed by a SearchResultDone with - the clientUpdateDone control optionally attached. If the - control is present, it contains the cookie that represents the - current state of the client's data. The value of the - resultCode in the SearchResultDone message will be either - lcupClientDisconnect or some other LDAPResult resultCode (not - success). The control may not be present if some error - occurred. - -4.9 Size and Time Limits - - The search request size or the time limits can only be imposed for - non-persistent operations, those that set the updateType field of - the ClientUpdateControlValue to synchronizeOnly (for the entire - operation) or synchronizeAndPersist (for the initial synchronization - phase only). All other operations MUST set both limits to 0. The - server SHOULD ignore the limits set for persistent operations. - -4.10 Changes vs. Operations - - A server that supports UUIDs SHOULD communicate a modifyDN - operation by sending the client the current form of the entry (with - its new DN) along with an entryUUID attribute. A server that does - not support UUIDs SHOULD communicate a modifyDN operation by sending - the client a deletion for the previous DN followed by an entry for - the new DN. Note that for servers that do not support UUIDs, no - guarantees are made about the correctness of the client state in the - presence of modifyDN operations. - - Communicating modifyDN operations by sending a delete of the old DN - followed by an entry with the new DN makes it impossible for an LCUP - client to distinguish between a modifyDN operation, which is one - -Megginson, et. al. Proposed Standard - Expires: December 2002 10 - - - - atomic operation, and an delete operation followed by an add of a - new entry. The loss of information about atomicity may cause - problems for some LCUP clients. For example, when an entry is - renamed, a client that manages resources such as a person's mailbox - might delete the mailbox and everything in it instead of merely - changing the name associated with the mailbox. - - Also note that regardless of how a modifyDN operation is - communicated to the client, if the client state shows that the - object that underwent the modifyDN operation was the root of a - subtree, the client MUST infer that the DNs of all objects in the - subtree have changed such that they reflect the new DN of the - subtree root. - -4.11 Operations on the Same Connection - - It is permissible for the client to issue other LDAP operations on - the connection used by the protocol. Since each LDAP - request/response carries a message id there will be no ambiguity - about which PDU belongs to which operation. By sharing the - connection among multiple operations, the server will be able to - conserve its resources. - -4.12 Interactions with Other LDAP Search and Response Controls - - LCUP defines neither restrictions nor guarantees about the ability - to use the LDAP client update control defined in this document in - conjunction with other LDAP controls, except for the following: A - server MAY ignore non-critical controls supplied with the LCUP - control. A server MAY ignore the LCUP control if it is non-critical - and it is supplied with other critical controls. If a server - receives a critical LCUP control with another critical control, and - the server does not support both controls at the same time, the - server SHOULD return unavailableCriticalExtension. - -5. Additional Features - - There are several features present in other protocols or considered - useful by clients that are currently not included in the protocol - primarily because they are difficult to implement on the server. - These features are briefly discussed in this section. This section - is intended to open a discussion on the merits of including and - approaches to implementing these features. - -5.1 Triggered Search Change Type - - This feature is present in the Triggered Search specification. A - flag is attached to each entry returned to the client indicating the - reason why this entry is returned. The possible reasons from the - draft are - "- notChange: the entry existed in the directory and matched the - search at the time the operation is being performed, - - enteredSet: the entry entered the result, - - leftSet: the entry left the result, - -Megginson, et. al. Proposed Standard - Expires: December 2002 11 - - - - - modified: the entry was part of the result set, was modified or - renamed, and still is in the result set." - - The leftSet feature is particularly useful because it indicates to - the client that an entry is no longer within the client's search - specification and the client can remove the associated data from its - data store. Ironically, this feature is the hardest to implement on - the server because the server does not keep track of the client's - state and has no easy way of telling which entries moved out of - scope between synchronization sessions with the client. - - A compromise could be reached by only providing this feature for the - operations that occur while the client is connected to the server. - This is easier to accomplish because the decision about the change - type can be made based only on the change without need for any - historical information. This, however, would add complexity to the - protocol. - -5.2 Persistent Search Change Type - - This feature is present in the Persistent Search specification. - Persistent search has the notion of changeTypes. The client - specifies which type of updates will cause entries to be returned, - and optionally whether the server tags each returned entry with the - type of change that caused that entry to be returned. - - For LCUP, the intention is full synchronization, not partial. Each - entry returned by an LCUP search will have some change associated - with it that may concern the client. The client may have to have a - local index of entries by DN or UUID to determine if the entry has - been added or just modified. It is easy for clients to determine if - the entry has been deleted because the entryDeleted value of the - entryUpdateControl will be TRUE. - -5.3 Sending Changes - - Some earlier synchronization protocols sent the client(s) only the - modified attributes of the entry rather than the entire entry. While - this approach can significantly reduce the amount of data returned - to the client, it has several disadvantages. First, unless a - separate mechanism (like the change type described above) is used to - notify the client about entries moving into the search scope, - sending only the changes can result in the client having an - incomplete version of the data. Let's consider an example. An - attribute of an entry is modified. As a result of the change, the - entry enters the scope of the client's search. If only the changes - are sent, the client would never see the initial data of the entry. - Second, this feature is hard to implement since the server might not - contain sufficient information to construct the changes based solely - on the server's state and the client's cookie. On the other hand, - this feature can be easily implemented by the client assuming that - the client has the previous version of the data and can perform - value by value comparisons. - - -Megginson, et. al. Proposed Standard - Expires: December 2002 12 - - - -5.4 Data Size Limits - - Some earlier synchronization protocols allowed clients to control - the amount of data sent to them in the search response. This feature - was intended to allow clients with limited resources to process - synchronization data in batches. However, an LDAP search operation - already provides the means for the client to specify the size limit - by setting the sizeLimit field in the SearchRequest to the maximum - number of entries the client is willing to receive. While the - granularity is not the same, the assumption is that regular LDAP - clients that can deal with the limitations of the LDAP protocol will - implement LCUP. - -5.5 Data Ordering - - Some earlier synchronization protocols allowed a client to specify - that parent entries should be sent before the children for add - operations and children entries sent before their parents during - delete operations. This ordering helps clients to maintain a - hierarchical view of the data in their data store. While possibly - useful, this feature is relatively hard to implement and is - expensive to perform. - -6. Client Side Considerations - - Clients SHOULD always specify entryUUID in the SearchRequest - attribute list. - - The cookie received from the server after a synchronization session - can only be used with the same or more restrictive search - specification than the search that generated the cookie. The server - will reject the search operation with a cookie that does not satisfy - this condition. This is because the client can end up with an - incomplete data store otherwise. A more restrictive search - specification is the one that generates a subset of the data - produced by the original search specification. - - Because an LCUP client specifies the area of the tree with which it - wishes to synchronize through the standard LDAP search - specification, the client can be returned noSuchObject error if the - root of the synchronization area was renamed between the - synchronization sessions or during a synchronization session. If - this condition occurs, the client can attempt to locate the root by - using the root's UUID saved in client's local data store. It then - can repeat the synchronization request using the new search base. In - general, a client can detect that an entry was renamed and apply the - changes received to the right entry by using the UUID rather than DN - based addressing. - - Each active persistent operation requires that an open TCP - connection be maintained between an LDAP client and an LDAP server - that might not otherwise be kept open. Therefore, client - implementors are encouraged to avoid using persistent operations for - non-essential tasks and to close idle LDAP connections as soon as - -Megginson, et. al. Proposed Standard - Expires: December 2002 13 - - - - practical. The server may close connections if server resources - become tight. - - The client MAY receive a continuation reference - (SearchResultReference [RFC2251 SECTION 4.5.3]) if the search - request spans multiple parts of the DIT, some of which may require a - different LCUP cookie, some of which may not even be managed by - LCUP. The client SHOULD maintain a cache of the LDAP URLs returned - in the continuation references and the cookies associated with them. - The client is responsible for performing another LCUP search to - follow the references, and SHOULD use the cookie corresponding to - the LDAP URL for that reference (if it has a cookie). - - The client may receive a referral (Referral [RFC2251 SECTION - 4.1.11]) when the search base is a subordinate reference, and this - will end the operation. - - For alias dereferencing, the server will behave as if the client had - requested neverDerefAliases or derefFindingBaseObj as the - derefAliases field in the search request [RFC2251, Section 4.5.1]. - If the client specifies a value other than neverDerefAliases or - derefFindingBaseObj, the server will return protocolError to the - client. - - Changes to data (e.g., that might affect the LCUP client's filter or - scope) or meta-data (e.g., that might affect the client's read - access) may affect the presence of entries in the search set. - Servers MAY notify LCUP clients of changes to the search set that - result from such changes, but an LCUP client MUST NOT assume that - such notification will occur. Therefore, in the case where a client - is maintaining a cache of entries using LCUP, the data held by the - client may be a superset or a subset of the entries that would be - returned by a new search request. For example, if access control - meta information is changed to deny access to particular entries in - the search result set, and the access control information is outside - of the search scope (e.g., in a parent entry), the client may have - entries stored locally which are no longer part of its desired - search set. Similarly, if entries are added to the search result - set due to changes in meta-data, the client's cache of entries may - not include these entries. - - Some clients may wish to perform an initial synchronization in order - to prime a cache or establish a baseline set of entries, then look - for changes after that. The recommended way to do this is to first - issue an LCUP search with the updateType field of the clientUpdate - control value set to synchronizeOnly, then after that search - successfully completes, immediately issue an LCUP search with the - updateType field of the clientUpdate control value set to - synchronizeAndPersist. - - Some clients may have unreliable connections, for example, a - wireless device or a WAN connection. These clients may want to - insure that the cookie is returned often in the entryUpdate control - value, so that if they have to reconnect, they do not have to - -Megginson, et. al. Proposed Standard - Expires: December 2002 14 - - - - process many redundant entries. These clients should set the - sendCookieInterval in the clientUpdate control value to a low - number, perhaps even 1. Also, some clients may have a limited - bandwidth connection, and may not want to receive the cookie very - often, or even at all (however, the cookie is always sent back in - the clientUpdateDone control value upon successful completion). - These clients should set the sendCookieInterval in the clientUpdate - control value to a high number. - -7. Server Implementation Considerations - - Servers SHOULD support UUIDs. Otherwise, it will be very difficult - to support modifyDN operations. Adding support for UUIDs should be - seen as a necessary component of LCUP. - - By design, the protocol supports multiple cookie schemes. This is - to allow different implementations the flexibility of storing any - information applicable to their environment. A reasonable - implementation for an LDUP compliant server would be to use the - Replica Update Vector (RUV). For each master, RUV contains the - largest CSN seen from this master. In addition, the RUV implemented - by some directory servers (not yet in LDUP) contains replica - generation - an opaque string that identifies the replica's data - store. The replica generation value changes whenever the replica's - data is reloaded. Replica generation is intended to signal the - replication/synchronization peers that the replica's data was - reloaded and that all other replicas need to be reinitialized. RUV - satisfies the three most important properties of the cookie: (1) it - uniquely identifies the state of client's data, (2) it can be used - to synchronize with multiple servers, and (3) it can be used to - detect that the server's data was reloaded. - - A server may support one or more LCUP cookie schemes. It is - expected that schemes will be published along with their OIDs as - RFCs. If a client initiates an LCUP session with a particular - scheme, the server MUST use that same scheme throughout the LCUP - session, or until an LCUP context boundary is crossed, in which case - the server will usually require a different cookie anyway. - - In addition, the cookie must contain enough information to allow the - server to determine whether the cookie can be safely used with the - search specification it is attached to. As discussed earlier in the - document, the cookie can only be used with the search specification - that is equally or more restrictive than the one for which the - cookie was generated. - - An implementation must make sure that it can correctly update the - client's cookie when there is a size limit imposed on the search - results by either the client's request or by the server's - configuration. If RUV is used as the cookie, entries last modified - by a particular master must be sent to the client in the order of - their last modified CSN. This ordering guarantees that the RUV can - be updated after each entry is sent. - - -Megginson, et. al. Proposed Standard - Expires: December 2002 15 - - - - The server's DIT may be partitioned into different sections which - may have different cookies associated with them. For example, some - servers may use some sort of replication mechanism to support LCUP. - If so, the DIT may be partitioned into multiple replicas. A client - may send an LCUP search request that spans multiple replicas. Some - parts of the DIT spanned by the search request scope may be managed - by LCUP and some may not. A part of the DIT which is enabled for - LCUP is referred to as an LCUP Context. The server SHOULD send a - SearchResultReference [RFC2251, SECTION 4.5.3] when the LCUP Context - for a returned entry changes. The server SHOULD return all entries - for a particular LCUP Context before returning a reference to other - LCUP Contexts or non-LCUP enabled parts of the DIT, in order to - minimize the processing burden on the clients. The LDAP URL(s) - returned MUST contain the DN(s) of the base of another section of - the DIT (however the server implementation has partitioned the DIT). - The client will then issue another LCUP search using the LDAP URL - returned. Each section of the DIT MAY require a different cookie - value, so the client SHOULD maintain a cache, mapping the different - LDAP URL values to different cookies. If the cookie changes, the - scheme may change as well, but the cookie scheme MUST be the same - within a given LCUP Context. - - An implementation SHOULD notify the client about all entries deleted - from the search set since the client's last session, but an LCUP - client MUST NOT assume that such notification will occur. For - example, the server might not notify the client of the deletion of - an object if the object left the search set following the client's - last synchronization and prior to the object's deletion. An LDUP - compliant implementation can achieve this through the use of entry - tombstones. The implementation should avoid aggressive tombstone - purging since lack of tombstones would cause client's data to be - reloaded. We suggest that only the tombstone content be removed - during the regular trimming cycle while tombstones themselves are - discarded much less frequently. - - The specification makes no guarantees about how soon a server should - send notification of a changed entry to the client when the - connection between the client and the server is kept open. This is - intentional as any specific maximum delay would be impossible to - meet in a distributed directory service implementation. Server - implementors are encouraged to minimize the delay before sending - notifications to ensure that clients' needs for timeliness of change - notification are met. - - Implementors of servers that support the mechanism described in this - document should ensure that their implementation scales well as the - number of active persistent operations and the number of changes - made in the directory increases. Server implementors are also - encouraged to support a large number of client connections if they - need to support large numbers of persistent operations. - -8. Synchronizing Heterogeneous Data Stores - - - -Megginson, et. al. Proposed Standard - Expires: December 2002 16 - - - - Clients, like a meta directory join engine, synchronizing multiple - writable data stores will only work correctly if each piece of - information is single mastered (for instance, only by an LDUP - compliant directory). This is because different systems have - different notions of time and different update resolution - procedures. As a result, a change applied on one system can be - discarded by the other, thus preventing the data stores from - converging. - -9. Security Considerations - - In some situations, it may be important to prevent general exposure - of information about changes that occur in an LDAP server. - Therefore, servers that implement the mechanism described in this - document SHOULD provide a means to enforce access control on the - entries returned and MAY also provide specific access control - mechanisms to control the use of the controls and extended - operations defined in this document. - - As with normal LDAP search requests, a malicious client can initiate - a large number of persistent search requests in an attempt to - consume all available server resources and deny service to - legitimate clients. The protocol provides the means to stop - malicious clients by disconnecting them from the server. The servers - that implement the mechanism SHOULD provide the means to detect the - malicious clients. In addition, the servers SHOULD provide the means - to limit the number of resources that can be consumed by a single - client. - - Access control on the data can be modified in such a way that the - data is no longer visible to the client. The specification does not - specify how the server should handle this condition. Moreover, data - consistency is not guaranteed if access control is changed from a - more restrictive to a less restrictive one. This is because access - control can be considered as an additional filter on the search - specification and the protocol does not support going from a more to - a less restrictive search specification. See Client Side - Considerations Section for more detailed explanation of the problem. - -10. Normative References - - [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate - Requirement Levels", RFC 2119, March 1997. - - [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory - Access Protocol", RFC 2251, December 1997. - - [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax - Definitions", RFC 2252, December 1997. - - [CANCEL] K. Zeilenga, "LDAP Cancel Extended Operation", - draft-zeilenga-ldap-cancel-xx.txt, a work in progress. - - -Megginson, et. al. Proposed Standard - Expires: December 2002 17 - - - -11. Acknowledgements - - The LCUP protocol is based in part on the Persistent Search Change - Notification Mechanism defined by Mark Smith, Gordon Good, Tim - Howes, and Rob Weltman, the LDAPv3 Triggered Search Control defined - by Mark Wahl, and the LDAP Control for Directory Synchronization - defined by Michael Armijo. - -12. Author's Addresses - - Rich Megginson - Netscape Communications Corp. - 901 San Antonio Rd. - Palo Alto, CA 94303-4900 - Mail Stop SCA17 - 201 - Phone: +1 505 797-7762 - Email: richm@netscape.com - - Olga Natkovich - Yahoo, Inc. - 701 First Ave. - Sunnyvale, CA 94089 - Phone: +1 408 349-6153 - Email: olgan@yahoo-inc.com - - Mark Smith - Netscape Communications Corp. - 901 San Antonio Rd. - Palo Alto, CA 94303-4900 - Mail Stop SCA17 - 201 - Phone: +1 650 937-3477 - Email: mcs@netscape.com - - Jeff Parham - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052-6399 - Phone: +1 425 882-8080 - Email: jeffparh@microsoft.com - -13. Full Copyright Statement - "Copyright (C) The Internet Society (date). All Rights Reserved. - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - -Megginson, et. al. Proposed Standard - Expires: December 2002 18 - - - - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -14. Appendix A - Summary of Changes - - Changes new to version 03: - - Emphasized the use of UUIDs throughout the document. Implementers - are strongly encouraged to use UUIDs as a necessary component of - the protocol. - - Removed the LCUP Cancel extended operation in favor of the new - LDAP Cancel operation [CANCEL]. - - Got rid of the lcupSuccess result code. All result codes will be - added to the IANA LDAP result code registry as part of the LDAP - standard. Also removed the result code and text from the client - update done control value. - - Changed any and all wording suggesting an LCUP Context is related - to a naming context. New text says an LCUP Context is a part of - the DIT that supports LCUP, and that a server may have one or more - LCUP Contexts. - - Removed Old Section 4.2: lcupCookieScheme - We decided that LCUP did not need a discovery mechanism. The - controls and extended operations will be published in the root DSE - as per the LDAP standards. - - Changed references to "Unique Identifier" to either "Universally - Unique Identifier" or "UUID". - - Added this text to section 6 "Client Side Considerations": - "- The client may receive a referral (Referral [RFC2251 SECTION - 4.1.11]) when the search base is a subordinate reference, and - this will end the operation." - - Added a note to section 6 "Client Side Considerations" about how - to establish a baseline set of entries or entry cache. - - Added the field sendCookieInterval to the clientUpdate control - value. - - Added a note to section 6 "Client Side Considerations" explaining - possible uses of the sendCookieInterval. - -Megginson, et. al. Proposed Standard - Expires: December 2002 19 - - - - - Changes new to version 02: - - Section 4.2: The lcupCookieScheme operational attribute MUST be - present in the root DSE, and MAY be present in entries. Each - value of the attribute in the root DSE will be a list of OIDs of - cookie schemes followed by the DN of the LCUP context which - supports the schemes. The attribute value in the DIT entries will - be the list of OIDs followed by the DN of the LCUP context. - - section 4.5 - the entry uuid is now MAY instead of MUST - if - implementers do not wish to identify entries by a unique ID other - than DN (which may not be unique), then so be it. For returned - SearchResultEntry PDUs other than deleted entries, the client MAY - request that the Unique Identifier attribute be returned by - specifying it in the attribute list to be returned by the search - request. - - section 4.5 - added "or the base DN of the client's search - request." to the phrase. "The server MAY send the entry at the - root of the client's tree, or the base DN of the client's search - request." I think this clarifies which entry the client may - search for. - - section 4.6 - the clientUpdateDone control is now optional for - error conditions. Also, the cookie value of the control is now - optional for lcup error conditions (e.g. not lcupSuccess or - lcupClientDisconnect). - - Added section 4.12 - Interactions with Other LDAP Search and - Response Controls - - Added blurb about alias dereferencing back to section 6: - "For alias dereferencing, the server will behave as if the client - had requested neverDerefAliases or derefFindingBaseObj as the - derefAliases field in the search request [RFC2251, Section 4.5.1]. - If the client specifies a value other than neverDerefAliases or - derefFindingBaseObj, the server will return protocolError to the - client." - - Changed this in section 6: - Because an LCUP client specifies the area of the tree with which - it wishes to synchronize through the standard LDAP search - specification, the client can be returned noSuchObject error if - the root of the synchronization area was renamed between the - synchronization sessions "or during a synchronization session" - - Changes new to version 01: - - The opaque cookie has been split into two parts - a scheme which - is an OID, and a value. The value may or may not have a format - known to the client, depending on the specified scheme. Section - 4.2 describes the new cookie format and defines the LCUP Cookie - Value. - -Megginson, et. al. Proposed Standard - Expires: December 2002 20 - - - - - Added new section 4.3 - the lcupCookieScheme operational - attribute. - - Changes new to version 00: - - Added the definition for Unique Identifier (basically copied from - the LDUP model doc http://search.ietf.org/internet-drafts/draft- - ietf-ldup-model-06.txt. I needed to add the definition here - because LCUP needs a Unique Identifier but should not be dependent - on LDUP. - - Removed all normative references to LDUP. I've left the - implementation suggestions that refer to LDUP, but LCUP should not - be dependent on LDUP. - - Cleaned up the protocol flows. - - Removed this text from section 4.8: "Clients MUST NOT issue - multiple synchronization requests on the same connection. This is - because the protocol includes an extended operation and it would - be impossible to decide which synchronization session it belongs - to." - This is no longer true, since the extended operation now - includes the message ID of the search request. - - "Client Side Consideration" section - the client will never - receive a referral or continuation reference - - Added section 12. Acknowledgements - - Removed normative references to documents not depended on. - - Removed explicit references to software vendors. - - Section 4.1 - Changed ClientUpdateControlValue to remove the - keepConnection and changesOnly fields and replace them with - updateType which is an ENUMERATED with three values: - synchronizeOnly, synchronizeAndPersist, and persistOnly. - - Section 4.2 - The EntryUpdateControlValue fields stateUpdate and - entryDeleted no longer have DEFAULT values, they must be specified - - this eliminates any potential ambiguity. - - Added this text to the description of the entryDeleted field - (section 4.2): "The server SHOULD also set this to TRUE if the - entry has left the clients search result set. As far as the client - is concerned, a deleted entry is no different than an entry which - has left the result set." - Section 4.2 - Added an explanation of the concept and requirement - for the Unique Identifier. - - Section 4.4 - Added to the extended operation a request value - containing the message id of the operation to stop. - - -Megginson, et. al. Proposed Standard - Expires: December 2002 21 - - - - Updated contact information for Olga. - - Removed Michael Armijo and added Jeff Parham as an author. - - Changes new to previous version: - - "Authors" section - added Rich Megginson as the new editor. - - "Client Side Consideration" section - added a note and a question - concerning referral and continuation reference handling. - - "Client Update Control Value" section (4.1) - clarified the meaning - of keepConnection and added a table summarizing the effects of - different values of keepConnection and changesOnly. - - "Stop Client Update Request and Response" - added section 4.4 - describing this extended operation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Megginson, et. al. Proposed Standard - Expires: December 2002 22 - \ No newline at end of file diff --git a/doc/drafts/draft-weltman-ldapv3-proxy-xx.txt b/doc/drafts/draft-weltman-ldapv3-proxy-xx.txt deleted file mode 100644 index a97e8cdb3c..0000000000 --- a/doc/drafts/draft-weltman-ldapv3-proxy-xx.txt +++ /dev/null @@ -1,351 +0,0 @@ - - -INTERNET-DRAFT Rob Weltman -Intended Category: Standards Track Netscape Communications Corp. - May 2002 - - LDAP Proxied Authorization Control - draft-weltman-ldapv3-proxy-11.txt - - -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 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. - - -Abstract - - This document defines the Lightweight Directory Access Protocol - (LDAP) Proxied Authorization Control. The Proxied Authorization - Control allows a client to request that an operation be processed - under a provided authorization identity [AUTH] instead of as the - current authorization identity associated with the connection. - - -1. Introduction - - This document defines support for proxied authorization using the - Control mechanism. LDAP [LDAPV3] supports the use of SASL [SASL] for - authentication and for supplying an authorization identity distinct - from the authentication identity, where the authorization identity - applies to the whole LDAP session. The proposed Proxied Authorization - Control provides a mechanism for specifying an authorization identity - on a per operation basis, benefiting clients that need to efficiently - perform operations on behalf of multiple users. - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and - "MAY NOT" used in this document are to be interpreted as described - in [KEYWORDS]. - - - -Expires November 2002 [Page 1] - -PROXIED AUTHORIZATION CONTROL May 2002 - - -2. Publishing support for the Proxied Authorization Control - - Support for the Proxied Authorization Control is indicated by the - presence of the OID "2.16.840.1.113730.3.4.18" in the - supportedControl attribute of a server's root DSE. - - -3. Proxied Authorization Control - - A single Proxied Authorization Control may be included in any search, - compare, modify, add, delete, modDN or extended operation request - message (with the exception of any extension that causes a change in - authentication, authorization, or data confidentiality [RFC 2828], - such as startTLS) as part of the controls field of the LDAPMessage, - as defined in [LDAPV3]. - - The controlType of the proxied authorization control is - "2.16.840.1.113730.3.4.18". - - The criticality MUST be present and MUST be TRUE. This requirement - protects clients from submitting a request that is executed with an - unintended authorization identity. - - The controlValue is either an LDAPString [LDAPv3] containing an - authzId as defined in section 9 of [AUTH] to use as the authorization - identity for the request, or an empty value if the anonymous identity - is to be used. - - The mechanism for determining proxy access rights is specific to the - server's access control policy. - - If the requested authorization identity is recognized by the server, - and the client is authorized to adopt the requested authorization - identity, the request will be executed as if submitted by the proxied - authorization identity, otherwise the result code TBD is returned. - [Note to the IESG/IANA/RFC Editor: the value TBD is to be replaced - with an IANA assigned LDAP Result Code (see draft-ietf-ldapbis-iana- - xx.txt, Section 3.5)] - - -4. Implementation Considerations - - The interaction of proxied authorization access control and normal - access control is illustrated here for the case of search requests. - During evaluation of a search request, an entry which would have been - returned for the search if submitted by the proxied authorization - identity directly may not be returned if the server finds that the - requester does not have the right to assume the requested identity - for searching the entry, even if the entry is within the scope of a - search request under a base DN which does imply such rights. This - means that fewer results, or no results, may be returned compared to - the case where the proxied authorization identity issued the request - directly. An example of such a case may be a system with fine-grained - -Expires November 2002 [Page 2] - -PROXIED AUTHORIZATION CONTROL May 2002 - - - access control, where the proxy right requester has proxy rights at - the top of a search tree, but not at or below a point or points - within the tree. - - -5. Security Considerations - - The Proxied Authorization Control method is subject to general LDAP - security considerations [LDAPV3] [AUTH] [LDAPTLS]. The control may be - passed over a secure as well as over an insecure channel. - - The control allows for an additional authorization identity to be - passed. In some deployments, these identities may contain - confidential information which require privacy protection. - - Note that the server is responsible for determining if a proxied - authorization request is to be honored. "Anonymous" users SHOULD NOT - be allowed to assume the identity of others. - - -6. Copyright - - Copyright (C) The Internet Society (date). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -7. References - - [LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - -Expires November 2002 [Page 3] - -PROXIED AUTHORIZATION CONTROL May 2002 - - - - [KEYWORDS] Bradner, Scott, "Key Words for use in RFCs to Indicate - Requirement Levels", draft-bradner-key-words-03.txt, January, - 1997. - - [SASL] J. Myers, "Simple Authentication and Security Layer (SASL)", - RFC 2222, October 1997 - - [AUTH] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication - Methods for LDAP", RFC 2829, May 2000 - - [LDAPTLS] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory - Access Protocol (v3): Extension for Transport Layer Security", - RFC 2830, May 2000 - - [RFC 2828] R. Shirey, "Internet Security Glossary", RFC 2828, May - 2000 - -8. Author's Address - - Rob Weltman - Netscape Communications Corp. - 466 Ellis Street - Mountain View, CA 94043 - USA - +1 650 937-3194 - rweltman@netscape.com - - -9. Acknowledgements - - Mark Smith of Netscape Communications Corp., Mark Wahl of Sun - Microsystems, Inc, Kurt Zeilenga of OpenLDAP Foundation, Jim - Sermersheim of Novell, and Steven Legg of Adacel have contributed - with reviews of this draft. - - -10. Revision History - -10.1 Changes from draft-weltman-ldapv3-proxy-10.txt - - Clarified the interaction of proxy access rights and normal access - control evaluation. - - -10.2 Changes from draft-weltman-ldapv3-proxy-09.txt - - Removed description of Control mechanism from Abstract. - - Added description of how this is different from SASL authz to the - Introduction. - - -Expires November 2002 [Page 4] - -PROXIED AUTHORIZATION CONTROL May 2002 - - - Reworded description of the value of the control (no semantic - changes). - Added new result code TBD for failure to acquire proxy rights. - - Added references to RFCs 2829 and 2830 in Security section. - - -10.3 Changes from draft-weltman-ldapv3-proxy-08.txt - - Proxied Authorization Control - - Clarifications: the control may not be submitted with a startTLS - request; an empty controlValue implies the anonymous identity; only - one control may be included with a request. - - Permission to execute as proxy - - Replaced "proxy identity" with "proxied authorization identity". - - - Security Considerations - - Added statement that anonymous users should not be allowed to assume - the identity of others. - - -10.4 Changes from draft-weltman-ldapv3-proxy-07.txt - - Proxied Authorization Control - - Clarification: the content of the control is an LDAPString. - - -10.5 Changes from draft-weltman-ldapv3-proxy-06.txt - - None - - - - - - - - - - - - - - - - - -Expires November 2002 [Page 5] - -PROXIED AUTHORIZATION CONTROL May 2002 - - -10.6 Changes from draft-weltman-ldapv3-proxy-05.txt - - The control also applies to add and extended operations. - - The control value is an authorization ID, not necessarily a DN. - - Confidentiality concerns are mentioned. - - -10.7 Changes from draft-weltman-ldapv3-proxy-04.txt - - The control does not apply to bind, unbind, or abandon operations. - - The proxy DN is represented as a string in the control, rather than - embedded in a sequence. - - Support for the control is published in the supportedControl - attribute of the root DSE, not in supportedExtensions. - - The security section mentions confidentiality issues with exposing an - additional identity. - - -10.8 Changes from draft-weltman-ldapv3-proxy-03.txt - - None - - - -10.9 Changes from draft-weltman-ldapv3-proxy-02.txt - - The Control is now called Proxied Authorization Control, rather than - Proxied Authentication Control, to reflect that no authentication - occurs as a consequence of processing the Control. - - Rather than containing an LDAPDN as the Control value, the Control - contains a Sequence (which contains an LDAPDN). This is to provide - for future extensions. - - - - - - - - - - - - - - - -Expires November 2002 [Page 6] - \ No newline at end of file diff --git a/doc/drafts/draft-zeilenga-ldap-cancel-xx.txt b/doc/drafts/draft-zeilenga-ldap-cancel-xx.txt deleted file mode 100644 index 9ea467ec0f..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-cancel-xx.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 17 May 2002 - - - LDAP Cancel Extended Operation - - - -1. Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extension Working Group - mailing list . Please send editorial - comments directly to the author . - - 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 - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright 2002, The Internet Society. All Rights Reserved. - - Please see the Copyright section near the end of this document for - more information. - - -Abstract - - This specification describes an LDAP (Lightweight Directory Access - Protocol) extended operation to cancel (or abandon) an outstanding - operation. Unlike the LDAP Abandon operation but like the X.511 DAP - Abandon operation, this operation has a response which provides an - indication of its outcome. - - - - -Zeilenga LDAP Cancel [Page 1] - -INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002 - - -Conventions - - 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 BCP 14 [RFC2119]. - - Protocol elements are described using ASN.1 [X.680]. The term - "BER-encoded" means the element is to be encoded using the Basic - Encoding Rules [X.690] under the restrictions detailed in Section 5.1 - of [RFC2251]. - - -1. Background and Intent of Use - - LDAP [RFC2251] provides an Abandon operation which clients may use to - cancel other operations. The Abandon operation does not have a - response and also calls for there to be no response of the abandoned - operation. These semantics provide the client with no clear - indication of the outcome of the Abandon operation. - - X.511 DAP [X.511] provides an Abandon operation which does have a - response and also requires the abandoned operation to return a - response with indicating it was canceled. The Cancel operation is - modeled after the DAP Abandon operation. - - The Cancel operation SHOULD be used instead of the LDAP Abandon - operation when the client needs an indication of the outcome. This - operation may be used to cancel both interrogation and update - operations. - - -4. Cancel Operation - - The Cancel operation is defined as a LDAPv3 Extended Operation - [RFC2251, Section 4.12] identified by the OBJECT IDENTIFIER cancelOID. - This section details the syntax of the Cancel request and response - messages and defines additional LDAP resultCodes. - - cancelOID OBJECT IDENTIFIER ::= IANA-ASSIGNED - - cancelRequestValue ::= SEQUENCE { - cancelID MessageID - } - - -4.1. Cancel Request - - The Cancel request is an ExtendedRequest with the requestName field - - - -Zeilenga LDAP Cancel [Page 2] - -INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002 - - - containing cancelOID OID and a requestValue field which contains a - cancelRequestValue value encoded per [RFC2251, Section 5.1]. The - cancelID field contains the message id associated with the operation - to be canceled. - - -4.2. Cancel Response - - A Cancel response is an ExtendedResponse where the responseName and - response fields are absent. - - -4.3. Additional Result Codes - - Implementations of this specification SHALL recognize the following - additional resultCode values: - - canceled (IANA-ASSIGNED-1) - noSuchOperation (IANA-ASSIGNED-2) - tooLate (IANA-ASSIGNED-3) - cannotCancel (IANA-ASSIGNED-4) - - -5. Operational Semantics - - The function of the Cancel Operation is to request that the server - cancel an outstanding operation issued within the same session. - - The client requests the cancelation of an outstanding operation by - issuing a Cancel Response with a cancelID with the message id - identifying the outstanding operation. The Cancel Request itself has - a distinct message id. Clients SHOULD NOT request cancelation of an - operation multiple times. - - If the server is unable to parse the requestValue or the requestValue - is absent, the server shall return protocolError. - - If the server is willing and able to cancel the outstanding operation - identified by the cancelId, the server SHALL return a Cancel Response - with a success resultCode and the canceled operation SHALL fail with - canceled resultCode. Otherwise the Cancel Response SHALL have a - non-success resultCode and SHALL NOT have impact upon the outstanding - operation (if it exists). - - The server SHALL return noSuchOperation if it has no knowledge of the - operation requested to be canceled. - - The server SHALL return cannotCancel if the identified operation does - - - -Zeilenga LDAP Cancel [Page 3] - -INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002 - - - not support cancelation or the cancel operation could not be - performed. The following classes of operations are not cancelable: - - - operations which have no response, - - - operations which associate or disassociate authentication and/or - authorization associations, - - - operations which establish or tear-down security services, and - - - operations which abandon or cancel other operations. - - Specifically, Abandon, Bind, Start TLS [RFC2830], Unbind and Cancel - operations are not cancelable. - - If the result of the outstanding operation has been determined by the - server, the outstanding operation SHALL NOT be canceled and the cancel - operation SHALL result in tooLate. - - Servers SHOULD indicate their support for this extended operation by - providing cancelOID as a value of the supportedExtension attribute - type in their root DSE. A server MAY choose to advertise this - extension only when the client is authorized and/or has established - the necessary security protections to use this operation. Clients - SHOULD verify the server implements this extended operation prior to - attempting the operation by asserting the supportedExtension attribute - contains a value of cancelOID. - - -6. Security Considerations - - This operation is intended to allow a user to cancel operations they - previously issued. No user should be allowed to cancel an operation - issued by another user (within the same session or not). However, as - this operation may only be used to cancel within the same session and - LDAP requires operations to be abandoned upon bind requests, this is a - non-issue. - - Some operations should not be cancelable for security reasons. This - specification disallows cancelation of Bind operation and Start TLS - extended operation so as to avoid adding complexity to authentication, - authorization, and security layer semantics. Designers of future - extended operations and/or controls SHOULD disallow abandonment and - cancelation when appropriate. - - -7. IANA Considerations - - - - -Zeilenga LDAP Cancel [Page 4] - -INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002 - - -7.1. Object Identifiers - - It is requested that IANA register a Directory Number OID for use in - this document upon Standards Action by the IESG. This OID will be - used to identify the LDAP Cancel extended operation as indicated - above. The following registration template is suggested: - - Subject: Request for LDAP OID Registration - Person & email address to contact for further information: - Kurt Zeilenga - Specification: RFCXXX - Author/Change Controller: IESG - - -7.2. LDAP Result Codes - - It is requested that IANA register the LDAP result codes: - - canceled (IANA-ASSIGNED-1) - noSuchOperation (IANA-ASSIGNED-2) - tooLate (IANA-ASSIGNED-3) - cannotCancel (IANA-ASSIGNED-4) - - upon Standards Action by the IESG. The following registration - template is suggested: - - Subject: LDAP Result Code Registration - Person & email address to contact for further information: - Kurt Zeilenga - Result Code Name: canceled - Result Code Name: noSuchOperation - Result Code Name: tooLate - Result Code Name: cannotCancel - Specification: RFCXXXX - Author/Change Controller: IESG - Comments: request four consecutive result codes be assigned - - -8. Acknowledgment - - This document is based upon input from the IETF LDAPext working group. - - -9. Normative References - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - - - -Zeilenga LDAP Cancel [Page 5] - -INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002 - - - [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory - Access Protocol (v3): Extension for Transport Layer - Security", RFC 2830, May 2000. - - [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification - of Basic Notation", X.680, 1994. - - [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, - Canonical, and Distinguished Encoding Rules", X.690, 1994. - - -9. Informative References - - [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service - Definition", 1993. - - -11. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - - -Copyright 2002, The Internet Society. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, - - - -Zeilenga LDAP Cancel [Page 6] - -INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002 - - - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga LDAP Cancel [Page 7] - diff --git a/doc/drafts/draft-zeilenga-ldap-collective-xx.txt b/doc/drafts/draft-zeilenga-ldap-collective-xx.txt deleted file mode 100644 index 4411e64b64..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-collective-xx.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -INTERNET-DRAFT Editor: Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 17 May 2002 - - - Collective Attributes in LDAP - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extension Working Group - mailing list . Please send editorial - comments directly to the author . - - 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 - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright 2002, The Internet Society. All Rights Reserved. - - Please see the Copyright section near the end of this document for - more information. - - -Abstract - - X.500 collective attributes allow common characteristics to be shared - between collections of entries. This document summarizes the X.500 - information model for collective attributes and describes use of - collective attributes in LDAP (Lightweight Directory Access Protocol). - This document provides schema definitions for collective attributes - for use in LDAP. - - - -Zeilenga draft-zeilenga-ldap-collective-07 [Page 1] - -INTERNET-DRAFT LDAP Collective Attributes 17 May 2002 - - -Conventions - - Schema definitions are provided using LDAPv3 description formats - [RFC2252]. Definitions provided here are formatted (line wrapped) for - readability. - - 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 BCP 14 [RFC2119]. - - -1. Introduction - - In X.500, a collective attribute is "a user attribute whose values are - the same for each member of an entry collection" [X.501]. This - document details their use in the Lightweight Directory Access - Protocol (LDAP) [LDAPTS]. - - -1.1. Entry Collections - - A collection of entries is a grouping of object and alias entries - based upon common properties or shared relationship between the - corresponding entries which share certain attributes. An entry - collection consists of all entries within scope of a collective - attributes subentry [SUBENTRY]. An entry can belong to several entry - collections. - - -1.2. Collective Attributes - - Attributes shared by the entries comprising an entry collection are - called collective attributes. Values of collective attributes are - visible but not updateable to clients accessing entries within the - collection. Collective attributes are updated (i.e. modified) via - their associated collective attributes subentry. - - When an entry belongs to multiple entry collections, the entry's - values of each collective attribute are combined such that independent - sources of these values are not manifested to clients. - - Entries can specifically exclude a particular collective attribute by - listing the attribute as a value of the collectiveExclusions - attribute. Like other user attributes, collective attributes are - subject to a variety of controls including access, administrative, and - content controls. - - - - - -Zeilenga draft-zeilenga-ldap-collective-07 [Page 2] - -INTERNET-DRAFT LDAP Collective Attributes 17 May 2002 - - -2. System Schema for Collective Attributes - - The following operational attributes are used to manage Collective - Attributes. LDAP servers [LDAPTS] MUST act in accordance with the - X.500 Directory Models [X.501] when providing this service. - - -2.1. collectiveAttributeSubentry - - Subentries of this object class are used to administer collective - attributes and are referred to as collective attribute subentries. - - ( 2.5.20.2 NAME 'collectiveAttributeSubentry' AUXILIARY ) - - A collective attribute subentry SHOULD contain at least one collective - attribute. The collective attributes contained within a collective - attribute subentry are available for finding, searching, and - comparison at every entry within the scope of the subentry. The - collective attributes, however, are administered (e.g. modified) via - the subentry. - - Implementations of this specification SHOULD support collective - attribute subentries in both collectiveAttributeSpecificArea - (2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative - areas [SUBENTRY][X.501]. - - -2.2. collectiveAttributeSubentries - - The collectiveAttributeSubentries operational attribute identifies all - collective attribute subentries that affect the entry. - - ( 2.5.18.12 NAME 'collectiveAttributeSubentries' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 - USAGE directoryOperation NO-USER-MODIFICATION ) - - -2.3. collectiveExclusions - - The collectiveExclusions operational attribute allows particular - collective attributes to be excluded from an entry. It MAY appear in - any entry and MAY have multiple values. - - ( 2.5.18.7 NAME 'collectiveExclusions' - EQUALITY objectIdentifierMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 - USAGE directoryOperation ) - - - -Zeilenga draft-zeilenga-ldap-collective-07 [Page 3] - -INTERNET-DRAFT LDAP Collective Attributes 17 May 2002 - - - The descriptor excludeAllCollectiveAttributes is associated with the - OID 2.5.18.0. When this descriptor or OID is present as a value of - the collectiveExclusions attribute, all collective attributes are - excluded from an entry. - - -3. Collective Attribute Types - - A userApplications attribute type can be defined to be COLLECTIVE - [RFC2252]. This indicates that the same attribute values will appear - in the entries of an entry collection subject to the use of the - collectiveExclusions attribute and other administrative controls. - These administrative controls MAY include DIT Content Rules, if - implemented. - - Collective attribute types are commonly defined as subtypes of non- - collective attribute types. By convention, collective attributes are - named by prefixing the name of their non-collective supertype with - "c-". For example, the collective telephone attribute is named - c-TelephoneNumber after its non-collective supertype telephoneNumber. - - Non-collective attributes types SHALL NOT subtype collective - attributes. - - Collective attributes SHALL NOT be SINGLE-VALUED. Collective - attribute types SHALL NOT appear in the attribute types of an object - class definition. - - Operational attributes SHALL NOT be defined to be collective. - - The remainder of section provides a summary of collective attributes - derived from those defined in [X.520]. The SUPerior attribute types - are described in [RFC 2256] for use with LDAP. - - Implementations of this specification SHOULD support the following - collective attributes and MAY support additional collective - attributes. - - -3.1. Collective Locality Name - - The c-l attribute type specifies a locality name for a collection of - entries. - - ( 2.5.4.7.1 NAME 'c-l' - SUP l COLLECTIVE ) - - - - - -Zeilenga draft-zeilenga-ldap-collective-07 [Page 4] - -INTERNET-DRAFT LDAP Collective Attributes 17 May 2002 - - -3.2. Collective State or Province Name - - The c-st attribute type specifies a state or province name for a - collection of entries. - - ( 2.5.4.8.1 NAME 'c-st' - SUP st COLLECTIVE ) - - -3.3. Collective Street Address - - The c-street attribute type specifies a street address for a - collection of entries. - - ( 2.5.4.9.1 NAME 'c-street' - SUP street COLLECTIVE ) - - -3.4. Collective Organization Name - - The c-o attribute type specifies an organization name for a collection - of entries. - - ( 2.5.4.10.1 NAME 'c-o' - SUP o COLLECTIVE ) - - -3.5. Collective Organizational Unit Name - - The c-ou attribute type specifies an organizational unit name for a - collection of entries. - - ( 2.5.4.11.1 NAME 'c-ou' - SUP ou COLLECTIVE ) - - -3.6. Collective Postal Address - - The c-PostalAddress attribute type specifies a postal address for a - collection of entries. - - ( 2.5.4.16.1 NAME 'c-PostalAddress' - SUP postalAddress COLLECTIVE ) - - -3.7. Collective Postal Code - - The c-PostalCode attribute type specifies a postal code for a - - - -Zeilenga draft-zeilenga-ldap-collective-07 [Page 5] - -INTERNET-DRAFT LDAP Collective Attributes 17 May 2002 - - - collection of entries. - - ( 2.5.4.17.1 NAME 'c-PostalCode' - SUP postalCode COLLECTIVE ) - - -3.8. Collective Post Office Box - - The c-PostOfficeBox attribute type specifies a post office box for a - collection of entries. - - ( 2.5.4.18.1 NAME 'c-PostOfficeBox' - SUP postOfficeBox COLLECTIVE ) - - -3.9. Collective Physical Delivery Office Name - - The c-PhysicalDeliveryOfficeName attribute type specifies a physical - delivery office name for a collection of entries. - - ( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName' - SUP physicalDeliveryOfficeName COLLECTIVE ) - - -3.10. Collective Telephone Number - - The c-TelephoneNumber attribute type specifies a telephone number for - a collection of entries. - - ( 2.5.4.20.1 NAME 'c-TelephoneNumber' - SUP telephoneNumber COLLECTIVE ) - - -3.11. Collective Telex Number - - The c-TelexNumber attribute type specifies a telex number for a - collection of entries. - - ( 2.5.4.21.1 NAME 'c-TelexNumber' - SUP telexNumber COLLECTIVE ) - - -3.13. Collective Facsimile Telephone Number - - The c-FacsimileTelephoneNumber attribute type specifies a facsimile - telephone number for a collection of entries. - - ( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber' - - - -Zeilenga draft-zeilenga-ldap-collective-07 [Page 6] - -INTERNET-DRAFT LDAP Collective Attributes 17 May 2002 - - - SUP facsimileTelephoneNumber COLLECTIVE ) - - -3.14. Collective International ISDN Number - - The c-InternationalISDNNumber attribute type specifies an - international ISDN number for a collection of entries. - - ( 2.5.4.25.1 NAME 'c-InternationalISDNNumber' - SUP internationalISDNNumber COLLECTIVE ) - - -4. Security Considerations - - Collective attributes are not believed to introduce any additional - security considerations to LDAP [LDAPTS]. - - -5. IANA Considerations - - It is requested that IANA register the LDAP descriptors used in this - document per the following registration template: - - Subject: Request for LDAP Descriptor Registration - Descriptor (short name): see comment - Object Identifier: see comment - Person & email address to contact for further information: - Kurt Zeilenga - Usage: see comment - Specification: RFCXXXX - Author/Change Controller: IESG - Comments: - - NAME Type OID - ------------------------ ---- ----------------- - c-FacsimileTelephoneNumber A 2.5.4.23.1 - c-InternationalISDNNumber A 2.5.4.25.1 - c-PhysicalDeliveryOffice A 2.5.4.19.1 - c-PostOfficeBox A 2.5.4.18.1 - c-PostalAddress A 2.5.4.16.1 - c-PostalCode A 2.5.4.17.1 - c-TelephoneNumber A 2.5.4.20.1 - c-TelexNumber A 2.5.4.21.1 - c-l A 2.5.4.7.1 - c-o A 2.5.4.10.1 - c-ou A 2.5.4.11.1 - c-st A 2.5.4.8.1 - c-street A 2.5.4.9.1 - - - -Zeilenga draft-zeilenga-ldap-collective-07 [Page 7] - -INTERNET-DRAFT LDAP Collective Attributes 17 May 2002 - - - collectiveAttributeSubentries A 2.5.18.12 - collectiveAttributeSubentry O 2.5.20.2 - collectiveExclusions A 2.5.18.7 - - where Type A is Attribute and Type O is ObjectClass. - - - This document uses in this document were assigned by the ISO/IEC Joint - Technical Committee 1 - Subcommitte 6 to identify elements of X.500 - schema. This document make no OID assignments, it only associates - LDAP schema descriptions with existing elements of X.500 schema. - - -6. Acknowledgments - - This document is based upon the ITU Recommendations for the Directory - [X.501][X.520]. - - -7. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - - -8. Normative References - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax - Definitions", RFC 2252, December 1997. - - [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use - with LDAPv3", RFC 2256, December 1997. - - [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", - draft-ietf-ldapbis-ldapv3-ts-xx.txt. - - [SUBENTRY] K. Zeilenga, S. Legg, "Subentries in LDAP", - draft-zeilenga-ldap-subentry-xx.txt, a work in progress. - - - - -Zeilenga draft-zeilenga-ldap-collective-07 [Page 8] - -INTERNET-DRAFT LDAP Collective Attributes 17 May 2002 - - - [X.501] "The Directory: Models", ITU-T Recommendation X.501, 1993. - - -9. Informative References - - [X.500] "The Directory: Overview of Concepts, Models", ITU-T - Recommendation X.500, 1993. - - [X.520] "The Directory: Selected Attribute Types", ITU-T - Recommendation X.520, 1993. - - -Copyright 2002, The Internet Society. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - -Zeilenga draft-zeilenga-ldap-collective-07 [Page 9] - diff --git a/doc/drafts/draft-zeilenga-ldap-subentry-xx.txt b/doc/drafts/draft-zeilenga-ldap-subentry-xx.txt deleted file mode 100644 index e8eb3ca014..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-subentry-xx.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Date: 17 May 2002 Steven Legg -Expires in six months Adacel Technologies - - - Subentries in LDAP - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extension Working Group - mailing list . Please send editorial - comments directly to the author . - - 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 - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright 2002, The Internet Society. All Rights Reserved. - - Please see the Copyright section near the end of this document for - more information. - - -Abstract - - In X.500 directories, subentries are special entries used to hold - information associated with a subtree or subtree refinement. This - document adapts X.500 subentries mechanisms for use with Lightweight - Directory Access Protocol (LDAP). - - - - -Zeilenga draft-zeilenga-ldap-subentry-05 [Page 1] - -INTERNET-DRAFT Subentries in LDAP 17 May 2002 - - -Conventions - - Schema definitions are provided using LDAP description formats - [RFC2252]. Definitions provided here are formatted (line wrapped) for - readability. - - Protocol elements are described using ASN.1 [X.680]. The term - "BER-encoded" means the element is to be encoded using the Basic - Encoding Rules [X.690] under the restrictions detailed in Section 5.1 - of [RFC2251]. - - 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 BCP 14 [RFC2119]. - - -1. Overview - - From [X.501]: - A subentry is a special kind of entry immediately subordinate to - an administrative point. It contains attributes that pertain to a - subtree (or subtree refinement) associated with its administrative - point. The subentries and their administrative point are part of - the same naming context. - - A single subentry may serve all or several aspects of - administrative authority. Alternatively, a specific aspect of - administrative authority may be handled through one or more of its - own subentries. - - Subentries in Lightweight Directory Access Protocol (LDAP) [LDAPTS] - SHALL behave in accordance with X.501 unless noted otherwise in this - specification. - - In absence of the subentries control (detailed in Section 3), - subentries SHALL NOT be considered in one-level and subtree scope - search operations. For all other operations, including base scope - search operations, subentries SHALL be considered. - - -2. Subentry Schema - -2.1. Subtree Specification Syntax - - The Subtree Specification syntax provides a general purpose mechanism - for the specification of a subset of entries in a subtree of the - Directory Information Tree (DIT). A subtree begins at some base entry - and includes the subordinates of that entry down to some identified - - - -Zeilenga draft-zeilenga-ldap-subentry-05 [Page 2] - -INTERNET-DRAFT Subentries in LDAP 17 May 2002 - - - lower boundary, possibly extending to the leaf entries. A subtree - specification is always used within a context or scope which - implicitly determines the bounds of the subtree. For example, the - scope of a subtree specification for a subschema administrative area - does not include the subtrees of any subordinate administrative point - entries for subschema administration. Where a subtree specification - does not identify a contiguous subset of the entries within a single - subtree the collection is termed a subtree refinement. - - This syntax corresponds to the SubtreeSpecification ASN.1 type - described in [X.501], Section 11.3. This ASN.1 data type definition - is reproduced here for completeness. - - SubtreeSpecification ::= SEQUENCE { - base [0] LocalName DEFAULT { }, - COMPONENTS OF ChopSpecification, - specificationFilter [4] Refinement OPTIONAL } - - - LocalName ::= RDNSequence - - ChopSpecification ::= SEQUENCE { - specificExclusions [1] SET OF CHOICE { - chopBefore [0] LocalName, - chopAfter [1] LocalName } OPTIONAL, - minimum [2] BaseDistance DEFAULT 0, - maximum [3] BaseDistance OPTIONAL} - - BaseDistance ::= INTEGER (0 .. MAX) - - Refinement ::= CHOICE { - item [0] OBJECT-CLASS.&id, - and [1] SET OF Refinement, - or [2] SET OF Refinement, - not [3] Refinement } - - The components of SubtreeSpecification are: base, which identifies the - base entry of the subtree or subtree refinement, and - specificExclusions, minimum, maximum and specificationFilter, which - then reduce the set of subordinate entries of the base entry. The - subtree or subtree refinement contains all the entries within scope - that are not excluded by any of the components of the subtree - specification. When all of the components of SubtreeSpecification are - absent (i.e. when a value of the Subtree Specification syntax is the - empty sequence, {}), the subtree so specified implicitly includes all - the entries within scope. - - Any particular use of this mechanism MAY impose limitations or - - - -Zeilenga draft-zeilenga-ldap-subentry-05 [Page 3] - -INTERNET-DRAFT Subentries in LDAP 17 May 2002 - - - constraints on the components of SubtreeSpecification. - - The LDAP syntax specification is: - - ( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' ) - - The native LDAP encoding of values of this syntax is defined by the - Generic String Encoding Rules [GSER]. Appendix A provides an - equivalent ABNF for this syntax. - - -2.1.1. Base - - The base component of SubtreeSpecification nominates the base entry of - the subtree or subtree refinement. The base entry may be an entry - which is subordinate to the root entry of the scope in which the - subtree specification is used, in which case the base component - contains a sequence of RDNs relative to the root entry of the scope, - or may be the root entry of the scope itself (the default), in which - case the base component is absent or contains an empty sequence of - RDNs. - - Entries that are not subordinates of the base entry are excluded from - the subtree or subtree refinement. - - -2.1.2. Specific Exclusions - - The specificExclusions component of a ChopSpecification is a list of - exclusions that specify entries and their subordinates to be excluded - from the the subtree or subtree refinement. The entry is specified by - a sequence of RDNs relative to the base entry (i.e. a LocalName). - Each exclusion is of either the chopBefore or chopAfter form. If the - chopBefore form is used then the specified entry and its subordinates - are excluded from the subtree or subtree refinement. If the chopAfter - form is used then only the subordinates of the specified entry are - excluded from the subtree or subtree refinement. - - -2.1.3. Minimum and Maximum - - The minimum and maximum components of a ChopSpecification allow the - exclusion of entries based on their depth in the DIT. - - Entries that are less than the minimum number of RDN arcs below the - base entry are excluded from the subtree or subtree refinement. A - minimum value of zero (the default) corresponds to the base entry. - - - - -Zeilenga draft-zeilenga-ldap-subentry-05 [Page 4] - -INTERNET-DRAFT Subentries in LDAP 17 May 2002 - - - Entries that are more than the maximum number of RDN arcs below the - base entry are excluded from the subtree or subtree refinement. An - absent maximum component indicates that there is no upper limit on the - number of RDN arcs below the base entry for entries in the subtree or - subtree refinement. - -2.1.4. Specification Filter - - The specificationFilter component is a boolean expression of - assertions about the values of the objectClass attribute of the base - entry and its subordinates. A Refinement assertion item evaluates to - true for an entry if that entry's objectClass attribute contains the - OID nominated in the assertion. Entries for which the overall filter - evaluates to false are excluded from the subtree refinement. If the - specificationFilter is absent then no entries are excluded from the - subtree or subtree refinement because of their objectClass attribute - values. - - -2.2. Administrative Role Attribute Type - - The Administrative Model defined in [X.501], clause 10 requires that - administrative entries contain an administrativeRole attribute to - indicate that the associated administrative area is concerned with one - or more administrative roles. - - The administrativeRole operational attribute is specified as follows: - - ( 2.5.18.5 NAME 'administrativeRole' - EQUALITY objectIdentifierMatch - USAGE directoryOperation - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) - - The possible values of this attribute defined in X.501 are: - - OID NAME - -------- ------------------------------- - 2.5.23.1 autonomousArea - 2.5.23.2 accessControlSpecificArea - 2.5.23.3 accessControlInnerArea - 2.5.23.4 subschemaAdminSpecificArea - 2.5.23.5 collectiveAttributeSpecificArea - 2.5.23.6 collectiveAttributeInnerArea - - Other values may be defined in other specifications. Names associated - with each administrative role are Object Identifier Descriptors - [LDAPIANA]. - - - - -Zeilenga draft-zeilenga-ldap-subentry-05 [Page 5] - -INTERNET-DRAFT Subentries in LDAP 17 May 2002 - - - The administrativeRole operational attribute is also used to regulate - the subentries permitted to be subordinate to an administrative entry. - A subentry not of a class permitted by the administrativeRole - attribute cannot be subordinate to the administrative entry. - - -2.3. Subtree Specification Attribute Type - - The subtreeSpecification operational attribute is defined as follows: - - ( 2.5.18.6 NAME 'subtreeSpecification' - SINGLE-VALUE - USAGE directoryOperation - SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 ) - - This attribute is present in all subentries. See [X.501], clause 10. - Values of the subtreeSpecification attribute nominate collections of - entries within the DIT for one or more aspects of administrative - authority. - - -2.4. Subentry Object Class - - The subentry object class is a structural object class. - - ( 2.5.20.0 NAME 'subentry' - SUP top STRUCTURAL - MUST ( cn $ subtreeSpecification ) ) - - -3. Subentries Control - - The subentries control MAY be sent with a searchRequest to control the - visibility of entries and subentries which are within scope. - Non-visible entries or subentries are not returned in response to the - request. - - The subentries control is an LDAP Control whose controlType is - 1.3.6.1.4.1.4203.1.10.1, criticality is TRUE or FALSE (hence absent), - and controlValue contains a BER-encoded BOOLEAN indicating visibility. - A controlValue containing the value TRUE indicates that subentries are - visible and normal entries are not. A controlValue containing the - value FALSE indicates that normal entries are visible and subentries - are not. - - Note that TRUE visibility has the three octet encoding { 01 01 FF } - and FALSE visibility has the three octet encoding { 01 01 00 }. - - - - -Zeilenga draft-zeilenga-ldap-subentry-05 [Page 6] - -INTERNET-DRAFT Subentries in LDAP 17 May 2002 - - - The controlValue SHALL NOT be absent. - - In absence of this control, subentries are not visible to singleLevel - and wholeSubtree scope Search requests but are visible to baseObject - scope Search requests. - - There is no corresponding response control. - - This control is not appropriate for non-Search operations. - - -4. Security Considerations - - Subentries often hold administrative information or other sensitive - information and should be protected from unauthorized access and - disclosure as described in [RFC2829][RFC2830]. - - General LDAP [LDAPTS] security considerations also apply. - - -5. IANA Considerations - -5.1 Descriptors - - It is requested that IANA register the LDAP descriptors used in this - document per the following registration template: - - Subject: Request for LDAP Descriptor Registration - Descriptor (short name): see comment - Object Identifier: see comment - Person & email address to contact for further information: - Kurt Zeilenga - Usage: see comment - Specification: RFCXXXX - Author/Change Controller: IESG - Comments: - - NAME Type OID - ------------------------ ---- -------- - accessControlInnerArea R 2.5.23.3 - accessControlSpecificArea R 2.5.23.2 - administrativeRole A 2.5.18.5 - autonomousArea R 2.5.23.1 - collectiveAttributeInnerArea R 2.5.23.6 - collectiveAttributeSpecificArea R 2.5.23.5 - subentry O 2.5.20.0 - subschemaAdminSpecificArea R 2.5.23.4 - subtreeSpecification A 2.5.18.6 - - - -Zeilenga draft-zeilenga-ldap-subentry-05 [Page 7] - -INTERNET-DRAFT Subentries in LDAP 17 May 2002 - - - where Type A is Attribute, Type O is ObjectClass, and Type R is - Administrative Role. - - -5.2 Object Identifiers - - No IANA assignment of object identifiers is requested. - - This document uses the OID 1.3.6.1.4.1.4203.1.10.1 to identify an LDAP - protocol element defined herein. This OID was assigned [ASSIGN] by - OpenLDAP Foundation under its IANA assigned private enterprise - allocation [PRIVATE] for use in this specification. - - Other OIDs which appear in this document were either assigned by the - ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify - elements of X.500 schema or assigned in RFC 2252 for the use described - here. - - -6. Acknowledgment - - This document is based on engineering done by IETF LDUP and LDAPext - Working Groups including "LDAP Subentry Schema" by Ed Reed. This - document also borrows from a number of ITU documents including X.501. - - -7. Authors' Addresses - - Kurt D. Zeilenga - OpenLDAP Foundation - - Email: Kurt@OpenLDAP.org - - Steven Legg - Adacel Technologies Ltd. - 405-409 Ferntree Gully Road - Mount Waverley, Victoria 3149 - AUSTRALIA - - Phone: +61 3 9451 2107 - Fax: +61 3 9541 2121 - EMail: steven.legg@adacel.com.au - - -8. Normative References - - [X.501] ITU-T, "The Directory -- Models," X.501, 1993. - - - - -Zeilenga draft-zeilenga-ldap-subentry-05 [Page 8] - -INTERNET-DRAFT Subentries in LDAP 17 May 2002 - - - [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - - Specification of Basic Notation", X.680, 1994. - - [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, - Canonical, and Distinguished Encoding Rules", X.690, 1994. - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (was RFC 2119), March 1997. - - [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax - Definitions", RFC 2252, December 1997. - - [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, - "Authentication Methods for LDAP", RFC 2829, May 2000 - - [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory - Access Protocol (v3): Extension for Transport Layer - Security", RFC 2830, May 2000. - - [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", - draft-ietf-ldapbis-ldapv3-ts-xx.txt, a work in progress. - - [GSER] S. Legg, "Generic String Encoding Rules for ASN.1 Types", - draft-legg-ldapext-gser--xx.txt, a work in progress. - - [LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", draft-ietf- - ldapbis-iana-xx.txt, a work in progress. - - -9. Informative References - - [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [GCE] S. Legg, "Common Elements of GSER Encodings", - draft-legg-ldap-gser-abnf-xx.txt, a work in progress. - - [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", - http://www.openldap.org/foundation/oid-delegate.txt. - - [PRIVATE] IANA, "Private Enterprise Numbers", - http://www.iana.org/assignments/enterprise-numbers. - - - - -Zeilenga draft-zeilenga-ldap-subentry-05 [Page 9] - -INTERNET-DRAFT Subentries in LDAP 17 May 2002 - - -A. Subtree Specification ABNF - - This appendix is non-normative. - - The LDAP-specific native string encoding for the Subtree Specification - syntax is specified by the Generic String Encoding Rules [GSER]. The - ABNF [RFC2234] in this appendix for this syntax is provided only as a - convenience and is equivalent to the encoding specified by the - application of [GSER]. Since the SubtreeSpecification ASN.1 type may - be extended in future editions of [X.501], the provided ABNF should be - regarded as a snapshot in time. The native LDAP encoding for any - extension to the SubtreeSpecification ASN.1 type can be determined - from [GSER]. - - In the event that there is a discrepancy between this ABNF and the - encoding determined by [GSER], [GSER] is to be taken as definitive. - - SubtreeSpecification = "{" [ sp base ] - [ sep sp specificExclusions ] - [ sep sp minimum ] - [ sep sp maximum ] - [ sep sp specificationFilter ] - sp "}" - - base = id-base msp LocalName - specificExclusions = id-specificExclusions msp SpecificExclusions - minimum = id-minimum msp BaseDistance - maximum = id-maximum msp BaseDistance - specificationFilter = id-specificationFilter msp Refinement - - id-base = %x62.61.73.65 ; "base" - id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73 - %x69.6F.6E.73 ; "specificExclusions" - id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum" - id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum" - id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46 - %x69.6C.74.65.72 ; "specificationFilter" - - SpecificExclusions = "{" sp SpecificExclusion - *( "," sp SpecificExclusion ) sp "}" - SpecificExclusion = chopBefore / chopAfter - chopBefore = id-chopBefore ":" LocalName - chopAfter = id-chopAfter ":" LocalName - id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore" - id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter" - - Refinement = item / and / or / not - item = id-item ":" OBJECT-IDENTIFIER - - - -Zeilenga draft-zeilenga-ldap-subentry-05 [Page 10] - -INTERNET-DRAFT Subentries in LDAP 17 May 2002 - - - and = id-and ":" Refinements - or = id-or ":" Refinements - not = id-not ":" Refinement - Refinements = "{" [ sp Refinement - *( "," sp Refinement ) ] sp "}" - id-item = %x69.74.65.6D ; "item" - id-and = %x61.6E.64 ; "and" - id-or = %x6F.72 ; "or" - id-not = %x6E.6F.74 ; "not" - - BaseDistance = INTEGER - - The , , , , and - rules are defined in [GCE]. - - -Copyright 2002, The Internet Society. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - -Zeilenga draft-zeilenga-ldap-subentry-05 [Page 11] - -- 2.39.5