--- /dev/null
+
+Internet-Draft D. Boreham, Bozeman Pass
+LDAPext Working Group J. Sermersheim, Novell
+Intended Category: Standards Track A. Kashi, Microsoft
+<draft-ietf-ldapext-ldapv3-vlv-06.txt>
+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
+\f
+ 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
+\f
+ 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
+\f
+ 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
+\f
+ 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
+\f
+ 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
+\f
+ 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
+\f
+ 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
+\f
+ 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
+\f
+ 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
+\f
+ 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
--- /dev/null
+
+
+INTERNET-DRAFT Michael P. Armijo
+<draft-ietf-ldapext-locate-07.txt> Levon Esibov
+February 20, 2002 Paul Leach
+Expires: August 20, 2002 Microsoft Corporation
+ R.L. Morgan
+ University of Washington
+
+ Discovering LDAP Services with DNS
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet- Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this memo is unlimited. It is filed as <draft-
+ ietf-ldapext-locate-07.txt>, and expires on August 20, 2002.
+ Please send comments to the authors.
+
+ Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+
+Abstract
+
+ A Lightweight Directory Access Protocol (LDAP) request must be
+ directed to an appropriate server for processing. This document
+ specifies a method for discovering such servers using information in
+ the Domain Name System.
+
+
+
+
+
+
+
+
+
+Armijo, Esibov, Leach and Morgan [Page 1]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS February 20, 2002
+
+
+
+1. Introduction
+
+ The LDAPv3 protocol [1] is designed to be a lightweight access
+ protocol for directory services supporting X.500 models. As a
+ distributed directory service, the complete set of directory
+ information (known as the Directory Information Base) is spread
+ across many different servers. Hence there is the need to
+ determine, when initiating or processing a request, which servers
+ hold the relevant information. In LDAP, the Search, Modify, Add,
+ Delete, ModifyDN, and Compare operations all specify a Distinguished
+ Name (DN) [2] on which the operation is performed. A client, or a
+ server acting on behalf of a client, must be able to determine the
+ server(s) that hold the naming context containing that DN, since
+ that server (or one of that set of servers) must receive and process
+ the request. This determination process is called "server
+ location". To support dynamic distributed operation, the
+ information needed to support server location must be available via
+ lookups done at request processing time, rather than, for example,
+ as static data configured into each client or server.
+
+ It is possible to maintain the information needed to support server
+ location in the directory itself, and X.500 directory deployments
+ typically do so. In practice, however, this only permits location
+ of servers within a limited X.500-connected set. LDAP-specific
+ methods of maintaining server location information in the directory
+ have not yet been standardized. This document defines an
+ alternative method of managing server location information using the
+ Domain Name System. This method takes advantage of the global
+ deployment of the DNS, by allowing LDAP server location information
+ for any existing DNS domain to be published by creating the records
+ described below. A full discussion of the benefits and drawbacks of
+ the various directory location and naming methods is beyond the
+ scope of this document.
+
+ RFC 2247[3] defines an algorithm for mapping DNS domain names into
+ DNs. This document defines the inverse mapping, from DNs to DNS
+ domain names, based on the conventions in [3], for use in this
+ server location method. The server location method described in
+ this document is only defined for DNs that can be so mapped, i.e.,
+ those DNs that are based on domain names. In practice this is
+ reasonable because many objects of interest are named with domain
+ names, and use of domain-name-based DNs is becoming common.
+
+
+
+2. Mapping Distinguished Names into Domain Names
+
+ This section defines a method of converting a DN into a DNS domain
+ name for use in the server location method described below. Some
+ DNs cannot be converted into a domain name. Converted DNs result
+ in a fully qualified domain name.
+
+Armijo, Esibov, Leach and Morgan [Page 2]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS February 20, 2002
+
+
+
+ The output domain name is initially empty. The DN is processed in
+ right-to-left order (i.e., beginning with the first RDN in the
+ sequence of RDNs). An RDN is able to be converted if it (1)
+ consists of a single AttributeTypeAndValue; (2) the attribute type
+ is "DC"; and (3) the attribute value is non-null. If it can be
+ converted, the attribute value is used as a domain name component
+ (label). The first such value becomes the rightmost (i.e., most
+ significant) domain name component, and successive converted RDN
+ values extend to the left. If an RDN cannot be converted,
+ processing stops. If the output domain name is empty when
+ processing stops, the DN cannot be converted into a domain name.
+
+ For DN:
+
+ cn=John Doe,ou=accounting,dc=example,dc=net
+
+ The client would convert the DC components as defined above into
+ DNS name:
+
+ example.net
+
+ The determined DNS name will be submitted as a DNS query using the
+ algorithm defined in section 3.
+
+
+
+3. Locating LDAPv3 servers through DNS
+
+ LDAPv3 server location information is to be stored using DNS Service
+ Location Record (SRV)[5]. The data in a SRV record contains the DNS
+ name of the server that provides the LDAP service, corresponding
+ Port number, and parameters that enable the client to choose an
+ appropriate server from multiple servers according to the algorithm
+ described in [5]. The name of this record has the following format:
+
+ _<Service>._<Proto>.<Domain>.
+
+ where <Service> is "ldap", and <Proto> is "tcp". <Domain> is the
+ domain name formed by converting the DN of a naming context mastered
+ by the LDAP Server into a domain name using the algorithm in
+ Section 2. Note that "ldap" is the symbolic name for the LDAP
+ service in Assigned Numbers[6], as required by [5].
+
+
+
+
+
+
+
+
+
+
+Armijo, Esibov, Leach and Morgan [Page 3]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS February 20, 2002
+
+
+ Presence of such records enables clients to find the LDAP servers
+ using standard DNS query [4]. A client (or server) seeking an LDAP
+ server for a particular DN converts that DN to a domain name using
+ the algorithm of Section 2, does a SRV record query using the DNS
+ name formed as described in the preceding paragraph, and interprets
+ the response as described in [5] to determine a host (or hosts) to
+ contact. As an example, a client that searches for an LDAP server
+ for the DN "ou=foo,dc=example,dc=net" that supports the TCP protocol
+ will submit a DNS query for a set of SRV records with owner name:
+
+ _ldap._tcp.example.net.
+
+ The client will receive the list of SRV records published in DNS
+ that satisfy the requested criteria. The following is an example of
+ such a record:
+
+ _ldap._tcp.example.net. IN SRV 0 0 389 phoenix.example.net.
+
+ The set of returned records may contain multiple records in the case
+ where multiple LDAP servers serve the same domain. If there are no
+ matching SRV records available for the converted DN the client SHOULD
+ NOT attempt to 'walk the tree' by removing the least significant
+ portion of the constructed fully qualified domain name.
+
+
+4. IANA Considerations
+
+ This document does not require any IANA actions.
+
+
+5. Security Considerations
+
+ DNS responses can typically be easily spoofed. Clients using this
+ location method SHOULD ensure, via use of strong security
+ mechanisms, that the LDAP server they contact is the one they
+ intended to contact. See [7] for more information on security
+ threats and security mechanisms.
+
+ When using LDAP with TLS the client must check the server's name,
+ as described in section 3.6 of [RFC 2830]. As specified there, the
+ name the client checks for is the server's name before any
+ potentially insecure transformations, including the SRV record
+ lookup specified in this memo. Thus the name the client must check
+ for is the name obtained by doing the mapping step defined in
+ section 2 above. For example, if the DN "cn=John
+ Doe,ou=accounting,dc=example,dc=net" is converted to the DNS name
+ "example.net", the server's name must match "example.net".
+
+ This document describes a method that uses DNS SRV records to
+ discover LDAP servers. All security considerations related to DNS
+ SRV records are inherited by this document. See the security
+ considerations section in [5] for more details.
+
+Armijo, Esibov, Leach and Morgan [Page 4]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS February 20, 2002
+
+
+6. References
+
+ [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol(v3)", RFC 2251, December 1997.
+
+ [2] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", RFC 2253, December 1997.
+
+ [3] Kille, S. and M. Wahl, "Using Domains in LDAP/X.500
+ Distinguished Names", RFC 2247, January 1998.
+
+ [4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
+ 1034, STD 13, November 1987.
+
+ [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1700, October 1994.
+
+ [7] Wahl, M., Alvestrand, H., Hodges, J. and Morgan, R.,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [8] Hodges, J., Morgan, R., Wahl, M., "Lightweight Directory Access
+ Protocol (v3): Extension for Transport Layer Security", RFC 2830,
+ May 2000.
+
+
+
+
+
+
+7. Authors' Addresses
+
+ Michael P. Armijo
+ One Microsoft Way
+ Redmond, WA 98052
+ micharm@microsoft.com
+
+ Paul Leach
+ One Microsoft Way
+ Redmond, WA 98052
+ paulle@microsoft.com
+
+ Levon Esibov
+ One Microsoft Way
+ Redmond, WA 98052
+ levone@microsoft.com
+
+
+
+Armijo, Esibov, Leach and Morgan [Page 5]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS February 20, 2002
+
+ RL "Bob" Morgan
+ University of Washington
+ 4545 15th Ave NE
+ Seattle, WA 98105
+ US
+
+ Phone: +1 206 221 3307
+ EMail: rlmorgan@washington.edu
+ URI: http://staff.washington.edu/rlmorgan/
+
+
+8. Intellectual Property Statement
+
+The IETF takes no position regarding the validity or scope of any
+intellectual property or other rights that might be claimed to pertain
+to the implementation or use of the technology described in this
+document or the extent to which any license under such rights might or
+might not be available; neither does it represent that it has made any
+effort to identify any such rights. Information on the IETF's
+procedures with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11. Copies of claims of
+rights made available for publication and any assurances of licenses to
+be made available, or the result of an attempt made to obtain a general
+license or permission for the use of such proprietary rights by
+implementors or users of this specification can be obtained from the
+IETF Secretariat.
+
+The IETF invites any interested party to bring to its attention any
+copyrights, patents or patent applications, or other proprietary rights
+which may cover technology that may be required to practice this
+standard. Please address the information to the IETF Executive
+Director.
+
+
+9. Full Copyright Statement
+
+Copyright (C) The Internet Society (2001). 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
+
+
+Armijo, Esibov, Leach and Morgan [Page 6]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS February 20, 2002
+
+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."
+
+
+10. Expiration Date
+
+ This documentis filed as <draft-ietf-ldapext-locate-06.txt>, and
+ expires August 20, 2002.
+
+Armijo, Esibov, Leach and Morgan [Page 7]
\ No newline at end of file
--- /dev/null
+
+
+Internet Draft R. Megginson, Editor
+Document: <draft-ietf-ldup-lcup-02.txt> M. Smith
+Category: Proposed Standard Netscape
+ Communications Corp.
+ O. Natkovich
+ Yahoo
+ J. Parham
+ Microsoft Corporation
+ November 2001
+
+
+ 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
+
+\f
+
+
+ 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
+ replication protocol that is being defined by the LDUP IETF
+ working group should be used for this purpose.
+
+ Several features of the protocol distinguish it from LDUP
+ replication. First, the server does not maintain any state
+ information on behalf of its clients. The clients are responsible
+ for storing the information about how up to date they are with
+ respect to the server's content. Second, no predefined agreements
+ exist between the clients and the servers. The client decides when
+ and from where to retrieve the changes. Finally, the server never
+ pushes the data to the client; the client always initiates the
+ update session during which it pulls the changes from the server.
+
+ The set of clients that are allowed to synchronize with an LDAP
+ server is determined by the server defined policy.
+
+ 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.
+
+
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 2
+\f
+
+
+ A server can define a naming context or some part thereof to
+ participate in LCUP. This document will refer to this as an LCUP
+ Context. For example, LDUP defines a replica, a part of the DIT
+ which may participate in replication. The LCUP context may be
+ coincident with the replicated area, depending on the server's
+ implementation. It is assumed that most server implementations of
+ LCUP will make use of the server's underlying replication mechanism,
+ but this does not have to be LDUP compliant.
+
+4. Protocol Specification
+
+ This section describes the protocol elements and the protocol flow.
+
+4.1 Unique Identifiers
+
+ Distinguished names can change, so are therefore unreliable
+ as identifiers. The server SHOULD assign a Unique Identifier 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. If the client wants to use entryUUID, it
+ should supply entryUUID in the list of attributes to return in the
+ LCUP search (described below).
+ A consistent algorithm for generating such 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 `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.
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 3
+\f
+
+
+
+
+ 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.
+
+ Further uses of the LCUP Cookie value are described below.
+
+4.3 LCUP Cookie Schemes Operational Attribute
+
+ The OIDs of the supported LCUP cookie schemes SHOULD be published
+ using the following operational attribute:
+
+ ( OID-TBD
+ NAME 'lcupCookieScheme'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The lcupCookieScheme operational attribute MUST be present in the
+ root DSE. The lcupCookieScheme operational attribute MAY be present
+ in every directory entry that may be used as the baseObject for a
+ search request that contains an LCUP clientUpdate control. If a
+ client wants to determine what LCUP cookie schemes are supported, it
+ MAY use a base object search to read the lcupCookieScheme attribute
+ from the entry that will be used as the baseObject in subsequent
+ LCUP sessions, then query the root DSE if the lcupCookieScheme was
+ not found in the base entry. Clients SHOULD NOT search for entries
+ that contain lcupCookieScheme values; rather, it is RECOMMENDED that
+ servers support LCUP sessions based at as many different entries as
+ possible.
+ Each value of the attribute will be a list of OIDs of the cookie
+ schemes followed by the DN of the LCUP context which supports the
+ schemes. The delimiter will be a single space character. For
+ example:
+ lcupCookieScheme: 1.2.3.4 5.6.7.8 dc=mycorp, dc=com
+ Everything after the last space after the last OID will be the LCUP
+ Context DN. If the attribute is present in a regular directory
+ entry in an LCUP Context, the values corresponding to DNs other than
+ the LCUP Context containing the entry MAY be omitted.
+
+4.4 Client Update Control Value
+
+ A client initiates a synchronization session with a server by
+ attaching a clientUpdate control to a search operation. 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
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 4
+\f
+
+
+ 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:
+
+ ClientUpdateControlValue ::= SEQUENCE {
+ updateType ENUMERATED {
+ synchronizeOnly (0),
+ synchronizeAndPersist (1),
+ persistOnly (2) },
+ 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 which 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 which satisfy the search
+ criteria.
+
+ 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 clientUpdateDone control
+ attached with the reason set to the value of lcupInvalidCookie
+ (see below). Also, the LDAP result code MUST be
+ unwillingToPerform. 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 clientUpdateDone control
+ attached with the reason set to the value of
+ lcupUnsupportedScheme (see below). Also, the LDAP result code
+ MUST be unwillingToPerform.
+
+ 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 which describes the LCUP state of the returned
+ entry. To represent a deleted entry, the server attaches an
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 5
+\f
+
+
+ entryUpdate control to the corresponding SearchResultEntry. The
+ SearchResultEntry corresponding to a deleted entry MUST contain a
+ valid DN and MAY contain a valid Unique Identifier but, to reduce
+ the amount of data sent to the client, it SHOULD not contain any
+ other attributes. Distinguished names can change, so are therefore
+ unreliable as identifiers. A Unique Identifier MAY therefore be
+ assigned to each entry as it is created. The Unique Identifier
+ allows the client to uniquely identify entries even in the presence
+ of modifyDN operations. The Unique Identifier is carried in the
+ entryUUID attribute.
+ 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. If the Unique Identifier is not returned, the client MAY
+ use the entry DN to keep track of returned entries.
+
+ 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 cookie SHOULD be present in every entryUpdate
+ control sent to the client to insure ease of synchronization. The
+ cookie is also provided in the entryUpdate control. 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, i.e. the entry should contain a valid
+ dn. 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 which 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
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 6
+\f
+
+
+
+ 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 which is not success, 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 {
+ reason INTEGER,
+ reasonText LDAPString,
+ cookie LCUPCookie OPTIONAL
+ }
+
+ reason - reason for terminating the operation. The following values
+ are defined:
+
+ lcupSuccess (0) the operation was successfully
+ processed
+ lcupResourcesExhausted (1) the server is running out of resource
+ lcupSecurityViolation (2) the client is suspected of malicious
+ actions
+ lcupInvalidCookie (3) invalid cookie was supplied by the
+ client - both/either the scheme
+ and/or the value part was invalid
+ lcupUnsupportedScheme (4) The scheme part of the cookie is a
+ valid OID but is not supported by
+ this server
+ lcupClientDisconnect (5) client requested search termination
+ using the stopClientUpdate request
+ (defined below)
+ lcupReloadRequired (6) 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 that the
+ server's data was reloaded since the
+ last synchronization session
+
+ reasonText - The reasonText field of this construct may, at the
+ server's option, be used to return a string containing a textual,
+ human-readable (terminal control and page formatting characters
+ should be avoided) error diagnostic. As this error diagnostic is
+ not standardized, implementations MUST NOT rely on the values
+ returned. If the server chooses not to return a textual
+ diagnostic, the reasonText field of the
+ ClientUpdateDoneControlValue MUST contain a zero length string.
+ The reasonText should be limited to characters in the range 0x00 to
+ 0x7F.
+
+ cookie - the LCUP cookie value that represents the current state of
+ the client's data. Although this value is OPTIONAL, it MUST be set
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 7
+\f
+
+
+ in the ClientUpdateDoneControlValue if the reason is lcupSuccess or
+ lcupClientDisconnect and the LDAP search result code is success.
+ 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). 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 and the value of the reason field is set to
+ lcupResourcesExhausted. 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 in the reason field of the
+ response.
+
+4.7 Stop Client Update Request and Response
+
+ The Stop Client Update operation is an LDAPv3 Extended Operation
+ [RFC2251, Section 4.12] and is identified by the OBJECT IDENTIFIER
+ stopClientUpdateRequestOID (to be assigned). This section details
+ the syntax of the protocol.
+
+ An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL
+ }
+
+ 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 a stopClientUpdateRequest extended operation. The
+ operation carries the following data. The extended operation
+ requestValue is an OCTET STRING, whose contents are the bytes of the
+ BER encoding of the following:
+
+ StopClientUpdateRequestValue ::= MessageID
+
+ StopClientUpdateRequestValue - the message ID of the search that
+ included the original clientUpdate control
+
+ The server responds immediately with a stopClientUpdateResponse
+ extended operation that carries no data, and an OBJECT IDENTIFIER of
+ stopClientUpdateResponseOID (to be assigned). 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. The value of the reason
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 8
+\f
+
+
+ in the clientUpdateDone control value MUST be either an error code
+ (some value other than lcupSuccess) or lcupClientDisconnect. The
+ stopClientUpdateResponse is sent only to satisfy LDAP requirement
+ that every server must issue an extended response for each extended
+ request it receives.
+
+ If the client is not interested in the state information, it can
+ simply abandon the search operation or disconnect from the server.
+
+ The requestName portion of the stopClientUpdate must be the
+ OID stopClientUpdateOID (to be assigned). The requestValue is the
+ message ID corresponding to the client's search request. If the
+ message ID is not valid, the server MUST send back to the client an
+ LDAP error code of unwillingToPerform.
+
+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:
+
+ 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 clientUpdateDone control
+ attached. The control contains the reason field set to
+ lcupResourcesExhausted or lcupSecurityViolation depending on
+ the reason for termination. The server MAY provide more
+ details to the client via the reasonText field of the control.
+ *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 the stopClientUpdate extended operation.
+ *S->C If the server receives the stopClientUpdate extended op, it
+ will immediately send back the stopClientUpdate extended op
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 9
+\f
+
+
+ response
+ *S->C If the client sent the stopClientUpdate extended op, the
+ server MAY send any pending SearchResultEntry PDUs in its
+ outgoing queue
+ *S->C If the client sent the stopClientUpdate extended op, after the
+ server sends the response and any pending SearchResultEntry
+ PDUs, the server sends the SearchResultDone message with the
+ clientUpdateDone control attached. The value of the reason
+ field of the clientUpdateDone control value will be either
+ lcupClientDisconnect or some lcup error code (not
+ lcupSuccess).
+ 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
+ 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 and the
+ reason flag set to lcupSuccess.
+ *S->C If an invalid cookie is specified, the server sends the
+ SearchResultDone message with clientUpdateDone control
+ attached. The reason field of the control is set to
+ lcupInvalidCookie and the reasonText field MAY contain
+ explanation of the error.
+ *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
+ clientUpdateDone control attached. The reason field of the
+ control is set to lcupReloadRequired and the reasonText field
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 10
+\f
+
+
+ MAY contain explanation of the error.
+ *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, 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 reason field of the control is set to lcupSuccess.
+ The client stores the cookie received from the server until
+ the next synchronization session.
+ *C->S If the reason field of the control 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:
+
+ 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 clientUpdateDone control
+ attached. The control contains the reason field set to
+ lcupResourcesExhausted or lcupSecurityViolation depending on
+ the reason for termination. The server MAY provide more
+ details to the client via the reasonText field of the control.
+ *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 a stopClientUpdateRequest extended operation to the
+ server to terminate the synchronization session.
+ S->C Responds with a stopClientUpdateResponse extended operation
+ followed by a SearchResultDone with the clientUpdateDone
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 11
+\f
+
+
+ control optionally attached. If present, the control contains
+ the cookie that represents the current state of the client's
+ data. The value of the reason field of the clientUpdateDone
+ control value will be either lcupClientDisconnect or some lcup
+ error code (not lcupSuccess). 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
+
+ The server sends to the client modified entries rather than
+ operations. Given this model, the server communicates a modifyDN
+ operation in one of two ways: by sending the client the current form
+ of the entry (with its new DN) along with an entryUUID attribute, or
+ by sending the client a deletion for the previous DN and an entry
+ for the new DN. The latter method must be used if the server does
+ not support the entryUUID attribute. In either case, 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
+
+
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 12
+\f
+
+
+ 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,
+ - 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 unique identifier 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
+
+
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 13
+\f
+
+
+ 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.
+
+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 LCUP protocol
+ will be implemented by regular LDAP clients that can deal with the
+ limitations of the LDAP protocol.
+
+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
+
+ There are several issues that the implementors of a synchronization
+ client need to consider:
+
+ - 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.
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 14
+\f
+
+
+
+ - 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 Unique Identifier 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 Unique Identifier rather then 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 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).
+
+ - 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,
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 15
+\f
+
+
+ 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.
+
+7. Server Implementation Considerations
+
+ 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.
+
+ 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
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 16
+\f
+
+
+ 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
+
+ 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
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 17
+\f
+
+
+
+ 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. 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.
+
+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.
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 18
+\f
+
+
+ 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
+ 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
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 19
+\f
+
+
+
+ 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: May 2002 20
+\f
+
+
+
+ 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: May 2002 21
+\f
+
+
+ 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: May 2002 22
+\f
\ No newline at end of file
--- /dev/null
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
\ No newline at end of file
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Informational OpenLDAP Foundation
+Expires in six months 17 May 2002
+
+
+ LDAPv3: Requesting Attributes by Object Class
+ <draft-zeilenga-ldap-adlist-01.txt>
+
+
+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 an Informational document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions Working Group
+ mailing list <ietf-ldapext@netscape.com>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ Copyright 2002, The Internet Society. All Rights Reserved.
+
+ Please see the Copyright section near the end of this document for
+ more information.
+
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) search operation
+ provides mechanisms for clients to request all user application
+ attributes, all operational attributes, or attributes selected by
+ their description. This document extends LDAP to provide a mechanism
+ for LDAP clients to request the return of all attributes of an object
+ class.
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
+
+
+1. Overview
+
+ LDAP [RFC2251] search operations support mechanisms for requesting
+ sets of attributes. This set is determined by a list of attribute
+ descriptions. Two special descriptors are defined to request all user
+ attributes ("*") and all operational attributes ("+"). However, there
+ is no convenient mechanism for requesting pre-defined sets of
+ attributes. This document extends LDAP to allow an object class
+ identifier to be specified in search request attributes list to
+ request the return all attributes allowed by object class.
+
+ 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].
+
+
+2. Return of all Attributes of an Object Class
+
+ This extension allows object class identifiers is to be provided in
+ the attributes field of the LDAP SearchRequest [RFC2251]. For each
+ object class identified in the attributes field, the request is to be
+ treated as if each attribute allowed by that class (by "MUST" or
+ "MAY", directly or by SUPerior) was itself listed. For example, a
+ request for "country" [RFC2256] is treated as if "c", "searchGuide",
+ "description", and "objectClass" were requested.
+
+ As a special case, requesting extensibleObject [RFC2252] is treated as
+ if "objectClass,*,+" was requested [RFC2251][OPATTRS].
+
+ If the object class identifier is unrecognized, it is be treated an an
+ unrecognized attribute description.
+
+ This extension redefines the attributes field of the SearchRequest to
+ be a DescriptionList described by the following [ASN.1]:
+
+ DescriptionList ::= SEQUENCE OF Description
+ Description ::= LDAPString
+
+ The Description is string conforming to the [ABNF]:
+
+ Description ::= AttributeDescription | ObjectClassDescription.
+ ObjectDescription ::= ObjectClass *( ";" options )
+
+ where AttributeDescription and options productions are as defined in
+ Section 4.1.5 of [RFC2251] and an ObjectClass is an objectIdentifier,
+ in either numericoid or descr form [RFC 2252], of an object class.
+
+ ObjectDescription options are provided for extensibility. This
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
+
+
+ document only defines semantics of ObjectDescriptions with zero
+ options in the attributes field of a SearchRequest. Other uses may be
+ defined in future specifications.
+
+ Servers supporting this feature SHOULD publish the Object Identifier
+ 1.3.6.1.4.1.4203.1.5.2 as a value of the supportedFeatures [FEATURES]
+ attribute in the root DSE.
+
+
+3. Security Considerations
+
+ This extension provides a shorthand for requesting all attributes of
+ an object class. As these attributes which could have been listed
+ individually, this short hand is not believed to raises additional
+ security considerations.
+
+ Implementors of this (or any) LDAP extension should be familiar with
+ general LDAP general security considerations [LDAPTS].
+
+
+4. IANA Considerations
+
+ No IANA assignments are requested.
+
+ This document uses the OID 1.3.6.1.4.1.4203.1.5.2 to identify the LDAP
+ feature it details. This OID was assigned [ASSIGN] by OpenLDAP
+ Foundation under its IANA assigned private enterprise allocation
+ [PRIVATE] for use in this specification.
+
+
+5. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+6. 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.
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
+
+
+ [LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification",
+ draft-ietf-ldapbis-ldapv3-ts-xx.txt (a work in progress).
+
+ [FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
+ draft-zeilenga-ldap-features-xx.txt (a work in progress).
+
+ [OPATTRS] K. Zeilenga, "LDAPv3: All Operational Attributes",
+ draft-zeilenga-ldap-opattrs-xx.txt (a work in progress).
+
+
+7. Informative References
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+ [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
+ Definition", 1993.
+
+ [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.
+
+
+
+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.
+
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
+
+
+ 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 Requesting Attributes by Object Class [Page 5]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 17 May 2002
+
+
+
+ LDAP "Who am I?" Operation
+ <draft-zeilenga-ldap-authzid-06.txt>
+
+
+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 <ietf-ldapext@netscape.com>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ 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 provides a mechanism for Lightweight Directory
+ Access Protocol (LDAP) clients to obtain the authorization identity
+ which the server has associated with the user or application entity.
+ This mechanism is specified as an LDAP extended operation called the
+ LDAP "Who am I?" operation.
+
+
+
+Zeilenga LDAP "Who am I?" [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 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].
+
+
+1. Background and Intent of Use
+
+ This specification describes a Lightweight Directory Access Protocol
+ (LDAP) [RFC2251] extended operation which clients can use to obtain
+ the primary authorization identity in its primary form which the
+ server has associated with the user or application entity.
+
+ Servers often associate multiple authorization identities with the
+ client and each authorization identity may be represented by multiple
+ authzId [RFC2829] strings. This operation requests and returns the
+ authzId the server considers to be primary. In the specification, the
+ term "the authorization identity" and "the authzid" are to generally
+ read as "the primary authorization identity" and the "the primary
+ authzid", respectively.
+
+ This specification is intended to replace the existing [AUTHCTL]
+ mechanism which uses Bind request and response controls to request and
+ return the authorization identity. Bind controls are not protected by
+ the security layers established by the Bind operation which they are
+ transferred as part of. While it is possible to establish security
+ layers prior to the Bind operation, it is often desirable to only use
+ security layers established by the Bind operation. An extended
+ operation sent after a Bind operation is protected by the security
+ layers established by the Bind operation.
+
+ There are other cases where it is desirable to request the
+ authorization identity which the server associated with the client
+ separately from the Bind operation. For example, the "Who am I?"
+ operation can be augmented with a Proxied Authorization Control
+ [PROXYCTL] to determine the authorization identity which the server
+ associates with the identity asserted in the Proxied Authorization
+ Control. The "Who am I?" operation can also be used prior to the Bind
+ operation.
+
+ The LDAP "Who am I?" operation is named after the UNIX whoami(1)
+ command. The whoami(1) command displays the effective user id.
+
+
+2. The "Who am I?" Operation
+
+ The "Who am I?" operation is defined as an LDAP Extended Operation
+
+
+
+Zeilenga LDAP "Who am I?" [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
+
+
+ [RFC2251, Section 4.12] identified by the whoamiOID Object Identifier
+ (OID). This section details the syntax of the operation's whoami
+ request and response messages.
+
+ whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
+
+
+2.1. The whoami Request
+
+ The whoami request is an ExtendedRequest with the requestName field
+ containing the whoamiOID OID and an absent requestValue field. For
+ example, a whoami request could be encoded as the sequence of octets
+ (in hex):
+
+
+2.2. The whoami Response
+
+ The whoami response is an ExtendedResponse where the responseName
+ field is absent and, if present, the response field is empty or an
+ authzId [RFC2829]. For example, a whoami response returning the
+ authzid "u:kurt@OPENLDAP.ORG" (in response to the example request)
+ would be encoded as the sequence of octets (in hex):
+
+
+
+3. Operational Semantics
+
+ The function of the "Who am I?" operation is to request that the
+ server returns the authorization identity it currently associates with
+ the client. The client requests this authorization identity by
+ issuing a whoami Request. The server responds to this request with a
+ whoami Response.
+
+ If the server is willing and able to provide the authorization
+ identity it associates with the client, the server SHALL return a
+ whoami Response with a success resultCode. If the server is treating
+ the client as an anonymous entity, the response field is empty.
+ Otherwise the server is to provide the authzId [RFC2829] representing
+ the authorization identity it currently associates with the client in
+ the response field.
+
+ If the server is unwilling or unable to provide the authorization
+ identity it associates with the client, the server SHALL return a
+ whoami Response with an appropriate non-success resultCode (such as
+ operationsError, protocolError, confidentialityRequired,
+ insufficientAccessRights, busy, unavailable, unwillingToPerform, or
+ other) and an absent response field.
+
+
+
+
+Zeilenga LDAP "Who am I?" [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
+
+
+ As described in [RFC2251] and [RFC2829], an LDAP session has an
+ "anonymous" association until the client has been successfully
+ authenticated using the Bind operation. Clients MUST NOT invoke the
+ "Who Am I?" operation while any Bind operation is in progress,
+ including between two Bind requests made as part of a multi-stage Bind
+ operation.
+
+
+4. Extending the "Who am I?" operation with controls
+
+ Future specifications may extend the "Who am I?" operation using the
+ control mechanism. When extended by controls, the "Who am I?"
+ operation requests and returns the authorization identity the server
+ associates with the client in a particular context indicated by the
+ controls.
+
+
+4.1. Proxied Authorization Control
+
+ The Proxied Authorization Control [PROXYCTL] is used by clients to
+ request that the operation it is attached to operates under the
+ authorization of an assumed identity. The client provides the
+ identity to assume in the Proxied Authorization request control. If
+ the client is authorized to assume the requested identity, the server
+ executes the operation as if the requested identity had issued the
+ operation.
+
+ As servers often map the asserted authzId to another identity
+ [RFC2829], it is desirable to request the server provide the authzId
+ it associates with the assumed identity.
+
+ When a Proxied Authorization Control is be attached to the "Who Am I?"
+ operation, the operation requests the return of the authzid the server
+ associates with the identity asserted in the Proxied Authorization
+ Control. The TBD result code is used to indicate that the server does
+ not allow the client to assume the asserted identity. [[Note to RFC
+ Editor: TBD is to be replaced with the name/code assigned by IANA for
+ [PROXYCTL] use.]]
+
+
+5. Security Considerations
+
+ Identities associated with users may be sensitive information. When
+ so, security layers [RFC2829][RFC2830] should be established to
+ protect this information. This mechanism is specifically designed to
+ allow security layers established by a Bind operation to protect the
+ integrity and/or confidentiality of the authorization identity.
+
+
+
+
+Zeilenga LDAP "Who am I?" [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
+
+
+ Servers may place access control or other restrictions upon the use of
+ this operation.
+
+ As with any other extended operations, general LDAP considerations
+ apply. These are detailed in [RFC2251], [RFC2829], and [RFC2830].
+
+
+6. IANA Considerations
+
+ No IANA assignments are requested.
+
+ This document uses the OID 1.3.6.1.4.1.4203.1.11.3 to identify the
+ LDAP "Who Am I? extended operation. This OID was assigned [ASSIGN] by
+ OpenLDAP Foundation under its IANA assigned private enterprise
+ allocation [PRIVATE] for use in this specification.
+
+
+7. Acknowledgment
+
+ This document borrows from prior work in this area including
+ "Authentication Response Control" [AUTHCTL] by Rob Weltman, Mark Smith
+ and Mark Wahl.
+
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+9. 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.
+
+ [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
+ "Authentication Methods for LDAP", RFC 2829, June 2000.
+
+ [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer
+ Security", RFC 2830, May 2000.
+
+ [PROXYCTL] R. Weltman, "LDAP Proxied Authentication Control", draft-
+ weltman-ldapv3-proxy-xx.txt (a work in progress).
+
+
+
+Zeilenga LDAP "Who am I?" [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
+
+
+10. Informative References
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [AUTHCTL] R. Weltman, M. Smith, M. Wahl, "LDAP Authentication
+ Response Control", draft-weltman-ldapv3-auth-response-
+ xx.txt (a work in progress).
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+
+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 LDAP "Who am I?" [Page 6]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 17 May 2002
+
+
+ LDAP Cancel Extended Operation
+ <draft-zeilenga-ldap-cancel-05.txt>
+
+
+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 <ietf-ldapext@netscape.com>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 <kurt@OpenLDAP.org>
+ 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 <kurt@OpenLDAP.org>
+ 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]
+\f
+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
+ <Kurt@OpenLDAP.org>
+
+
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 17 May 2002
+
+
+ Collective Attributes in LDAP
+ <draft-zeilenga-ldap-collective-07.txt>
+
+
+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 <ietf-ldapext@netscape.com>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 <kurt@OpenLDAP.org>
+ 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]
+\f
+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
+ <Kurt@OpenLDAP.org>
+
+
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 17 May 2002
+
+
+ Feature Discovery in LDAP
+ <draft-zeilenga-ldap-features-03.txt>
+
+
+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 an 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 <ietf-ldapext@netscape.com>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ Copyright 2002, The Internet Society. All Rights Reserved.
+
+ Please see the Copyright section near the end of this document for
+ more information.
+
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) is an extensible
+ protocol with numerous elective features. This document introduces a
+ general mechanism for discovery of elective features and extensions
+ which cannot be discovered using existing mechanisms.
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-features-03 [Page 1]
+\f
+INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
+
+
+1. Background and Intended Use
+
+ LDAP [RFC2251] is an extensible protocol with numerous elective
+ features. LDAP provides mechanisms for a client to discover supported
+ protocol versions, controls, extended operations, SASL mechanisms, and
+ subschema information. However, these mechanisms are not designed to
+ support general feature discovery.
+
+ This document describes a simple, general-purpose mechanism which
+ clients may use to discover the set of features supported by a server.
+
+ 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].
+
+
+2. Discovery of supported features
+
+ Each feature whose support may be discovered SHALL be identified by an
+ Object Identifier (OID). A server advertises its support for a given
+ feature by providing the OID associated with the feature as a value of
+ the supportedFeatures attribute held in the root DSE. A client may
+ examine the values of this attribute to determine if a particular
+ feature is supported by the server.
+
+ The supportedFeatures attribute type is described as follows:
+
+ ( 1.3.6.1.4.1.4203.1.3.5
+ NAME 'supportedFeatures'
+ DESC 'features supported by the server'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ Servers MUST be capable of recognizing this attribute type by the name
+ 'supportedFeatures'. Servers MAY recognize the attribute type by
+ other names.
+
+
+3. Security Considerations
+
+ As rogue clients can discover features of a server by other means
+ (such as by trial and error), this feature discovery mechanism is not
+ believed to introduce any new security risk to LDAP.
+
+
+
+Zeilenga draft-zeilenga-ldap-features-03 [Page 2]
+\f
+INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
+
+
+4. IANA Considerations
+
+ It is requested that IANA register the LDAP 'supportedFeatures'
+ descriptor used in this document per the following registration
+ template:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): supportedFeatures
+ Object Identifier: 1.3.6.1.4.1.4203.1.3.5
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Attribute Type
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+
+
+ This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA
+ assigned private enterprise allocation [PRIVATE] for use in this
+ specification.
+
+
+5. Acknowledgment
+
+ This document is based upon input from the IETF LDAPext working group.
+
+
+6. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+7. 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.
+
+
+8. Informative References
+
+
+
+
+Zeilenga draft-zeilenga-ldap-features-03 [Page 3]
+\f
+INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
+
+
+Full Copyright
+
+ 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-features-03 [Page 4]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires: 20 May 2002 20 November 2001
+
+
+
+ Named Subordinate References in LDAP Directories
+ <draft-zeilenga-ldap-namedref-05.txt>
+
+
+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 <ietf-ldapext@netscape.com>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ Copyright 2001, The Internet Society. All Rights Reserved.
+
+ Please see the Copyright section near the end of this document for
+ more information.
+
+
+Abstract
+
+ This document details schema and protocol elements for representing
+ and managing named subordinate references in LDAP directories.
+
+
+Conventions
+
+
+
+Zeilenga LDAP NamedRef [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
+ Schema definitions are provided using LDAPv3 description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped) for
+ readability.
+
+ The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD",
+ "SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be
+ interpreted as described in BCP 14 [RFC2119].
+
+
+1. Background and Intended Usage
+
+ The broadening of interest in LDAP (Lightweight Directory Access
+ Protocol) [RFC2251] directories beyond their use as front ends to
+ X.500 [X.500] directories has created a need to represent knowledge
+ information in a more general way. Knowledge information is
+ information about one or more servers maintained in another server,
+ used to link servers and services together.
+
+ This document details schema and protocol elements for representing
+ and manipulating named subordinate references in LDAP directories. A
+ referral object is used to hold subordinate reference information in
+ the directory. These referral objects hold one or more URIs [RFC2396]
+ contained in values of the ref attribute type and are used to generate
+ protocol referrals and continuations.
+
+ A control, ManageDsaIT, is defined to allow manipulation of referral
+ and other special objects as normal objects. As the name of control
+ implies, it is intended to be analogous to the ManageDsaIT service
+ option described in X.511(97) [X.511].
+
+ Other forms of knowledge information are not detailed by this
+ document. These forms may be described in subsequent documents.
+
+ This document details subordinate referral processing requirements for
+ servers. This document does not describe protocol syntax and
+ semantics. This is detailed in RFC 2251 [RFC2251].
+
+ This document does not detail use of subordinate knowledge references
+ to support replicated environments nor distributed operations (e.g.,
+ chaining of operations from one server to other servers).
+
+
+2. Schema
+
+2.1. The referral Object Class
+
+ A referral object is a directory entry whose structural object class
+ is (or is derived from) the referral object class.
+
+
+
+Zeilenga LDAP NamedRef [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
+ ( 2.16.840.1.113730.3.2.6
+ NAME 'referral'
+ DESC 'named subordinate reference object'
+ STRUCTURAL
+ MUST ref )
+
+ The referral object class is a structural object class used to
+ represent a subordinate reference in the directory. The referral
+ object class SHOULD be used in conjunction with the extensibleObject
+ object class to support the naming attributes used in the entry's
+ Distinguished Name (DN) [RFC2253]. Referral objects are directory
+ entries whose structural object class is (or is derived from)
+ referral.
+
+ Referral objects are normally instantiated at DSEs immediately
+ subordinate to object entries within a naming context held by the DSA.
+ Referral objects are analogous to X.500 subordinate knowledge (subr)
+ DSEs [X.501].
+
+ In the presence of a ManageDsaIT control, referral objects are treated
+ as normal entries as described in section 3. Note that the ref
+ attribute is operational and will only returned in a search entry
+ response when requested.
+
+ In the absence of a ManageDsaIT control, the content of referral
+ objects are used to construct referrals and search references as
+ described in section 4 and, as such, the referral entries are not
+ themselves visible to clients.
+
+
+2.2 The ref Attribute Type
+
+ ( 2.16.840.1.113730.3.1.34
+ NAME 'ref'
+ DESC 'named reference - a labeledURI'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ USAGE distributedOperation )
+
+ The ref attribute type has directoryString syntax and is case
+ sensitive. The ref attribute is multi-valued. Values placed in the
+ attribute MUST conform to the specification given for the labeledURI
+ attribute [RFC2079]. The labeledURI specification defines a format
+ that is a URI, optionally followed by whitespace and a label. This
+ document does not make use of the label portion of the syntax. Future
+ documents MAY enable new functionality by imposing additional
+ structure on the label portion of the syntax as it appears in the ref
+ attribute.
+
+
+
+Zeilenga LDAP NamedRef [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
+ If the URI contained in a ref attribute value refers to a LDAP
+ [RFC2251] server, it MUST be in the form of a LDAP URL [RFC2255]. The
+ LDAP URL SHOULD NOT contain an explicit scope specifier, filter,
+ attribute description list, or any extensions. The LDAP URL SHOULD
+ contain a non-empty DN. The handling of LDAP URLs with absent or
+ empty DN parts or with explicit scope specifier is not defined by this
+ specification.
+
+ Other URI schemes MAY be used so long as all operations returning
+ referrals based upon the value could be performed. This document does
+ not detail use of non-LDAP URIs. This is left to future
+ specifications.
+
+ The referential integrity of the URI SHOULD NOT be validated by the
+ server holding or returning the URI (whether as a value of the
+ attribute or as part of a referral result or search reference
+ response).
+
+ When returning a referral result or search continuation, the server
+ MUST NOT return the separator or label portions of the attribute
+ values as part of the reference. When the attribute contains multiple
+ values, the URI part of each value is used to construct the referral
+ result or search continuation.
+
+ The ref attribute values SHOULD NOT be used as a relative
+ name-component of an entry's DN [RFC2253].
+
+ This document uses the ref attribute in conjunction with the referral
+ object class to represent subordinate references. The ref attribute
+ may be used for other purposes as defined by other documents.
+
+
+3. The ManageDsaIT Control
+
+ The client may provide the ManageDsaIT control with an operation to
+ indicate that the operation is intended to manage objects within the
+ DSA (server) Information Tree. The control causes Directory-specific
+ entries (DSEs), regardless of type, to be treated as normal entries
+ allowing clients to interrogate and update these entries using LDAP
+ operations.
+
+ A client MAY specify the following control when issuing an add,
+ compare, delete, modify, modifyDN, search request or an extended
+ operation for which the control is defined.
+
+ The control type is 2.16.840.1.113730.3.4.2. The control criticality
+ may be TRUE or, if FALSE, absent. The control value is absent.
+
+
+
+
+Zeilenga LDAP NamedRef [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
+ When the control is present in the request, the server SHALL NOT
+ generate a referral or continuation reference based upon information
+ held in referral objects and instead SHALL treat the referral object
+ as a normal entry. The server, however, is still free to return
+ referrals for other reasons. When not present, referral objects SHALL
+ be handled as described above.
+
+ The control MAY cause other objects to be treated as normal entries as
+ defined by subsequent documents.
+
+
+4. Named Subordinate References
+
+ A named subordinate reference is constructed by instantiating a
+ referral object in the referencing server with ref attribute values
+ which point to the corresponding subtree maintained in the referenced
+ server. In general, the name of the referral object is the same as
+ the referenced object and this referenced object is a context prefix
+ [X.501].
+
+ That is, if server A holds "DC=example,DC=net" and server B holds
+ "DC=sub,DC=example,DC=net", server A may contain a referral object
+ named "DC=sub,DC=example,DC=net" which contains a ref attribute with
+ value of "ldap://B/DC=sub,DC=example,DC=net".
+
+ dn: DC=sub,DC=example,DC=net
+ dc: sub
+ ref: ldap://B/DC=sub,DC=example,DC=net
+ objectClass: referral
+ objectClass: extensibleObject
+
+ Typically the DN of the referral object and the DN of the object in
+ the referenced server are the same.
+
+ If the ref attribute has multiple values, all the DNs contained within
+ the LDAP URLs SHOULD be equivalent. Administrators SHOULD avoid
+ configuring naming loops using referrals.
+
+ Named references MUST be treated as normal entries if the request
+ includes the ManageDsaIT control as described in section 3.
+
+
+5. Scenarios
+
+ The following sections contain specifications of how referral objects
+ should be used in different scenarios followed by examples that
+ illustrate that usage. The scenarios described here consist of
+ referral object handling when finding target of a non-search
+
+
+
+Zeilenga LDAP NamedRef [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
+ operation, when finding the base of a search operation, and when
+ generating search references. Lastly, other operation processing
+ considerations are presented.
+
+ It is to be noted that, in this document, a search operation is
+ conceptually divided into two distinct, sequential phases: (1) finding
+ the base object where the search is to begin, and (2) performing the
+ search itself. The first phase is similar to, but not the same as,
+ finding the target of a non-search operation.
+
+ It should also be noted that the ref attribute may have multiple
+ values and, where these sections refer to a single ref attribute
+ value, multiple ref attribute values may be substituted and SHOULD be
+ processed and returned (in any order) as a group in a referral or
+ search reference in the same way as described for a single ref
+ attribute value.
+
+ Search references returned for a given request may be returned in any
+ order.
+
+
+5.1. Example Configuration
+
+ For example, suppose the contacted server (hosta) holds the entry
+ "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW" and the following
+ referral objects:
+
+ dn: OU=People,O=MNN,C=WW
+ ou: People
+ ref: ldap://hostb/OU=People,O=MNN,C=US
+ ref: ldap://hostc/OU=People,O=MNN,C=US
+ objectClass: referral
+ objectClass: extensibleObject
+
+ dn: OU=Roles,O=MNN,C=WW
+ ou: Roles
+ ref: ldap://hostd/OU=Roles,O=MNN,C=WW
+ objectClass: referral
+ objectClass: extensibleObject
+
+ The first referral object provides the server with the knowledge that
+ subtree "OU=People,O=MNN,C=WW" is held by hostb and hostc (e.g., one
+ is the master and the other a shadow). The second referral object
+ provides the server with the knowledge that the subtree
+ "OU=Roles,O=MNN,C=WW" is held by hostd.
+
+ Also, in the context of this document, the "nearest naming context"
+ means the deepest context which the object is within. That is, if the
+
+
+
+Zeilenga LDAP NamedRef [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
+ object is within multiple naming contexts, the nearest naming context
+ is the one which is subordinate to all other naming contexts the
+ object is within.
+
+
+5.2. Target object considerations
+
+ This section details referral handling for add, compare, delete,
+ modify, and modify DN operations. If the client requests any of these
+ operations, there are four cases that the server must handle with
+ respect to the target object.
+
+ The DN part MUST be modified such that it refers to the appropriate
+ target in the referenced server (as detailed below). Even where the
+ DN to be returned is the same as the target DN, the DN part SHOULD NOT
+ be trimmed.
+
+ In cases where the URI to be returned is a LDAP URL, the server SHOULD
+ trim any present scope, filter, or attribute list from the URI before
+ returning it. Critical extensions MUST NOT be trimmed or modified.
+
+ Case 1: The target object is not held by the server and is not within
+ or subordinate to any naming context nor subordinate to any
+ referral object held by the server.
+
+ The server SHOULD process the request normally as appropriate for
+ a non-existent base which is not within any naming context of the
+ server (generally return noSuchObject or a referral based upon
+ superior knowledge reference information). This document does not
+ detail management or processing of superior knowledge reference
+ information.
+
+ Case 2: The target object is held by the server and is a referral
+ object.
+
+ The server SHOULD return the URI value contained in the ref
+ attribute of the referral object appropriately modified as
+ described above.
+
+ Example: If the client issues a modify request for the target object
+ of "OU=People,O=MNN,c=WW", the server will return:
+
+ ModifyResponse (referral) {
+ ldap://hostb/OU=People,O=MNN,C=WW
+ ldap://hostc/OU=People,O=MNN,C=WW
+ }
+
+
+
+
+
+Zeilenga LDAP NamedRef [Page 7]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
+ Case 3: The target object is not held by the server, but the nearest
+ naming context contains no referral object which the target object
+ is subordinate to.
+
+ If the nearest naming context contains no referral object which
+ the target is subordinate to, the server SHOULD process the
+ request as appropriate for a nonexistent target (generally return
+ noSuchObject).
+
+ Case 4: The target object is not held by the server, but the nearest
+ naming context contains a referral object which the target object
+ is subordinate to.
+
+ If a client requests an operation for which the target object is
+ not held by the server and the nearest naming context contains a
+ referral object which the target object is subordinate to, the
+ server SHOULD return a referral response constructed from the URI
+ portion of the ref value of the referral object.
+
+ Example: If the client issues an add request where the target object
+ has a DN of "CN=Manager,OU=Roles,O=MNN,C=WW", the server will
+ return
+
+ AddResponse (referral) {
+ ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW"
+ }
+
+ Note that the DN part of the LDAP URL is modified such that it
+ refers to the appropriate entry in the referenced server.
+
+
+5.3. Base Object Considerations
+
+ This section details referral handling for base object processing
+ within search operations. Like target object considerations for non-
+ search operations, there are the four cases.
+
+ In cases where the URI to be returned is a LDAP URL, the server MUST
+ provide an explicit scope specifier from the LDAP URL prior to
+ returning it. In addition, the DN part MUST be modified such that it
+ refers to the appropriate target in the referenced server (as detailed
+ below).
+
+ If aliasing dereferencing was necessary in finding the referral
+ object, the DN part of the URI MUST be replaced with the base DN as
+ modified by the alias dereferencing such that the return URL refers to
+ the new target object per [RFC2251, 4.1.11].
+
+
+
+
+Zeilenga LDAP NamedRef [Page 8]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
+ Critical extensions MUST NOT be trimmed nor modified.
+
+ Case 1: The base object is not held by the server and is not within
+ nor subordinate to any naming context held by the server.
+
+ The server SHOULD process the request normally as appropriate for
+ a non-existent base which not within any naming context of the
+ server (generally return a superior referral or noSuchObject).
+ This document does not detail management or processing of superior
+ knowledge references.
+
+ Case 2: The base object is held by the server and is a referral
+ object.
+
+ The server SHOULD return the URI value contained in the ref
+ attribute of the referral object appropriately modified as
+ described above.
+
+
+ Example: If the client issues a subtree search in which the base
+ object is "OU=Roles,O=MNN,C=WW", the server will return
+
+ SearchResultDone (referral) {
+ ldap://hostd/OU=Roles,O=MNN,C=WW??sub
+ }
+
+ If the client were to issue a base or oneLevel search instead of
+ subtree, the returned LDAP URL would explicitly specify "base" or
+ "one", respectively, instead of "sub".
+
+ Case 3: The base object is not held by the server, but the nearest
+ naming context contains no referral object which the base object
+ is subordinate to.
+
+ If the nearest naming context contains no referral object which
+ the base is subordinate to, the request SHOULD be processed
+ normally as appropriate for a nonexistent base (generally return
+ noSuchObject).
+
+ Case 4: The base object is not held by the server, but the nearest
+ naming context contains a referral object which the base object is
+ subordinate to.
+
+ If a client requests an operation for which the target object is
+ not held by the server and the nearest naming context contains a
+ referral object which the target object is subordinate to, the
+ server SHOULD return a referral response which is constructed from
+ the URI portion of the ref value of the referral object.
+
+
+
+Zeilenga LDAP NamedRef [Page 9]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
+ Example: If the client issues a base search request for
+ "CN=Manager,OU=Roles,O=MNN,C=WW", the server will return
+
+ SearchResultDone (referral) {
+ ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base"
+ }
+
+ If the client were to issue a subtree or oneLevel search instead
+ of subtree, the returned LDAP URL would explicitly specify "sub"
+ or "one", respectively, instead of "base".
+
+ Note that the DN part of the LDAP URL is modified such that it
+ refers to the appropriate entry in the referenced server.
+
+
+5.4. Search Continuation Considerations
+
+ For search operations, once the base object has been found and
+ determined not to be a referral object, the search may progress. Any
+ entry matching the filter and scope of the search which is not a
+ referral object is returned to the client normally as described in
+ [RFC2251].
+
+ For each referral object within the requested scope, regardless of the
+ search filter, the server SHOULD return a SearchResultReference which
+ is constructed from the URI component of values of the ref attribute.
+ If the URI component is not a LDAP URL, it should be returned as is.
+ If the LDAP URL's DN part is absent or empty, the DN part must be
+ modified to contain the DN of the referral object. If the URI
+ component is a LDAP URL, the URI SHOULD be modified to add an explicit
+ scope specifier.
+
+ Subtree Example:
+
+ If a client requests a subtree search of "O=MNN,C=WW", then in
+ addition to any entries within scope which match the filter, hosta
+ will also return two search references as the two referral objects
+ are within scope. One possible response might be:
+
+ SearchEntry for O=MNN,C=WW
+ SearchResultReference {
+ ldap://hostb/OU=People,O=MNN,C=WW??sub
+ ldap://hostc/OU=People,O=MNN,C=WW??sub
+ }
+ SearchEntry for CN=Manager,O=MNN,C=WW
+ SearchResultReference {
+ ldap://hostd/OU=Roles,O=MNN,C=WW??sub
+ }
+
+
+
+Zeilenga LDAP NamedRef [Page 10]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
+ SearchResultDone (success)
+
+ One Level Example:
+
+ If a client requests a one level search of "O=MNN,C=WW" then, in
+ addition to any entries one level below the "O=MNN,C=WW" entry
+ matching the filter, the server will also return two search
+ references as the two referral objects are within scope. One
+ possible sequence is shown:
+
+ SearchResultReference {
+ ldap://hostb/OU=People,O=MNN,C=WW??base
+ ldap://hostc/OU=People,O=MNN,C=WW??base
+ }
+ SearchEntry for CN=Manager,O=MNN,C=WW
+ SearchResultReference {
+ ldap://hostd/OU=Roles,O=MNN,C=WW??base
+ }
+ SearchResultDone (success)
+
+ Note: Unlike the examples in Section 4.5.3.1 of RFC 2251, the LDAP
+ URLs returned with the SearchResultReference messages contain,
+ as required by this specification, an explicit scope specifier.
+
+
+5.6. Other Considerations
+
+ This section details processing considerations for other operations.
+
+
+5.6.1 Bind
+
+ Servers SHOULD NOT return referral result code if the bind name (or
+ authentication identity or authorization identity) is (or is
+ subordinate to) a referral object but MAY use the knowledge
+ information to process the bind request (such as in support a future
+ distributed operation specification). Where the server makes no use
+ of the knowledge information, the server processes the request
+ normally as appropriate for a non-existent authentication or
+ authorization identity (e.g., return invalidCredentials).
+
+
+5.6.2 Modify DN
+
+ If the newSuperior is a referral object or is subordinate to a
+ referral object, the server SHOULD return affectsMultipleDSAs. If the
+ newRDN already exists but is a referral object, the server SHOULD
+ return affectsMultipleDSAs instead of entryAlreadyExists.
+
+
+
+Zeilenga LDAP NamedRef [Page 11]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
+6. Security Considerations
+
+ This document defines mechanisms that can be used to tie LDAP (and
+ other) servers together. The information used to tie services
+ together should be protected from unauthorized modification. If the
+ server topology information is not public information, it should be
+ protected from unauthorized disclosure as well.
+
+
+7. Acknowledgments
+
+ This document borrows heavily from previous work by IETF LDAPext
+ Working Group. In particular, this document is based upon "Named
+ Referral in LDAP Directories" (an expired Internet Draft) by
+ Christopher Lukas, Tim Howes, Michael Roszkowski, Mark C. Smith, and
+ Mark Wahl.
+
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+9. Normative References
+
+ [RFC2079] M. Smith, "Definition of an X.500 Attribute Type and an
+ Object Class to Hold Uniform Resource Identifiers (URIs)",
+ RFC 2079, January 1997.
+
+ [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.
+
+ [RFC2253] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", RFC 2253, December 1997.
+
+ [RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255,
+ December, 1997.
+
+
+
+
+Zeilenga LDAP NamedRef [Page 12]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
+ [RFC2396] Berners-Lee, T., R. Fielding, L. Masinter, "Uniform Resource
+ Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+ [X.501] ITU-T, "The Directory: Models", X.501, 1993.
+
+
+10. Informative References
+
+ [X.500] ITU-T, "The Directory: Overview of Concepts, Models, and
+ Services", X.500, 1993.
+
+ [X.511] ITU-T, "The Directory: Abstract Service Definition", X.500,
+ 1993.
+
+
+Copyright 2001, 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 LDAP NamedRef [Page 13]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 17 May 2002
+
+
+
+ LDAPv3: All Operational Attributes
+ <draft-zeilenga-ldap-opattrs-03.txt>
+
+
+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 Extensions Working Group
+ mailing list <ietf-ldapext@netscape.com>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ Copyright 2002, The Internet Society. All Rights Reserved.
+
+ Please see the Copyright section near the end of this document for
+ more information.
+
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) supports a mechanism
+ for requesting the return of all user attributes but does not all
+ operational attributes. This document describes an LDAP extension
+ which clients may use to request the return of all operational
+ attributes.
+
+
+
+Zeilenga LDAP All Op Attrs [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
+
+
+1. Overview
+
+ X.500 [X.500] provides a mechanism for clients to request all
+ operational attributes be returned with entries provided in response
+ to a search operation. This mechanism is often used by clients to
+ discover which operational attributes are present in an entry.
+
+ This documents extends LDAP [RFC2251] to provide a simple mechanism
+ which clients may use to request the return of all operation
+ attributes. The mechanism is designed for use with existing general
+ purpose LDAP clients (including web browsers which support LDAP URLs)
+ and existing LDAP API.
+
+ 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].
+
+
+2. All Operational Attributes
+
+ The presence of the attribute description "+" (ASCII 43) in the list
+ of attributes in a Search Request SHALL signify a request for the
+ return of all operational attributes.
+
+ As with all search requests, client implementors should note that
+ results may not include all requested attributes due to access
+ controls or other restrictions. Clients implementors should also note
+ that certain operational attributes may be returned only if requested
+ by name even when "+" is present. This is because some operational
+ attributes are very expensive to return.
+
+ Servers supporting this feature SHOULD publish the Object Identifier
+ 1.3.6.1.4.1.4203.1.5.1 as a value of the supportedFeatures [FEATURES]
+ attribute in the root DSE.
+
+
+3. Interoperability Considerations
+
+ This mechanism is specifically designed to allow users to request all
+ operational attributes using existing LDAP clients. In particular,
+ the mechanism is designed to be compatible with existing general
+ purpose LDAP clients includes web browsers which support LDAP URLs
+ [RFC2255].
+
+ The addition of this mechanism to LDAPv3 is believed not to cause any
+ significant interoperability issues (this has been confirmed through
+ testing). Servers which have yet to implement this specification
+ should ignore the "+" as an unrecognized attribute description per
+
+
+
+Zeilenga LDAP All Op Attrs [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
+
+
+ [RFC2251, Section 4.5.1]. From the client's perspective, a server
+ which does not return all operational attributes when "+" is requested
+ should be viewed as having other restrictions.
+
+ It is also noted that this mechanism is believed to require no
+ modification of existing LDAP APIs.
+
+
+4. Security Considerations
+
+ This document provides a mechanism which clients may use to discover
+ operational attributes. Those relying on security by obscurity SHOULD
+ implement appropriate access controls to restricts access to
+ operational attributes per local policy.
+
+
+5. IANA Considerations
+
+ No IANA assignments are requested.
+
+ This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the
+ feature described above. This OID was assigned [ASSIGN] by OpenLDAP
+ Foundation under its IANA assigned private enterprise allocation
+ [PRIVATE] for use in this specification.
+
+
+6. Acknowledgment
+
+ The "+" mechanism is believed to have been first suggested by Bruce
+ Greenblatt in a November 1998 post to the IETF LDAPext Working Group
+ mailing list.
+
+
+7. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+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.
+
+
+
+
+Zeilenga LDAP All Op Attrs [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
+
+
+ [FEATURES] K. Zeilenga, "Feature Discovery in LDAP", draft-zeilenga-
+ ldap-features-xx.txt (a work in progress).
+
+
+9. Informative References
+
+ [RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+ [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.
+
+
+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 LDAP All Op Attrs [Page 4]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 1 March 2002
+Obsoletes: RFC 2596
+
+
+ Language Tags and Ranges in LDAP
+ draft-zeilenga-ldap-rfc2596-01.txt
+
+
+Status of 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 Extensions Working Group
+ (LDAPext) mailing list <ietf-ldapext@netscape.com>. Please send
+ editorial comments directly to the document editor
+ <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ Copyright 2002, The Internet Society. All Rights Reserved.
+
+ Please see the Copyright section near the end of this document for
+ more information.
+
+Abstract
+
+ It is often desirable to to be able to indicate the natural language
+ associated with values held in a directory and to be able to query the
+ directory for values which fulfill the user's language needs. This
+ document details the use of Language Tags and Ranges in the
+ Lightweight Directory Access Protocol (LDAP).
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 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].
+
+
+1. Background and Intended Use
+
+ The Lightweight Directory Access Protocol (LDAP) [Roadmap] provides a
+ means for clients to interrogate and modify information stored in a
+ distributed directory system. The information in the directory is
+ maintained as attributes of entries. Most of these attributes have
+ syntaxes which are human-readable strings, and it is desirable to be
+ able to indicate the natural language associated with attribute
+ values.
+
+ This document describes how language tags and ranges [RFC3066] are
+ carried in LDAP and are to be interpreted by LDAP implementations.
+ All implementations MUST be prepared to accept language tags and
+ ranges in the LDAP protocol.
+
+ This document replaces RFC 2596. Appendix A summaries changes made
+ since RFC 2596.
+
+ Appendix B discusses differences from X.500(1997) "contexts"
+ mechanism.
+
+ Appendix A and B are provided for information purposes and are not a
+ normative part of this specification.
+
+ The remainder of this section provides a summary of Language Tags,
+ Language Ranges, and Attribute Descriptions.
+
+
+1.1. Language Tags
+
+ Section 2 of BCP 47 [RFC3066] describes the language tag format which
+ is used in LDAP. Briefly, it is a string of ASCII alphabetic
+ characters and hyphens. Examples include "fr", "en-US" and "ja-JP".
+ Language tags are case insensitive. For example, the language tag
+ "en-us" is the same as "EN-US".
+
+ Section 2 of this document details use of language tags in LDAP.
+
+
+1.2. Language Ranges
+
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+ Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
+ Language ranges are used to specify sets of language tags.
+
+ A language range matches a language tag if it exactly equals the tag,
+ or if it exactly equals a prefix of the tag such that the first
+ character following the prefix is "-". The special tag "*" matches
+ all tags.
+
+ Due to restrictions upon option naming in LDAP, this document uses a
+ different language range syntax. However, the semantics of language
+ ranges in LDAP is consistent with BCP 47.
+
+ Section 3 of this document details use of language ranges in LDAP.
+
+
+1.3. Attribute Descriptions
+
+ This section provides an overview of attributes in LDAP. LDAP
+ attributes are defined in [Models].
+
+ An attribute consists of a type, a set of zero or more associated
+ tagging options, and a set of one or more values. The type and the
+ options are combined into the AttributeDescription.
+ AttributeDescriptions can also contain options which are not part of
+ the attribute, but indicate some other function such as the transfer
+ encoding.
+
+ An attribute with one or more tagging options is a direct subtype of
+ each attribute of the same with all but one of the tagging options.
+ If the attribute's type is a direct subtype of some other type, then
+ the attribute is also a direct subtype of the attribute whose
+ description consists of the the supertype and all of the tagging
+ options. That is, CN;x-bar;x-foo is a direct subtype of CN;x-bar,
+ CN;x-foo, and name;x-bar;x-foo. Note that CN is a subtype of name.
+
+ If the attribute description contains an unrecognized option, the
+ attribute description is treated as an unrecognized attribute type.
+
+ As language tags are intended to stored with the attribute, they are
+ to treated as tagging options as described in Section 2. Language
+ range are used only to match against language ranges and are not
+ stored with the attribute. They are not treated tagging options (nor
+ as transfer options), but as described in Section 3.
+
+
+2. Use of Language Tags in LDAP
+
+ This section describes how LDAP implementations MUST interpret
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+ language tags in performing operations.
+
+ Servers which support storing attributes with language tag options in
+ the Directory Information Tree (DIT) SHOULD allow any attribute type
+ it recognizes that has the Directory String, IA5 String, or other
+ textual string syntax to have language tag options associated with it.
+ Servers MAY allow language options to be associated with other
+ attributes types.
+
+ Clients SHOULD NOT assume servers are capable of storing attributes
+ with language tags in the directory.
+
+ Implementations MUST NOT otherwise interpret the structure of the tag
+ when comparing two tag, and MUST treat them simply as strings of
+ characters. Implementations MUST allow any arbitrary string which
+ conforms to the syntax defined in BCP 47 [RFC3066] to be used as a
+ language tag.
+
+
+2.1. Language Tag Options
+
+ A language tag option associates a natural language with values of an
+ attribute. An attribute description MAY contain multiple language tag
+ options. An entry MAY contain multiple attributes with same attribute
+ type but different combinations of language tag (and other) options.
+
+ A language tag option conforms to the following ABNF [RFC2234]:
+
+ language-tag-option = "lang-" Language-Tag
+
+ where the Language-Tag production is as defined in BCP 47 [RFC3066].
+ This production and those it imports from [RFC2234] are provided here
+ for convenience:
+
+ Language-Tag = Primary-subtag *( "-" Subtag )
+
+ Primary-subtag = 1*8ALPHA
+
+ Subtag = 1*8(ALPHA / DIGIT)
+
+ ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
+
+ DIGIT = %x30-39 ; 0-9
+
+ A language tag option is a tagging option [Models]. A language tag
+ option has no effect on the syntax of the attribute's values nor their
+ transfer encoding.
+
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+ Examples of valid AttributeDescription:
+
+ givenName;lang-en-US
+ CN;lang-ja
+ SN;lang-de;lang-gem-PFL
+ O;lang-i-klingon;x-foobar
+ description;x-foobar
+ CN
+
+ Notes: The last two have no language tag options. The x-foobar option
+ is fictious and used for example purposes.
+
+
+2.2. Search Filter
+
+ If language tag options are present in an AttributeDescription in an
+ assertion, then for each entry within scope, the values of each
+ attribute whose AttributeDescription consists of the same attribute
+ type or its subtypes and contains each of the presented (and possibly
+ other) options is to be matched.
+
+ Thus for example a filter of an equality match of type
+ "name;lang-en-US" and assertion value "Billy Ray", against the
+ following directory entry
+
+ dn: SN=Ray,DC=example,DC=com
+ objectclass: top DOES NOT MATCH (wrong type)
+ objectclass: person DOES NOT MATCH (wrong type)
+ name;lang-en-US: Billy Ray MATCHES
+ name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
+ CN;lang-en-US: Billy Ray MATCHES
+ CN;lang-en-US;x-foobar: Billy Ray MATCHES
+ CN;lang-en;x-foobar: Billy Ray DOES NOT MATCH (differing lang-)
+ CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
+ name: Billy Ray DOES NOT MATCH (no lang-)
+ SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
+ SN: Ray DOES NOT MATCH (no lang-,
+ wrong value)
+
+ (Note that "CN" and "SN" are subtypes of "name".)
+
+ It is noted that providing a language tag option in a search filter
+ AttributeDescription will filter out desirable values where the tag
+ does not match exactly. For example, the filter (name;lang-en=Billy
+ Ray) does NOT match the attribute "name;lang-en-US: Billy Ray".
+
+ If the server does not support storing attributes with language tag
+ options in the DIT, then any assertion which includes a language tag
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+ option will not match as such it is an unrecognized attribute type.
+ No error would be returned because of this; a presence assertion would
+ evaluate to FALSE and all other assertions to Undefined.
+
+ If no options are specified in the assertion, then only the base
+ attribute type and the assertion value need match the value in the
+ directory.
+
+ Thus for example a filter of an equality match of type "name" and
+ assertion value "Billy Ray", against the following directory entry
+
+ dn: SN=Ray,DC=example,DC=net
+ objectclass: top DOES NOT MATCH (wrong type)
+ objectclass: person DOES NOT MATCH (wrong type)
+ name;lang-en-US: Billy Ray MATCHES
+ name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
+ CN;lang-en-US;x-foobar: Billy Ray MATCHES
+ CN;lang-en;x-foobar: Billy Ray MATCHES
+ CN;x-foobar: Billy Ray MATCHES
+ name: Billy Ray MATCHES
+ SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
+ SN: Ray DOES NOT MATCH (wrong value)
+
+
+2.3. Requested Attributes in Search
+
+ Clients can provide language tag options in AttributeDescription in
+ the requested attribute list in a search request.
+
+ If language tag options are provided in an attribute description, then
+ only attributes in a directory entry whose attribute descriptions have
+ the same attribute type or its subtype and the provided language tags
+ options are to be returned. Thus if a client requests just the
+ attribute "name;lang-en", the server would return "name;lang-en" and
+ "CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr".
+
+ Clients can provide in the attribute list multiple
+ AttributeDescription which have the same base attribute type but
+ different options. For example a client could provide both
+ "name;lang-en" and "name;lang-fr", and this would permit an attribute
+ with either language tag option to be returned. Note there would be
+ no need to provide both "name" and "name;lang-en" since all subtypes
+ of name would match "name".
+
+ If a server does not support storing attributes with language tag
+ options in the DIT, then any attribute descriptions in the list which
+ include language tag options are to be ignored, just as if they were
+ unknown attribute types.
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+ If a request is made specifying all attributes or an attribute is
+ requested without providing a language tag option, then all attribute
+ values regardless of their language tag option are returned.
+
+ For example, if the client requests a "description" attribute, and a
+ matching entry contains the following attributes:
+
+ objectclass: top
+ objectclass: organization
+ O: Software GmbH
+ description: software
+ description;lang-en: software products
+ description;lang-de: Softwareprodukte
+ postalAddress: Berlin 8001 Germany
+ postalAddress;lang-de: Berlin 8001 Deutschland
+
+ The server would return:
+
+ description: software
+ description;lang-en: software products
+ description;lang-de: Softwareprodukte
+
+
+2.4. Compare
+
+ Language tag options can be present in an AttributeDescription used in
+ a compare request AttributeValueAssertion. This is to be treated by
+ servers the same as the use of language tag options in a search filter
+ with an equality match, as described in Section 2.2. If there is no
+ attribute in the entry with the same subtype and language tag options,
+ the noSuchAttributeType error will be returned.
+
+ Thus for example a compare request of type "name" and assertion value
+ "Johann", against an entry containing the following attributes:
+
+ objectclass: top
+ objectclass: person
+ givenName;lang-de-DE: Johann
+ CN: Johann Sibelius
+ SN: Sibelius
+
+ would cause the server to return compareTrue.
+
+ However, if the client issued a compare request of type "name;lang-de"
+ and assertion value "Johann" against the above entry, the request
+ would fail with the noSuchAttributeType error.
+
+ If the server does not support storing attributes with language tag
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 7]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+ options in the DIT, then any comparison which includes a language tag
+ option will always fail to locate an attribute, and
+ noSuchAttributeType will be returned.
+
+
+ 2.5. Add Operation
+
+ Clients can provide language options in AttributeDescription in
+ attributes of a new entry to be created.
+
+ A client can provide multiple attributes with the same attribute type
+ and value, so long as each attribute has a different set of language
+ tag options.
+
+ For example, the following is a legal request.
+
+ dn: CN=John Smith,DC=example,DC=com
+ objectclass: top
+ objectclass: person
+ objectclass: residentialPerson
+ name: John Smith
+ CN: John Smith
+ CN;lang-en: John Smith
+ SN: Smith
+ SN;lang-en;lang-en-US: Smith
+ streetAddress: 1 University Street
+ streetAddress;lang-en: 1 University Street
+ streetAddress;lang-fr: 1 rue Universite
+ houseIdentifier;lang-fr: 9e etage
+
+ If a server does not support storing language tag options with
+ attribute values in the DIT, then it MUST treat an
+ AttributeDescription with a language tag option as an unrecognized
+ attribute. If the server forbids the addition of unrecognized
+ attributes then it MUST fail the add request with an appropriate
+ result code.
+
+
+2.6. Modify Operation
+
+ A client can provide language tag options in an AttributeDescription
+ as part of a modification element in the modify operation.
+
+ Attribute types and language tag options MUST match exactly against
+ values stored in the directory. For example, if the modification is a
+ "delete", then if the stored values to be deleted have language tag
+ options, then those language tag options MUST be provided in the
+ modify operation, and if the stored values to be deleted do not have
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 8]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+ any language tag option, then no language tag option is to be
+ provided.
+
+ If the server does not support storing language tag options with
+ attribute values in the DIT, then it MUST treat an
+ AttributeDescription with a language tag option as an unrecognized
+ attribute, and MUST fail the request with an appropriate result code.
+
+
+3. Use of Language Ranges in LDAP
+
+ Since the publication of RFC 2596, it has become apparent that there
+ is a need to provide a mechanism for a client to request attributes
+ based upon set of language tag options whose tags all begin with the
+ same sequence of language sub-tags.
+
+ AttributeDescriptions containing language range options are intended
+ to be used in attribute value assertions, search attribute lists, and
+ other places where the client desires to provide an attribute
+ description matching of a range of language tags associated with
+ attributes.
+
+ A language range option conforms to the following ABNF [RFC2234]:
+
+ language-range-option = "lang-" [ Language-Tag "-" ]
+
+ where the Language-Tag production is as defined in BCP 47 [RFC3066].
+ This production and those it imports from [RFC2234] are provided here
+ for convenience:
+
+ Language-Tag = Primary-subtag *( "-" Subtag )
+
+ Primary-subtag = 1*8ALPHA
+
+ Subtag = 1*8(ALPHA / DIGIT)
+
+ ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
+
+ DIGIT = %x30-39 ; 0-9
+
+ A language range option matches a language tag option if language
+ range option less the trailing "-" matches exactly the language tag or
+ if the language range option (including the trailing "-") matches a
+ prefix of the language tag option. Note that the language range
+ option "lang-" matches all language tag options.
+
+ Examples of valid AttributeDescription containing language range
+ options:
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 9]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+ givenName;lang-en-
+ CN;lang-
+ O;lang-x-;x-foobar
+
+ A language range option is not a tagging option. Attributes cannot be
+ stored with language range options. Any attempt to add or update an
+ attribute description with a language range option SHALL be treated as
+ an undefined attribute type and result in an error.
+
+ A language range option has no effect on the transfer encoding nor on
+ the syntax of the attribute values.
+
+ Servers SHOULD support assertion of language ranges for any attribute
+ which they allow to stored with language tags.
+
+
+3.1. Search Filter
+
+ If a language range option is present in an AttributeDescription in an
+ assertion, then for each entry within scope, the values of each
+ attribute whose AttributeDescription consists of the same attribute
+ type or its subtypes and contains a language tag option matching the
+ language range option are to be returned.
+
+ Thus for example a filter of an equality match of type "name;lang-en-"
+ and assertion value "Billy Ray", against the following directory entry
+
+ dn: SN=Ray,DC=example,DC=com
+ objectclass: top DOES NOT MATCH (wrong type)
+ objectclass: person DOES NOT MATCH (wrong type)
+ name;lang-en-US: Billy Ray MATCHES
+ name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
+ CN;lang-en-US: Billy Ray MATCHES
+ CN;lang-en-US;x-foobar: Billy Ray MATCHES
+ CN;lang-en;x-foobar: Billy Ray MATCHES
+ CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
+ name: Billy Ray DOES NOT MATCH (no lang-)
+ SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
+ SN: Ray DOES NOT MATCH (no lang-,
+ wrong value)
+
+ (Note that "CN" and "SN" are subtypes of "name".)
+
+ If the server does not support storing attributes with language tag
+ options in the DIT, then any assertion which includes a language range
+ option will not match as it is an unrecognized attribute type. No
+ error would be returned because of this; a presence filter would
+ evaluate to FALSE and all other assertions to Undefined.
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 10]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+3.2. Requested Attributes in Search
+
+ Clients can provide language range options in AttributeDescription in
+ the requested attribute list in a search request.
+
+ If a language range option is provided in an attribute description,
+ then only attributes in a directory entry whose attribute descriptions
+ have the same attribute type or its subtype and a language tag option
+ matching the provided language range option are to be returned. Thus
+ if a client requests just the attribute "name;lang-en-", the server
+ would return "name;lang-en-US" and "CN;lang-en;lang-ja" but not "SN"
+ nor "name;lang-fr".
+
+ Clients can provide in the attribute list multiple
+ AttributeDescription which have the same base attribute type but
+ different options. For example a client could provide both
+ "name;lang-en-" and "name;lang-fr-", and this would permit an
+ attribute whose type was name or subtype of name and with a language
+ tag option matching either language range option to be returned.
+
+ If a server does not support storing attributes with language tag
+ options in the DIT, then any attribute descriptions in the list which
+ include language range options are to be ignored, just as if they were
+ unknown attribute types.
+
+
+3.3. Compare
+
+ Language range options can be present in an AttributeDescription used
+ in a compare request AttributeValueAssertion. This is to be treated
+ by servers the same as the use of language range options in a search
+ filter with an equality match, as described in Section 3.1. If there
+ is no attribute in the entry with the same subtype and a matching
+ language tag option, the noSuchAttributeType error will be returned.
+
+ Thus for example a compare request of type "name;lang-" and assertion
+ value "Johann", against the entry with the following attributes:
+
+ objectclass: top
+ objectclass: person
+ givenName;lang-de-DE: Johann
+ CN: Johann Sibelius
+ SN: Sibelius
+
+ will cause the server to return compareTrue. (Note that the language
+ range option "lang-" matches any language tag option.)
+
+ However, if the client issued a compare request of type "name;lang-de"
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 11]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+ and assertion value "Sibelius" against the above entry, the request
+ would fail with the noSuchAttributeType error.
+
+ If the server does not support storing attributes with language tag
+ options in the DIT, then any comparison which includes a language
+ range option will always fail to locate an attribute, and
+ noSuchAttributeType will be returned.
+
+
+4. Discovering Language Option Support
+
+ A server SHOULD indicate that it supports storing attributes with
+ language tag options in the DIT by publishing OID.TDB as a value of
+ the supportedFeatures [FEATURES] attribute in the root DSE.
+
+ A server SHOULD indicate that it supports language range matching of
+ attributes with language tag options stored in the DIT by publishing
+ OID.TDB as a value of the supportedFeatures [FEATURES] attribute in
+ the root DSE.
+
+ A server MAY restrict use of language tag options to a subset of the
+ attribute types it recognizes. This document does not define a
+ mechanism for determining which subset of attribute types can be used
+ with language tag options.
+
+
+5. Security Considerations
+
+ Language tags and range options are used solely to indicate the native
+ language of values and in querying the directory for values which
+ fulfill the user's language needed. These options are not known to
+ raise specific security considerations. However, the reader should
+ consider general directory security issues detailed in the LDAP
+ technical specification [Roadmap].
+
+
+6. Acknowledgments
+
+ This document is a revision of RFC 2596 by Mark Wahl and Tim Howes.
+ RFC 2596 was a product of the IETF ASID and LDAPEXT working groups.
+
+ This document borrows from a number of IETF documents including BCP
+ 47.
+
+
+7. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 12]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
+ BCP 47 (also RFC 3066), January 2001.
+
+ [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
+ Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Models] K. Zeilenga (editor), "LDAP: Directory Information Models",
+ draft-ietf-ldapbis-models-xx.txt, a work in progress.
+
+ [FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
+ draft-zeilenga-ldap-features-xx.txt (a work in progress).
+
+
+8. Informative References
+
+ [X.501] "The Directory: Models", ITU-T Recommendation X.501, 1997.
+
+
+Appendix A. Differences from RFC 2596
+
+ This document adds support for language ranges, provides a mechanism
+ that a client can use to discover whether a server supports language
+ tags and ranges, and clarifies how attributes with multiple language
+ tags are to be treated. This document is a significant rewrite of RFC
+ 2596.
+
+
+Appendix B. Differences from X.500(1997)
+
+ X.500(1997) [X.501] defines a different mechanism, contexts, as the
+ means of representing language tags (codes). This section summarizes
+ the major differences in approach.
+
+ a) An X.500 operation which has specified a language code on a value
+ matches a value in the directory without a language code.
+ b) LDAP references BCP 47 [RFC3066], which allows for IANA
+ registration of new tags as well as unregistered tags.
+ c) LDAP supports language ranges.
+ d) LDAP does not allow language tags (and ranges) in distinguished
+ names.
+ e) X.500 describes subschema administration procedures to allow
+ language codes to be associated with particular attributes types.
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 13]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+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 Language Tags and Ranges in LDAP [Page 14]
+\f
--- /dev/null
+
+
+
+
+
+
+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
+ <draft-zeilenga-ldap-subentry-05.txt>
+
+
+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 <ietf-ldapext@netscape.com>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 <kurt@OpenLDAP.org>
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 <sp>, <msp>, <sep>, <INTEGER>, <OBJECT-IDENTIFIER> and <LocalName>
+ 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]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 17 May 2002
+
+
+
+ LDAP True/False Filters
+ <draft-zeilenga-ldap-t-f-02.txt>
+
+
+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 Extensions Working Group
+ mailing list <ietf-ldapext@netscape.com>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ Copyright 2002, The Internet Society. All Rights Reserved.
+
+ Please see the Copyright section near the end of this document for
+ more information.
+
+
+Abstract
+
+ This document extends the Lightweight Directory Access Protocol (LDAP)
+ to support absolute True and False filters based upon similar
+ capabilities found in X.500 directory systems. The document also
+ extends the String Representation of LDAP Search Filters to support
+ these filters.
+
+
+
+Zeilenga LDAP True/False Filters [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
+
+
+1. Background and Intended Use
+
+ The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
+ True and False assertions. An 'and' filter with zero elements always
+ evaluates to True. An 'or' filter with zero elements always evaluates
+ to False. These filters are commonly used when requesting DSA-
+ specific Entries (DSEs) which do not necessarily have objectClass
+ attributes. That is, where "(objectClass=*)" may evaluate to False.
+
+ While LDAPv2 [RFC1777] placed no restriction on the number of elements
+ in 'and' and 'or' filter sets, the LDAPv2 string representation
+ [RFC1960] could not represent empty 'and' and 'or' filter sets. Due
+ to this, LDAPv3 [RFC2251] required 'and' and 'or' filter sets to have
+ at least one element. Hence, LDAPv3 does not provide absolute True or
+ False filters.
+
+ This documents extends LDAPv3 [RFC2251] to support absolute True and
+ False matches by allowing empty 'and' and 'or' and extends the filter
+ string representation [RFC2254] to allow empty filter lists.
+
+ 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].
+
+
+2. Absolute True and False Filters
+
+ Implementations of this extension SHALL allow 'and' and 'or' choices
+ with zero filter elements.
+
+ An 'and' Filter consisting of an empty set of filters SHALL evaluate
+ to True. This filter is to represented by the string "(&)".
+
+ An 'or' Filter consisting of an empty set of filters SHALL evaluate to
+ False. This filter is to represented by the string "(|)".
+
+ Servers supporting this feature SHOULD publish the Object Identifier
+ 1.3.6.1.4.1.4203.1.5.3 as a value of the supportedFeatures [FEATURES]
+ attribute in the root DSE.
+
+ Clients supporting this feature SHOULD NOT use the feature unless they
+ have knowledge the server supports it.
+
+
+3. Security Considerations
+
+ The (re)introduction of absolute True and False filters does not raise
+ any new security considerations.
+
+
+
+Zeilenga LDAP True/False Filters [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
+
+
+ Implementors of this (or any) LDAP extension should be familiar with
+ general LDAP general security considerations [LDAPTS].
+
+
+4. IANA Considerations
+
+ No IANA assignments are requested.
+
+ This document uses the OID 1.3.6.1.4.1.4203.1.5.3 to identify the
+ feature described above. This OID was assigned [ASSIGN] by OpenLDAP
+ Foundation under its IANA assigned private enterprise allocation
+ [PRIVATE] for use in this specification.
+
+
+5. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+6. 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.
+
+ [RFC2254] T. Howes, "A String Representation of LDAP Search Filters",
+ RFC 2254, December 1997.
+
+ [LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification",
+ draft-ietf-ldapbis-ldapv3-ts-xx.txt (a work in progress).
+
+ [FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
+ draft-zeilenga-ldap-features-xx.txt (a work in progress).
+
+
+7. Informative References
+
+ [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol", RFC 1777, March 1995.
+
+ [RFC1960] T. Howes, "A String Representation of LDAP Search Filters",
+ RFC 1960, June 1996.
+
+
+
+
+Zeilenga LDAP True/False Filters [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
+
+
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+ [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
+ Definition", 1993.
+
+ [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.
+
+
+
+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 LDAP True/False Filters [Page 4]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 17 May 2002
+Obsoletes: RFC 1274
+Updates: RFC 2798
+
+
+ LDAPv3: A Collection of User Schema
+ <draft-zeilenga-ldap-user-schema-06.txt>
+
+
+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 Directory Interest mailing list
+ <directory@apps.ietf.org>. Please send editorial comments directly to
+ the author <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ Copyright 2002, The Internet Society. All Rights Reserved.
+
+ Please see the Copyright section near the end of this document for
+ more information.
+
+
+Abstract
+
+ This document provides a collection of user schema elements for use
+ with LDAP (Lightweight Directory Access Protocol) from both ITU-T
+ Recommendations for the X.500 Directory and COSINE and Internet X.500
+ pilot projects.
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 1]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 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].
+
+
+Table of Contents (to be expanded by editor)
+
+ Status of this Memo 1
+ Abstract
+ Conventions 2
+ Table of Contents
+ 1. Background and Intended Use 3
+ 2. Matching Rules
+ 2.1. booleanMatch 4
+ 2.2. caseExactMatch
+ 2.3. caseExactOrderingMatch
+ 2.4. caseExactSubstringsMatch
+ 2.5. caseIgnoreListSubstringsMatch
+ 2.6. directoryStringFirstComponentMatch 5
+ 2.7. integerOrderingMatch
+ 2.8. keywordMatch
+ 2.9. numericStringOrderingMatch 6
+ 2.10. octetStringOrderingMatch
+ 2.11. storedPrefixMatch
+ 2.12. wordMatch 7
+ 3. Attribute Types
+ 3.1. associatedDomain
+ 3.2. associatedName
+ 3.3. buildingName
+ 3.3. co 8
+ 3.5. documentAuthor
+ 3.6. documentIdentifier
+ 3.7. documentLocation
+ 3.8. documentPublisher 9
+ 3.9. documentTitle
+ 3.10. documentVersion
+ 3.11. drink
+ 3.12. homePhone 10
+ 3.13. homePostalAddress
+ 3.14. host
+ 3.16. info
+ 3.17. mail 11
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 2]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ 3.18. manager
+ 3.19. mobile
+ 3.20. organizationalStatus
+ 3.21. otherMailbox 12
+ 3.22. pager
+ 3.23. personalTitle
+ 3.24. roomNumber 13
+ 3.25. secretary
+ 3.26. uid
+ 3.27. uniqueIdentifier
+ 3.28. userClass 14
+ 4. Object Classes
+ 4.1. account
+ 4.2. document 15
+ 4.3. documentSeries
+ 4.4. domainRelatedObject
+ 4.5. friendlyCountry
+ 4.6. rFC822LocalPart 16
+ 4.7. room
+ 4.8. simpleSecurityObject
+ 5. Security Considerations 17
+ 6. IANA Considerations
+ 7. Acknowledgments 19
+ 8. Author's Address
+ 9. Normative References
+ 10. Informative References
+ Full Copyright 20
+
+
+1. Background and Intended Use
+
+ This document provides descriptions [RFC2252] of user schema for use
+ with LDAP [LDAPTS] collected from numerous sources.
+
+ This document includes a summary of select schema introduced for the
+ COSINE and Internet X.500 pilot projects [RFC1274]. This document
+ obsoletes RFC 1274.
+
+ This document includes a summary of X.500 user schema [X.520] not
+ previously specified for use with LDAP. Some of these items were
+ described in the inetOrgPerson [RFC2798] schema. This document
+ supersedes these descriptions, replacing sections 9.1.3 and 9.3.3 of
+ RFC 2798.
+
+
+2. Matching Rules
+
+ This section introduces LDAP matching rules based upon descriptions of
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 3]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ their X.500 counterparts.
+
+
+2.1. booleanMatch
+
+ BooleanMatch compares for equality a asserted Boolean value with an
+ attribute value of BOOLEAN syntax. The rule returns TRUE if and only
+ if the values are the same, i.e. both are TRUE or both are FALSE.
+ (Source: X.520)
+
+ ( 2.5.13.13 NAME 'booleanMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
+
+
+2.2. caseExactMatch
+
+ CaseExactMatch compares for equality the asserted value with an
+ attribute value of DirectoryString syntax. The rule is identical to
+ the caseIgnoreMatch [RFC2252] rule except that case is not ignored.
+ (Source: X.520)
+
+ ( 2.5.13.5 NAME 'caseExactMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+2.3. caseExactOrderingMatch
+
+ CaseExactOrderingMatch compares the collation order of the asserted
+ string with an attribute value of DirectoryString syntax. The rule is
+ identical to the caseIgnoreOrderingMatch [RFC2252] rule except that
+ letters are not folded. (Source: X.520)
+
+ ( 2.5.13.6 NAME 'caseExactOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+2.4. caseExactSubstringsMatch
+
+ CaseExactSubstringsMatch determines whether the asserted value(s) are
+ substrings of an attribute value of DirectoryString syntax. The rule
+ is identical to the caseIgnoreSubstringsMatch [RFC2252] rule except
+ that case is not ignored. (Source: X.520)
+
+ ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+
+2.5. caseIgnoreListSubstringsMatch
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 4]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ CaseIgnoreListSubstringMatch compares the asserted substring with an
+ attribute value which is a sequence of DirectoryStrings, but where the
+ case (upper or lower) is not significant for comparison purposes. The
+ asserted value matches a stored value if and only if the asserted
+ value matches the string formed by concatenating the strings of the
+ stored value. This matching is done according to the
+ caseIgnoreSubstringsMatch [RFC2252] rule; however, none of the
+ initial, any, or final values of the asserted value are considered to
+ match a substring of the concatenated string which spans more than one
+ of the strings of the stored value. (Source: X.520)
+
+ ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+
+2.6. directoryStringFirstComponentMatch
+
+ DirectoryStringFirstComponentMatch compares for equality the asserted
+ DirectoryString value with an attribute value of type SEQUENCE whose
+ first component is mandatory and of type DirectoryString. The rule
+ returns TRUE if and only if the attribute value has a first component
+ whose value matches the asserted DirectoryString using the rules of
+ caseIgnoreMatch [RFC2252]. A value of the assertion syntax is derived
+ from a value of the attribute syntax by using the value of the first
+ component of the SEQUENCE. (Source: X.520)
+
+ ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+2.7. integerOrderingMatch
+
+ The integerOrderingMatch rule compares the ordering of the asserted
+ integer with an attribute value of Integer syntax. The rule returns
+ True if the attribute value is less than the asserted value. (Source:
+ X.520)
+
+ ( 2.5.13.15 NAME 'integerOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+
+2.8. keywordMatch
+
+ The keywordMatch rule compares the asserted string with keywords in an
+ attribute value of DirectoryString syntax. The rule returns TRUE if
+ and only if the asserted value matches any keyword in the attribute
+ value. The identification of keywords in an attribute value and of
+ the exactness of match are both implementation specific. (Source:
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 5]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ X.520)
+
+ ( 2.5.13.32 NAME 'keywordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+2.9. numericStringOrderingMatch
+
+ NumericStringOrderingMatch compares the collation order of the
+ asserted string with an attribute value of NumericString syntax. The
+ rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule except
+ that all space characters are skipped during comparison (case is
+ irrelevant as characters are numeric). (Source: X.520)
+
+ ( 2.5.13.9 NAME 'numericStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+
+2.10. octetStringOrderingMatch
+
+ OctetStringOrderingMatch compares the collation order of the asserted
+ octet string with an attribute value of OCTET STRING syntax. The rule
+ compares octet strings from first octet to last octet, and from the
+ most significant bit to the least significant bit within the octet.
+ The first occurrence of a different bit determines the ordering of the
+ strings. A zero bit precedes a one bit. If the strings are identical
+ but contain different numbers of octets, the shorter string precedes
+ the longer string. (Source: X.520)
+
+ ( 2.5.13.18 NAME 'octetStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+
+2.11. storedPrefixMatch
+
+ StoredPrefixMatch determines whether an attribute value, whose syntax
+ is DirectoryString, is a prefix (i.e. initial substring) of the
+ asserted value, without regard to the case (upper or lower) of the
+ strings. The rule returns TRUE if and only if the attribute value is
+ an initial substring of the asserted value with corresponding
+ characters identical except possibly with regard to case. (Source:
+ X.520)
+
+ ( 2.5.13.41 NAME 'storedPrefixMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ Note: This rule can be used, for example, to compare values in the
+ Directory which are telephone area codes with a purported value
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 6]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ which is a telephone number.
+
+
+2.12. wordMatch
+
+ The wordMatch rule compares the asserted string with words in an
+ attribute value of DirectoryString syntax. The rule returns TRUE if
+ and only if the asserted word matches any word in the attribute value.
+ Individual word matching is as for the caseIgnoreMatch [RFC2252]
+ matching rule. The precise definition of a "word" is implementation
+ specific. (Source: X.520)
+
+ ( 2.5.13.32 NAME 'wordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+3. Attribute Types
+
+ This section details attribute types for use in LDAP.
+
+
+3.1. associatedDomain
+
+ The associatedDomain attribute type specifies a DNS domain [RFC1034]
+ which is associated with an object. For example, the entry in the DIT
+ with a distinguished name "DC=example,DC=com" might have an associated
+ domain of "example.com". (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+
+3.2. associatedName
+
+ The associatedName attribute type specifies an entry in the
+ organizational DIT associated with a DNS domain [RFC1034]. (Source:
+ RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+
+3.3. buildingName
+
+ The buildingName attribute type specifies the name of the building
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 7]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ where an organization or organizational unit is based. (Source: RFC
+ 1274)
+
+ ( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+3.3. co
+
+ The co (Friendly Country Name) attribute type specifies names of
+ countries in human readable format. It is commonly used in
+ conjunction with the c (Country Name) [RFC2256] attribute type (which
+ restricted to one of the two-letter codes defined in [ISO3166]).
+ (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.43
+ NAME ( 'co' 'friendlyCountryName' )
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+3.5. documentAuthor
+
+ The documentAuthor attribute type specifies the distinguished name of
+ the author of a document. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+
+3.6. documentIdentifier
+
+ The documentIdentifier attribute type specifies a unique identifier
+ for a document. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+3.7. documentLocation
+
+ The documentLocation attribute type specifies the location of the
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 8]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ document original. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+3.8. documentPublisher
+
+ The documentPublisher attribute is the person and/or organization that
+ published a document. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+3.9. documentTitle
+
+ The documentTitle attribute type specifies the title of a document.
+ (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+3.10. documentVersion
+
+ The documentVersion attribute type specifies the version number of a
+ document. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+3.11. drink
+
+ The drink (Favourite Drink) attribute type specifies the favorite
+ drink of an object (or person). (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDrink' )
+ EQUALITY caseIgnoreMatch
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 9]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+3.12. homePhone
+
+ The homePhone (Home Telephone Number) attribute type specifies a home
+ telephone number (e.g., "+44 71 123 4567") associated with a person.
+ (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.20
+ NAME ( 'homePhone' 'homeTelephoneNumber' )
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+
+3.13. homePostalAddress
+
+ The homePostalAddress attribute type specifies a home postal address
+ for an object. This SHOULD be limited to up to 6 lines of 30
+ characters each. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.39
+ NAME 'homePostalAddress'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+
+3.14. host
+
+ The host attribute type specifies a host computer. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.9
+ NAME 'host'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+3.16. info
+
+ The info (Information) attribute type specifies any general
+ information pertinent to an object. It is RECOMMENDED that specific
+ usage of this attribute type is avoided, and that specific
+ requirements are met by other (possibly additional) attribute types.
+ Note that the description attribute type [RFC2256] is available for
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 10]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ specifying descriptive information pertinent to an object. (Source:
+ RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.4
+ NAME 'info'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} )
+
+
+3.17. mail
+
+ The mail (rfc822mailbox) attribute type holds an the electronic mail
+ address in [RFC822] form (e.g.: user@example.com). Note that this
+ attribute SHOULD NOT be used to hold non-Internet addresses. (Source:
+ RFC 1274)
+
+
+ ( 0.9.2342.19200300.100.1.3
+ NAME ( 'mail' 'rfc822Mailbox' )
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
+
+
+3.18. manager
+
+ The Manager attribute type specifies the manager of an object
+ represented by an entry. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.10
+ NAME 'manager'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+
+3.19. mobile
+
+ The mobile (Mobile Telephone Number) attribute type specifies a mobile
+ telephone number (e.g., "+44 71 123 4567") associated with a person.
+ (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.41
+ NAME ( 'mobile' 'mobileTelephoneNumber' )
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 11]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+3.20. organizationalStatus
+
+ The organizationalStatus attribute type specifies a category by which
+ a person is often referred to in an organization. Examples of usage
+ in academia might include undergraduate student, researcher, lecturer,
+ etc.
+
+ A Directory administrator SHOULD consider carefully the distinctions
+ between this and the title and userClass attributes. (Source: RFC
+ 1274)
+
+ ( 0.9.2342.19200300.100.1.45
+ NAME 'organizationalStatus'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+3.21. otherMailbox
+
+ The otherMailbox attribute type specifies values for electronic
+ mailbox types other than X.400 and RFC822. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.22
+ NAME 'otherMailbox'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 )
+
+
+3.22. pager
+
+ The pager (Pager Telephone Number) attribute type specifies a pager
+ telephone number (e.g., "+44 71 123 4567") for an object. (Source:
+ RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.42
+ NAME ( 'pager' 'pagerTelephoneNumber' )
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+
+3.23. personalTitle
+
+ The personalTitle attribute type specifies a personal title for a
+ person. Examples of personal titles are "Frau", "Dr", "Herr", and
+ "Prof". (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.40
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 12]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ NAME 'personalTitle'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+3.24. roomNumber
+
+ The roomNumber attribute type specifies the room number of an object.
+ Note that the cn (commonName) attribute type SHOULD be used for naming
+ room objects. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.6
+ NAME 'roomNumber'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+3.25. secretary
+
+ The secretary attribute type specifies the secretary of a person. The
+ attribute value for Secretary is a distinguished name. (Source: RFC
+ 1274)
+
+ ( 0.9.2342.19200300.100.1.21
+ NAME 'secretary'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+
+3.26. uid
+
+ The uid (userid) attribute type specifies a computer system login
+ name. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.1
+ NAME ( 'uid' 'userid' )
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+3.27. uniqueIdentifier
+
+ The Unique Identifier attribute type specifies a "unique identifier"
+ for an object represented in the Directory. The domain within which
+ the identifier is unique, and the exact semantics of the identifier,
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 13]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ are for local definition. For a person, this might be an institution-
+ wide payroll number. For an organizational unit, it might be a
+ department code. An attribute value for uniqueIdentifier is a
+ directoryString. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ Note: X.520 describes an attribute also called 'uniqueIdentifier'
+ (2.5.4.45) which is called 'x500UniqueIdentifier' in LDAP
+ [RFC2256]. The attribute detailed here ought not be confused
+ with x500UniqueIdentifier.
+
+
+3.28. userClass
+
+ The userClass attribute type specifies a category of computer user.
+ The semantics placed on this attribute are for local interpretation.
+ Examples of current usage od this attribute in academia are
+ undergraduate student, researcher, lecturer, etc. Note that the
+ organizationalStatus attribute type is now often be preferred as it
+ makes no distinction between computer users and others. (Source: RFC
+ 1274)
+
+ ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+4. Object Classes
+
+ This section details object classes for use in LDAP.
+
+
+4.1. account
+
+ The account object class is used to define entries representing
+ computer accounts. The uid (userid) attribute SHOULD be used for
+ naming entries of this object class. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.4.5
+ NAME 'account'
+ SUP top STRUCTURAL
+ MUST uid
+ MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 14]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+4.2. document
+
+ The document object class is used to define entries which represent
+ documents. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.4.6
+ NAME 'document'
+ SUP top STRUCTURAL
+ MUST documentIdentifier
+ MAY ( cn $ description $ seeAlso $ l $ o $ ou $
+ documentTitle $ documentVersion $ documentAuthor $
+ documentLocation $ documentPublisher ) )
+
+
+4.3. documentSeries
+
+ The documentSeries object class is used to define an entry which
+ represents a series of documents (e.g., The Request For Comments
+ memos). (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.4.9
+ NAME 'documentSeries'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( description $ l $ o $ ou $ seeAlso $
+ telephonenumber ) )
+
+
+4.4. domainRelatedObject
+
+ The domainRelatedObject object class is used to define entries which
+ represent DNS domains which are "equivalent" to an X.500 domain: e.g.,
+ an organization or organizational unit. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.4.17
+ NAME 'domainRelatedObject'
+ SUP top AUXILIARY
+ MUST associatedDomain )
+
+
+4.5. friendlyCountry
+
+ The friendlyCountry object class is used to define country entries in
+ the DIT. The object class is used to allow friendlier naming of
+ countries than that allowed by the object class country [RFC2256].
+ (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.4.18
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 15]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ NAME 'friendlyCountry'
+ SUP country STRUCTURAL
+ MUST co )
+
+
+4.6. rFC822LocalPart
+
+ The rFC822LocalPart object class is used to define entries which
+ represent the local part of [RFC822] mail addresses. This treats this
+ part of an RFC 822 address as a domain [RFC2247]. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.4.14
+ NAME 'rFC822localPart'
+ SUP domain STRUCTURAL
+ MAY ( cn $ description $ destinationIndicator $
+ facsimileTelephoneNumber $ internationaliSDNNumber $
+ physicalDeliveryOfficeName $ postalAddress $
+ postalCode $ postOfficeBox $ preferredDeliveryMethod $
+ registeredAddress $ seeAlso $ sn $ street $
+ telephoneNumber $ teletexTerminalIdentifier $
+ telexNumber $ x121Address ) )
+
+
+4.7. room
+
+ The room object class is used to define entries representing rooms.
+ The cn (commonName) attribute SHOULD be used for naming entries of
+ this object class. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.4.7 NAME 'room'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( roomNumber $ description $
+ seeAlso $ telephoneNumber ) )
+
+
+4.8. simpleSecurityObject
+
+ The simpleSecurityObject object class is used to require an entry to
+ have a userPassword attribute when the entry's structural object class
+ does not require (or allow) the userPassword attribute. (Source: RFC
+ 1274)
+
+
+ ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
+ SUP top AUXILIARY
+ MUST userPassword )
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 16]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ Note: Security considerations related to the use of simple
+ authentication mechanisms in LDAP are discussed in RFC 2829
+ [RFC2829].
+
+
+5. Security Considerations
+
+ General LDAP security considerations [LDAPTS] is applicable to the use
+ of this schema. Additional considerations are noted above where
+ appropriate.
+
+
+6. IANA Considerations
+
+ It is requested that IANA update the LDAP descriptors registry as
+ indicated the following template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: see comment
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors should be added:
+
+ NAME Type OID
+ ------------------------ ---- ---------
+ booleanMatch M 2.5.13.13
+ caseExactMatch M 2.5.13.5
+ caseExactOrderingMatch M 2.5.13.6
+ caseExactSubstringsMatch M 2.5.13.7
+ caseIgnoreListSubstringsMatch M 2.5.13.12
+ directoryStringFirstComponentMatch M 2.5.13.31
+ integerOrderingMatch M 2.5.13.15
+ keywordMatch M 2.5.13.32
+ numericStringOrderingMatch M 2.5.13.9
+ octetStringOrderingMatch M 2.5.13.18
+ storedPrefixMatch M 2.5.13.41
+ wordMatch M 2.5.13.32
+
+ The following descriptors should be updated to refer to RFC XXXX.
+
+ NAME Type OID
+ ------------------------ ---- --------------------------
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 17]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ account O 0.9.2342.19200300.100.4.5
+ associatedDomain A 0.9.2342.19200300.100.1.37
+ associatedName A 0.9.2342.19200300.100.1.38
+ buildingName A 0.9.2342.19200300.100.1.48
+ co A 0.9.2342.19200300.100.1.43
+ document O 0.9.2342.19200300.100.4.6
+ documentAuthor A 0.9.2342.19200300.100.1.14
+ documentIdentifier A 0.9.2342.19200300.100.1.11
+ documentLocation A 0.9.2342.19200300.100.1.15
+ documentPublisher A 0.9.2342.19200300.100.1.56
+ documentSeries O 0.9.2342.19200300.100.4.8
+ documentTitle A 0.9.2342.19200300.100.1.12
+ documentVersion A 0.9.2342.19200300.100.1.13
+ domainRelatedObject O 0.9.2342.19200300.100.4.17
+ drink A 0.9.2342.19200300.100.1.5
+ favouriteDrink A 0.9.2342.19200300.100.1.5
+ friendlyCountry O 0.9.2342.19200300.100.4.18
+ friendlyCountryName A 0.9.2342.19200300.100.1.43
+ homePhone A 0.9.2342.19200300.100.1.20
+ homePostalAddress A 0.9.2342.19200300.100.1.39
+ homeTelephone A 0.9.2342.19200300.100.1.20
+ host A 0.9.2342.19200300.100.1.9
+ info A 0.9.2342.19200300.100.1.4
+ mail A 0.9.2342.19200300.100.1.3
+ manager A 0.9.2342.19200300.100.1.10
+ mobile A 0.9.2342.19200300.100.1.41
+ mobileTelephoneNumber A 0.9.2342.19200300.100.1.41
+ organizationalStatus A 0.9.2342.19200300.100.1.45
+ otherMailbox A 0.9.2342.19200300.100.1.22
+ pager A 0.9.2342.19200300.100.1.42
+ pagerTelephoneNumber A 0.9.2342.19200300.100.1.42
+ personalTitle A 0.9.2342.19200300.100.1.40
+ RFC822LocalPart O 0.9.2342.19200300.100.4.14
+ RFC822Mailbox A 0.9.2342.19200300.100.1.3
+ room O 0.9.2342.19200300.100.4.7
+ roomNumber A 0.9.2342.19200300.100.1.6
+ secretary A 0.9.2342.19200300.100.1.21
+ simpleSecurityObject O 0.9.2342.19200300.100.4.19
+ singleLevelQuality A 0.9.2342.19200300.100.1.50
+ uid A 0.9.2342.19200300.100.1.1
+ uniqueIdentifier A 0.9.2342.19200300.100.1.44
+ userClass A 0.9.2342.19200300.100.1.8
+ userId A 0.9.2342.19200300.100.1.1
+
+ where Type A is Attribute, Type O is ObjectClass, and Type M
+ is Matching Rule.
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 18]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ This document make no OID assignments, it only associates LDAP schema
+ descriptions with existing elements of X.500 schema.
+
+
+7. Acknowledgments
+
+ This document borrows from a number of IETF documents including RFC
+ 1274 by Paul Barker and Steve Kille. This document also borrows from
+ a number of ITU documents including X.520.
+
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+9. Normative References
+
+ [RFC822] D. Crocker, "Standard for the format of ARPA Internet text
+ messages", STD 11 (also RFC 822), August 1982.
+
+ [RFC1034] P.V. Mockapetris, "Domain names - concepts and facilities",
+ STD 13 (also RFC 1034), November 1987.
+
+ [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2247] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri,
+ "Using Domains in LDAP/X.500 Distinguished Names", January
+ 1998.
+
+ [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.
+
+ [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol
+ (v3): Technical Specification", draft-ietf-ldapbis-
+ ldapv3-ts-00.txt.
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 19]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+10. Informative References
+
+ [ISO3166] International Standards Organization, "Codes for the
+ representation of names of countries", ISO 3166.
+
+ [RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema",
+ November 1991.
+
+ [RFC2798] M. Smith, "The LDAP inetOrgPerson Object Class", RFC 2798,
+ April 2000.
+
+ [X.520] International Telephone Union, "The Directory: Selected
+ Attribute Types", X.520, 1997.
+
+
+Full Copyright
+
+ 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-user-schema-06 [Page 20]
+\f
projects / openldap / commitdiff