Skip to content
Snippets Groups Projects
Commit e18b9336 authored by Kurt Zeilenga's avatar Kurt Zeilenga
Browse files

draft-02 (a complete rewrite)

parent c8f7041c
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
doc/drafts/draft-ietf-ldapext-matchedval-xx.txt
+ 405
− 307
View file @ e18b9336
Internet-Draft David Chadwick Internet-Draft David Chadwick
LDAPExt WG University of Salford LDAPExt WG University of Salford
Intended Category: Standards Track Sean Mullan Intended Category: Standards Track Sean Mullan
Sun Sun Microsystems
Microsystems Expires: 1 January 2001 1 July 2000
Expires: 8 March 2000 8 September 1999
Returning Matched Values with LDAPv3 Returning Matched Values with LDAPv3
<draft-ietf-ldapext-matchedval-01.txt> <draft-ietf-ldapext-matchedval-02.txt>
STATUS OF THIS MEMO
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all the provisions of Section 10 of RFC2026. This document is an Internet-Draft and is in full conformance with
all the 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 Internet-Drafts are working documents of the Internet Engineering
groups may also distribute working documents as Internet-Drafts. 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 Internet-Drafts are draft documents valid for a maximum of six months
time. It is inappropriate to use Internet-Drafts as reference and may be updated, replaced, or obsoleted by other documents at any
material or to cite them other than as "work in progress." 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 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. The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft expires on 8 March 2000. Comments and suggestions
on this document are encouraged. Comments on this document should be This Internet-Draft expires on 1 January 2001. Comments and
sent to the LDAPExt working group discussion list: suggestions on this document are encouraged. Comments on this
ietf-ldapext@netscape.com document should be sent to the LDAPExt working group discussion list:
or directly to the authors. ietf-ldapext@netscape.com
or directly to the authors.
ABSTRACT
This document describes a control for the Lightweight Directory ABSTRACT
Access Protocol v3 that is used to return a subset of attribute
values from an entry, specifically, only those values that This document describes a control for the Lightweight Directory
contributed to the search filter evaluating to TRUE. Without support Access Protocol v3 that is used to return a subset of attribute
for this control, a client must retrieve all of an attribute's values values from an entry, specifically, only those values that match a
and search for specific values locally. "values return" filter. Without support for this control, a client
must retrieve all of an attribute's values and search for specific
1. Introduction values locally.
When reading an attribute from an entry using LDAP v2 [1] or LDAPv3
[2], it is normally only possible to read either the attribute type, 1. Introduction
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 When reading an attribute from an entry using LDAP v2 [1] or LDAPv3
holds many values, for example, the userCertificate attribute, or the [2], it is normally only possible to read either the attribute type,
subschema publishing operational attributes objectClasses and or the attribute type and all its values. It is not possible to
attributeTypes [3], then it may be desirable for the user to be able selectively read just a few of the attribute values. If an attribute
to selectively retrieve a subset of the values, specifically, those holds many values, for example, the userCertificate attribute, or the
attribute values that match the selection criteria as specified by subschema publishing operational attributes objectClasses and
the user in the filter. Without the control specified in this attributeTypes [3], then it may be desirable for the user to be able
[ID/standard] a client must read all of the attribute's values and to selectively retrieve a subset of the values, specifically, those
filter out the unwanted values, necessitating the client to implement attribute values that match some user defined selection criteria.
the matching rules. It also requires the client to potentially read Without the control specified in this [ID/standard] a client must
and process many irrelevant values, which can be inefficient if the read all of the attribute's values and filter out the unwanted
values are large or complex, or there are many values stored per values, necessitating the client to implement the matching rules. It
attribute. also requires the client to potentially read and process many
irrelevant values, which can be inefficient if the values are large
This Internet Draft specifies an LDAPv3 control to enable a user to or complex, or there are many values stored per attribute.
return only those values that matched (i.e. returned TRUE to) one or
more elements of the Search filter. This control can be especially This Internet Draft specifies an LDAPv3 control to enable a user to
useful when used in conjunction with extensible matching rules that return only those values that matched (i.e. returned TRUE to) one or
match on one or more components of complex binary attribute values. more elements of a newly defined "values return" filter. This control
can be especially useful when used in conjunction with extensible
The control has been described in such a way as to be fully matching rules that match on one or more components of complex binary
compatible with the matchedValuesOnly boolean of the X.500 DAP [4] attribute values.
Search argument, as amended in the latest version [6].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
document are to be interpreted as described in RFC 2119 [5].
2. The matchedValuesOnly Control 2. The valuesReturnFilter Control
The matchedValuesOnly control MAY be critical or non-critical as The valuesReturnFilter control MAY be critical or non-critical as
determined by the user. It is only applicable to the Search determined by the user. It is only applicable to the Search
operation, and SHALL be ignored by the server if it is present on any operation, and SHALL be ignored by the server if it is present on any
other LDAP operation (even if marked critical on such operations). other LDAP operation (even if marked critical on such operations).
The object identifier for this control is 1.2.826.0.1.3344810.2.2 The object identifier for this control is 1.2.826.0.1.3344810.2.3
The controlValue is absent.
The controlValue is
If the server supports this control, the server MUST make use of the
control as follows: ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem
(1) If the typesOnly parameter of the Search Request is TRUE, SimpleFilterItem ::= CHOICE {
the control has no effect and the Search Request SHOULD be equalityMatch [3] AttributeValueAssertion,
processed as if the control had not been specified. substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
(2) If the attributes parameter of the Search Request consists lessOrEqual [6] AttributeValueAssertion,
of a list containing only the attribute with OID "1.1" present [7] AttributeDescription,
(specifying that no attributes are to be returned), the control approxMatch [8] AttributeValueAssertion,
has no effect and the Search Request SHOULD be processed as if extensibleMatch [9] SimpleMatchingAssertion }
the control had not been specified.
SimpleMatchingAssertion ::= SEQUENCE {
(3) For each attribute listed in the attributes parameter of the matchingRule [1] MatchingRuleId OPTIONAL,
Search Request, the server MUST apply the control as follows: type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue}
i) Every attribute value that evaluates TRUE against one or
more filters, excluding the ignored filters (see below), All the above data types have their standard meanings as defined in
is logically marked by the server as contributing to the [2].
filter matching.
ii) Attributes that have no values marked as contributing, If the server supports this control, the server MUST make use of the
have all their values returned to the user. control as follows:
iii) Attributes that have one or more values marked as
contributing have only the contributing values returned to (1) The Search Filter is first executed in order to determine
the user, whilst the other values of the same attribute which entries satisfy the Search criteria. The control has no
(if there are any) are not returned. impact on this step.
Certain filters are ignored for the purposes of marking the attribute (2) If the typesOnly parameter of the Search Request is TRUE,
values as contributing. These are: the control has no effect and the Search Request SHOULD be
processed as if the control had not been specified.
the ôpresentö filter, since this filter does not test against
any attribute values; (3) If the attributes parameter of the Search Request consists
the ônotö filter, since this would have the effect of marking of a list containing only the attribute with OID "1.1"
all the attribute values except the one(s) that matched the (specifying that no attributes are to be returned), the control
non-negated filter. has no effect and the Search Request SHOULD be processed as if
the control had not been specified.
3. Relationship to X.500
(4) For each attribute listed in the attributes parameter of the
The matchedValuesOnly control defined in this document is derived Search Request, the server MUST apply the control as follows:
from the matchedValuesOnly boolean parameter of the X.511 (93) DAP
Search operation [4]. Note however that in X.511 (93), the i) Every attribute value that evaluates TRUE against one or
matchedValuesOnly parameter is ignored when used with an "equality" more elements of the ValuesReturnFilter is placed in the
match FilterItem, and so the user must use the extensibleMatch filter SearchResultEntry.
along with the equality matching rule if only matched values are ii) Every attribute value that evaluates FALSE or undefined
wanted with equality matching. This slightly spurious equality match against all elements of the ValuesReturnFilter is not
restriction has been removed from the 2000 version of X.511 [6]. For placed in the SearchResultEntry. An attribute that has no
LDAP servers acting as a gateway to an X.500 directory, the matched values selected is returned with an empty set of vals.
valuesOnly control can be directly mapped onto the X.511
matchedValuesOnly Search parameter as follows: Editor's Note. There is possibly a more efficient but slightly more
complex way of achieving the value filtering. An alternative is to
(1) If the matchedValuesOnly control is specified, the remove the 'present' SimpleFilterItem (which obviously evaluates true
matchedValuesOnly DAP parameter MUST be set to true. If the for every attribute value of the 'present' attribute description),
control criticality value is TRUE then bit 17 of the DAP and to say that any attribute whose type is not mentioned in the
criticalExtensions MUST be set. ValuesReturnFilter is not filtered and has all its attribute values
returned. Comments please.
(2) If an equality matching rule is specified in the filter of
the LDAPv3 search operation, then if operating with a pre-2000
edition DSA, the corresponding equality FilterItem contained in 3. Relationship to X.500
the X.511 filter parameter MUST NOT be used, but rather the
extensibleMatch filter item MUST be used instead (the assertion The control is a superset of the matchedValuesOnly boolean of the
consisting of the equality matching rule, the attribute type to X.500 DAP [4] Search argument, as amended in the latest version [6].
match on, and the asserted value). When operating with DSAs Close examination of the matchedValuesOnly boolean by the LDAPExt
that support the 2000 DAP enhancement, the equality FilterItem group revealed ambiguities and complexities in the MVO boolean that
MAY be used. could not easily be resolved. For example, are only those attribute
values that contributed to the overall truth of the filter governed
4. Examples by the MVO boolean, or all values of attributes in the filter
governed by the MVO boolean, even if the filter item containing the
(1) The first example simply shows how the control can be used to attribute evaluated to false. For this reason the LDAP group decided
selectively read a subset of attribute values. to replace the MVO boolean with a simple filter that removes any
uncertainty as to whether an attribute value has been selected or
The entry below represents a groupOfNames object class containing not.
several members from different organizations.
cn: Cross Organizational Standards Body 4. Examples
member: cn=joe, o=acme
member: cn=alice, o=acme (1) The first example simply shows how the control can be used to
member: cn=bob, o=foo selectively read a subset of attribute values.
member: cn=sue, o=bar
The entry below represents a groupOfNames object class containing
An LDAP search operation is specified with a baseObject set to the several members from different organizations.
DN of the entry, a baseObject scope, a filter set to
"member=*o=acme", and the list of attributes to be returned set to cn: Cross Organizational Standards Body
"member". In addition, a matchedValuesOnly control is attached to the member: cn=joe,o=acme
search request. member: cn=alice,o=acme
member: cn=bob,o=foo
The search results returned by the server would consist of the member: cn=sue,o=bar
following entry:
An LDAP search operation is specified with a baseObject set to the
cn: Cross Organizational Standards Body DN of the entry, a baseObject scope, a filter set to
member: cn=joe, o=acme "member=*o=acme", and the list of attributes to be returned set to
member: cn=alice, o=acme "member". In addition, a ValuesReturnFilter control is set to
"member=*o=acme".
(2) The second example shows how the control has no effect on
attributes that do not participate in the search filter. The search results returned by the server would consist of the
following entry:
The entries below represent inetOrgPerson [7] object classes located
below some distinguished name in the directory. cn: Cross Organizational Standards Body
member: cn=joe, o=acme
cn: Sean Mullan member: cn=alice, o=acme
mail: sean.mullan@sun.com
mail: mullan@east.sun.com
telephoneNumber: +1 781 442 0926 (2) The second example shows how the control can be set to match on
telephoneNumber: 555-9999 attributes that are (mail) and are not (telephoneNumber) part of the
search filter. It also shows how a user can filter some attribute
cn: David Chadwick values (mail) and not others (telephoneNumber).
mail: d.w.chadwick@salford.ac.uk
The entries below represent inetOrgPerson [7] object classes located
An LDAP search operation is specified with a baseObject set to the below some distinguished name in the directory.
DN of the entry, a subtree scope, a filter set to
"(|(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk))", and cn: Sean Mullan
the list of attributes to be returned set to "mail telephoneNumber". mail: sean.mullan@sun.com
In addition, a matchedValuesOnly control is attached to the search mail: mullan@east.sun.com
request. telephoneNumber: +1 781 442 0926
telephoneNumber: 555-9999
The search results returned by the server would consist of the
following entries: cn: David Chadwick
mail: d.w.chadwick@salford.ac.uk
cn: Sean Mullan
mail: sean.mullan@sun.com An LDAP search operation is specified with a baseObject set to the
telephoneNumber: +1 781 442 0926 DN of the entry, a subtree scope, a filter set to
telephoneNumber: 555-9999 "(|(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk))", and
the list of attributes to be returned set to "mail telephoneNumber".
cn: David Chadwick In addition, a ValuesReturnFilter control is set to
mail: d.w.chadwick@salford.ac.uk "mail=sean.mullan@sun.com, mail=d.w.chadwick@salford.ac.uk,
telephoneNumber=*"
Note that the control has no effect on the values returned for the
"telephoneNumber" attribute (all of the values are returned), since The search results returned by the server would consist of the
it did not participate in the search filter. following entries:
5. Security Considerations cn: Sean Mullan
mail: sean.mullan@sun.com
This Internet Draft does not discuss security issues at all. telephoneNumber: +1 781 442 0926
telephoneNumber: 555-9999
Note that attribute values MUST only be returned if the access
controls applied by the LDAP server allow them to be returned, and in cn: David Chadwick
this respect the effect of the matchedValuesOnly control is of no mail: d.w.chadwick@salford.ac.uk
consequence.
Note that the control has no effect on the values returned for the
Note that the matchedValuesOnly control may have a positive effect on "telephoneNumber" attribute (all of the values are returned), since
the deployment of public key infrastructures. Certain PKI operations, the control specified that all values should be returned.
like searching for specific certificates, become more practical (when
combined with X.509 certificate matching rules at the server) and (3) The third example shows how one might retrieve a single attribute
more scalable, since the control avoids the downloading of type schema definition for the "gunk" attribute with OID 1.2.3.4.5
potentially large numbers of irrelevant certificates which would have
to be processed and filtered locally (which in some cases is very Assume the subschema subentry is held somewhere below the root entry
difficult to perform). with RDN "subschema subentry", and this holds an attributeTypes
operational attribute holding the descriptions of the 35 attributes
6. Copyright known to this server (each description is held as a single attribute
value of the attributeTypes attribute).
Copyright (C) The Internet Society (date). All Rights Reserved.
cn: subschema subentry
This document and translations of it may be copied and furnished to objectClass: subschema
others, and derivative works that comment on or otherwise explain it attributeTypes: ( 2.5.4.3 NAME 'cn' SUP name )
or assist in its implementation may be prepared, copied, published attributeTypes: ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )
and distributed, in whole or in part, without restriction of any attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY
kind, provided that the above copyright notice and this paragraph are objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
included on all such copies and derivative works. However, this attributeTypes: ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY
document itself may not be modified in any way, such as by removing generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
the copyright notice or references to the Internet Society or other SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-
Internet organizations, except as needed for the purpose of MODIFICATION USAGE directoryOperation )
developing Internet standards in which case the procedures for attributeTypes: ( 2.5.21.6 NAME 'objectClasses' EQUALITY
copyrights defined in the Internet Standards process must be objectIdentifierFirstComponentMatch SYNTAX
followed, or as required to translate it into languages other than 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )
English. attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SYNTAX
The limited permissions granted above are perpetual and will not be 1.3.6.1.4.1.1466.115.121.1.44{64} )
revoked by the Internet Society or its successors or assigns. attributeTypes: ( 2.5.21.5 NAME 'attributeTypes' EQUALITY
objectIdentifierFirstComponentMatch SYNTAX
This document and the information contained herein is provided on an 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING plus another 28 - you get the idea.
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. The user creates an LDAP search operation with a baseObject set to
root, a subtree scope, a filter set to "objectClass=subschema", the
7. References list of attributes to be returned set to "attributeTypes", and the
ValuesReturnFilter set to "attributeTypes=1.2.3.4.5"
[1] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access
Protocol", RFC 1777, March 1995. The search result returned by the server would consist of the
[2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access following entry:
Protocol (v3)", Dec. 1997, RFC 2251
[3] M. Wahl, A. Coulbeck, T. Howes, S. Kille, ôLightweight Directory cn: subschema subentry
Access Protocol (v3): Attribute Syntax Definitionsö, RFC 2252, Dec attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch
1997 SUBSTR caseIgnoreSubstringsMatch SYNTAX
[4] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1.3.6.1.4.1.1466.115.121.1.44{64} )
1993.
[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement (4) The final example shows how the control can be set to match on
Levels", RFC 2119, March 1997. attributes that are not part of the search filter. For example,
[6] ôFPDAMs to ISO/IEC 9594 Parts 1, 2, 3, 4, 5, 6, 7 and 9 to searching for all entries that have an email address in the
support the ITU-T Rec. F.510 "Automated Directory Assistance, White sun.com domain, and returning the telephone number for any attribute
Pages Service Definitions"ö, Collaborative ITU-T/SG7/Q15 and values that start with "555".
JTC1/SC6/WG7 OSI Directory Meeting 7-15 April 1999, Orlando, USA
[7] M. Smith. "Definition of the inetOrgPerson LDAP Object Class", The entries below represent inetOrgPerson [7] object classes located
Internet Draft <draft-smith-ldap-inetorgperson-03.txt>, April 1999. below some distinguished name in the directory.
8. Authors Addresses cn: Sean Mullan
mail: sean.mullan@sun.com
David Chadwick mail: mullan@east.sun.com
IS Institute telephoneNumber: +1 781 442 0926
University of Salford telephoneNumber: 555-9999
Salford M5 4WT
England cn: David Chadwick
mail: d.w.chadwick@salford.ac.uk
Email: d.w.chadwick@salford.ac.uk
An LDAP search operation is specified with a baseObject set to the
Sean Mullan DN of the entry, a subtree scope, a filter set to "mail=*sun.com",
Sun Microsystems Laboratories and the list of attributes to be returned set to "telephoneNumber".
One Network Drive In addition, a ValuesReturnFilter control is set to
Burlington "telephoneNumber=555*"
MA 01803-0902
USA The search results returned by the server would consist of the
following entry:
Tel: +1 781 442-0926 Fax: +1 781 442-1692
Email: sean.mullan@sun.com cn: Sean Mullan
telephoneNumber: 555-9999
Internet-Draft Returning Matched Values with LDAPv3 8 September 1999
5 5. Security Considerations
This Internet Draft does not discuss security issues at all.
Note 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.
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
practical (when combined with X.509 certificate matching rules at the
server) and more scalable, since the control avoids the downloading
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).
6. Acknowledgements
The authors would like to thank members of the LDAPExt list for their
constructive comments on earlier versions of this draft, 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.
7. 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.
8. References
[1] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[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.
[6] ISO/IEC 9594 / ITU-T Rec X.511 (2000) The Directory: Abstract
Service Definition.
[7] M. Smith. "Definition of the inetOrgPerson LDAP Object Class",
Internet Draft <draft-smith-ldap-inetorgperson-03.txt>, April 1999.
9. Authors Addresses
David Chadwick
IS Institute
University of Salford
Salford M5 4WT
England
Email: d.w.chadwick@salford.ac.uk
Sean Mullan
Sun Microsystems
East Point Business Park
Dublin 3
Ireland
Tel: +353 1 853 0655
Email: sean.mullan@sun.com
Internet-Draft Returning Matched Values with LDAPv3 1 July 2000
1
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment