Stable Implementation Agreements for Open Systems Interconnection Protocols: Part 7 - 1984 Message Handling Systems Output from the December 1993 Open Systems Environment Implementors' Workshop (OIW) SIG Chair: Neil Koorland (Microsoft) SIG Editor: Rich Ankney (Fischer International) Part 7: 1984 Message Handling Systems December 1993 (Stable) Foreword This part of the Stable Implementation Agreements was prepared by the Message Handling Systems Special Interest Group (X.400 SIG) of the Open Systems Environment Implementors' Workshop (OIW). Text in this part has been approved by the Plenary of the X.400 SIG. This part replaces the previously existing chapter on this subject. There is no significant technical change from this text as previously given. Future changes and additions to this version of these Implementor Agreements will be published as change pages. Deleted and replaced text will be shown as strikeout. New and replacement text will be shown as shaded. ii Part 7: 1984 Message Handling Systems December 1993 (Stable) Table of Contents Part 7 CCITT 1984 X.400 Based Message Handling System . . . 1 0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Normative references . . . . . . . . . . . . . . . . . . 5 3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Errata . . . . . . . . . . . . . . . . . . . . . . . . . 6 5 PRMD to PRMD . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Introduction . . . . . . . . . . . . . . . . . . . . 6 5.2 Service elements and optional user facilities . . . 8 5.2.1 Classification of support for services . . 8 5.2.1.1 Support (S) . . . . . . . . . . . . . . . . 8 5.2.1.2 Non Support (N) . . . . . . . . . . . . . . 9 5.2.1.3 Not Used (N/U) . . . . . . . . . . . . . . 9 5.2.1.4 Not Applicable (N/A) . . . . . . . . . . . 9 5.2.2 Summary of supported services . . . . . . . 9 5.2.3 MT service elements and optional user facilities . . . . . . . . . . . . . . . . 9 5.2.4 IPM service elements and optional user facilities . . . . . . . . . . . . . . . . 12 5.3 X.400 protocol definitions . . . . . . . . . . . . . 15 5.3.1 Protocol classification . . . . . . . . . . 15 5.3.2 General statements on pragmatic constraints 17 5.3.3 MPDU size . . . . . . . . . . . . . . . . . 18 5.3.4 P1 protocol elements . . . . . . . . . . . 18 5.3.5 ORName protocol elements . . . . . . . . . 27 5.3.6 P2 protocol profile (based on [X.420]) . . 31 5.3.6.1 P2 protocol - Heading . . . . . . . . . . . 31 5.3.6.2 P2 protocol - BodyParts . . . . . . . . . . 36 5.3.6.2.1 BodyPart identifiers . . . . . . . . . . . 36 5.3.6.2.2 Privately defined BodyParts . . . . . . . . 37 5.3.6.3 P2 BodyPart protocol elements . . . . . . . 38 5.4 Reliable Transfer Server (RTS) . . . . . . . . . . . 43 5.4.1 Implementation strategy . . . . . . . . . . 43 5.4.2 RTS option selection . . . . . . . . . . . 44 5.4.3 RTS protocol options and clarifications . . 44 5.4.4 RTS protocol limitations . . . . . . . . . 49 5.5 Use of session services . . . . . . . . . . . . . . 53 iii Part 7: 1984 Message Handling Systems December 1993 (Stable) 5.6 Data transfer syntax . . . . . . . . . . . . . . . . 53 6 PRMD to ADMD and ADMD to ADMD . . . . . . . . . . . . . . 53 6.1 Introduction . . . . . . . . . . . . . . . . . . . . 53 6.2 Additional ADMD functionality . . . . . . . . . . . 55 6.2.1 Relay responsibilities of an ADMD . . . . . 55 6.2.2 P1 protocol classification changes . . . . 55 6.2.3 O/R Names . . . . . . . . . . . . . . . . . 57 6.2.4 P1 ADMD name . . . . . . . . . . . . . . . 57 6.2.5 Interworking with integrated UAs . . . . . 57 6.3 Differences with other profiles . . . . . . . . . . 58 6.3.1 TTC profile . . . . . . . . . . . . . . . . 58 6.3.2 CEPT profile . . . . . . . . . . . . . . . 58 6.4 Connection of PRMDs to multiple ADMDs . . . . . . . 58 6.5 Connection of an ADMD to a routing PRMD . . . . . . 59 6.6 Management domain names . . . . . . . . . . . . . . 60 6.7 Envelope validation errors . . . . . . . . . . . . . 60 6.8 Quality of service . . . . . . . . . . . . . . . . . 61 6.8.1 Domain availability . . . . . . . . . . . . 61 6.8.1.1 ADMD availability . . . . . . . . . . . . . 61 6.8.1.2 PRMD availability . . . . . . . . . . . . . 61 6.8.2 Delivery times . . . . . . . . . . . . . . 61 6.9 Billing information . . . . . . . . . . . . . . . . 62 6.10 Transparency . . . . . . . . . . . . . . . . . . . . 63 6.11 RTS password management . . . . . . . . . . . . . . 63 6.12 For further study . . . . . . . . . . . . . . . . . 64 7 Inter and intra PRMD connections . . . . . . . . . . . . 64 7.1 Introduction . . . . . . . . . . . . . . . . . . . . 64 7.2 The relaying PRMD . . . . . . . . . . . . . . . . . 65 7.2.1 Relay responsibilities of a PRMD . . . . . 65 7.2.2 Interaction with an ADMD . . . . . . . . . 65 7.3 Intra PRMD connections . . . . . . . . . . . . . . . 67 7.3.1 Relay responsibilities of an MTA . . . . . 67 7.3.2 Loop suppression within a PRMD . . . . . . 67 7.3.3 Routing within a PRMD . . . . . . . . . . . 68 7.3.3.1 Class designations . . . . . . . . . . . . 69 7.3.3.2 Specification of MTA classes . . . . . . . 70 7.3.3.3 Consequences of using certain classes of MTAs . . . . . . . . . . . . . . . . . . . 70 7.3.4 Uniqueness of MPDUIdentifiers within a PRMD 71 7.4 Service elements and optional user facilities . . . 72 7.5 X.400 protocol definitions . . . . . . . . . . . . . 72 7.5.1 Protocol classification . . . . . . . . . . 72 7.5.2 P1 protocol elements . . . . . . . . . . . 73 7.5.3 Reliable Transfer Server (RTS) . . . . . . 79 8 Error handling . . . . . . . . . . . . . . . . . . . . . 79 8.1 MPDU encoding . . . . . . . . . . . . . . . . . . . 79 iv Part 7: 1984 Message Handling Systems December 1993 (Stable) 8.2 Contents . . . . . . . . . . . . . . . . . . . . . . 79 8.3 Envelope . . . . . . . . . . . . . . . . . . . . . . 79 8.3.1 Pragmatic constraint violations . . . . . . 80 8.3.2 Protocol violations . . . . . . . . . . . . 80 8.3.3 O/R Names . . . . . . . . . . . . . . . . . 80 8.3.4 TraceInformation . . . . . . . . . . . . . 81 8.3.5 InternalTraceInfo . . . . . . . . . . . . . 81 8.3.6 Unsupported X.400 protocol elements . . . . 82 8.3.6.1 deferredDelivery . . . . . . . . . . . . . 82 8.3.6.2 PerDomainBilateralInfo . . . . . . . . . . 82 8.3.6.3 ExplicitConversion . . . . . . . . . . . . 82 8.3.6.4 alternateRecipientAllowed . . . . . . . . . 82 8.3.6.5 contentReturnRequest . . . . . . . . . . . 83 8.3.7 Unexpected values for INTEGER protocol elements . . . . . . . . . . . . . . . . . 83 8.3.7.1 Priority . . . . . . . . . . . . . . . . . 83 8.3.7.2 ExplicitConversion . . . . . . . . . . . . 83 8.3.7.3 ContentType . . . . . . . . . . . . . . . . 83 8.3.8 Additional elements . . . . . . . . . . . . 83 8.4 Reports . . . . . . . . . . . . . . . . . . . . . . 84 9 MHS use of Directory Services . . . . . . . . . . . . . . 84 9.1 Directory service elements . . . . . . . . . . . . . 84 9.2 Use of names and addresses . . . . . . . . . . . . . 85 10 Conformance . . . . . . . . . . . . . . . . . . . . . . . 86 10.1 Introduction . . . . . . . . . . . . . . . . . . . . 86 10.2 Definition of conformance . . . . . . . . . . . . . 86 10.3 Conformance requirements . . . . . . . . . . . . . . 88 10.3.1 Introduction . . . . . . . . . . . . . . . 88 10.3.2 Initial conformance . . . . . . . . . . . . 88 10.3.2.1 Interworking . . . . . . . . . . . . . . . 89 10.3.2.2 Service . . . . . . . . . . . . . . . . . . 89 Annex A (normative) Interpretation of X.400 service elements . . . . . . . . . . 90 A.1 Service elements . . . . . . . . . . . . . . . . . . 90 A.2 Probe . . . . . . . . . . . . . . . . . . . . . . . 90 A.3 Deferred delivery . . . . . . . . . . . . . . . . . 91 A.4 Content type indication . . . . . . . . . . . . . . 91 A.5 Original encoded information types indication . . . 91 A.6 Registered encoded information types . . . . . . . . 91 A.7 Delivery notification . . . . . . . . . . . . . . . 92 A.8 Disclosure of other recipients . . . . . . . . . . . 92 A.9 Typed body . . . . . . . . . . . . . . . . . . . . . 92 A.10 Blind copy recipient indication . . . . . . . . . . 92 v Part 7: 1984 Message Handling Systems December 1993 (Stable) A.11 Auto forwarded indication . . . . . . . . . . . . . 93 A.12 Primary and copy recipients indication . . . . . . . 93 A.13 Sensitivity indication . . . . . . . . . . . . . . . 93 A.14 Reply request indication . . . . . . . . . . . . . . 93 A.15 Body part encryption . . . . . . . . . . . . . . . . 93 A.16 Forwarded IP message indication . . . . . . . . . . 94 A.17 Multipart body . . . . . . . . . . . . . . . . . . . 94 Annex B (informative) Recommended X.400 practices . . . . . . . . . . . . . . . . . 95 B.1 Recommended practices in P2 . . . . . . . . . . . . 95 B.1.1 ORDescriptor . . . . . . . . . . . . . . . 95 B.1.2 ForwardedIPMessage BodyParts . . . . . . . 95 B.1.3 DeliveryInformation . . . . . . . . . . . . 95 B.2 Recommended practices in RTS . . . . . . . . . . . . 96 B.2.1 S-U-ABORT . . . . . . . . . . . . . . . . . 96 B.2.2 S-U-EXCEPTION-REPORT . . . . . . . . . . . 96 B.2.2.1 receiving ability jeopardized (value 1) . . 96 B.2.2.2 local ss-User error (value 5) . . . . . . . 96 B.2.2.3 irrecoverable procedure error (value 6) . . 96 B.2.2.4 non specific error (value 0) . . . . . . . 96 B.2.2.5 sequence error (value 3): . . . . . . . . . 96 B.2.3 OSI addressing information . . . . . . . . 97 B.3 Recommended practices for ORName . . . . . . . . . . 97 B.4 Postal addressing . . . . . . . . . . . . . . . . . 100 B.5 EDI use of X.400 . . . . . . . . . . . . . . . . . . 101 B.5.1 Introduction and scope . . . . . . . . . . 101 B.5.2 Model . . . . . . . . . . . . . . . . . . . 102 B.5.3 Protocol elements supported for EDI . . . . 103 B.5.3.1 Content type . . . . . . . . . . . . . . . 103 B.5.3.2 Original encoded information types . . . . 104 B.5.4 Addressing and routing . . . . . . . . . . 104 B.6 USA body parts . . . . . . . . . . . . . . . . . . . 104 B.7 Recommended practices for binary data transfer . . . 105 B.8 Recommended practice for Office Document Architecture (ODA) transfer . . . . . . . . . . . . 106 B.8.1 ODA In P2 . . . . . . . . . . . . . . . . . 106 B.8.2 ODA In P1 . . . . . . . . . . . . . . . . . 106 B.8.3 Interworking with later versions of X.400 . 106 Annex C (normative) Rendition of IA5Text and T61String characters . . . . . . . . 108 C.1 Generating and imaging IA5Text . . . . . . . . . . . 108 C.2 Generating and imaging T61String . . . . . . . . . . 109 Annex D (informative) vi Part 7: 1984 Message Handling Systems December 1993 (Stable) Differences in interpretation discovered through testing of the MHS for the CeBit 1987 demonstration . . . . . . . . . . . . 110 D.1 Encoding of RTS user data . . . . . . . . . . . . . 110 D.2 Extra session functional units . . . . . . . . . . . 111 D.3 Mixed case in the MTA name . . . . . . . . . . . . . 111 D.4 X.410 activity identifier . . . . . . . . . . . . . 112 D.5 Encoding of empty bitstrings . . . . . . . . . . . . 112 D.6 Additional octets for bitstrings . . . . . . . . . . 112 D.7 Application protocol identifier . . . . . . . . . . 113 D.8 Initial serial number in S-CONNECT . . . . . . . . . 113 D.9 Connection data on RTS recovery . . . . . . . . . . 113 D.10 Activity resume . . . . . . . . . . . . . . . . . . 113 D.11 Old activity identifier . . . . . . . . . . . . . . 114 D.12 Negotiation down to transport class 0 . . . . . . . 114 Annex E (informative) Worldwide X.400 conformance profile matrix . . . . . . . . . 115 Annex F (informative) Interworking warnings . . . . . . . . . . . . . . . . . . . . 136 vii Part 7: 1984 Message Handling Systems December 1993 (Stable) List of Figures Figure 1 - The layered structure of this implementation agreement. . . . . . . . . . . . . . . . . . . . . . . . 2 Figure 2 - This agreement applies to the interface between: (A) PRMD and PRMD; (B) PRMD and ADMD; (C) ADMD and ADMD; and (D) MTA and MTA. . . . . . . . . . . . . . . 4 Figure 3 - Interconnection of private domains. . . . . . . . 7 Figure 4 - X.409 definition of privately defined BodyParts. . 38 Figure 5 - An ADMD May (b) or May Not (a) Serve as a Relay. . 55 Figure 6 - Relaying PRMD. . . . . . . . . . . . . . . . . . . 65 Figure 7 - Intra PRMD connections. . . . . . . . . . . . . . 66 Figure 8 - MD C must know of A to route the message. . . . . 66 Figure 9 - Definition of InternalTraceInfo. . . . . . . . . . 67 Figure 10 - Defined actions in MTASuppliedInfo. . . . . . . . 68 Figure 11 - Example of a configuration to be avoided. . . . . 71 viii Part 7: 1984 Message Handling Systems December 1993 (Stable) List of Tables Table 1 - Basic MT service elements . . . . . . . . . . . . . 10 Table 2 - MT optional user facilities provided to the UA-selectable on a per-message basis . . . . . . . . . . 11 Table 3 - MT optional user facilities provided to the UA agreed for any contractual period of Time . . . . . . . 12 Table 4 - Basic IPM service elements . . . . . . . . . . . . 13 Table 5 - IPM optional facilities agreed for a contractual period of time . . . . . . . . . . . . . . . . . . . . . 13 Table 6 - IPM optional user facilities selectable on a per-message basis . . . . . . . . . . . . . . . . . . . 14 Table 7 - Protocol classifications . . . . . . . . . . . . . 16 Table 8 - P1 protocol elements . . . . . . . . . . . . . . . 19 Table 9 - ORName protocol elements . . . . . . . . . . . . . 28 Table 10 - P2 Heading protocol elements . . . . . . . . . . . 32 Table 11 - P2 BodyParts . . . . . . . . . . . . . . . . . . . 39 Table 12 - Checkpoint window size of IP . . . . . . . . . . . 48 Table 13 - RTS protocol elements . . . . . . . . . . . . . . 50 Table 14 - P1 protocol classification changes for a delivering ADMD . . . . . . . . . . . . . . . . . . . . 56 Table 15 - Delivery time targets . . . . . . . . . . . . . . 62 Table 16 - Forced nondelivery times . . . . . . . . . . . . . 62 Table 17 - Conformant MTA classifications . . . . . . . . . . 69 Table 18 - P1 protocol elements . . . . . . . . . . . . . . . 74 Table B.1 - Printable String to ASCII mapping . . . . . . . . 99 Table E.1 - Protocol element comparison of RTS . . . . . . . 116 Table E.2 - Protocol element comparison of P1 . . . . . . . . 119 Table E.3 - Protocol element comparison of P2 . . . . . . . . 130 ix Part 7 CCITT 1984 X.400 Based Message Handling System NOTE - The classification schema used in this chapter (see table 7) pre-dated TR 10 000 and was the basis of extensive harmonization, as such: No attempt will be made to align this chapter with TR 10 000. 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. While this agreement introduces no new protocols, it eliminates ambiguities in interpretations. This is an implementation agreement for a Message Handling System (MHS) based on the X.400-series of Recommendations (1984) and Version 5 of the X.400 Series Implementor's Guide from the CCITT. It is recommended that product vendors consult later versions of this guide. Figure 1 displays the layered structure of this agreement. This agreement can be used over any Transport protocol class. In particular, this MHS agreement can be used over the Transport protocol class 0 used over CCITT X.25, described in clause 5.2 of this document. In addition, this MHS agreement can be used over the Transport profiles used in support of MAP (Manufacturing Automation Protocol) or TOP (Technical and Office Protocols). Note that the MAP or TOP environment must support the reduced Basic Activity Subset (BAS) as defined in X.410. The UAs and MTAs require access to directory and routing services. A Directory Service is to be provided for each (vendor-specific) domain. Except insofar as they must be capable of providing addressing and routing described hereunder, these services and associated protocols are not described by this agreement. 1 Part 7: 1984 Message Handling Systems December 1993 (Stable) +------------------------------------------------------------ ------------+ | | | User Agent Layer CCITT X.420 | +------------------------------------------------------------ ------------+ | | | Message Transfer Agent Layer CCITT X.411 | +------------------------------------------------------------ ------------+ | | | Reliable Transfer Service Layer CCITT X.410 | +------------------------------------------------------------ ------------+ | | | Presentation Layer CCITT X.410 Sec. 4.2 | +---------------------------------------------------------------- -------+ | | | Session Layer See clause 5.9 | +---------------------------------------------------------------- -------+ Figure 1 - The layered structure of this implementation agreement. 2 Part 7: 1984 Message Handling Systems December 1993 (Stable) 1 Scope This agreement applies to Private Management Domains (PRMDs) and Administration Management Domains (ADMDs). Four boundary interfaces are specified: a) PRMD to PRMD, b) PRMD to ADMD, c) ADMD to ADMD, and d) MTA to MTA (within a PRMD, e.g., for MTAs from different vendors). In case A, the PRMDs do not make use of MHS services provided by an ADMD. In cases B and C, UAs associated with an ADMD can be the source or destination for messages. Furthermore, in cases A and B, a PRMD can serve as a relay between MDs, and in cases B and C an ADMD can serve as a relay between MDs. Figure 2 illustrates the interfaces to which the agreement applies. X.400 protocols other than the Message Transfer Protocol (P1) and the Interpersonal Messaging Protocol (P2) are beyond the scope of this agreement. Issues arising from the use of other protocols or relating to P1 components in support of other protocols are outside the scope of this document. This agreement describes the minimum level of services provided at each interface shown in figure 2. Provision for the use of the remaining services defined in the X.400 Series of Recommendations is outside the scope of this document. With the exception of intra domain connections, this agreement does not cover message exchange between communicating entities within a domain even if these entities communicate via P1 or P2. Bilateral agreements between domains may be implemented in addition to the requirements stated in this document. Conformance to this agreement requires the ability to exchange messages without use of bilateral agreements. 3 Part 7: 1984 Message Handling Systems December 1993 (Stable) +---------------------------------------------------------------- -+ | | | PRMD = Private Management Domain | | ADMD = Administration Management Domain +-----+ | | |PRMD | | | +--+--+ | | +--------------+ | ---|----A | | | PRMD | | +--+--+ | | | +-------+ +--------------------------------------+PRMD | | | | | MTA A | | | +--+--+ | | | +---+---+ | | A ---|----B | | | ---|---D | | +--+--+ | | | +---+---+ +--------------------------------------+ADMD | | | | | MTA B | | | +--+--+ | | | +-------+ | | ---|----C | | +--------------+ B +--+--+ | | |ADMD | | | +-----+ | | | +---------------------------------------------------------------- -+ Figure 2 - This agreement applies to the interface between: (A) PRMD and PRMD; (B) PRMD and ADMD; (C) ADMD and ADMD; and (D) MTA and MTA. 4 Part 7: 1984 Message Handling Systems December 1993 (Stable) 2 Normative references CCITT Recommendation X.121 (1988), International Numbering Plan. CCITT Recommendation X.400, (Red Book, 1984), Message Handling Systems: System Model-Service Elements. CCITT Recommendation X.401, (Red Book, 1984), Message Handling Systems: Basic Service Elements and Optional User Facilities. CCITT Recommendation X.408, (Red Book, 1984), Message Handling Systems: Encoded Information Type Conversion Rules. CCITT Recommendation X.409, (Red Book, 1984), Message Handling Systems: Presentation Transfer Syntax and Notation. CCITT Recommendation X.410, (Red Book, 1984), Message Handling Systems: Remote Operations and Reliable Transfer Server. CCITT Recommendation X.411, (Red Book, 1984), Message Handling Systems: Message Transfer Layer. CCITT Recommendation X.420, (Red Book, 1984), MessageHandling Systems: Interpersonal Messaging User Agent Layer. CCITT Recommendation X.430, (Red Book, 1984), Message Handling Systems: Access Protocol for Teletex Terminals. 3 Status This version of the X.400 based Message Handling System implementation agreements was completed on December 16, 1988. No further enhancements will be made to this version. See the next clause--Errata. 5 Part 7: 1984 Message Handling Systems December 1993 (Stable) 4 Errata 5 PRMD to PRMD 5.1 Introduction This clause is limited in scope to issues arising from the direct connection (interface A in figure 2) of two PRMDs. "Direct" means that no ADMD or relaying PRMD provides MHS services to facilitate message interchange. "Direct" does not exclude those instances for which Administrations happen to be ADMDs but are not providing X.400 services, that is, they are used only to provide lower layer services such as X.25. Figure 3 schematically represents the scope of this clause. These issues relate to the use of the UAL (User Agent Layer) and MTL (Message Transfer Layer) services, protocol elements, recommended practices and constraints. In particular, this clause addresses the P1 and P2 protocols and their related services in a direct connection environment. This clause describes the minimum level of services provided by a PRMD. Provision for the use of the remaining services defined in the X.400 Series of Recommendations is beyond the scope of this clause. 6 Part 7: 1984 Message Handling Systems December 1993 (Stable) +---------------------------------------------------------------- ------------+ | | | +--------------------+ +---------------------+ | | | Private Domain X | | Private Domain Y | | | | | | | | | | | | | | | | | | | | | | +-----+ | | +------+ | | | | +->| UA |<------+----------- P2 --------------+---->| UA |<-+ | | | | | +-----+ | | +------+ | | | | | | | MTA |<------+----------- P1 --------------+---->| MTA | | | | | | | +-----+ | | +------+ | | | | | | /|\ | | /|\ | | | | | | | | | | | | | | | | | | | | the | | the | | | | remainder of | | remainder of | | | | Domain X | | Domain Y | | | | NETWORK | | NETWORK | | | | | | | | | +--------------------+ +---------------------+ | | | +---------------------------------------------------------------- ------------+ Figure 3 - Interconnection of private domains. 7 Part 7: 1984 Message Handling Systems December 1993 (Stable) 5.2 Service elements and optional user facilities This clause identifies those service elements and optional user facilities that must be provided in support of P1 and P2. 5.2.1 Classification of support for services The classification of UA and MT-Service elements is used to define characteristics of equipment. Equipment can claim SUPPORT or NON-SUPPORT of a Service; in the case of UA-service elements, a separate classification is given for Origination and Reception. The service provider is defined as the entity providing the service, in this case, the MTL or the UAL. The service user is either the MHS user or the UAL. The classification of provider and user relates to the sublayer for which the service element is defined. 5.2.1.1 Support (S) Support means: a) The service provider makes the service element available to the service user, and b) The service user gives adequate support to the MHS to invoke the service element or makes information associated with the service element available. Support for Origination means that: a) The service provider makes the service element available to the service user for invocation, and b) The service user gives adequate support to the end user of the MHS to invoke the service element. Support for Reception means that: a) The service provider makes information associated with the service element available to the service user. NOTE - A UA- or MT-service element can carry information from originator to recipient only if: b) the service element is available to the originator, 8 Part 7: 1984 Message Handling Systems December 1993 (Stable) c) the service element is available to the recipient, and d) all intermediate steps carry the information. 5.2.1.2 Non Support (N) This means that the service provider is not required to make the service element available to the service user. However, the service provider should not regard the occurrence of the corresponding protocol elements as an error and should be able to relay such elements. Implementations making a profile available should indicate deviations (additions or deletions) with respect to the requirement in the profile. 5.2.1.3 Not Used (N/U) This means that although the Recommendation allows this service element, this profile does not use it. 5.2.1.4 Not Applicable (N/A) This means that this service element does not apply in this particular case (for originator or recipient). 5.2.2 Summary of supported services Within a PRMD, a User Agent must support all P2 BASIC IPM Services (X.400) and all P2 ESSENTIAL IPM Optional user facilities (X.401) subject to the qualifiers listed in annex A. Within a PRMD, a MTA must support all BASIC MT Services (X.400) and all ESSENTIAL MT optional user facilities (X.401) subject to the qualifiers listed in annex A. No support is required of the additional optional user facilities of X.401. 5.2.3 MT service elements and optional user facilities Tables 1 through 3 show the Message Transfer (MT) service elements and optional user facilities. 9 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 1 - Basic MT service elements +------------------------------------------------------------+ | Support (S) or | | Service Elements Non-support (N) | +------------------------------------------------------------+ | Access Management N/U1 | | Content Type Indication S | | Converted Indication S | | Delivery Time Stamp Indication S | | Message Identification S | | Non-delivery Notification S | | Original Encoded Information Types Indication S | | Registered Encoded Information Types N/U1 | | Submission Time Stamp Indication S | +------------------------------------------------------------+ | Notes | | 1 Not applicable to co-resident UA and MTA. | +------------------------------------------------------------+ 10 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 2 - MT optional user facilities provided to the UA-selectable on a per-message basis +---------------------------------------------------------------- ------------+ | Support (S) or | | MT Optional User Facilities Categorization Non-support (N) | +---------------------------------------------------------------- ------------+ | | | Alternate Recipient Allowed E S | | Conversion Prohibition E S | | Deferred Delivery E N2 | | Deferred Delivery Cancellation E N2 | | Delivery Notification E S | | Disclosure of Other Recipients E N3 | | Explicit Conversion A N | | Grade of Delivery Selection E S | | Multi-destination Delivery E S | | Prevention of Non-delivery Notification A N | | Probe E N4 | | Return of Contents A N | | | +---------------------------------------------------------------- ------------+ | Legend | | E: Essential optional user facility. | | A: Additional optional user facility. | +---------------------------------------------------------------- ------------+ | Notes 11 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | 2 A local facility subject to qualifiers in annex A. | | 3 Support not required for an originating MT user; support must be | | provided for recipient MT users. | | 4 Subject to qualifiers in annex A. | +---------------------------------------------------------------- ------------+ Table 3 - MT optional user facilities provided to the UA agreed for any contractual period of Time +---------------------------------------------------------------+ | Support (S) or | | MT Optional User Facilities Categorization Non-Support (N)| +---------------------------------------------------------------+ | | |Alternate Recipient Assignment A N | |Hold for Delivery A N/U | |Implicit Conversion A N | +---------------------------------------------------------------+ | Legend | | A: Additional optional user facility. | +---------------------------------------------------------------+ 5.2.4 IPM service elements and optional user facilities Tables 4 through 6 show the IPM service elements and optional user facilities. 12 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 4 - Basic IPM service elements +---------------------------------------------------------------+ | Origination Reception | | Service Elements by UAs by UAs | +---------------------------------------------------------------+ | Access Management N/U5 N/U5 | | Content Type Indication S S | | Converted Indication N/A S | | Delivery Time Stamp Indication N/A S | | Message Identification S S | | Non-delivery Notification S N/A | | Original Encoded Information S S | | Types Indication | | Registered Encoded Information Types N/A N/A5 | | Submission Time Stamp Indication S S | | IP-message Identification S S | | Typed Body S S | +---------------------------------------------------------------+ | Notes | | 5 Does not apply to co-resident UA and MTA. | +---------------------------------------------------------------+ Table 5 - IPM optional facilities agreed for a contractual period of time +--------------------------------------------------------------+ | Support (S) or | | Service Elements Categorization Non-Support (N)| +--------------------------------------------------------------+ | Alternate Recipient Assignment A N | | Hold for Delivery A N | | Implicit Conversion A N | +--------------------------------------------------------------+ 13 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 6 - IPM optional user facilities selectable on a per-message basis +-------------------------------------------------------------+ | Origination Reception| | IPM Optional User Facilities by UAs by UAs | +-------------------------------------------------------------+ | Alternate Recipient Allowed A (N) A (N)| | Authorizing Users Indication A (N) E (S)| | Auto-forwarded Indication A (N) E (S)| | Blind Copy Recipient Indication A (N) E (S)| | Body Part Encryption Indication A (N) E (S)| | Conversion Prohibition E (S) E (S)| | Cross-referencing Indication A (N) E (S)| | Deferred Delivery E (N)6 N/A | | Deferred Delivery Cancellation A (N/U)6 N/A | | Delivery Notification E (S) N/A | +-------------------------------------------------------------+ | Disclosure of Other Recipients A (N) E (S)| | Expiry Date Indication A (N) E (S)| | Explicit Conversion A (N) N/A | | Forwarded IP-message Indication A (N) E (S)| | Grade of Delivery Selection E (S) E (S)| | Importance Indication A (N) E (S)| | Multi-destination Delivery E (S) N/A | | Multi-part Body A (N) E (S)| | Non-receipt Notification A (N) A (N)| | Obsoleting Indication A (N) E (S)| +-------------------------------------------------------------+ | Originator Indication E (S) E (S)| | Prevention of Non-delivery Notification A (N) N/A | | Primary and Copy Recipients Indication E (S) E (S)| | Probe A (N) N/A | | Receipt Notification A (N) A (N)| | Reply Request Indication A (N) E (S)| | Replying IP-message Indication E (S) E (S)| | Return of Contents A (N) N/A | | Sensitivity Indication A (N) E (S)| | Subject Indication E (S) E (S)| +-------------------------------------------------------------+ | Notes | | 6 A local facility subject to qualifiers in annex A. | +-------------------------------------------------------------+ 14 Part 7: 1984 Message Handling Systems December 1993 (Stable) 5.3 X.400 protocol definitions This clause reflects the agreements of the OIW regarding P1 and P2 protocol elements. 5.3.1 Protocol classification The protocol classifications are defined in table 7. 15 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 7 - Protocol classifications +---------------------------------------------------------------- -----------+ | 1) UNSUPPORTED = X | | These elements may be generated, but no specific processing should | | be expected in a relaying or delivering domain. A relaying domain | | must at least relay the semantics of the element. The absence of | | these elements should not be assumed, in a relaying or delivering | | domain, to convey any significance. | | | | 2) SUPPORTED = H | | These elements may be generated. However, implementations are not | | required to be able to generate these elements. Appropriate | | actions shall be taken in a relaying or delivering domain. | | | | 3) GENERATABLE = G | | Implementations must be able to generate and handle these protocol | | elements, although they are not necessarily present in all | | messages generated by implementations of this profile. | | Appropriate actions shall be taken in a relaying or delivering | | domain. | | | | 4) REQUIRED = R | | Implementations of this profile must always generate this protocol | | element. However, its absence cannot be regarded as a protocol | | violation as other MHS implementations may not require this | 16 Part 7: 1984 Message Handling Systems December 1993 (Stable) | protocol element. Appropriate actions shall be taken in a | | relaying or delivering domain. | | | | 5) MANDATORY = M | | This must occur in each message as per X.411 or X.420 as | | appropriate; absence is a protocol violation. Appropriate actions | | shall be taken in a relaying or delivering domain. | +---------------------------------------------------------------- -----------+ 5.3.2 General statements on pragmatic constraints Where a protocol element is defined as a choice of Numeric String and Printable String (i.e., Administration Domain Name and Private Domain Identifier), then a numeric value encoded as a printable string is equivalent to the same value encoded as a numeric string. This does not apply to the Country Name protocol element. The maximum number of recipients in a single MPDU is 32K - 1 (that is, 32767). However, no individual limits on the number of occurrences (recipients) are placed on the following protocol elements: Authorizing Users, Primary Recipients, Copy Recipients, Blind Copy Recipients, Obsoletes and Cross References. Additionally, there is no limit on the number of Reply to Users. This is a local matter for the originating system. Use of strings. A Printable String is defined in terms of the number of characters, which is the same number of octets. For T.61 strings the number of octets is twice the number of characters specified. The ability to generate maximum size elements is not required, with the exception of the component fields in the Standard Attribute List, in which case it is required. 17 Part 7: 1984 Message Handling Systems December 1993 (Stable) 5.3.3 MPDU size The following agreements govern the size of MPDUs: a) All MTAEs must support at least one MPDU of at least 2 megabyte, and b) The size of the largest MPDU supported by a UAE is a local matter. 5.3.4 P1 protocol elements Table 8 contains Protocol Elements and their classes. 18 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 8 - P1 protocol elements +---------------------------------------------------------------- ------------+ |Element Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ |MPDU | | UserMPDU G | | DeliveryReportMPDU G | | | | ProbeMPDU H | | | |UserMDPU | | UMPDUEnvelope M | | UMPDUContent M | | | |UMPDUEnvelope | | MPDUIdentifier M | | originator ORname M | | originalEncodedInformationTypes G | | If this field is absent, then the | | Encoded Information Type is | | "unspecified." | | ContentType M | | UAContentID H Maximum length = 16 characters. | | Priority G | | PerMessageFlag G Maximum length = 2 octets. | 19 Part 7: 1984 Message Handling Systems December 1993 (Stable) | deferredDelivery X | | PerDomainBilateralInfo X No limit on number of occurrences. | | RecipientInfo M Maximum number = 32K - 1 occurr- | | ences. More severe limitations are | | by bilateral agreement. | | TraceInformation M | |UMPDUContent M | | | |MPDUIdentifier | | GlobalDomainIdentifier M | | IA5String M Maximum length = 32 characters, | | graphical subset only. Refer to | | T.50 for clarification of graphical| |PerMessageFlag subset. | | discloseRecipients H | | conversionProhibited G | | alternateRecipientAllowed H | | contentReturnRequest X | +---------------------------------------------------------------- ------------+ 20 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 8 - P1 protocol elements (continued) +---------------------------------------------------------------- ------------+ |Element Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ |PerDomainBilateralInfo | | CountryName M Maximum length = 3 characters. | | AdministrationDomainName M Maximum length = 16 characters. | | BilateralInfo M Maximum depth = 8; maximum | | length = 1024 octets | | (including encoding). | | RecipientInfo | | recipient M | | ExtensionIdentifier M Maximum value = 32K - 1 (32767). | | perRecipientFlag M Maximum length = 2 octets. | | ExplicitConversion X | | | |perRecipientFlag | | ResponsibilityFlag M | | ReportRequest M | | UserReportRequest M | | | |TraceInformation Reference should be made to | | Version 5 of the X.400 Imple- | | mentor's Guide for information | | GlobalDomainIdentifier M related to Trace sequencing. | 21 Part 7: 1984 Message Handling Systems December 1993 (Stable) | DomainSuppliedInfo M | | | |DomainSuppliedInfo | | arrival M | | deferred X | | action M | | 0=relayed (value) G | | 1=rerouted (value) H Rerouting is not required. | | converted H | | previous H | | | |ORName See clause 5.3.5 | | | |EncodedInformationTypes | | bit string M Delivery can only occur if match | | is made with Registered Encoded | | Information Types. Individual | | vendors may impose limits. | | Maximum length = 4 octets. | | G3NonBasicParameters X | | TeletexNonBasicParameters X | | PresentationCapabilities X | +---------------------------------------------------------------- ------------+ 22 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 8 - P1 protocol elements (continued) +---------------------------------------------------------------- ------------+ |Element Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ | | |DeliveryReportMPDU | | DeliveryReportEnvelope M | | DeliveryReportContent M | | | |DeliveryReportEnvelope | | report M | | originator M | | TraceInformation M | | | |DeliveryReportContent | | original M | | intermediate G See comment at end of table. | | UAContentID G | | ReportedRecipientInfo M Maximum number = 32K - 1 | | occurrences. | | returned H Can only be issued if specifically | | requested in the originating | | message. | | billingInformation X Maximum depth = 8; maximum | | length = 1024 octets (including | 23 Part 7: 1984 Message Handling Systems December 1993 (Stable) | encoding). | | | |ReportedRecipientInfo | | recipient M | | ExtensionsIdentifier M | | PerRecipientFlag M | | LastTraceInformation M | | intendedRecipient H | | SupplementaryInformation X Maximum length = 64 characters. | | Value is pending verification by | | the CCITT SG VIII or XI. | | | |LastTraceInformation | | arrival M | | converted G | | Report M | +---------------------------------------------------------------- ------------+ 24 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 8 - P1 protocol elements (concluded) +---------------------------------------------------------------- ------------+ | | |Element Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ |Report | | DeliveredInfo G Generated if delivery is reported. | | NondeliveredInfo G Generated if failure to deliver | | is reported. | |DeliveredInfo | | delivery M | | typeofUA R This element must be generated with| | a PRIVATE value by PRMDs. | | | |NonDeliveredInfo | | ReasonCode M | | DiagnosticCode H Whenever possible, use a meaningful| | diagnostic code. | | | |ProbeEnvelope | | probe M | | originator M | | ContentType M | | UAContentID H Maximum length = 16 characters. | | original G If this field is 25 Part 7: 1984 Message Handling Systems December 1993 (Stable) absent, then the | | Encoded Information Type is | | "unspecified." | | | | | | TraceInformation M | | | | PerMessageFlag G | | | | contentLength H | | PerDomainBilateralInfo X | | RecipientInfo M Maximum number = 32K - 1 | | occurrences. | |GlobalDomainIdentifier | | CountryName M Maximum length = 3 characters. | | AdministrationDomainName (4) M Maximum length = 16 characters or | | digits. | | | | PrivateDomainIdentifier R Maximum length = 16 characters or | | digits. This element must be | | generated by PRMDs. | | | | End of Definitions | +---------------------------------------------------------------- ------------+ Note: [Comment on intermediate TraceInformation in the 26 Part 7: 1984 Message Handling Systems December 1993 (Stable) DeliveryReportContent in table 8: Audit and confirmed reports should not be requested by other than the originating domain for two reasons. First, the return path of the report may be different from the path taken by the original message, and it may exclude the domain that added the request for audit and confirmed to the message. Second, if the return path is different from the path of the original message, the originating domain would receive intermediate trace information that it did not request.] 5.3.5 ORName protocol elements Only form 1 variant 1 O/R names are supported. Table 9 contains ORName protocol elements. These agreements interpret 1984 X.400 clause 3.4 to mean that the attributes in the ORName in the MPDU must identify exactly one UA, and that all the values for the attributes specified in the ORName must be identical to the values of the corresponding attributes associated with the recipient UA. Underspecified names that are unique are deliverable. Overspecified ORNames, ORNames with mismatching fields, and ambiguous names are to be non-delivered or sent to the alternate recipient as appropriate. 27 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 9 - ORName protocol elements +---------------------------------------------------------------- ------------+ |Element Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ | | |ORName | | StandardAttributeList M | | DomainDefinedAttributeList G | | | |StandardAttributeList (1) | | CountryName R As defined in X.411, Maximum | | length = 3 characters. | | AdministrationDomainName (4) R Maximum length = 16 characters | | or digits. | | X121Address X Maximum length = 15 digits. | | TerminalID X Maximum length = 24 characters. | | PrivateDomainName (2) G Maximum length = 16 characters. | | OrganizationName (2) G Maximum length = 64 characters. | | UniqueUAIdentifier X Maximum length = 32 digits. | | PersonalName G Maximum length of values of sub- | | elements = 64 characters. | | Note: The possibility that this | | value may be reduced to 40 | | characters is for further | | study by the CCITT. | 28 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | | OrganizationalUnit (3) G Maximum length = 32 characters per | | occurrence. A maximum of four | | occurrences are allowed. | | | |DomainDefinedAttributeList (5) Maximum = 4 occurrences. | | type M Maximum length = 8 characters. | | value M Maximum length = 128 characters. | | | |PersonalName | | surName M Maximum length = 40 characters. | | givenName G Maximum length = 16 characters. | | initials G Maximum length = 5 characters; | | excluding surname initial and | | punctuation and spaces. | | generationQualifier G Maximum length = 3 characters. | +---------------------------------------------------------------- ------------+ 29 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 9 - ORName protocol elements (concluded) +---------------------------------------------------------------- ------------+ | Notes: | | 1 The following apply for comparison of the Standard Attributes of an | | O/R Name: | | a) Lower case is interpreted as upper case (for IA5). | | b) Multiple spaces may be interpreted as a single space. Originating | | domains shall only transmit single significant spaces. If multiple | | spaces are transmitted, non-delivery may occur. | | 2 At least one of these must be supplied. | | 3 These should be sent in descending sequence, from the most significant | | (highest in organization hierarchy) to the least | | significant. Only those specified should be sent. (That is, an | | unspecified should not be sent along as a field | | of [null] content, nor zero length, etc.) | | 4 This attribute shall contain one space in all ORNames of messages | | originated in a PRMD that is not connected to an ADMD, and in ORNames | | of recipients reachable only through a PRMD; otherwise, this attribute | | shall contain an appropriate ADMD name. | | 5 Some existing systems which will be accessed via an X.400 service | | (whether directly connected using X.400 protocols or otherwise) may | | require the provision of addressing attributes which are not adequately | | supported by Standard Attributes as defined in these Agreements. In | | such cases, Domain Defined Attributes are an acceptable means of | | carrying additional addressing information. Failure to support the | 30 Part 7: 1984 Message Handling Systems December 1993 (Stable) | specification and relaying of DDAs may prevent successful interworking | | with such existing systems until such time as all systems are capable | | of relaying and delivery using only the Standard Attribute list. | | Specific recommendations on the use of DDAs for particular applications | | are in the Recommended Practices, annex B. | +---------------------------------------------------------------- ------------+ 5.3.6 P2 protocol profile (based on [X.420]) Tables 10 and 11 classify the support for the P2 protocol elements required by this profile. The tables give restrictions and comments in addition to X.420. Restriction on length is one of the types of restrictions. The reaction of implementations to a violation of this restriction is not defined by this Profile. 5.3.6.1 P2 protocol - Heading Table 10 specifies the support for protocol elements in P2 Headings. 31 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 10 - P2 Heading protocol elements +---------------------------------------------------------------- ------------+ | Element Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ |UAPDU | | IM-UAPDU G | | SR-UAPDU X | | | |IM-UAPDU | | Heading M | | Body M | | | |Heading | | IPMessageId M | | originator R | | authorizingUsers H | | primaryRecipients G At least one of primaryRecipients, | | copyRecipients G copyRecipients, or | | blindCopyRecipients must be | | blindCopyRecipients H present. | | inReplyTo G | | obsoletes H | | crossReferences H | | subject G Maximum length = 128 T.61 | | characters (256 octets);the ability| 32 Part 7: 1984 Message Handling Systems December 1993 (Stable) | to generate the maximum size | | subject is not required. | | expiryDate H | | replyBy H | | replyToUsers H | | importance H Appropriate action is for further | | study. | | sensitivity H Appropriate action is for further | | study. | | autoforwarded H | +---------------------------------------------------------------- ------------+ 33 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 10 - P2 Heading protocol elements (continued) +---------------------------------------------------------------- ------------+ |Element Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ | | |IPmessageId | | ORName H | | PrintableString M Maximum length = 64 characters. | |ORDescriptor | | ORName H Specify the ORName whenever it is | | possible. See annex B. | | freeformName H Maximum length = 64 characters, | | graphical subset only (128 octets.)| | telephoneNumber H Maximum length = 32 characters. | | This allows for punctuation. It | | does not take into account possible| | future use by ISDN. | | | |Recipient | | ORDescriptor M | | reportRequest X | | replyRequest H | | | |Body No limit on number of BodyParts. | | BodyPart G No limit on length of any BodyPart | 34 Part 7: 1984 Message Handling Systems December 1993 (Stable) | or the depth of ForwardedIPMessage | | BodyParts nested. Classification is| | subject to pending CCITT resolution| | | | | |SR-UAPDU | | nonReceipt H | | receipt H | | reported M | | actualRecipient R | | intendedRecipient H | | converted X | |NonReceiptInformation | | reason M | | nonReceiptQualifier H | | comments H Maximum length = 256 characters. | | returned H May only be issued if specifically | | requested by originator. | +---------------------------------------------------------------- ------------+ 35 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 10 - P2 Heading protocol elements (concluded) +---------------------------------------------------------------- ------------+ |Element Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ | | |ReceiptInformation | | receipt M | | typeOfReceipt H | | SupplementaryInformation X Maximum length = 64 characters. | | Note: This value is pending | | verification by the CCITT SG | | VIII or IX. | | | | End of Definitions | +---------------------------------------------------------------- ------------+ 5.3.6.2 P2 protocol - BodyParts 5.3.6.2.1 BodyPart identifiers All BodyParts with identifiers in the range 0 up to and including 16K -1 are legal and should be relayed. BodyPart identifiers corresponding to X.121 Country Codes should be interpreted as described in Note 2 of figure 4. a) Implementations are required to generate and image IA5Text. b) Implementations should specify the other BodyPart types supported. c) If an implementation supports a particular BodyPart type for reception, it should also be able to support that 36 Part 7: 1984 Message Handling Systems December 1993 (Stable) BodyPart type for reception if it is part of a ForwardedIPMessage. d) For the BodyPart types currently considered, support for the protocol elements is as indicated in table 11. 5.3.6.2.2 Privately defined BodyParts This clause describes an interim means for identifying privately defined BodyParts. This clause shall be replaced in a future version taking into account CCITT recommendations with equivalent functionality. 37 Part 7: 1984 Message Handling Systems December 1993 (Stable) +---------------------------------------------------------------+ | BodyPart :: = CHOICE { | | [0] IMPLICIT IA5Text, | | [1] IMPLICIT TLX, | | . | | . | | . | | [234] IMPLICIT UKBodyParts, | | . | | . | | . | | [310] IMPLICIT USABodyParts, | | . | | . | | . } | | -- Where UKBodyParts and USABodyParts are defined as: | | SEQUENCE { BodyPartNumber, ANY } | | BodyPartNumber ::= INTEGER | +---------------------------------------------------------------+ | Notes | | 1 In the EncodedInformationTypes of the P1 Envelope, the | | undefined bit must be set when a message contains a | | privately defined BodyPart. Each UA that expects such | | BodyParts should include undefined in the set of | | deliverable EncodedInformationTypes it registers with the | | MTA. | | | | 2 All BodyPartNumbers assigned must be interpreted relative | | to the BodyPart in which they are used, which is that | | tagged with the value [310] for those defined within the | | United States. The NIST assigns unique message | | BodyPartNumbers for privately defined formats within the | | United States. | | | | 3 Refer to clause 12.6 for recommendations regarding the | | implementaion of USABodyParts. | +---------------------------------------------------------------+ Figure 4 - X.409 definition of privately defined BodyParts. 5.3.6.3 P2 BodyPart protocol elements 38 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 11 - P2 BodyParts +---------------------------------------------------------------- ------------+ |Elements Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ | | |BodyPart | | IA5Text G | | TLX X | | Voice X | | G3Fax X | | TIFO X | | TTX X | | Videotex X | | NationallyDefined X | | Encrypted X | | ForwardedIPMessage H | | SFD X | | TIF1 X | | unidentified X | | | |IA5Text | | repertoire H | | IA5String M For rendition of IA5Text see | | annex C. | |TLX For further study by CCITT. | 39 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | |Voice | | Set For further study by CCITT. | | BitString M | | | |G3Fax | | numberOfPages X | | P1.G3NonBasicParameters X | | SEQUENCE (OF BIT STRING) M | | BIT STRING H See Note. | | | |P1.G3NonBasicParameters Support for individual elements is | | for further study. | | | |TIFO | | T.73Document M | | T.73ProtocolElement H See Note. | +---------------------------------------------------------------- ------------+ 40 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 11 - P2 BodyParts (continued) +---------------------------------------------------------------- ------------+ |Elements Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ | | |TTX | | numberOfPages X | | telexCompatible X | | P1.TeletexNonBasicParams X | | SEQUENCE M | | T61String H See Note. | | | |P1.TeletexNonBasicParams | | graphicCharacterSets X | | controlCharacterSets X | | pageFormats X | | miscTerminalCapabilities X | | privateUse X | | | |Videotex | | SET For further study by CCITT. | | VideotexString M | | | |NationallyDefined | | ANY M | 41 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | |Encrypted | | SET For further study by CCITT. | | BIT STRING M | | | |ForwardedIPMessage | | delivery H | | DeliveryInformation H | | IM-UAPDU M | | | |DeliveryInformation | | P1.ContentType M | | originator M | | original M | | P1.Priority G | | DeliveryFlags M | | otherRecipients H | | thisRecipient M | | intendedRecipient H | | converted X | | submission M | +---------------------------------------------------------------- ------------+ 42 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 11 - P2 BodyParts (concluded) +---------------------------------------------------------------- ------------+ |Elements Class Restrictions and Comments | | | +---------------------------------------------------------------- ------------+ |SFD | | SFD.Document M | | | |TIF1 | | T73 Document M | | T73.ProtocolElement H See note. | +---------------------------------------------------------------- ------------+ | | |Note: This element is not an addition to the definition of the BodyPart. | | It is described here to show that the SEQUENCE may contain zero | | elements. A Problem Report has been submitted to the CCITT to | | clarify whether this is permissible. The NIST/OSI Workshop | | will adopt the CCITT decision. | +---------------------------------------------------------------- ------------+ 5.4 Reliable Transfer Server (RTS) 5.4.1 Implementation strategy Based on X.410 Clause 3 and X.411 Clause 3.5. 43 Part 7: 1984 Message Handling Systems December 1993 (Stable) 5.4.2 RTS option selection The maximum number of simultaneous associations is not limited in this profile; if the capacity of a system is exceeded, it should not initiate or accept additional associations. Associations are established by the MTA which has messages to transfer. Associations are released when they are not needed. Associations may also be ended prematurely due to internal problems of the RTS. For both monologue and two way alternate associations, the initiator keeps the initial turn. When establishing an RTS association, the following rules apply to the use of parameters in addition to those in X.410 Clause 3.2.1: a) Dialogue mode: Monologue must be supported for this profile; two-way alternate is used only if both partners agree. b) Initial turn: Kept by the initiator of the association. The "priority-mechanism" and the "transfer-time limit" are regarded as local matters. 5.4.3 RTS protocol options and clarifications Realization of the RTS protocol is subject to the following rules in addition to those specified in X.410 Clause 4: a) One RTS association corresponds to one or more consecutive session connections (not concurrent ones). The first is opened with ConnectionData of type OPEN, and subsequent ones are opened with type RECOVER. b) Recovery of a Session connection is only by RTS initiator. c) Checkpoint size: 1) Checkpointing and No Checkpointing should be supported. Whenever possible, checkpointing should be used. 44 Part 7: 1984 Message Handling Systems December 1993 (Stable) 2) The minimum checkpointSize is 1 (that is, 1024 octets). d) Window size: 1) Minimal value of 1 (if checkpointing is supported). 2) WindowSize = 1 means: After an S-SYNCH-MINOR request is sent, wait until the confirmation is received before issuing an S-DATA, S-SYNCH-MINOR, or S-ACTIVITY-END request. e) APDUs should not be blocked into one activity. f) Only one SSDU shall be transferred: 1) Between two adjacent minor synch points. 2) Between minor synch points and adjacent S-ACTIVITY-START and S-ACTIVITY-END requests. 3) Between S-ACTIVITY-START and S-ACTIVITY-END without checkpoints. g) A monologue association is defined as follows: 1) The RTS user responsible for establishing the association is called the initiator. 2) The initiator keeps the initial turn. 3) APDUs are transferred in the direction of the initiator to the recipient only. 4) There shall be no token passing. 5) Only the initiator can effect an orderly release of the association. h) A two-way alternate association is as described in X.410. i) In the UserData parameter of the S-U-ABORT, the ReflectedParameter will not be used in the AbortInformation element. j) When the S-ACTIVITY-RESUME is used to resume an activity in the same session connection as the one in which it started, this must happen immediately after the activity has 45 Part 7: 1984 Message Handling Systems December 1993 (Stable) been interrupted (i.e., no intervening activity can occur). Otherwise, X.410 Clause 4.3 paragraph 1 may be violated. k) When S-ACTIVITY-RESUME is used to resume an activity started in another session connection, the following conditions must be met: 1) The current session connection is of type "recover." 2) The value of OldSessionConnectionIdentifier in S-ACTIVITY-RESUME must match the value of the SessionConnectionIdentifier parameter used in the S-CONNECT of the prior session connection. This value is also identical to the SessionConnectionIdentifier in the ConnectionData (in PConnect, in SS-UserData) for the current session connection. 3) This must occur as the first activity of the next session connection for the same RTS-association. It must be the first, otherwise X.410 Clause 4.5.1 point 1 is violated. NOTE - It is in the same RTS-ASSOCIATION because the use of S-ACTIVITY-RESUME only makes sense within the scope of one RTS association. l) If the transfer of an APDU is interrupted before the confirmation of the first checkpoint, the value of the SynchronizationPointSerialNumber in S-ACTIVITY-RESUME should be zero, and the S-ACTIVITY-RESUME must be immediately followed by an S-ACTIVITY-DISCARD. m) In S-TOKEN-PLEASE, the UserData parameter shall contain an integer conforming to X.409 which conveys the priority. n) The receiving RTS can use the value of the Reason parameter in the S-U-EXCEPTION-REPORT to suggest to the sending RTS that it should either interrupt or discard the current activity. S-U-Exception Reports are handled as stated in Version 5 of the Implementors Guide pages 12-13, paragraph E-33. o) In the case of S-P-ABORT, the current activity (if any) is regarded as interrupted, rather than discarded. p) Table 12 illustrates the legal negotiation possibilities allowed by X.410 Clause 4.2.1 regarding checkpoint size and window size. 46 Part 7: 1984 Message Handling Systems December 1993 (Stable) q) These agreements include the provisions of Version 6 of the Implementors Guide identical in all respects to Version 5, except that the following points have been added to clause 3.5: 1) for section 4.4.1 of X.410; "If the receiving RTS receives an S-ACTIVITY-DISCARD indication primitive and has already issued a TRANSFER indication primitive, it aborts the connection (S-U-ABORT request) with the 'transfer completed' version code." 2) for section 4.6.2 of X.410 "The `transfer completed (7)' abort reason is used to indicate to the sending RTS that the receiving RTS could not discard the activity because it has already completed the transfer (issued a TRANSFER indication primitive)." Transfer completed (7) is also added to the table of abort reasons in this clause. 47 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 12 - Checkpoint window size of IP +--------------------------------------------------+ | acceptor answer | +----------------+----------------+----------------+ | CS = 0 | CS = m | CS = n | |(or unspecified)| WS = j | WS = j | | WS unspecified |(or unspecified)|(or unspecified)| +---------+--------------- +---------------+----------------+---- ------------+ | | CS = O | | | | | |(or unspecified)| legal | legal | legal | | | WS = i | | | | |initiator|(or unspecified)| | | | |proposal | | | | | | +----------------+---------------+----------------+-------------- --+ | | CS = k | | | | | | WS = i | legal | legal | not allowed | | |(or unspecified)| | | | +---------+----------------+---------------+----------------+---- ------------+ | Legend | | CS: means CheckpointSize | | WS: means WindowSize | | i, j, k, m, and n: are integer values with the following relations: | | 0 m k < n (values assigned to CS) | | 0 < j i (values assigned to WS) | | For unspecified parameters, the default applies. In this 48 Part 7: 1984 Message Handling Systems December 1993 (Stable) case, the | | numeric relations apply, that is, the default values substitutefor | | the unspecified integer. | +---------------------------------------------------------------- ------------+ 5.4.4 RTS protocol limitations The RTS Protocol Limitations for this profile are listed in table 13. 49 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 13 - RTS protocol elements +---------------------------------------------------------------- ------------+ |Element Class Restriction | +---------------------------------------------------------------- ------------+ | | |PConnect M | | DataTransferSyntax M Value = 0. | |pUserData M | | checkpointSize H | | windowSize H | | dialogueMode H | | ConnectionData M | | applicationProtocol G Value = 1. | | H Value = 8883. | | ConnectionData | | open G | | recover G | | | | open | | RTS user data G | | | | recover | | SessionConnectionIdentifier G | | | |RTS user data | 50 Part 7: 1984 Message Handling Systems December 1993 (Stable) | mTAName G Maximum length 32 characters | | graphic subset of IA5 only. | | password G Maximum length 64 octets | | graphic subset of IA5 only. | | < null RTS User Data > G Generated if other validation | | methods are used. | | | |SessionConnectionIdentifier | | CallingSSUserReference M Maximum length 64 octets including | | encoding = 62 octets of T.61. | | CommonReference M | | AdditionalReferenceInformation H Maximum length 4 octets including | | encoding = 2 octets of T.61. | | | |PAccept G | | DataTransferSyntax M Value = 0. | | pUserData M | | checkpointSize H | | windowSize H | | ConnectionData M | +---------------------------------------------------------------- ------------+ 51 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 13 - RTS protocol elements (concluded) +------------------------------------------------------------------------ -----+ |Element Class Restriction | +------------------------------------------------------------------------ -----+ | | |PRefuse G | | RefuseReason M | | | |SS User Data G See Note | | (in S-TOKEN-PLEASE) | | | |AbortInformation G | | (in S-U-ABORT) | | AbortReason H | | reflectedParameter X Restricted to 8 bits. | | | | End of Definitions | +---------------------------------------------------------------- ------------+ | Note - Generated if supplied by the RTS-user. The RTS use may specify a | | priority in the TURN-PLEASE primitive, and if so, it is carried as the | | SS-User-Data in S-TOKEN-PLEASE. | +---------------------------------------------------------------- ------------+ 52 Part 7: 1984 Message Handling Systems December 1993 (Stable) 5.5 Use of session services The session requirements and use of session are covered in part 5 of this document. 5.6 Data transfer syntax This clause defines Presentation Transfer Syntax and notation rules applicable to these agreements. Implementations must conform EXACTLY as specified in X.409 with no further restrictions. Annex C defines rendition of IA5 Text and T61 characters. 6 PRMD to ADMD and ADMD to ADMD 6.1 Introduction This clause defines the implementation agreements that apply to the interface between two management domains when at least one is an ADMD. A message arriving at an ADMD has either no recipient within that domain or one or more recipients within that domain. In the former case, the ADMD serves as a relay between two or more domains and the actions required of that ADMD are independent of the nature (PRMD or ADMD) of the domains. In the latter case, the ADMD is responsible for delivering messages to the proper recipient(s) within its jurisdiction, and may also be responsible for relaying the message. Given the two roles for an ADMD, this clause describes two distinct sets of functional requirements for an ADMD. The first is the relaying requirement that is needed to provide PRMD and other ADMD interworking. The second is analogous to the PRMD's support to its customers through the integrated UAs. These are distinct functional differences. The services provided to the UAs of an ADMD are independent of the requirement that an ADMD provide a function for interworking with any type of Management Domain (MD). Figure 5 illustrates the two roles played by an ADMD. This clause is presented in the form of deviations from the agreements applicable to PRMD-to-PRMD (sec. 5). Unless explicitly noted in the remainder of this clause, all of the specifications for PRMD to PRMD apply to PRMD to ADMD and ADMD to ADMD. 53 Part 7: 1984 Message Handling Systems December 1993 (Stable) +---------------------------------------------------------------- ------------+ | | | +-------------------+ +-------------------+ | | | PRMD or ADMD | | ADMD | | | | +----------+ <--|-------------P2-----------------|--> +---------+ | | | | | IPM - UA | | | |IPM - UA | | | | | +----------+ <--|-------------P1-----------------|--> +---------+ | | | | | MTA | | | | MTA | | | | | +----------+ | | +---------+ | | | +-------------------+ +-------------------+ | | | | (a) | | | +---------------------------------------------------------------- ------------+ | | | +-------------------+ +-------------------+ | | | PRMD or ADMD | | PRMD or ADMD | | | | +----------+ | | +----------+ | | | | | IPM - UA | <--|-------------P2-----------------|-> | IPM - UA | | | | | +----------+ | | +----------+ | | | | | MTA | | | | MTA | | | | | +----------+ | | +----------+ | | | +-------------------+ +-------------------+ | | | | | | | 54 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | | | | | | P1 P1 | | | | | | | +------------------+ | | | | | ADMD | | | | --------------->| +----+ |<---------------- | | | | MTA| | | | | +----+ | | | +------------------+ | | | | (b) | | | +---------------------------------------------------------------- ------------+ Figure 5 - An ADMD May (b) or May Not (a) Serve as a Relay. 6.2 Additional ADMD functionality The following defines the additional ADMD specific functionality required over and above that specified in the PRMD clause. 6.2.1 Relay responsibilities of an ADMD ADMDs will relay all content types (not just P2) unchanged in the absence of a request for conversion. 6.2.2 P1 protocol classification changes Table 14 describes the changes to the PRMD P1 Protocol classifications required for a delivering Administration domain (with respect to the original message; this means the domain which originates the delivery reports). 55 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 14 - P1 protocol classification changes for a delivering ADMD +---------------------------------------------------------------- -----------+ | Protocol Elements Class | +---------------------------------------------------------------- -----------+ | DeliveredInfo | | typeOfUA H | | | | ReportedRecipientInfo | | SupplementaryInformation H See Note 1. | | | | GlobalDomainIdentifier | | PrivateDomainIdentifier H | | | | For relaying Administration domains, the classifications are all "X" | | | | For originating Administration domains, these are all "NOT APPLICABLE." | +---------------------------------------------------------------- -----------+ | Notes | | 1 Domains providing access to TELEX/TELETEX recipients, whether | | directly or indirectly as a result of bilateral agreements | | between domains, must ensure that this information, when | | present, is accessible by the recipient of the delivery report. | +---------------------------------------------------------------- -----------+ 56 Part 7: 1984 Message Handling Systems December 1993 (Stable) 6.2.3 O/R Names O/R Names shall consist of: a) CountryName, b) AdministrationDomainName. as well as one or more of the following: a) PrivateDomainName, b) PersonalName, c) OrganizationName, d) OrganizationalUnit, e) UniqueUAIdentifier, f) X121Address. g) DomainDefinedAttributeList. (An implementation may accept or reject an OR Name that only contains country, ADMD, and DDA list.) NOTE - The destination PrivateDomainName or OrganizationName must be present if destined for a PRMD. The ADMD relaying the message to that destination PRMD requires this element. 6.2.4 P1 ADMD name Management Domains (MDs) must specify in the ADMD name field of the O/R Name StandardAttributeList in P1, the name of the Administration domain: a) to which the message is being sent (in recipient names) b) from which the message originated (in the originator name). 6.2.5 Interworking with integrated UAs If the message originates at a UA owned by an ADMD, or is delivered to such a UA, the O/R Name follows the same Form 1 Variant 1 constraints as the base specifications; except that the ADMD name is the name of the ADMD that owns the UA and instead of 57 Part 7: 1984 Message Handling Systems December 1993 (Stable) supplying a PRMD Name, one (or more) of the following must be provided: a) OrganizationName, b) OrganizationalUnit, c) PersonalName. d) DomainDefinedAttributeList. (An implementation may accept or reject an OR Name that only contains country, ADMD, and DDA list.) 6.3 Differences with other profiles 6.3.1 TTC profile There are no outstanding issues regarding interworking between TTC-conformant systems and NIST-conformant systems with the exception of the number of recipients and the supported MPDU sizes. The ExtensionIdentifier field may contain a maximum value of 32K-1; however, according to the current TTC profile, if a message with more than 256 recipients is received, some TTC-conformant domain may generate a nondelivery notification. This also applies to the ReportedRecipientInfo in a delivery report. Further, a TTC MTA is required to handle an MPDU size of at least 32KB. The NIST required MPDU size is 2MB as covered in clause 5.3.3. Other differences are shown in annex E. TTC is currently based on Version 4 of the Implementor's Guide. 6.3.2 CEPT profile See annex E. 6.4 Connection of PRMDs to multiple ADMDs Given that Management Domain names (both PRMD and ADMD) shall be unique within the United States, then when an ADMD is presented a message for transfer from a PRMD, it will accept O/R Names (both originator and recipient) which have an AdministrationDomainName field value different than the Administration's name. "Accept" implies the attempt to route/deliver the message shall be made, as appropriate, based upon the knowledge that MD names are unique. 58 Part 7: 1984 Message Handling Systems December 1993 (Stable) Whether this functionality is required by an Administration for conformance to this agreement is for further study. If a PRMD is connected to two or more ADMDs which are not effectively connected (either directly or via a third ADMD), full X.400 functionality shall not be available. Problems occur especially in the areas of: a) Naming, b) Routing, c) Replying. It should be noted that a single PRMD that is connected to more than one ADMD can be represented by more than one combination of country-name, ADMD-name, and PRMD name. For example, it may occur that the PRMD-name for a particular PRMD may take different values, depending on the ADMD-name. Implementors should be aware of the consequences of these possibilities on routing. 6.5 Connection of an ADMD to a routing PRMD It is possible for a collection of interconnected private domains to establish one domain as the "gateway" to an ADMD, and hence to the world. If an ADMD is connected to such a gateway PRMD, the individual private domains shall be registered with the Administration. Administrations need not support such connections. Note also that upon receipt by the ADMD of a message originating somewhere within the PRMD collection, that the TraceInformation may contain more than one element. The X.400 Recommendations specify that an ADMD should not attempt to relay a message destined for another ADMD through a PRMD, thus an ADMD should ensure that messages destined for another ADMD are not relayed through a PRMD. It should be noted, however, that a relaying PRMD will relay any such message it receives. 59 Part 7: 1984 Message Handling Systems December 1993 (Stable) 6.6 Management domain names All Management Domain Names (both Private and Administration) shall be unique within the U.S. A central naming authority shall be established to register domain names. 6.7 Envelope validation errors For validation errors, a non-delivery notice shall be generated (if possible) with reason code of "unableToTransfer" and diagnostic code of "invalidParameters" (unless specified otherwise). ADMDs will validate P1 Envelopes in the following areas: a) The X.409 syntax of all elements should be checked. b) The pragmatic constraint limits (lengths of fields and number of occurrences of fields) should be checked. c) Semantic validation of the following elements should be done: 1) originator O/R Name, 2) recipient O/R Name in the RecipientInfo, 3) Priority. d) Only recipient Names with the responsibility flag set should be validated. The validation of O/R names is defined in 8.3.3; the validation of priority is defined in 8.3.7.1. e) MPDU Identifier Validation 1) Validation of the GlobalDomainIdentifier component of the MPDU Identifier is performed upon reception of a message (i.e., as a result of a TRANSFER.Indication). 2) The country name should be known to the validating domain, and depending on the country name, validation of the ADMD name may also be possible. 3) Additional validation of the GlobalDomainIdentifier is performed against the corresponding first entry in the TraceInformation. If inconsistencies are found 60 Part 7: 1984 Message Handling Systems December 1993 (Stable) during the comparison, a non-delivery notice with the above defined reason and diagnostic codes is generated. 4) A request will be generated to the CCITT for a more meaningful diagnostic code (such as "InconsistentMPDUIdentifier"). 6.8 Quality of service 6.8.1 Domain availability 6.8.1.1 ADMD availability The goal is to provide 24 hour per day availability. Note that there will be periods of time when an ADMD may be unavailable due to maintenance windows in its supporting network or in an MTA within the domain. 6.8.1.2 PRMD availability Although the goal of PRMD availability is also 24 hours per day, business reasons are likely to dictate some different level of availability. ADMDs shall require a profile from the PRMD that indicates its schedule of regular availability to the ADMD. 6.8.2 Delivery times In the absence of standardized quality of service parameters, the following are agreed to. When standardized parameters from CCITT Study Group I become available, they shall be adopted. a) In table 15 the delivery time targets are established. b) The interval(s) between retries and the number of retry attempts that an ADMD uses in attempting delivery to a PRMD or integrated UA, will be locally determined domain parameters. However, the total elapsed times after which delivery attempts will be stopped are shown in table 16. This implies that, after these times, a Non-Delivery Notice will be generated. c) An Administration shall continue to attempt delivery until the forced nondelivery time, even if the recipient domain has scheduled an unavailability window. 61 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 15 - Delivery time targets +----------------------------+-------------------------------+ | Delivery Class | 95% Delivered Before | +----------------------------+-------------------------------+ | Urgent | 3/4 hour | | Normal | 4 hours | | Non-Urgent | 24 hours | +----------------------------+-------------------------------+ Table 16 - Forced nondelivery times +----------------------------+----------------------------------- + | Delivery Class | NonDelivery Forced After | +----------------------------+----------------------------------- + | Urgent | 4 hours | | Normal | 24 hours | | Non-Urgent | 36 hours | +----------------------------+----------------------------------- + NOTE - Both tables apply to the period between acceptance by the originating MTA in the originating Administration domain to the time of delivery in the destination Administration domain. Transit time within PRMDs is NOT included in the above times. 6.9 Billing information All aspects relating to billing, charging, tariffs, settlement, and in particular to the use of the billingInformation field in the delivery report, is subject to bilateral agreement, and shall not be addressed in these implementation agreements. No ADMD shall require a PRMD to supply or process billing information. 62 Part 7: 1984 Message Handling Systems December 1993 (Stable) 6.10 Transparency No P1 extensions, other than the MOTIS extensions are to be allowed (Reference A/3211). Should an ADMD receive a message containing P1 extensions, it shall generate a non-delivery notice (if possible) with reason code of unableToTransfer and diagnostic code of invalidParameters. If MOTIS elements are present, a relaying MTA can optionally: a) Relay the message. If the MTA does relay, it must not drop any of the protocol elements. b) Non-Deliver the message. A receiving MTA can optionally: a) Deliver the message b) Non-Deliver the message. The CCITT has been requested to establish a more meaningful diagnostic code (such as protocolError) for this occurrence. Such a code has now been provided in the Implementors Guide. P2 extensions shall be relayed transparently by ADMDs. 6.11 RTS password management RTS password management shall be a local matter. This includes: a) password length b) frequency of changes c) exchange of passwords with communicating partners d) loading passwords ( i.e., the timing of password changes with respect to active associations). 63 Part 7: 1984 Message Handling Systems December 1993 (Stable) 6.12 For further study Issues requiring further study are: a) Intra-Domain Routing b) Multi-Vendor Domains 7 Inter and intra PRMD connections 7.1 Introduction This clause is limited in scope to issues arising from the indirect connection of a PRMD to another PRMD or to an ADMD, and to the interconnection of MTAs to form inter-PRMD connections. Indirect means that the connection is made via a relaying PRMD. The X.400 Recommendations describe the way that a PRMD connects to a ADMD and the way that an ADMD connects to another ADMD. The Recommendations do not, however, describe the way that a PRMD connects indirectly to an ADMD or another PRMD, nor do they describe the way that MTAs are connected within a PRMD. These configurations (shown in figures 6 and 7) are useful, for example, in connecting equipment from different vendors at a single customer site. The P1 protocol and its related services for both inter and intra PRMD connections are addressed in this clause. In addition, a method for routing within a PRMD is given. It is recognized that uniform methods for Administration, maintenance, and quality of service should be developed for such configurations, and this work is for further study. This clause describes the minimum that must be provided in order to implement a relaying PRMD and a MTA within a PRMD. This clause is presented in the form of deviations from agreements applicable to PRMD to PRMD connection (sec. 5). That is, unless specifically noted in the remainder of this clause, the agreements in clause 5 apply to both relaying PRMDs and MTAs within a PRMD. It should be noted that the comments regarding ORNames in clause 6.5 also apply to this clause. 64 Part 7: 1984 Message Handling Systems December 1993 (Stable) 7.2 The relaying PRMD A PRMD that has the capability of relaying messages to another PRMD is called a relaying PRMD. A PRMD implementation need not claim to be a relaying PRMD. A PRMD implementation which does claim to be a relaying PRMD must follow the implementation agreements in this clause. 7.2.1 Relay responsibilities of a PRMD The responsibilities of a relaying PRMD are the same as those of an ADMD (as specified in secs. 6.8 and 6.2.1). In addition, the PRMD will simply deliver messages routed to it from an ADMD, even if this results in routing a message from the ADMD to the PRMD to another ADMD. 7.2.2 Interaction with an ADMD In order for an ADMD to route a message to ADMD A via ADMD B, it must know that A is reachable through B. Similarly, in order for any MD to route a message to PRMD A via a relaying PRMD B, it must know that A is reachable through B (see figure 8). +---------------------------------------------------------+ | +--------+ | | | ADMD | | | +---+----+ | | +--------+ +---+----+ +--------+ | | | PRMD A +-----------+ PRMD B +------------+ PRMD C | | | +--------+ +--------+ +--------+ | | Relay | +---------------------------------------------------------+ Figure 6 - Relaying PRMD. 65 Part 7: 1984 Message Handling Systems December 1993 (Stable) +---------------------------------------------------------------+ | | | +---------------------------------------------+ | | | PRMD | | | | +------+ +------+ | | | | |MTA A | | MTA D| | | | | +--+---+ +--+---+ | | | | | | | +-------+ | | | | | | | ADMD | | | | +--+---+ +--+---+ | | | | | | |MTA B +---------------+ MTA C+---+---+ or | | | | +------+ +------+ | | | | | | | | PRMD | | | +---------------------------------------------+ +-------+ | | | +---------------------------------------------------------------+ Figure 7 - Intra PRMD connections. NOTES 1 Clause 6.6 specifies that ADMDs are not required to connect to a relaying PRMD, but they are not precluded from doing so. 2 TraceInformation may have more than one sequence on submission of a message by a relaying PRMD to an ADMD. +----------------------------------------------------------+ | | | +-------+ | | | MD D | | | +---+---+ | | +-----+---------+ | | | relay | +----------+ +--------+ | | | MD C with |-------+ relay +--------+ MD A | | | | a message | | MD B | +--------+ | | | for A | +----------+ | | +---------------+ | | | +----------------------------------------------------------+ Figure 8 - MD C must know of A to route the message. 66 Part 7: 1984 Message Handling Systems December 1993 (Stable) 7.3 Intra PRMD connections A PRMD is composed of MTAs which cooperate to perform the functions expected of a domain. An MTA implementation need not claim to follow the implementation agreements of this clause. 7.3.1 Relay responsibilities of an MTA The relaying responsibilities of an MTA are the same as those of an ADMD (as specified in 6.8 and 6.2.1) with one exception: loop suppression within the domain is done using the MOTIS InternalTraceInfo protocol element. The MTA must validate the InternalTraceInfo (see 8.3.5 for details on validation). In addition, the PRMD will simply deliver messages routed to it from an ADMD, even if this results in routing a message from the ADMD to the PRMD to another ADMD (please see 6.6). 7.3.2 Loop suppression within a PRMD The only mechanism defined in the X.400 Recommendations for suppressing loops is TraceInformation, which is added on a per domain basis to detect and suppress loops among domains. Loops among MTAs within a domain need to be detected and suppressed. This implies that each MTA must add trace information that is meaningful within the domain. The MOTIS solution of adding InternalTraceInfo to the P1 Envelope of a message was adopted. The definition of InternalTraceInfo is given in figure 9. The InternalTraceInfo is added by each MTA within a PRMD to handle a message, and it is examined in the same way as TraceInformation to detect and suppress loops. +---------------------------------------------------------------- ------------+ | InternalTraceInfo ::= [APPLICATION 30] IMPLICIT SEQUENCE OF SEQUENCE { | | MTAName, | | MTASuppliedInfo } | | | | MTAName ::= PrintableString | +---------------------------------------------------------------- ------------+ Figure 9 - Definition of InternalTraceInfo. 67 Part 7: 1984 Message Handling Systems December 1993 (Stable) If the MTAName and password of X.411 are used for validation, then it is recommended that the MTAName used for validation also be used in the InternalTraceInfo. However, there is a complication: in X.411, MTAName is an IA5String, and the MTAname defined by MOTIS is a PrintableString. Efforts will be made to change the MOTIS definition from PrintableString to IA5String. Three actions are defined in MTASuppliedInfo: relayed, rerouted, and recipientReassignment as shown in figure 10. The recipientReassignment action is not supported in these agreements. The ability to generate it is not required, and if it is present on an incoming message, the action field will be ignored. +---------------------------------------------------------------+ | MTASuppliedInfo ::= SET { | | arrival [0] IMPLICIT Time, | | deferred [1] IMPLICIT Time OPTIONAL, | | action [2] IMPLICIT INTEGER { | | relayed (0), | | rerouted (1), | | recipientReassignment (2) } | | previous MTAName OPTIONAL } | +---------------------------------------------------------------+ Figure 10 - Defined actions in MTASuppliedInfo. 7.3.3 Routing within a PRMD Routing within a PRMD is complicated by the lack of a directory standard. In particular, it constrains intra-domain routing decisions to be based on some combination of the intra-domain attributes of the O/R Name, Organization Name Organizational Units, and Personal Name. In order to enhance interworking and to reduce the difficulty of configuring intra-domain connections, it is useful to restrict the ways in which these may be used in making routing decisions. However, it is recognized that vendors may wish to provide MTAs with varying degrees of routing capability within a PRMD as a temporary expedient until appropriate standards for automated construction of directories and routing tables are available. This clause assigns class numbers to certain levels of routing capability and discusses the consequences of using MTAs which fall into each class. The classification scheme will allow some diversity in allocating O/R Name space and in configuring intra-domain routes. When other methods are recommended by standards bodies, the 68 Part 7: 1984 Message Handling Systems December 1993 (Stable) classification scheme described here will become obsolete. Large-scale, multi-vendor PRMDs may not be practical in the absence of standardized methods. 7.3.3.1 Class designations When it is clear that a message is to be delivered within a domain, the Country Name, ADMD Name, and PRMD Name have already served their purpose in determining the next MTA in the route to the recipient. The remaining fields that might be used on making routing decisions within the PRMD are the Organization Name, Organizational Units, and Personal Name. MTAs are classified by their ability to discriminate between O/R names when making routing decisions within a PRMD. Conformant MTAs will be classified as shown in table 17. Table 17 - Conformant MTA classifications +---------------------------------------------------------------- + | Class 1 Class 2 Class 3 | +---------------------------------------------------------------- + | Organization Name H H H | | SEQUENCE OF Organizational Unit X H H | | Personal Name X X H | +---------------------------------------------------------------- + An "H" means that the MTA must be able to base its intra-domain routing decisions on the given component of the O/R Name. In particular, both Class 2 and Class 3 MTAs must be able to discriminate on all the members in a supplied sequence of OrganizationalUnits. A Class 3 MTA must be able to discriminate on all of the elements in a PersonalName. An "X" means that the MTA need not have the ability to discriminate on the given component. There is a hierarchy in support of components. The ability to discriminate on a given component does not imply the requirement to do so: e.g., a Class 3 MTA is not required to have tables for every PersonalName in the domain. Equally, an MTA which can discriminate on OrganizationalUnits to make routing decisions 69 Part 7: 1984 Message Handling Systems December 1993 (Stable) need not always use the full sequence in an O/R Name if a partial sequence provides enough information. The above classifications only apply to routing decisions in selecting a next hop within a domain. All MTAs are entitled to examine the full O/R Name when identifying their own directly served UAs. The routing table of a Class 1 MTA will be relatively small, because intra-domain routing decisions are based solely on OrganizationName. The routing table of a Class 2 MTA may be substantially larger and more complex because of its ability to discriminate on OrganizationalUnits as well as OrganizationName to make routing decisions. The routing table of a Class 3 MTA may be larger still, because its use of the components of PersonalName in addition to the other information. 7.3.3.2 Specification of MTA classes If an MTA implementation claims to follow the implementation agreements, it must be either a Class 1, Class 2, or a Class 3 MTA. The class of an MTA implementation should be specified so that PRMD administrators can choose equipment properly. 7.3.3.3 Consequences of using certain classes of MTAs Definition: An MTA which accepts submission requests and furnishes delivery indications to a UA is said to "directly serve" the UA. The presence in a domain of an MTA acting as a Class 1 or Class 2 MTA imposes administrative restrictions on the assignment of O/R Names to UAs and in the configuration of routes within that domain. A Class 1 MTA may directly serve UAs from several OrganizationNames. However, if a Class 1 MTA directly serves a UA with a given OrganizationName, no other MTA in the domain may directly serve a user with the same OrganizationName. This means that if all MTAs in a domain are Class 1, then all UAs with a given OrganizationName must be assigned to the same MTA. A Class 2 MTA may directly serve UAs from any combination of OrganizationName and sequence of OrganizationalUnits. However, if a Class 2 MTA directly serves a UA with a given combination, no other MTA in the domain may directly serve a user with the same combination. This means that if all MTAs in a domain are Class 2, 70 Part 7: 1984 Message Handling Systems December 1993 (Stable) then all UAs with a given OrganizationName and sequence of OrganizationalUnits must be assigned to the same MTA. A domain consisting entirely of Class 3 MTAs is free of all the above restrictions. If Class 1 or Class 2 MTAs are used to perform relaying within a PRMD containing MTAs of other classes, care must be exercised in determining the topology of the domain to avoid leaving certain UAs inacessible from certain MTAs within the domain. The example below shows one of the configurations that should be avoided. The example is intended to stimulate careful examination of the relationship between network and organizational topologies. +---------------------------------------------------------------- ----+ | | | +---------------+ +----------+ +---------------+ | | | MTA A | | MTA B | | MTA C | | | | serving +-- ... --+ +-- ... --+ serving | | | |Organization X | | (Class 1)| |Organization X | | | +---------------+ +----------+ +---------------+ | | | +---------------------------------------------------------------- ----+ Figure 11 - Example of a configuration to be avoided. In figure 11, B will route all messages for Organization X to either A or C because B is a Class 1 MTA. The administrator who created this configuration probably wanted B to route some messages for Organization X to A, and some to C. However, B does not have the capability for this because it is only a Class 1 MTA. The configuration in figure 11 can be corrected by replacing B with a Class 2 or Class 3 MTA. 7.3.4 Uniqueness of MPDUIdentifiers within a PRMD When generating an IA5String in an MPDUIdentifier, 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 71 Part 7: 1984 Message Handling Systems December 1993 (Stable) 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 a PRMD 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. 7.4 Service elements and optional user facilities A PRMD made up of MTAs which support varying sets of service elements in addition to those required in these agreements may appear to provide inconsistent service for these elements. For example, if one MTA supports deferred delivery and another MTA does not, then deferred delivery can be used by some, but not all, users in the PRMD. Similarly, if one MTA supports return of contents and another does not, then a user outside of the PRMD will receive returned contents for messages sent to one user, but not for messages sent to another user. Note that this same inconsistency occurs when sending to two PRMDs which support different additional optional elements. 7.5 X.400 protocol definitions This clause describes additions and modifications to clause 5.3 which are required for implementation of a relaying PRMD or an MTA within a PRMD. 7.5.1 Protocol classification The classification scheme given in clause 5.3.1 applies to elements passing from one PRMD to another. For both relaying PRMDs, and MTAs in a PRMD, the same classification scheme will be used, but within a PRMD the classification applies to elements passing from one MTA to another. In addition to the classifications given in clause 5.3.1, a classification of Prohibited has been used. PROHIBITED = P This element shall not be used. Presence of this element is a protocol violation. 72 Part 7: 1984 Message Handling Systems December 1993 (Stable) 7.5.2 P1 protocol elements Table 18 contains protocol elements and their classes. An * signifies that the classification of the protocol element has not changed from table 8. 73 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 18 - P1 protocol elements +---------------------------------------------------------------- ------------+ |Element Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ | | |UMPDUEnvelope | | MPDUIdentifier M* This field needs to be unique | | within a PRMD. See clause | | 7.3.4 for the method of | | ensuring uniqueness. | | | | originator M* It is recommended that all | | components of the originator's | | ORName be included to help ensure | | that reports can be returned. | | | | TraceInformation M* The first MTA in the domain to | | receive the message adds the | | TraceInformation. Subsequent | | MTAs can update the | | TraceInformation in the event of | | conversion or deferred delivery. | | When a message is generated, the | | originating MTA adds the | | TraceInformation. | 74 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | | InternalTraceInfo M/P This element is mandatory for | | envelopes transferred between | | MTAs within a PRMD, and | | prohibited in messages | | transferred outside the domain. | | Elements are always added to the | | end of the sequence. (See Note 1) | | | |InternalTraceInfo M MTANames within a PRMD must be | | MTAName unique. See clause 7.3.4 for | | the method of assuring uniqueness | | Maximum length = 32 characters. | | | | MTASuppliedInfo M | +---------------------------------------------------------------- ------------+ 75 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 18 - P1 protocol elements (continued) +---------------------------------------------------------------- ------------+ |Element Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ | | | | |MTASuppliedInfo | | arrival M | | deferred X This field must be generated by | | MTAs which perform deferred | | delivery. | | | | action M See clause 7.3.2 for | | restrictions on values of this | | field. | | | | previous X This field must be generated by | | MTAs which perform rerouting. | | | |DeliveryReportEnvelope | | TraceInformation M* The first MTA in the domain to | | receive the report adds the | | TraceInformation. When a report | | is generated, the originating MTA | | adds the TraceInformation. | 76 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | | InternalTraceInfo M/P This field is mandatory for | | envelopes transferred between | | MTAs within a PRMD, and | | prohibited in messages | | transferred outside the domain. | | (See Note 1) | |DeliveryReportContent | | intermediate InternalTraceInfo P If it were possible to include | | this field in the delivery report | | content, an audit and confirmed | | report could be provided to | | detect problems within a PRMD. | | Efforts are being made to add | | this field to the MOTIS | | definition. | | | |DeliveredInfo | | typeOFUA R* It is the responsibility of the | | MTA generating the report to | | generate this element. | +---------------------------------------------------------------- ------------+ 77 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table 18 - P1 protocol elements (concluded) +---------------------------------------------------------------- ------------+ |Element Class Restrictions and Comments | +---------------------------------------------------------------- ------------+ | | |ProbeEnvelope | | TraceInformation M* The first MTA in the domain to | | receive the probe adds the | | TraceInformation. When a probe | | is generated, the originating MTA | | adds the TraceInformation. | | | | InternalTraceInfo M/P This field is mandatory for | | envelopes transferred between | | MTAs within a PRMD, and | | prohibited in messages | | transferred outside the domain. | | (See Note 1) | +---------------------------------------------------------------- ------------+ | Notes | | 1 The M classification is only applicable if an implementation is | | claiming conformance according to clause 10.2. | +---------------------------------------------------------------- ------------+ 78 Part 7: 1984 Message Handling Systems December 1993 (Stable) 7.5.3 Reliable Transfer Server (RTS) In the pUserData of PConnect, the value of applicationProtocol should be 1. This value was chosen because the agreements on intra-domain connections are not strictly P1, nor are they MOTIS. Philosophically, it would be good to choose a new application protocol identifier for these agreements, but this introduces too many practical problems. Since these agreements are closer to P1 than to MOTIS, the value of 1 will be used. This will not cause interworking problems between domains, because the only deviation from P1 is the InternalTraceInfo, which will not be present in messages transferred outside of a domain. 8 Error handling This clause describes appropriate actions to be taken upon receipt of protocol elements which are not supported in this profile, malformed MPDUs, unrecognized O/R Name forms, content errors, errors in reports, and unexpected values for protocol elements. 8.1 MPDU encoding The MPDU should have a context-specific tag of 0, 1, or 2. If it does not have one of these tags, it is not possible to figure out who originated the message. Therefore, the way this error is reported is a local matter. 8.2 Contents Once delivery to the UA has occurred, it is not possible to report errors in P2 information to the originator. In addition, it seems unreasonable to insist that the MTA that delivers a message ensure that the P2 content of the message is acceptable. As a result, the handling of content errors is a local matter. 8.3 Envelope This clause describes the handling of errors in message envelopes. Some of the error conditions described below may be detected in a recipient's O/R Name. This may limit the reporting MTA's ability to generate a nondelivery notification that accurately reflects the erroneous O/R Name in the ReportedRecipientInfo. This handling of this situation is a local matter. 79 Part 7: 1984 Message Handling Systems December 1993 (Stable) 8.3.1 Pragmatic constraint violations In all cases of pragmatic constraint violation, a nondelivery report should be generated with a ReasonCode of unableToTransfer, and a DiagnosticCode of pragmaticConstraintViolation. 8.3.2 Protocol violations If all required protocol elements are not present, a nondelivery report with a ReasonCode of unableToTransfer and a DiagnosticCode of protocolViolation should be generated. If a protocol element is expected to be of one type, but is encoded as another, then a nondelivery report with a ReasonCode of unableToTransfer and a DiagnosticCode of invalidParameters should be generated. 8.3.3 O/R Names The domain that has responsibility for delivering a message should also have the responsibility to send the nondelivery notification if the message cannot be delivered. Therefore, each MTA should only validate the O/R Names of recipients with responsibility flags set to TRUE. In addition, a nondelivery notification can only be sent if the originator's O/R Name is valid. If any element in the O/R Name is unrecognized or if the CountryName, AdministrationDomainName, and one of PrivateDomainName and OrganizationName (and, for ADMDs, PersonalName and OrganizationalUnit) are not all present, then a nondelivery report should be generated with a ReasonCode of unableToTransfer, and a DiagnosticCode of unrecognizedORName. If the message can be delivered even though the ORName is invalid, delivery is a local matter. Note, however, that if the message is delivered, the invalid ORName might be propagated through the X.400 system (e.g., by forwarding). If the O/R Name has all of the appropriate protocol elements and the message still cannot be delivered to the recipient, the following DiagnosticCodes may appear in the nondelivery report: unrecognizedORName,ambiguousORName,and uaUnavailable. 80 Part 7: 1984 Message Handling Systems December 1993 (Stable) 8.3.4 TraceInformation Since non-relaying domains need not do loop suppression, domains with responsibility for delivering the message need not be concerned about the semantics of the TraceInformation, that is, arrival time and converted EncodedInformationTypes can be provided to the UA without inspection by the MTAs of the domain as long as the TraceInformation is properly encoded according to X.409. When a message is accepted for relay, the relaying domain must check that a TraceInformation SEQUENCE has been added by the domain that last handled the message. If the appropriate TraceInformation was not added, this should be treated as a protocolViolation (sec. 8.3.2). In addition, the relaying domain must check that the information was added in the sequence defined by the rules for adding TraceInformation in the CCITT X.400 Implementor's Guide. If the sequence is invalid,then a nondelivery report should be generated with a ReasonCode of unableToTransfer and a diagnosticCode of invalidParameters. NOTE - It would be desirable for the CCITT to add a diagnostic code of invalidTraceInformation to allow a more meaningful description of this problem. A request for this new diagnostic code will be submitted. 8.3.5 InternalTraceInfo This clause applies only to MTAs which follow the agreements of clause 7. When a message is accepted for relay from another MTA in the domain, the relaying MTA must check that an InternalTraceInfo SEQUENCE has been added by the MTA that last handled the message. If the appropriate InternalTraceInfo was not added, this should be treated as a protocolViolation (sec. 8.3.2). In addition, the relaying MTA must check that the information was added in the sequence defined by the rules for adding TraceInformation in the CCITT X.400 Implementor's Guide. If the sequence is invalid, then a nondelivery report should be generated with a ReasonCode of unableToTransfer and a diagnosticCode of invalidParameters. NOTE - It would be desirable for the CCITT to add a diagnostic code of invalidTraceInformation to allow for a 81 Part 7: 1984 Message Handling Systems December 1993 (Stable) more meaningful description of this problem. A request for this new diagnostic code will be submitted. 8.3.6 Unsupported X.400 protocol elements The protocol elements defined in X.400 but unsupported by this profile are: the deferredDelivery and PerDomainBilateralInfo parameters of the UMPDUEnvelope, the ExplicitConversion parameter of RecipientInfo, and the alternateRecipientAllowed and contentReturnRequest bits of the PerMessageFlag. Appropriate actions are described below for domains that do not support the protocol elements. 8.3.6.1 deferredDelivery The delivering domain shall do one of the following: a) deliver at once, b) hold for deferred delivery, c) return a nondelivery notification with a ReasonCode of unableToTransfer and a DiagnosticCode of noBilateralAgreement. 8.3.6.2 PerDomainBilateralInfo If a delivering domain receives this element, the element can be ignored. 8.3.6.3 ExplicitConversion If ExplicitConversion is requested the message should be delivered if possible. That is, if the UA is registered to accept the EncodedInformationTypes of the message, then the message should be delivered even though the requested conversion could not be performed along the route. If delivery is not possible, then a nondelivery report should be generated with a ReasonCode of conversionNotPerformed with no DiagnosticCode. 8.3.6.4 alternateRecipientAllowed If a delivering domain receives this element the element can be ignored. 82 Part 7: 1984 Message Handling Systems December 1993 (Stable) 8.3.6.5 contentReturnRequest If a delivering domain receives this element, the element can be ignored. 8.3.7 Unexpected values for INTEGER protocol elements There are three INTEGERs in the P1 Envelope. Appropriate actions are described below for domains receiving unexpected values for Priority, ExplicitConversion, and ContentType. 8.3.7.1 Priority Additional values for Priority have been suggested by at least one group of implementors as upward compatible changes to the X.400 Recommendations. Therefore, if a PRMD receives an unexpected value for Priority, and this value is greater than one byte in length, a nondelivery report should be generated with a ReasonCode of unableToTransfer and DiagnosticCode of invalidParameters. If the value is less than or equal to one byte, the PRMD can either generate a nondelivery report as previously specified or interpret the Priority as normal and deliver or relay the message. 8.3.7.2 ExplicitConversion When an unexpected value is received for ExplicitConversion, it should be handled as in clause 8.3.6.3. 8.3.7.3 ContentType If the ContentType is not supported by the delivering MTA, then a nondelivery report should be generated with a ReasonCode of unableToTransfer, and a DiagnosticCode of contentTypeNotSupported. 8.3.8 Additional elements In the absence of multilateral agreements to the contrary, receipt of privately tagged elements and protocol elements in addition to those defined in X.400 will result in a nondelivery report with a ReasonCode of unableToTransfer and a DiagnosticCode of invalidParameters. 83 Part 7: 1984 Message Handling Systems December 1993 (Stable) The exceptions to this are the MOTIS elements. The treatment of MPDU's containing these MOTIS extensions is described in clause 6.11. 8.4 Reports There is no mechanism for returning a delivery or status report due to errors in the report itself. Therefore the handling of errors in reports is a local matter. 9 MHS use of Directory Services 9.1 Directory service elements Recommendation X.400 recognizes the need of MHS users for a number of directory service elements. Directory service elements are intended to assist users and their UAs in obtaining information to be used in submitting messages for delivery by the MTS. The MTS may also use directory service elements to obtain information to be used in routing messages. Some functional requirements of directories have been identified and are listed below: a) Verify the existence of an O/R name. b) Return the O/R address that corresponds to the O/R name presented. c) Determine whether the O/R name presented denotes a user or a distribution list. d) Return a list of the members of a distribution list. e) When given a partial name, return a list of O/R name possibilities. f) Allow users to scan directory entries. g) Allow users to scan directory entries selectively. h) Return the capabilities of the entity referred to by the O/R name. i) Provide maintenance functions to keep the directory up-to-date. 84 Part 7: 1984 Message Handling Systems December 1993 (Stable) In addition to functionality, a number of operational aspects must be considered. These include user-friendliness, flexibility, availability, expendability, and reliability. Currently, these aspects of directory service elements and procedures are under study by both the CCITT and the ISO. Both organizations are committed to the development of a single Directory Service specification for use by MHS and all other OSI based applications. Given the incomplete nature of the ongoing activities within the CCITT and the ISO, no implementation details will be provided now for MHS use of Directory Services. Implementation agreements for MHS Use of Directory Services will be issued when current activities within the CCITT and the ISO are stable. 9.2 Use of names and addresses It is recognized that these agreements enable a wide variety of naming and addressing attributes (see sec. 5.3.5 ORName Protocol Elements) wherein each PRMD may adopt particular routing schemes within its domain. With the exception of the intra-domain connection agreements: a) These agreements make no attempt to recommend a standard practice for electronic mail addressing. Inter-PRMD addressing may be secured according to practices outside the scope of these agreements, such as: a) manual directories b) on-line directories c) ORName address specifications d) ORName address translation. Further, each PRMD may adopt naming and addressing schemes wherein the user view may take a form entirely different from the attributes reflected in table 9. And, each PRMD may have one user view for the originator form and another for the recipient form, and perhaps other forms of user addressing. In some cases (e.g., receipt notification) these user forms must be preserved within the constraints of these implementation agreements. However, mapping between one PRMD user form to another PRMD user form, via the X.400 ORName attributes of these agreements, is outside the 85 Part 7: 1984 Message Handling Systems December 1993 (Stable) scope of these agreements. 10 Conformance 10.1 Introduction In order to ensure that products conform to these implementation agreements, it is necessary to define the types and degrees of conformance testing that products must pass before they may be classified as conformant. This clause defines the conformance requirements and provides guidelines for the interpretation of the results from this type of testing. This clause is incomplete and will be enhanced in future versions of this Agreement. Later versions will reflect the problems of conformance testing and will outline specific practices and recommendations to aid the development of conformance tests and procedures. 10.2 Definition of conformance For this clause, the term conformance is defined by the following: a) The tests indicated for this clause are intended to establish a high degree of confidence in a statement that the implementation under test (IUT) conforms (or does not conform) to the agreements of this clause. b) Conformance to a service element means that the information associated with the service element is made accessible to the user (person or process) whenever this agreement says that this information should be available. Accessible means that information must be provided describing how a user (person or process): 1) causes appropriate information to be displayed, or 2) causes appropriate information to be obtained. c) Conformance to P1, P2, and RTS as part of an X.400 OSI application requires that only the external behavior of that OSI system adheres to the relevant protocol standards. In order to achieve conformance to this clause, it is not required that the inter-layer interfaces be available for testing purposes. 86 Part 7: 1984 Message Handling Systems December 1993 (Stable) d) Conformance to the protocols requires: 1) that MPDUs correspond to instances of syntactically correct data units, 2) MPDUs in which the data present in the fields and the presence (or absence) of those fields is valid in type and semantics as defined in X.400, as qualified by this profile, 3) correct sequences of protocol data units in responses (resulting from protocol procedures). e) Statements regarding the conformance of any one implementation to this profile are not complete unless a Protocol Implementation Conformance Statement (PICS) is supplied. f) The term "Implementation Under Test" (IUT) is interchangeable with the term "system" in the definition of conformance, and may refer to: 1) a domain, which may be one or more MTA's with co-located or remote UA's, 2) a single instance of an MTA and co-located UA with X.400 (P1, P2, RTS and session) software, 3) a relaying product with P1, RTS and session software, 4) a gateway product. g) Claiming Implementation Conformance 1) An implementation which claims to be conformant as an ADMD must adhere to the agreements in clauses 5 and 6. 2) An implementation which claims to be conformant as a PRMD must adhere to the agreements in clause 5. 3) An implementation which claims to be conformant as a relaying PRMD must adhere to the agreements in clause 5 and the appropriate clauses of 7. 4) An implementation which claims to be conformant to the intra-domain connection agreements must adhere to the agreements in clause 5 and the appropriate clauses 87 Part 7: 1984 Message Handling Systems December 1993 (Stable) of 7. 10.3 Conformance requirements 10.3.1 Introduction Conformance to this specification requires that all the services listed as supported in clauses 5, 6, and if appropriate, 7 of these agreements are supported in the manner defined, in either the CCITT X.400 Recommendations or these agreements. It is not necessary to implement the recommended practices of annex B, in order to conform to these agreements. It is the intention to adopt, where and when appropriate the testing methodology and/or the abstract test scenarios currently being defined by the CCITT X.400 Conformance Group. However, it is recognized that formal CCITT Recommendations relating to X.400 Conformance Testing will not be available until 1988. It is also recognized that aspects of these agreements are outside the scope of the CCITT, and that other organizations will have to provide conformance tests in these cases. 10.3.2 Initial conformance This clause is intended to provide guidelines to vendors who envisage having X.400 products available prior to any formal mechanism, or "Conformance Test Center" being made accessible that would allow for conformance to this product specification to be tested. It is feasible that vendors and carriers will want to enter bilateral test agreements that will allow for initial trials to be carried out for the purposes of testing initial interworking capabilities. It is equally feasible that for the purposes of testing interoperability, only a subset of this specification will initially be tested. NOTE - By claiming conformance to this subset of information the vendor or carrier CANNOT claim conformance to this entire specification. There are two aspects to the requirements, interworking and service, as described in the following clauses. 88 Part 7: 1984 Message Handling Systems December 1993 (Stable) 10.3.2.1 Interworking The interworking requirements for conformance implies that tests be done to check for the syntax and semantics of protocol data elements for a system as defined by the classification scheme of clauses 5.2.1.1 and 7.5.2. For a relay system, the correct protocol elements should be relayed as appropriate. For a recipient system, a message with correct protocol elements must not be rejected where appropriate. 10.3.2.2 Service For information available to the recipients via the IPMessage Heading and Body, the following should be made accessible: a) IPMessage ID - only the PrintableString portion of the IPMessageId needs to be accessible. b) subject, c) primaryRecipients, d) copyRecipients, e) blindcopyRecipients, f) authorizingUsers, g) originator, h) inReplyTo, i) replyToUsers, j) importance, k) sensitivity, l) IA5Text Bodypart. 89 Part 7: 1984 Message Handling Systems December 1993 (Stable) Annex A (normative) Interpretation of X.400 service elements The work on service element definitions is limited to those that are defined as "supported" in clause 5 of this specification. Furthermore it is not the intent of this clause to define how information should be made available or presented to a MHS user, nor is it intended to define how individual vendors should design their products. In addition, statements on conformance to a specific service element and the allocation of error codes that are generated as a result of violations of the service should be defined in the clauses on conformance and errors as part of the main product specification. The main objective is to provide clarification, where required, on the functions of a service element, and in particular what the original intent of the Recommendations were. A.1 Service elements The following Service Elements defined in X.400 have been examined and require further text to be added to their definitions to represent the proposed implementation of these service elements by the X.400 SIG. The service element clarifications are to be taken in the context of this profile. Service elements not referenced in this clause are as defined in X.400. A.2 Probe A PRMD need not generate probes. If a probe is addressed to and received by a PRMD, the PRMD must respond with a Delivery Report as appropriate at the time the probe was processed. 90 Part 7: 1984 Message Handling Systems December 1993 (Stable) A.3 Deferred delivery In the absence of bilateral agreements to the contrary, Deferred Delivery and Deferred Delivery Cancellation are local matters (i.e., confined to the originating domain) and need not be provided. The extension of Deferred Delivery beyond the boundaries of the initiating domain is via bilateral agreement as specified in section 3.4.2.1 of X.411. A.4 Content type indication It is required that both an originating and recipient domain be able to support P2 content type. The ability for domains to be able to exchange content types other than P2 will depend on the existence of bilateral or multi-lateral agreements. A.5 Original encoded information types indication It is required that both an originating and recipient domain be able to support IA5 text. Support for other encoded information types, for the purposes of message transfer between domains, will depend on the existence of bilateral or multi-lateral agreements. The use of the "unspecified" form of encoded information type should only be used when the UMPDU content represents an SR-UAPDU or contains an auto-forwarded IM-UAPDU. The original encoded information type of a message is not meaningful unless a message is converted en route to the recipient. These agreements support only IA5 text, which should not undergo conversion. The original encoded information types should be made accessible to the recipient for upward compatibility with the use of non-IA5 text message body parts. A.6 Registered encoded information types A UMPDU with an "unspecified" value for Original Encoded Information Type shall be delivered to the UA. 91 Part 7: 1984 Message Handling Systems December 1993 (Stable) A.7 Delivery notification The UAContentID may be used by the recipient of the delivery notification for correlation purposes. A.8 Disclosure of other recipients This service is not made available by originating MTAE's to UAE's, but must be supported by relaying and recipient MTAE's. By supporting the disclosure of other recipients the message recipient can be informed of the O/R names of the other recipient(s) of the message, as defined in the P1 envelope, in addition to the O/R Descriptors within the P2 header. These agreements do not support initiation of disclosure of other recipients, but the information associated with it should be made accessible to the recipient for upward compatibility with support for the initiation of this service element. A.9 Typed body As defined in X.400 with the addition of the Private Body Types that are to be supported. At present there is no mechanism provided within X.420 that would allow you to respond to reception of an unsupported body type. Action taken in this situation is a local matter. A.10 Blind copy recipient indication It should be considered that the recipient's UA acts on behalf of the recipient, and therefore may choose to disclose all BCC recipients to each other. Therefore it is the responsibility of the originating domain to submit two or more messages, depending on whether or not each BCC should be disclosed to each other BCC. 92 Part 7: 1984 Message Handling Systems December 1993 (Stable) A.11 Auto forwarded indication A UA may choose not to forward a message that was previously auto-forwarded. In addition there is no requirement for an IPM UA that does not support non-receipt or receipt notification to respond with a non-receipt notification when a message is auto-forwarded. A.12 Primary and copy recipients indication It is required that at least one primary recipient be specified; however, for a forwarded message this need not be present. The recipient UA should be prepared to accept no primary and copy recipients to enable future interworking with Teletex, Fax, etc. A.13 Sensitivity indication A message originator should make no assumptions as to the semantic interpretation by the recipients UA regarding classifications of sensitivity. For example, a personal message may be printed on a shared printer. A.14 Reply request indication In requesting this service an originator may additionally supply a date by which the reply should be sent and a list of the intended recipients of the reply. If no such list is provided then the initiator of the reply sends the reply to the originator of the message and any recipients the reply initiator wishes to include. The replytoUsers and the replyBy date may be specified without any explicit reply being requested. This may be interpreted by the recipient as an implicit reply request. Note that for an auto-forwarded message an explicit or implicit reply request may not be meaningful. A.15 Body part encryption The original encoded information type indication includes the encoded information type(s) of message body parts prior to encryption by the originating domain. The ability for the recipient domain to decode an encrypted body part is a local matter. Successful use of this facility can only be guaranteed if there exists bilateral agreements to support the exchange of encrypted body parts. 93 Part 7: 1984 Message Handling Systems December 1993 (Stable) A.16 Forwarded IP message indication The following use of the original encoded information type in the context of forwarded messages is clarified: a) If forwarding a private message body part the originator of the forwarded message shall set the original encoded information types in the P1 envelope to undefined for that body part. b) The encoded information types of the message being forwarded should be reflected in the new original encoded information types being generated. c) See ammex B on recommended practices for the use of the delivery information as part of Forwarded IP-message. A.17 Multipart body It is the intent of multipart bodies to allow for the useful and meaningful structuring of a message that is constructed using differing body part types. For example, it is not recommended that a message made up of only IA5 text should be represented as a number of IA5 body parts, each one representing a paragraph of text. 94 Part 7: 1984 Message Handling Systems December 1993 (Stable) Annex B (informative) Recommended X.400 practices It is not necessary to follow the recommended practices when claiming conformance to these agreements. B.1 Recommended practices in P2 B.1.1 ORDescriptor Vendors following the OSI Implementors' Workshop guidelines shall, whenever possible, generate the ORName portion of an ORDescriptor in ALL IPM heading fields. B.1.2 ForwardedIPMessage BodyParts ForwardedIPMessage BodyParts should be nested no deeper than eight. There is no restriction on the number of ForwardedIPMessage BodyParts at any given depth. B.1.3 DeliveryInformation It is strongly recommended that DeliveryInformation be supplied in both forwarded and autoforwarded message body parts. DeliveryInformation is useful when a message has multiple forwarded message body parts because without it, the EncodedInformationType(s) of the component forwarded messages cannot be deduced easily. DeliveryInformation is useful for autoforwarded messages because the EncodedInformationType of an autoforwarded message is "unspecified" and the EncodedInformationType(s) of the message cannot be determined easily without it. Absence of the EncodedInformationType(s) makes it difficult for a UA to easily determine whether the message can be rendered. 95 Part 7: 1984 Message Handling Systems December 1993 (Stable) B.2 Recommended practices in RTS B.2.1 S-U-ABORT In the case where S-U-ABORT indicates a temporaryProblem, reestablishment of the session should not be attempted for a "sensible" time period (typically not less than 5 min). In instances where this delay is not required or necessary, report a localSystemProblem. B.2.2 S-U-EXCEPTION-REPORT S-U-EXCEPTION-REPORT reason codes can be interpreted as follows: B.2.2.1 receiving ability jeopardized (value 1) Possible meaning: The receiving RTS knows of an impending system shutdown. B.2.2.2 local ss-User error (value 5) Possible meaning: The receiving RTS needs to resynchronize the session dialogue. B.2.2.3 irrecoverable procedure error (value 6) Possible meaning: The receiving RTS has had to delete a partially received APDU, even though some minor synchronization points have been confirmed. B.2.2.4 non specific error (value 0) Possible meaning: The receiving RTS cannot handle the APDU (for example, because it was too large) and wishes to inform the sending RTS not to try again. B.2.2.5 sequence error (value 3): Possible meaning: The S-ACTIVITY-RESUME request specified a minor synchronization point serial number which does not match the checkpoint data. 96 Part 7: 1984 Message Handling Systems December 1993 (Stable) B.2.3 OSI addressing information For purposes of identifying an MTA during an RTS Open, OSI addressing information should be used. This addressing information is conveyed by lower layer protocols and is reflected by the calling and called SSAP parameters of the S-CONNECT primitives. MTA validation and identification are related, but separate, functions. The mTAName and password protocol elements of the RTS user data should be used for validation, rather that identification, of an MTA. The RTS initiator and responder may independently require each other to supply mTAName and password. The CallingSSUserReference parameter of the S-CONNECT primitives should only have meaning to the entity that encoded it and should not be used to identify an MTA. B.3 Recommended practices for ORName Table 9 stipulates that the StandardAttributeList must contain either PrivateDomainName or OrganizationName. It is recommended that, for both originator and recipients in a private domain, the PrivateDomainName field be used. It is recommended that there should be a DomainDefinedAttribute to be used in addressing UAs in existing mail systems, in order to curtail the proliferation of different types of DomainDefinedAttributes used for the same purpose. The syntax of this DomainDefinedAttribute conforms to the CCITT Pragmatic Constraints, and thus has a maximum value length of 128 octets and a type length of 8 octets, each of type Printable String. Only one occurrence is allowed. This DomainDefinedAttribute has the type name "ID" (in uppercase). It contains the unique identifier of the UA used in addressing within the domain. This DomainDefinedAttribute is to be exclusively used for routing within the destination domain (i.e., once routed to that domain via the mandatory components of the StandardAttributeList); any other components of the StandardAttributeList may be provided. If they conflict delivery is not made. The contents of this parameter need not be validated in the originating domain or any relaying domain, but simply transferred intact to the next MTA or domain. Class 2 and class 3 MTAs in a PRMD should allow administrators to 97 Part 7: 1984 Message Handling Systems December 1993 (Stable) decide the number of OrganizationalUnits that should appear in user names, instead of imposing a software controlled limit which is less than four. This is desirable because when two different vendors impose different limits on the number of OrganizationalUnits in a name, it becomes difficult for the administrator to choose a sensible naming scheme. There are existing mail systems that include a small set of non- Printable String characters in their identifiers. For these systems to communicate with X.400 messaging systems, either for pass-through service or delivery to X.400 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 the ID DDA, which is intended to carry electronic mail identifiers. X.400 User Agents may also wish to perform such conversions. It is recommended that the following symmetrical encoding and decoding algorithm for non-Printable String characters be employed by gateways. The encoding algorithm maps an ID from an ASCII representation to a PrintableString representation. Any non-printable string characters not specified in the table are covered by the category "other" in the table below. The principal conversion table for the mapping is as follows: 98 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table B.1 - 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) | +---------------------------------------------------------------- ------------+ 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, the table and the following algorithm should be used: +-------------------------------------------------------+ | IF current character is in the encoding set THEN | | encode the character according to the table above | | ELSE | | write the current character; | | continue reading; | +-------------------------------------------------------+ To decode a PrintableString representation to an ASCII representation, the table and the following algorithm should be used: 99 Part 7: 1984 Message Handling Systems December 1993 (Stable) +------------------------------------------------------------+ | IF current character is not "(" THEN | | write character | | ELSE | | { | | look ahead appropriate characters; | | IF composite characters are in the above table THEN | | decode per above table | | ELSE | | write current character; | | } | | continue reading; | +------------------------------------------------------------+ Class 2 and class 3 MTAs in a PRMD should allow administrators to decide the number of OrganizationalUnits that should appear in user names, instead of imposing a software controlled limit which is less than four. This is desirable because when two different vendors impose different limits on the number of OrganizationalUnits in a name, it becomes difficult for the administrator to choose a sensible naming scheme. B.4 Postal addressing For domains wishing to support postal (or physical) delivery options, the following interim set of "nationally-defined" domain defined attributes are recommended. The CCITT will define Standard Attributes in support of physical delivery in its 1988 Recommendations; this is only an interim solution. CCITT will also be addressing the services associated with physical delivery. This interim solution does not address the end-to-end service aspects of physical delivery; in particular, the following IPM service elements do not currently extend outside of the X.400 environment: a) alternate Recipient Assignment b) PROBE c) Receipt Notification / Non-Receipt Notifications d) Grade of delivery "Delivery" means passing a message from the MTS to the physical delivery system (PDS), and not to the user (or user agent). The following three DDAs are recommended to be used to specify a 100 Part 7: 1984 Message Handling Systems December 1993 (Stable) postal (or physical) address: CNTRPC encodes the country and postal code for postal delivery. The DDA value is of the form "Country?Postalcode" (for example, "USA?22096"). The country field is optional, the postal code is optional; the separator ("?") is not. If both country and postal code are missing, this DDA should not be specified. PDA1 The country and postal code fields are free-form text. PDA2 These two DDA (signifying Postal Delivery Address strings 1 and 2) form a 256 character free-form postal address. Fields are separated by a question mark ("?"). There is no implied separator between PDA1 and PDA2. The meaning of the fields are defined by each domain supporting the physical delivery interface. PDA1 contains the first 128 characters, PDA2 the next 128 characters. If the PDA string is less than 128 characters, PDA2 is not used. For example, if the domain interprets the PDA fields as lines, the address Mr. John Smith Conway Steel 123 Main Street Reston VA 22096 would be encoded as follows: type = "PDA1" value = "Mr. John Smith?Conway Steel?123 Main Street?Reston VA" CNTRPC = "?22096" B.5 EDI use of X.400 B.5.1 Introduction and scope This is a guideline for EDI data transfer in an X.400 environment conforming to the NIST agreements. These recommended practices outline procedures for use in transferring EDI transactions between trading partner applications in an attempt to facilitate actual X.400 implementation by EDI users. The scope of this guideline is to describe specific recommendations for adopting X.400 as the data transfer mechanism between EDI applications. 101 Part 7: 1984 Message Handling Systems December 1993 (Stable) B.5.2 Model The MHS recommendations can accommodate EDI through the approach illustrated below. Many Message Transfer (MT) service elements defined in the X.400 recommendations are particularly useful to the EDI application. +---------------------------------------------------------------- -------+ | X.400 Message (1 EDI interchange) | | +-------------------------------------+ | | | | | | | +------------------------------+ | | | | | | | | | Envelope ------------------->| P1 Control | | | | | | Information | | | | | +------------------------------+ | | | | | | | | | | | | | | | | +------------------------------+ | | | | | One | | | | Content ------------------->| EDI | | | | | | Interchange | | | | | +------------------------------+ | | | | | | | +-------------------------------------+ | | MHS Message | +-----------------------------------------------------------------------+ 102 Part 7: 1984 Message Handling Systems December 1993 (Stable) This diagram depicts an EDI content (1 EDI interchange) enveloped by the P1 MHS envelope. All the MT Services defined in the X.400 Recommendations may be used for EDI. However, it is not required to support optional or non-essential services to exchange EDI data between EDI users. When an EDI user submits an EDI Trade Document to the EDI User Agent, the EDI UA will submit the EDI content plus P1 envelope to the Message Transfer System (MTS). +---------------------------------------------------------------- -----+ | | | +-----------+ +------------+ +-----------+ | | | | | EDI | | EDI | | | | MTS |<----------->| UA |<------------>| User | | | | | | | | | | | +-----------+ +------------+ +-----------+ | | | +---------------------------------------------------------------- -----+ The EDI UA must support the essential MT Services as defined in these Agreements; for example, as a minimum, to provide default values for services not elected by the EDI user, such as Grade of Delivery. NOTE - MT Services are not necessarily made available by the EDI UA to the EDI user. B.5.3 Protocol elements supported for EDI The following P1 protocol elements will be used to support EDI applications: B.5.3.1 Content type For EDI applications, the content type will be 0 (undefined content). 103 Part 7: 1984 Message Handling Systems December 1993 (Stable) B.5.3.2 Original encoded information types Any EIT defined in the X.400 Recommendations may be used to specify the encoding of EDI content. However, for ANSI X12 EDI applications in particular, it is expected that the "undefined" and "Ia5Text" EIT's will normally be used, with "undefined" used to signify the EBCDIC character set. B.5.4 Addressing and routing It is anticipated that connection of some existing systems to an X.400 service for EDI purposes will be by other than X.400 protocols, at least in the short term. EDI messages entering the X.400 environment will therefore need to have X.400 O/R Names added to identify the origination and recipient trading partners, typically by means of local directory services in the origination domain which will map EDI identifiers/addresses into O/R Names. Such O/R Names will contain Standard Attributes as defined in table 9 and for recipient trading partners will at least identify the destination domain. In the case of trading partners outside the X.400 environment, it is expected, however, that there will be cases where message delivery will require the provision of addressing information beyond that which can be carried in Standard Attributes. In such cases, Domain Defined Attributes are recommended to be used. The syntax of this DDA is as defined in table 9, with a single occurrence having the type name "EDI" (uppercase) and a value containing the identifier/address of the trading partner. For ASC X12 purposes, specifically, this value will comprise the 2 digit interchange ID qualifier followed by the interchange ID (max 15 characters). Routing on this DDA shall only occur, if at all, in the destination domain. B.6 USA body parts It is recommended that UAs can generate any USA Body Part, as defined in clause 5.3.6.2, and that they can receive such body parts as well. reception of USA Body Parts does not imply further processing by the UA, but merely that the body part is made available, with a indication of its registered body part identifier, to another process or deposition in a file. Generation implies the reverse of this process. 104 Part 7: 1984 Message Handling Systems December 1993 (Stable) B.7 Recommended practices for binary data transfer The capability to transfer binary data, such as those generated by word/document processing, spreadsheets, or graphics applications among X.400 system is a useful and desirable feature. Many messaging systems provide such capability today. It is recommended that transfer of binary data through 1984-based systems be achieved using the unidentified BodyPart in P2 with the ASN1 definition recaptured as follows: +-----------------------------------------------------------+ | BodyPart ::= CHOICE { | | [0] IMPLICIT IA5Text | | ... | | [14] IMPLICIT Unidentified | | ... } | | Unidentified ::= OCTET STRING | +-----------------------------------------------------------+ NOTE - the Unidentified BodyPart is included in 1984 X.400 Implementor's Guide, Version 6, and is renamed as BilaterallyDefinedBodyPart in 1988 X.400 Series with the same tag and definition. Additionally the binary data can be identified by a text string in the subject heading or in an IA5Text body part preceding the Unidentified BodyPart. When the Unidentified BodyPart is present in a P2 message, the undefined(0) bit of the P1 EncodedInformationTypes will be set. If the IA5Text bodypart is also present, the IA5text(2) bit will also be set. The binary data is the raw data as generated by user applications. Besides encapsulating it for transfer purposes, X.400 systems do not encode or interprete the binary data in any way further. How the data is encoded or decoded is defined by the cooperating user applications. How the data is injected into X.400 systems or transferred out of X.400 systems to the user applications, or how the user applications are invoked to process the data is a local implementation issue and not defined. 105 Part 7: 1984 Message Handling Systems December 1993 (Stable) B.8 Recommended practice for Office Document Architecture (ODA) transfer It is recommended that the conveyance of ODA documents through 1984-based X.400 systems be achieved using the following schemes: B.8.1 ODA In P2 An ODA document will be transferred as a single body part with tag 12, recaptured as follows: +----------------------------------------------------------+ | BodyPart ::= CHOICE { | | [0] IMPLICIT IA5Text | | ... | | oda [12] IMPLICIT OCTET STRING | | ... } | +----------------------------------------------------------+ The content of the 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). B.8.2 ODA In P1 The undefined bit (bit 0) of the EncodedInformationTypes must be set and the ODA bit (bit 10) of the EncodedInformationTypes should be set when an ODA document is present in P2. However, MTAs should be tolerant of messages containing ODA documents being received with just the undefined bit (bit 0) set, and should still deliver the message. B.8.3 Interworking with later versions of X.400 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 106 Part 7: 1984 Message Handling Systems December 1993 (Stable) systems to accept these unexpected integer values if at all possible. (Note clause 8.3.7 of this section describes appropriate actions for unexpected values of the INTEGER fields in the P1 envelope.) No downgrading should be done for these values when passing affected messages from newer systems to older systems. 107 Part 7: 1984 Message Handling Systems December 1993 (Stable) Annex C (normative) Rendition of IA5Text and T61String characters C.1 Generating and imaging 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 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: +------------------------------------------------------------+ | 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 that X.408 states that for conversion from IA5Text to Teletex, the maximum line length is 77 characters. 108 Part 7: 1984 Message Handling Systems December 1993 (Stable) C.2 Generating and imaging T61String For further study. 109 Part 7: 1984 Message Handling Systems December 1993 (Stable) Annex D (informative) Differences in interpretation discovered through testing of the MHS for the CeBit 1987 demonstration Several interworking problems were discovered through multi- vendor testing. These problems, and recommendations for solutions to them are discussed in this annex. D.1 Encoding of RTS user data The password is defined as an ANY in the X.400 Recommendations, and implementor's groups have decided to use an IA5String for this field. There was some confusion about what the X.409 encoding for this IA5String would be, and the correct encoding is: +---------------------------------------------------------------- ----------+ | class: context specific | | form: constructor | | id code: 1 | | length: length of contents | | contents: (primitive encoding) | | IA5String: 16 | | length: length of contents | | contents: the password string | | class: context specific | | form: constructor | | id code: 1 | | length: length of contents | | contents: (constructor encoding) left as an exercise for the reader | +--------------------------------------------------------------------------+ 110 Part 7: 1984 Message Handling Systems December 1993 (Stable) Implementations should be prepared to receive any X.409 type for the password because of its definition as an ANY. D.2 Extra session functional units One vendor proposed more than the required set of functional units on opening the session connection, and the receiver rejected the connection. All debate aside about whether the initiator should have proposed units outside of the required set, or whether the receiver should have rejected the connection, the set of functional units can be negotiated in a straightforward way. The following is recommended. If the initiator proposes using more than the required set of functional units, the responder should specify the set of functional units that it would like to use (which should include the required set) in the open response. The session implementations will automatically use the intersection of the units proposed by both sides. If the initiator proposes using less than the required set of functional units, the responder should reject the connection. Unfortunately, there is not an appropriate RefuseReason for rejecting the connection, so instead of refusing the connection in the response to the S-CONNECT, the receiver should issue an S- U-ABORT with an AbortReason of protocolError. Note that it is valid to issue an S-U-ABORT instead of responding to the S- CONNECT. A problem report has been submitted to the CCITT requesting the addition of a RefuseReason for this situation. If the responder proposes using less than the required set of functional units, the session connection is established before the initiator can check for this. If too few functional units have been proposed, the initiator should abort the connection using S-U-ABORT, with an abort reason of protocolError. D.3 Mixed case in the MTA name The MTA name is frequently exchanged over the telephone when two systems are being configured to communicate with one another. In one such telephone exchange, the casing of the MTA name was not specified, the MTA name consisted of both upper and lower case letters, and one of the implementations compared MTA names for equality in a case sensitive manner. Consequently, connections failed until the problem was detected and repaired. It is recommended that the MTA name be compared for equality in a case insensitive manner, and that the password be compared for 111 Part 7: 1984 Message Handling Systems December 1993 (Stable) equality in a case sensitive manner. D.4 X.410 activity identifier The X.400 Implementor's Guide recommends that the activity identifier be X.409 encoded, but this is only a recommendation and not a requirement. Consequently, receiving systems cannot assume that the activity identifier will be X.409 encoded. Encoding of per recipient flag and per message fFlag In the definition of the PerRecipientFlag in X.411, there is a statement that the last three bits are reserved, and should be set to zero. It is unclear whether those bits are unused in the X.409 encoding. Receivers should accept encodings with either zero or three unused bits. A problem report has been submitted to the CCITT asking for clarification. Though there is not any statement in X.411 about the last four bits of the PerMessageFlag, some vendors have encoded this with zero unused bits, and some have encoded it with four unused bits. The PerMessageFlag should be encoded with at least four unused bits. D.5 Encoding of empty bitstrings There are three valid encodings for an empty bitstring: a constructor of length zero, a constructor of indefinite length followed by the end-of-contents terminator, and a primitive of length one with a zero octet as the value. D.6 Additional octets for bitstrings Nothing in X.409 constrains an implementation from sending two, three, four, or even more octets for a bitstring that fits into one octet, with the undefined bits set to zero. Note that the number of excess octets is bounded by the pragmatic constraints guidelines of the CCITT X.400 Implementor's Guide for all of the bitstrings in P1. 112 Part 7: 1984 Message Handling Systems December 1993 (Stable) D.7 Application protocol identifier If a value other that 1 is received in the applicationProtocol of the pUserData in the PConnect, NIST implementations will reject the connection. If CEN/CENELEC implementations receive a value other than 8883 for this field, they will reject the connection. This is an unfortunate state of affairs, because if NIST implementations accept the value of 8883 without supporting the MOTIS service elements, they would be misrepresenting themselves. To make matters worse, CEPT uses a value of 1, but relays MOTIS elements, which means that MOTIS elements will be relayed to implementations using a value of 1 to demonstrate that they do not support MOTIS. Work is continuing to try to find a solution that will allow European implementations to interwork with U.S implementations. D.8 Initial serial number in S-CONNECT This should be implemented in accordance with section 3.5.1 E4 of the Implementor's Guide. D.9 Connection data on RTS recovery It is clarified that the ConnectionData is identical in both the S-CONNECT.request and the S-CONNECT.response. The value of the ConnectionData is the old Session Connection Identifier. D.10 Activity resume If an activity is being resumed on a new session connection, it is not clear from X.410 and X.225 whether all four of the called- ss-user reference, the calling-ss-user reference, the common reference, and the additional reference information should be specified in the S-ACTIVITY-RESUME, or whether one of the ss- user-references should be absent. It is also unclear whether the called-ss-user reference should be identical to the calling-ss- user reference if both are present. Consequently, receivers should be tolerant of this situation. Appropriate problem reports will be submitted to the CCITT asking for clarification. 113 Part 7: 1984 Message Handling Systems December 1993 (Stable) D.11 Old activity identifier The Old Activity Identifier in S-ACTIVITY-RESUME refers to the original activity identifier. D.12 Negotiation down to transport class 0 For European implementations, X.410 specifies that class 0 transport must be supported. However, it is permissible for an initiator to propose a higher class as the preferred class, provided that class 0 appears as the alternate class in the T- Connect PDU. A responding implementation can choose to use either the preferred or alternate class, but again, must be able to use class 0. In other words, for private to private connections in Europe, class 0 transport is required. This conflicts with the OIW agreements, since class 0 is only required if one of the partners in a connection is an ADMD. 114 Part 7: 1984 Message Handling Systems December 1993 (Stable) Annex E (informative) Worldwide X.400 conformance profile matrix Y CONFORMANCE (E) implies a conformance problem for European products in the United States. Y CONFORMANCE (US) implies a conformance problem for U.S. products in Europe. The A/311 profile is specified in Env 41 202, the A/3211 profile in Env 41 201 No TTC protocol classification for RTS exists. The notation X/Y indicates "X" for PRMDs and "Y" for ADMDs, i.e., "M/G" would be Mandatory for PRMDs and Generatable for ADMDs. 115 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table E.1 - Protocol element comparison of RTS +-----------------------+-------+----------+---------+----------- ------------+ |RTS element | NIST | A/311 | A/3211 | PROBLEM Y/N | +-----------------------+-------+----------+---------+----------- ------------+ |PConnect | M | M | M | N | | DataTransferSyntax | M 0 | M 0 | M 0 | N | |PUserData | M | M | M | N | | checkpointSize | H | H | H | N | | windowSize | H | H | H | N | | dialogueMode | H | H | H | N | | connectdata | M | M | M | N | | applicationProtocol | G 1 | H 1 | R 8883 | N | | | H 8883| | | | | ConnectionData | | | | | | Open | G | G | G | N | | Recover | G | H | G | N | | | | | | | | Open | | | | | | RTSUserData | G | G | G | N | | | | | | | | Recover | | | | | | SessionConnectionID | G | G | G | N | | | | | | | |RTSUserData | | | | | | MTAName | G | G | G | N | 116 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | | | | | | Password | G | G | G | N | | | | | | | | null | G | G | G | N | | | | | | | |SessionConnectionID | | | | | | CallingUserReference | M | M | M | N | | | | | | | | CommonReference | M | M | M | N | | AdditionalRefInfo | H | H | H | N | | | | | | | +-----------------------+-------+----------+---------+----------- ------------+ 117 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table E.1 - Protocol element comparison of RTS (concluded) +-----------------------+------+-----------+---------+----------- ------------+ |RTS element | NIST | A/311 | A/3211 | PROBLEM (Y/N) | +-----------------------+------+-----------+---------+----------- ------------+ |PAccept | G | G | G | N | | DataTransferSyntax | M 0 | M 0 | M 0 | N | | | | | | | |PUserData | M | M | M | N | | CheckpointSize | H | H | H | N | | WindowSize | H | H | H | N | | ConnectionData | M | M | M | N | | | | | | | |PRefuse | G | G | G | N | | RefuseReason | M | M | M | N | | | | | | | |SSUserData | G | G | G | N | | (in S-TOKEN-PLEASE) | | | | | | | | | | | |AbortInformation | G | G | G | N | | (in S-U-ABORT) | | | | | | AbortReason | H | H | H | N | | reflectedParameter | X | X | X | N | +-----------------------+------+-----------+---------+----------- ------------+ 118 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table E.2 - Protocol element comparison of P1 +---------------------------------+----+-----+------+----+------- ------------+ | P1 Protocol |NIST|A/311|A/3211|TTC | PROBLEM (Y/N) | +---------------------------------+----+-----+------+----+------- ------------+ | | | | | | | | ORname | | | | | | | StandardAttributeList | M | M | M | M | N See Note 4 | | DomainDefAttributeList | X | X | X | G | Y See Note 5 | | | | | | | | | StandardAttributeList | | | | | | | CountryName | R | R | R | M | N | | | |SO R | R | | N | | | |.121 | H | | Y Conformance (E) | | | |ther | X | | Y Prot Vio | | AdministrationDomainName| R | R | G | M | N | | ... if PrintableString| | R | G | | N | | ... if numericString | | H | H | | Y Conformance (E) | | X.121 Address | X | X/R | X | | Conf(US)See Note 1| | Terminal ID | X | X/G | X | | Conf(US)See Note 1| | PrivateDomainName | G | G | G | G | N | | | | | | | | | OrganizationName | G | G | G | G | N | | UniqueUAidentifier | X | X/G | X | | Conf(US)See Note 1| | PersonalName | G | G | G | G | N | | OrganizationalUnit | G | G | G | G | N 119 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | | | | | | | | DomainDefinedAttribute | X | X | X | G | N | | Type | M | M | M | M | N | | Value | M | M | M | M | N | | | | | | | | | PersonalName | | | | | | | Surname | M | M | M | M | N | | GivenName | G | G | G | G | N | | Initials | G | G | G | G | N | | | | | | | | | GenerationQualifier | G | X | X | X | Y Conformance (E) | | | | | | | | | GlobalDomainIdentifier | | | | | | | CountryName | M | M | M | M | N | | AdministrationDomainName| M | M | G | M | Y Proto Vio | | PrivateDomainIdentifier | R/H| H | R |M/X | N | | | | | | | | | MPDU | | | | | | | UserMPDU | G | G | G | G | Y TTC required | | | | | | | MPDU size is | | | | | | | 32K | | DeliveryReportMPDU | G | G | G | G | N | | | | | | | | | ProbeMPDU | H | H | H | H | N | 120 Part 7: 1984 Message Handling Systems December 1993 (Stable) +---------------------------------+----+-----+------+----+------- ------------+ 121 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table E.2 - Protocol element comparison of P1 (continued) +---------------------------------+----+-----+------+----+------- ------------+ | P1 Protocol |NIST|A/311|A/3211|TTC | PROBLEM (Y/N) | +---------------------------------+----+-----+------+----+------- ------------+ | | | | | | | | UserMPDU | | | | | | | UMPDUenvelope | M | M | M | M | N | | UMPDUcontent | M | M | M | M | N | | | | | | | | | UMPDUenvelope | | | | | | | MPDUidentifier | M | M | M | M | N | | originatorORname | M | M | M | M | N | | originalEncodedTypes | G | H | H | G | Y Conformance (E)| | | | | | | | | ContentType | M | M | M | M | N | | UAcontentID | H | H | H | H | N | | Priority | G | G | G | G | N | | PerMessageFlag | G | G | G | G | N | | DeferredDelivery | X | X | X | X | N | | PerDomainBilatInfo | X | X | X | X | N | | RecipientInfo | M | M | M | M | Y TTC MPDU 32K | | TraceInformation | M | M | M | M | N | |MOTIS-> LatestDelivery | | | X | | N | |MOTIS-> InternalTraceInfo | M/P| | P | | N | | UMPDUcontent | M | M | M | M | N 122 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | | | | | | | | MPDUidentifier | | | | | | | GlobalDomainIdent | M | M | M | M | N | | IA5string | M | M | M | M | N | | | | | | | | | PerMessageFlag | | | | | | | DiscloseRecipients | H | @ MT| H | H | Y Conformance (US)| | | | at U| ? | | Y Conformance (US)| | ConversionProhibited | G | G | G | G | N | | AlternatRecipAllowed | H | @ MT| H | X | Y Conformance (US)| | | | at U| ? | | Y Conformance (US)| | ContentReturnRequest | X | X | X | X | | |MOTIS-> redirectionProhibited | | | X | | N | | | | | | | | | PerDomainBilateralInfo | | | | | | | CountryName | M | M | M | M | N | | AdminDomainName | M | M | G | M | Y Prot Vio | |MOTIS-> PrivateDomainName | | | G | | N | | BilateralInfo | M | M | M | M | N | +---------------------------------+----+-----+------+----+------- ------------+ 123 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table E.2 - Protocol element comparison of P1 (continued) +---------------------------------+----+-----+------+----+------- ------------+ | P1 Protocol |NIST|A/311|A/3211|TTC | PROBLEM (Y/N) | +---------------------------------+----+-----+------+----+------- ------------+ | DeliveryReportContent | | | | | | | original MPDUident | M | M | M | M | N | | intermediate Trace | X/G| X | X | X | Y Conformance (E) | | UAcontentID | G | G | G | G | N | | ReportedRecipientInfo | M | M | M | M | Y TTC 256 max | | returned | H | H | X | X | Y Conformance (E) | | billing information | X | X | X | X | N | | | | | | | | | ReportedRecipientInfo | | | | | | | recipient ORname | M | M | M | M | N | | extensionsIdentifier | M | M | M | M | N | | PerRecipientFlag | M | M | M | M | N | | LastTraceInformation | M | M | M | M | N | | intendedRecipient | H | H | H | H | N | | SupplementaryInfo | X/H| X | X | X | Y Conformance (E) | |MOTIS-> ReassignmentInfo | | | X | | N | | | | | | | | |MOTIS-> ReassignmentInfo | | | | | | |MOTIS-> intendedRecipient | | | M | | N | |MOTIS-> reasonForReassignment | | | H | | N | | | | | | | 124 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | LastTraceInformation | | | | | | | arrival | M | M | M | M | N | | convertedEncInfoTypes | G | G | H | G | Y Conformance (E) | | Report | M | M | M | M | N | | | | | | | | | Report | | | | | | | DeliveredInfo | G | G | G |-+ | N See Note 6 | | | | | | +-M| | | NonDeliveredInfo | G | G | G |-+ | N | | | | | | | | | DeliveredInfo | | | | | | | delivery | M | M | M | M | N | | TypeofUA | R/H| H | R |M/G | N | | | | | | | | | NonDeliveredInfo | | | | | | | ReasonCode | M | M | M | M | N | | DiagnosticCode | H | H | H | H | N | |MOTIS-> UAprofileIdentifier | | | X | | N | | | | | | | | |MOTIS-> UAprofileIdentifier | | | | | | |MOTIS-> ContentType | | | M | | N | |MOTIS-> EncodedInfoTypes | | | M | | N | +---------------------------------+----+-----+------+----+------- ------------+ 125 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table E.2 - Protocol element comparison of P1 (continued) +---------------------------------+----+-----+------+----+------- ------------+ | P1 Protocol |NIST|A/311|A/3211|TTC | PROBLEM (Y/N) | +---------------------------------+----+-----+------+----+------- ------------+ | | | | | | | | ProbeEnvelope | | | | | | | probe | M | M | M | M | N | | originator | M | M | M | M | N | | ContentType | M | M | M | M | N | | UAcontentID | H | H | H | H | N | | originalEncInfoTypes | G | H | H | G | Y Conformance (E) | | TraceInformation | M | M | M | M | N | | PerMessageFlag | G | G | G | G | N | | ContentLength | H | H | H | H | N | | PerDomainBilatInfo | X | X | X | X | N | | RecipientInfo | M | M | M | M | Y TTC 256 max | |MOTIS-> InternalTraceInfo | M/P| | P | | N | | | | | | | | | RecipientInfo | | | | | | | RecipientORname | M | M | M | M | N | | ExtensionIdentifier | M | M | M | M | N | | PerRecipientFlag | M | M | M | M | N | | ExplicitConversion | X | X | X | X | N | |MOTIS-> OriginReqAlternatRecip | | | X | | N | |MOTIS-> ReassignmentInfo | | | X | | N 126 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | | | | | | | | PerRecipientFlag | | | | | | | ResponsibilityFlag | M | M | M | M | N | | ReportRequest | M | M | M | M | N | | UserReportRequest | M | M | M | M | N | | | | | | | | | TraceInformation | | | | | | | | | | | | | | GlobalDomainIdent | M | M | M | M | N | | DomainSuppliedInfo | M | M | M | M | N | +---------------------------------+----+-----+------+----+------- ------------+ 127 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table E.2 - Protocol element comparison of P1 (concluded) +---------------------------------+----+-----+------+----+------- ------------+ | P1 Protocol |NIST|A/311|A/3211|TTC | PROBLEM (Y/N) | +---------------------------------+----+-----+------+----+------- ------------+ | | | | | | | | DomainSuppliedInfo | | | | | | | arrival | M | M | M | M | N | | deferred | X | X | X | X | N | | action | M | M | M | M | N | | (0=relayed) | G | G | G | | N Note: | | | | | | | Re- routing not | | | | | | | required. | | (1=rerouted) | H | H | H | | N | |MOTIS-> (2=recipientReassigned)| | | H | | N | | converted | H | G | H | H | Y Conformance(US)| | previous | H | G | G | X | Y Conformance(US)| | | | | | | (Note: G is | | | | | | | inconsistent with| | | | | | | action (relayed) | | | | | | | being "H.") | | | | | | | | | ORname | | | | | | | | | | | | | | EncodedInformationTypes | | | | | | | BitString | M | M | M | M | N See Note 3 | 128 Part 7: 1984 Message Handling Systems December 1993 (Stable) | G3NonBasicParameters | X | X | X | X | N | | TeletexNonBasicParams | X | R | X | X | Y Conformance(US)| | PresentationAbilities | X | X | X | X | N | | | | | | | | | DeliveryReportMPDU | G | G | M | G | N | | DeliveryReportEnvelop | M | M | M | M | N | | DeliveryReportContent | M | M | M | M | N | | | | | | | | | DeliveryReportEnvelope | | | | | | | report | M | M | M | M | N | | originator ORname | M | M | M | M | N | | TraceInformation | M | M | M | M | N | | InternalTraceInfo | M/P| | P | | N | +---------------------------------+----+-----+------+----+------- ------------+ 129 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table E.3 - Protocol element comparison of P2 +---------------------------------+----+-----+------+----+------- ------------+ |P2 Protocol |NIST|A/311|A/3211|TTC | PROBLEM (Y/N) | +---------------------------------+----+-----+------+----+------- ------------+ | | | | | | | | UAPDU | | | | | | | IM_UAPDU | G | G | G | G | N | | SR_UAPDU | X | X | X | X | N | | | | | | | | | IM_UAPDU | | | | | | | Heading | M | M | M | M | N | | Body | M | M | M | M | N | | | | | | | | | Heading | | | | | | | IPmessageID | M | M | M | M | N | | Originator ORname | R | R | R | M/G| N | | AuthorizingUsers | H | H | H | H | Y TTC 16 max | | PrimaryRecipients | G | G | G | G | Y TTC 256 max | | CopyRecipients | G | G | G | G | Y TTC 256 max | | BlindCopyRecipient | H | H | H | H | Y TTC 256 max | | InReplyTo | G | G | G | G | N | | Obsoletes | H | H | H | H | Y TTC 8 max | | CrossReferences | H | H | H | H | Y TTC 8 max | | Subject | G | G | G | G | N | | ExpiryDate | H | H | H | H | N | 130 Part 7: 1984 Message Handling Systems December 1993 (Stable) | ReplyBy | H | H | H | H | N | | ReplyToUsers | H | H | H | H | Y TTC 32 max | | Importance | H | H | H | H | N | | Sensitivity | H | H | H | H | N | | Autoforwarded | H | H | H | H | N | |MOTIS-> CirculationList | | | X | | N | |MOTIS-> ObsoletingTime | | | X | | N | | | | | | | | | IPmessageID | | | | | | | ORname | H | H | H | H | N | | PrintableString | M | M | M | M | N | | | | | | | | | ORdescriptor | | | | | | | ORname | H | H | H |-+ | N See Note 6 | | | | | | +-M| | | FreeFormName | H | H | H |-+ | N | | TelephoneNumber | H | H | H | G | N | | | | | | | | | Recipient | | | | | | | ORdescriptor | M | M | M | M | N | | ReportRequest | X | X | X | X | N | | ReplyRequest | H | H | H | H | N | +---------------------------------+----+-----+------+----+------- ------------+ 131 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table E.3 - Protocol element comparison of P2 (continued) +---------------------------------+----+-----+------+----+------- ------------+ |P2 Protocol |NIST|A/311|A/3211|TTC | PROBLEM (Y/N) | +---------------------------------+----+-----+------+----+------- ------------+ |MOTIS-> CirculationList | | | | | | |MOTIS-> CirculationMember | | | X | | N | |MOTIS-> checkmark | | | M | | N | |MOTIS-> membername | | | M | | N | | | | | | | | |MOTIS-> OBsoletingTime | | | | | | |MOTIS-> Time | | | H | | N | |MOTIS-> IP_MessageID | | | H | | N | | | | | | | | | Body | | | | | | | BodyPart | G | M | M | G | Y Conformance (US)| | | | | | | | | SR_UAPDU | | | | | | | NonReceipt | H | H | H |-+ | N | | | | | | +-M| | | Receipt | H | H | H |-+ | N | | Reported | M | M | M | M | N | | ActualRecipient | R | R | R | G | N | | IntendedRecipient | H | H | H | H | N | | Converted | X | X | X | G | N | |MOTIS-> CirculationStatus | | | X | | N | 132 Part 7: 1984 Message Handling Systems December 1993 (Stable) | | | | | | | | NonReceiptInformation | | | | | | | Reason | M | M | M | M | N | | NonReceiptQualifier | H | H | H | H | N | | =expired (value) | 0 | 0 | 0 | 0 | N | | =obsoleted (value) | 1 | 1 | 1 | 1 | N | | =subscriptionTerminated| 2 | 2 | 2 | 2 | N | |MOTIS-> =timeobsoleted (value) | | | X | | N | | Comments | H | H | H | X | N | | returned | H | X | X | X | Y Conformance (E) | | | | | | | | | ReceiptInformation | | | | | | | Receipt | M | M | M | M | N | | TypeOfReceipt | H | H | H | G | N | | SupplementaryInfo | X | X | X | X | N | +---------------------------------+----+-----+------+----+------- ------------+ 133 Part 7: 1984 Message Handling Systems December 1993 (Stable) Table E.3 - Protocol element comparison of P2 (concluded) +---------------------------------+----+-----+------+---+-------- ------------+ |P2 Protocol |NIST|A/311|A/3211|TTC| PROBLEM (Y/N) | +---------------------------------+----+-----+------+---+-------- ------------+ | | | | | | | | BODYPART SUPPORT | | | | | | | | | | | | | | o IA5 Text | G | G | G | | N See Note 7 | | o TLX | X | X | X | | N | | o Voice | X | X | X | | N | | o G3FAX | X | X | X | | N | | o TIFO | X | X | X | | N | | o TTX | X | X/H | X | |Y Conf(US)See Note 2| | o VideoTex | X | X | X | | N | | o NationallyDefined | X | X | X | | N | | o Encrypted | X | X | X | | N | | o ForwardedIPmessage | H | H | H | | N | | o SFD | X | X | X | | N | | o TIFI | X | X | X | | N | | | | | | | | |MOTIS-> o ODA | | | X | | N | |MOTIS-> o ISO6937 Text | | | H | | N | | | | | | | | +---------------------------------+----+-----+------+---+-------- ------------+ 134 Part 7: 1984 Message Handling Systems December 1993 (Stable) NOTES 1 It should be noted that the A/311 profile states: For routing all ADMDs should support all Form 1 Variants of O/R Name. All PRMDs should support at least Form 1, Variant 1 form of OR Name. 2 It should also be noted that the A/311 profile requires that all ADMDs should support the reception of Teletex body parts for delivery to their own UAEs. 3 An A/3211 implementation may generate MOTIS encoded information types. See 6.11. 4 Only Form 1 Variant 1 of O/Rname shown for TTC, but TTC defines other forms and variants. Form 1 Variant 1 recommended for PRMDs and ADMDs, Form 1 Variant 2 also recommended for ADMDs. 5 DDA's can be used to specify recipients in any Japanese domains other than TTC. Assignment of DDAs for UAs within TTC domains is not recommended. 6 One of [DeliveredInfo/NonDeliveredInfo] must be present. TTC encodes this as shown. Other profiles represent this by classifying both protocol elements as generatable. A similar situation exists with the P2 ORdescriptor. 7 TTC is expected to support IA5 for some international MHS communications. 135 Part 7: 1984 Message Handling Systems December 1993 (Stable) Annex F (informative) Interworking warnings ADMD name is to be encoded as a single space when configurations with no ADMD's are present. It should be noted that this may change in January 1988 so that the ADMD name is encoded as a zero length element in such cases. The OSI Implementors' agreements allow implementation to generate MPDUs with no body parts. Such MPDUs will be rejected by European-conformant systems. (Note this situation may change in January 1988) In order to optimize the number of recipients you can read and reply to, it is advisable to be able to generate all standard O/R name attributes. 136