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.
- Reply to Ommitted components in the 1327 mapping Michael Storz
- Reply to Reply to Ommitted components in the 1327… Kevin E. Jordan