directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject [index review]About EntryCSN, EntryUUID and IANA registration
Date Sat, 16 May 2009 09:31:41 GMT
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-parameters ) :

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-chu-ldap-csn-xx.txt and 
https://opends.dev.java.net/public/standards/draft-sermersheim-ldap-csn.txt) 
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.4203.666.html

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.html

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 ?

-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message