< draft-moats-ldap-dereference-match-01.txt		draft-moats-ldap-dereference-match-02.txt >
	Internet-Draft Ryan Moats		Internet-Draft Ryan Moats
	draft-moats-ldap-dereference-match-01.txt Jerry Maziarski		draft-moats-ldap-dereference-match-02.txt Jerry Maziarski
	Expires in six months AT&T		Expires in six months AT&T
	Category: Standards Track John Strassner		Category: Experimental Track John Strassner
	cisco Systems		cisco Systems
	June 1999		December 1999
	Extensible Match Rule to Dereference Pointers		Extensible Match Rule to Dereference Pointers
	Filename: draft-moats-ldap-dereference-match-01.txt		Filename: draft-moats-ldap-dereference-match-02.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are working		all provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	1. Introduction		1. Introduction
	When mapping rich information models, it sometimes becomes necessary		When mapping rich information models, it sometimes becomes necessary
	to use DN pointers to show relationships between objects in the		to use DN pointers to show relationships between objects in the
	schema. An example is the information model and resulting core		schema. An example is the information model and resulting core
	schema that is currently being proposed by the policy working group		schema that is currently being proposed by the policy working group
	(see [1]).		(see [1]).
	To maintain client efficiency, it is desirable to define an		To maintain client efficiency, it is desirable to define an
	extensible match rule that allows a LDAP search filter not to an		extensible match rule that follows DN pointers as part of a query.
	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. dereferencingMatch		2. dereferencingMatch
	A server will advertise support for this matching rule by having the		A server will advertise support for this matching rule by having the
	following rule definition present in its root subschema subentry.		following rule definition present in its root subschema subentry.
	( <oid-m1> NAME "dereferencingMatch"		( <oid-m1> NAME "dereferencingMatch"
	DESC "Extended match that dereferences before searching"		DESC "Extended match that dereferences before searching"
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12		SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	)		)
	This extensibleMatch filter is used by a client presenting <oid-m1>		This extensibleMatch filter is used by a client presenting <oid-m1>
	as the matchingRule, any attribute with DN syntax as the type and a		as the matchingRule, any attribute with DN syntax as the type and a
	string representation of a LDAP search filter as the value. The		string representation of a LDAP search filter as the value. The
	server first collects the objects that the attribute points to and		server first collects the objects that the attribute points to and
	the client has permission to read and then applies the specified LDAP		the client has permission to read and then applies the specified LDAP
	filter to them, returning the objects that were matched.		filter to them, returning the objects that were matched.
	For example, a client that presented the following filter:		For example, a client that presented the following filter:
	(targetDN:<oid-m1>:=(&(objectClass=dmtfActiveConnection)(trafficType=2)))		(targetDN:<oid-m1>:=(&(objectClass=cimActiveConnection)(trafficType=2)))
	The server would apply the filter specified to all objects referenced		The server would apply the filter specified to all objects referenced
	to by the values of the targetDN attribute of the current object. It		to by the values of the targetDN attribute of the current object. It
	would then return the requested attributes of the objects that		would then return the requested attributes of the objects that
	matched the specified filter.		matched the specified filter.
	If the LDAP filter itself contains a dereferencingMatch rule, it is		If the LDAP filter itself contains a dereferencingMatch rule, it is
	possible to do double dereferencing. The following filter causes the		possible to do double dereferencing. The following filter causes the
	server to first apply the embedded filter (trafficType=2) to objects		server to first apply the embedded filter (trafficType=2) to objects
	pointed to by the dmtfActiveConnectionRefs attribute of the base		pointed to by the cimActiveConnectionRefs attribute of the base
	object. Requested attributes of all objects pointed to by the		object. Requested attributes of all objects pointed to by the
	destinationDmtfProtocolEndpointsRef attribute of objects that passed		cimProtocolEndpointsRef attribute of objects that passed the first
	the first filter are then returned to the client.		filter are then returned to the client.
	(destinationDmtfProtocolEndpointsRef:<oid-m1>:=		(cimProtocolEndpointsRef:<oid-m1>:=
	(dmtfActiveConnectionRefs:<oid-m1>:=(trafficType=2)))		(cimActiveConnectionRefs:<oid-m1>:=(trafficType=2)))
	In cases where a client does not have permission to access an object		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.		pointed to by a reference, that object is not placed on the list.
	3. Considerations		3. Considerations
	3.1 Advertisement		3.1 Advertisement
	A server implementing this extended match rule MUST include the OID of		A server implementing this extended match rule MUST include the OID of
	this matching rule in the subschema entry of the root DSE, per RFCs 2251		this matching rule in the subschema entry of the root DSE, per RFCs 2251
	[2].		[2].
	3.2 Non-supporting Server Reply		3.2 Non-supporting Server Reply
	Servers that do not support this extension MUST follow section 7.8 of		Servers that do not support this extension MUST follow section 7.8 of
	X.511 [3]. This is consistent with RFC 2251.		X.511 [3]. This is consistent with RFC 2251.
	3.3 Interaction with sizelimit		3.3 Interaction with sizelimit
	If the number of objects that result from the application of the search		During the application of this search filter, intermediate collections
	filter exceed the size limit, the server MUST respond with a size limit		of entries will result. If the number of entries in these intermediate
	exceeded error.		collections exceed the server's size limit, the server MUST respond with
			size limit exceeded error.
	3.4 Search scoping considerations		3.4 Search scoping considerations
	Because of the possibility of size limit overload and the loss of		Because of the possibility of size limit overload and the loss of
	relationship between the returned objects and the source object		relationship between the returned objects and the source object
	during one-level or subtree searches, it is strongly recommended that		during one-level or subtree searches, it is strongly recommended that
	this match rule only be used with base level searches.		this match rule only be used with base level searches.
	3.5 Combining with other search filters		3.5 Combining with other search filters
	Because this extensible matching rule is intended to result in		Because this extensible matching rule is intended to result in
	objects and not a true/false value, rules for combination with other		objects and not a true/false value, rules for combination with other
	filters is necessary. When combining filters, all non-dereferencing		filters are necessary. When combining filters, all non-dereferencing
	match filters at the level of the dereferencing-match are applied to		match filters at the level of the dereferencing-match are applied to
	the current object first. Then, any remaining objects have the		the current object first. Then, any remaining objects have the
	dereferencing match applied to it.		dereferencing match applied to it.
	This rule means that it is illegal to have two dereferencing match		This rule means that it is illegal to have two dereferencing match
	filters at the same level. The only legal combination is for a		filters at the same level. The only legal combination is for a
	dereferencing match filter to "include" another dereferencing match		dereferencing match filter to "include" another dereferencing match
	filter. This would allow a two step pointer dereferencing.		filter. This would allow a multi-step pointer dereferencing.
	Also, it is illegal for a boolean filter to be at a level "above" the		Also, it is illegal for a boolean filter to be at a level "above" the
	dereferencing match, because of scope conflicts.		dereferencing match, because of scope conflicts.
	To help clarify this rule, the following examples are provided:		To help clarify this rule, the following examples are provided:
	&(targetDN:<oid-m1>:=(&(objectClass=dmtfActiveConnection)		&(targetDN:<oid-m1>:=(&(objectClass=cimActiveConnection)
	(trafficType=2)))		(trafficType=2)))
	(sourceDN:<oid-m1>:=(objectClass=foobar)		(sourceDN:<oid-m1>:=(objectClass=foobar)
	This filter is illegal because it specifies two dereferencing match		This filter is illegal because it specifies two dereferencing match
	rules at the same level.		rules at the same level.
	(targetDN:<oid-m1>:=(sourceDN:<oid-m1>:=(objectClass=*)))		(targetDN:<oid-m1>:=(sourceDN:<oid-m1>:=(objectClass=*)))
	This filter is legal and returns all objects pointed to by the		This filter is legal and returns all objects pointed to by the
	sourceDN attribute of all objects pointed to by the targetDN		sourceDN attribute of all objects pointed to by the targetDN
	attribute of all objects in the search scope.		attribute of all objects in the search scope.
	&(objectClass=fancyconnectiontype)		&(objectClass=fancyconnectiontype)
	(targetDN:<oid-m1>:=(&(objectClass=dmtfActiveConnection)		(targetDN:<oid-m1>:=(&(objectClass=cimActiveConnection)
	(trafficType=2)))		(trafficType=2)))
	This filter is legal, and would return all objects pointed to by the		This filter is legal, and would return all objects pointed to by the
	targetDN attribute of objects whose objectClass attribute was equal		targetDN attribute of objects whose objectClass attribute was equal
	to fancyconnectiontype that had their objectClass attribute equal to		to fancyconnectiontype that had their objectClass attribute equal to
	dmtfActiveConnection and their trafficType attribute equal to 2.		cimActiveConnection and their trafficType attribute equal to 2.
	|(foo=bar)		|(foo=bar)
	(foo=barshelf)		(foo=barshelf)
	(&(objectClass=fancyconnectiontype)		(&(objectClass=fancyconnectiontype)
	(targetDN:<oid-m1>:=(&(objectClass=dmtfActiveConnection)		(targetDN:<oid-m1>:=(&(objectClass=cimActiveConnection)
	(trafficType=2))))		(trafficType=2))))
	This filter is illegal because the first two filters are at a		This filter is illegal because the first two filters are at a
	"higher" level than the dereferencing match filter.		"higher" level than the dereferencing match filter.
	3.6 How to handle referrals		3.6 How to handle referrals
	In the case of a query that encounters referrals, the solution set		For a query that encounters referrals, the solution set returns
	returns answers based on the local data set only. Referrals should		answers based on the local data set only. Referrals should be
	be returned so that the client may submit the query to the referred		returned using a rewritten query contained in a LDAP URL so that the
	machine.		client may submit the rewritten query to the referred machine.
			Without query rewriting, it would be impossible for the client to
			know at what stage of pointer dereferencing the referral occurred.
	4. Examples of Use		4. Examples of Use
	We present two (admittedly simple) examples for how this rule could		We present two (admittedly simple) examples for how this rule could
	be used.		be used.
	4.1 White Pages Example		4.1 White Pages Example
	In our first example, a directory holds white pages information,		In our first example, a directory holds white pages information,
	including building managers for buildings. In their schema,		including building managers for buildings. In their schema,
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 31 ¶
	QosPolicyDirection (integer) and policyRulesAuxContainedSet (multi-		QosPolicyDirection (integer) and policyRulesAuxContainedSet (multi-
	valued DN). This latter attribute points, in turn, to policy rules		valued DN). This latter attribute points, in turn, to policy rules
	(objectClass: policyRule) with multiple attributes.		(objectClass: policyRule) with multiple attributes.
	To find policy rules for outbound traffic (QosPolicyDirection = 2)		To find policy rules for outbound traffic (QosPolicyDirection = 2)
	for routers with IP address 192.128.170.x, the following search could		for routers with IP address 192.128.170.x, the following search could
	be used		be used
	query type: subtree		query type: subtree
	filter: (policyRulesAuxContainedSet:<oid-m1>:		filter: (policyRulesAuxContainedSet:<oid-m1>:
	&(ipAddress="192.128.170.*")		&(ipAddress="192.128.170.*")
	(qosPolicyRules:<oid>:(QosPolicyDirection=2)))		(qosPolicyRules:<oid-m1>:(QosPolicyDirection=2)))
	returned attributes: all		returned attributes: all
			4.3 Referral Example
			As an example of how query-rewriting occurs during a referral, let us
			consider the example from section 4.2 above. It could be possible
			that policy rules for the routers are stored under a different
			portion of the directory tree that is contained in a different server
			(for example referral.foo.bar on port 389). In that case, the
			referral would point to object <dn> and the following URL would be
			returned:
			ldap://referral.foo.bar/<dn>?sub?(qosPolicyRules:<oid-m1>
			:(QosPolicyDirection=2))
			The client could then follow this URL to continue the search.
	5. Why use an extensible matching rule rather than a control?		5. Why use an extensible matching rule rather than a control?
	An alternative implementation of this procedure would be to use a new		An alternative implementation of this procedure would be to use a new
	control, rather than an extensible matching rule. We have considered		control, rather than an extensible matching rule. We have considered
	this, but have failed to find a method for supporting multiple levels		this, but have failed to find a method for supporting multiple levels
	of dereferencing, which can be supported when using an extensible		of dereferencing, which can be supported when using an extensible
	matching rule.		matching rule.
	6. Security considerations		6. Security considerations
	An improperly formed query can create a denial of service attack by		An improperly formed query can create a denial of service attack by
	using up excessive resources. Therefore, queries of this type should		using up excessive resources. Therefore, servers that support
	also specify a specific time limit to ensure that other clients can		queries of this type should implement specific time limits that
	continue to make use of the directory.		cannot be overriddent 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		Although this type of query allows a client to request that the
	objects before applying the search filter, a client may be able to		server collect objects before applying the search filter, it creates
	determine information about what objects they have rights to search		no additional security issues above what needs to be considered when
	on. This is no different from what is possible using a subtree		allowing a subtree search.
	search.
	7. References		7. References
	Request For Comments (RFC) and Internet Draft documents are available		Request For Comments (RFC) and Internet Draft documents are available
	from numerous mirror sites.		from numerous mirror sites.
	[1] J. Strassner, E. Ellesson, B. Moore, "Policy Framework Core		[1] J. Strassner, E. Ellesson, B. Moore, R. Moats,
	Information Model," Internet Draft (work in progress), May		"Policy Framework Core Information Model," Internet
	1999.		Draft (work in progress), November 1999.
	[2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access		[2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
	Protocol (v3)," RFC 2251, December 1997.		Access Protocol (v3)," RFC 2251, December 1997.
	[3] ITU-T Rec. X.511, "The Directory: Abstract Service Defini-		[3] ITU-T Rec. X.511, "The Directory: Abstract Service
	tion," 1993.		Definition," 1993.
	7. Author's Addresses		7. Author's Addresses
	Ryan Moats Jerry Maziarski John Strassner		Ryan Moats Jerry Maziarski John Strassner
	15621 Drexel Circle Room C3-3Z01 Cisco Systems, Bldg 1		15621 Drexel Circle Room C3-3Z01 Cisco Systems, Bldg 1
	Omaha, NE 68135 200 S. Laurel Ave. 170 West Tasman Drive		Omaha, NE 68135 200 S. Laurel Ave. 170 West Tasman Drive
	USA Middletown, NJ 07748 San Jose, CA 95134		USA Middletown, NJ 07748 San Jose, CA 95134
	E-mail: jayhawk@att.com USA E-mail:		E-mail: jayhawk@att.com USA E-mail:
	johns@cisco.com		johns@cisco.com
	E-mail: gfm@qsun.att.com		E-mail: gfm@qsun.att.com
End of changes. 25 change blocks.
	47 lines changed or deleted		63 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/