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.
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.
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
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
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.
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.
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].
- 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.
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.
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.
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.
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
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).
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.
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.
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.
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 "]"
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..g3Fax refers to a value of P1.EncodedInformationTypes. . 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.
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.
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.
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.
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.
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.
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.
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
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
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
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.
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"
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).
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