Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!ncis.tis.llnl.gov!CS.UCL.AC.UK!S.Kille From: S.Kille@CS.UCL.AC.UK (Steve Kille) Newsgroups: comp.protocols.iso.x400.gateway Subject: Fw: 5 of 5 Message-ID: <1074.616429322@UK.AC.UCL.CS> Date: 14 Jul 89 14:22:02 GMT Sender: root@ncis.tis.llnl.gov Reply-To: kehres@tis.llnl.gov Distribution: inet Organization: The Internet Lines: 1368 Approved: post-x400-gateway@tis.llnl.gov Kille [page 94] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Appendix A - Quoted String Encodings This Appendix describes a quoting mechanism which may be used to allow general interworking between RFC 822, and variants of RFC 822 which do not support 822.quoted-string. This is important, as the basic X.400 <-> RFC 822 mapping makes use of 822.quoted-string. WARNING: THIS APPENDIX IS RETAINED FOR BACKWARDS | COMPATIBILITY WITH RFC 987. ITS USE IS DEPRECATED. | WHERE USED, THE REVERSE PATH MUST BE THROUGH A GATEWAY | WHICH ALSO USES THIS SPECIFICATION. 1. Introduction There are places where it is needed to convert between PrintableString or IA5Text (X.400), and 822.word (RFC 822). word may be encoded as 822.atom (which has a restricted character set) or as 822.quoted-string, which can handle all ASCII characters. If 822.quoted-string is used, clearly the mappings for PrintableString defined in Chapter 3 provide a straightforward mapping. However, some RFC 822 based networks cannot handle the 822.quoted-string format in all cases. This Appendix is for use in these cases. The major requirement for this mapping is the UNIX world, but it may well be needed in other places. These mappings are somewhat artificial, and their usage is discouraged, except in cases where there is no alternative. 2. ASCII <-> 822.atom The following EBNF is specified. Kille [page 95] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 atom-encoded = *( a-char / a-encoded-char ) a-char = a-encoded-char = "_" ; (space) / "#u#" ; (_) / "#l#" ; <(> / "#r#" ; <)> / "#m#" ; (,) / "#c#" ; (:) / "#b#" ; (\) / "#h#" ; (#) / "#e#" ; ($=) / "#s#" ; ($/) / "#" 3DIGIT "#" NOTE There are two encodings of double characters. This is so that systems using this encoding, do not also need to know about the "$" quoting mechanism defined in Chapter 4. The 822.3DIGIT in EBNF.a-encoded-char must have range 0-127, and is interpreted in decimal as the corresponding ASCII character. The choice of special abbreviations (as opposed to decimal encoding) provided is based on the manner in which this mapping is most frequently used: encoding PrintableString components of O/R names as atom. Therefore, there are special encodings for each of the PrintableString characters not in EBNF.a-char, except ".". Space is given a single character encoding, due to its (expected) frequency of use, and backslash as the RFC 822 single quote character. To encode (ASCII -> atom): all EBNF.a-char are used directly and all other CHAR are encoded as EBNF.a-encoded-char. To decode (822.atom -> ASCII): if 822.atom can be parsed as EBNF.encoded-atom reverse the previous mapping. If it cannot be so parsed, map the characters directly. 3. 822.local-part <-> ASCII A related transformation is for 822.local-part (or other element defined as '822.word ("." 822.word)') where not 822.quoted-text is used. To encode (ASCII -> 822.local-part), all EBNF.a-char and "." are used directly and all other 822.CHAR are encoded as Kille [page 96] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 EBNF.a-encoded-char. To decode (822.local-part -> ASCII), first attempt to parse 822.local-part as '822.atom *("." 822.atom)'. If this fails, or if each 822.atom cannot be parsed as EBNF.atom-encoded then map each character directly. Otherwise map each "." directly, and each atom as in the previous section. Kille [page 97] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Appendix B - Mappings specific to the JNT Mail This Appendix is specific to the JNT Mail Protocol. It describes specific changes in the context of this protocol. 1. Introduction There are five aspects of a gateway which are JNT Mail Specific. These are each given a section of this appendix. 2. Domain Ordering When interpreting and generating domains, the UK NRS domain ordering must be used. 3. Acknowledge-To: This field has no direct functional equivalent in X.400. However, it can be supported to an extent, and can be used to improve X.400 support. If an Acknowledge-To: field is present when going from JNT Mail to X.400, MTS.PerRecipientSubmissionFields.originator-request-report.report shall be set for each recipient. If there is more that one address in the Acknowledge-To: field, or if the one address is not equivalent to the 822-MTS return address, then: 1. Acknowledgement(s) should be generated by the gateway. The text of these acknowledgements should indicate that they are generated by the gateway. 2. The Acknowledge-To: field should also be passed as an extension header. When going from X.400 to JNT Mail, in cases where MTA.PerRecipientMessageTransferFields.per-recipient-indicators. originator-report is set, the copy of the message to that recipient should have an Acknowledge-To: field containing the MTS.OtherMessageDeliveryFields.originator-name. No special treatment should be given when MTA.PerRecipientMessageTransferFields.per-recipient-indicators. Kille [page 98] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 originating-MTA-report is set. No attempt should be made to map Receipt notification requests onto Acknowledge-To:, as no association can be guaranteed between IPMS and MTS level addressing information. 4. Trace JNT Mail trace uses the Via: syntax. When going from JNT Mail to X.400, a mapping similar to that for Received: is used. No MTS.GlobalDomainIdentifier of the site making the trace can be derived from the Via:, so a value for the gateway should be used. The trace text, including the "Via:", should be unfolded, truncated to MTS.ub-mta-name-length (32), and mapped to MTA.InternalTraceInformationElement.mta-name. 5. Timezone specification The extended syntax of zone defined in the JNT Mail Protocol should be used in the mapping of UTCTime defined in Chapter 3. 6. Lack of 822-MTS originator specification In JNT Mail the default mapping of the P1.MPDUEnvelope.originator is to the Sender: field. This can cause a problem when going from X.400 to JNT Mail if the mapping of P2.Heading has already generated a Sender: field. To overcome this, new extended JNT Mail field is defined. This is chosen to align with the JNT recommendation for interworking with full RFC 822 systems [Kille84b]. original-sender = "Original-Sender" ":" mailbox If an IPM has no IPMS.Heading.authorising-users component and IPMS.Heading.originator.formal-name is different from MTS.OtherMessageDeliveryFields.originator-name, map MTS.OtherMessageDeliveryFields.originator-name, onto the Sender: field. If an IPM has a IPMS.Heading.authorising-users component, and IPMS.Heading.originator.formal-name is different from MTS.OtherMessageDeliveryFields.originator-name, MTS.OtherMessageDeliveryFields.originator-name should be mapped onto the Sender: field, and IPMS.Heading.originator mapped onto the Original-Sender: field. Kille [page 99] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 In other cases the MTS.OtherMessageDeliveryFields.originator-name, is already correctly represented. Note that in some pathological cases, this mapping is asymmetrical. Kille [page 100] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Appendix C - Mappings specific to UUCP Mail | Gatewaying of UUCP and X.400 is handled by first gatewaying * the UUCP address into RFC 822 syntax (using RFC 976) and then gatewaying the resulting RFC 822 address into X.400. For example, an X.400 address Country US Organization Xerox Personal Name John Smith might be expressed from UUCP as inthop!gate!gatehost.COM!/C=US/O=Xerox/PN=John.Smith/ (assuming gate is a UUCP-ARPA gateway and gatehost.COM is an ARPA-X.400 gateway) or inthop!gate!Xerox.COM!John.Smith (assuming that Xerox.COM and /C=US/O=Xerox/ are equivalent.) In the other direction, a UUCP address Smith@ATT.COM, integrated into 822, would be handled as any other 822 address. A non-integrated address such as inthop!dest!user might be handled through a pair of| gateways: Country US ADMD ATT PRMD ARPA Organization GateOrg RFC-822 inthop!dest!user@gatehost.COM or through a single X.400 to UUCP gateway: Country US ADMD ATT PRMD UUCP Organization GateOrg RFC-822 inthop!dest!user Kille [page 101] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Appendix D - Object Identifier Assignment | An object identifier is needed for the extension IPMS element. * The following initial assignment is given. rfc-987-88 OBJECT IDENTIFIER ::= {ccitt data(9) pss(2342) ucl(234219200300) rfc-987-88(200)} id-rfc-822-field OBJECT IDENTIFIER ::= {rfc987-88 field(0)} Kille [page 102] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Appendix E - BNF Summary | boolean = "TRUE" / "FALSE" numericstring = *DIGIT printablestring = *( ps-char ) ps-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+" / "," / "-" / "." / "/" / ":" / "=" / "?" ps-delim = "(" / ")" ps-char = ps-delim / ps-restricted-char ps-encoded = *( ps-restricted-char / ps-encoded-char ) ps-encoded-char = "(a)" ; (@) / "(p)" ; (%) / "(b)" ; (!) / "(q)" ; (") / "(u)" ; (_) / "(l)" ; "(" / "(r)" ; ")" / "(" 3DIGIT ")" teletex-string = *( ps-char / t61-encoded ) | t61-encoded = "{" 1* t61-encoded-char "}" | t61-encoded-char = 3DIGIT | teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ]| labelled-integer ::= key-string "(" numericstring ")" Kille [page 103] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 object-identifier ::= [ defined-value ] oid-comp-list oid-comp-list ::= oid-comp oid-comp-list | oid-comp defined-value ::= key-string oid-comp ::= [ key-string ] "(" numericstring ")" key-string = *key-char key-char = encoded-info = 1#encoded-type encoded-type = built-in-eit / object-identifier built-in-eit = "Undefined" ; undefined (0) / "Telex" ; tLX (1) / "IA5-Text" ; iA5Text (2) / "G3-Fax" ; g3Fax (3) / "TIF0" ; tIF0 (4) / "Teletex" ; tTX (5) / "Videotex" ; videotex (6) / "Voice" ; voice (7) / "SFD" ; sFD (8) / "TIF1" ; tIF1 (9) encoded-pn = [ given "." ] *( initial "." ) surname given = 2* initial = ALPHA surname = printablestring Kille [page 104] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 std-or-address = 1*( "/" attribute "=" value ) "/" attribute = standard-type / "RFC-822" / registered-dd-type / dd-key "." std-printablestring standard-type = key-string registered-dd-type = key-string dd-key = key-string value = std-printablestring std-printablestring | = *( std-char / std-pair ) std-char = <"{", "}", "*", and any ps-char except "/" and "="> std-pair = "$" ps-char dmn-or-address = dmn-part *( "." dmn-part ) dmn-part = attribute "$" value attribute = standard-type / "~" dmn-printablestring value = dmn-printablestring / "@" dmn-printablestring = = *( dmn-char / dmn-pair ) dmn-char = <"{", "}", "*", and any ps-char except "."> dmn-pair = "\." global-id = std-or-address mta-field = "X400-Received" ":" x400-trace | / "Deferred-Delivery" ":" date-time / "Latest-Delivery-Time" ":" date-time | Kille [page 105] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 x400-trace = "by" [ "mta" mta "in" ] global-id ";" | [ "deferred until" date-time ";" ] | [ "converted" "(" encoded-info ")" ] [ "attempted domain" global-id ";" ] | action-list | ";" date-time | mta = word | arrival-time = date-time | routing-action = | other-action-list = 1#action | action = "Redirected" | / "Expanded" | / "Relayed" | / "Rerouted" | Kille [page 106] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 dr-body-format = dr-summary || dr-recipients || dr-extra-information || dr-content-return || dr-content-return = "The Original Message is not available"|| / "The Original Message follows:" || message || dr-summary = "This report relates to your message:" || content-correlator || "Which failed at" failure-point || dr-recipients = *(dr-recipient ) || dr-recipient = dr-recip-success / dr-recip-failure || dr-recip-success = || "Your message was successfully delivered to:"|| mailbox || dr-recip-failure = "Your message was not delivered to:" || mailbox || "for the following reason:" *word || Kille [page 107] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 dr-extra-information = || "The following information is derived from the Report" || "It may be useful for problem diagnosis:" || drc-field-list = *(drc-field ) || drc-field = "Subject-Submision-Identifier" ":" || mts-msg-id || / "Content-Identifier" ":" printablestring || / "Content-Type" ":" mts-content-type || / "Original-Encoded-Information-Types" ":" || encoded-info || / "Originator-and-DL-Expansion-History" ":" || dl-history || / "Reporting-DL-Name" ":" mailbox || / "Content-Correlator" ":" content-correlator || / "Recipient-Info" ":" recipient-info || recipient-info = mailbox "," std-or ";" || report-type || [ "converted eits" encoded-info ";" ] || [ "originally intended recipient" || mailbox "," std-or ";" ] || [ "supplementary info" printablestring ] || [ "redirection history" 1#redirection ] || [ "physical forwarding address" || printablestring ] || report-type = "SUCCESS" drc-success / "FAILURE" drc-failure drc-success = "delivered at" date-time ";" [ "type of MTS user" labelled-integer ";" ] | drc-failure = "reason" labelled-integer ";" [ "diagnostic" labelled-integer ";" ] | failure-point = [ "mta" word "in" ] global-id || content-correlator = *word || dl-history = 1#mailbox || Kille [page 108] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 mts-field = "X400-MTS-Identifier" ":" mts-msg-id || / "X400-Originator" ":" mailbox || / "X400-Recipients" ":" 1#mailbox || / "Original-Encoded-Information-Types" ":" || encoded-info || / "X400-Content-Type" ":" mts-content-type || / "Content-Identifier" ":" printablestring || / "Priority" ":" priority | / "Originator-Return-Address" ":" 1#mailbox || / "DL-Expansion-History" ":" mailbox ";" date-time ";"|| / "Redirection-History" ":" redirection || / "Conversion" ":" prohibition || / "Conversion-With-Loss" ":" prohibition || / "Requested-Delivery-Method" ":" || 1*( labelled-integer ) || / "Discarded-X400-MTS-Extensions" ":" 1#oid || prohibition = "Prohibited" / "Allowed" | mts-msg-id = global-id ";" *text | mts-content-type = "P2" / labelled-integer | / object-identifer | priority = "normal" / "non-urgent" / "urgent" redirection = mailbox ";" "reason" "=" | redirection-reason | redirection-reason = "Recipient Assigned Alternate Recipient" | / "Originator Requested Alternate Recipient" / "Recipient MD Assigned Alternate Recipient" | Kille [page 109] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 ipn-body-format = ipn-description || [ ipn-extra-information ] || ipn-content-return || ipn-preamble = * ( printablestring ) || ipn-description = ipn-receipt / ipn-non-receipt || ipn-receipt = "Your message to:" preferred-recipient || "was received at" receipt-time || "This notification was generated" || acknowledgement-mode || "The following extra information was given:" || ipn-suppl || ipn-non-receipt "Your message to:" || preferred-recipient || ipn-reason || ipn-reason = ipn-discarded / ipn-auto-forwarded || ipn-discarded = "was discarded for the following reason:" || discard-reason || ipn-auto-forwarded = "was automatically forwarded." || [ "The following comment was made:" || auto-comment ] || ipn-extra-information = || "The following information types were converted:" || encoded-info || ipn-content-return = "The Original Message is not available"|| / "The Original Message follows:" || message || Kille [page 110] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 preferred-recipient = mailbox || receipt-time = date-time || auto-comment = printablestring || ipn-suppl = printablestring || non-receipt-reason = "Discarded" / "Auto-Forwarded" discard-reason = "Expired" / "Obsoleted" / "User Subscription Terminated" | acknowledgement-mode = "Manually" / "Automatically" | ipms-field = "Obsoletes" ":" 1#msg-id / "Expiry-Date" ":" date-time / "Reply-By" ":" date-time / "Importance" ":" importance / "Sensitivity" ":" sensitivity / "Autoforwarded" ":" boolean / "Incomplete-Copy" ":" / "Language" ":" language / "Message-Type" ":" message-type | / "Discarded-X400-IPMS-Extensions" ":" 1#oid | importance = "low" / "normal" / "high" sensitivity = "Personal" / "Private" / "Company-Confidential" | language = 2*ALPHA [ language-description ] | language-description = printable-string message-type = "Delivery Report" / "InterPersonal Notification" / "Multiple part" Kille [page 111] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Appendix F - Format of address mapping tables | There is a need to specify the association between the domain and | X.400 namespaces described in Chapter 4. The use of this | association leads to a better service on both sides of the | gateway, and so defining mappings and distributing them in the | form defined in this appendix is strongly encouraged. | This syntax defined is initially in table form, but the | syntax is defined in a manner which makes it suitable for use | with domain nameservices (such as the DARPA Domain nameservers or | the UK NRS). The mapping is not symmetric, and so a separate | table is specified for each direction. If multiple matches are | possible, the longest possible match should be used. | First, an address syntax is defined, which is compatible | with the syntax used for 822.domains. It is intended that this | syntax may be used in conjunction with systems which support this | form of name. | To allow the mapping of null attributes to be represented, | the pseudo-value "@" (not a printable string character) is used | to indicate omission of a level in the hierarchy. This is | distinct from the form including the element with no value, | although a correct X.400 implementation will interpret both in | the same manner. | This syntax is not intended to be handled by users. | dmn-or-address = dmn-part *( "." dmn-part ) dmn-part = attribute "$" value attribute = standard-type / "~" dmn-printablestring value = dmn-printablestring / "@" dmn-printablestring = = *( dmn-char / dmn-pair ) dmn-char = <"{", "}", "*", and any ps-char except "."> dmn-pair = "\." An example usage: | Kille [page 112] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 ~ROLE$Big\.Chief.ADMD$ATT.C$US PRMD$DEC.ADMD$@.C$US The first example illustrates quoting of a ".", and the second | omission of the ADMD level. | Various further restrictions are placed on the usage of | dmn-or-address: | 1. Only C, ADMD, PRMD, O, and OU may be used. | 2. There must be a strict ordering of all components, with the | most significant components on the RHS. | 3. No components may be omitted from the hierarchy, although | the hierarchy may terminate at any level. If the mapping is | to an omitted component, the "@" syntax is used. | For domain -> X.400: | domain-syntax "#" dmn-or-address "#" Note that the trailing "#" is used for clarity, as the dmn-or- | address syntax can lead to values with trailing blanks. Lines | staring with "#" are comments. | For example: AC.UK#PRMD$UK\.AC.ADMD$GOLD 400.C$GB# XEROX.COM#O$Xerox.ADMD$ATT.C$US# GMD.DE#O$@.PRMD$GMD.ADMD$DBP.C$DE# For X.400 -> domain: | dmn-or-address "#" domain-syntax "#" For example: # # Mapping table # PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK# Kille [page 113] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Appendix G - Differences with RFC 987 | This appendix summarises changes between this document and RFC 987/RFC 1026. 1. Introduction The model has shifted from a protocol based mapping to a service based mapping. This has increased the generality of the specification, and improved the model. This change affects the entire document. A restriction on scope has been added. 2. Service Elements - The new service elements of X.400 are dealt with. - A clear distinction is made between origination and reception 3. Basic Mappings - Add teletex support - Add object identifier support - Add labelled integer support - Make PrintableString <-> ASCII mapping reversible - The printable string mapping is aligned to the NBS mapping derived from RFC 987. 4. Addressing - Support for new addressing attributes - The message ID mapping is changed to not be table driven * Kille [page 114] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 5. Detailed Mappings - Define extended IPM Header, and use instead of second body | part for RFC 822 extensions - Realignment of element names - New syntax for reports, simlifying the header and | introducing a mandatory body format (the RFC 987 header | format was unusable) - Drop complex autoforwarded mapping - Add full mapping for IP Notifications, defining a body | format - Adopt an MTS Identifier syntax in line with the O/R Address syntax | - A new format for X400 Trace representation on the RFC 822 | side | 6. Appendices | - Retain, but discourage use of Appendix A | - Delete Phonenet and SMTP Appendixes Kille [page 115] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 References CCITT88a. CCITT, "Specification of Abstract Syntax Notation One (ASN.1)," CCITT Recommendation X.208 / ISO IS 8824, December 1988. CCITT88b. CCITT, "CCITT Recommendations X.408," Message Handling Systems: Encoded Information Type Conversion Rules, December 1988. CCITT/ISO88a. CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1," Message Handling: System and Service Overview , December 1988. CCITT/ISO88b. CCITT/ISO, "CCITT Recommendations X.420/ ISO IS 10021-7," Message Handling Systems: Interpersonal Messaging System, December 1988. CCITT/ISO88c. CCITT/ISO, "CCITT Recommendations X.411/ ISO IS 10021-3," Message Handling Systems: Message Transfer System: Abstract Service Definition and Procedures, December 1988. Crocker82a. D.H. Crocker, "Standard of the Format of ARPA Internet Text Messages," RFC 822, August 1982. Horton86a. M.R. Horton, "UUCP Mail Interchange Format Standard," RFC 976, February 1986. Kille84b. S.E. Kille, "Gatewaying between RFC 822 and JNT Mail," JNT Mailgroup Note 15, May 1984. Kille84a. S.E. Kille (Editor), JNT Mail Protocol (revision 1.0), Joint Network Team, Rutherford Appleton Laboratory, March 1984. Kille [page 116] RFC 987(88) Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0 Kille86a. S.E. Kille, "Mapping Between X.400 and RFC 822," UK Academic Community Report (MG.19) / RFC 987, June 1986. Kille87a. S.E. Kille, "Addendum to RFC 987," UK Academic Community Report (MG.23) / RFC 1026, August 1987. Kille89a. S.E. Kille, "A String Encoding of Presentation Address," UCL Research Note 89/14, March 1989. Larmouth83a. J. Larmouth, "JNT Name Registration Technical Guide," Salford University Computer Centre, April 1983. Postel84a. J. Postel and J. Reynolds, "Domain Requirements," RFC 920, October 1984. Postel82a. J.B. Postel, "SIMPLE MAIL TRANSFER PROTOCOL," RFC 821, August 1982. Rose85a. M.T. Rose and E.A. Stefferud, "Proposed Standard for Message Encapsulation," RFC 934, January 1985. Systems85a. CEN/CENELEC/Information Technology/Working Group on Private Message Handling Systems, "FUNCTIONAL STANDARD A/3222," CEN/CLC/IT/WG/PMHS N 17, October 1985. Kille [page 117]