service
Click on the red underlined text to get to the source
... The X.400 series protocols have been defined by CCITT to provide
an Interpersonal Messaging Service (IPMS), making use of a store
and forward Message Transfer Service ...
... Service (IPMS), making use of a store
and forward Message Transfer Service. It is expected that this
standard will be implemented very widely. As well as the base
standard (X.400 ...
... 920 which is a specification for a
domain name system and a distributed name service [Postel84a].
RFC 822std11(-> 2822prop), or protocols derived from RFC 822std11(-> 2822prop) ...
... 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 X.400 systems. This
will be a requirement ...
... make a transition to use of X.400, where conversion will be needed
to ensure a smooth service transition. It is expected that there
will be more than one gateway <1>, and this specification will
...
... 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 ...
... The CCITT X.400 series recommendations specify a number of
services and protocols. The services are specified in X.400.
...
... X.400 series recommendations specify a number of
services and protocols. The services are specified in X.400.
Two of these services ...
... services are specified in X.400.
Two of these services are fundamental to this document:
1. The Message Transfer Service ...
... services are fundamental to this document:
1. The Message Transfer Service, which can be provided by
either the P1 or P3 protocols, which are specified in
X.411 [CCITT84b]. This document talks in terms of P1,
...
... but the mappings are equally applicable to P3.
2. The Interpersonal Messaging Service (IPMS), which is
provided by the P2 protocol specified in X.420
...
... This document considers only IPMS, and not of any other usage
of the Message Transfer Service. This is reasonable, as
RFC 822std11(-> 2822prop), broadly speaking, provides a service ...
... Service. This is reasonable, as
RFC 822std11(-> 2822prop), broadly speaking, provides a service corresponding to
IPMS, and no services ...
... service corresponding to
IPMS, and no services other than IPMS have been defined over
the Message Transfer Service ...
... services other than IPMS have been defined over
the Message Transfer Service. As none of the RTS (Reliable
Transfer Service ...
... Service. As none of the RTS (Reliable
Transfer Service) service elements is available to the IPMS ...
... The Message Transfer Service defines an end-to-end service over
a series of Message Transfer Agents (MTA ...
... list of recipients, and trace information. It is used to
carry data for higher level services.
Probe ...
... priority. The validity of these fields is not
guaranteed by the Message Transfer Service. This
provides the basic IPMS.
...
... RFC 822std11(-> 2822prop) is based on the assumption that there is an underlying
service, which is here called the 822-P1 service. The 822-P1
service ...
... 822std11(-> 2822prop) is based on the assumption that there is an underlying
service, which is here called the 822-P1 service. The 822-P1
service provides three basic functions:
...
... service, which is here called the 822-P1 service. The 822-P1
service provides three basic functions:
1. Identification of a list of recipients.
...
... functional nature of a gateway can now be considered. It would
be elegant to consider the 822-P1 service mapping onto P1 and
RFC 822std11(-> 2822prop) mapping onto P2, but reality just does not fit.
...
... RFC 822std11(-> 2822prop) and X.400 provide a number of services to the end user. This
document describes the extent to which each service can be supported
...
... X.400 provide a number of services to the end user. This
document describes the extent to which each service can be supported
across an X.400 <-> RFC 822std11(-> 2822prop) ...
... crossings are noted where appropriate.
When a service element is described as supported, this means that
when this service ...
... service element is described as supported, this means that
when this service element is specified by a message originator for a
recipient behind a gateway ...
... gateway, that it is mapped by the gateway to
provide the service implied by the element. For example, if an
RFC 822std11(-> 2822prop) ...
... element.
For some services, the corresponding protocol elements map well, and
so the service ...
... services, the corresponding protocol elements map well, and
so the service can be fully provided. In other cases, the service
cannot be provided, as there is a complete mismatch. In the
...
... protocol elements map well, and
so the service can be fully provided. In other cases, the service
cannot be provided, as there is a complete mismatch. In the
remaining cases, the service ...
... service
cannot be provided, as there is a complete mismatch. In the
remaining cases, the service can be partially fulfilled. The level
of partial support is summarised.
...
... of partial support is summarised.
NOTE: It should be clear that support of service elements on
reception is not a gatewaying issue. It is assumed that all
...
...
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. A mechanism
of mapping used in several cases, is to place the text of the
...
... 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 almost supported. Chapter 5
describes how to map these new headers in both directions. Other
...
... gateway as they cannot be
provided by RFC 822std11(-> 2822prop). Some service elements are are marked N/A
(not applicable). These elements ...
... Interpersonal Message Service Elements ...
... remote system, with the choice of gateway being left to the
Message Transfer Service. There are two fundamental reasons why
this is not possible:
...
... restriced syntax is chosen as it is the one chosen by the
various domain service administrations.
This provides a general aliasing mechanism.
...
... It is not clear how widely supported X.400 return of contents
service will be. However, profiling work suggests that most
systems will not support this service. As this service ...
... service will be. However, profiling work suggests that most
systems will not support this service. As this service is
expected in the RFC 822std11(-> 2822prop) ...
... service will be. However, profiling work suggests that most
systems will not support this service. As this service is
expected in the RFC 822std11(-> 2822prop) world, two approaches are specified (it is
...
... delivery reports are
distinguished from messages). The choice will depend on the
service level of the X.400 community being serviced by the
gateway ...
... 822std11(-> 2822prop) -> X.400. The
content return service can then be passed back to the end
(RFC 822std11(-> 2822prop)) user in a straightforward manner.
...
... Service MPDU ...
... 822std11(-> 2822prop) functionality. The value of the
reply is dependent on whether the gateway could service a
User MPDU with the values specified in the probe. The reply
...
... implementors, but should be noted carefully
by transport and network service implementors. (Sometime called
a "mail relay".)
...