service
Click on the red underlined text to get to the source
... 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.
...
...
to discard information in the objects it processes. This
includes requested services which cannot be fully mapped.
4. All mail gateways ...
... 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 ...
... 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 define the interaction between MTAs, along with the procedures
...
... which define 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
or MTA ...
...
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)).
In particular, there is no expectation of additional X.400 ...
... 822std11(-> 2822prop)).
In particular, there is no expectation of additional X.400 services
being mapped - although this may be possible in some cases.
...
... X.400
side are minimised, but are more acceptable, due to the mapping onto
a new set of services and protocols.
A summary of changes ...
...
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 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 services ...
... 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 ...
...
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 ...
... 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 ...
... 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 should be 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 should be represented in
...
... MTS.OtherMessageDeliveryFields.extensions should be 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 ...
...
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
...
... There is a need to map directly onto some aspects of the MTA Abstract
service, for the following reasons:
- So the the MTS ...
... 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 these fields to X.400 ...
... 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 should be
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 ...
... some cases, a different RFC 822std11(-> 2822prop) message would be calculated for
each recipient. If this is due to differing service requests for
each recipient, then a different message should be generated.
If it is due only to the request for non-disclosure of
...
... 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 ...
... 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
...
... namespaces described in Chapter 4. The use of this association
leads to a better service on both sides of the gateway, and so
defining mappings and distributing them in the form defined in this
...
... ISO, "CCITT Recommendations X.400/ ISO IS 10021-1", Message Handling: System and Service Overview, CCITT/ISO, December 1988. ...
... ISO, "CCITT Recommendations X.411/ ISO IS 10021-4", Message Handling Systems: Message Transfer System: Abstract Service Definition and Procedures, CCITT/ISO, December 1988. ...