+++ /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 R. Megginson, Editor
-Document: <draft-ietf-ldup-lcup-03.txt> M. Smith
-Category: Proposed Standard Netscape
- Communications Corp.
- O. Natkovich
- Yahoo
- J. Parham
- Microsoft Corporation
- June 2002
-
-
- LDAP Client Update Protocol
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026 [1].
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other documents
- at any time. It is inappropriate to use Internet- Drafts as
- reference material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
- Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-1. Abstract
-
- This document defines the LDAP Client Update Protocol (LCUP). The
- protocol is intended to allow an LDAP client to synchronize with the
- content of a directory information tree (DIT) stored by an LDAP
- server and to be notified about the changes to that content.
-
-
-2. Conventions used in this document
-
- In the protocol flow definition, the notation C->S and S->C
- specifies the direction of the data flow from the client to the
- server and from the server to the client respectively.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
- this document are to be interpreted as described in RFC-2119
- [KEYWORDS].
-
-
-3. Overview
-
-\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 IETF is
- developing a LDAP replication protocol, called [LDUP], which is
- specifically designed to address this problem area.
-
- There are currently several protocols in use for LDAP client server
- synchronization. While each protocol addresses the needs of a
- particular group of clients (e.g., on-line clients or off-line
- clients) none satisfies the requirements of all clients in the
- target group. For instance, a mobile client that was off-line and
- wants to become up to date with the server and stay up to date while
- connected can't be easily supported by any of the existing
- protocols.
-
- Several features of the protocol distinguish it from LDUP
- replication. LCUP is designed such that the server does not need to
- maintain state information on behalf of the client. The clients are
- responsible for storing the information about how up to date they
- are with respect to the server's content. LCUP design avoids the
- need for LCUP-specific update agreements to be made between client
- and server prior to LCUP use. The client decides when and from where
- to retrieve the changes. LCUP design requires clients to initiate
- the update session and "pull" the changes from server.
-
- LCUP operations are subject to administrative and access
- control policies enforced by the server.
-
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 2
-\f
-
-
- A part of the DIT which is enabled for LCUP is referred to as an
- LCUP Context. A server may support one or more LCUP Contexts.
-
-4. Protocol Specification
-
- This section describes the protocol elements and the protocol flow.
-
-4.1 Universally Unique Identifiers
-
- Distinguished names can change, so are therefore unreliable
- as identifiers. The server SHOULD assign a Universally Unique
- Identifier (or UUID for short) to each entry as it is created. This
- identifier will be stored as an operational attribute of the entry,
- named `entryUUID'. The entryUUID attribute is single valued. A
- consistent algorithm for generating such universally unique
- identifiers may be standardized at some point in the future.
- The definition of the entryUUID attribute type, written using the
- BNF form of AttributeDescription described in RFC 2252 [RFC2252] is:
-
- ( OID-To-Be-Specified
- NAME `entryUUID'
- DESC `universally unique entry identifier'
- EQUALITY caseIgnoreMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
- SINGLE-VALUE
- NO-USER-MODIFICATION
- USAGE directoryOperation )
-
-4.2 LCUP Cookie Value
-
- The LCUP protocol uses a cookie to hold the state of the client's
- data with respect to the server's data. The LCUP Cookie is a value
- of the following ASN.1 type:
-
- LCUPCookie ::= SEQUENCE {
- scheme LDAPOID,
- value OCTET STRING OPTIONAL
- }
-
- scheme - this is the OID which identifies the format of the value.
- The scheme OID, like all object identifiers, MUST be unique for a
- given cookie scheme. The cookie value may be opaque or it may be
- exposed to LCUP clients. For cookie schemes that expose their
- value, the preferred form of documentation is an RFC. It is
- expected that there will be one or more standards track cookie
- schemes where the value format is exposed and described in detail.
-
- value - this is the actual data describing the state of the
- client's data. This value may be opaque, or its value may have
- some well-known format, depending on the scheme. The cookie value
- MUST be included except when a client has no stored state; i.e.,
- when the client is requesting a full synchronization. When the
- server sends back a cookie, the cookie value MUST be present.
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 3
-\f
-
-
- Further uses of the LCUP Cookie value are described below.
-
-4.3 Additional LDAP Result Codes defined by LCUP
-
- The LDAP result code names and numbers defined in the following
- table are to be replaced with IANA assigned result code names and
- numbers per draft-ietf-ldapbis-iana-xx.txt.
-
- lcupResourcesExhausted (TBD) the server is running out of
- resources
- lcupSecurityViolation (TBD) the client is suspected of malicious
- actions
- lcupInvalidCookie (TBD) invalid cookie was supplied by the
- client - both/either the scheme
- and/or the value part was invalid
- lcupUnsupportedScheme (TBD) The scheme part of the cookie is a
- valid OID but is not supported by
- this server
- lcupClientDisconnect (TBD) client requested search termination
- using the LDAP Cancel extended
- operation request [CANCEL]
- lcupReloadRequired (TBD) indicates that client data needs to
- be reinitialized. This reason is
- returned if the server does not
- contain sufficient information to
- synchronize the client or if the
- server's data was reloaded since the
- last synchronization session
-
- The uses of these codes are described below.
-
-4.4 Client Update Control Value
-
- A client initiates a synchronization session with a server by
- attaching a clientUpdate control to an LDAP searchRequest message.
- The client SHOULD specify entryUUID in the attributes list in the
- searchRequest message. The search specification determines the part
- of the directory information tree (DIT) the client wishes to
- synchronize with, the set of attributes it is interested in and the
- amount of data the client is willing to receive. The clientUpdate
- control contains the client's synchronization specification. The
- controlType field for the clientUpdate control is
- ClientUpdateControlOID (to be assigned). The controlValue is an
- OCTET STRING, whose contents are the bytes of the BER encoding of
- the following:
-
-
-
-
-
-
-
-
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 4
-\f
-
-
- ClientUpdateControlValue ::= SEQUENCE {
- updateType ENUMERATED {
- synchronizeOnly (0),
- synchronizeAndPersist (1),
- persistOnly (2) },
- sendCookieInterval INTEGER OPTIONAL,
- cookie LCUPCookie OPTIONAL
- }
-
- updateType - specifies the type of update requested by the client
-
- synchronizeOnly - the server sends all the data needed to
- synchronize the client with the server, then closes the
- connection
-
- synchronizeAndPersist - the server sends all the data needed to
- synchronize the client with the server, then leaves open the
- connection, sending to the client any new added, modified, or
- deleted entries that satisfy the search criteria.
-
- persistOnly - the server does not synchronize the data with the
- client but leaves open the connection and sends over any new
- added, modified, or deleted entries that satisfy the search
- criteria.
-
- sendCookieInterval û (optional) the server SHOULD send the cookie
- back in the entryUpdate control value for every
- sendCookieInterval number of SearchResultEntry PDUs returned to
- the client. For example, if the value is 5, the server SHOULD
- send the cookie back in the entryUpdate control value for every 5
- search results returned to the client. If this value is absent,
- zero or less than zero, the server chooses the interval.
-
- cookie - a value that represents the current state of the client's
- data. If a cookie is provided, the server MUST use the enclosed
- scheme throughout the duration of the LCUP session or until an
- LCUP context boundary is crossed, since a new cookie may be
- required in that case. If the value or scheme part of the cookie
- is invalid, the server MUST return immediately with a
- SearchResultDone message with the resultCode set to the value of
- lcupInvalidCookie. If the scheme part of the cookie is a valid
- OID, but is not supported, the server MUST return immediately
- with a SearchResultDone message with the resultCode set to the
- value of lcupUnsupportedScheme.
-
- If the cookie is omitted, the server MAY use any scheme it
- supports.
-
-4.5 Entry Update Control Value
-
- In response to the client's synchronization request, the server
- returns one or more SearchResultEntry PDU that fits the client's
- specification. Each SearchResultEntry PDU also contains an
- entryUpdateControl that describes the LCUP state of the returned
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 5
-\f
-
-
- entry. To represent a deleted entry, the server attaches an
- entryUpdate control to the corresponding SearchResultEntry. The
- SearchResultEntry corresponding to a deleted entry MUST contain a
- valid DN and SHOULD contain a valid UUID but, to reduce the amount
- of data sent to the client, it SHOULD not contain any other
- attributes.
-
- Furthermore, the server may elect to periodically return to the
- client the cookie that represents the state of the client's data.
- This information is useful in case the client crashes or gets
- disconnected. The client MAY specify how often to receive the cookie
- by the use of the sendCookieInterval in the clientUpdate control
- value (see above). If the client does not specify a value, the
- server will determine the interval.
-
- The controlType field for the entryUpdate control is
- EntryUpdateControlOID (to be assigned). The controlValue is an
- OCTET STRING, whose contents are the bytes of the BER encoding of
- the following:
-
- EntryUpdateControlValue ::= SEQUENCE {
- stateUpdate BOOLEAN,
- entryDeleted BOOLEAN,
- cookie LCUPCookie OPTIONAL
-
- }
-
- stateUpdate - if set to TRUE, indicates that the entry to which the
- control is attached contains no changes and it is sent only to
- communicate to the client the new cookie. In this case, the
- entryDeleted field MUST be ignored and the cookie field MUST
- contain the updated cookie. This feature allows updating the
- client's cookie when there are no changes that effect the
- client's data store. Note that the control MUST be attached to a
- valid SearchResultEntry, which should contain a valid LDAPDN in
- the objectName field, and MAY contain an entryUUID attribute, but
- SHOULD NOT contain any other attributes. The server MAY send the
- entry named by the baseObject from the client's search request.
-
- entryDeleted - if set to TRUE, indicates that the entry to which
- the control is attached was deleted. The server MAY also set
- this to TRUE if the entry has left the client's search result
- set. As far as the client is concerned, a deleted entry is no
- different than an entry that has left the result set.
-
- cookie - the LCUP cookie value that represents the current state of
- the client's data.
-
-4.6 Client Update Done Control Value
-
- When the server has finished processing the client's request, it
- attaches a clientUpdateDone control to the SearchResultDone message
- and sends it to the client. However, if the SearchResultDone message
- contains a resultCode that is not success or lcupClientDisconnect,
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 6
-\f
-
-
- the clientUpdateDone control MAY be omitted. The controlType field
- for the clientUpdateDone control is ClientUpdateDoneControlOID (to
- be assigned). The controlValue is an OCTET STRING, whose contents
- are the bytes of the BER encoding of the following:
-
- ClientUpdateDoneControlValue ::= SEQUENCE {
- cookie LCUPCookie OPTIONAL
- }
-
- cookie - the LCUP cookie value that represents the current state of
- the client's data. Although this value is OPTIONAL, it MUST be set
- in the ClientUpdateDoneControlValue if the SearchResultDone
- resultCode is success or lcupClientDisconnect. This provides a
- good "checksum" of what the server thinks the state of the client
- is. If some error occurred, either an LDAP search error (e.g.
- insufficientAccessRights) or an LCUP error (e.g.
- lcupUnsupportedScheme), the cookie MAY be omitted.
-
- If server resources become tight, the server can terminate one or
- more search operations by sending a SearchResultDone message to the
- client(s) with a resultCode of lcupResourcesExhausted. Unless the
- client sets the updateType field to persistOnly, the server attaches
- a clientUpdateDone control that contains the cookie that corresponds
- to the current state of the client's data. A server set policy is
- used to decide which searches to terminate. This can also be used as
- a security mechanism to disconnect clients that are suspected of
- malicious actions, but if the server can infer that the client is
- malicious, the server should return lcupSecurityViolation instead.
-
-4.7 Client Initiated Termination
-
- If the client needs to terminate the synchronization process and it
- wishes to obtain the cookie that represents the current state of its
- data, it issues an LDAP Cancel operation [CANCEL]. The server
- responds immediately with a LDAP Cancel response [CANCEL]. The
- server MAY send any pending SearchResultEntry PDUs if the server
- cannot easily abort or remove those search results from its outgoing
- queue. The server SHOULD send as few of these remaining
- SearchResultEntry PDUs as possible. Finally, the server sends the
- message SearchResultDone with the clientUpdateDone control attached.
-
- If the client is not interested in the state information, it can
- simply abandon the search operation or disconnect from the server.
-
-4.8 Protocol Flow
-
- The client server interaction can proceed in three different ways
- depending on the client's requirements. Protocol flows beginning
- with an asterisk (*) are optional or conditional.
-
- If the client's intent is not to synchronize data but to trigger
- actions in response to directory modifications, the protocol
- proceeds as follows:
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 7
-\f
-
-
- C->S Sends a search operation with a clientUpdate control attached.
- The search specification determines the part of the DIT the
- client wishes to synchronize with and the set of attributes it
- is interested in. The updateType field of the control value
- should be set to persistOnly.
- *S->C If there is an error (invalid search scope, invalid cookie)
- the server returns the appropriate error codes and terminates
- the request (SearchResultDone message with optional
- clientUpdateDone control)
- S->C Sends change notification to the client for each change to the
- data within the client's search specification. Each
- SearchResultEntry may have an entryUpdate control attached.
- *S->C If the server starts to run out of resources or the client is
- suspected of malicious actions, the server SHOULD terminate
- the search operation by sending to the client a
- SearchResultDone message with optional clientUpdateDone
- control attached. The resultCode in the SearchResultDone
- mesasge SHOULD be set to lcupResourcesExhausted or
- lcupSecurityViolation depending on the reason for termination.
- *C->S If the client receives lcupResourcesExhausted error from the
- server, it MUST wait for a while before attempting another
- synchronization session with the server. It is RECOMMENDED
- that clients use an exponential backoff strategy.
- C->S The client terminates the search. The client can do this by
- abandoning the search operation, disconnecting from the
- server, or by sending an LDAP Cancel operation.
- *S->C If the server receives the LDAP Cancel op, it will immediately
- send back the LDAP Cancel response
- *S->C If the server sent the LDAP Cancel response, the server MAY
- send any pending SearchResultEntry PDUs in its outgoing queue
- *S->C If the server sent the LDAP Cancel response, after the server
- sends the response and any pending SearchResultEntry PDUs, the
- server sends the SearchResultDone message with the
- clientUpdateDone control attached. The resultCode in the
- SearchResultDone message will be either lcupClientDisconnect
- or some LDAP error code (not success).
- S->C Stops sending changes to the client and closes the connection.
-
- If the client's intent is to synchronize with the server and then
- disconnect, the protocol proceeds as follows:
-
- C->S Sends a search operation with the clientUpdate control
- attached. The search specification determines the part of the
- DIT the client wishes to synchronize with, the set of
- attributes it is interested in and the amount of data the
- client is willing to receive. If this is the initial
- synchronization session, the client either does not provide a
- cookie or provides a cookie with no value; otherwise, the
- cookie field of the control is set to the cookie received from
- the server at the end of the last synchronization session. If
- the scheme field of the cookie was provided, the server MUST
- use that scheme throughout the duration of the LCUP session or
- until an LCUP boundary is crossed, since the server will
- usually require a different cookie in that case anyway. (Note
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 8
-\f
-
-
- that the client can synchronize with different servers during
- different synchronization sessions.) The updateType field of
- the control value is set to synchronizeOnly.
- *S->C If there is an error (invalid search scope, invalid cookie)
- the server returns the appropriate error codes and terminates
- the request (SearchResultDone message with optional
- clientUpdateDone control)
- *S->C If no cookie is specified in the clientUpdate control, or if
- the value field of the cookie is empty, the server sends all
- data that matches the client's search specification followed
- by the SearchResultDone message with a clientUpdateDone
- control attached. The control contains the cookie that
- corresponds to the current state of the client's data. If
- synchronization was successful, the resultCode in the
- SearchResultDone message should be success.
- *S->C If an invalid cookie is specified, the server sends the
- SearchResultDone message with the resultCode set to
- lcupInvalidCookie.
- *S->C If a valid cookie is specified and the data that matches the
- search specification has been reloaded or the server does not
- contain enough state information to synchronize the client,
- the server sends a SearchResultDone message with the
- resultCode set to lcupReloadRequired.
- *S->C If the cookie is valid and the client is up to date, the
- server sends a success response to the client.
- S->C If the cookie is valid and there is data to be sent, the
- server sends the modified entries to the client. Each
- SearchResultEntry contains the attributes requested by the
- client in the search specification regardless of whether they
- were modified. An entryUpdate control with the entryDeleted
- field set to TRUE MUST be attached to every deleted entry. The
- server may also periodically attach an entryUpdate control to
- the entries sent to the client to indicate the current state
- of the client's data. In that case, the cookie field of the
- control represents the state of the client's data including
- the entry to which the control is attached. Once all the
- changes are sent successfully, the server sends a
- SearchResultDone with the clientUpdateDone control attached.
- The control contains the cookie that represents the current
- state of the client's data. The resultCode in the
- SearchResultDone message is set to success. If the resultCode
- is not success, the server may OPTIONALLY attach the
- clientUpdateDone control to the SearchResultDone message.
- The client stores the cookie received from the server until
- the next synchronization session.
- *C->S If the resultCode in the SearchResultDone message is set
- lcupReloadRequired, the client clears its data store and
- repeats the synchronization process by sending the search
- operation with clientUpdate control that contains no cookie,
- or that contains a cookie with no value field.
-
- If the client's intent is to be synchronized with the server and
- stay notified about data modifications, the protocol proceeds as
- follows:
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 9
-\f
-
-
-
- C->S The client behaves exactly as in the previous case except it
- sets the updateType field in the control value to
- synchronizeAndPersist.
- S->C The server behaves exactly as in the previous case except the
- connection is kept open after the initial set of changes is
- sent to the client. A SearchResultDone message is not sent to
- the client; instead, the server keeps sending changes to the
- client.
- *S->C If the server starts to run out of resources or the client is
- suspected of malicious actions, the server SHOULD terminate
- the search operation by sending to the client a
- SearchResultDone message with the resultCode set to
- lcupResourcesExhausted or lcupSecurityViolation depending on
- the reason for termination.
- *C->S If the client receives lcupResourcesExhausted error from the
- server, it MUST wait for a while before attempting another
- synchronization session with the server. We recommend
- exponential backoff strategy.
- C->S Sends an LDAP Cancel operation to the server to terminate the
- synchronization session.
- S->C Responds with an LDAP Cancel response, followed optionally by
- SearchResultEntry PDUs, followed by a SearchResultDone with
- the clientUpdateDone control optionally attached. If the
- control is present, it contains the cookie that represents the
- current state of the client's data. The value of the
- resultCode in the SearchResultDone message will be either
- lcupClientDisconnect or some other LDAPResult resultCode (not
- success). The control may not be present if some error
- occurred.
-
-4.9 Size and Time Limits
-
- The search request size or the time limits can only be imposed for
- non-persistent operations, those that set the updateType field of
- the ClientUpdateControlValue to synchronizeOnly (for the entire
- operation) or synchronizeAndPersist (for the initial synchronization
- phase only). All other operations MUST set both limits to 0. The
- server SHOULD ignore the limits set for persistent operations.
-
-4.10 Changes vs. Operations
-
- A server that supports UUIDs SHOULD communicate a modifyDN
- operation by sending the client the current form of the entry (with
- its new DN) along with an entryUUID attribute. A server that does
- not support UUIDs SHOULD communicate a modifyDN operation by sending
- the client a deletion for the previous DN followed by an entry for
- the new DN. Note that for servers that do not support UUIDs, no
- guarantees are made about the correctness of the client state in the
- presence of modifyDN operations.
-
- Communicating modifyDN operations by sending a delete of the old DN
- followed by an entry with the new DN makes it impossible for an LCUP
- client to distinguish between a modifyDN operation, which is one
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 10
-\f
-
-
- atomic operation, and an delete operation followed by an add of a
- new entry. The loss of information about atomicity may cause
- problems for some LCUP clients. For example, when an entry is
- renamed, a client that manages resources such as a person's mailbox
- might delete the mailbox and everything in it instead of merely
- changing the name associated with the mailbox.
-
- Also note that regardless of how a modifyDN operation is
- communicated to the client, if the client state shows that the
- object that underwent the modifyDN operation was the root of a
- subtree, the client MUST infer that the DNs of all objects in the
- subtree have changed such that they reflect the new DN of the
- subtree root.
-
-4.11 Operations on the Same Connection
-
- It is permissible for the client to issue other LDAP operations on
- the connection used by the protocol. Since each LDAP
- request/response carries a message id there will be no ambiguity
- about which PDU belongs to which operation. By sharing the
- connection among multiple operations, the server will be able to
- conserve its resources.
-
-4.12 Interactions with Other LDAP Search and Response Controls
-
- LCUP defines neither restrictions nor guarantees about the ability
- to use the LDAP client update control defined in this document in
- conjunction with other LDAP controls, except for the following: A
- server MAY ignore non-critical controls supplied with the LCUP
- control. A server MAY ignore the LCUP control if it is non-critical
- and it is supplied with other critical controls. If a server
- receives a critical LCUP control with another critical control, and
- the server does not support both controls at the same time, the
- server SHOULD return unavailableCriticalExtension.
-
-5. Additional Features
-
- There are several features present in other protocols or considered
- useful by clients that are currently not included in the protocol
- primarily because they are difficult to implement on the server.
- These features are briefly discussed in this section. This section
- is intended to open a discussion on the merits of including and
- approaches to implementing these features.
-
-5.1 Triggered Search Change Type
-
- This feature is present in the Triggered Search specification. A
- flag is attached to each entry returned to the client indicating the
- reason why this entry is returned. The possible reasons from the
- draft are
- "- notChange: the entry existed in the directory and matched the
- search at the time the operation is being performed,
- - enteredSet: the entry entered the result,
- - leftSet: the entry left the result,
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 11
-\f
-
-
- - modified: the entry was part of the result set, was modified or
- renamed, and still is in the result set."
-
- The leftSet feature is particularly useful because it indicates to
- the client that an entry is no longer within the client's search
- specification and the client can remove the associated data from its
- data store. Ironically, this feature is the hardest to implement on
- the server because the server does not keep track of the client's
- state and has no easy way of telling which entries moved out of
- scope between synchronization sessions with the client.
-
- A compromise could be reached by only providing this feature for the
- operations that occur while the client is connected to the server.
- This is easier to accomplish because the decision about the change
- type can be made based only on the change without need for any
- historical information. This, however, would add complexity to the
- protocol.
-
-5.2 Persistent Search Change Type
-
- This feature is present in the Persistent Search specification.
- Persistent search has the notion of changeTypes. The client
- specifies which type of updates will cause entries to be returned,
- and optionally whether the server tags each returned entry with the
- type of change that caused that entry to be returned.
-
- For LCUP, the intention is full synchronization, not partial. Each
- entry returned by an LCUP search will have some change associated
- with it that may concern the client. The client may have to have a
- local index of entries by DN or UUID to determine if the entry has
- been added or just modified. It is easy for clients to determine if
- the entry has been deleted because the entryDeleted value of the
- entryUpdateControl will be TRUE.
-
-5.3 Sending Changes
-
- Some earlier synchronization protocols sent the client(s) only the
- modified attributes of the entry rather than the entire entry. While
- this approach can significantly reduce the amount of data returned
- to the client, it has several disadvantages. First, unless a
- separate mechanism (like the change type described above) is used to
- notify the client about entries moving into the search scope,
- sending only the changes can result in the client having an
- incomplete version of the data. Let's consider an example. An
- attribute of an entry is modified. As a result of the change, the
- entry enters the scope of the client's search. If only the changes
- are sent, the client would never see the initial data of the entry.
- Second, this feature is hard to implement since the server might not
- contain sufficient information to construct the changes based solely
- on the server's state and the client's cookie. On the other hand,
- this feature can be easily implemented by the client assuming that
- the client has the previous version of the data and can perform
- value by value comparisons.
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 12
-\f
-
-
-5.4 Data Size Limits
-
- Some earlier synchronization protocols allowed clients to control
- the amount of data sent to them in the search response. This feature
- was intended to allow clients with limited resources to process
- synchronization data in batches. However, an LDAP search operation
- already provides the means for the client to specify the size limit
- by setting the sizeLimit field in the SearchRequest to the maximum
- number of entries the client is willing to receive. While the
- granularity is not the same, the assumption is that regular LDAP
- clients that can deal with the limitations of the LDAP protocol will
- implement LCUP.
-
-5.5 Data Ordering
-
- Some earlier synchronization protocols allowed a client to specify
- that parent entries should be sent before the children for add
- operations and children entries sent before their parents during
- delete operations. This ordering helps clients to maintain a
- hierarchical view of the data in their data store. While possibly
- useful, this feature is relatively hard to implement and is
- expensive to perform.
-
-6. Client Side Considerations
-
- Clients SHOULD always specify entryUUID in the SearchRequest
- attribute list.
-
- The cookie received from the server after a synchronization session
- can only be used with the same or more restrictive search
- specification than the search that generated the cookie. The server
- will reject the search operation with a cookie that does not satisfy
- this condition. This is because the client can end up with an
- incomplete data store otherwise. A more restrictive search
- specification is the one that generates a subset of the data
- produced by the original search specification.
-
- Because an LCUP client specifies the area of the tree with which it
- wishes to synchronize through the standard LDAP search
- specification, the client can be returned noSuchObject error if the
- root of the synchronization area was renamed between the
- synchronization sessions or during a synchronization session. If
- this condition occurs, the client can attempt to locate the root by
- using the root's UUID saved in client's local data store. It then
- can repeat the synchronization request using the new search base. In
- general, a client can detect that an entry was renamed and apply the
- changes received to the right entry by using the UUID rather than DN
- based addressing.
-
- Each active persistent operation requires that an open TCP
- connection be maintained between an LDAP client and an LDAP server
- that might not otherwise be kept open. Therefore, client
- implementors are encouraged to avoid using persistent operations for
- non-essential tasks and to close idle LDAP connections as soon as
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 13
-\f
-
-
- practical. The server may close connections if server resources
- become tight.
-
- The client MAY receive a continuation reference
- (SearchResultReference [RFC2251 SECTION 4.5.3]) if the search
- request spans multiple parts of the DIT, some of which may require a
- different LCUP cookie, some of which may not even be managed by
- LCUP. The client SHOULD maintain a cache of the LDAP URLs returned
- in the continuation references and the cookies associated with them.
- The client is responsible for performing another LCUP search to
- follow the references, and SHOULD use the cookie corresponding to
- the LDAP URL for that reference (if it has a cookie).
-
- The client may receive a referral (Referral [RFC2251 SECTION
- 4.1.11]) when the search base is a subordinate reference, and this
- will end the operation.
-
- For alias dereferencing, the server will behave as if the client had
- requested neverDerefAliases or derefFindingBaseObj as the
- derefAliases field in the search request [RFC2251, Section 4.5.1].
- If the client specifies a value other than neverDerefAliases or
- derefFindingBaseObj, the server will return protocolError to the
- client.
-
- Changes to data (e.g., that might affect the LCUP client's filter or
- scope) or meta-data (e.g., that might affect the client's read
- access) may affect the presence of entries in the search set.
- Servers MAY notify LCUP clients of changes to the search set that
- result from such changes, but an LCUP client MUST NOT assume that
- such notification will occur. Therefore, in the case where a client
- is maintaining a cache of entries using LCUP, the data held by the
- client may be a superset or a subset of the entries that would be
- returned by a new search request. For example, if access control
- meta information is changed to deny access to particular entries in
- the search result set, and the access control information is outside
- of the search scope (e.g., in a parent entry), the client may have
- entries stored locally which are no longer part of its desired
- search set. Similarly, if entries are added to the search result
- set due to changes in meta-data, the client's cache of entries may
- not include these entries.
-
- Some clients may wish to perform an initial synchronization in order
- to prime a cache or establish a baseline set of entries, then look
- for changes after that. The recommended way to do this is to first
- issue an LCUP search with the updateType field of the clientUpdate
- control value set to synchronizeOnly, then after that search
- successfully completes, immediately issue an LCUP search with the
- updateType field of the clientUpdate control value set to
- synchronizeAndPersist.
-
- Some clients may have unreliable connections, for example, a
- wireless device or a WAN connection. These clients may want to
- insure that the cookie is returned often in the entryUpdate control
- value, so that if they have to reconnect, they do not have to
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 14
-\f
-
-
- process many redundant entries. These clients should set the
- sendCookieInterval in the clientUpdate control value to a low
- number, perhaps even 1. Also, some clients may have a limited
- bandwidth connection, and may not want to receive the cookie very
- often, or even at all (however, the cookie is always sent back in
- the clientUpdateDone control value upon successful completion).
- These clients should set the sendCookieInterval in the clientUpdate
- control value to a high number.
-
-7. Server Implementation Considerations
-
- Servers SHOULD support UUIDs. Otherwise, it will be very difficult
- to support modifyDN operations. Adding support for UUIDs should be
- seen as a necessary component of LCUP.
-
- By design, the protocol supports multiple cookie schemes. This is
- to allow different implementations the flexibility of storing any
- information applicable to their environment. A reasonable
- implementation for an LDUP compliant server would be to use the
- Replica Update Vector (RUV). For each master, RUV contains the
- largest CSN seen from this master. In addition, the RUV implemented
- by some directory servers (not yet in LDUP) contains replica
- generation - an opaque string that identifies the replica's data
- store. The replica generation value changes whenever the replica's
- data is reloaded. Replica generation is intended to signal the
- replication/synchronization peers that the replica's data was
- reloaded and that all other replicas need to be reinitialized. RUV
- satisfies the three most important properties of the cookie: (1) it
- uniquely identifies the state of client's data, (2) it can be used
- to synchronize with multiple servers, and (3) it can be used to
- detect that the server's data was reloaded.
-
- A server may support one or more LCUP cookie schemes. It is
- expected that schemes will be published along with their OIDs as
- RFCs. If a client initiates an LCUP session with a particular
- scheme, the server MUST use that same scheme throughout the LCUP
- session, or until an LCUP context boundary is crossed, in which case
- the server will usually require a different cookie anyway.
-
- In addition, the cookie must contain enough information to allow the
- server to determine whether the cookie can be safely used with the
- search specification it is attached to. As discussed earlier in the
- document, the cookie can only be used with the search specification
- that is equally or more restrictive than the one for which the
- cookie was generated.
-
- An implementation must make sure that it can correctly update the
- client's cookie when there is a size limit imposed on the search
- results by either the client's request or by the server's
- configuration. If RUV is used as the cookie, entries last modified
- by a particular master must be sent to the client in the order of
- their last modified CSN. This ordering guarantees that the RUV can
- be updated after each entry is sent.
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 15
-\f
-
-
- The server's DIT may be partitioned into different sections which
- may have different cookies associated with them. For example, some
- servers may use some sort of replication mechanism to support LCUP.
- If so, the DIT may be partitioned into multiple replicas. A client
- may send an LCUP search request that spans multiple replicas. Some
- parts of the DIT spanned by the search request scope may be managed
- by LCUP and some may not. A part of the DIT which is enabled for
- LCUP is referred to as an LCUP Context. The server SHOULD send a
- SearchResultReference [RFC2251, SECTION 4.5.3] when the LCUP Context
- for a returned entry changes. The server SHOULD return all entries
- for a particular LCUP Context before returning a reference to other
- LCUP Contexts or non-LCUP enabled parts of the DIT, in order to
- minimize the processing burden on the clients. The LDAP URL(s)
- returned MUST contain the DN(s) of the base of another section of
- the DIT (however the server implementation has partitioned the DIT).
- The client will then issue another LCUP search using the LDAP URL
- returned. Each section of the DIT MAY require a different cookie
- value, so the client SHOULD maintain a cache, mapping the different
- LDAP URL values to different cookies. If the cookie changes, the
- scheme may change as well, but the cookie scheme MUST be the same
- within a given LCUP Context.
-
- An implementation SHOULD notify the client about all entries deleted
- from the search set since the client's last session, but an LCUP
- client MUST NOT assume that such notification will occur. For
- example, the server might not notify the client of the deletion of
- an object if the object left the search set following the client's
- last synchronization and prior to the object's deletion. An LDUP
- compliant implementation can achieve this through the use of entry
- tombstones. The implementation should avoid aggressive tombstone
- purging since lack of tombstones would cause client's data to be
- reloaded. We suggest that only the tombstone content be removed
- during the regular trimming cycle while tombstones themselves are
- discarded much less frequently.
-
- The specification makes no guarantees about how soon a server should
- send notification of a changed entry to the client when the
- connection between the client and the server is kept open. This is
- intentional as any specific maximum delay would be impossible to
- meet in a distributed directory service implementation. Server
- implementors are encouraged to minimize the delay before sending
- notifications to ensure that clients' needs for timeliness of change
- notification are met.
-
- Implementors of servers that support the mechanism described in this
- document should ensure that their implementation scales well as the
- number of active persistent operations and the number of changes
- made in the directory increases. Server implementors are also
- encouraged to support a large number of client connections if they
- need to support large numbers of persistent operations.
-
-8. Synchronizing Heterogeneous Data Stores
-
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 16
-\f
-
-
- Clients, like a meta directory join engine, synchronizing multiple
- writable data stores will only work correctly if each piece of
- information is single mastered (for instance, only by an LDUP
- compliant directory). This is because different systems have
- different notions of time and different update resolution
- procedures. As a result, a change applied on one system can be
- discarded by the other, thus preventing the data stores from
- converging.
-
-9. Security Considerations
-
- In some situations, it may be important to prevent general exposure
- of information about changes that occur in an LDAP server.
- Therefore, servers that implement the mechanism described in this
- document SHOULD provide a means to enforce access control on the
- entries returned and MAY also provide specific access control
- mechanisms to control the use of the controls and extended
- operations defined in this document.
-
- As with normal LDAP search requests, a malicious client can initiate
- a large number of persistent search requests in an attempt to
- consume all available server resources and deny service to
- legitimate clients. The protocol provides the means to stop
- malicious clients by disconnecting them from the server. The servers
- that implement the mechanism SHOULD provide the means to detect the
- malicious clients. In addition, the servers SHOULD provide the means
- to limit the number of resources that can be consumed by a single
- client.
-
- Access control on the data can be modified in such a way that the
- data is no longer visible to the client. The specification does not
- specify how the server should handle this condition. Moreover, data
- consistency is not guaranteed if access control is changed from a
- more restrictive to a less restrictive one. This is because access
- control can be considered as an additional filter on the search
- specification and the protocol does not support going from a more to
- a less restrictive search specification. See Client Side
- Considerations Section for more detailed explanation of the problem.
-
-10. Normative References
-
- [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory
- Access Protocol", RFC 2251, December 1997.
-
- [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax
- Definitions", RFC 2252, December 1997.
-
- [CANCEL] K. Zeilenga, "LDAP Cancel Extended Operation",
- draft-zeilenga-ldap-cancel-xx.txt, a work in progress.
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 17
-\f
-
-
-11. Acknowledgements
-
- The LCUP protocol is based in part on the Persistent Search Change
- Notification Mechanism defined by Mark Smith, Gordon Good, Tim
- Howes, and Rob Weltman, the LDAPv3 Triggered Search Control defined
- by Mark Wahl, and the LDAP Control for Directory Synchronization
- defined by Michael Armijo.
-
-12. Author's Addresses
-
- Rich Megginson
- Netscape Communications Corp.
- 901 San Antonio Rd.
- Palo Alto, CA 94303-4900
- Mail Stop SCA17 - 201
- Phone: +1 505 797-7762
- Email: richm@netscape.com
-
- Olga Natkovich
- Yahoo, Inc.
- 701 First Ave.
- Sunnyvale, CA 94089
- Phone: +1 408 349-6153
- Email: olgan@yahoo-inc.com
-
- Mark Smith
- Netscape Communications Corp.
- 901 San Antonio Rd.
- Palo Alto, CA 94303-4900
- Mail Stop SCA17 - 201
- Phone: +1 650 937-3477
- Email: mcs@netscape.com
-
- Jeff Parham
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052-6399
- Phone: +1 425 882-8080
- Email: jeffparh@microsoft.com
-
-13. Full Copyright Statement
- "Copyright (C) The Internet Society (date). All Rights Reserved.
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph
- are included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 18
-\f
-
-
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-14. Appendix A - Summary of Changes
-
- Changes new to version 03:
-
- Emphasized the use of UUIDs throughout the document. Implementers
- are strongly encouraged to use UUIDs as a necessary component of
- the protocol.
-
- Removed the LCUP Cancel extended operation in favor of the new
- LDAP Cancel operation [CANCEL].
-
- Got rid of the lcupSuccess result code. All result codes will be
- added to the IANA LDAP result code registry as part of the LDAP
- standard. Also removed the result code and text from the client
- update done control value.
-
- Changed any and all wording suggesting an LCUP Context is related
- to a naming context. New text says an LCUP Context is a part of
- the DIT that supports LCUP, and that a server may have one or more
- LCUP Contexts.
-
- Removed Old Section 4.2: lcupCookieScheme
- We decided that LCUP did not need a discovery mechanism. The
- controls and extended operations will be published in the root DSE
- as per the LDAP standards.
-
- Changed references to "Unique Identifier" to either "Universally
- Unique Identifier" or "UUID".
-
- Added this text to section 6 "Client Side Considerations":
- "- The client may receive a referral (Referral [RFC2251 SECTION
- 4.1.11]) when the search base is a subordinate reference, and
- this will end the operation."
-
- Added a note to section 6 "Client Side Considerations" about how
- to establish a baseline set of entries or entry cache.
-
- Added the field sendCookieInterval to the clientUpdate control
- value.
-
- Added a note to section 6 "Client Side Considerations" explaining
- possible uses of the sendCookieInterval.
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 19
-\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: December 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: December 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: December 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: 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
-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
projects / openldap / commitdiff