Internet Standards/CD2.mdf/ccitt/1992/f/f420.asc

Text File | 1994-01-30 | 46KB | 1,092 lines

Recommendation F.420

                     MESSAGE HANDLING SERVICES:
            THE PUBLIC INTERPERSONAL MESSAGING SERVICE

     The establishment in various countries of message handling
services in association with public networks creates the need to
produce Recommendations covering the aspects of public message
handling services.

     The CCITT,

considering

     (a)   the need for public message handling services;

     (b)   the strategic and commercial importance of
standardization of message handling services;

     (c)   the urgent need for intercommunication agreements for
existing telematic services, and other services with public message
handling services;

     (d)   the need for a clear distinction between the
responsibilities to be allocated to service providers and those of
subscribers and/or users;

     (e)   the need for establishing international compatibility
between different messaging systems;

     (f)   the growth of the installed base of terminals and
personal computers with the ability to access message handling
systems;

     (g)   that several F-series Recommendations describe public
message handling services;

     (h)   that certain X and T-series Recommendations cover
relevant aspects of systems used for the provision of messaging
services,

unanimously declares

     the view that the requirements specified in this
Recommendation should be applied for the provision of the public
interpersonal messaging service internationally.

                             CONTENTS


1    Purpose and scope
     1.1  General
     1.2  Message handling systems used in the provision of IPM
        service

2    IPM service
     2.1  General service requirements
     2.2  IPM service features
     2.3  Responsibility boundaries
     2.4  Message service
     2.5  Use of directory
     2.6  Security
     2.7  Distribution lists
     2.8  Intercommunication with physical delivery services

3    Types of body parts

4    Conversion between different encoded information types

5    Naming and addressing in general
     5.1  Directory names
     5.2  O/R names
     5.3  O/R addresses

6    Operation of the service
     6.1  General
     6.2  Message handling phases

7    Quality of service
     7.1  Message status
     7.2  Support by Administrations
     7.3  Model of delivery and notification times
     7.4  Message delivery time targets
     7.5  Delivery notification time targets
     7.6  Receipt notifications and non-receipt notifications
     7.7  Error protection
     7.8  Availability of service
     7.9  Minimum storage capacity

8    Tariff and accounting principles

9    Network requirements

10   User information and support

11   Use of the IPM service within CCITT-defined telematic services

Annex A -  Abbreviations

Annex B -  Subscriber access and terminal requirements

Annex C -  IPM service elements from 1984 X.400 Recommendations


1    Purpose and scope

1.1  General

     This Recommendation specifies the general, operational and
quality of service aspects of the public international
interpersonal messaging service. interpersonal messaging services
provided by Administrations belong to the group of telematic
services defined in the F-series Recommendations.

     This type of message handling service is an international
telecommunication service offered by Administrations, enabling
subscribers to send a message to one or more recipients and to
receive messages via telecommunication networks using a combination
of store-and-forward, and store-and-retrieve techniques.

     Locally provided functions, for which communication with other
subscribers is not required, are not covered by CCITT
Recommendations.

     The Interpersonal Messaging (IPM) Service enables subscribers
to request a variety of features to be performed during the
handling and exchange of messages.

     Some features are inherent in the basic IPM service. Other non-
basic features may be selected by the subscriber, either on a per-
message basis or for an agreed contractual period of time, if they
are provided by Administrations.

     Basic features have to be made available internationally by
Administrations. Non-basic features, visible to the subscriber, are
classified as either essential or additional. Essential optional
features must be made available internationally by Administrations
for national use and internationally on the basis of bilateral
agreement. Non-basic features are called optional user facilities.

     IPM service may be provided using any physical network. IPM
service may be offered separately or in combination with various
telematic or data communication services. It can be obtained by
making appropriate arrangements.

     Technical specifications and protocols, to be used in the IPM
service are defined in the X.400-series Recommendations, in
Recommendation T.330 and in Recommendation U.204.

     This service definition is contained in ñ 2. Requirements for
intercommunication between subscribers are described in ññ 3 and 4.
Section 5 describes naming and addressing, while ññ 6, 7 and 8
describe the operation of the service, quality of service, tariff
and accounting principles. Network requirements are given in ñ 9.
The provision of subscriber information is in ñ 10, and ñ 11
contains information on the use of IPM service within CCITT defined
telematic services.

1.2  Message handling systems used in the provision of IPM service

1.2.11984 implementations

     This service Recommendation assumes that the message handling
systems implemented to provide the service outlined herein are
based on the 1988 version of the X.400-series Recommendations. It
is recognized however that for some time after the publication of
this Recommendation, the majority of implementations of IPM service
will be based on the 1984 X.400-series of Recommendations.
Administrations are encouraged to adopt the latest CCITT
Recommendations; however, in the interim, they may make use of this
Recommendation with 1984 implementations as outlined below.

1.2.2Elements of service

     Elements of service available for message handling services
are listed and classified in Recommendation F.400. Annex C provides
a list of all the elements of service (called service elements in
1984) for IPM from the 1984 X.400 Recommendation. In addition, the
classification of each element of service as they were in 1984 in
Recommendation X.401 are shown. In the 1988 X.400 Recommendation,
there are many new elements of service representing the new
functionality that were not present in 1984. Most of these have
been classified as additional, meaning that they do not have to be
supported, hence the 1984 implementations can make use of this
service Recommendation in most cases. Other differences between
1988 and 1984 are of two types, new elements of service that are
classified as essential, and old (meaning 1984) elements of service
that have been re-classified as essential for 1988. Annex C of
Recommendation F.400 lists both the new elements of service in 1988
as well as changes in classification to any 1984 elements of
service. In both cases, to allow for 1984 implementations to be
used for the provision of public IPM service as described in this
Recommendation, a grace period of 8 years is provided for
Administrations to upgrade their implementations in this respect to
the 1988 technical Recommendations.

1.2.3Name forms

     The specification of the name forms in the 1988
Recommendations have been enhanced and postal O/R addresses have
been added. The name forms and the mandatory components of the 1984
Recommendations have their equivalence in the new framework and are
aligned in principle.

1.2.4Interworking

     In order to protect the investment of Administrations who have
implemented 1984 systems for the provision of IPM service, 1988
ADMD implementations shall be able to interwork to 1984 ADMDs as
outlined in Recommendation X.419, Annex B.

     Interworking from 1988 ADMDs to 1984 PRMDs is a national
matter.


2    IPM service

2.1  General service requirements

2.1.1   The fundamental ability of the IPM service is to provide a
public interface between originators and recipients to enhance
their means of communication especially where there is no immediate
or convenient direct telecommunication service available between
subscriber's equipment or the telecommunication services available
are incompatible.

     This service may also provide features available for the
preparation and the presentation of the messages.

2.1.2   The IPM service will be provided by Administrations using
the message transfer service defined in Recommendation F.410, and
by systems that conform to the X.400-series of Recommendations.

     Management domains (MDs) are defined for the purpose of
responsibility boundaries. The MD managed by an Administration is
called an administration management domain (ADMD). The MD managed
by an organization is called a private management domain (PRMD).

2.1.3   International exchange of messages are performed between
administration management domains through CCITT-standardized public
data transmission services.

2.1.4   Different body part types of messages may be exchanged
through this service. The urgent body part types are listed in ñ 3.

2.1.5   An Administration may provide subscribers with different
methods of access to the IPM service. The possible methods are:
     1)directly from the user's terminal;
     2)via a private message handling system.

2.1.6   Each Administration is responsible for the national access
to its management domain.

2.1.7   The characteristics of the interfaces and access methods
used between terminals and the IPM service are a national matter,
although they may follow various CCITT-standardized services such
as telex, teletex, facsimile videotex or data transmission
services. However, the IPM service optional user facilities offered
are defined and are independent of the access method and user's
terminal.

2.1.8   The national implementation of the IPM service may provide
intercommunication with existing services such as telex, teletex,
facsimile and videotex. When implemented, the interfaces between
the IPM and the other services shall be according to relevant CCITT
Recommendations.

2.1.9   As the service is providing indirect communication, cases
of non-delivery of the message to the intended recipient may occur.
The IPM service provides for non-delivery notification and, as
optional user facilities, for delivery, receipt and non-receipt
notifications.

2.1.10  Due to the intermediate storage of the message, the service
may provide conversion optional user facilities: speed, access
procedures, networks, and coding of message contents.

2.1.11  The message belongs to the originator until delivery has
taken place. After delivery, the message belongs to the recipient.

2.1.12  Where a sender and recipient have different and conflicting
requirements, the sender's requirements shall take precedence
(e.g., body type conversion or redirection control).

2.2  IPM service features

2.2.1Introduction

     Recommendation F.400, ñ 19, defines elements of service which
are available in the IPM service and are classified as either
belonging to the basic service or as IPM optional user facilities.
Elements of service comprising the basic IPM service are inherently
part of the service and are always provided and available. The
optional user facilities that are classified as essential are
always provided and those classified as additional may be available
nationally, or internationally on the basis of bilateral agreement.

2.2.2Basic IPM service

     A set of elements of service comprises the basic IPM service.
This set is defined in Recommendation F.400, and listed in Table
10/F.400. The basic IPM service, which is built upon the MT
service, enables a user to send and receive IP messages. A user
prepares IP-messages with the assistance of his user agent (UA).
User agents, which are a set of computer application processes,
cooperate with each other to facilitate communication between their
respective users. To send an IP-message, the originating user makes
a request of his UA, specifying the name or address of the
recipient who is to receive the IP-message. The IP-message, which
has an identifier conveyed with it, is then sent by the
originator's UA to the recipient's UA via the message transfer
service.

     Following a successful delivery to the recipient's UA, the IP-
message can be followed by the recipient. To facilitate meaningful
communication, a receiving user may specify the encoded information
type(s) that can be contained in IP-messages delivered to him, as
well as the maximum length of a message he is willing to have
delivered to him. The original encoded information type(s) and an
indication of any conversions that may have been performed and the
resulting encoded information type(s) are supplied with each
delivered IP-messages. In addition, the submission time, delivery
time and other capabilities are supplied with each IP-message. Non-
delivery notification is provided with the basic services.

2.2.3IPM optional user facilities

     A set of the elements of services of the IPM service are
optional user facilities. The optional user facilities which may be
selected on a per-message basis or for an agreed contractual period
of time, are listed in Tables 11/F.400 and 12/F.400, respectively.
Local user facilities may be usefully provided in conjunction with
some of these user facilities.

     The optional user facilities of the the IPM service that are
selected on a per-message basis are classified for both origination
and reception by UAs. If an Administration provides the IPM service
and offers these optional user facilities for origination by UAs,
then a user is able to create and send IP-messages according to the
procedures defined for the associated element of service. If an
Administration provides the IPM service and offers these optional
user facilities for reception by UAs, then the receiving UA will be
able to receive and recognize the indication associated with the
corresponding Element of Service and to inform the user of the
requested optional user facility. Each optional user facility is
classified as additional or essential for UAs from these two
perspectives.

     Note - With the access protocol described in Recommendation
T.330, teletex terminals are able to make use of the basic IPM
service as well as of the optional user facilities provided by the
message handling service.

2.2.4Local functions

     The MHS may perform many local functions for its subscribers
in addition to providing IPM features. For example, to assist
subscribers in preparing and editing IP-messages, MHS may provide
an editing capability. This editor could operate on a single line
of text at a time, or it could permit the display and alteration of
a page at a time. A subscriber may have to access MHS frequently to
determine if new messages have arrived. Alternatively, the MHS
could alert the subscriber when new messages have arrived (for
example, by setting a message light on his telephone, or by his
displaying on his desktop terminal the originator's name and
subject of all unread messages or by computer-initiated voice
indication).

     The MHS may provide local database controls to help the
subscriber find previously received and filed IP-messages (for
example, to find the message from Mr. Jones delivered sometime in
August on the subject of teleconferencing). A subscriber on
vacation may request the MHS to automatically forward all his IP-
messages to his delegate, or define rules for which IP-messages
should not be auto-forwarded (for example, personal messages).

     Local services such as those above, while perhaps utilizing
some of the IPM features, do not require coordination or
cooperation with other subscribers. Thus they do not impact the
communication protocols associated with MHS. Therefore, local
functions that may be provided by Administrations are outside the
scope of CCITT.

2.3  Responsibility boundaries

     The purpose of the MHS is to allow messages to be submitted
for transfer to the destination and to be delivered to a UA/MS
whose address is specified by the originator.

     A user interacts with his UA on the sending and on the
receiving side. On his request, a message is submitted to the MTS.
He is also able to retrieve a received message from his UA or MS.

     The responsibility for the message rests in the MHS when the
originating user gives the command to send the message. The
responsibility for a message is turned over to the receiving UA/MS
after successful delivery. If the UA or MS is provided by an
Administration, the responsibility for the message is taken over by
the user when he reads the message.

     As a basic feature, a non-delivery notification is created by
the MHS when delivery to the receiving UA/MS is not possible. The
conditions applied to this criteria may also depend on optional
user facilities, e.g. conversion prohibition. An originating user
may, for a particular message, specifically request a delivery
notification, and/or a receipt notification, and/or a non-receipt
notification.

     In the case of telematic addresses or telex addresses,
delivery takes place automatically when the message is transmitted
to the receiving terminal. The responsibility of the MHS ends when
the message is received by the terminal. After delivery to a
document store, or a message store, responsibility turns over to
the user after having read the message once. When leaving the
message in the store, the responsibility will be defined by the
service provider.

     Loss of information may occur through the process of
conversion as long as the conversion is not explicitly prohibited
by the originating user.

     The responsibility of messages transferred through MDs starts
at the moment of entering the domain and ends when leaving the
domain; however, a later audit must be possible.

     When an ADMD interacts with a PRMD, the ADMD takes
responsibility for the actions of the PRMD which are related to the
interaction. In addition to ensuring that the PRMD properly
provides the MT service, the ADMD is responsible for ensuring that
the accounting, logging, quality of service and other related
operations of the PRMD are correctly performed. An ADMD acts as the
naming authority for the associated PRMDs.

2.4  Message store

     Administrations may optionally provide message store (MS) to
permit delivery of messages so that the recipient's UA does not
have to be on line continuously. This is described in
Recommendation F.400, ñ 7.4. A message delivered to an MS is deemed
delivered by MHS. Messages delivered to an MS can be retrieved by
the recipient at his convenience and various optional user
facilities can be provided to allow for retrieval for listing,
fetching, and deletion of messages. When subscribing to an MS, all
messages destined to the UA are delivered to the MS, and if the UA
is on line, an alert will be sent to the UA (from the MS) to inform
the user of the fact that a message just arrived.

2.5  Use of directory

     By making use of directory systems, IPM users will be able to
address recipients by using directory names or distribution list
names, which are more user friendly than O/R addresses. The MHS
will be able to access a directory system and find out the O/R
address(es) corresponding to a given directory name or distribution
list name, for delivery of a message. This capability is described
in Recommendation F.400, ñ 14.

2.6  Security

     Administrations may optionally provide security mechanisms as
outlined in Recommendation F.400, ñ 15, to counter the various
security threats mentioned. This capability relies on a Directory
System storing certified copies of public keys for MHS users.

2.7  Distribution lists

     A group whose membership is stored in the directory can be
used as a distribution list (DL). The originator simply supplies
the name of the list on submission of a message, and the MHS can
obtain the directory names (and then the O/R addresses) of the
individual recipients, by consulting the directory. Upon receipt of
a message addressed to a distribution list, the recipient can
determine through which DL the message arrived. An originator can
prohibit the expansion of the distribution if one of the recipients
specified refers to a distribution list. Recommendation F.400, ñ
14, outlines the full capabilities available to DL users.

     If a user unknowingly sends a message to a DL, he may incur
charges for multiple deliveries that he was not expecting. Because
of this, names of distribution lists should be indicative of the
fact that what is being named is a DL. Owners of DLs should also
insure that they respect a potential member's wishes about being a
member and the rules of the country of the member that may prohibit
inclusion without prior agreement.

2.8  Intercommunication with physical delivery services

     The intercommunication with the physical delivery services is
an optional capability of the IPM service that allows for the
sending of a message from an IPM user to a recipient via physical
means, such as the traditional postal service. To invoke the
capability, the originating user shall use the requested delivery
method element of service on submission of his message, specifying
physical delivery. The message may be addressed using the postal
O/R address, or the directory name of the intended recipient, in
which case the MHS will consult the directory system to determine
the postal O/R address, The use of MH/PD service intercommunication
by IPM users is described in Recommendation F.415 and
Recommendation F.400, ñ 10.


3    Types of body parts

     Messages sent and received in the IPM service can be composed
of one or more body parts. Applicable body part types are defined
in Recommendation X.420 and comprise the following:
     - IA5 text,
     - Voice,
     - G3 facsimile,
     - G4 class 1,
     - Teletex,
     - Videotex,
     - Encrypted,
     - Message (e.g., for a forwarded message),
     - Mixed mode,
     - Bilaterally defined,
     - Nationally defined,
     - Externally defined.


4    Conversion between different encoded information types

     The MTS provides conversion functions to allow IPM users to
input messages in one encoded format, called encoded information
type (EIT), and have them delivered in another EIT to cater to
users with different terminal types. This capability is inherent in
the IPM service, and increases the possibility of delivery by
tailoring the message to the recipient's terminal capabilities. The
EITs supported for the IPM service are defined in Recommendation
X.420. IPM users have some control over the conversion process
through various elements of service as described Recommendation
F.400/Annex B. These include the ability for a user to explicitly
request the conversion required or as a default to let the MTS
determine the need for, and type of, conversion performed. Users
also have the ability to request that conversion not be performed
or that conversion not be performed if loss of information will
result. The definition of loss of information is given in
Recommendation X.408.

     When the MTS performs conversion on a message, it informs the
UA to whom the message is delivered that conversion took place and
what the original EIT was.

     The conversion process for IP-messages can be performed on
specific body parts if they are present in a message. The general
aspects of conversion and the specific conversion rules for
conversion between different EITs in the IPM service are detailed
in Recommendation X.408.


5    Naming and addressing in general

     In MHS, the principal entity that requires naming is the user
(the originator and recipient of messages). In addition,
distribution lists (DLs) have names for use in MHS. Users of MHS
nad DLs are identified by O/R names. O/R names are comprised of
directory names and/or O/R addresses, all of which are described in
this section. Recommendation F.401 provides more detail on naming
and addressing for public message handling services, including
naming restrictions and responsibilities of Administrations.

5.1  Directory names

     Users of MHS service, and DLs, may be identified by a name,
called a directory name. A directory name has to be looked up in a
directory to find out the corresponding O/R address. The structure
and components of directory names is described in the X.500 series
of Recommendations.

     A user may access a directory system directly to find out the
O/R address of a user or O/R addresses of the members of a DL (both
of which are outside the scope of these Recommendations). As an
alternative, a user may use the directory name and have the MHS
access the directory to resolve the corresponding O/R address or
addresses automatically.

     Every MHS user or DL will not necessarily have a directory
name, unless they are registered in a directory. As directories
become more prevalent, it is expected that directory names will be
the preferred method of identifying MHS users to each other.

5.2  O/R names

     Every MHS user or DL will have an O/R name. An O/R name
comprises a directory name, an O/R address, or both. The directory
name unambiguously identifies an MHS user but not necessarily
uniquely. The O/R addres uniquely identifies an MHS user.

     Either or both components of an O/R name may be used on
submission of a message. If only the directory name is present, the
MHS will access a directory to attempt to determine the O/R
address, which it will then use to route and deliver the message.
If the directory name is absent, it will use the O/R address, but
will carry the directory name and present both to the recipient. If
the O/R address is incorrect, it will then attempt to use the
directory name as above.

5.2  O/R addresses

     An O/R address contains information that enables the MHS to
uniquely identify a user to deliver a message or return a
notification to him. (The prefix ╥O/R╙ recognizes the fact that the
user can be acting as either the originator or recipient of the
message or notification in question).

     Various forms of O/R addresses are currently defined, each
serving its own purpose. These forms and their purpose are as
follows:
     - Mnemonic O/R address: Provides a user-friendly means of
        identifying users in the absence of a directory. It is also
        used for identifying a distribution list.
     - Terminal O/R address: Provides a means of identifying users
        with terminals belonging to various networks.
     - Numeric O/R address: Provides a means of identifying users
        with numeric keypads.
     - Postal O/R address: Provides a means of identifying
        originators and recipients of messages and notifications,
        for physical delivery.

     An O/R address is made up of a collection of information
called attributes. These attributes as used in each of the O/R
address forms above are detailed in Recommendation F.401.

     Management domains shall allow their users to originate
messages using any of the above forms. The form in which names are
input by or presented to the subscriber is a national matter (as
for example the use of distribution lists or of friendly ways of
identifying user agents).

     Each Administration is responsible for the unique
identification of each user agent in its management domain.


6    Operation of the service

6.1  General

6.1.1   The IPM service provides that messages can be sent,
transferred, delivered and received, using fully automatic
procedures.

     Note - Manual receipt and sending of message can be provided
in the case of interworking with postal systems.

6.1.2   Messages are prepared in, sent from, and delivered to a
memory. These memories are part of the User Agent/MS functionality
and are under control of the subscriber.

6.1.3   The transfer of messages between management domains will be
in accordance to the message transfer service as described in CCITT
Recommendation F.410.

6.1.4   Each Administration providing the IPM service should
validate the subscribers' identities, at the time of access.

     Note - Further study is needed in the case of auto-receipt.

6.1.5   It is a national matter whether to allow private messaging
systems to connect to the public IPM service, in order to allow
users of these systems to exchange messages. If these
interconnections are provided, they should take place between
Administration management domains in accordance with CCITT
Recommendations.

6.1.6   When implicit conversion is provided by the Adminstration
via the message transfer service, the message vill be converted if
necessary, unless prohibited by the originator. The conversion will
be in accordance to the rules specified in CCITT Recommendations
X.408. See also ñ 4 of this Recommendation.

6.1.7   Deferred Delivery shall be provided by the management
domain of the originator, which is responsible for the storage of
the message until the date and time specified for intended
delivery. Therefore the element of service, deferred delivery,
should not be used across international links.

6.2  Message handling phases

6.2.1General

     The IPM service has different message handling phases visible
to the user.

6.2.2Preparation phase

     In this phase, messages are prepared by making use of the User
Agent functionality (e.g. editing and filing). The way in which
these functions are performed is outside the scope of this
Recommendation.

6.2.3Sending phase

     In this phase, the originator may request the user agent or
message store to send a prepared message to one or more recipients
and to request certain optional user facilities.

6.2.4Receipt phase

     In this phase, the subscriber can receive delivered messages
and notifications from his user agent or message store. The receipt
phase can be initiated by the service (auto-receipt) or by the
subscriber for message reception. The operation of the user agent
receiving messages is specified in Recommendation X.420.

     Subscribers using terminals without user agent functionality
may registter for a contractual period of time during which they
will receive delivered messages automatically from their user agent
to a terminal, if the Administration provides for this alternative.
Normally the user agent is called to receive incoming messages.

     In the case of auto-receipt, the MHS will initiate a call to
the subscriber's terminal. In the other case, the subscriber shall
initiate a call to the MHS at a time convenient to the subscriber.

     The body parts of the message will be received by the
subscriber in the form in which the originator has sent it, unless
conversion has been performed.

     For messages delivered to a teletex access unit,
Recommendation T.330 defines the optional means by which the
subscriber may receive or retrieve delivered messages.

     The indication of the optional user facilities requested by
the originator are presented by the user agent to the recipient in
a form convenient to him.

     Notifications: Four notifications can be received:
     - non-delivery notification;
     - delivery notification;
     - receipt notification;
     - non-receipt notification.

     Non-delivery notification is automatically originated by the
MTS, while delivery notification, receipt and non-receipt
notification depend on the action of the recipient. In the case of
a message to a teletex terminal, (auto) receipt notification may be
returned by the TTXAU.


7    Quality of service

7.1  Message status

     The unique identification of each IP-message enables the
system to provide information about, e.g., the status of an IP-
message.

     In the event of system failure, all accepted and non-delivered
messages should be traceable. If messages cannot be delivered, the
originator must be informed by a non-delivery notification.

7.2  Support by Administrations

     Administrations should provide assistance to their
subscribers, with regard to non-delivery notifications not being
received in due time, as far as public system components are
concerned. Additional provision on support of status and tracing of
messages may be provided under national responsibility.

     When the user agent is provided by an Administration,
additional functionality should be provided in order to minimize
cases of not reading messages within a certain period of time (the
definition of this period is for further study). This functionality
could be, for example, alert messages sent to an automatic
reception terminal.

7.3  Model of delivery and notification times (see Figure 1/F.420)

7.4  Message delivery time targets

     The management domain of the recipient UA should force non-
delivery notification if the message has not been delivered before
x hours after submission (or after date and time indicated for
deferred delivery), the value of x being dependent on the grade of
delivery requested by the originator. (See Recommendation F.410, ñ
4.4.)

7.5  Delivery notification time targets

     Non-delivery notifications or requested delivery notifications
should be returned on a per-recipient basis, in order not to delay
notifications for those messages in a multi-addressed message which
have already been delivered, to enable the originating management
domain either to return per-recipient notifications or to batch
notifications to its subscribers. (See Recommendation F.410, ñ
4.5.)

7.6  Receipt notifications and non-receipt notifications

     Delivery times for receipt or non-receipt notifications in the
first place depend on local arrangements. When they are initiated
by the receiving UA/user, they have the same time targets as the
messages that cause them to occur (see Table 1/F.420).

7.7  Error protection

     Error protection on transmission is provided by the MHS and
underlying protocols used in the provision of the IPM service.

7.8  Availability of service

     In principle, the IPM service should be available
continuously. The user agent should be available for submission of
delivery continuously (unless hold for delivery is invoked). In
cases where the UA is not available for delivery continuously, a
message store should be used.




                          Figure 1/F.420


                           TABLE 1/F.420

                    Grade of      95% delivered
                  delivery (of        before
                  the referred
                    message)


                Urgent              0.75 hours


                Normal              4    hours


                Non-urgent         24    hours

Note - Intercommunication with PRMDs is not included in the
calculation of the time targets.

7.9  Minimum storage capacity

     The storage capacity of a user agent and message store shall
be sufficient to provide a high grade of service.

     Note - This is for further study.


8    Tariff and accounting principles

     See D-series Recommendations.


9    Network requirements

     The IPM service is network independent, that is, the basic
service and the essential optional user facilities are provided
independently of the type of network used for service access.
Additional optional user facilities chosen by an Administration to
offer may vary.


10   User information and support

     A directory shall be provided by each Administration for its
domain. The directory can be hard copy or preferably electronic
form.

     The directory shall at least contain the following:
     a)how to use the directory and the service;
     b)list of O/R addresses of subscribers belonging to the
        Administration's domain;
     c)list of standardized abbreviations for O/R address
        attributes;
     d)list of country and Administration management domain names
        reachable by the public IPM service.


11   Use of the IPM service within CCITT-defined telematic services

     See relevant F-series Recommendations.



                              ANNEX A

                     (to Recommendation F.420)

                           Abbreviations


     The following abbreviations are used in this Recommendation.
           A       Additional Optional User Facility
           ADMD    Administration Management Domain
           DL      Distribution List
           E       Essential Optional User Facility
           EIT     Encoded Information Type
           G3      Group 3 (Facsimile)
           G4      Group 4 (Facsimile)
           IA5     International Alphabet 5
           IP      Interpersonal
           IPM     Interpersonal Messaging
           MD      Management Domain
           MHS     Message Handling System
           MS      Message Store
           MT      Message Transfer
           MTA     Message Transfer Agent
           MTS     Message Tranfer System
           N/A     Not Applicable
           O/R     Originator/Recipient
           PD      Physical Delivery
           PDN     Public Data Network
           PDS     Physical Delivery System
           PRMS    Private Management Domain
           TTXAU   Teletex Access Unit
           UA      User Agent
 Note 1 - For a glossary of terms see Annex A to Recommendation
F.400.
Note 2 - For references see Recommendations F.400 and F.401.



                              ANNEX B

                     (to Recommendation F.420)

            Subscriber access and terminal requirements


B.1  General

     Various types of terminals may be used for accessing the
service. These terminals are functionally divided into two
categories: those without user agent functionality, and those with
user agent functionality. The telematic terminals assume a special
user agent. Telex terminals belong to that first category.

B.2  Terminals without UA functionality

     Terminals in this category require additional functions to be
provided by MHS to enable their participation in the IPM service.

B.2.1Telex terminals

     Telex terminals shall conform to the relevant technical
Recommendations, and be based on the relevant service
Recommendations.

B.2.2Teletex terminals

     Teletex terminals shall conform to Recommendations T.60 and
T.61. Documents which are exchanged between teletex terminals and
the IPM service shall be in conformance to Recommendation F.200.

     The access procedures for submission and delivery of documents
shall conform to Recommendation T.330.

     Note - The use of the interactive session protocol for
submission and delivery is for further study. The ability to
provide IPM service for documents using teletex standardized
options is for further study.

B.2.3Facsimile terminals

     Group 3 and Group 4 facsimile terminals should have access to
the IPM service.

     Note - Access procedures are for further study.

B.2.4Videotex terminals

     These terminals shall conform to Recommendation F.300.

     Note - Access procedures are for further study. Eventual
subset of Recommendation F.300 needs to be considered.

B.2.5IA5 terminals

     The IA5 terminals are terminals able to send and receive
messages encoded by characters chosen from the International
Alphabet No. 5 (Recommendation T.50). The access procedures shall
be based on one of the applicable procedures specified in
Recommendations X.20 to X.32. These procedures describe the
possibility for access to PDNs for data transmission.

     Note - Additional procedures are for further study.

B.3  Terminals with UA functionality

     These terminals shall, as a minimum, have the capabilities to:
     1)provide the capabilities to subscribers of the basic
        features defined in ñ 2;
     2)make use of the IPM protocol specified in Recommendation
        X.420;
     3)use the submission and delivery protocol specified in
        Recommendation X.419;
     4)use the remote operation procedures specified in
        Recommendation X.419.

     These terminals shall be able to handle at least one EIT as
defined in Recommendation X.408 (e.g., IA5, teletex, etc.).
                              ANNEX C

                     (to Recommendation F.420)

       IPM service elements from 1984 X.400 Recommendations

                                             Classification
           Element of service    Basic          Optionnal
                                        Orginat  Recepti  Contrac
                                          ion      on      tual
           Access management               X
           Alternate recipient                      A        A
           allowed
           Alternate recipient                               A
           assignment
           Authorizing users               A        E
           indication
           Auto-fowarded                   A        E
           indication
           Blind copy                      A        E
           recipient
           indication
           Body part                       A        E
           encryption
           indication
           Content type            X
           indication
           Conversion                      E        E
           prohibition
           Converted               X
           indication
           Cross referencing               A        E
           indication
           Deferred delivery               E       N/A
           Deferred delivery               A       N/A
           cancellation
           Delivery                        E       N/A
           notification
           Delivery time stamp     X
           indication
           Disclosure of other             A        E
           recipients
           Expiry date                     A        E
           indication
           Explicit conversion             A       N/A
           Fowarded IP-message             A        E
           indication
           Grade of delivery               E        E
           selection
           Hold for delivery                                 A
           Implicit conversion                               A
           Importance                      A        E
           indication
           IP-message              X
           identification
           Message                 X
           identification
           Multi-destination               E       N/A
           delivery
           Multi-part body                 A        E
           Non-delivery            X
           notification
           Non-receipt                     A        A
           notification
           Obsoleting                      A        E
           indication
           Original encoded        X
           information types
           indication
           Originator                      E        E
           indication
           Prevention of non-              A       N/A
           delivery
           notification
           Primary and copy                E        E
           recipients
           indication
           Probe                           A       N/A
           Receipt                         A        A
           notification
           Registered encoded      X
           information types
           Reply request                   A        E
           indication
           Replying IP-message             E        E
           indication
           Return of contents              A       N/A
           Sensitivity                     A        E
           indication
           Subject indication              E        E
           Submission time         X
           stamp indication
           Typed body              X