As per Relevance of the word delivery, we have this rfc below:
Network Working Group S.
Request for Comments: 2156 Isode Ltd
Obsoletes: 987, 1026, 1138, 1148, 1327, 1495 January 1998
Updates: 822
Category: Standards
MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
Table of
1 - Overview ...................................... 3
1.1 - X.400 ......................................... 3
1.2 - RFC 822 and MIME .............................. 3
1.3 - The need for conversion ....................... 4
1.4 - General approach .............................. 4
1.5 - Gatewaying Model .............................. 5
1.6 - Support of X.400 (1984) ....................... 8
1.7 - X.400 (1992) .................................. 8
1.8 - MIME .......................................... 8
1.9 - Body Parts .................................... 8
1.10 - Local and Global Scenarios .................... 9
1.11 - Compatibility with previous versions .......... 10
1.12 - Aspects not covered ........................... 10
1.13 - Subsetting .................................... 11
1.14 - Specification Language ........................ 11
1.15 - Related Specifications ........................ 11
1.16 - Document Structure ............................ 12
1.17 - Acknowledgements .............................. 12
2 - Service Elements .............................. 13
2.1 - The Notion of Service Across a Gateway ........ 13
2.2 - RFC 822 ....................................... 15
2.3 - X.400 ......................................... 18
3 - Basic Mappings ................................ 27
3.1 - Notation ...................................... 27
Kille Standards Track [Page 1]
RFC 2156 MIXER January 1998
3.2 - ASCII and IA5 ................................. 29
3.3 - Standard Types ................................ 29
3.4 - Encoding ASCII in Printable String ............ 33
3.5 - RFC 1522 ...................................... 34
4 - Addressing and Message IDs .................... 35
4.1 - A textual representation of MTS.ORAddress ..... 36
4.2 - Global Address Mapping ........................ 43
4.3 - EBNF.822-address <-> MTS.ORAddress ............ 46
4.4 - Repeated Mappings ............................. 59
4.5 - Directory Names ............................... 62
4.6 - MTS Mappings .................................. 62
4.7 - IPMS Mappings ................................. 67
5 - Detailed Mappings ............................. 71
5.1 - RFC 822 -> X.400: Detailed Mappings ........... 71
5.2 - Return of Contents ............................ 86
5.3 - X.400 -> RFC 822: Detailed Mappings ........... 86
Appendix A - Mappings Specific to SMTP ..................... 114
1 - Probes ........................................ 114
2 - Long Lines .................................... 114
3 - SMTP Extensions ............................... 114
3.1 - SMTP Extension mapping to X.400 ............... 114
3.2 - X.400 Mapping to SMTP Extensions .............. 115
Appendix B - Mapping with X.400(1984) ...................... 116
Appendix C - RFC 822 Extensions for X.400 access ........... 118
Appendix D - Object Identifier Assignment .................. 119
Appendix E - BNF Summary ................................... 120
Appendix F - Text format for MCGAM distribution ............ 127
1 - Text Formats .................................. 127
2 - Mechanisms to register and to
MCGAMs ........................................ 127
3 - Syntax Definitions ............................ 128
4 - Table Lookups ................................. 129
5 - Domain -> OR Address MCGAM format ............. 129
6 - OR Address -> Domain MCGAM format ............. 129
7 - Domain -> OR Address of Preferred
table ......................................... 130
8 - OR Addresss -> domain of Preferred
table ......................................... 130
Appendix G - Conformance ................................... 131
Appendix H - Change History: RFC 987, 1026, 1138, 1148
............................................... 133
1 - Introduction .................................. 133
2 - Service Elements .............................. 133
3 - Basic Mappings ................................ 133
4 - Addressing .................................... 134
5 - Detailed Mappings ............................. 134
6 - Appendices .................................... 134
Appendix I - Change History: RFC 1148 to RFC 1327 .......... 135
Kille Standards Track [Page 2]
RFC 2156 MIXER January 1998
1 - General ....................................... 135
2 - Basic Mappings ................................ 135
3 - Addressing .................................... 135
4 - Detailed Mappings ............................. 135
5 - Appendices .................................... 136
Appendix J - Change History: RFC 1327 to this
............................................... 137
1 - General ....................................... 137
2 - Service Elements .............................. 137
3 - Basic Mappings ................................ 137
4 - Addressing .................................... 137
5 - Detailed Mappings ............................. 138
6 - Appendices .................................... 138
Appendix L - ASN.1 Summary ................................. 139
Security Considerations .................................... 141
Author's Address ........................................... 141
References ................................................. 141
Full Copyright Statement ................................... 144
Chapter 1 --
1.1. X.400
This document relates primarily to the ITU-T 1988 and 1992 X.400
Series Recommendations / ISO IEC 10021 International Standard.
ISO/ITU-T standard is referred to in this document as "X.400",
is a convenient shorthand. Any reference to the 1984
will be explicit. Any mappings relating to elements which are in
1992 version and not in the 1988 version will be noted explicitly
X.400 defines an Interpersonal Messaging System (IPMS), making use
a store and forward Message Transfer System. This document
to the IPMS, and not to wider application of X.400, such as EDI
defined in X.435.
1.2. RFC 822 and
RFC 822 evolved as a messaging standard on the DARPA (the US
Advanced Research Projects Agency) Internet. RFC 822 specifies
end to end message format, consisting of a header and an
text body. MIME (Multipurpose Internet Mail Extensions) specifies
structured message body format for use with RFC 822. The term "
822" is used in this document to refer to the combination of MIME
RFC 822. RFC 822 and MIME are used in conjunction with a number
different message transfer protocol environments. The core of
MIXER specification is designed to work with any supporting
transfer protocol
Kille Standards Track [Page 3]
RFC 2156 MIXER January 1998
One transfer protocol, SMTP, is of particular importance and
covered in MIXER. On the Internet and other TCP/IP networks, RFC 822
is used in conjunction with RFC 821, also known as Simple
Transfer Protocol (SMTP) [30], in a manner conformant with the
requirements specification [10]. Use of MIXER with SMTP is
in Appendix A
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 between the
technologies, 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 mapping between RFC 822 and X.400. This is
usage amongst mail implementors, but differs from that used
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
to discard information in the objects it processes.
includes requested services which cannot be fully mapped
Kille Standards Track [Page 4]
RFC 2156 MIXER January 1998
4. Mail gateways operate at a level above the layer on
they perform mappings. This implies that the gateway
not only be cognisant of the semantics of objects at
gateway level, but also be cognisant of higher
semantics. If meaningful transformation of the objects
the gateway operates on is to occur, then the gateway
to understand more than the objects themselves
5. Subject to 1), the mapping should be reversible. That is,
double transformation should bring you back to where
started
1.5. Gatewaying
1.5.1. X.400
X.400 defines the IPMS Abstract Service in X.420 , [11]
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 forwarded Interpersonal Messages.
heading consists of fields containing end to end
information, such as subject, primary recipients (To:),
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 Standards Track [Page 5]
RFC 2156 MIXER January 1998
These IPMS Services utilise the Message Transfer System (MTS
Abstract Service [12]. The MTS 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). The Envelope includes
message identifier, an originator, and a list of recipients
Submission also includes the probe service, which supports the
Probe. Delivery also includes Reports, which indicate whether a
MTS Message has been delivered or not (or for a probe if
would have happened).
The MTS is provided by MTAs which interact using the MTA (
Transfer Agent) Service, which defines the interaction between MTAs
along with the procedures for distributed operation. This
provides for transfer of MTS 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
This specification will be used most commonly with SMTP as the 822-
MTS service. The core MIXER specification is written so that it
not rely on non-basic 822-MTS services. Use of non-basic
services is described in Appendix A. The core of this document
written using SMTP terminology for 822-MTS services
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
Kille Standards Track [Page 6]
RFC 2156 MIXER January 1998
heading fields, although some are analogous to MTS Service
or MTA Service Elements
RFC 822 supports delivery status notifications by use of the
mechanisms [28].
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 SMTP (822-MTS) service mapping onto the MTS
Elements and RFC 822 mapping onto an IPM, but there is a not a
match between these services. Another elegant approach would be
treat this document as the definition of an X.400 Access Unit (AU).
In this case, the abstraction level is too high, and some
mapping function is lost. It is necessary to consider that the
format definition, the IPMS Service Elements, the MTS
Elements, and MTA Service Elements on one side are mapped into
822 + SMTP on the other in a slightly tangled manner. The details
the tangle will be made clear in Chapter 5. Access to the
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 SMTP
is always mapped into an IPM (MTA, MTS, and IPMS Services) and
Delivery Status Notification is mapped onto a Report. Going
X.400 to RFC 822, an RFC 822 message and the associated
information may be derived from
1. An IPN (MTA, MTS, and IPMS services
2. An IPM (MTA, MTS, and IPMS services
A Report (MTA, and MTS Services) is mapped onto a delivery
notification
Probes (MTA Service) shall 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 shall
rejected at the gateway if no other gatewaying procedure is defined
This specification is concerned with X.400 IPMS.
specifications may defined mappings for other X.400 content types
Kille Standards Track [Page 7]
RFC 2156 MIXER January 1998
1.5.4. Repeated
The primary goal of this specification is to support single mappings
so that X.400 and RFC 822 users can communicate with
functionality
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).
Some RFC 822 networks may wish to use X.400 as an
mechanism (typically for policy reasons), and this is
supported
Where an X.400 message transfers to RFC 822 and then back to X.400,
there is no expectation of X.400 services which do not have
equivalent service in standard RFC 822 being preserved -
this may be possible in some cases
1.6. Support of X.400 (1984)
The MIXER definition is based on the initial specification of RFC 987
and in its addendum RFC 1026, which defined a mapping
X.400(1984) and RFC 822. The core MIXER mapping is defined using
full 1988 version of X.400, and not to a 1984 compatible subset.
features of X.400(1988) can be used to provide a much cleaner
than that defined in RFC 987. To interwork with 1984 systems
Appendix B shall be followed
If a message is being transferred to an X.400(1984) system by way
X.400(1988) MTA it will give a slightly better service to follow
rules of Appendix B, than to downgrade without this knowledge
Downgrading specifications which supplement those specified in X.400
(X.419) are given in RFC 1328 [22] and RFC 1496 (HARPOON) [5].
1.7. X.400 (1992)
X.400 (1992) features are not used by the core of this mapping,
so there is not an equivalent downgrade problem
1.8.
MIME format messages are generated by this mapping. As MIME
are fully RFC 822 compliant, this will not cause problems
systems which are not MIME capable
Kille Standards Track [Page 8]
RFC 2156 MIXER January 1998
1.9. Body
MIME and X.400 IPMS can both carry arbitrary body parts. MIME
a mechanism for adding new body parts, and new body parts
registered with the IANA. X.400 defines a mechanism adding new
parts, usually referred to as Body Part 15. Extensions are
by Object Identifiers, so there is no requirement for a central
part registration authority. The Electronic Messaging
(EMA) maintains a list of some commonly used body parts. The EMA
specified a mechanism to use the File Transfer Body Part (FTBP) as
more generic means to support message attachments. This approach
gaining widespread commercial support
The mapping between X.400 and MIME body parts is defined in
companion MIXER specification, referenced here as RFC 2157 [8].
document is an update of RFC 1494 [6].
Editor's Note
References to 2157 will be resolved as these
documents are expected to progress in parallel
These two specifications together form the complete MIXER Mapping
1.10. Local and Global
There are two basic scenarios for X.400/MIME interworking
Global
There are two global mail networks (Internet/MIME and X.400),
interconnected by multiple gateways. Objects may be
over multiple gateways, and so it is important that
behave in a coherent fashion. MIXER is critical to support
scenario
Local
A gateway is used to connect a closed community to a global
network (this could be enforced by connectivity or
authorisation policy). This is a common commercial scenario
MIXER is useful to support this scenario, as it allows an
standard provision of service, but this could be supported
something which was MIXER-like
A solution for the global scenario will work for the local scenario
However, there are aspects of MIXER which have
implementation or deployment effort (the global mapping is the
one, but there are other details too) which and are needed to
Kille Standards Track [Page 9]
RFC 2156 MIXER January 1998
the global scenario, but are not needed in the local scenario
Note that the local scenario may be the driving force for
deployments, and support of the global scenario may be an
secondary goal
There is also a transition effect. Gateways which are
deployed in a strict local scenario situation start to
themselves in a global scenario. A common case is ADMD
gateways, which are targeted strictly at the local scenario.
practice they soon start to operate in the global scenario,
of distribution lists and messages exchanged with X.400 users
are not customers of the ADMD. At this point, users are hurt by
restrictions of a local scenario gateway
Note that conformance to MIXER applies to an instantiation of
gateway, not just an implementation (although clearly it is
that the implementation is capable of being operated in a
manner).
MIXER's conformance target is the global scenario, and
specification of MIXER defines operation in this way
1.11. Compatibility with previous
The changes between this and older versions of the document are
in Appendices H, I and J. These are RFCs 987, 1026, 1138, 1148
1327. This document is a revision of RFC 1327 [21]. As far
possible, changes have been made in a compatible fashion
1.12. Aspects not
There have been a number of cases where previous versions of
document were used in a manner which was not intended. This
is to make clear some limitations of scope. In particular,
specification does not 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 MIXER
Kille Standards Track [Page 10]
RFC 2156 MIXER January 1998
an interface - there are too many aspects of X.400 which cannot
accessed through it. If a text interface is desired, a
targeted at X.400, without RFC 822 restrictions, would be
appropriate. Some optional and limited extensions in this area
proved useful, and are defined in Appendix C
1.13.
This proposal specifies a mapping which is appropriate to
services in existing RFC 822 communities. Implementations
specifications which subset this specification are non-conformant
strongly discouraged
1.14. Specification
ISO and Internet standards have clear definitions as to the style
language used. This specification maps between ISO/ITU-T
and Internet protocols. This document uses ISO terminology for
following reasons
1. This was done in previous versions
2. ISO language may be mechanically converted to
language, but not vice versa
The key elements of the ISO rules are
1. All mandatory features shall clearly be indicated
imperative statements or the word "shall" or "shall not".
2. Optional features shall be indicated by the word "may".
3. The word "should" and the phrase "may not" shall not
used
In some cases the specification issues guidance on use of
features, by use of the the phrase word "recommended" or "
recommended".
To interpet this document according to Internet rules, replace
occurrence of "shall" with "must".
1.15. Related
Mappings between Mail-11 and X.400 and Mail-11 and RFC 822
described in RFC 2162, using mappings related to those defined
[2].
Kille Standards Track [Page 11]
RFC 2156 MIXER January 1998
1.16. 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
names and RFC 822 addresses, which is a fundamental
component
5. Detailed Mappings - This describes the details of all
mappings
There are also ten appendices
WARNING
THE REMAINDER OF THIS SPECIFICATION IS TECHNICALLY DETAILED.
WILL NOT MAKE SENSE, EXCEPT IN THE CONTEXT OF RFC 822 AND X.400
(1988). DO NOT ATTEMPT TO READ THIS DOCUMENT UNLESS YOU
FAMILIAR WITH THESE SPECIFICATIONS
1.17.
The work in this specification was substantially based on RFC 987
RFC 1148, which had input from many people, who are credited in
respective documents
A number of comments from people on RFC 1148 lead to RFC 1327.
particular, there were comments and suggestions from: Maurice
(HP); Harald Alvestrand (Sintef); Peter Cowen (X-Tel); Jim
(JNT); Ella Gardner (MITRE); Christian Huitema (Inria); Erik
(SURFnet); Neil Jones (DEC); Ignacio Martinez (IRIS); Julian
(X-Tel); Simon Poole (SWITCH); Clive Roberts (Data General);
Vanderbilt (SUN); Alan Young (Concurrent).
RFC 1327 has been widely adopted, and a review team was formed.
comprised of: Urs Eppenberger (SWITCH)(Chair); Claudio
(INFN); Harald Alvestrand (UNINETT); Dave Crocker (Brandenburg);
Freed (Innosoft); Erik Huizer (SURFnet); Steve Kille (Isode);
Sylvester (GC Tech).
Kille Standards Track [Page 12]
RFC 2156 MIXER January 1998
Harald Alvestrand also supplied the tables mapping DSN status
with X.400 codes. Ned Freed defined parts of the File Transfer
Part mapping
Comment and input has also been received from: Bengt Ackzell (
Systems); Samir Albadine (Transpac); Mark Boyes (DEC); Larry
(Boston Software Works); Jacqui Caren (Cray); Allan Cargille (MCI);
Kevin Carrosso (Innosoft); Charlie Combs (OIW); Jim Craigie (Net
Tel); Eamon Doyle (Isocor); Efifion Edem (SITA); Jyrki
(ICL); Edward Hibbert (DCL); Jeroun Houttin (Terena); Kevin
(CDS); Paul Kingsnorth (DEC); Carl-Uno Manros (Manros Consulting);
Suzan Mendes (Telis); Robert Miles (Softswitch); Roger
(Enterprise Solutions Ltd); Keith Moore (University of Tennessee);
Ruth Moulton (Net-Tel) Michel Musy (Bull); Kenji Nonaka (NTT):
OIW MHSIG; Tom Oliphant (SWITCH); Julian Onions (NEXOR); Jacob
(KTH); Olivier Paridaens (ULB); Mary la Roche (Citicorp);
Setsaas (Maxware); Russell Sharpe (DCL); Patrick Soulier (CCETT);
Eftimios Tsigros (Universite Libre de Bruxelles); Sean Turner (IECA);
Mark Wahl (Isode); David Wilson (Isode); Bill Wohler (Worldtalk);
Alan Young (Isode); Alain Zahm (Telis).
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
Kille Standards Track [Page 13]
RFC 2156 MIXER January 1998
The corresponding protocol elements map well, and so the
can be fully provided
Not
The service cannot be provided, as there is a complete 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
In many cases, the required action will simply be to make
information available to the end user. In other cases, actions
imply generating a delivery report
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
Kille Standards Track [Page 14]
RFC 2156 MIXER January 1998
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
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
are recommended to require that their X.400 User Agents are able
display these heading extensions. Support for the various
elements (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 multiple references
given, partial support is given by mapping to "Cross
Indication". This gives similar semantics
References: Supported
Kille Standards Track [Page 15]
RFC 2156 MIXER January 1998
Keywords: Supported by use of a heading extension
Subject: Supported
Comments: Supported by use of a heading extension
Encrypted: Supported by use of a heading extension
Content-Language: Supported
Resent-*
Supported by use of a heading extension. Note that addresses
these fields are mapped onto text, and so are not accessible
the X.400 user as addresses. In principle, fuller support
be possible by mapping onto a forwarded IP Message, but this
not suggested
Other
In particular X-* fields, and "illegal" fields in common
(e.g., "Fruit-of-the-day:") are supported by use of
extensions
MIME introduces a number of headings. Support is defined in
2157.
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
Kille Standards Track [Page 16]
RFC 2156 MIXER January 1998
Message-Id
In-Reply-To
References
Subject
Content-Type: (See RFC 2157)
Content-Transfer-Encoding: (See RFC 2157)
MIME-Version: (See RFC 2157)
The following services (headers) may be present in the header of
message. These are defined in more detail in Chapter 5 (5.3.4, 5.3.6,
5.3.7):
Autoforwarded
Autosubmitted
X400-Content-Identifier
Content-Language
Conversion
Conversion-With-Loss
Delivery-Date
Discarded-X400-IPMS-Extensions
Discarded-X400-MTS-Extensions
DL-Expansion-History
Deferred-Delivery
Expires
Importance
Incomplete-Copy
Latest-Delivery-Time
Kille Standards Track [Page 17]
RFC 2156 MIXER January 1998
Message-Type
Original-Encoded-Information-Types
Originator-Return-Address
Priority
Reply-By
Sensitivity
Supersedes
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, and registered
publication in this standard. It is intended that co-operating
822 systems may also use them. Where these new fields are used,
no system action is implied, the service can be regarded as
partially supported. Chapter 5 describes how to map X.400
onto these new headers. Other elements are provided, in part, by
gateway as 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 RFC 822
recipients
Kille Standards Track [Page 18]
RFC 2156 MIXER January 1998
N/A (PDAU
These service elements are only applicable where the recipient
reached by use of a Physical Delivery Access Unit (PDAU), and
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 shall be performed prior to
gateway
N/A (MS
These services are only applicable to Message Store (i.e., a
service).
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. Section 19.8
has cross references to short definitions of each service
Access
N/A (local).
Content Type
Supported by a new RFC 822 header (X400-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 header (X400-MTS-Identifier).
This new header is required, as X.400 has two message-ids
Kille Standards Track [Page 19]
RFC 2156 MIXER January 1998
RFC 822 has only one (see IP Message
Non-delivery
Not supported in all cases. Supported where the recipient
supports NOTARY DSNs. In general all RFC 822 systems will
error reports by use of IP messages. In other service elements
this pragmatic result can be treated as effective support of
service element
Original Encoded Information Types
Supported as a new RFC 822 header (Original-Encoded-Information
Types:).
Submission Time Stamp
Supported
Typed
Support is defined in RFC 2157.
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 RFC 822
system may freely send an undeliverable message to a
postmaster). A MIXER gateway has two conformant options.
first is not to gateway a message requesting prohibition
alternate recipient, as this control cannot be guaranteed.
option supports the service, but may cause unacceptable level
message rejections. The second is to gateway the message on
basis that there is no alternate recipient service in RFC 822.
1327 allowed only the second option. If the first option
shown to be operationally effective, it may be the only option
future versions of MIXER
Authorising User's
Supported
Kille Standards Track [Page 20]
RFC 2156 MIXER January 1998
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 header (Original-Encoded
Information-Types:), although in most cases it will not
possible to map the body part in question
Content
Not supported
Content
Not supported
Conversion
Supported. Operation defined in RFC 2157.
Conversion Prohibition in Case of Loss of
Supported. Operation defined in RFC 2157.
Counter
N/A (PDAU).
Counter Collection with
N/A (PDAU).
Cross Referencing
Supported
Deferred
N/A (prior). This service shall always be provided by the
prior to the gateway. A new RFC 822 header (Deferred-Delivery:)
is provided to transfer information on this service to
recipient
Deferred Delivery
N/A (local).
Delivery
Supported. This is performed at the gateway, but may be
at the end system if the end system supports NOTARY. Thus,
notification is sent by the gateway to the originator
Kille Standards Track [Page 21]
RFC 2156 MIXER January 1998
Delivery via Bureaufax
N/A (PDAU).
Designation of Recipient by Directory
N/A (local).
Disclosure of Other
Supported by use of a new RFC 822 header (X400-Recipients:).
is descriptive information for the RFC 822 recipient, and is
reverse mappable
DL Expansion History
Supported by use of a new RFC 822 header (DL-Expansion-History:).
DL Expansion
Distribution List means MTS supported distribution list, in
manner of X.400. This service does not exist in the RFC 822
world, although RFC 822 supports distribution list functionality
There is no SMTP leve control to prohibit distribution
expansion. A MIXER gateway has two conformant options.
first is not to gateway a message requesting DL
prohibition, as this control cannot be guaranteed. This
supports the service, but may cause unacceptable level of
rejections. The second is to gateway the message on the basis
there is no distribution list service in RFC 822. RFC 1327
only the second option. If the first option is shown to
operationally effective, it may be the only option in
versions of MIXER
Express Mail
N/A (PDAU).
Expiry Date
Supported as new RFC 822 header (Expires:). In general,
automatic action can be expected
Explicit
N/A (prior).
Forwarded IP Message
Supported
Grade of Delivery
Not Supported. There is no equivalent service in RFC 822.
Importance
Supported as new RFC 822 header (Importance:).
Kille Standards Track [Page 22]
RFC 2156 MIXER January 1998
Incomplete Copy
Supported as new RFC 822 header (Incomplete-Copy:).
Language
Supported as new RFC 822 header (Content-Language:).
Latest Delivery
Not supported. A new RFC 822 header (Latest-Delivery-Time:)
provided, which may be used by the recipient for
information, but will not be acted on by the SMTP infrastrucuture
Message Flow
Not supported
Message Origin
N/A (reception).
Message Security
Not supported
Message Sequence
Not supported
Multi-Destination Delivery Supported
Multi-part
Supported
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 (Supersedes:).
Ordinary
N/A (PDAU).
Originator
Supported
Kille Standards Track [Page 23]
RFC 2156 MIXER January 1998
Originator Requested Alternate
Not supported, but is placed as comment next to address (X400-
Recipients:).
Physical Delivery Notification by
N/A (PDAU).
Physical Delivery Notification by
N/A (PDAU).
Physical Forwarding
Supported by use of a comment in a new RFC 822 header (X400-
Recipients:), associated with the recipient in question
Physical Forwarding
Supported by use of a comment in a new RFC 822 header (X400-
Recipients:), associated with the recipient in question
Prevention of Non-delivery
Supported where SMTP and NOTARY are available. In other
formally supported, as delivery notifications cannot be
by RFC 822. In practice, errors will be returned as IP Messages
and so this service may appear not to be supported (see Non
delivery Notification).
Primary and Copy Recipients
Supported at the gateway (i.e., the gateway services the probe).
Probe Origin
N/A (reception).
Proof of
Not supported
Proof of
N/A (local).
Receipt Notification Request
Not supported
Kille Standards Track [Page 24]
RFC 2156 MIXER January 1998
Redirection Disallowed by
Redirection means MTS supported redirection, in the manner
X.400. This service does not exist in the RFC 822 world. RFC 822
redirection (e.g., aliasing) is regarded as an
redirection mechanism, beyond the scope of this control.
will be sent to RFC 822, irrespective of whether this service
requested. In practice, control of this service is not supported
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 service request is dealt with at
time. Any such request is made available through the gateway
use of a comment associated with the recipient in question
Return of
Supported where SMTP and NOTARY are used. In principle for
situations, this is N/A, as non-delivery notifications are
supported. In practice, most RFC 822 systems will return part
all of the content along with the IP Message indicating an
(see Non-delivery Notification).
Sensitivity
Supported as new RFC 822 header (Sensitivity:).
Special
N/A (PDAU).
Stored Message
N/A (MS).
Kille Standards Track [Page 25]
RFC 2156 MIXER January 1998
Stored Message
N/A (MS).
Stored Message
N/A (MS).
Stored Message
N/A (MS).
Subject
Supported
Undeliverable Mail with Return of Physical
N/A (PDAU).
Use of Distribution
In principle this applies only to X.400 supported
lists (see DL Expansion Prohibited). Theoretically, this
is N/A (prior). In practice, because of informal RFC 822 lists
this service can be regarded as supported
Auto-Submitted
2.3.2. Reception by X.400
2.3.2.1. Standard Mandatory
The following standard IPM mandatory user facilities are required
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
Kille Standards Track [Page 26]
RFC 2156 MIXER January 1998
2.3.2.2. Standard Optional
The following standard IPM optional user facilities are required
reception of RFC 822 originated mail by an X.400 UA
Authorising User's
Blind Copy Recipient
Cross Referencing
Originator
Primary and Copy Recipients
Replying IP Message
Subject
2.3.2.3. New
A new X.400 service "RFC 822 Header Field" is defined using
extension 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 [16]. In the EBNF
used in this specification, the syntax rules given in Appendix D
RFC 822 are assumed. When these EBNF tokens are referred to
an EBNF definition, they are identified by the string "822."
to the beginning of the string (e.g., 822.addr-spec).
syntax rules, to be used throughout this specification, are
in this chapter
The EBNF is used in two ways
Kille Standards Track [Page 27]
RFC 2156 MIXER January 1998
1. To describe components of RFC 822 messages (or of
components). When these new EBNF tokens are referred
outside an EBNF definition, they are identified by
string "EBNF." appended to the beginning of the
(e.g., EBNF.importance).
2. To describe the structure of IA5 or ASCII information not
an RFC 822 message
For all new EBNF, tokens will either be self delimiting, or
delimited by self delimiting tokens. Comments and LWSP are not
as delimiters, except for the following cases, where LWSP may
inserted according to RFC 822 rules
- Around the ":" in all
- EBNF.labelled-
- EBNF.object-
- EBNF.encoded-
RFC 822 folding rules are applied to all headers. Comments are
used in these new headers
This notation is used in a modified form to refer to NOTARY
[28]. For this EBNF, the keyword EBNF it replaces with DSN,
example DSN.final-recipient-field fields
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 / ISO 10021-
7.
MTS MTSAbstractService defined in Section 9 of X.411 / ISO 10021-4.
TA MTAAbstractService defined in Section 13 of X.411 / ISO 10021-4.
Kille Standards Track [Page 28]
RFC 2156 MIXER January 1998
FTBP File Transfer Body Part, as defined in [27].
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.
defines the subject element of the IPMS heading. The same syntax
also used to refer to element values. For example
MTS.EncodedInformationTypes.[0].g3Fax refers to a value
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 [14]. For each case, an EBNF syntax definition
given, for use in all of this specification, which leads to a
between ASN.1, and an EBNF construct. All EBNF syntax definitions
ASN.1 types are in lower case, whereas ASN.1 types are referred
with the first letter in upper case. Except as noted, all
are symmetrical
3.3.1.
Boolean is encoded as
boolean = "TRUE" / "FALSE
3.3.2.
NumericString is encoded as
numericstring = *(DIGIT / " ")
Kille Standards Track [Page 29]
RFC 2156 MIXER January 1998
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 is to render
characters appropriately in the remote character set, rather than
maximise reversibility. For these cases, there are two options,
of which are conformant to this specification
1. The mappings to IA5 defined in ITU-T Recommendation X.408
(1988) may be used [13]. These will then be encoded
ASCII. This is the approach mandated in RFC 1327.
2. This mapping may be used if the characters are not
within ASCII repertoire, but are all in an IANA-
character set. Use the encoding defined in RFC 1522 [9]
generate appropriate encoded-words. If this mapping
used, the character set ISO-8859-1 shall be used if all
the characters needed are available in this repertoire.
other cases, the character set TELETEX shall be used.
details of this character set is defined in the Appendix
of RFC 2157.
There is also a need to represent Teletex Strings in ASCII, for
aspects of OR Address. For these, the following encoding is used
teletex-string = *( ps-char / t61-encoded )
t61-encoded = "{" 1* t61-encoded-char "}"
t61-encoded-char = 3
Characters in EBNF.ps-char are mapped simply. Other octets
including control characters, are mapped using a quoting
similar to the printable string mechanism. Each octet is
as 3 decimal digits. For example, the Yen character (hex A5)
represented as {165}. As the three character string, a,
character, b, would be represented as either "a{165}b".
Kille Standards Track [Page 30]
RFC 2156 MIXER January 1998
The use of escape sequences follows that set down for ASN1. in
8825-1, with the additional specifiction that the default G1 page
ISO Latin 1. The page settings may be changed by escape sequences
Changes of the settings hold within a pair of curly brackets ({}),
and the settings revert to the default after the right bracket (})
(i.e., they do not carry forward to subsequent T.61 encoding).
There are a number of places where a string may have a Teletex and/
Printable String representation. The following EBNF 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. An example is
"yen*{165}"
3.3.5.
Both UTCTime and the RFC 822 822.date-time syntax contain: Year
Month, Day of Month, hour, minute, second (optional), and
(technically a time differential in UTCTime). 822.date-time
contains an optional day of the week, but this is redundant.
the exception of Year, a symmetrical mapping can be made
these constructs
Note
In practice, a gateway will need to parse various illegal
on 822.date-time. In cases where 822.date-time cannot be parsed
it is recommended that the derived UTCTime is set to the value
the time of translation. Such errors may be noted in an RFC 822
comment, to aid detection and correction
When mapping to X.400, the UTCTime format which specifies
timezone offset shall be used
When mapping to RFC 822, the 822.date-time format shall include
numeric timezone offset (e.g., -0500).
When mapping time values, the timezone shall be preserved
specified. The date shall not be normalised to any other timezone
Kille Standards Track [Page 31]
RFC 2156 MIXER January 1998
RFC 822, as modified by RFC 1123, requires use of a four digit year
Note that the original RFC 822 uses a two digit date, which is
longer legal. UTCTime uses a two digit date. To map a year from
822 to X.400, simply use the last two digits. To map a year
X.400 to RFC 822, assume that the two digit year refers to a year
the 10 year epoch 1980-2079.
3.3.6.
A basic ASN.1 Integer will be mapped onto EBNF.numericstring.
many cases ASN.1 will enumerate Integer values or use ENUMERATED.
EBNF 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, a text label may
added. It is recommended that this is done wherever possible
that clear text labels are chosen
A second encoding labelled-integer-2 is provided. This is used
DSNs, where the parsing rules will treat the text as a comment.
definition was not present in RFC 1327.
labelled-integer ::= [ key-string ] "(" numericstring ")"
labelled-integer-2 ::= [ numericstring ] "(" key-string ")"
key-string = *key-
key-char =
3.3.7. Object
Object identifiers are represented in a form similar to that given
ASN.1. The order is the same as for ASN.1 (big-endian). The
are mandatory, and used when mapping from the ASCII to ASN.1.
key-strings are optional. It is recommended that as many strings
possible are generated when mapping from ASN.1 to ASCII,
facilitate user recognition
object-identifier ::= oid-comp object-
| oid-
oid-comp ::= [ key-string ] "(" numericstring ")"
Kille Standards Track [Page 32]
RFC 2156 MIXER January 1998
An example representation of an object identifier is
joint-iso-ccitt(2) mhs (6) ipms (1) ep (11) ia5-text (0)
(2) (6) (1)(11)(0)
Because of the use of brackets and the conflict with the RFC 822
comment convention, MIXER is defines so that the EBNFobject
identifier definition is not used in structured fields
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.
shall 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 shall 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 shall
interpreted in a case insensitive manner, but always generated
lower 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 shall only be used in cases where
printable strings have been derived from ASCII (and will
Kille Standards Track [Page 33]
RFC 2156 MIXER January 1998
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
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 shall be given to
