[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] Re: I-D ACTION:draft-sermersheim-ldap-csn-02.txt
- To: "Howard Chu" <hyc@highlandsun.com>, "Ldapext" <ldapext@ietf.org>
- Subject: RE: [ldapext] Re: I-D ACTION:draft-sermersheim-ldap-csn-02.txt
- From: "Liben, Michael (GTI)" <michael_liben@ml.com>
- Date: Fri, 4 Nov 2005 16:22:48 -0500
- Cc:
- Content-class: urn:content-classes:message
- Importance: normal
- Thread-index: AcXhhFqZrhtKZVXfRMmpGh84Pv0d8AAAUpcA
- Thread-topic: [ldapext] Re: I-D ACTION:draft-sermersheim-ldap-csn-02.txt
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
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
--------------------------------------------------------
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