Reply to Reply to still on omittedORAddressComponent

[Kevin Jordan <[e-mail]>]

> P.S.  The OID for at-associated-or-addr has changed from previous
> versions (was at 1 now at 6) presumably because its changed syntax
> from mhs-or-address to distinguished name,
> 
> Why then couldn't the oids oc-rfc822-to-x400-mapping and
> oc_x400-to-rfc822-mapping be changed ?
> The object classes they represent have changed with the dropping of
> the nonAuthoritativeAssociatedORAddress and
> nonAuthoritativeAssociatedDomain attributes and with the change in the
> syntax and OID of the associatedORAddress attribute. 
> 
> This make it a pain to upgrade. Every DSA that has a definition of the
> object classes has to be changed to show the new one. You can't run
> the two concurrently, as they have the same OID. 

Since the OID of associatedORAddress has changed, it is therefore a new
attribute.  So, the object class lost one old attribute and gained a new
one.  We accommodated this in our implementation by updating the object
class definition simply to include the new associatedORAddress attribute.
To avoid the external name conflict, we actually named this
associatedX400Address.  This allows the implementation to be backward
compatible with its older revisions, and it also allows it to interoperate
with up-to-date revisions.  It can also receive slave updates from up-to-date
implementations, and it can send slave updates as long as the replicates
don't include obsolete attributes.  As there really wasn't any mapping
information in the Open Tree previously, this isn't much of an issue.

Now that the documents are RFC's, any future revisions to object class and
attribute definitions absolutely must be accomplished by assigning new OID's
instead of "recycling" existing ones.