service
Click on the red underlined text to get to the source
... / ISO IEC 10021 on the Message Oriented Text Interchange Service
(MOTIS). This ISO/CCITT standard is referred to in this document as
...
... 920 which is a Specification for domains and a
distributed name service [Postel84a].
UUCP Networks ...
... Team) Mail Protocol, also known as Greybook [Kille84a].
This is used with domains and name service specified by the
JNT NRS (Name Registration Scheme ...
... There is a large community using RFC 822std11(-> 2822prop) based protocols for mail
services, who will wish to communicate with users of the IPMS
provided by X.400 ...
... X.400
IPMS, as conversion will be needed to ensure a smooth service
transition. It is expected that there will be more than one gateway,
...
... service to users.
2. The best service in cases where a message passes through
multiple gateways.
...
... gateway
to discard information in the objects it processes. This
includes requested services which cannot be fully mapped.
4. All mail gateways ...
... X.400 defines the IPMS Abstract Service in X.420/ISO 10021-7,
[CCITT/ISO88b] which comprises of three basic services ...
... Service in X.420/ISO 10021-7,
[CCITT/ISO88b] which comprises of three basic services:
1. Origination
...
... Management is a local interaction between the user and the IPMS, and
is therefore not relevant to gatewaying. The first two services
consist of operations to originate and receive the following two
objects:
...
... UA level.
The Origination service also allows for origination of a probe, which
is an object to test whether a given IPM could be correctly received.
...
... is an object to test whether a given IPM could be correctly received.
The Reception service also allows for receipt of Delivery Reports
DR ...
... Services utilise the Message Transfer (MT) Abstract
Service [CCITT/ISO88c]. The MT Abstract Service provides the
...
... Service [CCITT/ISO88c]. The MT Abstract Service provides the
following three basic services:
...
... MT Abstract Service provides the
following three basic services:
1. Submission (used by IPMS ...
... which includes an ID, an originator, and a list of recipients.
Submission also includes the probe service, which supports the IPMS
Probe ...
... MTS is REFINED into the MTA (Message Transfer Agent) Service,
which defines the interaction between MTAs, along with the procedures
...
... which defines the interaction between MTAs, along with the procedures
for distributed operation. This service provides for transfer of MTS
Messages, Probes ...
... RFC 822std11(-> 2822prop) is based on the assumption that there is an underlying
service, which is here called the 822-MTS service. The 822-MTS ...
... service. The 822-MTS
service provides three basic functions:
1. Identification of a list of recipients.
...
... protocol elements. Most of these fields are analogous to P2
heading fields, although some are analogous to MTS Service Elements
...
...
Given this functional description of the two services, the functional
nature of a gateway can now be considered. It would be elegant to
...
... gateway can now be considered. It would be elegant to
consider the 822-MTS service mapping onto the MTS Service Elements ...
... fit. It is necessary to consider that the IPM format definition, the
IPMS Service Elements, the MTS Service ...
... Service Elements, and MTA Service
Elements on one side are mapped into RFC 822std11(-> 2822prop) ...
... in a slightly tangled manner. The details of the tangle will be made
clear in Chapter 5. Access to the MTA Service Elements is minimised.
...
... MTS, and IPMS
Services). Going from X.400 to RFC 822std11(-> 2822prop), an RFC 822std11(-> 2822prop) ...
... 822std11(-> 2822prop). This is often
essential, particularly in the case of distribution lists. However,
in general, this will lead to a level of service which is the lowest
common denominator (approximately the services offered by RFC 822std11(-> 2822prop) ...
... in general, this will lead to a level of service which is the lowest
common denominator (approximately the services offered by RFC 822std11(-> 2822prop)).
...
... X.400,
there is no expectation of X.400 services which do not have an
equivalent service in standard RFC 822std11(-> 2822prop) ...
... X.400 services which do not have an
equivalent service in standard RFC 822std11(-> 2822prop) being preserved - although
this may be possible in some cases.
...
... The first two of these are really coupled. To map the X.400
services, this specification defines a number of extensions to RFC
822std11(-> 2822prop). As a side effect, these give the 822 user access ...
... user access to SOME X.400
services. However, the aim on the RFC 822std11(-> 2822prop) side is to preserve
current service ...
... services. However, the aim on the RFC 822std11(-> 2822prop) side is to preserve
current service, and it is intentional that access is not given to
all X.400 ...
...
This proposal specifies a mapping which is appropriate to preserve
services in existing RFC 822std11(-> 2822prop) communities. Implementations and
specifications which subset this specification are strongly
...
...
This chapter considers the services offered across a gateway built
according to this specification. It gives a view of the
...
... gateway for communication with users
in the opposite domain. This chapter considers service mappings in
the context of SINGLE transfers only, and not repeated mappings
...
... RFC 822std11(-> 2822prop) and X.400 provide a number of services to the end user. This
chapter describes the extent to which each service can be supported
...
... X.400 provide a number of services to the end user. This
chapter describes the extent to which each service can be supported
across an X.400 <-> RFC 822std11(-> 2822prop) ...
...
When a user originates a message, a number of services are available.
Some of these imply actions (e.g., delivery to a recipient), and some
...
... are insertion of known data (e.g., specification of a subject field).
This chapter describes, for each offered service, to what extent it
is supported for a recipient accessed through a gateway. There are
...
... The corresponding protocol elements map well, and so the
service can be fully provided.
Not Supported
...
...
Not Supported
The service cannot be provided, as there is a complete
mismatch.
...
... 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 are
additional implications, or the (non) support is not intuitive. For
...
... partial support is good, this will be described by a phrase such as
"Supported by use of.....". A common case of this is where the
service is mapped onto a non- standard service on the other side of
the gateway ...
... "Supported by use of.....". A common case of this is where the
service is mapped onto a non- standard service on the other side of
the gateway, and this would have lead to support if it had been a
...
... the gateway, and this would have lead to support if it had been a
standard service. In many cases, this is equivalent to support. For
partial support, an indication of the mechanism is given, in order to
give a feel for the level of support provided. Note that this is not
...
... a replacement for Chapter 5, where the mapping is fully specified.
If a service is described as supported, this implies:
- Semantic ...
... element.
An example of a service gaining full support: If an RFC 822std11(-> 2822prop)
originator specifies a Subject ...
...
All RFC 822std11(-> 2822prop) services are supported or partially supported for
origination. The implications of non-supported X.400 services ...
... services are supported or partially supported for
origination. The implications of non-supported X.400 services is
described under X.400.
...
...
For reception, the list of service elements required to support this
mapping is specified. This is really an indication of what a
...
...
RFC 822std11(-> 2822prop) does not explicitly define service elements, as distinct from
protocol elements ...
... trace, can be regarded as corresponding to implicit
RFC 822std11(-> 2822prop) service elements.
...
... available to any X.400 implementations which are interested in these
services. Communities which require significant RFC 822std11(-> 2822prop) interworking
...
... X.400 User Agents are able to
display these heading extensions. Support for the various service
elements (headers ...
... X.400 system and transferred across a gateway. The
following standard services (headers) may be present in such a
message:
...
... Subject:
The following non-standard services (headers) may be present. These
are defined in more detail in Chapter 5 (5.3.4, 5.3.6, 5.3.7):
...
... 822std11(-> 2822prop)
systems may use them. Where these new fields are used, and no system
action is implied, the service can be regarded as being partially
supported. Chapter 5 describes how to map X.400 services ...
... service can be regarded as being partially
supported. Chapter 5 describes how to map X.400 services onto these
new headers. Other elements ...
... 822std11(-> 2822prop).
Some service elements are marked N/A (not applicable). There are
five cases, which are marked with different comments:
...
...
N/A (PDAU)
These service elements are only applicable where the
recipient is reached by use of a Physical ...
...
N/A (reception)
These services are only applicable for reception.
N/A (prior)
...
... These services are only applicable to Message Store (i.e., a
local service).
Finally, some service ...
... service).
Finally, some service elements are not supported. In particular, the
new security services ...
... service elements are not supported. In particular, the
new security services are not mapped onto RFC 822std11(-> 2822prop). Unless otherwise
indicated, the behaviour of service ...
... security services are not mapped onto RFC 822std11(-> 2822prop). Unless otherwise
indicated, the behaviour of service elements marked as not supported
will depend on the criticality marking supplied by the user ...
... Basic Interpersonal Messaging Service ...
... 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 management ...
... X.400 has two message-ids whereas RFC 822std11(-> 2822prop) has only one (see
previous service).
Non-delivery Notification ...
... return error reports by use of IP messages. In other
service elements, this pragmatic result can be treated as
effective support of this service ...
... service elements, this pragmatic result can be treated as
effective support of this service element.
...
... IPM Service Optional User Facilities ...
...
This section describes support for the optional (user selectable) IPM
services as listed in Section 19.9 of X.400 / ISO/IEC 10021- 1,
...
... ISO/IEC 10021- 1,
listed here in the order given. Section 19.9 has cross references to
short definitions of each service.
Additional Physical ...
... Alternate Recipient Allowed
Not supported. There is no RFC 822std11(-> 2822prop) service equivalent to
prohibition of alternate recipient assignment (e.g., an RFC
822std11(-> 2822prop) ...
... assignment of alternative recipients on the RFC 822std11(-> 2822prop) side.
This service really means giving the user control as to
whether or not an alternate recipient is allowed. This
specification requires transfer of messages to RFC 822std11(-> 2822prop) ...
... specification requires transfer of messages to RFC 822std11(-> 2822prop)
irrespective of this service request, and so this service is
not supported.
...
... 822std11(-> 2822prop)
irrespective of this service request, and so this service is
not supported.
...
... Deferred Delivery
N/A (prior). This service should always be provided by the
MTS prior to the gateway ...
... Deferred-Delivery:) is provided to transfer information on
this service to the recipient.
Deferred Delivery ...
... MTS supported distribution list, in
the manner of X.400. This service does not exist in the RFC
822std11(-> 2822prop) world. RFC 822std11(-> 2822prop) ...
... this control. Messages will be sent to RFC 822std11(-> 2822prop),
irrespective of whether this service is requested.
Theoretically therefore, this service is supported, although
...
... irrespective of whether this service is requested.
Theoretically therefore, this service is supported, although
in practice it may appear that it is not supported.
...
... in practice it may appear that it is not supported.
Express Mail Service
N/A (PDAU).
...
... 822std11(-> 2822prop). In practice, errors will be returned as IP
Messages, and so this service may appear not to be supported
see Non-delivery Notification).
...
... MTS supported redirection, in the manner
of X.400. This service does not exist in the RFC 822std11(-> 2822prop) world.
RFC 822std11(-> 2822prop) ...
... control. Messages will be sent to RFC 822std11(-> 2822prop), irrespective of
whether this service is requested. Theoretically therefore,
this service is supported, although in practice it may
...
... whether this service is requested. Theoretically therefore,
this service is supported, although in practice it may
appear that it is not supported.
...
... Requested Delivery Method
N/A (local). The services required must be dealt with at
submission time. Any such request is made available through
the gateway ...
... distribution lists (see DL Expansion Prohibited).
Theoretically, this service is N/A (prior). In practice,
because of informal RFC 822std11(-> 2822prop) lists, this service ...
... service is N/A (prior). In practice,
because of informal RFC 822std11(-> 2822prop) lists, this service can be
regarded as supported.
...
... Standard Mandatory Services ...
... Standard Optional Services ...
... New Services ...
... identifier identifies a type or value key in the
context of the defined service specification. Subsequent
EBNF.identifiers identify a value label or type in the context ...
... P/T 18.1 6
MTS.PDSName PD-SERVICE P 18.3.11 7
MTS.PhysicalDeliveryCountryName PD-C P 18.3.13 8
MTS ...
... remote system, with the choice of gateway being left to the Message
Transfer Service. There are two fundamental reasons why this is not
possible:
...
... restricted syntax is chosen as it is the one chosen by the
various domain service administrations.
3. To deal with missing elements ...
... be an incorrect action. However, in most real cases,
it will do the "right" thing and provide a better
service to the end user. This is a reflection on the
excessive and inappropriate use of source routing ...
... In some situations this type of recursion may be frequent. It is
important that where this occurs, that no unnecessary protocol
conversion occurs. This will minimise loss of service.
...
... too frequent) cases where RFC 822std11(-> 2822prop) and X.400 services are partitioned.
The syntax may be used to source route ...
...
explicit-conversion
This optional component is omitted, as this service is not
needed
...
... X.400 side, which
cannot be mapped into analogous 822-MTS services. For this reason,
new RFC 822std11(-> 2822prop) ...
...
In addition, the following per-recipient services from
MTS.OtherMessageDeliveryFields.extensions are represented in comments
...
... MTS.OtherMessageDeliveryFields.extensions are represented in comments
if they are used. None of these services can be provided on RFC 822std11(-> 2822prop)
networks ...
... 822std11(-> 2822prop) fields cannot be mapped onto a standard IPM Heading
field, and so an extended field is defined in Section 5.1.2. This is
then used for fields which cannot be mapped onto existing services.
The message is submitted to the MTS ...
...
The message is submitted to the MTS, and the services required can be
defined by specifying MTS.MessageSubmissionEnvelope. A few
...
... MTS.MessageSubmissionEnvelope. A few
parameters of the MTA Abstract service are also specified, which are
not in principle available to the MTS User. Use of these services ...
... service are also specified, which are
not in principle available to the MTS User. Use of these services
allows RFC 822std11(-> 2822prop) MTA ...
... MTA level parameters to be carried in the analogous
X.400 service elements. The advantages of this mapping far outweigh
the layering violation.
...
...
The IPM (IPMS Service Request) is generated according to the rules of
this section. The IPMS.IPM.body usually consists of one IPMS ...
... Notifications and IP Messages in Section 5.3. As this specification
only aims to preserve existing services, a gateway conforming to this
specification does not need to map all of these fields to X.400 ...
... MTA, MTS, or IPMS services. The level of
support for this reverse mapping should be indicated in the gateway
...
... It is not clear how widely supported the X.400 return of contents
service will be. Experience with X.400(1984) suggests that support
of this service ...
... service will be. Experience with X.400(1984) suggests that support
of this service may not be universal. As this service is expected in
the RFC 822std11(-> 2822prop) ...
... X.400(1984) suggests that support
of this service may not be universal. As this service is expected in
the RFC 822std11(-> 2822prop) world, two approaches are specified. The choice will
...
...
In environments where return of contents is widely supported, content
return can be requested as a service. The content return service can
then be passed back to the end (RFC 822std11(-> 2822prop) ...
... In environments where return of contents is widely supported, content
return can be requested as a service. The content return service can
then be passed back to the end (RFC 822std11(-> 2822prop)) user in a straightforward
...
... IPMS.BodyParts are mapped onto a
single RFC 822std11(-> 2822prop) body. Other services are mapped onto RFC 822std11(-> 2822prop) header
fields. Where there is no appropriate existing field, new fields are
...
... Delivery. As with
submission, there are aspects where the MTA (transfer) services are
also used. In particular, there is an optimisation to allow for
multiple 822-MTS ...
...
An RFC 822std11(-> 2822prop) Service requires to have a number of mandatory fields in
the RFC 822std11(-> 2822prop) Header ...
... 822std11(-> 2822prop) Header. Some 822-MTS services mandate specification of
an 822-MTS Originator. Even in cases where this is optional, it is
...
... delivery-envelope is used
for the MTS Abstract Service Mappings. If present, the
IPMS.MessageBodyPart.parameters.delivery ...
...
These elements imply use of security services not available
in the RFC 822std11(-> 2822prop) environment. If they are marked as critical ...
...
There are some mappings at the MTA Abstract Service level which are
done for IPM and IPN. These can be derived from
MTA ...
... different RFC 822std11(-> 2822prop) message would be calculated for each recipient, due
to differing service requests for each recipient. As discussed in
4.6.2..2, this specification allows either for multiple messages to
be generated, or for the per- recipient information to be discarded.
...
... Delivery reports are mapped at the MTS service level. This means
that only reports destined for the MTS user will be mapped. Some
...
... that only reports destined for the MTS user will be mapped. Some
additional services are also taken from the MTA service.
...
...
A Delivery Report service will be represented as
MTS.ReportDeliveryEnvelope, which comprises of per-report-fields
...
... 822std11(-> 2822prop) functionality. The value
of the reply is dependent on whether the gateway could service an MTS
Message with the values specified in the probe ...
... shall be set for each recipient, and the Acknowledge-To: field
discarded. Here, X.400 can provide the equivalent service.
In all other cases two actions are taken.
...
... table format, but the syntax is defined in a manner which makes it
suitable to be adapted for use with the Domain Name Service.
This syntax allows for a general representation of O/R addresses,
...
... provided to give access from RFC 822std11(-> 2822prop) to a number of X.400 services.
These mappings are beyond the basic scope of this specification.
There has been a definite demand to use extended RFC 822std11(-> 2822prop) ...
... X.400
side are minimised, but are more acceptable, due to the mapping onto
a new set of services and protocols.
1. Introduction
...
... 1. Introduction
The model has shifted from a protocol based mapping to a service
based mapping. This has increased the generality of the
specification, and improved the model. This change affects the
...
... Message Handling Systems: Message Transfer System: Abstract
Service Definition and Procedures, December 1988.
CCITT/ISO88d.
...