As per Relevance of the word component, we have this rfc below:
UCL Technical Report 120
Mailgroup Note 19
Network Working Group S.E.
Request for Comments: 987 University College
June 1986
Mapping between X.400 and RFC 822
Status of This
This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
Distribution of this memo is unlimited
This document describes a set of mappings which will
interworking between systems operating the CCITT X.400 (1984)
of protocols [CCITT84a], and systems using the RFC 822 mail
[Crocker82a], or protocols derived from RFC 822. The approach
to maximise the services offered across the boundary, whilst
requiring unduly complex mappings. The mappings should not
any changes to end systems
This specification should be used when this mapping is performed
the ARPA-Internet or in the UK Academic Community.
specification may be modified in the light of
experience, but no substantial changes are expected
Kille [Page 1]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Chapter 1 --
1.1. X.400
The X.400 series protocols have been defined by CCITT to
an Interpersonal Messaging Service (IPMS), making use of a
and forward Message Transfer Service. It is expected that
standard will be implemented very widely. As well as the
standard (X.400), work is underway on various functional
of profiles which specify how X.400 will be used in
communities. Many of the major functional standards (e.g.
CEPT, CEN/CENELEC, and NBS) are likely to be similar. Some of
decisions in this document are in the light of this work.
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
Defense Advanced Research Projects Agency) Internet. It
currently used on the ARPA-Internet in conjunction with two
standards: RFC 821, also known as Simple Mail Transfer
(SMTP) [Postel82a], and RFC 920 which is a specification for
domain name system and a distributed name service [Postel84a].
RFC 822, or protocols derived from RFC 822 are used in a number
other networks. In particular
UUCP
UUCP is the UNIX to UNIX CoPy protocol <0>, which is
used over dialup telephone networks to provide a
message transfer mechanism. There are some extensions
RFC 822, particularly in the addressing. They are likely
use domains which conform to RFC 920, but not
corresponding domain nameservers [Horton86a].
Some portions of CSNET will follow the ARPA-
protocols. The dialup portion of CSNET uses the
protocols as a replacement for RFC 821. This portion
likely to use domains which conform to RFC 920, but not
corresponding domain nameservers
Some parts of BITNET use RFC 822 related protocols,
EBCDIC encoding
Kille [Page 2]
RFC 987 June 1986
Mapping between X.400 and RFC 822
JNT Mail
A number of X.25 networks, particularly those
with the UK Academic Community, use the JNT (Joint
Team) Mail Protocol, also known as Greybook [Kille84a].
This is used with domains and name service specified by
JNT NRS (Name Registration Scheme) [Larmouth83a].
The mappings specified here are appropriate for all of
networks
1.3. The Need for
There is a large community using RFC 822 based protocols for
services, who will wish to communicate with X.400 systems.
will be a requirement, even in cases where communities intend
make a transition to use of X.400, where conversion will be
to ensure a smooth service transition. It is expected that
will be more than one gateway <1>, and this specification
enable them to behave in a consistent manner. These gateways
sometimes called mail relays. Consistency between gateways
desirable to provide
1. Consistent service to users
2. The best service in cases where a message passes
multiple gateways
1.4. General
There are a number of basic principles underlying the details
the specification
1. The specification should be pragmatic. There should
be a requirement for complex mappings for 'Academic
reasons. Complex mappings should not be required
support trivial additional functionality
2. Subject to 1), functionality across a gateway should be
high as possible
3. It is always a bad idea to lose information as a result
any transformation. Hence, it is a bad idea for a
to discard information in the objects it processes.
includes requested services which cannot be fully mapped
4. All mail gateways actually operate at exactly one
Kille [Page 3]
RFC 987 June 1986
Mapping between X.400 and RFC 822
above the layer on which they conceptually operate.
implies that the gateway must not only be cognisant of
semantics of objects at the gateway level, but also
cognisant of higher level semantics. If
transformation of the objects that the gateway operates
is to occur, then the gateway needs to understand
than the objects themselves
1.5. Gatewaying
1.5.1. X.400
The CCITT X.400 series recommendations specify a number
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
either the P1 or P3 protocols, which are specified
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
provided by the P2 protocol specified in X.420
[CCITT84c].
This document considers only IPMS, and not of any other
of the Message Transfer Service. This is reasonable,
RFC 822, broadly speaking, provides a service corresponding
IPMS, and no services other than IPMS have been defined
the Message Transfer Service. As none of the RTS (
Transfer Service) service elements is available to the
user, this level and lower levels are of no concern in
gatewaying specification. Note that in this memo "IP"
"InterPersonal" (not Internet Protocol).
The Message Transfer Service defines an end-to-end service
a series of Message Transfer Agents (MTA). It also defines
protocol, P1, which is used between a pair of MTAs.
protocol is simply a file format (Message Protocol Data Unit
or MPDU), transferred between two MTAs using the RTS.
are three types of MPDU
User
This contains envelope information, and
contents. The envelope includes an ID, an originator,
Kille [Page 4]
RFC 987 June 1986
Mapping between X.400 and RFC 822
list of recipients, and trace information. It is used
carry data for higher level services
This contains only envelope information. It is used
determine whether a User UMPDU could be delivered to
given O/R (originator/recipient) name
Delivery
This contains envelope information, and
contents. It is used to indicate delivery success
failure of a User or Probe MPDU over the Message
Service
IPMS (P2) specifies two content types for the P1 User
(User Agent Protocol Data Units or UAPDU):
Interpersonal Message (IM-UAPDU
This has two components: a heading, and a body. The
is structured as a sequence of body parts, which may
basic components (e.g.IA5 text, or G3 fax), or
Messages. The header contains end to end
information, such as subject, primary recipients (To:),
and priority. The validity of these fields is
guaranteed by the Message Transfer Service.
provides the basic IPMS
Status Report (SR-UAPDU
This UAPDU has defined contents. It is used to
that a message has been received by a User Agent.
does not have to be implemented
1.5.2. RFC 822
RFC 822 is based on the assumption that there is an
service, which is here called the 822-P1 service. The 822-P
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.
822-P1 protocols, in particular SMTP, can provide
functionality, but as these are neither mandatory in SMTP,
available in other 822-P1 protocols, they are not
here. Details of aspects specific to a number of 822-P
protocols are given in appendices B to E. An RFC 822
consists of a header, and content which is uninterpreted
text. The header is divided into fields, which are
protocol elements. Most of these fields are analogous to P
header elements, although some are analogous to P1
elements
1.5.3. The
Given this functional description of the two protocols,
functional nature of a gateway can now be considered. It
be elegant to consider the 822-P1 service mapping onto P1
RFC 822 mapping onto P2, but reality just does not fit
Therefore one must consider that P1 or P1 + P2 on one side
mapped into RFC 822 + 822-P1 on the other in a slightly
manner. The details of the tangle will be made clear
chapter 5. The following basic mappings are thus proposed
When going from RFC 822 to X.400, an RFC 822 message and
associated 822-P1 information is always mapped into an IM-
and the associated P1 envelope. Going from X.400 to RFC 822,
an RFC 822 message and the associated 822-P1 information may
derived from
1. A Delivery Report
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
discussed in chapter 5. Any other User MPDUs are not mapped
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
This document has five chapters
1. Overview - this document
2. Service Elements - This describes the (end user)
mapped by a gateway
3. Basic mappings - This describes some basic notation
in chapters 3-5, the mappings between character sets,
some fundamental protocol elements
4. Addressing - This considers the mapping between X.400 O/
names and RFC 822 addresses, which is a
gateway component
5. Protocol Elements - This describes the details of
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.
This document is eclectic, and credit should be given
- Study of the EAN X.400 system code which performs
function [Neufeld85a]. Some detailed clarification
made by the DFN report on EAN [Bonacker85a].
- An unpublished ICL report, which considered a subset
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
encodings of chapter 3 were derived directly from
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
RFC 822 and X.400 provide a number of services to the end user.
document describes the extent to which each service can be
across an X.400 <-> RFC 822 gateway. The cases considered are
transfers across such a gateway, although the problems of
crossings are noted where appropriate
When a service element is described as supported, this means
when this service element is specified by a message originator for
recipient behind a gateway, that it is mapped by the gateway
provide the service implied by the element. For example, if
RFC 822 originator specifies a Subject: field, this is considered
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,
so the service can be fully provided. In other cases, the
cannot be provided, as there is a complete mismatch. In
remaining cases, the service can be partially fulfilled. The
of partial support is summarised
NOTE: It should be clear that support of service elements
reception is not a gatewaying issue. It is assumed that
outbound messages are fully conforming to the
standards
2.1. RFC 822
RFC 822 does not explicitly define service elements, as
from protocol elements. However, all of the RFC 822
fields, with the exception of trace, can be regarded
corresponding to implicit RFC 822 service elements. A
of mapping used in several cases, is to place the text of
header into the body of the IP Message. This can usually
regarded as partial support, as it allows the information to
conveyed to the end user even though there is no
X.400 protocol element. Support for the various service
(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
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.
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
supported in a fuller manner, but this is not suggested
Other
In particular X-* fields, and "illegal" fields in
usage (e.g. "Fruit-of-the-day:") are passed in the
text
2.2. X.400
When mapping from X.400 to RFC 822, it is not proposed to map
elements into the body of an RFC 822 message. Rather, new RFC 822
headers are defined. It is intended that these fields will
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.
elements are provided, in part, by the gateway as they cannot
provided by RFC 822. Some service elements are are marked N/
(not applicable). These elements are only applicable to
Agent / Message Transfer Agent interaction and have no end-to-
implication. These elements do not need to be mapped by
gateway
2.2.1. Message Transfer Service
Access
N/A
Kille [Page 11]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Content Type
Not mapped. As it can only have one value (P2), there
little use in creating a new RFC 822 header field, unless
was to distinguish delivery reports
Converted
Supported by a new RFC 822 header
Delivery Time Stamp
N/A
Message
Supported, by use of a new RFC 822 header. This new
is required, as X.400 has two message-ids whereas RFC 822
has only one
Non-delivery
Not supported, although in general an RFC 822 system
return errors as IP messages. In other elements,
pragmatic result is treated as effective support of
service element
Original Encoded Information Types
Supported as a new RFC 822 header
Registered Encoded Information
N/A
Submission Time Stamp
Supported
Alternate Recipient
Not supported. Any value is ignored by the gateway
Deferred
Support is optional. The framework is provided so
messages may be held at the gateway. However, a
Kille [Page 12]
RFC 987 June 1986
Mapping between X.400 and RFC 822
following this specification does not have to do this.
is in line with the emerging functional standards
Deferred Delivery
Supported
Delivery
Supported at gateway. Thus, a notification is sent by
gateway to the originator <2>.
Disclosure of Other
Supported by use of a new RFC 822 header
Grade of Delivery
Supported as a new RFC 822 header. In general, this
only be for user information in the RFC 822 world
Multi-Destination
Supported
Prevention of Non-delivery
Not Supported, as there is no control in the RFC 822
(but see Non-delivery Notification).
Return of
This is normally the case, although the user has no
(but see Non-delivery Notification).
Conversion
Supported. Note that in practice this support is
by the nature of the gateway
Explicit
Supported, for appropriate values (See the IPMS Typed
service element).
Kille [Page 13]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Implicit
Supported, in the sense that there will be
conversion to IA5 in cases where this is practical
Supported at the gateway (i.e. the gateway services
probe).
Alternate Recipient
N/A
Hold for
N/A
2.2.2. Interpersonal Message Service
IP-message
Supported
Typed
Supported. IA5 is fully supported. ForwardedIPMessage
supported, with some loss of information. A subset of
is supported (see section 5 for the specification of
subset), with some loss of information. SFD may
supported, with some loss of information. TTX and SFD
only supported when conversion is allowed. Other types
not supported
Blind Copy Recipient
Supported
Non-receipt
Not supported
Receipt
Not supported
Kille [Page 14]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Auto-forwarded
Supported as new RFC 822 header
Originator
Supported
Authorising User's
Supported, although the mapping (From:) is not quite
same
Primary and Copy Recipients
Supported
Expiry Date
Supported as new RFC 822 header. In general, only
action can be expected
Cross Referencing
Supported
Importance
Supported as new RFC 822 header
Obsoleting
Supported as new RFC 822 header
Sensitivity
Supported as new RFC 822 header
Subject
Supported
Reply Request
Supported as comment next to address
Kille [Page 15]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Forwarded IP-message
Supported, with some loss of information
Body Part Encryption
Not supported
Multi-part
Supported, with some loss of information, in that
structuring cannot be formalised in RFC 822.
Kille [Page 16]
RFC 987 June 1986
Mapping between X.400 and RFC 822
Chapter 3 -- Basic
3.1.
The P1 and P2 protocols are encoded in a structured
according to the X.409 specifications, whereas RFC 822 is
encoded. To define a detailed mapping, it is necessary to
to detailed protocol elements in each format. This is described
3.1.4. RFC 822
Structured text is defined according to the Extended
Naur Form (EBNF) defined in section 2 of RFC 822 [Crocker82a].
In the EBNF definitions used in this specification, the
rules given in Appendix D of RFC 822 are assumed. When
EBNF tokens are referred to outside an EBNF definition,
are identified by the string "882." appended to the
of the string (e.g. 822.addr-spec). Additional syntax rules
to be used throughout this specification are defined in
chapter
The EBNF is used in two ways
1. To describe components of RFC 822 messages (or
822-P1 components). In this case, the lexical
defined in section 3 of RFC 822 should be used.
these new EBNF tokens are referred to outside an
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
not in an RFC 822 message. In these cases, tokens
either be self delimiting, or be delimited by
delimiting tokens. Comments and LWSP are not used
delimiters
3.1.5. X.409
An element is referred to with the following syntax, defined
EBNF
element = protocol "." definition *( "." definition )
protocol = "P1" / "P2"
definition = identifier /
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
the P2 heading. The same syntax is also used to refer
element values. For example
P1.EncodedInformationTypes.[0].g3Fax refers to a value
P1.EncodedInformationTypes.[0] .
3.2. ASCII and IA
A gateway will interpret all IA5 as ASCII. Thus, they are
identically for the rest of this document
3.3. Universal
There is a need to convert between ASCII text, and some of
Universal Primitive types defined in X.409 [CCITT84d]. For
case, an EBNF syntax definition is given, for use in all of
specification. All EBNF syntax definitions of
Primitives are in lower case, whereas X.409 primitives
referred to with the first letter in upper case. Except as noted
all mappings are symmetrical
3.3.1.
Boolean is encoded as
boolean = "TRUE" / "FALSE
3.3.2.
NumericString is encoded as
numericstring = *
3.3.3.
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
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
ASCII character. Special encodings are given for: at sign (@),
percent (%), exclamation mark/bang (!), double quote ("),
underscore (_). These characters are not included
PrintableString, but are common in RFC 822 addresses.
abbreviations will ease specification of RFC 822 addresses
an X.400 system
An asymmetric mapping between PrintableString and ASCII can
be defined <3>. To encode ASCII as PrintableString,
EBNF.ps-encoded syntax is used, with all EBNF.ps-char
EBNF.ps-delim mapped directly <4>. All other 822.CHAR
encoded as EBNF.ps-encoded-char. There are two cases
encoding PrintableString as ASCII. If the PrintableString
be parsed as EBNF.ps-encoded, then the previous mapping
be reversed. If not, it should be interpreted
EBNF.printablestring
Some examples are now given. Note the arrows which
asymmetrical mappings
PrintableString
'a demo.' <-> 'a demo.'
foo(a)bar <-> foo@
(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
common cases, so that it is general, and so that it
straightforward to code. It is not attempting to minimise
number of pathological cases
Kille [Page 19]
RFC 987 June 1986
Mapping between X.400 and RFC 822
3.3.4. T.61
T.61 strings are, in general, only used for conveying
interpreted information. Thus, the aim of a mapping should
to render the characters appropriately in the remote
set, rather than to maximise reversibility. The
defined in the CEN/CENELEC X.400 functional standard should
used [CEN/CENELEC/85a]. These are based on the mappings
X.408 (sections 4.2.2 and 5.2.2).
3.3.5.
Both UTCTime and the RFC 822 822.date-time syntax contain:
(lowest two digits), Month, Day of Month, hour, minute,
(optional), and Timezone. 822.date-time also contains
optional day of the week, but this is redundant. Therefore
symmetrical mapping can be made between these constructs <5>.
The UTCTime format which specifies the timezone offset
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 is probably the trickiest problem of an X.400 <-> RFC 822
gateway. Therefore it is given a separate chapter. This chapter,
a side effect, also defines a standard textual representation
X.400 addresses
Initially we consider an address in the (human) mail user sense
"what is typed at the mailsystem to reference a human". A
RFC 822 address is defined by the EBNF EBNF.822-address
822-address = [ route ] addr-
In an 822-P1 protocol, the originator and each recipient should
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
information has any semantics, other than to the end user
The basic X.400 address is defined by P1.ORName. In P1 all
P1.ORnames are encapsulated within P1.RecipientInfo, and in P2
P2.ORNames <6> are encapsulated within P2.ORDescriptor
It can be seen that RFC 822 822.address must be mapped
P2.ORDescriptor, and that RFC 822 EBNF.822-address must be
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
the later mappings, and as a side effect provides a
representation for O/R names
4.3 Mapping between EBNF.822-address and P1.
4.4 The Full P1 / 822-P1
4.5 The Full P2 / RFC 822
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
clearly necessary to be able to encode this in ASCII
gatewaying purposes. A general encoding is given here, which
be used as a basis for a user interface, as well as for
defined gateway mapping
4.1.1. Basic
A series of BNF definitions of each possible attribute
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
BNF components, with the mapping to X.400 encoding
trivial
attributevalue = c / admd / prmd / x121 / t-id / o /
/ ua-id / pn.g / pn.i / pn.s / pn.gq / dd.
c = printablestring ; P1.
admd = printablestring ; P1.
prmd = printablestring ; P1.
x121 = numericstring ; P1.X121
t-id = numericstring ; P1.
o = printablestring ; P1.
ou = printablestring ; P1.
ua-id = numericstring ; P1.
pn.s = printablestring ; P1.PersonalName.
pn.g = printablestring ; P1.PersonalName.
pn.i = printablestring ; P1.PersonalName.
pn.gq = printablestring ; P1.PersonalName.
dd.value = printablestring ; P1.
Attribute.
In cases where an attribute can be encoded as either
PrintableString or NumericString (Country, ADMD, PRMD) it
assumed that the NumericString encoding will be adopted
possible. This prevents the encoding of PrintableString
the characters are all numbers. This restriction
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.
standard-type =
"C" ; P1.
/ "ADMD" ; P1.
/ "PRMD" ; P1.
/ "X121" ; P1.X121
/ "T-ID" ; P1.
/ "O" ; P1.
/ "OU" ; P1.
/ "UA-ID" ; P1.
/ "S" ; P1.PersonalName.
/ "G" ; P1.PersonalName.
/ "I" ; P1.PersonalName.
/ "GQ" ; P1.PersonalName.
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
Handling of Personal Name based purely on
EBNF.standard-type syntax defined above is likely to be clumsy
It seems desirable to utilise the "human" conventions
encoding these components. A syntax is proposed here. It
designed to cope with the common cases of O/R
specification where
1. There is no generational
2. Initials contain only letters <7>.
3. Given Name does not contain full stop ("."), and is
least two characters long
4. If Surname contains full stop, then it may not be
the first two characters, and either initials or
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 "." )
given = 2*
initial =
surname =
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
encode ALL initials. Therefore, the proposed encoding
"natural" when either GivenName or Initials, but not both,
present. The case where both are present can be encoded,
this appears to be contrived
4.1.3. Two encodings of P1.
Given this structure, we can specify a BNF representation of
O/R Name
Kille [Page 24]
RFC 987 June 1986
Mapping between X.400 and RFC 822
std-orname = 1*( "/" attribute "=" value ) "/"
attribute = standard-
/ "PN
/ standard-dd-
/ registered-dd-
/ "DD." std-
value = std-
registered-dd-
= std-
std-printablestring =
= *( std-char / std-pair )
std-char =
and "=">
std-pair = "$" ( ps-delim / ps-char )
If the type is PN, the value is interpreted according
EBNF.encoded-pn, and the components of P1.PersonalName
accordingly. If the value is registered-dd-type, if the
is registered at the SRI NIC as an accepted Domain
Attribute type, then the value should be
accordingly. This restriction maximises the syntax
which can be done at a gateway
Another syntax is now defined. This is intended to
compatible with the syntax used for 822.domains. This
is not intended to be handled by users
dmn-orname = dmn-part *( "." dmn-part )
dmn-part = attribute "$"
attribute = standard-
/ "~" dmn-
value = dmn-
dmn-printablestring =
= *( dmn-char / dmn-pair )
dmn-char =
dmn-pair = "\."
For example: C$US.ADMD$ATT.~ROLE$Big\.
Kille [Page 25]
RFC 987 June 1986
Mapping between X.400 and RFC 822
4.2. Mapping between EBNF.822-address and P1.
Ideally, the mapping specified would be entirely symmetrical
global, to enable addresses to be referred to transparently in
remote system, with the choice of gateway being left to
Message Transfer Service. There are two fundamental reasons
this is not possible
1. The syntaxes are sufficiently different to make
awkward
2. In the general case, there would not be the
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
in the 822.local-part of EBNF.822-address. Further O/R
information may be associated with the 822.domain component
This cannot be used in the general case, basically due
character set problems, and lack of order in X.400 O/R Names
The only way to encode the full PrintableString character
in a domain is by use of the 822.domain-ref syntax. This
likely to cause problems on many systems. The
character set of domains is in practice reduced from
RFC 822 set, by restrictions imposed by domain conventions
policy
A generic 822.address consists of a 822.local-part and
sequence of 822.domains (e.g
<@domain1,@domain2:user@domain3>). All except the 822.
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 (
they may have identified the gateway from within the RFC 822
world). The 822.domain associated with the 822.local-part
also identify the gateway from within the RFC 822 world.
final 822.domain may be used to determine some number of O/
Name attributes. The following O/R Name attributes
considered as a hierarchy, and may be specified by the domain
They are (in order of hierarchy):
Country, ADMD, PRMD, Organisation, Organisational
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,
some set of attributes. This association
hierarchically: i.e. if a domain implies ADMD, it also
country. If one of the hierarchical components is omitted
an X.400 structure, this information can be associated with
corresponding domain (e.g. a domain can be mapped onto
Country/ADMD/Organisation tuple). Subdomains under this
associated according to the O/R Name hierarchy. For example
=> "AC.UK" might be associated
C="234", ADMD="BT", PRMD="DES
then domain "R-D.Salford.AC.UK" maps
C="234", ADMD="BT", PRMD="DES", O="Salford", OU="R-D
There are two basic reasons why a domain/attribute
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
country, and so it does not need to be
explicitly
2. To deal with cases where attribute values do not
the syntax
domain-syntax = ALPHA [ *alphanumhyphen alphanum ]
alphanum =
alphanumhyphen =
Although RFC 822 allows for a more general syntax,
restriced syntax is chosen as it is the one chosen by
various domain service administrations
This provides a general aliasing mechanism
This set of mappings need only be known by the
relaying between the RFC 822 world, and the O/R Name
associated with the mapping in question. However, it
desirable (for the optimal mapping of third party addresses
for all gateways to know these mappings. A format for
exchange of this information is defined in Appendix F
From the standpoint of the RFC 822 Message Transfer System,
domain specification is simply used to route the message in
Kille [Page 27]
RFC 987 June 1986
Mapping between X.400 and RFC 822
standard manner. The standard domain mechanisms are used
identify gateways, and are used to select appropriate
for the corresponding O/R Name namespace. In most cases,
will be done by registering the higher levels, and
that the gateway can handle the lower levels
As a further mechanism to simplify the encoding of
cases, where the only attributes to be encoded on the LHS
Personal Name attributes which comply with the restrictions
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.
encodes the P1.ORName consisting
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
J.Linnimouth@Marketing.Xerox.COM could be used
Note that in this example, the first three attributes
determined by the domain Xerox.COM. The OrganisationalUnit
determined systematically
There has been an implicit assumption that an RFC 822 domain
either X.400 or RFC 822. This is pragmatic, but undesirable
as the namespace should be structured on a logical basis
does not necessarily correspond to the choice of
Transfer protocols. The restriction can be lifted,
that the nameservice deals with multiple message
protocols. This can happen in a straightforward manner for
UK NRS, as explained in [Kille86a]. It could also be
with the DARPA Domain Nameserver scheme by use of the
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,
give a "natural" encoding of genuine RFC 822 addresses.
depends largely on the allocation of appropriate
domains
The general case is mapped by use of domain defined attributes
Three are defined, according to the full environment used
interpret the RFC 822 information
1. Domain defined type "RFC-822". This string is to
interpreted in the context of RFC 822, and RFC 920
[Crocker82a,Postel84a].
2. Domain defined type "JNT-Mail". This string is to
interpreted in the context of the JNT Mail protocol
and the NRS [Kille84a,Larmouth83a].
3. Domain defined type "UUCP". This is
according to the constraints of the UUCP
[Horton86a].
These three are values currently known to be of use.
recognised values may be defined. These will be maintained
a list at the SRI Network Information Center
Other O/R Name attributes will be used to identify a context
which the O/R Name will be interpreted. This might be
Management Domain, or some part of a Management Domain
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
is interpreted everywhere within the (Administrative
Private) Management Domain. In the second example,
attributes are needed within the Management Domain to
a gateway. Thus, this scheme can be used with varying
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
include RFC 822 addresses which are given
encodings
2. "Genuine" RFC 822 addresses
The mapping should proceed as follows, by first assuming
1).
STAGE 1.
1. If the 822-address is not of the form
local-part "@"
go to stage 2.
2. Attempt to parse domain as
*( domain-syntax "." ) known-
Where known-domain is the longest possible match in
list of gatewayed domains. If this fails, and the
does not explicitly identify the local gateway, go
stage 2. If it succeeds, allocate the
associated with EBNF.known-domain, and
allocate the attributes implied by
EBNF.domain-syntax component
3. Map 822.local-part to ASCII, according to
definition of Appendix A. This step should be applied
A. If the source network cannot
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
increases the functionality of the gateway, and
not imply any loss of generality. Mapping case
allows sites which cannot generate 822.quoted-
to address recipients the gateway, without the
having to know this explicitly. There is no loss
functionality, as the quoting character of Appendix
(#) is not in PrintableString. This seems desirable
It should not be applied in to other addresses, as
third party RFC#822 address containing the
EBNF.atom-encoded (as defined in Appendix A) would
transformed asymmetrically
4. Map the result of 3) to EBNF.ps-encoded according
section 3.
5. Parse the result of 4) according to the
EBNF.std-orname. If this parse fails, parse the
of 4) according to the EBNF EBNF.encoded-pn. If
also fails, go to stage 2. Otherwise, the result is
set of type/value pairs
6. Associate the EBNF.attribute-value syntax (
from the identified type) with each value, and
that it conforms. If not, go to stage 2.
7. Ensure that the set of attributes conforms both to
X.411 P1.ORName specification and to the
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
not a valid X.400 encoding. If the address is an 822-P
recipient address, it must be rejected, as there is a need
interpret such an address in X.400. For the 822-P1
address, and any addresses in the RFC 822 header, they
now be encoded as RFC 822 addresses in an X.400 O/R Name
1. Convert the EBNF.822-address to PrintableString,
specified in chapter 3.
2. The domain defined attribute ("RFC-822", "JNT-Mail"
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
Domain agreed manner, so that the O/R Name will
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
symmetrically encoded RFC 822 addresses
When a P1 Recipient O/R Name is interpreted, gatewaying will
selected if there a single special domain defined
present ("RFC-822", "JNT-Mail" or "UUCP"). In this case,
mapping A. For other O/R Names
1. Contain the special attribute
2. Identify the local gateway with the other attributes
Use mapping A. In other cases, use mapping B
Mapping
1. Map the domain defined attribute value to ASCII,
defined in chapter 3.
2. Where appropriate (P1 recipients), interpret the
according to the semantics implied by the
defined attribute
Mapping B
This will be used for X.400 addresses which do not use
explicit RFC 822 encoding
1. Noting the hierarchy specified in 4.3.1, determine
maximum set of attributes which have an
domain specification. If no match is found,
Kille [Page 32]
RFC 987 June 1986
Mapping between X.400 and RFC 822
the domain as the domain specification of the
gateway, and go to step 4.
2. Following the 4.3.1 hierarchy, if each
component exists, and conforms to the
EBNF.domain-syntax (as defined in 4.3.1), allocate
next subdomain
3. If the remaining components are personal-
components, conforming to the restrictions of 4.2.2,
then EBNF.encoded-pn should be derived to
822.local-part. In other cases the
components should simply be encoded as a 822.local-
using the EBNF.std-orname syntax. Where
domain defined types exist, the DD. syntax should
be used
4. If this step is reached for an 822-P1 recipient,
the address is invalid. For other addresses, if
derived 822.local-part can only be encoded by use
822.quoted-string, the gateway may optionally use
ASCII to 822.local-part mapping defined in Appendix A
dependent on the mail protocols of the networks
relayed to. Use of this encoding is discouraged
4.3. Repeated
The mappings defined are symmetrical across a single gateway
except in certain pathological cases (see chapter 3). However,
is always possible to specify any valid address across a gateway
This symmetry is particularly useful in cases of (mail
type) distribution list expansion. For example, an X.400
sends to a list on an RFC 822 system which he belongs to.
received message will have the originator and any 3rd party X.400
O/R names in correct format (rather than doubly encoded).
cases (X.400 or RFC 822) where there is common agreement
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
by X.400. Then by JNT Mail to another gateway determined
the domain FR.PTT.Inria. This will then derive the X.400 O/
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.
/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj#l#a#r#seismo.css.gov
@monet.berkeley.
The second case uses the Appendix A encoding to
822.quoted-text. This will be sent to monet.berkeley.edu
RFC 822, then to the AC PRMD by X.400, and then
jj@seismo.css.gov by RFC 822.
4.4. The full P1 / 822-P1
There are two basic mappings at the P1 level
1. 822-P1 return address <-> P1.UMPDUEnvelope.
2. 822-P1 recipient <-> P1.
822-P1 recipients and return addresses are encoded
EBNF.822-address. As P1.UMPDUEnvelope.originator is encoded
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
component of P1.RecipientInfo
P1.
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.
Responsibility Flag should be set. Report Request
be set according to content return policy, as
in section 5.3. User Report Request should be set
Basic
P1.
This optional component should be omitted
4.4.2. X.400 -> RFC 822
The mapping only takes place in cases
P1.RecipientInfo.perRecipientFlag Responsibility Flag is set
The following treatment should be given to the
P1.RecipientInfo components
P1.
Not used
P1.RecipientInfo.
If ReportRequest is Confirmed or Audit-and-Confirmed
a delivery report indicating success should be sent
the gateway. This report should use
P1.ReportedRecipientInfo.SupplementaryInformation
indicate the identity of the gateway, and the nature
the report (i.e. only as far as the gateway).
will be handled by returning RFC 822 messages, and
User Report Request set to No report is ignored
P1.
If present, the O/R name should be rejected, unless
requested conversion can be achieved. None of
currently recognised values of this parameter
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
All RFC 822 addresses are assumed to use the 822.mailbox syntax
This should include all 822.comments associated with the
tokens of the 822.mailbox. All P2.ORNames are encoded within
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
822.addr-spec or 822.route-addr syntax. This is
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.
822.route-addr construct
- Any 822.comments, in order, retaining
parentheses
This string should then be encoded into T.61 (
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
P2.Recipient.reportRequest should be omitted
If the 822.group construct is present, each
822.mailbox should be encoded as above. The 822.group
be mapped to T.61, and a P2.ORDesciptor with only
freeformName component built from it
4.5.2. X.400 -> RFC 822
In the basic case, where P2.ORName is present, proceed
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
to ASCII (chapter 3), and use use this as
822.phrase component of 822.mailbox using
822.phrase 822.route-addr construct
2b. If P2.ORDescriptor.freeformName is absent,
EBNF.822-address is parsed as 822.addr-spec use this
the encoding of 822.mailbox. If EBNF.822-address
parsed as 822.route 822.addr-spec, then a 822.
taken from 822.local-part should be added
3. If P2.ORDescriptor.telephoneNumber is present,
should be placed in a trailing 822.comment
4. If P2.Recipient.reportRequest has
receiptNotification bit set, then an 822.
"(Receipt Notification Requested)" should be
to the address. The effort of correlating P1 and P
information is too great to justify the gateway
Receipt Notifications
5. If P2.Recipient.replyRequest is present, an 822.
"(Reply requested)" or "(Reply not requested)"
be appended to the address, dependent on its value
If P2.ORName is absent, P2.ORDescriptor.freeformName should
converted to ASCII, and used with the RFC 822 822.group syntax
freeformname ":" ";"
Steps 3-5 should then be followed
4.6. Message
There is a need to map both ways between 822.msg-id
P2.IPMessageID. A mapping is defined which is symmetrical
non-pathological cases. The mapping allows for the fact
P2.IPMessageID.PrintableString is mandatory for the Cen/
profile. This allows for good things to happen when messages
multiple times across the X.400/RFC 822 boundary. A
between 822.msg-id and P1.MPDUIdentifier is defined. This
for X.400 error messages to reference an RFC 822 ID, which
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-
P2.IPMessageID.ORName is used to generate an 822.addr-spec,
defined above. P2.IPMessageID.PrintableString is mapped
ASCII, as defined in chapter 3. This string (if it is
and if the value is not "RFC-822") is appended to the front
the 822.local-part of the 822.msg-id, with "*" as a separator
If no ORName is present, an 822.msg-id of the
"PrintableString*@gateway-domain" is generated
4.6.2. 822.msg-id -> P2.
822.local-part is parsed as
[ printablestring "*" ] real-local-
If EBNF.printablestring is found, it is mapped
PrintableString, and used as P2.IPMessageID.PrintableString
P2.IPMessageID.PrintableString is set to "RFC-822".
arbitrary value allows for conformance to Cen/Cenelec.
EBNF.real-local-part is not present, no P2.IPMessageID.
is generated. Otherwise, 822.local-part is replaced
EBNF.real-local-part, and 822.addr-spec is mapped
P2.IPMessageID.ORName as defined above
4.6.3. 822.msg-id -> P1.
P1.CountryName is assigned to "", P1.
to 822.domain (from 822.msg-id) and P1.MPDUIdentifier.IA5
to 822.local-part (from 822.msg-id).
4.6.4. P1.MPDUIdentifier -> 822.msg-
822.local-part is set to P1.MPDUIdentifier.IA5String, with
CRLF mapped to SPACE. If P1.CountryName is "", 822.domain
set to P1.AdministrationDomainName; Otherwise
P1.AdministrationDomainName ".." P1.CountryName. If there
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
This chapter gives detailed mappings for the functions outlined
chapters 1 and 2. It makes extensive use of the notations
mappings defined in chapters 3 and 4. This chapter is structured
follows
5.1. Basic RFC 822 -> X.400
5.2. A definition of some new RFC 822 elements, and their
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
as follows
822-P1
Mapped to P1.UMPDUEnvelope.originator (see chapter 4).
822-P1
Mapped to P1.RecipientInfo (see chapter 4).
The RFC 822 headers are used to generate both a P1.
and a P2.Heading. The IP Message will have either one or
P2.BodyParts which will be type P2.IA5Text with
P2.IA5Text.repertoire component. The last P2.BodyPart will
the RFC 822 message body. If there are any RFC 822 headers
indicate mapping into the P2.BodyPart, then two P2.BodyParts
generated. If a revised version of P2 allowed for
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
otherwise mapped (both 822.field-name and 822.field-body).
order of any such headers should be preserved. Similarly
ordering within P2.Heading and P1.UMPDUEnvelope should
ordering within the RFC 822 header. No P1 or P2 optional
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
defaults may be changed by the values in the RFC 822 message
mapped. The mandatory P1 and P2 components have the
defaults
P1.
The default should be unique value generated by the gateway
P1.
Always generated from 822-P1.
P1.
P1.ContentType.p
P1.
These will always be supplied from 822-P1.
P1.
The last P1.TraceInformation component is generated
that: P1.TraceInformation.GlobalDomainIdentifier is set
the local vaglue. P1.DomainSuppliedInfo.action is set
relayed. P1.DomainSuppliedInfo.arrival is set to the
time. P1.DomainSuppliedInfo.previous may be set if there
anything sensible to set it to
P2.
The default shoul