About EntryCSN, EntryUUID and IANA registration

Hi guys,

while I'm trying to inject the EntryCSN and EntryUUID index into the 
server, I have some difficulties to find the correct OID for those 
elements. We currently have a schema (apache.schema) where those 
attributeType are declared :

attributetype ( 1.3.6.1.4.1.18060.0.4.1.2.29
        NAME 'entryUUID'
        DESC 'LCUP/LDUP: UUID of the entry'
        EQUALITY octetStringMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{64}
        SINGLE-VALUE
        NO-USER-MODIFICATION
        USAGE directoryOperation )

attributetype ( 1.3.6.1.4.1.18060.0.4.1.2.30
        NAME 'entryCSN'
        DESC 'LCUP/LDUP: change sequence number of the entry'
        EQUALITY octetStringMatch
        ORDERING octetStringOrderingMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{64}
        SINGLE-VALUE
        NO-USER-MODIFICATION
        USAGE directoryOperation )

However, the IANA has registred only one of those two AT, the EntryUUID 
( from http://www.iana.org/assignments/ldap-paramete... ) :

entryUUID                             A  1.3.6.1.1.16.4               [RFC4530]

This AT is described in http://www.rfc-editor.org/rfc/rfc4530.txt :

       ( 1.3.6.1.1.16.4 NAME 'entryUUID'
           DESC 'UUID of the entry'
           EQUALITY uuidMatch
           ORDERING uuidOrderingMatch
           SYNTAX 1.3.6.1.1.16.1
           SINGLE-VALUE
           NO-USER-MODIFICATION
           USAGE directoryOperation )

with the associated uuidMatch MR :
       ( 1.3.6.1.1.16.2 NAME 'uuidMatch'
           SYNTAX 1.3.6.1.1.16.1 )


and uuidOrderingMatch  :

       ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch'
           SYNTAX 1.3.6.1.1.16.1 )

So we must modify the values we have in Apache.schema, and probably move 
it to core.schema for EntryUUID.

Regarding the entryCSN, this is a different story. There is no IANA 
registration for the moment. It's described in some drafts 
(http://www.zytrax.com/books/ldap/apc/draft-ch... and 
https://opends.dev.java.net/public/standards/...) 
with different OIDS :
1.3.6.1.1.16.4 for the first draft and 1.3.6.1.1.16.7 for the second 
draft (the first OID collides with the UUID OID). At the end of the day, 
OpenLDAP has defined the EntryCSN OID using the OpenLDAP experimental 
OID arc :

http://www.alvestrand.no/objectid/1.3.6.1.4.1...

Thus the definition of EntryCSN in OpenLDAP is the following :

    ( 1.3.6.1.4.1.4203.666.1.7 NAME 'entryCSN'
         DESC 'change sequence number of the entry content'
         EQUALITY CSNMatch
         ORDERING CSNOrderingMatch
         SYNTAX 1.3.6.1.4.1.4203.666.11.2.1{64}
         SINGLE-VALUE
         NO-USER-MODIFICATION
         USAGE directoryOperation )

with

    ( 1.3.6.1.4.1.4203.666.11.2.2 NAME 'CSNMatch'
         SYNTAX 1.3.6.1.4.1.4203.666.11.2.1 )

and

    ( 1.3.6.1.4.1.4203.666.11.2.3 NAME 'CSNOrderingMatch'
         SYNTAX 1.3.6.1.4.1.4203.666.11.2.1 )

which are described in http://www.openldap.org/faq/data/cache/1145.h...

Now, what should we do ? Should we use our Apache PEN number and store 
the EntryCSN and the associated elements into it, as OpenLDAP did ? Or 
should we simply use the OpenLDAP experiment OID arc, waiting for the 
OIDs to be registred by IANA?

IMO, the second approach is probably better, as first it will ensure the 
OpenLDAP compatibility.

wdyt ?

Emmanuel Lecharny wrote:
> Now, what should we do ? Should we use our Apache PEN number and store
> the EntryCSN and the associated elements into it, as OpenLDAP did ? Or
> should we simply use the OpenLDAP experiment OID arc, waiting for the
> OIDs to be registred by IANA?
> 
> IMO, the second approach is probably better, as first it will ensure the
> OpenLDAP compatibility.
> 
> wdyt ?
I also think it makes sense to reuse the OpenLDAP OIDs.

Kind Regards,
Stefan

On Sat, May 16, 2009 at 12:54 PM, Stefan Seelmann wrote:

> Emmanuel Lecharny wrote:
> > Now, what should we do ? Should we use our Apache PEN number and store
> > the EntryCSN and the associated elements into it, as OpenLDAP did ? Or
> > should we simply use the OpenLDAP experiment OID arc, waiting for the
> > OIDs to be registred by IANA?
> >
> > IMO, the second approach is probably better, as first it will ensure the
> > OpenLDAP compatibility.
> >
> > wdyt ?
>
> I also think it makes sense to reuse the OpenLDAP OIDs.
>
I agree as well and as you say it ensures OpenLDAP compat.