.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .sp 2P .LP \fBRecommendation\ F.420\fR .RT .sp 2P .ce 1000 \fBMESSAGE\ HANDLING\ SERVICES:\fR .EF '% Fascicle\ II.6\ \(em\ Rec.\ F.420'' .OF '''Fascicle\ II.6\ \(em\ Rec.\ F.420 %' .ce 0 .sp 1P .ce 1000 \fBTHE\ PUBLIC\ INTERPERSONAL\ MESSAGING\ SERVICE\fR .ce 0 .sp 1P .PP 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. .sp 1P .RT .sp 2P .LP The\ CCITT, .sp 1P .RT .sp 1P .LP \fIconsidering\fR .sp 9p .RT .PP (a) the need for public message handling services; .PP (b) the strategic and commercial importance of standardization of message handling services; .PP (c) the urgent need for intercommunication agreements for existing telematic services, and other services with public message handling services; .PP (d) the need for a clear distinction between the responsibilities to be allocated to service providers and those of subscribers and/or users; .PP (e) the need for establishing international compatibility between different messaging systems; .PP ( f ) the growth of the installed base of terminals and personal computers with the ability to access message handling systems; .PP (g) that several F\(hyseries Recommendations describe public message handling services; .PP (h) that certain X and T\(hyseries Recommendations cover relevant aspects of systems used for the provision of messaging services, .sp 1P .LP \fIunanimously declares\fR .sp 9p .RT .PP the view that the requirements specified in this Recommendation should be applied for the provision of the public interpersonal messaging service internationally. .sp 1P .ce 1000 \fBCONTENTS\fR .ce 0 .sp 1P .sp 2P .LP 1 \fIPurpose and scope\fR .sp 1P .RT .LP 1.1 General .LP 1.2 Message handling systems used in the provision of IPM service .sp 1P .LP 2 \fIIPM service\fR .sp 9p .RT .LP 2.1 General service requirements .LP 2.2 IPM service features .LP 2.3 Responsibility boundaries .LP 2.4 Message service .LP 2.5 Use of directory .LP 2.6 Security .LP 2.7 Distribution lists .LP 2.8 Intercommunication with physical delivery services .sp 1P .LP 3 \fITypes of body parts\fR .bp .sp 9p .RT .sp 1P .LP 4 \fIConversion between different encoded information types\fR .sp 9p .RT .sp 1P .LP 5 \fINaming and addressing in general\fR .sp 9p .RT .LP 5.1 Directory names .LP 5.2 O/R names .LP 5.3 O/R addresses .sp 1P .LP 6 \fIOperation of the service\fR .sp 9p .RT .LP 6.1 General .LP 6.2 Message handling phases .sp 1P .LP 7 \fIQuality of service\fR .sp 9p .RT .LP 7.1 Message status .LP 7.2 Support by Administrations .LP 7.3 Model of delivery and notification times .LP 7.4 Message delivery time targets .LP 7.5 Delivery notification time targets .LP 7.6 Receipt notifications and non\(hyreceipt notifications .LP 7.7 Error protection .LP 7.8 Availability of service .LP 7.9 Minimum storage capacity .sp 1P .LP 8 \fITariff and accounting principles\fR .sp 9p .RT .sp 1P .LP 9 \fINetwork requirements\fR .sp 9p .RT .sp 1P .LP 10 \fIUser information and support\fR .sp 9p .RT .sp 1P .LP 11 \fIUse of the IPM service within CCITT\(hydefined telematic services\fR .sp 9p .RT .sp 1P .LP \fIAnnex\ A\fR \(em Abbreviations .sp 9p .RT .LP \fIAnnex\ B\fR \(em Subscriber access and terminal requirements .LP \fIAnnex\ C\fR \(em IPM service elements from 1984 X.400 Recommendations .sp 2P .LP \fB1\fR \fBPurpose and scope\fR .sp 1P .RT .sp 1P .LP 1.1 \fIGeneral\fR .sp 9p .RT .PP 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\(hyseries Recommendations. .PP 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\(hyand\(hyforward, and store\(hyand\(hyretrieve techniques. .PP Locally provided functions, for which communication with other subscribers is not required, are not covered by CCITT Recommendations. .PP The Interpersonal Messaging (IPM) Service enables subscribers to request a variety of features to be performed during the handling and exchange of messages. .PP Some features are inherent in the basic IPM service. Other non\(hybasic features may be selected by the subscriber, either on a per\(hymessage basis or for an agreed contractual period of time, if they are provided by Administrations. .bp .PP Basic features have to be made available internationally by Administrations. Non\(hybasic 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\(hybasic features are called \fIoptional user facilities\fR . .PP 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. .PP Technical specifications and protocols, to be used in the IPM service are defined in the X.400\(hyseries Recommendations, in Recommendation\ T.330 and in Recommendation\ U.204. .PP This service definition is contained in \(sc\ 2. Requirements for intercommunication between subscribers are described in \(sc\(sc\ 3 and\ 4. Section\ 5 describes naming and addressing, while \(sc\(sc\ 6, 7 and\ 8 describe the operation of the service, quality of service, tariff and accounting principles. Network requirements are given in \(sc\ 9. The provision of subscriber information is in \(sc\ 10, and \(sc\ 11 contains information on the use of IPM service within CCITT defined telematic services. .RT .sp 2P .LP 1.2 \fIMessage handling systems used in the provision of IPM service\fR .sp 1P .RT .sp 1P .LP 1.2.1 \fI1984 implementations\fR .sp 9p .RT .PP 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\(hyseries 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\(hyseries 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. .RT .sp 1P .LP 1.2.2 \fIElements of service\fR .sp 9p .RT .PP 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\(hyclassified 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. .RT .sp 1P .LP 1.2.3 \fIName forms\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP 1.2.4 \fIInterworking\fR .sp 9p .RT .PP 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. .PP Interworking from 1988 ADMDs to 1984 PRMDs is a national matter. .bp .RT .sp 2P .LP \fB2\fR \fBIPM service\fR .sp 1P .RT .sp 1P .LP 2.1 \fIGeneral service requirements\fR \v'3p' .sp 9p .RT .PP 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. .PP This service may also provide features available for the preparation and the presentation of the messages. .PP 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\(hyseries of Recommendations. .PP 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). .PP 2.1.3 International exchange of messages are performed between administration management domains through CCITT\(hystandardized public data transmission services. .PP 2.1.4 Different body part types of messages may be exchanged through this service. The urgent body part types are listed in \(sc\ 3. .PP 2.1.5 An Administration may provide subscribers with different methods of access to the IPM service. The possible methods are: .LP 1) directly from the user's terminal; .LP 2) via a private message handling system. .PP 2.1.6 Each Administration is responsible for the national access to its management domain. .PP 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\(hystandardized 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. .PP 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. .PP 2.1.9 As the service is providing indirect communication, cases of non\(hydelivery of the message to the intended recipient may occur. The IPM service provides for non\(hydelivery notification and, as optional user facilities, for delivery, receipt and non\(hyreceipt notifications. .PP 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. .PP 2.1.11 The message belongs to the originator until delivery has taken place. After delivery, the message belongs to the recipient. .PP 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). .sp 2P .LP 2.2 \fIIPM service features\fR .sp 1P .RT .sp 1P .LP 2.2.1 \fIIntroduction\fR .sp 9p .RT .PP Recommendation F.400, \(sc 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. .bp .RT .sp 1P .LP 2.2.2 \fIBasic IPM service\fR .sp 9p .RT .PP 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\(hymessages 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\(hymessage, the originating user makes a request of his UA, specifying the name or address of the recipient who is to receive the IP\(hymessage. The IP\(hymessage, 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. .PP Following a successful delivery to the recipient's UA, the IP\(hymessage 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\(hymessages 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\(hymessages. In addition, the submission time, delivery time and other capabilities are supplied with each IP\(hymessage. Non\(hydelivery notification is provided with the basic services. .RT .sp 1P .LP 2.2.3 \fIIPM optional user facilities\fR .sp 9p .RT .PP 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\(hymessage 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. .PP The optional user facilities of the the IPM service that are selected on a per\(hymessage 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\(hymessages 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. .PP \fINote\fR \ \(em\ 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. .RT .sp 1P .LP 2.2.4 \fILocal functions\fR .sp 9p .RT .PP 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\(hymessages, 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\(hyinitiated voice indication). .PP The MHS may provide local database controls to help the subscriber find previously received and filed IP\(hymessages (for example, to find the message from Mr.\ Jones delivered sometime in August on the subject of \fIteleconferencing\fR ). A subscriber on vacation may request the MHS to automatically forward all his IP\(hymessages to his delegate, or define rules for which IP\(hymessages should not be auto\(hyforwarded (for example, personal messages). .PP 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. .bp .RT .sp 1P .LP 2.3 \fIResponsibility boundaries\fR .sp 9p .RT .PP 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. .PP 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. .PP 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. .PP As a basic feature, a non\(hydelivery 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\(hyreceipt notification. .PP 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. .PP Loss of information may occur through the process of conversion as long as the conversion is not explicitly prohibited by the originating user. .PP 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. .PP 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. .RT .sp 1P .LP 2.4 \fIMessage store\fR .sp 9p .RT .PP 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, \(sc\ 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. .RT .sp 1P .LP 2.5 \fIUse of\fR \fIdirectory\fR .sp 9p .RT .PP 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, \(sc\ 14. .RT .sp 1P .LP 2.6 \fISecurity\fR .sp 9p .RT .PP Administrations may optionally provide security mechanisms as outlined in Recommendation\ F.400, \(sc\ 15, to counter the various security threats mentioned. This capability relies on a Directory System storing certified copies of public keys for MHS users. .RT .sp 1P .LP 2.7 \fIDistribution lists\fR .sp 9p .RT .PP 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, \(sc\ 14, outlines the full capabilities available to DL users. .bp .PP 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. .RT .sp 1P .LP 2.8 \fIIntercommunication with physical delivery services\fR .sp 9p .RT .PP 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, \(sc\ 10. .RT .sp 2P .LP \fB3\fR \fBTypes of\fR \fBbody parts\fR .sp 1P .RT .PP 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: .RT .LP \(em IA5 text, .LP \(em Voice, .LP \(em G3 facsimile, .LP \(em G4 class 1, .LP \(em Teletex, .LP \(em Videotex, .LP \(em Encrypted, .LP \(em Message (e.g., for a forwarded message), .LP \(em Mixed mode, .LP \(em Bilaterally defined, .LP \(em Nationally defined, .LP \(em Externally defined. .sp 2P .LP \fB4\fR \fBConversion between different encoded information types\fR .sp 1P .RT .PP 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. .PP 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. .PP The conversion process for IP\(hymessages 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. .RT .sp 2P .LP \fB5\fR \fBNaming and addressing in general\fR .sp 1P .RT .PP 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. .bp .RT .sp 1P .LP 5.1 \fIDirectory names\fR .sp 9p .RT .PP 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. .PP 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. .PP 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. .RT .sp 1P .LP 5.2 \fIO/R names\fR .sp 9p .RT .PP 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. .PP 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. .RT .sp 1P .LP 5.2 \fIO/R addresses\fR .sp 9p .RT .PP 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 \*QO/R\*U recognizes the fact that the user can be acting as either the originator or recipient of the message or notification in question). .PP Various forms of O/R addresses are currently defined, each serving its own purpose. These forms and their purpose are as follows: .RT .LP \(em \fIMnemonic O/R address\fR \fI:\fR \ Provides a user\(hyfriendly means of identifying users in the absence of a directory. It is also used for identifying a distribution list. .LP \(em \fITerminal O/R address\fR \fI:\fR \ Provides a means of identifying users with terminals belonging to various networks. .LP \(em \fINumeric O/R address\fR \fI:\fR \ Provides a means of identifying users with numeric keypads. .LP \(em \fIPostal O/R address\fR \fI:\fR \ Provides a means of identifying originators and recipients of messages and notifications, for physical delivery. .PP 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. .PP 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). .PP Each Administration is responsible for the unique identification of each user agent in its management domain. .RT .sp 2P .LP \fB6\fR \fBOperation of the service\fR .sp 1P .RT .sp 1P .LP 6.1 \fIGeneral\fR \v'3p' .sp 9p .RT .PP 6.1.1 The IPM service provides that messages can be sent, transferred, delivered and received, using fully automatic procedures. .PP \fINote\fR \ \(em\ Manual receipt and sending of message can be provided in the case of interworking with postal systems. .bp .PP 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. .PP 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. .PP 6.1.4 Each Administration providing the IPM service should validate the subscribers' identities, at the time of access. .PP \fINote\fR \ \(em\ Further study is needed in the case of auto\(hyreceipt. .PP 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. .PP 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 \(sc\ 4 of this Recommendation. .PP 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. .sp 2P .LP 6.2 \fIMessage handling phases\fR .sp 1P .RT .sp 1P .LP 6.2.1 \fIGeneral\fR .sp 9p .RT .PP The IPM service has different message handling phases visible to the user. .RT .sp 1P .LP 6.2.2 \fIPreparation phase\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP 6.2.3 \fISending phase\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP 6.2.4 \fIReceipt phase\fR .sp 9p .RT .PP 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\(hyreceipt) or by the subscriber for message reception. The operation of the user agent receiving messages is specified in Recommendation\ X.420. .PP 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. .PP In the case of auto\(hyreceipt, 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. .PP 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. .PP 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. .PP 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. .PP \fINotifications:\fR \ Four notifications can be received: .RT .LP \(em non\(hydelivery notification; .LP \(em delivery notification; .LP \(em receipt notification; .LP \(em non\(hyreceipt notification. .bp .PP Non\(hydelivery notification is automatically originated by the MTS, while delivery notification, receipt and non\(hyreceipt 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. .sp 2P .LP \fB7\fR \fBQuality of service\fR .sp 1P .RT .sp 1P .LP 7.1 \fIMessage status\fR .sp 9p .RT .PP The unique identification of each IP\(hymessage enables the system to provide information about, e.g.,\ the status of an IP\(hymessage. .PP In the event of system failure, all accepted and non\(hydelivered messages should be traceable. If messages cannot be delivered, the originator must be informed by a non\(hydelivery notification. .RT .sp 1P .LP 7.2 \fISupport by Administrations\fR .sp 9p .RT .PP Administrations should provide assistance to their subscribers, with regard to non\(hydelivery 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. .PP 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. .RT .sp 1P .LP 7.3 \fIModel of delivery and notification times\fR | see Figure\ 1/F.420) .sp 9p .RT .sp 1P .LP 7.4 \fIMessage delivery time targets\fR .sp 9p .RT .PP The management domain of the recipient UA should force non\(hydelivery notification if the message has not been delivered before \fIx\fR \ hours after submission (or after date and time indicated for deferred delivery), the value of \fIx\fR being dependent on the grade of delivery requested by the originator. (See Recommendation\ F.410, \(sc\ 4.4.) .RT .sp 1P .LP 7.5 \fIDelivery notification time targets\fR .sp 9p .RT .PP Non\(hydelivery notifications or requested delivery notifications should be returned on a per\(hyrecipient basis, in order not to delay notifications for those messages in a multi\(hyaddressed message which have already been delivered, to enable the originating management domain either to return per\(hyrecipient notifications or to batch notifications to its subscribers. (See Recommendation\ F.410, \(sc\ 4.5.) .RT .sp 1P .LP 7.6 \fIReceipt notifications and non\(hyreceipt notifications\fR .sp 9p .RT .PP Delivery times for receipt or non\(hyreceipt 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). .RT .sp 1P .LP 7.7 \fIError protection\fR .sp 9p .RT .PP Error protection on transmission is provided by the MHS and underlying protocols used in the provision of the IPM service. .RT .sp 1P .LP 7.8 \fIAvailability of service\fR .sp 9p .RT .PP 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. .bp .RT .LP .rs .sp 38P .ad r \fBFigure 1/F.420, p.1\fR .sp 1P .RT .ad b .RT .ce \fBH.T. [T1.420]\fR .ce TABLE\ 1/F.420 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(60p) | cw(60p) . { Grade of delivery (of the referred message) } 95% delivered before _ .T& lw(60p) | cw(60p) . Urgent \ 0.75 hours .T& lw(60p) | cw(60p) . Normal \ 4 | \ hours .T& lw(60p) | cw(60p) . Non\(hyurgent 24 | \ hours .TE .LP \fINote\fR \ \(em\ Intercommunication with PRMDs is not included in the calculation of the time targets. .nr PS 9 .RT .ad r \fBTableau 1/F.420 [T1.420], p.2\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 7.9 \fIMinimum storage capacity\fR .sp 9p .RT .PP The storage capacity of a user agent and message store shall be sufficient to provide a high grade of service. .PP \fINote\fR \ \(em\ This is for further study. .RT .sp 2P .LP \fB8\fR \fBTariff and accounting principles\fR .sp 1P .RT .PP See D\(hyseries Recommendations. .RT .sp 2P .LP \fB9\fR \fBNetwork requirements\fR .sp 1P .RT .PP 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. .RT .sp 2P .LP \fB10\fR \fBUser information and support\fR .sp 1P .RT .PP A directory shall be provided by each Administration for its domain. The directory can be hard copy or preferably electronic form. .PP The directory shall at least contain the following: .RT .LP a) how to use the directory and the service; .LP b) list of O/R addresses of subscribers belonging to the Administration's domain; .LP c) list of standardized abbreviations for O/R address attributes; .LP d) list of country and Administration management domain names reachable by the public IPM service. .sp 2P .LP \fB11\fR \fBUse of the IPM service within CCITT\(hydefined telematic services\fR .sp 1P .RT .PP See relevant F\(hyseries Recommendations. .RT .LP .rs .sp 20P .ad r BLANC .ad b .RT .LP .bp .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation F.420) .sp 9p .RT .ce 0 .ce 1000 \fBAbbreviations\fR .sp 1P .RT .ce 0 .PP The following abbreviations are used in this Recommendation. .sp 1P .RT .ce \fBH.T. [T2.420]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(30p) | lw(120p) . A { Additional Optional User Facility } .T& lw(30p) | lw(120p) . ADMD { Administration Management Domain } .T& lw(30p) | lw(120p) . DL Distribution List .T& lw(30p) | lw(120p) . E { Essential Optional User Facility } .T& lw(30p) | lw(120p) . EIT Encoded Information Type .T& lw(30p) | lw(120p) . G3 Group 3 (Facsimile) .T& lw(30p) | lw(120p) . G4 Group 4 (Facsimile) .T& lw(30p) | lw(120p) . IA5 International Alphabet 5 .T& lw(30p) | lw(120p) . IP Interpersonal .T& lw(30p) | lw(120p) . IPM Interpersonal Messaging .T& lw(30p) | lw(120p) . MD Management Domain .T& lw(30p) | lw(120p) . MHS Message Handling System .T& lw(30p) | lw(120p) . MS Message Store .T& lw(30p) | lw(120p) . MT Message Transfer .T& lw(30p) | lw(120p) . MTA Message Transfer Agent .T& lw(30p) | lw(120p) . MTS Message Tranfer System .T& lw(30p) | lw(120p) . N/A Not Applicable .T& lw(30p) | lw(120p) . O/R Originator/Recipient .T& lw(30p) | lw(120p) . PD Physical Delivery .T& lw(30p) | lw(120p) . PDN Public Data Network .T& lw(30p) | lw(120p) . PDS Physical Delivery System .T& lw(30p) | lw(120p) . PRMS Private Management Domain .T& lw(30p) | lw(120p) . TTXAU Teletex Access Unit .T& lw(30p) | lw(120p) . UA User Agent .TE .LP \fINote\ 1\fR \ \(em\ For a glossary of terms see Annex A to Recommendation F.400. .LP \fINote\ 2\fR \ \(em\ For references see Recommendations F.400 and F.401. .nr PS 9 .RT .ad r \fBTable [T2.420], p.\fR .sp 1P .RT .ad b .RT .LP .sp 8 .bp .ce 1000 ANNEX\ B .ce 0 .ce 1000 (to Recommendation F.420) .sp 9p .RT .ce 0 .ce 1000 \fBSubscriber access and terminal requirements\fR .sp 1P .RT .ce 0 .LP B.1 \fIGeneral\fR .sp 1P .RT .PP 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. .RT .sp 1P .LP B.2 \fITerminals without UA functionality\fR .sp 9p .RT .PP Terminals in this category require additional functions to be provided by MHS to enable their participation in the IPM service. .RT .sp 1P .LP B.2.1 \fITelex terminals\fR .sp 9p .RT .PP Telex terminals shall conform to the relevant technical Recommendations, and be based on the relevant service Recommendations. .RT .sp 1P .LP B.2.2 \fITeletex terminals\fR .sp 9p .RT .PP 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. .PP The access procedures for submission and delivery of documents shall conform to Recommendation\ T.330. .PP \fINote\fR \ \(em\ 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. .RT .sp 1P .LP B.2.3 \fIFacsimile terminals\fR .sp 9p .RT .PP Group 3 and Group 4 facsimile terminals should have access to the IPM service. .PP \fINote\fR \ \(em\ Access procedures are for further study. .RT .sp 1P .LP B.2.4 \fIVideotex terminals\fR .sp 9p .RT .PP These terminals shall conform to Recommendation F.300. .PP \fINote\fR \ \(em\ Access procedures are for further study. Eventual subset of Recommendation\ F.300 needs to be considered. .RT .sp 1P .LP B.2.5 \fIIA5 terminals\fR .sp 9p .RT .PP 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. .PP \fINote\fR \ \(em\ Additional procedures are for further study. .RT .sp 1P .LP B.3 \fITerminals with UA functionality\fR .sp 9p .RT .PP These terminals shall, as a minimum, have the capabilities to: .RT .LP 1) provide the capabilities to subscribers of the basic features defined in \(sc\ 2; .LP 2) make use of the IPM protocol specified in Recommendation\ X.420; .LP 3) use the submission and delivery protocol specified in Recommendation\ X.419; .LP 4) use the remote operation procedures specified in Recommendation\ X.419. .PP These terminals shall be able to handle at least one EIT as defined in Recommendation\ X.408 (e.g.,\ IA5, teletex,\ etc.). .bp .ce 1000 ANNEX\ C .ce 0 .ce 1000 (to Recommendation F.420) .sp 9p .RT .ce 0 .ce 1000 \fBIPM service elements from 1984 X.400 Recommendations\fR .sp 1P .RT .ce 0 .ce \fBH.T. [T3.420]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS 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 _ .T& lw(108p) | cw(30p) | lw(30p) | lw(30p) | lw(30p) . Access management X .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | lw(30p) . Alternate recipient allowed A A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Alternate recipient assignment } A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Authorizing users indication A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Auto\(hyfowarded indication A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Blind copy recipient indication } A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Body part encryption indication } A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Content type indication X .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Conversion prohibition E E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Converted indication X .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Cross referencing indication A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Deferred delivery E N/A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Deferred delivery cancellation } A N/A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Delivery notification E N/A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Delivery time stamp indication } X .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Disclosure of other recipients } \fR A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Expiry date indication A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Explicit conversion A N/A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Fowarded IP\(hymessage indication } A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Grade of delivery selection E E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Hold for delivery A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Implicit conversion A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Importance indication A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . IP\(hymessage identification X .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Message identification X .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Multi\(hydestination delivery E N/A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Multi\(hypart body A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Non\(hydelivery notification X .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Non\(hyreceipt notification A A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Obsoleting indication A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Original encoded information types indication } X .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Originator indication E E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Prevention of non\(hydelivery notification } A N/A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Primary and copy recipients indication } E E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Probe A N/A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Receipt notification A A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Registered encoded information types } X .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Reply request indication A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Replying IP\(hymessage indication } E E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Return of contents A N/A .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Sensitivity indication A E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Subject indication E E .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { Submission time stamp indication } X .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Typed body X _ .TE .nr PS 9 .RT .ad r \fBTable [T3.420], p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP \fBRecommendation\ F.421\fR .FS This Recommendation is the same as Recommendation\ F.75 of which only the title appears in Fascicle | I.4. .FE .RT .sp 2P .ce 1000 \fBMESSAGE\ HANDLING\ SERVICES:\fR .EF '% Fascicle\ II.6\ \(em\ Rec.\ F.421'' .OF '''Fascicle\ II.6\ \(em\ Rec.\ F.421 %' .ce 0 .ce 1000 \fBINTERCOMMUNICATION\ BETWEEN\ THE\ IPM\ SERVICE\fR .ce 0 .sp 1P .ce 1000 \fBAND\ THE\ TELEX\ SERVICE\fR .ce 0 .sp 1P .PP 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. .sp 1P .RT .sp 2P .LP The\ CCITT, .sp 1P .RT .sp 1P .LP \fIconsidering\fR .sp 9p .RT .PP (a) the need for public message handling services; .PP (b) the strategic and commercial importance of standardization of message handling services; .PP (c) the urgent need for intercommunication arrangements for existing telematic services, and other services with public message handling services; .PP (d) the need for a clear distinction between the responsibilities to be allocated to service providers and those of subscribers and/or users; .PP (e) the need for establishing international compatibility between different messaging systems; .PP (f ) the growth of the installed base of terminals and personal computers with the ability to access message handling systems; .PP (g) that several F\(hyseries Recommendations describe public message handling services; .PP (h) that certain X, T and U\(hyseries Recommendations cover relevant aspects of systems used for the provision of messaging services; .PP (i) that Recommendations F.60 and F.69 define the service requirements for the telex service; .PP (j) that Recommendation F.72 defines international telex store\(hyand\(hyforward; .PP (k) that the U\(hyseries Recommendations define the technical requirements for the telex service; .PP (l) that Recommendation U.204 defines the technical requirements for the intercommunication between the IPM service and the telex service; .sp 1P .LP \fIunanimously declares\fR .sp 9p .RT .PP that operational procedures for intercommunication between the public interpersonal messaging service and the telex service shall be in accordance with this Recommendation. .sp 1P .ce 1000 \fBCONTENTS\fR .ce 0 .sp 1P .sp 2P .LP 1 \fIScope\fR .sp 1P .RT .sp 1P .LP 2 \fIIntroduction\fR .sp 9p .RT .sp 1P .LP 3 \fIService outline\fR .sp 9p .RT .LP .sp 1 .bp .sp 1P .LP 4 \fIOperational procedures\fR .sp 9p .RT .LP 4.1 IPM service to telex service direction .LP 4.2 Telex service to IPM service direction .LP 4.3 Construction of the IP\(hymessage .sp 1P .LP \fIAnnex\ A\fR \(em Abbreviations .sp 9p .RT .LP \fIAnnex\ B\fR \(em Actions to be taken by the PTLXAU/examples .LP \fIAnnex\ C\fR \(em IPM message to telex .LP \fIAnnex\ D\fR \(em Telex message to IPM .sp 2P .LP \fB1\fR \fBScope\fR \v'3p' .sp 1P .RT .PP 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. .PP 1.2 The intercommunication is based on store\(hyand\(hyforward principles which allow users of one service to exchange messages with the users of the other service. .sp 2P .LP \fB2\fR \fBIntroduction\fR .sp 1P .RT .PP 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. .PP 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. .PP In general the selection procedures for the telex subscriber will be two\(hystage; 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\(hystage selection procedures may be used. .RT .sp 2P .LP \fB3\fR \fBService outline\fR \v'3p' .sp 1P .RT .PP 3.1 Communication between subscribers of the telex service and the IPM service is on store\(hyand\(hyforward basis; thus conversational mode interworking between users is not applicable. .PP 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. .PP 3.3 The PTLXAU belongs to the IPM service. .PP 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. .PP 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. .PP 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. .LP .rs .sp 11P .ad r \fBFigure 1/F.421, p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP 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. .sp 2P .LP \fB4\fR \fBOperational procedures\fR .sp 1P .RT .sp 1P .LP 4.1 \fIIPM service to telex service direction\fR \v'3p' .sp 9p .RT .PP 4.1.1 Messages from an IPM service user to a telex subscriber are sent as normal IP\(hymessage with the appropriate IPM elements of service, in accordance with Recommendation\ F.420. .PP 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. .PP \fINote\fR \ \(em\ The conversion process may take place in the message transfer system (MTS) associated with the PTLXAU. .PP 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. .PP 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. .PP 4.1.5 The IP\(hymessage 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\ \*QCI\*U, the code expression \*QIPM\*U, and the telex network identification code in accordance with Recommendation\ F.69, e.g.\ \*QCI | (raIPM | (raCH\*U. .PP 4.1.6 A general layout of an IP\(hymessage delivered to the telex service is shown in Annex\ C. .PP 4.1.7 The elements of service related to the IP\(hymessage 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). .PP 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 \*QFOR RECALL\*U (see Annex\ C). .PP 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\(hydelivery of the message to the telex subscriber, a non\(hydelivery notification shall be sent back to the IPM service user (unless the IPM user has requested prevention of non\(hydelivery notification). .sp 1P .LP 4.2 \fITelex service to IPM service direction\fR .sp 9p .RT .PP In this direction, Administrations may implement either or both one\(hystage and two\(hystage call set\(hyup procedures. .RT .sp 1P .LP 4.2.1 \fIOne\(hystage selection\fR \v'3p' .sp 9p .RT .LP 4.2.1.1\ \ Where one\(hystage call set\(hyup procedures are used, the number assigned to a user in the IPM service must appear to be part of the national telex numbering plan. .LP 4.2.1.2\ \ The length of the number assigned to the IPM service user shall be in accordance with the relevant U\(hyseries signalling Recommendations. .LP 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. .LP 4.2.1.4\ \ The call shall be established using normal telex call set\(hyup procedures. .bp .LP 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: .LP 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; .LP 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. .LP 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. .LP 4.2.1.7\ \ The call shall be cleared using normal telex call clearing procedures. .LP 4.2.1.8\ \ When the message cannot be delivered to the IPM service user, a non\(hydelivery notification shall be returned to the telex subscriber. The procedures for establishing the calling telex address are specified in Recommendation\ U.204. .LP 4.2.1.9\ \ The non\(hydelivery 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. .LP 4.2.1.10\ \ The action to be taken when a non\(hydelivery notification cannot be returned to the calling telex subscriber is for further study. .LP 4.2.1.11\ \ The format of notifications and the procedures for their delivery should be in accordance with Recommendation\ U.204. .LP 4.2.1.12\ \ The use of IPM elements of service by the telex subscriber is for further study. .sp 1P .LP 4.2.2 \fITwo\(hystage selection\fR \v'3p' .sp 9p .RT .LP 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. .LP 4.2.2.2\ \ Procedures for access to the PTLXAU shall follow Recommendation\ U.204. .LP 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). .LP 4.2.2.4\ \ The PTLXAU shall be able to accommodate the following O/R address forms: .LP \(em Mnemonic O/R address; .LP \(em Terminal O/R address; .LP \(em Numeric O/R address; .LP as specified in Recommendation\ F.401. The O/R address should be input in accordance with the requirements of Recommendation\ U.204. .PP 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\(hyof\(hyaddress (EOA) indicator. .PP The structure of the service identifier and the address input is shown in Table\ 1/F.421. .RT .PP Each attribute of the address structure shall be contained in one line. .PP Each address attribute and the service shall be identified by a code expression according to Tables\ 2/F.421 and\ 3/F.421. .RT .LP 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 \*QTHIS MESSAGE MAY BE INCOMPLETE\*U. Annex\ D shows a general layout applicable in case of submission of message(s) to the PTLXAU by the telex subscriber. .LP 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. .bp .ce \fBH.T. [T1.421]\fR .ce TABLE\ 1/F.421 .ce \fBTelex service to IPM service address structure .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(120p) . Service identifier .T& lw(120p) . { Address attribute identifier } .T& cw(120p) . . .T& cw(120p) . . .T& cw(120p) . . .T& lw(120p) . { Address attribute identifier } .T& lw(120p) . End of single O/R address (+) .T& lw(120p) . [Next O/R address(es)] .T& lw(120p) . { [Request for IPM elements of service] } .T& lw(120p) . End of address(es) (BT) [Request for delivery notification] .TE .LP \fINote\fR \ \(em\ [ ] indicates optional attributes. .nr PS 9 .RT .ad r \fBTableau 1/F.421 [T1.421], p.6\fR .sp 1P .RT .ad b .RT .ce \fBH.T. [T2.421]\fR .ce TABLE\ 2/F.421 .ce \fBCode expressions for address attribute identifiers .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(90p) | cw(60p) . Address attribute Format _ .T& lw(90p) | lw(60p) . Country name CTN > .T& lw(90p) | lw(60p) . Administration domain name ADM > .T& lw(90p) | lw(60p) . Private domain name \fR PRI > .T& lw(90p) | lw(60p) . Organization name ORG > .T& lw(90p) | lw(60p) . Organization unit name(s) OUN > .T& lw(90p) | lw(60p) . Personal name \(em\ Surname SUR > .T& lw(90p) | lw(60p) . \(em\ Given name GIV > .T& lw(90p) | lw(60p) . \(em\ Initials INI > .T& lw(90p) | lw(60p) . \(em\ Generation qualifier GEN > .T& lw(90p) | lw(60p) . \(em\ Common name COM > .T& lw(90p) | lw(60p) . Numeric user identifier NUS > .T& lw(90p) | lw(60p) . { Terminal type and network address for telex } TLX > .T& lw(90p) | lw(60p) . \fBfor\fR teletex TTX > .T& lw(90p) | lw(60p) . \fBfor\fR facsimile FAX > .T& lw(90p) | lw(60p) . \fBfor\fR videotex VTX > .T& lw(90p) | lw(60p) . Domain defined attribute(s) .T& lw(90p) | lw(60p) . \(em\ Type DDT > .T& lw(90p) | lw(60p) . \(em\ Value DDV > .TE .LP \fINote\ 1\fR \ \(em\ The symbol\ > equals a space. .LP \fINote\ 2\fR \ \(em\ Allowed attribute values are specified in Recommendation F.401. .nr PS 9 .RT .ad r \fBTableau 2/F.421 [T2.421], p.7\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [T3.421]\fR .ce TABLE\ 3/F.421 .ce \fBCode expression for the service identifier\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(90p) | cw(36p) . Service Format _ .T& lw(90p) | cw(36p) . { Interpersonal messaging service } IPM _ .TE .nr PS 9 .RT .ad r \fBTableau 3/F.421 [T3.421], p.8\fR .sp 1P .RT .ad b .RT .LP 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: .LP \(em The existence of mandatory attributes. .LP \(em The existence of non\(hyallowed attributes. .LP \(em The minimum and maximum allowed number of characters in each attribute. .LP \(em The existence of non\(hyallowed characters in an attribute. .PP Where applicable, the existence/non\(hyexistence of non\(hysignificant character(s) preceding or following the attribute values shall not prevent validation. .PP 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. .RT .LP 4.2.2.8\ \ The service principles for delivery and non\(hydelivery 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. .sp 1P .LP 4.3 \fIConstruction of the IP\(hymessage\fR .sp 9p .RT .PP The message received by the PTLXAU shall be delivered to the IPM user(s) in accordance with following rules. .RT .sp 1P .LP 4.3.1 \fIP2 body part\fR .sp 9p .RT .PP The received message, excluding the recipient address(es), shall form the body of the IP\(hymessage. All the received characters shall be delivered except the WRU signals. .RT .sp 1P .LP 4.3.2 \fIRecipient O/R address\fR .sp 9p .RT .PP All recognized O/R addresses shall be assumed as primary recipients. By default, these primary recipients will not be disclosed to each other. .RT .sp 1P .LP 4.3.3 \fIOriginator indication\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP 4.3.4 \fISubject indication\fR .sp 9p .RT .PP The PTLXAU shall generate the element of service which will cause TELEX to appear in the subject indication element of service field. .RT .sp 1P .LP 4.3.5 \fIIP\(hymessage identification\fR .sp 9p .RT .PP The content of the message reference information returned to the calling telex subscriber shall also be used as the unique identifier in the IP\(hymessage identification element of service field. .bp .RT .sp 1P .LP 4.3.6 \fIGrade of delivery selection\fR .sp 9p .RT .PP The PTLXAU shall set the grade of delivery selection element of service to the value URGENT. .RT .sp 1P .LP 4.3.7 \fIConversion prohibition in case of loss of information\fR .sp 9p .RT .PP The use of the element of service \(em conversion prohibition in case of loss of information \(em\ is for further study. .RT .sp 1P .LP 4.3.8 \fIDisclosure of other recipients\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP 4.3.9 \fIDeferred delivery\fR .sp 9p .RT .PP 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. .PP \fINote\fR \ \(em\ The code expressions to be used for the selection of the elements of service described in \(sc\(sc\ 4.3.8 and\ 4.3.9 by the telex subscriber, are shown in Table\ 4/F.421. .RT .ce \fBH.T. [T4.421]\fR .ce TABLE\ 4/F.421 .ce \fBCode expressions for the use of IPM elements of service .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(78p) | cw(48p) . IPM element of service Format _ .T& lw(78p) | lw(48p) . { Disclosure of other recipients } DUR .T& lw(78p) | lw(48p) . Deferred delivery DEF > .T& lw(78p) | lw(48p) . Delivery notification BT, ACK | ua\d\u)\d .TE .LP \ua\d\u)\d The request for delivery notification may be given together with the code for end of address(es) (BT) if delivery notification is required. .LP \fINote\fR \ \(em\ The symbol\ > equals a space. .nr PS 9 .RT .ad r \fBTable 4/F.421 [T4.421], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 4.3.10 \fIOther elements of service\fR .sp 9p .RT .PP 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. .RT .LP .rs .sp 9P .ad r BLANC .ad b .RT .LP .bp .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation F.421) .sp 9p .RT .ce 0 .ce 1000 \fBAbbreviations\fR .sp 1P .RT .ce 0 .ce \fBH.T. [T5.421]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(30p) | lw(120p) . A/B Answerback .T& lw(30p) | lw(120p) . ACK { Request for Delivery Notification Signal } .T& lw(30p) | lw(120p) . ADM { Administration Management Domain } .T& lw(30p) | lw(120p) . BT End of Address(es) Signal .T& lw(30p) | lw(120p) . CI Conversation Impossible .T& lw(30p) | lw(120p) . COM Common Name .T& lw(30p) | lw(120p) . CTN Country Name .T& lw(30p) | lw(120p) . DDT { Domain Defined Attribute Type } .T& lw(30p) | lw(120p) . DDV { Domain Defined Attribute Value } .T& lw(30p) | lw(120p) . DEF Deferred Delivery .T& lw(30p) | lw(120p) . DUR { Disclosure of other Recipients } .T& lw(30p) | lw(120p) . EOA End of Address .T& lw(30p) | lw(120p) . EOM End of Message .T& lw(30p) | lw(120p) . EOT End of Transacton .T& lw(30p) | lw(120p) . FAX Facsimile .T& lw(30p) | lw(120p) . GEN Generation Qualifier .T& lw(30p) | lw(120p) . GIV Given Name .T& lw(30p) | lw(120p) . I Initials .T& lw(30p) | lw(120p) . IP Interpersonal .T& lw(30p) | lw(120p) . IPM Interpersonal Messaging .T& lw(30p) | lw(120p) . MT Message Transfer .T& lw(30p) | lw(120p) . MTS Message Transfer System .T& lw(30p) | lw(120p) . NP { The called party is not, or no longer, a subscriber } .T& lw(30p) | lw(120p) . NUS Numeric User Identifier .T& lw(30p) | lw(120p) . O/R Originator/Recipient .T& lw(30p) | lw(120p) . ORG Organization Name .T& lw(30p) | lw(120p) . OUN Organization Unit Name(s) .T& lw(30p) | lw(120p) . P2 IPM Protocol .T& lw(30p) | lw(120p) . PRI Private Domain Name .T& lw(30p) | lw(120p) . PTLXAU Public Telex Access Unit .T& lw(30p) | lw(120p) . SUR Surname .T& lw(30p) | lw(120p) . TID Terminal Identifier .T& lw(30p) | lw(120p) . TLX Telex .T& lw(30p) | lw(120p) . TTX Teletex .T& lw(30p) | lw(120p) . UTC Universal Coordinated Time .T& lw(30p) | lw(120p) . VTX Videotex .T& lw(30p) | lw(120p) . WRU Who Are You .T& lw(30p) | lw(120p) . + { End of Single O/R Address signal } .T& lw(30p) | lw(120p) . > Space .TE .LP \fINote\ 1\fR \ \(em\ For a glossary of terms see Annex A to Recommendation F.400. .LP \fINote\ 2\fR \ \(em\ For references see Recommendation F.400. .nr PS 9 .RT .ad r \fBTable [T5.421], p.\fR .sp 1P .RT .ad b .RT .LP .bp .ce 1000 ANNEX\ B .ce 0 .ce 1000 (to Recommendation F.421) .sp 9p .RT .ce 0 .ce 1000 \fBActions to be taken by the PTLXAU/examples\fR .sp 1P .RT .ce 0 .PP 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\(hy1/F.421). .sp 1P .RT .ce \fBH.T. [1T6.421]\fR .ce TABLE\ B\(hy1/F.421 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(36p) | cw(68p) | cw(62p) | cw(62p) . { Reference Rec. F.400 Annex B } Elements of service Action to be taken Examples _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.5\ Authorizing users indication Display in message heading Authority: > _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.6\ Auto\(hyforwarded indication Ignore _ .T& 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 > _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.9\ { Body part encryption indication } { The PTLXAU shall send a non\(hydelivery notification to the originator } _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.12 Content type indication { National matter for content types different than P2 } _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.13 Conversion prohibition { If ITA2, ignore. Otherwise the PTLXAU generates a non\(hydelivery notificaton } _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.15 Converted indication Ignore _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.18 Cross referencing indication Display in message heading Reference > _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.21 Delivery notification { The PTLXAU shall send a delivery notification to the originator } _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.22 { Delivery time stamp indication } Ignore _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.25 { Disclosure of other recipients } Disclose all recipients _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.26 { DL expansion history indication } Ignore _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.29 Expiry date indication Display in message heading { Message invalid after: > } _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.31 { Forwarded IP\(hymessage indication } { the PTLXAU shall build a message heading for each IP\(hymessage contained in the body part } _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.32 Grade of delivery selection National matter _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.34 Implicit conversion { Convert to telex according to Rec. X.408 } _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.35 Importance indication Display in message heading { Message importance: > } _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.37 IP\(hymessage identification display in message heading Message reference > _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.38 Language indication Ignore _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.39 Latest delivery designation National matter _ .TE .nr PS 9 .RT .ad r \fBTable B\(hy1/F.421 [1T6.421], p.\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [2T6.421]\fR .ce TABLE\ B\(hy1/F.421\ \fI(cont.)\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(36p) | cw(68p) | cw(62p) | cw(62p) . { References Rec. F.400 Annex B } Elements of message Action to be taken Examples _ .T& cw(36p) | lw(68p) | lw(62p) | cw(62p) . B.41 Message identification Ignore _ .T& cw(36p) | lw(68p) | lw(62p) | cw(62p) . B.45 Multi\(hydestination delivery { Deliver the message to all recipients } _ .T& cw(36p) | lw(68p) | lw(62p) | cw(62p) . B.46 Multi\(hypart body { Messages containing not supported body parts are not delivered. Send back a non\(hydelivery notification to the originator } _ .T& cw(36p) | lw(68p) | lw(62p) | cw(62p) . B.47 Non\(hydelivery notification { The PTLXAU shall generate a delivery report } _ .T& cw(36p) | lw(68p) | lw(62p) | cw(62p) . B.48 { Non\(hyreceipt notification request } Ignore _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.52 Obsoleting indication Obsoletes: > _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.54 { Original encoded information types indication } Ignore _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.55 Originator indication Ignore _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.56 { Originator request alternate recipient } National matter _ .T& 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: > TO: > CC: > CC: > } _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.63 Probe National matter _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.67 { Receipt notification request indication } Ignore _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.72 Reply request indication Display in message heading { Reply > requested > by > sender } _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.73 { Replying IP\(emmessage indication } Display in message heading Reply to message: > _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.80 Sensibility indication { Display in message heading just above text of body } _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.88 Subject indication { Display in message heading just above text of body } Subject: > _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.89 Subsmission time stamp Display in message heading Submitted: > > UTC _ .T& cw(36p) | lw(68p) | lw(62p) | lw(62p) . B.90 Typed body Ignore .TE .LP \fINote\fR \ \(em\ The symbol\ > equals a space. .nr PS 9 .RT .ad r \fBTable B\(hy1/F.421 [2T6.421], p.\fR .sp 1P .RT .ad b .RT .LP .bp .ce 1000 ANNEX\ C .ce 0 .ce 1000 (to Recommendation F.421) .sp 9p .RT .ce 0 .ce 1000 \fBIPM message to telex\fR .sp 1P .RT .ce 0 .PP General layout of a message originated by an IPM service user and delivered by the PTLXAU to a telex subscriber. .sp 1P .RT .LP .rs .sp 18P .ad r \fBTable, p.\fR .sp 1P .RT .ad b .RT .PP Display of the originator O/R address related information to the telex user in the message heading: .LP a) Two\(hystage selection: .LP FROM: | (raGIV | (rafrancois .LP FROM: | (ra SUR | (ramaurer .LP FROM: | (ra ORG | (raswiss\(raptt .LP FROM: | (ra ADM | (raarcom400 .LP FROM: | (ra CTN | (rach .LP b) \fIOne\(hystage selection\fR | .LP FROM: | (ra(F.74 A/B) .LP .rs .sp 6P .ad r BLANC .ad b .RT .LP .bp .ce 1000 ANNEX\ D .ce 0 .ce 1000 (to Recommendation F.421) .sp 9p .RT .ce 0 .ce 1000 \fBTelex message to IPM\fR .sp 1P .RT .ce 0 .ce 1000 (Two\(hystage selection) .ce 0 .PP General layout of a message originated by a telex subscriber using the two\(hystage selection, submitted to the PTLXAU for delivery to the IPM service. .sp 1P .RT .LP .rs .sp 22P .ad r \fBTable, p.\fR .sp 1P .RT .ad b .RT .LP .rs .sp 12P .ad r BLANC .ad b .RT .LP .bp .sp 2P .LP \fBRecommendation\ F.422\fR .RT .sp 2P .ce 1000 \fBMESSAGE\ HANDLING\ SERVICES:\fR .EF '% Fascicle\ II.6\ \(em\ Rec.\ F.422'' .OF '''Fascicle\ II.6\ \(em\ Rec.\ F.422 %' .ce 0 .ce 1000 \fBINTERCOMMUNICATION\ BETWEEN\ THE\ IPM\ SERVICE\fR .ce 0 .sp 1P .ce 1000 \fBAND\ THE\ TELETEX\ SERVICE\fR .ce 0 .sp 1P .PP 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. .sp 1P .RT .sp 2P .LP The\ CCITT, .sp 1P .RT .sp 1P .LP \fIconsidering\fR .sp 9p .RT .PP (a) the need for public message handling services; .PP (b) the strategic and commercial importance of standardization of message handling services; .PP (c) the urgent need for intercommunication arrangements for existing telematic services, and other services with public message handling services; .PP (d) the need for a clear distinction between the responsibilities to be allocated to service providers and those of subscribers and/or users; .PP (e) the need for establishing international compatibility between different messaging systems; .PP (f) the growth of the installed base of terminals and personal computers with the ability to access message handling systems; .PP (g) that several F\(hyseries Recommendations describe public message handling services; .PP (h) that certain X and T\(hyseries Recommendations cover relevant aspects of systems used for the provision of messaging services; .PP (i) that the F.200 series and appropriate T\(hyseries Recommendations define, respectively, the service and technical requirements for the teletex service; .PP (j) that Recommendation T.330 defines the technical requirements of the intercommunication between the IPM service and the teletex service, .sp 1P .LP \fIunanimously declares the view\fR .sp 9p .RT .PP 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. .sp 1P .ce 1000 \fBTABLE\ OF\ CONTENTS\fR .ce 0 .sp 1P .sp 2P .LP 1 \fIPurpose and scope\fR .sp 1P .RT .sp 1P .LP 2 \fIDescription of intercommunication\fR .sp 9p .RT .sp 1P .LP 3 \fIRequirements for intercommunication\fR .sp 9p .RT .sp 1P .LP 4 \fIElements of service\fR .sp 9p .RT .sp 1P .LP 5 \fIQuality of service\fR .sp 9p .RT .sp 1P .LP \fIAnnex\ A\fR \ \(em\ Abbreviations .bp .sp 9p .RT .sp 2P .LP \fB1\fR \fBPurpose and scope\fR \v'3p' .sp 1P .RT .PP 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. .PP The technical requirements for this intercommunication are specified in Recommendation\ T.330. .PP 1.2 Teletex users who are registered users of the IPM service are not covered by this Recommendation (see Recommendation\ F.420). .PP 1.3 For intercommunication the following principles apply: .LP 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 \(sc\ 4. .LP b) Where two Administrations have an IPM service, the preferred method of international intercommunication is through the use of these services. .LP 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. .PP Figure 1/F.422 shows the environment for the service intercommunication described in this Recommendation. .LP \fB2\fR \fBDescription of intercommunication\fR .sp 1P .RT .sp 2P .LP 2.1 \fIResponsibility boundaries\fR .sp 1P .RT .sp 1P .LP 2.1.1 \fIIPM service to teletex service\fR .sp 9p .RT .PP 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). .RT .sp 1P .LP 2.1.2 \fITeletex service to IPM service\fR .sp 9p .RT .PP 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. .PP Identification of the calling teletex terminal is a national matter. .RT .PP 2.1.3 All notifications except receipt notifications are the responsibility of the PTTXAU. .sp 9p .RT .LP .rs .sp 12P .ad r \fBFigure 1/F.422, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 2.2 \fILocation of the PTTXAU\fR \v'3p' .sp 9p .RT .PP 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. .LP .rs .sp 14P .ad r \fBFigure 2/F.422, p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP \fB3\fR \fBRequirements for intercommunication\fR \v'3p' .sp 1P .RT .PP 3.1 The intercommunication between IPM service and teletex service and vice versa is based on store\(hyand\(hyforward principles. There is neither interactive nor direct user\(hyto\(hyuser communication. .sp 1P .LP 3.2 \fIIntercommunication from IPM service to teletex service\fR \v'3p' .sp 9p .RT .PP 3.2.1 When sending an IPM user originated message to a teletex terminal equipment the following conditions may occur: .LP a) the message can be delivered without conversion; .LP b) the message can be delivered with conversion; .LP c) message delivery will not occur because of conversion prohibition; .LP d) conversion should not be carried out since loss of information beyond that specified in Recommendation\ X.408 will occur. .PP 3.2.2 Recommendation F.420 applies between the IPM UA and the PTTXAU. .PP 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. .PP 3.2.4 The PTTXAU will format IP\(hymessages into documents suitable for delivery to teletex terminal equipment in accordance with Recommendation\ F.200. .PP 3.2.5 The call identification line (CIL) will contain sufficient information to advise the teletex user of the network address of the PTTXAU. .PP 3.2.6 The header of the message will contain sufficient information in human readable form regarding the originating IPM user. .sp 1P .LP 3.3 \fIIntercommunication from teletex service to IPM service\fR \v'3p' .sp 9p .RT .PP 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. .bp .PP 3.3.2 This formatted header is mapped by the PTTXAU into the envelope and heading necessary for delivering the IP\(hymessage 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. .LP .rs .sp 17P .ad r \fBFigure 3/F.422, p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP \fB4\fR \fBElements of service\fR \v'3p' .sp 1P .RT .PP 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. .sp 2P .LP \fB5\fR \fBQuality of service\fR \v'3p' .sp 1P .RT .PP 5.1 Provision of intercommunication should maintain as much as possible the quality of each service. .PP 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. .PP 5.3 The PTTXAU will recover from an intercommunication failure with teletex terminal equipment using the document retransmission method. .PP 5.4 If non\(hydelivery 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. .LP .rs .sp 6P .ad r BLANC .ad b .RT .LP .bp .ce \fBH.T. [T1.422]\fR .ce TABLE\ 1/F.422 .ce \fBElements of service\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS 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 } _ .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.5\ Autorizing users indication X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.6\ Auto\(hyforwarded indication X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.8\ { Blind copy recipient indication } X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.9\ { Body part encryption indication } X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.12 Content type indication X X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.13 Conversion prohibition X X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.15 Converted indication X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.18 Cross referencing indication X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.21 Delivery notification X N/A X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.22 { Delivery time stamp indication } X X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.25 { Disclosure of other recipients } X X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.26 { DL expansion history indication } X X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.29 Expiry date indication X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.31 { Forwarded IP\(hymessage indication } X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.32 Grade of delivery selection X X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.34 Implicit conversion N/A X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.35 Importance indication X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.37 IP\(hymessage identification X X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.38 Language indication X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.39 Latest delivery indication N/A X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.41 Message identification X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.45 Multi\(hydestination delivery X N/A .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.46 Multi\(hypart body X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.47 Non\(hydelivery notification N/A X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.48 { Non\(hyreceipt notification request } X N/A .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.52 Obsoleting indication X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.54 { Original encoded information types indication } X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.55 Originator indication X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.56 { Originator request alternate recipient } X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.62 { Primary and copy recipients indication } X X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.72 Reply request indication X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.73 { Replying IP\(hymessage indication } X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.80 Sensitivity indication X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.88 Subject indication X X .T& cw(30p) | lw(108p) | cw(30p) | cw(30p) | cw(30p) . B.89 { Submission time stamp indication } X X .TE .LP \fINote\fR \ \(em\ Definitions of the Elements of Service are contained in Recommendation F.400, Annex B. .nr PS 9 .RT .ad r \fBTableau 1/F.422 [T1.422], p.18\fR .sp 1P .RT .ad b .RT .LP .sp 2 .bp .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation F.422) .sp 9p .RT .ce 0 .ce 1000 \fBAbbreviations\fR .sp 1P .RT .ce 0 .ce \fBH.T. [T2.422]\fR .ce .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(30p) | lw(120p) . AU Access Unit .T& lw(30p) | lw(120p) . CIL Call Identification Line .T& lw(30p) | lw(120p) . DL Distribution List .T& lw(30p) | lw(120p) . IPM Interpersonal Messaging .T& lw(30p) | lw(120p) . MHS Message Handling System .T& lw(30p) | lw(120p) . MT Message Transfer .T& lw(30p) | lw(120p) . MTS Message Transfer System .T& lw(30p) | lw(120p) . N/A Not Applicable .T& lw(30p) | lw(120p) . O/R Originator/Recipient .T& lw(30p) | lw(120p) . PTTXAU Public Teletex Access Unit .T& lw(30p) | lw(120p) . TTX Teletex .T& lw(30p) | lw(120p) . UA User Agent .TE .LP \fINote\ 1\fR \ \(em\ For a glossary of terms see Annex A to Recommendation F.400. .LP \fINote\ 2\fR \ \(em\ For references see Recommendations F.400\ and\ F.401. .nr PS 9 .RT .ad r \fBTable [T2.422], p.\fR .sp 1P .RT .ad b .RT .LP .sp 20 .bp .LP \fBMONTAGE: PAGE 146 = PAGE BLANCHE\fR .sp 1P .RT .LP .bp