Hi Erik, This problem is complex. Since ASN.1 encoding rules provide compatibility between different versions, a new OID is not needed. In that case a read operation will give all the components known by the DSA which has retrieved the data from the Directory and also known by the DUA. In a modify operation only the components known by the DUA and the DSA master of the naming context will be taken in consideration. But the DUA cannot be sure that all requested changes have been applied. Using a new OID for a new version of the syntax can solve this problem and also the problem with LDAP using ABNF. But it that case a DUA have to know the version used by the DSA and in a Directory System all the DSAs can use different versions of a same attribute. This also adds complexity in distribution and replication. Regards Jean-Paul. De : Erik Andersen [mailto:era@xxxxxxx] Envoyé : samedi 17 décembre 2011 10:16 À : Directory list; SG17-Q11 Objet : [T17Q11] Extension markers for attribute syntaxes I am getting concerned about extension markers in syntax data types. When an attribute syntax is changed, the attribute type should have a new OID. In addition, LDAP uses Augmented Backus-Naur Form (ABNF) for defining attribute syntaxes, except for X.509 ones, where a binary encoding is used. ABNF does not allow for extension markers. Adding new components to an X.500 attribute syntax will cause discrepancy between the X.500 variant and the LDAP variant. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@xxxxxxx Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ <http://dk.linkedin.com/in/andersenerik> http://dk.linkedin.com/in/andersenerik