From owner-ietf-ldup@mail.imc.org Tue Jul 1 07:37:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08146 for ; Tue, 1 Jul 2003 07:37:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNEFK046684 for ; Tue, 1 Jul 2003 04:23:14 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61BNEWd046682 for ietf-ldup-bks; Tue, 1 Jul 2003 04:23:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61BNCFK046676 for ; Tue, 1 Jul 2003 04:23:12 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07182; Tue, 1 Jul 2003 07:23:09 -0400 (EDT) Message-Id: <200307011123.HAA07182@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-usage-profile-05.txt Date: Tue, 01 Jul 2003 07:23:09 -0400 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 : General Usage Profile for LDAPv3 Replication Author(s) : R. Huber, G. Maziarski, R. Moats Filename : draft-ietf-ldup-usage-profile-05.txt Pages : 18 Date : 2003-6-30 Support for replication in LDAP directory systems is often one of the key factors in the decision to deploy them. But replication brings design constraints along with its benefits. We discuss some of the factors that should be taken into consideration when designing a replicated directory system. Both programming and architectural/operational concerns are addressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-05.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-usage-profile-05.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-usage-profile-05.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: <2003-6-30151440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-usage-profile-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-usage-profile-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151440.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Jul 1 10:28:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02528 for ; Tue, 1 Jul 2003 10:28:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61EIhFK056308 for ; Tue, 1 Jul 2003 07:18:43 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61EIhGB056307 for ietf-ldup-bks; Tue, 1 Jul 2003 07:18:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61EIfFK056283 for ; Tue, 1 Jul 2003 07:18:42 -0700 (PDT) (envelope-from rvh@qsun.mt.att.com) Received: from qsun.mt.att.com ([135.16.31.2]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h61EIZfA004687 for ; Tue, 1 Jul 2003 10:18:35 -0400 Received: by qsun.mt.att.com (8.8.8p2+Sun/ATTEMS-1.4.1 sol2) id KAA06594; Tue, 1 Jul 2003 10:18:43 -0400 (EDT) Date: Tue, 1 Jul 2003 10:18:43 -0400 (EDT) Message-Id: <200307011418.KAA06594@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldup@imc.org Subject: LCUP Comment/Question Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Two comments on the LCUP draft: [CANCEL] (draft-zeilenga-ldap-cancel-08.txt) is given as a normative reference but it is still an Internet Draft. Since LCUP is intended for standards track, doesn't this mean LCUP cannot be published as an RFC until [CANCEL] is an RFC? So what is the status of [CANCEL]? I don't remember a last call on it but I might have missed it. Should the Applicability section (Section 2) say something about the expected behavior of LCUP in a replicated environment? In particular, when an LCUP client disconnects and then reconnects, which case do we have: 1. LCUP is defined to work if it reconnects to ANY server holding a replica of the LCUP Context? 2. LCUP is defined to work only if it connects to the SAME replica that it was previously connected to? 3. this situation is undefined by LCUP and is determined by the implementation? 4. something else? Rick Huber From owner-ietf-ldup@mail.imc.org Tue Jul 1 11:58:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05430 for ; Tue, 1 Jul 2003 11:58:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61Fe6FK063369 for ; Tue, 1 Jul 2003 08:40:06 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61Fe66v063368 for ietf-ldup-bks; Tue, 1 Jul 2003 08:40:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61Fe5FK063360 for ; Tue, 1 Jul 2003 08:40:05 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h61Fe6c6056950 for ; Tue, 1 Jul 2003 15:40:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030701081954.01be5c88@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 01 Jul 2003 08:37:02 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LCUP WG-Last-Call Comment 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: As previously discussed on the list, it is our opinion that the protocol suffers from a fundamental design flaw as well as number of technical errors and omissions. Hence, we do not support the advancement of this document as suggested. Since we do not agree with the approach taken by the WG and have no interest in the protocol specified by the WG, and hence neither the time nor energy to do a detailed review, we have not attempted to do a detailed review of the document. We trust that those in the WG which are interested in the specified protocol will provide adequate review of the document. Kurt and Jong From owner-ietf-ldup@mail.imc.org Tue Jul 1 13:07:03 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07184 for ; Tue, 1 Jul 2003 13:07:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61H0EFK068561 for ; Tue, 1 Jul 2003 10:00:14 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61H0Eeu068560 for ietf-ldup-bks; Tue, 1 Jul 2003 10:00:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61H0DFK068555 for ; Tue, 1 Jul 2003 10:00:13 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h61H0Ec6057697; Tue, 1 Jul 2003 17:00:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030701083719.01d2d9f0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 01 Jul 2003 09:57:10 -0700 To: rvh@qsun.mt.att.com (Richard V Huber) From: "Kurt D. Zeilenga" Subject: Re: LCUP Comment/Question Cc: ietf-ldup@imc.org In-Reply-To: <200307011418.KAA06594@qsun.mt.att.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: At 07:18 AM 7/1/2003, Richard V Huber wrote: >Two comments on the LCUP draft: > >[CANCEL] (draft-zeilenga-ldap-cancel-08.txt) is given as a normative >reference but it is still an Internet Draft. Since LCUP is intended >for standards track, doesn't this mean LCUP cannot be published as an >RFC until [CANCEL] is an RFC? Approved documents wait at the RFC-Editor for their normative references to catch up. >So what is the status of [CANCEL]? I am presently considering making a recommendation to advance this I-D. >I don't remember a last call on it but I might have missed it. Stay tuned to (for an informal call) and the IETF announce list (for the formal call). >Should the Applicability section (Section 2) say something about the >expected behavior of LCUP in a replicated environment? In particular, >when an LCUP client disconnects and then reconnects, which case do we >have: > > 1. LCUP is defined to work if it reconnects to ANY server holding a > replica of the LCUP Context? > > 2. LCUP is defined to work only if it connects to the SAME replica > that it was previously connected to? > > 3. this situation is undefined by LCUP and is determined by the > implementation? > > 4. something else? I note that the WG should likely consider LCUP's behavior in replicated environments where the replication protocol (DISP, LDUP) allows replication events to be coalesced. Kurt From owner-ietf-ldup@mail.imc.org Tue Jul 1 15:14:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12822 for ; Tue, 1 Jul 2003 15:14:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61J47FK078979 for ; Tue, 1 Jul 2003 12:04:07 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61J47ta078978 for ietf-ldup-bks; Tue, 1 Jul 2003 12:04:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61J46FK078971 for ; Tue, 1 Jul 2003 12:04:06 -0700 (PDT) (envelope-from jmcmeek@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h61J42i8117394 for ; Tue, 1 Jul 2003 15:04:02 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h61J41lS115904; Tue, 1 Jul 2003 15:04:01 -0400 Subject: Re: LCUP Comment/Question To: rvh@qsun.mt.att.com (Richard V Huber) Cc: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Tue, 1 Jul 2003 14:03:54 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V602_05052003|May 05, 2003) at 07/01/2003 14:04:01 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: See response (JAM:) below. John McMeeking rvh@qsun.mt.att.c om (Richard V To: ietf-ldup@imc.org Huber) cc: Sent by: Subject: LCUP Comment/Question owner-ietf-ldup@m ail.imc.org 07/01/2003 09:18 AM > Two comments on the LCUP draft: > > [CANCEL] [text deleted] > > Should the Applicability section (Section 2) say something about the > expected behavior of LCUP in a replicated environment? In particular, > when an LCUP client disconnects and then reconnects, which case do we > have: > > 1. LCUP is defined to work if it reconnects to ANY server holding a > replica of the LCUP Context? > > 2. LCUP is defined to work only if it connects to the SAME replica > that it was previously connected to? > > 3. this situation is undefined by LCUP and is determined by the > implementation? > > 4. something else? JAM: I think something like 3. It could work if the LCUP scheme supports such a thing and all the servers involved support that schema. I hope that some implementation will support this. But an implementation isn't / shouldn't be required to support this. Maybe some words like: Use of an LCUP cookie with multiple DSAs in a replicated environment is not defined by LCUP. An implementation of LCUP may support continuation of a LCUP session with another DSA holding a replica of the LCUP context. In such cases, the implementation should document the LCUP Scheme used. In the absence of knowledge about such support the client should not use a LCUP cookie with any DSA other than the DSA which issued the original cookie. Or something that conveys the notion that it isn't defined by LCUP, but isn't prohibited. And leave the door open for vendors (or later standards) to address this. And the "document the scheme" part needn't involve defining an OID and having the client request that format. I'd hope that an implementation of LCUP in an replicated environment would support this with its default LCUP scheme. > Rick Huber From owner-ietf-ldup@mail.imc.org Tue Jul 1 16:37:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15596 for ; Tue, 1 Jul 2003 16:37:34 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61KSEFK083212 for ; Tue, 1 Jul 2003 13:28:14 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61KSE11083211 for ietf-ldup-bks; Tue, 1 Jul 2003 13:28:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61KSDFK083198 for ; Tue, 1 Jul 2003 13:28:13 -0700 (PDT) (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h61KS2E22574 for ; Tue, 1 Jul 2003 13:28:02 -0700 (PDT) Received: from netscape.com ([10.169.192.82]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HHD4UM01.WCY; Tue, 1 Jul 2003 13:27:58 -0700 Message-ID: <3F01EED6.6080701@netscape.com> Date: Tue, 01 Jul 2003 16:28:06 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: John McMeeking CC: Richard V Huber , ietf-ldup@imc.org Subject: Re: LCUP Comment/Question References: In-Reply-To: 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 John McMeeking wrote: > ... Maybe some words like: > > Use of an LCUP cookie with multiple DSAs in a replicated environment is not > defined by LCUP. An implementation of LCUP may support continuation of a > LCUP session with another DSA holding a replica of the LCUP context. In > such cases, the implementation should document the LCUP Scheme used. In > the absence of knowledge about such support the client should not use a > LCUP cookie with any DSA other than the DSA which issued the original > cookie. > > Or something that conveys the notion that it isn't defined by LCUP, but > isn't prohibited. And leave the door open for vendors (or later standards) > to address this. And the "document the scheme" part needn't involve > defining an OID and having the client request that format. I'd hope that > an implementation of LCUP in an replicated environment would support this > with its default LCUP scheme. My too. I thought we discussed this before... LCUP needs to allow implementations to support using the same cookie with different replicas, and needs to gracefully handle the case where an implementation does not support it. For example, if a server does not recognize the cookie or can't use the information contained in it, it may force a full refresh... but that decision is in the hands of the server. I do not think there is any need for the implementation to document the cookie scheme or for the client to be careful in this case... what am I missing? Server implementations must be able to recognize whether a cookie presented by a client is one they sent or a compatible cookie (e.g., one sent by a replica). -- Mark Smith Netscape Directory Product Development My words are my own, not my employer's. From owner-ietf-ldup@mail.imc.org Wed Jul 2 07:11:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04415 for ; Wed, 2 Jul 2003 07:11:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62AthFK051113 for ; Wed, 2 Jul 2003 03:55:43 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62AthEt051112 for ietf-ldup-bks; Wed, 2 Jul 2003 03:55:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62AtgFK051105 for ; Wed, 2 Jul 2003 03:55:43 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02699; Wed, 2 Jul 2003 06:55:42 -0400 (EDT) Message-Id: <200307021055.GAA02699@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-infomod-07.txt Date: Wed, 02 Jul 2003 06:55:41 -0400 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 : LDUP Replication Information Model Author(s) : R. Huber, J. McMeeking, R. Moats Filename : draft-ietf-ldup-infomod-07.txt Pages : 32 Date : 2003-7-1 [LDUP Model] describes the architectural approach to replication of LDAP directory contents. This document describes the information model and schema elements which support LDAP Replication Services which conform to [LDUP Model]. Directory schema is extended to provide object classes, subentries, and attributes to describe areas of the namespace which are under common administrative authority, units of replication (ie, subtrees, or partitions of the namespace, which are replicated), servers which hold replicas of various types for the various partitions of the namespace, which namespaces are held on given servers, and the progress of various namespace management and replication operations. Among other things, this knowledge of where directory content is located will provide the basis for dynamic generation of LDAP referrals for clients who can follow them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-07.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-infomod-07.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-infomod-07.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: <2003-7-1134620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-infomod-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-infomod-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134620.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Mon Jul 7 22:15:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24547 for ; Mon, 7 Jul 2003 22:15:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68285qt006373 for ; Mon, 7 Jul 2003 19:08:05 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h68285iC006372 for ietf-ldup-bks; Mon, 7 Jul 2003 19:08:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68282qt006365 for ; Mon, 7 Jul 2003 19:08:03 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-141-150-215-118.delv.east.verizon.net [141.150.215.118]) by echt.caledonia.net; Mon, 07 Jul 2003 20:07:39 -0600 Reply-To: From: "Chris Apple" To: Cc: "'John Strassner'" Subject: RE: LDUP WG Last Call: LCUP Deliverable Date: Mon, 7 Jul 2003 22:07:24 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000001c344f5$b2d5d3e0$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <000a01c3345f$6d389cb0$3d00000a@D7ST2111> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The LCUP WG Last Call concluded as scheduled on July 2, 2003. There were two threads generated in response to this message containing comments that factor into assessing whether or not to recommend consideration of the LCUP draft as a standards track RFC to our ADs. 1) http://www.imc.org/ietf-ldup/mail-archive/msg01832.html This posting is a summarized restatement of disagreement with established WG consensus. As such, this posting does not require that any changes be made to the document prior to proceeding. 2) http://www.imc.org/ietf-ldup/mail-archive/msg01831.html This was more a question than a specific request for changes to the document, and there was some further discussion by others including one of the document editors. Based on this question being raised, it does appear that the specification needs some clarification in this area and there was language proposed to do so in a follow up to the original posting. The document editors should respond to the mailing list with their intended action (incorporating the suggested text, proposing some edited version for inclusion, or something else...). Once this issue is resolved on the mailing list, the LCUP document can be revised (if necessary) and a recommendation for consideration for standards track RFC publication will be sent by John and I to the ADs at that time. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Monday, June 16, 2003 7:32 PM To: ietf-ldup@imc.org Cc: John Strassner Subject: LDUP WG Last Call: LCUP Deliverable The purpose of this message is to initiate the LDUP working group last call on the LDAP Client Update Protocol draft. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-05.txt WHAT IS A LAST CALL FOR? The purpose of the working group last call is to ensure that the working group has reached consensus on the document, believes that all the known outstanding issues have been addressed, and is ready to put the document forward for Proposed Standard status. During the last call, any comments on the documents are collected and discussed on the mailing list. HOW LONG DOES IT LAST? The last call starts Monday, June 16, 2003 and will last approximately two weeks. It will end on Tuesday, July 1, 2003 at 1700 US ET. WHAT'S THE NEXT STEP? After the last call completes, there are three possible outcomes: 1) No changes are required and we request our ADs to put forward the documents to the IESG for Proposed Standard status. 2) Minor changes agreed to on the list are required, and the documents are revised. We then ask our ADs to put forward the revised documents to the IESG for Proposed Standard status. 3) Major issues are raised and no consensus is reached on the list. In this case, we discuss things until consensus is reached, at which time another working group last call will be issued. Assuming we achieve outcome 1) or 2), and that the ADs agree with our assessment, the next stop for the documents is with the IESG. The IESG reads them and may approve the documents (with or without changes), or send the documents back to the working group to have major issues addressed. If the first outcome happens, the documents are put forward for a two-week last call to the entire IETF, and after successful completion the documents are published as RFCs with Proposed Standard status. If the second outcome happens, we go back and address the issues, putting the documents forward again when we believe they're ready. WHAT SHOULD YOU DO? You should read the documents, making sure that 1) there are no problems or deficiencies or outstanding issues that need to be resolved; and 2) that there are no typos, formatting problems, grammatical errors, etc. Any substantive problems you find, you should send to the list. Any minor problems (typos, etc.) you may send to the list or just to the authors. If, for some reason, you have comments you don't want to send to the entire list, you may send them to me and/or LDUP WG co-chair John Strassner. Silence means consent. Read, enjoy, and send your comments in! regards, Chris Apple and John Strassner Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Mon Jul 7 22:36:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24777 for ; Mon, 7 Jul 2003 22:36:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h682U6qt007057 for ; Mon, 7 Jul 2003 19:30:06 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h682U60H007056 for ietf-ldup-bks; Mon, 7 Jul 2003 19:30:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h682U4qt007045 for ; Mon, 7 Jul 2003 19:30:05 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-141-150-215-118.delv.east.verizon.net [141.150.215.118]) by echt.caledonia.net; Mon, 07 Jul 2003 20:29:33 -0600 Reply-To: From: "Chris Apple" To: Cc: Subject: LDUP WG Meeting Agenda Date: Mon, 7 Jul 2003 22:29:17 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000201c344f8$c2040f50$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit LDAP Duplication/Replication/Update Protocols WG (ldup) Tuesday, July 15 at 1300-1400 ================================ CHAIRS: Chris Apple John Strassner AGENDA: 1) Agenda Additions? 2) LCUP WG Last Call & Status http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-05.txt 3) Remaining WG Documents http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-08.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-04.txt Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Mon Jul 7 22:52:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24980 for ; Mon, 7 Jul 2003 22:52:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h682k6qt007489 for ; Mon, 7 Jul 2003 19:46:06 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h682k6ps007488 for ietf-ldup-bks; Mon, 7 Jul 2003 19:46:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h682k4qt007477 for ; Mon, 7 Jul 2003 19:46:05 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-141-150-215-118.delv.east.verizon.net [141.150.215.118]) by echt.caledonia.net; Mon, 07 Jul 2003 20:45:43 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: LDUP WG Meeting Agenda Date: Mon, 7 Jul 2003 22:45:33 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000401c344fb$03ca3750$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <000201c344f8$c2040f50$6500a8c0@D7ST2111> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit FYI. I am unable to finance attending this meeting myself even though I thought I'd be able to swing it as late as 9 PM tonight. Expenses associated with my home (when the AC konked out around 9 ;) have just outpaced my ability to fund this trip. If we have a need to meet in Minneapolis, I *may* see you all there. John Strassner will be there and will lead the meeting. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Monday, July 07, 2003 10:29 PM To: agenda@ietf.org Cc: ietf-ldup@imc.org Subject: LDUP WG Meeting Agenda LDAP Duplication/Replication/Update Protocols WG (ldup) Tuesday, July 15 at 1300-1400 ================================ CHAIRS: Chris Apple John Strassner AGENDA: 1) Agenda Additions? 2) LCUP WG Last Call & Status http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-05.txt 3) Remaining WG Documents http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-08.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-04.txt Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From subs-reminder@imc.org Sat Jul 19 19:47:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26026 for ; Sat, 19 Jul 2003 19:47:10 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JNlAqt035442 for ; Sat, 19 Jul 2003 16:47:10 -0700 (PDT) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JNlAq7035441; Sat, 19 Jul 2003 16:47:10 -0700 (PDT) Date: Sat, 19 Jul 2003 16:47:10 -0700 (PDT) Message-Id: <200307192347.h6JNlAq7035441@above.proper.com> To: ldup-archive@ietf.org Subject: [[048756663]] 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. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** 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 Sat Jul 19 19:48:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26047 for ; Sat, 19 Jul 2003 19:48:14 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JNmEqt035690 for ; Sat, 19 Jul 2003 16:48:14 -0700 (PDT) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6JNmEH8035689; Sat, 19 Jul 2003 16:48:14 -0700 (PDT) Date: Sat, 19 Jul 2003 16:48:14 -0700 (PDT) Message-Id: <200307192348.h6JNmEH8035689@above.proper.com> To: ldup-archive@ietf.org Subject: [[988974161]] 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. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** 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 Wed Jul 23 16:39:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01778 for ; Wed, 23 Jul 2003 16:39:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NKU3qt068653 for ; Wed, 23 Jul 2003 13:30:03 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NKU3QX068652 for ietf-ldup-bks; Wed, 23 Jul 2003 13:30:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NKU1qt068642 for ; Wed, 23 Jul 2003 13:30:01 -0700 (PDT) (envelope-from richm@netscape.com) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h6NKTqi11001 for ; Wed, 23 Jul 2003 13:29:52 -0700 (PDT) Received: from netscape.com ([10.178.168.3]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HIHVLX00.CA4; Wed, 23 Jul 2003 13:29:57 -0700 Message-ID: <3F1EF016.8040709@netscape.com> Date: Wed, 23 Jul 2003 14:29:10 -0600 From: richm@netscape.com (Rich Megginson) Reply-To: rmegginson0224@aol.com Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John McMeeking CC: ietf-ldup@imc.org Subject: Re: Comments on lcup-05 References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090704080600070900010408" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090704080600070900010408 Content-Type: multipart/alternative; boundary="------------050800030305040404000603" This is a multi-part message in MIME format. --------------050800030305040404000603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks for your comments John. John McMeeking wrote: >Here's some comments on draft-ietf-ldup-lcup-05.txt: > >1. Overview - paragraph on state information. I would resatate this >something like: "... the server does not need to maintain state information >specific to individual clients. The server may need to maintain additional >state information about deleted or moved/renamed entries." > Here is the text I decided to use, which is very similar to yours: "... the server does not need to maintain state information specific to individual clients. The server may need to maintain additional state information about attribute modifications, deleted entries, and moved/renamed entries." >3.5 (all controls). All these controls have a significant number of >optional fields. I think we should add tags to simplify proper decoding of >the control data. Also, given recent discussions about ASN.1 tagging, it >would be appropriate to state that implicit tagging is used (if it is). > Could you (or someone else) give me an example of what the ASN.1 should look like? >4.2.7 Result for Entries that have left the result set. There are two "An >entry SHOULD be returned as having left...." clauses. It appears the >second one is left over from a rewrite, as it repeats information in 4.2.5. >This would make it more consistent with 4.2.6. > Done. >4.3.4/4.3.5. I think the server should be given the option of rejecting a >LCUP search that includes virtual or collective attributes. If a server >would normally return these attributes, it must either properly synchronize >these attributes or reject the search request. Maybe a new >"lcupInvalidAttribute" or "unwillingToPerform" resultCode would be >appropriate. > Here is the new text of 4.3.4 and 4.3.5: 4.3.4 Operational Attributes and Administrative Entries An operational attribute SHOULD be returned if it is specified in the attributes list and would normally be returned as subject to the constraints of [RFC2251 Section 4.5]. If the server does not support syncing of operational attributes, the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform. LDAP Subentries [SUBENTRY] SHOULD be returned if they would normally be returned by the search request. If the server does not support syncing of LDAP Subentries, and the server can determine from the search request that the client has requested LDAP Subentries to be returned (e.g. search control or search filter), the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform. Otherwise, the server MAY simply omit returning LDAP Subentries. 4.3.5 Virtual Attributes An entry may have attributes whose presence in the entry, or presence of values of the attribute, is generated on the fly, possibly by some mechanism outside of the entry, elsewhere in the DIT. An example of this is collective attributes [COLLECTIVE]. These attributes shall be referred to in this document as virtual attributes. LCUP treats these attributes the same way as normal, non-virtual attributes. A virtual attribute SHOULD be returned if it is specified in the attributes list and would normally be returned as subject to the constraints of [RFC2251 Section 4.5]. If the server does not support syncing of virtual attributes, the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform. One consequence of this is that if you change the definition of a virtual attribute such that it makes the value of that attribute change in many entries in the client's search scope, this means that a server may have to return many entries to the client as a result of that one change. It is not anticipated that this will be a frequent occurrence, and the server has the option to simply force the client to resync if necessary. It is also possible that a future LDAP control will allow the client to request only virtual or only non-virtual attributes. >4.4.1 Server Initiated Termination. This para references a >lcupClientDisconnected resultCode. I didn't see that resultCode defined. > Changed to "canceled [CANCEL]". >4.5 This can probably be deleted, >though it might be helpful earlier to explain what the synchronize and >persist phases do and the sequence of requests/controls. > I would like to get rid of this, or at least not require this section for Last Call. >John McMeeking > > > --------------050800030305040404000603 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for your comments John.

John McMeeking wrote:
Here's some comments on draft-ietf-ldup-lcup-05.txt:

1. Overview - paragraph on state information.  I would resatate this
something like: "... the server does not need to maintain state information
specific to individual clients.  The server may need to maintain additional
state information about deleted or moved/renamed entries."
Here is the text I decided to use, which is very similar to yours:
"... the server does not need to maintain state information specific to individual clients.  The server may need to maintain additional state information about attribute modifications, deleted entries, and moved/renamed entries." 
3.5 (all controls).  All these controls have a significant number of
optional fields.  I think we should add tags to simplify proper decoding of
the control data.  Also, given recent discussions about ASN.1 tagging, it
would be appropriate to state that implicit tagging is used (if it is).
Could you (or someone else) give me an example of what the ASN.1 should look like?
4.2.7 Result for Entries that have left the result set.  There are two "An
entry SHOULD be returned as having left...." clauses.  It appears the
second one is left over from a rewrite, as it repeats information in 4.2.5.
This would make it more consistent with 4.2.6.
Done.
4.3.4/4.3.5.  I think the server should be given the option of rejecting a
LCUP search that includes virtual or collective attributes.  If a server
would normally return these attributes, it must either properly synchronize
these attributes or reject the search request.  Maybe a new
"lcupInvalidAttribute" or "unwillingToPerform" resultCode would be
appropriate.
Here is the new text of 4.3.4 and 4.3.5:

4.3.4 Operational Attributes and Administrative Entries

An operational attribute SHOULD be returned if it is specified in the attributes list and would normally be returned as subject to the constraints of [RFC2251 Section 4.5].  If the server does not support syncing of operational attributes, the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform.

LDAP Subentries [SUBENTRY] SHOULD be returned if they would normally be returned by the search request.  If the server does not support syncing of LDAP Subentries, and the server can determine from the search request that the client has requested LDAP Subentries to be returned (e.g. search control or search filter), the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform.  Otherwise, the server MAY simply omit returning LDAP Subentries.

4.3.5 Virtual Attributes 

An entry may have attributes whose presence in the entry, or presence of values of the attribute, is generated on the fly, possibly by some mechanism outside of the entry, elsewhere in the DIT.  An example of this is collective attributes [COLLECTIVE].  These attributes shall be referred to in this document as virtual attributes.

LCUP treats these attributes the same way as normal, non-virtual attributes.  A virtual attribute SHOULD be returned if it is specified in the attributes list and would normally be returned as subject to the constraints of [RFC2251 Section 4.5].  If the server does not support syncing of virtual attributes, the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform. 

One consequence of this is that if you change the definition of a virtual attribute such that it makes the value of that attribute change in many entries in the client's search scope, this means that a server may have to return many entries to the client as a result of that one change.  It is not anticipated that this will be a frequent occurrence, and the server has the option to simply force the client to resync if necessary.

It is also possible that a future LDAP control will allow the client to request only virtual or only non-virtual attributes.

4.4.1 Server Initiated Termination.  This para references a
lcupClientDisconnected resultCode.  I didn't see that resultCode defined.
Changed to "canceled [CANCEL]".
4.5  <What to do about this section????>  This can probably be deleted,
though it might be helpful earlier to explain what the synchronize and
persist phases do and the sequence of requests/controls.
I would like to get rid of this, or at least not require this section for Last Call.
John  McMeeking
--------------050800030305040404000603-- --------------ms090704080600070900010408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL6zCC A9YwggM/oAMCAQICBAIAAeYwDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UEBhMCVVMxGDAWBgNV BAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdDAeFw0w MTA2MDExMjQ3MDBaFw0wNDA2MDEyMzU5MDBaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMC Q0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIElu YzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlm aWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDi718sdkOJSxpf s+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SIiGne/YNX4KMRGRGq1ty877PSFS5Uxm58 v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhClvMGk0XhMBuVkQfwFJWMm6+8Mx25UoYzO VFe2H5LashJLjQIDAQABo4IBgjCCAX4wTQYDVR0fBEYwRDBCoECgPoY8aHR0cDovL3d3dzEu dXMtaG9zdGluZy5iYWx0aW1vcmUuY29tL2NnaS1iaW4vQ1JML0dURVJvb3QuY2dpMB0GA1Ud DgQWBBQp27Itg35/iyO7wsxmuTnoKfMChjBmBgNVHSAEXzBdMEYGCiqGSIb4YwECAQUwODA2 BggrBgEFBQcCARYqaHR0cDovL3d3dy5iYWx0aW1vcmUuY29tL0NQUy9PbW5pUm9vdC5odG1s MBMGAyoDBDAMMAoGCCsGAQUFBwIBMFgGA1UdIwRRME+hSaRHMEUxCzAJBgNVBAYTAlVTMRgw FgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJlclRydXN0IFJvb3SC AgGjMCsGA1UdEAQkMCKADzIwMDEwNjAxMTI0NzMwWoEPMjAwMzA5MDEyMzU5MDBaMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMA0GCSqGSIb3DQEBBQUAA4GBAEpiDtn6RncE CmwN3f7SIjmZEAquiC2GPVeE5hIkN2n7WV7iEbD5n6RXhoppHwZj0X3uMzZJECAPH5cXLCds PWw5BHviReiHG1S2YEFtHa4F8535OjSa43trTHH466grg7A1kEwZaHHt8GMiXsJb7CB6tbBR c+kH7oFndnlT95XUMIIEBDCCA22gAwIBAgICb4cwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMS QW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQD Ex5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDMwNzE3MTI0MjU4WhcNMDQw MTEzMTI0MjU4WjB9MQswCQYDVQQGEwJVUzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5j MRUwEwYKCZImiZPyLGQBARMFcmljaG0xITAfBgkqhkiG9w0BCQEWEnJpY2htQG5ldHNjYXBl LmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5zb24wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAM0xzJVFg2ipLH24lRTenspJ6r43StzZDCOzysfywnc6TkwnkHI2ZXJ/2NUa5nfUMVL0 wrajB6evmyIb5Q81HC3IqHB7ltCQcU+jwTgl5QvhdGj5FTGYTV6SxyLrWfTXsFObq9oONdwl +egskUTRKY/DqzfooL1oaLfdreKcBmvBAgMBAAGjggF6MIIBdjAOBgNVHQ8BAf8EBAMCBSAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGCWCGSAGG+EIBDQQ2FjRJc3N1ZWQg YnkgTmV0c2NhcGUgQ2VydGlmaWNhdGUgTWFuYWdlbWVudCBTeXN0ZW0gNC41MIGbBgNVHREE gZMwgZCBEnJpY2htQG5ldHNjYXBlLmNvbYEOcmljaG1AbWNvbS5jb22BF3JpY2hfbWVnZ2lu c29uQG1jb20uY29tgRtyaWNoX21lZ2dpbnNvbkBuZXRzY2FwZS5jb22BG3JtZWdnaW5zb24w MjI0QG5ldHNjYXBlLmNvbYEXcm1lZ2dpbnNvbjAyMjRAbWNvbS5jb20wHwYDVR0jBBgwFoAU KduyLYN+f4sju8LMZrk56CnzAoYwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVodHRw Oi8vY2VydGlmaWNhdGVzLm5ldHNjYXBlLmNvbS9vY3NwMA0GCSqGSIb3DQEBBQUAA4GBAH1a Cx0wGJLNPmAQp2GaSV+ICOvOn2capnZr5q1h63Wm+NS4lVK7liHoXjxbDNLPTcXmzUVXmcpg gP5yT25Pueb/rUoVR4UOOt9MUf0vAOqR849VYzRSvLtks1oI3e51S0EgM20f7FwF1ec1a7Fa buMyteo6vMEZlet5mCWVO1o+MIIEBTCCA26gAwIBAgICb4gwDQYJKoZIhvcNAQEEBQAwgZMx CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkG A1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScw JQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDMwNzE3MTI0MjU4 WhcNMDQwMTEzMTI0MjU4WjB9MQswCQYDVQQGEwJVUzEbMBkGA1UEChMSQW1lcmljYSBPbmxp bmUgSW5jMRUwEwYKCZImiZPyLGQBARMFcmljaG0xITAfBgkqhkiG9w0BCQEWEnJpY2htQG5l dHNjYXBlLmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5zb24wgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAMxIyDbN22w/X3RLlXYEzqbSJtCxFwKBdAAyTIyasbUm4TnKdjpUfcf0cUN/ eD/zuItQ8wYqOosRQwXqKd6BtS/AL6kSjBDQhizXCzLbhoL4dWF4inxYgX3S26RenSGm+PZM uU93PvmosYjcwwSawd4cYyOS/bwydDR44l5zm4i9AgMBAAGjggF7MIIBdzAPBgNVHQ8BAf8E BQMDB4AAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBglghkgBhvhCAQ0ENhY0 SXNzdWVkIGJ5IE5ldHNjYXBlIENlcnRpZmljYXRlIE1hbmFnZW1lbnQgU3lzdGVtIDQuNTCB mwYDVR0RBIGTMIGQgRJyaWNobUBuZXRzY2FwZS5jb22BDnJpY2htQG1jb20uY29tgRdyaWNo X21lZ2dpbnNvbkBtY29tLmNvbYEbcmljaF9tZWdnaW5zb25AbmV0c2NhcGUuY29tgRtybWVn Z2luc29uMDIyNEBuZXRzY2FwZS5jb22BF3JtZWdnaW5zb24wMjI0QG1jb20uY29tMB8GA1Ud IwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcw AYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDANBgkqhkiG9w0BAQQF AAOBgQCs46Yi7zWvrRr02pvEVb5SRaOmYgUsydv4aUPQlHO3rx3e2e9Uc0rV1l0JNfcRGhGW Kwt/RjbbXDVwEf7Fzi0eRyRuV+ffKHzkDcvE+AN8CldvociUFH3nJXGtAIIdbKOmCMkPkK8b HXZ1M4+H8aCBQLriyq/b99gK11VeeFcifjGCA1QwggNQAgEBMIGaMIGTMQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJp Y2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50 cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJviDAJBgUrDgMCGgUAoIICDzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA3MjMyMDI5MTBaMCMGCSqG SIb3DQEJBDEWBBTMulBCgZS/NMaXtG1QO0FM78bq3jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCBqwYJKwYBBAGCNxAEMYGdMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMC Q0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIElu YzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AgJvhzCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAm+HMA0GCSqGSIb3DQEBAQUABIGAGtaD PUEaQpN9BpxRVSJdxRRhMOqvz9NQWa2HuW8mBlfFZf0xyN0JTm83VEEL9LzUkRzpCviOufuV crmVfzSkKQDE3dbQ2HQNg1tMPJMYcTZ8jruDXcMoDnbHBN8LD6fOTWzTi28mStQEqur6pr2D YSCJCffNtB01nVNMaHbitUwAAAAAAAA= --------------ms090704080600070900010408-- From owner-ietf-ldup@mail.imc.org Wed Jul 23 16:40:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01814 for ; Wed, 23 Jul 2003 16:40:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NKWlqt068813 for ; Wed, 23 Jul 2003 13:32:47 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NKWlF7068812 for ietf-ldup-bks; Wed, 23 Jul 2003 13:32:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NKWkqt068801 for ; Wed, 23 Jul 2003 13:32:46 -0700 (PDT) (envelope-from richm@netscape.com) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h6NKWai11213 for ; Wed, 23 Jul 2003 13:32:36 -0700 (PDT) Received: from netscape.com ([10.178.168.3]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HIHVQG00.28O; Wed, 23 Jul 2003 13:32:40 -0700 Message-ID: <3F1EF0BA.5040601@netscape.com> Date: Wed, 23 Jul 2003 14:31:54 -0600 From: richm@netscape.com (Rich Megginson) Reply-To: rmegginson0224@aol.com Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark C Smith CC: John McMeeking , Richard V Huber , ietf-ldup@imc.org Subject: Re: LCUP Comment/Question References: <3F01EED6.6080701@netscape.com> In-Reply-To: <3F01EED6.6080701@netscape.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000105030700040509070308" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000105030700040509070308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mark C Smith wrote: > > John McMeeking wrote: > >> ... Maybe some words like: >> >> Use of an LCUP cookie with multiple DSAs in a replicated environment >> is not >> defined by LCUP. An implementation of LCUP may support continuation >> of a >> LCUP session with another DSA holding a replica of the LCUP context. In >> such cases, the implementation should document the LCUP Scheme used. In >> the absence of knowledge about such support the client should not use a >> LCUP cookie with any DSA other than the DSA which issued the original >> cookie. > I think this text should be sufficient. >> Or something that conveys the notion that it isn't defined by LCUP, but >> isn't prohibited. And leave the door open for vendors (or later >> standards) >> to address this. And the "document the scheme" part needn't involve >> defining an OID and having the client request that format. I'd hope >> that >> an implementation of LCUP in an replicated environment would support >> this >> with its default LCUP scheme. > > > My too. I thought we discussed this before... LCUP needs to allow > implementations to support using the same cookie with different > replicas, and needs to gracefully handle the case where an > implementation does not support it. For example, if a server does not > recognize the cookie or can't use the information contained in it, it > may force a full refresh... but that decision is in the hands of the > server. I do not think there is any need for the implementation to > document the cookie scheme or for the client to be careful in this > case... what am I missing? Server implementations must be able to > recognize whether a cookie presented by a client is one they sent or a > compatible cookie (e.g., one sent by a replica). > --------------ms000105030700040509070308 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL6zCC A9YwggM/oAMCAQICBAIAAeYwDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UEBhMCVVMxGDAWBgNV BAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdDAeFw0w MTA2MDExMjQ3MDBaFw0wNDA2MDEyMzU5MDBaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMC Q0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIElu YzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlm aWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDi718sdkOJSxpf s+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SIiGne/YNX4KMRGRGq1ty877PSFS5Uxm58 v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhClvMGk0XhMBuVkQfwFJWMm6+8Mx25UoYzO VFe2H5LashJLjQIDAQABo4IBgjCCAX4wTQYDVR0fBEYwRDBCoECgPoY8aHR0cDovL3d3dzEu dXMtaG9zdGluZy5iYWx0aW1vcmUuY29tL2NnaS1iaW4vQ1JML0dURVJvb3QuY2dpMB0GA1Ud DgQWBBQp27Itg35/iyO7wsxmuTnoKfMChjBmBgNVHSAEXzBdMEYGCiqGSIb4YwECAQUwODA2 BggrBgEFBQcCARYqaHR0cDovL3d3dy5iYWx0aW1vcmUuY29tL0NQUy9PbW5pUm9vdC5odG1s MBMGAyoDBDAMMAoGCCsGAQUFBwIBMFgGA1UdIwRRME+hSaRHMEUxCzAJBgNVBAYTAlVTMRgw FgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJlclRydXN0IFJvb3SC AgGjMCsGA1UdEAQkMCKADzIwMDEwNjAxMTI0NzMwWoEPMjAwMzA5MDEyMzU5MDBaMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMA0GCSqGSIb3DQEBBQUAA4GBAEpiDtn6RncE CmwN3f7SIjmZEAquiC2GPVeE5hIkN2n7WV7iEbD5n6RXhoppHwZj0X3uMzZJECAPH5cXLCds PWw5BHviReiHG1S2YEFtHa4F8535OjSa43trTHH466grg7A1kEwZaHHt8GMiXsJb7CB6tbBR c+kH7oFndnlT95XUMIIEBDCCA22gAwIBAgICb4cwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMS QW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQD Ex5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDMwNzE3MTI0MjU4WhcNMDQw MTEzMTI0MjU4WjB9MQswCQYDVQQGEwJVUzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5j MRUwEwYKCZImiZPyLGQBARMFcmljaG0xITAfBgkqhkiG9w0BCQEWEnJpY2htQG5ldHNjYXBl LmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5zb24wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAM0xzJVFg2ipLH24lRTenspJ6r43StzZDCOzysfywnc6TkwnkHI2ZXJ/2NUa5nfUMVL0 wrajB6evmyIb5Q81HC3IqHB7ltCQcU+jwTgl5QvhdGj5FTGYTV6SxyLrWfTXsFObq9oONdwl +egskUTRKY/DqzfooL1oaLfdreKcBmvBAgMBAAGjggF6MIIBdjAOBgNVHQ8BAf8EBAMCBSAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGCWCGSAGG+EIBDQQ2FjRJc3N1ZWQg YnkgTmV0c2NhcGUgQ2VydGlmaWNhdGUgTWFuYWdlbWVudCBTeXN0ZW0gNC41MIGbBgNVHREE gZMwgZCBEnJpY2htQG5ldHNjYXBlLmNvbYEOcmljaG1AbWNvbS5jb22BF3JpY2hfbWVnZ2lu c29uQG1jb20uY29tgRtyaWNoX21lZ2dpbnNvbkBuZXRzY2FwZS5jb22BG3JtZWdnaW5zb24w MjI0QG5ldHNjYXBlLmNvbYEXcm1lZ2dpbnNvbjAyMjRAbWNvbS5jb20wHwYDVR0jBBgwFoAU KduyLYN+f4sju8LMZrk56CnzAoYwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVodHRw Oi8vY2VydGlmaWNhdGVzLm5ldHNjYXBlLmNvbS9vY3NwMA0GCSqGSIb3DQEBBQUAA4GBAH1a Cx0wGJLNPmAQp2GaSV+ICOvOn2capnZr5q1h63Wm+NS4lVK7liHoXjxbDNLPTcXmzUVXmcpg gP5yT25Pueb/rUoVR4UOOt9MUf0vAOqR849VYzRSvLtks1oI3e51S0EgM20f7FwF1ec1a7Fa buMyteo6vMEZlet5mCWVO1o+MIIEBTCCA26gAwIBAgICb4gwDQYJKoZIhvcNAQEEBQAwgZMx CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkG A1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScw JQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDMwNzE3MTI0MjU4 WhcNMDQwMTEzMTI0MjU4WjB9MQswCQYDVQQGEwJVUzEbMBkGA1UEChMSQW1lcmljYSBPbmxp bmUgSW5jMRUwEwYKCZImiZPyLGQBARMFcmljaG0xITAfBgkqhkiG9w0BCQEWEnJpY2htQG5l dHNjYXBlLmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5zb24wgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAMxIyDbN22w/X3RLlXYEzqbSJtCxFwKBdAAyTIyasbUm4TnKdjpUfcf0cUN/ eD/zuItQ8wYqOosRQwXqKd6BtS/AL6kSjBDQhizXCzLbhoL4dWF4inxYgX3S26RenSGm+PZM uU93PvmosYjcwwSawd4cYyOS/bwydDR44l5zm4i9AgMBAAGjggF7MIIBdzAPBgNVHQ8BAf8E BQMDB4AAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBglghkgBhvhCAQ0ENhY0 SXNzdWVkIGJ5IE5ldHNjYXBlIENlcnRpZmljYXRlIE1hbmFnZW1lbnQgU3lzdGVtIDQuNTCB mwYDVR0RBIGTMIGQgRJyaWNobUBuZXRzY2FwZS5jb22BDnJpY2htQG1jb20uY29tgRdyaWNo X21lZ2dpbnNvbkBtY29tLmNvbYEbcmljaF9tZWdnaW5zb25AbmV0c2NhcGUuY29tgRtybWVn Z2luc29uMDIyNEBuZXRzY2FwZS5jb22BF3JtZWdnaW5zb24wMjI0QG1jb20uY29tMB8GA1Ud IwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcw AYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDANBgkqhkiG9w0BAQQF AAOBgQCs46Yi7zWvrRr02pvEVb5SRaOmYgUsydv4aUPQlHO3rx3e2e9Uc0rV1l0JNfcRGhGW Kwt/RjbbXDVwEf7Fzi0eRyRuV+ffKHzkDcvE+AN8CldvociUFH3nJXGtAIIdbKOmCMkPkK8b HXZ1M4+H8aCBQLriyq/b99gK11VeeFcifjGCA1QwggNQAgEBMIGaMIGTMQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJp Y2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50 cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJviDAJBgUrDgMCGgUAoIICDzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA3MjMyMDMxNTRaMCMGCSqG SIb3DQEJBDEWBBRm0RJfg3K8AzIESmhRM1VLZfigMDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCBqwYJKwYBBAGCNxAEMYGdMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMC Q0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIElu YzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AgJvhzCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAm+HMA0GCSqGSIb3DQEBAQUABIGAkZYk ANxMtOcP6ZFpvk0JPvuCiLI20mX2XSTLpA5CLGhxDxKkFXgl3QTTqE8bnVO5b3fsB4zO3fvC s/RubTa+r5H/N0BFy7SMJ7WPqlqe2mOlDIMSlLdo/s2w3UMo86xpTvrDLTJiH2tLGhdM/h03 9plswUZ4vHncQM4pOpAXL4cAAAAAAAA= --------------ms000105030700040509070308--