[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Dereferencing Match draft for the repository...
I-D editor:
Please insert the following draft as
draft-moats-ldap-dereference-match-00.txt Thanks-
LDAPEXT:
This is the first draft of an extensible
match rule that allows a client to
request that a server dereference DN
pointers before applying a search filter.
This allows for more efficient BW use and
thinner clients in the presence of richer
information models.
Tim, Mark:
I'd like to a ten to fifteen minute slot
during the Oslo meeting to discuss whether
this should be taken up as a working group
topic and to introduce the topic, since it
is different from other extensibleMatch
rules
Thanks,
Ryan Moats
==========cut here
Internet-Draft Ryan Moats
draft-moats-ldap-dereference-match-00.txt Jerry Maziarski
Expires in six months AT&T
John Strassner
cisco Systems
June 1999
Extensible Match Rule to Dereference Pointers
Filename: draft-moats-ldap-dereference-match-00.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 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.
Abstract
This document defines a LDAPv3 extensible matching rule that allows a
server to dereference pointers stored in an object's attribute and
apply a LDAP search filter to the resulting objects. This rule is
needed for schema definitions that attempt to capture richer
association models than that typically seen in white pages related
schema.
1. Introduction
When mapping rich information models, it sometimes becomes necessary
to use DN pointers to show relationships between objects in the
schema. An example is the information model and resulting core
schema that is currently being proposed by the policy working group
(see [1]).
Expires 12/31/99 [Page 1]
INTERNET DRAFTExtensible Match Rule to Dereference Pointers June 1999
To maintain client efficiency, it is desirable to define an
extensible match rule that allows a LDAP search filter not to an
object, but to the objects that are pointed to by DN pointers
contained in a particular attribute of the base object of the search.
2. derefencingMatch
A server will advertise support for this matching rule by having the
following rule definition present in its root subschema subentry.
( <oid-m1> NAME "derefencingMatch"
DESC "Extended match that dereferences before searching"
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
)
This extensibleMatch filter is used by a client presenting <oid-m1>
as the matchingRule, any attribute with DN syntax as the type and a
string representation of a LDAP search filter as the value. The
server first collects the objects that the attribute points to and
the client has permission to read and then applies the specified LDAP
filter to them, returning the objects that were matched.
For example, a client that presented the following filter:
(targetDN:<oid-m1>:=(&(objectClass=dmtfActiveConnection)(trafficType=2)))
The server would apply the filter specified to all objects referenced
to by the values of the targetDN attribute of the current object. It
would then return the requested attributes of the objects that
matched the specified filter.
If the LDAP filter itself contains a dereferencingMatch rule, it is
possible to do double dereferencing. The following filter causes the
server to first apply the embedded filter (trafficType=2) to objects
pointed to by the dmtfActiveConnectionRefs attribute of the base
object. Requested attributes of all objects pointed to by the
destinationDmtfProtocolEndpointsRef attribute of objects that passed
the first filter are then returned to the client.
(destinationDmtfProtocolEndpointsRef:<oid-m1>:=
(dmtfActiveConnectionRefs:<oid-m1>:=(trafficType=2)))
In cases where a client does not have permission to access an object
pointed to by a reference, that object is not placed on the list.
3. Interaction with sizelimit
If the number of objects that result from the application of the
search filter exceed the size limit, the server MUST respond with a
size limit exceeded error.
Expires 12/31/99 [Page 2]
INTERNET DRAFTExtensible Match Rule to Dereference Pointers June 1999
4. Search scoping considerations
Because of the possibility of size limit overload and the loss of
relationship between the returned objects and the source object
during one-level or subtree searches, it is strongly recommended that
this match rule only be used with base level searches.
5. Security considerations
An improperly formed query can create a denial of service attack by
using up excessive resources. Therefore, queries of this type should
also specify a specific time limit to ensure that other clients can
continue to make use of the directory.
In addition, by allowing a client to request that the server collect
objects before applying the search filter, a client may be able to
determine information about what objects they have rights to search
on. This is no different from what is possible using a subtree
search.
6. References
Request For Comments (RFC) and Internet Draft documents are available
from numerous mirror sites.
[1] J. Strassner, E. Ellesson, B. Moore, "Policy Frame-
work Core Information Model," Internet Draft (work
in progress), May 1999.
5. Author's Addresses
Ryan Moats Jerry Maziarski John Strassner
15621 Drexel Circle Room C3-3Z01 Cisco Systems, Bldg 1
Omaha, NE 68135 200 S. Laurel Ave. 170 West Tasman Drive
USA Middletown, NJ 07748 San Jose, CA 95134
E-mail: jayhawk@att.com USA E-mail:
johns@cisco.com
E-mail: gfm@qsun.att.com
Expires 12/31/99 [Page 3]