From subs-reminder@imc.org Mon Apr 1 19:03:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19666 for ; Mon, 1 Apr 2002 19:03:11 -0500 (EST) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id g3203AV10390; Mon, 1 Apr 2002 16:03:10 -0800 (PST) Date: Mon, 1 Apr 2002 16:03:10 -0800 (PST) Message-Id: <200204020003.g3203AV10390@above.proper.com> To: ldup-archive@ietf.org Subject: [[251081181]] Subscription to ietf-ldup for ldup-archive@lists.ietf.org Greetings. This message is a periodic reminder that ldup-archive@lists.ietf.org is subscribed to the ietf-ldup mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ldup mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-ldup-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "ldup-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From subs-reminder@imc.org Mon Apr 1 19:04:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19716 for ; Mon, 1 Apr 2002 19:04:40 -0500 (EST) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id g3204d910740; Mon, 1 Apr 2002 16:04:39 -0800 (PST) Date: Mon, 1 Apr 2002 16:04:39 -0800 (PST) Message-Id: <200204020004.g3204d910740@above.proper.com> To: ldup-archive@ietf.org Subject: [[315963303]] Subscription to ietf-ldup for ldup-archive@lists.ietf.org Greetings. This message is a periodic reminder that ldup-archive@lists.ietf.org is subscribed to the ietf-ldup mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ldup mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-ldup-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "ldup-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-ldup@mail.imc.org Tue Apr 2 07:27:41 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12922 for ; Tue, 2 Apr 2002 07:27:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g32CIlx15379 for ietf-ldup-bks; Tue, 2 Apr 2002 04:18:47 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g32CIkm15374 for ; Tue, 2 Apr 2002 04:18:46 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12624; Tue, 2 Apr 2002 07:18:45 -0500 (EST) Message-Id: <200204021218.HAA12624@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-replica-req-12.txt Date: Tue, 02 Apr 2002 07:18:45 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAPv3 Replication Requirements Author(s) : E. Stokes, R. Weiser, R. Moats, R. Huber Filename : draft-ietf-ldup-replica-req-12.txt Pages : 30 Date : 01-Apr-02 This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol (version 3) [RFC2251]. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-12.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-ietf-ldup-replica-req-12.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-ietf-ldup-replica-req-12.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: <20020401104318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-replica-req-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-replica-req-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020401104318.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Wed Apr 3 21:48:24 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22821 for ; Wed, 3 Apr 2002 21:48:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g342bXf24430 for ietf-ldup-bks; Wed, 3 Apr 2002 18:37:33 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g342bWm24423 for ; Wed, 3 Apr 2002 18:37:32 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g342bQO01767 for ; Wed, 3 Apr 2002 18:37:26 -0800 (PST) Received: from netscape.com ([205.217.228.238]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GU0VAG00.2MC; Wed, 3 Apr 2002 18:37:28 -0800 Message-ID: <3CABBBBC.7BE7B3AA@netscape.com> Date: Wed, 03 Apr 2002 19:34:36 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpana@metasolv.com CC: ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms012ED7D1EFFAAC8A2D95FB7D" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms012ED7D1EFFAAC8A2D95FB7D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Mircea Pana > > om> cc: > Sent by: Subject: LCUP and PSearch on Sync-And-Persist > owner-ietf-ldup@m > ail.imc.org > > > 03/26/2002 10:25 > AM > Please respond to > mpana > > > > Both LCUP and PSearch are unclear on the order of results sent back to a > client in case of a sync-and-persist search request. An order seems to > be suggested but not formally recommended. > > If a client issues a search requests with the appropriate control and > specifies updateType=synchronizeAndPersist (LCUP) or changesOnly=FALSE > (PSearch), in response the server will start by sending all the data > needed to synchronize the client. If a change occurs to an entry which > satisfy the search criteria while the server is still synchronizing the > client then: > 1. the server will pause the synchronization, sent that changed entry to > the client and then resume the synchronization > -or- > 2 (suggested). the server will queue the changed entry and sent it to > the client after the synchronization is completed > -or- > 3. the server will ignore the change > > Which one of the above is recommended by LCUP / PSearch? I'm speaking only for LCUP, not PSearch. I think the above assumes that entries sent during the synchronize phase are somehow different from the entries sent during the persistent phase. Why should the client care if either 1 or 2 is used? For 1), why would the server have to pause? It could just insert the changed entry either into it's outgoing sync queue, or it could put it on the end of the queue. I don't think it matters as long as the implementor has designed the server such that the server knows exactly where it left off if the connection is cut. The cookie sent back to the client should contain all the information required to resync that client, hopefully with no overlaps. > How is a client informed that the synchronization is complete and the > only results that it may eventually receive are changes? I'm not sure why the client would need to know that in the LCUP case. I would appreciate more information about what type of application you have that would require that information. > > > Regards, > Mircea Pana. --------------ms012ED7D1EFFAAC8A2D95FB7D Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJbwYJKoZIhvcNAQcCoIIJYDCCCVwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B0IwggNkMIICzaADAgECAgJRWzANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMTEyMDExNzE3NTRaFw0wMjA1MzAxNzE3NTRa MH0xCzAJBgNVBAYTAlVTMRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxFTATBgoJkiaJ k/IsZAEBEwVyaWNobTEhMB8GCSqGSIb3DQEJARYScmljaG1AbmV0c2NhcGUuY29tMRcwFQYD VQQDEw5SaWNoIE1lZ2dpbnNvbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAy+QEICyv nXraX0tvcretFdF6qUJS5AMstn6ohTpaw8OxpAkprpj3VcP/N39mavcqZ4H0y3OT7SKZLTlv g6H3mWD6jnhht5G2YFdeO6fmb26QXXDjj6kpqt6iQhTZxg5ZUSHL79oTmbdj7M/xn9wnbDMD vWG6G2NnhCzELzWycxkCAwEAAaOB2zCB2DAOBgNVHQ8BAf8EBAMCBeAwQwYJYIZIAYb4QgEN BDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0 LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+L I7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRp ZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDANBgkqhkiG9w0BAQQFAAOBgQCwNXTrDTui/LLE dafKau8xKlXyFgG5XbqNiHIkU4g88IgtK79pgSEys9uovMmXZLrItHs7jMPzHKr7ad6WDuq3 y2GVs4vmXQamQ5oei83ESFzfipgHNqCpn93a5S3zZPmg2F//Udd1JNcn55H9W1Zbi8p5bfUM u+OSlj6JT+zJiTCCA9YwggM/oAMCAQICBAIAAeYwDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1 c3QgUm9vdDAeFw0wMTA2MDExMjQ3MDBaFw0wNDA2MDEyMzU5MDBaMIGTMQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJp Y2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50 cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDi718sdkOJSxpfs+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SIiGne/YNX4KMRGRGq 1ty877PSFS5Uxm58v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhClvMGk0XhMBuVkQfwF JWMm6+8Mx25UoYzOVFe2H5LashJLjQIDAQABo4IBgjCCAX4wTQYDVR0fBEYwRDBCoECgPoY8 aHR0cDovL3d3dzEudXMtaG9zdGluZy5iYWx0aW1vcmUuY29tL2NnaS1iaW4vQ1JML0dURVJv b3QuY2dpMB0GA1UdDgQWBBQp27Itg35/iyO7wsxmuTnoKfMChjBmBgNVHSAEXzBdMEYGCiqG SIb4YwECAQUwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5iYWx0aW1vcmUuY29tL0NQUy9P bW5pUm9vdC5odG1sMBMGAyoDBDAMMAoGCCsGAQUFBwIBMFgGA1UdIwRRME+hSaRHMEUxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJl clRydXN0IFJvb3SCAgGjMCsGA1UdEAQkMCKADzIwMDEwNjAxMTI0NzMwWoEPMjAwMzA5MDEy MzU5MDBaMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMA0GCSqGSIb3DQEBBQUA A4GBAEpiDtn6RncECmwN3f7SIjmZEAquiC2GPVeE5hIkN2n7WV7iEbD5n6RXhoppHwZj0X3u MzZJECAPH5cXLCdsPWw5BHviReiHG1S2YEFtHa4F8535OjSa43trTHH466grg7A1kEwZaHHt 8GMiXsJb7CB6tbBRc+kH7oFndnlT95XUMYIB9TCCAfECAQEwgZowgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmlj YSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRy YW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAlFbMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwNDA0MDIzNDM2WjAjBgkqhkiG 9w0BCQQxFgQU7Q+gz23AHWYYeacdO5Wlw9DEzsMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYBw6W8RTh5u1pCL1RPbvEhv216U+W5REodyKMtmMpAW Y+JapdDhDkcZYFgJKRiwjvAUbSrQ2d5lyDn4RuBetNcH4XCV5uOyUm+/iqQtGlHYYRMwc1// 7UU3N59AowXZZIIc+KDcWBvrb1lCumLRVPoA/avELaY4tGqk0G2mXckadw== --------------ms012ED7D1EFFAAC8A2D95FB7D-- From owner-ietf-ldup@mail.imc.org Wed Apr 3 22:13:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23186 for ; Wed, 3 Apr 2002 22:13:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3435xi25043 for ietf-ldup-bks; Wed, 3 Apr 2002 19:05:59 -0800 (PST) Received: from e1.esmtp.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3435wm25039 for ; Wed, 3 Apr 2002 19:05:58 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.esmtp.ibm.com (8.12.2/8.12.2) with ESMTP id g3432UXb170696 for ; Wed, 3 Apr 2002 22:02:30 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g3435qZ19308 for ; Wed, 3 Apr 2002 22:05:52 -0500 Subject: Re: LCUP and PSearch on Sync-And-Persist To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Timothy Hahn" Date: Wed, 3 Apr 2002 22:05:00 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.10 |March 28, 2002) at 04/03/2002 10:05:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rich, Two comments below - with ... Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 richm@netscape.co m (Rich To: mpana@metasolv.com Megginson) cc: ietf-ldup@imc.org Sent by: Subject: Re: LCUP and PSearch on Sync-And-Persist owner-ietf-ldup@m ail.imc.org 04/03/2002 09:34 PM > Mircea Pana > > om> cc: > Sent by: Subject: LCUP and PSearch on Sync-And-Persist > owner-ietf-ldup@m > ail.imc.org > > > 03/26/2002 10:25 > AM > Please respond to > mpana > > > > Both LCUP and PSearch are unclear on the order of results sent back to a > client in case of a sync-and-persist search request. An order seems to > be suggested but not formally recommended. > > If a client issues a search requests with the appropriate control and > specifies updateType=synchronizeAndPersist (LCUP) or changesOnly=FALSE > (PSearch), in response the server will start by sending all the data > needed to synchronize the client. If a change occurs to an entry which > satisfy the search criteria while the server is still synchronizing the > client then: > 1. the server will pause the synchronization, sent that changed entry to > the client and then resume the synchronization > -or- > 2 (suggested). the server will queue the changed entry and sent it to > the client after the synchronization is completed > -or- > 3. the server will ignore the change > > Which one of the above is recommended by LCUP / PSearch? I'm speaking only for LCUP, not PSearch. I think the above assumes that entries sent during the synchronize phase are somehow different from the entries sent during the persistent phase. Why should the client care if either 1 or 2 is used? For 1), why would the server have to pause? It could just insert the changed entry either into it's outgoing sync queue, or it could put it on the end of the queue. I don't think it matters as long as the implementor has designed the server such that the server knows exactly where it left off if the connection is cut. The cookie sent back to the client should contain all the information required to resync that client, hopefully with no overlaps. I suspect there exists a "time window" where the client may not have enough information (yet) in order to do anything "meaningful" with the "changed entry", depending on where the server "inserted the changed entry" into the outgoing sync queue, based on what has been sent to the client so far. This implies to me that the server has to be "somewhat intelligent" in when it can finally send "changed entries" to the client. > How is a client informed that the synchronization is complete and the > only results that it may eventually receive are changes? I'm not sure why the client would need to know that in the LCUP case. I would appreciate more information about what type of application you have that would require that information. What about a client that wants to "hold off" on handling search requests until it knows that its information is "close" to what is held in the server? "close" being defined as the "synchronization" part being done and only "updates" will be sent from here forward. > > > Regards, > Mircea Pana. From owner-ietf-ldup@mail.imc.org Thu Apr 4 04:36:50 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07824 for ; Thu, 4 Apr 2002 04:36:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g349G9i24223 for ietf-ldup-bks; Thu, 4 Apr 2002 01:16:09 -0800 (PST) Received: from bt1sqtl3.bouyguestelecom.fr (smtpl3.bouyguestelecom.fr [212.208.45.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g349G4m24200 for ; Thu, 4 Apr 2002 01:16:08 -0800 (PST) Received: from bt1sqt2s.BPA.BOUYGUESTELECOM.FR (unverified) by bt1sqtl3.bouyguestelecom.fr (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 04 Apr 2002 11:16:50 +0200 Received: from bt1sqtbc.bpa.bouyguestelecom.fr (unverified) by bt1sqt2s.BPA.BOUYGUESTELECOM.FR (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 04 Apr 2002 11:15:36 +0200 Received: by bt1sqtbc.bpa.bouyguestelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 11:15:36 +0200 Message-Id: <776BD5C0BA88D4118ABD0008C79F30770232D59A@bt1sqteb.bpa.bouyguestelecom.fr> From: CBRENDEL@bouyguestelecom.fr To: ietf-ldup@imc.org Subject: LDUP project status & maturity ? Date: Thu, 4 Apr 2002 11:15:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I'd like to know what is the status and the maturity of the LDUP project. The "last modified" field of the http://www.ietf.org/html.charters/ldup-charter.html page is "02april 2002", and therefore the goals & milestones date reefer to 2001. Is the project has been stopped ? Or is it just a mistake from the webmaster ? If not, is anyone could you give me the future milestones ? Thanks in advance for your answer. Christophe From owner-ietf-ldup@mail.imc.org Thu Apr 4 10:12:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18066 for ; Thu, 4 Apr 2002 10:12:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34F28A20533 for ietf-ldup-bks; Thu, 4 Apr 2002 07:02:08 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34F27m20528 for ; Thu, 4 Apr 2002 07:02:07 -0800 (PST) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id g34F21O16491 for ; Thu, 4 Apr 2002 07:02:01 -0800 (PST) Received: from netscape.com ([10.169.184.16]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GU1TRE00.OVC; Thu, 4 Apr 2002 07:02:02 -0800 Message-ID: <3CAC6AE9.3090203@netscape.com> Date: Thu, 04 Apr 2002 10:02:01 -0500 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:0.9.9+) Gecko/20020322 Netscape6/6.2.1+ X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timothy Hahn CC: ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Timothy Hahn wrote: > > What about a client that wants to "hold off" on handling search requests > until it knows that its > information is "close" to what is held in the server? "close" being > defined as the "synchronization" > part being done and only "updates" will be sent from here forward. I think this may be a valid requirement for LCUP. With Persistent Search, a client can tell where the stream of changes begins, but only after the first change is received (by looking for the presence of an entryChangeControl in the SearchResultEntry PDU). -Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Thu Apr 4 11:28:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21411 for ; Thu, 4 Apr 2002 11:28:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34GJwh25060 for ietf-ldup-bks; Thu, 4 Apr 2002 08:19:58 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34GJvm25054 for ; Thu, 4 Apr 2002 08:19:57 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g34GJm706720 for ; Thu, 4 Apr 2002 08:19:49 -0800 (PST) Received: from netscape.com ([205.217.228.86]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GU1XD100.HU3; Thu, 4 Apr 2002 08:19:49 -0800 Message-ID: <3CAC7C78.F598CE60@netscape.com> Date: Thu, 04 Apr 2002 09:16:56 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark C Smith CC: Timothy Hahn , ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist References: <3CAC6AE9.3090203@netscape.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE25EC76789F4D3678AF16599" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msE25EC76789F4D3678AF16599 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark C Smith wrote: > Timothy Hahn wrote: > > > > What about a client that wants to "hold off" on handling search requests > > until it knows that its > > information is "close" to what is held in the server? "close" being > > defined as the "synchronization" > > part being done and only "updates" will be sent from here forward. > > I think this may be a valid requirement for LCUP. With Persistent > Search, a client can tell where the stream of changes begins, but only > after the first change is received (by looking for the presence of an > entryChangeControl in the SearchResultEntry PDU). Do we need to have the sync phase be completely finished before the persistent phase begins? Or is it merely enough to know that a returned entry is from the sync phase or the persistent phase? For the latter, it would be easy to add another field to the response control. For the former, that would be much harder for server implementors to guarantee some sort of order I think. What is the requirement? > > > -Mark Smith > Netscape --------------msE25EC76789F4D3678AF16599 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJbwYJKoZIhvcNAQcCoIIJYDCCCVwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B0IwggNkMIICzaADAgECAgJRWzANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMTEyMDExNzE3NTRaFw0wMjA1MzAxNzE3NTRa MH0xCzAJBgNVBAYTAlVTMRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxFTATBgoJkiaJ k/IsZAEBEwVyaWNobTEhMB8GCSqGSIb3DQEJARYScmljaG1AbmV0c2NhcGUuY29tMRcwFQYD VQQDEw5SaWNoIE1lZ2dpbnNvbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAy+QEICyv nXraX0tvcretFdF6qUJS5AMstn6ohTpaw8OxpAkprpj3VcP/N39mavcqZ4H0y3OT7SKZLTlv g6H3mWD6jnhht5G2YFdeO6fmb26QXXDjj6kpqt6iQhTZxg5ZUSHL79oTmbdj7M/xn9wnbDMD vWG6G2NnhCzELzWycxkCAwEAAaOB2zCB2DAOBgNVHQ8BAf8EBAMCBeAwQwYJYIZIAYb4QgEN BDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0 LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+L I7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRp ZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDANBgkqhkiG9w0BAQQFAAOBgQCwNXTrDTui/LLE dafKau8xKlXyFgG5XbqNiHIkU4g88IgtK79pgSEys9uovMmXZLrItHs7jMPzHKr7ad6WDuq3 y2GVs4vmXQamQ5oei83ESFzfipgHNqCpn93a5S3zZPmg2F//Udd1JNcn55H9W1Zbi8p5bfUM u+OSlj6JT+zJiTCCA9YwggM/oAMCAQICBAIAAeYwDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1 c3QgUm9vdDAeFw0wMTA2MDExMjQ3MDBaFw0wNDA2MDEyMzU5MDBaMIGTMQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJp Y2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50 cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDi718sdkOJSxpfs+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SIiGne/YNX4KMRGRGq 1ty877PSFS5Uxm58v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhClvMGk0XhMBuVkQfwF JWMm6+8Mx25UoYzOVFe2H5LashJLjQIDAQABo4IBgjCCAX4wTQYDVR0fBEYwRDBCoECgPoY8 aHR0cDovL3d3dzEudXMtaG9zdGluZy5iYWx0aW1vcmUuY29tL2NnaS1iaW4vQ1JML0dURVJv b3QuY2dpMB0GA1UdDgQWBBQp27Itg35/iyO7wsxmuTnoKfMChjBmBgNVHSAEXzBdMEYGCiqG SIb4YwECAQUwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5iYWx0aW1vcmUuY29tL0NQUy9P bW5pUm9vdC5odG1sMBMGAyoDBDAMMAoGCCsGAQUFBwIBMFgGA1UdIwRRME+hSaRHMEUxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJl clRydXN0IFJvb3SCAgGjMCsGA1UdEAQkMCKADzIwMDEwNjAxMTI0NzMwWoEPMjAwMzA5MDEy MzU5MDBaMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMA0GCSqGSIb3DQEBBQUA A4GBAEpiDtn6RncECmwN3f7SIjmZEAquiC2GPVeE5hIkN2n7WV7iEbD5n6RXhoppHwZj0X3u MzZJECAPH5cXLCdsPWw5BHviReiHG1S2YEFtHa4F8535OjSa43trTHH466grg7A1kEwZaHHt 8GMiXsJb7CB6tbBRc+kH7oFndnlT95XUMYIB9TCCAfECAQEwgZowgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmlj YSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRy YW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAlFbMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwNDA0MTYxNjU2WjAjBgkqhkiG 9w0BCQQxFgQU9vE51zKp0sN6xpBXyptv/pSzPB0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYC8yuT0EMdcbcyQRPNEVyPsi+0ir4N4tIjOgDDDjh3k zRdA/xERt3tlz4BvxRnnMAtqX3BOjLp4te9zZz8JpbaFL8Xy5fHvzB1C86d4STFEc9JTHxcf WuwDNUewPL00G/gb+bUXDTQlZlpnGyNWTR+XZNG58JYgYRFPfgdqLG1Raw== --------------msE25EC76789F4D3678AF16599-- From owner-ietf-ldup@mail.imc.org Thu Apr 4 12:12:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23610 for ; Thu, 4 Apr 2002 12:12:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34H3iK28963 for ietf-ldup-bks; Thu, 4 Apr 2002 09:03:44 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34H3hm28959 for ; Thu, 4 Apr 2002 09:03:43 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g34H3aC18491; Thu, 4 Apr 2002 17:03:36 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020404085702.0279ae10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Apr 2002 09:03:48 -0800 To: richm@netscape.com (Rich Megginson) From: "Kurt D. Zeilenga" Subject: Re: LCUP and PSearch on Sync-And-Persist Cc: Mark C Smith , Timothy Hahn , ietf-ldup@imc.org In-Reply-To: <3CAC7C78.F598CE60@netscape.com> References: <3CAC6AE9.3090203@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There are many clients which need to know they are 'in sync'. I note that this is not just after the initial 'sync up' phase, but subsequently. Also, there are cases where the server needs to update the cookie without sending an update (in the 'persist' phase. I suggest that we add a 'in sync' notification to LCUP. Basically, just a (intermediate) response PDU which says "you're in sync" and, OPTIONALLY, provides a new cookie. The server should send one when it has sent all changes necessary to 'sync' the client. The server may send them subsequently to again notify the client it is 'in sync'. Kurt At 08:16 AM 2002-04-04, Rich Megginson wrote: >Mark C Smith wrote: > >> Timothy Hahn wrote: >> > >> > What about a client that wants to "hold off" on handling search requests >> > until it knows that its >> > information is "close" to what is held in the server? "close" being >> > defined as the "synchronization" >> > part being done and only "updates" will be sent from here forward. >> >> I think this may be a valid requirement for LCUP. With Persistent >> Search, a client can tell where the stream of changes begins, but only >> after the first change is received (by looking for the presence of an >> entryChangeControl in the SearchResultEntry PDU). > >Do we need to have the sync phase be completely finished before the persistent phase begins? Or is it merely enough to know that >a returned entry is from the sync phase or the persistent phase? For the latter, it would be easy to add another field to the >response control. For the former, that would be much harder for server implementors to guarantee some sort of order I think. >What is the requirement? > >> >> >> -Mark Smith >> Netscape From owner-ietf-ldup@mail.imc.org Thu Apr 4 12:18:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23926 for ; Thu, 4 Apr 2002 12:18:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34HA8Q29143 for ietf-ldup-bks; Thu, 4 Apr 2002 09:10:08 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34HA6m29139 for ; Thu, 4 Apr 2002 09:10:06 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g34HA0O12985 for ; Thu, 4 Apr 2002 09:10:00 -0800 (PST) Received: from netscape.com ([205.217.228.86]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GU1ZOP00.3SV; Thu, 4 Apr 2002 09:10:01 -0800 Message-ID: <3CAC883D.E7C8E3F2@netscape.com> Date: Thu, 04 Apr 2002 10:07:09 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Mark C Smith , Timothy Hahn , ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist References: <3CAC6AE9.3090203@netscape.com> <5.1.0.14.0.20020404085702.0279ae10@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCDA6630ADD8A36056A261C91" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msCDA6630ADD8A36056A261C91 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > There are many clients which need to know they are 'in sync'. > I note that this is not just after the initial 'sync up' phase, > but subsequently. Also, there are cases where the server > needs to update the cookie without sending an update (in the > 'persist' phase. > > I suggest that we add a 'in sync' notification to LCUP. Basically, > just a (intermediate) response PDU which says "you're in sync" > and, OPTIONALLY, provides a new cookie. > > The server should send one when it has sent all changes necessary > to 'sync' the client. The server may send them subsequently to > again notify the client it is 'in sync'. But what exactly does 'sync' mean? Does this mean 'all changes between the time I last connected and the time I connected for this session'? Because changes may come in to the server during the sync phase. What should happen to these changes? Or should those entries be included? What if the server is under a heavy update load and never gets to the end of the sync phase? > > > Kurt > > At 08:16 AM 2002-04-04, Rich Megginson wrote: > >Mark C Smith wrote: > > > >> Timothy Hahn wrote: > >> > > >> > What about a client that wants to "hold off" on handling search requests > >> > until it knows that its > >> > information is "close" to what is held in the server? "close" being > >> > defined as the "synchronization" > >> > part being done and only "updates" will be sent from here forward. > >> > >> I think this may be a valid requirement for LCUP. With Persistent > >> Search, a client can tell where the stream of changes begins, but only > >> after the first change is received (by looking for the presence of an > >> entryChangeControl in the SearchResultEntry PDU). > > > >Do we need to have the sync phase be completely finished before the persistent phase begins? Or is it merely enough to know that > >a returned entry is from the sync phase or the persistent phase? For the latter, it would be easy to add another field to the > >response control. For the former, that would be much harder for server implementors to guarantee some sort of order I think. > >What is the requirement? > > > >> > >> > >> -Mark Smith > >> Netscape --------------msCDA6630ADD8A36056A261C91 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJbwYJKoZIhvcNAQcCoIIJYDCCCVwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B0IwggNkMIICzaADAgECAgJRWzANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMTEyMDExNzE3NTRaFw0wMjA1MzAxNzE3NTRa MH0xCzAJBgNVBAYTAlVTMRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxFTATBgoJkiaJ k/IsZAEBEwVyaWNobTEhMB8GCSqGSIb3DQEJARYScmljaG1AbmV0c2NhcGUuY29tMRcwFQYD VQQDEw5SaWNoIE1lZ2dpbnNvbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAy+QEICyv nXraX0tvcretFdF6qUJS5AMstn6ohTpaw8OxpAkprpj3VcP/N39mavcqZ4H0y3OT7SKZLTlv g6H3mWD6jnhht5G2YFdeO6fmb26QXXDjj6kpqt6iQhTZxg5ZUSHL79oTmbdj7M/xn9wnbDMD vWG6G2NnhCzELzWycxkCAwEAAaOB2zCB2DAOBgNVHQ8BAf8EBAMCBeAwQwYJYIZIAYb4QgEN BDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0 LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+L I7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRp ZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDANBgkqhkiG9w0BAQQFAAOBgQCwNXTrDTui/LLE dafKau8xKlXyFgG5XbqNiHIkU4g88IgtK79pgSEys9uovMmXZLrItHs7jMPzHKr7ad6WDuq3 y2GVs4vmXQamQ5oei83ESFzfipgHNqCpn93a5S3zZPmg2F//Udd1JNcn55H9W1Zbi8p5bfUM u+OSlj6JT+zJiTCCA9YwggM/oAMCAQICBAIAAeYwDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1 c3QgUm9vdDAeFw0wMTA2MDExMjQ3MDBaFw0wNDA2MDEyMzU5MDBaMIGTMQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJp Y2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50 cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDi718sdkOJSxpfs+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SIiGne/YNX4KMRGRGq 1ty877PSFS5Uxm58v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhClvMGk0XhMBuVkQfwF JWMm6+8Mx25UoYzOVFe2H5LashJLjQIDAQABo4IBgjCCAX4wTQYDVR0fBEYwRDBCoECgPoY8 aHR0cDovL3d3dzEudXMtaG9zdGluZy5iYWx0aW1vcmUuY29tL2NnaS1iaW4vQ1JML0dURVJv b3QuY2dpMB0GA1UdDgQWBBQp27Itg35/iyO7wsxmuTnoKfMChjBmBgNVHSAEXzBdMEYGCiqG SIb4YwECAQUwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5iYWx0aW1vcmUuY29tL0NQUy9P bW5pUm9vdC5odG1sMBMGAyoDBDAMMAoGCCsGAQUFBwIBMFgGA1UdIwRRME+hSaRHMEUxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJl clRydXN0IFJvb3SCAgGjMCsGA1UdEAQkMCKADzIwMDEwNjAxMTI0NzMwWoEPMjAwMzA5MDEy MzU5MDBaMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMA0GCSqGSIb3DQEBBQUA A4GBAEpiDtn6RncECmwN3f7SIjmZEAquiC2GPVeE5hIkN2n7WV7iEbD5n6RXhoppHwZj0X3u MzZJECAPH5cXLCdsPWw5BHviReiHG1S2YEFtHa4F8535OjSa43trTHH466grg7A1kEwZaHHt 8GMiXsJb7CB6tbBRc+kH7oFndnlT95XUMYIB9TCCAfECAQEwgZowgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmlj YSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRy YW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAlFbMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwNDA0MTcwNzA5WjAjBgkqhkiG 9w0BCQQxFgQUfaWe/bgjbTXfSG+S8N0JlrZkTrYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYA3In9dH4nVo+mcNSJ/r5uY6FAbh9CBp/cWXXtcn/Un IosVUm/cforhehrQBY8eDyKGVnq3w76ffMXpzkMeV7MD77eMD5lZXtRBK9+xd58puTVgt2aR ETR36dumuIwDNApP4YdzfW8tCH5qIljro+F2dsChrgFwoS3r0enc4+cCZA== --------------msCDA6630ADD8A36056A261C91-- From owner-ietf-ldup@mail.imc.org Thu Apr 4 13:21:09 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29808 for ; Thu, 4 Apr 2002 13:21:08 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g34IC6g01367 for ietf-ldup-bks; Thu, 4 Apr 2002 10:12:06 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34IC4m01361 for ; Thu, 4 Apr 2002 10:12:04 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g34IBwC18841; Thu, 4 Apr 2002 18:11:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020404095128.0279af58@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Apr 2002 10:12:10 -0800 To: richm@netscape.com (Rich Megginson) From: "Kurt D. Zeilenga" Subject: Re: LCUP and PSearch on Sync-And-Persist Cc: Mark C Smith , Timothy Hahn , ietf-ldup@imc.org In-Reply-To: <3CAC883D.E7C8E3F2@netscape.com> References: <3CAC6AE9.3090203@netscape.com> <5.1.0.14.0.20020404085702.0279ae10@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:07 AM 2002-04-04, Rich Megginson wrote: >"Kurt D. Zeilenga" wrote: > >> There are many clients which need to know they are 'in sync'. >> I note that this is not just after the initial 'sync up' phase, >> but subsequently. Also, there are cases where the server >> needs to update the cookie without sending an update (in the >> 'persist' phase. >> >> I suggest that we add a 'in sync' notification to LCUP. Basically, >> just a (intermediate) response PDU which says "you're in sync" >> and, OPTIONALLY, provides a new cookie. >> >> The server should send one when it has sent all changes necessary >> to 'sync' the client. The server may send them subsequently to >> again notify the client it is 'in sync'. > >But what exactly does 'sync' mean? It means that the server has sent all the messages necessary for the client to have a complete and accurate copy of the requested (and provided) information. >Does this mean 'all changes between the time I last connected and the time I connected for this >session'? It means all the changes necessary to have a complete and accurate copy of the requested (and provided) information. >Because changes may come in to the server during the sync phase. The server may send them or queue them or possible use other approaches. >What should happen to these changes? Or should those >entries be included? What if the server is under a heavy update load and never gets to the end of the sync phase? If it never reaches the 'in sync' condition, it never should sent the 'in sync' message. I think we should get away from this 'sync'/'persist' phase business and look at this simply as a sequence up messages which 'updates' entries of interest. When the sequence of updates sent is known to reflect the server's current state (for all entries of interest), the server sends an 'in sync' message notifying the client of this. The initial 'in sync' message should be sent as soon as the all the changes necessary to be 'in sync' have be sent. Subsequent 'in sync' messages can be sent whenever the server desires to send them. Kurt Kurt From owner-ietf-ldup@mail.imc.org Thu Apr 4 14:14:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04706 for ; Thu, 4 Apr 2002 14:14:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34J5rm04920 for ietf-ldup-bks; Thu, 4 Apr 2002 11:05:53 -0800 (PST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34J5qm04916 for ; Thu, 4 Apr 2002 11:05:52 -0800 (PST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g34J5fP23494 for ; Thu, 4 Apr 2002 14:05:41 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2C54KQ54; Thu, 4 Apr 2002 14:05:41 -0500 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.183.58]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQL95MTL; Thu, 4 Apr 2002 14:05:42 -0500 Message-ID: <3CACA438.49307F31@metasolv.com> Date: Thu, 04 Apr 2002 14:06:32 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Mircea Pana Reply-To: mpana@metasolv.com Organization: Metasolv Software X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist References: <3CABBBBC.7BE7B3AA@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > would appreciate more information about what type of > application you have that would require that information. > The application (LDAP Client) processes data that is heavily interdependent (references and subordination) thus a single entry may not have a meaning by itself. Also, in the synchronization phase, a large number of entries is expected by the client in a relatively short period of time. So, the results are buffered but not processed by the application while synchronizing since it is assumed that the information is incomplete. Also, a session lost while synchronizing is not "recoverable" from the application point of view since the information received may violate the semantics. Regards, Mircea. From owner-ietf-ldup@mail.imc.org Thu Apr 4 14:31:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05735 for ; Thu, 4 Apr 2002 14:31:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34JNBS05332 for ietf-ldup-bks; Thu, 4 Apr 2002 11:23:11 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34JNAm05327 for ; Thu, 4 Apr 2002 11:23:10 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g34JN3O25205 for ; Thu, 4 Apr 2002 11:23:03 -0800 (PST) Received: from netscape.com ([205.217.228.86]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GU25UI00.95H; Thu, 4 Apr 2002 11:23:06 -0800 Message-ID: <3CACA76E.2BAE521C@netscape.com> Date: Thu, 04 Apr 2002 12:20:14 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpana@metasolv.com CC: ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist References: <3CABBBBC.7BE7B3AA@netscape.com> <3CACA438.49307F31@metasolv.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms23BF48E997DC5F808444D0FA" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms23BF48E997DC5F808444D0FA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mircea Pana wrote: > > would appreciate more information about what type of > > application you have that would require that information. > > > > The application (LDAP Client) processes data that is heavily interdependent > (references and subordination) thus a single entry may not have a meaning by > itself. Also, in the synchronization phase, a large number of entries is > expected by the client in a relatively short period of time. > > So, the results are buffered but not processed by the application while > synchronizing since it is assumed that the information is incomplete. Also, a > session lost while synchronizing is not "recoverable" from the application point > of view since the information received may violate the semantics. So, if you lose a connection, or the server crashes, or any number of reasons to lose a session, you have to resync from scratch every time? > > > Regards, > Mircea. --------------ms23BF48E997DC5F808444D0FA Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJbwYJKoZIhvcNAQcCoIIJYDCCCVwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B0IwggNkMIICzaADAgECAgJRWzANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMTEyMDExNzE3NTRaFw0wMjA1MzAxNzE3NTRa MH0xCzAJBgNVBAYTAlVTMRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxFTATBgoJkiaJ k/IsZAEBEwVyaWNobTEhMB8GCSqGSIb3DQEJARYScmljaG1AbmV0c2NhcGUuY29tMRcwFQYD VQQDEw5SaWNoIE1lZ2dpbnNvbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAy+QEICyv nXraX0tvcretFdF6qUJS5AMstn6ohTpaw8OxpAkprpj3VcP/N39mavcqZ4H0y3OT7SKZLTlv g6H3mWD6jnhht5G2YFdeO6fmb26QXXDjj6kpqt6iQhTZxg5ZUSHL79oTmbdj7M/xn9wnbDMD vWG6G2NnhCzELzWycxkCAwEAAaOB2zCB2DAOBgNVHQ8BAf8EBAMCBeAwQwYJYIZIAYb4QgEN BDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0 LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+L I7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRp ZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDANBgkqhkiG9w0BAQQFAAOBgQCwNXTrDTui/LLE dafKau8xKlXyFgG5XbqNiHIkU4g88IgtK79pgSEys9uovMmXZLrItHs7jMPzHKr7ad6WDuq3 y2GVs4vmXQamQ5oei83ESFzfipgHNqCpn93a5S3zZPmg2F//Udd1JNcn55H9W1Zbi8p5bfUM u+OSlj6JT+zJiTCCA9YwggM/oAMCAQICBAIAAeYwDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1 c3QgUm9vdDAeFw0wMTA2MDExMjQ3MDBaFw0wNDA2MDEyMzU5MDBaMIGTMQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJp Y2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50 cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDi718sdkOJSxpfs+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SIiGne/YNX4KMRGRGq 1ty877PSFS5Uxm58v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhClvMGk0XhMBuVkQfwF JWMm6+8Mx25UoYzOVFe2H5LashJLjQIDAQABo4IBgjCCAX4wTQYDVR0fBEYwRDBCoECgPoY8 aHR0cDovL3d3dzEudXMtaG9zdGluZy5iYWx0aW1vcmUuY29tL2NnaS1iaW4vQ1JML0dURVJv b3QuY2dpMB0GA1UdDgQWBBQp27Itg35/iyO7wsxmuTnoKfMChjBmBgNVHSAEXzBdMEYGCiqG SIb4YwECAQUwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5iYWx0aW1vcmUuY29tL0NQUy9P bW5pUm9vdC5odG1sMBMGAyoDBDAMMAoGCCsGAQUFBwIBMFgGA1UdIwRRME+hSaRHMEUxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJl clRydXN0IFJvb3SCAgGjMCsGA1UdEAQkMCKADzIwMDEwNjAxMTI0NzMwWoEPMjAwMzA5MDEy MzU5MDBaMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMA0GCSqGSIb3DQEBBQUA A4GBAEpiDtn6RncECmwN3f7SIjmZEAquiC2GPVeE5hIkN2n7WV7iEbD5n6RXhoppHwZj0X3u MzZJECAPH5cXLCdsPWw5BHviReiHG1S2YEFtHa4F8535OjSa43trTHH466grg7A1kEwZaHHt 8GMiXsJb7CB6tbBRc+kH7oFndnlT95XUMYIB9TCCAfECAQEwgZowgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmlj YSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRy YW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAlFbMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwNDA0MTkyMDE0WjAjBgkqhkiG 9w0BCQQxFgQUHr3UKGrdUh9GXR9R5UsQfjjtTUEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYACbqGDvd8SS5YB7OGHpB/+4yOqfSDHOmCb5D34QYV/ 14RWzQDwF4tCZfNg7+W3sUFBLlApKf7Hj8YOSZ9dM6RFktdj8yZrWLCy7W/5Y7OZXHV/n/vq ZHkPlD8MjRGJqUD6ijCm079sDukbRDjcom9HstYZjD0nD8EZtERsDb1BJw== --------------ms23BF48E997DC5F808444D0FA-- From owner-ietf-ldup@mail.imc.org Fri Apr 5 11:56:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09706 for ; Fri, 5 Apr 2002 11:56:39 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35GhF524898 for ietf-ldup-bks; Fri, 5 Apr 2002 08:43:15 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35GhEm24892 for ; Fri, 5 Apr 2002 08:43:14 -0800 (PST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 5 Apr 2002 08:43:11 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Apr 2002 08:43:10 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 5 Apr 2002 08:43:10 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 5 Apr 2002 08:43:10 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Fri, 5 Apr 2002 08:39:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: LCUP and PSearch on Sync-And-Persist Date: Fri, 5 Apr 2002 08:39:46 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD033F7650@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: LCUP and PSearch on Sync-And-Persist thread-index: AcHcBAge/ArX2IxrQcGJwkVWKHo5HgAMvkEg From: "Jeff Parham" To: "Kurt D. Zeilenga" , "Rich Megginson" Cc: "Mark C Smith" , "Timothy Hahn" , X-OriginalArrivalTime: 05 Apr 2002 16:39:46.0095 (UTC) FILETIME=[7EB8B3F0:01C1DCC0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g35GhEm24893 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit What is the scenario in which a client needs to do something special on receipt of the "in sync" notification? The only one I can see is on an "initial sync," where some clients might want to know they have a reasonably complete set of search results as they existed in the recent past (excepting loose consistency due to replication latency between DSAs, etc.). In such a case the client could initially use a synchronizeOnly LCUP exchange with the DSA, then switch to synchronizeAndPersist for future LCUP interactions. The example scenario cited by Mircea -- ensuring the client has a consistent view across many objects -- is not one that can or should be solved through LCUP. The solution to this problem is the use of application versioning of objects. Many strategies for this exist -- e.g., those detailed at http://msdn.microsoft.com/library/en-us/netdir/ad/detecting_and_avoiding _replication_latency.asp. In short, I am not yet convinced that the currently specified behavior of LCUP in this area is deficient. -J -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, April 04, 2002 10:12 AM To: Rich Megginson Cc: Mark C Smith; Timothy Hahn; ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist At 09:07 AM 2002-04-04, Rich Megginson wrote: >"Kurt D. Zeilenga" wrote: > >> There are many clients which need to know they are 'in sync'. >> I note that this is not just after the initial 'sync up' phase, >> but subsequently. Also, there are cases where the server >> needs to update the cookie without sending an update (in the >> 'persist' phase. >> >> I suggest that we add a 'in sync' notification to LCUP. Basically, >> just a (intermediate) response PDU which says "you're in sync" >> and, OPTIONALLY, provides a new cookie. >> >> The server should send one when it has sent all changes necessary >> to 'sync' the client. The server may send them subsequently to >> again notify the client it is 'in sync'. > >But what exactly does 'sync' mean? It means that the server has sent all the messages necessary for the client to have a complete and accurate copy of the requested (and provided) information. >Does this mean 'all changes between the time I last connected and the time I connected for this >session'? It means all the changes necessary to have a complete and accurate copy of the requested (and provided) information. >Because changes may come in to the server during the sync phase. The server may send them or queue them or possible use other approaches. >What should happen to these changes? Or should those >entries be included? What if the server is under a heavy update load and never gets to the end of the sync phase? If it never reaches the 'in sync' condition, it never should sent the 'in sync' message. I think we should get away from this 'sync'/'persist' phase business and look at this simply as a sequence up messages which 'updates' entries of interest. When the sequence of updates sent is known to reflect the server's current state (for all entries of interest), the server sends an 'in sync' message notifying the client of this. The initial 'in sync' message should be sent as soon as the all the changes necessary to be 'in sync' have be sent. Subsequent 'in sync' messages can be sent whenever the server desires to send them. Kurt Kurt From owner-ietf-ldup@mail.imc.org Mon Apr 8 09:58:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23771 for ; Mon, 8 Apr 2002 09:58:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38DkJm14098 for ietf-ldup-bks; Mon, 8 Apr 2002 06:46:19 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38DkIm14089 for ; Mon, 8 Apr 2002 06:46:18 -0700 (PDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g38Dk87a403078 for ; Mon, 8 Apr 2002 09:46:10 -0400 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g38Dk6p41314 for ; Mon, 8 Apr 2002 09:46:06 -0400 Subject: RE: LCUP and PSearch on Sync-And-Persist To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Timothy Hahn" Date: Mon, 8 Apr 2002 09:39:28 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.10 |March 28, 2002) at 04/08/2002 09:46:05 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeff and Rich, Thanks for your consideration on this topic. I went back and reviewed the draft to brush up on the general aspects of the protocol definition. I still have some questions regarding how the original intentions can be satisfied. I see two issues: 1) How are "intermediate updates" to be handled by implementations? I suspect that this may be wound up in a server's implementation of the "state" represented by the "cookie" value and the draft may leave this as an "excercise for the implementer". If so, I think it would be to everyone's advantage that the draft indicate "beware - invention required here" on this topic. For example: if the "cookie" value changes relatively often (so that client's presumably don't have to re-start from scratch all the time), and an update to an entry is received on one thread while a LCUP session is "in process" on another, it is problematic for the server implementation to merely send the "updated entry" in the middle of the "synchronize" data stream for the client. If this occurs, and the "cookie" is updated ... depending on the "cookie format", lots of data could be missed on a re-driven synchronization request. 2) How is a client supposed to know when they're "close"? I believe the algorithm you've listed below, using the final "cookie" from the "synchronizeOnly" session as the "starting point" for the "synchronizeAndPersist" session, can work (assuming the server understands this, of course, and the client is careful to re-use the last "cookie" value from the first LCUP session). Again, the dangers in "intermediate updates" should be considered - for example, should server implementations send "intermediate updates" if "synchronizeOnly" is specified? Since "cookies" are to be used "across" LCUP sessions, it seems to strongly suggest that they be related to some form of timestamp. (I know it's not required, but establishing "what has changed since I sent this client this 'cookie'" seems to lead one to see that there has to be some time component to the "cookie" - if only there is a table in the server implementation which relates the cookie value to some time and space point. But this gets into trouble depending on which cookie values are "remembered" by the client especially if "intermediate updates" flow in the middle of the LCUP session. One more point - since the protocol indicates that the response to the client is in the form of a searchResultEntry, this implies that for entries with attributes that have a large number of values, small changes to those attributes will require large data transfers over LCUP sessions. It would be good to note this in the LCUP draft as a consideration for implementors/users of the protocol. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Jeff Parham" , "Rich Megginson" rosoft.com> cc: "Mark C Smith" , Timothy Hahn/Endicott/IBM@IBMUS, 04/05/2002 11:39 AM Subject: RE: LCUP and PSearch on Sync-And-Persist What is the scenario in which a client needs to do something special on receipt of the "in sync" notification? The only one I can see is on an "initial sync," where some clients might want to know they have a reasonably complete set of search results as they existed in the recent past (excepting loose consistency due to replication latency between DSAs, etc.). In such a case the client could initially use a synchronizeOnly LCUP exchange with the DSA, then switch to synchronizeAndPersist for future LCUP interactions. The example scenario cited by Mircea -- ensuring the client has a consistent view across many objects -- is not one that can or should be solved through LCUP. The solution to this problem is the use of application versioning of objects. Many strategies for this exist -- e.g., those detailed at http://msdn.microsoft.com/library/en-us/netdir/ad/detecting_and_avoiding _replication_latency.asp. In short, I am not yet convinced that the currently specified behavior of LCUP in this area is deficient. -J -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, April 04, 2002 10:12 AM To: Rich Megginson Cc: Mark C Smith; Timothy Hahn; ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist At 09:07 AM 2002-04-04, Rich Megginson wrote: >"Kurt D. Zeilenga" wrote: > >> There are many clients which need to know they are 'in sync'. >> I note that this is not just after the initial 'sync up' phase, >> but subsequently. Also, there are cases where the server >> needs to update the cookie without sending an update (in the >> 'persist' phase. >> >> I suggest that we add a 'in sync' notification to LCUP. Basically, >> just a (intermediate) response PDU which says "you're in sync" >> and, OPTIONALLY, provides a new cookie. >> >> The server should send one when it has sent all changes necessary >> to 'sync' the client. The server may send them subsequently to >> again notify the client it is 'in sync'. > >But what exactly does 'sync' mean? It means that the server has sent all the messages necessary for the client to have a complete and accurate copy of the requested (and provided) information. >Does this mean 'all changes between the time I last connected and the time I connected for this >session'? It means all the changes necessary to have a complete and accurate copy of the requested (and provided) information. >Because changes may come in to the server during the sync phase. The server may send them or queue them or possible use other approaches. >What should happen to these changes? Or should those >entries be included? What if the server is under a heavy update load and never gets to the end of the sync phase? If it never reaches the 'in sync' condition, it never should sent the 'in sync' message. I think we should get away from this 'sync'/'persist' phase business and look at this simply as a sequence up messages which 'updates' entries of interest. When the sequence of updates sent is known to reflect the server's current state (for all entries of interest), the server sends an 'in sync' message notifying the client of this. The initial 'in sync' message should be sent as soon as the all the changes necessary to be 'in sync' have be sent. Subsequent 'in sync' messages can be sent whenever the server desires to send them. Kurt Kurt From owner-ietf-ldup@mail.imc.org Mon Apr 8 12:10:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28497 for ; Mon, 8 Apr 2002 12:10:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38G2KJ25168 for ietf-ldup-bks; Mon, 8 Apr 2002 09:02:20 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38G2Im25164 for ; Mon, 8 Apr 2002 09:02:18 -0700 (PDT) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38G1ui20906; Mon, 8 Apr 2002 12:01:56 -0400 (EDT) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2P901GKX; Mon, 8 Apr 2002 12:01:55 -0400 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.183.58]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQL95PFD; Mon, 8 Apr 2002 12:01:55 -0400 Message-ID: <3CB1BF0F.43C0D5E8@metasolv.com> Date: Mon, 08 Apr 2002 12:02:24 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Mircea Pana Reply-To: mpana@metasolv.com Organization: Metasolv Software X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: richm@netscape.com, ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist References: <3CACA76E.2BAE521C@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > So, if you lose a connection, or the server crashes, or any number of > reasons to lose a session, you have to resync from scratch > every time? I have two kinds of client apps.: 1. A lightweight client without persistent storage resync "from scratch" every time. Due to the relatively heavy data processing required, it will wait for "sync" state to be reached before compiling the initial data. Subsequently it will act on change. Such client has a limited scope (expects to receive a moderate number of entries). 2. A full featured client with persistent storage keeps a copy of the processed data (not 1:1 with the raw LDAP entries). Once past the "(re)sync." phase, it compiles the data received and takes the necessary actions. It can "recover" a broken session based on the cookie of the last successfully processed data element. If the Directory server does not provide an "in sync." indication, the client apps. mentioned above need to treat all responses incrementally which would affect their performance. So, IMO, even though not a must, supporting such feature is a strong wish. However, there is a case that I don't see how to resolve without an "in sync." indication from the server: Let's say that an application with persistent storage has received, processed and stored a fair amount of data from the Directory server when the session closes and the cookie is either lost or corrupted or the client receives a "reload required". The only option the client has is to start the next session "from scratch". The "old" data can not be cleared away immediately because that may lead to temporary disruption of critical services - unacceptable! So, the application would attempt to "sync." from the Directory server, process the new data, compare it with the old one and apply the delta before going into the "persistence" mode. Any suggestions would be greatly appreciated. Thanks, Mircea. > From owner-ietf-ldup@mail.imc.org Mon Apr 8 12:31:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29138 for ; Mon, 8 Apr 2002 12:31:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38GLnf25523 for ietf-ldup-bks; Mon, 8 Apr 2002 09:21:49 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38GLmm25519 for ; Mon, 8 Apr 2002 09:21:48 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g38GLhS19428 for ; Mon, 8 Apr 2002 09:21:43 -0700 (PDT) Received: from netscape.com ([205.217.228.65]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GU9C4700.76Y; Mon, 8 Apr 2002 09:21:43 -0700 Message-ID: <3CB1C2E5.183BABE4@netscape.com> Date: Mon, 08 Apr 2002 10:18:45 -0600 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Timothy Hahn CC: ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCAE2C9C23A010A0DB2EF6266" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msCAE2C9C23A010A0DB2EF6266 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Timothy Hahn wrote: > Jeff and Rich, > > Thanks for your consideration on this topic. > > I went back and reviewed the draft to brush up on the general aspects of > the protocol definition. > > I still have some questions regarding how the original intentions can be > satisfied. > > I see two issues: > > 1) How are "intermediate updates" to be handled by implementations? I > suspect that this may be wound up in a server's implementation of the > "state" represented by the "cookie" value and the draft may leave this as > an "excercise for the implementer". If so, I think it would be to > everyone's advantage that the draft indicate "beware - invention required > here" on this topic. For example: if the "cookie" value changes relatively > often (so that client's presumably don't have to re-start from scratch all > the time), and an update to an entry is received on one thread while a LCUP > session is "in process" on another, it is problematic for the server > implementation to merely send the "updated entry" in the middle of the > "synchronize" data stream for the client. If this occurs, and the "cookie" > is updated ... depending on the "cookie format", lots of data could be > missed on a re-driven synchronization request. One possible implementation is to use an RUV or some other data containing one or more CSNs in the cookie. The CSNs of course contain a timestamp. If the server sends LCUP responses to the client in CSN order, I think it would be relatively easy for the server to figure out where in the outgoing data stream to insert the "updated entry" (assuming well behaved replication). The cookie would contain the min and max CSNs. One possible problem would be that the LCUP server receives an update with a very old CSN - older than the min CSN in any cookie. But this should not happen in well behaved replication. > 2) How is a client supposed to know when they're "close"? I believe the > algorithm you've listed below, using the final "cookie" from the > "synchronizeOnly" session as the "starting point" for the > "synchronizeAndPersist" session, can work (assuming the server understands > this, of course, and the client is careful to re-use the last "cookie" > value from the first LCUP session). Again, the dangers in "intermediate > updates" should be considered - for example, should server implementations > send "intermediate updates" if "synchronizeOnly" is specified? Yes, I believe. Let's say a client establishes the initial LCUP session at time T0 (the T part of the CSN), and the session is for synchronizeOnly. This means that the server should send every update with a CSN which has a timestamp Tx <= T0. So, if the server receives an update after T0, but the CSN has a timestamp <= T0, it should be included in the initial synchronization. I believe if a client wants to be "close", the client should simply do a synchronizeOnly session. If the server is not experiencing a large update rate, this should be sufficient. If the server is experiencing a large update rate, how can the client ever be assured of being close? > Since "cookies" are to be used "across" LCUP sessions, it seems to strongly > suggest that they be related to some form of timestamp. (I know it's not > required, but establishing "what has changed since I sent this client this > 'cookie'" seems to lead one to see that there has to be some time component > to the "cookie" - if only there is a table in the server implementation > which relates the cookie value to some time and space point. But this gets > into trouble depending on which cookie values are "remembered" by the > client especially if "intermediate updates" flow in the middle of the LCUP > session. > > One more point - since the protocol indicates that the response to the > client is in the form of a searchResultEntry, this implies that for entries > with attributes that have a large number of values, small changes to those > attributes will require large data transfers over LCUP sessions. It would > be good to note this in the LCUP draft as a consideration for > implementors/users of the protocol. That's very good to note, and might cause big problems with people wishing to use LCUP to sync lots of changes to large static groups. > > > Regards, > Tim Hahn > > Internet: hahnt@us.ibm.com > Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) > phone: 607.752.6388 tie-line: 8/852.6388 > fax: 607.752.3681 > > > "Jeff Parham" > , "Rich Megginson" > rosoft.com> cc: "Mark C Smith" , Timothy Hahn/Endicott/IBM@IBMUS, > > 04/05/2002 11:39 AM Subject: RE: LCUP and PSearch on Sync-And-Persist > > > > > What is the scenario in which a client needs to do something special on > receipt of the "in sync" notification? > > The only one I can see is on an "initial sync," where some clients might > want to know they have a reasonably complete set of search results as > they existed in the recent past (excepting loose consistency due to > replication latency between DSAs, etc.). In such a case the client > could initially use a synchronizeOnly LCUP exchange with the DSA, then > switch to synchronizeAndPersist for future LCUP interactions. > > The example scenario cited by Mircea -- ensuring the client has a > consistent view across many objects -- is not one that can or should be > solved through LCUP. The solution to this problem is the use of > application versioning of objects. Many strategies for this exist -- > e.g., those detailed at > http://msdn.microsoft.com/library/en-us/netdir/ad/detecting_and_avoiding > _replication_latency.asp. > > In short, I am not yet convinced that the currently specified behavior > of LCUP in this area is deficient. > > -J > > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, April 04, 2002 10:12 AM > To: Rich Megginson > Cc: Mark C Smith; Timothy Hahn; ietf-ldup@imc.org > Subject: Re: LCUP and PSearch on Sync-And-Persist > > At 09:07 AM 2002-04-04, Rich Megginson wrote: > >"Kurt D. Zeilenga" wrote: > > > >> There are many clients which need to know they are 'in sync'. > >> I note that this is not just after the initial 'sync up' phase, > >> but subsequently. Also, there are cases where the server > >> needs to update the cookie without sending an update (in the > >> 'persist' phase. > >> > >> I suggest that we add a 'in sync' notification to LCUP. Basically, > >> just a (intermediate) response PDU which says "you're in sync" > >> and, OPTIONALLY, provides a new cookie. > >> > >> The server should send one when it has sent all changes necessary > >> to 'sync' the client. The server may send them subsequently to > >> again notify the client it is 'in sync'. > > > >But what exactly does 'sync' mean? > > It means that the server has sent all the messages necessary for > the client to have a complete and accurate copy of the requested > (and provided) information. > > >Does this mean 'all changes between the time I last connected and the > time I connected for this > >session'? > > It means all the changes necessary to have a complete and accurate > copy of the requested (and provided) information. > > >Because changes may come in to the server during the sync phase. > > The server may send them or queue them or possible use other > approaches. > > >What should happen to these changes? Or should those > >entries be included? What if the server is under a heavy update load > and never gets to the end of the sync phase? > > If it never reaches the 'in sync' condition, it never should sent > the 'in sync' message. > > I think we should get away from this 'sync'/'persist' phase > business and look at this simply as a sequence up messages which > 'updates' entries of interest. When the sequence of updates > sent is known to reflect the server's current state (for all > entries of interest), the server sends an 'in sync' message > notifying the client of this. > > The initial 'in sync' message should be sent as soon as the > all the changes necessary to be 'in sync' have be sent. > Subsequent 'in sync' messages can be sent whenever the > server desires to send them. > > Kurt > Kurt --------------msCAE2C9C23A010A0DB2EF6266 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJbwYJKoZIhvcNAQcCoIIJYDCCCVwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B0IwggNkMIICzaADAgECAgJRWzANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMTEyMDExNzE3NTRaFw0wMjA1MzAxNzE3NTRa MH0xCzAJBgNVBAYTAlVTMRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxFTATBgoJkiaJ k/IsZAEBEwVyaWNobTEhMB8GCSqGSIb3DQEJARYScmljaG1AbmV0c2NhcGUuY29tMRcwFQYD VQQDEw5SaWNoIE1lZ2dpbnNvbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAy+QEICyv nXraX0tvcretFdF6qUJS5AMstn6ohTpaw8OxpAkprpj3VcP/N39mavcqZ4H0y3OT7SKZLTlv g6H3mWD6jnhht5G2YFdeO6fmb26QXXDjj6kpqt6iQhTZxg5ZUSHL79oTmbdj7M/xn9wnbDMD vWG6G2NnhCzELzWycxkCAwEAAaOB2zCB2DAOBgNVHQ8BAf8EBAMCBeAwQwYJYIZIAYb4QgEN BDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0 LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+L I7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRp ZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDANBgkqhkiG9w0BAQQFAAOBgQCwNXTrDTui/LLE dafKau8xKlXyFgG5XbqNiHIkU4g88IgtK79pgSEys9uovMmXZLrItHs7jMPzHKr7ad6WDuq3 y2GVs4vmXQamQ5oei83ESFzfipgHNqCpn93a5S3zZPmg2F//Udd1JNcn55H9W1Zbi8p5bfUM u+OSlj6JT+zJiTCCA9YwggM/oAMCAQICBAIAAeYwDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1 c3QgUm9vdDAeFw0wMTA2MDExMjQ3MDBaFw0wNDA2MDEyMzU5MDBaMIGTMQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJp Y2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50 cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDi718sdkOJSxpfs+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SIiGne/YNX4KMRGRGq 1ty877PSFS5Uxm58v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhClvMGk0XhMBuVkQfwF JWMm6+8Mx25UoYzOVFe2H5LashJLjQIDAQABo4IBgjCCAX4wTQYDVR0fBEYwRDBCoECgPoY8 aHR0cDovL3d3dzEudXMtaG9zdGluZy5iYWx0aW1vcmUuY29tL2NnaS1iaW4vQ1JML0dURVJv b3QuY2dpMB0GA1UdDgQWBBQp27Itg35/iyO7wsxmuTnoKfMChjBmBgNVHSAEXzBdMEYGCiqG SIb4YwECAQUwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5iYWx0aW1vcmUuY29tL0NQUy9P bW5pUm9vdC5odG1sMBMGAyoDBDAMMAoGCCsGAQUFBwIBMFgGA1UdIwRRME+hSaRHMEUxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJl clRydXN0IFJvb3SCAgGjMCsGA1UdEAQkMCKADzIwMDEwNjAxMTI0NzMwWoEPMjAwMzA5MDEy MzU5MDBaMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMA0GCSqGSIb3DQEBBQUA A4GBAEpiDtn6RncECmwN3f7SIjmZEAquiC2GPVeE5hIkN2n7WV7iEbD5n6RXhoppHwZj0X3u MzZJECAPH5cXLCdsPWw5BHviReiHG1S2YEFtHa4F8535OjSa43trTHH466grg7A1kEwZaHHt 8GMiXsJb7CB6tbBRc+kH7oFndnlT95XUMYIB9TCCAfECAQEwgZowgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmlj YSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRy YW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAlFbMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwNDA4MTYxODQ1WjAjBgkqhkiG 9w0BCQQxFgQUV6kWPQglEzP58b+haz80nUmjWZUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYAbLhMZXsAjRtnA2x7dIZKEtlM0hLvR4fvIn9UlAXw2 5jT8awgCisAqP/T3i/Wg0lKbnP2R5Hh9d+3Y9mpoLrUS762mXSMxbHlAH20EXjy8Fm/82M5u 2/VTL06+uNkM+E9nQ7gr98DaAsyqj6VMvzSXfmS2pIAjsWsTpnKgWCoAiw== --------------msCAE2C9C23A010A0DB2EF6266-- From owner-ietf-ldup@mail.imc.org Mon Apr 8 12:39:23 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29357 for ; Mon, 8 Apr 2002 12:39:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38GVPT25759 for ietf-ldup-bks; Mon, 8 Apr 2002 09:31:25 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38GVOm25755 for ; Mon, 8 Apr 2002 09:31:24 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g38GVGS23469 for ; Mon, 8 Apr 2002 09:31:16 -0700 (PDT) Received: from netscape.com ([205.217.228.65]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GU9CK400.34Y; Mon, 8 Apr 2002 09:31:16 -0700 Message-ID: <3CB1C525.1837A7D2@netscape.com> Date: Mon, 08 Apr 2002 10:28:21 -0600 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpana@metasolv.com CC: ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist References: <3CACA76E.2BAE521C@netscape.com> <3CB1BF0F.43C0D5E8@metasolv.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms82E9339D037C2329E8B970C2" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms82E9339D037C2329E8B970C2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mircea Pana wrote: > > So, if you lose a connection, or the server crashes, or any number of > > reasons to lose a session, you have to resync from scratch > > every time? > > I have two kinds of client apps.: > > 1. A lightweight client without persistent storage resync "from scratch" every > time. Due to the relatively heavy data processing required, it will wait for > "sync" state to be reached before compiling the initial data. Subsequently it > will act on change. Such client has a limited scope (expects to receive a > moderate number of entries). > > 2. A full featured client with persistent storage keeps a copy of the processed > data (not 1:1 with the raw LDAP entries). Once past the "(re)sync." phase, it > compiles the data received and takes the necessary actions. It can "recover" a > broken session based on the cookie of the last successfully processed data > element. > > If the Directory server does not provide an "in sync." indication, the client > apps. mentioned above need to treat all responses incrementally which would > affect their performance. So, IMO, even though not a must, supporting such > feature is a strong wish. Why can't the clients first do a synchronizeOnly session? If the server is not under a heavy update load, this will get the clients sufficiently close. If the server is under a heavy update load, the clients may have to wait indefinitely to be "in sync". > However, there is a case that I don't see how to resolve without an "in sync." > indication from the server: > Let's say that an application with persistent storage has received, processed > and stored a fair amount of data from the Directory server when the session > closes and the cookie is either lost or corrupted or the client receives a > "reload required". The only option the client has is to start the next session > "from scratch". The "old" data can not be cleared away immediately because that > may lead to temporary disruption of critical services - unacceptable! So, the > application would attempt to "sync." from the Directory server, process the new > data, compare it with the old one and apply the delta before going into the > "persistence" mode. Why can't the client first do a synchronizeOnly session? If that session completes successfully, the client knows that it is "reasonably" close to being "in sync" with the server (depending on the server update load). If the client loses the cookie, perhaps the server could "guess" about the state of the client if the client still knows some information like the last update time of the last entry received. I'm not sure why the client would receive a reload required assuming the client does not lose the cookie, the server is not reloaded, and the client can "keep up" with the updates on the server. Why would the application have to compare the old one with the new one? Why couldn't it just use the new one directly, unless this is an implementation detail? Please know that I am trying to understand your problem, to see if LCUP can solve it right now, that LCUP may be able to solve it with some minor modifications, or that LCUP is simply not suitable for your problem. > > > Any suggestions would be greatly appreciated. > > Thanks, > Mircea. > > > --------------ms82E9339D037C2329E8B970C2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJbwYJKoZIhvcNAQcCoIIJYDCCCVwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B0IwggNkMIICzaADAgECAgJRWzANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMTEyMDExNzE3NTRaFw0wMjA1MzAxNzE3NTRa MH0xCzAJBgNVBAYTAlVTMRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxFTATBgoJkiaJ k/IsZAEBEwVyaWNobTEhMB8GCSqGSIb3DQEJARYScmljaG1AbmV0c2NhcGUuY29tMRcwFQYD VQQDEw5SaWNoIE1lZ2dpbnNvbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAy+QEICyv nXraX0tvcretFdF6qUJS5AMstn6ohTpaw8OxpAkprpj3VcP/N39mavcqZ4H0y3OT7SKZLTlv g6H3mWD6jnhht5G2YFdeO6fmb26QXXDjj6kpqt6iQhTZxg5ZUSHL79oTmbdj7M/xn9wnbDMD vWG6G2NnhCzELzWycxkCAwEAAaOB2zCB2DAOBgNVHQ8BAf8EBAMCBeAwQwYJYIZIAYb4QgEN BDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0 LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+L I7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRp ZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDANBgkqhkiG9w0BAQQFAAOBgQCwNXTrDTui/LLE dafKau8xKlXyFgG5XbqNiHIkU4g88IgtK79pgSEys9uovMmXZLrItHs7jMPzHKr7ad6WDuq3 y2GVs4vmXQamQ5oei83ESFzfipgHNqCpn93a5S3zZPmg2F//Udd1JNcn55H9W1Zbi8p5bfUM u+OSlj6JT+zJiTCCA9YwggM/oAMCAQICBAIAAeYwDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1 c3QgUm9vdDAeFw0wMTA2MDExMjQ3MDBaFw0wNDA2MDEyMzU5MDBaMIGTMQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJp Y2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50 cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDi718sdkOJSxpfs+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SIiGne/YNX4KMRGRGq 1ty877PSFS5Uxm58v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhClvMGk0XhMBuVkQfwF JWMm6+8Mx25UoYzOVFe2H5LashJLjQIDAQABo4IBgjCCAX4wTQYDVR0fBEYwRDBCoECgPoY8 aHR0cDovL3d3dzEudXMtaG9zdGluZy5iYWx0aW1vcmUuY29tL2NnaS1iaW4vQ1JML0dURVJv b3QuY2dpMB0GA1UdDgQWBBQp27Itg35/iyO7wsxmuTnoKfMChjBmBgNVHSAEXzBdMEYGCiqG SIb4YwECAQUwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5iYWx0aW1vcmUuY29tL0NQUy9P bW5pUm9vdC5odG1sMBMGAyoDBDAMMAoGCCsGAQUFBwIBMFgGA1UdIwRRME+hSaRHMEUxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJl clRydXN0IFJvb3SCAgGjMCsGA1UdEAQkMCKADzIwMDEwNjAxMTI0NzMwWoEPMjAwMzA5MDEy MzU5MDBaMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMA0GCSqGSIb3DQEBBQUA A4GBAEpiDtn6RncECmwN3f7SIjmZEAquiC2GPVeE5hIkN2n7WV7iEbD5n6RXhoppHwZj0X3u MzZJECAPH5cXLCdsPWw5BHviReiHG1S2YEFtHa4F8535OjSa43trTHH466grg7A1kEwZaHHt 8GMiXsJb7CB6tbBRc+kH7oFndnlT95XUMYIB9TCCAfECAQEwgZowgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmlj YSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRy YW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAlFbMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwNDA4MTYyODIxWjAjBgkqhkiG 9w0BCQQxFgQUC2MpkPhMv0USLU4OP4psYt4vYaQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYCsto9WjSFgJaRccAYEPp54Xtrvs5xmfCYStf8lWAm4 /VnGa/BAdwT01kl2+QDXFq2m9i/dPbDKrwcI8sqvH08eJAbdtzKX57acw40oxDJ3bDUYs5DS Q13QugSXnGSVSL/7zTLvOk7DrUfWtut3UlO2o+aeUt6h+s3Fe/6VseOk+g== --------------ms82E9339D037C2329E8B970C2-- From owner-ietf-ldup@mail.imc.org Mon Apr 8 14:49:04 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02472 for ; Mon, 8 Apr 2002 14:49:04 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g38Ie8900998 for ietf-ldup-bks; Mon, 8 Apr 2002 11:40:08 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38Ie6m00994 for ; Mon, 8 Apr 2002 11:40:06 -0700 (PDT) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38Icii02725; Mon, 8 Apr 2002 14:38:45 -0400 (EDT) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2P9016MB; Mon, 8 Apr 2002 14:38:44 -0400 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.183.58]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQL95PMD; Mon, 8 Apr 2002 14:38:45 -0400 Message-ID: <3CB1E3D0.C3C81092@metasolv.com> Date: Mon, 08 Apr 2002 14:39:12 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Mircea Pana Reply-To: mpana@metasolv.com Organization: Metasolv Software X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: richm@netscape.com CC: ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist References: <3CB1C525.1837A7D2@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rich, > [...]Why can't the clients first do a synchronizeOnly session? This sounds like a good idea. When it starts, the client will have to perform two operations in sequence (SyncOnly followed by SyncAndPersist) instead of just one, but it doesn't sound like it would be a significant overload. Thanks for the suggestion. > [...]I'm not sure why the client would receive a reload required assuming the The cookie may become invalid if the server and/or the application are re-loaded from backups for instance. > Why would the application have to compare the old one with the new one? The application actually compiles the data and sends it over to various service engines. In a full resync session the application compares the new data set with the old one to determine the old data units to be removed. These correspond to a subset of the entries deleted after the last LCUP session but before the current one. (I suppose that in case of a "full sync." session, the Directory server will not send the previously deleted entries. Right?) I still have a question: In case of a SyncOnly session, the server "knows" when there is no more data to send to the client and closes the session with a SearchResultsDone (with lcupSuccess). Since the Directory server also has this state information in case of a SyncAndPersist session, would it be difficult or wrong to include a notification in the appropriate EntryUpdateControlValue? I appreciate your help. Thanks a lot, Mircea. > > Please know that I am trying to understand your problem, to see if LCUP can > solve it right now, that LCUP may be able to solve it > with some minor modifications, or that LCUP is simply not suitable for your > problem. > > > > > > > Any suggestions would be greatly appreciated. > > > > Thanks, > > Mircea. > > > > > From owner-ietf-ldup@mail.imc.org Mon Apr 8 15:30:41 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03749 for ; Mon, 8 Apr 2002 15:30:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38JM8L03727 for ietf-ldup-bks; Mon, 8 Apr 2002 12:22:08 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38JM7m03723 for ; Mon, 8 Apr 2002 12:22:07 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g38JM1s21541 for ; Mon, 8 Apr 2002 12:22:01 -0700 (PDT) Received: from netscape.com ([205.217.228.65]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GU9KGR00.PM5; Mon, 8 Apr 2002 12:22:03 -0700 Message-ID: <3CB1ED2C.12A9C96E@netscape.com> Date: Mon, 08 Apr 2002 13:19:08 -0600 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpana@metasolv.com CC: ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist References: <3CB1C525.1837A7D2@netscape.com> <3CB1E3D0.C3C81092@metasolv.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7E860D0F699C7474AF462769" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms7E860D0F699C7474AF462769 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mircea Pana wrote: > Rich, > > > [...]Why can't the clients first do a synchronizeOnly session? > > This sounds like a good idea. When it starts, the client will have to perform > two operations in sequence (SyncOnly followed by SyncAndPersist) instead of just > one, but it doesn't sound like it would be a significant overload. Thanks for > the suggestion. > > > [...]I'm not sure why the client would receive a reload required assuming the > > The cookie may become invalid if the server and/or the application are re-loaded > from backups for instance. Right. > > Why would the application have to compare the old one with the new one? > > The application actually compiles the data and sends it over to various service > engines. In a full resync session the application compares the new data set with > the old one to determine the old data units to be removed. These correspond to a > subset of the entries deleted after the last LCUP session but before the current > one. (I suppose that in case of a "full sync." session, the Directory server > will not send the previously deleted entries. Right?) Right. So a client acting as an intermediary would want to prevent doing a full resync of its clients. > I still have a question: In case of a SyncOnly session, the server "knows" when > there is no more data to send to the client and closes the session with a > SearchResultsDone (with lcupSuccess). Since the Directory server also has this > state information in case of a SyncAndPersist session, would it be difficult or > wrong to include a notification in the appropriate EntryUpdateControlValue? That necessarily means server implementors will have to sort the entries into two groups. I could forsee that many clients may not care to know when they are "in sync" in a syncAndPersist session, and the server would just be able to insert updated entries anywhere it chooses to in the outgoing data stream. Of course this is highly implementation dependent - I don't think this would work given the model I spoke of using CSNs for ordering. Or maybe we can make this behavior switchable by the client. I'll speak to the other authors about this. > > > I appreciate your help. > Thanks a lot, > Mircea. > > > > > Please know that I am trying to understand your problem, to see if LCUP can > > solve it right now, that LCUP may be able to solve it > > with some minor modifications, or that LCUP is simply not suitable for your > > problem. > > > > > > > > > > > Any suggestions would be greatly appreciated. > > > > > > Thanks, > > > Mircea. > > > > > > > --------------ms7E860D0F699C7474AF462769 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJbwYJKoZIhvcNAQcCoIIJYDCCCVwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B0IwggNkMIICzaADAgECAgJRWzANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMTEyMDExNzE3NTRaFw0wMjA1MzAxNzE3NTRa MH0xCzAJBgNVBAYTAlVTMRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxFTATBgoJkiaJ k/IsZAEBEwVyaWNobTEhMB8GCSqGSIb3DQEJARYScmljaG1AbmV0c2NhcGUuY29tMRcwFQYD VQQDEw5SaWNoIE1lZ2dpbnNvbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAy+QEICyv nXraX0tvcretFdF6qUJS5AMstn6ohTpaw8OxpAkprpj3VcP/N39mavcqZ4H0y3OT7SKZLTlv g6H3mWD6jnhht5G2YFdeO6fmb26QXXDjj6kpqt6iQhTZxg5ZUSHL79oTmbdj7M/xn9wnbDMD vWG6G2NnhCzELzWycxkCAwEAAaOB2zCB2DAOBgNVHQ8BAf8EBAMCBeAwQwYJYIZIAYb4QgEN BDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0 LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+L I7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRp ZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDANBgkqhkiG9w0BAQQFAAOBgQCwNXTrDTui/LLE dafKau8xKlXyFgG5XbqNiHIkU4g88IgtK79pgSEys9uovMmXZLrItHs7jMPzHKr7ad6WDuq3 y2GVs4vmXQamQ5oei83ESFzfipgHNqCpn93a5S3zZPmg2F//Udd1JNcn55H9W1Zbi8p5bfUM u+OSlj6JT+zJiTCCA9YwggM/oAMCAQICBAIAAeYwDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1 c3QgUm9vdDAeFw0wMTA2MDExMjQ3MDBaFw0wNDA2MDEyMzU5MDBaMIGTMQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJp Y2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50 cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDi718sdkOJSxpfs+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SIiGne/YNX4KMRGRGq 1ty877PSFS5Uxm58v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhClvMGk0XhMBuVkQfwF JWMm6+8Mx25UoYzOVFe2H5LashJLjQIDAQABo4IBgjCCAX4wTQYDVR0fBEYwRDBCoECgPoY8 aHR0cDovL3d3dzEudXMtaG9zdGluZy5iYWx0aW1vcmUuY29tL2NnaS1iaW4vQ1JML0dURVJv b3QuY2dpMB0GA1UdDgQWBBQp27Itg35/iyO7wsxmuTnoKfMChjBmBgNVHSAEXzBdMEYGCiqG SIb4YwECAQUwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5iYWx0aW1vcmUuY29tL0NQUy9P bW5pUm9vdC5odG1sMBMGAyoDBDAMMAoGCCsGAQUFBwIBMFgGA1UdIwRRME+hSaRHMEUxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJl clRydXN0IFJvb3SCAgGjMCsGA1UdEAQkMCKADzIwMDEwNjAxMTI0NzMwWoEPMjAwMzA5MDEy MzU5MDBaMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMA0GCSqGSIb3DQEBBQUA A4GBAEpiDtn6RncECmwN3f7SIjmZEAquiC2GPVeE5hIkN2n7WV7iEbD5n6RXhoppHwZj0X3u MzZJECAPH5cXLCdsPWw5BHviReiHG1S2YEFtHa4F8535OjSa43trTHH466grg7A1kEwZaHHt 8GMiXsJb7CB6tbBRc+kH7oFndnlT95XUMYIB9TCCAfECAQEwgZowgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmlj YSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRy YW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAlFbMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwNDA4MTkxOTA4WjAjBgkqhkiG 9w0BCQQxFgQUDV0uTNFvBEsLMDT6DICkdrNbNlYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYA/dpOqQTNP9pAcIPTGCZRSVcHMDt9i1O2worBEfBRf ZQ7VhGG9RvY5TBXQknFfGEr/JXnN8xgeGk66lVIASQ+UOOldg5Jao5b35P8i2vvwrIJ4MPJK n1FNZmzMDeKTiDwytHNHstSG6kTrrcLqzPqOQ2XprmZdHyK0IZQgfBOMfg== --------------ms7E860D0F699C7474AF462769-- From owner-ietf-ldup@mail.imc.org Mon Apr 8 17:22:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06834 for ; Mon, 8 Apr 2002 17:22:51 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g38LE0008116 for ietf-ldup-bks; Mon, 8 Apr 2002 14:14:00 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38LDxm08112 for ; Mon, 8 Apr 2002 14:13:59 -0700 (PDT) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38LDgt25837; Mon, 8 Apr 2002 17:13:42 -0400 (EDT) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2P90FS2Z; Mon, 8 Apr 2002 17:13:42 -0400 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.183.58]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQL95PTY; Mon, 8 Apr 2002 17:13:44 -0400 Message-ID: <3CB20823.C244CFDF@metasolv.com> Date: Mon, 08 Apr 2002 17:14:11 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Mircea Pana Reply-To: mpana@metasolv.com Organization: Metasolv Software X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: richm@netscape.com CC: ietf-ldup@imc.org Subject: Re: LCUP and PSearch on Sync-And-Persist References: <3CB1ED2C.12A9C96E@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > That necessarily means server implementors will have to sort the entries > into two groups. I could forsee that many clients may > not care to know when they are "in sync" in a syncAndPersist session, and > the server would just be able to insert updated entries > anywhere it chooses to in the outgoing data stream. I would argue that the lack of sequence is annoying for consumers with complex data models and as LDAP gains market share, such models become more and more frequent. These LCUP clients would have to sort and hold data until meaningful. Of course, I speak from the point of view if the client (trying to make my life easier ;-) but I'm sure that the server side has its own challenges. So, whatever the resolution will be, thanks for taking these issues into consideration. Mircea. From owner-ietf-ldup@mail.imc.org Sat Apr 13 11:35:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25783 for ; Sat, 13 Apr 2002 11:35:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3DFPFc24836 for ietf-ldup-bks; Sat, 13 Apr 2002 08:25:15 -0700 (PDT) Received: from out006.verizon.net (out006pub.verizon.net [206.46.170.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3DFPEm24832 for ; Sat, 13 Apr 2002 08:25:14 -0700 (PDT) Received: from D7ST2111 ([141.158.247.197]) by out006.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020413152346.DNEK27046.out006.verizon.net@D7ST2111>; Sat, 13 Apr 2002 10:23:46 -0500 Reply-To: From: "Chris Apple" To: , Cc: , "John Strassner" Subject: LDUP WG Meeting Minutes Date: Sat, 13 Apr 2002 11:24:59 -0400 Message-ID: <001e01c1e2ff$60841010$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001F_01C1E2DD.D9727010" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C1E2DD.D9727010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 0) Agenda Bashing No additions or changes were made to the agenda. 1) LDAPv3 Replication Requirements http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-11.txt This version represents the WG's first attempt to address IESG feedback and comment. Some list discussion has taken place and appears to be circling in on consensus relative to language to address IESG comments. There are also some off-list discussions that are being resolved with the assistance of the Applications ADs. We expect that this document will be ready to re-submit to the IESG for consideration for publication as an Informational RFC by mid-April. 2) LDAP Client Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-02.txt As of the last WG meeting there were believed to be small, non-contentious issues to be resolved with the document. It became obvious during this WG meeting that there may be a larger number of issues to discuss on the list that previously anticipated based on the number of people who have actually commented on it. Therefore, more list discussion and a revision of the document are expected. Despite this expectation, this document is Still considered to be one of the next documents we will be delivering to the IESG for consideration for publication as an RFC, in this case, as a standards-track document. 3) LDUP Update Reconciliation Procedures http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-06.txt Changes were made to the document based on list discussion. The slides used during the meeting by the document editor show the details - these slides will be submitted for inclusion in the Proceedings as well as to the WG mailing list. There are still some issues to resolve relative to synchronizing this document with the content of the LDAP Replication Architecture document. 4) LDAP Replication Architecture http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-07.txt This revision resulted from a major overhaul of the prior version to bring its content into convergence with other WG documents and list discussion. Specific changes are documented in slides used by the document editor presenting at the WG meeting. These slides will be submitted for the IETF proceedings and also will be posted to the WG mailing list. When the question about this document being ready for WG Last Call was raised, the room generally indicated that more time on the mailing list would be appropriate. One particular issue on which the architecture document is dependent is the selection or specification of an administrative model for replication by the WG. 5) LDUP Replication Information Model http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-04.txt This document is in a holding pattern, so to speak. The issue of selecting an administrative model for replication should be resolved before its revised. 6) LDAP Subentry Schema http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.txt This document has been withdrawn from WG consideration. A similar WG deliverable may or may not be needed depending on WG consensus relative to the selection or specification of an administrative model for replication. The question was raised about the X.500 administrative model being sufficient for the needs of LDAPv3 replication. This particular way of resolving the administrative model issue will be considered by the WG along with other options 7) The LDUP Replication Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-03.txt Not revised prior to the WG meeting. It is expected to enter WG Last Call along with the URP document. A revision of this document may be needed once the URP document is believed to be stable enough to enter WG Last Call. 8) General Usage Profile for LDAPv3 Replication http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-02.txt Not revised prior to the WG meeting. This document is expected to be the last to mature of all WG documents because it is a profile of how to make use of all other specifications. 9) Profile for Framing LDAPv3 Operations http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-profile-00.t xt Not revised prior to the WG meeting. This document has the same issue/dependency as the LDAP Subentry Schema and the LDAP Replication Information Model documents. an administrative model needs to be selected or specified by the WG before there is any utility in either revising it or adopting one or more individual contributions to take its place. 10) Mandatory LDAP Replica Management http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-01.txt This document has been significantly fleshed out since the last WG meeting. There are issues flagged in the document which are known to need WG discussion to stabilize the document's content. The specific issues are documented in slides presented during the WG meeting. These slides will be submitted for inclusion in the IETF proceedings as well as be posted to the WG mailing list. 11) LDUP Access Control Design Team The co-chair present at the WG meeting presented a status report on the recently formed LDUP Access Control Design Team. Specifically, a terse mission statement and proposed team work plan was presented to the WG. There were some concerns expressed about the lack of any obvious status reports into the WG being included explicitly in the work plan. There were also concerns raised about how far the proposed work plan goes down the path of allowing for the possibility of the current design team members actually creating specifications for access control in the context of LDAPv3 replication. A third area of concern was not having the design team membership included in the document presented during the WG meeting. The co-chair agreed to do the following to help alleviate these concerns: i) revise the design team's work plan to include explicit status reports and inputs to the WG ii) add a list of design team member names with e-mail addresses to the work plan iii) post the resulting document to the WG mailing list for further discussion 12) WG Charter Bashing The room consensus was that the WG charter needs to be revised to address: + actual versus anticipated publication of revisions to WG documents + the formation of the LDUP Access Control Design Team + the current dependency of the WG charter on the Access Control deliverables of the soon-to-conclude LDAPEXT WG + the LDAPv3 framing/grouping concept + an administrative model for replication + replication-relevant access control input from the LDUP Access Control Design Team During this discussion topic, the WG room was polled for likelihood of attendance by WG participants and document editors of an LDUP meeting in Japan. Only one document editor raised their hand indicating that they were planning to be at the next IETF meeting in Japan. Therefore, unless list consensus indicates that there is value in scheduling a session at the next IETF meeting, the LDUP WG will defer meeting until the Fall IETF meeting in Atlanta, GA. Chris Apple capple@cotelligent.com christopher.apple@verizon.net ------=_NextPart_000_001F_01C1E2DD.D9727010 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_001F_01C1E2DD.D9727010-- From owner-ietf-ldup@mail.imc.org Sat Apr 13 16:31:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28796 for ; Sat, 13 Apr 2002 16:31:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3DKMDD07522 for ietf-ldup-bks; Sat, 13 Apr 2002 13:22:13 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3DKMCm07518 for ; Sat, 13 Apr 2002 13:22:12 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g3DKM9C75321; Sat, 13 Apr 2002 20:22:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020413150336.0177d3b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 13 Apr 2002 15:22:21 -0500 To: From: "Kurt D. Zeilenga" Subject: Re: LDUP WG Meeting Minutes Cc: , , "John Strassner" In-Reply-To: <001e01c1e2ff$60841010$0300a8c0@D7ST2111> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:24 AM 2002-04-13, Chris Apple wrote: >11) LDUP Access Control Design Team > >The co-chair present at the WG meeting presented a status report on the >recently formed LDUP Access Control Design Team. Specifically, a terse >mission statement and proposed team work plan was presented to the WG. >There were some concerns expressed about the lack of any obvious status >reports into the WG being included explicitly in the work plan. There >were >also concerns raised about how far the proposed work plan goes down the >path >of allowing for the possibility of the current design team members >actually >creating specifications for access control in the context of LDAPv3 >replication. >A third area of concern was not having the design team membership >included >in the document presented during the WG meeting. The co-chair agreed to >do the >following to help alleviate these concerns: > > i) revise the design team's work plan to include explicit status > reports and inputs to the WG > ii) add a list of design team member names with e-mail addresses > to the work plan > iii) post the resulting document to the WG mailing list for > further discussion I noted that the LDUP WG is not yet chartered to do engineering work in the area of LDAP Access Controls and, hence, the WG's design team must limit its work (until such time a charter revision is approved) to making a recommendation on how to revise the charter. >12) WG Charter Bashing > >The room consensus was that the WG charter needs to be revised to >address: While I believe there is consensus that the LDUP WG charter needs to revised, I do not believe there is any consensus as to how the charter should be revised. In particular, I do not believe there is yet consensus on which items should or should not be added/modified/removed. No specific charter revision was proposed or discussed at the meeting. > + actual versus anticipated publication of revisions to WG >documents > + the formation of the LDUP Access Control Design Team > + the current dependency of the WG charter on the Access Control > deliverables of the soon-to-conclude LDAPEXT WG > + the LDAPv3 framing/grouping concept > + an administrative model for replication > + replication-relevant access control input from the > LDUP Access Control Design Team From owner-ietf-ldup@mail.imc.org Sat Apr 13 17:21:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29305 for ; Sat, 13 Apr 2002 17:21:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3DLE6I09183 for ietf-ldup-bks; Sat, 13 Apr 2002 14:14:06 -0700 (PDT) Received: from out019.verizon.net (out019pub.verizon.net [206.46.170.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3DLE5m09179 for ; Sat, 13 Apr 2002 14:14:05 -0700 (PDT) Received: from D7ST2111 ([141.158.246.15]) by out019.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020413211402.DXKO13286.out019.verizon.net@D7ST2111>; Sat, 13 Apr 2002 16:14:02 -0500 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" Cc: , , "'John Strassner'" Subject: RE: LDUP WG Meeting Minutes Date: Sat, 13 Apr 2002 17:13:53 -0400 Message-ID: <000001c1e330$1decad30$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C1E30E.96DB0D30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.0.20020413150336.0177d3b8@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C1E30E.96DB0D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As-a-Co-Chair: Your clarification is appreciated. However, for the purposes of the meeting minutes, I believe that the present text is generic enough to cover this and the other types (those not motivated by present charter scope) of motivations that were expressed for the same types of concerns. "There were also concerns raised about how far the proposed work plan goes down the path of allowing for the possibility of the current design team members actually creating specifications for access control in the context of LDAPv3 replication." There were some folks who didn't feel that it was appropriate based on simply not knowing what it was the team would produce at a detailed level in the earlier Stages (those that pre-date stages which would involve writing specs on the topic that is out of scope). This represents a different motivating factor than your concern over how the present charter scope was or was not applied to the proposed work plan for the design team. The minutes were getting long enough and I didn't want to start adding more volume to them by documenting specific positions held by specific individuals. In regards to the details of your clarification, I assert that the design team is not required to bound its efforts by the current or any other version of the WG charter. Admittedly, if its members do work which the WG doesn't believe that it could eventually find to be useful, time and effort are being wasted - but even that won't impact the WG significantly because the WG doesn't have to consider in detail any input that it doesn't believe is within the scope of its current charter. I also don't think there is any harm done to have the work plan be as is, with its many exit points based on WG consensus, prior to any real access control work being done by either the design team or the WG. If WG consensus is to not undertake or even attempt to reference access control specifications, it will surely tell the design team not to proceed further; then John and I would declare the design team as concluded. If the members of the design team decide to proceed regardless (which I doubt would happen), as co-chairs, John and I would be required to make statements prohibiting on-list discussion of any associated outputs from the design team. Given that scenario, I'm having trouble understanding what harm you are trying to prevent by raising the concern based on charter scope applicability to the design team's tentative work plan. Not-as-a-Co-Chair: With that said, WG consensus could be that it is uncomfortable with the design team's work plan extending so far into unknown territory, regardless of the lack of harm that doing so represents. As-a-Co-Chair: Also, because your particular motivation of concern to be squarely a process issue, please advise me if you believe that I am missing knowledge of documented IETF process which states that design teams can't be formed to work on topics on which a WG is dependent, but which currently fall out of the present scope of the WG charter. As a part of this advice, please provide as specific a reference as possible from IETF process documentation. Then, John and I can consider whether or not we have the same interpretation of that referenced text as you do. Chris Apple christopher.apple@verizon.net -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Saturday, April 13, 2002 4:22 PM To: christopher.apple@verizon.net Cc: ietf-ldup@imc.org; capple@cotelligent.com; John Strassner Subject: Re: LDUP WG Meeting Minutes At 10:24 AM 2002-04-13, Chris Apple wrote: >11) LDUP Access Control Design Team > >The co-chair present at the WG meeting presented a status report on the >recently formed LDUP Access Control Design Team. Specifically, a terse >mission statement and proposed team work plan was presented to the WG. >There were some concerns expressed about the lack of any obvious status >reports into the WG being included explicitly in the work plan. There >were also concerns raised about how far the proposed work plan goes >down the path >of allowing for the possibility of the current design team members >actually >creating specifications for access control in the context of LDAPv3 >replication. >A third area of concern was not having the design team membership >included >in the document presented during the WG meeting. The co-chair agreed to >do the >following to help alleviate these concerns: > > i) revise the design team's work plan to include explicit status > reports and inputs to the WG > ii) add a list of design team member names with e-mail addresses > to the work plan > iii) post the resulting document to the WG mailing list for > further discussion I noted that the LDUP WG is not yet chartered to do engineering work in the area of LDAP Access Controls and, hence, the WG's design team must limit its work (until such time a charter revision is approved) to making a recommendation on how to revise the charter. >12) WG Charter Bashing > >The room consensus was that the WG charter needs to be revised to >address: While I believe there is consensus that the LDUP WG charter needs to revised, I do not believe there is any consensus as to how the charter should be revised. In particular, I do not believe there is yet consensus on which items should or should not be added/modified/removed. No specific charter revision was proposed or discussed at the meeting. > + actual versus anticipated publication of revisions to WG >documents > + the formation of the LDUP Access Control Design Team > + the current dependency of the WG charter on the Access Control > deliverables of the soon-to-conclude LDAPEXT WG > + the LDAPv3 framing/grouping concept > + an administrative model for replication > + replication-relevant access control input from the > LDUP Access Control Design Team ------=_NextPart_000_0001_01C1E30E.96DB0D30 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0001_01C1E30E.96DB0D30-- From owner-ietf-ldup@mail.imc.org Sat Apr 13 17:42:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29451 for ; Sat, 13 Apr 2002 17:42:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3DLZ1309425 for ietf-ldup-bks; Sat, 13 Apr 2002 14:35:01 -0700 (PDT) Received: from out018.verizon.net (out018pub.verizon.net [206.46.170.96]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3DLZ0m09421 for ; Sat, 13 Apr 2002 14:35:00 -0700 (PDT) Received: from D7ST2111 ([141.158.246.15]) by out018.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020413213458.ERVY598.out018.verizon.net@D7ST2111>; Sat, 13 Apr 2002 16:34:58 -0500 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" Cc: , , "'John Strassner'" Subject: RE: LDUP WG Meeting Minutes Date: Sat, 13 Apr 2002 17:34:49 -0400 Message-ID: <000701c1e333$0a854d30$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_01C1E311.8373AD30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.0.20020413150336.0177d3b8@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C1E311.8373AD30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >12) WG Charter Bashing > >The room consensus was that the WG charter needs to be revised to >address: While I believe there is consensus that the LDUP WG charter needs to revised, I do not believe there is any consensus as to how the charter should be revised. In particular, I do not believe there is yet consensus on which items should or should not be added/modified/removed. No specific charter revision was proposed or discussed at the meeting. > + actual versus anticipated publication of revisions to WG >documents > + the formation of the LDUP Access Control Design Team > + the current dependency of the WG charter on the Access Control > deliverables of the soon-to-conclude LDAPEXT WG > + the LDAPv3 framing/grouping concept > + an administrative model for replication > + replication-relevant access control input from the > LDUP Access Control Design Team Room consensus doesn't mean that any decisions have been made by the WG. To me, this term only means that there was a hum of agreement that something needed to be included in a proposed charter revision for the WG to consider. Even if such additions, deletions, and/or modifications aren't actually accepted by the WG (because WG consensus can shift during discussions), the charter revision that actually is accepted by the WG will have addressed those issues by either including or excluding them. If included, the WG is addressing the issue by explicitly making some statement about them - that it either will or will not produce deliverables related to the resolving the issue. If excluded, the WG is making an implicit statement about them - that they are out of scope. The meeting minutes didn't attempt to state that a specific revision was available for review because none was required to discuss the WG Charter. The agenda item title signifies that the WG Charter would be discussed. Without other qualifications, the term "WG Charter" means the *current* WG Charter which requires no written proposal to the WG because its available online at the IETF web site. Therefore, I don't believe that the meeting minutes need to change to reflect room consensus during the meeting. Chris. ------=_NextPart_000_0008_01C1E311.8373AD30 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0008_01C1E311.8373AD30-- From owner-ietf-ldup@mail.imc.org Sun Apr 14 11:29:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19342 for ; Sun, 14 Apr 2002 11:29:43 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3EFIiF07162 for ietf-ldup-bks; Sun, 14 Apr 2002 08:18:44 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3EFIhm07156 for ; Sun, 14 Apr 2002 08:18:43 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g3EFIhC78961; Sun, 14 Apr 2002 15:18:43 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020414081414.01760fa8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 14 Apr 2002 08:18:53 -0700 To: From: "Kurt D. Zeilenga" Subject: charter additions (Was: LDUP WG Meeting Minutes) Cc: , , "'John Strassner'" In-Reply-To: <000701c1e333$0a854d30$0300a8c0@D7ST2111> References: <5.1.0.14.0.20020413150336.0177d3b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My point is that the room consensus that the items be considered by the WG does not imply that the room had consensus on whether any of the items should be added or not to the charter. That is, IMO, the consensus was for the chairs to make a specific proposal to the WG to consider. Kurt From owner-ietf-ldup@mail.imc.org Sun Apr 14 11:57:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19774 for ; Sun, 14 Apr 2002 11:57:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3EFmw409417 for ietf-ldup-bks; Sun, 14 Apr 2002 08:48:58 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3EFmvm09411 for ; Sun, 14 Apr 2002 08:48:57 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g3EFmsC79053; Sun, 14 Apr 2002 15:48:54 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020414081905.01748e58@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 14 Apr 2002 08:49:05 -0700 To: From: "Kurt D. Zeilenga" Subject: LDAP ACM work (Was: LDUP WG Meeting Minutes) Cc: , , "'John Strassner'" In-Reply-To: <000001c1e330$1decad30$0300a8c0@D7ST2111> References: <5.1.0.14.0.20020413150336.0177d3b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My concern is that that WG appears to be doing work in an area which it is not chartered to work in. A design team is a sub-group of the WG. It would be inappropriate for a WG to use design teams to circumvent its charter. I would be far more comfortable if the LDUP's LDAP ACM design team's mission was to just to produce a charter text for the WG to consider. Kurt From owner-ietf-ldup@mail.imc.org Sun Apr 14 21:05:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24348 for ; Sun, 14 Apr 2002 21:05:06 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3F0iaA00103 for ietf-ldup-bks; Sun, 14 Apr 2002 17:44:36 -0700 (PDT) Received: from dns-ext-3.cotelligent.com (dns-ext-3.cotelligent.com [66.7.140.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3F0iZm29999 for ; Sun, 14 Apr 2002 17:44:35 -0700 (PDT) Received: from cotldom21.cotelligent.com (cotldom21.cotelligent.com [10.86.0.21]) by dns-ext-3.cotelligent.com (8.11.3/8.11.3) with ESMTP id g3F0mBX26328; Sun, 14 Apr 2002 20:48:11 -0400 Received: by cotldom21.cotelligent.com with Internet Mail Service (5.5.2653.19) id <216M4DF4>; Sun, 14 Apr 2002 20:41:30 -0400 Message-ID: <916EA44D78B4D2118FE100805FBB8A2E010BD388@sfa-phl-1.cotelligent.com> From: "Apple, Chris" To: "'Kurt D. Zeilenga'" , christopher.apple@verizon.net Cc: ietf-ldup@imc.org, "Apple, Chris" , "'John Strassner'" Subject: RE: LDAP ACM work (Was: LDUP WG Meeting Minutes) Date: Sun, 14 Apr 2002 20:41:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1E416.450E67F0" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1E416.450E67F0 Content-Type: text/plain The Design Team is not the WG. The WG is doing work consistent with its charter. The Design Team will explore, propose, and, *if* the WG agrees, complete work items for the WG to consider just as any individual is free to request that the co-chairs consider individually created works. I'll post the revised Design Team work plan/mission statement tomorrow. The WG should definitely *not* consider that posting to be a proposal for extending the WG charter into areas related to ACM. It is only being presented as a document that the Design Team is planning to use as a guide for its work. I'll restate that with the actual posting just so that the applicability of the posting is clear in context. Chris Apple FastTrack Solution Development Manager Cotelligent, Inc. 401 Parkway Drive Broomall, PA 19008 (V) 610-359-5850 (M) 610-585-4241 (E) capple@cotelligent.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Sunday, April 14, 2002 11:49 AM To: christopher.apple@verizon.net Cc: ietf-ldup@imc.org; capple@cotelligent.com; 'John Strassner' Subject: LDAP ACM work (Was: LDUP WG Meeting Minutes) My concern is that that WG appears to be doing work in an area which it is not chartered to work in. A design team is a sub-group of the WG. It would be inappropriate for a WG to use design teams to circumvent its charter. I would be far more comfortable if the LDUP's LDAP ACM design team's mission was to just to produce a charter text for the WG to consider. Kurt ------_=_NextPart_000_01C1E416.450E67F0 Content-Type: application/octet-stream; name="Apple, Chris.vcf" Content-Disposition: attachment; filename="Apple, Chris.vcf" BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Apple, Chris ORG:Cotelligent;Business Development TITLE:Solutions Development Manager NOTE: TEL;WORK;VOICE:610-359-5850 TEL;WORK;VOICE: TEL;HOME;VOICE:215-873-0850 TEL;CELL;VOICE:610-585-4241 TEL;PAGER;VOICE: TEL;HOME: ADR;WORK:;Philadelphia;401 Parkway Drive;Broomall;PA;19106;US LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Philadelphia=0D=0A401 Parkway Drive=0D=0ABroomall, PA 19106=0D=0AUS EMAIL;PREF;INTERNET:capple@cotelligent.com REV:20020318T145638Z END:VCARD ------_=_NextPart_000_01C1E416.450E67F0-- From owner-ietf-ldup@mail.imc.org Mon Apr 15 08:01:58 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14098 for ; Mon, 15 Apr 2002 08:01:57 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3FBqql15161 for ietf-ldup-bks; Mon, 15 Apr 2002 04:52:52 -0700 (PDT) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FBqom15157 for ; Mon, 15 Apr 2002 04:52:50 -0700 (PDT) Received: from [10.0.1.2] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA27702; Mon, 15 Apr 2002 13:51:06 +0200 (MET DST) Date: Mon, 15 Apr 2002 11:31:52 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Apple, Chris" , "'Richard Huber'" cc: Ryan Moats , Ellen Stokes , Russel Weiser , "Apple, Chris" , "Strassner, John" , IETF LDUP Mailing List , "Freed, Ned" Subject: RE: LDUP Requirements draft 12 Message-ID: <50636117.1018870312@localhost> In-Reply-To: <916EA44D78B4D2118FE100805FBB8A2E010BD31B@sfa-phl-1.cotelligent.com> References: <916EA44D78B4D2118FE100805FBB8A2E010BD31B@sfa-phl-1.cotelligent. com> X-Mailer: Mulberry/2.2.0b4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On 2002-03-29 17.02 -0500 "Apple, Chris" wrote: > Rick is correct. The document is ready for IESG consideration > for publication as an Informational RFC once its officially published. I saw it was published on Apr 2. I'll take over from here. paf