As per Relevance of the word mappings, we have this rfc below:
Network Working Group S.
Request for Comments 1138 University College
Updates: RFCs 822, 987, 1026 December 1989
Mapping between X.400(1988) / ISO 10021 and RFC 822
Status of this
This RFC suggests an electronic mail protocol mapping for
Internet community and UK Academic Community, and requests
and suggestions for improvements. This memo does not specify
Internet standard. Distribution of this memo is unlimited
This document describes a set of mappings which will
interworking between systems operating the CCITT X.400 (1988)
Recommendations on Message Handling Systems / ISO IEC 10021
Oriented Text Interchange Systems (MOTIS) [CCITT/ISO88a], and
using the RFC 822 mail protocol [Crocker82a] or protocols
from RFC 822. The approach aims to maximise the services
across the boundary, whilst not requiring unduly complex mappings
The mappings should not require any changes to end systems
This document is based on RFC 987 and RFC 1026 [Kille86a, Kille87a],
which define a similar mapping for X.400 (1984). This document
not obsolete the earlier ones, as its domain of application
different
This document specifies a mapping between two protocols.
specification should be used when this mapping is performed on
Internet or in the UK Academic Community. This specification may
modified in the light of implementation experience, but
substantial changes are expected
Table of
1. Overview ............................................... 2
1.1 X.400 ................................................. 2
1.2 RFC 822 ............................................... 3
1.3 The need for conversion ............................... 4
1.4 General approach ...................................... 4
1.5 Gatewaying Model ...................................... 5
1.6 RFC 987 ............................................... 7
1.7 Aspects not covered ................................... 8
1.8 Subsetting ............................................ 9
1.9 Document Structure .................................... 9
Kille [Page 1]
RFC 1138 Mapping X.400(88) and 822 December 1989
1.10 Acknowledgements ..................................... 10
2. Service Elements ....................................... 10
2.1 The Notion of Service Across a Gateway ................ 10
2.2 RFC 822 ............................................... 11
2.3 X.400 ................................................. 15
3. Basic Mappings ........................................ 24
3.1 Notation .............................................. 24
3.2 ASCII and IA5 ......................................... 25
3.3 Standard Types ........................................ 25
3.4 Encoding ASCII in Printable String .................... 28
4. Addressing ............................................. 29
4.1 A textual representation of MTS.ORAddress ............. 30
4.2 Basic Representation .................................. 30
4.3 EBNF.822-address <-> MTS.ORAddress .................... 34
4.4 Repeated Mappings ..................................... 43
4.5 Directory Names ....................................... 45
4.6 MTS Mappings .......................................... 45
4.7 IPMS Mappings ....... ................................. 48
5. Detailed Mappings ...................................... 52
5.1 RFC 822 -> X.400 ...................................... 52
5.2 Return of Contents .................................... 59
5.3 X.400 -> RFC 822 ...................................... 60
Appendix A Differences with RFC 987 ....................... 78
1. Introduction ........................................... 78
2. Service Elements ....................................... 78
3. Basic Mappings ......................................... 78
4. Addressing ............................................. 78
5. Detailed Mappings ...................................... 79
6. Appendices ............................................. 79
Appendix B Mappings specific to the JNT Mail .............. 79
1. Introduction ........................................... 79
2. Domain Ordering ........................................ 79
3. Acknowledge-To: ........................................ 79
4. Trace .................................................. 80
5. Timezone specification ................................. 80
6. Lack of 822-MTS originator specification ............... 80
Appendix C Mappings specific to UUCP Mail ................. 81
Appendix D Object Identifier Assignment ................... 82
Appendix E BNF Summary .................................... 82
Appendix F Format of address mapping tables ............... 89
References ................................................. 91
Chapter 1 --
1.1. X.400
This document relates to the CCITT 1988 X.400 Series
/ ISO IEC 10021 on the Message Oriented Text Interchange
Kille [Page 2]
RFC 1138 Mapping X.400(88) and 822 December 1989
(MOTIS). This ISO/CCITT standard is referred to in this document
"X.400", which is a convenient shorthand. Any reference to the 1984
CCITT Recommendations will be explicit. X.400 defines
Interpersonal Messaging System (IPMS), making use of a store
forward Message Transfer System. This document relates to the IPMS
and not to wider application of X.400. It is expected that X.400
will be implemented very widely
1.2. RFC 822
RFC 822 is the current specification of the messaging standard on
Internet. This standard evolved with the evolution of the
from the ARPANET (created by the Defense Advanced Research
Agency) to the Internet, which now involves over 1000 networks and
sponsored by DARPA, NSF, DOE, NASA, and NIH. It specifies an end
end message format. It is used in conjunction with a number
different message transfer protocol environments
SMTP
On the Internet and other TCP/IP networks, RFC 822 is used
conjunction with two other standards: RFC 821, also known
Simple Mail Transfer Protocol (SMTP) [Postel82a], and RFC 1034
which is a Specification for domains and a distributed
service [Mockapetris87a].
UUCP
UUCP is the UNIX to UNIX CoPy protocol, which is usually
over dialup telephone networks to provide a simple
transfer mechanism. There are some extensions to RFC 822,
particularly in the addressing. They use domains which
to RFC 1034, but not the corresponding domain
[Horton86a].
Some portions of Csnet follow the Internet protocols.
dialup portion of Csnet uses the Phonenet protocols as
replacement for RFC 821. This portion uses domains
conform to RFC 1034, but not the corresponding
nameservers
Some parts of Bitnet and related networks use RFC 822
protocols, with EBCDIC encoding
Kille [Page 3]
RFC 1138 Mapping X.400(88) and 822 December 1989
JNT Mail
A number of X.25 networks, particularly those associated
the UK Academic Community, use the JNT (Joint Network Team
Mail Protocol, also known as Greybook [Kille84a]. This is
with domains and name service specified by the JNT NRS (
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 users of the
provided by X.400 systems. This will also be a requirement in
where communities intend to make a transition to use of an X.400
IPMS, as conversion will be needed to ensure a smooth
transition. It is expected that there will be more than one gateway
and this specification will enable them to behave in a
manner. Note that the term gateway is used to describe a
performing the protocol mappings between RFC 822 and X.400. This
standard usage amongst mail implementors, but should be
carefully by transport and network service implementors
Consistency between gateways is 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 of
specification. These principles are goals, and are not achieved
all aspects of the specification
1. The specification should be pragmatic. There should not
a requirement for complex mappings for "Academic" reasons
Complex mappings should not be required to support
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
Kille [Page 4]
RFC 1138 Mapping X.400(88) and 822 December 1989
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
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 more
the objects themselves
5. The specification should be reversible. That is, a
transformation should bring you back to where you started
1.5. Gatewaying
1.5.1. X.400
X.400 defines the IPMS Abstract Service in X.420/ISO 10021-7,
[CCITT/ISO88b] which comprises of three basic services
1.
2.
3.
Management is a local interaction between the user and the IPMS,
is therefore not relevant to gatewaying. The first two
consist of operations to originate and receive the following
objects
1. IPM (Interpersonal Message). This has two components:
heading, and a body. The body is structured as a
of body parts, which may be basic components (e.g., IA
text, or G3 fax), or IP Messages. The heading consists
fields containing end to end user information, such
subject, primary recipients (To:), and importance
2. IPN (Inter Personal Notification). A notification
receipt of a given IPM at the UA level
The Origination service also allows for origination of a probe,
is an object to test whether a given IPM could be correctly received
The Reception service also allows for receipt of Delivery
(DR), which indicate delivery success or failure
Kille [Page 5]
RFC 1138 Mapping X.400(88) and 822 December 1989
These IPMS Services utilise the Message Transfer (MT)
Service [CCITT/ISO88c]. The MT Abstract Service provides
following three basic services
1. Submission (used by IPMS Origination
2. Delivery (used by IPMS Reception
3. Administration (used by IPMS Management
Administration is a local issue, and so does not affect
standard. Submission and delivery relate primarily to the
Message (comprising Envelope and Content), which carries an IPM
IPN (or other uninterpreted contents). There is also an Envelope
which includes an ID, an originator, and a list of recipients
Submission also includes the probe service, which supports the
Probe. Delivery also includes Reports, which indicate whether
given MTS Message has been delivered or not
The MTS is REFINED into the MTA (Message Transfer Agent) Service
which define the interaction between MTAs, along with the
for distributed operation. This service provides for transfer of
Messages, Probes, and Reports
1.5.2. RFC 822
RFC 822 is based on the assumption that there is an
service, which is here called the 822-MTS service. The 822-
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-
protocols, in particular SMTP, can provide additional functionality
but as these are neither mandatory in SMTP, nor available in
822-MTS protocols, they are not considered here. Details of
specific to two 822-MTS protocols are given in Appendices B and C
An RFC 822 message consists of a header, and content which
uninterpreted ASCII text. The header is divided into fields,
are the protocol elements. Most of these fields are analogous to P
heading fields, although some are analogous to MTS Service
or MTA Service Elements
Kille [Page 6]
RFC 1138 Mapping X.400(88) and 822 December 1989
1.5.3. The
Given this functional description of the two services, the
nature of a gateway can now be considered. It would be elegant
consider the 822-MTS service mapping onto the MTS Service
and RFC 822 mapping onto an IPM, but reality just does not fit
Another elegant approach would be to treat this document as
definition of an X.400 Access Unit (AU). Again, reality does
fit. It is necessary to consider that the IPM format definition,
IPMS Service Elements, the MTS Service Elements, and MTA
Elements on one side are mapped into RFC 822 + 822-MTS on the
in a slightly tangled manner. The details of the tangle will be
clear in Chapter 5. Access to the MTA Service Elements is minimised
The following basic mappings are thus defined. When going from
822 to X.400, an RFC 822 message and the associated 822-
information is always mapped into an IPM (MTA, MTS, and
Services). Going from X.400 to RFC 822, an RFC 822 message and
associated 822-MTS information may be derived from
1. A Report (MTA, and MTS Services
2. An IPN (MTA, MTS, and IPMS Services
3. An IPM (MTA, MTS, and IPMS Services
Probes (MTA Service) must be processed by the gateway, as
in Chapter 5. MTS Messages containing Content Types other than
defined by the IPMS are not mapped by the gateway, and should
rejected at the gateway
1.5.4. Repeated
The mappings specified here are designed to work where a
traverses multiple times between X.400 and RFC 822. This is
essential, particularly in the case of distribution lists. However
in general, this will lead to a level of service which is the
common denominator (approximately the services offered by RFC 822).
In particular, there is no expectation of additional X.400
being mapped - although this may be possible in some cases
1.6. RFC 987
Much of this work is based on the initial specification of RFC 987
and in its addendum RFC 1026. A basic decision is that the
will be to the full 1988 version of X.400, and not to a 1984
compatible subset. This is important, to give good support
communities which will utilise full X.400 at an early date. This
Kille [Page 7]
RFC 1138 Mapping X.400(88) and 822 December 1989
the following implications
- This document does not obsolete RFC 987, as it has
different domain of application
- If a gatewayed message is being transferred to a 1984
system, then RFC 987 should be used. If the X.400 side
the gateway is a 1988 system, then it should be operated
1984 compatibility mode. There is no advantage and
disadvantage in using the new mapping, and later on
X.400 downgrading rules. Note that in an environment
RFC 822 is of major importance, it may be desirable
downgrading to consider the case where the message
originated in an RFC 822 system, and mapped according
this specification
- New features of X.400 can be used to provide a much
mapping than that defined in RFC 987.
Unnecessary change is usually a bad idea. Changes on the RFC 822
side are avoided as far as possible, so that RFC 822 users do not
arbitrary differences between systems conforming to
specification, and those following RFC 987. Changes on the X.400
side are minimised, but are more acceptable, due to the mapping
a new set of services and protocols
A summary of changes made is given in Appendix A
1.7. Aspects not
There have been a number of cases where RFC 987 was used in a
which was not intended. This section is to make clear
limitations of scope. In particular, this specification does
specify
- Extensions of RFC 822 to provide access to all X.400
- X.400 user interface
These are really coupled. To map the X.400 services,
specification defines a number of extensions to RFC 822. As a
effect, these give the 822 user access to SOME X.400 services
However, the aim on the RFC 822 side is to preserve current service
and it is intentional that access is not given to all X.400 services
Thus, it will be a poor choice for X.400 implementors to use
987(88) as an interface - there are too many aspects of X.400
Kille [Page 8]
RFC 1138 Mapping X.400(88) and 822 December 1989
cannot be accessed through it. If a text interface is desired,
specification targeted at X.400, without RFC 822 restrictions,
be more appropriate
1.8.
This proposal specifies a mapping which is appropriate to
services in existing RFC 822 communities. Implementations
specifications which subset this specification are
discouraged
1.9. Document
This document has five chapters
1. Overview - this chapter
2. Service Elements - This describes the (end user)
mapped by a gateway
3. Basic mappings - This describes some basic notation used
Chapters 3-5, the mappings between character sets, and
fundamental protocol elements
4. Addressing - This considers the mapping between X.400 O/
names and RFC 822 addresses, which is a fundamental
component
5. Detailed Mappings - This describes the details of all
mappings
There are also six appendices
A. Differences with RFC 987
B. Mappings Specific to JNT
C. Mappings Specific to UUCP
D. Object Identifier
E. BNF
F. Format of Address
WARNING
THE REMAINDER OF THIS SPECIFICATION IS TECHNICALLY DETAILED
Kille [Page 9]
RFC 1138 Mapping X.400(88) and 822 December 1989
IT WILL NOT MAKE SENSE, EXCEPT IN THE CONTEXT OF RFC 822
X.400 (1988). DO NOT ATTEMPT TO READ THIS DOCUMENT
YOU ARE FAMILIAR WITH THESE SPECIFICATIONS
1.10.
This work was partly sponsored by the Joint Network Team.
workshop at UCL in June 1989 to work on this specification was
an IFIP WG 6.5 meeting
The work in this specification was substantially based on RFC 987,
which had input from many people
Useful comments and suggestions were made by Pete Cowen (
Univ), Jim Craigie (JNT), Christian Huitema (Inria), Peter
(Prime), Julian Onions (Nottingham Univ), Sandy Shaw (
Univ), Einar Stefferud (NMA), and Peter Sylvester (GMD).
Chapter 2 -- Service
This chapter considers the services offered across a gateway
according to this specification. It gives a view of
functionality provided by such a gateway for communication with
in the opposite domain. This chapter considers service mappings
the context of SINGLE transfers only, and not repeated
through multiple gateways
2.1. The Notion of Service Across a
RFC 822 and X.400 provide a number of services to the end user.
chapter 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
2.1.1. Origination of
When a user originates a message, a number of services are available
Some of these imply actions (e.g., delivery to a recipient), and
are insertion of known data (e.g., specification of a subject field).
This chapter describes, for each offered service, to what extent
is supported for a recipient accessed through a gateway. There
three levels of support
The corresponding protocol elements map well, and so
service can be fully provided
Kille [Page 10]
RFC 1138 Mapping X.400(88) and 822 December 1989
Not
The service cannot be provided, as there is a
mismatch
Partial
The service can be partially fulfilled
In the first two cases, the service is simply marked as "Supported
or "Not Supported". Some explanation may be given if there
additional implications, or the (non) support is not intuitive.
partial support, the level of partial support is summarised.
partial support is good, this will be described by a phrase such
"Supported by use of.....". A common case of this is where
service is mapped onto a non- standard service on the other side
the gateway, and this would have lead to support if it had been
standard service. In many cases, this is equivalent to support.
partial support, an indication of the mechanism is given, in order
give a feel for the level of support provided. Note that this is
a replacement for Chapter 5, where the mapping is fully specified
If a service is described as supported, this implies
- Semantic correspondence
- No (significant) loss of information
- Any actions required by the service element
An example of a service gaining full support: If an RFC 822
originator specifies a Subject: field, this is considered to
supported, as an X.400 recipient will get a subject indication
All RFC 822 services are supported or partially supported
origination. The implications of non-supported X.400 services
described under X.400.
2.1.2. Reception of
For reception, the list of service elements required to support
mapping is specified. This is really an indication of what
recipient might expect to see in a message which has been
originated
2.2. RFC 822
RFC 822 does not explicitly define service elements, as distinct
protocol elements. However, all of the RFC 822 header fields,
the exception of trace, can be regarded as corresponding to
Kille [Page 11]
RFC 1138 Mapping X.400(88) and 822 December 1989
RFC 822 service elements
2.2.1. Origination in RFC 822
A mechanism of mapping, used in several cases, is to map the RFC 822
header into a heading extension in the IPM (InterPersonal Message).
This can be regarded as partial support, as it makes the
available to any X.400 implementations which are interested in
services. Communities which require significant RFC 822
should require that their X.400 User Agents are able to display
heading extensions. Support for the various service
(headers) is now listed
Date
Supported
From
Supported. For messages where there is also a sender field
the mapping is to "Authorising Users Indication", which
subtly different semantics to the general RFC 822 usage
From:.
Sender
Supported
Reply-To
Supported
To: Supported
Cc: Supported
Bcc: Supported
Message-Id
Supported
In-Reply-To
Supported, for a single reference. Where
references are given, partial support is given by mapping
"Cross Referencing Indication". This gives
semantics
References
Supported
Keywords
Supported by use of a heading extension
Kille [Page 12]
RFC 1138 Mapping X.400(88) and 822 December 1989
Subject
Supported
Comments
Supported by use of an extra body part
Encrypted
Supported by use of a heading extension
Resent-*
Supported by use of a heading extension. Note
addresses in these fields are mapped onto text, and so
not accessible to the X.400 user as addresses.
principle, fuller support would be possible by mapping
a forwarded IP Message, but this is not suggested
Other
In particular X-* fields, and "illegal" fields in
usage (e.g., "Fruit-of-the-day:") are supported by use
heading extensions
2.2.2. Reception by RFC 822
This considers reception by an RFC 822 User Agent of a
originated in an X.400 system and transferred across a gateway.
following standard services (headers) may be present in such
message
Date
From
Sender
Reply-To
To
Cc
Bcc
Message-Id
In-Reply-To
References
Kille [Page 13]
RFC 1138 Mapping X.400(88) and 822 December 1989
Subject
The following non-standard services (headers) may be present.
are defined in more detail in Chapter 5 (5.3.4, 5.3.6, 5.3.7):
Autoforwarded
Content-Identifier
Conversion
Conversion-With-Loss
Delivery-Date
Discarded-X400-IPMS-Extensions
Discarded-X400-MTS-Extensions
DL-Expansion-History
Deferred-Delivery
Expiry-Date
Importance
Incomplete-Copy
Language
Latest-Delivery-Time
Message-Type
Obsoletes
Original-Encoded-Information-Types
Originator-Return-Address
Priority
Redirection-History
Reply-By
Requested-Delivery-Method
Kille [Page 14]
RFC 1138 Mapping X.400(88) and 822 December 1989
Sensitivity
X400-Content-Type
X400-MTS-Identifier
X400-Originator
X400-Received
X400-Recipients
2.3. X.400
2.3.1. Origination in X.400
When mapping services from X.400 to RFC 822 which are not
by RFC 822, new RFC 822 headers are defined. It is intended
these fields will be registered, and that co-operating RFC 822
systems may use them. Where these new fields are used, and no
action is implied, the service can be regarded as being
supported. Chapter 5 describes how to map X.400 services onto
new headers. Other elements are provided, in part, by the gateway
they cannot be provided by RFC 822.
Some service elements are marked N/A (not applicable). There
five cases, which are marked with different comments
N/A (local
These elements are only applicable to User Agent /
Transfer Agent interaction and so they cannot apply to
822 recipients
N/A (PDAU
These service elements are only applicable where
recipient is reached by use of a Physical Delivery
Unit (PDAU), and so do not need to be mapped by the gateway
N/A (reception
These services are only applicable for reception
N/A (prior
If requested, this service must be performed prior to
gateway
N/A (MS
These services are only applicable to Message Store (i.e.,
local service).
Kille [Page 15]
RFC 1138 Mapping X.400(88) and 822 December 1989
Finally, some service elements are not supported. In particular,
new security services are not mapped onto RFC 822. Unless
indicated, the behaviour of service elements marked as not
will depend on the criticality marking supplied by the user. If
element is marked as critical for transfer or delivery, a non
delivery notification will be generated. Otherwise, the
request will be ignored
2.3.1.1. Basic Interpersonal Messaging
These are the mandatory IPM services as listed in Section 19.8
X.400 / ISO/IEC 10021-1, listed here in the order given.
19.8 has cross references to short definitions of each service
Access
N/A (local).
Content Type
Supported by a new RFC 822 header (Content-Type:).
Converted
Supported by a new RFC 822 header (X400-Received:).
Delivery Time Stamp
N/A (reception).
IP Message
Supported
Message
Supported, by use of a new RFC 822
(X400-MTS-Identifier). This new header is required,
X.400 has two message-ids whereas RFC 822 has only one (
previous service).
Non-delivery
Not supported, although in general an RFC 822 system
return error reports by use of IP messages. In
service elements, this pragmatic result can be treated
effective support of this service element
Original Encoded Information Types
Supported as a new RFC 822
(Original-Encoded-Information-Types:).
Submission Time Stamp
Supported
Kille [Page 16]
RFC 1138 Mapping X.400(88) and 822 December 1989
Typed
Some types supported. IA5 is fully supported
ForwardedIPMessage is supported, with some loss
information. Other types get some measure of support
dependent on X.400 facilities for conversion to IA5.
will only be done where content conversion is
prohibited
User Capabilities
N/A (local).
2.3.1.2. IPM Service Optional User
This section describes support for the optional (user selectable)
services as listed in Section 19.9 of X.400 / ISO/IEC 10021- 1,
listed here in the order given. Section 19.9 has cross references
short definitions of each service
Additional Physical
N/A (PDAU).
Alternate Recipient
Not supported. There is no RFC 822 service equivalent
prohibition of alternate recipient assignment (e.g., an
822 system may freely send an undeliverable message to
local postmaster). Thus, the gateway cannot
assignment of alternative recipients on the RFC 822 side
This service really means giving the user control as
whether or not an alternate recipient is allowed.
specification requires transfer of messages to RFC 822
irrespective of this service request, and so this service
not supported
Authorising User's
Supported
Auto-forwarded
Supported as new RFC 822 header (Auto-Forwarded:).
Basic Physical
N/A (PDAU).
Blind Copy Recipient
Supported
Body Part Encryption
Supported by use of a new RFC 822
(Original-Encoded-Information-Types:), although in
Kille [Page 17]
RFC 1138 Mapping X.400(88) and 822 December 1989
cases it will not be possible to map the body part
question
Content
Not supported
Content
Not supported
Conversion
Supported. In this case, only messages with IA5 body parts
other body parts which contain only IA5, and Forwarded
Messages (subject recursively to the same restrictions),
will be mapped
Conversion Prohibition in Case of Loss of
Supported
Counter
N/A (PDAU).
Counter Collection with
N/A (PDAU).
Cross Referencing
Supported
Deferred
N/A (prior). This service should always be provided by
MTS prior to the gateway. A new RFC 822
(Deferred-Delivery:) is provided to transfer information
this service to the recipient
Deferred Delivery
N/A (local).
Delivery
Supported. This is performed at the gateway. Thus,
notification is sent by the gateway to the originator.
the 822-MTS protocol is JNT Mail, a notification may also
sent by the recipient UA
Delivery via Bureaufax
N/A (PDAU).
Designation of Recipient by Directory
N/A (local).
Kille [Page 18]
RFC 1138 Mapping X.400(88) and 822 December 1989
Disclosure of Other
Supported by use of a new RFC 822 header (X400-Recipients:).
This is descriptive information for the RFC 822 recipient
and is not reverse mappable
DL Expansion History
Supported by use of a new RFC 822
(DL-Expansion-History:).
DL Expansion
Distribution List means MTS supported distribution list,
the manner of X.400. This service does not exist in the
822 world. RFC 822 distribution lists should be regarded
an informal redistribution mechanism, beyond the scope
this control. Messages will be sent to RFC 822,
irrespective of whether this service is requested
Theoretically therefore, this service is supported,
in practice it may appear that it is not supported
Express Mail
N/A (PDAU).
Expiry Date
Supported as new RFC 822 header (Expiry-Date:). In general
no automatic action can be expected
Explicit
N/A (prior).
Forwarded IP Message
Supported, with some loss of information. The message
forwarded in an RFC 822 body, and so can only be
visually
Grade of Delivery
N/A (PDAU
Importance
Supported as new RFC 822 header (Importance:).
Incomplete Copy
Supported as new RFC 822 header (Incomplete-Copy:).
Language
Supported as new RFC 822 header (Language:).
Latest Delivery
Not supported. A new RFC 822 header (Latest-Delivery-Time:)
Kille [Page 19]
RFC 1138 Mapping X.400(88) and 822 December 1989
is provided, which may be used by the recipient
Message Flow
Not supported
Message Origin
N/A (reception).
Message Security
Not supported
Message Sequence
Not supported
Multi-Destination
Supported
Multi-part
Supported, with some loss of information, in that
structuring cannot be formalised in RFC 822.
Non Receipt Notification
Not supported
Non Repudiation of
Not supported
Non Repudiation of
N/A (reception).
Non Repudiation of
N/A (local).
Obsoleting
Supported as new RFC 822 header (Obsoletes:).
Ordinary
N/A (PDAU).
Originator
Supported
Originator Requested Alternate
Not supported, but is placed as comment next to
(X400-Recipients:).
Physical Delivery Notification by
N/A (PDAU).
Kille [Page 20]
RFC 1138 Mapping X.400(88) and 822 December 1989
Physical Delivery Notification by
N/A (PDAU).
Physical Forwarding
Supported by use of a comment in a new RFC 822
(X400-Recipients:), associated with the recipient
question
Physical Forwarding
Supported by use of a comment in a new RFC 822
(X400-Recipients:), associated with the recipient
question
Prevention of Non-delivery
Supported, as delivery notifications cannot be generated
RFC 822. In practice, errors will be returned as
Messages, and so this service may appear not to be
(see Non-delivery Notification).
Primary and Copy Recipients
Supported
Supported at the gateway (i.e., the gateway services
probe).
Probe Origin
N/A (reception).
Proof of
Not supported
Proof of
N/A (local).
Receipt Notification Request
Not supported
Redirection Allowed by
Redirection means MTS supported redirection, in the
of X.400. This service does not exist in the RFC 822 world
RFC 822 redirection (e.g., aliasing) should be regarded
an informal redirection mechanism, beyond the scope of
control. Messages will be sent to RFC 822, irrespective
whether this service is requested. Theoretically therefore
this service is supported, although in practice it
appear that it is not supported
Kille [Page 21]
RFC 1138 Mapping X.400(88) and 822 December 1989
Registered
N/A (PDAU).
Registered Mail to Addressee in
N/A (PDAU).
Reply Request
Supported as comment next to address
Replying IP Message
Supported
Report Origin
N/A (reception).
Request for Forwarding
N/A (PDAU).
Requested Delivery
N/A (local). The services required must be dealt with
submission time. Any such request is made available
the gateway by use of a comment associated with
recipient in question
Return of
In principle, this is N/A, as non-delivery notifications
not supported. In practice, most RFC 822 systems
return part or all of the content along with the IP
indicating an error (see Non-delivery Notification).
Sensitivity
Supported as new RFC 822 header (Sensitivity:).
Special
N/A (PDAU).
Stored Message
N/A (MS).
Stored Message
N/A (MS).
Stored Message
N/A (MS).
Stored Message
N/A (MS).
Kille [Page 22]
RFC 1138 Mapping X.400(88) and 822 December 1989
Subject
Supported
Undeliverable Mail with Return of Physical
N/A (PDAU).
Use of Distribution
In principle this applies only to X.400
distribution lists (see DL Expansion Prohibited).
Theoretically, this service is N/A (prior). In practice
because of informal RFC 822 lists, this service can
regarded as supported
2.3.2. Reception by X.400
2.3.2.1. Standard Mandatory
The following standard IPM mandatory user facilities may be
for reception of RFC 822 originated mail by an X.400 UA
Content Type
Delivery Time Stamp
IP Message
Message
Non-delivery
Original Encoded Information Types
Submission Time Stamp
Typed
2.3.2.2. Standard Optional
The following standard IPM optional user facilities may be
for reception of RFC 822 originated mail by an X.400 UA
Authorising User's
Blind Copy Recipient
Cross Referencing
Originator
Kille [Page 23]
RFC 1138 Mapping X.400(88) and 822 December 1989
Primary and Copy Recipients
Replying IP Message
Subject
2.3.2.3. New
A new service "RFC 822 Header Field" is defined using the
facilities. This allows for any RFC 822 header field to
represented. It may be present in RFC 822 originated messages,
are received by an X.400 UA
Chapter 3 -- Basic
3.1.
The X.400 protocols are encoded in a structured manner according
ASN.1, whereas RFC 822 is text encoded. To define a
mapping, it is necessary to refer to detailed protocol elements
each format. A notation to achieve this is described in
section
3.1.1. RFC 822
Structured text is defined according to the Extended Backus Naur
(EBNF) defined in Section 2 of RFC 822 [Crocker82a]. In the
definitions used in this specification, the syntax rules given
Appendix D of RFC 822 are assumed. When these EBNF tokens
referred to outside an EBNF definition, they are identified by
string "822." appended to the beginning of the string (e.g.,
822.addr-spec). Additional syntax rules, to be used throughout
specification, are defined in this chapter
The EBNF is used in two ways
1. To describe components of RFC 822 messages (or of 822-
components). In this case, the lexical analysis defined
Section 3 of RFC 822 should be used. When these new
tokens are referred to outside an EBNF definition, they
identified by the string "EBNF." appended to the
of the string (e.g., EBNF.bilateral-info).
2. To describe the structure of IA5 or ASCII information not
an RFC 822 message. In these cases, tokens will either
self delimiting, or be delimited by self delimiting tokens
Comments and LWSP are not used as delimiters
Kille [Page 24]
RFC 1138 Mapping X.400(88) and 822 December 1989
3.1.2. ASN.1
An element is referred to with the following syntax, defined in EBNF
element = service "." definition *( "." definition )
service = "IPMS" / "MTS" / "MTA
definition = identifier /
identifier = ALPHA *< ALPHA or DIGIT or "-" >
context = "[" 1*DIGIT "]"
The EBNF.service keys are shorthand for the following
specifications
IPMS IPMSInformationObjects defined in Annex E of X.420 /
10021-7.
MTS MTSAbstractService defined in Section 9 of X.411 /
10021-4.
MTA MTAAbstractService defined in Section 13 of X.411 /
10021-4.
The first EBNF.identifier identifies a type or value key in
context of the defined service specification.
EBNF.identifiers identify a value label or type in the context of
first identifier (SET or SEQUENCE). EBNF.context indicates a
tag, and is used where there is no label or type to uniquely
a component. The special EBNF.identifier keyword "value" is used
denote an element of a sequence
For example, IPMS.Heading.subject defines the subject element of
IPMS heading. The same syntax is also used to refer to
values. For example, MTS.EncodedInformationTypes.[0].g3Fax refers
a value of MTS.EncodedInformationTypes.[0].
3.2. ASCII and IA
A gateway will interpret all IA5 as ASCII. Thus, mapping
these forms is conceptual
3.3. Standard
There is a need to convert between ASCII text, and some of the
defined in ASN.1 [CCITT/ISO88d]. For each case, an EBNF
definition is given, for use in all of this specification,
leads to a mapping between ASN.1, and an EBNF construct
All EBNF syntax definitions of ASN.1 types are in lower case,
Kille [Page 25]
RFC 1138 Mapping X.400(88) and 822 December 1989
ASN.1 types are 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-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
ps-delim = "(" / ")"
ps-char = ps-delim / ps-restricted-
This can be used to represent real printable strings in EBNF
3.3.4. T.61
In cases where T.61 strings are only used for conveying
interpreted information, the aim of a mapping should be to render
characters appropriately in the remote character set, rather than
maximise reversibility. For these cases, the mappings to IA5
in CCITT Recommendation X.408 (1988) should be used [CCITT/ISO88a].
These will then be encoded in ASCII
There is also a need to represent Teletex Strings in ASCII, for
aspects of O/R Address. For these, the following encoding is used
teletex-string = *( ps-char / t61-encoded )
t61-encoded = "{" 1* t61-encoded-char "}"
t61-encoded-char = 3
Common characters are mapped simply. Other octets are mapped using
quoting mechanism similar to the printable string mechanism.
octet is represented as 3 decimal digits
There are a number of places where a string may have a Teletex and/
Kille [Page 26]
RFC 1138 Mapping X.400(88) and 822 December 1989
Printable String representation. The following BNF is used
represent this
teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ]
The natural mapping is restricted to EBNF.ps-char, in order to
the full BNF easier to parse
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 an
day of the week, but this is redundant. Therefore a
mapping can be made between these constructs
Note
In practice, a gateway will need to parse various
variants on 822.date-time. In cases where 822.date-
cannot be parsed, it is recommended that the derived
is set to the value at the time of translation
The UTCTime format which specifies the timezone offset should
used
3.3.6.
A basic ASN.1 Integer will be mapped onto EBNF.numericstring. In
cases ASN.1 will enumerate Integer values or use ENUMERATED. An
encoding labelled-integer is provided. When mapping from EBNF
ASN.1, only the integer value is mapped, and the associated text
discarded. When mapping from ASN.1 to EBNF, addition of
appropriate text label is strongly encouraged
labelled-integer ::= [ key-string ] "(" numericstring ")"
key-string = *key-
key-char =
3.3.7. Object
Object identifiers are represented in a form similar to
given in ASN.1. The numbers are mandatory, to ease encoding
It is recommended that as many strings as possible are used,
facilitate user recognition
object-identifier ::= [ defined-value ] oid-comp-
Kille [Page 27]
RFC 1138 Mapping X.400(88) and 822 December 1989
oid-comp-list ::= oid-comp oid-comp-
| oid-
defined-value ::= key-
oid-comp ::= [ key-string ] "(" numericstring ")"
3.4. Encoding ASCII in Printable
Some information in RFC 822 is represented in ASCII, and needs to
mapped into X.400 elements encoded as printable string. For
reason, a mechanism to represent ASCII encoded as PrintableString
needed
A structured subset of EBNF.printablestring is now defined. This
be used to encode ASCII in the PrintableString character set
ps-encoded = *( ps-restricted-char / ps-encoded-char )
ps-encoded-char = "(a)" ; (@)
/ "(p)" ; (%)
/ "(b)" ; (!)
/ "(q)" ; (")
/ "(u)" ; (_)
/ "(l)" ; "("
/ "(r)" ; ")"
/ "(" 3DIGIT ")"
The 822.3DIGIT in EBNF.ps-encoded-char must have range 0-127, and
interpreted in decimal as the corresponding ASCII character.
encodings are given for: at sign (@), percent (%),
mark/bang (!), double quote ("), underscore (_), left bracket ((),
and right bracket ()). These characters, with the exception of
brackets, are not included in PrintableString, but are common in
822 addresses. The abbreviations will ease specification of RFC 822
addresses from an X.400 system. These special encodings should
mapped in a case insensitive manner, but always be generated in
case
A reversible mapping between PrintableString and ASCII can now
defined. The reversibility means that some values of
string (containing round braces) cannot be generated from ASCII
Therefore, this mapping must only be used in cases where
printable strings may only be derived from ASCII (and will
have a restricted domain). For example, in this specification, it
only applied to a Domain defined attribute which will have
generated by use of this specification and a value such as "("
not be possible
Kille [Page 28]
RFC 1138 Mapping X.400(88) and 822 December 1989
To encode ASCII as PrintableString, the EBNF.ps-encoded syntax
used, with all EBNF.ps-restricted-char mapped directly. All
822.CHAR are encoded as EBNF.ps-encoded-char
To encode PrintableString as ASCII, parse PrintableString
EBNF.ps-encoded, and then reverse the previous mapping. If
PrintableString cannot be parsed, then the mapping is being
in to an inappropriate value, and an error should be given to
procedure doing the mapping. In some cases, it may be preferable
pass the printable string through unaltered
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) <-> @
(l)a(r) <-> (a
(126) <-> ~
( -> (
(l) <-> (
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 textual representation of an X.400 O/
Address
Initially, we consider an address in the (human) mail user sense
"what is typed at the mailsystem to reference a mail user". A
RFC 822 address is defined by the EBNF EBNF.822-address
822-address = [ route ] addr-
In an 822-MTS 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 O/R Address, used by the MTS for routing, is
by MTS.ORAddress. In IPMS, the MTS.ORAddress is encapsulated
Kille [Page 29]
RFC 1138 Mapping X.400(88) and 822 December 1989
IPMS.ORDescriptor
It can be seen that RFC 822 822.address must be mapped
IPMS.ORDescriptor, and that RFC 822 EBNF.822-address must be
with MTS.ORAddress
4.1. A textual representation of MTS.
MTS.ORAddress is structured as a set of attribute value pairs. It
clearly necessary to be able to encode this in ASCII for
purposes. All aspects should be encoded, in order to
return of error messages, and to optimise third party replies
4.2. Basic
An O/R Address has a number of structured and
attributes. For each unstructured attribute, a key and an
is specified. For structured attributes, the X.400 attribute
mapped onto one or more attribute value pairs. For domain
attributes, each element of the sequence will be mapped onto a
(key and two values), with each value having the same encoding.
attributes are as follows, with 1984 attributes given in the
part of the table. For each attribute, a reference is given
consisting of the relevant sections in X.402 / ISO 10021-2, and
extension identifier for 88 only attributes
Attribute (Component) Key Enc Ref
84/88
MTS.CountryName C P 18.3.3
MTS.AdministrationDomainName ADMD P 18.3.1
MTS.PrivateDomainName PRMD P 18.3.21
MTS.NetworkAddress X121 N 18.3.7
MTS.TerminalIdentifier T-ID N 18.3.23
MTS.OrganizationName O P/T 18.3.9
MTS.OrganizationalUnitNames.value OU P/T 18.3.10
MTS.NumericUserIdentifier UA-ID N 18.3.8
MTS.PersonalName PN P/T 18.3.12
MTS.PersonalName.surname S P/T 18.3.12
MTS.PersonalName.given-name G P/T 18.3.12
MTS.PersonalName.initials I P/T 18.3.12
MTS.
.generation-qualifier GQ P/T 18.3.12
MTS.DomainDefinedAttribute.value DD P/T 18.1
Kille [Page 30]
RFC 1138 Mapping X.400(88) and 822 December 1989
88
MTS.CommonName CN P/T 18.3.2 1
MTS.TeletexCommonName CN P/T 18.3.2 2
MTS.TeletexOrganizationName O P/T 18.3.9 3
MTS.TeletexPersonalName PN P/T 18.3.12 4
MTS.TeletexPersonalName.surname S P/T 18.3.12 4
MTS.TeletexPersonalName.given-name G P/T 18.3.12 4
MTS.TeletexPersonalName.initials I P/T 18.3.12 4
MTS.
.generation-qualifier GQ P/T 18.3.12 4
MTS.
.value OU P/T 18.3.10 5
MTS.
.value DD P/T 18.1 6
MTS.PDSName PD-SYSTEM P 18.3.11 7
MTS.PhysicalDeliveryCountryName PD-C P 18.3.13 8
MTS.PostalCode POSTCODE P 18.3.19 9
MTS.PhysicalDeliveryOfficeName PD-OFFICE P/T 18.3.14 10
MTS.PhysicalDeliveryOfficeNumber PD-OFFICE-NUM P/T 18.3.15 11
MTS.ExtensionORAddressComponents PD-EXT-D P/T 18.3.4 12
MTS.PhysicalDeliveryPersonName PD-PN P/T 18.3.17 13
MTS.PhysicalDelivery PD-O P/T 18.3.16 14
MTS.
AddressComponents PD-EXT-LOC P/T 18.3.5 15
MTS.UnformattedPostalAddress PD-ADDRESS P/T 18.3.25 16
MTS.StreetAddress STREET P/T 18.3.22 17
MTS.PostOfficeBoxAddress PO-BOX P/T 18.3.18 18
MTS.PosteRestanteAddress POSTE-RESTANTE P/T 18.3.20 19
MTS.UniquePostalName PD-UNIQUE P/T 18.3.26 20
MTS.LocalPostalAttributes PD-LOCAL P/T 18.3.6 21
MTS.
.e163-4-address.number NET-NUM N 18.3.7 22
MTS.
.e163-4-address.sub-address NET-SUB N 18.3.7 22
MTS.
.psap-address NET-PSAP X 18.3.7 22
MTS.TerminalType NET-TTYPE I 18.3.24 23
The following keys identify different EBNF encodings, which
associated with the ASCII representation of MTS.ORAddress
Key
P
N
T teletex-
Kille [Page 31]
RFC 1138 Mapping X.400(88) and 822 December 1989
P/T teletex-and-or-
I labelled-
X presentation-
The BNF for presentation-address is taken from the specification "
String Encoding of Presentation Address" [Kille89a].
In most cases, the EBNF encoding maps directly to the ASN.1
of the attribute. There are a few exceptions. In cases where
attribute can be encoded as either a PrintableString or
(Country, ADMD, PRMD), either form should be mapped into the BNF
When generating ASN.1, the NumericString encoding should be used
the string contains only digits
There are a number of cases where the P/T (teletex-and-or-ps
representation is used. Where the key maps to a single attribute
this choice is reflected in the encoding of the attribute (
10-21). For most of the 1984 attributes and common name, there is
printablestring and a teletex variant. This pair of attributes
mapped onto the single component here. This will give a
mapping for the common cases where only one form of the name is used
4.2.1. Encoding of Personal
Handling of Personal Name and Teletex Personal Name based purely
the EBNF.standard-type syntax defined above is likely to be clumsy
It seems desirable to utilise the "human" conventions for
these components. A syntax is defined, which is designed to
a clean encoding for the common cases of O/R address
where
1. There is no generational
2. Initials contain only
3. Given Name does not contain full stop ("."), and is at
two characters long
4. If Surname contains full stop, then it may not be in
first two characters, and either initials or given name
present
The following EBNF is defined
encoded-pn = [ given "." ] *( initial "." )
given = 2*
Kille [Page 32]
RFC 1138 Mapping X.400(88) and 822 December 1989
initial =
surname =
This can be used to map from any string containing only
string characters to an O/R address personal name. Parse the
according to the EBNF. The given name and surname are
directly. All EBNF.initial tokens are concatenated
intervening full stops to generate the initials
For an O/R address which follows the above restrictions, a string
be derived in the natural manner. In this case, the mapping will
reversible
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 X.400 suggest that Initials is used to encode ALL initials
Therefore, the proposed encoding is "natural" when either
or Initials, but not both, are present. The case where both
present can be encoded, but this appears to be contrived
4.2.2. Standard Encoding of MTS.
Given this structure, we can specify a BNF representation of an O/
Address
std-or-address = 1*( "/" attribute "=" value ) "/"
attribute = standard-
/ "RFC-822"
/ registered-dd-
/ dd-key "." std-
standard-type = key-
Kille [Page 33]
RFC 1138 Mapping X.400(88) and 822 December 1989
registered-dd-
= key-
dd-key = key-
value = std-
std-
= *( std-char / std-pair )
std-char = <"{", "}", "*", and any ps-
except "/" and "=">
std-pair = "$" ps-
The standard-type is any key defined in the table in Section 4.2,
except PN, and DD. The value, after quote removal, should
interpreted according to the defined encoding
If the standard-type is PN, the value is interpreted according
EBNF.encoded-pn, and the components of MTS.PersonalName and/
MTS.TeletexPersonalName derived accordingly
If dd-key is the recognised Domain Defined string (DD), then the
and value should be interpreted according to the syntax implied
the encoding, and aligned to either the teletex or printable
form. Key and value should have the same encoding
If value is "RFC-822", then the (printable string) Domain
Type of "RFC-822" is assumed. This is an optimised encoding of
domain defined type defined by this specification
The matching of all keywords should be