upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2026-02-18 18:18:06 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update drafts

Browse source
This commit is contained in:
Kurt Zeilenga 2002-06-08 20:08:28 +00:00
parent 4eb430cfcb
commit a2a687411c
15 changed files with 8113 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

625
doc/drafts/draft-ietf-ldapext-ldapv3-vlv-xx.txt Normal file
View file

@ -0,0 +1,625 @@
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
LDAP Extensions for Scrolling View May 2002
Browsing of Search Results
3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
to be interpreted as described in RFC 2119 [Bradner97].
4. Background
A Virtual List is a graphical user interface technique employed where
ordered lists containing a large number of entries need to be
displayed. A window containing a small number of visible list entries
is drawn. The visible portion of the list may be relocated to
different points within the list by means of user input. This input
can be to a scroll bar slider; from cursor keys; from page up/down
keys; from alphanumeric keys for "typedown". The user is given the
impression that they may browse the complete list at will, even
though it may contain millions of entries. It is the fact that the
complete list contents are never required at any one time that
characterizes Virtual List View. Rather than fetch the complete list
from wherever it is stored (typically from disk or a remote server),
only that information which is required to display the part of the
list currently in view is fetched. The subject of this document is
the interaction between client and server required to implement this
functionality in the context of the results from a sorted LDAP search
request.
For example, suppose an e-mail address book application displays a
list view onto the list containing the names of all the holders of e-
mail accounts at a large university. The list is sorted
alphabetically. While there may be tens of thousands of entries in
this list, the address book list view displays only 20 such accounts
at any one time. The list has an accompanying scroll bar and text
input window for type-down. When first displayed, the list view shows
the first 20 entries in the list, and the scroll bar slider is
positioned at the top of its range. Should the user drag the slider
to the bottom of its range, the displayed contents of the list view
should be updated to show the last 20 entries in the list. Similarly,
if the slider is positioned somewhere in the middle of its travel,
the displayed contents of the list view should be updated to contain
the 20 entries located at that relative position within the complete
list. Starting from any display point, if the user uses the cursor
keys or clicks on the scroll bar to request that the list be scrolled
up or down by one entry, the displayed contents should be updated to
reflect this. Similarly the list should be displayed correctly when
the user requests a page scroll up or down. Finally, when the user
types characters in the type-down window, the displayed contents of
the list should "jump" or "seek" to the appropriate point within the
list. For example, if the user types "B", the displayed list could
center around the first user with a name beginning with the letter
"B". When this happens, the scroll bar slider should also be updated
to reflect the new relative location within the list.
Boreham et al Internet-Draft 2
LDAP Extensions for Scrolling View May 2002
Browsing of Search Results
This document defines a request control which extends the LDAP search
operation. Always used in conjunction with the server side sorting
control [SSS], this allows a client to retrieve selected portions of
large search result set in a fashion suitable for the implementation
of a virtual list view.
5. Client-Server Interaction
The Virtual List View control extends a regular LDAP Search operation
which must also include a server-side sorting control [SSS]. Rather
than returning the complete set of appropriate SearchResultEntry
messages, the server is instructed to return a contiguous subset of
those entries, taken from the sorted result set, centered around a
particular target entry. Henceforth, in the interests of brevity, the
sorted search result set will be referred to as "the list".
The sort control MAY contain any sort specification valid for the
server. The attributeType field in the first SortKeyList sequence
element has special significance for "typedown".
The desired target entry and the number of entries to be returned,
both before and after that target entry in the list, are determined
by the client's VirtualListViewRequest control.
When the server returns the set of entries to the client, it attaches
a VirtualListViewResponse control to the SearchResultDone message.
The server returns in this control: its current estimate for the list
content count, the location within the list corresponding to the
target entry, any error codes, and optionally a context identifier.
The target entry is specified in the VirtualListViewRequest control
by one of two methods. The first method is for the client to indicate
the target entry's offset within the list. The second way is for the
client to supply an attribute assertion value. The value is compared
against the values of the attribute specified as the primary sort key
in the sort control attached to the search operation. The first sort
key in the SortKeyList is the primary sort key. The target entry is
the first entry in the list with value greater than or equal to (in
the primary sort order), the presented value. The order is determined
by rules defined in [SSS]. Selection of the target entry by this
means is designed to implement "typedown". Note that it is possible
that no entry satisfies these conditions, in which case there is no
target entry. This condition is indicated by the server returning the
special value contentCount + 1 in the target position field.
Because the server may not have an accurate estimate of the number of
entries in the list, and to take account of cases where the list size
is changing during the time the user browses the list, and because
the client needs a way to indicate specific list targets "beginning"
Boreham et al Internet-Draft 3
LDAP Extensions for Scrolling View May 2002
Browsing of Search Results
and "end", offsets within the list are transmitted between client and
server as ratios---offset to content count. The server sends its
latest estimate as to the number of entries in the list (content
count) to the client in every response control. The client sends its
assumed value for the content count in every request control. The
server examines the content count and offsets presented by the client
and computes the corresponding offsets within the list, based on its
own idea of the content count.
Si = Sc * (Ci / Cc)
Where:
Si is the actual list offset used by the server
Sc is the server's estimate for content count
Ci is the client's submitted offset
Cc is the client's submitted content count
The result is rounded to the nearest integer.
If the content count is stable, and the client returns to the server
the content count most recently received, Cc = Sc and the offsets
transmitted become the actual server list offsets.
The following special cases exist when the client is specifying the
offset and content count:
- an offset of one and a content count of non-one (Ci = 1, Cc != 1)
indicates that the target is the first entry in the list.
- equivalent values (Ci = Cc) indicate that the target is the last
entry in the list.
- a content count of zero, and a non-zero offset (Cc = 0, Ci != 0)
means the client has no idea what the content count is, the server
MUST use its own content count estimate in place of the client's.
Because the server always returns contentCount and targetPosition,
the client can always determine which of the returned entries is the
target entry. Where the number of entries returned is the same as the
number requested, the client is able to identify the target by simple
arithmetic. Where the number of entries returned is not the same as
the number requested (because the requested range crosses the
beginning or end of the list, or both), the client must use the
target position and content count values returned by the server to
identify the target entry. For example, suppose that 10 entries
before and 10 after the target were requested, but the server returns
13 entries, a content count of 100 and a target position of 3. The
client can determine that the first entry must be entry number 1 in
the list, therefore the 13 entries returned are the first 13 entries
in the list, and the target is the third one.
A server-generated context identifier MAY be returned to clients. A
client receiving a context identifier SHOULD return it unchanged in a
subsequent request which relates to the same list. The purpose of
Boreham et al Internet-Draft 4
LDAP Extensions for Scrolling View May 2002
Browsing of Search Results
this interaction is to enhance the performance and effectiveness of
servers which employ approximate positioning.
6. The Controls
Support for the virtual list view control extension is indicated by
the presence of the OID "2.16.840.1.113730.3.4.9" in the
supportedControl attribute of a server's root DSE.
6.1. Request Control
This control is included in the SearchRequest message as part of the
controls field of the LDAPMessage, as defined in Section 4.1.12 of
[LDAPv3]. The controlType is set to "2.16.840.1.113730.3.4.9". The
criticality SHOULD be set to TRUE. If this control is included in a
SearchRequest message, a Server Side Sorting request control [SSS]
MUST also be present in the message. The controlValue is an OCTET
STRING whose value is the BER-encoding of the following SEQUENCE:
VirtualListViewRequest ::= SEQUENCE {
beforeCount INTEGER (0..maxInt),
afterCount INTEGER (0..maxInt),
CHOICE {
byoffset [0] SEQUENCE {
offset INTEGER (0 .. maxInt),
contentCount INTEGER (0 .. maxInt) },
greaterThanOrEqual [1] AssertionValue },
contextID OCTET STRING OPTIONAL }
beforeCount indicates how many entries before the target entry the
client wants the server to send. afterCount indicates the number of
entries after the target entry the client wants the server to send.
offset and contentCount identify the target entry as detailed in
section 4. greaterThanOrEqual is an attribute assertion value defined
in [LDAPv3]. If present, the value supplied in greaterThanOrEqual is
used to determine the target entry by comparison with the values of
the attribute specified as the primary sort key. The first list entry
who's value is no less than (less than or equal to when the sort
order is reversed) the supplied value is the target entry. If
present, the contextID field contains the value of the most recently
received contextID field from a VirtualListViewResponse control. The
type AssertionValue and value maxInt are defined in [LDAPv3].
contextID values have no validity outwith the connection on which
they were received. That is, a client should not submit a contextID
which it received from another connection, a connection now closed,
or a different server.
6.2. Response Control
Boreham et al Internet-Draft 5
LDAP Extensions for Scrolling View May 2002
Browsing of Search Results
This control is included in the SearchResultDone message as part of
the controls field of the LDAPMessage, as defined in Section 4.1.12
of [LDAPv3].
The controlType is set to "2.16.840.1.113730.3.4.10". The criticality
is FALSE (MAY be absent). The controlValue is an OCTET STRING, whose
value is the BER encoding of a value of the following SEQUENCE:
VirtualListViewResponse ::= SEQUENCE {
targetPosition INTEGER (0 .. maxInt),
contentCount INTEGER (0 .. maxInt),
virtualListViewResult ENUMERATED {
success (0),
operationsError (1),
unwillingToPerform (53),
insufficientAccessRights (50),
busy (51),
timeLimitExceeded (3),
adminLimitExceeded (11),
sortControlMissing (60),
offsetRangeError (61),
other (80) },
contextID OCTET STRING OPTIONAL }
targetPosition gives the list offset for the target entry.
contentCount gives the server's estimate of the current number of
entries in the list. Together these give sufficient information for
the client to update a list box slider position to match the newly
retrieved entries and identify the target entry. The contentCount
value returned SHOULD be used in a subsequent VirtualListViewRequest
control. contextID is a server-defined octet string. If present, the
contents of the contextID field SHOULD be returned to the server by a
client in a subsequent VirtualListViewRequest control.
The virtualListViewResult codes which are common to the LDAP
searchResponse (adminLimitExceeded, timeLimitExceeded, busy,
operationsError, unwillingToPerform, insufficientAccessRights) have
the same meanings as defined in [LDAPv3], but they pertain
specifically to the VLV operation. For example, the server could
exceed an administration limit processing a SearchRequest with a
VirtualListViewRequest control. However, the same administration
limit would not be exceeded should the same SearchRequest be
submitted by the client without the VirtualListViewRequest control.
In this case, the client can determine that an administration limit
has been exceeded in servicing the VLV request, and can if it chooses
resubmit the SearchRequest without the VirtualListViewRequest
control.
insufficientAccessRights means that the server denied the client
permission to perform the VLV operation.
Boreham et al Internet-Draft 6
LDAP Extensions for Scrolling View May 2002
Browsing of Search Results
If the server determines that the results of the search presented
exceed the range specified in INTEGER values, it MUST return
offsetRangeError.
6.2.1 virtualListViewError
A new LDAP error is introduced called virtualListViewError. Its value
is 76.
[Note to the IESG/IANA/RFC Editor: the value 76 has been suggested by
experts, had expert review, and is currently being used by some
implementations. The intent is to have this number designated as an
official IANA assigned LDAP Result Code (see draft-ietf-ldapbis-iana-
xx.txt, Section 3.5)]
If the server returns any code other than success (0) for
virtualListViewResult, then the server SHOULD return
virtualListViewError as the resultCode of the SearchResultDone
message.
7. Protocol Example
Here we walk through the client-server interaction for a specific
virtual list view example: The task is to display a list of all 78564
people in the US company "Ace Industry". This will be done by
creating a graphical user interface object to display the list
contents, and by repeatedly sending different versions of the same
virtual list view search request to the server. The list view
displays 20 entries on the screen at a time.
We form a search with baseDN "o=Ace Industry, c=us"; search scope
subtree; filter "objectClass=inetOrgPerson". We attach a server sort
order control to the search, specifying ascending sort on attribute
"cn". To this base search, we attach a virtual list view request
control with contents determined by the user activity and send the
search to the server. We display the results from each search in the
list window and update the slider position.
When the list view is first displayed, we want to initialize the
contents showing the beginning of the list. Therefore, we set
beforeCount = 0, afterCount = 19, contentCount = 0, offset = 1 and
send the request to the server. The server duly returns the first 20
entries in the list, plus the content count = 78564 and
targetPosition = 1. We therefore leave the scroll bar slider at its
current location (the top of its range).
Say that next the user drags the scroll bar slider down to the bottom
of its range. We now wish to display the last 20 entries in the list,
so we set beforeCount = 19, afterCount = 0, contentCount = 78564,
offset = 78564 and send the request to the server. The server returns
Boreham et al Internet-Draft 7
LDAP Extensions for Scrolling View May 2002
Browsing of Search Results
the last 20 entries in the list, plus the content count = 78564 and
targetPosition = 78564.
Next the user presses a page up key. Our page size is 20, so we set
beforeCount = 0, afterCount = 19, contentCount = 78564, offset =
78564-19-20 and send the request to the server. The server returns
the preceding 20 entries in the list, plus the content count = 78564
and targetPosition = 78525.
Now the user grabs the scroll bar slider and drags it to 68% of the
way down its travel. 68% of 78564 is 53424 so we set beforeCount = 9,
afterCount = 10, contentCount = 78564, offset = 53424 and send the
request to the server. The server returns the preceding 20 entries in
the list, plus the content count = 78564 and targetPosition = 53424.
Lastly, the user types the letter "B". We set beforeCount = 9,
afterCount = 10 and greaterThanOrEqual = "B". The server finds the
first entry in the list not less than "B", let's say "Babs Jensen",
and returns the nine preceding entries, the target entry, and the
proceeding 10 entries. The server returns content count = 78564 and
targetPosition = 5234 and so the client updates its scroll bar slider
to 6.7% of full scale.
8. Notes for Implementers
While the feature is expected to be generally useful for arbitrary
search and sort specifications, it is specifically designed for those
cases where the result set is very large. The intention is that this
feature be implemented efficiently by means of pre-computed indices
pertaining to a set of specific cases. For example, an offset
relating to "all the employees in the local organization, sorted by
surname" would be a common case.
The intention for client software is that the feature should fit
easily with the host platform's graphical user interface facilities
for the display of scrolling lists. Thus the task of the client
implementers should be one of reformatting up the requests for
information received from the list view code to match the format of
the virtual list view request and response controls.
Client implementers should note that any offset value returned by the
server may be approximate. Do not design clients > which only operate
correctly when offsets are exact.
Server implementers using indexing technology which features
approximate positioning should consider returning context identifiers
to clients. The use of a context identifier will allow the server to
distinguish between client requests which relate to different
displayed lists on the client. Consequently the server can decide
more intelligently whether to reposition an existing database cursor
Boreham et al Internet-Draft 8
LDAP Extensions for Scrolling View May 2002
Browsing of Search Results
accurately to within a short distance of its current position, or to
reposition to an approximate position. Thus the client will see
precise offsets for "short" repositioning (e.g. paging up or down),
but approximate offsets for a "long" reposition (e.g. a slider
movement).
Server implementers are free to return status code unwillingToPerform
should their server be unable to service any particular VLV search.
This might be because the resolution of the search is computationally
infeasible, or because excessive server resources would be required
to service the search.
Client implementers should note that this control is only defined on
a client interaction with a single server. If a server returns
referrals as a part of its response to the search request, the client
is responsible for deciding when and how to apply this control to the
referred-to servers, and how to collate the results from multiple
servers.
9. Relationship to "Simple Paged Results"
These controls are designed to support the virtual list view, which
has proved hard to implement with the Simple Paged Results mechanism
[SPaged]. However, the controls described here support any operation
possible with the Simple Paged Results mechanism. The two mechanisms
are not complementary; rather one has a superset of the other's
features. One area where the mechanism presented here is not a strict
superset of the Simple Paged Results scheme is that here we require a
sort order to be specified. No such requirement is made for paged
results.
10. Security Considerations
Server implementers may wish to consider whether clients are able to
consume excessive server resources in requesting virtual list
operations. Access control to the feature itself; configuration
options limiting the featureÆs use to certain predetermined search
base DNs and filters; throttling mechanisms designed to limit the
ability for one client to soak up server resources, may be
appropriate.
Consideration should be given as to whether a client will be able to
retrieve the complete contents, or a significant subset of the
complete contents of the directory using this feature. This may be
undesirable in some circumstances and consequently it may be
necessary to enforce some access control.
Boreham et al Internet-Draft 9
LDAP Extensions for Scrolling View May 2002
Browsing of Search Results
Clients can, using this control, determine how many entries are
contained within a portion of the DIT. This may constitute a security
hazard. Again, access controls may be appropriate.
Server implementers SHOULD exercise caution concerning the content of
the contextID. Should the contextID contain internal server state, it
may be possible for a malicious client to use that information to
gain unauthorized access to information.
11. Acknowledgements
Chris Weider, Anoop Anantha, and Michael Armijo of Microsoft co-
authored previous versions of this document.
12. References
[LDAPv3] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
Access Protocol (v3)", Internet Standard, RFC 2251,
December, 1997.
[SPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP
Control Extension for Simple Paged Results Manipulation",
RFC2696, September 1999.
[SSS] Wahl, M., Herron, A. and T. Howes, "LDAP Control
Extension for Server Side Sorting of Search Results",
RFC 2891, August, 2000.
[Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Boreham et al Internet-Draft 10
LDAP Extensions for Scrolling View May 2002
Browsing of Search Results
13. Authors' Addresses
David Boreham
Bozeman Pass, Inc
+1 406 222 7093
david@bozemanpass.com
Jim Sermersheim
Novell, Inc
1800 South Novell Place
Provo, Utah 84606, USA
jimse@novell.com
Asaf Kashi
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052, USA
+1 425 882-8080
asafk@microsoft.com
14. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Boreham et al Internet-Draft 11

362
doc/drafts/draft-ietf-ldapext-locate-xx.txt Normal file
View file

@ -0,0 +1,362 @@
INTERNET-DRAFT Michael P. Armijo
<draft-ietf-ldapext-locate-07.txt> Levon Esibov
February 20, 2002 Paul Leach
Expires: August 20, 2002 Microsoft Corporation
R.L. Morgan
University of Washington
Discovering LDAP Services with DNS
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. It is filed as <draft-
ietf-ldapext-locate-07.txt>, and expires on August 20, 2002.
Please send comments to the authors.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
A Lightweight Directory Access Protocol (LDAP) request must be
directed to an appropriate server for processing. This document
specifies a method for discovering such servers using information in
the Domain Name System.
Armijo, Esibov, Leach and Morgan [Page 1]
INTERNET-DRAFT Discovering LDAP Services with DNS February 20, 2002
1. Introduction
The LDAPv3 protocol [1] is designed to be a lightweight access
protocol for directory services supporting X.500 models. As a
distributed directory service, the complete set of directory
information (known as the Directory Information Base) is spread
across many different servers. Hence there is the need to
determine, when initiating or processing a request, which servers
hold the relevant information. In LDAP, the Search, Modify, Add,
Delete, ModifyDN, and Compare operations all specify a Distinguished
Name (DN) [2] on which the operation is performed. A client, or a
server acting on behalf of a client, must be able to determine the
server(s) that hold the naming context containing that DN, since
that server (or one of that set of servers) must receive and process
the request. This determination process is called "server
location". To support dynamic distributed operation, the
information needed to support server location must be available via
lookups done at request processing time, rather than, for example,
as static data configured into each client or server.
It is possible to maintain the information needed to support server
location in the directory itself, and X.500 directory deployments
typically do so. In practice, however, this only permits location
of servers within a limited X.500-connected set. LDAP-specific
methods of maintaining server location information in the directory
have not yet been standardized. This document defines an
alternative method of managing server location information using the
Domain Name System. This method takes advantage of the global
deployment of the DNS, by allowing LDAP server location information
for any existing DNS domain to be published by creating the records
described below. A full discussion of the benefits and drawbacks of
the various directory location and naming methods is beyond the
scope of this document.
RFC 2247[3] defines an algorithm for mapping DNS domain names into
DNs. This document defines the inverse mapping, from DNs to DNS
domain names, based on the conventions in [3], for use in this
server location method. The server location method described in
this document is only defined for DNs that can be so mapped, i.e.,
those DNs that are based on domain names. In practice this is
reasonable because many objects of interest are named with domain
names, and use of domain-name-based DNs is becoming common.
2. Mapping Distinguished Names into Domain Names
This section defines a method of converting a DN into a DNS domain
name for use in the server location method described below. Some
DNs cannot be converted into a domain name. Converted DNs result
in a fully qualified domain name.
Armijo, Esibov, Leach and Morgan [Page 2]
INTERNET-DRAFT Discovering LDAP Services with DNS February 20, 2002
The output domain name is initially empty. The DN is processed in
right-to-left order (i.e., beginning with the first RDN in the
sequence of RDNs). An RDN is able to be converted if it (1)
consists of a single AttributeTypeAndValue; (2) the attribute type
is "DC"; and (3) the attribute value is non-null. If it can be
converted, the attribute value is used as a domain name component
(label). The first such value becomes the rightmost (i.e., most
significant) domain name component, and successive converted RDN
values extend to the left. If an RDN cannot be converted,
processing stops. If the output domain name is empty when
processing stops, the DN cannot be converted into a domain name.
For DN:
cn=John Doe,ou=accounting,dc=example,dc=net
The client would convert the DC components as defined above into
DNS name:
example.net
The determined DNS name will be submitted as a DNS query using the
algorithm defined in section 3.
3. Locating LDAPv3 servers through DNS
LDAPv3 server location information is to be stored using DNS Service
Location Record (SRV)[5]. The data in a SRV record contains the DNS
name of the server that provides the LDAP service, corresponding
Port number, and parameters that enable the client to choose an
appropriate server from multiple servers according to the algorithm
described in [5]. The name of this record has the following format:
_<Service>._<Proto>.<Domain>.
where <Service> is "ldap", and <Proto> is "tcp". <Domain> is the
domain name formed by converting the DN of a naming context mastered
by the LDAP Server into a domain name using the algorithm in
Section 2. Note that "ldap" is the symbolic name for the LDAP
service in Assigned Numbers[6], as required by [5].
Armijo, Esibov, Leach and Morgan [Page 3]
INTERNET-DRAFT Discovering LDAP Services with DNS February 20, 2002
Presence of such records enables clients to find the LDAP servers
using standard DNS query [4]. A client (or server) seeking an LDAP
server for a particular DN converts that DN to a domain name using
the algorithm of Section 2, does a SRV record query using the DNS
name formed as described in the preceding paragraph, and interprets
the response as described in [5] to determine a host (or hosts) to
contact. As an example, a client that searches for an LDAP server
for the DN "ou=foo,dc=example,dc=net" that supports the TCP protocol
will submit a DNS query for a set of SRV records with owner name:
_ldap._tcp.example.net.
The client will receive the list of SRV records published in DNS
that satisfy the requested criteria. The following is an example of
such a record:
_ldap._tcp.example.net. IN SRV 0 0 389 phoenix.example.net.
The set of returned records may contain multiple records in the case
where multiple LDAP servers serve the same domain. If there are no
matching SRV records available for the converted DN the client SHOULD
NOT attempt to 'walk the tree' by removing the least significant
portion of the constructed fully qualified domain name.
4. IANA Considerations
This document does not require any IANA actions.
5. Security Considerations
DNS responses can typically be easily spoofed. Clients using this
location method SHOULD ensure, via use of strong security
mechanisms, that the LDAP server they contact is the one they
intended to contact. See [7] for more information on security
threats and security mechanisms.
When using LDAP with TLS the client must check the server's name,
as described in section 3.6 of [RFC 2830]. As specified there, the
name the client checks for is the server's name before any
potentially insecure transformations, including the SRV record
lookup specified in this memo. Thus the name the client must check
for is the name obtained by doing the mapping step defined in
section 2 above. For example, if the DN "cn=John
Doe,ou=accounting,dc=example,dc=net" is converted to the DNS name
"example.net", the server's name must match "example.net".
This document describes a method that uses DNS SRV records to
discover LDAP servers. All security considerations related to DNS
SRV records are inherited by this document. See the security
considerations section in [5] for more details.
Armijo, Esibov, Leach and Morgan [Page 4]
INTERNET-DRAFT Discovering LDAP Services with DNS February 20, 2002
6. References
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol(v3)", RFC 2251, December 1997.
[2] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished
Names", RFC 2253, December 1997.
[3] Kille, S. and M. Wahl, "Using Domains in LDAP/X.500
Distinguished Names", RFC 2247, January 1998.
[4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
1034, STD 13, November 1987.
[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[7] Wahl, M., Alvestrand, H., Hodges, J. and Morgan, R.,
"Authentication Methods for LDAP", RFC 2829, May 2000.
[8] Hodges, J., Morgan, R., Wahl, M., "Lightweight Directory Access
Protocol (v3): Extension for Transport Layer Security", RFC 2830,
May 2000.
7. Authors' Addresses
Michael P. Armijo
One Microsoft Way
Redmond, WA 98052
micharm@microsoft.com
Paul Leach
One Microsoft Way
Redmond, WA 98052
paulle@microsoft.com
Levon Esibov
One Microsoft Way
Redmond, WA 98052
levone@microsoft.com
Armijo, Esibov, Leach and Morgan [Page 5]
INTERNET-DRAFT Discovering LDAP Services with DNS February 20, 2002
RL "Bob" Morgan
University of Washington
4545 15th Ave NE
Seattle, WA 98105
US
Phone: +1 206 221 3307
EMail: rlmorgan@washington.edu
URI: http://staff.washington.edu/rlmorgan/
8. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive
Director.
9. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
Armijo, Esibov, Leach and Morgan [Page 6]
INTERNET-DRAFT Discovering LDAP Services with DNS February 20, 2002
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
10. Expiration Date
This documentis filed as <draft-ietf-ldapext-locate-06.txt>, and
expires August 20, 2002.
Armijo, Esibov, Leach and Morgan [Page 7]

1298
doc/drafts/draft-ietf-ldup-lcup-xx.txt Normal file
View file

File diff suppressed because it is too large Load diff

351
doc/drafts/draft-weltman-ldapv3-proxy-xx.txt Normal file
View file

@ -0,0 +1,351 @@
INTERNET-DRAFT Rob Weltman
Intended Category: Standards Track Netscape Communications Corp.
May 2002
LDAP Proxied Authorization Control
draft-weltman-ldapv3-proxy-11.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Task Force
(IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines the Lightweight Directory Access Protocol
(LDAP) Proxied Authorization Control. The Proxied Authorization
Control allows a client to request that an operation be processed
under a provided authorization identity [AUTH] instead of as the
current authorization identity associated with the connection.
1. Introduction
This document defines support for proxied authorization using the
Control mechanism. LDAP [LDAPV3] supports the use of SASL [SASL] for
authentication and for supplying an authorization identity distinct
from the authentication identity, where the authorization identity
applies to the whole LDAP session. The proposed Proxied Authorization
Control provides a mechanism for specifying an authorization identity
on a per operation basis, benefiting clients that need to efficiently
perform operations on behalf of multiple users.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and
"MAY NOT" used in this document are to be interpreted as described
in [KEYWORDS].
Expires November 2002 [Page 1]
PROXIED AUTHORIZATION CONTROL May 2002
2. Publishing support for the Proxied Authorization Control
Support for the Proxied Authorization Control is indicated by the
presence of the OID "2.16.840.1.113730.3.4.18" in the
supportedControl attribute of a server's root DSE.
3. Proxied Authorization Control
A single Proxied Authorization Control may be included in any search,
compare, modify, add, delete, modDN or extended operation request
message (with the exception of any extension that causes a change in
authentication, authorization, or data confidentiality [RFC 2828],
such as startTLS) as part of the controls field of the LDAPMessage,
as defined in [LDAPV3].
The controlType of the proxied authorization control is
"2.16.840.1.113730.3.4.18".
The criticality MUST be present and MUST be TRUE. This requirement
protects clients from submitting a request that is executed with an
unintended authorization identity.
The controlValue is either an LDAPString [LDAPv3] containing an
authzId as defined in section 9 of [AUTH] to use as the authorization
identity for the request, or an empty value if the anonymous identity
is to be used.
The mechanism for determining proxy access rights is specific to the
server's access control policy.
If the requested authorization identity is recognized by the server,
and the client is authorized to adopt the requested authorization
identity, the request will be executed as if submitted by the proxied
authorization identity, otherwise the result code TBD is returned.
[Note to the IESG/IANA/RFC Editor: the value TBD is to be replaced
with an IANA assigned LDAP Result Code (see draft-ietf-ldapbis-iana-
xx.txt, Section 3.5)]
4. Implementation Considerations
The interaction of proxied authorization access control and normal
access control is illustrated here for the case of search requests.
During evaluation of a search request, an entry which would have been
returned for the search if submitted by the proxied authorization
identity directly may not be returned if the server finds that the
requester does not have the right to assume the requested identity
for searching the entry, even if the entry is within the scope of a
search request under a base DN which does imply such rights. This
means that fewer results, or no results, may be returned compared to
the case where the proxied authorization identity issued the request
directly. An example of such a case may be a system with fine-grained
Expires November 2002 [Page 2]
PROXIED AUTHORIZATION CONTROL May 2002
access control, where the proxy right requester has proxy rights at
the top of a search tree, but not at or below a point or points
within the tree.
5. Security Considerations
The Proxied Authorization Control method is subject to general LDAP
security considerations [LDAPV3] [AUTH] [LDAPTLS]. The control may be
passed over a secure as well as over an insecure channel.
The control allows for an additional authorization identity to be
passed. In some deployments, these identities may contain
confidential information which require privacy protection.
Note that the server is responsible for determining if a proxied
authorization request is to be honored. "Anonymous" users SHOULD NOT
be allowed to assume the identity of others.
6. Copyright
Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
7. References
[LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
Expires November 2002 [Page 3]
PROXIED AUTHORIZATION CONTROL May 2002
[KEYWORDS] Bradner, Scott, "Key Words for use in RFCs to Indicate
Requirement Levels", draft-bradner-key-words-03.txt, January,
1997.
[SASL] J. Myers, "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997
[AUTH] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
Methods for LDAP", RFC 2829, May 2000
[LDAPTLS] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer Security",
RFC 2830, May 2000
[RFC 2828] R. Shirey, "Internet Security Glossary", RFC 2828, May
2000
8. Author's Address
Rob Weltman
Netscape Communications Corp.
466 Ellis Street
Mountain View, CA 94043
USA
+1 650 937-3194
rweltman@netscape.com
9. Acknowledgements
Mark Smith of Netscape Communications Corp., Mark Wahl of Sun
Microsystems, Inc, Kurt Zeilenga of OpenLDAP Foundation, Jim
Sermersheim of Novell, and Steven Legg of Adacel have contributed
with reviews of this draft.
10. Revision History
10.1 Changes from draft-weltman-ldapv3-proxy-10.txt
Clarified the interaction of proxy access rights and normal access
control evaluation.
10.2 Changes from draft-weltman-ldapv3-proxy-09.txt
Removed description of Control mechanism from Abstract.
Added description of how this is different from SASL authz to the
Introduction.
Expires November 2002 [Page 4]
PROXIED AUTHORIZATION CONTROL May 2002
Reworded description of the value of the control (no semantic
changes).
Added new result code TBD for failure to acquire proxy rights.
Added references to RFCs 2829 and 2830 in Security section.
10.3 Changes from draft-weltman-ldapv3-proxy-08.txt
Proxied Authorization Control
Clarifications: the control may not be submitted with a startTLS
request; an empty controlValue implies the anonymous identity; only
one control may be included with a request.
Permission to execute as proxy
Replaced "proxy identity" with "proxied authorization identity".
Security Considerations
Added statement that anonymous users should not be allowed to assume
the identity of others.
10.4 Changes from draft-weltman-ldapv3-proxy-07.txt
Proxied Authorization Control
Clarification: the content of the control is an LDAPString.
10.5 Changes from draft-weltman-ldapv3-proxy-06.txt
None
Expires November 2002 [Page 5]
PROXIED AUTHORIZATION CONTROL May 2002
10.6 Changes from draft-weltman-ldapv3-proxy-05.txt
The control also applies to add and extended operations.
The control value is an authorization ID, not necessarily a DN.
Confidentiality concerns are mentioned.
10.7 Changes from draft-weltman-ldapv3-proxy-04.txt
The control does not apply to bind, unbind, or abandon operations.
The proxy DN is represented as a string in the control, rather than
embedded in a sequence.
Support for the control is published in the supportedControl
attribute of the root DSE, not in supportedExtensions.
The security section mentions confidentiality issues with exposing an
additional identity.
10.8 Changes from draft-weltman-ldapv3-proxy-03.txt
None
10.9 Changes from draft-weltman-ldapv3-proxy-02.txt
The Control is now called Proxied Authorization Control, rather than
Proxied Authentication Control, to reflect that no authentication
occurs as a consequence of processing the Control.
Rather than containing an LDAPDN as the Control value, the Control
contains a Sequence (which contains an LDAPDN). This is to provide
for future extensions.
Expires November 2002 [Page 6]

283
doc/drafts/draft-zeilenga-ldap-adlist-xx.txt Normal file
View file

@ -0,0 +1,283 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
Expires in six months 17 May 2002
LDAPv3: Requesting Attributes by Object Class
<draft-zeilenga-ldap-adlist-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Informational document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions Working Group
mailing list <ietf-ldapext@netscape.com>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Abstract
The Lightweight Directory Access Protocol (LDAP) search operation
provides mechanisms for clients to request all user application
attributes, all operational attributes, or attributes selected by
their description. This document extends LDAP to provide a mechanism
for LDAP clients to request the return of all attributes of an object
class.
Zeilenga Requesting Attributes by Object Class [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
1. Overview
LDAP [RFC2251] search operations support mechanisms for requesting
sets of attributes. This set is determined by a list of attribute
descriptions. Two special descriptors are defined to request all user
attributes ("*") and all operational attributes ("+"). However, there
is no convenient mechanism for requesting pre-defined sets of
attributes. This document extends LDAP to allow an object class
identifier to be specified in search request attributes list to
request the return all attributes allowed by object class.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
2. Return of all Attributes of an Object Class
This extension allows object class identifiers is to be provided in
the attributes field of the LDAP SearchRequest [RFC2251]. For each
object class identified in the attributes field, the request is to be
treated as if each attribute allowed by that class (by "MUST" or
"MAY", directly or by SUPerior) was itself listed. For example, a
request for "country" [RFC2256] is treated as if "c", "searchGuide",
"description", and "objectClass" were requested.
As a special case, requesting extensibleObject [RFC2252] is treated as
if "objectClass,*,+" was requested [RFC2251][OPATTRS].
If the object class identifier is unrecognized, it is be treated an an
unrecognized attribute description.
This extension redefines the attributes field of the SearchRequest to
be a DescriptionList described by the following [ASN.1]:
DescriptionList ::= SEQUENCE OF Description
Description ::= LDAPString
The Description is string conforming to the [ABNF]:
Description ::= AttributeDescription | ObjectClassDescription.
ObjectDescription ::= ObjectClass *( ";" options )
where AttributeDescription and options productions are as defined in
Section 4.1.5 of [RFC2251] and an ObjectClass is an objectIdentifier,
in either numericoid or descr form [RFC 2252], of an object class.
ObjectDescription options are provided for extensibility. This
Zeilenga Requesting Attributes by Object Class [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
document only defines semantics of ObjectDescriptions with zero
options in the attributes field of a SearchRequest. Other uses may be
defined in future specifications.
Servers supporting this feature SHOULD publish the Object Identifier
1.3.6.1.4.1.4203.1.5.2 as a value of the supportedFeatures [FEATURES]
attribute in the root DSE.
3. Security Considerations
This extension provides a shorthand for requesting all attributes of
an object class. As these attributes which could have been listed
individually, this short hand is not believed to raises additional
security considerations.
Implementors of this (or any) LDAP extension should be familiar with
general LDAP general security considerations [LDAPTS].
4. IANA Considerations
No IANA assignments are requested.
This document uses the OID 1.3.6.1.4.1.4203.1.5.2 to identify the LDAP
feature it details. This OID was assigned [ASSIGN] by OpenLDAP
Foundation under its IANA assigned private enterprise allocation
[PRIVATE] for use in this specification.
5. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
6. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
Zeilenga Requesting Attributes by Object Class [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
[LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-xx.txt (a work in progress).
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
[OPATTRS] K. Zeilenga, "LDAPv3: All Operational Attributes",
draft-zeilenga-ldap-opattrs-xx.txt (a work in progress).
7. Informative References
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Zeilenga Requesting Attributes by Object Class [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga Requesting Attributes by Object Class [Page 5]

339
doc/drafts/draft-zeilenga-ldap-authzid-xx.txt Normal file
View file

@ -0,0 +1,339 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 May 2002
LDAP "Who am I?" Operation
<draft-zeilenga-ldap-authzid-06.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extension Working Group
mailing list <ietf-ldapext@netscape.com>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Abstract
This specification provides a mechanism for Lightweight Directory
Access Protocol (LDAP) clients to obtain the authorization identity
which the server has associated with the user or application entity.
This mechanism is specified as an LDAP extended operation called the
LDAP "Who am I?" operation.
Zeilenga LDAP "Who am I?" [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
1. Background and Intent of Use
This specification describes a Lightweight Directory Access Protocol
(LDAP) [RFC2251] extended operation which clients can use to obtain
the primary authorization identity in its primary form which the
server has associated with the user or application entity.
Servers often associate multiple authorization identities with the
client and each authorization identity may be represented by multiple
authzId [RFC2829] strings. This operation requests and returns the
authzId the server considers to be primary. In the specification, the
term "the authorization identity" and "the authzid" are to generally
read as "the primary authorization identity" and the "the primary
authzid", respectively.
This specification is intended to replace the existing [AUTHCTL]
mechanism which uses Bind request and response controls to request and
return the authorization identity. Bind controls are not protected by
the security layers established by the Bind operation which they are
transferred as part of. While it is possible to establish security
layers prior to the Bind operation, it is often desirable to only use
security layers established by the Bind operation. An extended
operation sent after a Bind operation is protected by the security
layers established by the Bind operation.
There are other cases where it is desirable to request the
authorization identity which the server associated with the client
separately from the Bind operation. For example, the "Who am I?"
operation can be augmented with a Proxied Authorization Control
[PROXYCTL] to determine the authorization identity which the server
associates with the identity asserted in the Proxied Authorization
Control. The "Who am I?" operation can also be used prior to the Bind
operation.
The LDAP "Who am I?" operation is named after the UNIX whoami(1)
command. The whoami(1) command displays the effective user id.
2. The "Who am I?" Operation
The "Who am I?" operation is defined as an LDAP Extended Operation
Zeilenga LDAP "Who am I?" [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
[RFC2251, Section 4.12] identified by the whoamiOID Object Identifier
(OID). This section details the syntax of the operation's whoami
request and response messages.
whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
2.1. The whoami Request
The whoami request is an ExtendedRequest with the requestName field
containing the whoamiOID OID and an absent requestValue field. For
example, a whoami request could be encoded as the sequence of octets
(in hex):
2.2. The whoami Response
The whoami response is an ExtendedResponse where the responseName
field is absent and, if present, the response field is empty or an
authzId [RFC2829]. For example, a whoami response returning the
authzid "u:kurt@OPENLDAP.ORG" (in response to the example request)
would be encoded as the sequence of octets (in hex):
3. Operational Semantics
The function of the "Who am I?" operation is to request that the
server returns the authorization identity it currently associates with
the client. The client requests this authorization identity by
issuing a whoami Request. The server responds to this request with a
whoami Response.
If the server is willing and able to provide the authorization
identity it associates with the client, the server SHALL return a
whoami Response with a success resultCode. If the server is treating
the client as an anonymous entity, the response field is empty.
Otherwise the server is to provide the authzId [RFC2829] representing
the authorization identity it currently associates with the client in
the response field.
If the server is unwilling or unable to provide the authorization
identity it associates with the client, the server SHALL return a
whoami Response with an appropriate non-success resultCode (such as
operationsError, protocolError, confidentialityRequired,
insufficientAccessRights, busy, unavailable, unwillingToPerform, or
other) and an absent response field.
Zeilenga LDAP "Who am I?" [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
As described in [RFC2251] and [RFC2829], an LDAP session has an
"anonymous" association until the client has been successfully
authenticated using the Bind operation. Clients MUST NOT invoke the
"Who Am I?" operation while any Bind operation is in progress,
including between two Bind requests made as part of a multi-stage Bind
operation.
4. Extending the "Who am I?" operation with controls
Future specifications may extend the "Who am I?" operation using the
control mechanism. When extended by controls, the "Who am I?"
operation requests and returns the authorization identity the server
associates with the client in a particular context indicated by the
controls.
4.1. Proxied Authorization Control
The Proxied Authorization Control [PROXYCTL] is used by clients to
request that the operation it is attached to operates under the
authorization of an assumed identity. The client provides the
identity to assume in the Proxied Authorization request control. If
the client is authorized to assume the requested identity, the server
executes the operation as if the requested identity had issued the
operation.
As servers often map the asserted authzId to another identity
[RFC2829], it is desirable to request the server provide the authzId
it associates with the assumed identity.
When a Proxied Authorization Control is be attached to the "Who Am I?"
operation, the operation requests the return of the authzid the server
associates with the identity asserted in the Proxied Authorization
Control. The TBD result code is used to indicate that the server does
not allow the client to assume the asserted identity. [[Note to RFC
Editor: TBD is to be replaced with the name/code assigned by IANA for
[PROXYCTL] use.]]
5. Security Considerations
Identities associated with users may be sensitive information. When
so, security layers [RFC2829][RFC2830] should be established to
protect this information. This mechanism is specifically designed to
allow security layers established by a Bind operation to protect the
integrity and/or confidentiality of the authorization identity.
Zeilenga LDAP "Who am I?" [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
Servers may place access control or other restrictions upon the use of
this operation.
As with any other extended operations, general LDAP considerations
apply. These are detailed in [RFC2251], [RFC2829], and [RFC2830].
6. IANA Considerations
No IANA assignments are requested.
This document uses the OID 1.3.6.1.4.1.4203.1.11.3 to identify the
LDAP "Who Am I? extended operation. This OID was assigned [ASSIGN] by
OpenLDAP Foundation under its IANA assigned private enterprise
allocation [PRIVATE] for use in this specification.
7. Acknowledgment
This document borrows from prior work in this area including
"Authentication Response Control" [AUTHCTL] by Rob Weltman, Mark Smith
and Mark Wahl.
8. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
9. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
"Authentication Methods for LDAP", RFC 2829, June 2000.
[RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
[PROXYCTL] R. Weltman, "LDAP Proxied Authentication Control", draft-
weltman-ldapv3-proxy-xx.txt (a work in progress).
Zeilenga LDAP "Who am I?" [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
10. Informative References
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[AUTHCTL] R. Weltman, M. Smith, M. Wahl, "LDAP Authentication
Response Control", draft-weltman-ldapv3-auth-response-
xx.txt (a work in progress).
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga LDAP "Who am I?" [Page 6]

395
doc/drafts/draft-zeilenga-ldap-cancel-xx.txt Normal file
View file

@ -0,0 +1,395 @@
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]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
Protocol elements are described using ASN.1 [X.680]. The term
"BER-encoded" means the element is to be encoded using the Basic
Encoding Rules [X.690] under the restrictions detailed in Section 5.1
of [RFC2251].
1. Background and Intent of Use
LDAP [RFC2251] provides an Abandon operation which clients may use to
cancel other operations. The Abandon operation does not have a
response and also calls for there to be no response of the abandoned
operation. These semantics provide the client with no clear
indication of the outcome of the Abandon operation.
X.511 DAP [X.511] provides an Abandon operation which does have a
response and also requires the abandoned operation to return a
response with indicating it was canceled. The Cancel operation is
modeled after the DAP Abandon operation.
The Cancel operation SHOULD be used instead of the LDAP Abandon
operation when the client needs an indication of the outcome. This
operation may be used to cancel both interrogation and update
operations.
4. Cancel Operation
The Cancel operation is defined as a LDAPv3 Extended Operation
[RFC2251, Section 4.12] identified by the OBJECT IDENTIFIER cancelOID.
This section details the syntax of the Cancel request and response
messages and defines additional LDAP resultCodes.
cancelOID OBJECT IDENTIFIER ::= IANA-ASSIGNED
cancelRequestValue ::= SEQUENCE {
cancelID MessageID
}
4.1. Cancel Request
The Cancel request is an ExtendedRequest with the requestName field
Zeilenga LDAP Cancel [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
containing cancelOID OID and a requestValue field which contains a
cancelRequestValue value encoded per [RFC2251, Section 5.1]. The
cancelID field contains the message id associated with the operation
to be canceled.
4.2. Cancel Response
A Cancel response is an ExtendedResponse where the responseName and
response fields are absent.
4.3. Additional Result Codes
Implementations of this specification SHALL recognize the following
additional resultCode values:
canceled (IANA-ASSIGNED-1)
noSuchOperation (IANA-ASSIGNED-2)
tooLate (IANA-ASSIGNED-3)
cannotCancel (IANA-ASSIGNED-4)
5. Operational Semantics
The function of the Cancel Operation is to request that the server
cancel an outstanding operation issued within the same session.
The client requests the cancelation of an outstanding operation by
issuing a Cancel Response with a cancelID with the message id
identifying the outstanding operation. The Cancel Request itself has
a distinct message id. Clients SHOULD NOT request cancelation of an
operation multiple times.
If the server is unable to parse the requestValue or the requestValue
is absent, the server shall return protocolError.
If the server is willing and able to cancel the outstanding operation
identified by the cancelId, the server SHALL return a Cancel Response
with a success resultCode and the canceled operation SHALL fail with
canceled resultCode. Otherwise the Cancel Response SHALL have a
non-success resultCode and SHALL NOT have impact upon the outstanding
operation (if it exists).
The server SHALL return noSuchOperation if it has no knowledge of the
operation requested to be canceled.
The server SHALL return cannotCancel if the identified operation does
Zeilenga LDAP Cancel [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
not support cancelation or the cancel operation could not be
performed. The following classes of operations are not cancelable:
- operations which have no response,
- operations which associate or disassociate authentication and/or
authorization associations,
- operations which establish or tear-down security services, and
- operations which abandon or cancel other operations.
Specifically, Abandon, Bind, Start TLS [RFC2830], Unbind and Cancel
operations are not cancelable.
If the result of the outstanding operation has been determined by the
server, the outstanding operation SHALL NOT be canceled and the cancel
operation SHALL result in tooLate.
Servers SHOULD indicate their support for this extended operation by
providing cancelOID as a value of the supportedExtension attribute
type in their root DSE. A server MAY choose to advertise this
extension only when the client is authorized and/or has established
the necessary security protections to use this operation. Clients
SHOULD verify the server implements this extended operation prior to
attempting the operation by asserting the supportedExtension attribute
contains a value of cancelOID.
6. Security Considerations
This operation is intended to allow a user to cancel operations they
previously issued. No user should be allowed to cancel an operation
issued by another user (within the same session or not). However, as
this operation may only be used to cancel within the same session and
LDAP requires operations to be abandoned upon bind requests, this is a
non-issue.
Some operations should not be cancelable for security reasons. This
specification disallows cancelation of Bind operation and Start TLS
extended operation so as to avoid adding complexity to authentication,
authorization, and security layer semantics. Designers of future
extended operations and/or controls SHOULD disallow abandonment and
cancelation when appropriate.
7. IANA Considerations
Zeilenga LDAP Cancel [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
7.1. Object Identifiers
It is requested that IANA register a Directory Number OID for use in
this document upon Standards Action by the IESG. This OID will be
used to identify the LDAP Cancel extended operation as indicated
above. The following registration template is suggested:
Subject: Request for LDAP OID Registration
Person & email address to contact for further information:
Kurt Zeilenga <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]
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]
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]

507
doc/drafts/draft-zeilenga-ldap-collective-xx.txt Normal file
View file

@ -0,0 +1,507 @@
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]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
Conventions
Schema definitions are provided using LDAPv3 description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
1. Introduction
In X.500, a collective attribute is "a user attribute whose values are
the same for each member of an entry collection" [X.501]. This
document details their use in the Lightweight Directory Access
Protocol (LDAP) [LDAPTS].
1.1. Entry Collections
A collection of entries is a grouping of object and alias entries
based upon common properties or shared relationship between the
corresponding entries which share certain attributes. An entry
collection consists of all entries within scope of a collective
attributes subentry [SUBENTRY]. An entry can belong to several entry
collections.
1.2. Collective Attributes
Attributes shared by the entries comprising an entry collection are
called collective attributes. Values of collective attributes are
visible but not updateable to clients accessing entries within the
collection. Collective attributes are updated (i.e. modified) via
their associated collective attributes subentry.
When an entry belongs to multiple entry collections, the entry's
values of each collective attribute are combined such that independent
sources of these values are not manifested to clients.
Entries can specifically exclude a particular collective attribute by
listing the attribute as a value of the collectiveExclusions
attribute. Like other user attributes, collective attributes are
subject to a variety of controls including access, administrative, and
content controls.
Zeilenga draft-zeilenga-ldap-collective-07 [Page 2]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
2. System Schema for Collective Attributes
The following operational attributes are used to manage Collective
Attributes. LDAP servers [LDAPTS] MUST act in accordance with the
X.500 Directory Models [X.501] when providing this service.
2.1. collectiveAttributeSubentry
Subentries of this object class are used to administer collective
attributes and are referred to as collective attribute subentries.
( 2.5.20.2 NAME 'collectiveAttributeSubentry' AUXILIARY )
A collective attribute subentry SHOULD contain at least one collective
attribute. The collective attributes contained within a collective
attribute subentry are available for finding, searching, and
comparison at every entry within the scope of the subentry. The
collective attributes, however, are administered (e.g. modified) via
the subentry.
Implementations of this specification SHOULD support collective
attribute subentries in both collectiveAttributeSpecificArea
(2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative
areas [SUBENTRY][X.501].
2.2. collectiveAttributeSubentries
The collectiveAttributeSubentries operational attribute identifies all
collective attribute subentries that affect the entry.
( 2.5.18.12 NAME 'collectiveAttributeSubentries'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE directoryOperation NO-USER-MODIFICATION )
2.3. collectiveExclusions
The collectiveExclusions operational attribute allows particular
collective attributes to be excluded from an entry. It MAY appear in
any entry and MAY have multiple values.
( 2.5.18.7 NAME 'collectiveExclusions'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE directoryOperation )
Zeilenga draft-zeilenga-ldap-collective-07 [Page 3]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
The descriptor excludeAllCollectiveAttributes is associated with the
OID 2.5.18.0. When this descriptor or OID is present as a value of
the collectiveExclusions attribute, all collective attributes are
excluded from an entry.
3. Collective Attribute Types
A userApplications attribute type can be defined to be COLLECTIVE
[RFC2252]. This indicates that the same attribute values will appear
in the entries of an entry collection subject to the use of the
collectiveExclusions attribute and other administrative controls.
These administrative controls MAY include DIT Content Rules, if
implemented.
Collective attribute types are commonly defined as subtypes of non-
collective attribute types. By convention, collective attributes are
named by prefixing the name of their non-collective supertype with
"c-". For example, the collective telephone attribute is named
c-TelephoneNumber after its non-collective supertype telephoneNumber.
Non-collective attributes types SHALL NOT subtype collective
attributes.
Collective attributes SHALL NOT be SINGLE-VALUED. Collective
attribute types SHALL NOT appear in the attribute types of an object
class definition.
Operational attributes SHALL NOT be defined to be collective.
The remainder of section provides a summary of collective attributes
derived from those defined in [X.520]. The SUPerior attribute types
are described in [RFC 2256] for use with LDAP.
Implementations of this specification SHOULD support the following
collective attributes and MAY support additional collective
attributes.
3.1. Collective Locality Name
The c-l attribute type specifies a locality name for a collection of
entries.
( 2.5.4.7.1 NAME 'c-l'
SUP l COLLECTIVE )
Zeilenga draft-zeilenga-ldap-collective-07 [Page 4]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
3.2. Collective State or Province Name
The c-st attribute type specifies a state or province name for a
collection of entries.
( 2.5.4.8.1 NAME 'c-st'
SUP st COLLECTIVE )
3.3. Collective Street Address
The c-street attribute type specifies a street address for a
collection of entries.
( 2.5.4.9.1 NAME 'c-street'
SUP street COLLECTIVE )
3.4. Collective Organization Name
The c-o attribute type specifies an organization name for a collection
of entries.
( 2.5.4.10.1 NAME 'c-o'
SUP o COLLECTIVE )
3.5. Collective Organizational Unit Name
The c-ou attribute type specifies an organizational unit name for a
collection of entries.
( 2.5.4.11.1 NAME 'c-ou'
SUP ou COLLECTIVE )
3.6. Collective Postal Address
The c-PostalAddress attribute type specifies a postal address for a
collection of entries.
( 2.5.4.16.1 NAME 'c-PostalAddress'
SUP postalAddress COLLECTIVE )
3.7. Collective Postal Code
The c-PostalCode attribute type specifies a postal code for a
Zeilenga draft-zeilenga-ldap-collective-07 [Page 5]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
collection of entries.
( 2.5.4.17.1 NAME 'c-PostalCode'
SUP postalCode COLLECTIVE )
3.8. Collective Post Office Box
The c-PostOfficeBox attribute type specifies a post office box for a
collection of entries.
( 2.5.4.18.1 NAME 'c-PostOfficeBox'
SUP postOfficeBox COLLECTIVE )
3.9. Collective Physical Delivery Office Name
The c-PhysicalDeliveryOfficeName attribute type specifies a physical
delivery office name for a collection of entries.
( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName'
SUP physicalDeliveryOfficeName COLLECTIVE )
3.10. Collective Telephone Number
The c-TelephoneNumber attribute type specifies a telephone number for
a collection of entries.
( 2.5.4.20.1 NAME 'c-TelephoneNumber'
SUP telephoneNumber COLLECTIVE )
3.11. Collective Telex Number
The c-TelexNumber attribute type specifies a telex number for a
collection of entries.
( 2.5.4.21.1 NAME 'c-TelexNumber'
SUP telexNumber COLLECTIVE )
3.13. Collective Facsimile Telephone Number
The c-FacsimileTelephoneNumber attribute type specifies a facsimile
telephone number for a collection of entries.
( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber'
Zeilenga draft-zeilenga-ldap-collective-07 [Page 6]
INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
SUP facsimileTelephoneNumber COLLECTIVE )
3.14. Collective International ISDN Number
The c-InternationalISDNNumber attribute type specifies an
international ISDN number for a collection of entries.
( 2.5.4.25.1 NAME 'c-InternationalISDNNumber'
SUP internationalISDNNumber COLLECTIVE )
4. Security Considerations
Collective attributes are not believed to introduce any additional
security considerations to LDAP [LDAPTS].
5. IANA Considerations
It is requested that IANA register the LDAP descriptors used in this
document per the following registration template:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <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]
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]
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]

227
doc/drafts/draft-zeilenga-ldap-features-xx.txt Normal file
View file

@ -0,0 +1,227 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 May 2002
Feature Discovery in LDAP
<draft-zeilenga-ldap-features-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extension Working Group
mailing list <ietf-ldapext@netscape.com>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Abstract
The Lightweight Directory Access Protocol (LDAP) is an extensible
protocol with numerous elective features. This document introduces a
general mechanism for discovery of elective features and extensions
which cannot be discovered using existing mechanisms.
Zeilenga draft-zeilenga-ldap-features-03 [Page 1]
INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
1. Background and Intended Use
LDAP [RFC2251] is an extensible protocol with numerous elective
features. LDAP provides mechanisms for a client to discover supported
protocol versions, controls, extended operations, SASL mechanisms, and
subschema information. However, these mechanisms are not designed to
support general feature discovery.
This document describes a simple, general-purpose mechanism which
clients may use to discover the set of features supported by a server.
Schema definitions are provided using LDAPv3 description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
2. Discovery of supported features
Each feature whose support may be discovered SHALL be identified by an
Object Identifier (OID). A server advertises its support for a given
feature by providing the OID associated with the feature as a value of
the supportedFeatures attribute held in the root DSE. A client may
examine the values of this attribute to determine if a particular
feature is supported by the server.
The supportedFeatures attribute type is described as follows:
( 1.3.6.1.4.1.4203.1.3.5
NAME 'supportedFeatures'
DESC 'features supported by the server'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
Servers MUST be capable of recognizing this attribute type by the name
'supportedFeatures'. Servers MAY recognize the attribute type by
other names.
3. Security Considerations
As rogue clients can discover features of a server by other means
(such as by trial and error), this feature discovery mechanism is not
believed to introduce any new security risk to LDAP.
Zeilenga draft-zeilenga-ldap-features-03 [Page 2]
INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
4. IANA Considerations
It is requested that IANA register the LDAP 'supportedFeatures'
descriptor used in this document per the following registration
template:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): supportedFeatures
Object Identifier: 1.3.6.1.4.1.4203.1.3.5
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Attribute Type
Specification: RFCXXXX
Author/Change Controller: IESG
This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA
assigned private enterprise allocation [PRIVATE] for use in this
specification.
5. Acknowledgment
This document is based upon input from the IETF LDAPext working group.
6. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
7. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
8. Informative References
Zeilenga draft-zeilenga-ldap-features-03 [Page 3]
INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
Full Copyright
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga draft-zeilenga-ldap-features-03 [Page 4]

743
doc/drafts/draft-zeilenga-ldap-namedref-xx.txt Normal file
View file

@ -0,0 +1,743 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires: 20 May 2002 20 November 2001
Named Subordinate References in LDAP Directories
<draft-zeilenga-ldap-namedref-05.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extension Working Group
mailing list <ietf-ldapext@netscape.com>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2001, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Abstract
This document details schema and protocol elements for representing
and managing named subordinate references in LDAP directories.
Conventions
Zeilenga LDAP NamedRef [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
Schema definitions are provided using LDAPv3 description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD",
"SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be
interpreted as described in BCP 14 [RFC2119].
1. Background and Intended Usage
The broadening of interest in LDAP (Lightweight Directory Access
Protocol) [RFC2251] directories beyond their use as front ends to
X.500 [X.500] directories has created a need to represent knowledge
information in a more general way. Knowledge information is
information about one or more servers maintained in another server,
used to link servers and services together.
This document details schema and protocol elements for representing
and manipulating named subordinate references in LDAP directories. A
referral object is used to hold subordinate reference information in
the directory. These referral objects hold one or more URIs [RFC2396]
contained in values of the ref attribute type and are used to generate
protocol referrals and continuations.
A control, ManageDsaIT, is defined to allow manipulation of referral
and other special objects as normal objects. As the name of control
implies, it is intended to be analogous to the ManageDsaIT service
option described in X.511(97) [X.511].
Other forms of knowledge information are not detailed by this
document. These forms may be described in subsequent documents.
This document details subordinate referral processing requirements for
servers. This document does not describe protocol syntax and
semantics. This is detailed in RFC 2251 [RFC2251].
This document does not detail use of subordinate knowledge references
to support replicated environments nor distributed operations (e.g.,
chaining of operations from one server to other servers).
2. Schema
2.1. The referral Object Class
A referral object is a directory entry whose structural object class
is (or is derived from) the referral object class.
Zeilenga LDAP NamedRef [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
( 2.16.840.1.113730.3.2.6
NAME 'referral'
DESC 'named subordinate reference object'
STRUCTURAL
MUST ref )
The referral object class is a structural object class used to
represent a subordinate reference in the directory. The referral
object class SHOULD be used in conjunction with the extensibleObject
object class to support the naming attributes used in the entry's
Distinguished Name (DN) [RFC2253]. Referral objects are directory
entries whose structural object class is (or is derived from)
referral.
Referral objects are normally instantiated at DSEs immediately
subordinate to object entries within a naming context held by the DSA.
Referral objects are analogous to X.500 subordinate knowledge (subr)
DSEs [X.501].
In the presence of a ManageDsaIT control, referral objects are treated
as normal entries as described in section 3. Note that the ref
attribute is operational and will only returned in a search entry
response when requested.
In the absence of a ManageDsaIT control, the content of referral
objects are used to construct referrals and search references as
described in section 4 and, as such, the referral entries are not
themselves visible to clients.
2.2 The ref Attribute Type
( 2.16.840.1.113730.3.1.34
NAME 'ref'
DESC 'named reference - a labeledURI'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE distributedOperation )
The ref attribute type has directoryString syntax and is case
sensitive. The ref attribute is multi-valued. Values placed in the
attribute MUST conform to the specification given for the labeledURI
attribute [RFC2079]. The labeledURI specification defines a format
that is a URI, optionally followed by whitespace and a label. This
document does not make use of the label portion of the syntax. Future
documents MAY enable new functionality by imposing additional
structure on the label portion of the syntax as it appears in the ref
attribute.
Zeilenga LDAP NamedRef [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
If the URI contained in a ref attribute value refers to a LDAP
[RFC2251] server, it MUST be in the form of a LDAP URL [RFC2255]. The
LDAP URL SHOULD NOT contain an explicit scope specifier, filter,
attribute description list, or any extensions. The LDAP URL SHOULD
contain a non-empty DN. The handling of LDAP URLs with absent or
empty DN parts or with explicit scope specifier is not defined by this
specification.
Other URI schemes MAY be used so long as all operations returning
referrals based upon the value could be performed. This document does
not detail use of non-LDAP URIs. This is left to future
specifications.
The referential integrity of the URI SHOULD NOT be validated by the
server holding or returning the URI (whether as a value of the
attribute or as part of a referral result or search reference
response).
When returning a referral result or search continuation, the server
MUST NOT return the separator or label portions of the attribute
values as part of the reference. When the attribute contains multiple
values, the URI part of each value is used to construct the referral
result or search continuation.
The ref attribute values SHOULD NOT be used as a relative
name-component of an entry's DN [RFC2253].
This document uses the ref attribute in conjunction with the referral
object class to represent subordinate references. The ref attribute
may be used for other purposes as defined by other documents.
3. The ManageDsaIT Control
The client may provide the ManageDsaIT control with an operation to
indicate that the operation is intended to manage objects within the
DSA (server) Information Tree. The control causes Directory-specific
entries (DSEs), regardless of type, to be treated as normal entries
allowing clients to interrogate and update these entries using LDAP
operations.
A client MAY specify the following control when issuing an add,
compare, delete, modify, modifyDN, search request or an extended
operation for which the control is defined.
The control type is 2.16.840.1.113730.3.4.2. The control criticality
may be TRUE or, if FALSE, absent. The control value is absent.
Zeilenga LDAP NamedRef [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
When the control is present in the request, the server SHALL NOT
generate a referral or continuation reference based upon information
held in referral objects and instead SHALL treat the referral object
as a normal entry. The server, however, is still free to return
referrals for other reasons. When not present, referral objects SHALL
be handled as described above.
The control MAY cause other objects to be treated as normal entries as
defined by subsequent documents.
4. Named Subordinate References
A named subordinate reference is constructed by instantiating a
referral object in the referencing server with ref attribute values
which point to the corresponding subtree maintained in the referenced
server. In general, the name of the referral object is the same as
the referenced object and this referenced object is a context prefix
[X.501].
That is, if server A holds "DC=example,DC=net" and server B holds
"DC=sub,DC=example,DC=net", server A may contain a referral object
named "DC=sub,DC=example,DC=net" which contains a ref attribute with
value of "ldap://B/DC=sub,DC=example,DC=net".
dn: DC=sub,DC=example,DC=net
dc: sub
ref: ldap://B/DC=sub,DC=example,DC=net
objectClass: referral
objectClass: extensibleObject
Typically the DN of the referral object and the DN of the object in
the referenced server are the same.
If the ref attribute has multiple values, all the DNs contained within
the LDAP URLs SHOULD be equivalent. Administrators SHOULD avoid
configuring naming loops using referrals.
Named references MUST be treated as normal entries if the request
includes the ManageDsaIT control as described in section 3.
5. Scenarios
The following sections contain specifications of how referral objects
should be used in different scenarios followed by examples that
illustrate that usage. The scenarios described here consist of
referral object handling when finding target of a non-search
Zeilenga LDAP NamedRef [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
operation, when finding the base of a search operation, and when
generating search references. Lastly, other operation processing
considerations are presented.
It is to be noted that, in this document, a search operation is
conceptually divided into two distinct, sequential phases: (1) finding
the base object where the search is to begin, and (2) performing the
search itself. The first phase is similar to, but not the same as,
finding the target of a non-search operation.
It should also be noted that the ref attribute may have multiple
values and, where these sections refer to a single ref attribute
value, multiple ref attribute values may be substituted and SHOULD be
processed and returned (in any order) as a group in a referral or
search reference in the same way as described for a single ref
attribute value.
Search references returned for a given request may be returned in any
order.
5.1. Example Configuration
For example, suppose the contacted server (hosta) holds the entry
"O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW" and the following
referral objects:
dn: OU=People,O=MNN,C=WW
ou: People
ref: ldap://hostb/OU=People,O=MNN,C=US
ref: ldap://hostc/OU=People,O=MNN,C=US
objectClass: referral
objectClass: extensibleObject
dn: OU=Roles,O=MNN,C=WW
ou: Roles
ref: ldap://hostd/OU=Roles,O=MNN,C=WW
objectClass: referral
objectClass: extensibleObject
The first referral object provides the server with the knowledge that
subtree "OU=People,O=MNN,C=WW" is held by hostb and hostc (e.g., one
is the master and the other a shadow). The second referral object
provides the server with the knowledge that the subtree
"OU=Roles,O=MNN,C=WW" is held by hostd.
Also, in the context of this document, the "nearest naming context"
means the deepest context which the object is within. That is, if the
Zeilenga LDAP NamedRef [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
object is within multiple naming contexts, the nearest naming context
is the one which is subordinate to all other naming contexts the
object is within.
5.2. Target object considerations
This section details referral handling for add, compare, delete,
modify, and modify DN operations. If the client requests any of these
operations, there are four cases that the server must handle with
respect to the target object.
The DN part MUST be modified such that it refers to the appropriate
target in the referenced server (as detailed below). Even where the
DN to be returned is the same as the target DN, the DN part SHOULD NOT
be trimmed.
In cases where the URI to be returned is a LDAP URL, the server SHOULD
trim any present scope, filter, or attribute list from the URI before
returning it. Critical extensions MUST NOT be trimmed or modified.
Case 1: The target object is not held by the server and is not within
or subordinate to any naming context nor subordinate to any
referral object held by the server.
The server SHOULD process the request normally as appropriate for
a non-existent base which is not within any naming context of the
server (generally return noSuchObject or a referral based upon
superior knowledge reference information). This document does not
detail management or processing of superior knowledge reference
information.
Case 2: The target object is held by the server and is a referral
object.
The server SHOULD return the URI value contained in the ref
attribute of the referral object appropriately modified as
described above.
Example: If the client issues a modify request for the target object
of "OU=People,O=MNN,c=WW", the server will return:
ModifyResponse (referral) {
ldap://hostb/OU=People,O=MNN,C=WW
ldap://hostc/OU=People,O=MNN,C=WW
}
Zeilenga LDAP NamedRef [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
Case 3: The target object is not held by the server, but the nearest
naming context contains no referral object which the target object
is subordinate to.
If the nearest naming context contains no referral object which
the target is subordinate to, the server SHOULD process the
request as appropriate for a nonexistent target (generally return
noSuchObject).
Case 4: The target object is not held by the server, but the nearest
naming context contains a referral object which the target object
is subordinate to.
If a client requests an operation for which the target object is
not held by the server and the nearest naming context contains a
referral object which the target object is subordinate to, the
server SHOULD return a referral response constructed from the URI
portion of the ref value of the referral object.
Example: If the client issues an add request where the target object
has a DN of "CN=Manager,OU=Roles,O=MNN,C=WW", the server will
return
AddResponse (referral) {
ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW"
}
Note that the DN part of the LDAP URL is modified such that it
refers to the appropriate entry in the referenced server.
5.3. Base Object Considerations
This section details referral handling for base object processing
within search operations. Like target object considerations for non-
search operations, there are the four cases.
In cases where the URI to be returned is a LDAP URL, the server MUST
provide an explicit scope specifier from the LDAP URL prior to
returning it. In addition, the DN part MUST be modified such that it
refers to the appropriate target in the referenced server (as detailed
below).
If aliasing dereferencing was necessary in finding the referral
object, the DN part of the URI MUST be replaced with the base DN as
modified by the alias dereferencing such that the return URL refers to
the new target object per [RFC2251, 4.1.11].
Zeilenga LDAP NamedRef [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
Critical extensions MUST NOT be trimmed nor modified.
Case 1: The base object is not held by the server and is not within
nor subordinate to any naming context held by the server.
The server SHOULD process the request normally as appropriate for
a non-existent base which not within any naming context of the
server (generally return a superior referral or noSuchObject).
This document does not detail management or processing of superior
knowledge references.
Case 2: The base object is held by the server and is a referral
object.
The server SHOULD return the URI value contained in the ref
attribute of the referral object appropriately modified as
described above.
Example: If the client issues a subtree search in which the base
object is "OU=Roles,O=MNN,C=WW", the server will return
SearchResultDone (referral) {
ldap://hostd/OU=Roles,O=MNN,C=WW??sub
}
If the client were to issue a base or oneLevel search instead of
subtree, the returned LDAP URL would explicitly specify "base" or
"one", respectively, instead of "sub".
Case 3: The base object is not held by the server, but the nearest
naming context contains no referral object which the base object
is subordinate to.
If the nearest naming context contains no referral object which
the base is subordinate to, the request SHOULD be processed
normally as appropriate for a nonexistent base (generally return
noSuchObject).
Case 4: The base object is not held by the server, but the nearest
naming context contains a referral object which the base object is
subordinate to.
If a client requests an operation for which the target object is
not held by the server and the nearest naming context contains a
referral object which the target object is subordinate to, the
server SHOULD return a referral response which is constructed from
the URI portion of the ref value of the referral object.
Zeilenga LDAP NamedRef [Page 9]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
Example: If the client issues a base search request for
"CN=Manager,OU=Roles,O=MNN,C=WW", the server will return
SearchResultDone (referral) {
ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base"
}
If the client were to issue a subtree or oneLevel search instead
of subtree, the returned LDAP URL would explicitly specify "sub"
or "one", respectively, instead of "base".
Note that the DN part of the LDAP URL is modified such that it
refers to the appropriate entry in the referenced server.
5.4. Search Continuation Considerations
For search operations, once the base object has been found and
determined not to be a referral object, the search may progress. Any
entry matching the filter and scope of the search which is not a
referral object is returned to the client normally as described in
[RFC2251].
For each referral object within the requested scope, regardless of the
search filter, the server SHOULD return a SearchResultReference which
is constructed from the URI component of values of the ref attribute.
If the URI component is not a LDAP URL, it should be returned as is.
If the LDAP URL's DN part is absent or empty, the DN part must be
modified to contain the DN of the referral object. If the URI
component is a LDAP URL, the URI SHOULD be modified to add an explicit
scope specifier.
Subtree Example:
If a client requests a subtree search of "O=MNN,C=WW", then in
addition to any entries within scope which match the filter, hosta
will also return two search references as the two referral objects
are within scope. One possible response might be:
SearchEntry for O=MNN,C=WW
SearchResultReference {
ldap://hostb/OU=People,O=MNN,C=WW??sub
ldap://hostc/OU=People,O=MNN,C=WW??sub
}
SearchEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW??sub
}
Zeilenga LDAP NamedRef [Page 10]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
SearchResultDone (success)
One Level Example:
If a client requests a one level search of "O=MNN,C=WW" then, in
addition to any entries one level below the "O=MNN,C=WW" entry
matching the filter, the server will also return two search
references as the two referral objects are within scope. One
possible sequence is shown:
SearchResultReference {
ldap://hostb/OU=People,O=MNN,C=WW??base
ldap://hostc/OU=People,O=MNN,C=WW??base
}
SearchEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW??base
}
SearchResultDone (success)
Note: Unlike the examples in Section 4.5.3.1 of RFC 2251, the LDAP
URLs returned with the SearchResultReference messages contain,
as required by this specification, an explicit scope specifier.
5.6. Other Considerations
This section details processing considerations for other operations.
5.6.1 Bind
Servers SHOULD NOT return referral result code if the bind name (or
authentication identity or authorization identity) is (or is
subordinate to) a referral object but MAY use the knowledge
information to process the bind request (such as in support a future
distributed operation specification). Where the server makes no use
of the knowledge information, the server processes the request
normally as appropriate for a non-existent authentication or
authorization identity (e.g., return invalidCredentials).
5.6.2 Modify DN
If the newSuperior is a referral object or is subordinate to a
referral object, the server SHOULD return affectsMultipleDSAs. If the
newRDN already exists but is a referral object, the server SHOULD
return affectsMultipleDSAs instead of entryAlreadyExists.
Zeilenga LDAP NamedRef [Page 11]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
6. Security Considerations
This document defines mechanisms that can be used to tie LDAP (and
other) servers together. The information used to tie services
together should be protected from unauthorized modification. If the
server topology information is not public information, it should be
protected from unauthorized disclosure as well.
7. Acknowledgments
This document borrows heavily from previous work by IETF LDAPext
Working Group. In particular, this document is based upon "Named
Referral in LDAP Directories" (an expired Internet Draft) by
Christopher Lukas, Tim Howes, Michael Roszkowski, Mark C. Smith, and
Mark Wahl.
8. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
9. Normative References
[RFC2079] M. Smith, "Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers (URIs)",
RFC 2079, January 1997.
[RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
[RFC2253] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished
Names", RFC 2253, December 1997.
[RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255,
December, 1997.
Zeilenga LDAP NamedRef [Page 12]
INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
[RFC2396] Berners-Lee, T., R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[X.501] ITU-T, "The Directory: Models", X.501, 1993.
10. Informative References
[X.500] ITU-T, "The Directory: Overview of Concepts, Models, and
Services", X.500, 1993.
[X.511] ITU-T, "The Directory: Abstract Service Definition", X.500,
1993.
Copyright 2001, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga LDAP NamedRef [Page 13]

227
doc/drafts/draft-zeilenga-ldap-opattrs-xx.txt Normal file
View file

@ -0,0 +1,227 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 May 2002
LDAPv3: All Operational Attributes
<draft-zeilenga-ldap-opattrs-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions Working Group
mailing list <ietf-ldapext@netscape.com>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Abstract
The Lightweight Directory Access Protocol (LDAP) supports a mechanism
for requesting the return of all user attributes but does not all
operational attributes. This document describes an LDAP extension
which clients may use to request the return of all operational
attributes.
Zeilenga LDAP All Op Attrs [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
1. Overview
X.500 [X.500] provides a mechanism for clients to request all
operational attributes be returned with entries provided in response
to a search operation. This mechanism is often used by clients to
discover which operational attributes are present in an entry.
This documents extends LDAP [RFC2251] to provide a simple mechanism
which clients may use to request the return of all operation
attributes. The mechanism is designed for use with existing general
purpose LDAP clients (including web browsers which support LDAP URLs)
and existing LDAP API.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
2. All Operational Attributes
The presence of the attribute description "+" (ASCII 43) in the list
of attributes in a Search Request SHALL signify a request for the
return of all operational attributes.
As with all search requests, client implementors should note that
results may not include all requested attributes due to access
controls or other restrictions. Clients implementors should also note
that certain operational attributes may be returned only if requested
by name even when "+" is present. This is because some operational
attributes are very expensive to return.
Servers supporting this feature SHOULD publish the Object Identifier
1.3.6.1.4.1.4203.1.5.1 as a value of the supportedFeatures [FEATURES]
attribute in the root DSE.
3. Interoperability Considerations
This mechanism is specifically designed to allow users to request all
operational attributes using existing LDAP clients. In particular,
the mechanism is designed to be compatible with existing general
purpose LDAP clients includes web browsers which support LDAP URLs
[RFC2255].
The addition of this mechanism to LDAPv3 is believed not to cause any
significant interoperability issues (this has been confirmed through
testing). Servers which have yet to implement this specification
should ignore the "+" as an unrecognized attribute description per
Zeilenga LDAP All Op Attrs [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
[RFC2251, Section 4.5.1]. From the client's perspective, a server
which does not return all operational attributes when "+" is requested
should be viewed as having other restrictions.
It is also noted that this mechanism is believed to require no
modification of existing LDAP APIs.
4. Security Considerations
This document provides a mechanism which clients may use to discover
operational attributes. Those relying on security by obscurity SHOULD
implement appropriate access controls to restricts access to
operational attributes per local policy.
5. IANA Considerations
No IANA assignments are requested.
This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the
feature described above. This OID was assigned [ASSIGN] by OpenLDAP
Foundation under its IANA assigned private enterprise allocation
[PRIVATE] for use in this specification.
6. Acknowledgment
The "+" mechanism is believed to have been first suggested by Bruce
Greenblatt in a November 1998 post to the IETF LDAPext Working Group
mailing list.
7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
8. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
Zeilenga LDAP All Op Attrs [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP", draft-zeilenga-
ldap-features-xx.txt (a work in progress).
9. Informative References
[RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga LDAP All Op Attrs [Page 4]

787
doc/drafts/draft-zeilenga-ldap-rfc2596-xx.txt Normal file
View file

@ -0,0 +1,787 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 1 March 2002
Obsoletes: RFC 2596
Language Tags and Ranges in LDAP
draft-zeilenga-ldap-rfc2596-01.txt
Status of Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions Working Group
(LDAPext) mailing list <ietf-ldapext@netscape.com>. Please send
editorial comments directly to the document editor
<Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Abstract
It is often desirable to to be able to indicate the natural language
associated with values held in a directory and to be able to query the
directory for values which fulfill the user's language needs. This
document details the use of Language Tags and Ranges in the
Lightweight Directory Access Protocol (LDAP).
Zeilenga Language Tags and Ranges in LDAP [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
1. Background and Intended Use
The Lightweight Directory Access Protocol (LDAP) [Roadmap] provides a
means for clients to interrogate and modify information stored in a
distributed directory system. The information in the directory is
maintained as attributes of entries. Most of these attributes have
syntaxes which are human-readable strings, and it is desirable to be
able to indicate the natural language associated with attribute
values.
This document describes how language tags and ranges [RFC3066] are
carried in LDAP and are to be interpreted by LDAP implementations.
All implementations MUST be prepared to accept language tags and
ranges in the LDAP protocol.
This document replaces RFC 2596. Appendix A summaries changes made
since RFC 2596.
Appendix B discusses differences from X.500(1997) "contexts"
mechanism.
Appendix A and B are provided for information purposes and are not a
normative part of this specification.
The remainder of this section provides a summary of Language Tags,
Language Ranges, and Attribute Descriptions.
1.1. Language Tags
Section 2 of BCP 47 [RFC3066] describes the language tag format which
is used in LDAP. Briefly, it is a string of ASCII alphabetic
characters and hyphens. Examples include "fr", "en-US" and "ja-JP".
Language tags are case insensitive. For example, the language tag
"en-us" is the same as "EN-US".
Section 2 of this document details use of language tags in LDAP.
1.2. Language Ranges
Zeilenga Language Tags and Ranges in LDAP [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
Language ranges are used to specify sets of language tags.
A language range matches a language tag if it exactly equals the tag,
or if it exactly equals a prefix of the tag such that the first
character following the prefix is "-". The special tag "*" matches
all tags.
Due to restrictions upon option naming in LDAP, this document uses a
different language range syntax. However, the semantics of language
ranges in LDAP is consistent with BCP 47.
Section 3 of this document details use of language ranges in LDAP.
1.3. Attribute Descriptions
This section provides an overview of attributes in LDAP. LDAP
attributes are defined in [Models].
An attribute consists of a type, a set of zero or more associated
tagging options, and a set of one or more values. The type and the
options are combined into the AttributeDescription.
AttributeDescriptions can also contain options which are not part of
the attribute, but indicate some other function such as the transfer
encoding.
An attribute with one or more tagging options is a direct subtype of
each attribute of the same with all but one of the tagging options.
If the attribute's type is a direct subtype of some other type, then
the attribute is also a direct subtype of the attribute whose
description consists of the the supertype and all of the tagging
options. That is, CN;x-bar;x-foo is a direct subtype of CN;x-bar,
CN;x-foo, and name;x-bar;x-foo. Note that CN is a subtype of name.
If the attribute description contains an unrecognized option, the
attribute description is treated as an unrecognized attribute type.
As language tags are intended to stored with the attribute, they are
to treated as tagging options as described in Section 2. Language
range are used only to match against language ranges and are not
stored with the attribute. They are not treated tagging options (nor
as transfer options), but as described in Section 3.
2. Use of Language Tags in LDAP
This section describes how LDAP implementations MUST interpret
Zeilenga Language Tags and Ranges in LDAP [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
language tags in performing operations.
Servers which support storing attributes with language tag options in
the Directory Information Tree (DIT) SHOULD allow any attribute type
it recognizes that has the Directory String, IA5 String, or other
textual string syntax to have language tag options associated with it.
Servers MAY allow language options to be associated with other
attributes types.
Clients SHOULD NOT assume servers are capable of storing attributes
with language tags in the directory.
Implementations MUST NOT otherwise interpret the structure of the tag
when comparing two tag, and MUST treat them simply as strings of
characters. Implementations MUST allow any arbitrary string which
conforms to the syntax defined in BCP 47 [RFC3066] to be used as a
language tag.
2.1. Language Tag Options
A language tag option associates a natural language with values of an
attribute. An attribute description MAY contain multiple language tag
options. An entry MAY contain multiple attributes with same attribute
type but different combinations of language tag (and other) options.
A language tag option conforms to the following ABNF [RFC2234]:
language-tag-option = "lang-" Language-Tag
where the Language-Tag production is as defined in BCP 47 [RFC3066].
This production and those it imports from [RFC2234] are provided here
for convenience:
Language-Tag = Primary-subtag *( "-" Subtag )
Primary-subtag = 1*8ALPHA
Subtag = 1*8(ALPHA / DIGIT)
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
A language tag option is a tagging option [Models]. A language tag
option has no effect on the syntax of the attribute's values nor their
transfer encoding.
Zeilenga Language Tags and Ranges in LDAP [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Examples of valid AttributeDescription:
givenName;lang-en-US
CN;lang-ja
SN;lang-de;lang-gem-PFL
O;lang-i-klingon;x-foobar
description;x-foobar
CN
Notes: The last two have no language tag options. The x-foobar option
is fictious and used for example purposes.
2.2. Search Filter
If language tag options are present in an AttributeDescription in an
assertion, then for each entry within scope, the values of each
attribute whose AttributeDescription consists of the same attribute
type or its subtypes and contains each of the presented (and possibly
other) options is to be matched.
Thus for example a filter of an equality match of type
"name;lang-en-US" and assertion value "Billy Ray", against the
following directory entry
dn: SN=Ray,DC=example,DC=com
objectclass: top DOES NOT MATCH (wrong type)
objectclass: person DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
CN;lang-en-US;x-foobar: Billy Ray MATCHES
CN;lang-en;x-foobar: Billy Ray DOES NOT MATCH (differing lang-)
CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
name: Billy Ray DOES NOT MATCH (no lang-)
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (no lang-,
wrong value)
(Note that "CN" and "SN" are subtypes of "name".)
It is noted that providing a language tag option in a search filter
AttributeDescription will filter out desirable values where the tag
does not match exactly. For example, the filter (name;lang-en=Billy
Ray) does NOT match the attribute "name;lang-en-US: Billy Ray".
If the server does not support storing attributes with language tag
options in the DIT, then any assertion which includes a language tag
Zeilenga Language Tags and Ranges in LDAP [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
option will not match as such it is an unrecognized attribute type.
No error would be returned because of this; a presence assertion would
evaluate to FALSE and all other assertions to Undefined.
If no options are specified in the assertion, then only the base
attribute type and the assertion value need match the value in the
directory.
Thus for example a filter of an equality match of type "name" and
assertion value "Billy Ray", against the following directory entry
dn: SN=Ray,DC=example,DC=net
objectclass: top DOES NOT MATCH (wrong type)
objectclass: person DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US;x-foobar: Billy Ray MATCHES
CN;lang-en;x-foobar: Billy Ray MATCHES
CN;x-foobar: Billy Ray MATCHES
name: Billy Ray MATCHES
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (wrong value)
2.3. Requested Attributes in Search
Clients can provide language tag options in AttributeDescription in
the requested attribute list in a search request.
If language tag options are provided in an attribute description, then
only attributes in a directory entry whose attribute descriptions have
the same attribute type or its subtype and the provided language tags
options are to be returned. Thus if a client requests just the
attribute "name;lang-en", the server would return "name;lang-en" and
"CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr".
Clients can provide in the attribute list multiple
AttributeDescription which have the same base attribute type but
different options. For example a client could provide both
"name;lang-en" and "name;lang-fr", and this would permit an attribute
with either language tag option to be returned. Note there would be
no need to provide both "name" and "name;lang-en" since all subtypes
of name would match "name".
If a server does not support storing attributes with language tag
options in the DIT, then any attribute descriptions in the list which
include language tag options are to be ignored, just as if they were
unknown attribute types.
Zeilenga Language Tags and Ranges in LDAP [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
If a request is made specifying all attributes or an attribute is
requested without providing a language tag option, then all attribute
values regardless of their language tag option are returned.
For example, if the client requests a "description" attribute, and a
matching entry contains the following attributes:
objectclass: top
objectclass: organization
O: Software GmbH
description: software
description;lang-en: software products
description;lang-de: Softwareprodukte
postalAddress: Berlin 8001 Germany
postalAddress;lang-de: Berlin 8001 Deutschland
The server would return:
description: software
description;lang-en: software products
description;lang-de: Softwareprodukte
2.4. Compare
Language tag options can be present in an AttributeDescription used in
a compare request AttributeValueAssertion. This is to be treated by
servers the same as the use of language tag options in a search filter
with an equality match, as described in Section 2.2. If there is no
attribute in the entry with the same subtype and language tag options,
the noSuchAttributeType error will be returned.
Thus for example a compare request of type "name" and assertion value
"Johann", against an entry containing the following attributes:
objectclass: top
objectclass: person
givenName;lang-de-DE: Johann
CN: Johann Sibelius
SN: Sibelius
would cause the server to return compareTrue.
However, if the client issued a compare request of type "name;lang-de"
and assertion value "Johann" against the above entry, the request
would fail with the noSuchAttributeType error.
If the server does not support storing attributes with language tag
Zeilenga Language Tags and Ranges in LDAP [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
options in the DIT, then any comparison which includes a language tag
option will always fail to locate an attribute, and
noSuchAttributeType will be returned.
2.5. Add Operation
Clients can provide language options in AttributeDescription in
attributes of a new entry to be created.
A client can provide multiple attributes with the same attribute type
and value, so long as each attribute has a different set of language
tag options.
For example, the following is a legal request.
dn: CN=John Smith,DC=example,DC=com
objectclass: top
objectclass: person
objectclass: residentialPerson
name: John Smith
CN: John Smith
CN;lang-en: John Smith
SN: Smith
SN;lang-en;lang-en-US: Smith
streetAddress: 1 University Street
streetAddress;lang-en: 1 University Street
streetAddress;lang-fr: 1 rue Universite
houseIdentifier;lang-fr: 9e etage
If a server does not support storing language tag options with
attribute values in the DIT, then it MUST treat an
AttributeDescription with a language tag option as an unrecognized
attribute. If the server forbids the addition of unrecognized
attributes then it MUST fail the add request with an appropriate
result code.
2.6. Modify Operation
A client can provide language tag options in an AttributeDescription
as part of a modification element in the modify operation.
Attribute types and language tag options MUST match exactly against
values stored in the directory. For example, if the modification is a
"delete", then if the stored values to be deleted have language tag
options, then those language tag options MUST be provided in the
modify operation, and if the stored values to be deleted do not have
Zeilenga Language Tags and Ranges in LDAP [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
any language tag option, then no language tag option is to be
provided.
If the server does not support storing language tag options with
attribute values in the DIT, then it MUST treat an
AttributeDescription with a language tag option as an unrecognized
attribute, and MUST fail the request with an appropriate result code.
3. Use of Language Ranges in LDAP
Since the publication of RFC 2596, it has become apparent that there
is a need to provide a mechanism for a client to request attributes
based upon set of language tag options whose tags all begin with the
same sequence of language sub-tags.
AttributeDescriptions containing language range options are intended
to be used in attribute value assertions, search attribute lists, and
other places where the client desires to provide an attribute
description matching of a range of language tags associated with
attributes.
A language range option conforms to the following ABNF [RFC2234]:
language-range-option = "lang-" [ Language-Tag "-" ]
where the Language-Tag production is as defined in BCP 47 [RFC3066].
This production and those it imports from [RFC2234] are provided here
for convenience:
Language-Tag = Primary-subtag *( "-" Subtag )
Primary-subtag = 1*8ALPHA
Subtag = 1*8(ALPHA / DIGIT)
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
A language range option matches a language tag option if language
range option less the trailing "-" matches exactly the language tag or
if the language range option (including the trailing "-") matches a
prefix of the language tag option. Note that the language range
option "lang-" matches all language tag options.
Examples of valid AttributeDescription containing language range
options:
Zeilenga Language Tags and Ranges in LDAP [Page 9]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
givenName;lang-en-
CN;lang-
O;lang-x-;x-foobar
A language range option is not a tagging option. Attributes cannot be
stored with language range options. Any attempt to add or update an
attribute description with a language range option SHALL be treated as
an undefined attribute type and result in an error.
A language range option has no effect on the transfer encoding nor on
the syntax of the attribute values.
Servers SHOULD support assertion of language ranges for any attribute
which they allow to stored with language tags.
3.1. Search Filter
If a language range option is present in an AttributeDescription in an
assertion, then for each entry within scope, the values of each
attribute whose AttributeDescription consists of the same attribute
type or its subtypes and contains a language tag option matching the
language range option are to be returned.
Thus for example a filter of an equality match of type "name;lang-en-"
and assertion value "Billy Ray", against the following directory entry
dn: SN=Ray,DC=example,DC=com
objectclass: top DOES NOT MATCH (wrong type)
objectclass: person DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
CN;lang-en-US;x-foobar: Billy Ray MATCHES
CN;lang-en;x-foobar: Billy Ray MATCHES
CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
name: Billy Ray DOES NOT MATCH (no lang-)
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (no lang-,
wrong value)
(Note that "CN" and "SN" are subtypes of "name".)
If the server does not support storing attributes with language tag
options in the DIT, then any assertion which includes a language range
option will not match as it is an unrecognized attribute type. No
error would be returned because of this; a presence filter would
evaluate to FALSE and all other assertions to Undefined.
Zeilenga Language Tags and Ranges in LDAP [Page 10]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
3.2. Requested Attributes in Search
Clients can provide language range options in AttributeDescription in
the requested attribute list in a search request.
If a language range option is provided in an attribute description,
then only attributes in a directory entry whose attribute descriptions
have the same attribute type or its subtype and a language tag option
matching the provided language range option are to be returned. Thus
if a client requests just the attribute "name;lang-en-", the server
would return "name;lang-en-US" and "CN;lang-en;lang-ja" but not "SN"
nor "name;lang-fr".
Clients can provide in the attribute list multiple
AttributeDescription which have the same base attribute type but
different options. For example a client could provide both
"name;lang-en-" and "name;lang-fr-", and this would permit an
attribute whose type was name or subtype of name and with a language
tag option matching either language range option to be returned.
If a server does not support storing attributes with language tag
options in the DIT, then any attribute descriptions in the list which
include language range options are to be ignored, just as if they were
unknown attribute types.
3.3. Compare
Language range options can be present in an AttributeDescription used
in a compare request AttributeValueAssertion. This is to be treated
by servers the same as the use of language range options in a search
filter with an equality match, as described in Section 3.1. If there
is no attribute in the entry with the same subtype and a matching
language tag option, the noSuchAttributeType error will be returned.
Thus for example a compare request of type "name;lang-" and assertion
value "Johann", against the entry with the following attributes:
objectclass: top
objectclass: person
givenName;lang-de-DE: Johann
CN: Johann Sibelius
SN: Sibelius
will cause the server to return compareTrue. (Note that the language
range option "lang-" matches any language tag option.)
However, if the client issued a compare request of type "name;lang-de"
Zeilenga Language Tags and Ranges in LDAP [Page 11]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
and assertion value "Sibelius" against the above entry, the request
would fail with the noSuchAttributeType error.
If the server does not support storing attributes with language tag
options in the DIT, then any comparison which includes a language
range option will always fail to locate an attribute, and
noSuchAttributeType will be returned.
4. Discovering Language Option Support
A server SHOULD indicate that it supports storing attributes with
language tag options in the DIT by publishing OID.TDB as a value of
the supportedFeatures [FEATURES] attribute in the root DSE.
A server SHOULD indicate that it supports language range matching of
attributes with language tag options stored in the DIT by publishing
OID.TDB as a value of the supportedFeatures [FEATURES] attribute in
the root DSE.
A server MAY restrict use of language tag options to a subset of the
attribute types it recognizes. This document does not define a
mechanism for determining which subset of attribute types can be used
with language tag options.
5. Security Considerations
Language tags and range options are used solely to indicate the native
language of values and in querying the directory for values which
fulfill the user's language needed. These options are not known to
raise specific security considerations. However, the reader should
consider general directory security issues detailed in the LDAP
technical specification [Roadmap].
6. Acknowledgments
This document is a revision of RFC 2596 by Mark Wahl and Tim Howes.
RFC 2596 was a product of the IETF ASID and LDAPEXT working groups.
This document borrows from a number of IETF documents including BCP
47.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Zeilenga Language Tags and Ranges in LDAP [Page 12]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47 (also RFC 3066), January 2001.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Models] K. Zeilenga (editor), "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
8. Informative References
[X.501] "The Directory: Models", ITU-T Recommendation X.501, 1997.
Appendix A. Differences from RFC 2596
This document adds support for language ranges, provides a mechanism
that a client can use to discover whether a server supports language
tags and ranges, and clarifies how attributes with multiple language
tags are to be treated. This document is a significant rewrite of RFC
2596.
Appendix B. Differences from X.500(1997)
X.500(1997) [X.501] defines a different mechanism, contexts, as the
means of representing language tags (codes). This section summarizes
the major differences in approach.
a) An X.500 operation which has specified a language code on a value
matches a value in the directory without a language code.
b) LDAP references BCP 47 [RFC3066], which allows for IANA
registration of new tags as well as unregistered tags.
c) LDAP supports language ranges.
d) LDAP does not allow language tags (and ranges) in distinguished
names.
e) X.500 describes subschema administration procedures to allow
language codes to be associated with particular attributes types.
Zeilenga Language Tags and Ranges in LDAP [Page 13]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga Language Tags and Ranges in LDAP [Page 14]

619
doc/drafts/draft-zeilenga-ldap-subentry-xx.txt Normal file
View file

@ -0,0 +1,619 @@
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]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
Conventions
Schema definitions are provided using LDAP description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
Protocol elements are described using ASN.1 [X.680]. The term
"BER-encoded" means the element is to be encoded using the Basic
Encoding Rules [X.690] under the restrictions detailed in Section 5.1
of [RFC2251].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
1. Overview
From [X.501]:
A subentry is a special kind of entry immediately subordinate to
an administrative point. It contains attributes that pertain to a
subtree (or subtree refinement) associated with its administrative
point. The subentries and their administrative point are part of
the same naming context.
A single subentry may serve all or several aspects of
administrative authority. Alternatively, a specific aspect of
administrative authority may be handled through one or more of its
own subentries.
Subentries in Lightweight Directory Access Protocol (LDAP) [LDAPTS]
SHALL behave in accordance with X.501 unless noted otherwise in this
specification.
In absence of the subentries control (detailed in Section 3),
subentries SHALL NOT be considered in one-level and subtree scope
search operations. For all other operations, including base scope
search operations, subentries SHALL be considered.
2. Subentry Schema
2.1. Subtree Specification Syntax
The Subtree Specification syntax provides a general purpose mechanism
for the specification of a subset of entries in a subtree of the
Directory Information Tree (DIT). A subtree begins at some base entry
and includes the subordinates of that entry down to some identified
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 2]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
lower boundary, possibly extending to the leaf entries. A subtree
specification is always used within a context or scope which
implicitly determines the bounds of the subtree. For example, the
scope of a subtree specification for a subschema administrative area
does not include the subtrees of any subordinate administrative point
entries for subschema administration. Where a subtree specification
does not identify a contiguous subset of the entries within a single
subtree the collection is termed a subtree refinement.
This syntax corresponds to the SubtreeSpecification ASN.1 type
described in [X.501], Section 11.3. This ASN.1 data type definition
is reproduced here for completeness.
SubtreeSpecification ::= SEQUENCE {
base [0] LocalName DEFAULT { },
COMPONENTS OF ChopSpecification,
specificationFilter [4] Refinement OPTIONAL }
LocalName ::= RDNSequence
ChopSpecification ::= SEQUENCE {
specificExclusions [1] SET OF CHOICE {
chopBefore [0] LocalName,
chopAfter [1] LocalName } OPTIONAL,
minimum [2] BaseDistance DEFAULT 0,
maximum [3] BaseDistance OPTIONAL}
BaseDistance ::= INTEGER (0 .. MAX)
Refinement ::= CHOICE {
item [0] OBJECT-CLASS.&id,
and [1] SET OF Refinement,
or [2] SET OF Refinement,
not [3] Refinement }
The components of SubtreeSpecification are: base, which identifies the
base entry of the subtree or subtree refinement, and
specificExclusions, minimum, maximum and specificationFilter, which
then reduce the set of subordinate entries of the base entry. The
subtree or subtree refinement contains all the entries within scope
that are not excluded by any of the components of the subtree
specification. When all of the components of SubtreeSpecification are
absent (i.e. when a value of the Subtree Specification syntax is the
empty sequence, {}), the subtree so specified implicitly includes all
the entries within scope.
Any particular use of this mechanism MAY impose limitations or
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 3]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
constraints on the components of SubtreeSpecification.
The LDAP syntax specification is:
( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' )
The native LDAP encoding of values of this syntax is defined by the
Generic String Encoding Rules [GSER]. Appendix A provides an
equivalent ABNF for this syntax.
2.1.1. Base
The base component of SubtreeSpecification nominates the base entry of
the subtree or subtree refinement. The base entry may be an entry
which is subordinate to the root entry of the scope in which the
subtree specification is used, in which case the base component
contains a sequence of RDNs relative to the root entry of the scope,
or may be the root entry of the scope itself (the default), in which
case the base component is absent or contains an empty sequence of
RDNs.
Entries that are not subordinates of the base entry are excluded from
the subtree or subtree refinement.
2.1.2. Specific Exclusions
The specificExclusions component of a ChopSpecification is a list of
exclusions that specify entries and their subordinates to be excluded
from the the subtree or subtree refinement. The entry is specified by
a sequence of RDNs relative to the base entry (i.e. a LocalName).
Each exclusion is of either the chopBefore or chopAfter form. If the
chopBefore form is used then the specified entry and its subordinates
are excluded from the subtree or subtree refinement. If the chopAfter
form is used then only the subordinates of the specified entry are
excluded from the subtree or subtree refinement.
2.1.3. Minimum and Maximum
The minimum and maximum components of a ChopSpecification allow the
exclusion of entries based on their depth in the DIT.
Entries that are less than the minimum number of RDN arcs below the
base entry are excluded from the subtree or subtree refinement. A
minimum value of zero (the default) corresponds to the base entry.
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 4]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
Entries that are more than the maximum number of RDN arcs below the
base entry are excluded from the subtree or subtree refinement. An
absent maximum component indicates that there is no upper limit on the
number of RDN arcs below the base entry for entries in the subtree or
subtree refinement.
2.1.4. Specification Filter
The specificationFilter component is a boolean expression of
assertions about the values of the objectClass attribute of the base
entry and its subordinates. A Refinement assertion item evaluates to
true for an entry if that entry's objectClass attribute contains the
OID nominated in the assertion. Entries for which the overall filter
evaluates to false are excluded from the subtree refinement. If the
specificationFilter is absent then no entries are excluded from the
subtree or subtree refinement because of their objectClass attribute
values.
2.2. Administrative Role Attribute Type
The Administrative Model defined in [X.501], clause 10 requires that
administrative entries contain an administrativeRole attribute to
indicate that the associated administrative area is concerned with one
or more administrative roles.
The administrativeRole operational attribute is specified as follows:
( 2.5.18.5 NAME 'administrativeRole'
EQUALITY objectIdentifierMatch
USAGE directoryOperation
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The possible values of this attribute defined in X.501 are:
OID NAME
-------- -------------------------------
2.5.23.1 autonomousArea
2.5.23.2 accessControlSpecificArea
2.5.23.3 accessControlInnerArea
2.5.23.4 subschemaAdminSpecificArea
2.5.23.5 collectiveAttributeSpecificArea
2.5.23.6 collectiveAttributeInnerArea
Other values may be defined in other specifications. Names associated
with each administrative role are Object Identifier Descriptors
[LDAPIANA].
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 5]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
The administrativeRole operational attribute is also used to regulate
the subentries permitted to be subordinate to an administrative entry.
A subentry not of a class permitted by the administrativeRole
attribute cannot be subordinate to the administrative entry.
2.3. Subtree Specification Attribute Type
The subtreeSpecification operational attribute is defined as follows:
( 2.5.18.6 NAME 'subtreeSpecification'
SINGLE-VALUE
USAGE directoryOperation
SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 )
This attribute is present in all subentries. See [X.501], clause 10.
Values of the subtreeSpecification attribute nominate collections of
entries within the DIT for one or more aspects of administrative
authority.
2.4. Subentry Object Class
The subentry object class is a structural object class.
( 2.5.20.0 NAME 'subentry'
SUP top STRUCTURAL
MUST ( cn $ subtreeSpecification ) )
3. Subentries Control
The subentries control MAY be sent with a searchRequest to control the
visibility of entries and subentries which are within scope.
Non-visible entries or subentries are not returned in response to the
request.
The subentries control is an LDAP Control whose controlType is
1.3.6.1.4.1.4203.1.10.1, criticality is TRUE or FALSE (hence absent),
and controlValue contains a BER-encoded BOOLEAN indicating visibility.
A controlValue containing the value TRUE indicates that subentries are
visible and normal entries are not. A controlValue containing the
value FALSE indicates that normal entries are visible and subentries
are not.
Note that TRUE visibility has the three octet encoding { 01 01 FF }
and FALSE visibility has the three octet encoding { 01 01 00 }.
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 6]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
The controlValue SHALL NOT be absent.
In absence of this control, subentries are not visible to singleLevel
and wholeSubtree scope Search requests but are visible to baseObject
scope Search requests.
There is no corresponding response control.
This control is not appropriate for non-Search operations.
4. Security Considerations
Subentries often hold administrative information or other sensitive
information and should be protected from unauthorized access and
disclosure as described in [RFC2829][RFC2830].
General LDAP [LDAPTS] security considerations also apply.
5. IANA Considerations
5.1 Descriptors
It is requested that IANA register the LDAP descriptors used in this
document per the following registration template:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <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]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
where Type A is Attribute, Type O is ObjectClass, and Type R is
Administrative Role.
5.2 Object Identifiers
No IANA assignment of object identifiers is requested.
This document uses the OID 1.3.6.1.4.1.4203.1.10.1 to identify an LDAP
protocol element defined herein. This OID was assigned [ASSIGN] by
OpenLDAP Foundation under its IANA assigned private enterprise
allocation [PRIVATE] for use in this specification.
Other OIDs which appear in this document were either assigned by the
ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify
elements of X.500 schema or assigned in RFC 2252 for the use described
here.
6. Acknowledgment
This document is based on engineering done by IETF LDUP and LDAPext
Working Groups including "LDAP Subentry Schema" by Ed Reed. This
document also borrows from a number of ITU documents including X.501.
7. Authors' Addresses
Kurt D. Zeilenga
OpenLDAP Foundation
Email: Kurt@OpenLDAP.org
Steven Legg
Adacel Technologies Ltd.
405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149
AUSTRALIA
Phone: +61 3 9451 2107
Fax: +61 3 9541 2121
EMail: steven.legg@adacel.com.au
8. Normative References
[X.501] ITU-T, "The Directory -- Models," X.501, 1993.
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 8]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 1994.
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", X.690, 1994.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (was RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
[RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000
[RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
[LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-xx.txt, a work in progress.
[GSER] S. Legg, "Generic String Encoding Rules for ASN.1 Types",
draft-legg-ldapext-gser--xx.txt, a work in progress.
[LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", draft-ietf-
ldapbis-iana-xx.txt, a work in progress.
9. Informative References
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[GCE] S. Legg, "Common Elements of GSER Encodings",
draft-legg-ldap-gser-abnf-xx.txt, a work in progress.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 9]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
A. Subtree Specification ABNF
This appendix is non-normative.
The LDAP-specific native string encoding for the Subtree Specification
syntax is specified by the Generic String Encoding Rules [GSER]. The
ABNF [RFC2234] in this appendix for this syntax is provided only as a
convenience and is equivalent to the encoding specified by the
application of [GSER]. Since the SubtreeSpecification ASN.1 type may
be extended in future editions of [X.501], the provided ABNF should be
regarded as a snapshot in time. The native LDAP encoding for any
extension to the SubtreeSpecification ASN.1 type can be determined
from [GSER].
In the event that there is a discrepancy between this ABNF and the
encoding determined by [GSER], [GSER] is to be taken as definitive.
SubtreeSpecification = "{" [ sp base ]
[ sep sp specificExclusions ]
[ sep sp minimum ]
[ sep sp maximum ]
[ sep sp specificationFilter ]
sp "}"
base = id-base msp LocalName
specificExclusions = id-specificExclusions msp SpecificExclusions
minimum = id-minimum msp BaseDistance
maximum = id-maximum msp BaseDistance
specificationFilter = id-specificationFilter msp Refinement
id-base = %x62.61.73.65 ; "base"
id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73
%x69.6F.6E.73 ; "specificExclusions"
id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum"
id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum"
id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46
%x69.6C.74.65.72 ; "specificationFilter"
SpecificExclusions = "{" sp SpecificExclusion
*( "," sp SpecificExclusion ) sp "}"
SpecificExclusion = chopBefore / chopAfter
chopBefore = id-chopBefore ":" LocalName
chopAfter = id-chopAfter ":" LocalName
id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore"
id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter"
Refinement = item / and / or / not
item = id-item ":" OBJECT-IDENTIFIER
Zeilenga draft-zeilenga-ldap-subentry-05 [Page 10]
INTERNET-DRAFT Subentries in LDAP 17 May 2002
and = id-and ":" Refinements
or = id-or ":" Refinements
not = id-not ":" Refinement
Refinements = "{" [ sp Refinement
*( "," sp Refinement ) ] sp "}"
id-item = %x69.74.65.6D ; "item"
id-and = %x61.6E.64 ; "and"
id-or = %x6F.72 ; "or"
id-not = %x6E.6F.74 ; "not"
BaseDistance = INTEGER
The <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]

227
doc/drafts/draft-zeilenga-ldap-t-f-02.txt Normal file
View file

@ -0,0 +1,227 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 May 2002
LDAP True/False Filters
<draft-zeilenga-ldap-t-f-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions Working Group
mailing list <ietf-ldapext@netscape.com>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Abstract
This document extends the Lightweight Directory Access Protocol (LDAP)
to support absolute True and False filters based upon similar
capabilities found in X.500 directory systems. The document also
extends the String Representation of LDAP Search Filters to support
these filters.
Zeilenga LDAP True/False Filters [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
1. Background and Intended Use
The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
True and False assertions. An 'and' filter with zero elements always
evaluates to True. An 'or' filter with zero elements always evaluates
to False. These filters are commonly used when requesting DSA-
specific Entries (DSEs) which do not necessarily have objectClass
attributes. That is, where "(objectClass=*)" may evaluate to False.
While LDAPv2 [RFC1777] placed no restriction on the number of elements
in 'and' and 'or' filter sets, the LDAPv2 string representation
[RFC1960] could not represent empty 'and' and 'or' filter sets. Due
to this, LDAPv3 [RFC2251] required 'and' and 'or' filter sets to have
at least one element. Hence, LDAPv3 does not provide absolute True or
False filters.
This documents extends LDAPv3 [RFC2251] to support absolute True and
False matches by allowing empty 'and' and 'or' and extends the filter
string representation [RFC2254] to allow empty filter lists.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
2. Absolute True and False Filters
Implementations of this extension SHALL allow 'and' and 'or' choices
with zero filter elements.
An 'and' Filter consisting of an empty set of filters SHALL evaluate
to True. This filter is to represented by the string "(&)".
An 'or' Filter consisting of an empty set of filters SHALL evaluate to
False. This filter is to represented by the string "(|)".
Servers supporting this feature SHOULD publish the Object Identifier
1.3.6.1.4.1.4203.1.5.3 as a value of the supportedFeatures [FEATURES]
attribute in the root DSE.
Clients supporting this feature SHOULD NOT use the feature unless they
have knowledge the server supports it.
3. Security Considerations
The (re)introduction of absolute True and False filters does not raise
any new security considerations.
Zeilenga LDAP True/False Filters [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
Implementors of this (or any) LDAP extension should be familiar with
general LDAP general security considerations [LDAPTS].
4. IANA Considerations
No IANA assignments are requested.
This document uses the OID 1.3.6.1.4.1.4203.1.5.3 to identify the
feature described above. This OID was assigned [ASSIGN] by OpenLDAP
Foundation under its IANA assigned private enterprise allocation
[PRIVATE] for use in this specification.
5. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
6. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2254] T. Howes, "A String Representation of LDAP Search Filters",
RFC 2254, December 1997.
[LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-xx.txt (a work in progress).
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
7. Informative References
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol", RFC 1777, March 1995.
[RFC1960] T. Howes, "A String Representation of LDAP Search Filters",
RFC 1960, June 1996.
Zeilenga LDAP True/False Filters [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga LDAP True/False Filters [Page 4]

1123
doc/drafts/draft-zeilenga-ldap-user-schema-xx.txt Normal file
View file

File diff suppressed because it is too large Load diff