5i' 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 han- dling 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 responsibili- ties 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 per- sonal computers with the ability to access message handling sys- tems; (g) that several F-series Recommendations describe public mes- sage 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 ser- vices 3 Types of body parts .bp 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 notifica- tions 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 require- ments 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 interper- sonal 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 sub- scribers 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 Recommenda- tions. The Interpersonal Messaging (IPM) Service enables subscribers to request a variety of features to be performed during the han- dling 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 S 2. Requirements for intercommunication between subscribers are described in SS 3 and 4. Section 5 describes naming and addressing, while SS 6, 7 and 8 describe the operation of the service, quality of service, tariff and accounting principles. Network requirements are given in S 9. The provision of subscriber information is in S 10, and S 11 con- tains 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. Adminis- trations 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 func- tionality that were not present in 1984. Most of these have been classified as additional, meaning that they do not have to be sup- ported, 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 ser- vice. In both cases, to allow for 1984 implementations to be used for the provision of public IPM service as described in this Recom- mendation, a grace period of 8 years is provided for Administra- tions 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 Recommenda- tions have been enhanced and postal O/R addresses have been added. The name forms and the mandatory components of the 1984 Recommenda- tions have their equivalence in the new framework and are aligned in principle. 1.2.4 Interworking 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 S 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 ser- vices. 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 reci- pient. 2.1.12 Where a sender and recipient have different and con- flicting requirements, the sender's requirements shall take pre- cedence (e.g., body type conversion or redirection control). 2.2 IPM service features 2.2.1 Introduction Recommendation F.400, S 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.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 reci- pient 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 meaning- ful communication, a receiving user may specify the encoded infor- mation 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 per- spectives. Note - With the access protocol described in Recommendation T.330, teletex terminals are able to make use of the basic IPM ser- vice 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 sub- scribers 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 sub- ject of all unread messages or by computer-initiated voice indication). The MHS may provide local database controls to help the sub- scriber find previously received and filed IP-messages (for exam- ple, to find the message from Mr. Jones delivered sometime in August on the subject of teleconferencing ). A subscriber on vaca- tion 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 coopera- tion with other subscribers. Thus they do not impact the communica- tion 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 receiv- ing 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 respon- sibility for a message is turned over to the receiving UA/MS after successful delivery. If the UA or MS is provided by an Administra- tion, 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 docu- ment 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 conver- sion 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 responsi- bility for the actions of the PRMD which are related to the interaction. In addition to ensuring that the PRMD properly pro- vides the MT service, the ADMD is responsible for ensuring that the accounting, logging, quality of service and other related opera- tions of the PRMD are correctly performed. An ADMD acts as the nam- ing 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, S 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, S 14. 2.6 Security Administrations may optionally provide security mechanisms as outlined in Recommendation F.400, S 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, S 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 send- ing of a message from an IPM user to a recipient via physical means, such as the traditional postal service. To invoke the capa- bility, 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, S 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 conver- sion 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 per- formed. Users also have the ability to request that conversion not be performed or that conversion not be performed if loss of infor- mation 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 conver- sion 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, distribu- tion 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 sec- tion. 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 sub- mission 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 notifica- tion 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 fol- lows: - 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 iden- tifying users with terminals belonging to various networks. - Numeric O/R address : Provides a means of iden- tifying users with numeric keypads. - Postal O/R address : Provides a means of identi- fying 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 mes- sages 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 identifica- tion 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 pro- cedures. 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 messag- ing systems to connect to the public IPM service, in order to allow users of these systems to exchange messages. If these interconnec- tions 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 Adminstra- tion 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 S 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.1 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 Recom- mendation. 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 sub- scriber 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 sub- scriber in the form in which the originator has sent it, unless conversion has been performed. For messages delivered to a teletex access unit, Recommenda- tion 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 notifica- tion depend on the action of the recipient. In the case of a mes- sage 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 sys- tem 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 sub- scribers, with regard to non-delivery notifications not being received in due time, as far as public system components are con- cerned. 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, addi- tional functionality should be provided in order to minimize cases of not reading messages within a certain period of time (the defin- ition of this period is for further study). This functionality could be, for example, alert messages sent to an automatic recep- tion 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, S 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, S 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 continu- ously. 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, p.1 H.T. [T1.420] TABLE 1/F.420 _____________________________________________________ { Grade of delivery (of the referred message) } 95% delivered before _____________________________________________________ Urgent 0.75 hours Normal 4 | hours Non-urgent 24 | hours _____________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | Note - Intercommunication with PRMDs is not included in the calcu- lation of the time targets. Tableau 1/F.420 [T1.420], p.2 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. Addi- tional 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. BLANC ANNEX A (to Recommendation F.420) Abbreviations The following abbreviations are used in this Recommendation. H.T. [T2.420] _______________________________________________________________ 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. Table [T2.420], p. ANNEX B (to Recommendation F.420) Subscriber access and terminal requirements B.1 General Various types of terminals may be used for accessing the ser- vice. 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 Recom- mendations, 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 sub- mission 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 sub- set of Recommendation F.300 needs to be considered. B.2.5 IA5 terminals The IA5 terminals are terminals able to send and receive mes- sages 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 possi- bility 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 S 2; 2) make use of the IPM protocol specified in Recommendation X.420; 3) use the submission and delivery protocol speci- fied 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 H.T. [T3.420] ______________________________________________________________________________________ Classification Basic Element of service Optional Origination ______________________________________________________________________________________ Access management X Alternate recipient allowed A A { Alternate recipient assignment } A Authorizing users indication A E Auto-fowarded indication A E { Blind copy recipient indication } A E { Body part encryption indication } A E Content type indication X Conversion prohibition E E Converted indication X Cross referencing indication A E Deferred delivery E N/A { Deferred delivery cancellation } A N/A Delivery notification E N/A { Delivery time stamp indication } X { Disclosure of other recipients } A E Expiry date indication A E Explicit conversion A N/A { Fowarded IP-message indication } A E Grade of delivery selection E E Hold for delivery A Implicit conversion A Importance indication A E IP-message identification X Message identification X Multi-destination delivery E N/A Multi-part body A E Non-delivery notification X Non-receipt notification A A Obsoleting indication A E { Original encoded information types indication } X Originator indication E E { Prevention of non-delivery notification } A N/A { Primary and copy recipients indication } E E Probe A N/A Receipt notification A A { Registered encoded information types } X Reply request indication A E { Replying IP-message indication } E E Return of contents A N/A Sensitivity indication A E Subject indication E E { Submission time stamp indication } X Typed body X ______________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T3.420], p. Recommendation F.421 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 han- dling services. The CCITT, considering (a) the need for public message handling services; (b) the strategic and commercial importance of standardization of message handling services; _________________________ This Recommendation is the same as Recommendation F.75 of which only the title appears in Fascicle | I.4. (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 responsibili- ties 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 per- sonal computers with the ability to access message handling sys- tems; (g) that several F-series Recommendations describe public mes- sage 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 require- ments 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 2 Introduction 3 Service outline 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 - Abbreviations Annex B - Actions to be taken by the PTLXAU/examples Annex C - IPM message to telex Annex D - Telex message to IPM 1 Scope 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 prin- ciples which allow users of one service to exchange messages with the users of the other service. 2 Introduction 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 sub- scribers in the telex network. Therefore, to match dissimilar characteristics of the two ser- vices, 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 pro- cedures may be used. 3 Service outline 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. Figure 1/F.421, p. 3.7 Where two Administrations offer an IPM service, the inter- national boundary may be placed within the IPM service by bilateral agreement. In this configuration, however, international telex con- nections should continue to be established via the international telex network. 4 Operational procedures 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 informa- tion 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 iden- tification is a national matter but should include the service code "CI", the code expression "IPM", and the telex network iden- tification 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 head- ing 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 ori- ginator, 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 mes- sage 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 Recom- mendations. 4.2.1.3 The procedures for message transfer within the IPM ser- vice, 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. 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 Administra- tion which also provides all or part of the telex network, the ser- vice signal NP may be returned; b) where the PTLXAU is not provided by the Administration which also provides all or part of the telex net- work, 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 con- tain 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 sub- scriber is for further study. 4.2.2 Two-stage selection 4.2.2.1 The telex subscribers shall use normal telex call pro- cedures 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 ter- minated 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 gen- eral 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. H.T. [T1.421] TABLE 1/F.421 Telex service to IPM service address structure _______________________________________ Service identifier { Address attribute identifier } { Address attribute identifier } End of single O/R address (+) [Next O/R address(es)] { [Request for IPM elements of service] } 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 _____________________________________________________ Address attribute Format _____________________________________________________ Country name CTN > Administration domain name ADM > Private domain name PRI > Organization name ORG > Organization unit name(s) OUN > Personal name - Surname SUR > - Given name GIV > - Initials INI > - Generation qualifier GEN > - Common name COM > Numeric user identifier NUS > { Terminal type and network address for telex } TLX > for teletex TTX > for facsimile FAX > for videotex VTX > Domain defined attribute(s) - Type DDT > - Value DDV > _____________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - The symbol > equals a space. Note 2 - Allowed attribute values are specified in Recommendation F.401. Tableau 2/F.421 [T2.421], p.7 H.T. [T3.421] TABLE 3/F.421 Code expression for the service identifier __________________________________________ Service Format __________________________________________ { Interpersonal messaging service } IPM __________________________________________ | | | | | | | | | | | | | | | | | | 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 charac- ters 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 subse- quently delivered and, in this case, the originating telex sub- scriber 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 reci- pients. 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 The content of the message reference information returned to the calling telex subscriber shall also be used as the unique iden- tifier in the IP-message identification element of service field. 4.3.6 Grade of delivery selection The 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 mes- sage. 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 SS 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 __________________________________________________ IPM element of service Format __________________________________________________ { Disclosure of other recipients } DUR Deferred delivery DEF > 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. Table 4/F.421 [T4.421], p. 4.3.10 Other elements of service 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 ANNEX A (to Recommendation F.421) Abbreviations H.T. [T5.421] ____________________________________________________________________________________ A/B Answerback ACK { Request for Delivery Notification Signal } ADM { Administration Management Domain } BT End of Address(es) Signal CI Conversation Impossible COM Common Name CTN Country Name DDT { Domain Defined Attribute Type } DDV { Domain Defined Attribute Value } DEF Deferred Delivery DUR { Disclosure of other Recipients } EOA End of Address EOM End of Message EOT End of Transacton FAX Facsimile GEN Generation Qualifier GIV Given Name I Initials IP Interpersonal IPM Interpersonal Messaging MT Message Transfer MTS Message Transfer System NP { The called party is not, or no longer, a subscriber } NUS Numeric User Identifier O/R Originator/Recipient ORG Organization Name OUN Organization Unit Name(s) P2 IPM Protocol PRI Private Domain Name PTLXAU Public Telex Access Unit SUR Surname TID Terminal Identifier TLX Telex TTX Teletex UTC Universal Coordinated Time VTX Videotex WRU Who Are You + { End of Single O/R Address signal } > 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. 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 ___________________________________________________________________________________________________________________________________________________________________ { Reference Rec. F.400 Annex B } Elements of service Action to be taken Examples ___________________________________________________________________________________________________________________________________________________________________ B.5 Authorizing users indication Display in message heading Authority: > ___________________________________________________________________________________________________________________________________________________________________ B.6 Auto-forwarded indication Ignore ___________________________________________________________________________________________________________________________________________________________________ B.8 { Blind copy recipient indication } { Display the O/R descriptor information of the blind copy recipient(s) } BCC > ___________________________________________________________________________________________________________________________________________________________________ B.9 { Body part encryption indication } { The PTLXAU shall send a non-delivery notification to the originator } ___________________________________________________________________________________________________________________________________________________________________ B.12 Content type indication { National matter for content types different than P2 } ___________________________________________________________________________________________________________________________________________________________________ B.13 Conversion prohibition { If ITA2, ignore. Otherwise the PTLXAU generates a non-delivery notificaton } ___________________________________________________________________________________________________________________________________________________________________ B.15 Converted indication Ignore ___________________________________________________________________________________________________________________________________________________________________ B.18 Cross referencing indication Display in message heading Reference > ___________________________________________________________________________________________________________________________________________________________________ B.21 Delivery notification { The PTLXAU shall send a delivery notification to the originator } ___________________________________________________________________________________________________________________________________________________________________ B.22 { Delivery time stamp indication } Ignore ___________________________________________________________________________________________________________________________________________________________________ B.25 { Disclosure of other recipients } Disclose all recipients ___________________________________________________________________________________________________________________________________________________________________ B.26 { DL expansion history indication } Ignore ___________________________________________________________________________________________________________________________________________________________________ B.29 Expiry date indication Display in message heading { Message invalid after: > } ___________________________________________________________________________________________________________________________________________________________________ B.31 { Forwarded IP-message indication } { the PTLXAU shall build a message heading for each IP-message contained in the body part } ___________________________________________________________________________________________________________________________________________________________________ B.32 Grade of delivery selection National matter ___________________________________________________________________________________________________________________________________________________________________ B.34 Implicit conversion { Convert to telex according to Rec. X.408 } ___________________________________________________________________________________________________________________________________________________________________ B.35 Importance indication Display in message heading { Message importance: > } ___________________________________________________________________________________________________________________________________________________________________ B.37 IP-message identification display in message heading Message reference > ___________________________________________________________________________________________________________________________________________________________________ B.38 Language indication Ignore ___________________________________________________________________________________________________________________________________________________________________ B.39 Latest delivery designation National matter ___________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table B-1/F.421 [1T6.421], p. H.T. [2T6.421] TABLE B-1/F.421 (cont.) _______________________________________________________________________________________________________________________________________________________________ { References Rec. F.400 Annex B } Elements of message Action to be taken Examples _______________________________________________________________________________________________________________________________________________________________ B.41 Message identification Ignore _______________________________________________________________________________________________________________________________________________________________ B.45 Multi-destination delivery { Deliver the message to all recipients } _______________________________________________________________________________________________________________________________________________________________ B.46 Multi-part body { Messages containing not supported body parts are not delivered. Send back a non-delivery notification to the originator } _______________________________________________________________________________________________________________________________________________________________ B.47 Non-delivery notification { The PTLXAU shall generate a delivery report } _______________________________________________________________________________________________________________________________________________________________ B.48 { Non-receipt notification request } Ignore _______________________________________________________________________________________________________________________________________________________________ B.52 Obsoleting indication Obsoletes: > _______________________________________________________________________________________________________________________________________________________________ B.54 { Original encoded information types indication } Ignore _______________________________________________________________________________________________________________________________________________________________ B.55 Originator indication Ignore _______________________________________________________________________________________________________________________________________________________________ B.56 { Originator request alternate recipient } National matter _______________________________________________________________________________________________________________________________________________________________ B.62 { Primary and copy recipients indication } { Display the O/R descriptor information of the recipient(s) in the message heading } { TO: > TO: > CC: > CC: > } _______________________________________________________________________________________________________________________________________________________________ B.63 Probe National matter _______________________________________________________________________________________________________________________________________________________________ B.67 { Receipt notification request indication } Ignore _______________________________________________________________________________________________________________________________________________________________ B.72 Reply request indication Display in message heading { Reply > requested > by > sender } _______________________________________________________________________________________________________________________________________________________________ B.73 { Replying IP-message indication } Display in message heading Reply to message: > _______________________________________________________________________________________________________________________________________________________________ B.80 Sensibility indication { Display in message heading just above text of body } _______________________________________________________________________________________________________________________________________________________________ B.88 Subject indication { Display in message heading just above text of body } Subject: > _______________________________________________________________________________________________________________________________________________________________ B.89 Subsmission time stamp Display in message heading Submitted: > > UTC _______________________________________________________________________________________________________________________________________________________________ B.90 Typed body Ignore _______________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note - The symbol > equals a space. Table B-1/F.421 [2T6.421], p. 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 | (raswissptt FROM: | (ra ADM | (raarcom400 FROM: | (ra CTN | (rach b) One-stage selection | FROM: | (ra(F.74 A/B) BLANC 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 Recommendation F.422 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 han- dling 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 responsibili- ties 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 mes- sage 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 Recommenda- tions define, respectively, the service and technical requirements for the teletex service; (j) that Recommendation T.330 defines the technical require- ments of the intercommunication between the IPM service and the teletex service, unanimously declares the view that where Administrations provide international intercommuni- cation 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 4 Elements of service 5 Quality of service Annex A - Abbreviations 1 Purpose and scope 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 capabil- ity 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 S 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 intercom- munication described in this Recommendation. 2 Description of intercommunication 2.1 Responsibility boundaries 2.1.1 IPM service to teletex service The PTTXAU retains the responsibility of the message ori- ginated by an IPM user until the teletex terminal equipment posi- tively 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 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 suit- able for delivery to teletex terminal equipment in accordance with Recommendation F.200. 3.2.5 The call identification line (CIL) will contain suffi- cient information to advise the teletex user of the network address of the PTTXAU. 3.2.6 The header of the message will contain sufficient infor- mation 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 equip- ment and the PTTXAU is according to Recommendation F.200. The sub- mission 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. 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 intercom- munication. 5 Quality of service 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 provid- ing the PTTXAU to advise the originator via other suitable means. BLANC H.T. [T1.422] TABLE 1/F.422 Elements of service ___________________________________________________________________________________________________ { 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 } ___________________________________________________________________________________________________ B.5 Autorizing users indication X B.6 Auto-forwarded indication X B.8 { Blind copy recipient indication } X B.9 { Body part encryption indication } X B.12 Content type indication X X B.13 Conversion prohibition X X B.15 Converted indication X B.18 Cross referencing indication X B.21 Delivery notification X N/A X B.22 { Delivery time stamp indication } X X B.25 { Disclosure of other recipients } X X B.26 { DL expansion history indication } X X B.29 Expiry date indication X B.31 { Forwarded IP-message indication } X B.32 Grade of delivery selection X X B.34 Implicit conversion N/A X B.35 Importance indication X B.37 IP-message identification X X B.38 Language indication X B.39 Latest delivery indication N/A X B.41 Message identification X B.45 Multi-destination delivery X N/A B.46 Multi-part body X B.47 Non-delivery notification N/A X B.48 { Non-receipt notification request } X N/A B.52 Obsoleting indication X B.54 { Original encoded information types indication } X B.55 Originator indication X B.56 { Originator request alternate recipient } X B.62 { Primary and copy recipients indication } X X B.72 Reply request indication X B.73 { Replying IP-message indication } X B.80 Sensitivity indication X B.88 Subject indication X X 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 ANNEX A (to Recommendation F.422) Abbreviations H.T. [T2.422] ______________________________________ AU Access Unit CIL Call Identification Line DL Distribution List IPM Interpersonal Messaging MHS Message Handling System MT Message Transfer MTS Message Transfer System N/A Not Applicable O/R Originator/Recipient PTTXAU Public Teletex Access Unit TTX Teletex 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.422], p. MONTAGE: PAGE 146 = PAGE BLANCHE