Robert.Ullmann@en-c06.x400.prime.COM (07/17/89)
[this message is not "private", the "sensitivity" field
non-withstanding; the X.400 MUA here doesn't seem to believe that
sensitivity is supposed to be optional ...]
Hi,
The following is the almost-final draft of an RFC describing an
algorithmic mapping between the X.400 and internet address space.
This is intended to replace the magic tables of RFC 987, which have
been found to be unworkable in the real world: messages will transit
multiple gates, replies will transit gates other than those the
original message passed through, and the users *must* see a uniform
address space, regardless of the point of view.
Even with multiple transits of the same gate, the table method does not
work unless the table is entirely static: users will reply to messages
that are months (or years) old, and expect it to work (provided that
the remote address has not changed, of course!).
Users have a very simple definition of a working mailer: if "reply"
doesn't work, the mail system is broken. Full Stop.
The administrative problems of using the same table(s) on each of the
gates are (I believe) impossible to resolve; there will be on the order
of 10s of thousands of entries, and many 10s of thousands of gates.
(Prime Computer alone would require 28 entries minimum; and we expect to
have 350+ gateways by 1992).
The problem is not one of transition; it is one of co-existance: both
Internet and X.400 mail protocols will be used over a very wide range
of systems and domains for at least a decade into the future.
The solutions must then be real solutions, workable in a production,
commercial environment. A "transistion hack" is simply not acceptable.
I have explosion-proofed my mailbox ...
Best Regards,
Robert Ullmann
Prime Computer, Inc.
Network Working Group R. Ullmann
Request for Comments: (tba) Prime Computer, Inc.
July 1989
Mapping between Internet and X.400 addresses
1. Status of this memo
This memo proposes a standard for the address translation at gateways
between X.400 systems and Internet mail systems.
Distribution of this memo is unlimited.
2. Table of Contents
1. Status of this memo 1
2. Table of Contents 1
3. Introduction 2
3.1. X.400 2
3.2. The Internet 2
3.3. Philosophy of connection 3
3.4. X.400 attribute names used within this document 3
3.5. Internet routed addresses 4
4. Mapping between X.400 domain attributes and internet domains 4
4.1. Procedure for domain name translation 4
4.2. Internet top level domains with more than 2 letters 5
4.3. Routing within the systems 6
5. Mapping between X.400 Personal Name and Internet "local-part" 7
5.1. Procedure 7
5.2. Alpha X.400 to Internet 7
5.3. Alpha Internet to X.400 8
5.4. Beta X.400 to Internet 9
5.5. Beta Internet to X.400 10
6. Some complete examples 11
A. () escape syntax 11
B. # escape syntax 13
B.1. Representation of missing and blank values 13
References 14
Author's Address 15
Ullmann [Page 1]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
3. Introduction
The purpose of this RFC is to pass on our practical experience of
internetworking between X.400 and SMTP/Internet, from a starting point
of an attempt to implement RFC 987 [3].
While RFC 987 goes into extreme detail regarding the mapping of the
various attributes, it leaves the issue of workable addressing mostly
unresolved. The present RFC is a proposed solution to the addressing
problem, providing a reversible translation between the systems.
The methods and procedures in this memo have been implemented for the
Prime 50-series computers by Peter Lynch of the Willen Lake, U.K.
research and development facility of Prime Computer, in parallel with
the development of this specification.
The resulting gateway is now in production use within Prime Computer, as
well as providing a connection between EurOSInet and the Internet.
3.1. X.400
X.400 is a set of protocols developed by the CCITT (The International
Telegraph and Telephone Consultative Committee) for message handling.
Note that the term "X.400" is used somewhat loosely in this document to
refer to the series of specifications, including X.409, X.411, et al, as
well as other related specifications of ISO and the CCITT.
3.2. The Internet
The internet protocols were originally developed under the aegis of the
(U.S.) Defence Advanced Research Projects Agency. They have since become
the de-facto standard for heterogenous computer networks around the
world. The protocols are described by their authors in a series of
"RFCs", Requests For Comment, of which this memo is a part. The mail
protocols are defined by RFCs 821 and 822 [8, 2].
The Internet and internet protocols provide service, directly and
indirectly, to several million users in more than 30 countries.
Note that the term "internet" (lower case) is used in this document to
refer to the Internet, and many networks connected to it.
Ullmann [Page 2]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
3.3. Philosophy of connection
A message must be able to transit more than one gateway, with consistant
address mapping. For example, internet mailing lists contain X.400
addresses, and when one of those subscribers sends to the list, the
message will transit two gateways.
Replies to messages will also typically be routed through a different
gateway than the original message. This is a consequence of the
different policies and procedures on each side.
Addresses must also be translatable with no knowledge of whether they
are in fact internet or X.400 addresses (or something else, mapped into
either one). For example, other recipients of a message, other than
those this instance of the message is directed to, must be translated
correctly.
3.4. X.400 attribute names used within this document
Within this document, the following single letter attribute
abbreviations are used:
C country
A ADMD
P PRMD
O organization
U organizational unit(s)
S Surname
I Initials
G Given name
Q generational qualifier
D a domain defined attribute, name "ID"
Notes:
- X.400 uses an "implicit sequence" of U, organizational unit.
All other attributes occur once.
Ullmann [Page 3]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
- The (U.S.) NIST OSI Implementors Guide [7] recommends the use
of domain-defined attribute "ID" for domain specific mailbox
ID's.
3.5. Internet routed addresses
The addresses in the internet envelope are full source routes, i.e. a
series of domains followed by a fully qualified address. In the case of
Return-Path, this records the route the message has traversed so far.
Forward-Path specifies the route the message must take (possibly through
other domains as well, but at least through the specified domains in
order.)
Routed Forward-Path addresses are almost always the result of a returned
message, where the recorded Return-Path is used to transmit the message
back to the originator; but sometimes is used intentionally by the
sender.
When converting into X.400, only the last fully specified address is
used from the Return-Path, i.e. the actual originator. The Forward-Path
must consist only of a single address at arrival at the gate; if it is
the result of a return, this will necessarily be true.
Many sites on the internet also implement the "% hack", which allows
domain-defined recursive re-evaluation of the address. This cannot be
interpreted by the gate, since the address can only be properly
evaluated by the site specified by the domain name. Similar comments
apply to the use of uucp "bang paths" with ! in the local-part.
4. Mapping between X.400 domain attributes and internet domains
4.1. Procedure for domain name translation
Internet domain name labels, read right to left, are mapped into
corresponding X.400 C, A, P, O, and sequence of U.
Missing components of the X.400 sequence are replaced by # when
translating from X.400 to internet. From the internet, # is mapped to a
missing attribute. Similarily, blank attributes are mapped with ##. (See
section B.1 for a more complete discussion of this.)
Ullmann [Page 4]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
Underscore '_' in an internet name label, is translated to X.400 space
' '. And the reverse in the other direction. Other special characters
are mapped as in appendix B.
For example:
X.400 Internet
/C=GB/A=Gold 400/P=Prime Prime.Gold_400.GB
/C=US/A=DIALCOM/O=DIALCOM DIALCOM.#.DIALCOM.US
/C=US/A=VA/P=Reston/O=NRI NRI.Reston.VA.US
/C=US/A=CA/P=MPK/O=ANTERIOR ANTERIOR.MPK.CA.US
/C=FR/A=ATLAS ATLAS.FR
/C=FR/A=INRIA INRIA.FR
/C=NO/A=NTA/P=TOR TOR.NTA.NO
/C=UK/A=AC/P=UCL/O=CS CS.UCL.AC.UK
/C=CA/A=CRIM/P=CLOUSO CLOUSO.CRIM.CA
Note:
- The characters _ and # are added by this specification to the
set of characters permitted in domain names. They should not
appear in actual internet host names, but only in domain names
mapping non-internet names.
- The character + is added by this specification to the set of
characters generally permitted in internet host names.
This method provides a general escape translation for non-alphanumeric
domain labels that may be useful at gateways to other protocols.
4.2. Internet top level domains with more than 2 letters
The common internet domains not representing countries are longer than 2
letters: COM, MIL, EDU, GOV, ORG, NET, and INT. There are also several
others in common use: ARPA, BITNET, and UUCP.
To translate these into X.400, the first ISO 3166 extension code (XA) is
Ullmann [Page 5]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
used, with the top level internet domain translating to the A attribute,
and the other labels translated in sequence to P, O, and sequence of
U. The corresponding X.121 code used, if the X.400 implementation
requires it, is 316 (one of the DCCs registered to the U.S.; "US" itself
uses DCC 310).
This translation is done whenever the top level domain is not exactly
two letters.
In the other direction, from X.400, if the translation results in a
domain name ending in .XA, it is removed.
Examples:
X.400 Internet
/C=XA/A=COM/P=Prime/O=Relay Relay.Prime.COM
/C=XA/A=EDU/P=ISI/O=Venera Venera.ISI.EDU
/C=XA/A=ARPA/P=SRI-NIC SRI-NIC.ARPA
/C=XA/A=BITNET/P=MITVMA MITVMA.BITNET
Note:
- this implicitly imposes the requirement that the domains
defined within "XA" not be 2 alphabetic characters, i.e.
Internet top-level domains not representing countries must be
more than 2 characters.
4.3. Routing within the systems
Within X.400, country XA should be routed by sites to an internet
gateway. Other domain identifiers, not recognized as X.400 ADMDs, can
also be default-routed to a gate.
Within the internet, the X.400 ADMDs should have MX records in the
domain system [5, 6] specifying the gateway(s) for the particular ADMD.
ATLAS.FR, for example, is already registered in this way.
Ullmann [Page 6]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
5. Mapping between X.400 Personal Name and Internet "local-part"
5.1. Procedure
We define 2 levels of transformation, called Alpha and Beta. Since each
occurs for each direction, we have 4 transform algorithms.
The actual resultant transform is defined by the Beta transforms. The
Alpha transforms are used to define the Beta algorithms. This method
allows the transforms to invoke a number of heuristics, and also be
provably reversible in spite of the resulting complexity.
The Alpha transforms are not symmetric, therefore not reversible. The
Beta transforms are defined in such a manner as to be provably
reversible, regardless of the details of the Alpha transform algorithms.
5.2. Alpha X.400 to Internet
The objective in translating from X.400 is to represent the names in a
reasonable order, with some probability of looking like a natural name.
In particular, the simple case of attributes S and G (and possibly a
single I), should be represented in the "obvious" way.
1. all attributes are expanded with the #x# syntax to remove
"specials" (as defined by RFC 822), space becomes _
(underscore). attributes present, but null, are set to ##
(see appendix B)
2. the Initials attribute, if present, is expanded by adding .
in between characters, but not at the end.
3. if Q exists, and I does not, I is set to null
4. if G is a single character, G is set to G##
5. the attributes are concatenated with . in between, in the
order G, I, S, Q. The . is only introduced where required,
i.e. the result is S, G.S, I.S, G.I.S, I.S.Q, or G.I.S.Q
For example:
Ullmann [Page 7]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
/S=Ullmann/G=Robert/ Robert.Ullmann
/S=Ullmann/G=R/I=L/ R##.L.Ullmann
/I=SE/S=Kille/ S.E.Kille
/S=Lynch/I=P/ P.Lynch
Note:
- Although the S attribute is required, not optional, at least
one existing X.400 implementation does not always provide it.
Setting it to # (in step 1) when missing has proven useful in
this case.
5.3. Alpha Internet to X.400
The objective in translating from the internet local part to X.400 is to
attempt to reproduce the intended meaning of the components of a name.
It is designed to re-capture as many of the Alpha X.400 to internet
translations as possible.
If an internet local part happens to be the full name of the owner of
the mailbox, this algorithm will usually interpret the attributes
correctly.
1. the local part is separated into tokens delimited by .
2. if the first token is exactly one character, any following
tokens that are also one character are concatenated (in)to
it, except the last token, which is not included.
3. (else) if the first token is more than one character, the
preceeding step is applied starting with the second token.
4. if there are more than four tokens, return NULL (failure)
5. if there are 4 tokens, and the second was one character or
null before step 2, assign them to G, I, S, and Q in that
order.
6. if there are 4 tokens, and the second was more than one
Ullmann [Page 8]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
character before step 2, fail.
7. if 3 tokens, and the second was one character or null before
step 2, assign them to G, I and S.
8. if 3 tokens, and the second was more than one character
before step 2, fail.
9. if 2 tokens, and the first was one character or null before
step 2, assign them to I and S
10. if 2 tokens, and the first was more than one character before
step 2, assign them to G and S
11. if 1, assign it to S
12. if G, I, or Q is null, drop it (them)
13. remove #x# escapes, converting _ to space, and ## to nothing.
14. if lengths of G, I, S, or Q exceed 16, 5, 40, or 3
respectively, return failure (NIST limits).
For example:
Ariel /S=Ariel/
Robert.Ullmann /S=Ullmann/G=Robert/
R.L.Ullmann /S=Ullmann/I=RL/
Most internet mailbox names will translate to a single "surname"
attribute.
5.4. Beta X.400 to Internet
Now we define the actual transform used.
Given X.400 attributes S, G, I, Q, D:
Ullmann [Page 9]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
1. if D exists, undo the (x) syntax, and return the resulting
string (see appendix A)
2. apply the Alpha X.400 to internet transform, it will always
succeed, returning a local-part L.
3. apply the Alpha internet to X.400 transform to L. If it fails
go to step 5. If it succeeds it returns (S, G, I and Q)'
4. compare the returned S' with S, G' with G, and so forth. If
all match (considering "null" does not match "not present")
return L as the result string
5. (else) format the attributes in the /S=name/G=name/ format,
using the attribute names as in [3], with the values expanded
with the #x# syntax, (optionally) enclose in double quotes
(""), and return it.
5.5. Beta Internet to X.400
Given an internet local-part L:
1. if it is in (possibly quoted) /S=name/G=name/ format, i.e.
begins with / and ends with /, decode it, remove the #x#
escapes, and return the resultant attributes.
2. if L contains the characters % or ! (indicating a route, as
in uucp or greybook), or any other character not in the
PrintableString set, skip to step 6
3. apply the Alpha internet to X.400 transform to L. If it fails
go to step 6. If it succeeds it returns (S, G, I and Q)
4. apply the Alpha X.400 to internet transform to (S, G, I and
Q), it will always succeed, returning a local-part L'.
5. compare L to L' (string comparison). If they are equal,
return the X.400 attributes from step 3
6. (else) encode L with the (x) syntax producing attribute D
(see appendix A)
Ullmann [Page 10]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
6. Some complete examples
These are some examples of the combined translation.
X.400
Internet
/C=XA/A=COM/P=Prime/O=Relay/S=Ariel/
Ariel@Relay.Prime.COM
/C=XA/A=COM/P=Prime/O=X400/OU=EN-C06/S=Ullmann/G=Robert/
Robert.Ullmann@EN-C06.X400.Prime.COM
/C=GB/A=Gold 400/P=Prime/O=Willen R+D/S=Stone/I=DF/G=David/
David.D.F.Stone@Willen_R+D.Prime.Gold_400.GB
/C=XA/A=ARPA/P=SRI-NIC/S=Service/
Service@SRI-NIC.ARPA
/C=XA/A=COM/P=Prime/O=OAS-US/DD.ID=AB(042)/
AB*@OAS-US.Prime.COM
/C=US/A=MA/P=Boston/O=Xanadu/S=Ariel/
Ariel@Xanadu.Boston.MA.US
and some imaginary examples, to show more unusual things:
/C=US/A=DIALCOM/O=Dialcom/S=Wilson/G=Mary Jane/
Mary_Jane.Wilson@Prime.#.DIALCOM.US
/C=VA/A=Vatican/G=John Paul/GQ=II
John_Paul..#.II@Vatican.VA
A. () escape syntax
In converting internet names to X.400 PrintableString, several
characters need to be encoded because of the restricted set available.
The following translation is used.
Ullmann [Page 11]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
@ (a) at-sign
% (p) percent
! (b) exclamation
" (q) quote
_ (u) underscore
( (l) left parenthesis
) (r) right parenthesis
others (nnn) where nnn is the 3-digit decimal ASCII-8 code
Note that a sequence of zero or more characters may be escaped together.
For example:
string: becomes:
84% 84(p)
(etc) (l)etc(r)
"!" (qbq)
and the sequence "A", "%", CR, LF, "B" (i.e. 065 037 013 010 066 in
decimal)
A%[CRLF]B A(p013010)B
a null string can be mapped, if useful:
[null] ()
"Others" include #, $, &, *, ., ;, <, >, [, \, ], ^. None of these are
particularily common in internet local-part names.
Ullmann [Page 12]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
B. # escape syntax
In translation from X.400, in particular when the target is a domain
label, the following escapes are used:
[space] _ space becomes underscore
_ #u# underscore
( #l# left parenthesis
) #r# right parenthesis
, #m# comma
: #c# colon
\ #b# backslash
# #h# hash mark, U.S. "pound sign"
= #e# equals sign
/ #s# slash, solidus
others #nnn# where nnn is the 3-digit decimal ASCII-8 code
Alphanumerics, - (hyphen), and + (plus sign) are mapped to themselves.
Others, such as ' and ?, are escaped with the #nnn# syntax when
converting to a domain label, but not translated in the local-part.
In the same way as with the parenthesis escape described in the
preceeding section, a sequence of zero or more characters can be
escaped. The representation of a null string by ## is particularily
useful.
B.1. Representation of missing and blank values
X.400 permits several different variations of the concept of a null
attribute, and does not specify that they must compare equal when
routing or delivering messages. While practical X.400 implementations
surely will not differentiate (try explaining to a user that a message
was not delivered because the user specified an address component as
blank instead of missing!), the mapping still must provide a method of
preserving the distinction.
Ullmann [Page 13]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
Therefore the following are used. Except for #, these follow logically
>from the preceeding table. The missing value represention is used only
with the domain name, as the local-part to personal name mapping handles
"missing" values differently.
X.400 attribute Internet
missing #
blank, i.e. zero-length ##
length 1, value zero #000#
length 1, value space _ [or] #032#
References
[1] International Telegraph and Telephone Consultative Committee.
Data Communication Networks: Message Handling Systems.
In CCITT Recommendations X.400 to X.430. VIIIth Plenary Assembly,
Malaga-Torremolinos, 1984.
Fascicle VIII.7 ("Red Book").
[2] David H. Crocker.
Standard for the Format of ARPA Internet Text Messages.
RFC 822, University of Delaware, August, 1982.
[3] S. E. Kille.
Mapping between X.400 and RFC 822.
RFC 987, University College London, June, 1986.
[4] S. E. Kille.
Addendum to RFC 987: (Mapping between X.400 and RFC-822).
RFC 1026, University College London, September, 1987.
[5] P. Mockapetris.
Domain Names -- Concepts and Facilities.
RFC 1034, ISI, November, 1987.
[6] P. Mockapetris.
Domain Names -- Implementation and Specification.
RFC 1035, ISI, November, 1987.
Ullmann [Page 14]
RFC (tba) Mapping between Internet and X.400 addresses July 1989
[7] National Institute of Standards and Technology.
Stable Implementation Agreements for Open Systems Interconnection
Protocols.
SP 500-162, NIST, December, 1988.
[8] Jon Postel.
Simple Mail Transfer Protocol.
RFC 821, USC Information Sciences Institute, August, 1982.
Author's Address
Robert Ullmann 23A-32
Prime Computer, Inc.
Technology Drive
Milford, MA 01757
Phone: +1 508 478 8600 x1736
Email: Ariel@Relay.Prime.COM
Ullmann [Page 15]dupont@INRIA.INRIA.FR (Francis Dupont) (07/19/89)
In the draft RFC on X.400 to Internet addressing, Robert Ullmann said : > Within the internet, the X.400 ADMDs should have MX records in the > domain system [5, 6] specifying the gateway(s) for the particular ADMD. > ATLAS.FR, for example, is already registered in this way. ^^^^^^^^ But it is not a good example ! ATLAS is definitively NOT a sub-domain of FR in the DNS. ATLAS 400 is only a RPOA, and is not aware of such a thing like the Internet. I believe Robert Ullmann has done this mistake because there is a MX RR for *.fr in order to catch miscellaneous sub-domains (in general UUCP sites with a domain name (see note)). I think that the idea to give a MX RR to ATLAS.FR is an error. For example, nobody'd like to have names like pucc.princeton.nsf.us because Princeton University uses the network organization NSF ... Francis.Dupont@inria.fr [INRIA DNS wizard] Note : today there are 40 sub-domains of .FR, and only 25 of them could be reached directly (or will be accessible) from the Internet. Several UUCP sites have got a domain name, much preferable than old UUCP paths. X.400 has one (only) good thing : it uses no routes (yet).
Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) (07/19/89)
There is a single reason for having an "atlas.fr" subdomain in the French internet: being able to address simply those users whose mailbox is managed by ATLAS. This domain is not generally available to users outside France, as we are not allowed to *relay* towards it; it can simply be *accessed* by those French site which do have an ATLAS subscription. Christian Huitema