Subject: I-D ACTION:draft-ietf-ldapext-matchedval-04.txt

From: [email-masked]
Date: Tue, 17 Oct 2000 06:50:17 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP Extension Working Group of the IETF.

	Title		: Returning Matched Values with LDAPv3
	Author(s)	: D. Chadwick, S. Mullan
	Filename	: draft-ietf-ldapext-matchedval-04.txt
	Pages		: 8
	Date		: 16-Oct-00
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-matchedval-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldapext-matchedval-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ldapext-matchedval-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 17 Oct 2000 23:03:12 -0700

Section 5 says:
 The string representation of the valuesReturnFilter in the examples 
 below uses the notation defined in RFC 2254 [11].

However, as a valuesReturnFilter is a sequence of simple
filters, the string representation of valuesReturnFilter is
actually more like:

	valuesReturnFilter = "(" 1*simplefilter ")"
	simplefilter = "(" item ")"

where item is as defined by RFC2254.  I suggest the string
representation should be specified in the I-D.

Using the above BNF, all of the single item valueReturnFilter
presented in the examples need to be wrapped by another set of
parens, e.g:  ((attributeTypes=1.2.3.4.5))

One could define a BNF that for sequences of 1 simplefilter
the outer parens were eliminated.  However, having the
outer parens distinguishes valueReturnFilters from
filters.

Kurt

---

From: "David Chadwick" <[email-masked]>
Date: Sat, 21 Oct 2000 16:08:22 +0100

From:           	"Kurt D. Zeilenga" <[email-masked]>

>  simplefilter = "(" item ")"

Yes you are right

> representation should be specified in the I-D.

Do you mean repeating all the "item" BNF from 2254, or just 
inserting the 2 lines above. I have assumed the latter and made that 
change.

> parens, e.g:  ((attributeTypes=1.2.3.4.5))

agreed and done for version 5.

David

> outer parens distinguishes valueReturnFilters from

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 21 Oct 2000 08:36:04 -0700

>inserting the 2 lines above. I have assumed the latter and made that 

I prefer the latter.  However, it would be okay to include
an "informational purposes only" copy the BNF from 2254 if
so desired.