From ldapext-bounces@ietf.org Fri Nov 04 16:10:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY8pF-0004GH-4k; Fri, 04 Nov 2005 16:10:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY8pC-0004GC-6N for ldapext@megatron.ietf.org; Fri, 04 Nov 2005 16:10:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14080 for ; Fri, 4 Nov 2005 16:09:50 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY94E-0002ia-8O for ldapext@ietf.org; Fri, 04 Nov 2005 16:25:48 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id jA4L9d22021141 for ; Fri, 4 Nov 2005 15:09:40 -0600 Message-ID: <436BCE24.2070304@highlandsun.com> Date: Fri, 04 Nov 2005 13:09:56 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051027 SeaMonkey/1.1a MIME-Version: 1.0 To: Ldapext Subject: Re: [ldapext] Re: I-D ACTION:draft-sermersheim-ldap-csn-02.txt References: <43605543.1060002@eB2Bcom.com> In-Reply-To: <43605543.1060002@eB2Bcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org A couple of concerns were raised about using fractional seconds in the timestamp portion of the CSN. Mainly, that they do not always increase monotonically; some systems will decrement while adjusting the clock (e.g. using NTP?). The draft-ietf-ldup-model document specifically excluded fractional seconds; I think we need to continue with that restriction here. Also wrt timestamps, expressing an implementation preference: I would like to see the timestamps restricted to UTC. As I see it, use of local time is really an issue of user-friendliness. As such, it's a matter for clients and user interfaces to deal with, not servers. And storing local time in the server is no friendlier if the client is querying from a remote timezone. I.e., the client must always be prepared to translate the server's timestamp into its localtime regardless, so storing localtime in the server doesn't save anything. It actually makes it harder for clients that are searching for CSNs greater than a specific time. Even if the server is "consistent" in its use of localtime - e.g., we just changed off of Daylight Savings Time, so there's an hour's worth of timestamps that overlap each other except for their offset. In this case, it's more developer-friendly to use UTC consistently. > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : The LDAP Change Sequence Number >> Author(s) : H. Chu, J. Sermersheim >> Filename : draft-sermersheim-ldap-csn-02.txt >> Pages : 16 >> Date : 2005-10-26 >> >> This document defines a syntax schema element for the Lightweight >> Directory Access Protocol ([LDAP]) which is used to hold a Change >> Sequence Number (CSN). In general, a change sequence number >> represents the place and time that a directory entity was changed. It >> may be used by various attributes for various LDAP replication, and >> synchronization applications. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-csn-02.txt -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Nov 04 16:23:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY91n-0006dA-Q1; Fri, 04 Nov 2005 16:23:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY91l-0006d5-R8 for ldapext@megatron.ietf.org; Fri, 04 Nov 2005 16:23:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14622 for ; Fri, 4 Nov 2005 16:22:50 -0500 (EST) Received: from mlnya405er.ml.com ([199.43.38.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY9Gn-00032o-6E for ldapext@ietf.org; Fri, 04 Nov 2005 16:38:48 -0500 Received: from MLNYA355BH.amrs.win.ml.com (unknown [146.125.98.5]) by mlnya405er.ml.com (Postfix) with ESMTP id 87D9B120004A9; Fri, 4 Nov 2005 16:22:49 -0500 (EST) Importance: normal Priority: normal Received: from mlnyb801bh.amrs.win.ml.com ([146.125.97.60]) by MLNYA355BH.amrs.win.ml.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 4 Nov 2005 16:22:49 -0500 Received: from mlnyb707mb.amrs.win.ml.com ([146.125.97.15]) by mlnyb801bh.amrs.win.ml.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 4 Nov 2005 16:22:48 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Re: I-D ACTION:draft-sermersheim-ldap-csn-02.txt Date: Fri, 4 Nov 2005 16:22:48 -0500 Message-ID: <36D738A911A2814EA3DC134DAA5091A81566FF51@cicgt098x.pc.ml.com> Thread-Topic: [ldapext] Re: I-D ACTION:draft-sermersheim-ldap-csn-02.txt thread-index: AcXhhFqZrhtKZVXfRMmpGh84Pv0d8AAAUpcA From: "Liben, Michael (GTI)" To: "Howard Chu" , "Ldapext" X-OriginalArrivalTime: 04 Nov 2005 21:22:48.0985 (UTC) FILETIME=[E80AD090:01C5E185] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Not sure you can restrict to UTC owing to legacy. However, I'm sure the spec can strongly recommend using only UTC (e.g., SHOULD use UTC, SHOULD NOT use local time) -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org] On Behalf Of Howard Chu Sent: Friday, November 04, 2005 4:10 PM To: Ldapext Subject: Re: [ldapext] Re: I-D ACTION:draft-sermersheim-ldap-csn-02.txt A couple of concerns were raised about using fractional seconds in the=20 timestamp portion of the CSN. Mainly, that they do not always increase=20 monotonically; some systems will decrement while adjusting the clock=20 (e.g. using NTP?). The draft-ietf-ldup-model document specifically=20 excluded fractional seconds; I think we need to continue with that=20 restriction here. Also wrt timestamps, expressing an implementation preference: I would=20 like to see the timestamps restricted to UTC. As I see it, use of local=20 time is really an issue of user-friendliness. As such, it's a matter for clients and user interfaces to deal with, not servers. And storing local time in the server is no friendlier if the client is querying from a=20 remote timezone. I.e., the client must always be prepared to translate=20 the server's timestamp into its localtime regardless, so storing=20 localtime in the server doesn't save anything. It actually makes it=20 harder for clients that are searching for CSNs greater than a specific=20 time. Even if the server is "consistent" in its use of localtime - e.g., we just changed off of Daylight Savings Time, so there's an hour's worth of timestamps that overlap each other except for their offset. In this=20 case, it's more developer-friendly to use UTC consistently. > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : The LDAP Change Sequence Number >> Author(s) : H. Chu, J. Sermersheim >> Filename : draft-sermersheim-ldap-csn-02.txt >> Pages : 16 >> Date : 2005-10-26 >> =09 >> This document defines a syntax schema element for the Lightweight=20 >> Directory Access Protocol ([LDAP]) which is used to hold a Change=20 >> Sequence Number (CSN). In general, a change sequence number=20 >> represents the place and time that a directory entity was changed. It >> may be used by various attributes for various LDAP replication, and=20 >> synchronization applications. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-csn-02.txt --=20 -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the = sender, delete it and do not read, act upon, print, disclose, copy, = retain or redistribute it. Click here for important additional terms = relating to this e-mail. http://www.ml.com/email_terms/ -------------------------------------------------------- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun Nov 06 21:12:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYwUK-00072I-83; Sun, 06 Nov 2005 21:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYwUI-000724-GO; Sun, 06 Nov 2005 21:11:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05275; Sun, 6 Nov 2005 21:11:30 -0500 (EST) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYwjk-0003b1-Lf; Sun, 06 Nov 2005 21:27:58 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jA72BjiN023091; Sun, 6 Nov 2005 21:11:45 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jA72Bi4A105116; Sun, 6 Nov 2005 21:11:44 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jA72BiqU032238; Sun, 6 Nov 2005 21:11:44 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jA72BieS032231; Sun, 6 Nov 2005 21:11:44 -0500 In-Reply-To: <436BCE24.2070304@highlandsun.com> Subject: Re: [ldapext] Re: I-D ACTION:draft-sermersheim-ldap-csn-02.txt To: Howard Chu X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: John McMeeking Date: Sun, 6 Nov 2005 20:11:42 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 7.0|August 18, 2005) at 11/06/2005 08:11:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ldapext-bounces@ietf.org, Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Howard Chu wrote on 11/04/2005 03:09:56 PM: > A couple of concerns were raised about using fractional seconds in the > timestamp portion of the CSN. Mainly, that they do not always increase > monotonically; some systems will decrement while adjusting the clock > (e.g. using NTP?). The draft-ietf-ldup-model document specifically > excluded fractional seconds; I think we need to continue with that > restriction here. Is eliminating fractional seconds from the CSN the way to address the problem of decreasing CSNs? Would it be more appropriate to require that any CSN generator generate strictly increasing sequences of CSNs with respect to the time and timeCount components? I believe there is a similar requirement for the DCE UUID time-based variants. On that note, this document doesn't say much about the use or behavior of the timeCount field, though some use is implied by the ordering rule. John McMeeking _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Nov 07 00:51:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYzuU-0005rm-3C; Mon, 07 Nov 2005 00:51:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYzuP-0005rd-KQ; Mon, 07 Nov 2005 00:51:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15786; Mon, 7 Nov 2005 00:50:43 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ09w-0000K3-Cy; Mon, 07 Nov 2005 01:07:13 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id jA75owkT020262; Sun, 6 Nov 2005 23:50:58 -0600 Message-ID: <436EEB44.9010705@highlandsun.com> Date: Sun, 06 Nov 2005 21:51:00 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051027 SeaMonkey/1.1a MIME-Version: 1.0 To: John McMeeking Subject: Re: [ldapext] Re: I-D ACTION:draft-sermersheim-ldap-csn-02.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ldapext-bounces@ietf.org, Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org John McMeeking wrote: > Howard Chu wrote on 11/04/2005 03:09:56 PM: > >> A couple of concerns were raised about using fractional seconds in the >> timestamp portion of the CSN. Mainly, that they do not always increase >> monotonically; some systems will decrement while adjusting the clock >> (e.g. using NTP?). The draft-ietf-ldup-model document specifically >> excluded fractional seconds; I think we need to continue with that >> restriction here. > > Is eliminating fractional seconds from the CSN the way to address the > problem of decreasing CSNs? Would it be more appropriate to require that > any CSN generator generate strictly increasing sequences of CSNs with > respect to the time and timeCount components? I believe there is a similar > requirement for the DCE UUID time-based variants. Yes, we probably need an explicit statement to this effect, since that is the actual concern. Eliminating fractional seconds helps simplify conformance to this requirement, otherwise there is no bound on the resolution necessary to meet the requirement. > On that note, this document doesn't say much about the use or behavior of > the timeCount field, though some use is implied by the ordering rule. Yes, I suggested to Jim that we should provide examples / use cases for these fields but there wasn't time to get those in. > > John McMeeking -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext