Re: Reply to still on omittedORAddressComponent

[Peter Cowen <[e-mail]>]

Okay I think I see the light a bit

Consider the mapping rules
 
O$@.PRMD$daimlerbenz.ADMD$d400.C$de#daimlerbenz.d400.de#
PRMD$daimlerbenz.ADMD$d400.C$de#org.daimlerbenz.d400.de#

If I understand correctly these will be represented by the entries in
the X.400 to RFC 822 subtree with the DNs of

oRAddressComponentType=OIDforO, PRMD=daimlerbenz, ADMD=d400, C=DE
	(will be of object class x400ToRFCMAPPING & omittedORAddressComponent
	will contain oRAddressComponentType=OIDforO (RDN)
	and associatedDomain=daimlerbenz.d400.de)

PRMD=daimlerbenz, ADMD=d400, C=DE
	(will be of object class x400ToRFCMAPPING & PRMD
	will contain prmdName=daimlerbenz (RDN)
	and associatedDomain=org.daimlerbenz.d400.de)


This (I think) then works for X400 -> 822 but the document needs to
spell out how to convert an X400 address to the DN (point 1 at the
top of page 4
"Take the O/R Address, and derive a directory name"

The derivation MUST always put in the oRAddressComponentType=OIDforXXX
where a component is missing.

And when is a component missing ?

If I have the address
/S=help/OU=help/PRMD=help/ADMD=helpfulADMD/C=WS/
Is it missing an O component ? Yes so need oRAddressComponentType=OIDforO
Is it missing an GivenName component ? Yes but not required in this
part of the rfc1327 conversion
Is it missing an X121 component ? No because its a mnenomic address
and so can not have a x121 component

NOTE that there may be multiple missing compnonents i.e.
/S=help/OU=help/ADMD=helpfulADMD/C=WS/ is a valid mnemonic address
with missing O and PRMD.

The document should have exmaple addresses with missing components and
show the DN derived from them
e.g
/S=smith/ou=abc/o=xyz/prmd=pp/admd=xx/c=ws/ dervives the following DN
S=smith, ou=abc, o=xyx, prmd=pp, admd=xx, c=ws

/S=smith/o=xyz/prmd=pp/admd=xx/c=ws/ dervives the following DN
S=smith, o=xyx, prmd=pp, admd=xx, c=ws

/S=smith/ou=abc/prmd=pp/admd=xx/c=ws/ dervives the following DN
S=smith, ou=abc, oRAddressComponentType=OIDforO, prmd=pp, admd=xx, c=ws

/S=smith/ou=abc/o=xyz/admd=xx/c=ws/ derives
S=smith, ou=abc, o=xyz, oRAddressComponentType=OIDforPRMD, admd=xx, c=ws

/S=help/OU=help/ADMD=helpfulADMD/C=WS/ derives
S=help, OU=help, oRAddressComponentType=OIDforO, oRAddressComponentType=OIDforPRMD, C=WS

In summary, the ommittedORAddressComponent class is sufficient to
support missing components when mapping from X400 to 822. However the
document leaves a lot to be inferred. A few examples would really help
clarify things

Peter

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.