brian@sdcsvax.UCSD.EDU (Brian Kantor) (11/16/87)
--- 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]