Working Implementation Agreements for Open Systems Interconnection Protocols: Part 8 - Message Handling Systems Output from the September 1993 NIST Workshop for Implementors of OSI SIG Chair: Chris Bonatti, Booz Allen & Hamilton SIG Editor: Rich Ankney, Fischer International Part 8: Message Handling Systems September 1993 (Working) Foreword The text in this chapter specifies the North American requirements for use of the MHS ISPs. It also specifies any additional requirements and Recommended Practices that are beyond the scope of the ISPs. ii Part 8: Message Handling Systems September 1993 (Working) Table of Contents Part 8 Message Handling Systems . . . . . . . . . . . . . . 1 0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 References . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 CCITT . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 ISO . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 Taxonomy and Functional Groups . . . . . . . . . . . . . 4 4.1 AMH1 . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2 AMH2 . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3 AMH3 . . . . . . . . . . . . . . . . . . . . . . . . 8 5 Conformance . . . . . . . . . . . . . . . . . . . . . . . 9 6 Common Messaging . . . . . . . . . . . . . . . . . . . . 12 6.1 Introduction . . . . . . . . . . . . . . . . . . . . 12 6.2 Elements of Service . . . . . . . . . . . . . . . . 12 6.3 MTS Transfer Protocol (P1) . . . . . . . . . . . . . 12 6.4 MTS Access Protocol (P3) . . . . . . . . . . . . . . 12 6.5 MS Transfer Protocol (P7) . . . . . . . . . . . . . 13 6.6 Pragmatic Constraints . . . . . . . . . . . . . . . 13 6.6.1 MTS - APDU Size . . . . . . . . . . . . . . 13 6.6.2 Number of Recipient Names . . . . . . . . . 14 6.7 1988/84 Interworking Considerations . . . . . . . . 14 7 MHS Management . . . . . . . . . . . . . . . . . . . . . 16 8 IPM Service . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Introduction . . . . . . . . . . . . . . . . . . . . 16 9 EDI Messaging Service . . . . . . . . . . . . . . . . . . 17 9.1 Introduction . . . . . . . . . . . . . . . . . . . . 17 9.2 EDIMS Elements of Service . . . . . . . . . . . . . 17 9.3 P(EDI) Protocol . . . . . . . . . . . . . . . . . . 21 9.3.1 MS Attributes . . . . . . . . . . . . . . . 21 9.4 EDIMS Multi-Part Body Functional Group . . . . . . . 21 9.4.1 General . . . . . . . . . . . . . . . . . . 21 9.4.2 Elements of Service . . . . . . . . . . . . 21 9.5 EDI Message Store (EDI-MS) . . . . . . . . . . . . . 21 9.6 Conversion . . . . . . . . . . . . . . . . . . . . . 22 9.7 EDIMS Security Functional Group . . . . . . . . . . 22 iii Part 8: Message Handling Systems September 1993 (Working) 9.7.1 EDIMS Security Class EDI-A (SEC-A) . . . . 23 9.7.2 EDIMS Security Class EDI-B (SEC-B) . . . . 23 9.7.3 EDIMS Security Class EDI-C (SEC-C) . . . . 23 9.8 Physical Delivery . . . . . . . . . . . . . . . . . 23 9.9 EDIMS Forwarding Functional Group . . . . . . . . . 24 9.9.1 General . . . . . . . . . . . . . . . . . . 24 9.9.2 Elements of Service . . . . . . . . . . . . 24 9.10 Use of Directory . . . . . . . . . . . . . . . . . . 24 9.11 EDI-UA Conformance . . . . . . . . . . . . . . . . . 25 10 Management Domain Agreements . . . . . . . . . . . . . . 25 Annex A (normative) MHS Protocol Specifications . . . . . . . . . . . . . . . . . 26 A.1 EDI Messaging Service Protocol (Pedi) . . . . . . . 26 A.2 Message Store EDIMS Attribute Support . . . . . . . 32 Annex B (normative) Naming, Addressing and Routing . . . . . . . . . . . . . . . 35 B.1 ORAddress Attribute List Equivalence Rules . . . . . 35 B.2 MHS Use of Directory . . . . . . . . . . . . . . . . 35 B.2.1 Introduction . . . . . . . . . . . . . . . 35 B.2.2 Functional Configuration . . . . . . . . . 36 B.2.3 Functionality . . . . . . . . . . . . . . . 36 B.2.4 Naming and Attributes . . . . . . . . . . . 37 B.2.5 Directory Services . . . . . . . . . . . . 38 B.2.6 OIW Application Specific Attributes and Attribute Sets . . . . . . . . . . . . . . 38 B.2.7 OIW Application Specific Object Classes . . 40 B.2.8 Structure Rules . . . . . . . . . . . . . . 40 B.2.8.1 MHS Distribution List . . . . . . . . . . . 40 B.2.8.2 MHS User . . . . . . . . . . . . . . . . . 40 B.2.9 Use of Capabilities Information . . . . . . 40 Annex C (normative) IPM Body Part Support . . . . . . . . . . . . . . . . . . . . 41 Annex D (normative) Object Identifiers . . . . . . . . . . . . . . . . . . . . . 43 D.1 X.400 SIG Object Identifiers . . . . . . . . . . . . 43 D.2 Content Types . . . . . . . . . . . . . . . . . . . 43 D.3 Body Part Types . . . . . . . . . . . . . . . . . . 44 D.4 Security Classes . . . . . . . . . . . . . . . . . . 44 Annex E (informative) iv Part 8: Message Handling Systems September 1993 (Working) Interpretation of Elements of Service . . . . . . . . . . . . 45 Annex F (informative) Recommended Practices . . . . . . . . . . . . . . . . . . . . 46 F.1 Printable String . . . . . . . . . . . . . . . . . . 46 F.2 Rendition of IA5Text . . . . . . . . . . . . . . . . 47 F.3 EDI Use of MHS . . . . . . . . . . . . . . . . . . . 48 F.3.1 P0 Recommended Practice . . . . . . . . . . 48 F.3.1.1 P0 to P(edi) Conversion . . . . . . . . . . 48 F.3.1.2 P(edi) to P0 Conversion . . . . . . . . . . 49 F.3.2 P2 Recommended Practice . . . . . . . . . . 50 F.3.2.1 Conversion from IPMS to EDIMS (P2 to P(edi)) . . . . . . . . . . . . . . . . . . 50 F.3.2.2 Conversion from EDIMS to IPMS (P(edi) to P2) . . . . . . . . . . . . . . . . . . . . 51 F.4 ODA Transfer . . . . . . . . . . . . . . . . . . . . 51 F.5 Use of Externally Defined Body Part . . . . . . . . 52 F.5.1 General . . . . . . . . . . . . . . . . . . 52 F.5.2 Use of Equivalents of Basic Body Part Types 53 F.5.3 Use of General Text Body Part Type . . . . 53 F.5.4 Use of File Transfer Body Part Type . . . . 53 F.5.4.1 Encoding of General Identifier . . . . . . 53 F.5.4.2 Encoding of Contents Type . . . . . . . . . 53 F.5.4.3 Encoding of Application Specific Information . . . . . . . . . . . . . . . . 53 F.5.4.4 EITs for the File Transfer Body Part . . . 54 F.5.5 Use of Other Extended Body Part Types . . . 54 F.5.6 Obtaining Object Identifiers . . . . . . . 55 F.6 Privacy Enhanced Mail Body Part . . . . . . . . . . 55 F.7 Selection of OR Name Attributes . . . . . . . . . . 56 F.8 Use of the Teletex Body Part . . . . . . . . . . . . 56 F.9 Provision of Security Class S0A Using Asymmetric Algorithms . . . . . . . . . . . . . . . . . . . . . 56 F.9.1 Protocol Elements . . . . . . . . . . . . . 57 F.9.2 Algorithm Selection . . . . . . . . . . . . 58 F.9.3 Certificate Management . . . . . . . . . . 58 F.9.4 Other Issues . . . . . . . . . . . . . . . 59 Annex G (informative) Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 60 G.1 ANSI . . . . . . . . . . . . . . . . . . . . . . . . 60 G.2 Internet . . . . . . . . . . . . . . . . . . . . . . 60 G.3 Other References . . . . . . . . . . . . . . . . . . 60 Annex H (informative) Defense Message Handling Profiles . . . . . . . . . . . . . . 61 H.1 Introduction . . . . . . . . . . . . . . . . . . . . 61 v Part 8: Message Handling Systems September 1993 (Working) Annex I (informative) Management Domains . . . . . . . . . . . . . . . . . . . . . 62 I.1 Management Domain Names . . . . . . . . . . . . . . 62 I.2 Use of ADMD Names . . . . . . . . . . . . . . . . . 64 I.3 Uniqueness of MTS Identifiers Within a Management Domain . . . . . . . . . . . . . . . . . . . . . . . 65 vi Part 8: Message Handling Systems September 1993 (Working) List of Figures Figure 1 - Combinations of AMH1n Profiles . . . . . . . . . . 5 Figure 2 - Combinations of AMH2n Profiles . . . . . . . . . . 7 Figure 3 - 1988 MHS Physical Configurations . . . . . . . . . 9 Figure 2 - 1988 to 1984 Mapping . . . . . . . . . . . . . . . 15 Figure 3 - 1984 to 1988 Mapping . . . . . . . . . . . . . . . 16 Figure 7 - Example of Unregistered Object Class Definition . 37 Figure 10 - Privately-Defined Body Parts . . . . . . . . . . 42 Figure 15 - Definition of the mhsig Object Identifier . . . . 43 Figure 16 - Defintion of the X.400 SIG Object Identifier Categories. . . . . . . . . . . . . . . . . . . . . . . 43 Figure 17 - Definition of the External Body Part Object Identifiers . . . . . . . . . . . . . . . . . . . . . . 44 Figure 19 - ASCII to PrintableString Algorithm . . . . . . . 47 Figure 20 - PrintableString to ASCII Algorithm . . . . . . . 47 Figure 22 - Externally Defined Body Part Definition . . . . . 52 Figure 23 - Definition of the Privacy Enhanced Mail Body Part Type . . . . . . . . . . . . . . . . . . . . . . . 56 Figure 12 - Management Domain Name Construction . . . . . . . 62 Figure 13 - Name Construction by Subauthorities . . . . . . . 63 Figure 14 - Prefix . . . . . . . . . . . . . . . . . . . . . 64 vii Part 8: Message Handling Systems September 1993 (Working) List of Tables Table X - MHS Configurations . . . . . . . . . . . . . . . . 10 Table 4 - Deltas to Clause A.1.2 of ISP 10611-3 . . . . . . . 12 Table 8 - Deltas to Table A.1.2.4 of ISP 10611-4 . . . . . . 12 Table 21 - Deltas to Table A.1.2.4 of ISP 10611-5 . . . . . . 13 Table 22 - Deltas to Table A.1.3.1 of ISP 10611-5 . . . . . . 13 Table 31 - Deltas to Table A.1.11 of ISP 10611-5 . . . . . . 13 Table 28 - EDIMS Functional Groups . . . . . . . . . . . . . 17 Table 29.1 - EDIMS: Basic EDI Elements of Service . . . . . 18 Table 29.2 - EDIMS: Optional EDI Elements of Service . . . . 19 Table 46 - Classification of the Pedi Protocol Elements . . . 27 Table 47 - Classification of the Message Store EDIMS attributes . . . . . . . . . . . . . . . . . . . . . . . 33 Table 11 - Directory Service Support Requirements . . . . . . 38 Table 49 - Printable String to ASCII Mapping . . . . . . . . 46 Table 50 - Interpretation of Format Effector Combinations . . 47 viii Part 8 Message Handling Systems 0 Introduction This is an Implementation Agreement developed by the Implementor's Workshop sponsored by the U. S. National Institute of Standards and Technology to promote the useful exchange of data between devices manufactured by different vendors. This Agreement is based on, and employs protocols developed in accord with, the OSI Reference Model. It provides detailed guidance for the implementor and eliminates ambiguities in interpretations. This is an Implementation Agreement for Message Handling Systems (MHS) based on the CCITT X.400 (1988) series of Recommendations, the similar (but not identical) ISO MOTIS standard, and Recommendations F.435 and X.435 (1991) (see References). These Recommendations and Standards are referred to as the base standards. The term `MHS' is used to refer to both sources where a distinction is unnecessary. Similarly, `1984' and `1988' are often used to distinguish between the CCITT X.400 (1984) series of Recommendations and the later sources. This Implementation Agreement seeks to establish a common specification which is conformant with both CCITT and ISO with a view to: a) Preventing a proliferation of incompatible communities of MHS systems which are isolated for protocol reasons; b) Achieving interworking with implementations conforming to the OIW Stable Implementation Agreements for CCITT 1984 X.400-based Message Handling Systems; and, c) Facilitating integration of other OSI-based services (e.g., Directory) within a single real system. This Implementation Agreement is designed to encourage upgrade of existing 1984-based systems as follows: a) To add 1988 functionality (Message Store, Remote User Agent, etc); and, b) To provide additional functionality above the minimal conformant 1988 MHS defined in the December 1989 version of the OIW Implementation Agreements. These 1988 aspects are described in this agreement as either incremental enhancements or new functional groups. However, it is considered that the OIW Stable Implementation Agreements for CCITT 1984 X.400-based Message Handling Systems (part 7) should not be withdrawn at this stage. It is anticipated 1 Part 8: Message Handling Systems September 1993 (Working) that X.400 (1984) implementations will continue to provide a viable alternative for applications that do not require the additional 1988 functionality for some time. 1 Scope This Agreement specifies the requirements for MHS implementations based on the 1988 MHS standards. This Agreement applies equally to Private Management Domains (PRMDs) and Administration Management Domains (ADMDs). Four boundary interfaces are specified, as illustrated in figure 1: a) Management Domain (MD) to MD; b) Message Transfer Agent (MTA) to MTA within a domain; c) MTA to remote Message Store (MS) or User Agent (UA); and, d) MS to Remote UA. MHS protocols other than the Message Transfer Protocol (P1), the Message Transfer System Access Protocol (P3), the Interpersonal Messaging Protocol (P22, i.e. P2 encoded as integer 22), the Message Store Access Protocol (P7), and the EDI Messaging Protocol (P35) are beyond the scope of this Agreement. Issues arising from the use of other protocols are outside the scope of this document. 2 References 2.1 CCITT Application Layer - MHS CCITT Recommendation X.400 (1988), Message Handling, System and Service Overview. CCITT Recommendation X.402 (1988), Message Handling Systems, Overall Architecture. CCITT Recommendation X.407 (1988), Message Handling Systems, Abstract Service Definition Conventions. CCITT Recommendation X.411 (1988), Message Handling Systems, Message Transfer System: Abstract Service Definition and 2 Part 8: Message Handling Systems September 1993 (Working) Procedures. CCITT Recommendation X.413 (1988), Message Handling Systems, Message Store: Abstract Service Definition. CCITT Recommendation X.419 (1988), Message Handling Systems, Protocol Specifications. CCITT Recommendation X.420 (1988), Message Handling Systems, Interpersonal Messaging System. CCITT Recommendation X.121 (1988), International Numbering Plan. CCITT Recommendation X.435 (1991), Message Handling Systems, EDI Messaging System, Protocol Specifications. CCITT Recommendation F.435 (1991), Message Handling Systems, EDI Messaging System, Abstract Service Definition. CCITT MHS Implementors Guide, Version 8. 2.2 ISO Application Layer - MHS ISO 10021-1 Information Processing Systems - Text Communication - MOTIS - System and Service Overview. ISO 10021-2 Information Processing Systems - Text Communication - MOTIS - Overall Architecture. ISO 10021-3 Information Processing Systems - Text Communication - MOTIS - Abstract Service Definition Conventions. ISO 10021-4 Information Processing Systems - Text Communication - MOTIS - Message Transfer System: Abstract Service Definition and Procedures. ISO 10021-5 Information Processing Systems - Text Communication - MOTIS - Message Store: Abstract Service Definition. ISO 10021-6 Information Processing Systems - Text Communication - MOTIS - Protocol Specifications. ISO 10021-7 Information Processing Systems - Text Communication - MOTIS - Interpersonal Messaging System. DISP 10611 Information Processing Systems - International Standardized Profiles AMH1n - Message Handling Systems - Common 3 Part 8: Message Handling Systems September 1993 (Working) Messaging. PDISP AMH2n Information Processing Systems - International Standardized Profiles AMH2n - Message Handling Systems - Interpersonal Messaging. PDISP AMH3n Information Processing Systems - International Standardized Profiles AMH3n - Message Handling Systems - EDI Messaging. 3 Status This version of the Implementation Agreements for Message Handling Systems (MHS) is under development. It is based on the CCITT X.400 (1988) Recommendations and ISO MOTIS (10021, parts 1- 7) standards, as amended by the MHS Implementors Guide, version 8, as well as ISPs AMH1n and AMH2n (with deltas defined in this document). 4 Taxonomy and Functional Groups The 1988 MHS standards cover a wide and diverse range of functional areas, not all of which would be relevant to every implementation. The Implementors Agreements describe the services in terms of profiles and divide some of the functionality into the concept of optional Functional Groups. Although the profiles have been developed in open workshops and were reasonably mature there have been some differences between the OIW profiles and those developed by EWOS/ETSI. It has therefore, in the interest of international harmonization, been the intention all along to replace the OIW agreements with pointers to the International Standardized Profiles for MHS once these became stable. At this point these agreements include the ISPs by reference and include any differences that are required in the North American market in the form of deltas to the ISPs. The AMH ISPs were developed under the management of the MHS ISP Special Group (MISG). The MISG was formed in early 1991 as a joint workshop initiative, comprising delegations from the MHS groups of the three regional workshops, OIW, EWOS/ETSI, and AOW. It has provided a forum for developing and agreeing the MHS ISP taxonomy, resolving key issues and carrying out initial review of revised ISP drafts. All MISG decisions have been subject to ratification by the full meetings of the workshop MHS groups, which have also carried out detailed review of the ISP drafts. 4 Part 8: Message Handling Systems September 1993 (Working) The AMH set of profiles, so far consists of three multipart profiles. AMH1 covers Common Messaging - i.e. those aspects of the MHS base standards which are independent of a particular content type. AMH2 covers the Interpersonal Messaging content type. AMH3 covers the EDI Messaging content type.. 4.1 AMH1 The AMH1n set of profiles is applicable to end systems operating in an Open Systems Interconnection (OSI) environment which form part of a distributed Message Handling Systems (MHS) environment as specified in ISO/IEC 10021 (MOTIS) and the equivalent CCITT X.400 Recommendations. The AMH1n profiles each specify a particular combination of OSI standards which collectively provide one of the MHS services as realized by an MHS protocol: - AMH11 - Message Transfer (P1 protocol) - between message transfer agents (MTAs) - AMH12 - Message Transfer System (MTS) Access (P3 protocol) - between a remote user agent (UA) and an MTA, and between a remote message store (MS) and an MTA. - AMH13 - Message Store (MS) Access (P7 protocol) - between a remote UA and an MS Profile AMH11 is further subdivided into: - AMH111 - requiring support of a 'normal mode' OSI protocol infrastructure [as required by ISO/IEC 10021 (MOTIS)] - AMH112 - requiring support of an 'X.410 mode' OSI protocol infrastructure [as required by the CCITT X.400 (1984) Recommendations] An MTA which conforms to profile AMH11 may conform to AMH111, or to AMH112, or both. Each AMH1n profile specifies the conformance requirements for all relevant MHS functional objects (i.e., MTA, UA, MS). Two or more AMH1n profiles can be combined to establish the conformance requirements for the various physical configurations that may be achieved within the scope of the MHS base standards as illustrated in the following diagram. 5 Part 8: Message Handling Systems September 1993 (Working) +-------+ AMH11 +-------+ AMH11 +-------+ AMH11 +-------+ | MTA +-----------+ MTA +----------+ MTA +----------+ MTA | +---+---+ +---+---+ +-------+ +-------+ | | | MS | | UA | | AMH12 | AMH12 +---+---+ +-------+ | | | +---+---+ +---+---+ | AMH13 | UA | | MS | | +-------+ +---+---+ +---+---+ | | UA | | AMH13 +-------+ | +---+---+ | UA | +-------+ Figure 1 - Combinations of AMH1n Profiles The AMH1n set of profiles is specified as a multipart ISP consisting of the following parts: Part 1: MHS service support. A common text part which provides functional description and specification of MHS service support and associated functionality as covered by the AMH1n set of profiles. It identifies what service support and associated functionality can be supported by each type of MHS component, divided into basic requirements (i.e., required to be supported by all implementations) and zero or more optional functional groups (discrete sets of related functionality which are not required to be supported by all implementations). Such specifications are in many cases applicable to more than one MHS protocol or are otherwise concerned with component functionality which although it can be verified via protocol, is not just related to protocol support. The 6 Part 8: Message Handling Systems September 1993 (Working) specification in this part is therefore designed for reference by the following parts (which specify conformance requirements by protocol for each MHS component) and is additional to the protocol-specific requirements specified in those parts. Thus, although this part contains normative requirements, there is no separate conformance to this part (i.e., it is not identified in the MHS taxonomy) since such requirements are only significant when referenced in the context of a particular protocol profile. Part 2: Specification of ROSE, RTSE, ACSE, Presentation and Session protocols for use by MHS. A common text part which provides specification of the underlying protocol infrastructure requirements to support the various MHS application contexts. This is achieved as far as possible by reference to the Common Upper Layer Requirements (CULR): Basic connection oriented requirements ISP 11188-1, plus specification of any further requirements which are either MHS-specific or otherwise not covered by Part 1 of the CULR ISP (ROSE, RTSE). Part 3: AMH11 - Message Transfer (P1). This part covers message transfer between MTAs using the P1 Message transfer Protocol. It specifies P1 support in terms of basic requirements and optional functional groups and defines conformance requirements for an MTA which supports transfer with respect to support of P1 and associated functionality (by reference to the common specifications in part 1). Part 4: AMH12 - MTS Access (P3). This part covers access to an MTS using the P3 MTS Access Protocol. It specifies P3 support in terms of basic requirements and optional functional groups and defines conformance requirements for an MTA which supports remote access, and for a remote MTS-user (i.e., UA or MS). with respect to support of P3 and associated functionality (by reference to the common specifications in part 1). Part 5: AMH13 - MS Access (P7). This part covers access to an MS using the P7 MS Access Protocol It specifies P7 support in terms of basic requirements and optional functional groups and defines the conformance requirements for an MS which supports remote access, and for a remote MS-user (i.e., UA), with respect to support of P7 and associated functionality (by reference to 7 Part 8: Message Handling Systems September 1993 (Working) the common specifications in part 1). 4.2 AMH2 The AMH2n set of profiles is applicable to end systems operating in an Open Systems Interconnection (OSI) environment which form part of a distributed Message Handling Systems (MHS) environment and which provide an interpersonal messaging service. The AMH21 profile specifies the Inerpersonal Messaging (IPM) content (P2 'protocol') which is carried end-to-end (i.e. UA-to- UA) by the MHS protocols (i.e. P1, P3, and P7). The remaining AMH2n profiles cover the other aspects of an IPM MHS environment, specifying additional requirements to those specified in the AMH1n Common Messaging set of profiles as appropriate to support an IPM service: - AMH22 - IPM Requirements for Message Transfer (P1) - any additional MTA capabilities related to message transfer which are specific to support of an IPM environment (i.e. additional to the requirements of AMH11) - AMH23 - IPM Requirements for MTS Access (P3) - any additional MTA and MTS-user capabilities related to MTS access which are specific to support of an IPM environment (i.e. additional to the requirements of AMH12) - AMH24 - IPM Requirements for MS Access (P7) - any additional MS and MS-user capabilities related to MS access which are specific to support of an IPM environment (i.e. additional to the requirements of AMH13) Each AMH2n profile specifies the conformance requirements for all relevant MHS functional objects (i.e., MTA, UA, MS). Two or more AMH2n profiles can be combined to establish the conformance requirements for the various physical configurations that may be achieved within the scope of the MHS base standards as illustrated in the following diagram. 8 Part 8: Message Handling Systems September 1993 (Working) +-------+ AMH22 +-------+ AMH22 +-------+ AMH22 +-------+ | MTA +-----------+ MTA +----------+ MTA +----------+ MTA | +---+---+ +---+---+ +-------+ +-------+ | | | MS | | UA | | AMH23 | AMH23 +---+---+ +-------+ | | | . +---+---+ +---+---+ | AMH24 . | UA | | MS | | . +-------+ +---+---+ +---+---+ . . | | UA | . . | AMH24 +-------+ . . | . . . +---+---+ . . . | UA | . . . +-------+ . . . . . . . . . . ........................................................... AMH21 Figure 2 - Combinations of AMH2n Profiles The AMH1n set of profiles is specified as a multipart ISP consisting of the following parts: Part 1: MHS service support. A common text part which provides functional description and 9 Part 8: Message Handling Systems September 1993 (Working) specification of MHS service support and associated functionality as covered by the AMH1n set of profiles. It identifies what service support and associated functionality can be supported by each type of MHS component, divided into basic requirements (i.e., required to be supported by all implementations) and zero or more optional functional groups (discrete sets of related functionality which are not required to be supported by all implementations). Such specifications are in many cases applicable to more than one MHS protocol or are otherwise concerned with component functionality which although it can be verified via protocol, is not just related to protocol support. The specification in this part is therefore designed for reference by the following parts (which specify conformance requirements by protocol for each MHS component) and is additional to the protocol-specific requirements specified in those parts. Thus, although this part contains normative requirements, there is no separate conformance to this part (i.e., it is not identified in the MHS taxonomy) since such requirements are only significant when referenced in the context of a particular protocol profile. Part 2: Specification of ROSE, RTSE, ACSE, Presentation and Session protocols for use by MHS. A common text part which provides specification of the underlying protocol infrastructure requirements to support the various MHS application contexts. This is achieved as far as possible by reference to the Common Upper Layer Requirements (CULR): Basic connection oriented requirements ISP 11188-1, plus specification of any further requirements which are either MHS-specific or otherwise not covered by Part 1 of the CULR ISP (ROSE, RTSE). Part 3: AMH11 - Message Transfer (P1). This part covers message transfer between MTAs using the P1 Message transfer Protocol. It specifies P1 support in terms of basic requirements and optional functional groups and defines conformance requirements for an MTA which supports transfer with respect to support of P1 and associated functionality (by reference to the common specifications in part 1). Part 4: AMH12 - MTS Access (P3). This part covers access to an MTS using the P3 MTS Access Protocol. It specifies P3 support in terms of basic requirements and optional functional groups and defines conformance requirements for an MTA which supports remote 10 Part 8: Message Handling Systems September 1993 (Working) access, and for a remote MTS-user (i.e., UA or MS). with respect to support of P3 and associated functionality (by reference to the common specifications in part 1). Part 5: AMH13 - MS Access (P7). This part covers access to an MS using the P7 MS Access Protocol It specifies P7 support in terms of basic requirements and optional functional groups and defines the conformance requirements for an MS which supports remote access, and for a remote MS-user (i.e., UA), with respect to support of P7 and associated functionality (by reference to the common specifications in part 1). 4.3 AMH3 Editor's Note - This will contain similar text to AMH1 above describing the profiles and then the parts of the ISP The 1988 MHS standards cover a wide and diverse range of functional areas, not all of which would be relevant to every implementation. In order to achieve a more precise definition of conformance requirements according to the functionality supported by an implementation, and additionally to facilitate future enhancement of this specification, the concept of Functional Groups has been introduced. Conformance requirements for support of Functional Groups by particular configurations are specified in clause ?. 5 Conformance MHS implementations may be configured as any single or multiple occurrence or combination of MTA, MS and UA, as illustrated in figure 1. It is not intended to restrict the types of system that may be configured for conformance to this Agreement (although it is equally recognized that not all configuration types may be commercially viable). MHS Implementations may be configured as any single or multiple occurrence or combination of MTA, MS and UA, as illustrated in Figure x. It is not intended to restrict the types of systems that may be configured for conformance to this Agreement (although it is equally recognized that not all configuration types may be commercially viable). 11 Part 8: Message Handling Systems September 1993 (Working) MHS-88- MHS-88-MTA MHS-88-MTA-UA MTA-MS-UA MHS-88-MTA-MS P1 +-------+ P1 +------+ +--------+ P1 +--------++--------------+ MTA +----------------+ MTA | | MTA +-----+ MTA ++ MHS-88-MS ++--+-+-+ +------+ +--------+ +--------+ +-------+ P3 | | +---------+P3 | UA | | MS | | MS | | MS +----+ |P7 +--+---+ +------+ +--------+ +---+----+ +---+---+ +---+---+ | UA | | UA | | | | MS | +------+ +--------+ |P7 |P7 +-------+ MHS-88- Remote- | | | UA | UA-P3 +---+----+ +---+---+ +-------+ | UA | | UA | MHS-88-Remote-UA-MS +--------+ +-------+ MHS-88-UA-P7 MHS-88-UA-P7 Figure 3 - 1988 MHS Physical Configurations Figure 1 shows the possible physical configurations for 1988 MHS implementations. The following lists the conformance requirements for each according to the name in that figure and the requirements in this Agreement. "MHS-88-MTA" specifies a 1988 relay MTA. It must conform to AMH11 as enhanced by the delta described in section 6 of this Agreement. If the MTA also supports a particular content type it may claim conformance to AMH22 for IPMS or AMH32 for EDI, again as enhanced by sections 8 for IPM or 9 for EDI, support for additional content types can be specified in the PICS for AMH11, section A.3.2. "MHS-88-MTA-UA" specifies a 1988 end system in which the MTA is co-located with a User Agent. If the UA is a CCITT 1988 Interpersonal Messaging (IPM) UA, it must conform to AMH21 and AMH22 as enhanced by section 8 of this Agreement. If the UA is an Electronic Data Interchange (EDI) UA it must conform to AMH31 and AMH32 as enhanced by section 9 of this Agreement. If the UA supports any other content type, the implementation must conform 12 Part 8: Message Handling Systems September 1993 (Working) to AMH11. The same UA implementation may support multiple content types by conforming to more than one of these profile combinations. "MHS-88-MTA-MS-UA" specifies an end system in which a Message Store and User Agent are co-located with the MTA. Conformance to this configuration can only be tested in terms of the MTA and UA interfaces, therefore the conformance requirements are identical to the "MHS-88-MTA-UA". "MHS-88-MTA-MS" specifies an end system in which a Message Store is co-located with the MTA. At a minimum this configuration must conform to AMH11 and AMH13 as enhanced by section 6 of this Agreement If the MS supports one or more content types these must be specified in filling out the PICS for AMH13 or by conformance to AMH24 for IPMS or AMH34 for EDI, again as enhanced by this Agreement. "MHS-88-Remote-UA-P3" specifies a remote User Agent that does not require Message Store services. If the UA is a CCITT 1988 Interpersonal Messaging (IPM) UA, it must conform to AMH21 and AMH23 as enhanced by section 8 of this Agreement. If the UA is an Electronic Data Interchange (EDI) UA it must conform to AMH31 and AMH33 as enhanced by section 9 of this Agreement. If the UA supports any other content type, the implementation must conform to AMH12. The same UA implementation may support multiple content types by conforming to more than one of these profile combinations. "MHS-88-Remote-UA-P7" specifies a remote User Agent that does require Message Store services. If the UA is a CCITT 1988 Interpersonal Messaging (IPM) UA, it must conform to AMH21 and AMH24 as enhanced by section 8 of this Agreement. If the UA is an Electronic Data Interchange (EDI) UA it must conform to AMH31 and AMH34 as enhanced by section 9 of this Agreement. If the UA supports any other content type, the implementation must conform to AMH12. The same UA implementation may support multiple content types by conforming to more than one of these profile combinations. "MHS-88-MS" specifies a remote Message Store that serves a remote User Agent. If the MS is a CCITT 1988 Interpersonal Messaging (IPM) MS, it must conform to AMH24 and AMH22 as enhanced by section 8 of this Agreement. If the MS is an Electronic Data Interchange (EDI) MS, it must conform to AMH34 and AMH33 as enhanced by section 9 of this Agreement. If the MS supports any other content type, the implementation must conform to both AMH12 and AMH13 and specify the content type(s) supported, if any, in section A.1.3 of the PICS for AMH13. 13 Part 8: Message Handling Systems September 1993 (Working) "MHS-88-Remote-UA-MS" specifies a remote User Agent that is co-located with a Message Store. For conformance purposes this is the same as the "MHS-88-Remote UA-P3". The following table summarizes the conformance requirements for each possible '88 MHS implementation. Table X - MHS Configurations Entity Protocol(s) Conformance MHS-88-MTA P1 + AMH11 + Section 6 possible content types IPMS AMH22 + Section 8 EDI AMH32 + Section 9 other details in PICS in AMH11 (A.3.2) 14 Part 8: Message Handling Systems September 1993 (Working) Table X - MHS Configurations (concluded) Entity Protocol(s) Conformance MHS-88-MTA-UA P1 + AMH11 + Section 6 possible content types IPMS AMH21 + AMH22 + Sec. 6 EDI AMH31 + AMH32 + Sec. 9 other details in PICS in AMH11 (A.3.2) MHS-88-MTA-MS P1 + P7 + AMH11 + AMH13 + Sec. 6 possible content types IPMS AMH22 + AMH24 + Sec. 8 EDI AMH32 + AMH34 + Sec. 9 other details in PICS in AMH11 (A.3.2) and AMH13 (A.3) MHS-88-Remote-UA- P3 + AMH12 + Sec. 6 P3 possible content types IPMS AMH21 + AMH24 + Sec. 8 EDI AMH31 + AMH34 + Sec. 9 other detail in PICS in AMH13 (A.3) MHS-88-Remote-UA- P7 + AMH13 + Sec. 6 P7 possible content types IPMS AMH21 + AMH24 + Sec. 8 EDI AMH31 + AMH34 + Sec. 9 other details in PICS in AMH13 (A.3) MHS-88-MS P7 + AMH12 + AMH13 + Sec. 6 possible content types IPMS AMH23 + AMH24 + Sec. 8 EDI AMH32 + AMH34 + Sec. 9 other details in PICS in AMH13 (A.3) and AMH14 (A.3) MHS-88-Remote-UA- P3 + AMH12 + Sec. 6 MS possible content types IPMS AMH21 + AMH23 + Sec. 8 EDI AMH31 + AMH33 + Sec. 8 other details in PICS in AMH12 (A.3) 15 Part 8: Message Handling Systems September 1993 (Working) MHS-88-MTA- P1 + AMH11 + Sec. 6 MS-UA possible content types IPMS AMH21 + AMH22 + Sec. 8 EDI AMH31 + AMH32 + Sec. 9 other details in PICS in AMH11 (A.3.2) 6 Common Messaging 6.1 Introduction A minimal 1988-based MTA shall conform to AMH111 and AMH112, and will support the interworking functional group, in order to achieve interworking with 1984-based MTAs and to facilitate migration to full 1988 operation. In addition, a conforming implementation shall obey the criticality mechanism defined in the base standards. The following protocol elements are made critical for delivery for these Implementation Agreements: message token, content integrity check, and content confidentiality algorithm ID. 6.2 Elements of Service Implementations conforming to these agreements shall conform to the Element of Service (EoS) requirements of ISP 10611-1, as modified by the following tables. 6.3 MTS Transfer Protocol (P1) Implementations of MTAs conforming to these agreements shall, at a minimum, implement the AMH111 and AMH112 profiles specified in ISP 10611-3. Collectively, these profiles require support of all three application contexts defined in the 1988 base standards. The OIW requires support of both profiles in order to encourage use of the mts-transfer application context, and to provide a solid foundation for 1984 interworking. Implementations conforming to these agreements shall conform to the requirements of ISP 10611-3, as modified by the following tables. 16 Part 8: Message Handling Systems September 1993 (Working) Table 4 - Deltas to Clause A.1.2 of ISP 10611-3 Profil Ref Application Context e 1 mts-transfer m 2 mts-transfer-protocol m mts-transfer-protocol- 3 m 1984 6.4 MTS Access Protocol (P3) Implementations conforming to these agreements shall conform to the EoS requirements of ISP 10611-4, as modified by the following tables. Table 8 - Deltas to Table A.1.2.4 of ISP 10611-4 MTS-user MTA Ref Operation Prof Prof Base Base ile ile 1 Register m ChangeCredentials 2 m (MTA to UA) ChangeCredentials 3 m (UA to MTA) 6.5 MS Transfer Protocol (P7) Implementations conforming to these agreements shall conform to the EoS requirements of ISP 10611-5, as modified by the following tables. Table 21 - Deltas to Table A.1.2.4 of ISP 10611-5 UA MS Ref Operation Prof Prof Base Base ile ile ChangeCredentials 2 m (MTA to UA) 17 Part 8: Message Handling Systems September 1993 (Working) Table 22 - Deltas to Table A.1.3.1 of ISP 10611-5 UA MS Ref Element Prof Prof Base Base ile ile 1 ARGUMENT fetch- 1.4 restrictions 1.4 allowed-content- m .1 types 1.4 allowed-EITs m .2 1.4 maximum-content- m .3 length Table 31 - Deltas to Table A.1.11 of ISP 10611-5 UA MS Ref Attribute Prof Prof Base Base ile ile 28 originator-name m9 o1 - This element is classified as m in the ISP. m9 - Presently classified as o in ISP. MISG #7 proposed to change this field to m. 6.6 Pragmatic Constraints 6.6.1 MTS - APDU Size This clause is not intended to constrain the size of PDUs that are transferred across the network, since some body part types and content types (e.g., voice, file transfer, and EDI) may require very large PDUs. The following agreements govern the size of MTS-APDUs: a) All MTAEs must support at least one MTS-APDU of at least two megabytes; and, b) The size of the largest MTS-APDU content supported by a UAE is a local matter. 18 Part 8: Message Handling Systems September 1993 (Working) 6.6.2 Number of Recipient Names There is no specified bound on the number of recipient-names an implementation must support, other than the 32K-1 specified in the standard (Annex B/X.411). 6.7 1988/84 Interworking Considerations a) Internal Trace Information - If the 1984-based MTA does not support Internal Trace Information per clause 7.3.2 of part 7, the following description is not applicable. When a 1988-based MTA supports interworking with a 1984-based MTA that generates Internal Trace Information as per clause 7.3.3 of part 7, the 1988-based MTA must support reception of the Internal Trace Information by converting the Internal Trace Information from the form in clause 7.3.2 of part 7 to the form specified in 1988 X.411, as per the following description. When the 1988-based MTA sends to a 1984 MTA, the 1988-based MTA must apply the conversion to 1984, as described below. The Stable NBS Implementation Agreements X.400 (1984) definition for MTA's Internal Trace Information is different from the X.400 (1988) MTA definition. Consequently, a X.400 (1988) MTA operating in an MD with other MTAs of 1984 vintage, must map the Internal Trace Information to and/or from the 1984 format. Figures 2 and 3 depict algorithms for mapping between X.400 (1988) Internal Trace element formats and the OIW IA X.400 (1984) Internal Trace element format. To avoid potential looping within a MD composed of 1984 and 1988 vintage MTAs, MD administrators are strongly advised to name all MTAs (1984 and 1988 vintages) using only the Printable String characters. In X.400 (1988) the MTA-Name is defined to be named using IA5 String characters where in the IAs for X.400 (1984) MTAs, NBS restricted the MTA-Name to be formed using the Printable String character subset of IA5. If the 1988-based MTA Name uses IA5 characters not in the Printable String subset, that Internal Trace Element should be omitted when converting from 1988 to 1984. 19 Part 8: Message Handling Systems September 1993 (Working) +---------------------------------------------------------------+ | For each Internal Trace element in the sequence: | | DO | | IF global-domain-identifier does not identify the | | current domain THEN | | Discard all internal trace elements up to this point, | | including this element; | | ELSE IF converted-encoded-information-types present THEN | | Discard all internal trace elements up to this point, | | including this element; | | ELSE IF MTA-Name is made up of non-PrintableString | | characters THEN | | Discard this Internal Trace element; | | ELSE | | { Discard the GlobalDomainIdentifier; | | Within the MTASuppliedInformation: | | Copy the arrival time over; | | Copy the routing action over; | | IF attempted is present | | { IF it is a domain: | | Discard the `attempted' attribute; | | IF it is an MTA: | | Copy it to PreviousMTAName; | | } | | IF the additional actions are present: | | { IF the deferred time is present: | | Copy it over; | | IF other-actions is present: | | IF `redirected' or `dl-operation' (from | | A/3311) THEN | | [NOTE: Another instance of Internal Trace | | Info must be added following the instance | | being processed!] | | Discard it; | | } | | Append the Internal Trace Info to the output list; | | IF other-actions requires an additional instance THEN| | { Copy the arrival time from the previous instance;| | Copy the MTAName from the previous instance; | | Set the `action' attribute to `recipient- | | reassigned (2)'; | | Append the Internal Trace Info to the | | output list; | | } | | } | | END-DO | +---------------------------------------------------------------+ Figure 2 - 1988 to 1984 Mapping 20 Part 8: Message Handling Systems September 1993 (Working) +---------------------------------------------------------------+ | Find the [APPLICATION 30] entry in the P1 envelope; | | FOR each Internal Trace element: | | DO | | Insert the GlobalDomainIdentifier of this MTA; | | Copy the MTAName over; | | Within the MTASuppliedInfo: | | Copy the arrival time; | | IF the deferred time is present: | | copy it to the additional actions field within the | | 1988 Internal Trace information; | | IF the routing action is Relayed or Rerouted: | | copy it over; | | IF the routing action is Recipient-reassigned: | | map to Relayed; | | IF the previous MTAName is present: | | copy it to the MTAName in the attempted field; | | | | END-DO | +---------------------------------------------------------------+ Figure 3 - 1984 to 1988 Mapping NOTE - The 1988 X.419 Recommendation acknowledges that a 1984 system may receive messages containing new distinguished [integer] values that it is not expecting, and that this may result in service irregularities. It is implied that it would be optimal for 1984 systems to accept these unexpected integer values if at all possible. No downgrading should be done for these values when passing affected messages from newer systems to older systems. 7 MHS Management NOTE - For further study. 21 Part 8: Message Handling Systems September 1993 (Working) 8 IPM Service 8.1 Introduction This clause specifies IPM conformance requirements. Conformance to AMH2 is required, as well as support og the Interworking functional group. 9 EDI Messaging Service Editor's Note - This section is left in the Working Text until AMH3 is finalized. 9.1 Introduction This clause specifies the requirements for an EDI Messaging Service (EDIMS). These requirements are based on Recommendations X.435 and F.435 which define the P(edi) content type and outline various EDIMS operational scenarios. This EDIMS Implementation Agreement separates the functions of the base standard into a Kernel and optional Functional Groups (FGs). These functional groups may be used to support the different scenarios of the EDIMS. The following functional groups are defined: - EDIMS Security - EDIMS Forwarding - EDIMS Multipart Body These agreeements classify the support of these functional groups as follows: Table 28 - EDIMS Functional Groups +------------------------------------------+------------------+ | Functional Group | Support | +------------------------------------------+------------------+ | EDIMS Forwarding | O | | EDIMS Security | O | | EDIMS Multi Part Body | O | +------------------------------------------+------------------+ | Notes | +-------------------------------------------------------------+ 22 Part 8: Message Handling Systems September 1993 (Working) 9.2 EDIMS Elements of Service Tables 29.1 and 29.2 specify the requirements for support of EDIMS EoS by a UA conforming to the EDIMS functional group of this Agreement. The classification scheme for support of EoS is as defined in clause 6.2. Table 29.1 - EDIMS: Basic EDI Elements of Service +----------------------------------------------+------+-------+ | Element of Service | Orig | Recep | +----------------------------------------------+------+-------+ | Access Management | M1 | M1 | | Content Type Indication | M | M | | Converted Indication | - | M | | Delivery Time Stamp Indication | - | M | | EDI-message Identification | M | M | | Message Identification | M | M | | Non-delivery Notification | M | - | | Original Encoded Information | | | | Types Indication | M | M | | Submission Time Stamp Indication | M | M | | Typed Body | M | M | | User/UA Capabilities Registration (1988) | - | M1 | +----------------------------------------------+------+-------+ | Notes | | 1 In the case of a collocated UA/MTA or collocated | | UA/MS, the method and extent to which this Element of | | Service is provided is a local matter; it is not | | necessarily testable in the absence of support for the | | P3 or P7 protocol. | +-------------------------------------------------------------+ 23 Part 8: Message Handling Systems September 1993 (Working) Table 29.2 - EDIMS: Optional EDI Elements of Service +--------------------------------+----------+-----------------+ | | Kernel | Func. Group | +--------------------------------+-----+----+-------+----+----+ | Element of Service |Orig |Rec | FG |Orig|Rec | +--------------------------------+-----+----+-------+----+----+ | Alternate Recipient Allowed | M | M | | | | | Alternate Recipient Assignment | - | O | | | | | Application Security Element | O | O1 | SEC-C | M | M | | Character Set | M | M | | | | | Content Confidentiality | O | O |SEC-A,B| C7 | C | | Content Integrity5 | O | O |SEC-A,B| C7 | C | | Conversion Prohibition | M | M | | | | | Conversion Prohibition in Case | | | | | | | of Information Loss (1988) | O | O | | | | | Cross Reference Information | O | M | MPB | M | M | | Deferred Delivery | M | - | | | | | Deferred Delivery Cancellation | M | - | | | | | Delivery Notification | M | - | | | | | Designation of Recipient by | | | | | | | Directory Name | O | - | | | | | Disclosure of Other Recipients | M | M | | | | | DL Expansion History Ind.(1988)| - | M | | | | | DL Expansion Prohibited | M | - | | | | | EDI Forwarding | O | - | FWD | M | - | | EDI Message Type(s) | M | M | | | | | EDI Notification Request | M | M | | | | | EDI Standard Indication | M | M | | | | | EDIM Responsibility Forwarding | | | | | | | Allowed Indication | M | M | | | | | EDIN Receiver | O | M | FWD | M | M | | Expiry Date/Time Indication | O | M | | | | | Explicit Conversion | O | - | | | | | Grade of Delivery Selection | M | M | | | | | Hold for Delivery | - | O4 | | | | | Implicit Conversion | - | O | | | | | Incomplete Copy Indication | O | M | FWD | O2 | M | | Interchange Header | M | M | | | | | Latest Delivery Designation | O | - | | | | | Message Flow Confidentiality | O | - | | | | | Message Origin Authentication5 | O | O |SEC-A,B| C7 | C | | Message Security Labelling | O | O |SEC-A,B| C7 | C | | Message Sequence Integrity | O | O | | | | | Multi-Destination Delivery | M | - | | | | | Multi-Part Body | O | M | MPB | M | M | | Non-repudiation of Content | | | | | | | Originated | O | O | SEC-B | M | M | | Non-repudiation of Content | | | | | | | Received | O | O | SEC-B | M | M | | Non-repudiation of Content | | | | | | 24 Part 8: Message Handling Systems September 1993 (Working) | Received Request | O | O | SEC-B | M | M | | Non-repudiation of Delivery | O | O |SEC-A,B| C7 | C | | Non-repudiation of EDI | | | | | | | Notification | O | O | SEC-B | M | M | | Non-repudiation of EDI | | | | | | | Notification Request | O | O | SEC-B | M | M | +-------------------------------------------------------------+ Table 29.2 EDIMS: Optional EDI Elements of Service (concluded) +--------------------------------+----------+-----------------+ | | Kernel | Func. Group | +--------------------------------+-----+----+-------+----+----+ | Element of Service |Orig |Rec | FG |Orig|Rec | +--------------------------------+-----+----+-------+----+----+ | Non-repudiation of Origin6 | O | O |SEC-A,B| C7 | C | | Non-repudiation of Submission | O | O | | | | | Obsoleting Indication | O | M | | | | | Originator Indication | M | M | | | | | Originator Requested Alternate | | | | | | | Recipient (1988) | O | - | | | | | Prevention of Non Delivery | | | | | | | Notification | O | - | | | | | Probe | O | - | | | | | Probe Origin Authentication | O | - | | | | | Proof of Content Received | O | O |SEC-A,B| M | M | | Proof of Content Received | | | | | | | Request | O | O |SEC-A,B| M | M | | Proof of Delivery | O | O | | | | | Proof of EDI Notification | O | O |SEC-A,B| M | M | | Proof of EDI Notification | | | | | | | Request | O | O |SEC-A,B| M | M | | Proof of Submission | O | - | | | | | Recipient Indication | M | M | | | | | Redirection Disallowed by | | | | | | | Originator | O | - | | | | | Redirection of Incoming | | | | | | | Messages (1988) | - | O | | | | | Related Message(s) | O | M | | | | | Report Origin Authentication | O | O | | | | | Requested Delivery Method | M | - | | | | | Restricted Delivery (1988) | - | O | | | | | Return of Contents3 | O | - | | | | | Secure Access Management | O | - | | | | | Services Indication | O | O | | | | | Stored EDI Message Auto-forward| - | O | | | | | Use of Distribution List (1988)| O | - | | | | +--------------------------------+-----+----+-------+----+----+ | Notes | | 1 This EOS requires a bilateral agreement. | | 2 Mandatory when an implementation supports the removal | 25 Part 8: Message Handling Systems September 1993 (Working) | of body parts. | | 3 A defect report was submitted to CCITT/ISO by EWOS/ETSI, | | since the Return of Contents EoS was omitted from the | | list of EDIMS EoS in F.435. | | 4 Mandatory if P3 is supported. | | 5 SEC-A or SEC-B EoS may require the use of these services.| | 6 SEC-B EoS may require the use of this service. | | 7 Support of this EOS is dependent on the MHS Security | | Class implemented to support security class EDI-A | | (SEC-A) or EDI-B (SEC-B). See clause 10. | +-------------------------------------------------------------+ 9.3 P(EDI) Protocol The requirements for EDI-UA support of the EDI protocol (Pedi) elements are defined in clause A.1. 9.3.1 MS Attributes Refer to Clause A.12, Table 47, for MS attributes support required for this functional group. 9.4 EDIMS Multi-Part Body Functional Group 9.4.1 General The EDIMS Multi-Part Body functional group defines the services and functionality required to support the origination and reception of multiple body parts in an EDIM. 9.4.2 Elements of Service The EDIMS Multi-Part Body functional group constitutes support of the following Elements of Service on origination and reception: - Cross Reference Information - Multi-Part Body 26 Part 8: Message Handling Systems September 1993 (Working) 9.5 EDI Message Store (EDI-MS) See Table 4 for EoS support for the EDI-MS, as well as the Stored EDI Message Auto-Forward EoS in Table 29.2. The EDI-MS provides more flexible access to the general attributes (see clause ?, table 43, enhanced column) as well as supporting EDIMS attributes (see clause A.2). EDI UAs can make use of either the basic MS or the EDI MS. Clause A.2 is to be read in accordance with Annex C of X.435. An EDI-MS shall, at a minimum, support the MS attributes indicated as M under column "EDI MS Org." An EDI-UA usomg an EDI-MS shall support MS attributes indicated as M under column "EDI UA Rec." 9.6 Conversion No explicit conversions have been defined for the Primary Body Part (which contains an EDI Body Part or EDIM Body Part) by the MTS. Implicit or explicit conversion of the other Body Parts (which contain additional information, such as graphics or text) shall conform to the specification in section 13.6, IPM Service Body Part Conversion Functional Group. Note that any conversions performed by the receiving EDI-UA are independent of the setting of the Implicit Conversion Prohibited EoS, or of any other EoS pertaining to conversion. The use of some MHS Security EoS require that any conversion that is performed by the receiving EDI-UA be done after security services are performed. NOTE - Implicit conversion of the Primary Body Part is for further study. 9.7 EDIMS Security Functional Group The EDIMS Security functional group defines the services and functionality required to provide security for EDIMs and EDINs. These security features are specific to the EDIMS, and are described in X.435. As the interface between the EDI Messaging (EDIMG) user and the EDI-UA is outside the scope of this document, implementations of the security mechanisms can be implemented as a discrete hardware/software component or within the EDI-UA. NOTE - There are alternative methods of providing security 27 Part 8: Message Handling Systems September 1993 (Working) to the EDIMG user. For example, the EDI-UA may just avail itself of the (content-type independent) security services provided or supported by the (1988) MHS and described in section 10 (e.g., content confidentiality, proof of delivery), without using the additional services of this functional group. Finally, security services may be provided within the EDI interchange itself, while possibly using the EDI Application Security Element to convey some (bilaterally agreed) security arguments (e.g., key IDs) in the EDIM header. The EDIMS Security functional group is specified as two security classes, denoted EDI-A and EDI-B. Note that the services provided below are provided, in some cases, by 1988 MHS security elements in the P1 (and P3) envelope. For example, depending on the security policy in force, the proof and non repudiation services below use the Content Integrity Check or Message Origin Authentication Check protocol elements. See Section 10 of these Agreements for a description of the 1988 MHS Security functional group and classes. Annex A of these Agreements outlines support of the security protocol elements by the MTS. Please note that, depending on the security policy in force, either security class S0 or S2 might be suitable for support of the EDI security classes. NOTE - In order to counter the threat that a message could be stolen and its value credited to a third party, the use of content confidentiality is recommended. When using S0A, the base security EoS shall be used in the following way: - the Content integrity check shall be generated from the clear content; - the Content integrity check shall be carried in the message token; - Content confidentiality shall be used. Encryption of the content prevents re-generation of the Content integrity check by a third party. 9.7.1 EDIMS Security Class EDI-A (SEC-A) This class provides proof services; the recipient of an EDI information object can be assured that it was originated by the specified EDIMG user. Table 29 outlines support for the EoS contained in this class. 28 Part 8: Message Handling Systems September 1993 (Working) 9.7.2 EDIMS Security Class EDI-B (SEC-B) This class provides non repudiation services. These are "stronger" than the corresponding proof services in the sense that the recipient of an EDI information object can prove to a third party that the object was originated by the specified EDIMG user. Table 29 outlines support for the EoS contained in this class. 9.7.3 EDIMS Security Class EDI-C (SEC-C) The security class EDI-C offers the following Element of Service: - Application Security Element This security class mandates that the above service is provided by an EDIMS end system. 9.8 Physical Delivery For the Physical Delivery Functional Group, there are no additional requirements of Elements of Service for EDIMS, beyond those identified in section 11.1, Table 21, and Table 22. An EDIMS Physical Delivery Access Unit (PDAU) shall support the EoS classification in the "PDAU Reception" column. The EDIMS PDAU shall also support the P-edi protocol and conform to clause A.11, Table 46, column "Support by EDI UA" on reception. An EDI-UA that claims conformance to the Physical Delivery functional group shall support the EoS classification in clause 11.1.2, Table 21, column "UA Origination," and the character string support requirements, Table 22, column "Origination (UA)." 9.9 EDIMS Forwarding Functional Group 9.9.1 General The EDIMS Forwarding functional group defines the services and functionality required to perform forwarding of an EDI message by or on behalf of an EDIMG user. An EDI-UA or EDI-MS claiming conformance to the EDI Forwarding functional group shall understand the semantics of the EDIMS abstract operations and service with regard to forwarding, EDI Notifications and EDIN reasons/diagnostic codes. The EDI-UA or 29 Part 8: Message Handling Systems September 1993 (Working) EDI-MS shall generate appropriate EDI notifications when accepting, forwarding, or refusing responsibility for the EDI message. These notifications may be generated automatically by an EDI-MS or EDI-UA based on the presence or absence of an EDI-MS in the configuration. In addition, notifications may be generated as a result of a request by the EDIMG user. Please refer to Section 17.3.3 of X.435 for a full description of EDI Forwarding. An EDI-UA that claims conformance to the EDIMS Forwarding functional group shall conform to clause A.12, Table 47, as regards protocol elements required by this functional group. 9.9.2 Elements of Service The EDIMS Forwarding functional group constitutes support of the following Elements of Service: - EDI Forwarding - EDIN Receiver Conditional on the support of removal of body parts, the EDIMS Forwarding functional group offers the additional element of service: - Incomplete Copy Indication 9.10 Use of Directory Please refer to Annex D of F.435 and Annexes H and J of X.435 for a recommended DIT structure and procedures for use of the Directory by the EDIMS. This structure assumes the use of a directory subtree for each naming authority (e.g., DUNS). The naming authority is of class organization, and will allocate an entry for each of its users; the RDN of each user is the name as issued by the naming authority. This entry will typically contain such attributes as the X.400 O/R address of the EDI user, EDI capabilities, etc. Additionally, aliasing may be used to allow other access paths to this entry (e.g., via the normal organizational hierarchy). Note that these recommendations assume the EDI-UA performs name resolution (O/R Address lookup) given the EDI name (recipient ID) from an EDI interchange. The correspondding directory name can be constructed or derived from the recipient identification code (EDI name) and qualifier (organization and, optionally, country). 30 Part 8: Message Handling Systems September 1993 (Working) A mapping table may be necessary to map the qualifier to a directory organization and country, as a local matter. 9.11 EDI-UA Conformance The EDI functional group requires the support of the EDIFACT and ANSI X12 EDI syntaxes. 10 Management Domain Agreements Editor's Note - This section has been moved to an informative annex. It might also go in a separate implementation guide. 31 Part 8: Message Handling Systems September 1993 (Working) Annex A (normative) MHS Protocol Specifications Editor's Note - Covered in the ISP. (This annex needs extensive review to find any deltas to the ISP.) A.1 EDI Messaging Service Protocol (Pedi) 32 Part 8: Message Handling Systems September 1993 (Working) Table 46 - Classification of the Pedi Protocol Elements +--------------------------------------------------------------+- ------------+ | EDI Messaging Service Protocol (Pedi) | Part 1 of 6 | +---------------------------------------+----------------------+- ------------+ | Support by EDI | | +---------------------------------+-+UA +------+---+-------------------------+ | Protocol Element |S|O/R| FGs |O/R| Comments/References | +---------------------------------+-+---+------+---+------------- ------------+ | InformationObject | | | | | | | edim |M|M/M| | | | | edin |M|M/M| | | | | | | | | | | | EDIMIdentifier |M|M/M| | | | | user |M|M/M| | | | | user-relative-identifier |M|M/M| | | | | | | | | | | | ExtensionField |M|M/M| | | | | type |M|M/M| | | | | criticality |M|M/M| | | | | value |M|M/M| | | | | | | | | | | | EDIM |M|M/M| | | | | heading |M|M/M| | | | | body |M|M/M| | | | | | | | | | | | Heading | | | | | 33 Part 8: Message Handling Systems September 1993 (Working) | | this-EDIM |M|M/M| | | | | originator |O|M/M| | | | | recipients |O|M/M| | | | | edin-receiver |O|O/M| FWD |M/M| | | responsibility-forwarded |O|O/M| FWD |M/M| | | edi-bodypart-type |O|M/M| | | | | incomplete-copy |O|O/M| FWD |O/M| See Note 2 | | expiry-time |O|O/M| | | | | related-messages |O|O/M| | | | | obsoleted-EDIMs |O|O/M| | | | | edi-application-security- | | | | | | | elements |O|O/O|SEC-C |M/M| | | cross-referencing-information |O|O/M| MBP |M/M| | | edi-message-type |O|M/M| | | | | service-string-advice |O|M/M| | | | | syntax-identifier |O|M/M| | | | | interchange-sender |O|M/M| | | | | date-and-time-of-preparation |O|M/M| | | | | application-reference |O|M/M| | | | | heading-extensions |O|O/M| | | See Note 3 | | | | | | | | | | | | | | | | | | | | | | +---------------------------------+-+---+------+---+------------- ------------+ 34 Part 8: Message Handling Systems September 1993 (Working) Table 46 - Classification of the Pedi Protocol Elements (continued) +--------------------------------------------------------------+- ------------+ | EDI Messaging Service Protocol (Pedi) | Part 2 of 6 | +---------------------------------------+----------------------+- ------------+ | Support by EDI | | +---------------------------------+-+UA +------+---+-------------------------+ | Protocol Element |S|O/R| FGs |O/R| Comments/References | +---------------------------------+-+---+------+---+------------- ------------+ | RecipientSubfield | | | | | | | recipient |M|M/M| | | | | action-request |O|O/M| | | | | edi-notification-requests-field|O|M/M| | | | | responsibility-passing-allowed |O|M/M| | | | | interchange-recipient |O|M/M| | | | | recipient-reference |O|M/M| | | | | interchange-control-reference |O|M/M| | | | | processing-priority-code |O|M/M| | | | | acknowledgement-request |O|M/M| | | | | communications-agreement-id |O|M/M| | | | | test-indicator |O|M/M| | | | | authorization-information |O|M/M| | | | | recipient-extensions |O|O/M| | | See Note 3 | | | | | | | | | EDINotificationRequestsFields | | | | | | | edi-notification-requests |O|M/M| | | | 35 Part 8: Message Handling Systems September 1993 (Working) | edi-notification-security |O|O/O|SEC-A |M/M| | | | | |SEC-B |M/M| | | edi-reception-security |O|O/O|SEC-A |M/M| | | | | |SEC-B |M/M| | | | | | | | | | InterchangeRecipientField | | | | | | | recipient-identification |M|M/M| | | | | identification-code-qualifier |O|M/M| | | | | routing-address |O|M/M| | | | | | | | | | | | RecipientReferenceField | | | | | | | recipient-reference |M|M/M| | | | | recipient-reference-qualifier |O|M/M| | | | | | | | | | | | EDINReceiverField | | | | | | | edin-receiver-name |M|M/M| | | | | original-edim-identifier |O|O/M| FWD |M/M| | | first-recipient |O|O/M| FWD |M/M| | | | | | | | | | RelatedMessageField | | | | | | | RelatedMessageReference |M|M/M| | | | | edi-message-reference |O|M/M| | | | | external-message-reference |O|M/M| | | | | | | | | | | | EDIApplicationSecurityElements- | | | | | | 36 Part 8: Message Handling Systems September 1993 (Working) | Field | | | | | | | edi-application-security- | | | | | | | element |O|M/M| | | | | edi-encrypted-primary-bodypart |O|M/M| | | | | edi-application-security- | | | | | | | extensions |O|O/M| | | See Note 3 | | | | | | | | +---------------------------------+-+---+------+---+-------------------------+ 37 Part 8: Message Handling Systems September 1993 (Working) Table 46 - Classification of the Pedi Protocol Elements (continued) +--------------------------------------------------------------+- ------------+ | EDI Messaging Service Protocol (Pedi) | Part 3 of 6 | +---------------------------------------+----------------------+- ------------+ | Support by EDI | | +---------------------------------+-+UA +------+---+-------------------------+ | Protocol Element |S|O/R| FGs |O/R| Comments/References | +---------------------------------+-+---+------+---+------------- ------------+ | CrossReferencingInformation- | | | | | | | Subfield | | | | | | | application-cross-reference |M|M/M| | | | | message-reference |O|M/M| | | | | body-part-reference |M|M/M| | | | | | | | | | | | ServiceStringAdviceField | | | | | | | component-data-element- | | | | | | | separator |M|M/M| | | | | data-element-separator |M|M/M| | | | | decimal-notation |M|M/M| | | | | release-indicator |O|M/M| | | | | reserved |O|M/M| | | | | segment-terminator |M|M/M| | | | | | | | | | | | SyntaxIdentifierField | | | | | | | syntax-identifier |M|M/M| | | | 38 Part 8: Message Handling Systems September 1993 (Working) | syntax-version |M|M/M| | | | | | | | | | | | InterchangeSenderField | | | | | | | sender-identification |M|M/M| | | | | identification-code-qualifier |O|M/M| | | | | address-for-reverse-routing |O|M/M| | | | | | | | | | | | AuthorizationInformationField | | | | | | | authorization-information |M|M/M| | | | | authorization-information- | | | | | | | qualifier |O|M/M| | | | | | | | | | | | Body | | | | | | | primary-body-part |M|M/M| | | | | additional-body-parts |O|O/M| MBP |M/M| | | | | | | | | | PrimaryBodyPart | | | | | | | edi-body-part |O|M/M| | | | | forwarded-EDIM |O|O/M| FWD |M/M| | | | | | | | | | EDIMBodyPart | | | | | | | parameters |O|O/M| FWD |M/M| | | message-data |M|M/M| | | | | | | | | | | | MessageParameters | | | | | | 39 Part 8: Message Handling Systems September 1993 (Working) | delivery-time |O|M/M| FWD |M/M| See Note 1 | | delivery-envelope |O|M/M| FWD |M/M| See Note 1 | +---------------------------------+-+---+------+---+------------- ------------+ Table 46 - Classification of the Pedi Protocol Elements (continued) +--------------------------------------------------------------+- ------------+ | EDI Messaging Service Protocol (Pedi) | Part 4 of 6 | +---------------------------------------+----------------------+- ------------+ | Support by EDI | | +---------------------------------+-+UA +------+---+-------------------------+ | Protocol Element |S|O/R| FGs |O/R| Comments/References | +---------------------------------+-+---+------+---+------------- ------------+ | other-parameters |O|O/O| | | See Note 4 | | | | | | | | | MessageData | | | | | | | heading |M|M/M| | | | | body |M|M/M| | | | | | | | | | | | BodyOrRemoved | | | | | | | primary-or-removed |M|M/M| | | | | additional-body-parts |O|M/M| | | | | | | | | | | | PrimaryOrRemoved | | | | | | | removed-edi-body |O|O/M| | | See Note 5 | | primary-body-part |O|M/M| | | | | | | | | | 40 Part 8: Message Handling Systems September 1993 (Working) | | AdditionalBodyParts | | | | | | | external-body-part |O|M/M| | | | | place-holder |O|O/M| | | See Note 5 | | | | | | | | | EDIM-ExternallyDefinedBodyPart | | | | | | | body-part-reference |O|M/M| | | | | external-body-part |M|M/M| | | | | | | | | | | | EDIN | | | | | | | positive-notification |O|M/M| | | | | negative-notification |O|M/M| | | | | forwarded-notification |O|O/M| FWD |M/M| | | | | | | | | | CommonFields | | | | | | | subject-edim |M|M/M| | | | | edin-originator |M|M/M| | | | | first-recipient |O|M/M| | | | | notification-time |M|M/M| | | | | notification-security-elements |O|O/O|SEC-A |M/M| See Note 8 | | | | |SEC-B |M/M| See Note 8 | | | | |SEC-C |M/M| See Note 8 | | edin-initiator |M|M/M| | | | | notifications-extensions |O|O/M| | | See Note 3 | | | | | | | | | SecurityElementField | | | | | 41 Part 8: Message Handling Systems September 1993 (Working) | | original-content |O|O/O|SEC-A |M/M| See Note 6 | | | | |SEC-B |M/M| | | original-content-integrity- |O|O/O|SEC-A |M/M| See Note 6 | | check | | |SEC-B |M/M| | | edi-application-security- | | | | | | | elements |O|O/O|SEC-C |M/M| | | security-extensions |O|O/M| | | See Note 3 | +---------------------------------+-+---+------+---+------------- ------------+ 42 Part 8: Message Handling Systems September 1993 (Working) Table 46 - Classification of the Pedi Protocol Elements (continued) +--------------------------------------------------------------+- ------------+ | EDI Messaging Service Protocol (Pedi) | Part 5 of 6 | +---------------------------------------+----------------------+- ------------+ | Support by EDI | | +---------------------------------+-+UA +------+---+-------------------------+ | Protocol Element |S|O/R| FGs |O/R| Comments/References | +---------------------------------+-+---+------+---+------------- ------------+ | PositiveNotificationFields | | | | | | | pn-common-fields |M|M/M| | | | | pn-supplementary-information |O|O/M| | | | | pn-extensions |O|O/M| | | See Note 3 | | | | | | | | | NegativeNotificationFields | | | | | | | nn-common-fields |M|M/M| | | | | nn-reason-code |M|M/M| | | | | nn-supplementary-information |O|M/M| | | | | nn-extensions |O|O/M| | | See Note 3 | | | | | | | | | NNReasonCodeField | | | | | | | nn-ua-ms-reason-code |O|M/M| | | | | nn-user-reason-code |O|M/M| | | | | nn-pdau-reason-code |O|O/M| | | | | | | | | | | | NNUAMSReasonCodeField | | | | | | 43 Part 8: Message Handling Systems September 1993 (Working) | nn-ua-ms-basic-code |M|M/M| | | | | nn-ua-ms-diagnostic |O|M/M| | | | | | | | | | | | NNUserReasonCodeField | | | | | | | nn-user-basic-code |M|M/M| | | | | nn-user-diagnostic |O|M/M| | | | | | | | | | | | NNPDAUReasonCodeField | | | | | | | nn-pdau-basic-code |M|M/M| | | | | nn-pdau-diagnostic |O|M/M| | | | | | | | | | | | ForwardNotificationFields | | | | | | | fn-common-fields |M|M/M| | | | | forwarded-to |M|M/M| | | | | fn-reason-code |M|M/M| | | | | fn-supplementary-information |O|O/M| FWD |M/M| | | fn-extensions |O|O/M| | | See Note 3 | | | | | | | | | FNReasonCodeField | | | | | | | fn-ua-ms-reason-code |M|O/M| | | See Note 7 | | fn-user-reason-code |O|O/M| | | See Note 7 | | fn-pdau-reason-code |O|O/M| | | | | | | | | | | | FNUAMSReasonCodeField | | | | | | | fn-ua-ms-basic-code |M|M/M| | | | 44 Part 8: Message Handling Systems September 1993 (Working) | fn-ua-ms-diagnostic |O|M/M| | | | | fn-security-check |O|O/O|SEC-A |M/M| | | | | |SEC-B |M/M| | | | | | | | | +---------------------------------+-+---+------+---+------------- ------------+ Table 46 - Classification of the Pedi Protocol Elements (concluded) +--------------------------------------------------------------+- ------------+ | EDI Messaging Service Protocol (Pedi) | Part 6 of 6 | +---------------------------------------+----------------------+- ------------+ | Support by EDI | | +---------------------------------+-+UA +------+---+-------------------------+ | Protocol Element |S|O/R| FGs |O/R| Comments/References | +---------------------------------+-+---+------+---+------------- ------------+ | FNUserReasonCodeField | | | | | | | fn-user-basic-code |M|M/M| | | | | fn-user-diagnostic |O|O/M| | | | | | | | | | | | FNPDAUReasonCodeField | | | | | | | fn-pdau-basic-code |M|M/M| | | | | fn-pdau-diagnostic |O|M/M| | | | | | | | | | | +---------------------------------+-+---+------+---+------------- ------------+ | Notes | | 1 M on origination if the implementation supports forwarding of a multi | | part EDIM without accepting responsibility. 45 Part 8: Message Handling Systems September 1993 (Working) | | 2 Mandatory (on origination) when an implementation supports the | | removal of body parts. | | 3 Critical extensions must be supported in order to accept | | responsibility. | | 4 Use of supplementary information fields requires bilateral agreement. | | 5 Mandatory on origination if removal of body parts is supported. | | 6 One of these two elements must be supported on origination when using | | the SEC-A or SEC-B EDI security class. | | 7 One of these two elements must be supported on origination. | | 8 M on origination if EDI-notification-security or EDI- reception-security | | (of the EDINotificationRequestsFields) are supported on reception. | +---------------------------------------------------------------- ------------+ A.2 Message Store EDIMS Attribute Support Table 47 specifies the classification of the Message Store EDIMS attributes. This clause is to be read in accordance with Annex C of X.435. For support of MS General Attributes, see table 43, enhanced MS column. 46 Part 8: Message Handling Systems September 1993 (Working) Table 47 - Classification of the Message Store EDIMS attributes +-----------------------------------------------------------+---- ---------+ | Message Store EDIMS Attribute Support | Part 1 of 2 | +------------------------------------------+---+------------+---- ---------+ | Support by: EDI |EDI| Functional Group Support | +------------------------------------+-+UA |MS +--------+--------+--------+ | Attribute |S|Rec|Org| FG | UA Rec | MS Org | +------------------------------------+-+---+---+--------+-------- +--------+ | acknowledgement-request-for-this- | | | | | | | | recipient |O| O | O | | | | | action-request-for-this-recipient |O| O | O | | | | | application-reference |O| O | O | | | | | authorization-information-for- | | | | | | | | this-recipient |O| O | O | | | | | body |M| M | M | | | | | communications-agreement-id-for- | | | | | | | | this-recipient |O| O | O | | | | | cross-referencing-information |O| O | O | | | | | date-and-time-of-preparation |M| M | M | | | | | edi-application-security-elements |O| O | O | EDI-C | M | M | | edi-application-security-extensions|O| O | O | EDI-C | M | M | | edi-body-part |M| M | M | | | | | edi-body-part-type |M| M | M | | | | | edi-message-type |M| M | M | | | | | edi-notification-indicator |O| M | M | | | | | edi-notification-request-for-this- | | | | | 47 Part 8: Message Handling Systems September 1993 (Working) | | | recipient |O| O | O | | | | | edi-notification-security-for- | | | | EDI-A | M | M | | this-recipient |O| O | O | EDI-B | M | M | | edi-reception-security-for-this- | | | | EDI-A | M | M | | recipient |O| O | O | EDI-B | M | M | | edim-body-part |O| O | O | FWD | M | M | | edim-synopsis |O| O | O | | | | | edims-entry-type |M| M | M | | | | | edin-initiator |O| O | O | | | | | edin-originator |O| O | O | | | | | edin-receiver |O| O | O | FWD | M | M | | expiry-time |O| O | O | | | | | externally-defined-body-part-types |O| O | O | MBP | M | M | | first-recipient |O| O | O | FWD | M | M | | fn-extensions |O| O | O | | | | | fn-reason-code |O| O | O | FWD | M | M | | fn-supplementary-information |O| O | O | | | | | forwarded-to |O| O | O | FWD | M | M | | heading |M| M | M | | | | | heading-extension |O| O | O | | | | | incomplete-copy |O| O | O | FWD | M | M | | interchange-control-reference-for- | | | | | | | | this-recipient |M| M | M | | | | | interchange-length |O| O | O | | | | | interchange-recipient-for-this- | | | | | 48 Part 8: Message Handling Systems September 1993 (Working) | | | recipient |M| M | M | | | | | interchange-sender |M| M | M | | | | +------------------------------------+-+---+---+--------+-------- +--------+ 49 Part 8: Message Handling Systems September 1993 (Working) Table 47 - Classification of the Message Store EDIMS attributes (concluded) +-----------------------------------------------------------+---- ---------+ | Message Store EDIMS Attribute Support | Part 2 of 2 | +------------------------------------------+---+------------+---- ---------+ | Support by: EDI |EDI| Functional Group Support | +------------------------------------+-+UA |MS +--------+--------+--------+ | Attribute |S|Rec|Org| FG | UA Rec | MS Org | +------------------------------------+-+---+---+--------+-------- +--------+ | message-data |O| O | O | | | | | message-parameters |O| O | O | | | | | nn-extensions |O| O | O | | | | | nn-reason-code |O| O | O | | | | | nn-supplementary-information |O| O | O | | | | | notification-time |O| O | O | | | | | notification-extensions |O| O | O | | | | | notification-security-elements |O| O | O | EDI-A | M | M | | | | | | EDI-B | M | M | | | | | | EDI-C | M | M | | obsoleted-edims |O| O | O | | | | | originator |O| O | O | | | | | pn-extensions |O| O | O | | | | | pn-supplementary-information |O| O | O | | | | | processing-priority-code-for-this- | | | | | | | | recipient |O| M | M | | | | | recipient-extensions-for-this- | | | | | | | 50 Part 8: Message Handling Systems September 1993 (Working) | recipient |O| O | O | | | | | recipient-reference-for-this- | | | | | | | | recipient |O| O | O | | | | | related-messages |O| O | O | | | | | responsibility-forwarded |O| O | O | FWD | M | M | | responsibility-passing-allowed- | | | | | | | | for-this-recipient |O| O | O | FWD | M | M | | service-string-advice |O| M | M | | | | | subject-edim |M| O | O | | | | | syntax-identifier |M| M | M | | | | | test-indicator-for-this-recipient |O| M | M | | | | | this-edim |M| M | M | | | | | this-recipient |O| O | O | | | | +------------------------------------+-+---+---+--------+-------- +--------+ 51 Part 8: Message Handling Systems September 1993 (Working) Annex B (normative) Naming, Addressing and Routing B.1 ORAddress Attribute List Equivalence Rules Two ORAddresses are equivalent if each contains the same set of attributes and each attribute compares in type and value. The following equivalence rules apply when comparing a provided ORAddress with a collection of known ORAddresses. For example, in order to perform delivery of a message to a recipient, the MTA must unambiguously match the ORAddress contained in the message with the known ORAddresses. See X.402 (1988), section 18.4, for the base standard attribute equivalence rules. The following additional rules must also be applied by the delivering (or non- delivering) MTA: a) An ADMD or PRMD name that is all numeric but encoded as Printable String is considered to be equivalent to the same ADMD or PRMD name, respectively, with the same numeric values encoded as Numeric String. b) An extension attribute encoded as Teletex String shall be compared with the corresponding standard attribute encoded as Printable String if that extension attribute is not present in both ORAddresses. Matching rules are as specified in clause 18.4 of X.402 (1988) (as modified in the MHS Implementors' Guide) except that only teletex graphic characters from repertoire no. 102 need to be compared for Printable String equivalence (i.e., the presence of graphic characters from other repertoires can be treated as a mismatch). NOTES 1 An X.500 Directory service may or may not support these matching rules for equivalence. 52 Part 8: Message Handling Systems September 1993 (Working) B.2 MHS Use of Directory Editor's Note - It has been suggested that much of this material could be moved to an informative annex. B.2.1 Introduction The MHS standards recognize the need of MHS users for a number of directory service elements. Directory service elements are intended to assist users, their UAs, and MTAs in obtaining information for use in submission, delivery, and the transfer of messages. NOTE - The MTS may also use the directory service elements to obtain information, for example, to be used in the routing of messages. This application of the directory service is not defined by the base standards and is therefore not addressed by this Agreement. B.2.2 Functional Configuration B.2.3 Functionality Examples of functional usages of directories have been identified for UAs and the MTAs in conjunction with their DUAs. These are: a) UA Specific Functionality: 1) Verify the existence of a Directory Name. 2) Given a partial name, return a list of possibilities. 3) Search the Directory for entries containing a specified attribute type and value and return the Distinguished Names of the matching entries. 4) Return the O/R Address(es) that correspond to a Directory Name. 5) Determine whether a Directory Name presented denotes a user or a Distribution List. 6) Return the members of a Distribution List. 7) Return the capabilities of the entity referred to by a Directory Name. 53 Part 8: Message Handling Systems September 1993 (Working) 8) Maintenance functions to keep the directory up-to-date, e.g. register and change credentials. b) MTA Specific Functionality: 1) Authentication. 2) Return the O/R Address(es) that correspond to a Directory Name. 3) Determine whether a Directory Name presented denotes a user or a Distribution List. 4) Return the members of a Distribution List. 5) Return the capabilities of the entity referred to by a Directory Name. 6) Maintenance functions to keep the directory up-to-date. In addition to functionality, a number of operational aspects must be considered. These include user-friendliness, flexibility, availability, expandability and reliability. B.2.4 Naming and Attributes Since user-friendliness is of primary importance in a messaging system, the naming conventions used in building the Directory Information Tree (DIT) will impact the ability of a user to make intelligent guesses for Directory Names. It is recommended that the naming guidelines and DIT structures defined in Annex B of Recommendation X.521/ISO 9594-7 be used as the basis for MHS Directory Names. Annex C of Recommendation X.402/ISO 10021-2 specifies further the MHS specific object classes. The naming for MHS specific object classes are recommended as follows: a) The naming for mhs-message-store, mhs-message-transfer-agent, and mhs-user-agent is that of Application Entity in the DIT. b) The naming attribute for mhs-distribution-list is commonName. The organization, organizationalUnit, organizationalRole, organizationalPerson, locality, or groupOfNames can be immediate superior to entries of object class mhs-distribution-list. 54 Part 8: Message Handling Systems September 1993 (Working) c) The naming for mhs-user is that of organizationalPerson, residentialPerson, organizationalRole, organizationalUnit, organization, or locality. NOTE - The mhs-user object class is a generic object class which may be used in conjunction with another standard object class for the purpose of adding MHS information attributes, such as ORAddresses, to a Directory entry. The means to associate attributes of a generic object class to an entry (or to different entries) named by a standard object class(es) is by defining a new (un-)registered object class, whose superclass(es) is that of the naming object class(es), and of the generic object class. E.g., to associate mhs-user attributes in the organizationalPerson entry, a new unregistered object class can be defined as shown in figure 7. +---------------------------------------------------------+ | | | real-user-entry ::= OBJECT CLASS | | SUBCLASS OF organizationalPerson, | | mhs-user | | | +---------------------------------------------------------+ Figure 7 - Example of Unregistered Object Class Definition The MHS object classes, attributes, and attribute syntaxes that need to be supported by the Directory are as specified in Annex C of Recommendation X.402/ISO 10021-2. In addition, the object classes organization, organizationalUnit, organizationalRole, organizationalPerson, locality, groupOfNames, residentialPerson, and country and their attributes and associated syntaxes as defined in X.520 (ISO 9594, Part 6) and X.521 (ISO 9594, Part 7) are required to support the MHS. B.2.5 Directory Services These Implementation Agreements require the Directory services as defined in table 11. Indicated are the Directory services required to support the needs of the MHS UA/MTA and MHS Administrator. 55 Part 8: Message Handling Systems September 1993 (Working) Table 11 - Directory Service Support Requirements +-----------------------------+--------+-------+ | | MHS | MHS | | Directory Service | UA/MTA | Admin | +-----------------------------+--------+-------+ | Bind and Unbind | M | M | | Read | M | M | | Compare | M | M | | Abandon | M | M | | List | M | M | | Search | M | M | | Add Entry | O | M | | Remove Entry | O | M | | Modify Entry | M | M | | Modify RDN | O | O | +-----------------------------+--------+-------+ B.2.6 OIW Application Specific Attributes and Attribute Sets The following attribute is proposed as an addition to mhs-user. mhs-or-addresses-with-capabilities ATTRIBUTE WITH ATTRIBUTE SYNTAX mhs-or-addresses-with-capabilities-syntax MULTI VALUE ::= id-at-mhs-or-addresses-with-capabilities This is similar to a proposal in "Working Draft for ISO/IEC 10021-2/PDAM 3, Second Minor Enhancements," which is expected to be ballotted as a PDAM. Logically, both the present ORAddress and individual capabilities and mhs-or-addresses-with-capabilities would be populated in the Directory for users with multiple O/R addresses. If multiple O/R addresses are returned when an O/R address is requested, the user can then query the new attribute for capabilities of each O/R address. The capabilities of ORAddress would be a union of the capabilities in the 1988 standard of all the O/R addresses. The syntax proposed in the expected PDAM does not fulfill user requirements or future standards requirements, because it is not extensible. Furthermore, the syntax does not make sense, since it specifies multiple sets of capabilities for one ORAddress, and there is no matching rule allowing one to find an ORAddress having a particular capability. The following syntax and matching rules are suggested to overcome the shortcoming in the expected PDAM. 56 Part 8: Message Handling Systems September 1993 (Working) mhs-or-addresses-with-capabilities-syntax ::= SEQUENCE { address ORAddress, capabilities SEQUENCE OF Attribute OPTIONAL } The following matching rule matches on the ORAddress part: address-part-Match MATCHING-RULE ::= { SYNTAX ORAddress ID id-mr-address-part-Match } The following matching rule matches on the capabilities: capabilities-part-Match MATCHING-RULE ::= { SYNTAX AttributeValueAssertion ID id-mr-capabilities-part-Match } For 1993 systems, actual evaluation of assertions would use the equality matching rule associated with the capability attribute presented in the assertion. The returnMatchedValues extension to the Directory Abstract Service could be used to return only the values of the attribute which matched. Matching rules could be defined for the syntax proposed in the working draft but would require tedious enumeration to take into account all of the component of the syntax and the extensions. Automatic construction of a filter by an MTA or an MHS UA for multiple capabilities may result in a filter that exceeds the limits of the DSA holding the recipient's entry. In 1988 systems, all values of the mhs-or-addresses-with-capabilities would be returned. In addition, we propose adding the following attribute to identify the delivery method supported by an ORAddress because it is generally useful to the messaging community. mhs-delivery-method ATTRIBUTE WITH ATTRIBUTE SYNTAX Mhs-delivery-method MULTI VALUE ::= id-at-mhs-delivery-method Mhs-delivery-method ::= INTEGER { mhs-delivery (1), physical-delivery (2), telex-delivery (3), teletex-delivery (4), g3-facsimile-delivery (5), g4-facsimile-delivery (6), ia5-terminal-delivery (7), 57 Part 8: Message Handling Systems September 1993 (Working) videotex-delivery (8), telephone-delivery (9) } NOTE - Mhs-delivery-method includes selected delivery methods from preferredDeliveryMethod in CCITT X.520|ISO/IEC 9594-6. B.2.7 OIW Application Specific Object Classes There are no application specific object classes defined by these Implementation Agreements. B.2.8 Structure Rules This clause defines the naming and structure rules for the MHS object classes which are subclasses of top. B.2.8.1 MHS Distribution List Attribute commonName is used for naming. The mhs-distribution-list, organization, organizationalUnit, organizationalRole, organizationalPerson, locality, or groupOfNames can be immediately superior to entries of object class mhs-distribution-list. B.2.8.2 MHS User The naming for mhs-user is that of organizationalPerson, residentialPerson, organizationalRole, organizationalUnit, organization, or locality. The organizationalPerson, residentialPerson, organizationalRole, organizationalUnit, organization, or locality object classes can be combined with the mhs-user object class to form a new composite object class. B.2.9 Use of Capabilities Information The capabilities information in the X.500 Directory should not be considered sufficient to warrant a non-delivery decision by an originating or relaying MTA. This clause is not intended to impose any conformance requirement. 58 Part 8: Message Handling Systems September 1993 (Working) Annex C (normative) IPM Body Part Support This annex specifies the requirements for support of IPM body part types by a UA conforming to this Agreement. A UA must support those IPM body part types defined in Annex E of X.420 (1988) as listed and qualified in AMH22. Support for reception means that the UA can receive the body part's encoding and, in the case of text body parts, accept all the character encodings in the supported repertoire(s). If an implementation supports a particular body part type for reception, it should also be able to support that body part type for reception if it is part of a forwarded message. If an implementation supports origination of forwarded messages, it must be capable of forwarding every body part that is supported on reception. The reception requirements on the UA do not necessarily include the ability to render (display) all of the characters received. If the message is forwarded, the UA must transmit exactly equivalent characters, but not necessarily from the same character set. 59 Part 8: Message Handling Systems September 1993 (Working) +-------------------------------------------------------------+ | BodyPart ::= CHOICE { | | ia5-text [0] IA5TextBodyPart, | | . | | oda-1984 [12] IMPLICIT OCTET STRING, | | iso-6937 [13] ISO6937BodyPart, | | bilaterally-defined [14] Unidentified, | | externally-defined [15] ExternallyDefinedBodyPart, | | . | | . | | [310] IMPLICIT | | USAPrivatelyDefinedBodyParts,| | . } | | | | Unidentified := OCTET STRING | | | | The content of the ODA OCTET STRING will contain a value of | | type ODABodyPart as follows: | | | | ODABodyPart ::= SEQUENCE { | | ODABodyPartParameters, | | ODAData } | | | | The Parameters and Data components are defined in Annex E | | of CCITT Recommendation T.411 (1988) (ISO 8613-1). | | | | USAPrivatelyDefinedBodyParts are defined as: | | | | SEQUENCE {BodyPartNumber, ANY} | | | | BodyPartNumber ::= INTEGER | | | | These privately-defined body part types are specified as an | | interim measure to provide backward compatibility with 1984 | | MHS implementations. For interworking between UAs based on | | the 1988 (or later) MHS standards, it is strongly | | recommended that the externally-defined body part be used | | instead. | | | | The undefined bit in P1 EncodedInformationTypes must be set | | when a message contains a privately defined body part. Each | | UA that expects such body parts should include undefined in | | the set of deliverable EncodedInformationTypes it registers | | with the MTA. | | | | Body part numbers are interpreted relative to the body part | | type in which they are used. OIW registers body part | | numbers for privately-defined formats within the United | | States. | +-------------------------------------------------------------+ 60 Part 8: Message Handling Systems September 1993 (Working) Figure 10 - Privately-Defined Body Parts 61 Part 8: Message Handling Systems September 1993 (Working) Annex D (normative) Object Identifiers D.1 X.400 SIG Object Identifiers The X.400 SIG object identifiers all allocated under the mhsig node in the OIW object identifier subtree, as defined in part 6 of the Stable Implementors Agreements document. This definition is duplicated in figure 15. +---------------------------------------------------------------- ------------+ | | | id-mhsig OBJECT IDENTIFIER ::= | | { iso (1) identified-organization (3) oiw (14) mhsig (6) } | | | +---------------------------------------------------------------- ------------+ Figure 15 - Definition of the mhsig Object Identifier The X.400 SIG has defined several categories of object identifiers. Their definition is provided in figure 16. +---------------------------------------------------------------- ------------+ | | | id-mhsig-content-types OBJECT IDENTIFIER ::= | | { id-mhsig content-types (0) } | | | | id-mhsig-body-part-types OBJECT IDENTIFIER ::= | | { id-mhsig body-part-types (1) } | | | +---------------------------------------------------------------- ------------+ Figure 16 - Defintion of the X.400 SIG Object Identifier Categories. 62 Part 8: Message Handling Systems September 1993 (Working) D.2 Content Types There are presently no object identifiers for content types allocated by the X.400 SIG. D.3 Body Part Types The object identifiers for the external body part types allocated by the X.400 SIG are defined in figure 17. +---------------------------------------------------------------- ------------+ | | | id-privacy-enhanced-mail OBJECT IDENTIFIER ::= | | { id-mhsig-body-part-types pem (0) } | | | +---------------------------------------------------------------- ------------+ Figure 17 - Definition of the External Body Part Object Identifiers D.4 Security Classes Editor's Note - Identical to the ISP. 63 Part 8: Message Handling Systems September 1993 (Working) Annex E (informative) Interpretation of Elements of Service The objective of this clause is to provide clarification, where required, on the functionality of Elements of Service where the MHS standards are unclear or ambiguous. It is not the intent of this clause to define how information should be made available or presented to an MHS user, nor is it intended to define how individual vendors should design their products. The following MHS Elements of Service require further text to be added to their definitions to represent the proposed implementation of these Elements of Service for conformance to this Agreement. Elements of Service which are not referenced in this clause are as defined in the MHS base standards. Reply Request Indication: The reply-recipients and the reply-time may be specified without any explicit reply being requested. This may be interpreted by the recipient as an implicit reply request. NOTE - For an auto-forwarded message an explicit or implicit reply request may not be meaningful. Forwarded IP-message Indication: The following use of the original encoded information type in the context of forwarded messages is clarified: a) The encoded information types of the message being forwarded should be reflected in the new original encoded information types being generated. b) If forwarding a privately defined body part (see figure 10), the originator of the forwarding message shall set the original encoded information types in the P1 envelope to Undefined for that body part. 64 Part 8: Message Handling Systems September 1993 (Working) Annex F (informative) Recommended Practices This clause provides guidelines on areas not addressed by the base standards. These guidelines have been produced in order to promote awareness of interim solution to problems as agree by members of the OIW X.400 SIG. However implementors of these recommended practices should note that it is not necessary to follow the recommended practices when claiming conformance to these agreements. Implementors should also note that future standardization by CCITT and ISO/IEC on area covered by this clause may result in different solutions to those proposed in this clause. F.1 Printable String There are existing mail systems that include a small set of non- Printable String characters in their identifiers. For these systems to communicate with MHS systems, either for pass-through service or delivery to MHS users, gateways will be employed to encode these special characters into a sequence of Printable String characters. This conversion should be performed by the gateway according to a common scheme and before insertion in Domain Defined Attributes, which are intended to carry electronic mail identifiers. MHS UAs may also perform such conversions. It is recommended that the following symmetrical encoding and decoding algorithm for non-Printable String characters be employed. The encoding algorithm maps an ASCII representation to a PrintableString representation. Any non-printable string characters not specified in table 49 are covered by the category "other". Table 49 - Printable String to ASCII Mapping +--------------------+----------------------------+ | ASCII Character | Printable String Character | +--------------------+----------------------------+ | % (percent) | (p) | | @ (at sign) | (a) | | ! (exclamation) | (b) | | " (quote mark) | (q) | | _ (underline) | (u) | | ( (left paren.) | (l) | | ) (right paren.) | (r) | | other | (3DIGIT) | +--------------------+----------------------------+ 65 Part 8: Message Handling Systems September 1993 (Working) where 3DIGIT has the range 000 to 377 and is interpreted as the octal encoding of an ASCII character. To encode an ASCII representation to a PrintableString, table 49 and the algorithm in figure 19 should be used. +-------------------------------------------------------+ | IF current character is in the encoding set THEN | | encode the character according to table 49 | | ELSE | | write the current character; | | continue reading; | +-------------------------------------------------------+ Figure 19 - ASCII to PrintableString Algorithm To decode a PrintableString representation to an ASCII representation, table 48 and the algorithm in figure 20 should be used. +-------------------------------------------------------+ | IF current character is not "(" THEN | | write character | | ELSE | | { | | look ahead appropriate characters; | | IF composite characters are in table 48 THEN | | decode per table 48 | | ELSE | | write current character; | | } | | continue reading; | +-------------------------------------------------------+ Figure 20 - PrintableString to ASCII Algorithm F.2 Rendition of IA5Text The characters that may be used in an IA5String are the graphic characters (including Space), control characters and Delete of the IA5 character repertoire ISO 646. The graphic characters that may be used with a guaranteed rendition are those related with positions 2/0 to 2/2, 2/5 to 3/15, 4/1 to 5/10, 5/15 and 6/1 to 7/10 in the basic 7-bit code table. The other graphic characters may be used but have no guaranteed rendition. The control characters that may be used but have no guaranteed 66 Part 8: Message Handling Systems September 1993 (Working) effect are a subset consisting of the format effectors 0/10 (LF), 0/12 (FF) and 0/13 (CR) provided they are used in one of the following combinations as defined in table 50. Table 50 - Interpretation of Format Effector Combinations +-------------+----------------------------------------------+ | Combination | Interpretation | +-------------+----------------------------------------------+ | CR LF | to start a new line | | CR FF | to start a new page (and line) | | LF .. LF | to show empty lines (always after one of the | | | preceding combinations). | +-------------+----------------------------------------------+ The other control characters or the above control characters in different combinations may be used but have no guaranteed effect. The character Delete may occur but has no guaranteed effect. The IA5String in a P2 IA5Text BodyPart represents a series of lines which may be divided into pages. Each line should contain from 0 to 80 graphic characters for guaranteed rendition. Longer lines may be arbitrarily broken for rendition. NOTE - X.408 states that for conversion from IA5Text to Teletex, the maximum line length is 77 characters. F.3 EDI Use of MHS Editor's Note - This section may be moved to the ISP. F.3.1 P0 Recommended Practice This section outlines a recommended method for interworking between a P(edi) UA with a UA implementing the Recommended Practice (EDI Use of X.400) in parts 7 and 8 of the OIW Stable Implementation Agreements. That Recommended Practice is commonly referred to as the "P0" approach to EDI use of the X.400 MTS. This section does not define where the conversion between the two content types occurs. It is possible for the conversion to be performed by the P0 UA, the P(edi) UA, or a gateway. The Recommended Practice outlined in this section only attempts to document the rules that should be followed to ensure a conversion which retains the maximum amount of information. 67 Part 8: Message Handling Systems September 1993 (Working) F.3.1.1 P0 to P(edi) Conversion The converting entity may assume that the P0 content contains only one EDI interchange. This interchange will become the first and only body part of the EDIM. The content type field of the message will have the value "undefined" before the conversion and will have the integer value "35" or the object identifier value for P(edi) which is specified in X.435 after conversion. The EDIM Heading fields can be formed using the following rules: EDIMIdentifier: Originator ORName concatenated with the UTCTime at which the conversion from P0 to P(edi) was performed. Originator: Originator ORName. Recipients: Recipients from the P1 envelope. EDI Notification Requests are not specified as none are requested when using the P0 approach. EDIBodyPartType: This element may have one of deveral values depending on the encoded information type (EIT) value of the P0 message or the ability of the converting entity to determine which EDI syntax is present in the content: a) X.435-defined value for ANSI X12/EBCDIC if the EIT field of the P1 envelope has the value "undefined". b) X.435-defined value for ANSI X12/ISO 646 if the EIT field of the P1 envelope has the value "IA5String". c) Any other valid value if the entity performing the conversion can determine which EDI syntax is contained in the content and which character encoding is used for the EDI syntax. Other heading fields will only be set if the entity performing the conversion is capable of parsing the EDI Interchange and discovering the correct values of EDI Heading fields. As the P0 message will not contain requests for EDI Notifications, an EDI UA will never create an EDIN when it receives an EDIM converted from P0 . F.3.1.2 P(edi) to P0 Conversion When converting a P(edi) content to a P0 content, the following rules apply: 68 Part 8: Message Handling Systems September 1993 (Working) The first body part of the EDIM will be copied to the content. All other body parts of the EDIM will be discarded. The P1 envelope fields shall have the following values: Content Type: Value for "undefined". Originator: Originator ORName. Recipients: Recipients from the EDIM Heading. An NN EDIN with NN Reason Code set to the value "unspecified" is created for each Recipient for whom a Notification Request was specified. The EDIN Originator is set to the Recipient ORName. It is recommended that the supplementary information field of the NN be used to provide additional information on the disposition of the EDIM. Encoded Information Types (EITs): This element may have one of several values depending on the value of the EDI Body Part Type: a) The EIT is set to "undefined" if the EDI Body Part Type is encoded with the EBCDIC character set. b) The EIT is set to "IA5String" if the EDI Body Part Type is encoded using the ISO 646 (ASCII) character set. c) A value is not present for the EIT if EDI Body Part Type does not contain one of the above mentioned values. F.3.2 P2 Recommended Practice As there are a substantial number of users in the NIST OIW community that implemented the CEC TEDIS "P2" approach to EDI use of the X.400 MTS, this section will also include text that describes interworking between a P(edi) UA and a P2 UA. This text is not maintained by the EDI Working Group of the NIST OIW X.400 SIG but is included for the convenience of our user community. Users intending to interwork between P2 and P(edi) User Agents should consult the current version of the EWOS/ETSI document "A/3331 - Functional Profile of an Electronic Data Interchange User Agent." This will ensure that the most up to date technical information is obtained. F.3.2.1 Conversion from IPMS to EDIMS (P2 to P(edi)) It is assumed that there is one and only one body part in the IPM Message, and that this body part contains an EDI interchange. 69 Part 8: Message Handling Systems September 1993 (Working) The IPM becomes the first, and only, body part of the EDIM. The EDIM Heading fields are set as follows: EDIMIdentifier: Originator ORName concatenated with the LocalIPMIdentifier portion of the IPM Identifier. Originator: Originator ORName. Recipients: Recipient ORNames from the IPM Heading. The edi- notification-requests-field is not coded. EDIBodyPartType: The value is a local implementation issue. If the entity performing the conversion can identify the EDI syntax of the EDI Interchange then it can specify an appropriate value. Otherwise, the entity must be assuming a specific encoding and will specify the value for the syntax it is assuming. Other heading fields may be set if the entity performing the conversion is capable of parsing the EDI Interchange and discovering the correct values of the EDIM Heading fields. Since there are not notification requests, the EDI UA will never create an EDIN when it receives a converted EDIM and therefore the action for handling EDINs in the reverse direction does not need to be considered. F.3.2.2 Conversion from EDIMS to IPMS (P(edi) to P2) NOTE - The verification of authority to perform a particular conversion is outside the scope of this annex. It is assumed that such conversion will be done with the full knowledge of the originating and recipient parties. The EDIBodyPart of the EDIM will be copied to the IPM body as an IA5TextBodyPart. All other body parts of the EDIM will be discarded. The IPM Heading fields are set as follows: IPM Identifier: EDIMIdentifier. Originator: Originator ORName. Recipients: Recipients from the EDIM Heading. All recipients become IPM Primary Recipients. An NN EDIN with NN Reason Code set to the value "unspecified" is created for each Recipient for whom a Notification Request was specified. The EDIN Originator is set to the Recipient ORName. The EDIN Originator is set to 70 Part 8: Message Handling Systems September 1993 (Working) the Recipient ORName. IPM Notifications shall not be requested. Subject: Not present or set to a single blank character. If EDINs have been requested the originator will always receive an NN. Since no IPM notifications are requested, the IPM UA will never create an IPM notification when it receives an IPM converted from an EDIM and therefore handling of notifications in the reverse direction does not need to be considered and is not an option for generating EDINs. F.4 ODA Transfer To ease interworking with 1984 implementations when transferring Office Document Architecture (ODA) documents, the following are recommended for 1988 implementations: a) Origination UA implementing 1988 Implementation Agreements. The 1988 will generate the ODA according to CCITT Recommendation T.411 Annex E for the destination UA(s) implementing 1988 Implementation Agreements. If the destination UA supports 1984 Implementation Agreements, the approach as described in section 7.12.8 is recommended. b) Recipient UA implementing 1988 Implementation Agreements. The recipient system will be able to handle the ODA bodypart in P2 (1984) as defined in section 7.12.8 for interworking with 1984 implementation, and will also be able to handle the ODA bodypart as defined in the appropriate base standards. c) MTA downgrading rules. When transferring an P22 with ODA body part in P22 as described in T.411 to an 1984 MTA, the EITs identified by ODA Object Identifiers are mapped to bits 0 and 10 of the built-in EITs. If the UA does not register to support P22 or ODA bodypart, a Non-Delivery-Report will be generated as required. F.5 Use of Externally Defined Body Part F.5.1 General An Externally Defined body part represents an information object whose semantics and abstract syntax are denoted by an Object Identifier which the body part carries. This body part type enables the exchantge of information objects of all kinds, each 71 Part 8: Message Handling Systems September 1993 (Working) unambiguously and uniquely identified. The Externally Defined Body Part definition is reproduced in figure 22. 72 Part 8: Message Handling Systems September 1993 (Working) +---------------------------------------------------------------- ------------+ | | | ExternallyDefinedBodyPart ::= SEQUENCE { | | parameters [0] ExternallyDefinedParameters OPTIONAL,| | data ExternallyDefinedData } | | | | ExternallyDefinedParameters ::= EXTERNAL | | ExternallyDefinedData ::= EXTERNAL | | | | EXTERNAL ::= [UNIVERSAL 8] IMPLICIT SEQUENCE { | | direct-reference OBJECT IDENTIFIER OPTIONAL, | | indirect-reference INTEGER OPTIONAL, | | data-value-descriptor ObjectDescriptor OPTIONAL, | | encoding CHOICE { | | single-ASN1-type [0] ANY, | | octet-aligned [1] IMPLICIT OCTET STRING, | | arbitrary [2] IMPLICIT BIT STRING } } | +---------------------------------------------------------------- ------------+ | Note - In the case of transfer of EXTERNAL in P2 BodyPart, the | | direct-reference component is mandatory and the indirect- reference and | | data-value-descriptor components must be absent. | +---------------------------------------------------------------- ------------+ Figure 22 - Externally Defined Body Part Definition On the basis of the Externally Defined body part type, all body part types are divided into two important classes as follows: a) basic: Said of any body part type except Externally 73 Part 8: Message Handling Systems September 1993 (Working) Defined. All basic body part types are denoted by an integer (an ASN.1 context-specific tag) and are defined in section 7.3 of X.420. b) extended: Said of the Externally Defined body part type restricted to any one value of the Direct-reference component of the Data component of such a body part. Denoted by an Object Identifier. Annex B of Recommendation X.420 defines some (but not necessarily all) extended body part types. F.5.2 Use of Equivalents of Basic Body Part Types For each basic body part types, section B.1 of Recommendation X.420 defines an equivalent extended body part type. In order to facilitate interworking with 1984 systems, use of these extended body part types is not recommended; the basic body part types should be used instead. Editor's Note: The requirements of this clause may change when interworking with 1984 systems is no longer critical. F.5.3 Use of General Text Body Part Type Unless otherwise specified in these agreements (e.g., IA5Text, 6937Text, Teletex) the General Text body part as defined in ISO 10021-7 Annex B.2 is the preferred means of supporting unstructured text body parts. The character set registration referred to in that annex is provided by ECMA. F.5.4 Use of File Transfer Body Part Type The File Transfer body part type is the recommended mechanism for the exchange of complex computer data via intra- and inter- company X.400 messages. It enables automatic type recognition for the file being sent and, possibly, automatic invocation of the appropriate application necessary to process the data. F.5.4.1 Encoding of General Identifier In order to optimize the machine-processing of information encoded in the Parameters and to enable registration, it is recommended that, if present, General Identifiers should be encoded as Object Identifiers. 74 Part 8: Message Handling Systems September 1993 (Working) F.5.4.2 Encoding of Contents Type It is recommended that the Contents Type parameter be encoded as document type. The encoding as constraint-set-and-abstract- syntax has been provided only for backward compatibility with FTAM and its use is discouraged. F.5.4.3 Encoding of Application Specific Information The type of a file can be considered from several perspectives: a) As a specific data structure consisting of a sequence of presentation data values - the position taken by the FTAM standard; b) As the output of a certain application - the position taken by e-mail users requiring the interchange of office documents. The fact that registered OSI document types have to be recognized by FTAM implementations and be described according to the requirements of ISO/IEC 9834-2 "Registration procedures for OSI document types" makes use of the Contents Type parameter inappropriate for expressing point of view (b). Considering that the environment parameter "application- reference" could describe not only the application that generated a document but, more generally, the application-level format of the document, it is recommended that the values given to the "application-reference" parameter component be Object Identifiers associated with such a format. Example: If an Object Identifier has been associated with a certain word-processing file format then this Object Identifier should be used as the value of "application-reference" when a file of that format is carried by a File Transfer body part, while the Content Type parameter should have as its value the Object Identifier associated with the "unstrucutred-binary" document type. F.5.4.4 EITs for the File Transfer Body Part It is recommended to use only the id-eit-file-transfer Object Identifier in association with the File Transfer body part. 75 Part 8: Message Handling Systems September 1993 (Working) The use of EITs describing other parameters of the File Transfer body part such as contents types, application references, etc. would force all potential recipients to register a possibly large number of EITs in order to avoid non-delivery of messages. F.5.5 Use of Other Extended Body Part Types The following are guidelines regarding the use of Externally Defined body part types not defined in the X.400 or other standards: a) Use of Parameters component: In simple cases, to ease the integration of applications to X.400 systems, the Parameters component need not be used. b) Use of Data component: For each different format of data, different Object Identifiers for the Data component are recommended. If an application chooses to use ASN.1 to format the data to achieve a single representation across platforms, the single-ASN1-type encoding choice should be used. Otherwise: 1) The octet- (i.e., byte) aligned choice is used if the data format is octet-aligned; or, 2) The arbitrary choice is used if the data is bit- aligned. c) Assignment of Object Identifiers: Object Identifiers need to be assigned for the EXTERNALs, and these identifiers for the Parameters and Data components should be different. The Object Identifier for an EXTERNAL also indicates the syntax of the data encoding, i.e., whether single-ASN1-type or octet-aligned or bit-aligned is being used. NOTE - Use of proprietary Externally Defined body part types is recommended only if the extended body part types already defined in the standards do not provide the apporpriate functionality. In order to communicate with 1984 systems, the use of the Bilaterally Defined body part is recommended. 76 Part 8: Message Handling Systems September 1993 (Working) F.5.6 Obtaining Object Identifiers There are many ways to obtain object identifiers. One such way is described as follows: a) The application provider obtains a unique Numeric Name form for their organization from ANSI, as described in ANSI ISSB 840 and ISSB 843, and appends this number form to {iso (1) member-body (2) US (840)} to form an object identifier denoting their organization. b) The application provider (organization) allocates a series of numbers to identify the application data format; these numbers are appended to the object identifier constructed in step (i) to form an object identifier that is globally unique. It is recommended that the application provider (organization) use a hierarchical structure for identifying their data types to ease the administration of the identifiers. For example, company PCSoftware Inc. obtains the organization number "999" from ANSI. The PCSoftware SpreadSheet file for MS- DOS might be assigned the following object identifier. NOTE - ASN.1 notation is used. The numbers in parentheses form the identifier, the associated words describe the number. { iso (1) member-body (2) US (840) PCSoftware Inc. (999) MS- DOS-Application (1) SpreadSheet (3) Data (1) } F.6 Privacy Enhanced Mail Body Part This clause describes a mechanism to convey an Internet Privacy Enhanced Mail (PEM) message across an X.400 MHS. PEM is described in Internet RFCs 1421, 1422, and 1423 and their successors. The general Internet mail message format is described in RFC 822. Mapping of RFC 822 messages to and from X.400 Inter Personal Messages is described in RFC 987 for 1984 X.400 and in RFC 1148 for 1988 X.400. The PEM message is conveyed as a P2(2) body part. All of the RFC 822 header information is conveyed in the P1 envelope and P2 header per RFC 987 and RFC 1148. The PEM message (encapsulated security header and, possibly encrypted, message text as described in RFC 1113) is conveyed in a single body part. On the X.400 side, this body part may be manipulated like any other body part; e.g., it may be included in a multi-part body. 77 Part 8: Message Handling Systems September 1993 (Working) For 1988 (P22), the PEM body part is externally defined and does not require parameters. This definition is provided in figure 23. +---------------------------------------------------------------- ------------+ | | | privacy-enhanced-mail EXTENDED-BODY-PART-TYPE | | DATA OCTET STRING | | ::= id-privacy-enhanced-mail | | | | -- The object identifier is defined in annex B. | | | +---------------------------------------------------------------- ------------+ Figure 23 - Definition of the Privacy Enhanced Mail Body Part Type For interworking with 1984 (P2) systems, a USA body part (integer) will be allocated by NIST as described in figure 10. F.7 Selection of OR Name Attributes To support the transition to addresses with Teletex components, it is recommended that a printable string alternative address be established for each address containing Teletex strings. F.8 Use of the Teletex Body Part The Teletex body part should be used purely for structured teletex documents, as described in F.200 and T.60, obeying page rules, etc. It should not be used to transfer T.61 characters, in a general sense, across the MTS. If only IA5 characters are being used, the IA5Text body part should be used, especially when interworking with 1984 UAs is relevant. Otherwise, the GeneralText body part should be used to transfer unstructured character data. 78 Part 8: Message Handling Systems September 1993 (Working) F.9 Provision of Security Class S0A Using Asymmetric Algorithms This clause describes one method of providing the security services of class S0A when using asymmetric (public key) cryptographic algorithms. It is recommended that this method be used unless the security requirements or policy specifies otherwise. Asymmetric cryptographic algorithms such as RSA are used to provide digital signatures in support of the content integrity and (end-to-end) message origin authentication services, as well as proof of delivery. Since asymmetric algorithms are used, the non repudiation of origin and non repudiation of delivery services of security class S2 are also provided. Content confidentiality is provided using a combination of symmetric and asymmetric encryption. The following paragraphs discuss the protocol elements used to provide these services, as well as certificate management and other issues. F.9.1 Protocol Elements The following protocol elements are provided by the originating UA in the submission envelope in support of the S0A security services. Content: If the content confidentiality services is required, the message content is encrypted under the content confidentiality key. Content Integrity Check: This per-recipient security element is a signature over the message content, and provides the content integrity, message origin authentication, and non repudiation of origin services if content confidentiality is not required. (If the message is encrypted, the content integrity check is included in the message token.) NOTE - The message origin authentication check provides a single signature, rather than a signature per recipient, thus reducing total message size in the case where multiple recipients are present. However, support for this protocol element is optional for security class S0. In addition, it is computed over the message content as sent (i.e., the encrypted content if content confidentiality is used). If the content is encrypted, this protocol element does not truly provide non repudiation of the unencrypted content. In this case, smaller message size was traded off for the additional service of non repudiation. Proof Of Delivery Request: This per-recipient security element is used to request the recipient to generate a proof of delivery, 79 Part 8: Message Handling Systems September 1993 (Working) in the case where content confidentiality is not used. (Where content confidentiality is used, the proof of delivery request is included in the message token, as shown below.) Originator Certificate: This security element is a set of one or more certificates which the recipient may use to obtain the oroginator's public key. For example, it might contain the chain of certificates from the originator, through the certification hierarchy to a top-level certification authority. Message Token: The asymmetric message token conveys security information from an originator to a single recipient. It is a signed structure, some of whose fields may be encrypted. The message token is used only when content confidentiality is desired, and supports the content integrity, message origin authentication, content confidentiality, and non repudiation of origin services. The following fields are required, and all other fields are optional: - Signature Algorithm Identifier: The algorithm identifier of the asymmetric algorithm used to sign the token. - Recipient Name: The OR Address and/or Directory Name of the recipient with whom the token is associated. Since the encrypted portion of the token is encrypted under the recipient's public key, it is recommended that the directory name be included, since the recipient's certificate contains his/her directory name rather than OR Address. - Time: The time of day when the token was generated. - Signed Data: The following fields are signed but not encrypted: a) Content Confidentiality Algorithm Identifier: The algorithm to be used to encrypt the message content. b) Proof of Delivery Request: This element is used to request the recipient to compute a proof of delivery over the received message. - Encrypted Data: These fields are encrypted under the recipient's public key: c) Content Confidentiality Key: The symmetric key used to encrypt the message content. d) Content Integrity Check: A signature on the unencrypted message content. If content confidentiality is required, this element provides the content integrity, message origin 80 Part 8: Message Handling Systems September 1993 (Working) authentication, and non repudiation of origin services. This signature is encrypted in order to protect against the "low entropy" attack described in Internet RFC 1113. (In RFC 1113, the signature is encrypted under the content confidentiality key.) NOTE - The encrypted portion of the token will then comprise two RSA encryption blocks. The following element of service is generated by the recipient, if requested by the originator. Proof Of Delivery: This security element provides proof and non repudiation of delivery. It is a digital signature computed over the received (possibly encrypted) message content and various delivery envelope fields, as defined in the base standard. F.9.2 Algorithm Selection This clause makes no recommendation as to hash algorithms, asymmetric encryption algorithms, or symmetric encryption algorithms. The implementor must select appropriate algorithms, based on factors such as performance, cost, and licensing and export restrictions. A fairly complete list of algorithms can be found in clause 7 (Security Algorithms) of Part 12 of these Agreements. In some cases, the implementor must also specify certain algorithm-dependent information. For example, when using the symmetric algorithm DES-CBC, the implementor must specify the padding mechanism used, since this algorithm operates on 8-byte input blocks. Internet RFC 1115 defines such padding rules for DES and RSA in various modes, and these mechanisms are recommended unless security requirements dictate otherwise. PKCS #1 (see Bibliography, Annex F) discusses such matters in more detail. F.9.3 Certificate Management Management of public key certificates is beyond the scope of this recommended practice. X.509 provides a generic authentication framework which uses the Directory to store certificates. In the absence of a ubiquitous Directory, local means may be used to obtain certificates. For example, the recipient of a message might choose to cache those certificates received in the OriginatorCertificate protocol element of the delivery envelope. Each community of interest will define its own policy regarding certificate management and the associated trust model. An 81 Part 8: Message Handling Systems September 1993 (Working) example of a centralized trust model can be found in Internet RFC 1114, while the most complete example of a decentralized trust model can be found in the paper on Digital's Distributed System Security Architecture cited in the Bibliography (Annex F). F.9.4 Other Issues In the case of the P2 content type, addressing information may be protected by replicating the P1/P3 recipient names in the P2 heading fields (To:, CC:, and BCC:). The X.400 security services discussed above are applied to the entire P2 IPM, including the heading and all body parts. Additional protection of heading and envelope fields may be provided using double enveloping. When using X.400 (1988) distribution lists (DLs), one might choose to distribute the private key associated with the DL to all members of the DL. This allows an originator to create a single message token in which the content confidentiality key is encrypted under the DL's public key. (This requires support of the DL expansion history protocol element on delivery, so that the recipient may select the proper private key for decryption. Alternatively, the originating UA may expand the DL locally and generate a message token for each member (recursively). There is no architected support for this mechanism in the base standard, nor is there architected support for performance of this function by an MTA when expanding a DL. 82 Part 8: Message Handling Systems September 1993 (Working) Annex G (informative) Bibliography G.1 ANSI Procedures for Registering Organization Names in the United States of America, ISSB 843, December 5, 1989. Procedures for Registering Names in the United States of America, ISSB 840, December 5, 1989. The U. S. Register is included. G.2 Internet Message Encipherment and Authentication Procedures, RFC 1421. Certificate-based Key Management, RFC 1422. Algorithms, Modes, and Identifiers, RFC 1423. G.3 Other References RSA Data Security, Inc., "PKCS #1: RSA Encryption Standard," June 1991. Gasser, M., A. Goldstein, C. Kaufman and B. Lampson, "The Digital Distributed System Security Architecture," Proceedings of the 12th National Computer Security Conference, 1989. 83 Part 8: Message Handling Systems September 1993 (Working) Annex H (informative) Defense Message Handling Profiles H.1 Introduction Several additional requirements for Message Handling Systems (MHS) are currently being investigated by the U.S. DoD Data Communications Protocol Standards (DCPS) Technical Management Panel (DTMP). This annex describes the DoD Standardized Profile(s) (DSP) that are required for Defense Message System (DMS) use. Two multipart DoD profiles are currently defined, namely: - DSP AMH1n(D) - Information Technology - Defense Standardized Profiles AMH1n(D) - Message Handling Systems - Common DoD Messaging - DSP AMH2n(D) - Information Technology - Defense Standardized Profiles AMH1n(D) - Message Handling Systems - Military Messaging These profiles will be published as part of the MIL-STD-2045 series. The AMH1n(D) profile consists of a DoD delta to the AMH1n ISP. AMH2n(D) is a standalone profile of a new military messaging content type (P772) based on the IPM content type. These extensions support military-unique functionality required by the DMS. For further information on these profiles, contact: DTMP WG/2 Chairman c/o Defense Information Systems Agency (DISA) Joint Interoperability Engineering Office (JIEO) Code TBBD Fort Monmouth, NJ 07703-5000 Phone: 908-532-7726 84 Part 8: Message Handling Systems September 1993 (Working) Annex I (informative) Management Domains The sections above describe agreements among implementors of particular X.400 components (e.g. MTAs, UAs, MSs). There are some agreements that don't apply to a single X.400 component, but instead apply to an entire domain of X.400 components. This section details any requirements for X.400 domains, independent of those for individual X.400 components. A single X.400 component cannot be conformance tested for these domain requirements, but for a domain to claim to be "operationally OIW compliant", it must abide by the rules stated below. I.1 Management Domain Names This section contains requirements on matters being considered by the U. S. CCITT Study Group D for national decisions. Such decisions are likely to supersede the relevant portions of this clause. The Implementation Agreements for 1984-based MHS implementations requires that all Management Domain Names (both Private and Administration) shall be unique within the U. S. This is also a requirement for 1988-based MHS implementations. A "Construction Syntax" is defined, which uses a registered OSI Organization Name from the ANSI US Register of Organization Names as a "root" in the construction of MHS Management Domain Names e.g., ADMD and PRMD). The constructed combinations based on this "root" will be guaranteed to be unique, and thus be safely used as MHS MD names in the United States. Other countries may wish to adopt these same rules. MHS MD (PRMD and ADMD) names shall be constructed according to the Extended BNF grammar shown in figure 12. 85 Part 8: Message Handling Systems September 1993 (Working) +---------------------------------------------------------------- ------+ | ::= | | | | ::= | | | | ::= | | | | | | | | | | | | ::= | | "+" | +---------------------------------------------------------------- ------+ Figure 12 - Management Domain Name Construction Subject to all of the following rules: Rule 1. The entire must not exceed 16 bytes (including any constructor operators that may be included, and shall be composed entirely of PrintableString characters. Rule 2. The shall be drawn from the alphanumeric names registered in the US Register. It shall contain at least one non-numeric character, and not contain the constructor operator "+" (plus sign). Rule 3. Each obtained from the US Registry will be accompanied by a NumberForm (numeric value) which shall be bound as the to the . Rule 4. In a , the shall be certified to be unique under the (sub)authority, by the registration authority. Rule 5. A shall be obtained 86 Part 8: Message Handling Systems September 1993 (Working) from the US Register and bound to the . Rule 6. A Private Management Domain's PrivateDomainIdentifier shall be the same as its PrivateDomainName. NOTES 1 The PRMD names resulting from the syntax (those having a "+" in them) are atomic values from the point of view of the MTA -- in particular, it is not permissible for the MTA to route on components of the PRMD name. 2 The construction rules are such that if ABC is a Registered National Organization Name, then the owner of that name controls the MHS Domain Name space including "ABC" and "ABC+", but not "ABC". 3 A "+" is legal in an ANSI provided name. 4 If a Registered Organization Name already contains the construction operator ("+" sign), then in order to use the name as an , its owner must also register the "root" which precedes the first "+" sign, with the US Register of Organization Names. (e.g., company B+Z+P would need to register "B" to be able to use the "constructed" name of B+Z+P.) 5 For the special case of the construction operator ("+" sign) being the first character of a Nationally Registered Name, no special action is required beyond its normal registration with the US Registry of Organization Names. 6 If the sub-authority determined by so wishes, the can be constructed using rules similar to the above, resulting in a hierarchical construction separated by "+"s. In particular, the sub- authority must maintain its own registry and might (for example) define the using the syntax 87 Part 8: Message Handling Systems September 1993 (Working) +---------------------------------------------------------------- -------+ | ::= | | | "+" | +---------------------------------------------------------------- -------+ Figure 13 - Name Construction by Subauthorities where the is drawn from the sub-authority's registry (and does not contain a "+"). Thus the sub-authority can delegate the use of the prefix +---------------------------------------------------------------- -------+ | + | +---------------------------------------------------------------- -------+ Figure 14 - Prefix to someone else. I.2 Use of ADMD Names This subsection was developed by an X.400 SIG working group in April, 1990. It contains extremely controversial positions that invoke national, commercial, and quality of service issues. The OIW may not be the correct forum to make these national decisions. Until these decisions can be reached or a national forum established, this section remains as a placeholder in the OIW X.400 SIG Working Text document only. NOTE - Version 2 of the CCITT X.400 Implementors Guide, dated 16 March 1990, allows for a single zero ("0") character as the ADMD name for the case of a PRMD that is not reachable from any ADMD. The following discussion does not apply to such PRMDs. A PRMD may be directly connected to more than one ADMD. Since a PRMD may not alter the originators ORAddress, the Country/ADMD name pair provided in the Originator ORAddress may not match those of the first ADMD to receive the message from the PRMD. The first ADMD is required to accept such messages and may not alter the originator's ORAddress. Any message originated by a PRMD must have an Originator's ORAddress that either uses the single space ADMD name or uses a 88 Part 8: Message Handling Systems September 1993 (Working) Country/ADMD name pair for an ADMD to which the PRMD is connected. (In both cases the Country name is required.) The X.400 Recommendations have defined a mechanism that enables PRMDs connected to multiple ADMDs to enter a single space as the ADMD name. To support this, these agreements recognize two classes of ADMDs. ADMDs in the first class, "space-supporting" ADMDs, must be able to route on PRMD name, independently from the ADMD name. Furthermore, the space-supporting ADMDs must arrange their routing configuration such that all PRMDs are reachable from all ADMDs. PRMDs using the single space ADMD name must be connected to at least one space-supporting ADMD. ADMDs in the other class, "non-space-supporting" ADMDs, must, at a minimum, route messages for which the ADMD name is a single space to a space-supporting ADMD (in the indicated country). It is hoped that in the long term, all ADMDs will be able to route on the PRMD name when the ADMD name is a single space. I.3 Uniqueness of MTS Identifiers Within a Management Domain When generating an IA5String in an MTS Identifier, each MTA in a domain must ensure that the string is unique within the domain. This shall be done by providing an MTA designator with a length of 12 octets which is unique within the domain, to be concatenated to a per message string with maximum length of 20 octets. Two pieces of information, the MTA name and MTA designator, need to be registered within an MD to guarantee uniqueness. This registration facility need not be automated. If the MTA name is less than or equal to 12 characters, it is recommended that it also be used as the MTA designator. 89