Reply to Reply to Ommitted components in the 1327 mapping

"Kevin E. Jordan" <Kevin.E.Jordan@cdc.com> Wed, 09 March 1994 18:14 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08565; 9 Mar 94 13:14 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08560; 9 Mar 94 13:14 EST
Received: from [129.179.91.44] by CNRI.Reston.VA.US id aa12565; 9 Mar 94 13:14 EST
Received: from mercury91.udev.cdc.com by sequoia.udev.cdc.com; Wed, 9 Mar 94 11:59:33 +0600
Received: by mercury.udev.cdc.com; Wed, 9 Mar 94 11:58:13 -0600
X-From: kej@mercury.udev.cdc.com Wed Mar 9 11:58 CST 1994
Received: from localhost by mercury.udev.cdc.com; Wed, 9 Mar 94 11:58:03 -0600
To: Michael Storz <michael.r.storz@lrz-muenchen.de>
cc: Return requested <mhs-ds@mercury.udev.cdc.com>
Subject: Reply to Reply to Ommitted components in the 1327 mapping
In-reply-to: Your message of "09 Mar 94 16:10:04" <940309163958554-MTALRZVEE*/c=de/admd=d400/prmd=lrz-muenchen/o=/ou=LRZ/s=Storz/g=Michael/i=R/@MHS>
Date: Wed, 09 Mar 1994 11:58:02 -0600
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Kevin E. Jordan" <Kevin.E.Jordan@cdc.com>
Message-Id: <2d7e0e2b4ea9002@mercury.udev.cdc.com>

> This means you have to use different solutions for the two mappings and I do not
> like such a solution. The solution should be symmetrical. The only possible
> solution then is 2) using a placeholder for the null value. I agree using a
> string as placeholder which could be a valid value is not a very elegant
> solution, but at least it is symmetrical.
> 
> Taking Haralds new information into account, that CCITT ruled empty
> organizations as illegal, then we can at least choose a value which is not
> valid for PRMD, because PRMD does not allow T.61 (for example a value with '$').
> This could be used for empty organizations too. This would help all the
> people which unfortunately have an empty organization like all the german
> universities. If an organization would exist where the value indeed is the
> string we choose, then all the organizations with an empty value would have a
> problem but this does not matter because it is not allowed to have such a value
> and therefore they should change their naming :-) But in the meantime we could
> register the mappings in a routing tree untill such a transition to non-empty
> values has ended.

The solution proposed by Steve is a good one.  It is clean, it is consistent
with RFC1327, and it is straightforward to implement.  I think that we
should accept this solution for the X.400->RFC822 direction of mapping.

Mapping from RFC822 to X.400 is a different kind of process.  It is not a
requirement that the data which drive the process be symmetrical to the 
data which drive the X.400 to RFC822 process.  The principal requirement is
that the mappings be reversible.

A good X.400 to RFC822 mapping proposal has been made.  Now, let's find and
agree upon a good RFC822 to X.400 proposal.  These need not be symmetrical.
They need only to generate reversible mappings which are consistent with
RFC1327.