delim @@
| 5i'
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
Fascicle II.6 -- Rec. F.420 1
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 4 5 |
Types of body parts .bp Conversion between different encoded information types 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 |
|
|
2 |
Fascicle II.6 -- Rec. F.420 |
7.8 Availability of service
|
7.9 Minimum storage capacity |
|||
|
8 9 10 11 |
Tariff and accounting principles Network requirements User information and support 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.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.
Fascicle II.6 -- Rec. F.420 3
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.1 1984 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.2 Elements 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.3 Name 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.4 Interworking
4 Fascicle II.6 -- Rec. F.420
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.
Fascicle II.6 -- Rec. F.420 5
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
6 Fascicle II.6 -- Rec. F.420
2.2.1 Introduction
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.
Fascicle II.6 -- Rec. F.420 7
2.2.2 Basic 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.3 IPM 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.4 Local 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.
8 Fascicle II.6 -- Rec. F.420
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.
Fascicle II.6 -- Rec. F.420 9
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.
10 Fascicle II.6 -- Rec. F.420
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.
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. |
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.
Fascicle II.6 -- Rec. F.420 11
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.
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.
12 Fascicle II.6 -- Rec. F.420
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.
Fascicle II.6 -- Rec. F.420 13
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. 14 Fascicle II.6 -- Rec. F.420
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 6.2.1 |
Message handling phases General The IPM service has different message handling phases visible to the user. |
|
|
6.2.2 |
Preparation 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.3 Sending 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.4 Receipt 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.
Fascicle II.6 -- Rec. F.420 15
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.
|
16 |
Notifications: Four notifications can be received: -- non-delivery notification; -- delivery notification; -- receipt notification; -- non-receipt notification. Fascicle II.6 -- Rec. F.420 |
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.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.
Fascicle II.6 -- Rec. F.420 17
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.
18 Fascicle II.6 -- Rec. F.420
|
H.T. [T1.420] |
Figure 1/F.420, p.1 |
|||||||||
|
center box; cw(60p) | cw(60p) . { Grade of delivery (of the referred message) } 95% delivered before _ lw(60p) | cw(60p) . |
Urgent |
0.75 hours lw(60p) | cw(60p) . |
Normal |
4 | |
hours lw(60p) | cw(60p) . |
|||||
|
Non-urgent 24 | hours |
|
Note -- Intercommunication with PRMDs is not included in the calculation of the time targets. |
||
|
Tableau Fascicle II.6 -- Rec. |
Tableau 1/F.420 [T1.420], p.2 F.420 19 |
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.
See D-series Recommendations.
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.
|
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. |
See relevant F-series Recommendations.
20 Fascicle II.6 -- Rec. F.420
BLANC
Fascicle II.6 -- Rec. F.420 21
ANNEX A
(to Recommendation F.420)
Abbreviations
The following abbreviations are used in this Recommendation.
H.T. [T2.420]
center box; lw(30p) | lw(120p) . A { Additional Optional User Facility
} lw(30p) | lw(120p) . ADMD { Administration Management Domain
} lw(30p) | lw(120p) . DL Distribution List lw(30p) | lw(120p) . E { Essential Optional User Facility
} lw(30p) | lw(120p) . EIT Encoded Information Type lw(30p) | lw(120p) . G3 Group 3 (Facsimile) lw(30p) | lw(120p) . G4 Group 4 (Facsimile) lw(30p) | lw(120p) . IA5 International Alphabet 5 lw(30p) | lw(120p) . IP Interpersonal lw(30p) | lw(120p) . IPM Interpersonal Messaging lw(30p) | lw(120p) . MD Management Domain lw(30p) | lw(120p) . MHS Message Handling System lw(30p) | lw(120p) . MS Message Store lw(30p) | lw(120p) . MT Message Transfer lw(30p) | lw(120p) . MTA Message Transfer Agent lw(30p) | lw(120p) . MTS Message Tranfer System lw(30p) | lw(120p) . N/A Not Applicable lw(30p) | lw(120p) . O/R Originator/Recipient lw(30p) | lw(120p) . PD Physical Delivery lw(30p) | lw(120p) . PDN Public Data Network lw(30p) | lw(120p) . PDS Physical Delivery System lw(30p) | lw(120p) . PRMS Private Management Domain lw(30p) | lw(120p) . TTXAU Teletex Access Unit lw(30p) | lw(120p) . 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. |
||
|
Table [T2.420], p. |
||
|
22 Fascicle II.6 -- Rec. F.420 |
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.1 |
Telex terminals Telex terminals shall conform to the relevant technical Recommendations, and be based on the relevant service Recommendations. |
|
|
B.2.2 |
Teletex 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.3 |
Facsimile terminals Group 3 and Group 4 facsimile terminals should have access to the IPM service. Note -- Access procedures are for further study. |
|
|
B.2.4 |
Videotex 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.5 |
IA5 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:
Fascicle II.6 -- Rec. F.420 23
|
24 |
1) provide 2) make 3) use 4) use These terminals Fascicle |
provide the capabilities to subscribers of the basic features defined in § 2; make use of the IPM protocol specified in Recommendation X.420; use the submission and delivery protocol specified in Recommendation X.419; use the remote operation procedures specified in Recommendation X.419. terminals shall be able to handle at least one EIT as defined in Recommendation X.408 (e.g., IA5, teletex, etc.). II.6 -- Rec. F.420 |
ANNEX C
(to Recommendation F.420)
IPM service elements from 1984 X.400 Recommendations
H.T. [T3.420]
center box; cw(108p) | cw(30p) | cw(30p) sw(30p) sw(30p) , ^ | c | c s s ^ | ^ | c | c | l. Element of service Classification Basic Optional
Origination Reception Contractual _ lw(108p) | cw(30p) | lw(30p) | lw(30p) | lw(30p) . Access management X
lw(108p) | cw(30p) | cw(30p) | cw(30p) | lw(30p) . Alternate recipient allowed A A lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
{ Alternate recipient assignment
} A lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Authorizing users indication A E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Auto-fowarded indication A E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
{ Blind copy recipient indication
} A E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
|
{ Body part encryption indication } A E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Content type indication |
X |
lw(108p) | cw(30p) | |
cw(30p) | cw(30p) | cw(30p) . Conversion prohibition E E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Converted indication X lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Cross referencing indication A E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Deferred delivery E N/A lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
|
{ Deferred delivery cancellation } A N/A lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Delivery notification |
E |
N/A lw(108p) | cw(30p) | cw(30p) | |
||
|
cw(30p) | cw(30p) . { Delivery time stamp indication } X lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Disclosure of other recipients } A E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Expiry date indication |
A E lw(108p) | cw(30p) | |
cw(30p) | cw(30p) | cw(30p) . Explicit conversion A N/A lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
{ Fowarded IP-message indication
} A E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Grade of delivery selection E E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Hold for delivery A lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Implicit conversion A lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Importance indication A E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . IP-message identification X lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Message identification X lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Multi-destination delivery E N/A lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Multi-part body A E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Non-delivery notification X lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Non-receipt notification A A lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Obsoleting indication A E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
|
{ Original encoded information types indication } X lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Originator indication |
E |
E |
lw(108p) | cw(30p) | cw(30p) | |
|||
|
cw(30p) | cw(30p) . { Prevention of non-delivery notification } A N/A lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Primary and copy recipients indication |
} E E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Probe A N/A lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Receipt notification A A lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
|
{ Registered encoded information types } X lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Reply request indication |
A |
E |
lw(108p) | cw(30p) | |
|||
|
cw(30p) | cw(30p) | cw(30p) . { Replying IP-message indication } E E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Return of contents A |
N/A |
lw(108p) |
| cw(30p) | cw(30p) | |
cw(30p) | cw(30p) . Sensitivity indication A E lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Subject indication E E
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
{ Submission time stamp indication
|
} |
X lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Typed body |
X |
_ |
_ |
|||
|
Fascicle |
Table II.6 -- Rec. F.420 25 |
Table [T3.420], p. |
MESSAGE HANDLING SERVICES:
INTERCOMMUNICATION BETWEEN THE IPM SERVICE
AND THE TELEX SERVICE
The establishment in various countries of message handling service 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 arrangements 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, T and U-series Recommendations cover relevant aspects of systems used for the provision of messaging services;
(i) that Recommendations F.60 and F.69 define the service requirements for the telex service;
(j) that Recommendation F.72 defines international telex store-and-forward;
(k) that the U-series Recommendations define the technical requirements for the telex service;
(l) that Recommendation U.204 defines the technical requirements for the intercommunication between the IPM service and the telex service;
unanimously declares
that operational procedures for intercommunication between the public interpersonal messaging service and the telex service shall be in accordance with this Recommendation.
CONTENTS
1 Scope
This Recommendation is the same as Recommendation F.75 of which only the title appears in Fascicle | I.4.
26 Fascicle II.6 -- Rec. F.421
2 Introduction
3 Service outline
Fascicle II.6 -- Rec. F.421 27
|
4 |
Operational procedures 4.1 IPM service to telex service direction 4.2 Telex service to IPM service direction 4.3 Construction of the IP-message |
|
Annex A Annex B Annex C Annex D |
-- -- -- -- |
Abbreviations Actions to be taken by the PTLXAU/examples IPM message to telex Telex message to IPM |
1.1 This Recommendation describes the general, operational and service procedures for the provision of intercommunication between the public interpersonal messaging service and the telex service.
1.2 The intercommunication is based on store-and-forward principles which allow users of one service to exchange messages with the users of the other service.
The IPM service is a messaging service which may be provided on a variety of networks and allows several forms of addresses, whereas the telex service provides direct connection between subscribers in the telex network.
Therefore, to match dissimilar characteristics of the two services, it is necessary to provide intercommunication via a public telex access unit (PTLXAU). In both IPM service to telex service, and telex service to IPM service directions, the complete message is deposited in the PTLXAU for onward transmission.
In general the selection procedures for the telex subscriber will be two-stage; however, where the destination IPM service user is assigned a numeric address that is part of the national telex numbering plan of the destination country, one-stage selection procedures may be used.
3.1 Communication between subscribers of the telex service and the IPM service is on store-and-forward basis; thus conversational mode interworking between users is not applicable.
3.2 Public access to the IPM service for telex subscribers and delivery of messages to telex subscribers from IPM service users is provided by means of a PTLXAU.
3.3 The PTLXAU belongs to the IPM service.
3.4 In the IPM service to telex service direction, the IPM service retains the responsibility for the message until delivery to the telex subscriber has been completed.
3.5 In the telex service to IPM service direction, the IPM service is responsible for the delivery of the message to the IPM service user, once the input is completed under normal conditions.
3.6 In both IPM service to telex service direction and telex service to IPM service direction, the international connection should be via the international telex network, as shown in Figure 1/F.421.
28 Fascicle II.6 -- Rec. F.421
Figure 1/F.421, p. Fascicle II.6 -- Rec. F.421 29
3.7 Where two Administrations offer an IPM service, the international boundary may be placed within the IPM service by bilateral agreement. In this configuration, however, international telex connections should continue to be established via the international telex network.
4.1 IPM service to telex service direction
4.1.1 Messages from an IPM service user to a telex subscriber are sent as normal IP-message with the appropriate IPM elements of service, in accordance with Recommendation F.420.
4.1.2 When a message is received by the PTLXAU, the message content will be converted into the format and character repertoire defined for the telex service. This may result in loss of information if the IPM service user does not conform to these defined rules.
Note -- The conversion process may take place in the message transfer system (MTS) associated with the PTLXAU.
4.1.3 The PTLXAU shall be responsible for the action to be taken for IPM elements of service received in accordance with Recommendation F.420. Annex B shows examples of IPM elements of service together with proposed actions to be taken by the PTLXAU.
4.1.4 Call establishment by and delivery of the message to the telex subscriber should be in accordance with Recommendations F.72 and U.204.
4.1.5 The IP-message sent to the called telex subscriber shall be preceded by a PTLXAU identification. The content of this identification is a national matter but should include the service code ``CI'', the code expression ``IPM'', and the telex network identification code in accordance with Recommendation F.69, e.g. ``CI | (raIPM | (raCH''.
4.1.6 A general layout of an IP-message delivered to the telex service is shown in Annex C.
4.1.7 The elements of service related to the IP-message heading shall be converted into printable text. The language of this text is a national matter. The PTLXAU shall transmit the originator O/R address to the called telex subscriber in the form necessary for recall, in accordance with the indications of Table 2/F.421 (see example in Annex C).
4.1.8 In order to help the telex recipients to recall the originator, the PTLXAU could transmit, as the first element of the message heading, some information as guidance. The contents of this field is a national matter, but when used should be called ``FOR RECALL'' (see Annex C).
4.1.9 Upon delivery of the message to the telex subscriber, a delivery notification should be sent back to the originating IPM service user if requested. In the event of non-delivery of the message to the telex subscriber, a non-delivery notification shall be sent back to the IPM service user (unless the IPM user has requested prevention of non-delivery notification).
4.2 Telex service to IPM service direction
In this direction, Administrations may implement either or both one-stage and two-stage call set-up procedures.
4.2.1 One-stage selection
4.2.1.1 Where one-stage call set-up procedures are used, the number assigned to a user in the IPM service must appear to be part of the national telex numbering plan.
4.2.1.2 The length of the number assigned to the IPM service user shall be in accordance with the relevant U-series signalling Recommendations. 4.2.1.3 The procedures for message transfer within the IPM service, e.g. mapping of the assigned number to an O/R address, are a national matter and not covered by this Recommendation.
4.2.1.4 The call shall be established using normal telex call set-up procedures.
30 Fascicle II.6 -- Rec. F.421
4.2.1.5 The telex number received by the PTLXAU from the telex network shall be verified by the IPM service as being proper to a registered IPM service user. If the verification fails:
a) where the PTLXAU is provided by the Administration which also provides all or part of the telex network, the service signal NP may be returned;
b) where the PTLXAU is not provided by the Administration which also provides all or part of the telex network, the procedures to be applied shall be in accordance with Recommendation F.74.
4.2.1.6 The answerback returned to the calling telex subscriber at call establishment and also during the text input stage shall contain the national telex number assigned to the IPM service user.
4.2.1.7 The call shall be cleared using normal telex call clearing procedures.
4.2.1.8 When the message cannot be delivered to the IPM service user, a non-delivery notification shall be returned to the telex subscriber. The procedures for establishing the calling telex address are specified in Recommendation U.204.
4.2.1.9 The non-delivery notification returned to the originating telex subscriber should contain a reference consisting of the telex address of the IPM service user and time and date of submission to the PTLXAU.
4.2.1.10 The action to be taken when a non-delivery notification cannot be returned to the calling telex subscriber is for further study.
4.2.1.11 The format of notifications and the procedures for their delivery should be in accordance with Recommendation U.204.
4.2.1.12 The use of IPM elements of service by the telex subscriber is for further study.
4.2.2 Two-stage selection
4.2.2.1 The telex subscribers shall use normal telex call procedures to access the PTLXAU which is allocated a telex number that is part of the national telex numbering plan of the country in which the PTLXAU is located.
4.2.2.2 Procedures for access to the PTLXAU shall follow Recommendation U.204.
4.2.2.3 A service identifier may be input before the O/R address(es) of the first message. If may allow the Administrations to provide intercommunication with several services through only one PTLXAU (see Tables 1/F.421, 3/F.421 and Annex D).
4.2.2.4 The PTLXAU shall be able to accommodate the following O/R address forms:
-- Mnemonic O/R address;
-- Terminal O/R address;
-- Numeric O/R address;
as specified in Recommendation F.401. The O/R address should be input in accordance with the requirements of Recommendation U.204.
It is the responsibility of the originating telex subscriber to be aware of the required attributes specific to the domain of the called IPM service user. Each attribute of the O/R address shall be identified and delimited. The complete O/R address shall be terminated with an end-of-address (EOA) indicator.
The structure of the service identifier and the address input is shown in Table 1/F.421.
Each attribute of the address structure shall be contained in one line.
Each address attribute and the service shall be identified by a code expression according to Tables 2/F.421 and 3/F.421.
4.2.2.5 Under normal conditions, the message input will be terminated by an end of message (EOM) or and end of transmission (EOT) signal. In case where no EOM or EOT signal is received, the PTLXAU shall forward any input received prior to call disconnect with the added text ``THIS MESSAGE MAY BE INCOMPLETE''. Annex D shows a general layout applicable in case of submission of message(s) to the PTLXAU by the telex subscriber.
4.2.2.6 Except as defined in 4.2.2.5 above, the action to be taken when abnormal conditions are encountered during message input shall be in accordance with Recommendation U.204.
Fascicle II.6 -- Rec. F.421 31
H.T. [T1.421]
TABLE 1/F.421
Telex service to IPM service address structure
|
{ Address attribute identifier <value> } cw(120p) . cw(120p) . cw(120p) . lw(120p) . { Address attribute identifier <value> } lw(120p) . End of single O/R address (+) lw(120p) . [Next O/R address(es)] lw(120p) . { [Request for IPM elements of service] } lw(120p) . End of address(es) (BT) [Request for delivery notification] Note -- [ ] indicates optional attributes. |
|
Tableau 1/F.421 [T1.421], p.6 |
|||
|
H.T. [T2.421] TABLE 2/F.421 Code expressions for address attribute identifiers |
center box; cw(90p) | cw(60p) . Address attribute Format _ lw(90p) | lw(60p) . Country name CTN > <value> lw(90p) | lw(60p) . Administration domain name ADM > <value> lw(90p) | lw(60p) . Private domain name PRI > <value> lw(90p) | lw(60p) . Organization name ORG > <value> lw(90p) | lw(60p) . Organization unit name(s) OUN > <value> lw(90p) | lw(60p) . Personal name -- Surname SUR > <value> lw(90p) | lw(60p) . -- Given name GIV > <value> lw(90p) | lw(60p) . -- Initials INI > <value> lw(90p) | lw(60p) . -- Generation qualifier GEN > <value> lw(90p) | lw(60p) . -- Common name COM > <value> lw(90p) | lw(60p) . Numeric user identifier NUS > <value> lw(90p) | lw(60p) .
{ Terminal type and network address for telex
|
} TLX > <value> lw(90p) | lw(60p) . for teletex TTX > <value> lw(90p) | lw(60p) . for facsimile for videotex VTX > <value> lw(90p) | lw(60p) . Domain defined attribute(s) lw(90p) | lw(60p) . -- Type . -- Value DDV > <value> Note 1 -- The symbol > equals a space. Note 2 -- Allowed attribute values are specified in Recommendation F.401. |
FAX > <value> lw(90p) | lw(60p) . DDT > <value> lw(90p) | lw(60p) |
|
|
Tableau 2/F.421 [T2.421], p.7 |
||
|
32 Fascicle II.6 -- Rec. F.421 |
H.T. [T3.421]
TABLE 3/F.421
Code expression for the service identifier
|
center box; cw(90p) | cw(36p) . Service { Interpersonal messaging service } IPM _ |
Format _ lw(90p) | cw(36p) . |
Tableau 3/F.421 [T3.421], p.8 |
4.2.2.7 During the input stage of the address, the PTLXAU shall validate, as a minimum, the following O/R address formats, as specified by the domain:
|
-- -- -- -- |
The existence of mandatory attributes. The existence of non-allowed attributes. The minimum and maximum allowed number of characters in each attribute. The existence of non-allowed characters in an attribute. |
Where applicable, the existence/non-existence of non-significant character(s) preceding or following the attribute values shall not prevent validation.
Despite the acceptance by the PTLXAU of the submitted O/R address, there is no guarantee that the message will be subsequently delivered and, in this case, the originating telex subscriber will be charged for a message which was not delivered. It is therefore desirable that a means of verifying the existence of the O/R address be provided and the method of achieving this is left for further study.
4.2.2.8 The service principles for delivery and non-delivery notifications should be in accordance with Recommendation F.72. The format of the notification messages is defined in Recommendation U.204. Delivery notification may be requested as a code expression following the end of address signal.
|
4.3 |
Construction of the IP-message The message received by the PTLXAU shall be delivered to the IPM user(s) in accordance with following rules. |
|
|
4.3.1 |
P2 body part The received message, excluding the recipient address(es), shall form the body of the IP-message. All the received characters shall be |
delivered except the WRU signals.
|
4.3.2 |
Recipient O/R address All recognized O/R addresses shall be assumed as primary recipients. By default, these primary recipients will not be disclosed to each |
|
|
other. 4.3.3 |
Originator indication |
|
|
The calling telex subscriber address shall be converted by the PTLXAU into the format of a terminal O/R address and shall be placed in the |
originator indication element of service field.
4.3.4 Subject indication
The PTLXAU shall generate the element of service which will cause TELEX to appear in the subject indication element of service field.
4.3.5 IP-message identification
Fascicle II.6 -- Rec. F.421 33
The content of the message reference information returned to the calling telex subscriber shall also be used as the unique identifier in the IP-message identification element of service field.
34 Fascicle II.6 -- Rec. F.421
|
4.3.6 |
The |
Grade of delivery selection PTLXAU shall set the grade of delivery selection element of service to the value URGENT. |
|||
|
4.3.7 |
Conversion prohibition in case of loss of information |
||||
|
The |
use of the element of service -- conversion prohibition in case of loss of information -- is for further study. |
||||
|
4.3.8 |
Disclosure of other recipients |
This element of service shall be set by the PTLXAU when the originating telex subscriber requests the disclosure of other recipients. The procedures for requesting this disclosure are defined in Recommendation U.204.
4.3.9 Deferred delivery
This element of service shall be set by the PTLXAU when the originating telex subscriber requests deferred delivery of his message. The procedures for requesting deferred delivery are defined in Recommendation U.204.
Note -- The code expressions to be used for the selection of the elements of service described in §§ 4.3.8 and 4.3.9 by the telex subscriber, are shown in Table 4/F.421.
H.T. [T4.421]
TABLE 4/F.421
Code expressions for the use of IPM elements of service
{ Disclosure of other recipients
} DUR lw(78p) | lw(48p) . Deferred delivery DEF > <value> lw(78p) | lw(48p) . Delivery notification BT, ACK | ua)
a) The request for delivery notification may be given together with the code for end of address(es) (BT) if delivery notification is required.
Note -- The symbol > equals a space.
|
4.3.10 |
Other elements of service |
Table 4/F.421 [T4.421], p. |
Elements of service of the basic IPM service other than those specified above shall be set by the PTLXAU in accordance with the requirements of the domain to which it belongs.
BLANC
Fascicle II.6 -- Rec. F.421 35
ANNEX A
(to Recommendation F.421)
Abbreviations
H.T. [T5.421]
|
center box; lw(30p) | lw(120p) . A/B Answerback lw(30p) | lw(120p) . ACK { Request for Delivery Notification Signal } lw(30p) | lw(120p) . ADM { Administration Management Domain } lw(30p) | lw(120p) . BT End of Address(es) Signal lw(30p) | lw(120p) . CI Conversation Impossible lw(30p) |
| lw(120p) . |
|
COM Common Name lw(30p) | lw(120p) . CTN Country Name lw(30p) | lw(120p) . DDT { Domain Defined Attribute Type |
} lw(30p) | lw(120p) . DDV { Domain Defined Attribute Value
} lw(30p) | lw(120p) . DEF Deferred Delivery lw(30p) | lw(120p) . DUR { Disclosure of other Recipients
} lw(30p) | lw(120p) . EOA End of Address lw(30p) | lw(120p) . EOM End of Message lw(30p) | lw(120p) . EOT End of Transacton lw(30p) | lw(120p) . FAX Facsimile lw(30p) | lw(120p) . GEN Generation Qualifier lw(30p) | lw(120p) . GIV Given Name lw(30p) | lw(120p) . I Initials lw(30p) | lw(120p) . IP Interpersonal lw(30p) | lw(120p) . IPM Interpersonal Messaging lw(30p) | lw(120p) . MT Message Transfer lw(30p) | lw(120p) . MTS Message Transfer System lw(30p) | lw(120p) . NP { The called party is not, or no longer, a subscriber
} lw(30p) | lw(120p) . NUS Numeric User Identifier lw(30p) | lw(120p) . O/R Originator/Recipient lw(30p) | lw(120p) . ORG Organization Name lw(30p) | lw(120p) . OUN Organization Unit Name(s) lw(30p) | lw(120p) . P2 IPM Protocol lw(30p) | lw(120p) . PRI Private Domain Name lw(30p) | lw(120p) . PTLXAU Public Telex Access Unit lw(30p) | lw(120p) . SUR Surname lw(30p) | lw(120p) . TID Terminal Identifier lw(30p) | lw(120p) . TLX Telex lw(30p) | lw(120p) . TTX Teletex lw(30p) | lw(120p) . UTC Universal Coordinated Time lw(30p) | lw(120p) . VTX Videotex lw(30p) | lw(120p) . WRU Who Are You lw(30p) | lw(120p) . + { End of Single O/R Address signal
} lw(30p) | lw(120p) . > Space
Note 1 -- For a glossary of terms see Annex A to Recommendation F.400.
|
Note 2 -- For references see Recommendation F.400. |
||
|
Table [T5.421], p. |
||
|
36 Fascicle II.6 -- Rec. F.421 |
ANNEX B
(to Recommendation F.421)
Actions to be taken by the PTLXAU/examples
Basic IPM elements of service and essential optional IPM user facilities which have to be processed by the PTLXAU in the case where a message is sent from the IPM service to the telex service direction (Table B-1/F.421).
H.T. [1T6.421]
TABLE B-1/F.421
center box; cw(36p) | cw(68p) | cw(62p) | cw(62p) .
{ Reference Rec. F.400 Annex B
} Elements of service Action to be taken Examples _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.5 Authorizing users indication Display in message heading Authority: > <value> _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.6 Auto-forwarded indication Ignore _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.8 { Blind copy recipient indication
|
} } } } |
{ Display the O/R descriptor information of the blind copy recipient(s) BCC > <value> _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.9 { Body part encryption indication { The PTLXAU shall send a non-delivery notification to the originator _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.12 Content type indication { National matter for content |
types different than P2 |
||
|
} |
_ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.13 Conversion prohibition { If ITA2, ignore. |
Otherwise the PTLXAU generates a |
non-delivery notificaton
} _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.15 Converted indication Ignore _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.18 Cross referencing indication Display in message heading Reference > <value> _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.21 Delivery notification { The PTLXAU shall send a delivery notification to the originator
|
} } } |
_ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.22 { Delivery time stamp indication Ignore _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.25 { Disclosure of other recipients Disclose all recipients _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.26 { DL expansion history |
history indication |
||
|
} |
Ignore _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.29 Expiry date indication Display |
in message heading { Message invalid |
after: > <value>
} _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.31 { Forwarded IP-message indication
} { the PTLXAU shall build a message heading for each IP-message contained in the body part
} _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.32 Grade of delivery selection National matter _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.34 Implicit conversion { Convert to telex according to Rec. X.408
} _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.35 Importance indication Display in message heading { Message importance: > <value>
} _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.37 IP-message identification display in message heading Message reference > <value> _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.38 Language indication Ignore _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.39 Latest delivery designation National matter _
Table B-1/F.421 [1T6.421], p.
Fascicle II.6 -- Rec. F.421 37
H.T. [2T6.421]
TABLE B-1/F.421 (cont.)
center box; cw(36p) | cw(68p) | cw(62p) | cw(62p) .
{ References Rec. F.400 Annex B
} Elements of message Action to be taken Examples _ cw(36p) | lw(68p) | lw(62p) | cw(62p) . B.41 Message identification Ignore
_ cw(36p) | lw(68p) | lw(62p) | cw(62p) . B.45 Multi-destination delivery { Deliver the message to all recipients
} _ cw(36p) | lw(68p) | lw(62p) | cw(62p) . B.46 Multi-part body { Messages containing not supported body parts are not delivered. Send back a non-delivery notification to the originator
} _ cw(36p) | lw(68p) | lw(62p) | cw(62p) . B.47 Non-delivery notification { The PTLXAU shall generate a delivery report
} _ cw(36p) | lw(68p) | lw(62p) | cw(62p) . B.48 { Non-receipt notification request
|
} Ignore _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.52 Obsoleting indication lw(62p) . B.54 { Original encoded information types indication } Ignore _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.55 Originator indication |
Obsoletes: > <value> _ cw(36p) | lw(68p) | lw(62p) | Ignore _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.56 { |
|
|
Originator request alternate recipient |
} National matter _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.62 { Primary and copy recipients indication
} { Display the O/R descriptor information of the recipient(s) in the message heading
|
} { TO: > <value> TO: > <value> CC: > <value> CC: > <value> } _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.63 Probe National matter _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.67 |
{ Receipt notification |
|
|
request indication } Ignore _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.72 Reply request indication Display in message heading |
{ Reply > requested > |
|
|
by > sender } _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.73 { Replying IP--message indication |
} Display in message heading Reply to message: > <value> _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.80 Sensibility indication { Display in message heading just above text of body
} _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.88 Subject indication { Display in message heading just above text of body
} Subject: > <value> _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.89 Subsmission time stamp Display in message heading Submitted: > <value> > UTC _ cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.90 Typed body Ignore
|
Note -- The symbol > equals a space. |
||
|
Table B-1/F.421 [2T6.421], p. |
||
|
38 Fascicle II.6 -- Rec. F.421 |
ANNEX C
(to Recommendation F.421)
IPM message to telex
|
General layout of a message originated by an IPM service user and delivered by the PTLXAU to a telex subscriber. |
||
|
Table, p. |
||
|
Display of the originator O/R address related information to the telex user in the message heading: a) Two-stage selection: FROM: | (raGIV | (rafrancois FROM: | (ra SUR | (ramaurer FROM: | (ra ORG | (raswissñptt FROM: | (ra ADM | (raarcom400 FROM: | (ra CTN | (rach b) One-stage selection | FROM: | (ra(F.74 A/B) BLANC Fascicle II.6 -- Rec. F.421 |
39 |
ANNEX D
(to Recommendation F.421)
Telex message to IPM
(Two-stage selection)
General layout of a message originated by a telex subscriber using the two-stage selection, submitted to the PTLXAU for delivery to the IPM service.
|
Table, p. |
||
|
BLANC 40 Fascicle |
II.6 -- Rec. F.421 |
MESSAGE HANDLING SERVICES:
INTERCOMMUNICATION BETWEEN THE IPM SERVICE
AND THE TELETEX 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 arrangements 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;
(i) that the F.200 series and appropriate T-series Recommendations define, respectively, the service and technical requirements for the teletex service;
(j) that Recommendation T.330 defines the technical requirements of the intercommunication between the IPM service and the teletex service,
unanimously declares the view
that where Administrations provide international intercommunication between the public interpersonal message service and the teletex service the operational and service procedures shall be in accordance with this Recommendation.
TABLE OF CONTENTS
1 Purpose and scope
2 Description of intercommunication
3 Requirements for intercommunication
Fascicle II.6 -- Rec. F.422 41
4 Elements of service
5 Quality of service
Annex A -- Abbreviations
42 Fascicle II.6 -- Rec. F.422
1.1 This Recommendation defines the intercommunication between the public IPM service and the teletex service (for teletex users not registered in the IPM service) and further defines the capability of IPM users to direct messages to teletex users, and teletex users to direct messages to IPM users.
The technical requirements for this intercommunication are specified in Recommendation T.330.
1.2 Teletex users who are registered users of the IPM service are not covered by this Recommendation (see Recommendation F.420).
1.3 For intercommunication the following principles apply:
a) The basic intercommunication function is to allow the exchange of messages from users of one service to users of the other service. The IPM elements of service available to users in each service to intercommunicate with each other are those listed in § 4.
b) Where two Administrations have an IPM service, the preferred method of international intercommunication is through the use of these services.
c) For those Administrations which do not provide an IPM service, in these cases, international connections between the teletex terminal equipment and the public teletex access unit (PTTXAU) should use the international data transmission facilities used for the teletex service.
Figure 1/F.422 shows the environment for the service intercommunication described in this Recommendation.
2.1 Responsibility boundaries
2.1.1 IPM service to teletex service
The PTTXAU retains the responsibility of the message originated by an IPM user until the teletex terminal equipment positively acknowledges the end of the document (see Recommendation T.62).
2.1.2 Teletex service to IPM service
The PTTXAU assumes responsibility for a teletex document when it acknowledges the end of the document. The responsibility of the PTTXAU within the MHS is defined in Recommendation F.420.
Identification of the calling teletex terminal is a national matter.
|
2.1.3 All notifications except receipt notifications are the responsibility of the PTTXAU. |
|||
|
Figure Fascicle II.6 -- Rec. F.422 43 |
Figure 1/F.422, p. |
2.2 Location of the PTTXAU
2.2.1 For international intercommunication between the IPM service and the teletex service, the PTTXAU may be located either in the country of origin or the destination country as shown in Figure 2/F.422. If an Administration provides both the IPM service and the teletex service (with a PTTXAU) the international link may be via the MHS.
Figure 2/F.422, p. 3 Requirements for intercommunication
3.1 The intercommunication between IPM service and teletex service and vice versa is based on store-and-forward principles. There is neither interactive nor direct user-to-user communication.
|
3.2 |
Intercommunication from IPM service to teletex service 3.2.1 When sending an IPM user originated message to a teletex terminal equipment the following conditions may occur: a) the message can be delivered without conversion; b) the message can be delivered with conversion; c) message delivery will not occur because of conversion prohibition; d) conversion should not be carried out since loss of information beyond that specified in Recommendation X.408 will occur. 3.2.2 Recommendation F.420 applies between the IPM UA and the PTTXAU. 3.2.3 The terminal O/R address of the teletex user as defined in Recommendation F.401 will be used to route the message to the teletex |
terminal via the appropriate PTTXAU.
3.2.4 The PTTXAU will format IP-messages into documents suitable for delivery to teletex terminal equipment in accordance with Recommendation F.200.
|
3.2.5 The call identification line (CIL) will contain sufficient information to advise the teletex user of the network address of the PTTXAU. 3.2.6 The header of the message will contain sufficient information in human readable form regarding the originating IPM user. |
||
|
3.3 |
Intercommunication from teletex service to IPM service 3.3.1 The intercommunication between teletex terminal equipment and the PTTXAU is according to Recommendation F.200. The |
submission will consist of a document with a formatted header. This header will contain the O/R address(es) and control information related to the IPM elements of service set as specified in Table 1/F.422, and selected by the originator. The format rules are specified in Recommendation T.330.
44 Fascicle II.6 -- Rec. F.422
3.3.2 This formatted header is mapped by the PTTXAU into the envelope and heading necessary for delivering the IP-message to the recipient(s) via the MT service. This process is depicted in Figure 3/F.422. The submission will consist of a heading and body which are mapped into an IPM envelope, heading, and a body.
Figure 3/F.422, p. 4 Elements of service
4.1 The elements of service applicable to IPM/TTX service intercommunication are identified in Table 1/F.422. These are the only elements of service that will be supported in this intercommunication.
5.1 Provision of intercommunication should maintain as much as possible the quality of each service.
5.2 The PTTXAU shall be capable of supporting the basic requirements of the teletex terminal equipment as defined in Recommendation F.200. The support of standardized optional user facilities is for further study.
5.3 The PTTXAU will recover from an intercommunication failure with teletex terminal equipment using the document retransmission method.
5.4 If non-delivery notifications cannot be delivered via the normal route it is the responsibility of the Administration providing the PTTXAU to advise the originator via other suitable means.
BLANC
Fascicle II.6 -- Rec. F.422 45
H.T. [T1.422]
TABLE 1/F.422
Elements of service
center box; cw(30p) | cw(108p) | cw(30p) | cw(30p) | cw(30p) .
{ Reference Rec. F.400 Annex B
} Elements of service { Message submission from TTX to PTTXAU
} { Message delivery to TTX from PTTXAU
} { Information generated by PTTXAU
} _ cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.5 Autorizing users indication X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.6 Auto-forwarded indication X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.8 { Blind copy recipient indication
} X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.9 { Body part encryption indication
} X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.12 Content type indication X X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.13 Conversion prohibition X X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.15 Converted indication X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.18 Cross referencing indication X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.21 Delivery notification X N/A X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.22 { Delivery time stamp indication
} X X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.25 { Disclosure of other recipients
} X X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.26 { DL expansion history indication
} X X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.29 Expiry date indication X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.31 { Forwarded IP-message indication
} X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.32 Grade of delivery selection X X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.34 Implicit conversion N/A X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.35 Importance indication X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.37 IP-message identification X X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.38 Language indication X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.39 Latest delivery indication N/A X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.41 Message identification X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.45 Multi-destination delivery X N/A cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.46 Multi-part body X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.47 Non-delivery notification N/A X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.48 { Non-receipt notification request
|
} X N/A cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.52 Obsoleting indication cw(30p) | cw(30p) . B.54 { Original encoded information types indication } X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.55 Originator indication |
X X |
cw(30p) | lw(108p) | cw(30p) | cw(30p) | lw(108p) | cw(30p) | |
||
|
cw(30p) | cw(30p) . B.56 { Originator request alternate recipient |
} X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.62 { Primary and copy recipients indication
} X X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.72 Reply request indication X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.73 { Replying IP-message indication
} X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.80 Sensitivity indication X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.88 Subject indication X X cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.89 { Submission time stamp indication
} X X
|
Note -- Definitions of the Elements of Service are contained in Recommendation F.400, Annex B. |
||
|
Tableau 1/F.422 [T1.422], p.18 |
||
|
46 Fascicle II.6 -- Rec. F.422 |
ANNEX A
(to Recommendation F.422)
Abbreviations
H.T. [T2.422]
center box;
lw(30p) | lw(120p) . AU Access Unit lw(30p) | lw(120p) . CIL Call Identification Line lw(30p) | lw(120p) . DL Distribution List lw(30p) | lw(120p) . IPM Interpersonal Messaging lw(30p) | lw(120p) . MHS Message Handling System lw(30p) | lw(120p) . MT Message Transfer lw(30p) | lw(120p) . MTS Message Transfer System lw(30p) | lw(120p) . N/A Not Applicable lw(30p) | lw(120p) . O/R Originator/Recipient lw(30p) | lw(120p) . PTTXAU Public Teletex Access Unit lw(30p) | lw(120p) . TTX Teletex lw(30p) | lw(120p) . 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. |
||
|
Table Fascicle II.6 -- Rec. F.422 47 |
Table [T2.422], p. |
MONTAGE: PAGE 146 = PAGE BLANCHE 48 Fascicle II.6 -- Rec. F.422
Fascicle II.6 -- Rec. F.422 49