Subject: I-D ACTION:draft-ietf-ldapext-ldapv3-dupent-02.txt

From: [email-masked]
Date: Mon, 18 Oct 1999 06:52:43 -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		: LDAP Control for a Duplicate Entry Representation of  
                          Search Results
	Author(s)	: J. Sermersheim
	Filename	: draft-ietf-ldapext-ldapv3-dupent-02.txt
	Pages		: 8
	Date		: 15-Oct-99
	
This document describes a Duplicate Entry Representation control
extension for the LDAP Search operation. By using the control with
an LDAP search, a client requests that the server return separate
entries for each value held in the specified attributes. For
instance, if a specified attribute of an entry holds multiple
values, the search operation will return multiple instances of that
entry, each instance holding a separate single value in that
attribute.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-dupent-02.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-ldapv3-dupent-02.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-ldapv3-dupent-02.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: "Salter, Thomas A" <[email-masked]>
Date: Mon, 18 Oct 1999 10:16:30 -0400

Why does this control define its own error results?  Can't these error
conditions all be handled in the error result of the search operation?  If
not, how do the two error conditions interact?  Is it possible for the
search to succeed, but the control to fail?

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 18 Oct 1999 10:25:53 -0600

Right, I included those errors for cases where a search may succeed, but the use of the control causes a failure. I tried to limit the error types to those that could be caused by servicing the control.  I believe the server side sort and virtual list view controls do this as well.

Jim

>>> "Salter, Thomas A" <[email-masked]> 10/18/99 08:17AM >>>

---

From: "Salter, Thomas A" <[email-masked]>
Date: Mon, 18 Oct 1999 13:21:59 -0400

Ok, but in that case, I think you should include a description of behavior
when the control returns an error but the search succeeds.   Is the result
the same as if the control was not specified?  What if the control is
critical?  Maybe another way of asking this question is, 'Of what use is
this information to the client?'  Why not just combine this error status in
the search result status?  

I can certainly see an advantage in returning extra error information if the
control is ignored because of the error.  Then there is clearly two pieces
of information to convery: the reason the control was ignored and the status
of the search.  On the other hand, if the operation is rejected because of
the control error, then why not put the status directly in the search
result.

If server side sort and virtual list view controls also do this, then these
same questions apply to those drafts.

Suppose all three (sort, vlv, and dupent) controls are specified on a
search.  What is the procedure the client app uses to test all the command
statuses and decide how to proceed?

 > -----Original Message-----
 > From: Jim Sermersheim [mailto:[email-masked]]
 > Sent: Monday, October 18, 1999 12:26 PM
 > To: [email-masked]; [email-masked]
 > Subject: RE: I-D ACTION:draft-ietf-ldapext-ldapv3-dupent-02.txt
 > 
 > 
 > Right, I included those errors for cases where a search may 
 > succeed, but the use of the control causes a failure. I 
 > tried to limit the error types to those that could be caused 
 > by servicing the control.  I believe the server side sort 
 > and virtual list view controls do this as well.
 > 
 > Jim
 >

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 18 Oct 1999 12:17:13 -0600

Good point on the error codes.  I'll take a look at specifying when one would use the extra errors as opposed to the normal result codes, and use the criticality of the control as the dissection line.

As far as all three 'list' controls being used at once, though there are some server implementation instructions, nothing is said about how clients should handle one or more controls failing.  I'll look into what useful information could be included for clients.

Jim

>>> "Salter, Thomas A" <[email-masked]> 10/18/99 11:21AM >>>