From ldapext-admin@ietf.org Tue Oct 1 01:52:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08126 for ; Tue, 1 Oct 2002 01:52:19 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g915quv16463; Tue, 1 Oct 2002 01:52:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g915pxv16411 for ; Tue, 1 Oct 2002 01:51:59 -0400 Received: from theano.catalogix.se (diamond.catalogix.se [212.217.248.41] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08076 for ; Tue, 1 Oct 2002 01:49:52 -0400 (EDT) Received: from [195.7.86.156] (helo=theano) by theano.catalogix.se with esmtp (Exim 4.05) id 17wG0M-0008JE-00 for ldapext@ietf.org; Tue, 01 Oct 2002 07:55:34 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Roland Hedberg Reply-To: roland@catalogix.se Organization: Catalogix To: ldapext Subject: Re: [ldapext] VLV: a particular target entry Date: Tue, 1 Oct 2002 07:52:04 +0200 X-Mailer: KMail [version 1.4] References: <3D945815.8060009@netscape.com> In-Reply-To: <3D945815.8060009@netscape.com> MIME-Version: 1.0 Message-Id: <200210010752.04438.roland@catalogix.se> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g915pxv16412 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Friday 27 September 2002 15:07, Mark C Smith wrote: > John McMeeking wrote: > > I agree with Kurt that positioning by DN would be useful, and it seems > > simple to implement. > > ... > > The real question in my mind is whether additional features like this > should be added to the VLV protocol now. I say no, it is too late: the > current VLV specification has been extensively reviewed and has been > held up on a minor issue for about 2 years now. Let's publish it as a > Proposed Standard and move on. Extensions to VLV or a VLV2 can of course > be pursued by anyone with time and interest. I totally agreee with this. This workinggroup will not make a complete remake of VLV. Anyone wanting to do so should seriously consider forming a new working group. If there is not consensus within this group to continue with the VLV draft with only minor modifications, I would propose that the group drops it and let the authors publish it as an individual contribution. Please bear in mind that this group is no more, it's just formally around since all its drafts aren't through to RFC status yet. -- Roland _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From sip-admin@ietf.org Tue Oct 1 06:17:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05912 for ; Tue, 1 Oct 2002 06:17:12 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91AIev29074 for ; Tue, 1 Oct 2002 06:18:40 -0400 Date: Tue, 01 Oct 2002 06:18:40 -0400 Message-ID: <20021001101840.2977.17760.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder To: ldapext-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ldapext-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@. Thanks! Passwords for ldapext-archive@lists.ietf.org: List Password // URL ---- -------- ldapext@ietf.org LxAC https://www1.ietf.org/mailman/options/ldapext/ldapext-archive%40lists.ietf.org From ldapext-admin@ietf.org Tue Oct 1 10:12:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18742 for ; Tue, 1 Oct 2002 10:12:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EDKv00939; Tue, 1 Oct 2002 10:13:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EAgv00558 for ; Tue, 1 Oct 2002 10:10:42 -0400 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18474 for ; Tue, 1 Oct 2002 10:08:41 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g91EAUEe027570; Tue, 1 Oct 2002 14:10:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021001070734.02916050@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Oct 2002 07:10:16 -0700 To: roland@catalogix.se From: "Kurt D. Zeilenga" Subject: Re: [ldapext] VLV: a particular target entry Cc: ldapext In-Reply-To: <200210010752.04438.roland@catalogix.se> References: <3D945815.8060009@netscape.com> <3D945815.8060009@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 10:52 PM 2002-09-30, Roland Hedberg wrote: >I totally agreee with this. Do you not see that VLV is broken without selection by DN. That is, the VLV scroll up/down mechanism fails in the general case, e.g. when content is unstable. This isn't about a NEW feature. It's about scrolling that works. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Oct 1 10:21:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19133 for ; Tue, 1 Oct 2002 10:21:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EM3v02213; Tue, 1 Oct 2002 10:22:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EL8v02143 for ; Tue, 1 Oct 2002 10:21:08 -0400 Received: from blackbear.mtbrook.boreham.org (server1.montana.boreham.org [63.112.219.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19004 for ; Tue, 1 Oct 2002 10:19:08 -0400 (EDT) Received: from squirrel ([192.168.10.22]) by blackbear.mtbrook.boreham.org with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Oct 2002 07:21:41 -0700 Message-ID: <080c01c26955$dca9b000$160aa8c0@mtbrook.boreham.org> From: "David Boreham" To: "ldapext" References: <3D945815.8060009@netscape.com> <3D945815.8060009@netscape.com> <5.1.0.14.0.20021001070734.02916050@127.0.0.1> Subject: Re: [ldapext] VLV: a particular target entry Date: Tue, 1 Oct 2002 07:21:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-OriginalArrivalTime: 01 Oct 2002 14:21:41.0456 (UTC) FILETIME=[DCA25D00:01C26955] Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Do you not see that VLV is broken without selection by DN. > That is, the VLV scroll up/down mechanism fails in the > general case, e.g. when content is unstable. Highly unstable content isn't within the scope of this protocol. Directories typically don't have highly unstable content. > This isn't about a NEW feature. It's about scrolling > that works. Strangely, the existing protocol has been 'working' for many folks for many years. AFAIK in the IETF culture, working interoperable implementations are considered something of an advantage vs theoretical complaints. Kurt: do you have a counterexample ? e.g. something you tried to implement with the current protocol but failed to get to work ? Tell us about it. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Oct 1 11:10:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21931 for ; Tue, 1 Oct 2002 11:10:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91FAOv05833; Tue, 1 Oct 2002 11:10:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91F9Uv05790 for ; Tue, 1 Oct 2002 11:09:30 -0400 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21824 for ; Tue, 1 Oct 2002 11:07:29 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g91F9PEe027902; Tue, 1 Oct 2002 15:09:25 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021001075534.0290df78@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Oct 2002 08:09:11 -0700 To: "David Boreham" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] VLV: a particular target entry Cc: "ldapext" In-Reply-To: <080c01c26955$dca9b000$160aa8c0@mtbrook.boreham.org> References: <3D945815.8060009@netscape.com> <3D945815.8060009@netscape.com> <5.1.0.14.0.20021001070734.02916050@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 07:21 AM 2002-10-01, David Boreham wrote: >> Do you not see that VLV is broken without selection by DN. >> That is, the VLV scroll up/down mechanism fails in the >> general case, e.g. when content is unstable. > >Highly unstable content isn't within the scope of this >protocol. Note that I did not say "highly unstable". I said "unstable". That is, one entry add/modification/delete is sufficient to cause this protocol to fail. >Directories typically don't have highly unstable content. But directories typically do change. And any change is sufficient to cause failure in this protocol. >Kurt: do you have a counterexample ? e.g. something >you tried to implement with the current protocol but failed >to get to work ? Tell us about it. Based upon my operational experience with implementing similar controls, it is obvious to me that the current protocol fails where contain is not stable. In particular, were DIT modification causes the positioning of entries in the list to shift. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 07:16:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02225 for ; Thu, 3 Oct 2002 07:16:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93BFLv06920; Thu, 3 Oct 2002 07:15:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93BDDv06745 for ; Thu, 3 Oct 2002 07:13:13 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01824; Thu, 3 Oct 2002 07:11:11 -0400 (EDT) Message-Id: <200210031111.HAA01824@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Oct 2002 07:11:11 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldapext-vlv-00.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP (Alternative) Virtual List View Operation Author(s) : K. Zeilenga Filename : draft-zeilenga-ldapext-vlv-00.txt Pages : 18 Date : 2002-10-2 This document describes an LDAP (Lightweight Directory Access Protocol) Virtual List View (VLV) operation. The operation allows the client to obtain portion (the view) of an ordered set (the list) of entries visible through a virtual window. The client can reissue the operation with different criteria to obtain a different view of the list. Clients may use this operation to page, scroll, or browse directory content. The VLV operation is defined as a set of LDAP controls which extend the Search operation. The VLV controls may be used in conjunction with a number of other search controls, such as the Server Side Sorting of Search Results (RFC 2891) control. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldapext-vlv-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-zeilenga-ldapext-vlv-00.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldapext-vlv-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-2132755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldapext-vlv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldapext-vlv-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-2132755.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 09:52:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09135 for ; Thu, 3 Oct 2002 09:52:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Dojv17905; Thu, 3 Oct 2002 09:50:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Dnev17771 for ; Thu, 3 Oct 2002 09:49:40 -0400 Received: from netscape.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08726 for ; Thu, 3 Oct 2002 09:47:37 -0400 (EDT) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id g93D08m25830 for ; Thu, 3 Oct 2002 06:00:08 -0700 (PDT) Received: from netscape.com ([10.169.192.41]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H3ERQN01.HV5 for ; Thu, 3 Oct 2002 06:49:35 -0700 Message-ID: <3D9C4AEE.3070309@netscape.com> Date: Thu, 03 Oct 2002 09:49:34 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ldapext@ietf.org Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldapext-vlv-00.txt References: <200210031111.HAA01824@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In my opinion, a very important and useful feature of the IETF process is that the authors of a document retain considerable control over the direction and scope of the work. Publishing an alternative to VLV as Kurt has done is one way to sidestep that constraint... but I do not think it is a good approach. The IETF has a long standing tradition of carefully balancing features, time-to-market, ease of implementation, and interoperability. I believe that Kurt's new I-D suffers has too many features, is at least 2 years late to market, will be difficult to implement in an effective and efficient manner on the server side, and therefore the likelihood that a large number of interoperable implementations will be created is very low. I feel strongly that draft-ietf-ldapext-ldapv3-vlv-08.txt should be published as a Proposed Standard (with minor changes if WG consensus dictates that they are needed). Of course I will leave it to the LDAPEXT WG chairs to judge consensus on this issue and provide the group with direction. -Mark Smith Netscape Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : LDAP (Alternative) Virtual List View Operation > Author(s) : K. Zeilenga > Filename : draft-zeilenga-ldapext-vlv-00.txt > Pages : 18 > Date : 2002-10-2 > > This document describes an LDAP (Lightweight Directory Access > Protocol) Virtual List View (VLV) operation. The operation allows the > client to obtain portion (the view) of an ordered set (the list) of > entries visible through a virtual window. The client can reissue the > operation with different criteria to obtain a different view of the > list. Clients may use this operation to page, scroll, or browse > directory content. > The VLV operation is defined as a set of LDAP controls which extend > the Search operation. The VLV controls may be used in conjunction > with a number of other search controls, such as the Server Side > Sorting of Search Results (RFC 2891) control. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zeilenga-ldapext-vlv-00.txt > ... _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 11:18:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17242 for ; Thu, 3 Oct 2002 11:18:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93FHTv26311; Thu, 3 Oct 2002 11:17:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93F9Gv25612 for ; Thu, 3 Oct 2002 11:09:17 -0400 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15737 for ; Thu, 3 Oct 2002 11:07:12 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g93F9BEe041171 for ; Thu, 3 Oct 2002 15:09:11 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021003074619.02916520@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Oct 2002 08:08:55 -0700 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldapext-vlv-00.txt In-Reply-To: <200210031111.HAA01824@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , As discussed recently on this list, draft-ietf-ldapext-ldapv3-vlv scroll up/down mechanism does not work when directory content changes. One entry add/delete/modify is sufficient to cause problems. The authors have confirmed that draft-ietf-ldapext-ldapv3-vlv scrolling mechanism was designed to work with static directory content. I believe this to be a serious flaw in the design of this extension. Standard track LDAP extensions should be designed to handle dynamic directory content. I have authored an alternative to demonstrate a scrolling and browsing approach designed to handle dynamic directory content. In moving forward, I would like to see draft-ietf-ldapext-ldapv3-vlv be modified to address dynamic directory content. I see two ways it could address dynamic directory content. 1) redesign as necessary to handle dynamic directory content or 2) clearly state that the extension is only applicable when the directory content is stable. In case 1), I hope my I-D will be of some use to the authors. In case 2), I suggest the authors don't pursue the work further on the Standard Track. Kurt At 04:11 AM 2002-10-03, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : LDAP (Alternative) Virtual List View Operation > Author(s) : K. Zeilenga > Filename : draft-zeilenga-ldapext-vlv-00.txt > Pages : 18 > Date : 2002-10-2 > >This document describes an LDAP (Lightweight Directory Access >Protocol) Virtual List View (VLV) operation. The operation allows the >client to obtain portion (the view) of an ordered set (the list) of >entries visible through a virtual window. The client can reissue the >operation with different criteria to obtain a different view of the >list. Clients may use this operation to page, scroll, or browse >directory content. >The VLV operation is defined as a set of LDAP controls which extend >the Search operation. The VLV controls may be used in conjunction >with a number of other search controls, such as the Server Side >Sorting of Search Results (RFC 2891) control. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-zeilenga-ldapext-vlv-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-zeilenga-ldapext-vlv-00.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: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-zeilenga-ldapext-vlv-00.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. >Content-Type: text/plain >Content-ID: <2002-10-2132755.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-zeilenga-ldapext-vlv-00.txt > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 11:30:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18153 for ; Thu, 3 Oct 2002 11:30:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93FT5v27228; Thu, 3 Oct 2002 11:29:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93FSav27209 for ; Thu, 3 Oct 2002 11:28:36 -0400 Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17900 for ; Thu, 3 Oct 2002 11:26:32 -0400 (EDT) Received: from rowlf.Central.Sun.COM ([129.153.131.70]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27238; Thu, 3 Oct 2002 09:28:32 -0600 (MDT) Received: from sun.com (dhcp-uaus09-130-183 [129.153.130.183]) by rowlf.Central.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id g93FSU401988; Thu, 3 Oct 2002 10:28:31 -0500 (CDT) Message-ID: <3D9C62CE.DA2870CC@sun.com> Date: Thu, 03 Oct 2002 10:31:26 -0500 From: Mark Wahl X-Mailer: Mozilla 4.77 [en]C-CCK-MCD NSCPCD477 (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: Mark C Smith CC: ldapext@ietf.org Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldapext-vlv-00.txt References: <200210031111.HAA01824@ietf.org> <3D9C4AEE.3070309@netscape.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark C Smith wrote: > > I feel strongly that draft-ietf-ldapext-ldapv3-vlv-08.txt should be > published as a Proposed Standard (with minor changes if WG consensus > dictates that they are needed). Of course I will leave it to the LDAPEXT > WG chairs to judge consensus on this issue and provide the group with > direction. VLV was reviewed by the working group and IESG and was submitted to the RFC editor 2 years ago, however a problem with the result codes reference meant that it was not published. I would like to see the VLV draft resolve any problems that have been found and be completed so that it can be published as an RFC. Mark Wahl Sun Microsystems Inc. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 14:20:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29127 for ; Thu, 3 Oct 2002 14:20:30 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93IJBv06893; Thu, 3 Oct 2002 14:19:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93IBiv06606 for ; Thu, 3 Oct 2002 14:11:44 -0400 Received: from blackbear.mtbrook.boreham.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28580 for ; Thu, 3 Oct 2002 14:09:40 -0400 (EDT) Received: from squirrel ([192.168.10.22]) by blackbear.mtbrook.boreham.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Oct 2002 11:12:15 -0700 Message-ID: <04c201c26b08$67592100$160aa8c0@mtbrook.boreham.org> From: "David Boreham" To: References: <200210031111.HAA01824@ietf.org> <3D9C4AEE.3070309@netscape.com> <3D9C62CE.DA2870CC@sun.com> Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldapext-vlv-00.txt Date: Thu, 3 Oct 2002 11:12:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 03 Oct 2002 18:12:15.0663 (UTC) FILETIME=[674A53F0:01C26B08] Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > VLV was reviewed by the working group and IESG and was submitted to the RFC > editor 2 years ago, however a problem with the result codes reference meant > that it was not published. I would like to see the VLV draft resolve any > problems that have been found and be completed so that it can be published > as an RFC. +1 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 14:31:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29646 for ; Thu, 3 Oct 2002 14:31:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93IW5v07609; Thu, 3 Oct 2002 14:32:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93IVrv07590 for ; Thu, 3 Oct 2002 14:31:53 -0400 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29536 for ; Thu, 3 Oct 2002 14:29:49 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g93IVkEe042488; Thu, 3 Oct 2002 18:31:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021003112918.02939d80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Oct 2002 11:31:41 -0700 To: "David Boreham" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldapext-vlv-00.txt Cc: In-Reply-To: <04c201c26b08$67592100$160aa8c0@mtbrook.boreham.org> References: <200210031111.HAA01824@ietf.org> <3D9C4AEE.3070309@netscape.com> <3D9C62CE.DA2870CC@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 11:12 AM 2002-10-03, David Boreham wrote: >> I would like to see the VLV draft resolve any >> problems that have been found and be completed so that it can be published >> as an RFC. > >+1 I agree. Let's resolve the problems with the VLV draft. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 14:51:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00573 for ; Thu, 3 Oct 2002 14:51:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Ip8v08808; Thu, 3 Oct 2002 14:51:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93IoNv08761 for ; Thu, 3 Oct 2002 14:50:23 -0400 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00426 for ; Thu, 3 Oct 2002 14:48:18 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Oct 2002 13:50:08 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Thu, 03 Oct 2002 12:49:26 -0600 From: "Jim Sermersheim" To: , Cc: Subject: Re: [ldapext] VLV: a particular target entry Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Help me understand the stability problem further. If the cookie mechanism is used, a server knows the last view that the client has. If a client asks for a new view (by offset) that overlaps or adjoins the last view, the server should be able to provide contiguous results--even when updates are happening. Jim >>> "Kurt D. Zeilenga" 10/01/02 09:09AM >>> At 07:21 AM 2002-10-01, David Boreham wrote: >> Do you not see that VLV is broken without selection by DN. >> That is, the VLV scroll up/down mechanism fails in the >> general case, e.g. when content is unstable. > >Highly unstable content isn't within the scope of this >protocol. Note that I did not say "highly unstable". I said "unstable". That is, one entry add/modification/delete is sufficient to cause this protocol to fail. >Directories typically don't have highly unstable content. But directories typically do change. And any change is sufficient to cause failure in this protocol. >Kurt: do you have a counterexample ? e.g. something >you tried to implement with the current protocol but failed >to get to work ? Tell us about it. Based upon my operational experience with implementing similar controls, it is obvious to me that the current protocol fails where contain is not stable. In particular, were DIT modification causes the positioning of entries in the list to shift. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 15:05:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01349 for ; Thu, 3 Oct 2002 15:05:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93J64v09425; Thu, 3 Oct 2002 15:06:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93J5hv09382 for ; Thu, 3 Oct 2002 15:05:43 -0400 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01251 for ; Thu, 3 Oct 2002 15:03:37 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g93J5ZEe042707; Thu, 3 Oct 2002 19:05:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021003115109.029417d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Oct 2002 12:05:30 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] VLV: a particular target entry Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 11:49 AM 2002-10-03, Jim Sermersheim wrote: >Help me understand the stability problem further. If the cookie >mechanism is used, a server knows the last view that the client has. If >a client asks for a new view (by offset) that overlaps or adjoins the >last view, the server should be able to provide contiguous results--even >when updates are happening. First, note that the present cookie is optionally provided by the server and optionally returned by the server. It's purpose has been described to allow the server to make optimize processing of related requests. It, however, hasn't been described as a mechanism which the protocol relies on to address content instability. If servers were REQUIRED to provide a cookie and clients were REQUIRED used the cookie in subsequent related requests, then the cookie could be used to address the stability problem. I would refer to this as a "state-full" approach. However, the authors have stated that VLV could be implemented in a "state-less" fashion. No cookies. Either VLV is stateful - some state is needed. stateless - no state is needed. Which is it? >Jim > >>>> "Kurt D. Zeilenga" 10/01/02 09:09AM >>> >At 07:21 AM 2002-10-01, David Boreham wrote: >>> Do you not see that VLV is broken without selection by DN. >>> That is, the VLV scroll up/down mechanism fails in the >>> general case, e.g. when content is unstable. >> >>Highly unstable content isn't within the scope of this >>protocol. > >Note that I did not say "highly unstable". I said "unstable". >That is, one entry add/modification/delete is sufficient >to cause this protocol to fail. > >>Directories typically don't have highly unstable content. > >But directories typically do change. And any change is >sufficient to cause failure in this protocol. > >>Kurt: do you have a counterexample ? e.g. something >>you tried to implement with the current protocol but failed >>to get to work ? Tell us about it. > >Based upon my operational experience with implementing similar >controls, it is obvious to me that the current protocol fails >where contain is not stable. In particular, were DIT >modification causes the positioning of entries in the list to >shift. > >Kurt > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 15:21:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02059 for ; Thu, 3 Oct 2002 15:21:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93JH7v10255; Thu, 3 Oct 2002 15:17:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93JGTv10233 for ; Thu, 3 Oct 2002 15:16:29 -0400 Received: from wstutil12a.ml.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01738 for ; Thu, 3 Oct 2002 15:14:24 -0400 (EDT) Received: from wstutil13a.ml.com (wstutil13a [146.125.185.11]) by wstutil12a.ml.com (8.11.3/8.11.3/wstutil12a-1.2) with ESMTP id g93JGNN22571; Thu, 3 Oct 2002 15:16:23 -0400 (EDT) Received: from ewstwt01.exchange.ml.com (ewstwt01.exchange.ml.com [146.125.249.151]) by wstutil13a.ml.com (8.11.3/8.11.3/wstutil13a-1.1) with SMTP id g93JGN100563; Thu, 3 Oct 2002 15:16:23 -0400 (EDT) Received: from 172.25.100.10 by ewstwt01.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Thu, 03 Oct 2002 15:14:44 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ewst10.exchange.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Thu, 3 Oct 2002 15:16:20 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF04B4C585@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'David Boreham'" , ldapext@ietf.org Subject: RE: [ldapext] I-D ACTION:draft-zeilenga-ldapext-vlv-00.txt Date: Thu, 3 Oct 2002 15:16:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 118248AE295909-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Perhaps it should be published with a cautionary paragraph reflecting Kurt's findings ? -----Original Message----- From: David Boreham [mailto:david_list@boreham.org] Sent: Thursday, October 03, 2002 2:12 PM To: ldapext@ietf.org Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldapext-vlv-00.txt > VLV was reviewed by the working group and IESG and was submitted to the RFC > editor 2 years ago, however a problem with the result codes reference meant > that it was not published. I would like to see the VLV draft resolve any > problems that have been found and be completed so that it can be published > as an RFC. +1 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 16:15:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03450 for ; Thu, 3 Oct 2002 16:15:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KFRv13182; Thu, 3 Oct 2002 16:15:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KE4v13129 for ; Thu, 3 Oct 2002 16:14:04 -0400 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03424 for ; Thu, 3 Oct 2002 16:11:48 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Oct 2002 15:13:38 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Thu, 03 Oct 2002 14:13:00 -0600 From: "Jim Sermersheim" To: Cc: , Subject: Re: [ldapext] VLV: a particular target entry Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The original purpose of the cookie was to provide a way for a server to associate a list with a client/connection. The problem was that a client could be maintaining two VLV lists on the same connection, using the same search criteria. In order for the server to perform certain operations (like consistent page up/down) it was neccessary to add the cookie so that the client's views could be known to the server. Novell is the one that requested it, and it wasn't to solve any performance issues. The reason it was added as an optional component was to not cause backward compatability problems with implementations that existed before its introduction. This should all be captured in the archives. Jim >>> "Kurt D. Zeilenga" 10/03/02 01:05PM >>> At 11:49 AM 2002-10-03, Jim Sermersheim wrote: >Help me understand the stability problem further. If the cookie >mechanism is used, a server knows the last view that the client has. If >a client asks for a new view (by offset) that overlaps or adjoins the >last view, the server should be able to provide contiguous results--even >when updates are happening. First, note that the present cookie is optionally provided by the server and optionally returned by the server. It's purpose has been described to allow the server to make optimize processing of related requests. It, however, hasn't been described as a mechanism which the protocol relies on to address content instability. If servers were REQUIRED to provide a cookie and clients were REQUIRED used the cookie in subsequent related requests, then the cookie could be used to address the stability problem. I would refer to this as a "state-full" approach. However, the authors have stated that VLV could be implemented in a "state-less" fashion. No cookies. Either VLV is stateful - some state is needed. stateless - no state is needed. Which is it? >Jim > >>>> "Kurt D. Zeilenga" 10/01/02 09:09AM >>> >At 07:21 AM 2002-10-01, David Boreham wrote: >>> Do you not see that VLV is broken without selection by DN. >>> That is, the VLV scroll up/down mechanism fails in the >>> general case, e.g. when content is unstable. >> >>Highly unstable content isn't within the scope of this >>protocol. > >Note that I did not say "highly unstable". I said "unstable". >That is, one entry add/modification/delete is sufficient >to cause this protocol to fail. > >>Directories typically don't have highly unstable content. > >But directories typically do change. And any change is >sufficient to cause failure in this protocol. > >>Kurt: do you have a counterexample ? e.g. something >>you tried to implement with the current protocol but failed >>to get to work ? Tell us about it. > >Based upon my operational experience with implementing similar >controls, it is obvious to me that the current protocol fails >where contain is not stable. In particular, were DIT >modification causes the positioning of entries in the list to >shift. > >Kurt > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 16:17:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03494 for ; Thu, 3 Oct 2002 16:17:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KI7v13258; Thu, 3 Oct 2002 16:18:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KHdv13228 for ; Thu, 3 Oct 2002 16:17:39 -0400 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03446 for ; Thu, 3 Oct 2002 16:15:19 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Oct 2002 15:17:10 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Thu, 03 Oct 2002 14:16:51 -0600 From: "Jim Sermersheim" To: Cc: , Subject: Re: [ldapext] VLV: a particular target entry Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I suggest we add more information on the intent of the contextID (cookie) and state that servers choosing to not use it may run into instability problems. Jim >>> "Kurt D. Zeilenga" 10/03/02 01:05PM >>> At 11:49 AM 2002-10-03, Jim Sermersheim wrote: >Help me understand the stability problem further. If the cookie >mechanism is used, a server knows the last view that the client has. If >a client asks for a new view (by offset) that overlaps or adjoins the >last view, the server should be able to provide contiguous results--even >when updates are happening. First, note that the present cookie is optionally provided by the server and optionally returned by the server. It's purpose has been described to allow the server to make optimize processing of related requests. It, however, hasn't been described as a mechanism which the protocol relies on to address content instability. If servers were REQUIRED to provide a cookie and clients were REQUIRED used the cookie in subsequent related requests, then the cookie could be used to address the stability problem. I would refer to this as a "state-full" approach. However, the authors have stated that VLV could be implemented in a "state-less" fashion. No cookies. Either VLV is stateful - some state is needed. stateless - no state is needed. Which is it? >Jim > >>>> "Kurt D. Zeilenga" 10/01/02 09:09AM >>> >At 07:21 AM 2002-10-01, David Boreham wrote: >>> Do you not see that VLV is broken without selection by DN. >>> That is, the VLV scroll up/down mechanism fails in the >>> general case, e.g. when content is unstable. >> >>Highly unstable content isn't within the scope of this >>protocol. > >Note that I did not say "highly unstable". I said "unstable". >That is, one entry add/modification/delete is sufficient >to cause this protocol to fail. > >>Directories typically don't have highly unstable content. > >But directories typically do change. And any change is >sufficient to cause failure in this protocol. > >>Kurt: do you have a counterexample ? e.g. something >>you tried to implement with the current protocol but failed >>to get to work ? Tell us about it. > >Based upon my operational experience with implementing similar >controls, it is obvious to me that the current protocol fails >where contain is not stable. In particular, were DIT >modification causes the positioning of entries in the list to >shift. > >Kurt > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 16:21:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03605 for ; Thu, 3 Oct 2002 16:21:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KL4v13366; Thu, 3 Oct 2002 16:21:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KKWv13348 for ; Thu, 3 Oct 2002 16:20:32 -0400 Received: from blackbear.mtbrook.boreham.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03508 for ; Thu, 3 Oct 2002 16:18:15 -0400 (EDT) Received: from squirrel ([192.168.10.22]) by blackbear.mtbrook.boreham.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Oct 2002 13:20:52 -0700 Message-ID: <05bf01c26b1a$5ea99910$160aa8c0@mtbrook.boreham.org> From: "David Boreham" To: References: Subject: Re: [ldapext] VLV: a particular target entry Date: Thu, 3 Oct 2002 13:20:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 03 Oct 2002 20:20:52.0079 (UTC) FILETIME=[5EA1F7F0:01C26B1A] Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > cookie so that the client's views could be known to the server. Novell > is the one that requested it, and it wasn't to solve any performance I guess I saw it as a performance issue in that the Novell server could serve non-cookied requests, it would just be slow to do so. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 16:31:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03863 for ; Thu, 3 Oct 2002 16:31:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KW5v13776; Thu, 3 Oct 2002 16:32:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KVkv13755 for ; Thu, 3 Oct 2002 16:31:46 -0400 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03810 for ; Thu, 3 Oct 2002 16:29:40 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Oct 2002 15:31:30 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Thu, 03 Oct 2002 14:31:05 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] VLV: a particular target entry Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit nope, it was to do with multiple concurrent duplicate VLVs from a single client on the same connection. I tried poking around the archives so I could quote myself, but there are a bunch of zero-byte archives that I fear hold the messages. Jim >>> "David Boreham" 10/03/02 02:20PM >>> > cookie so that the client's views could be known to the server. Novell > is the one that requested it, and it wasn't to solve any performance I guess I saw it as a performance issue in that the Novell server could serve non-cookied requests, it would just be slow to do so. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 16:37:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04099 for ; Thu, 3 Oct 2002 16:37:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Kc6v14597; Thu, 3 Oct 2002 16:38:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Kb0v13982 for ; Thu, 3 Oct 2002 16:37:00 -0400 Received: from blackbear.mtbrook.boreham.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03969 for ; Thu, 3 Oct 2002 16:34:54 -0400 (EDT) Received: from squirrel ([192.168.10.22]) by blackbear.mtbrook.boreham.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Oct 2002 13:37:31 -0700 Message-ID: <05e901c26b1c$b27b0c20$160aa8c0@mtbrook.boreham.org> From: "David Boreham" To: References: Subject: Re: [ldapext] VLV: a particular target entry Date: Thu, 3 Oct 2002 13:37:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 03 Oct 2002 20:37:31.0696 (UTC) FILETIME=[B2736B00:01C26B1C] Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > nope, it was to do with multiple concurrent duplicate VLVs from a single > client on the same connection. I tried poking around the archives so I > could quote myself, but there are a bunch of zero-byte archives that I > fear hold the messages. I have a pretty clear memory of the discussion. My memory says that it was related to the Novell server implementing only approximate indexing into the lists. Without the cookie, the database engine would need to create a new cursor (or whatever equivalent thing it uses) for every request. With the cookie it keeps cursors live for each client context. The Netscape/Sun servers are able to serve multiple concurrent clients without the cookie (because they maintain an exact index into the list---all state to serve the request unambiguously is carried in the request without needing the context carried over from operation to operation). Perhaps I've been smoking something in the meantime... _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 16:38:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04137 for ; Thu, 3 Oct 2002 16:38:12 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Kc3v14570; Thu, 3 Oct 2002 16:38:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KZnv13925 for ; Thu, 3 Oct 2002 16:35:49 -0400 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03958 for ; Thu, 3 Oct 2002 16:33:42 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g93KZeEe043060; Thu, 3 Oct 2002 20:35:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021003131730.029479c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Oct 2002 13:35:35 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] VLV: a particular target entry Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 01:13 PM 2002-10-03, Jim Sermersheim wrote: >The original purpose of the cookie was to provide a way for a server to >associate a list with a client/connection. The problem was that a client >could be maintaining two VLV lists on the same connection, using the >same search criteria. In order for the server to perform certain >operations (like consistent page up/down) it was neccessary to add the >cookie so that the client's views could be known to the server. Then the document should be clarified that the cookie is used to maintain state between related operations and that in the absence of a cookie, the server is to assume the operation is for an unrelated list. Note, even if the server only supported one list at a time, the request needs to state whether it is related to previous VLV operations or is unrelated. >Novell is the one that requested it, and it wasn't to solve any performance >issues. Okay, but this isn't what the I-D says nor what the author has said on this list in <003b01c265a6$eadb43d0$220aa8c0@mtbrook.boreham.org>. Cookies are optional because they're a performance optimization required only by a subset of implementations. >The reason it was added as an optional component was to not cause >backward compatability problems with implementations that existed before >its introduction. If a server doesn't return a cookie, what is the client to make of this? Is it to assume that the server only supports one VLV list? Is it to assume that each subsequent requests will be treated as related? or treated as unrelated? >This should all be captured in the archives. It needs to be captured in the I-D. Kurt >Jim > >>>> "Kurt D. Zeilenga" 10/03/02 01:05PM >>> >At 11:49 AM 2002-10-03, Jim Sermersheim wrote: >>Help me understand the stability problem further. If the cookie >>mechanism is used, a server knows the last view that the client has. >If >>a client asks for a new view (by offset) that overlaps or adjoins the >>last view, the server should be able to provide contiguous >results--even >>when updates are happening. > >First, note that the present cookie is optionally provided by >the server and optionally returned by the server. It's purpose >has been described to allow the server to make optimize processing >of related requests. It, however, hasn't been described as a >mechanism which the protocol relies on to address content >instability. > >If servers were REQUIRED to provide a cookie and clients >were REQUIRED used the cookie in subsequent related requests, then >the cookie could be used to address the stability problem. > >I would refer to this as a "state-full" approach. > >However, the authors have stated that VLV could be implemented >in a "state-less" fashion. No cookies. > >Either VLV is > stateful - some state is needed. > stateless - no state is needed. > >Which is it? > >>Jim >> >>>>> "Kurt D. Zeilenga" 10/01/02 09:09AM >>> >>At 07:21 AM 2002-10-01, David Boreham wrote: >>>> Do you not see that VLV is broken without selection by DN. >>>> That is, the VLV scroll up/down mechanism fails in the >>>> general case, e.g. when content is unstable. >>> >>>Highly unstable content isn't within the scope of this >>>protocol. >> >>Note that I did not say "highly unstable". I said "unstable". >>That is, one entry add/modification/delete is sufficient >>to cause this protocol to fail. >> >>>Directories typically don't have highly unstable content. >> >>But directories typically do change. And any change is >>sufficient to cause failure in this protocol. >> >>>Kurt: do you have a counterexample ? e.g. something >>>you tried to implement with the current protocol but failed >>>to get to work ? Tell us about it. >> >>Based upon my operational experience with implementing similar >>controls, it is obvious to me that the current protocol fails >>where contain is not stable. In particular, were DIT >>modification causes the positioning of entries in the list to >>shift. >> >>Kurt >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 16:38:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04150 for ; Thu, 3 Oct 2002 16:38:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Kd3v14660; Thu, 3 Oct 2002 16:39:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Kcnv14631 for ; Thu, 3 Oct 2002 16:38:49 -0400 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04065 for ; Thu, 3 Oct 2002 16:36:42 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g93KceEe043070; Thu, 3 Oct 2002 20:38:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021003133555.04665eb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Oct 2002 13:38:36 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] VLV: a particular target entry Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 01:16 PM 2002-10-03, Jim Sermersheim wrote: >I suggest we add more information on the intent of the contextID >(cookie) and state that servers choosing to not use it may run into >instability problems. It's the client what will run into stability problems if its not provided with a cookie and it doesn't provide the cookie in the next related request. >Jim > >>>> "Kurt D. Zeilenga" 10/03/02 01:05PM >>> >At 11:49 AM 2002-10-03, Jim Sermersheim wrote: >>Help me understand the stability problem further. If the cookie >>mechanism is used, a server knows the last view that the client has. >If >>a client asks for a new view (by offset) that overlaps or adjoins the >>last view, the server should be able to provide contiguous >results--even >>when updates are happening. > >First, note that the present cookie is optionally provided by >the server and optionally returned by the server. It's purpose >has been described to allow the server to make optimize processing >of related requests. It, however, hasn't been described as a >mechanism which the protocol relies on to address content >instability. > >If servers were REQUIRED to provide a cookie and clients >were REQUIRED used the cookie in subsequent related requests, then >the cookie could be used to address the stability problem. > >I would refer to this as a "state-full" approach. > >However, the authors have stated that VLV could be implemented >in a "state-less" fashion. No cookies. > >Either VLV is > stateful - some state is needed. > stateless - no state is needed. > >Which is it? > >>Jim >> >>>>> "Kurt D. Zeilenga" 10/01/02 09:09AM >>> >>At 07:21 AM 2002-10-01, David Boreham wrote: >>>> Do you not see that VLV is broken without selection by DN. >>>> That is, the VLV scroll up/down mechanism fails in the >>>> general case, e.g. when content is unstable. >>> >>>Highly unstable content isn't within the scope of this >>>protocol. >> >>Note that I did not say "highly unstable". I said "unstable". >>That is, one entry add/modification/delete is sufficient >>to cause this protocol to fail. >> >>>Directories typically don't have highly unstable content. >> >>But directories typically do change. And any change is >>sufficient to cause failure in this protocol. >> >>>Kurt: do you have a counterexample ? e.g. something >>>you tried to implement with the current protocol but failed >>>to get to work ? Tell us about it. >> >>Based upon my operational experience with implementing similar >>controls, it is obvious to me that the current protocol fails >>where contain is not stable. In particular, were DIT >>modification causes the positioning of entries in the list to >>shift. >> >>Kurt >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 16:41:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04234 for ; Thu, 3 Oct 2002 16:41:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Kg3v14836; Thu, 3 Oct 2002 16:42:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KfAv14784 for ; Thu, 3 Oct 2002 16:41:10 -0400 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04194 for ; Thu, 3 Oct 2002 16:39:04 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Oct 2002 15:40:55 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Thu, 03 Oct 2002 14:40:53 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] VLV: a particular target entry Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yes, the cookie/cursor association is how we maintain state, and can therefore perform page up/down sucessfully. Jim >>> "David Boreham" 10/03/02 02:37PM >>> > nope, it was to do with multiple concurrent duplicate VLVs from a single > client on the same connection. I tried poking around the archives so I > could quote myself, but there are a bunch of zero-byte archives that I > fear hold the messages. I have a pretty clear memory of the discussion. My memory says that it was related to the Novell server implementing only approximate indexing into the lists. Without the cookie, the database engine would need to create a new cursor (or whatever equivalent thing it uses) for every request. With the cookie it keeps cursors live for each client context. The Netscape/Sun servers are able to serve multiple concurrent clients without the cookie (because they maintain an exact index into the list---all state to serve the request unambiguously is carried in the request without needing the context carried over from operation to operation). Perhaps I've been smoking something in the meantime... _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 16:50:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04557 for ; Thu, 3 Oct 2002 16:50:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Ko5v15211; Thu, 3 Oct 2002 16:50:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Kmuv15126 for ; Thu, 3 Oct 2002 16:48:56 -0400 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04434 for ; Thu, 3 Oct 2002 16:46:50 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Oct 2002 15:48:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Thu, 03 Oct 2002 14:47:54 -0600 From: "Jim Sermersheim" To: Cc: , Subject: Re: [ldapext] VLV: a particular target entry Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >>>> "Kurt D. Zeilenga" 10/03/02 02:35PM >>> >At 01:13 PM 2002-10-03, Jim Sermersheim wrote: >>The original purpose of the cookie was to provide a way for a server to >>associate a list with a client/connection. The problem was that a client >>could be maintaining two VLV lists on the same connection, using the >>same search criteria. In order for the server to perform certain >>operations (like consistent page up/down) it was neccessary to add the >>cookie so that the client's views could be known to the server. > >Then the document should be clarified that the cookie is >used to maintain state between related operations and that >in the absence of a cookie, the server is to assume the >operation is for an unrelated list. I agree (unless the server implementation is to work against a more static list). >Note, even if the server only supported one list at a time, the >request needs to state whether it is related to previous VLV >operations or is unrelated. yes >>Novell is the one that requested it, and it wasn't to solve any performance >>issues. > >Okay, but this isn't what the I-D says nor what the author has said >on this list in <003b01c265a6$eadb43d0$220aa8c0@mtbrook.boreham.org>. > > Cookies are optional because they're a performance optimization > required only by a subset of implementations. It was added a long time ago. We should have added the intent into the doc (we probably left it out in order to leave its use unlimited). >>The reason it was added as an optional component was to not cause >>backward compatability problems with implementations that existed before >>its introduction. > >If a server doesn't return a cookie, what is the client to >make of this? Is it to assume that the server only supports >one VLV list? Is it to assume that each subsequent requests >will be treated as related? or treated as unrelated? Since some implementations use more static (pre-canned) result sets, the client can't really assume anything. Even if we required the cookie, we can't cause all implementations to use it to ensure continuity or quality. I think it's sufficient to have the mechanism available, state its intended use, and allow clients to assume that all servers will return contiguous results, regardless of how they achieve that. >>This should all be captured in the archives. > >It needs to be captured in the I-D. I agree. This is an easy fix. Jim >Kurt >Jim > >>>> "Kurt D. Zeilenga" 10/03/02 01:05PM >>> >At 11:49 AM 2002-10-03, Jim Sermersheim wrote: >>Help me understand the stability problem further. If the cookie >>mechanism is used, a server knows the last view that the client has. >If >>a client asks for a new view (by offset) that overlaps or adjoins the >>last view, the server should be able to provide contiguous >results--even >>when updates are happening. > >First, note that the present cookie is optionally provided by >the server and optionally returned by the server. It's purpose >has been described to allow the server to make optimize processing >of related requests. It, however, hasn't been described as a >mechanism which the protocol relies on to address content >instability. > >If servers were REQUIRED to provide a cookie and clients >were REQUIRED used the cookie in subsequent related requests, then >the cookie could be used to address the stability problem. > >I would refer to this as a "state-full" approach. > >However, the authors have stated that VLV could be implemented >in a "state-less" fashion. No cookies. > >Either VLV is > stateful - some state is needed. > stateless - no state is needed. > >Which is it? > >>Jim >> >>>>> "Kurt D. Zeilenga" 10/01/02 09:09AM >>> >>At 07:21 AM 2002-10-01, David Boreham wrote: >>>> Do you not see that VLV is broken without selection by DN. >>>> That is, the VLV scroll up/down mechanism fails in the >>>> general case, e.g. when content is unstable. >>> >>>Highly unstable content isn't within the scope of this >>>protocol. >> >>Note that I did not say "highly unstable". I said "unstable". >>That is, one entry add/modification/delete is sufficient >>to cause this protocol to fail. >> >>>Directories typically don't have highly unstable content. >> >>But directories typically do change. And any change is >>sufficient to cause failure in this protocol. >> >>>Kurt: do you have a counterexample ? e.g. something >>>you tried to implement with the current protocol but failed >>>to get to work ? Tell us about it. >> >>Based upon my operational experience with implementing similar >>controls, it is obvious to me that the current protocol fails >>where contain is not stable. In particular, were DIT >>modification causes the positioning of entries in the list to >>shift. >> >>Kurt >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 16:57:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04838 for ; Thu, 3 Oct 2002 16:57:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Kv4v15435; Thu, 3 Oct 2002 16:57:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93KuZv15418 for ; Thu, 3 Oct 2002 16:56:35 -0400 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04715 for ; Thu, 3 Oct 2002 16:54:28 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Oct 2002 15:56:19 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Thu, 03 Oct 2002 14:56:15 -0600 From: "Jim Sermersheim" To: Cc: , Subject: Re: [ldapext] VLV: a particular target entry Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The client may or may not run into a stability problem, depending on the server implementation. I believe iPlanet implements VLVs by using a pre-canned result set (at least that's one implementation). With that model, it can better ensure consistency without using state information. I don't know how they handle changes to the canned result set, or changes to the users access control. Jim >>> "Kurt D. Zeilenga" 10/03/02 02:38PM >>> At 01:16 PM 2002-10-03, Jim Sermersheim wrote: >I suggest we add more information on the intent of the contextID >(cookie) and state that servers choosing to not use it may run into >instability problems. It's the client what will run into stability problems if its not provided with a cookie and it doesn't provide the cookie in the next related request. >Jim > >>>> "Kurt D. Zeilenga" 10/03/02 01:05PM >>> >At 11:49 AM 2002-10-03, Jim Sermersheim wrote: >>Help me understand the stability problem further. If the cookie >>mechanism is used, a server knows the last view that the client has. >If >>a client asks for a new view (by offset) that overlaps or adjoins the >>last view, the server should be able to provide contiguous >results--even >>when updates are happening. > >First, note that the present cookie is optionally provided by >the server and optionally returned by the server. It's purpose >has been described to allow the server to make optimize processing >of related requests. It, however, hasn't been described as a >mechanism which the protocol relies on to address content >instability. > >If servers were REQUIRED to provide a cookie and clients >were REQUIRED used the cookie in subsequent related requests, then >the cookie could be used to address the stability problem. > >I would refer to this as a "state-full" approach. > >However, the authors have stated that VLV could be implemented >in a "state-less" fashion. No cookies. > >Either VLV is > stateful - some state is needed. > stateless - no state is needed. > >Which is it? > >>Jim >> >>>>> "Kurt D. Zeilenga" 10/01/02 09:09AM >>> >>At 07:21 AM 2002-10-01, David Boreham wrote: >>>> Do you not see that VLV is broken without selection by DN. >>>> That is, the VLV scroll up/down mechanism fails in the >>>> general case, e.g. when content is unstable. >>> >>>Highly unstable content isn't within the scope of this >>>protocol. >> >>Note that I did not say "highly unstable". I said "unstable". >>That is, one entry add/modification/delete is sufficient >>to cause this protocol to fail. >> >>>Directories typically don't have highly unstable content. >> >>But directories typically do change. And any change is >>sufficient to cause failure in this protocol. >> >>>Kurt: do you have a counterexample ? e.g. something >>>you tried to implement with the current protocol but failed >>>to get to work ? Tell us about it. >> >>Based upon my operational experience with implementing similar >>controls, it is obvious to me that the current protocol fails >>where contain is not stable. In particular, were DIT >>modification causes the positioning of entries in the list to >>shift. >> >>Kurt >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 17:03:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05097 for ; Thu, 3 Oct 2002 17:03:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93L45v16140; Thu, 3 Oct 2002 17:04:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93L3gv16125 for ; Thu, 3 Oct 2002 17:03:42 -0400 Received: from blackbear.mtbrook.boreham.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05045 for ; Thu, 3 Oct 2002 17:01:35 -0400 (EDT) Received: from squirrel ([192.168.10.22]) by blackbear.mtbrook.boreham.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Oct 2002 14:04:13 -0700 Message-ID: <062a01c26b20$6d509bc0$160aa8c0@mtbrook.boreham.org> From: "David Boreham" To: References: Subject: Re: [ldapext] VLV: a particular target entry Date: Thu, 3 Oct 2002 14:04:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 03 Oct 2002 21:04:13.0630 (UTC) FILETIME=[6D4725E0:01C26B20] Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > The client may or may not run into a stability problem, depending on the > server implementation. I believe iPlanet implements VLVs by using a > pre-canned result set (at least that's one implementation). With that It doesn't do this. It maintains an always-correct list of the results for any VLV searches specified in advance (indexed). Otherwise it computes the result set by brute force for each operation, or punts saying the request is too hard to resolve. > I don't know how they handle changes to the canned result set, or > changes to the users access control. It is possible for the client to miss entries or jump into some unfamiliar part of the list, if the list is highly dynamic concurrent with the client paging. I'm not convinced that it is possible (or even desirable) to try to invent a browsing mechanism which handles highly dynamic content, even with a context cookie. Does anyone have an application which needs this ? I've seen countless VLV applications developed and deployed and have never had this come up as a problem. We're talking address book lists here folks. If you want to do a scroll view onto a dynamic SQL result set, cool, but is this the place to be defining the protocol for that application ? _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 17:13:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05362 for ; Thu, 3 Oct 2002 17:13:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93LEIv17074; Thu, 3 Oct 2002 17:14:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93LAKv16883 for ; Thu, 3 Oct 2002 17:10:20 -0400 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05263 for ; Thu, 3 Oct 2002 17:08:14 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g93LACEe043207; Thu, 3 Oct 2002 21:10:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021003140519.0466ba38@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Oct 2002 14:10:07 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] VLV: a particular target entry Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 01:56 PM 2002-10-03, Jim Sermersheim wrote: >The client may or may not run into a stability problem, depending on the >server implementation. I believe iPlanet implements VLVs by using a >pre-canned result set (at least that's one implementation). With that >model, it can better ensure consistency without using state >information. >I don't know how they handle changes to the canned result set, or >changes to the users access control. I don't see how they could possibly pre-can dynamic content. I see how they might pre-can static content. If no cookie is not returned, should the client assume the content is static? Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 17:30:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05862 for ; Thu, 3 Oct 2002 17:30:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93LVXv17663; Thu, 3 Oct 2002 17:31:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93LOsv17454 for ; Thu, 3 Oct 2002 17:24:54 -0400 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05585 for ; Thu, 3 Oct 2002 17:22:47 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Oct 2002 16:24:38 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Thu, 03 Oct 2002 15:23:14 -0600 From: "Jim Sermersheim" To: Cc: , Subject: Re: [ldapext] VLV: a particular target entry Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Given what David just said in his latest reply, if I were a client, I would tend to assume that if the contextID is missing, the list _may_ become incosistent. But that neither insures that the list will become inconsistent, nor that lists produced by servers returning a contextID will remain consistent (in otherwords, implementations can be as clever or sloppy as they want to be). I think it's appropriate for the statement that discusses the intent of the contextID to warn that servers not returning a contextID may produce inconsistent results when paging. Is this what you're driving at? Jim. >>> "Kurt D. Zeilenga" 10/03/02 03:10PM >>> At 01:56 PM 2002-10-03, Jim Sermersheim wrote: >The client may or may not run into a stability problem, depending on the >server implementation. I believe iPlanet implements VLVs by using a >pre-canned result set (at least that's one implementation). With that >model, it can better ensure consistency without using state >information. >I don't know how they handle changes to the canned result set, or >changes to the users access control. I don't see how they could possibly pre-can dynamic content. I see how they might pre-can static content. If no cookie is not returned, should the client assume the content is static? Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 17:54:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06308 for ; Thu, 3 Oct 2002 17:54:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Ls5v19075; Thu, 3 Oct 2002 17:54:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Lrcv19035 for ; Thu, 3 Oct 2002 17:53:38 -0400 Received: from blackbear.mtbrook.boreham.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06257 for ; Thu, 3 Oct 2002 17:51:31 -0400 (EDT) Received: from squirrel ([192.168.10.22]) by blackbear.mtbrook.boreham.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Oct 2002 14:54:08 -0700 Message-ID: <000701c26b27$667ed580$160aa8c0@mtbrook.boreham.org> From: "David Boreham" To: References: Subject: Re: [ldapext] VLV: a particular target entry Date: Thu, 3 Oct 2002 14:54:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 03 Oct 2002 21:54:08.0666 (UTC) FILETIME=[66755FA0:01C26B27] Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Discussion point: what if the complete list were to change between two VLV requests from a client ? How does a cookie help us to render something unconfusing to the client ? If, as I hope, it's clear that this is a hopeless exercise, then let's think about a continuum of progressively less and less major change to the list between consecutive requests... Where on this continuum would we decide that there was sufficiently little change to make it possible to use cookies or whatever other protocol devices to ensure that the user isn't 'confused' by the list change ? _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 18:12:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06819 for ; Thu, 3 Oct 2002 18:12:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93MCBv20301; Thu, 3 Oct 2002 18:12:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93MBAv20272 for ; Thu, 3 Oct 2002 18:11:10 -0400 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06778 for ; Thu, 3 Oct 2002 18:09:03 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Oct 2002 17:10:54 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Thu, 03 Oct 2002 16:10:16 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] VLV: a particular target entry Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit If every entry in the client's current view has vanished, you would just attempt a re-position based on their current requested offset. They would end up in a place that may or may not be confusing. In my mind, for this particular issue, there doesn't need to be any change to the VLV protocol. Only clarifications and further notes to implementers. Jim >>> "David Boreham" 10/03/02 03:54PM >>> Discussion point: what if the complete list were to change between two VLV requests from a client ? How does a cookie help us to render something unconfusing to the client ? If, as I hope, it's clear that this is a hopeless exercise, then let's think about a continuum of progressively less and less major change to the list between consecutive requests... Where on this continuum would we decide that there was sufficiently little change to make it possible to use cookies or whatever other protocol devices to ensure that the user isn't 'confused' by the list change ? _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 18:15:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06855 for ; Thu, 3 Oct 2002 18:15:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93MG6v20422; Thu, 3 Oct 2002 18:16:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93MFUv20395 for ; Thu, 3 Oct 2002 18:15:30 -0400 Received: from blackbear.mtbrook.boreham.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06836 for ; Thu, 3 Oct 2002 18:13:22 -0400 (EDT) Received: from squirrel ([192.168.10.22]) by blackbear.mtbrook.boreham.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Oct 2002 15:16:00 -0700 Message-ID: <004301c26b2a$74563380$160aa8c0@mtbrook.boreham.org> From: "David Boreham" To: References: Subject: Re: [ldapext] VLV: a particular target entry Date: Thu, 3 Oct 2002 15:16:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 03 Oct 2002 22:16:00.0373 (UTC) FILETIME=[744BFA50:01C26B2A] Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > If every entry in the client's current view has vanished, you would just > attempt a re-position based on their current requested offset. They > would end up in a place that may or may not be confusing. Indeed. > In my mind, for this particular issue, there doesn't need to be any > change to the VLV protocol. Only clarifications and further notes to > implementers. My point was that there is no general solution to the dynamic list content problem, only various suggestions to make it not so bad, in the abstract, with no cited application where the problem has proven to arise in the first place. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 18:51:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07671 for ; Thu, 3 Oct 2002 18:51:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93MqKv22048; Thu, 3 Oct 2002 18:52:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93MpUv22015 for ; Thu, 3 Oct 2002 18:51:30 -0400 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07624 for ; Thu, 3 Oct 2002 18:49:21 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g93MpKEe043504; Thu, 3 Oct 2002 22:51:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021003152350.046a7e28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Oct 2002 15:51:16 -0700 To: "David Boreham" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] VLV: a particular target entry Cc: In-Reply-To: <004301c26b2a$74563380$160aa8c0@mtbrook.boreham.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 03:16 PM 2002-10-03, David Boreham wrote: >> If every entry in the client's current view has vanished, you would just >> attempt a re-position based on their current requested offset. They >> would end up in a place that may or may not be confusing. > >Indeed. Or return an error. >> In my mind, for this particular issue, there doesn't need to be any >> change to the VLV protocol. Only clarifications and further notes to >> implementers. > >My point was that there is no general solution to the >dynamic list content problem, I believe there are at least two general solutions to this problem. 1) a cookie (stateful) approach which can be used to position the view based upon previous list state and returned results, 2) a stateless approach which positions the view relative to a particular object in the list. Both solutions, where continuity cannot be provided, can detect the lack of continuity. >only various suggestions to make it not so bad, I disagree. Both of the above approaches not only handle minor list changes but deal with some major list changes... and, where they cannot deal with changes, they can detect that they cannot and return an error. This is significantly better ignoring the problem. >in the abstract, with no cited >application where the problem has proven to arise in the >first place. (Based upon your description of the Sun/Netscape server) Take your address book client, select a view against the Sun/Netscape server, add one entry from the list before the target, then page down. The provided view will skip over one entry. That's a problem, it's real. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 18:57:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07824 for ; Thu, 3 Oct 2002 18:57:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93Mw3v22187; Thu, 3 Oct 2002 18:58:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93MvJv22168 for ; Thu, 3 Oct 2002 18:57:19 -0400 Received: from blackbear.mtbrook.boreham.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07755 for ; Thu, 3 Oct 2002 18:55:11 -0400 (EDT) Received: from squirrel ([192.168.10.22]) by blackbear.mtbrook.boreham.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Oct 2002 15:57:49 -0700 Message-ID: <006301c26b30$4bdb9840$160aa8c0@mtbrook.boreham.org> From: "David Boreham" To: References: <5.1.0.14.0.20021003152350.046a7e28@127.0.0.1> Subject: Re: [ldapext] VLV: a particular target entry Date: Thu, 3 Oct 2002 15:57:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 03 Oct 2002 22:57:49.0430 (UTC) FILETIME=[4BCFB160:01C26B30] Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > (Based upon your description of the Sun/Netscape server) > Take your address book client, select a view against the > Sun/Netscape server, add one entry from the list before > the target, then page down. The provided view will skip > over one entry. That's a problem, it's real. In my limited world, this is _not_ a practical problem. So...an entry which was just added to the directory happens to not show up when a user pages down, where it will if they subsequently page up again, or re-position. The entry wasn't there a few seconds ago anyway, so where's the problem here ? I will repeat: many years of practical deployment experience has shown me that this is not a real problem. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 19:08:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08017 for ; Thu, 3 Oct 2002 19:08:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93N96v23052; Thu, 3 Oct 2002 19:09:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93N8jv23032 for ; Thu, 3 Oct 2002 19:08:45 -0400 Received: from junker.stroeder.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07976 for ; Thu, 3 Oct 2002 19:06:31 -0400 (EDT) Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id C2A3815718E for ; Fri, 4 Oct 2002 01:07:39 +0200 (CEST) Message-ID: <3D9CCDBB.1000805@stroeder.com> Date: Fri, 04 Oct 2002 01:07:39 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= Reply-To: michael@stroeder.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ldapext@ietf.org Subject: Re: [ldapext] VLV: a particular target entry References: <5.1.0.14.0.20021003152350.046a7e28@127.0.0.1> <006301c26b30$4bdb9840$160aa8c0@mtbrook.boreham.org> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David Boreham wrote: >>(Based upon your description of the Sun/Netscape server) >>Take your address book client, select a view against the >>Sun/Netscape server, add one entry from the list before >>the target, then page down. The provided view will skip >>over one entry. That's a problem, it's real. > > In my limited world, this is _not_ a practical problem. > > So...an entry which was just added to the directory > happens to not show up when a user pages down, where > it will if they subsequently page up again, or re-position. > The entry wasn't there a few seconds ago anyway, so > where's the problem here ? > > I will repeat: many years of practical deployment experience > has shown me that this is not a real problem. I can imagine that this is a serious problem in an administration application where the application user (e.g. a directory manager) expects to see the entries he added a few seconds ago in another window continously showing the list view. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 19:29:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08345 for ; Thu, 3 Oct 2002 19:29:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93NU9v23638; Thu, 3 Oct 2002 19:30:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93NTIv23573 for ; Thu, 3 Oct 2002 19:29:18 -0400 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08322 for ; Thu, 3 Oct 2002 19:27:09 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 03 Oct 2002 18:29:01 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Thu, 03 Oct 2002 17:28:47 -0600 From: "Jim Sermersheim" To: , Cc: Subject: Re: [ldapext] VLV: a particular target entry Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kurt, If I understand correctly, your view is that the control ought to guarantee continuity when a cookie is being exchanged. If continuity is lost, the server returns an error, and the client can re-request with a null cookie. Is that accurate? If so, I think this could be done with relatively few changes to the draft. I'm not sure how many of the current implementations will adopt the behavior. Given that most of them don't use the cookie today, I guess they'd still be acting in accordance with the draft. Jim >>> "Kurt D. Zeilenga" 10/03/02 04:51PM >>> At 03:16 PM 2002-10-03, David Boreham wrote: >> If every entry in the client's current view has vanished, you would just >> attempt a re-position based on their current requested offset. They >> would end up in a place that may or may not be confusing. > >Indeed. Or return an error. >> In my mind, for this particular issue, there doesn't need to be any >> change to the VLV protocol. Only clarifications and further notes to >> implementers. > >My point was that there is no general solution to the >dynamic list content problem, I believe there are at least two general solutions to this problem. 1) a cookie (stateful) approach which can be used to position the view based upon previous list state and returned results, 2) a stateless approach which positions the view relative to a particular object in the list. Both solutions, where continuity cannot be provided, can detect the lack of continuity. >only various suggestions to make it not so bad, I disagree. Both of the above approaches not only handle minor list changes but deal with some major list changes... and, where they cannot deal with changes, they can detect that they cannot and return an error. This is significantly better ignoring the problem. >in the abstract, with no cited >application where the problem has proven to arise in the >first place. (Based upon your description of the Sun/Netscape server) Take your address book client, select a view against the Sun/Netscape server, add one entry from the list before the target, then page down. The provided view will skip over one entry. That's a problem, it's real. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 19:35:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08438 for ; Thu, 3 Oct 2002 19:35:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93NZ4v23787; Thu, 3 Oct 2002 19:35:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93NYpv23761 for ; Thu, 3 Oct 2002 19:34:51 -0400 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08425 for ; Thu, 3 Oct 2002 19:32:42 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g93NYgEe043608; Thu, 3 Oct 2002 23:34:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021003160427.0465a158@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Oct 2002 16:34:37 -0700 To: "David Boreham" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] VLV: a particular target entry Cc: In-Reply-To: <006301c26b30$4bdb9840$160aa8c0@mtbrook.boreham.org> References: <5.1.0.14.0.20021003152350.046a7e28@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 03:57 PM 2002-10-03, David Boreham wrote: >> (Based upon your description of the Sun/Netscape server) >> Take your address book client, select a view against the >> Sun/Netscape server, add one entry from the list before >> the target, then page down. The provided view will skip >> over one entry. That's a problem, it's real. > >In my limited world, this is _not_ a practical problem. Maybe so. But we need to design standard track protocols such that they work well on the Internet for a wide range of applications. Maybe for your users and their applications, this is not a problem. However, I can see that for other applications this would be a major problem. Now, its don't necessary don't have to expand the applicability of a protocol, but authors do need to make sure that the known limitations your protocol are clearly stated. >So...an entry which was just added to the directory >happens to not show up when a user pages down, It actually far more likely to skip over existing entries. >where it will if they subsequently page up again, or re-position. When they subsequently page up, maybe one entry before the target is deleted, so the entry is skipped again. >The entry wasn't there a few seconds ago anyway, so >where's the problem here ? I scroll down, the entry I'm looking for isn't in the view. I scroll up, the entry I'm looking for isn't in the view. I naturally assume the entry isn't in list when in fact the entry has been in and continues to be in the list. Problem? well, that depends on what action I take (or don't take) based upon the entry not appearing on the list. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 19:58:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08766 for ; Thu, 3 Oct 2002 19:58:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93NwKv24904; Thu, 3 Oct 2002 19:58:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93NvHv24866 for ; Thu, 3 Oct 2002 19:57:17 -0400 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08730 for ; Thu, 3 Oct 2002 19:55:07 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g93Nv6Ee043689; Thu, 3 Oct 2002 23:57:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021003163513.0465eac8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Oct 2002 16:57:01 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] VLV: a particular target entry Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 04:28 PM 2002-10-03, Jim Sermersheim wrote: >If I understand correctly, your view is that the control ought to >guarantee continuity when a cookie is being exchanged. If continuity is >lost, the server returns an error, and the client can re-request with a >null cookie. >Is that accurate? Yes. >If so, I think this could be done with relatively few >changes to the draft. Basically, I think the I-D needs to: a) state what "continuity" means, b) state that intent of the cookie is to provide state to ensure continuity, c) state continuity requirements, d) state when a VLV operation with no cookie may be processed independently of other VLV operations and, hence, no continuity is ensured. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Oct 3 20:00:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08811 for ; Thu, 3 Oct 2002 20:00:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94013v25029; Thu, 3 Oct 2002 20:01:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9400Zv24979 for ; Thu, 3 Oct 2002 20:00:35 -0400 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08780 for ; Thu, 3 Oct 2002 19:58:26 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g9400REe043722 for ; Fri, 4 Oct 2002 00:00:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021003165710.046611f0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Oct 2002 17:00:22 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: [ldapext] VLV: a particular target entry In-Reply-To: <5.1.0.14.0.20021003160427.0465a158@127.0.0.1> References: <006301c26b30$4bdb9840$160aa8c0@mtbrook.boreham.org> <5.1.0.14.0.20021003152350.046a7e28@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 04:34 PM 2002-10-03, Kurt D. Zeilenga wrote: >Now, its don't necessary don't have to expand the >applicability of a protocol, but authors do need to make >sure that the known limitations your protocol are clearly >stated. Sorry, this should read: Now, it's not necessary to expand the applicability of a protocol, but the authors do need to make sure that the known limitations of the protocol are clearly stated. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Oct 8 16:44:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00223 for ; Tue, 8 Oct 2002 16:44:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98Kimv29771; Tue, 8 Oct 2002 16:44:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98KcDv29523 for ; Tue, 8 Oct 2002 16:38:13 -0400 Received: from prv-mail25.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29921 for ; Tue, 8 Oct 2002 16:36:02 -0400 (EDT) Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Tue, 08 Oct 2002 14:38:06 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 08 Oct 2002 14:37:51 -0600 From: "Bruce Bergeson" To: Cc: "Kent Boogert" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_8AD6193E.B0D1B772" Subject: [ldapext] LDAP Schema for UDDI Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_8AD6193E.B0D1B772 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit All, We have updated the draft http://www.ietf.org/internet-drafts/draft-bergeson-uddi-ldap-schema-01.txt based on a round of initial reviews and we want to progress it to RFC status. Before requesting the Area Director to initiate a last call, we wanted to see if anyone has any further feedback. We'll approach the AD in a week if there seems to be no issues. Bruce and Kent. --=_8AD6193E.B0D1B772 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
All,
 
We have updated the draft http://www.ietf.org/internet-drafts/draft-bergeson-uddi-ldap-schema-01.txt based on a round of initial reviews and we want to progress it to RFC status. Before requesting the Area Director to initiate a last call, we wanted to see if anyone has any further feedback.
 
We'll approach the AD in a week if there seems to be no issues.
 
Bruce and Kent.
--=_8AD6193E.B0D1B772-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Oct 8 17:21:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01279 for ; Tue, 8 Oct 2002 17:21:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98LM7v32069; Tue, 8 Oct 2002 17:22:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98KvEv30148 for ; Tue, 8 Oct 2002 16:57:14 -0400 Received: from mxout4.cac.washington.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00428 for ; Tue, 8 Oct 2002 16:55:03 -0400 (EDT) Received: from mailscan-out1.cac.washington.edu (mailscan-out1.cac.washington.edu [140.142.32.17]) by mxout4.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.09) with SMTP id g98Kv18t001843 for ; Tue, 8 Oct 2002 13:57:03 -0700 Received: FROM smtp.washington.edu BY mailscan-out1.cac.washington.edu ; Tue Oct 08 13:55:19 2002 -0700 Received: from D-140-142-21-76.dhcp4.washington.edu (D-140-142-21-76.dhcp4.washington.edu [140.142.21.76]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.08) with ESMTP id g98KtJpK030167 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 8 Oct 2002 13:55:19 -0700 Date: Tue, 8 Oct 2002 13:55:24 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost.localdomain To: Bruce Bergeson cc: IETF ldapext WG , Kent Boogert Subject: Re: [ldapext] LDAP Schema for UDDI In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , On Tue, 8 Oct 2002, Bruce Bergeson wrote: > We have updated the draft > http://www.ietf.org/internet-drafts/draft-bergeson-uddi-ldap-schema-01.txt > based on a round of initial reviews and we want to progress it to RFC > status. Before requesting the Area Director to initiate a last call, we > wanted to see if anyone has any further feedback. Can you say what relation this work has to the UDDI standardization work going on in the OASIS uddi-spec committee? (http://www.oasis-open.org/committees/uddi-spec/) The appropriate RFC reference to LDAPv3 as a whole is now RFC 3377. - RL "Bob" _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Oct 11 15:18:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02852 for ; Fri, 11 Oct 2002 15:18:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJIRv11466; Fri, 11 Oct 2002 15:18:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJEfv11264 for ; Fri, 11 Oct 2002 15:14:41 -0400 Received: from uxtpaprx1.nam.pwcinternal.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02720 for ; Fri, 11 Oct 2002 15:12:27 -0400 (EDT) From: christine.yoon@us.pwcglobal.com Received: from us-amsmta005.nam.pwcinternal.com (us-amsmta005.nam.pwcinternal.com [10.26.104.89]) by uxtpaprx1.nam.pwcinternal.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9BJEXF07670; Fri, 11 Oct 2002 15:14:33 -0400 (EDT) To: Cc: X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 11 Oct 2002 15:14:22 -0400 X-MIMETrack: Serialize by Router on US-AMSMTA005/US/INTL(Release 5.0.9 |November 16, 2001) at 10/11/2002 03:14:33 PM, Serialize complete at 10/11/2002 03:14:33 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00699CCF85256C4F_=" Subject: [ldapext] need of dynamic attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00699CCF85256C4F_= Content-Type: text/plain; charset="us-ascii" When a user account in a directory has expirationdate attribute, a today's ldap application needs to write a code to check the user's expirationdate against the system's today's date to validate if the account is valid. If a dynamic attribute such as todaysdate is defined as a part of ldap schema and the value of the attribute is the ldap server system's date, the application may simply configure a ldap filter something like (&(ou=useraccount)(todaysdate()When a user account in a directory has expirationdate attribute,
a today's ldap application needs to write a code to check the user's expirationdate against the system's today's date
to validate if the account is valid.

If a dynamic attribute such as todaysdate is defined as a part of ldap schema and
the value of the attribute is the ldap server system's date, the application may simply configure a ldap filter something like
    (&(ou=useraccount)(todaysdate()<expirationdate)

Dynamic attributes can be quite useful, which requires such attributes and
search filter using dynamic attributes to be defined.

I wonder if work on dynamic attributes is within ldapext scope.

Any thoughts?

Thanks,


Christine Yoon
Security Integration
PricewaterhouseCoopers
(201)981-1172 (cell)
(732)706-3559
_________________________________________________________________
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. --=_alternative 00699CCF85256C4F_=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Oct 11 15:26:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03149 for ; Fri, 11 Oct 2002 15:26:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJR3v11847; Fri, 11 Oct 2002 15:27:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BJQJv11809 for ; Fri, 11 Oct 2002 15:26:19 -0400 Received: from pheriche.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03126 for ; Fri, 11 Oct 2002 15:24:05 -0400 (EDT) Received: from rowlf.Central.Sun.COM ([129.153.131.70]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09934; Fri, 11 Oct 2002 13:26:12 -0600 (MDT) Received: from sun.com (dhcp-uaus09-130-183 [129.153.130.183]) by rowlf.Central.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id g9BJQB418724; Fri, 11 Oct 2002 14:26:11 -0500 (CDT) Message-ID: <3DA72674.A75DF2F6@sun.com> Date: Fri, 11 Oct 2002 14:28:52 -0500 From: Mark Wahl X-Mailer: Mozilla 4.79 [en]C-CCK-MCD NSCPCD477 (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: christine.yoon@us.pwcglobal.com CC: ldapext@ietf.org Subject: Re: [ldapext] need of dynamic attributes References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit christine.yoon@us.pwcglobal.com wrote: > > If a dynamic attribute such as todaysdate is defined as a part of ldap schema > and > the value of the attribute is the ldap server system's date, the application > may simply configure a ldap filter something like > (&(ou=useraccount)(todaysdate()=2002101023412Z) ? This wouldn't need a todays date or other LDAP schema extension. > Dynamic attributes can be quite useful, which requires such attributes and > search filter using dynamic attributes to be defined. There was an earlier draft on dynamic attributes which were attributes that would time out and disappear if not refreshed. This draft document itself timed out and disappeared though you might be able to find it from the informal expired I-D archives. What you describe sounds also like the capability which some LDAP implementations provide, which I call virtual attributes. > I wonder if work on dynamic attributes is within ldapext scope. LDAPEXT the working group has shut down already. You can discuss it on this mailing list but there is no working group 'scope' for dynamic attributes any more. Mark Wahl Sun Microsystems Inc. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Oct 11 16:02:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03794 for ; Fri, 11 Oct 2002 16:02:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BK36v13412; Fri, 11 Oct 2002 16:03:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BK21v13382 for ; Fri, 11 Oct 2002 16:02:01 -0400 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03753 for ; Fri, 11 Oct 2002 15:59:46 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g9BK1pEe090813; Fri, 11 Oct 2002 20:01:51 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021011124401.034cba10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 11 Oct 2002 13:01:40 -0700 To: Mark Wahl From: "Kurt D. Zeilenga" Subject: Re: [ldapext] need of dynamic attributes Cc: christine.yoon@us.pwcglobal.com, ldapext@ietf.org In-Reply-To: <3DA72674.A75DF2F6@sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 12:28 PM 2002-10-11, Mark Wahl wrote: >christine.yoon@us.pwcglobal.com wrote: >> If a dynamic attribute such as todaysdate is defined as a part of ldap schema >> and >> the value of the attribute is the ldap server system's date, the application >> may simply configure a ldap filter something like >> (&(ou=useraccount)(todaysdate() >But if my application is running at 2002101023412Z wouldn't it just send >(&(ou=useraccount)(expirationDate>=2002101023412Z) ? This wouldn't need >a todays date or other LDAP schema extension. I note that even if one had an operational 'todaysdate' attribute in every entry, there is no standard mechanism for compare values of one attribute to another attribute. An extension of some sort would be needed, like an extensible matching rule allowing assertions like: (expirationDate:=valuesGreaterThanOrEqualTo:=todaysdate) (where expirationDate and todaysdate are attribute types). >> Dynamic attributes can be quite useful, which requires such attributes and >> search filter using dynamic attributes to be defined. > >There was an earlier draft on dynamic attributes which were attributes >that would time out and disappear if not refreshed. This draft document >itself timed out and disappeared though you might be able to find it >from the informal expired I-D archives. What you describe sounds also like >the capability which some LDAP implementations provide, which I call virtual >attributes. I note as well that the LDAP provides "collective" attributes (RFC 2252/X.501) which appear to be similar in concept to "virtual" attributes (as provided by some LDAP implementations). As there are big gaps between RFC 2252 and X.501, I authored draft-zeilenga-ldap-collective. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext