2000-12-19 04:10:07 +08:00
|
|
|
Internet-Draft David Chadwick
|
|
|
|
LDAPExt WG University of Salford
|
|
|
|
Intended Category: Standards Track Sean Mullan
|
|
|
|
Sun Microsystems
|
2001-01-26 11:01:27 +08:00
|
|
|
Expires: 11 June 2001 11 December 2000
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
|
|
|
|
Returning Matched Values with LDAPv3
|
2001-01-26 11:01:27 +08:00
|
|
|
<draft-ietf-ldapext-matchedval-05.txt>
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
|
|
|
|
STATUS OF THIS MEMO
|
|
|
|
|
|
|
|
This document is an Internet-Draft and is in full conformance with
|
2000-12-19 04:11:30 +08:00
|
|
|
all the provisions of Section 10 of RFC2026 [1].
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2001-01-26 11:01:27 +08:00
|
|
|
This Internet-Draft expires on 11 June 2001.
|
2000-12-19 04:11:30 +08:00
|
|
|
|
|
|
|
Comments and suggestions on this document are encouraged. Comments on
|
|
|
|
this document should be sent to the LDAPEXT working group discussion
|
|
|
|
list:
|
2000-12-19 04:10:07 +08:00
|
|
|
ietf-ldapext@netscape.com
|
2000-12-19 04:11:30 +08:00
|
|
|
|
2000-12-19 04:10:07 +08:00
|
|
|
or directly to the authors.
|
|
|
|
|
|
|
|
|
|
|
|
ABSTRACT
|
|
|
|
|
|
|
|
This document describes a control for the Lightweight Directory
|
|
|
|
Access Protocol v3 that is used to return a subset of attribute
|
|
|
|
values from an entry, specifically, only those values that match a
|
|
|
|
"values return" filter. Without support for this control, a client
|
|
|
|
must retrieve all of an attribute's values and search for specific
|
|
|
|
values locally.
|
|
|
|
|
|
|
|
|
|
|
|
1. Introduction
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
When reading an attribute from an entry using LDAPv3 [2], it is
|
|
|
|
normally only possible to read either the attribute type, or the
|
|
|
|
attribute type and all its values. It is not possible to selectively
|
|
|
|
read just a few of the attribute values. If an attribute holds many
|
|
|
|
values, for example, the userCertificate attribute, or the subschema
|
|
|
|
publishing operational attributes objectClasses and attributeTypes
|
|
|
|
[3], then it may be desirable for the user to be able to selectively
|
|
|
|
retrieve a subset of the values, specifically, those attribute values
|
|
|
|
that match some user defined selection criteria. Without the control
|
|
|
|
specified in this [ID/standard/document] a client must read all of
|
|
|
|
the attribute's values and filter out the unwanted values,
|
|
|
|
necessitating the client to implement the matching rules. It also
|
|
|
|
requires the client to potentially read and process many irrelevant
|
|
|
|
values, which can be inefficient if the values are large or complex,
|
|
|
|
or there are many values stored per attribute.
|
|
|
|
|
|
|
|
This [ID/Standard/document] specifies an LDAPv3 control to enable a
|
|
|
|
user to return only those values that matched (i.e. returned TRUE to)
|
|
|
|
one or more elements of a newly defined "values return" filter. This
|
|
|
|
control can be especially useful when used in conjunction with
|
|
|
|
extensible matching rules that match on one or more components of
|
|
|
|
complex binary attribute values.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
|
|
document are to be interpreted as described in RFC 2119 [5].
|
|
|
|
|
|
|
|
|
|
|
|
2. The valuesReturnFilter Control
|
|
|
|
|
|
|
|
The valuesReturnFilter control MAY be critical or non-critical as
|
2000-12-19 04:11:30 +08:00
|
|
|
determined by the user. It only has meaning for the Search operation,
|
|
|
|
and SHOULD only be added to the Search operation by the client. If
|
|
|
|
the server supports the control and it is present on a Search
|
|
|
|
operation, the server MUST obey the control regardless of the value
|
|
|
|
of the criticality flag.
|
|
|
|
|
|
|
|
If the control is marked as critical, and either the server does not
|
|
|
|
support the control or the control is applied to an operation other
|
|
|
|
than Search, then the server MUST return an
|
|
|
|
unavailableCriticalExtension error. If the control is not marked as
|
|
|
|
critical, and either the server does not support the control or the
|
|
|
|
control is applied to an operation other than Search, then the server
|
|
|
|
MUST ignore the control.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
The object identifier for this control is 1.2.826.0.1.3344810.2.3
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
The controlValue is an OCTET STRING, whose value is the BER encoding
|
|
|
|
of a value of the type ValuesReturnFilter.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem
|
|
|
|
|
|
|
|
SimpleFilterItem ::= CHOICE {
|
|
|
|
equalityMatch [3] AttributeValueAssertion,
|
|
|
|
substrings [4] SubstringFilter,
|
|
|
|
greaterOrEqual [5] AttributeValueAssertion,
|
|
|
|
lessOrEqual [6] AttributeValueAssertion,
|
|
|
|
present [7] AttributeDescription,
|
|
|
|
approxMatch [8] AttributeValueAssertion,
|
|
|
|
extensibleMatch [9] SimpleMatchingAssertion }
|
|
|
|
|
|
|
|
SimpleMatchingAssertion ::= SEQUENCE {
|
|
|
|
matchingRule [1] MatchingRuleId OPTIONAL,
|
|
|
|
type [2] AttributeDescription OPTIONAL,
|
2000-12-19 04:11:30 +08:00
|
|
|
--- at least one of the above must be present
|
2000-12-19 04:10:07 +08:00
|
|
|
matchValue [3] AssertionValue}
|
|
|
|
|
|
|
|
All the above data types have their standard meanings as defined in
|
|
|
|
[2].
|
|
|
|
|
|
|
|
If the server supports this control, the server MUST make use of the
|
|
|
|
control as follows:
|
|
|
|
|
|
|
|
(1) The Search Filter is first executed in order to determine
|
2000-12-19 04:11:30 +08:00
|
|
|
which entries satisfy the Search criteria (these are the
|
|
|
|
filtered entries). The control has no impact on this step.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
(2) If the typesOnly parameter of the Search Request is TRUE,
|
|
|
|
the control has no effect and the Search Request SHOULD be
|
|
|
|
processed as if the control had not been specified.
|
|
|
|
|
|
|
|
(3) If the attributes parameter of the Search Request consists
|
|
|
|
of a list containing only the attribute with OID "1.1"
|
|
|
|
(specifying that no attributes are to be returned), the control
|
|
|
|
has no effect and the Search Request SHOULD be processed as if
|
|
|
|
the control had not been specified.
|
|
|
|
|
|
|
|
(4) For each attribute listed in the attributes parameter of the
|
2000-12-19 04:11:30 +08:00
|
|
|
Search Request, the server MUST apply the control as follows to
|
|
|
|
each entry in the set of filtered entries:
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
i) Every attribute value that evaluates TRUE against one or
|
|
|
|
more elements of the ValuesReturnFilter is placed in the
|
2000-12-19 04:11:30 +08:00
|
|
|
corresponding SearchResultEntry.
|
2000-12-19 04:10:07 +08:00
|
|
|
ii) Every attribute value that evaluates FALSE or undefined
|
|
|
|
against all elements of the ValuesReturnFilter is not
|
2000-12-19 04:11:30 +08:00
|
|
|
placed in the corresponding SearchResultEntry. An
|
|
|
|
attribute that has no values selected is returned with an
|
|
|
|
empty set of vals.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
Note. If the AttributeDescriptionList is empty or comprises "*"
|
|
|
|
then the control MUST be applied against every attribute.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
|
|
|
|
3. Relationship to X.500
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
The control is a superset of the matchedValuesOnly (MVO) boolean of
|
|
|
|
the X.500 DAP [4] Search argument, as amended in the latest version
|
|
|
|
[6]. Close examination of the matchedValuesOnly boolean by the
|
|
|
|
LDAPEXT group revealed ambiguities and complexities in the MVO
|
|
|
|
boolean that could not easily be resolved. For example, it was not
|
|
|
|
clear if the MVO boolean governed only those attribute values that
|
|
|
|
contributed to the overall truth of the filter, or all of the
|
|
|
|
attribute values even if the filter item containing the attribute
|
|
|
|
evaluated to false. For this reason the LDAPEXT group decided to
|
|
|
|
replace the MVO boolean with a simple filter that removes any
|
2000-12-19 04:10:07 +08:00
|
|
|
uncertainty as to whether an attribute value has been selected or
|
|
|
|
not.
|
|
|
|
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
4. Relationship to other LDAP Controls
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
The purpose of this control is to select zero, one or more attribute
|
|
|
|
values from each requested attribute in a filtered entry, and to
|
|
|
|
discard the remainder. Once the attribute values have been discarded
|
|
|
|
by this control they MUST NOT be re-instated into the Search results
|
|
|
|
by other controls.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
This control acts independently of other LDAP controls such as server
|
|
|
|
side sorting [10] and duplicate entries [7]. However, there might be
|
|
|
|
interactions between this control and other controls so that a
|
|
|
|
different set of Search Result Entries are returned, or the entries
|
|
|
|
are returned in a different order, depending upon the sequencing of
|
|
|
|
this control and other controls in the LDAP request. For example,
|
|
|
|
with server side sorting, if sorting is done first, and value return
|
|
|
|
filtering second, the set of Search Results may appear to be in the
|
|
|
|
wrong order since the value filtering may remove the attribute values
|
|
|
|
upon which the ordering was done. (The sorting document specifies
|
|
|
|
that entries without any sort key attribute values should be treated
|
|
|
|
as coming after all other attribute values.) Similarly with duplicate
|
|
|
|
entries, if duplication is performed before value filtering, the set
|
|
|
|
of Search Result Entries may contain identical duplicate entries,
|
|
|
|
each with an empty set of attribute values, because the value
|
|
|
|
filtering removed the attribute values that were used to duplicate
|
|
|
|
the results.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
For these reasons it is recommended that the ValuesReturnFilter
|
|
|
|
control in a SearchRequest SHOULD precede other controls that affect
|
|
|
|
the number and ordering of SearchResultEntrys.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
5. Examples
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
All entries are provided in LDIF format [8].
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
The string representation of the valuesReturnFilter in the examples
|
2001-01-26 11:01:27 +08:00
|
|
|
below uses the following ABNF notation:
|
|
|
|
|
|
|
|
valuesReturnFilter = "(" 1*simpleFilterItem ")"
|
|
|
|
simpleFilterItem = "(" item ")"
|
|
|
|
|
|
|
|
where item is as defined by RFC2254 [11].
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
(1) The first example shows how the control can be set to return all
|
|
|
|
attribute values from one attribute type (e.g. telephoneNumber) and a
|
|
|
|
subset of values from another attribute type (e.g. mail).
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
The entries below represent organizationalPerson object classes
|
|
|
|
located somewhere beneath the distinguished name dc=ac, dc=uk.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
dn: cn=Sean Mullan, ou=people, dc=sun, dc=ac, dc=uk
|
2000-12-19 04:10:07 +08:00
|
|
|
cn: Sean Mullan
|
2000-12-19 04:11:30 +08:00
|
|
|
sn: Mullan
|
|
|
|
objectClass: organizationalPerson
|
|
|
|
objectClass: person
|
|
|
|
objectClass: inetOrgPerson
|
|
|
|
mail: sean.mullan@hotmail.com
|
2000-12-19 04:10:07 +08:00
|
|
|
mail: mullan@east.sun.com
|
2000-12-19 04:11:30 +08:00
|
|
|
telephoneNumber: + 781 442 0926
|
2000-12-19 04:10:07 +08:00
|
|
|
telephoneNumber: 555-9999
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
dn: cn=David Chadwick, ou=isi, o=salford, dc=ac, dc=uk
|
2000-12-19 04:10:07 +08:00
|
|
|
cn: David Chadwick
|
2000-12-19 04:11:30 +08:00
|
|
|
sn: Chadwick
|
|
|
|
objectClass: organizationalPerson
|
|
|
|
objectClass: person
|
|
|
|
objectClass: inetOrgPerson
|
2000-12-19 04:10:07 +08:00
|
|
|
mail: d.w.chadwick@salford.ac.uk
|
|
|
|
|
|
|
|
An LDAP search operation is specified with a baseObject set to the
|
2000-12-19 04:11:30 +08:00
|
|
|
DN of the search base (i.e. dc=ac, dc=uk), a subtree scope, a filter
|
|
|
|
set to (sn=mullan), and the list of attributes to be returned set to
|
|
|
|
"mail, telephoneNumber". In addition, a ValuesReturnFilter control is
|
|
|
|
set to ((mail=*hotmail.com)(telephoneNumber=*))
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
The search results returned by the server would consist of the
|
2000-12-19 04:11:30 +08:00
|
|
|
following entry:
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
dn: cn=Sean Mullan, ou=people, dc=sun, dc=ac, dc=uk
|
|
|
|
mail: sean.mullan@hotmail.com
|
|
|
|
telephoneNumber: + 781 442 0926
|
2000-12-19 04:10:07 +08:00
|
|
|
telephoneNumber: 555-9999
|
|
|
|
|
|
|
|
Note that the control has no effect on the values returned for the
|
|
|
|
"telephoneNumber" attribute (all of the values are returned), since
|
|
|
|
the control specified that all values should be returned.
|
|
|
|
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
(2) The second example shows how one might retrieve a single
|
|
|
|
attribute type subschema definition for the "gunk" attribute with OID
|
|
|
|
1.2.3.4.5 from the subschema subentry
|
|
|
|
|
|
|
|
Assume the subschema subentry is held below the root entry with DN
|
|
|
|
cn=subschema subentry, o=myorg and this holds an attributeTypes
|
2000-12-19 04:10:07 +08:00
|
|
|
operational attribute holding the descriptions of the 35 attributes
|
|
|
|
known to this server (each description is held as a single attribute
|
|
|
|
value of the attributeTypes attribute).
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
dn: cn=subschema subentry, o=myorg
|
2000-12-19 04:10:07 +08:00
|
|
|
cn: subschema subentry
|
|
|
|
objectClass: subschema
|
|
|
|
attributeTypes: ( 2.5.4.3 NAME 'cn' SUP name )
|
|
|
|
attributeTypes: ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )
|
2000-12-19 04:11:30 +08:00
|
|
|
attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY
|
|
|
|
objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
|
|
|
|
attributeTypes: ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY
|
|
|
|
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
|
|
|
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-
|
|
|
|
MODIFICATION USAGE directoryOperation )
|
|
|
|
attributeTypes: ( 2.5.21.6 NAME 'objectClasses' EQUALITY
|
|
|
|
objectIdentifierFirstComponentMatch SYNTAX
|
|
|
|
1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )
|
|
|
|
attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch
|
|
|
|
SUBSTR caseIgnoreSubstringsMatch SYNTAX
|
|
|
|
1.3.6.1.4.1.1466.115.121.1.44{64} )
|
|
|
|
attributeTypes: ( 2.5.21.5 NAME 'attributeTypes' EQUALITY
|
|
|
|
objectIdentifierFirstComponentMatch SYNTAX
|
|
|
|
1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
plus another 28 - you get the idea.
|
|
|
|
|
|
|
|
|
|
|
|
The user creates an LDAP search operation with a baseObject set to
|
2000-12-19 04:11:30 +08:00
|
|
|
cn=subschema subentry, o=myorg, a scope of base, a filter set to
|
|
|
|
(objectClass=subschema), the list of attributes to be returned set to
|
|
|
|
"attributeTypes", and the ValuesReturnFilter set to
|
2001-01-26 11:01:27 +08:00
|
|
|
((attributeTypes=1.2.3.4.5))
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
The search result returned by the server would consist of the
|
|
|
|
following entry:
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
dn: cn=subschema subentry, o=myorg
|
|
|
|
attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch
|
|
|
|
SUBSTR caseIgnoreSubstringsMatch SYNTAX
|
|
|
|
1.3.6.1.4.1.1466.115.121.1.44{64} )
|
|
|
|
|
|
|
|
|
|
|
|
(3) The final example shows how the control can be used to match on a
|
|
|
|
userCertificate attribute value with a particular key usage bit set
|
|
|
|
(in this case the key encipherment bit). Note that this example
|
|
|
|
requires the LDAP server to support the certificateMatch matching
|
|
|
|
rule defined in [9] and extensible matching.
|
|
|
|
|
|
|
|
The entry below represent a pkiUser object class stored in the
|
|
|
|
directory.
|
|
|
|
|
|
|
|
dn: cn=David Chadwick + serialNumber=123456, ou=people, o=University
|
|
|
|
of Salford, c=gb
|
|
|
|
cn: David Chadwick + serialNumber=123456
|
|
|
|
objectClass: person
|
|
|
|
objectClass: organizationalPerson
|
|
|
|
objectClass: pkiUser
|
|
|
|
objectClass: inetOrgPerson
|
|
|
|
sn: Chadwick
|
2000-12-19 04:10:07 +08:00
|
|
|
mail: d.w.chadwick@salford.ac.uk
|
2000-12-19 04:11:30 +08:00
|
|
|
userCertificate: {binary representation of certificate including key
|
|
|
|
usage bit of digitalSignature (0)}
|
|
|
|
userCertificate: {binary representation of certificate including key
|
|
|
|
usage bit of nonRepudiation (1)}
|
|
|
|
userCertificate: {binary representation of certificate including key
|
|
|
|
usage bit of key encipherment (2)}
|
|
|
|
userCertificate: {binary representation of certificate including key
|
|
|
|
usage bit of data encipherment (3)}
|
|
|
|
|
|
|
|
An LDAP search operation is specified with a baseObject set to
|
|
|
|
o=University of Salford, c=gb, a subtree scope, a filter set to
|
|
|
|
(sn=chadwick) and the list of attributes to be returned set to
|
|
|
|
"userCertificate;binary". In addition, a ValuesReturnFilter control
|
2001-01-26 11:01:27 +08:00
|
|
|
is set to ((userCertificate:2.5.13.35:=(USE'001'B)))
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
The search result returned by the server would consist of the
|
2000-12-19 04:10:07 +08:00
|
|
|
following entry:
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
dn: cn=David Chadwick + serialNumber=123456, ou=people, o=University
|
|
|
|
of Salford, c=gb
|
|
|
|
userCertificate;binary: {binary representation of certificate with
|
|
|
|
key usage bit of key encipherment (2)}
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
6. Security Considerations
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
This [ID/standard/document] does not primarily discuss security
|
|
|
|
issues.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
Note however that attribute values MUST only be returned if the
|
|
|
|
access controls applied by the LDAP server allow them to be returned,
|
|
|
|
and in this respect the effect of the ValuesReturnFilter control is
|
|
|
|
of no consequence.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
Note that the ValuesReturnFilter control may have a positive effect
|
|
|
|
on the deployment of public key infrastructures. Certain PKI
|
|
|
|
operations, like searching for specific certificates, become more
|
2000-12-19 04:11:30 +08:00
|
|
|
practical when combined with X.509 certificate matching rules at the
|
|
|
|
server, and more scalable, since the control avoids the downloading
|
2000-12-19 04:10:07 +08:00
|
|
|
of potentially large numbers of irrelevant certificates which would
|
|
|
|
have to be processed and filtered locally (which in some cases is
|
|
|
|
very difficult to perform).
|
|
|
|
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
7. Acknowledgements
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
The authors would like to thank members of the LDAPExt list for their
|
2000-12-19 04:11:30 +08:00
|
|
|
constructive comments on earlier versions of this
|
|
|
|
[ID/standard/document], and in particular to Harald Alvestrand who
|
|
|
|
first suggested having an attribute return filter and Bruce
|
|
|
|
Greenblatt who first proposed a syntax for this control.
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
8. Copyright
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
9. References
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
[1] S. Bradner. "The Internet Standards Process -- Revision 3", RFC
|
|
|
|
2026, October 1996.
|
2000-12-19 04:10:07 +08:00
|
|
|
[2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
|
|
|
|
Protocol (v3)", Dec. 1997, RFC 2251
|
|
|
|
[3] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
|
|
|
|
Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, Dec
|
|
|
|
1997
|
|
|
|
[4] ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
|
|
|
|
1993.
|
|
|
|
[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement
|
|
|
|
Levels", RFC 2119, March 1997.
|
2000-12-19 04:11:30 +08:00
|
|
|
[6] Draft ISO/IEC 9594 / ITU-T Rec X.511 (2001) The Directory:
|
|
|
|
Abstract Service Definition.
|
|
|
|
[7] J. Sermersheim. "LDAP Control for a Duplicate Entry
|
|
|
|
Representation of Search Results", Internet Draft <draft-ietf-
|
2001-01-26 11:01:27 +08:00
|
|
|
ldapext-ldapv3-dupent-06.txt>, October 2000.
|
2000-12-19 04:11:30 +08:00
|
|
|
[8] G. Good. "The LDAP Data Interchange Format (LDIF) - Technical
|
|
|
|
Specification". RFC 2849, June 2000.
|
|
|
|
[9] D. Chadwick, S.Legg. "Internet X.509 Public Key Infrastructure -
|
|
|
|
Additional LDAP Schema for PKIs and PMIs", Internet Draft <draft-
|
|
|
|
pkix-ldap-schema-01.txt>, September 2000
|
|
|
|
[10] T. Howes, M. Wahl, A. Anantha, "LDAP Control Extension for
|
|
|
|
Server Side Sorting of Search Results", RFC 2891, August 2000
|
|
|
|
[11] T. Howes. "The String Representation of LDAP Search Filters".
|
|
|
|
RFC 2254, December 1997.
|
|
|
|
|
|
|
|
10. Authors Addresses
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
David Chadwick
|
|
|
|
IS Institute
|
|
|
|
University of Salford
|
|
|
|
Salford M5 4WT
|
|
|
|
England
|
|
|
|
|
|
|
|
Email: d.w.chadwick@salford.ac.uk
|
2000-12-19 04:11:30 +08:00
|
|
|
Tel: +44 161 295 5351
|
2000-12-19 04:10:07 +08:00
|
|
|
|
|
|
|
Sean Mullan
|
|
|
|
Sun Microsystems
|
|
|
|
East Point Business Park
|
|
|
|
Dublin 3
|
|
|
|
Ireland
|
|
|
|
Tel: +353 1 853 0655
|
|
|
|
Email: sean.mullan@sun.com
|
|
|
|
|
|
|
|
|
2000-12-19 04:11:30 +08:00
|
|
|
11. Changes since version 2
|
|
|
|
|
|
|
|
i) Revised the examples to be more appropriate
|
|
|
|
ii) Section on interactions with other LDAP controls added
|
|
|
|
iii) Removed Editor's note concerning present filter
|
|
|
|
iv) Tightened wording about its applicability to other operations
|
|
|
|
and use of criticality field
|
|
|
|
|
|
|
|
Changes since version 3
|
|
|
|
|
|
|
|
i) Mandated that at least one of type and matchingRule in
|
|
|
|
simpleMatchingAssertion be present
|
|
|
|
ii) Fixed LDIF mistakes in the examples
|
|
|
|
iii) Additional minor editorials only
|
2000-12-19 04:10:07 +08:00
|
|
|
|
2001-01-26 11:01:27 +08:00
|
|
|
Changes since version 4
|
|
|
|
|
|
|
|
i) corrected the ABNF for single items of valuesReturnFilter
|
2000-12-19 04:10:07 +08:00
|
|
|
|