diff options
Diffstat (limited to 'doc/rfc/rfc987.txt')
| -rw-r--r-- | doc/rfc/rfc987.txt | 3933 |
1 files changed, 3933 insertions, 0 deletions
diff --git a/doc/rfc/rfc987.txt b/doc/rfc/rfc987.txt new file mode 100644 index 0000000..87a81e2 --- /dev/null +++ b/doc/rfc/rfc987.txt @@ -0,0 +1,3933 @@ + + +UCL Technical Report 120 +Mailgroup Note 19 + +Network Working Group S.E. Kille +Request for Comments: 987 University College London + June 1986 + + Mapping between X.400 and RFC 822 + + +Status of This Memo + + This RFC suggests a proposed protocol for the ARPA-Internet + community, and requests discussion and suggestions for improvements. + Distribution of this memo is unlimited. + + This document describes a set of mappings which will enable + interworking between systems operating the CCITT X.400 (1984) series + of protocols [CCITT84a], and systems using the RFC 822 mail protocol + [Crocker82a], or protocols derived from RFC 822. The approach aims + to maximise the services offered across the boundary, whilst not + requiring unduly complex mappings. The mappings should not require + any changes to end systems. + + This specification should be used when this mapping is performed on + the ARPA-Internet or in the UK Academic Community. This + specification may be modified in the light of implementation + experience, but no substantial changes are expected. + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 1] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +Chapter 1 -- Overview + + 1.1. X.400 + + The X.400 series protocols have been defined by CCITT to provide + an Interpersonal Messaging Service (IPMS), making use of a store + and forward Message Transfer Service. It is expected that this + standard will be implemented very widely. As well as the base + standard (X.400), work is underway on various functional standards + of profiles which specify how X.400 will be used in various + communities. Many of the major functional standards (e.g. from + CEPT, CEN/CENELEC, and NBS) are likely to be similar. Some of the + decisions in this document are in the light of this work. No + reference is given, as these documents are not currently stable. + + 1.2. RFC 822 + + RFC 822 evolved as a messaging standard on the DARPA (the US + Defense Advanced Research Projects Agency) Internet. It is + currently used on the ARPA-Internet in conjunction with two other + standards: RFC 821, also known as Simple Mail Transfer Protocol + (SMTP) [Postel82a], and RFC 920 which is a specification for a + domain name system and a distributed name service [Postel84a]. + RFC 822, or protocols derived from RFC 822 are used in a number of + other networks. In particular: + + UUCP Networks + + UUCP is the UNIX to UNIX CoPy protocol <0>, which is usually + used over dialup telephone networks to provide a simple + message transfer mechanism. There are some extensions to + RFC 822, particularly in the addressing. They are likely to + use domains which conform to RFC 920, but not the + corresponding domain nameservers [Horton86a]. + + CSNET + + Some portions of CSNET will follow the ARPA-Internet + protocols. The dialup portion of CSNET uses the Phonenet + protocols as a replacement for RFC 821. This portion is + likely to use domains which conform to RFC 920, but not the + corresponding domain nameservers. + + BITNET + + Some parts of BITNET use RFC 822 related protocols, with + EBCDIC encoding. + + +Kille [Page 2] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + JNT Mail Networks + + A number of X.25 networks, particularly those associated + with the UK Academic Community, use the JNT (Joint Network + Team) Mail Protocol, also known as Greybook [Kille84a]. + This is used with domains and name service specified by the + JNT NRS (Name Registration Scheme) [Larmouth83a]. + + The mappings specified here are appropriate for all of these + networks. + + 1.3. The Need for Conversion + + There is a large community using RFC 822 based protocols for mail + services, who will wish to communicate with X.400 systems. This + will be a requirement, even in cases where communities intend to + make a transition to use of X.400, where conversion will be needed + to ensure a smooth service transition. It is expected that there + will be more than one gateway <1>, and this specification will + enable them to behave in a consistent manner. These gateways are + sometimes called mail relays. Consistency between gateways is + desirable to provide: + + 1. Consistent service to users. + + 2. The best service in cases where a message passes through + multiple gateways. + + 1.4. General Approach + + There are a number of basic principles underlying the details of + the specification. + + 1. The specification should be pragmatic. There should not + be a requirement for complex mappings for 'Academic' + reasons. Complex mappings should not be required to + support trivial additional functionality. + + 2. Subject to 1), functionality across a gateway should be as + high as possible. + + 3. It is always a bad idea to lose information as a result of + any transformation. Hence, it is a bad idea for a gateway + to discard information in the objects it processes. This + includes requested services which cannot be fully mapped. + + 4. All mail gateways actually operate at exactly one level + + +Kille [Page 3] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + above the layer on which they conceptually operate. This + implies that the gateway must not only be cognisant of the + semantics of objects at the gateway level, but also be + cognisant of higher level semantics. If meaningful + transformation of the objects that the gateway operates on + is to occur, then the gateway needs to understand more + than the objects themselves. + + 1.5. Gatewaying Model + + 1.5.1. X.400 + + The CCITT X.400 series recommendations specify a number of + services and protocols. The services are specified in X.400. + Two of these services are fundamental to this document: + + 1. The Message Transfer Service, which can be provided by + either the P1 or P3 protocols, which are specified in + X.411 [CCITT84b]. This document talks in terms of P1, + but the mappings are equally applicable to P3. + + 2. The Interpersonal Messaging Service (IPMS), which is + provided by the P2 protocol specified in X.420 + [CCITT84c]. + + This document considers only IPMS, and not of any other usage + of the Message Transfer Service. This is reasonable, as + RFC 822, broadly speaking, provides a service corresponding to + IPMS, and no services other than IPMS have been defined over + the Message Transfer Service. As none of the RTS (Reliable + Transfer Service) service elements is available to the IPMS + user, this level and lower levels are of no concern in this + gatewaying specification. Note that in this memo "IP" means + "InterPersonal" (not Internet Protocol). + + The Message Transfer Service defines an end-to-end service over + a series of Message Transfer Agents (MTA). It also defines a + protocol, P1, which is used between a pair of MTAs. This + protocol is simply a file format (Message Protocol Data Unit, + or MPDU), transferred between two MTAs using the RTS. There + are three types of MPDU: + + User MPDU + + This contains envelope information, and uninterpreted + contents. The envelope includes an ID, an originator, a + + + +Kille [Page 4] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + list of recipients, and trace information. It is used to + carry data for higher level services. + + Probe + + This contains only envelope information. It is used to + determine whether a User UMPDU could be delivered to a + given O/R (originator/recipient) name. + + Delivery Report + + This contains envelope information, and specified + contents. It is used to indicate delivery success or + failure of a User or Probe MPDU over the Message Transfer + Service. + + IPMS (P2) specifies two content types for the P1 User MPDU + (User Agent Protocol Data Units or UAPDU): + + Interpersonal Message (IM-UAPDU) + + This has two components: a heading, and a body. The body + is structured as a sequence of body parts, which may be + basic components (e.g.IA5 text, or G3 fax), or IP + Messages. The header contains end to end user + information, such as subject, primary recipients (To:), + and priority. The validity of these fields is not + guaranteed by the Message Transfer Service. This + provides the basic IPMS. + + Status Report (SR-UAPDU) + + This UAPDU has defined contents. It is used to indicate + that a message has been received by a User Agent. It + does not have to be implemented. + + 1.5.2. RFC 822 + + RFC 822 is based on the assumption that there is an underlying + service, which is here called the 822-P1 service. The 822-P1 + service provides three basic functions: + + 1. Identification of a list of recipients. + + 2. Identification of an error return address. + + 3. Transfer of an RFC 822 message. + + +Kille [Page 5] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + It is possible to achieve 2) within the RFC 822 header. Some + 822-P1 protocols, in particular SMTP, can provide additional + functionality, but as these are neither mandatory in SMTP, nor + available in other 822-P1 protocols, they are not considered + here. Details of aspects specific to a number of 822-P1 + protocols are given in appendices B to E. An RFC 822 message + consists of a header, and content which is uninterpreted ASCII + text. The header is divided into fields, which are the + protocol elements. Most of these fields are analogous to P2 + header elements, although some are analogous to P1 envelope + elements. + + 1.5.3. The Gateway + + Given this functional description of the two protocols, the + functional nature of a gateway can now be considered. It would + be elegant to consider the 822-P1 service mapping onto P1 and + RFC 822 mapping onto P2, but reality just does not fit. + Therefore one must consider that P1 or P1 + P2 on one side are + mapped into RFC 822 + 822-P1 on the other in a slightly tangled + manner. The details of the tangle will be made clear in + chapter 5. The following basic mappings are thus proposed. + When going from RFC 822 to X.400, an RFC 822 message and the + associated 822-P1 information is always mapped into an IM-UAPDU + and the associated P1 envelope. Going from X.400 to RFC 822, + an RFC 822 message and the associated 822-P1 information may be + derived from: + + 1. A Delivery Report MPDU + + 2. An SR-UAPDU and the associated P1 envelope. + + 3. An IM-UAPDU and the associated P1 envelope. + + Probe MPDUs must be processed by the gateway - this is + discussed in chapter 5. Any other User MPDUs are not mapped by + the gateway, and should be rejected at the gateway. + + + + + + + + + + + + +Kille [Page 6] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + 1.6. Document Structure + + This document has five chapters: + + 1. Overview - this document. + + 2. Service Elements - This describes the (end user) services + mapped by a gateway. + + 3. Basic mappings - This describes some basic notation used + in chapters 3-5, the mappings between character sets, and + some fundamental protocol elements. + + 4. Addressing - This considers the mapping between X.400 O/R + names and RFC 822 addresses, which is a fundamental + gateway component. + + 5. Protocol Elements - This describes the details of all + other mappings. + + There are also six appendices: + + A. Quoted String Encodings. + + B. Mappings Specific to JNT Mail. + + C. Mappings Specific to Internet Mail. + + D. Mappings Specific to Phonenet Mail. + + E. Mappings Specific to UUCP Mail. + + F. Format of Address Tables. + + 1.7. Acknowledgements + + This document is eclectic, and credit should be given: + + - Study of the EAN X.400 system code which performs this + function [Neufeld85a]. Some detailed clarification was + made by the DFN report on EAN [Bonacker85a]. + + - An unpublished ICL report, which considered a subset of + the problem [ICL84a]. + + - A document by Marshall Rose [Rose85a]. + + + +Kille [Page 7] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + - A document by Mark Horton [Horton85a]. The string + encodings of chapter 3 were derived directly from this + work, as is much of chapter 4. + + - Discussion on a number of electronic mailing lists. + + - Meetings in the UK and the US. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 8] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +Chapter 2 -- Service Elements + + RFC 822 and X.400 provide a number of services to the end user. This + document describes the extent to which each service can be supported + across an X.400 <-> RFC 822 gateway. The cases considered are single + transfers across such a gateway, although the problems of multiple + crossings are noted where appropriate. + + When a service element is described as supported, this means that + when this service element is specified by a message originator for a + recipient behind a gateway, that it is mapped by the gateway to + provide the service implied by the element. For example, if an + RFC 822 originator specifies a Subject: field, this is considered to + be supported, as an X.400 recipient will get a subject indication. + Support implies: + + - Semantic correspondence. + + - No loss of information. + + - Any actions required by the service element. + + For some services, the corresponding protocol elements map well, and + so the service can be fully provided. In other cases, the service + cannot be provided, as there is a complete mismatch. In the + remaining cases, the service can be partially fulfilled. The level + of partial support is summarised. + + NOTE: It should be clear that support of service elements on + reception is not a gatewaying issue. It is assumed that all + outbound messages are fully conforming to the appropriate + standards. + + 2.1. RFC 822 + + RFC 822 does not explicitly define service elements, as distinct + from protocol elements. However, all of the RFC 822 header + fields, with the exception of trace, can be regarded as + corresponding to implicit RFC 822 service elements. A mechanism + of mapping used in several cases, is to place the text of the + header into the body of the IP Message. This can usually be + regarded as partial support, as it allows the information to be + conveyed to the end user even though there is no corresponding + X.400 protocol element. Support for the various service elements + (headers) is now listed. + + + + +Kille [Page 9] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + Date: + + Supported. + + From: + + Supported. For messages where there is also a sender field, + the mapping is to "Authorising Addresses", which has subtly + different semantics to the general RFC 822 usage of From:. + + Sender: + + Supported. + + Reply-To: + + Supported. + + To: + + Supported. + + Cc: + + Supported. + + Bcc: + + Supported. + + Message-Id: + + Supported. + + In-Reply-To: + + Supported, for a single reference in msg-id form. Other + cases are passed in the message text. + + References: + + Supported. + + Keywords: + + Passed in the message text. + + + +Kille [Page 10] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + Subject: + + Supported. + + Comments: + + Passed in the message text. + + Encrypted: + + Passed in the message text. This may not be very useful. + + Resent-* + + Passed in the message text. In principle, these could be + supported in a fuller manner, but this is not suggested. + + Other Fields + + In particular X-* fields, and "illegal" fields in common + usage (e.g. "Fruit-of-the-day:") are passed in the message + text. + + 2.2. X.400 + + When mapping from X.400 to RFC 822, it is not proposed to map any + elements into the body of an RFC 822 message. Rather, new RFC 822 + headers are defined. It is intended that these fields will be + registered, and that co-operating RFC 822 systems may use them. + Where these new fields are used, and no system action is implied, + the service can be regarded as being almost supported. Chapter 5 + describes how to map these new headers in both directions. Other + elements are provided, in part, by the gateway as they cannot be + provided by RFC 822. Some service elements are are marked N/A + (not applicable). These elements are only applicable to User + Agent / Message Transfer Agent interaction and have no end-to-end + implication. These elements do not need to be mapped by the + gateway. + + 2.2.1. Message Transfer Service Elements + + Access Management + + N/A. + + + + + +Kille [Page 11] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + Content Type Indication + + Not mapped. As it can only have one value (P2), there is + little use in creating a new RFC 822 header field, unless it + was to distinguish delivery reports. + + Converted Indication + + Supported by a new RFC 822 header. + + Delivery Time Stamp Indication + + N/A. + + Message Identification + + Supported, by use of a new RFC 822 header. This new header + is required, as X.400 has two message-ids whereas RFC 822 + has only one. + + Non-delivery Notification + + Not supported, although in general an RFC 822 system will + return errors as IP messages. In other elements, this + pragmatic result is treated as effective support of this + service element. + + Original Encoded Information Types Indication + + Supported as a new RFC 822 header. + + Registered Encoded Information Types + + N/A. + + Submission Time Stamp Indication + + Supported. + + Alternate Recipient Allowed + + Not supported. Any value is ignored by the gateway. + + Deferred Delivery + + Support is optional. The framework is provided so that + messages may be held at the gateway. However, a gateway + + +Kille [Page 12] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + following this specification does not have to do this. This + is in line with the emerging functional standards. + + Deferred Delivery Cancellation + + Supported. + + Delivery Notification + + Supported at gateway. Thus, a notification is sent by the + gateway to the originator <2>. + + Disclosure of Other Recipients + + Supported by use of a new RFC 822 header. + + Grade of Delivery Selection + + Supported as a new RFC 822 header. In general, this will + only be for user information in the RFC 822 world. + + Multi-Destination Delivery + + Supported. + + Prevention of Non-delivery Notification + + Not Supported, as there is no control in the RFC 822 world + (but see Non-delivery Notification). + + Return of Contents + + This is normally the case, although the user has no control + (but see Non-delivery Notification). + + Conversion Prohibition + + Supported. Note that in practice this support is restricted + by the nature of the gateway. + + Explicit Conversion + + Supported, for appropriate values (See the IPMS Typed Body + service element). + + + + + +Kille [Page 13] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + Implicit Conversion + + Supported, in the sense that there will be implicit + conversion to IA5 in cases where this is practical. + + Probe + + Supported at the gateway (i.e. the gateway services the + probe). + + Alternate Recipient Assignment + + N/A. + + Hold for Delivery + + N/A. + + 2.2.2. Interpersonal Message Service Elements + + IP-message Identification + + Supported. + + Typed Body + + Supported. IA5 is fully supported. ForwardedIPMessage is + supported, with some loss of information. A subset of TTX + is supported (see section 5 for the specification of this + subset), with some loss of information. SFD may be + supported, with some loss of information. TTX and SFD are + only supported when conversion is allowed. Other types are + not supported. + + Blind Copy Recipient Indication + + Supported. + + Non-receipt Notification + + Not supported. + + Receipt Notification + + Not supported. + + + + +Kille [Page 14] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + Auto-forwarded Indication + + Supported as new RFC 822 header. + + Originator Indication + + Supported. + + Authorising User's Indication + + Supported, although the mapping (From:) is not quite the + same. + + Primary and Copy Recipients Indication + + Supported. + + Expiry Date Indication + + Supported as new RFC 822 header. In general, only human + action can be expected. + + Cross Referencing Indication + + Supported. + + Importance Indication + + Supported as new RFC 822 header. + + Obsoleting Indication + + Supported as new RFC 822 header. + + Sensitivity Indication + + Supported as new RFC 822 header. + + Subject Indication + + Supported. + + Reply Request Indication + + Supported as comment next to address. + + + + +Kille [Page 15] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + Forwarded IP-message Indication + + Supported, with some loss of information. + + Body Part Encryption Indication + + Not supported. + + Multi-part Body + + Supported, with some loss of information, in that the + structuring cannot be formalised in RFC 822. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 16] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +Chapter 3 -- Basic Mappings + + 3.1. Notation + + The P1 and P2 protocols are encoded in a structured manner + according to the X.409 specifications, whereas RFC 822 is text + encoded. To define a detailed mapping, it is necessary to refer + to detailed protocol elements in each format. This is described. + + 3.1.4. RFC 822 + + Structured text is defined according to the Extended Backus + Naur Form (EBNF) defined in section 2 of RFC 822 [Crocker82a]. + In the EBNF definitions used in this specification, the syntax + rules given in Appendix D of RFC 822 are assumed. When these + EBNF tokens are referred to outside an EBNF definition, they + are identified by the string "882." appended to the beginning + of the string (e.g. 822.addr-spec). Additional syntax rules, + to be used throughout this specification are defined in this + chapter. + + The EBNF is used in two ways. + + 1. To describe components of RFC 822 messages (or of + 822-P1 components). In this case, the lexical analysis + defined in section 3 of RFC 822 should be used. When + these new EBNF tokens are referred to outside an EBNF + definition, they are identified by the string "EBNF." + appended to the beginning of the string (e.g. + EBNF.bilateral-info). + + 2. To describe the structure of IA5 or ASCII information + not in an RFC 822 message. In these cases, tokens will + either be self delimiting, or be delimited by self + delimiting tokens. Comments and LWSP are not used as + delimiters. + + 3.1.5. X.409 + + An element is referred to with the following syntax, defined in + EBNF: + + element = protocol "." definition *( "." definition ) + protocol = "P1" / "P2" + definition = identifier / context + identifier = ALPHA *< ALPHA or DIGIT or "-" > + context = "[" 1*DIGIT "]" + + +Kille [Page 17] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + For example, P2.Heading.subject defines the subject element of + the P2 heading. The same syntax is also used to refer to + element values. For example, + P1.EncodedInformationTypes.[0].g3Fax refers to a value of + P1.EncodedInformationTypes.[0] . + + 3.2. ASCII and IA5 + + A gateway will interpret all IA5 as ASCII. Thus, they are treated + identically for the rest of this document. + + 3.3. Universal Primitives + + There is a need to convert between ASCII text, and some of the + Universal Primitive types defined in X.409 [CCITT84d]. For each + case, an EBNF syntax definition is given, for use in all of this + specification. All EBNF syntax definitions of Universal + Primitives are in lower case, whereas X.409 primitives are + referred to with the first letter in upper case. Except as noted, + all mappings are symmetrical. + + 3.3.1. Boolean + + Boolean is encoded as: + + boolean = "TRUE" / "FALSE" + + 3.3.2. NumericString + + NumericString is encoded as: + + numericstring = *DIGIT + + 3.3.3. PrintableString + + PrintableString is a restricted IA5String defined as: + + printablestring = *( ps-char / ps-delim ) + + ps-char = 1DIGIT / 1ALPHA / " " / "'" / "+" / ")" + / "," / "-" / "." / "/" / ":" / "=" / "?" + + ps-delim = "(" + + A structured subset of EBNF.printablestring is now defined. + This can be used to encode ASCII in the PrintableString + character set. + + +Kille [Page 18] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + ps-encoded = *( ps-char / ps-encoded-char ) + + ps-encoded-char = "(a)" ; (@) + / "(p)" ; (%) + / "(b)" ; (!) + / "(q)" ; (") + / "(u)" ; (_) + / "(" 3DIGIT ")" + + The 822.3DIGIT in EBNF.ps-encoded-char must have range 0-127 + (Decimal), and is interpreted in decimal as the corresponding + ASCII character. Special encodings are given for: at sign (@), + percent (%), exclamation mark/bang (!), double quote ("), and + underscore (_). These characters are not included in + PrintableString, but are common in RFC 822 addresses. The + abbreviations will ease specification of RFC 822 addresses from + an X.400 system. + + An asymmetric mapping between PrintableString and ASCII can now + be defined <3>. To encode ASCII as PrintableString, the + EBNF.ps-encoded syntax is used, with all EBNF.ps-char AND + EBNF.ps-delim mapped directly <4>. All other 822.CHAR are + encoded as EBNF.ps-encoded-char. There are two cases of + encoding PrintableString as ASCII. If the PrintableString can + be parsed as EBNF.ps-encoded, then the previous mapping should + be reversed. If not, it should be interpreted as + EBNF.printablestring. + + Some examples are now given. Note the arrows which indicate + asymmetrical mappings: + + PrintableString ASCII + + 'a demo.' <-> 'a demo.' + foo(a)bar <-> foo@bar + + (q)(u)(p)(q) <-> "_%" + (a) <-> @ + (a) <- (a) + (040)a(041) -> (a) + (040)(a) -> (@ + ((a) <- (@ + + The algorithm is designed so that it is simple to use in all + common cases, so that it is general, and so that it is + straightforward to code. It is not attempting to minimise the + number of pathological cases. + + +Kille [Page 19] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + 3.3.4. T.61String + + T.61 strings are, in general, only used for conveying human + interpreted information. Thus, the aim of a mapping should be + to render the characters appropriately in the remote character + set, rather than to maximise reversibility. The mappings + defined in the CEN/CENELEC X.400 functional standard should be + used [CEN/CENELEC/85a]. These are based on the mappings of + X.408 (sections 4.2.2 and 5.2.2). + + 3.3.5. UTCTime + + Both UTCTime and the RFC 822 822.date-time syntax contain: Year + (lowest two digits), Month, Day of Month, hour, minute, second + (optional), and Timezone. 822.date-time also contains an + optional day of the week, but this is redundant. Therefore a + symmetrical mapping can be made between these constructs <5>. + The UTCTime format which specifies the timezone offset should + be used, in line with CEN/CENELEC recommendations. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 20] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +Chapter 4 -- Addressing + + Addressing is probably the trickiest problem of an X.400 <-> RFC 822 + gateway. Therefore it is given a separate chapter. This chapter, as + a side effect, also defines a standard textual representation of + X.400 addresses. + + Initially we consider an address in the (human) mail user sense of + "what is typed at the mailsystem to reference a human". A basic + RFC 822 address is defined by the EBNF EBNF.822-address: + + 822-address = [ route ] addr-spec + + In an 822-P1 protocol, the originator and each recipient should be + considered to be defined by such a construct. In an RFC 822 header, + the EBNF.822-address is encapsulated in the 822.address syntax rule, + and there may also be associated comments. None of this extra + information has any semantics, other than to the end user. + + The basic X.400 address is defined by P1.ORName. In P1 all recipient + P1.ORnames are encapsulated within P1.RecipientInfo, and in P2 all + P2.ORNames <6> are encapsulated within P2.ORDescriptor. + + It can be seen that RFC 822 822.address must be mapped with + P2.ORDescriptor, and that RFC 822 EBNF.822-address must be mapped + with P1.ORName (originator) and P1.RecipientInfo (recipients). + + This chapter is structured as follows: + + 4.1 Introduction. + + 4.2 A textual representation of P1.ORName. This is needed for + the later mappings, and as a side effect provides a standard + representation for O/R names. + + 4.3 Mapping between EBNF.822-address and P1.ORName + + 4.4 The Full P1 / 822-P1 Mapping + + 4.5 The Full P2 / RFC 822 Mapping + + 4.6 Mapping Message-IDs. + + + + + + + +Kille [Page 21] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + 4.1. A textual representation of P1.ORName. + + P1.ORName is structured as a set of attribute value pairs. It is + clearly necessary to be able to encode this in ASCII for + gatewaying purposes. A general encoding is given here, which may + be used as a basis for a user interface, as well as for the + defined gateway mapping. + + 4.1.1. Basic Representation + + A series of BNF definitions of each possible attribute value + pair is given, which is given a 1:1 mapping with the X.400 + encoding. The rest of the mapping then talks in terms of these + BNF components, with the mapping to X.400 encoding being + trivial. + + attributevalue = c / admd / prmd / x121 / t-id / o / ou + / ua-id / pn.g / pn.i / pn.s / pn.gq / dd.value + + c = printablestring ; P1.CountryName + admd = printablestring ; P1.AdministrationDomainName + prmd = printablestring ; P1.PrivateDomainName + x121 = numericstring ; P1.X121Address + t-id = numericstring ; P1.TerminalID + o = printablestring ; P1.OrganisationName + ou = printablestring ; P1.OrganisationalUnit + ua-id = numericstring ; P1.UniqueUAIdentifier + pn.s = printablestring ; P1.PersonalName.surName + pn.g = printablestring ; P1.PersonalName.givenName + pn.i = printablestring ; P1.PersonalName.initials + pn.gq = printablestring ; P1.PersonalName.generation + Qualifier + dd.value = printablestring ; P1.DomainDefined + Attribute.value + + In cases where an attribute can be encoded as either a + PrintableString or NumericString (Country, ADMD, PRMD) it is + assumed that the NumericString encoding will be adopted if + possible. This prevents the encoding of PrintableString where + the characters are all numbers. This restriction seems + preferable to the added complexity of a general solution. + Similarly, we can define a set of attribute types. + + + + + + + +Kille [Page 22] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + dd.type = printablestring ; P1.DomainDefinedAttribute.type + + standard-type = + "C" ; P1.CountryName + / "ADMD" ; P1.AdministrationDomainName + / "PRMD" ; P1.PrivateDomainName + / "X121" ; P1.X121Address + / "T-ID" ; P1.TerminalID + / "O" ; P1.OrganisationName + / "OU" ; P1.OrganisationalUnit + / "UA-ID" ; P1.UniqueUAIdentifier + / "S" ; P1.PersonalName.surName + / "G" ; P1.PersonalName.givenName + / "I" ; P1.PersonalName.initials + / "GQ" ; P1.PersonalName.generationQualifier + + standard-dd-type = + "RFC-822" ; dd.type = "RFC-822" + / "JNT-Mail" ; dd.type = "JNT-Mail" + / "UUCP" ; dd.type = "UUCP" + + 4.1.2. Encoding of Personal Name + + Handling of Personal Name based purely on the + EBNF.standard-type syntax defined above is likely to be clumsy. + It seems desirable to utilise the "human" conventions for + encoding these components. A syntax is proposed here. It is + designed to cope with the common cases of O/R Name + specification where: + + 1. There is no generational qualifier + + 2. Initials contain only letters <7>. + + 3. Given Name does not contain full stop ("."), and is at + least two characters long. + + 4. If Surname contains full stop, then it may not be in + the first two characters, and either initials or given + name is present. + + + + + + + + + +Kille [Page 23] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + The following EBNF is defined: + + encoded-pn = [ given "." ] *( initial "." ) surname + + given = 2*<ps-char not including "."> + + initial = ALPHA + + surname = printablestring + + Subject to the above restriction, this is a reversible mapping. + + For example: + + GivenName = "Marshall" + Surname = "Rose" + + Maps with "Marshall.Rose" + + Initials = "MT" + Surname = "Rose" + + Maps with "M.T.Rose" + + GivenName = "Marshall" + Initials = "MT" + Surname = "Rose" + + Maps with "Marshall.M.T.Rose" + + Note that CCITT guidelines suggest that Initials is used to + encode ALL initials. Therefore, the proposed encoding is + "natural" when either GivenName or Initials, but not both, are + present. The case where both are present can be encoded, but + this appears to be contrived! + + 4.1.3. Two encodings of P1.ORName + + Given this structure, we can specify a BNF representation of an + O/R Name. + + + + + + + + + +Kille [Page 24] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + std-orname = 1*( "/" attribute "=" value ) "/" + attribute = standard-type + / "PN" + / standard-dd-type + / registered-dd-type + / "DD." std-printablestring + value = std-printablestring + registered-dd-type + = std-printablestring + std-printablestring = + = *( std-char / std-pair ) + std-char = <ps-delim, and any ps-char except "/" + and "="> + std-pair = "$" ( ps-delim / ps-char ) + + If the type is PN, the value is interpreted according to + EBNF.encoded-pn, and the components of P1.PersonalName derived + accordingly. If the value is registered-dd-type, if the value + is registered at the SRI NIC as an accepted Domain Defined + Attribute type, then the value should be interpreted + accordingly. This restriction maximises the syntax checking + which can be done at a gateway. + + Another syntax is now defined. This is intended to be + compatible with the syntax used for 822.domains. This syntax + is not intended to be handled by users. + + dmn-orname = dmn-part *( "." dmn-part ) + dmn-part = attribute "$" value + attribute = standard-type + / "~" dmn-printablestring + value = dmn-printablestring + dmn-printablestring = + = *( dmn-char / dmn-pair ) + dmn-char = <ps-delim, and any ps-char except "."> + dmn-pair = "\." + + For example: C$US.ADMD$ATT.~ROLE$Big\.Chief + + + + + + + + + + + +Kille [Page 25] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + 4.2. Mapping between EBNF.822-address and P1.ORName + + Ideally, the mapping specified would be entirely symmetrical and + global, to enable addresses to be referred to transparently in the + remote system, with the choice of gateway being left to the + Message Transfer Service. There are two fundamental reasons why + this is not possible: + + 1. The syntaxes are sufficiently different to make this + awkward. + + 2. In the general case, there would not be the necessary + administrative co-operation between the X.400 and RFC 822 + worlds, which would be needed for this to work. + + Therefore, an asymmetrical mapping is defined. + + 4.2.1. X.400 encoded in RFC 822 + + The std-orname syntax is used to encode O/R Name information + in the 822.local-part of EBNF.822-address. Further O/R Name + information may be associated with the 822.domain component. + This cannot be used in the general case, basically due to + character set problems, and lack of order in X.400 O/R Names. + The only way to encode the full PrintableString character set + in a domain is by use of the 822.domain-ref syntax. This is + likely to cause problems on many systems. The effective + character set of domains is in practice reduced from the + RFC 822 set, by restrictions imposed by domain conventions and + policy. + + A generic 822.address consists of a 822.local-part and a + sequence of 822.domains (e.g. + <@domain1,@domain2:user@domain3>). All except the 822.domain + associated with the 822.local-part (domain3 in this case) + should be considered to specify routing within the RFC 822 + world, and will not be interpreted by the gateway (although + they may have identified the gateway from within the RFC 822 + world). The 822.domain associated with the 822.local-part may + also identify the gateway from within the RFC 822 world. This + final 822.domain may be used to determine some number of O/R + Name attributes. The following O/R Name attributes are + considered as a hierarchy, and may be specified by the domain. + They are (in order of hierarchy): + + Country, ADMD, PRMD, Organisation, Organisational Unit + + + +Kille [Page 26] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + There may be multiple Organisational Units. + + Associations may be defined between domain specifications, and + some set of attributes. This association proceeds + hierarchically: i.e. if a domain implies ADMD, it also implies + country. If one of the hierarchical components is omitted from + an X.400 structure, this information can be associated with the + corresponding domain (e.g. a domain can be mapped onto a + Country/ADMD/Organisation tuple). Subdomains under this are + associated according to the O/R Name hierarchy. For example: + + => "AC.UK" might be associated with + C="234", ADMD="BT", PRMD="DES" + + then domain "R-D.Salford.AC.UK" maps with + C="234", ADMD="BT", PRMD="DES", O="Salford", OU="R-D" + + There are two basic reasons why a domain/attribute mapping + might be maintained, as opposed to using simply subdomains: + + 1. As a shorthand to avoid redundant X.400 information. + In particular, there will often be only one ADMD per + country, and so it does not need to be given + explicitly. + + 2. To deal with cases where attribute values do not fit + the syntax: + + domain-syntax = ALPHA [ *alphanumhyphen alphanum ] + alphanum = <ALPHA or DIGIT> + alphanumhyphen = <ALPHA or DIGIT or HYPHEN> + + Although RFC 822 allows for a more general syntax, this + restriced syntax is chosen as it is the one chosen by the + various domain service administrations. + + This provides a general aliasing mechanism. + + This set of mappings need only be known by the gateways + relaying between the RFC 822 world, and the O/R Name namespace + associated with the mapping in question. However, it is + desirable (for the optimal mapping of third party addresses) + for all gateways to know these mappings. A format for the + exchange of this information is defined in Appendix F. + + From the standpoint of the RFC 822 Message Transfer System, the + domain specification is simply used to route the message in the + + +Kille [Page 27] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + standard manner. The standard domain mechanisms are used to + identify gateways, and are used to select appropriate gateways + for the corresponding O/R Name namespace. In most cases, this + will be done by registering the higher levels, and assuming + that the gateway can handle the lower levels. + + As a further mechanism to simplify the encoding of common + cases, where the only attributes to be encoded on the LHS are + Personal Name attributes which comply with the restrictions of + 4.2.2, the 822.local-part may be encoded as EBNF.encoded-pn. + + An example encoding is: + + /PN=J.Linnimouth/GQ=5/@Marketing.Xerox.COM + + encodes the P1.ORName consisting of + + P1.CountryName = "US" + P1.AdministrationDomainName = "ATT" + P1.OrganisationName = "Xerox" + P1.OrganisationalUnit = "Marketing" + P1.PersonalName.surName = "Linnimouth" + P1.PersonalName.initials = "J" + P1.PersonalName.GenerationQualifier = "5" + + If the GenerationQualifier was not present, the encoding + J.Linnimouth@Marketing.Xerox.COM could be used. + + Note that in this example, the first three attributes are + determined by the domain Xerox.COM. The OrganisationalUnit is + determined systematically. + + There has been an implicit assumption that an RFC 822 domain is + either X.400 or RFC 822. This is pragmatic, but undesirable, + as the namespace should be structured on a logical basis which + does not necessarily correspond to the choice of Message + Transfer protocols. The restriction can be lifted, provided + that the nameservice deals with multiple message transfer + protocols. This can happen in a straightforward manner for the + UK NRS, as explained in [Kille86a]. It could also be achieved + with the DARPA Domain Nameserver scheme by use of the WKS + mechanism. + + + + + + + +Kille [Page 28] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + 4.2.2. RFC 822 Encoded in X.400 + + In some cases, the encoding defined above may be reversed, to + give a "natural" encoding of genuine RFC 822 addresses. This + depends largely on the allocation of appropriate management + domains. + + The general case is mapped by use of domain defined attributes. + Three are defined, according to the full environment used to + interpret the RFC 822 information. + + 1. Domain defined type "RFC-822". This string is to be + interpreted in the context of RFC 822, and RFC 920 + [Crocker82a,Postel84a]. + + 2. Domain defined type "JNT-Mail". This string is to be + interpreted in the context of the JNT Mail protocol, + and the NRS [Kille84a,Larmouth83a]. + + 3. Domain defined type "UUCP". This is interpreted + according to the constraints of the UUCP world + [Horton86a]. + + These three are values currently known to be of use. Further + recognised values may be defined. These will be maintained in + a list at the SRI Network Information Center. + + Other O/R Name attributes will be used to identify a context in + which the O/R Name will be interpreted. This might be a + Management Domain, or some part of a Management Domain which + identifies a gateway MTA. For example: + + 1) + + C = "GB" + ADMD = "BT" + PRMD = "AC" + "JNT-Mail" = "Jimmy(a)UK.CO.BT-RESEARCH-LABS" + + 2) + + C = "US" + ADMD = "Telemail" + PRMD = "San Fransisco" + O = "U Cal" + OU = "Berkeley" + "RFC-822" = "postel(a)usc-isib.arpa" + + +Kille [Page 29] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + Note in each case the PrintableString encoding of "@" as "(a)". + In the first example, the "JNT-Mail" domain defined attribute + is interpreted everywhere within the (Administrative or + Private) Management Domain. In the second example, further + attributes are needed within the Management Domain to identify + a gateway. Thus, this scheme can be used with varying levels + of Management Domain co-operation. + + 4.2.3. RFC 822 -> X.400 + + There are two basic cases: + + 1. X.400 addresses encoded in RFC 822. This will also + include RFC 822 addresses which are given reversible + encodings. + + 2. "Genuine" RFC 822 addresses. + + The mapping should proceed as follows, by first assuming case + 1). + + STAGE 1. + + 1. If the 822-address is not of the form: + + local-part "@" domain + + go to stage 2. + + 2. Attempt to parse domain as: + + *( domain-syntax "." ) known-domain + + Where known-domain is the longest possible match in a + list of gatewayed domains. If this fails, and the domain + does not explicitly identify the local gateway, go to + stage 2. If it succeeds, allocate the attributes + associated with EBNF.known-domain, and systematically + allocate the attributes implied by each + EBNF.domain-syntax component. + + 3. Map 822.local-part to ASCII, according to the + definition of Appendix A. This step should be applied: + + A. If the source network cannot support + 822.quoted-string (as discussed in Appendix A). + + + +Kille [Page 30] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + B. If the address is an 822-P1 recipient. + + This mapping is always applied in case B, as it + increases the functionality of the gateway, and does + not imply any loss of generality. Mapping case B + allows sites which cannot generate 822.quoted-string + to address recipients the gateway, without the gateway + having to know this explicitly. There is no loss of + functionality, as the quoting character of Appendix A + (#) is not in PrintableString. This seems desirable. + It should not be applied in to other addresses, as a + third party RFC#822 address containing the sequence + EBNF.atom-encoded (as defined in Appendix A) would be + transformed asymmetrically. + + 4. Map the result of 3) to EBNF.ps-encoded according to + section 3. + + 5. Parse the result of 4) according to the EBNF + EBNF.std-orname. If this parse fails, parse the result + of 4) according to the EBNF EBNF.encoded-pn. If this + also fails, go to stage 2. Otherwise, the result is a + set of type/value pairs. + + 6. Associate the EBNF.attribute-value syntax (determined + from the identified type) with each value, and check + that it conforms. If not, go to stage 2. + + 7. Ensure that the set of attributes conforms both to the + X.411 P1.ORName specification and to the restrictions + on this set given in X.400. If not go to stage 2. + + 8. Build the O/R Name from this information. + + STAGE 2. + + This will only be reached if the RFC 822 EBNF.822-address is + not a valid X.400 encoding. If the address is an 822-P1 + recipient address, it must be rejected, as there is a need to + interpret such an address in X.400. For the 822-P1 return + address, and any addresses in the RFC 822 header, they should + now be encoded as RFC 822 addresses in an X.400 O/R Name: + + 1. Convert the EBNF.822-address to PrintableString, as + specified in chapter 3. + + 2. The domain defined attribute ("RFC-822", "JNT-Mail" or + + +Kille [Page 31] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + "UUCP") appropriate to the gateway should be selected, + and its value set. + + 3. Build the rest of the O/R Name in the local Management + Domain agreed manner, so that the O/R Name will receive + a correct global interpretation. + + 4.2.4. X.400 -> RFC 822 + + There are two basic cases: + + 1. RFC 822 addresses encoded in X.400. + + 2. "Genuine" X.400 addresses. This may include + symmetrically encoded RFC 822 addresses. + + When a P1 Recipient O/R Name is interpreted, gatewaying will be + selected if there a single special domain defined attribute + present ("RFC-822", "JNT-Mail" or "UUCP"). In this case, use + mapping A. For other O/R Names which + + 1. Contain the special attribute. + + AND + + 2. Identify the local gateway with the other attributes. + + Use mapping A. In other cases, use mapping B. + + Mapping A + + 1. Map the domain defined attribute value to ASCII, as + defined in chapter 3. + + 2. Where appropriate (P1 recipients), interpret the string + according to the semantics implied by the domain + defined attribute. + + Mapping B. + + This will be used for X.400 addresses which do not use the + explicit RFC 822 encoding. + + 1. Noting the hierarchy specified in 4.3.1, determine the + maximum set of attributes which have an associated + domain specification. If no match is found, allocate + + + +Kille [Page 32] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + the domain as the domain specification of the local + gateway, and go to step 4. + + 2. Following the 4.3.1 hierarchy, if each successive + component exists, and conforms to the syntax + EBNF.domain-syntax (as defined in 4.3.1), allocate the + next subdomain. + + 3. If the remaining components are personal-name + components, conforming to the restrictions of 4.2.2, + then EBNF.encoded-pn should be derived to form + 822.local-part. In other cases the remaining + components should simply be encoded as a 822.local-part + using the EBNF.std-orname syntax. Where registered + domain defined types exist, the DD. syntax should not + be used. + + 4. If this step is reached for an 822-P1 recipient, then + the address is invalid. For other addresses, if the + derived 822.local-part can only be encoded by use of + 822.quoted-string, the gateway may optionally use the + ASCII to 822.local-part mapping defined in Appendix A, + dependent on the mail protocols of the networks being + relayed to. Use of this encoding is discouraged. + + 4.3. Repeated Mappings + + The mappings defined are symmetrical across a single gateway, + except in certain pathological cases (see chapter 3). However, it + is always possible to specify any valid address across a gateway. + This symmetry is particularly useful in cases of (mail exploder + type) distribution list expansion. For example, an X.400 user + sends to a list on an RFC 822 system which he belongs to. The + received message will have the originator and any 3rd party X.400 + O/R names in correct format (rather than doubly encoded). In + cases (X.400 or RFC 822) where there is common agreement on + gateway identification, then this will apply to multiple gateways. + + However, the syntax may be used to source route. + + For example: X.400 -> RFC 822 -> X.400 + + C = "UK" + ADMD = "BT" + PRMD = "AC" + "JNT-Mail" = "/PN=Duval/DD.Title=Manager/(a)FR.PTT.Inria" + + + +Kille [Page 33] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + This will be sent to an arbitrary UK Academic Community gateway + by X.400. Then by JNT Mail to another gateway determined by + the domain FR.PTT.Inria. This will then derive the X.400 O/R + Name: + + C = "FR" + ADMD = "PTT" + PRMD = "Inria" + PN.S = "Duval" + "Title" = "Manager" + + Similarly: RFC 822 -> X.400 -> RFC 822 + + "/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj(a)seismo.css.gov/" + @monet.berkeley.edu + + /C=UK/ADMD=BT/PRMD=AC/RFC-822=jj#l#a#r#seismo.css.gov/ + @monet.berkeley.edu + + The second case uses the Appendix A encoding to avoid + 822.quoted-text. This will be sent to monet.berkeley.edu by + RFC 822, then to the AC PRMD by X.400, and then to + jj@seismo.css.gov by RFC 822. + + 4.4. The full P1 / 822-P1 mapping + + There are two basic mappings at the P1 level: + + 1. 822-P1 return address <-> P1.UMPDUEnvelope.originator + + 2. 822-P1 recipient <-> P1.RecipientInfo + + 822-P1 recipients and return addresses are encoded as + EBNF.822-address. As P1.UMPDUEnvelope.originator is encoded as + P1.ORName, mapping 1) has already been specified. + P1.RecipientInfo contains a P1.ORName and additional information. + The handling of this additional information is now specified. + + 4.4.1. RFC 822 -> X.400 + + The following default settings should be made for each + component of P1.RecipientInfo. + + P1.ExtensionIdentifier + + This can be set systematically by the X.400 system. + + + +Kille [Page 34] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + P1.RecipientInfo.perRecipientFlag + + Responsibility Flag should be set. Report Request should + be set according to content return policy, as discussed + in section 5.3. User Report Request should be set to + Basic. + + P1.ExplicitConversion + + This optional component should be omitted. + + 4.4.2. X.400 -> RFC 822 + + The mapping only takes place in cases where + P1.RecipientInfo.perRecipientFlag Responsibility Flag is set. + The following treatment should be given to the other + P1.RecipientInfo components. + + P1.ExtensionIdentifier + + Not used. + + P1.RecipientInfo.perRecipientFlag + + If ReportRequest is Confirmed or Audit-and-Confirmed then + a delivery report indicating success should be sent by + the gateway. This report should use each + P1.ReportedRecipientInfo.SupplementaryInformation to + indicate the identity of the gateway, and the nature of + the report (i.e. only as far as the gateway). Failures + will be handled by returning RFC 822 messages, and so + User Report Request set to No report is ignored. + + P1.ExplicitConversion + + If present, the O/R name should be rejected, unless the + requested conversion can be achieved. None of the + currently recognised values of this parameter are + appropriate to a gateway using this specification. + + + + + + + + + + +Kille [Page 35] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + 4.5. The full P2 / RFC 822 mapping + + All RFC 822 addresses are assumed to use the 822.mailbox syntax. + This should include all 822.comments associated with the lexical + tokens of the 822.mailbox. All P2.ORNames are encoded within the + syntax P2.ORDescriptor, or P2.Recipient (or within Message IDs). + An asymmetrical mapping is defined between these components. + + 4.5.1. RFC 822 -> X.400 + + The following sequence is followed. + + 1. Take the address, and extract an EBNF.822-address. + This can be derived trivially from either the + 822.addr-spec or 822.route-addr syntax. This is mapped + to P2.ORName as described above. + + 2. A string should be built consisting of (if present): + + - The 822.phrase component if it is a 822.phrase + 822.route-addr construct. + + - Any 822.comments, in order, retaining the + parentheses. + + This string should then be encoded into T.61 (as + described in chapter 3). If the string is not null, + it should be assigned to P2.ORDescriptor.freeformName. + + 3. P2.ORDescriptor.telephoneNumber should be omitted. + + 4. In cases of converting to P2.Recipient, + P2.Recipient.replyRequest and + P2.Recipient.reportRequest should be omitted. + + If the 822.group construct is present, each included + 822.mailbox should be encoded as above. The 822.group should + be mapped to T.61, and a P2.ORDesciptor with only a + freeformName component built from it. + + 4.5.2. X.400 -> RFC 822 + + In the basic case, where P2.ORName is present, proceed as + follows. + + 1. Encode P2.ORName as EBNF.822-address. + + + +Kille [Page 36] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + 2a. If P2.ORDescriptor.freeformName is present, convert it + to ASCII (chapter 3), and use use this as the + 822.phrase component of 822.mailbox using the + 822.phrase 822.route-addr construct. + + 2b. If P2.ORDescriptor.freeformName is absent, if + EBNF.822-address is parsed as 822.addr-spec use this as + the encoding of 822.mailbox. If EBNF.822-address is + parsed as 822.route 822.addr-spec, then a 822.phrase + taken from 822.local-part should be added. + + 3. If P2.ORDescriptor.telephoneNumber is present, this + should be placed in a trailing 822.comment. + + 4. If P2.Recipient.reportRequest has the + receiptNotification bit set, then an 822.comment + "(Receipt Notification Requested)" should be appended + to the address. The effort of correlating P1 and P2 + information is too great to justify the gateway sending + Receipt Notifications. + + 5. If P2.Recipient.replyRequest is present, an 822.comment + "(Reply requested)" or "(Reply not requested)" should + be appended to the address, dependent on its value. + + If P2.ORName is absent, P2.ORDescriptor.freeformName should be + converted to ASCII, and used with the RFC 822 822.group syntax: + + freeformname ":" ";" + + Steps 3-5 should then be followed. + + 4.6. Message IDs + + There is a need to map both ways between 822.msg-id and + P2.IPMessageID. A mapping is defined which is symmetrical for + non-pathological cases. The mapping allows for the fact that + P2.IPMessageID.PrintableString is mandatory for the Cen/Cenelec + profile. This allows for good things to happen when messages pass + multiple times across the X.400/RFC 822 boundary. A mapping + between 822.msg-id and P1.MPDUIdentifier is defined. This allows + for X.400 error messages to reference an RFC 822 ID, which is + preferable to a gateway generated ID. + + + + + + +Kille [Page 37] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + 4.6.1. P2.IPMessageID -> 822.msg-id + + P2.IPMessageID.ORName is used to generate an 822.addr-spec, as + defined above. P2.IPMessageID.PrintableString is mapped to + ASCII, as defined in chapter 3. This string (if it is present + and if the value is not "RFC-822") is appended to the front of + the 822.local-part of the 822.msg-id, with "*" as a separator. + If no ORName is present, an 822.msg-id of the form + "PrintableString*@gateway-domain" is generated. + + 4.6.2. 822.msg-id -> P2.IPMessageID + + 822.local-part is parsed as: + + [ printablestring "*" ] real-local-part + + If EBNF.printablestring is found, it is mapped to + PrintableString, and used as P2.IPMessageID.PrintableString. + Otherwise + P2.IPMessageID.PrintableString is set to "RFC-822". This + arbitrary value allows for conformance to Cen/Cenelec. If + EBNF.real-local-part is not present, no P2.IPMessageID.ORName + is generated. Otherwise, 822.local-part is replaced with + EBNF.real-local-part, and 822.addr-spec is mapped to + P2.IPMessageID.ORName as defined above. + + 4.6.3. 822.msg-id -> P1.MPDUIdentifier + + P1.CountryName is assigned to "", P1.AdministrationDomainName + to 822.domain (from 822.msg-id) and P1.MPDUIdentifier.IA5String + to 822.local-part (from 822.msg-id). + + 4.6.4. P1.MPDUIdentifier -> 822.msg-id + + 822.local-part is set to P1.MPDUIdentifier.IA5String, with any + CRLF mapped to SPACE. If P1.CountryName is "", 822.domain is + set to P1.AdministrationDomainName; Otherwise to + P1.AdministrationDomainName ".." P1.CountryName. If there are + any specials, the domain literal encoding should be used. + + + + + + + + + + +Kille [Page 38] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +Chapter 5 -- Protocol Elements + + This chapter gives detailed mappings for the functions outlined in + chapters 1 and 2. It makes extensive use of the notations and + mappings defined in chapters 3 and 4. This chapter is structured as + follows: + + 5.1. Basic RFC 822 -> X.400 mappings + + 5.2. A definition of some new RFC 822 elements, and their mapping + to X.400. + + 5.3 Some special handling associated with Return of Contents. + + 5.4. X.400 -> RFC 822 + + 5.1. RFC 822 -> X.400 + + First, the basic functions of an 822-P1 protocol should be mapped + as follows: + + 822-P1 Originator + + Mapped to P1.UMPDUEnvelope.originator (see chapter 4). + + 822-P1 Recipient + + Mapped to P1.RecipientInfo (see chapter 4). + + The RFC 822 headers are used to generate both a P1.UMPDUEnvelope + and a P2.Heading. The IP Message will have either one or two + P2.BodyParts which will be type P2.IA5Text with no + P2.IA5Text.repertoire component. The last P2.BodyPart will contain + the RFC 822 message body. If there are any RFC 822 headers which + indicate mapping into the P2.BodyPart, then two P2.BodyParts are + generated. If a revised version of P2 allowed for extensible + header specification, this would be seen as a preferable mapping. + The first body part will start with the line: + + RFC-822-Headers: + + The rest of this body part will contain all of the headers not + otherwise mapped (both 822.field-name and 822.field-body). The + order of any such headers should be preserved. Similarly, + ordering within P2.Heading and P1.UMPDUEnvelope should reflect + ordering within the RFC 822 header. No P1 or P2 optional fields + are generated unless specified. + + +Kille [Page 39] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + A pro-forma X.400 message is now specified. Some of these + defaults may be changed by the values in the RFC 822 message being + mapped. The mandatory P1 and P2 components have the following + defaults. + + P1.MPDUIdentifier + + The default should be unique value generated by the gateway. + + P1.OriginatorORName + + Always generated from 822-P1. + + P1.ContentType + + P1.ContentType.p2 + + P1.RecipientInfo + + These will always be supplied from 822-P1. + + P1.Trace + + The last P1.TraceInformation component is generated such + that: P1.TraceInformation.GlobalDomainIdentifier is set to + the local vaglue. P1.DomainSuppliedInfo.action is set to + relayed. P1.DomainSuppliedInfo.arrival is set to the current + time. P1.DomainSuppliedInfo.previous may be set if there is + anything sensible to set it to. + + P2.IPMessageID + + The default should be a unique value generated by the + gateway. + + The following optional parameters should be set: + + P1.PerMessageFlag + + The P1.PerMessageFlag.contentReturnRequest bit should be set + according to the discussion in section 5.3. The + P1.PerMessageFlag.alternateRecipientAllowed bit should be + set, as it seems desirable to maximise opportunity for + (reliable) delivery. + + + + + +Kille [Page 40] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + The RFC 822 headings should be mapped as follows: + + Received: + + Fudged onto P1.TraceInformation (try not to grimace too + much). P1.DomainSuppliedInfo.action is set to relayed. + P1.DomainSuppliedInfo.arrival is set to the date-time + component P1.TraceInformation.GlobalDomainIdentifier has + P1.CountryName as a null string, and + P1..AdministrationDomainName as the domain of the receiving + host (if present - null string if not). + P1.DomainSuppliedInfo.previous has P1.CountryName as a null + string, and P1.AdministrationDomainName has the domain of + the sending host with all other information enclosed in + round parentheses. The encoding of ASCII to PrintableString + (chapter 3) should be used if needed. For example: + + Received: from 44e.cs.ucl.ac.uk by vax2.Cs.Ucl.AC.UK + with SMTP id a002110; 18 Dec 85 10:40 GMT + + maps to - + + P1.GlobalDomainIdentifier + CountryName = "" + AdministrationDomainName = "vax2.Cs.Ucl.AC.UK" + P1.DomainSuppliedInfo + arrival = 18 Dec 85 10:40 GMT + action = relayed + previous + CountryName = "" + AdministrationDomainName = + "44e.cs.ucl.ac.uk (with SMTP id a002110)" + + Date: + + This is used to set the first component of + P1.TraceInformation. The mandatory components are set as + follows: + + P1.GlobalDomainIdentifier + CountryName = "" + AdministrationDomainName = "" + P1.DomainSuppliedInfo + arrival = time derived from Date: + action = relayed + + No optional fields are used in the trace. + + +Kille [Page 41] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + Message-Id: + + Mapped to P2.IPMessageID. If the RFC 822 message does not + contain a P1-Message-ID: field, the Message-Id: field is + also mapped to P1.MPDUIdentifier. For these, and all other + fields containing msg-id the mappings of chapter 4 are used + for each msg-id. + + From: + + If Sender: is present, this is mapped to + P2.AuthorisingUsers. If not, it is mapped to P2.Originator. + For this, and other components containing addresses, the + mappings of chapter 4 are used for each address. + + Sender: + + Mapped to P2.Originator. + + Reply-To: + + Mapped to P2.Heading.replyToUsers. + + To: + + Mapped to P2.Heading.primaryRecipients + + Cc: + + Mapped to P2.Heading.copyRecipients. + + Bcc: + + Mapped to P2.Heading.blindCopyRecipients. + + In-Reply-To: + + Mapped to P2.Heading.inReplyTo for the first (if any) + 822.msg-id component. If the field contains an 822.phrase + component, or there are multiple 822.msg-id components, the + ENTIRE field is passed in the P2.BodyPart. + + References: + + Mapped to P2.Heading.crossReferences. + + + + +Kille [Page 42] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + Keywords: + + Passed in the P2.BodyPart. + + Subject: + + Mapped to P2.Heading.subject. The field-body uses the + mapping referenced in chapter 3 from ASCII to T.61. + + Comments: + + Passed in the P2.BodyPart. + + Encrypted: + + Passed in the P2.BodyPart. + + Resent-* + + Passed in the P2..BodyPart <8>. + + Other Fields + + In particular X-* fields, and "illegal" fields in common + usage (e.g. "Fruit-of-the-day:") are passed in the + P2.BodyPart. The same treatment should be applied to + RFC 822 fields where the content of the field does not + conform to RFC 822 (e.g. a Date: field with unparsable + syntax). + + 5.2. Extended RFC 822 Elements -> X.400 + + First an EBNF definition of a number of extended fields is given, + and then a mapping to X.400 is defined. In most cases, the + RFC 822 syntax is defined to make this mapping very + straightforward, and so no detailed explanation of the mapping is + needed. + + extended-field = "P1-Message-ID" ":" p1-msg-id + / "X400-Trace" ":" x400-trace + / "Original-Encoded-Information-Types" + ":"encoded-info + / "P1-Content-Type" ":" p1-content-type + / "UA-Content-ID" ":" printablestring + / "Priority" ":" priority + / "P1-Recipient" : 1 mailbox + / "Deferred-Delivery" ":" date-time + + +Kille [Page 43] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + / "Bilateral-Info" ":" bilateral-info + / "Obsoletes" ":" 1 msg-id + / "Expiry-Date" ":" date-time + / "Reply-By" ":" date-time + / "Importance" ":" importance + / "Sensitivity" ":" sensitivity + / "Autoforwarded" ":" boolean + + p1-msg-id = global-id ";" *text + + p1-content-type = "P2" / atom + + x400-trace = global-id ";" + "arrival" date-time + [ "deferred" date-time ] + [ "action" action ] + [ "converted" "(" encoded-info ")" ] + [ "previous" global-id ] + + action = "Relayed" / "Rerouted" / escape + + global-id = c "*" admd [ "*" prmd ] + + encoded-info = 1 encoded-type + + encoded-type = "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) + / escape + + priority = "normal" / "non-urgent" / "urgent" / escape + + bilateral-info = c "*" admd "*" *text + + importance = "low" / "normal" / "high" / escape + + sensitivity = "Personal" / "Private" + / "Company-Confidential" / escape + + escape = 1*DIGIT + + +Kille [Page 44] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + With the exception of "Bilateral-Info:" and "X400-Trace:", there + must be no more than one of each of these fields in an RFC 822 + header. Any field beginning with the String "Autoforwarded-" is + valid if the field would be syntactically valid with this string + removed. + + The mappings to X.400 are as follows: + + P1-Message-ID: + + Mapped to P1.UMPDUEnvelope.MPDUIdentifier. This take + precedence over any value derived from Message-ID:. + + X400-Trace: + + Mapped to the next component of + P1.UMPDUEnvelope.Traceinformation. Care should be taken to + preserve order. If one or more of these mappings is made, + then a trace component should NOT be generated from the + Date: field which should be redundant. This is because the + message has previously come from X.400, and the Date: + information will be redundant. Note that all trace + information (Received: and "X400-Trace:") in the RFC 822 + message will be in strict order, with the most recent at the + top. This order should be preserved in the mapping. + + Original-Encoded-Information-Types: + + This is used to set P1.UMPDUEnvelope.original. + P1.EncodedInformationTypes.[0] has bits set according to + each of the encoded-info components in this field. Any + escape values should not be encoded. + + P1-Content-Type: + + If the value is anything other than "P2", the mapping should + not be performed (unless the new value has some semantics to + the gateway). + + UA-Content-ID: + + Mapped to P1.UMPDUEnvelope.UAContentID. + + Priority: + + Mapped to P1.UMPDUEnvelope.Priority. An escape value should + be encoded as P1.Priority.normal. + + +Kille [Page 45] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + P1-Recipient: + + If this field is set, the + P1.PerMessageFlag.discloseRecipients bit should be set. Any + of the addresses here which do not correspond to 822-P1 + recipients should be added to the P1 recipient list, with + the responsibility bit turned off. + + Deferred-Delivery: + + Mapped to P1.UMPDUEnvelope.deferredDelivery. Note that the + value of this field should always be in the past, as this + field should only be present in messages which have come + originally from X.400. Thus there should be no implied + action. See also the comments on the reverse mapping. + + Bilateral-Info: + + No attempt is made to reconvert this information back to + X.400. + + Obsoletes: + + Mapped to P2.Heading.obsoletes. + + Expiry-Date: + + Mapped to P2.Heading.expiryDate. + + Reply-By: + + Mapped to P2.Heading.replyBy. + + Importance: + + Mapped to P2.Heading.importance. An escape value should be + encoded as P2.Heading.importance.normal. + + Sensitivity: + + Mapped to P2.Heading.sensitivity. An escape value should be + encoded as P2.Heading.sensitivity.normal. + + Autoforwarded: + + If this field is present and the value is "TRUE", there will + be zero or more field names beginning "Autoforwarded-". + + +Kille [Page 46] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + These should be taken, and the string "Autoforwarded-" + stripped. These fields, in conjunction with the 822-P1 + information should be used to build an IP Message. Any + implied actions should be taken. P2.Heading.autoforwarded is + set in this message. The other RFC 822 fields are used to + build another IP Message, which is used as the single body + part of the first message. This mechanism does not nest. + + 5.3. Return of Contents + + It is not clear how widely supported X.400 return of contents + service will be. However, profiling work suggests that most + systems will not support this service. As this service is + expected in the RFC 822 world, two approaches are specified (it is + not so necessary in the X.400 world, as delivery reports are + distinguished from messages). The choice will depend on the + service level of the X.400 community being serviced by the + gateway. + + In environments where return of contents is widely supported, the + P1.PerMessageFlag content return request bit will be set, and the + Report Request bit in P1.PerRecipientFlag will be set to + Confirmed, for every message passing from RFC 822 -> X.400. The + content return service can then be passed back to the end + (RFC 822) user in a straightforward manner. + + In environments where return of contents is not widely supported, + a gateway must make special provisions to handle return of + contents. For every message passing from RFC 822 -> X.400, the + P1.PerMessageFlag content return request bit will be set, and the + Report Request bit in P1.PerRecipientFlag will be set to + Confirmed. When the delivery report comes back, the gateway can + note that the message has been delivered to the recipient(s) in + question. If a non-delivery report is received, a meaningful + report (containing some or all of the original message) can be + sent to the 822-P1 originator. If no report is received for a + recipient, a (timeout) failure notice should be sent to the 822-P1 + originator. The gateway may retransmit the X.400 message if it + wishes. Delivery confirmations should only be sent back to the + 822-P1 originator if the P1.PerRecipientFlag User Report Request + bit is set to Confirmed. + + + + + + + + +Kille [Page 47] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + 5.4. X.400 -> RFC 822 + + 5.4.1. General + + This section describes how to build a pro-forma message, and + then explains how these defaults may be overridden. It should + be noted that RFC 822 folding of headers should be used in an + appropriate manner. + + 5.4.2. Service MPDU + + 5.4.2.1. Probe + + Any P1.ProbeMPDU should be serviced by the gateway, as there + is no equivalent RFC 822 functionality. The value of the + reply is dependent on whether the gateway could service a + User MPDU with the values specified in the probe. The reply + should make use of P1.SupplementaryInformation to indicate + that the probe was serviced by the gateway. + + 5.4.2.2. Delivery Report + + The 822-P1 components are constructed as follows: + + 822-P1 Originator + + This is set to an 822.addr-spec pointing to an + administrator at the gateway. + + 822-P1 Recipient + + The single recipient is constructed from + P1.DeliveryReportEnvelope.originator, using the + mappings of chapter 4. + + The mandatory RFC 822 headers for an RFC 822 pro-forma are + constructed as follows: + + Date: + + From the P1.DomainSuppliedInfo.arrival component of + the first P1.TraceInformation component. + + From: + + This is set to the same as the 822-P1 originator. An + + + +Kille [Page 48] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + appropriate phrase component may be added (e.g. giving + the name of the gateway). + + To: + + The same as the 822-P1 recipient. + + A Subject: field should be added, which contains some + appropriate words (e.g. "Delivery Report"). + + The other two P1.DeliveryReportEnvelope parameters should be + mapped as follows: + + P1.DeliveryReportEnvelope.report + + This should be mapped to a P1-Message-Id: field. + + P1.DeliveryReportEnvelope.TraceInformation + + Each component should be mapped to an "X400-Trace:" + field. RFC 822 and X.400 ordering should be + maintained (see 5.3). + + The P1.DeliveryReportContent parameters should be mapped to + a series of new RFC 822 headers. These new headers are + intended for processing in the RFC 822 world. No attempt + will be made to reverse the mappings. + + drc-field = "Delivery-Report-Content-Original" + ":" msg-id + / "Delivery-Report-Content-Intermediate-Trace" + ":" x400-trace + / "Delivery-Report-Content-UA-Content-ID" + ":" printablestring + / "Delivery-Report-Content-Billing-Information" + ":" *text + / "Delivery-Report-Content-Reported-Recipient-Info" + ":" drc-info + + drc-info = mailbox ";" + last-trace ";" + "ext" 1*DIGIT + "flags" 2DIGIT + [ "intended" mailbox ] ";" + [ "info" printablestring ] + + + + +Kille [Page 49] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + last-trace = drc-report ";" + date-time ";" + [ "converted" "(" encoded-info ")" + + drc-report = "SUCCESS" drc-success + / "FAILURE" drc-failure + + drc-success = date-time ";" 1*DIGIT + + drc-failure = *text [ ";" *text ] ";" + + There may be multiple + "Delivery-Report-Content-Intermediate-Trace:" and + "Delivery-Report-Content-Reported-Recipient-Info:" fields. + The msg-id for "Delivery-Report-Content-Original" is derived + according to the mapping of chapter 4. EBNF.drc-failure may + use numeric values or textual explanation. The latter is + preferred. All P1.DeliveryReportContent parameters are + mapped to the corresponding component. The order of + "Delivery-Report-Content-Intermediate-Trace:" should have + the most recently stamped one first. + + The body of the RFC 822 message should be a human readable + description of the critical parts of the + P1.DeliveryReportContent. In particular, the failed + recipients, and failure reason should be given. Some or all + of the original message should be included in the delivery + report. The original message will be available at the + gateway, as discussed in section 5.3. + + 5.4.3. User MPDU + + These elements are the basis for both Status Report and IP + Message. + + The 822-P1 components are constructed as follows: + + 822-P1 Originator + + This is derived from P1.UMPDUEnvelope.originator. + + 822-P1 Recipient + + Each recipient is constructed from the P1.RecipientInfo, + as described in chapter 4. This describes actions as + well as format mappings. + + + +Kille [Page 50] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + The mandatory RFC 822 field pro-forma is derived as follows. + In most cases where the P1.UMPDUContent is an IP Message, these + defaults will be overridden: + + Date: + + From the P1.DomainSuppliedInfo.arrival component of the + first P1.TraceInformation component. + + From: + + From the P1.UMPDUEnvelope.originator, as defined in + chapter 4. + + To: + + This default is only required if the generated RFC 822 + message has no destination specification. If + P1.PerMessageFlag.discloseRecipients is set then it + should contain the ORName in each P1.RecipientInfo + component. If it is not set, the it should be set to + "To: No Recipients Specified : ;". + + The mappings, and any actions for each P1.UserMPDU element is + now considered. + + P1.MPDUIdentifier + + Mapped to the extended RFC 822 field "P1-Message-ID:". + Note that the sequence CRLF is mapped to SPACE, which + makes the mapping irreversible for such cases. + + P1.UMPDUEnvelope.original + + Mapped to the extended RFC 822 field + "Original-Encoded-Information-Types:". If it contains + only P2.IA5Text, the RFC 822 field may be omitted. + + P1.ContentType + + As this can currently only have one value, it is not + mapped, on the basis that it is redundant. If the field + contains any value other than P2, then the UMPDU should + be rejected. + + + + + +Kille [Page 51] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + P1.UAContentID + + Mapped to the extended RFC 822 field "UA-Content-Id:". + + P1.Priority + + Mapped to the extended RFC 822 field "Priority:". + + P1.PerMesageFlag + + This has a number of components: + + - discloseRecipients + + If this bit is set, a "P1-Recipient:" field should + be generated, and contain each of the P1 + recipients. + + - conversionProhibited + + If this bit is set, the message should be rejected + if it contains P2.BodyPart which is not P2.IA5Text + or P2.ForwardedIPMessage. + + - alternateRecipientAllowed + + The value of this bit is ignored. + + - contentReturnRequest + + The value of this bit is ignored. + + P1.UMPDUEnvelope.deferredDelivery + + This should be mapped to the extended RFC 822 field + "Deferred-Delivery:". X.400 profiles, and in particular + the CEN/CENELEC profile [CEN/CENELEC/85a], specify that + this element must be supported at the first MTA. Thus, + it is expected that the value of this element will always + be in the past. If it is not, the function may + optionally be implemented by the gateway: that is, the + gateway should hold the message until the time specified + in the protocol element. Thus the extended RFC 822 field + is just for information. + + + + + +Kille [Page 52] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + P1.PerDomainBilateralInformation + + Each component should be encoded in the extended RFC 822 + field "Bilateral-Info:". P1.BilateralInfo should be + mapped into ASCII in a manner appropriate to its + contents. This submapping is not reversible. + + P1.TraceInformation + + This should be mapped to "X400-Trace:", as for the + delivery report. + + 5.4.4. Status Report + + The entire status report is mapped into the body of the RFC 822 + message, in the same manner as for a Delivery Report. An + appropriate "Subject:" field should be generated. As status + reports cannot be requested from the RFC 822 world, the mapping + is not likely to be used a great deal. + + 5.4.5. IP Message + + The P1.UMPDUEnvelope pro-forma specification ensures all the + 822-P1 information, and a minimal (legal) RFC 822 message. The + mappings and actions for the P2.Heading components are now + described. Basically, these are interpreted as actions and/or + mappings into RFC 822 fields. The following mappings are + specified: + + P2.IPMessageID + + This is mapped to the field "Message-ID:", according to + section 4. + + P2.Heading.originator + + If P2.Heading.authorisingUsers is present this is mapped + to Sender:, if not to From:. + + P2.Heading.authorisingUsers + + Mapped to From:. + + P2.Heading.primaryRecipients + + Mapped to To:. + + + +Kille [Page 53] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + P2.Heading.copyRecipients + + Mapped to Cc:. + + P2.Heading.blindCopyRecipients + + Mapped to Bcc:. + + P2.Heading.inReplyTo + + Mapped to In-Reply-To:. + + P2.Heading.obsoletes + + Mapped to the extended RFC 822 field "Obsoletes:" + + P2.Heading.crossReferences + + Mapped to References:. + + P2.Heading.subject + + Mapped to subject. The contents are converted to ASCII + (as defined in chapter 3). Any CRLF are not mapped, but + are used as points at which the subject field must be + folded. line. + + P2.Heading.expiryDate + + Mapped to the extended RFC 822 field "Expiry-Date:". + + P2.Heading.replyBy + + Mapped to the extended RFC 822 field "Reply-By:". + + P2.Heading.replyToUsers + + Mapped to Reply-To:. + + P2.Heading.importance + + Mapped to the extended RFC 822 field "Importance:". + + P2.Heading.sensitivity + + Mapped to the extended RFC 822 field "Sensitivity:". + + + +Kille [Page 54] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + P2.Heading.autoforwarded + + If it is set to FALSE, it is simply mapped to the + extended RFC 822 field "Autoforwarded:". If this is set + to TRUE, the P2.Body does not consist of a single + P2.ForwardedIPMessage, then there is an X.400 error, and + the message should be bounced. Otherwise the following + steps are taken. + + 1. The mappings for all of the message, except the + body part are completed. + + 2. Prepend each RFC 822 fieldname with the string + "Autoforwarded-". Mapped to the extended RFC 822 + field "Autoforwarded:". + + 3. Add the field "Autoforwarded:" with value TRUE. + + 4. Convert the syntax of the P2.ForwardedIPMessage to + generate the remaining RFC 822 fields. + + The P2.Body is mapped into the RFC 822 message body. Each + P2.BodyPart is converted to ASCII. If the P2.Body contains a + P2.BodyPart not listed here, the entire message should be + rejected. If there are exactly two P2.IA5Text body parts, and + the first line of the first is "RFC-822-Headers:", then the + rest of this first body part should be treated as additional + header information for the RFC 822 message. If there is an + "In-Reply-To:" field, this should be used to replace any + generated In-Reply-To: field. + + In other cases of multiple P2.BodyPart, the mapping defined by + Rose and Stefferud in [Rose85b], should be used to separate the + P2.BodyParts in the single RFC 822 message body. + + Individual body parts are mapped as follows: + + P2.IA5Text + + The mapping is trivial. + + P2.TTX + + If any P1.Teletex.NonBasicParams are set, the message + should be rejected. Otherwise, it should be converted to + ASCII according to chapter 3. + + + +Kille [Page 55] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + P2.SFD + + An SFD should be converted to ASCII as if it was being + rendered on an 79 column ASCII only VDU. It seems likely + that many gateways will not support this conversion. In + these cases, the message should be rejected. + + P2.ForwardedIPMessage + + The P2.ForwardedIPMessage.delivery and + P2.ForwardedIPMessage.DeliveryInformation are + discarded <9>. The IM-UAPDU should have its syntax + mapped (recursively) according to this gatewaying + specification. Clearly, it makes no sense to apply any + of the actions defined here. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 56] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +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. + + 1. ASCII <-> 822.atom + + The following EBNF is specified. + + atom-encoded = *( a-char / a-encoded-char ) + a-char = <any CHAR except specials, SPACE, + CTL, "_", and "#"> + 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 + (Decimal), and is interpreted in decimal as the corresponding + ASCII character. The choice of special abbreviations (as opposed + to octal 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. + + + +Kille [Page 57] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + 2. 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 + 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. + + 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. + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 58] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +Appendix B -- Mappings Specific to JNT Mail + + This Appendix is specific to the JNT Mail Protocol. It describes + specific changes in the context of this protocol. Addressing is not + discussed here, as it is covered in Appendix A. + + 1. Introduction + + There are four aspects of a gateway which are JNT Mail Specific, + in addition to those relating to addressing. These are each given + a section of this appendix. + + 2. 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. + + When going from JNT Mail to X.400, the User Report Request bits of + each P1.RecipientInfo.perRecipientFlag should be set to confirmed. + If there is more that one address in the Acknowledge-To: field, or + if the one address is not equivalent to the 822-P1 return address, + then: + + a. Acknowledgement(s) should be generated by the gateway. + The text of these acknowledgements should indicate that + they are generated by the gateway. + + b. The Acknowledge-To: field should also be passed in the + first P2.BodyPart. + + When going from X.400 to JNT Mail, in cases where + P1.RecipientInfo.perRecipientFlag has the user bits set to + confirmed the copy of the message to that recipient should have an + Acknowledge-To: field containing the P.UMPDUEnvelope.originator. + No attempt should be made to map Receipt notification requests + onto Acknowledge-To:. This is because no association can be + guaranteed between P2 and P1 level addressing information. + + 3. Trace + + JNT Mail trace uses the Via: syntax. When going from JNT Mail to + X.400, the following mapping onto P1.TraceInformation is used. + + P1.DomainSuppliedInfo.action is set to relayed. + + P1.DomainSuppliedInfo.arrival is set to the date-time component + + +Kille [Page 59] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + of the Via: field. P1.DomainSuppliedInfo.previous has + P1.CountryName as a null string, and + P1.AdministrationDomainName as the domain specified in the Via: + field. + P1.TraceInformation.GlobalDomainIdentifier has P1.CountryName + as a null string, and P1.AdministrationDomainName as any + commented information in the Via: field. For example: + + Via: UK.AC.Edinburgh ; 17 Jun 85 9:15:29 BST (EMAS V7) + + maps to - + + P1.GlobalDomainIdentifier + CountryName = "" + AdministrationDomainName = "(EMAS V7)" + P1.DomainSuppliedInfo + arrival = 17 Jun 85 9:15:29 BST + action = relayed + previous + CountryName = "" + AdministrationDomainName = "UK.AC.Edinburgh" + + 4. 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. + + 5. Lack of separate 822-P1 originator specification + + In JNT Mail the default mapping of the P1.MPDUEnvelope.originator + is to the Sender: field. This can cause a problem 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 P2.heading.authorisingUsers component and + P2.Heading.originator.ORName is different from + P1.UMPDUEnvelope.originator, map P1.MPDUEnvelope.originator onto + the Sender: field. + + If an IPM has a P2.heading.authorisingUsers component, and + P2.Heading.originator.ORName is different from + P1.UMPDUEnvelope.originator, P1.MPDUEnvelpoe.originator should be + + + +Kille [Page 60] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + mapped onto the Sender: field, and P2.Heading.originator mapped + onto the Original-Sender: field. + + In other cases the P1.MPDUEnvelope.Originator is already correctly + represented. + + Note that in some pathological cases, this mapping is + asymmetrical. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 61] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +Appendix C -- Mappings Specific to Internet Mail + + The Simple Mail Transfer Protocol [Postel82a] is used in the + ARPA-Internet, and in any network following the US DoD standards for + internetwork protocols. This appendix is specific to those hosts + which use SMTP to exchange mail. + + 1. Mapping between O/R names and SMTP addresses + + The mappings of Chapter 4 are to be used. + + 2. Use of the ARPA Domain System + + Whenever possible, domain-qualified addresses should be be used to + specify encoded O/R names. These domain encodings naturally + should be independent of any routing information. + + 3. Identification of gateways + + The ARPA-Internet Network Information Center (NIC) will maintain a + list of registered X.400 gateways in the ARPA Internet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 62] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +Appendix D -- Mappings Specific to Phonenet Mail + + There are currently no mappings specific to Phonenet Mail. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 63] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +Appendix E -- 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) [Horton86a] 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 thought 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 + UUCP inthop!dest!user + + + + + + + + + +Kille [Page 64] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +Appendix F -- Format of Address Mapping Tables + + There is a need to specify the association between the domain and + X.400 namespaces described in 4.2.1. This is defined as a table + syntax, but the syntax is defined in a manner which makes it suitable + for use with domain nameservers (such as the DARPA Domain nameservers + or the UK NRS). The symmetry of the mapping is not clear, so a + separate table is specified for each direction. For domain -> X.400: + + domain-syntax "#" dmn-orname "#" + + For example: + + AC.UK#PRMD$DES.ADMD$BT.C$UK# + XEROX.COM#O$Xerox.ADMD$ATT.C$US# + + For X.400 -> domain: + + dmn-orname "#" domain-syntax "#" + + EBNF.domain-syntax will be interpreted according to RFC 920. + EBNF.dmn-orname will have components ordered as defined in section + 4.2.1, and with the most significant component on the RHS. + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 65] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +References + + Bonacker85a. + + K.H. Bonacker, U. Pankoke-Babatz, and H. Santo, "EAN - Conformity + to X.400 and DFN-Pflichtenheft," GMD (Gesellschaft fur Mathematik + und Datenverarbeitung) report, June 1985. + + CCITT84a. + + CCITT SG 5/VII, "Recommendations X.400," Message Handling Systems: + System Model - Service Elements, October 1984. + + CCITT84b. + + CCITT SG 5/VII, "Recommendations X.411," Message Handling Systems: + Message Transfer Layer, October 1984. + + CCITT84c. + + CCITT SG 5/VII, "Recommendations X.420," Message Handling Systems: + Interpersonal Messaging User Agent Layer, October 1984. + + CCITT84d. + + CCITT SG 5/VII, "Recommendations X.409," Message Handling Systems: + Presentation Transfer Syntax and Notation, October 1984. + + CEN/CENELEC/85a. + + CEN/CENELEC/Information Technology/Working Group on Private + Message Handling Systems, "FUNCTIONAL STANDARD A/3222," + CEN/CLC/IT/WG/PMHS N 17, October 1985. + + Crocker82a. + + D.H. Crocker, "Standard of the Format of ARPA Internet Text + Messages," RFC 822, August 1982. + + Horton85a. + + M.R. Horton, "Draft Standard for ARPA/MHS Addressing Gateways," + AT&T Bell Laboratories, October 1985. + + + + + + +Kille [Page 66] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + Horton86a. + + M.R. Horton, "UUCP Mail Interchange Format Standard", RFC 976, + February 1986. + + ICL84a. + + ICL, "Comparison of service elements of Grey Book Mail and X.400," + Mailgroup Note 18: Extract from unpublished report for ITSU + (Information Technology Standards Unit), July 1984. + + Kille84a. + + S.E. Kille, (editor), JNT Mail Protocol (revision 1.0), Joint + Network Team, Rutherford Appleton Laboratory, March 1984. + + Kille84b. + + S.E. Kille, "Gatewaying between RFC 822 and JNT Mail," JNT + Mailgroup Note 15, May 1984. + + Kille86a. + + S.E. Kille, "O/R Names in the UK Academic Community," UK Working + Document, March 1986. + + Larmouth83a. + + J. Larmouth, "JNT Name Registration Technical Guide," Salford + University Computer Centre, April 1983. + + Neufeld85a. + + G. Neufeld, J. Demco, B. Hilpert, and R. Sample, "EAN: an X.400 + message system," in Second International Symposium on Computer + Message Systems, Washington, pp. 1-13, North Holland, + September 1985. + + Postel82a. + + J. Postel, "Simple Mail Transfer Protocol," RFC 821, August 1982. + + Postel84a. + + J. Postel and J. Reynolds, "Domain Requirements," RFC 920, + October 1984. + + + +Kille [Page 67] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + + Rose85a. + + M.T. Rose, "Mapping Service Elements between ARPA and MHS," Draft + proposal, October 1985. + + Rose85b. + + M.T. Rose and E.A. Stefferud, "Proposed Standard for Message + Encapsulation," RFC 934, January 1985. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille [Page 68] + + + +RFC 987 June 1986 +Mapping between X.400 and RFC 822 + + +Notes: + + <0> UNIX is a trademark of Bell Laboratories. + + <1> The term gateway is used to describe a component performing the + protocol mappings between RFC 822 and X.400. This is standard + usage amongst mail implementors, but should be noted carefully + by transport and network service implementors. (Sometime called + a "mail relay".) + + <2> If the remote protocol is JNT Mail, a notification may also be + sent by the recipient UA. + + <3> The asymmetry occurs where an ASCII string contains the sequence + EBNF.ps-encoded-char. This would be mapped directly to + PrintableString, but the reverse mapping would be to the value + implied by the sequence. + + <4> It might be suggested that for reasons of elegance, + EBNF.ps-delim (left parenthesis) is encoded as + EBNF.ps-encoded-char. This is not done, as it it would never be + possible to represent a PrintableString containing the character + "(" in ASCII. This is because an "(" in ASCII would be mapped + to the encoding in PrintableString. + + <5> In practice, a gateway will need to parse various illegal + variants on 822.date-time. In cases where 822.date-time cannot + be parsed, it is recommended that the derived UTCTime is set to + the value at the time of translation. + + <6> P2.ORname is defined as P1.ORName. + + <7> This recommendation may change in the light of CCITT or + CEN/CENELEC guidelines on the use of initials. + + <8> It would be possible to use a ForwardedIPMessage for these + fields, but the semantics are (arguably) slightly different, and + it is probably not worth the effort. + + <9> Although this violates chapter 1, part 4, principles 2 and 3, it + is suggested that this is justified by principle 1. + + + + + + + + +Kille [Page 69] +
\ No newline at end of file |