Emmanuel Lecharny wrote:
> Hi,
>
> currently, for replication, we are using a CSN built from
> http://tools.ietf.org/html/draft-sermersheim-ldap-csn-02 (more or less).
> In fact, our CSN is a composition of a timestamp
> (System.currentMillis()), an operation operationSequence and a
> replicaId. It is constructed this way :
>
> timestamp:replicaId:operationSequence (no padding)
>
>
> It's not what OpenLDAP is using. OpenLDAP is based on
> http://tools.ietf.org/html/draft-ietf-ldup-model-09, and a CSN is
> constructed this way :
>
> " ...
>   * The format of a CSN string is: yyyymmddhhmmssz#s#r#c
>   * where s is a counter of operations within a timeslice, r is
>   * the replica id (normally zero), and c is a counter of
>   * modifications within this operation.  s, r, and c are
>   * represented in hex and zero padded to lengths of 6, 3, and
>   * 6, respectively. (In previous implementations r was only 2 digits.)
>   ...
> "
>
> So far, both CSN are incompatible. We could write translators, but I
> also think that it would be great to avoid having a different structure.
>
> Does it makes sense to you ?
>
Hm, I was co-authoring an update of Jim Sermersheim's draft, to standardize on 
the OpenLDAP format. We never published it, I guess that may be my fault. But 
I expect that the OpenLDAP format is the one that will progress to the IETF, 
so obviously I recommend sticking with that.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/