Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!ncis.tis.llnl.gov!en-c06.x400.prime.COM!Robert.Ullmann From: Robert.Ullmann@en-c06.x400.prime.COM Newsgroups: comp.protocols.iso.x400.gateway Subject: Fw: draft RFC on X.400 to Internet addressing Message-ID: <897HB201201036*Robert.Ullmann@EN-C06.X400.Prime.COM> Date: 17 Jul 89 15:21:08 GMT Sender: root@ncis.tis.llnl.gov Reply-To: kehres@tis.llnl.gov Distribution: inet Organization: The Internet Lines: 897 Approved: post-x400-gateway@tis.llnl.gov [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]