5i' MONTAGE: REC. F.400 en t | te de cette page Recommendation F.401 MESSAGE HANDLING SERVICES: NAMING AND ADDRESSING FOR PUBLIC MESSAGE HANDLING SERVICES 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 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; (i) that unambiguous names are required for the exchange of messages; (j ) that naming conventions are necessary for worldwide compatible services; unanimously declares the view that the naming and addressing requirements specified in this Recommendation should be applied for the provision of pub- lic message handling services. CONTENTS 1 Purpose and scope 2 Naming and addressing in message handling 2.1 O/R addresses 2.2 Distribution list names 2.3 Directory names 3 Length of attributes 4 Principles for the allocation of O/R names and O/R addresses 5 Use of O/R names 5.1 General 5.2 Character repertoires 5.3 Specific rules 5.4 Support of forms of O/R addresses 6 References Annex A - Abbreviations Appendix I - List of Alpha-2 country codes 1 Purpose and scope This Recommendation specifies naming and addressing aspects for public message handling services which are described in other Recommendations of the F-series. It also establishes some princi- ples for the allocation of O/R addresses. 2 Naming and addressing in message handling Naming and addressing in message handling have to ensure that users can define the source and the destination of messages in an unambiguous way. The organizational mapping of message handling systems, and the structure of management domains (see Recommendation F.400/X.400), together with a set of naming conven- tions, are the means to establish a uniform and compatible environ- ment for the exchange of messages between any users of the message handling environment. Names and addresses are allocated by the responsible naming authority. In message handling systems (MHS), the principal entity that requires naming is the user (the originator and the recipient of messages). In addition distribution lists (DLs) have names for their use in the context of MHS. Users of MHs and DLs are identi- fied by O/R names. (The prefix "O/R" recognizes the fact that the user can be acting as either the originator or the recipient of a message). An O/R name comprises a directory name, an O/R address or both. Every user or DL has one or more O/R names. 2.1 O/R addresses An O/R address contains information that enables the MHS to identify a user to deliver a message or return a notification to him. DLs are also identified by an O/R address. An O/R address is comprised of a set of information called attributes. Recommendation X.402 specifies a set of standard attri- butes from which O/R addresses can be constructed. Standard attri- butes, the structure of attribute lists and their syntax and seman- tics are defined in Recommendation X.402. In addition to standard attributes, and to cater for existing messaging systems, there are domain defined attributes whose syntax and semantics are specified by management domains. They are applicable for an interim period. Various forms of O/R addresses are defined, each serving its own purpose. These forms and their purpose are as follows: - Mnemonic O/R address : Provides a user-friendly means of identifying users in the absence of a directory. It may also be 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 identi- fying users with numeric keypads. - Postal O/R address : Provides a means of identi- fying originators and recipients of messages and notifications, for physical delivery. 2.1.1 Mnemonic O/R address This form of O/R address provides addresses that mnemonically identifies a user or a DL relative to the Administration Management Domain (ADMD) through which the user is accessed. At least one of the conditional attributes following the domain name(s) has to be present. - Country name - Administration domain name - [Private domain name] - [Organization name] - [Organizational unit name] - [Personal name] - [Common name] - [[Domain defined attributes]] Note - Attributes in square brackets are conditional. Double square brackets indicate an attribute not belonging to the standard attribute list. 2.1.2 Terminal O/R address This form of O/R address provides a means for addressing a terminal with its network address, conditionally with the country name, the domain name(s), a terminal identifier and domain defined attributes. - [Country name] - [Administration domain name] - [Private domain name] - Network address - [Terminal identifier] - [Terminal type] - [[Domain defined attributes]] Note 1 - Attributes in square brackets are conditional. Dou- ble square brackets indicate an attribute not belonging to the standard attribute list. Note 2 - Domain defined attributes shall be present only if the country name and the administration domain name are present. The network address is composed of digits from the X.121 numbering plan (including escape codes) or the E.163/E.164 number- ing plan. The conditional terminal identifier might be, for example, a telex answerback string or a teletex terminal identifier. The conditional terminal type might be, for example, a telex, a teletex, a G3 facsimile, a G4 facsimile, an IA5, and a videotex terminal. 2.1.3 Numeric O/R address This form of O/R address provides addresses that can be entered from devices equipped only with numeric keypads. It identi- fies numerically a user relative to the ADMD through which the user is accessed. - Country name - Administration domain name - [Private domain name] - Numeric user identifier - [[Domain defined attributes]] Note 1 - Attributes in square brackets are conditional. Dou- ble square brackets indicate an attribute not belonging to the standard attribute list. Note 2 - Numeric values are assumed for all attributes. Note 3 - This form could also be used for a videotex user number. 2.1.4 Postal O/R address This form of O/R address provides for the identification of a user by means of his postal addresss, together with the country name(s), and the domain name(s), and the PD service name through which he is accessed. See also Recommendation F.415. Version 1 - Unformatted postal O/R address : - Physical delivery country name - Country name - Administration domain name - [Private domain name] - [Physical delivery service name] - Postal code - Unformatted postal address Sufficient address components have to be supplied in the unformatted postal address in order to enable the PD service to route, distribute and deliver the physical message properly. Version 2 - Formatted postal O/R address : - Physical delivery country name - Country name - Administration domain name - [Private domain name] - [Physical delivery service name] - Postal code - Set of formatted postal address attributes There is no defined order in the set of formatted postal address attributes. These attributes are: - Postal O/R address components : a) [Physical delivery personal name] b) [Physical delivery organization name] - Physical delivery address components : a) [Street address] b) [P.O. box address] c) [Poste restante address] d) [Unique postal name] - Physical delivery office address components : a) Physical delivery office name b) [Physical delivery office number] c) [Local postal attribute] - Other postal address components : a) [Extension of postal O/R address components] b) [Extension of physical delivery address com- ponents] Note - Attributes in square brackets are conditional. Sufficient attributes have to be provided in order to enable the PD service to route, distribute and deliver the physical mes- sage properly. For the description of formatted postal O/R address attributes see Annex A/F.400 and for the length see S 3. 2.2 Distribution list names In the context of message handling, names of distribution lists (making use of the common name attribute) are used to iden- tify the point of expansion of a message using a distribution list which contains a set of O/R addresses or further distribution list names (see Recommendation F.400). Care should be taken in the choice of distribution list names to ensure that users are aware that they are addressing a distribu- tion list. Note - For naming of distribution lists the attribute "Common Name" may be used. Names of distribution lists should clearly indi- cate their purpose. 2.3 Directory names In the context of message handling a directory name can be used to retrieve the required O/R address from a directory (see Recommendations F.400 and F.500). The directory may be provided by local functions. 3 Length of attributes The coding is specified in the Recommendations of the X.400 series. The O/R address shall allow the following information: - Country name The Alpha-2 country code listed in Appendix I or the DCC from Recommendation X.121 is used as the numeric country name. Maximum 3 characters. - Physical delivery country name The same conditions apply as for country name. - Administration domain name Maximum 16 characters. Numeric O/R address form assumes allocation of numeric administration domain names. - Private domain name Maximum 16 characters. - Physical delivery service name Maximum 16 characters - Organization name Maximum 64 characters - Organizational unit(s) Maximum 32 characters each Note - At least one organizational unit should be sup- ported on the sending side. - Personal name Maximum is the sum of the maxima of the parts (64 charac- ters). a) Surname - maximum 40 characters. b) Given name - maximum 16 characters. c) Initials (optional) - maximum 5 characters (for further study). d) Generation qualifier (optional) - maximum 3 characters. - Distribution list name Maximum of the common name applies. - Common name Maximum 64 characters. - Domain defined attributes Maximum four separate attributes, maximum length for "type" 8 and for "value" 128 characters. - Network address Maximum 14 + 1 digits, including the prefix (see Recommendation X.121). Note - The classification and maximum value may change to accommodate other addressing schemes. - Terminal identifier Maximum 24 characters. - Unformatted postal address Up to 6 lines with a maximum of 30 characters each. In the case of transit mail the last line is reserved for the name of the country of the final physical destinaton (see Note 1). - Formatted postal address Formatted postal address attributes These attributes and their constraints are: (for the descrip- tion of these attributes see Annex A/F.400) - Postal O/R address components | see Note 2) Physical delivery personal name (see Note 3) 30 characters (see Note 1) Physical delivery organization name (see Note 3) 30 characters (see Note 1) - Physical delivery address components | see Note 2) Street address 30 characters (see Note 1) P.O. box address 30 characters (see Note 1) Poste restante address 30 characters (see Note 1) Unique name 30 characters (see Note 1) - Physical delivery office address components Physical delivery office name x characters (see Notes 1 and 4) Physical delivery office number y characters (see Notes 1 and 4) Local postal attributes z characters (see Notes 1 and 4) - Other postal address components Extension of O/R address components (see Note 5) 30 characters (see Note 1) Extension of physical delivery address components (see Note 6) 30 characters (see Note 1) The overall constraints are 6 lines of attributes with a max- imum of 30 characters in each line. In the case of transit mail the last line is reserved for the name of the receiving country of the final physical destination. Note 1 - The number of characters specified refers to charac- ters to be printed (including spaces). Note 2 - At least one of the following attributes should be used. Note 3 - Physical delivery personal name and physical delivery organization name are free form names and have different length from personal name and organization name. Note 4 - These attributes have to be printed in one line, in some countries together with the postal code. Thus x + y + z is a maximum of 30 characters including the delimiting spaces and the postal code if printed in the same line. Note 5 - May be used to extend the postal O/R address com- ponents. Note 6 - May be used to extend the physical delivery address components. 4 Principles for the allocation of O/R names and O/R addresses 4.1 The naming authority of the country responsible for administration domain names will ensure the designation of an unam- biguous name to each ADMD of message handling services in that country. 4.2 Each ADMD is responsible for the administration of names for private management domains associated with it. Note - For PRMDs intercommunicating with more than one ADMD, agreement between all the ADMDs concerned is necessary for an unam- biguous name of the PRMD. 4.3 Each management domain (MD) is responsible for allocating unambiguous addresses to users below the level of the MD name(s) for the purpose of using message handling services. 4.4 A distribution list only shall be given a name which is clearly indicating to the user its intent. Names or O/R addresses shall only be included in a publicly accessible distribution list when the permission of the owner of the information is given and national rules for security are respected. 5 Use of O/R names 5.1 General With the help of O/R names a user can send messages via the MHS. Users may get support from their user agent in the use of O/R names. The latter is a local matter. 5.2 Character repertoires The character repertoire allowed in O/R names are either printable, numeric or teletex repertoires (for more detail see Recommendation X.402). The printable character repertoire is shown in Table 1/F.401. The numeric character repertoire is comprising the digits 0 - 9 and space, and is a subset of the printable character repertoire. For the teletex repertoire see Recommendation T.61. In general the teletex repertoire may also be used internationally. All name attributes that may use the teletex repertoire shall, when sent internationally, be conveyed together with the equivalent attribute(s) using the repertoire specified in Table 1/F.401. The use of an extended character repertoire within a manage- ment domain is a local matter. 5.3 Specific rules Rules for postal O/R addresses, see SS 2 and 3 and Recommendation F.415. Management domains will not allow O/R names, that differ only by the number of "space" characters, either at the beginning or the end of any of their attributes, to identify different users. Additionally MDs will not consider an O/R address attribute to identify different users when the attribute contains more than one word separated by one or more "space" characters. MDs will not allow O/R names, that differ only by small letter/capital letter distinctions, to identify different user. 5.4 Support of forms of O/R addresses Each MHS shall support all the name address forms in the incoming direction for transitting purposes. It is the decision of the management of a domain which name forms are allocated to the users of that domain. In the outgoing direction the originating domain needs to use the name forms the destination domain applies. The way in which names are input by or presented to the subscriber is a local matter. H.T. [T1.401] TABLE 1/F.401 Printable character repertoire for O/R names _____________________________________________ Designation Graphic representation _____________________________________________ Capital letters A, B, ..., Z Small letters a, b, ..., z Digits 0, 1, ..., 9 Space (space) Apostrophe ' Left parenthesis ( Right parenthesis ) Plus sign + Comma , Hyphen - Full stop . Solidus / Colon : Equals sign = Question mark ? _____________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note - According to Recommendation X.208 this repertoire is called a Printable String type. All these characters are available in ITA2 (as far as letters are concerned, only in upper or lower case). Table 1/F.401 [T1.401], p. 6 References Recommendation F.400 Message handling - System and service overview Recommendation F.410 Message handling services - The public message transfer service Recommendation F.415 Message handling services - Intercommunication with public physical delivery services Recommendation F.420 Message handling services - The public interpersonal messaging service Recommendation F.421 Messsage handling services - Intercommunication between the IPM service and the telex service Recommendation F.422 Message handling services - Intercommunication between the IPM service and the teletex service Recommendations of the X.400 series Message handling - System and service overview Recommendation T.61 Character repertoire and coded charac- ter sets for the international teletex service Recommendations of the X.500 series The directory - Overview of concepts, models and services Recommendation F.500 International public directory ser- vices Recommendation X.121 International numbering plan for pub- lic data networks Recommendation E.163 Numbering Plan for the international telephone service Recommendation E.164 Numbering Plan for the ISDN Era ISO 3166 Codes for the representation of names of countries ANNEX A (to Recommendation F.401) Abbreviations H.T. [T2.401] ______________________________________________________________________ ADMD { Administration Management Domain } DCC Data Country Code DL Distribution List IA5 International Alphabet 5 IPM Interpersonal Messaging ITA2 { International Telegraph Alphabet 2 } MD Management Domain MH Message Handling MHE Message Handling Environment MHS Message Handling System MT Message Transfer O/R Originator/Recipient P.O. Post Office PD Physical Delivery PRMD Private Management Domain RPOA { Recognized Private Operating Agency } UPU Universal Postal Union ______________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note - For a glossary of terms see Annex A of Recommendation F.400. Table [T2.401], p. APPENDIX I (to Recommendation F.401) List of Alpha-2 country codes .sp 3 Afghanistan AF Albania AL Algeria DZ American Samoa AS Andorra AD Angola AO Anguilla AI Antarctica AQ Antigua and Barbuda AG Argentina AR Aruba AW Australia AU Austria AT Bahamas BS Bahrain BH Bangladesh BD Barbados BB Belgium BE Belize BZ Benin BJ Bermuda BM Bhutan BT Bolivia BO Botswana BW Bouvet Island BV Brazil BR British Indian Ocean Territory IO British Virgin Islands VG Brunei Darussalam BN Bulgaria BG Burkina Faso BF Burma BU Burundi BI Byelorussian SR BY Cameroon CM Canada CA Cape Verde CV Cayman Islands KY Central African Republic CF Chad TD Chile CL China CN Christmas Islands CX Cocos (Keeling) Islands CC Colombia CO Comoros KM Congo CG Cook Islands CK Costa Rica CR C | te d'Ivoire CI Cuba CU Cyprus CY Czechoslovakia CS Denmark DK Djibouti DJ Dominica DM Dominican Republic DO East Timor TP Ecuador EC Egypt EG El Savador SV Equatorial Guinea GQ Ethiopia ET Faeroe Islands FO Falkland Islands (Malvinas) FK Fiji FJ Finland FI France FR French Guiana GF French Polynesia PF French Southern Territories TF Gabon GA Gambia GM German Democratic Republic DD Germany, Federal Republic of DE Ghana GH Gibraltar GI Greece GR Greenland GL Grenada GD Guadeloupe GP Guam GU Guatemala GT Guinea GN Guinea-Bissau GW Guyana GY Haiti HT Heard and McDonald Islands HM Honduras HN Hong Kong HK Hungary HU Iceland IS India IN Indonesia ID Iran, Islamic Republic of IR Iraq IQ Ireland IE Israel IL Italy IT Jamaica JM Japan JP Jordan JO Kampuchea, Democratic KH Kenya KE Kiribati KI Korea, Democratic People's Republic of KP Korea, Republic of KR Kuwait KW Lao People's Democratic Republic LA Lebanon LB Lesotho LS Liberia LR Libyan Arab Jamahiriya LY Liechtenstein LI Luxembourg LU Macau MO Madagascar MG Malawi MW Malaysia MY Maldives MV Mali ML Malta MT Martinique MQ Marshall Islands MH Mauritania MR Mauritius MU Mexico MX Micronesia FM Monaco MC Mongolia MN Montserrat MS Morocco MA Mozambique MZ Namibia NA Nauru NR Nepal NP Netherlands NL Netherlands Antilles AN Neutral Zone (between Saudia Arabia and Iraq) NT New Caledonia NC New Zealand NZ Nicaragua NI Niger NE Nigeria NG Niue NU Norfolk Island NF Northern Mariana Islands MP Norway NO Oman OM Pakistan PK Palau PW Panama PA Papua New Guinea PG Paraguay PY Peru PE Philippines PH Pitcairn PN Poland PL Portugal PT Puerto Rico PR Qatar QA Reunion RE Romania RO Rwanda RW St. Helena SH St. Kitts-Nevis KN Saint Lucia LC St. Pierre and Miquelon PM Saint Vincent and the Grenadines VC Samoa WS San Marino SM Sao Tome and Principe ST Saudi Arabia SA Senegal SN Seychelles SC Sierra Leone SL Singapore SG Solomon Islands SB Somalia SO South Africa ZA Spain ES Sri Lanka LK Sudan SD Suriname SR Svalbard and Jan Mayen Islands SJ Swaziland SZ Sweden SE Switzerland CH Syrian Arab Republic SY Taiwan, Province of China TW Tanzania, United Republic of TZ Thailand TH Togo TG Tokelau TK Tonga TO Trinidad and Tobago TT Tunisia TN Turkey TR Turks and Caicos Islands TC Tuvalu TV Uganda UG Ukrainian SSR UA United Arab Emirates AE United Kingdom GB United States US United States Minor Outlying Islands UM Uruguay UY USSR SU Vanuatu VU Vatican City State (Holy See) VA Venezuela VE Viet Nam VN Virgin Islands, U.S VI Wake Islands WK Wallis and Futuna Islands WF Western Sahara EH Yemen YE Yemen, Democratic YD Yugoslavia YU Zaire ZR Zambia ZM Zimbabwe ZW Source: ISO 3166 Current edition (1981 plus amendments up to 1987) at time of print- ing. The latest published edition from ISO should be applied. BLANC Recommendation F.410 MESSAGE HANDLING SERVICES: THE PUBLIC MESSAGE TRANSFER 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 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 Recommenda- tion should be applied for the provision of the public message transfer service internationally. CONTENTS 1 Purpose and scope 1.1 General 1.2 Message handling systems used in the provision of MT service 2 MT service 2.1 General service requirements 2.2 Message transfer service features 2.2.1 Introduction 2.2.2 The basic message transfer service 2.2.3 Optional user facilities in the MT service 2.2.4 Naming and addressing 3 Operation of the service 3.1 General 3.2 Message transfer 4 Quality of service 4.1 Message status 4.2 Responsibility for messages 4.3 Model of delivery and notification times 4.4 Message transfer time targets 4.5 Delivery notification time targets 4.6 Error protection 4.7 Availability of service 4.8 Minimum storage capacity 5 Networks requirements 5.1 General 5.2 Network requirements for international interconnection 5.3 Network requirements for service access 6 Use of MT service within CCITT defined telematic services Annex A - Abbreviations Annex B - MT elements of service for 1984 systems 1 Purpose and scope 1.1 General This Recommendation specifies the general, operational and quality of service aspects of the public international message transfer service. This type of message handling service is an international telecommunication service offered by Administrations, enabling sub- scribers' user agents to submit standardized classes of messages to message transfer agents for their transfer to another message transfer agent in the same Administration's domain, in another Administration's domain, or to private domains, via telecommunica- tion networks using store and forward techniques. The message transfer service also may transfer messages sub- mitted through a message store, and delivered to a message store, and to and from access units to other services. Locally provided functions, for which communication with other user agents or message transfer agents is not required, are nor covered by CCITT Recommendations. The message transfer (MT) service enables subscribers to request a variety of features to be performed during the transfer of messages. Some features are inherent in the basic MT 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. Elements of service belonging to the basic message transfer service and essential optional user facilities are to be made available internationally by Administrations. MT service may be provided using any physical network. MT ser- vice 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 MT service are defined in the X.400 series of Recommendations. The service definition is contained in S 2. Sections 3 and 4 describe the operation of the service and quality of service, and network requirements are given in S 5. 1.2 Message handling systems used in the provision of MT service 1.2.1 1984 implementations This 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 of technical Recommendations. It is recognized however that for some time after the publication of this Recommendation, the majority of implementations of MT 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 The elements of service available for message handling ser- vices are listed and classified in Recommendation F.400. Annex B/F.400 provides a list of all the elements of service (called Service Elements in 1984) for MT service from the 1984 X.400 Recommendation. In addition the classifications of each ele- ment 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 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 implementa- tions can make use of this service Recommendation in most cases. Other differences between 1988 and 1984 are of two types, new ele- ments of service that are classified as essential, and old (mean- ing 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 classifica- tion to any 1984 elements of service. In both cases to allow for 1984 implementations to be used for the provision of pubic MT ser- vice as described in this Recommendation, a grace period of 8 years is provided for Administrations to upgrade their implementations in this respect to the 1988 technical Recommendations. 1.2.3 Name forms The specifications 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 MT service, 1988 ADMD implementations must 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 MT service 2.1 General service requirements 2.1.1 The fundamental ability of the MT Service is to provide for the transfer of messages submitted by other services subscrib- ing to the MT service. These other services may submit messages from their user agents, if they are services that follow the X.400 series of Recommendations. Services may also access the MT service from standardized access units. Messages may also be transferred to and from message stores. The access units and message stores are not part of the MT service. Conversion of messages when different codings and other formats are used may be provided by the MT ser- vice. 2.1.2 The public MT service will be provided by Administra- tions using systems that conform to the X.400 series Recommenda- tions. Management domains (MDs) are defined for the purpose of responsibilities 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 administation management domains through CCITT standardized public data transmission services. Each Administration will designate one or more MTAs in its management domain as international access points to the MT service. 2.1.4 Different classes of messages may be exchanged through this service. Some classes of messages may be standardized by CCITT Recommendations, such as F.420. Other classes of messages may also be transferred, provided that the format adheres to the appropriate X.400 series or Recommendations. 2.1.5 An Administration may provide different methods of access to the MT service. The possible methods are: 1) from a subscribing service's user agent, message store, or access unit; 2) from an MTA in a private management domain. 2.1.6 Each Administration is responsible for the national access to its management domain. 2.1.7 The characteristics of the direct interfaces to the MT service, or between a private domain and the MT service are a national matter, although they should generally conform to the X.400 series of Recommendations. Interworking with postal systems, or other physical delivery systems, should be in accordance with F.415. 2.1.8 The national implementation of the MT service may pro- vide intercommunication of subscribing services with other telematic services such as telex, teletex, facsimile and videotex. When implemented, the interface between the MT service and the other services shall be according to relevant CCITT Recommenda- tions. Intercommunication may also be provided to a physical delivery system. 2.1.9 As the service is providing indirect communication, cases of non-delivery of the message to the intended recipient may occur. The MT service provides for non-delivery notification and, as an optional user facility, for delivery notification. 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 sender and recipient have different and conflict- ing requirements, the sender's requirements shall take precedence (e.g., content type conversion or redirection control). 2.1.13 Management domains shall relay messages even if some additional optional user facilities are not supported by that domain. 2.2 Message transfer service features 2.2.1 Introduction Recommendation F.400, S 19, defines elements of service which are available in the MT service and are classified as either belonging to the basic service or as MT optional user facilities. Elements of service comprising the basic MT 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. In the MT service there is the following grouping of elements of service: 1) basic service which corresponds with the basic elements of service listed in Table 4/F.400; 2) optional user facilities, which correspond to the MT optional user facilities listed in Table 5/F.400. Basic features are inherent in the service. Optional user facilities may be selected on a per-message basis or for an agreed contractual period of time. 2.2.2 The basic message transfer service The basic MT service shall be implemented according to the requirements of CCITT Recommendation X.411. The basic MT service enables UAs to access and be accessed by the MTS in order to exchange messages. Each message is assigned a unique message refer- ence identification. If a message cannot be delivered, the ori- ginating UA is informed. To facilitate meaningful communication, a UA may specify the types of encoded information that can be con- tained in messages delivered to it. The content type, the original encoded information types, the time of submission and delivery and whether conversion occurred are indicated for each message. The elements of service comprising the basic MT service are listed in Recommendation F.400, Table 4/F.400. 2.2.3 Optional user facilities in the MT service Two classes of optional user facilities are available in the MT services. The first class is selectable on a per-message basis. The second class may be provided to the subscribing service when agreed to over a contractual period of time. The classes are described and cited in Recommendation F.400 (S 19.3, and Table 5/F.400) and are available in the service based on the MT service. 2.2.4 Naming and addressing Naming and addressing as used in the MT service is described in overview in Recommendation F.400, S 12. The rules for naming and addressing in an Administration Management Domain are given in Recommendation F.401. 3 Operation of the service 3.1 General 3.1.1 The MT service provides that messages can be sent, transferred, delivered and received using fully automatic pro- cedures. Manual delivery of messages can be provided in the case of interworking with postal systems, and is described in Recommendation F.415. 3.1.2 Messages are prepared by subscribers services User Agents/Access Units or by User Agents/Access Units in other manage- ment domains. 3.1.3 Each Administration providing the MT service should validate its subscribers identities, at the time of access. It should also validate the identity of other Management Domains at their points of access. 3.1.4 Connectivity of the MT service to message transfer in private management domains, which will allow users of these systems to exchange messages, is desirable. This is recognized to be a national matter. If these interconnections are provided, they should take place between management domains in accordance with CCITT Recommendations. 3.1.5 When implicit conversion is provided by the Administra- tion via the message transfer service, the message will be con- verted if necessary, unless prohibited by the originator. The conversion will be in accordance to the rules specified in Recommendation X.408. 3.2 Message transfer Message transfer is initiated when a message is received from a User Agent/Message Store or access unit. Delivery is attempted to the address of the message. The body part of the message will be transferred in the form in which it was received unless conversion has been performed. The results of the transfer attempt may be conveyed by two notifications. - non-delivery notification; - delivery notification. Delivery notification may be given to the originating domain by the destination domain to indicate successful delivery. This delivery notification should be provided if requested. Non-delivery notification is automatically originated by the MTS, while delivery notification will be generated by the reci- pients MTA on request of the originator. If non-delivery notifica- tion is prevented, and delivery notification is not requested, no notification is possible. In the case of a message to a teletex terminal, (auto) receipt notification may be returned by the TTXAU. 4 Quality of service 4.1 Message status The unique identification of messages conforming to the requirements of CCITT X.400 series Recommendations enables the sys- tem to provide information about e.g., the status of an IP-message or other class of 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. 4.2 Responsibility for messages The subscribers to the service using the MTS are responsible for the messages in their User Agents/Message Stores. The service using the MT service is responsible for the transfer between the UAs/MSs in that service and the MT service. The Administration providing the MT service is responsible for the message transfer and the optional user facilities performed within its management domain and for messages coming from or directed to private management domains connected to its management domain, unless other national regulations apply. In international interconnection of ADMDs, the responsibility to deliver passes from managements domains with the message. Administrations should provide assistance to their sub- scribers, with regard to status and tracing of non-delivered mes- sages. Note - The international implications of this are for further study. 4.3 Model of delivery and notification times | see Figure 1/F.410) Figure 1/F.410, p. 4.4 Message transfer time targets The recipient ADMD should force non-delivery notification if it has not been able to transfer the message to the receiving UA before x hours after submission to the originating MTA (or after date and time indicated for deferred delivery), the value of x being dependent on the grade of delivery requested by the origina- tor as shown in Table 1/F.410. H.T. [T1.410] TABLE 1/F.410 _______________________________________________________ Grade of delivery 95% delivered before { Non-delivery forced after x } _______________________________________________________ Urgent 0.75 hours 4 hours Normal 4.0 hours 24 hours Non-urgent 24.0 hours 36 hours _______________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note - Intercommunication with PRMDs is not included in the calcu- lation of the time targets. Table 1/F.410 [T1.410], p. To be able to meet these time targets, a message has to tran- sit a transitting ADMD within y hours, the value of y being depen- dent on the grade of delivery requested by the originator as shown in Table 2/F.410. H.T. [T2.410] TABLE 2/F.410 ________________________________________ Grade of delivery { 95% transitted before y } ________________________________________ Urgent 0.45 hours Normal 2.5 hours Non-urgent 14.5 hours ________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - Time Targets assume that receiving UA is continuously available and excludes cases of Hold for Delivery. Note 2 - Intercommunication with PRMDs is not included in the cal- culation of the time targets. Table 2/F.410 [T2.410], p. 4.5 Delivery notification time targets Non-delivery notifications or requested delivery notifications should be returned on a per-recipient basis, in order not de 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 Table 3/F.410). H.T. [T3.410] TABLE 3/F.410 _______________________________________ Type 95% returned before _______________________________________ ND-notification 0.75 hours D-notification 0.75 hours _______________________________________ | | | | | | | | | | | | | | | Note - Time Targets assume that receiving UA is continuously available and excludes cases of Hold for Delivery. Table 3/F.410 [T3.410], p. 4.6 Error protection Error protection on transmission is provided by the MHS and underlying protocols used in the provision of the MT service. 4.7 Availability of service In principle the MT service should be available continuously. User agents or message stores connected to the MT service should be available for submission or delivery continuously (unless hold for delivery is invoked). 4.8 Minimum storage capacity The storage capacity of the message transfer agent shall be sufficient to provide a high grade of service. Note - This is for further study. 5 Network requirements 5.1 General The MT service is network independent, that is, the basic ser- vice 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. 5.2 Network requirements for international interconnection For an interim period (8 years) in the interest of ease of interconnection of the public international message transfer ser- vice between Administrations public packet switching connections shall be used. This does not preclude Administrations from using different means for this interconnection on a bilateral basis. 5.3 Network requirements for service access Access to the public message transfer service is a national matter. 6 Use of the MT service within CCITT defined telematic ser- vices See relevant F series Recommendations. BLANC ANNEX A (to Recommendation F.410) Abbreviations The following abbreviations are used in this Recommendation. H.T. [T4.410] _________________________________________________________________ A { Additional Optional User Facility } ADMD { Administration Management Domain } E { Essential Optional User Facility } IP Interpersonal MD Management Domain MHS Message Handling System MS Message Store MT Message Transfer MTA Message Transfer Agent MTS Message Transfer System PDS Physical Delivery System PRMD Private Management Domain TTXAU Teletex Access Unit UA User Agent _________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - For a glossary of terms see Annex A of Recommendation F.400. Note 2 - For references see Recommendations F.400 and F.401. Table [T4.410], p. ANNEX B (to Recommendation F.410) MT elements of service for 1984 systems H.T. [T5.410] ________________________________________________________________________ Classification Element of service Basic Optional ________________________________________________________________________ Access management X Alternate recipient allowed E { Alternate recipient assignment } A Content type indication X Conversion prohibition E Converted indication X Deferred delivery E { Deferred delivery cancellation } E Delivery notification E { Delivery time stamp indication } X { Disclosure of other recipients } E Explicit conversion A Grade of delivery selection E Hold for delivery A Implicit conversion A Message identification X Multi-destination delivery E Non-delivery notification X { Original encoded information types indication } X { Prevention of non-delivery notification } A Probe E { Registered encoded information types } X Return of content A { Submission time stamp indication } X ________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T5.410], p. Recommendation F.415 MESSAGE HANDLING SERVICES: INTERCOMMUNICATION WITH PUBLIC PHYSICAL DELIVERY SERVICES 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 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; (i) that there is a requirement for delivery of messages from message handling services in physical form to postal addresses; unanimously declares the view that the requirements specified in this Recommenda- tion should be applied for the provision of intercommunication between public message handling services and public physical delivery services inter nationally. CONTENTS 1 Introduction 2 Scope 3 Features 3.1 General description 3.2 Application 4 Physical rendition 4.1 Basic rendition capabilities 4.2 Rendition of IPM headers 4.3 Additional rendition capabilities 5 Naming and addressing .bp 6 Quality of service 6.1 Service objectives 6.2 Message status 6.3 Delivery and notification times model 6.4 Time targets 6.5 Responsibility for messages 6.6 Handling of incompatibilities 7 User information and support 8 Network requirements 9 Tariff and accounting considerations Annex A - Abbreviations Annex B - Physical rendition details Annex C - Undeliverable mail diagnostics Appendix I - Naming and addressing examples 1 Introduction This Recommendation specifies the general, operational and quality of service aspects of intercommunication between public message handling (MH) services and public physical delivery (PD) services. This intercommunication may be offered by Administrations, enabling subscribers to send messages to one or more recipients though telecommunications means for final delivery in physical form through a PD service. The postal services are general examples of public PD services. The general principles of intercommunication between MH ser- vices and PD services are overviewed in Recommendation F.400, and as a generic capability of the message transfer (MT) service in Recommendation F.410. The capabilities described in this Recommendation cover mes- sage transfer (MT) and interpersonal messaging (PM) service inter- communication with PD services. The output media addressed at this time is hard-copy; other forms of physical delivery media are for further study. The terms used in this Recommendation are defined in Recommendation F.400. Technical specifications and protocols to be used for MH/PD service intercommunication as covered in this Recommendation are defined in the X.400 series Recommendations. 2 Scope The model for MH/PD service intercommunication as covered in this Recommendation is shown in Figure 1/F.415. The actual provi- sions of PD services are not covered in this Recommendation. Figure 1/F.415, p. 3 Features 3.1 General description The MH/PD intercommunication provides MH users with a variety of facilities to be performed in the process of physical rendition, physical transport, and physical delivery of messages. The elements of service available to originating users are grouped into specific categories as shown in Table 1/F.415. H.T. [T1.415] TABLE 1/F.415 MH/PD elements of service ________________________________________________________________________________________________ Category Elements of service F.400 Ref. ________________________________________________________________________________________________ Physical delivery request Requested delivery method B.76 ________________________________________________________________________________________________ { Modes of physical transport and delivery } { Ordinary mail Special delivery EMS (express mail service) Counter collection Counter collection with advice Delivery via Bureaufax service } { B.53 B.81 B.28 B.16 B.17 B.23 } ________________________________________________________________________________________________ Registrations { Registered mail Registered mail to addressee in person } B.70 B.71 ________________________________________________________________________________________________ { Physical delivery notifications } { Undeliverable mail with return of physical message Physical delivery notification by PDS Physical delivery notification by MHS } . B.91 B.58 B.57 ________________________________________________________________________________________________ Physical forwarding { Physical forwarding allowed Physical forwarding prohibited Request for forwarding address } B.59 B.60 B.75 ________________________________________________________________________________________________ { Physical rendition capabilities } { Basic physical rendition Additional physical rendition } B.7 B.2 ________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 1/F.415 [T1.415], p. The definition and classification of MH/PD elements of service are found in Recommendation F.400; base elements of service and optional user facilities are defined. Base capabilities are inherent to the MH/PD service intercommunication and have to be made available internationally by all Administrations supporting this intercommunication. Optional user facilities are selectable by the originator on a per-recipient basis. These are classified as either essential or additional. Essential optional user facilities shall be made available interna- tionally by all Administrations. Additional optional user facili- ties may be made available by some Administrations for national use and internationally on the basis of bilateral agreement. 3.2 Application All MH/PD elements of service apply on a per-recipient basis. Various combinations of elements of service are possible. For example, the elements of service category physical delivery notifi- cations are useable with all modes of physical transport and delivery, with registrations and with physical forwarding categories. The elements of service submission time stamp and delivery time stamp also apply to MH/PD service intercommunication although they are not listed. These are MH elements of service whose defini- tions include MH/PD intercommunication. In all cases of physical delivery, it is highly desirable that the originator provide a postal O/R address for PD notifications to be sent by PDS, particularly when these are explicitly requested. To facilitate this, the originating UA could prompt the originator for this information or obtain it from a directory. Optional user facilities selectable by originating users affecting physical delivery are rendered on the physical message above the recipient's address visible through the window of the envelope to ensure that the proper handling procedures are taken in the PDS. Details of this are described in Annex B. In the case where the physical message cannot be delivered, it is returned to the originator, depending on the options selected and on national regulations, firstly as a vehicle to carry the non-delivery notification, and secondly to inform the originator on what has happened to the message. Notifications include undeliver- able mail diagnostics as defined in Annex C. Where more than one notification is to be returned to the ori- ginator, these are returned together at the farthest delivery point. For example, physical forwarding and physical delivery notification are generated as a combined notification after delivery. Where the recipient's forwarding address is returned, based on the originator's request, it is returned in the form of a postal address, as defined in Recommendation F.401. The element of service additional physical rendition is meant to establish generic place holders for use under bilateral agree- ments and possible future standardization. The actual methods of physical rendition, routing, and delivery used by Administrations may vary. 4 Physical rendition 4.1 Basic rendition capabilities The PDAU and associated PDS provide the capabilities for ren- dition, routing, transport, and delivery of physical messages based on inherent and user selected facilities as defined by the elements of service. Details of the basic physical rendition (hard copy) process are provided in Annex B. 4.2 Rendition of IPM headers In the case of IP-messages, heading information is printed on the physical message. The language selected is based on either the language indication element of service (provided that this is sup- ported in the receiving country) or the default national language(s) of the receiving country. Originators and/or originat- ing UAs are encouraged to specify the language. 4.3 Additional rendition capabilities Additional physical rendition capabilities of the PDAU are for further study, but may be provided by Administrations on the basis of bilateral agreements. Possible additions include: - use of extended character sets; - ability to select pre-encoded information (such as digitized logos and signatures) for rendition; - support of other encoded information types. 5 Naming and addressing Naming and addressing in message handling services is described in Recommendation F.400. For the purpose of physical delivery, the recipient of the physical message is identified by means of a postal O/R address as defined in Recommendation F.401. PD country name and country name would normally be identical, except in the case of transit mail. This occurs when a message is destined to a country which does not offer MH/PD service intercom- munication; the message would then be routed and printed in the nearest country (or another country based on established agree- ments), and subsequently physically delivered to the final destina- tion. A postal code is required for the routing of the MHS message to the proper PDAU. It may default to unspecified if no postal code exists. Two versions of postal O/R address are provided to allow: a) the use of the postal address as it commonly exists (Version 1 - unformatted postal O/R address); b) for further automatic routing within the PDS (Version 2 - formatted postal O/R address). Administrations should support both versions of the Postal O/R Address, and should encourage MH users to use the Formatted Postal O/R Address (Version 2). Users should be made aware that sufficient address information about the recipient and final destination has to be provided in either version of the postal O/R address in order to enable the PDS to route, transport and deliver a physical message properly. In terms of formatted postal address attributes, these gen- erally comprise: - one attribute of O/R address componets; - one attribute of physical delivery address com- ponents; and - the required set of attributes of physical delivery office address components. The postal O/R address is also used to supply the postal address of the originator of a physical message. Examples of postal O/R addresses are provided in Appendix I. 6 Quality of service 6.1 Service objectives Administrations are responsible for providing the service requested by the originator. In the event of failure, it would be beneficial if accepted and non-delivered messages would be trace- able and the originator informed. 6.2 Message status Administrations could provide assistance to their subscribers with regards to delivery status. The extent to which provisions are made for support of status and tracing of messages is a national matter. 6.3 Delivery and notification times model Figure 2/F.415 depicts a model of delivery and notification times relative to MH/PD service intercommunication. The meaning of times "Tn" in Figure 2/F.415 are defined as follows: T1 = delivery time of MH message 1) Start time corresponds to the submission time stamp. 2) End time corresponds to the delivery time stamp. T2 = delivery notification of MH message 1) Start time corresponds to the delivery time stamp. 2) End time corresponds to the time that the MH notification is made available to the user through the UA or MS. T3 = physical delivery notification by MHS 1) Start time corresponds to the time at which the physical delivery notification by MHS has been generated. 2) End time corresponds to the time that the physi- cal delivery notification by MHS is made available to the user through the UA or MS. Ta = physical handling 1) Start time corresponds to the delivery time stamp. 2) End time corresponds to the time at which the physical message is delivered to the recipient. Note - Physical handling includes physical rendition, tran- sport, and delivery. Tb = generation of physical delivery notification by MHS 1) Start time corresponds to the time at which the physical message is delivered to the recipient. 2) End time corresponds to the time that the physi- cal delivery notification by MHS is generated in the MHS. Tc = physical delivery notification by PDS 1) Start time corresponds to the time at which the physical message is delivered to the recipient. 2) End time corresponds to the time that the physi- cal delivery notification by PDS is delivered to the originator. Note - This time includes the generation of the physical delivery notification by PDS. Figure 2/F.415, p. 6.4 Time targets Time targets for MH (T1, T2, T3 in Figure 2/F.415) are speci- fied in Recommendations F.410 and F.420. In addition, times for physical handling (Ta, Tb, Tc in Figure 2/F.415) need to be con- sidered. These time targets are not specified in this Recommenda- tion but could be defined in the MH/PD service profile table described in S 7. Time targets for physical handling are dependent on the modes of physical transport and delivery requested by the originator and on the modes offered by the destination Administration. 6.5 Responsability for messages From the point of view of MH/PD service intercommunication, responsibility for physical delivery starts at the point where the MTA passes the message to the PDAU. Responsibility for messages prior to that belongs in MHS. Delivery through a specific PDS is a user option. If the user does not specify a certain PDS, messages are handled by the PDS associated with the MH domain. If there is more than one PDS, the traffic is routed based on administrative agreements. Although MH messages with incomplete physical routing data may cause problems or delays, service providers should accept such mes- sages in at least one gateway station and arrange for further rout- ing as appropriate. The MHS could check whether the requested elements of service and rendition capabilities are compatible with those offered by the destination MTA/PDAU and PDS. If this check is positive, the mes- sage is accepted by the MTA/PDAU which generates the delivery time stamp indication. This time stamp appears in the field service data as detailed in Annex B. 6.6 Handling of incompatibilities If MH messages are destined for a MH/PD service which does not offer the requested elements of service, or additional capabili- ties, the messages should be transferred to another suitable MH/PD service in the same management domain, or in another management domain (another country in the case of transit mail), based on established agreements. Another method for handling incompatible messages is to replace requested additional optional elements of service and printing capabilities by the best comparable service and to inform the originator, and if necessary also the recipient, about the chosen alternatives. If neither of these methods of handling incompatibilities are possible the MTA/PDAU shall reject the MS message and initiate a non-delivery report. The non-delivery report shall inform the ori- ginating UA of the reasons for rejection of a message. 7 User information and support When possible, the correctness and completeness of the physi- cal routing data could be checked and flagged to the originator at origination. To prevent incompatible international MH messages from being sent, the international community of users should be provided with all necessary information on the service provisions of MTA/PDAUs and PDS. This information is to be defined in MH/PD service profile tables and is to be provided either in hard-copy form or preferably in electronic form. These MH/PD profile tables will contain all the information required for routing traffic as well as information concerning additional optional user facilities and time targets provided by the destination Administration. Note - The specification of the type of information to be contained in the MH/PD service profile tables is for urgent further study. Each Administration participating in this intercommunication should apply information required for the MH/PD service profile tables to the ITU secretariat, either directly or through the International Bureau of the UPU. All subsequent amendments should be communicated by the Administrations without delay. The ITU General Secretariat will publish the MH/PD service profile tables containing the information received from Administra- tions. Subsequent amendments are published in the ITU Operational Bulletin. Note - The use of Probe or directory enquiries for origina- tors to obtain information on a MH/PD services prior to sending a message are for further study. 8 Network requirements Provision of MH/PD services is network independent. Basic ser- vice and optional user facilities are provided independently of the type of network used for service access. 9 Tariff and accounting considerations Tariff and accounting considerations applicable to the provi- sions of MH/PD services are for further study by CCITT and the UPU. The following elements of accounting components may need to be studied: - a basic charge component for the use of MH/PD service intercommunication (for ordinary mail delivery); - additional charge components based on the request for optional user facilities; - charge components based on the size of the mes- sage (number of pages) and the distance the message travels; - charge components for the establishment and maintenance of address lists and other information which is stored on behalf of a user; - charge components for additional physical rendi- tion, such as the registration and storage of graphics (logo, sig- nature). ANNEX A (to Recommendation F.415) Abbreviations H.T. [T2.415] _____________________________________________________________________________ EOS Elements of Service IA5 International Alphabet 5 IP Interpersonal IPM Interpersonal Messaging IRV { International Reference Version } ISO { International Organization for Standardization } ITU { International Telecommunications Union } MH Message Handling MHS Message Handling Systems MS Message Store MT Message Transfer MTA Message Transfer Agent O/R Originator/Recipient PD Physical Delivery PDAU { Physical Delivery Access Unit } PDS Physical Delivery System UA User Agent UPU Universal Postal Union _____________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - For a glossary of terms see Annex A of Recommendation F.400. Note 2 - For references see Recommendations F.400 and F.401. Note 3 - Administration is used in short form to indicate a Telecommunication Administration, a Recognized Private Operating Agency, and in the case of Message Handling Services intercommuni- cation with Physical Delivery Services, a Postal Administration. Table [T2.415], p. ANNEX B (to Recommendation F.415) Physical rendition details B.1 Basic rendition capabilities Messages destined for physical delivery are conveyed by the message transfer service and routed to an MTA/PDAU, the link between MHS and PDS. The MTA/PDAU provides the capabilities for the physical rendition based on the originator's message(s) and selected facilities. The physical message consists of a window envelope and a lim- ited number of pages with imprinted information. Information is printed as information fields as follows: - letter-head information; - indication of requested elements of service; - postal address of the recipient; - text of the message; and - service data. B.2 Printable area The information is printed in vertical orientation in an area which is the common printablea area of the 297 mmx 210 mm (ISO A4) and 280 mm x 216 mm (North American letter size) formats, as speci- fied in Figure A-2/T.60 (dotted area). This area is extended by three additional lines down to the bottom edge which is easily pos- sible with both formats. Figure B-1/F.415 shows the printable area. Figure B-1/F.415, p. B.3 Paper characteristics The choice of an appropriate paper type is a national matter as long as the printable area can be accommodated. Information should be printed on plain light paper and on one side only. Note - Preprinted paper, e.g., with service logo, may gen- erally be used but the imprint shall be outside the text of message field. B.4 Information fields The maximum size of each field corresponds to an area occupied by a given number of lines based on 6 lines/inch (4.23 mm/line) and a given number of characters based on 10 characters/inch (2.54 mm/character). Other forms of rendition and settings are pos- sible. These fields may be arranged on the pages according to national requirements. Figures B-2/F.415 and B-3/F.415 give two variations of the first page. Figure B-4/F.415 illustrates the lay- out of the second and following pages. Figure B-2/F.415, p. Figure B-3/F.415, p. B.4.1 Letter-head field The letter-head field is used to present the letter head as commonly used for business letters (with logo, originator address, references etc.). The use of the letter-head field is under the control of the PDAU and not of the user. The remaining space in the letter-head field can be used by the PDAU for other data, e.g., an MH address of the originator, which might be useful for replying through MHS. The size of the letter-head field is limited to 6 lines of 72 characters each. The originator address (30 characters per-line) is one subfield in the letter-head field. In the basic mode, only graphic characters which are generated by the MTA/PDAU from protocol data can be presented. The use of photographic elements and/or prestored logos and signatures is not part of the basic mode. B.4.2 Window area The window area is the area which is fully seen through the window of the envelopes considering also the play of the physical message in the envelope. This area contains all the information required for handling and delivery of the physical message by the PDS, and remains free of all other information (no wording or extraneous matter). The window area may be either on the left or on the right depending on national practice. Note - The use of double window envelopes is considered a national matter. Figure B-4/F.415, p. B.4.2.1 Elements of service indication field The elements of service indication field covers an area of 1 line comprising 30 characters. This area is to indicate all the options requested by the originator for the handling of the physi- cal message (e.g., special delivery). This handling may be indicated in descriptive terms or by the use of codes. It may be necessary to give additional indication in a form commonly used in the PD service; for example, by affixing stickers on the envelope. This is a national matter. B.4.2.2 Space line field The space line field shall be free of imprinted information. The space line is essential to ensure that information above the address is to be clearly separated. B.4.2.3 Postal address field This postal address field contains the postal address of the recipient. It covers a field of 6 lines of 30 characters each. B.4.3 Text of message The text of message field is used to present the content of the message. In the case of IP-messages, this field is composed of the IPM heading and body. The maximum size of this field is: a) on the first page, 35 lines of (72 + 5) charac- ters each and, b) on the following pages, 55 lignes of (72 + 5) characters each. Note 1 - The text of the message is presented relative to the home position. The home position is in the first line of the field text of message and approximately 20 mm from the left paper edge (position 8). Note 2 - 72 characters may be presented from position 8 to position 79 and 5 characters to the left of position 8 (positions 3 to 7). Note 3 - The utilization of the extra "+5" character spaces mentioned above requires the use of backspace. B.4.4 Service data field The service data field is used to present service data, e.g., time stamps, message identifier and page numbers. This field is recommended to extend over two lines of 72 characters each. Note - The service data field may also cover more or less than 2 lines; this is considered a national matter. B.5 Control codes for inserting machines Printing in position 3 to 7 is only allowed in the text of message field. In other fields, this space is reserved for bar codes controlling the enveloping process where automated paper han- dling equipment is used. In these cases, the bar codes could be used on all pages of the physical message. B.6 Character sets The MTA/PDAU supports the use of the following encoded infor- mation types: - Telex; - IA5 text, (IRV); - Teletex. Support of additional encoded information types is for further study. Additional encoded information types may be used under bila- teral agreements. It is an objective of the MH/PD service intercommunication to make the most use of electronic printers to ensure that the whole basic set of graphic characters received are rendered without ambi- guity or loss of information. It is therefore preferred that each PDAU will at least provide for the rendition of the full basic set of graphic characters from Figure 2/T.61. However, it may be unavoidable that messages have to be con- verted into a 7-bit set such as defined in Recommendation T.50 for further processing and rendition in some countries. The selection of a print font is considered to be a national matter. Fonts which are commonly used in a country should be chosen. Rendition rules for the representation of the basic charac- ter set of Figure 2/T.61 are also a national matter. B.7 Code conversion Conversion from telex and IA5 (IRV) to T.61 for further pro- cessing and rendition in the MTA/PDAU follows the rules given in Annex A. If conversion to a 7-bit encoded set in unavoidable, conver- sion from telex and IA5 (IRV) shall be according to Recommendation X.408. Conversion of messages received encoded in the T.61 set shall be converted in the greatest possible extent to minimize ambiguity and loss of information. B.8 Format conversion The constraints of format conversion for the content of the message are as given in S B.4.3. These constraints define the presentation space of the X-and-Y directions as defined in Recommendation X.408. Folding of the lines and pages to the constraints of the PDAU is considered a loss of information according to Recommendation X.408. To recover from loss of information the PDAU may apply the following fallbacks: - If the originator's line length is greater than 72 characters, but not more than 80 characters, the messages will be printed with 12 cpi instead of 10 cpi. - If the originator's first page length is greater than 35 lines but not more than 55 lines, the message will be printed starting on the second page (see Note). - In the case of IP-messages, the rendition of the IPM header is under the control of the PDAU. The user wil not know the remaining number of lines on the page on which the header is printed. Thus, if the first page of the body parts fits into the remaining space, it will be printed on that same page; otherwise it will be printed on the next page (see Note). Note - Notification of the recipient that the message was started on the next page, for example by a note, is a national matter. Messages which are not paginated, either because pagination was not possible in the originator's text or because the originator didn't use pagination, will be folded to pages by the PDAU. ANNEX C (to Recommendation F.415) Undeliverable mail diagnostics C.1 Reasons related to the address - Physical delivery address incorrect (does not exist). - Physical delivery office incorrect or invalid (does not exist). - Physical delivery address incomplete. C.2 Reasons related to the recipient - Recipient unknown. - Recipient deceased. - Organization expired. - Recipient refused to accept. - Recipient did not claim. - Recipient changed address permanently (moved), forwarding not applicable. - Recipient changed address temporarily (on travel), forwarding not applicable. - Recipient changed temporary address (departed), forwarding not applicable. C.3 Reasons of non-forwarding - New address unknown. - Recipient did not want forwarding. - Originator prohibited forwarding. C.4 Reasons related to the PDAU capabilities - Physical rendition not performed. - Physical rendition attributes not supported. APPENDIX I (of Recommendation F.415) Naming and addressing examples I.1 Example 1 I.1.1 Postal O/R address PD country name: DE (Germany, Federal Republic of) Country Name: DE (Germany, Federal Republic of) Administration domain name: DBP (Deutsche Bun- despost) PD service name: POST Postal Code: 6000 Version 1 (unformatted) Version 2 (formatted) Franz Muller Personal name: Franz Muller Rudesheimer Str. 21 Street address: Rudesheimer Str. 21 6000 FRANKFURT 1 PD office name: FRANKFURT PD office number: 1 I.1.2 Rendition of Postal Address The following printout appears on the first page of the letter and is visible through the window of the envelope. Franz Muller Rudesheimer Str. 21 6000 FRANKFURT 1 (see Note 1) BUNDESREPUBLIK DEUTSCHLAND (see Note 2) Note 1 - The postal code and country name will automatically be taken from the MHS routing data. Note 2 - Country name is optional, except in the case of transit mail. I.2 Example 2 I.2.1 Postal O/R address PD country name: CA (Canada) Country name: CA (Canada) Administration domain name: CPC (Canada Post Cor- poration) PD service name: EMAIL Postal code: K2E 7L9 Version 1 (unformatted) Version 2 (formatted) Mr. J. Doe Personal name: Mr. J. Doe ACME Corp. Organization name: ACME Corp. 141 Anyname Avenue Street address: 141 Anyname Avenue SMALLTOWN, Ontario PD office name: SMALL- TOWN, Ontario I.2.2 Rendition of postal address The following printout appears on the first page of the letter and is visible through the window of the envelope. Mr. J. Doe ACME Corp. 141 Anyname Avenue SMALLTOWN, Ontario K2E 7L9 (see Note) Note - The postal code and country name will automatically be taken from the MHS routig data.