Stable Implementation Agreements for Open Systems Interconnection Protocols: Part 8 - Message Handling Systems Output from the June 1994 NIST Workshop for Implementors of OSI SIG Chair: Chris Bonatti, Booz Allen & Hamilton SIG Editor: Chris Bonatti, Booz Allen & Hamilton Part 8: Message Handling Systems June 1994 (Stable) 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 June 1994 (Stable) 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 AMH2 . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3 AMH3 . . . . . . . . . . . . . . . . . . . . . . . . 11 5 Conformance . . . . . . . . . . . . . . . . . . . . . . . 11 6 Common Messaging . . . . . . . . . . . . . . . . . . . . 15 6.1 Introduction . . . . . . . . . . . . . . . . . . . . 15 6.2 Elements of Service . . . . . . . . . . . . . . . . 15 6.3 MTS Transfer Protocol (P1) . . . . . . . . . . . . . 15 6.4 MTS Access Protocol (P3) . . . . . . . . . . . . . . 16 6.5 MS Transfer Protocol (P7) . . . . . . . . . . . . . 16 6.6 Pragmatic Constraints . . . . . . . . . . . . . . . 17 6.6.1 MTS - APDU Size . . . . . . . . . . . . . . 17 6.6.2 Number of Recipient Names . . . . . . . . . 18 6.7 1988/84 Interworking Considerations . . . . . . . . 18 7 MHS Management . . . . . . . . . . . . . . . . . . . . . 20 8 IPM Service . . . . . . . . . . . . . . . . . . . . . . . 21 8.1 Introduction . . . . . . . . . . . . . . . . . . . . 21 9 EDI Messaging Service . . . . . . . . . . . . . . . . . . 21 Annex A (normative) Naming, Addressing and Routing . . . . . . . . . . . . . . . 22 A.1 ORAddress Attribute List Equivalence Rules . . . . . 22 A.2 MHS Use of Directory . . . . . . . . . . . . . . . . 23 A.2.1 Introduction . . . . . . . . . . . . . . . 23 A.2.2 Functional Configuration . . . . . . . . . 23 A.2.3 Functionality . . . . . . . . . . . . . . . 23 A.2.4 Naming and Attributes . . . . . . . . . . . 24 iii Part 8: Message Handling Systems June 1994 (Stable) A.2.5 Directory Services . . . . . . . . . . . . 25 A.2.6 OIW Application Specific Attributes and Attribute Sets . . . . . . . . . . . . . . 26 A.2.7 OIW Application Specific Object Classes . . 28 A.2.8 Structure Rules . . . . . . . . . . . . . . 28 A.2.8.1 MHS Distribution List . . . . . . . . . . . 28 A.2.8.2 MHS User . . . . . . . . . . . . . . . . . 28 A.2.9 Use of Capabilities Information . . . . . . 28 Annex B (normative) IPM Body Part Support . . . . . . . . . . . . . . . . . . . . 29 Annex C (normative) Object Identifiers . . . . . . . . . . . . . . . . . . . . . 32 C.1 X.400 SIG Object Identifiers . . . . . . . . . . . . 32 C.2 Content Types . . . . . . . . . . . . . . . . . . . 33 C.3 Body Part Types . . . . . . . . . . . . . . . . . . 33 C.4 Security Classes . . . . . . . . . . . . . . . . . . 34 Annex D (informative) Interpretation of Elements of Service . . . . . . . . . . . . 35 Annex E (informative) Recommended Practices . . . . . . . . . . . . . . . . . . . . 36 E.1 Printable String . . . . . . . . . . . . . . . . . . 36 E.2 Rendition of IA5Text . . . . . . . . . . . . . . . . 37 E.3 EDI Use of MHS . . . . . . . . . . . . . . . . . . . 38 E.3.1 P0 Recommended Practice . . . . . . . . . . 38 E.3.1.1 P0 to P(edi) Conversion . . . . . . . . . . 39 E.3.1.2 P(edi) to P0 Conversion . . . . . . . . . . 39 E.3.2 P2 Recommended Practice . . . . . . . . . . 40 E.3.2.1 Conversion from IPMS to EDIMS (P2 to P(edi)) . . . . . . . . . . . . . . . . . . 40 E.3.2.2 Conversion from EDIMS to IPMS (P(edi) to P2) . . . . . . . . . . . . . . . . . . . . 41 E.4 ODA Transfer . . . . . . . . . . . . . . . . . . . . 42 E.5 Use of Externally Defined Body Part . . . . . . . . 42 E.5.1 General . . . . . . . . . . . . . . . . . . 42 E.5.2 Use of Equivalents of Basic Body Part Types 45 E.5.3 Use of General Text Body Part Type . . . . 45 E.5.4 Use of File Transfer Body Part Type . . . . 45 E.5.4.1 Encoding of General Identifier . . . . . . 45 E.5.4.2 Encoding of Contents Type . . . . . . . . . 46 E.5.4.3 Encoding of Application Specific Information . . . . . . . . . . . . . . . . 46 E.5.4.4 EITs for the File Transfer Body Part . . . 46 iv Part 8: Message Handling Systems June 1994 (Stable) E.5.5 Use of Other Extended Body Part Types . . . 47 E.5.6 Obtaining Object Identifiers . . . . . . . 48 E.6 Privacy Enhanced Mail Body Part . . . . . . . . . . 48 E.7 Selection of OR Name Attributes . . . . . . . . . . 49 E.7.1 Teletex Name Attributes . . . . . . . . . . 49 E.8 Use of the Teletex Body Part . . . . . . . . . . . . 49 E.9 Provision of Security Class S0A Using Asymmetric Algorithms . . . . . . . . . . . . . . . . . . . . . 50 E.9.1 Protocol Elements . . . . . . . . . . . . . 50 E.9.2 Algorithm Selection . . . . . . . . . . . . 52 E.9.3 Certificate Management . . . . . . . . . . 52 E.9.4 Other Issues . . . . . . . . . . . . . . . 53 Annex F (informative) Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 54 F.1 ANSI . . . . . . . . . . . . . . . . . . . . . . . . 54 F.2 Internet . . . . . . . . . . . . . . . . . . . . . . 54 F.3 Other References . . . . . . . . . . . . . . . . . . 54 Annex G (informative) Defense Message Handling Profiles . . . . . . . . . . . . . . 55 G.1 Introduction . . . . . . . . . . . . . . . . . . . . 55 Annex H (informative) Management Domains . . . . . . . . . . . . . . . . . . . . . 56 H.1 Management Domain Names . . . . . . . . . . . . . . 56 H.2 Use of ADMD Names . . . . . . . . . . . . . . . . . 59 H.3 Uniqueness of MTS Identifiers Within a Management Domain . . . . . . . . . . . . . . . . . . . . . . . 60 v Part 8: Message Handling Systems June 1994 (Stable) List of Figures Figure 1 - Combinations of AMH1n Profiles . . . . . . . . . . 6 Figure 2 - Combinations of AMH2n Profiles . . . . . . . . . . 9 Figure 4 - 1988 MHS Physical Configurations . . . . . . . . . 12 Figure 5 - 1988 to 1984 Mapping . . . . . . . . . . . . . . . 19 Figure 6 - 1984 to 1988 Mapping . . . . . . . . . . . . . . . 20 Figure A1 - Example of Unregistered Object Class Definition . 25 Figure B1 - Privately-Defined Body Parts . . . . . . . . . . 31 Figure C1 - Definition of the mhsig Object Identifier . . . . 32 Figure C2 - Defintion of the X.400 SIG Object Identifier Categories. . . . . . . . . . . . . . . . . . . . . . . 33 Figure C3 - Definition of the External Body Part Object Identifiers . . . . . . . . . . . . . . . . . . . . . . 33 Figure E1 - ASCII to PrintableString Algorithm . . . . . . . 37 Figure E2 - PrintableString to ASCII Algorithm . . . . . . . 37 Figure E3 - Externally Defined Body Part Definition . . . . . 44 Figure E4 - Definition of the Privacy Enhanced Mail Body Part Type . . . . . . . . . . . . . . . . . . . . . . . 49 Figure H1 - Management Domain Name Construction . . . . . . . 57 Figure H2 - Name Construction by Subauthorities . . . . . . . 59 Figure H3 - Prefix . . . . . . . . . . . . . . . . . . . . . 59 vi Part 8: Message Handling Systems June 1994 (Stable) List of Tables Table 1 - MHS Configurations . . . . . . . . . . . . . . . . 13 Table 2 - Deltas to Clause A.1.2 of ISP 10611-3 . . . . . . . 16 Table 3 - Deltas to Table A.1.2.4 of ISP 10611-4 . . . . . . 16 Table 4 - Deltas to Table A.1.2.4 of ISP 10611-5 . . . . . . 16 Table 5 - Deltas to Table A.1.3.1 of ISP 10611-5 . . . . . . 17 Table 6 - Deltas to Table A.1.11 of ISP 10611-5 . . . . . . . 17 Table A1 - Directory Service Support Requirements . . . . . . 26 Table E1 - Printable String to ASCII Mapping . . . . . . . . 36 Table E2 - Interpretation of Format Effector Combinations . . 38 vii Part 8 Message Handling Systems 0 Introduction This is an Implementation Agreement developed by the Implementor's Workshop sponsored by the 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 June 1994 (Stable) 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: 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 June 1994 (Stable) 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. OIW SIA Chapter 29 - Working Draft ISP 10611 Information Processing Systems - International Standardized Profiles AMH1n - 3 Part 8: Message Handling Systems June 1994 (Stable) Message Handling Systems - Common Messaging. OIW SIA Chapter 30 - Working Draft ISP 12062 Information Processing Systems - International Standardized Profiles AMH2n - Message Handling Systems - Interpersonal 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. The AMH set of profiles, so far consists of three multipart profiles. AMH1 covers Common Messaging - i.e., those aspects of the MHS 4 Part 8: Message Handling Systems June 1994 (Stable) 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 June 1994 (Stable) +-------+ 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 June 1994 (Stable) 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 June 1994 (Stable) 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 Interpersonal 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 June 1994 (Stable) +-------+ 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 AMH2n set of profiles is specified as a multipart ISP consisting of the following parts: Part 1: IPM MHS service support. A common text part which provides functional description and specification of IPM-specific MHS service support and associated functionality as covered by the AMH2n set of profiles. It identifies what additional service support and functionality can be supported by each type of MHS component 9 Part 8: Message Handling Systems June 1994 (Stable) in an IPM environment (i.e., also covering the services supported by an IPMS UA, plus any additional MTA and MS aspects such as IPM body part conversion), divided into basic requirements and zero or more optional functional groups (see AMH1n). 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: IPM Content. This part covers IPMS UA functionality. It specifies support of the IPM content protocol in terms of basic requirements and optional functional groups and defines conformance requirements for an IPMS UA with respect to support of IPM content and associated functionality (by reference to the common IPM specifications in part 1). Part 3: AMH22 - IPM requirements for Message Transfer (P1). This part covers message transfer between MTAs using the P1 Message Transfer Protocol to support an IPM environment. It specifies any additional P1 support to that specified in AMH1n and defines conformance requirements for an MTA which supports IPM transfer with respect to support of P1 and associated functionality (requiring conformance to AMH11 and by reference to the common IPM specifications in part 1). Part 4: AMH23 - IPM requirements for MTS Access (P3). This part covers access to an MTS using the P3 MTS Access Protocol to support an IPM environment. It specifies any additional P3 support to that specified in AMH1n and defines conformance requirements for an MTA which supports remote access for IPM use, and for a remote MTS-user in an IPM context (i.e., IPMS UA or MS), with respect to support of P3 and associated functionality (requiring conformance to AMH12 and by reference to the common IPM specifications in part 1). 10 Part 8: Message Handling Systems June 1994 (Stable) Part 5: AMH24 - IPM requirements for Enhanced MS Access (P7). This part covers access to an MS using the P7 MS Access Protocol to support an IPM environment. It specifies any additional P7 support to that specified in AMH1n and defines conformance requirements for an MS which supports remote access for IPM use, and for a remote MS-user in an IPM context (i.e., IPMS UA), with respect to support of P7 and associated functionality (requiring conformance to AMH13 and by reference to the common IPM specifications in part 1). 4.3 AMH3 Editor's Note: [See the OIW Working Implementation Agreements, Chapter 8, Clause 4.3.] 5 Conformance MHS implementations may be configured as any single or multiple occurrence or combination of MTA, MS and UA, as illustrated in Figure 4. 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-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 11 Part 8: Message Handling Systems June 1994 (Stable) +--------+ +-------+ MHS-88-UA-P7 MHS-88-UA-P7 Figure 4 - 1988 MHS Physical Configurations Figure 4 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 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 12 Part 8: Message Handling Systems June 1994 (Stable) 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. "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 1 - 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) 13 Part 8: Message Handling Systems June 1994 (Stable) Table 1 - 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- P3 + AMH12 + Sec. 6 Remote-UA-P3 possible content types IPMS AMH21 + AMH24 + Sec. 8 EDI AMH31 + AMH34 + Sec. 9 other detail in PICS in AMH13 (A.3) MHS-88- P7 + AMH13 + Sec. 6 Remote-UA-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- P3 + AMH12 + Sec. 6 Remote-UA-MS possible content types IPMS AMH21 + AMH23 + Sec. 8 EDI AMH31 + AMH33 + Sec. 8 other details in PICS in AMH12 (A.3) 14 Part 8: Message Handling Systems June 1994 (Stable) 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 1984 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. Note that when a table entry is blank then the classification shall be that of the appropriate referenced ISP. 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. 15 Part 8: Message Handling Systems June 1994 (Stable) Table 2 - 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- 3 m protocol-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 3 - 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 4 - 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) 16 Part 8: Message Handling Systems June 1994 (Stable) Table 5 - 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 6 - 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. 17 Part 8: Message Handling Systems June 1994 (Stable) 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 OIW Stable 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 5 and 6 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. 18 Part 8: Message Handling Systems June 1994 (Stable) +---------------------------------------------------------------+ | 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 5 - 1988 to 1984 Mapping 19 Part 8: Message Handling Systems June 1994 (Stable) +---------------------------------------------------------------+ | 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 6 - 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 Editor's Note: [See OIW Working Implementation Agreements, Chapter 8, Clause 7.] 20 Part 8: Message Handling Systems June 1994 (Stable) 8 IPM Service 8.1 Introduction This clause specifies IPM conformance requirements. Conformance to AMH2 is required, as well as support of the 1984 Interworking functional group. 9 EDI Messaging Service Editor's Note: [See OIW Working Implementation Agreements, Chapter 8, Clause 9] 21 Part 8: Message Handling Systems June 1994 (Stable) Annex A (normative) Naming, Addressing and Routing A.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. 22 Part 8: Message Handling Systems June 1994 (Stable) A.2 MHS Use of Directory Editor's Note - It has been suggested that much of this material could be moved to an informative annex. A.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. A.2.2 Functional Configuration A.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. 23 Part 8: Message Handling Systems June 1994 (Stable) 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. A.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. 24 Part 8: Message Handling Systems June 1994 (Stable) 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 the following figure. +---------------------------------------------------------+ | | | real-user-entry ::= OBJECT CLASS | | SUBCLASS OF organizationalPerson, | | mhs-user | | | +---------------------------------------------------------+ Figure A1 - 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. A.2.5 Directory Services These Implementation Agreements require the Directory services as defined in the following table. Indicated are the Directory services required to support the needs of the MHS UA/MTA and MHS Administrator. 25 Part 8: Message Handling Systems June 1994 (Stable) Table A1 - 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 | +-----------------------------+--------+-------+ A.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. 26 Part 8: Message Handling Systems June 1994 (Stable) 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), 27 Part 8: Message Handling Systems June 1994 (Stable) videotex-delivery (8), telephone-delivery (9) } NOTE - Mhs-delivery-method includes selected delivery methods from preferredDeliveryMethod in CCITT X.520|ISO/IEC 9594-6. A.2.7 OIW Application Specific Object Classes There are no application specific object classes defined by these Implementation Agreements. A.2.8 Structure Rules This clause defines the naming and structure rules for the MHS object classes which are subclasses of top. A.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. A.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. A.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. 28 Part 8: Message Handling Systems June 1994 (Stable) Annex B (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. 29 Part 8: Message Handling Systems June 1994 (Stable) +-------------------------------------------------------------+ | 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. | +-------------------------------------------------------------+ 30 Part 8: Message Handling Systems June 1994 (Stable) Figure B1 - Privately-Defined Body Parts 31 Part 8: Message Handling Systems June 1994 (Stable) Annex C (normative) Object Identifiers C.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 the following figure. +---------------------------------------------------------------- ------------+ | | | id-mhsig OBJECT IDENTIFIER ::= | | { iso (1) identified-organization (3) oiw (14) mhsig (6) } | | | +---------------------------------------------------------------- ------------+ Figure C1 - Definition of the mhsig Object Identifier The X.400 SIG has defined several categories of object identifiers. Their definition is provided in the following figure. 32 Part 8: Message Handling Systems June 1994 (Stable) +---------------------------------------------------------------- ------------+ | | | 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 C2 - Defintion of the X.400 SIG Object Identifier Categories. C.2 Content Types There are presently no object identifiers for content types allocated by the X.400 SIG. C.3 Body Part Types The object identifiers for the external body part types allocated by the X.400 SIG are defined in the following figure. +---------------------------------------------------------------- ------------+ | | | id-privacy-enhanced-mail OBJECT IDENTIFIER ::= | | { id-mhsig-body-part-types pem (0) } | | | +---------------------------------------------------------------- ------------+ Figure C3 - Definition of the External Body Part Object Identifiers 33 Part 8: Message Handling Systems June 1994 (Stable) C.4 Security Classes Editor's Note - Identical to the ISP. 34 Part 8: Message Handling Systems June 1994 (Stable) Annex D (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 B1), the originator of the forwarding message shall set the original encoded information types in the P1 envelope to Undefined for that body part. 35 Part 8: Message Handling Systems June 1994 (Stable) Annex E (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. E.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 E1 are covered by the category "other." Table E1 - 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) | +--------------------+----------------------------+ 36 Part 8: Message Handling Systems June 1994 (Stable) 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 E1 and the algorithm in Figure E1 should be used. +-------------------------------------------------------+ | IF current character is in the encoding set THEN | | encode the character according to Table E1 | | ELSE | | write the current character; | | continue reading; | +-------------------------------------------------------+ Figure E1 - ASCII to PrintableString Algorithm To decode a PrintableString representation to an ASCII representation, Table E1 and the algorithm in Figure E2 should be used. +-------------------------------------------------------+ | IF current character is not "(" THEN | | write character | | ELSE | | { | | look ahead appropriate characters; | | IF composite characters are in Table E1 THEN | | decode per Table E1 | | ELSE | | write current character; | | } | | continue reading; | +-------------------------------------------------------+ Figure E2 - PrintableString to ASCII Algorithm E.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 37 Part 8: Message Handling Systems June 1994 (Stable) 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 the following table. Table E2 - 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. E.3 EDI Use of MHS E.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. 38 Part 8: Message Handling Systems June 1994 (Stable) E.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 . E.3.1.2 P(edi) to P0 Conversion When converting a P(edi) content to a P0 content, the following rules apply: 39 Part 8: Message Handling Systems June 1994 (Stable) 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. E.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. E.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. 40 Part 8: Message Handling Systems June 1994 (Stable) 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. E.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 41 Part 8: Message Handling Systems June 1994 (Stable) 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. E.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. E.5 Use of Externally Defined Body Part E.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 42 Part 8: Message Handling Systems June 1994 (Stable) unambiguously and uniquely identified. The Externally Defined Body Part definition is reproduced in Figure E3. 43 Part 8: Message Handling Systems June 1994 (Stable) +---------------------------------------------------------------- ------------+ | | | 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 E3 - 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 44 Part 8: Message Handling Systems June 1994 (Stable) 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. E.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. E.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. E.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. E.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. 45 Part 8: Message Handling Systems June 1994 (Stable) E.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. E.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. E.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. 46 Part 8: Message Handling Systems June 1994 (Stable) 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. E.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. 47 Part 8: Message Handling Systems June 1994 (Stable) E.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) } E.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. 48 Part 8: Message Handling Systems June 1994 (Stable) For 1988 (P22), the PEM body part is externally defined and does not require parameters. This definition is provided in the following figure. +---------------------------------------------------------------- ------------+ | | | privacy-enhanced-mail EXTENDED-BODY-PART-TYPE | | DATA OCTET STRING | | ::= id-privacy-enhanced-mail | | | | -- The object identifier is defined in annex B. | | | +---------------------------------------------------------------- ------------+ Figure E4 - 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 B1. E.7 Selection of OR Name Attributes E.7.1 Teletex 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. E.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. 49 Part 8: Message Handling Systems June 1994 (Stable) E.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 nonrepudiation of origin and nonrepudiation 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. E.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 nonrepudiation 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 nonrepudiation of the unencrypted content. In this case, smaller message size was traded off for the additional service of nonrepudiation. Proof Of Delivery Request: This per-recipient security element is used to request the recipient to generate a proof of delivery, 50 Part 8: Message Handling Systems June 1994 (Stable) 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 nonrepudiation 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 51 Part 8: Message Handling Systems June 1994 (Stable) authentication, and nonrepudiation 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 nonrepudiation 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. E.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. E.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 52 Part 8: Message Handling Systems June 1994 (Stable) certificate management and the associated trust model. An 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). E.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. 53 Part 8: Message Handling Systems June 1994 (Stable) Annex F (informative) Bibliography F.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. F.2 Internet Message Encipherment and Authentication Procedures, RFC 1421. Certificate-based Key Management, RFC 1422. Algorithms, Modes, and Identifiers, RFC 1423. F.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. 54 Part 8: Message Handling Systems June 1994 (Stable) Annex G (informative) Defense Message Handling Profiles G.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 55 Part 8: Message Handling Systems June 1994 (Stable) Annex H (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. H.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 the following figure. 56 Part 8: Message Handling Systems June 1994 (Stable) +---------------------------------------------------------------- ------+ | ::= | | | | ::= | | | | ::= | | | | | | | | | | | | ::= | | "+" | +---------------------------------------------------------------- ------+ Figure H1 - 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. 57 Part 8: Message Handling Systems June 1994 (Stable) Rule 5. A shall be obtained 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 shown in the following figure. 58 Part 8: Message Handling Systems June 1994 (Stable) +---------------------------------------------------------------- -------+ | ::= | | | "+" | +---------------------------------------------------------------- -------+ Figure H2 - 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 described in the following figure. +---------------------------------------------------------------- -------+ | + | +---------------------------------------------------------------- -------+ Figure H3 - Prefix to someone else. H.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 59 Part 8: Message Handling Systems June 1994 (Stable) 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. H.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. 60