home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD1.mdf
/
nist
/
oiw
/
agreemnt
/
1993
/
08s_9309.txt
< prev
next >
Wrap
Text File
|
1993-11-05
|
704KB
|
19,206 lines
Stable Implementation
Agreements for Open Systems
Interconnection Protocols:
Part 8 - Message Handling Systems
Output from the September 1993 Open Systems Environment
Implementors' Workshop (OIW)
SIG Chair: Chris Bonatti, Booz Allen & Hamilton
SIG Editor: Rich Ankney, Fischer International
Part 8: Message Handling Systems March 1993 (Stable)
Foreword
The text in this part contains a set of Message Handling System
(MHS) Implementation Agreements intended to serve in lieu of an
International Standardized Profile (ISP) for MHS. It is the aim
of the OIW X.400 SIG to pursue alignment of this part with the
developing ISP. When the ISP is complete, this part will be
revised to refer to the ISP, and to only highlight additional
practices and North American regional requirements.
ii
Part 8: Message Handling Systems March 1993 (Stable)
Table of Contents
Part 8 Message Handling Systems . . . . . . . . . . . . . . 1
0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 References . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 CCITT . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 ISO . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Errata . . . . . . . . . . . . . . . . . . . . . . . . . 5
5 MT kernel . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Introduction . . . . . . . . . . . . . . . . . . . . 5
5.2 Elements of service . . . . . . . . . . . . . . . . 6
5.3 MTS transfer protocol (P1) . . . . . . . . . . . . . 9
5.4 MTS - APDU size . . . . . . . . . . . . . . . . . . 9
5.4.1 Number of recipient names . . . . . . . . . 9
5.5 1988/84 interworking considerations . . . . . . . . 9
6 Message store . . . . . . . . . . . . . . . . . . . . . . 11
6.1 Introduction . . . . . . . . . . . . . . . . . . . . 11
6.2 Scope . . . . . . . . . . . . . . . . . . . . . . . 12
6.3 Elements of service . . . . . . . . . . . . . . . . 12
6.4 Attribute types . . . . . . . . . . . . . . . . . . 13
6.5 Pragmatic constraints for attribute types . . . . . 13
6.6 MS access protocol (P7) . . . . . . . . . . . . . . 13
6.7 MTS Access Protocol (P3) . . . . . . . . . . . . . . 14
7 Remote user agent support . . . . . . . . . . . . . . . . 14
7.1 Introduction . . . . . . . . . . . . . . . . . . . . 14
7.2 Scope . . . . . . . . . . . . . . . . . . . . . . . 15
7.3 Elements of service . . . . . . . . . . . . . . . . 15
7.4 MTS access protocol (P3) . . . . . . . . . . . . . . 15
8 Naming, addressing & routing . . . . . . . . . . . . . . 16
8.1 Use of O/R addresses for routing . . . . . . . . . . 16
8.2 ORAddress attribute list equivalence rules . . . . . 16
8.3 Distribution lists . . . . . . . . . . . . . . . . . 17
8.3.1 Introduction . . . . . . . . . . . . . . . 17
8.3.2 Elements of service . . . . . . . . . . . . 17
8.4 MHS use of Directory . . . . . . . . . . . . . . . . 18
8.4.1 Introduction . . . . . . . . . . . . . . . 18
8.4.2 Functional configuration . . . . . . . . . 18
iii
8.4.3 Functionality . . . . . . . . . . . . . . . 18
8.4.4 Naming and attributes . . . . . . . . . . . 19
8.4.5 Elements of service . . . . . . . . . . . . 20
8.4.6 Directory services . . . . . . . . . . . . 20
8.4.7 OIW X.400 base Directory Implementation
Agreements . . . . . . . . . . . . . . . . 21
8.4.7.1 Other profiles supported . . . . . . . . . 21
8.4.7.2 Standard application specific attributes
and attribute sets . . . . . . . . . . . . 21
8.4.7.3 Standard application specific object
classes . . . . . . . . . . . . . . . . . . 22
8.4.7.4 OIW application specific attributes and
attribute sets . . . . . . . . . . . . . . 22
8.4.7.5 OIW application specific object classes . . 22
8.4.7.6 Structure rules . . . . . . . . . . . . . . 22
8 . 4 . 7 . 6 . 1
MHS Distribution List . . . . . . . . . . . 22
8 . 4 . 7 . 6 . 2
MHS User . . . . . . . . . . . . . . . . . 22
8.4.7.7 Use of Capabilities Information . . . . . . 23
8.5 Address support for Teletex character sets . . . . . 23
8.6 Reply support . . . . . . . . . . . . . . . . . . . 23
9 MHS management . . . . . . . . . . . . . . . . . . . . . 23
10 MHS security . . . . . . . . . . . . . . . . . . . . . . 23
10.1 Overview . . . . . . . . . . . . . . . . . . . . . . 23
10.2 Common requirements . . . . . . . . . . . . . . . . 25
10.2.1 Interworking between security classes . . . 25
10.2.2 Comparison of security labels . . . . . . . 25
10.2.3 Application context . . . . . . . . . . . . 26
10.3 Description of security classes . . . . . . . . . . 26
10.4 Security class 0 (S0) . . . . . . . . . . . . . . . 27
10.4.1 Security functionality . . . . . . . . . . 27
10.4.2 Security services for S0 . . . . . . . . . 27
10.5 Security class 0A (S0a) . . . . . . . . . . . . . . 29
10.5.1 Security functionality . . . . . . . . . . 29
10.5.2 Security services for S0a . . . . . . . . . 29
10.6 Security class 1 (S1) . . . . . . . . . . . . . . . 30
10.6.1 Security functionality . . . . . . . . . . 30
10.6.2 Security services for S1 . . . . . . . . . 30
10.7 Security class 1A (S1a) . . . . . . . . . . . . . . 31
10.7.1 Security functionality . . . . . . . . . . 31
10.7.2 Security services for S1a . . . . . . . . . 31
10.8 Security class 2 (S2) . . . . . . . . . . . . . . . 32
10.8.1 Security functionality . . . . . . . . . . 32
10.8.2 Security services for S2 . . . . . . . . . 32
10.9 Security class 2A (S2a) . . . . . . . . . . . . . . 33
10.9.1 Security functionality . . . . . . . . . . 33
10.9.2 Security services for S2a . . . . . . . . . 33
iv
11 Specialized access . . . . . . . . . . . . . . . . . . . 33
11.1 Physical delivery . . . . . . . . . . . . . . . . . 33
11.1.1 Elements of service . . . . . . . . . . . . 33
11.2 Other access units . . . . . . . . . . . . . . . . . 35
11.2.1 Facsimile access units . . . . . . . . . . 35
11.2.2 Telex access units . . . . . . . . . . . . 35
11.2.3 Teletex access units . . . . . . . . . . . 35
12 Redirection . . . . . . . . . . . . . . . . . . . . . . . 35
13 IPM service . . . . . . . . . . . . . . . . . . . . . . . 35
13.1 Introduction . . . . . . . . . . . . . . . . . . . . 35
13.2 Elements of service . . . . . . . . . . . . . . . . 36
13.3 Interpersonal messaging protocol (P2) . . . . . . . 38
13.4 Body part support . . . . . . . . . . . . . . . . . 38
13.5 MS attributes . . . . . . . . . . . . . . . . . . . 40
13.5.1 Implementation of the IPM MS with 1984
systems . . . . . . . . . . . . . . . . . . 40
13.6 Body part conversion functional group . . . . . . . 40
13.6.1 General . . . . . . . . . . . . . . . . . . 40
13.6.2 Elements of service . . . . . . . . . . . . 41
13.6.3 Conformance . . . . . . . . . . . . . . . . 41
13.7 Security . . . . . . . . . . . . . . . . . . . . . . 42
13.8 Error handling . . . . . . . . . . . . . . . . . . . 42
13.9 Physical delivery . . . . . . . . . . . . . . . . . 42
14 EDI messaging service . . . . . . . . . . . . . . . . . . 43
14.1 Introduction . . . . . . . . . . . . . . . . . . . . 43
14.2 EDIMS Elements of service . . . . . . . . . . . . . 43
14.3 P(EDI) protocol . . . . . . . . . . . . . . . . . . 47
14.4 EDIMS Multi-Part Body functional group . . . . . . . 47
14.4.1 General . . . . . . . . . . . . . . . . . . 47
14.4.2 Elements of service . . . . . . . . . . . . 47
14.5 EDI Message Store (EDI-MS) . . . . . . . . . . . . . 47
14.5.1 MS Attributes . . . . . . . . . . . . . . . 47
14.6 Conversion . . . . . . . . . . . . . . . . . . . . . 47
14.7 EDIMS security functional group . . . . . . . . . . 47
14.7.1 EDIMS security class EDI-A (SEC-A) . . . . 48
14.7.2 EDIMS security class EDI-B (SEC-B) . . . . 48
14.7.3 EDIMS security class EDI-C (SEC-C) . . . . 48
14.8 EDIMS Physical Delivery functional group . . . . . . 49
14.9 EDIMS Forwarding functional group . . . . . . . . . 49
14.9.1 General . . . . . . . . . . . . . . . . . . 49
14.9.2 Elements of service . . . . . . . . . . . . 49
14.10 Use of Directory . . . . . . . . . . . . . 49
15 Use of underlying layers . . . . . . . . . . . . . . . . 50
15.1 MTS transfer protocol (P1) . . . . . . . . . . . . . 50
15.2 MTS access protocol (P3) and MS access protocol
(P7) . . . . . . . . . . . . . . . . . . . . . . . . 50
v
16 Error handling . . . . . . . . . . . . . . . . . . . . . 50
16.1 PDU encoding . . . . . . . . . . . . . . . . . . . . 50
16.2 Envelope . . . . . . . . . . . . . . . . . . . . . . 51
16.3 Reports . . . . . . . . . . . . . . . . . . . . . . 51
16.4 Pragmatic constraints . . . . . . . . . . . . . . . 51
17 Conformance . . . . . . . . . . . . . . . . . . . . . . . 51
17.1 MT Kernel Conformance Classes . . . . . . . . . . . 52
17.2 MS conformance levels . . . . . . . . . . . . . . . 53
17.3 EDI-UA conformance . . . . . . . . . . . . . . . . . 54
18 Management domain agreements . . . . . . . . . . . . . . 54
18.1 Management domain names . . . . . . . . . . . . . . 54
18.2 Use of ADMD names . . . . . . . . . . . . . . . . . 56
18.3 Uniqueness of MTS Identifiers within a management
domain . . . . . . . . . . . . . . . . . . . . . . . 57
Annex A (normative)
MHS protocol specifications . . . . . . . . . . . . . . . . . 58
A.1 MTS transfer protocol (P1) . . . . . . . . . . . . . 60
A.2 Interpersonal messaging protocol (P2) . . . . . . . 70
A.3 MTS access protocol (P3) . . . . . . . . . . . . . . 73
A.4 MS access protocol (P7) . . . . . . . . . . . . . . 85
A.5 Classification of the P1 protocol elements for
security classes . . . . . . . . . . . . . . . . . . 91
A.6 Classification of the P3 protocol elements for
security classes . . . . . . . . . . . . . . . . . . 95
A.7 Classification of the P7 Protocol Elements for
Security Classes . . . . . . . . . . . . . . . . . . 102
A.8 Message store general attribute support . . . . . . 103
A.9 Classification of the MS General Attributes for
Security Classes . . . . . . . . . . . . . . . . . . 106
A.10 Message store IPM attribute support . . . . . . . . 107
A.11 EDI messaging service protocol (Pedi) . . . . . . . 109
A.12 Message store EDIMS attribute support . . . . . . . 114
A.13 Classification of the P3 protocol elements for
physical delivery . . . . . . . . . . . . . . . . . 114
Annex B (normative)
Object identifiers . . . . . . . . . . . . . . . . . . . . . 116
B.1 X.400 SIG object identifiers . . . . . . . . . . . . 116
B.2 Content types . . . . . . . . . . . . . . . . . . . 116
B.3 Body part types . . . . . . . . . . . . . . . . . . 117
B.4 Security classes . . . . . . . . . . . . . . . . . . 117
Annex C (informative)
Interpretation of elements of service . . . . . . . . . . . . 118
vi
Annex D (informative)
Recommended practices . . . . . . . . . . . . . . . . . . . . 119
D.1 Printable String . . . . . . . . . . . . . . . . . . 119
D.2 Rendition of IA5Text . . . . . . . . . . . . . . . . 120
D.3 EDI use of MHS . . . . . . . . . . . . . . . . . . . 121
D.3.1 P0 recommended practice . . . . . . . . . . 121
D.3.1.1 P0 to P(edi) conversion . . . . . . . . . . 121
D.3.1.2 P(edi) to P0 conversion . . . . . . . . . . 122
D.3.2 P2 recommended practice . . . . . . . . . . 123
D.3.2.1 Conversion from IPMS to EDIMS (P2 to
P(edi)) . . . . . . . . . . . . . . . . . . 123
D.3.2.2 Conversion from EDIMS to IPMS (P(edi) to
P2) . . . . . . . . . . . . . . . . . . . . 123
D.4 ODA transfer . . . . . . . . . . . . . . . . . . . . 124
D.5 Use of externally defined body part . . . . . . . . 124
D.5.1 General . . . . . . . . . . . . . . . . . . 124
D.5.2 Use of equivalents of basic body part types 125
D.5.3 Use of General Text body part type . . . . 125
D.5.4 Use of File Transfer body part type . . . . 126
D.5.4.1 Encoding of General Identifier . . . . . . 126
D.5.4.2 Encoding of Contents Type . . . . . . . . . 126
D.5.4.3 Encoding of application specific
information . . . . . . . . . . . . . . . . 126
D.5.4.4 EITs for the File Transfer body part . . . 127
D.5.5 Use of other extended body part types . . . 127
D.5.6 Obtaining object identifiers . . . . . . . 127
D.6 Privacy Enchanced Mail body part . . . . . . . . . . 128
D.7 Selection of OR name attributes . . . . . . . . . . 129
D.8 Use of the Teletex body part . . . . . . . . . . . . 129
D.9 Provision of security class S0A using asymmetric
algorithms . . . . . . . . . . . . . . . . . . . . . 129
D.9.1 Protocol elements . . . . . . . . . . . . . 129
D.9.2 Algorithm selection . . . . . . . . . . . . 131
D.9.3 Certificate management . . . . . . . . . . 131
D.9.4 Other issues . . . . . . . . . . . . . . . 131
Annex E (informative)
Secure messaging guidelines . . . . . . . . . . . . . . . . . 132
E.1 Introduction . . . . . . . . . . . . . . . . . . . . 132
E.2 Message handling vulnerabilities . . . . . . . . . . 132
E.3 General principles . . . . . . . . . . . . . . . . . 133
E.3.1 Security policy . . . . . . . . . . . . . . 133
E.3.2 Security classes . . . . . . . . . . . . . 133
E.3.3 Dynamic behavior requirements . . . . . . . 134
E.3.4 Encryption techniques . . . . . . . . . . . 134
E.3.5 Implementation considerations . . . . . . . 135
E.3.5.1 Peer Entity authentication . . . . . . . . 135
E.3.5.2 Confidentiality . . . . . . . . . . . . . . 135
vii
E.3.5.3 Integrity . . . . . . . . . . . . . . . . . 135
E.3.5.4 Message origin authentication . . . . . . . 136
E.3.5.5 Non-Repudiation . . . . . . . . . . . . . . 136
E.3.5.6 Secure access management . . . . . . . . . 136
E.3.5.7 Implications for the use of distribution
lists . . . . . . . . . . . . . . . . . . . 136
E.3.5.8 Implications on redirection . . . . . . . . 136
E.3.5.9 Implications for 1984 interworking . . . . 137
E . 3 . 5 . 1 0
Implications for use of Directory . . . . . 137
E . 3 . 5 . 1 1
Implications for conversion . . . . . . . . 137
E . 3 . 5 . 1 2
Accountability . . . . . . . . . . . . . . 137
E . 3 . 5 . 1 3
Double enveloping . . . . . . . . . . . . . 137
E.4 Security class S0 . . . . . . . . . . . . . . . . . 138
E.4.1 Rationale . . . . . . . . . . . . . . . . . 138
E.4.2 Technical implications . . . . . . . . . . 139
E.5 Security class S1 . . . . . . . . . . . . . . . . . 139
E.5.1 Rationale . . . . . . . . . . . . . . . . . 139
E.5.2 Technical implications . . . . . . . . . . 139
E.6 Security class S2 . . . . . . . . . . . . . . . . . 140
E.6.1 Rationale . . . . . . . . . . . . . . . . . 140
E.6.2 Technical implications . . . . . . . . . . 140
E.7 Confidential security class variants (S0a, S1a, and
S2a) . . . . . . . . . . . . . . . . . . . . . . . . 141
E.7.1 Rationale . . . . . . . . . . . . . . . . . 141
E.7.2 Technical implications . . . . . . . . . . 141
Annex F (informative)
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 142
F.1 ANSI . . . . . . . . . . . . . . . . . . . . . . . . 142
F.2 Internet . . . . . . . . . . . . . . . . . . . . . . 142
Annex G (informative)
Defense message handling profiles . . . . . . . . . . . . . . 143
G.1 Introduction . . . . . . . . . . . . . . . . . . . . 143
Annex H (informative)
Differences between OIW Agreements and EWOS/ETSI Draft Profile
A/3312 . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
H.1 P7 . . . . . . . . . . . . . . . . . . . . . . . . . 144
viii
List of Figures
Figure 1 - Scenario definition . . . . . . . . . . . . . . . 2
Figure 2 - 1988 to 1984 mapping . . . . . . . . . . . . . . . 10
Figure 3 - 1984 to 1988 mapping . . . . . . . . . . . . . . . 11
Figure 4 - Message store model . . . . . . . . . . . . . . . 11
Figure 5 - Scope of message store agreements . . . . . . . . 12
Figure 6 - Scope of remote user agent agreements . . . . . . 15
Figure 7 - Example of unregistered object class definition . 20
Figure 8 - Incremental functionality of the security
classes . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 9 - Security interfaces . . . . . . . . . . . . . . . 27
Figure 10 - Privately-defined body parts . . . . . . . . . . 39
Figure 11 - MT kernel conformance classes . . . . . . . . . . 53
Figure 12 - Management domain name construction . . . . . . . 54
Figure 13 - Name construction by subauthorities . . . . . . . 56
Figure 14 - Prefix . . . . . . . . . . . . . . . . . . . . . 56
Figure 15 - Definition of the mhsig object identifier . . . . 116
Figure 16 - Defintion of the X.400 SIG Object Identifier
Categories. . . . . . . . . . . . . . . . . . . . . . . 116
Figure 17 - Definition of the External body part object
identifiers . . . . . . . . . . . . . . . . . . . . . . 117
Figure 18 - Security object identifiers . . . . . . . . . . . 117
Figure 19 - ASCII to PrintableString algorithm . . . . . . . 120
Figure 20 - PrintableString to ASCII algorithm . . . . . . . 120
Figure 22 - Externally Defined body part definition . . . . . 125
Figure 23 - Definition of the Privacy Enhanced Mail body
part type . . . . . . . . . . . . . . . . . . . . . . . 128
Figure 24 - Double enveloping technique . . . . . . . . . . . 138
ix
List of Tables
Table 1 - MT kernel: basic MT elements of service . . . . . . 7
Table 2 - MT kernel: MT service optional user facilities . . 8
Table 3 - Application contexts classification . . . . . . . . 9
Table 4 - Message store: elements of service . . . . . . . . 13
Table 5 - Application contexts support for P7 . . . . . . . . 14
Table 6 - Application contexts support for P3 . . . . . . . . 14
Table 7 - Remote user agent support: MT elements of service . 15
Table 8 - Application contexts support for P3 . . . . . . . . 16
Table 9 - Distribution lists: MT elements of service . . . . 17
Table 10 - Use of directory: MT elements of service . . . . . 20
Table 11 - Directory service support requirements . . . . . . 21
Table 12 - Standard attributes and attribute sets . . . . . . 21
Table 13 - Standard object classes . . . . . . . . . . . . . 22
Table 14 - Overview of security requirements for each
security class. . . . . . . . . . . . . . . . . . . . . 24
Table 15 - Security class 0 (S0) . . . . . . . . . . . . . . 28
Table 16 - Security class 0A (S0a) . . . . . . . . . . . . . 29
Table 17 - Security class 1 (S1) . . . . . . . . . . . . . . 31
Table 18 - Security class 1A (S1a) . . . . . . . . . . . . . 32
Table 19 - Security class 2 (S2) . . . . . . . . . . . . . . 32
Table 20 - Security class 2A (S2a) . . . . . . . . . . . . . 33
Table 21 - Physical delivery: MT elements of service . . . . 34
Table 22 - Character string support . . . . . . . . . . . . . 34
Table 23 - IPM kernel: basic IPM elements of service . . . . 36
Table 24 - IPM kernel: IPM service optional user facilities . 37
Table 25 - Conversion: MT elements of service . . . . . . . . 41
Table 26 - Physical delivery: IPM elements of service . . . . 42
Table 27 - EDIMS functional groups . . . . . . . . . . . . . 43
Table 28 - EDIMS: Basic EDI elements of service . . . . . . 44
Table 29 - EDIMS: Optional EDI elements of service . . . . . 45
Table 30 - Conformance requirements . . . . . . . . . . . . . 52
Table 31 - Classification changes . . . . . . . . . . . . . . 58
Table 32 - Classification of the P1 protocol elements . . . . 61
Table 33 - Classification of the P2 protocol elements . . . . 70
Table 34 - Classification of the P3 protocol elements . . . . 73
Table 35 - Classification of the P7 protocol elements . . . . 85
Table 36 - Conformance classification of the P1 protocol
elements for security class S1 . . . . . . . . . . . . . 91
Table 37 - Conformance classification of the P1 protocol
elements for security class S2 . . . . . . . . . . . . . 93
Table 38 - Conformance classification of the P3 protocol
elements for security class S0 . . . . . . . . . . . . . 95
Table 39 - Conformance classification of the P3 protocol
elements for security class S1 . . . . . . . . . . . . . 97
Table 40 - Conformance classification of the P3 protocol
elements for security class S2 . . . . . . . . . . . . . 100
Table 41 - Conformance classification of the P3 protocol
x
elements for security classes S0a, S1a, or S2a . . . . . 102
Table 42 - Conformance classification of the P7 protocol
elements for security class S1 . . . . . . . . . . . . . 103
Table 43 - Classification of the message store general
attributes . . . . . . . . . . . . . . . . . . . . . . . 104
Table 44 - MS security attribute support . . . . . . . . . . 106
Table 45 - Classification of the message store IPM
attributes . . . . . . . . . . . . . . . . . . . . . . . 107
Table 46 - Classification of the Pedi protocol elements . . . 109
Table 48 - Classification of the P3 protocol elements for
physical delivery . . . . . . . . . . . . . . . . . . . 115
Table 49 - Printable String to ASCII mapping . . . . . . . . 119
Table 50 - Interpretation of format effector combinations . . 120
xi
Part 8 Message Handling Systems
0 Introduction
This is an Implementation Agreement developed by the
Implementors' Workshop sponsored by the U. S. National Institute
of Standards and Technology to promote the useful exchange of
data between devices manufactured by different vendors. This
Agreement is based on, and employs protocols developed in accord
with, the OSI Reference Model. It provides detailed guidance for
the implementor and eliminates ambiguities in interpretations.
This is an Implementation Agreement for Message Handling Systems
(MHS) based on the CCITT X.400 (1988) series of Recommendations,
the similar (but not identical) ISO MOTIS standard, and
Recommendations F.435 and X.435 (1991) (see References). These
Recommendations and Standards are referred to as the base
standards. The term "MHS" is used to refer to both sources where
a distinction is unnecessary. Similarly, "1984" and "1988" are
often used to distinguish between the CCITT X.400 (1984) series
of Recommendations and the later sources.
This Implementation Agreement seeks to establish a common
specification which is conformant with both CCITT and ISO with a
view to:
a) Preventing a proliferation of incompatible communities
of MHS systems which are isolated for protocol reasons;
b) Achieving interworking with implementations conforming
to the OIW Stable Implementation Agreements for CCITT 1984
X.400-based Message Handling Systems; and,
c) Facilitating integration of other OSI-based services
(e.g., Directory) within a single real system.
This Implementation Agreement is designed to encourage upgrade of
existing 1984-based systems as follows:
a) To add 1988 functionality (Message Store, Remote User
Agent, etc.);
b) To provide additional functionality above the minimal
conformant 1988 MHS defined in the December 1989 version of
the OIW Implementation Agreements. These 1988 aspects are
described in this Agreement as either incremental
enhancements or new functional groups.
However, it is considered that the OIW Stable Implementation
Agreements for CCITT 1984 X.400-based Message Handling Systems
(part 7) should not be withdrawn at this stage. It is anticipated
1
that X.400 (1984) implementations will continue to provide a
viable alternative for applications that do not require the
additional 1988 functionality for some time.
1 Scope
This Agreement specifies the requirements for MHS implementations
based on the 1988 MHS standards.
This Agreement applies equally to Private Management Domains
(PRMDs) and Administration Management Domains (ADMDs). Four
boundary interfaces are specified, as illustrated in figure 1:
a) Management Domain (MD) to MD;
b) Message Transfer Agent (MTA) to MTA within a domain;
c) MTA to remote Message Store (MS) or User Agent (UA);
and,
d) MS to Remote UA.
MHS protocols other than the Message Transfer Protocol (P1), the
Message Transfer System Access Protocol (P3), the Interpersonal
Messaging Protocol (P2), and the Message Store Access Protocol
(P7) are beyond the scope of this Agreement. Issues arising from
the use of other protocols are outside the scope of this
document. This Agreement describes the services provided at each
interface shown in figure 1.
MHS implementations may be configured as any single or multiple
occurrence or combination of MTA, MS and UA, as illustrated in
figure 1. It is not intended to restrict the types of system that
may be configured for conformance to this Agreement (although it
is equally recognized that not all configuration types may be
commercially viable).
2
+----------------------------------------------------------------
--+
|
|
| +------------------------------------------------+
|
| | MD +---+ |
|
| | |UA | |
|
| | +---+ |
|
| | |MTA| |
|
| | +---+ +-+-+ |
|
| | |UA | | |
|
| | +---+ | P1 | +------+
|
| | |MS | | | | MD |
|
| | +---+ P1 +---+ P1 +-+-+ P3 +---+---+ | P1 | |
|
| | |MTA+------+MTA+--------+MTA+--------+MS |UA | +----+ |
|
| | +---+ +---+ +---+ +---+ +---+---+ | | |
|
| | | +---+ | | | |
|
| | +---+ P3| |MS | |P3 +---+ | +------+
|
| | |MS +----+ +-+-+ +----+UA | |
|
| | +-+-+ | P7 +---+ |
|
| | | P7 | |
|
| | +-+-+ +-+-+ |
|
| | |UA | |UA | |
|
| | +---+ +---+ |
|
| +------------------------------------------------+
|
|
|
+----------------------------------------------------------------
--+
3
Figure 1 - Scenario definition
The 1988 MHS standards cover a wide and diverse range of
functional areas, not all of which would be relevant to every
implementation. In order to achieve a more precise definition of
conformance requirements according to the functionality supported
by an implementation, and additionally to facilitate future
enhancement of this initial specification, the concept of
Functional Groups has been introduced. Conformance requirements
for support of Functional Groups by particular configurations are
specified in clause 17.
In the context of these agreements, the term "Support" means that
the service provider makes the element of service (and related
elements of protocol) available to the service user. The service
user provides adequate access to invoke the elements of service
and/or makes information associated with the service element
available. Additionally, for "Not Defined" or "Not Applicable"
elements, the service provider is not required to make the
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 relay those elements.
Naturally, protocol elements marked critical for submission,
transfer, or delivery must be processed according to the base
standards.
The following functional groups are covered by this Implementors
Agreement:
a) The MT Kernel in clause 5;
b) The Message Store in clause 6;
c) Remote User Agent support in clause 7;
d) Distribution Lists in clause 8.3;
e) Use of Directory in clause 8.4;
f) Address support for Teletex character sets in clause
8.5;
g) MHS Management in clause 9 (which is for further study);
h) Security in clause 10;
i) The Physical Delivery Access Unit in clause 11.1;
j) Other Access Units in clause 11.2 (which are for further
study);
4
k) Redirection in clause 12 (which is for further study);
and,
l) The IPM Service in clause 13;
m) The EDI Messaging Service in clause 14 (which is for
further study).
2 References
2.1 CCITT
Application Layer - MHS
CCITT Recommendation X.400 (1988), Message Handling, System and
Service Overview.
CCITT Recommendation X.402 (1988), Message Handling Systems,
Overall Architecture.
CCITT Recommendation X.407 (1988), Message Handling Systems,
Abstract Service Definition Conventions.
CCITT Recommendation X.411 (1988), Message Handling Systems,
Message Transfer System: Abstract Service Definition and
Procedures.
CCITT Recommendation X.413 (1988), Message Handling Systems,
Message Store: Abstract Service Definition.
CCITT Recommendation X.419 (1988), Message Handling Systems,
Protocol Specifications.
CCITT Recommendation X.420 (1988), Message Handling Systems,
Interpersonal Messaging System.
CCITT Recommendation X.121 (1988), International Numbering Plan.
CCITT Recommendation X.435 (1991), Message Handling Systems, EDI
Messaging System, Protocol Specifications.
CCITT Recommendation F.435 (1991), Message Handling Systems, EDI
Messaging System, Abstract Service Definition.
5
2.2 ISO
Application Layer - MHS
ISO 10021-1 Information Processing Systems - Text Communication -
MOTIS - System and Service Overview.
ISO 10021-2 Information Processing Systems - Text Communication -
MOTIS - Overall Architecture.
ISO 10021-3 Information Processing Systems - Text Communication -
MOTIS - Abstract Service Definition Conventions.
ISO 10021-4 Information Processing Systems - Text Communication -
MOTIS - Message Transfer System: Abstract Service Definition and
Procedures.
ISO 10021-5 Information Processing Systems - Text Communication -
MOTIS - Message Store: Abstract Service Definition.
ISO 10021-6 Information Processing Systems - Text Communication -
MOTIS - Protocol Specifications.
ISO 10021-7 Information Processing Systems - Text Communication -
MOTIS - Interpersonal Messaging System.
3 Status
This version of the Implementation Agreements for Message
Handling Systems (MHS) is under development. It is based on the
CCITT X.400 (1988) Recommendations and ISO MOTIS (10021, parts 1-
7) standards, as amended by the MHS Implementors Guide, version
6.
The initial version of these Stable Implementation Agreements
included an Agreement which specified a minimal 1988-based MHS
implementation and support for Message Stores and Remote User
Agents, and which addresses interworking with 1984-based
implementations. This version of the Agreement specifies support
for several additional 1988 features. The remaining features
specified in the 1988 standards will be covered in subsequent
versions of this Agreement.
This initial version has not yet been aligned with other MHS
profiles, so changes may be necessary in the future for
international harmonization, e.g., support for international
character repertoires and conversion.
6
4 Errata
No Errata to Stable material at this time.
5 MT kernel
5.1 Introduction
This clause specifies the requirements for a minimal 1988-based
MTS implementation (i.e., MTA) which is capable of interworking
with 1984-based MTAs. The "base" MT Service specified in this
clause does not include:
a) Message Store (see clause 6);
b) Remote UA (see clause 7);
c) Distribution Lists (see clause 8.3);
d) Use of Directory Services (see clause 8.4);
e) Security (see clause 10);
f) Interworking with Physical Delivery systems or
Specialized Access (see clause 11); and,
g) Conversion of body parts (see clause 13.6.2).
Such a minimal 1988-based MTA will have the following
capabilities in order to achieve interworking with 1984-based
MTAs and to facilitate migration to full 1988 operation:
a) It will be protocol-conformant to 1988 P1;
b) It will downgrade 1988 P1 to 1984 P1 when relaying to
1984-based MTAs, as specified in Annex B of X.419 (see
clause 5.5);
c) It will support both "normal" mode and "X.410-1984"
("passthrough") mode protocol stacks (i.e., as required by
ISO and CCITT respectively); and,
d) A conforming implementation shall obey the criticality
mechanism defined in the base standards. The following
abstract operations are made critical for delivery for these
Implementation Agreements: message token, content integrity
check, and content confidentiality algorithm Id.
7
5.2 Elements of service
This clause specifies the requirements for support of MT Elements
of Service by an MTA conforming to the MT Kernel Functional Group
of this Agreement. Table 1 specifies the support for the basic MT
Kernel elements of service and table 2 specifies the support for
the optional MT Kernel elements of service.
The classification scheme for support of Elements of Service is
as follows:
Mandatory (M): the Element of Service must be supported and
made available to the service user;
Optional (O): the Element of Service may be supported, but
is not required for conformance to this Agreement;
Out of Scope (I): the Element of Service is outside the
scope of these Implementation Agreements;
Not Applicable (-): the Element of Service is not applicable
in the particular context according to the base standard;
and,
To Be Determined (*): the support classification for the
Element of Service has yet to be determined.
The requirements for support of MT Elements of Service for
origination and reception and (where relevant) relaying are
distinguished. Elements of Service which are new in the 1988 MHS
standards are indicated as (1988).
An MTA must support those Basic MT Elements of Service and MT
Optional User Facilities defined in section 19 of X.400 (1988) as
listed and qualified in tables 1 and 2.
Specification of dynamic behavior in these agreements will only
be included in those cases where there is an identified
functional objective which is not satisfied by the specification
of dynamic behavior in the corresponding base standard(s) and
where the resulting behavior does not breach base standard
conformance requirements.
In these exceptional cases, there may be situations where these
agreements must specify the dynamic behavior of an implementation
as distinguished in annex C of ISO TR-10000. Where this occurs,
a table of dynamic conformance requirements will be presented
using the classification scheme below:
Mandatory (M): The element must be implemented although use
8
is not required for conformance to the base standard. The
element shall always be used for conformance to these
agreements.
Excluded (X): This element must either not be implemented,
or it must be possible to prevent use of the element.
NOTE - As stated in clause 6.7 of ISO TR-10000-1,
restrictions by a profile on the dynamic conformance
requirements of a base standard are exceptions, and should
only apply to transmission. Restrictions should not apply to
reception. In the case of Excluded options, it must be
possible to ensure that such options are not initiated or
transmitted. However, it is still possible that an
implementation may receive an Excluded element from an
implementation which does not conform to the same profile.
9
Table 1 - MT kernel: basic MT elements of service
+----------------------------------+-----------+---------+-------
-+
| Element of Service
|Origination|Reception|Relaying|
+----------------------------------+-----------+---------+-------
-+
| Access Management | M1 | M1 | -
|
| Content Type Indication | M | M | -
|
| Converted Indication | M | M | M
|
| Delivery Time Stamp Indication | - | M | -
|
| Message Identification | M | M | -
|
| Non-delivery Notification | M | M | M
|
| Original Encoded Information | | |
|
| Types Indication | M | M | -
|
| Submission Time Stamp Indication | M | M | -
|
| User/UA Capabilities | | |
|
| Registration (1988) | - | M1 | -
|
+----------------------------------+-----------+---------+-------
-+
| Notes
|
| 1 A local matter in the case of collocated UA/MTA and/or
|
| MS/MTA configurations.
|
+----------------------------------------------------------------
-+
10
Table 2 - MT kernel: MT service optional user facilities
+----------------------------------+-----------+---------+-------
-+
| Element of Service
|Origination|Reception|Relaying|
+----------------------------------+-----------+---------+-------
-+
| Alternate Recipient Allowed | M | M2 | -
|
| Alternate Recipient Assignment | - | O2 | -
|
| Conversion Prohibition | M | M | M
|
| Conversion Prohibition in Case | | |
|
| of Loss of Information (1988) | O | O | O
|
| Deferred Delivery | M3 | O | O
|
| Deferred Delivery Cancellation | M6 | - | -
|
| Delivery Notification | M | M | -
|
| Disclosure of Other Recipients | M | M | M
|
| DL Expansion History Indication | - | M4 | -
|
| DL Expansion Prohibited | M5,7 | - | -
|
| Explicit Conversion | O | O | O
|
| Grade of Delivery Selection | M | M | M
|
| Hold for Delivery | - | M1 | -
|
| Implicit Conversion | O | O | O
|
| Latest Delivery Designation (1988| O | O | O
|
| Multi Destination Delivery | M | M | M
|
| Originator Requested Alternate | | |
|
| Recipient (1988) | O | O | -
|
| Prevention of Non-delivery | | |
|
| Notification | M | - | -
|
| Probe | M | M | M
11
|
| Redirection Disallowed by | | |
|
| Originator (1988) | M | M | -
|
| Redirection of Incoming | | |
|
| Messages (1988) | - | O | -
|
| Requested Delivery Method (1988) | MO | MO | -
|
| Restricted Delivery (1988) | - | O | -
|
| Return of Content | O | O | O
|
+----------------------------------+-----------+---------+-------
-+
| Notes
|
| 1 A local matter in the case of collocated UA/MTA and/or
|
| MS/MTA configurations.
|
| 2 If Alternate Recipient Assignment is supported on
|
| reception, then support of Alternate Recipient Allowed is
|
| Mandatory on reception; otherwise, support of Alternate
|
| Recipient Allowed is not applicable on reception.
|
| 3 Support of this MT Element of Service is Mandatory for
|
| conformance reasons, but may be performed as a local
|
| matter to the originating MTA.
|
| 4 Support of this MT Element of Service refers only to the
|
| delivery of DL expansion history and not to the performing
|
| of DL expansion (see clause 8.3).
|
| 5 Support of this MT Element of Service does not imply the
|
| capability to perform DL expansion (see clause 8.3).
|
| 6 Messages should be held in the originating MTA to provide
|
| support for this element of service.
12
|
| 7 Support of this EoS has been made mandatory as the default
|
| is "allowed". Only the capability to generate the
|
| "prohibited" value is required for conformance to the ISP.
|
+----------------------------------------------------------------
-+
5.3 MTS transfer protocol (P1)
The requirements for support of MTS Transfer Protocol (P1)
elements are detailed in clause A.1.
Support of MTS Transfer Protocol application contexts by an MTA
is classified as in table 3.
Table 3 - Application contexts classification
+--------------------------------+------------+
| Application Context | Support |
+--------------------------------+------------+
| mts-transfer-protocol-1984 | Mandatory |
| mts-transfer-protocol | Mandatory |
| mts-transfer | Mandatory |
+--------------------------------+------------+
Use of the underlying services to support these application
contexts is specified in clause 14.10.
5.4 MTS - APDU size
This clause is not intended to constrain the size of PDUs that
are transferred across the network, since some body part types
and content types (e.g., voice, file transfer, and EDI) may
require very large PDUs.
The following agreements govern the size of MTS-APDUs:
a) All MTAEs must support at least one MTS-APDU of at least
two megabytes; and,
b) The size of the largest MTS-APDU content supported by a
UAE is a local matter.
13
5.4.1 Number of recipient names
There is no specified bound on the number of recipient-names an
implementation must support, other than the 32K-1 specified in
the standard (Annex B/X.411).
5.5 1988/84 interworking considerations
An MTA conforming to this Agreement will downgrade 1988 P1 to
1984 P1 when relaying to 1984-based MTAs, as specified in Annex B
of X.419 with the following additional requirements:
a) Supplementary Information - will need to be truncated if
it exceeds the pragmatic constraint identified in Version 2
of these Agreements (64 octets as opposed to 256 octets in
the 1988 MHS standards);
b) ISO DIS 8883 Extensions - An implementation may perform
the mapping of ISO DIS 8883 extensions to existing 1988
services when relevant, but is not obliged to.
Alternatively, it may discard the extensions or generate a
non-delivery report;
c) Internal Trace Information - If the 1984-based MTA does
not support Internal Trace Information per clause 7.3.2 of
part 7, the following description is not applicable. When a
1988-based MTA supports interworking with a 1984-based MTA
that generates Internal Trace Information as per clause
7.3.3 of part 7, the 1988-based MTA must support reception
of the Internal Trace Information by converting the Internal
Trace Information from the form in clause 7.3.2 of part 7 to
the form specified in 1988 X.411, as per the following
description. When the 1988-based MTA sends to a 1984 MTA,
the 1988-based MTA must apply the conversion to 1984, as
described below. The Stable NBS Implementation Agreements
X.400 (1984) definition for MTA's Internal Trace Information
is different from the X.400 (1988) MTA definition.
Consequently, a X.400 (1988) MTA operating in an MD with
other MTAs of 1984 vintage, must map the Internal Trace
Information to and/or from the 1984 format.
Figures 2 and 3 depict algorithms for mapping between X.400
(1988) Internal Trace element formats and the OIW IA X.400 (1984)
Internal Trace element format.
To avoid potential looping within a MD composed of 1984 and 1988
vintage MTAs, MD administrators are strongly advised to name all
MTAs (1984 and 1988 vintages) using only the Printable String
characters. In X.400 (1988) the MTA-Name is defined to be named
14
using IA5 String characters where in the IAs for X.400 (1984)
MTAs, NBS restricted the MTA-Name to be formed using the
Printable String character subset of IA5. If the 1988-based MTA
Name uses IA5 characters not in the Printable String subset, that
Internal Trace Element should be omitted when converting from
1988 to 1984.
+---------------------------------------------------------------+
| For each Internal Trace element in the sequence: |
| DO |
| IF MTA-Name is made up of non-Printable String characters: |
| Discard this Internal Trace element; |
| ELSE |
| { Discard the GlobalDomainIdentifier; |
| Copy the MTAname over; |
| Within the MTASuppliedInformation: |
| Copy the arrival time over; |
| Copy the routing action over; |
| IF attempted is present |
| { IF it is a domain: |
| Discard it; |
| IF it is an MTA: |
| Copy it to Previous MTAName; |
| } |
| IF the additional actions are present: |
| { IF the deferred time is present: |
| Copy it over; |
| IF the other-actions is present: |
| Discard it; |
| } |
| } |
| END-DO |
+---------------------------------------------------------------+
Figure 2 - 1988 to 1984 mapping
15
+---------------------------------------------------------------+
| Find the [APPLICATION 30] entry in the P1 envelope; |
| FOR each Internal Trace element: |
| DO |
| Insert the GlobalDomainIdentifier of this MTA; |
| Copy the MTAName over; |
| Within the MTASuppliedInfo: |
| Copy the arrival time; |
| IF the deferred time is present: |
| copy it to the additional actions field within the |
| 1988 Internal Trace information; |
| IF the routing action is Relayed or Rerouted: |
| copy it over; |
| IF the routing action is Recipient-reassigned: |
| map to Relayed; |
| IF the previous MTAName is present: |
| copy it to the MTAName in the attempted field; |
| |
| END-DO |
+---------------------------------------------------------------+
Figure 3 - 1984 to 1988 mapping
NOTE - The 1988 X.419 Recommendation acknowledges that a
1984 system may receive messages containing new
distinguished [integer] values that it is not expecting, and
that this may result in service irregularities. It is
implied that it would be optimal for 1984 systems to accept
these unexpected integer values if at all possible. No
downgrading should be done for these values when passing
affected messages from newer systems to older systems.
6 Message store
6.1 Introduction
This clause specifies Agreements for implementation of the
Message Store (MS) Functional Group. The MS is responsible for
accepting delivery of messages on behalf of a single end-user,
and retaining the messages until the end-user's UA is able to
retrieve them. Message submission and some administration
services are provided via "pass-through" to the MTS. Figure 4
illustrates the logical relationship of the MS to the UA and MTS.
16
+-------------------------------------------------------------+
| +-------+ RETRIEVAL +-------+ DELIVERY +-------+ |
| | UA +<---------------+ MS +<---------------+ MTS | |
| | | INDIRECT | | | | |
| | | SUBMISSION | | SUBMISSION | | |
| | +--------------->+-------+--------------->+ | |
| | | | | | | |
| | | ADMINISTRATION | | ADMINISTRATION | | |
| | +<-------------->+-------+<-------------->+ | |
| +-------+ +-------+ +-------+ |
+-------------------------------------------------------------+
Figure 4 - Message store model
The Agreements in this clause specify the Message Store's use of
the retrieval, delivery, and administration services. Agreements
on submission services are specified in clause 7, which describes
support for the Remote UA.
The goal of the Agreements in this clause is to define the
minimal set of features which are necessary to provide useful
Message Store services, independent of the MTA implementation
version (i.e., 1984 or 1988).
6.2 Scope
The scope of the Agreements in this clause is depicted in figure
5, and is confined to the services and protocols between the
boundaries shown (marked with asterisks). Requirements for the UA
and MTA are addressed only to the extent that they affect the
Message Store and Remote User Agent services and protocols. This
reflects the additional services required at the UA to support MS
access and at the MTA to support a remote MS.
+---------------------------------------------------------+
| |
| * * |
| | | |
| +-------+ P7 +-------+ P3 +-------+ |
| | UA +--------------+ MS +--------------+ MTA | |
| +-------+ +-------+ +-------+ |
| | | |
| |
+---------------------------------------------------------+
Figure 5 - Scope of message store agreements
The UA, MS and MTA configuration is not restricted; any of these
components may be collocated, although they are depicted as
logically separate. In the case of a collocated UA and MS, a
proprietary interface may be used instead of P7. In the case of a
17
collocated MS and MTA, a proprietary interface may be used
instead of P3.
6.3 Elements of service
This clause specifies the requirements for support of Elements of
Service to provide a Message Store conforming to the Message
Store Functional Group of this Agreement.
The classification scheme for support of Elements of Service is
as defined in clause 5.2.
Support for Elements of Service is specified in table 4 both for
the Message Store itself and for the User Agent.
Table 4 - Message store: elements of service
+-----------------------------------+-------------+-----------+
| Element of Service | UA | MS |
+-----------------------------------+-------------+-----------+
| MS Register | O | M |
| Stored Message Deletion | M | M |
| Stored Message Fetching | M | M |
| Stored Message Listing | M | M |
| Stored Message Summary | M | M |
| Stored Message Alert | O | O |
| Stored Message Auto Forward | O | O |
+-----------------------------------+-------------+-----------+
6.4 Attribute types
Requirements for support of the attributes used in the Message
Store are detailed in clauses A.8 and A.9.
There are two levels of support for General Attributes in the
Message Store.
The Basic MS is intended to support the use of the MS as a
continuously available, reliable device (such as a spooling
entity) for receiving, storing, and forwarding messages and
reports. The Basic MS is not required to support any content-
specific attributes.
The Enhanced MS supports a larger number of general attributes
and is suited to MSs that also support content-specific
attritbutes.
Additionally, support for security attributes is defined in
clause A.9, for use in secure environments.
18
Refer to the content-specific clauses for support for content-
specific attributes.
6.5 Pragmatic constraints for attribute types
There are no additional pragmatic constraints for attribute types
beyond those of the base standards.
6.6 MS access protocol (P7)
The requirements for support of MS Access Protocol (P7) elements
by an MS and a remote MS-user are detailed in clause A.4.
The requirements for support of MS Access Protocol (P7)
application contexts by an MS and an MS-user are as specified in
clauses 6.1 and 10.1 of X.419 (1988) (ISO 10021-6) with the
additional requirement that an MS-user must at least support the
ms-access application context, as defined in table 5.
Table 5 - Application contexts support for P7
+-------------------------+--------------+---------------+
| Application Context | MS | MS-user |
+-------------------------+--------------+---------------+
| ms-access | Mandatory | Mandatory |
| ms-reliable-access | Optional | Optional |
+-------------------------+--------------+---------------+
Use of the underlying services to support these application
contexts is specified in clause 14.10.
6.7 MTS Access Protocol (P3)
The requirements for support of MTS Access Protocol (P3) elements
by an MTA and an MS where the MS is not collocated with the MTA
are detailed in clause A.3.
The requirements for support of MTS Access Protocol (P3)
application contexts by an MTA and an MS in such a scenario are
as specified in sections 6.1 and 10.1 of X.419 (1988) (ISO 10021-
6) with the additional requirement that a remote MS must at least
support the mts-access and mts-forced-access application
contexts, as defined in table 6.
19
Table 6 - Application contexts support for P3
+----------------------------+-----------+-----------+
| Application Context | MTA | MS |
+----------------------------+-----------+-----------+
| mts-access | Mandatory | Mandatory |
| mts-forced-access | Mandatory | Mandatory |
| mts-reliable-access | Optional | Optional |
| mts-forced-reliable-access | Optional | Optional |
+----------------------------+-----------+-----------+
Use of the underlying services to support these application
contexts is specified in clause 14.10.
7 Remote user agent support
7.1 Introduction
This clause specifies Agreements for implementation of the Remote
User Agent Functional Group, i.e., for support of an UA that is
not collocated with its MTA.
The goal of the Agreements in this clause is to define the
minimal set of features which are necessary to provide useful
Remote User Agent services, independent of the MTA implementation
version (i.e., 1984 or 1988), and independent of any particular
content type. The content-specific requirements for UAs are
specified in the content-specific sections of this part of the
Implementor's Agreements.
7.2 Scope
The scope of the Agreements in this clause is depicted in figure
6, and is confined to the services and protocols between the
boundaries shown (marked with asterisks). Requirements for the UA
and MTA are addressed only to the extent that they affect the
Remote User Agent services and protocols. Access to a Message
Store by a Remote User Agent is covered in clause 6.
20
+---------------------------------------------------------+
| |
| * * |
| | | |
| +-------+ P3 +-------+ |
| | UA |-------------------------------------| MTA | |
| +-------+ +-------+ |
| | | |
| |
+---------------------------------------------------------+
Figure 6 - Scope of remote user agent agreements
7.3 Elements of service
This clause specifies the requirements for support of Elements of
Service for conformance to the Remote User Agent Functional Group
of this Agreement.
The classification scheme for support of Elements of Service is
as defined in clause 5.2.
Support for Elements of Service is specified for the MT Service
(table 7) and is in addition to the support requirements
specified in clauses 5 and 13 if this Functional Group is
supported.
Table 7 - Remote user agent support: MT elements of service
+-----------------------------------+-------------+-----------+
| Element of Service | Origination | Reception |
+-----------------------------------+-------------+-----------+
| Access Management | M | M |
| Hold for Delivery | - | M |
| User/UA Capabilities Registration | - | M |
+-----------------------------------+-------------+-----------+
7.4 MTS access protocol (P3)
The requirements for support of MTS Access Protocol (P3) elements
by an MTA and an MTS-user (whether UA or UA/MS) where the MTS-
user is not collocated with the MTA are detailed in clause A.3.
The requirements for support of MTS Access Protocol (P3)
application contexts by an MTA and an MTS-user in such a scenario
are as specified in sections 6.1 and 10.1 of X.419 (1988) (ISO
10021-6) with the additional requirement that a remote MTS-user
must at least support the mts-access and mts-forced-access
application contexts, as defined in table 8.
21
Table 8 - Application contexts support for P3
+----------------------------+-----------+-----------+
| Application Context | MTA | MTS-user |
+----------------------------+-----------+-----------+
| mts-access | Mandatory | Mandatory |
| mts-forced-access | Mandatory | Mandatory |
| mts-reliable-access | Optional | Optional |
| mts-forced-reliable-access | Optional | Optional |
+----------------------------+-----------+-----------+
Use of the underlying services to support these application
contexts is specified in clause 14.10.
8 Naming, addressing & routing
8.1 Use of O/R addresses for routing
Procurers are responsible for understanding the implications of
routing requirements and capabilities.
8.2 ORAddress attribute list equivalence rules
Two ORAddresses are equivalent if each contains the same set of
attributes and each attribute compares in type and value.
The following equivalence rules apply when comparing a provided
ORAddress with a collection of known ORAddresses. For example, in
order to perform delivery of a message to a recipient, the MTA
must unambiguously match the ORAddress contained in the message
with the known ORAddresses. See X.402 (1988), section 18.4, for
the base standard attribute equivalence rules. The following
additional rules must also be applied by the delivering (or non-
delivering) MTA:
a) If the provided ORAddress is an unambiguous
underspecification of a known ORAddress, the ORAddresses are
equivalent. For example, if the initials were omitted, the
ORAddress would still be equivalent. Under-specification
means that some attributes that are not present in the
provided ORAddress are present in the known ORAddresses.
Under-specification does not mean partial value (e.g.,
substring) equivalence when the same set of attributes are
present in the ORAddresses.
b) Over-specified ORAddresses are not equivalent. Over-
specification means that more attributes are present in the
provided ORAddress than are present in the known
22
ORAddresses, however, unrecognized DDA types may be ignored
for these purposes.
c) An ADMD or PRMD name that is all numeric but encoded as
Printable String is considered to be equivalent to the same
ADMD or PRMD name, respectively, with the same numeric
values encoded as Numeric String.
d) An extension attribute encoded as Teletex String shall
be compared with the corresponding standard attribute
encoded as Printable String if that extension attribute is
not present in both ORAddresses. Matching rules are as
specified in clause 18.4 of X.402 (1988) (as modified in the
MHS Implementors' Guide) except that only teletex graphic
characters from repertoire no. 102 need to be compared for
Printable String equivalence (i.e., the presence of graphic
characters from other repertoires can be treated as a
mismatch).
NOTES
1 An X.500 Directory service may or may not support these
matching rules for equivalence.
2 Operational equivalence between T.61 and Printable String
is for further study.
8.3 Distribution lists
8.3.1 Introduction
This clause identifies and specifies the Distribution Lists
Functional Group, which covers all issues relating to the
performance of distribution list (DL) expansion by an MTA. Other
aspects concerned with the use of distribution lists are covered
in the MT Kernel Functional Group.
8.3.2 Elements of service
This clause specifies the requirements for support of Elements of
Service for conformance to the Distribution Lists Functional
Group of this Agreement.
The classification scheme for support of Elements of Service is
as defined in clause 5.2.
Support for Elements of Service is specified for the MT Service
23
only (table 9), and is only concerned with the performance of DL
expansion by an MTA. Such support is in addition to the support
requirements specified in clause 5 if this Functional Group is
supported.
Table 9 - Distribution lists: MT elements of service
+---------------------------------+---------+
| Element of Service | Support |
+---------------------------------+---------+
| DL Expansion History Indication | M |
| DL Expansion Prohibited | M |
| Use of Distribution List | M1 |
+---------------------------------+---------+
| Notes |
| 1 Use of DL Names is always possible |
| because a DL name cannot be |
| distinguished from any other OR Name |
| on origination. |
+-------------------------------------------+
8.4 MHS use of Directory
8.4.1 Introduction
The MHS standards recognize the need of MHS users for a number of
directory service elements. Directory service elements are
intended to assist users, their UAs, and MTAs in obtaining
information for use in submission, delivery, and the transfer of
messages.
NOTE - The MTS may also use the directory service elements
to obtain information, for example, to be used in the
routing of messages. This application of the directory
service is not defined by the base standards and is
therefore not addressed by this Agreement.
8.4.2 Functional configuration
Two MHS functional entities, the UA and MTA, may access the
Directory service using the Directory User Agent (DUA). The
interface between the UA and DUA, or MTA and DUA is local and not
defined. The interaction between the DUA and Directory System
Agent (DSA) is specified in part 11. A collocated DUA and DSA is
also permitted.
24
8.4.3 Functionality
Examples of functional usages of directories have been identified
for UAs and the MTAs in conjunction with their DUAs. These are:
a) UA Specific Functionality:
1) Verify the existence of a Directory Name;
2) Given a partial name, return a list of
possibilities;
3) Search the Directory for entries containing a
specified attribute type and value and return the
Distinguished Names of the matching entries;
4) Return the O/R Address(es) that correspond to a
Directory Name;
5) Determine whether a Directory Name presented
denotes a user or a Distribution List;
6) Return the members of a Distribution List;
7) Return the capabilities of the entity referred to
by a Directory Name;
8) Maintenance functions to keep the directory
up-to-date, e.g., register and change credentials.
b) MTA Specific Functionality:
1) Authentication;
2) Return the O/R Address(es) that correspond to a
Directory Name;
3) Determine whether a Directory Name presented
denotes a user or a Distribution List;
4) Return the members of a Distribution List;
5) Return the capabilities of the entity referred to
by a Directory Name;
6) Maintenance functions to keep the directory
up-to-date.
In addition to functionality, a number of operational aspects
must be considered. These include user-friendliness, flexibility,
25
availability, expandability and reliability.
8.4.4 Naming and attributes
Since user-friendliness is of primary importance in a messaging
system, the naming conventions used in building the Directory
Information Tree (DIT) will impact the ability of a user to make
intelligent guesses for Directory Names.
It is recommended that the naming guidelines and DIT structures
defined in Annex B of Recommendation X.521/ISO 9594-7 be used as
the basis for MHS Directory Names. Annex C of Recommendation
X.402/ISO 10021-2 specifies further the MHS specific object
classes. The naming for MHS specific object classes are
recommended as follows:
a) The naming for mhs-message-store,
mhs-message-transfer-agent, and mhs-user-agent is that of
Application Entity in the DIT;
b) The naming attribute for mhs-distribution-list is
commonName. The organization, organizationalUnit,
organizationalRole, organizationalPerson, locality, or
groupOfNames can be immediate superior to entries of object
class mhs-distribution-list;
c) The naming for mhs-user is that of organizationalPerson,
residentialPerson, organizationalRole, organizationalUnit,
organization, or locality.
NOTE - The mhs-user object class is a generic object class
which may be used in conjunction with another standard
object class for the purpose of adding MHS information
attributes, such as ORAddresses, to a Directory entry. The
means to associate attributes of a generic object class to
an entry (or to different entries) named by a standard
object class(es) is by defining a new (un-)registered object
class, whose superclass(es) is that of the naming object
class(es), and of the generic object class. E.g., to
associate mhs-user attributes in the organizationalPerson
entry, a new unregistered object class can be defined as
shown in figure 7.
26
+---------------------------------------------------------+
| |
| real-user-entry ::= OBJECT CLASS |
| SUBCLASS OF organizationalPerson, |
| mhs-user |
| |
+---------------------------------------------------------+
Figure 7 - Example of unregistered object class definition
The MHS object classes, attributes, and attribute syntaxes that
need to be supported by the Directory are as specified in Annex C
of Recommendation X.402/ISO 10021-2.
In addition, the object classes organization, organizationalUnit,
organizationalRole, organizationalPerson, locality, groupOfNames,
residentialPerson, and country and their attributes and
associated syntaxes as defined in X.520 (ISO 9594, Part 6) and
X.521 (ISO 9594, Part 7) are required to support the MHS.
8.4.5 Elements of service
This clause specifies the requirements for support of Elements of
Service for conformance to the Use of Directory Functional Group
of this Agreement.
The classification scheme for support of Elements of Service is
as defined in clause 5.2.
Support for Elements of Service is specified both for the MT
Service (table 10).
Table 10 - Use of directory: MT elements of service
+-----------------------------+-------------+-----------+-------+
| Element of Service | Origination | Reception | Relay |
+-----------------------------+-------------+-----------+-------+
| Designation of Recipient by | | | |
| Directory Name | M | M | - |
+-----------------------------+-------------+-----------+-------+
8.4.6 Directory services
These Implementation Agreements require the Directory services as
defined in table 11. Indicated are the Directory services
required to support the needs of the MHS UA/MTA and MHS
Administrator.
27
Table 11 - Directory service support requirements
+-----------------------------+--------+-------+
| | MHS | MHS |
| Directory Service | UA/MTA | Admin |
+-----------------------------+--------+-------+
| Bind and Unbind | M | M |
| Read | M | M |
| Compare | M | M |
| Abandon | M | M |
| List | M | M |
| Search | M | M |
| Add Entry | O | M |
| Remove Entry | O | M |
| Modify Entry | M | M |
| Modify RDN | O | O |
+-----------------------------+--------+-------+
8.4.7 OIW X.400 base Directory Implementation Agreements
This clause defines the X.400 base Directory Implementation
Agreements. Its structure and content are based on the
Implementation Agreements template suggested in part 11.
8.4.7.1 Other profiles supported
The OIW X.400 Base Directory Implementation Agreements requires
the support of OIW Directory Common Application Directory
Implementation Agreements as defined in part 11.
8.4.7.2 Standard application specific attributes and attribute
sets
The standard application specific attributes and attributes sets
supported by these Implementation Agreements are listed in table
12. For each attribute and attribute set, a reference is provided
to the standard where it is defined.
28
Table 12 - Standard attributes and attribute sets
+-----------------------------------+------------------+
| Attribute / Attribute Set | References |
+-----------------------------------+------------------+
| mhs-deliverable-content-length | X.402/IS 10021-2 |
| mhs-deliverable-content-types | X.402/IS 10021-2 |
| mhs-deliverable-eits | X.402/IS 10021-2 |
| mhs-dl-members | X.402/IS 10021-2 |
| mhs-dl-submit-permissions | X.402/IS 10021-2 |
| mhs-message-store | X.402/IS 10021-2 |
| mhs-or-addresses | X.402/IS 10021-2 |
| mhs-preferred-delivery-methods | X.402/IS 10021-2 |
| mhs-supported-automatic-actions | X.402/IS 10021-2 |
| mhs-supported-content-types | X.402/IS 10021-2 |
| mhs-supported-optional-attributes | X.402/IS 10021-2 |
+-----------------------------------+------------------+
8.4.7.3 Standard application specific object classes
The standard application specific object classes supported by
these Implementation Agreements are listed in table 13. For each
object class, a reference is provided to the standard where it is
defined.
Table 13 - Standard object classes
+----------------------------+------------------+
| Object Class | References |
+----------------------------+------------------+
| mhs-distribution-list | X.402/IS 10021-2 |
| mhs-message-store | X.402/IS 10021-2 |
| mhs-message-transfer-agent | X.402/IS 10021-2 |
| mhs-user | X.402/IS 10021-2 |
| mhs-user-agent | X.402/IS 10021-2 |
+----------------------------+------------------+
8.4.7.4 OIW application specific attributes and attribute sets
There are no application specific attributes or attribute sets
defined by these Implementation Agreements.
8.4.7.5 OIW application specific object classes
There are no application specific object classes defined by these
Implementation Agreements.
29
8.4.7.6 Structure rules
This clause defines the naming and structure rules for the MHS
object classes which are subclasses of top.
8.4.7.6.1 MHS Distribution List
Attribute commonName is used for naming.
The mhs-distribution-list, organization, organizationalUnit,
organizationalRole, organizationalPerson, locality, or
groupOfNames can be immediately superior to entries of object
class mhs-distribution-list.
8.4.7.6.2 MHS User
The naming for mhs-user is that of organizationalPerson,
residentialPerson, organizationalRole, organizationalUnit,
organization, or locality.
The organizationalPerson, residentialPerson, organizationalRole,
organizationalUnit, organization, or locality object classes can
be combined with the mhs-user object class to form a new
composite object class.
8.4.7.7 Use of Capabilities Information
The capabilities information in the X.500 Directory should not be
considered sufficient to warrant a non-delivery decision by an
originating or relaying MTA. This clause is not intended to
impose any conformance requirement.
8.5 Address support for Teletex character sets
This clause identifies the Address Support for Teletex Character
Sets Functional Group, which covers the generation of Teletex
strings in OR Address components.
Support of this functional group implies that, if an address
component is supported for origination, the corresponding Teletex
component (if any) must be supported for origination.
30
8.6 Reply support
When originating a reply, the UA must be able to utilize the
applicable addressing components of the message to which it is
replying (regardless of character set support level).
9 MHS management
NOTE - For further study.
10 MHS security
10.1 Overview
The Security functional group is specified as three security
classes which are incremental subsets of the security features
available in the base standard. They are denoted as S0, S1, and
S2. An implementation that conforms to the Security functional
group map support one or more of the security classes defined in
these Implementation Agreements.
S0: This security class gathers together security functions
applicable only between MTS-Users. Consequently, security
mechanisms are implemented within the MTS-User. An MTA is
required to support the syntax of the security services on
submission, as the "Kernel" supports the syntax on relay and
delivery. The MTA is not expected to understand the semantics of
the security services.
S1: This security class requires secure functionality with the
MTS-User and MTS. The MTS secure functionality is only required
to achieve secure access management. As with S0, most of the
security mechanisms are implemented within an MTS-User. It
primarily provides integrity and authentication between MTS-
Users. However, MTAs are expected to support digital signatures
for peer to peer authentication, security labelling and security
contexts.
S2: This security class is a superset of S1, adding security
functions within MTAs and the MTS. The main security function
added within this group is authentication within the MTS, and, as
a consequence, due to the non-repudiable nature of the keys used
for authentication, non-repudiation is also added.
In addition, each of the three security classes has a variant,
denoted as S0a, S1a, and S2a, which mandates support of end-to-
end confidentiality.
31
Symmetric or asymmetric techniques (or a combination thereof) may
be used within each security class and are identified by the
registered algorithm identifier.
Various levels of assurance in trusted COMPUSEC functionality may
be used within each security class. This is outside the scope of
this Implementors Agreement.
A full rationale for each of the security classes and a broader
discussion of security considerations are provided in annex E.
Table 14 provides an overview of the requirements made by the
security classes on the MTS-User and MTA. The table entries are
descriptive, and are not intended to refer to security service
elements.
32
Table 14 - Overview of security requirements for each security
class.
+---------+------------------------------------------------------
-------+
| | Requirements
|
|
+------------------------------+------------------------------+
| Class | MTS-User | MTA
|
+---------+------------------------------+-----------------------
-------+
| Kernel | | Submission, delivery,
and |
| | | relay of EoS
|
+---------+------------------------------+-----------------------
-------+
| S0 | Content Integrity, Proof of | Kernel
|
| | Delivery, Message Origin |
|
| | Authentication (UA to UA) |
|
+---------+------------------------------+-----------------------
-------+
| S0a | S0 plus Content | Kernel
|
| | Confidentiality |
|
+---------+------------------------------+-----------------------
-------+
| S1 | S0 plus Message security | Peer entity
authentication, |
| | label, Message security | Security context,
Security |
| | context, Security Management | Management Services,
and |
| | Services | Message Security Label
|
+---------+------------------------------+-----------------------
-------+
| S1a | S1 plus Content | S1
|
| | confidentiality |
|
+---------+------------------------------+-----------------------
-------+
| S2 | S1 plus Message Origin | S1 plus Message Origin
|
33
| | Authentication Check, Probe | Authentication Check,
Prove |
| | Origin Authentication Check, | Origin Authentication
Check, |
| | Report Origin Authentication | Report Origin
Authentication |
| | Check, Proof of Submission, | Check, Proof of
Submission, |
| | and, Non-repudiation | and, Non-repudiation
|
+---------+------------------------------+-----------------------
-------+
| S2a | S1a plus S2 | S1a plus S2
|
+---------+------------------------------+-----------------------
-------+
The incremental functionality of the security classes can be
represented diagrammatically as shown in figure 8.
+------------------------+
| |
| S0 |
| | \ |
| | S0a |
| S1 |
| | \ |
| | S1a |
| S2 |
| \ |
| S2a |
| |
+------------------------+
Figure 8 - Incremental functionality of the security classes
10.2 Common requirements
10.2.1 Interworking between security classes
A security class can be viewed as a tool which can be used to
implement a security policy, and is not a security policy in its
own right but a component of a security policy.
Interworking between implementations supporting different
security classes can be achieved in terms of any common class(es)
supported. As specified in the base standard, the label of the
message, probe or report must be checked against the security
context by any implementation claiming conformance to classes S1,
34
S1a, S2, and S2a.
NOTE - Interworking can be limited to messages of only one
security class by defining a security context consisting of
labels with security policy identifiers of only that
security class.
This profile defines security policy identifiers (annex B, figure
18) that corresponds to the security classes defined in this
section. Such generic security policy identifiers only imply
support of the X.400 security services as specified for these
security classes in this clause. No other COMSEC or COMPUSEC
functionality can be assumed by use of such policy identifiers.
More specific security policies may be based on one or more of
the security classes in this section but will require use of
registered policy identifiers.
10.2.2 Comparison of security labels
The Security Content service ensures that the message security
label matches at least one of the set of labels specified in the
security content established between the communicating MHS
entities.
An MTA which supports the Security Content service shall as a
minimum support matching for equality on the security-policy-
identifier, security-classification, and security-categories
elements of the label.
NOTE - The basic support requirement is that absence of an
element shall not be treated as "any value," i.e., all
permissible combinations of occurrence and value for the
elements of the message security label must be elaborated in
the security context.
Any other matching rules (e.g., covering the privacy-mark element
or based on alternative methods of comparison may be used in
particular application scenarios, but such specification and
usage will be subject to bilateral agreement and will depend on
the security policy in force.
The message security label can be placed in the per-message
extensions or in the signed or encrypted data of the per-
recipient message token. It is recommended that the integrity of
the security label is protected by including it in the token
signed data, or (if the label is in the per-message extensions)
by computing the message origin authentication check on the
message. (Support of MOAC is optional in security classes S0 and
S1.) Which of these labels is/are checked by the security context
35
service is dictated by the security policy in force. The security
policy should also define any requirements on allowable (per-
recipient) label values in the case where the message is
addressed to multiple recipients (and thus has multiple tokens).
A label may also be included in the token encrypted data with
(confidential) end-to-end semantics.
10.2.3 Application context
When providing the peer entity authentication service, it is
recommended that MTAs should not use the "association-recovery"
procedure of RTSE (section 7.8.3 of X.228). MTAs in the role of
sender should not invoke this procedure and MTAs in the role of
receiver should not accept RT-OPEN requests asking for recovery.
NOTE - It is permissible for the sending MTA to perform the
"activity resumption" (sec. 7.8.1 of X.228) on an existing,
authenticated RTSE association owned by this MTA.
10.3 Description of security classes
The sections to follow describe the security classes within the
Security functional group. For each security class, there is a
description of the security functionalities provided, followed by
a table which gives the classification for each of the security
services required by that class. Where the classification of a
security service does not change for a higher security class,
then that security service is not repeated in the table for the
higher security class.
Figure 9 explains the column headings used in the security class
tables. The classifications are defined in clause 5.2.
36
+----------------------------------------------------+
| |
| +-1------------------------------------------+ |
| | +-4----------+ +-7----------+ | |
| ++--++ +----+ ++----+ +----++ +----+ ++--++ |
| | UA | | MS | | MTA | | MTA | | MS | | UA | |
| ++--++ ++--++ ++---++ ++---++ +++-++ ++---+ |
| | +-2--+ +-3--+ +-6--+ +-5--+| +-9--+ |
| +-8--------------------------------+ |
| |
+----------------------------------------------------+
| Legend |
| |
| 1: UA/UA 4: UA/MTA 7: MTA/UA |
| 2: UA/MS 5: MTA/MS 8: MS/Originating UA |
| 3: MS/MTA 6: MTA/MTA 9: MS/Recipient UA |
| |
| |
+----------------------------------------------------+
Figure 9 - Security interfaces
10.4 Security class 0 (S0)
10.4.1 Security functionality
Security measures shall be provided by the MHS implementation in
order to provide the following:
a) Integrity of message content;
b) Authentication of the MTS-User who originated the
message;
c) Authentication of the MTS-User to whom the message was
delivered.
This security class mandates the above services are provided by
an MTS-User.
There are no requirements placed on the MTA.
10.4.2 Security services for S0
Security class 0 (S0) mandates the security services listed in
table 15.
37
Table 15 - Security class 0 (S0)
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Security Interface | 1 | 2 | 3 | 4 | 5 | 6 |
7 | 8 | 9 |
+-------------------------------------+UA/|UA/|MS/|UA/|MTA/|MTA/|
MTA/|MS/|MS/|
| Security Service | UA| MS|MTA|MTA| MS| MTA|
UA| UA| UA|
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Origin Authentication | | | | | | |
| | |
| Message Origin Authentication1 | M | I | - | I | - | - |
- | - | - |
| Probe Origin Authentication | - | I6| -6| I | - | - |
- | - | - |
| Report Origin Authentication | - | - | - | - | I | I |
I | - | - |
| Proof of Submission | - | - | - | - | - | - |
I | - | - |
| Proof of Delivery | M | - | - | - | - | - |
- | M4| - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Secure Access Management | | | | | | |
| | |
| Peer Entity Authentication2,7 | - | O | O | O | O | O |
O | - | O |
| Security Context | - | O | O | O | O | O |
O | - | O |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Data Confidentiality | | | | | | |
| | |
| Connection Confidentiality8 | - | I | I | I | I | I |
I | - | I |
| Content Confidentiality | I | - | - | - | - | - |
- | - | - |
| Message Flow Confidentiality | I | - | - | - | - | - |
- | - | - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Data Integrity Services | | | | | | |
| | |
| Connection Integrity8 | - | I | I | I | I | I |
I | - | I |
| Content Integrity | M | - | - | - | - | - |
- | - | - |
| Message Sequence Integrity11 | O | - | - | - | - | - |
38
- | - | - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Non-Repudiation | | | | | | |
| | |
| Non-Repudiation of Origin1,5 | O | - | - | I | - | - |
- | - | - |
| Non-Repudiation of Submission | - | - | - | - | - | - |
I | - | - |
| Non-Repudiation of Delivery5,10 | O | - | - | - | - | - |
- | O | - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Message Security Labelling2,3 | O | O | O | O | O | O |
O | O | O |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Security Management Services | | | | | | |
| | |
| Change Credentials | - | O | - | O | O | I9 |
O | - | - |
| Register | - | O | - | O | - | - |
- | - | - |
| MS-Register | - | O | - | - | - | - |
- | - | - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
39
Table 15 - Security class 0 (S0) (concluded)
+----------------------------------------------------------------
------------+
| Notes
|
| 1 Only provided to the message recipient.
|
| 2 Using either symmetric or asymmetric algorithms as
identified |
| by the algorithm identifier in the applicable protocol
element. |
| 3 When security labelling is used, the security policy
identifier shall |
| be included.
|
| 4 If Proof of Delivery and Content Confidentiality are both
used, and |
| delivery is to an MS, then proof of delivery can only be
computed on the|
| encrypted content. It should be noted that this will not
provide |
| non-repudiation of delivery.
|
| 5 Using either a trusted notary (symmetric) or using
certificates |
| tokens which are not repudiable (asymmetric).
|
| 6 Corrects table 7 of X.402 in the base standard.
|
| 7 Authentication between collocated objects is a local issue.
|
| 8 Refer to section 10 of X.402 and ISO/IEC 10 021-2 and IS 7498-
2. |
| 9 These services are expected to be provided by non-standard
|
| management services and are therefore outside the scope of
this |
| Implementors Agreement.
|
| 10 Non-Repudiation of Delivery can only be provided when the
|
| proof-of-delivery service is used.
|
| 11 Allocation and management of sequence numbers is outside the
|
| of this Implementors Agreement (as it is subject to
bilateral |
| agreements).
|
+----------------------------------------------------------------
40
------------+
10.5 Security class 0A (S0a)
10.5.1 Security functionality
Security measures shall be provided by the MHS Implementation in
order to provide the following:
a) Security Functionality defined in security class S0;
and,
b) Content Confidentiality.
10.5.2 Security services for S0a
Security class 0A (S0a) mandates the security services of class
S0 plus those listed in table 16.
Table 16 - Security class 0A (S0a)
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Security Interface | 1 | 2 | 3 | 4 | 5 | 6 |
7 | 8 | 9 |
+-------------------------------------+UA/|UA/|MS/|UA/|MTA/|MTA/|
MTA/|MS/|MS/|
| Security Service | UA| MS|MTA|MTA| MS| MTA|
UA| UA| UA|
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Data Confidentiality | | | | | | |
| | |
| Content Confidentiality | M | - | - | - | - | - |
- | - | - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
10.6 Security class 1 (S1)
10.6.1 Security functionality
Security measures shall be provided by the MHS implementation in
order to provide the following:
a) Authentication of MTA, MS, and UA;
41
b) Confidentiality of connections between MTA, MS, and UA;
c) Integrity of message content;
d) Authentication of message originator;
e) Authentication of message delivery (Proof of delivery);
f) MLS-features of MTA, MS, and UA;
g) MLS-separation of messages, probes, and reports; and,
h) MLS-mediation by secure access measures.
NOTES
1 The level of assurance of the MLS trusted components is
subject to bilateral agreement.
2 The level of accountability provided is subject to
bilateral agreement.
10.6.2 Security services for S1
Security class 1 (S1) mandates the security servicesof class S0
plus those listed in table 17.
42
Table 17 - Security class 1 (S1)
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Security Interface | 1 | 2 | 3 | 4 | 5 | 6 |
7 | 8 | 9 |
+-------------------------------------+UA/|UA/|MS/|UA/|MTA/|MTA/|
MTA/|MS/|MS/|
| Security Service | UA| MS|MTA|MTA| MS| MTA|
UA| UA| UA|
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Origin Authentication | | | | | | |
| | |
| Message Origin Authentication2 | M1| I | - | I | - | - |
- | - | - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Secure Access Management | | | | | | |
| | |
| Peer Entity Authentication3,4 | - | M1| M1| M1| M1 | M1 |
M1 | - | M1|
| Security Context | - | M1| M1| M1| M1 | M1 |
M1 | - | M1|
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Data Integrity Services | | | | | | |
| | |
| Content Integrity | M1| - | - | - | - | - |
- | - | - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Message Security Labelling3 | M1| M1| M1| M1| M1 | M1 |
M1 | M1| M1|
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Security Management Services | | | | | | |
| | |
| Change Credentials | - | M | - | M | M | I5 |
M | - | - |
| Register | - | M | - | M | - | - |
- | - | - |
| MS-Register | - | M | - | - | - | - |
- | - | - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Notes
|
| 1 Shall always be used.
|
| 2 Only provided to the message recipient.
43
|
| 3 Using either symmetric or asymmetric algorithms as
identified by |
| the algorithm identifier in the applicable protocol element.
|
| 4 Authentication between collocated objects is a local issue.
|
| 5 These services are expected to be provided by non-standard
|
| management services and are therefore outside the scope of
this |
| Implementors Agreement.
|
+----------------------------------------------------------------
------------+
10.7 Security class 1A (S1a)
10.7.1 Security functionality
Security measures shall be provided by the MHS implementation in
order to provide the following:
a) Security functionality defined for security class S1;
and,
b) Content Confidentiality.
10.7.2 Security services for S1a
Security class 2A (S1a) mandates the security services of class
S1 plus those listed in table 18.
44
Table 18 - Security class 1A (S1a)
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Security Interface | 1 | 2 | 3 | 4 | 5 | 6 |
7 | 8 | 9 |
+-------------------------------------+UA/|UA/|MS/|UA/|MTA/|MTA/|
MTA/|MS/|MS/|
| Security Service | UA| MS|MTA|MTA| MS| MTA|
UA| UA| UA|
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Data Confidentiality | | | | | | |
| | |
| Content Confidentiality | M | - | - | - | - | - |
- | - | - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
10.8 Security class 2 (S2)
10.8.1 Security functionality
Security measures shall be provided by the MHS implementation in
order to provide the following:
a) Security functionality defined for security class S1;
and,
b) Authentication and non-repudiation of messages, probes,
and reports.
10.8.2 Security services for S2
Security class 2 (S2) mandates the security services of class S1
plus those listed in table 19.
45
Table 19 - Security class 2 (S2)
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Security Interface | 1 | 2 | 3 | 4 | 5 | 6 |
7 | 8 | 9 |
+-------------------------------------+UA/|UA/|MS/|UA/|MTA/|MTA/|
MTA/|MS/|MS/|
| Security Service | UA| MS|MTA|MTA| MS| MTA|
UA| UA| UA|
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Origin Authentication | | | | | | |
| | |
| Message Origin Authentication3 | M1| M1| - | M1| - | - |
- | - | - |
| Probe Origin Authentication | - | M4| - | M1| - | - |
- | - | - |
| Report Origin Authentication | - | - | - | - | M1 | M1 |
M1 | - | - |
| Proof of Submission | - | - | - | - | - | - |
- | M | - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Non-Repudiation | | | | | | |
| | |
| Non-Repudiation of Origin | M5| - | - | M2| - | - |
- | - | - |
| Non-Repudiation of Submission | - | - | - | - | - | - |
M2 | - | - |
| Non-Repudiation of Delivery | M5| - | - | - | - | - |
- | M2| - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Notes
|
| 1 Shall always be used.
|
| 2 Using an asymmetric mechanism (i.e., certificates and tokens
which |
| are not repudiable for authentication within MTAs and the
MTS. |
| 3 Using the Message Origin Authentication Check as detailed in
the |
| base standard.
|
| 4 Shall always be used, and corrects table 7 in X.402.
|
| 5 Using either a trusted notary (symmetric) or using
certificates |
| tokens which are not repudiable (asymmetric).
46
|
+----------------------------------------------------------------------------+
10.9 Security class 2A (S2a)
10.9.1 Security functionality
Security measures shall be provided by the MHS implementation in
order to provide the following:
a) Security functionality defined for security class S2;
and,
b) Content Confidentiality.
10.9.2 Security services for S2a
Security class 2A (S2a) mandates the services of class S2 plus
those listed in table 20.
Table 20 - Security class 2A (S2a)
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Security Interface | 1 | 2 | 3 | 4 | 5 | 6 |
7 | 8 | 9 |
+-------------------------------------+UA/|UA/|MS/|UA/|MTA/|MTA/|
MTA/|MS/|MS/|
| Security Service | UA| MS|MTA|MTA| MS| MTA|
UA| UA| UA|
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
| Data Confidentiality | | | | | | |
| | |
| Content Confidentiality | M | - | - | - | - | - |
- | - | - |
+-------------------------------------+---+---+---+---+----+----+
----+---+---+
47
11 Specialized access
11.1 Physical delivery
This clause identifies and specifies the Physical Delivery
Functional Group, which is intended to cover all issues relating
to access to physical delivery systems by an MHS implementation.
11.1.1 Elements of service
This specifies the requirements for support of Elements of
Service for conformance to the Physical Delivery Functional Group
of this Agreement.
The classification scheme for support of Elements of Service is
as defined in clause 5.2.
Support for Elements of Service is specified for:
a) the MT Service in table 21;
b) the O/R Address Attributes in table 22; and,
c) the character string support in table 23.
Editor's Note - table 23 does not appear in this part.
NOTE - All Elements of Service listed in table 21 are 1988.
48
Table 21 - Physical delivery: MT elements of service
+-----------------------------------+----------------+-----------
-----+
| Element of Service | UA Origination | PDAU
Reception |
+-----------------------------------+----------------+-----------
-----+
| Additional Physical Rendition | O | O
|
| Basic Physical Rendition | M | M
|
| Counter Collection | M | M
|
| Counter Collection with Advice | O | O
|
| Delivery via Bureaufax Service | O | O
|
| EMS (Express Mail Service) | MO | MO
|
| Ordinary Mail | M | M
|
| Physical Delivery Notification | |
|
| by MHS | O | O
|
| Physical Delivery Notification | |
|
| by PDS | O | O
|
| Physical Forwarding Allowed | M | M
|
| Physical Forwarding Prohibited | M | M
|
| Registered Mail | O | O
|
| Registered Mail to Addressee | |
|
| in Person | O | O
|
| Request for Forwarding Address | O | O
|
| Special Delivery | MO | MO
|
| Undeliverable Mail with Return | |
|
| of Physical Message | M | M
|
+-----------------------------------+----------------+-----------
-----+
49
Table 22 - Character string support
+------------------+-------------+-----------+
| | Origination | Reception |
| Character String | (UA) | (PDAU) |
+------------------+-------------+-----------+
| Printable | M | M |
| Teletex | O1 | O2 |
+------------------+-------------+-----------+
| Notes |
| 1 Mandatory if "Address Support for |
| Teletex Character Sets" functional |
| group is supported. |
| 2 Mandatory if "Address Support for |
| Teletex Character Sets" functional |
| group is supported, with a minimum |
| of one character repertoire. |
+--------------------------------------------+
11.2 Other access units
11.2.1 Facsimile access units
NOTE - The possible development of Agreements in this area
is for further study.
11.2.2 Telex access units
It is not currently intended to develop Agreements in this area.
11.2.3 Teletex access units
It is not currently intended to develop Agreements in this area.
50
12 Redirection
The redirection functional group is for further study.
13 IPM service
13.1 Introduction
This clause specifies the requirements for a minimal 1988-based
IPMS implementation (i.e., IPM UA) which is capable of
interworking with 1984-based UAs.
Such a minimal 1988-based UA will have the following capabilities
in order to achieve interworking with 1984-based UAs and to
facilitate migration to full 1988 operation:
a) It will continue to support content type P2 (encoded as
integer 2) on origination and reception;
b) It will support receipt of P2 (encoded as integer 22);
c) It may originate P2 encoded as integer 22, but the
guidelines specified in section 8.18.2 of X.420 (1988) are
to be followed, i.e., the content type shall be encoded as
integer 2 unless 1988 P2 protocol elements are present.All
IPM UAs must support either MTS Submission and Delivery
based on the protocol classifications in clause A.3, or MS
Submission and Retrieval based on the protocol
classifications in clause A.4. However, how such information
is conveyed to/from the MTS or MS in the case of a
collocated UA is a local matter, and will not necessarily be
subject to conformance verification.
13.2 Elements of service
This clause specifies the requirements for support of IPM
Elements of Service by a UA conforming to the IPM Kernel
Functional Group of this Agreement.
The classification scheme for support of Elements of Service is
as defined in clause 5.2.
The requirements for support of IPM Elements of Service for
origination and reception are distinguished. Elements of Service
which are new in the 1988 MHS standards are indicated as (1988).
A UA must support those Basic IPM Elements of Service and IPM
51
Optional User Facilities defined in section 19 of X.400 (1988) as
listed and qualified in tables 23 and 24.
Table 23 - IPM kernel: basic IPM elements of service
+----------------------------------------------+------+-------+
| Element of Service | Orig | Recep |
+----------------------------------------------+------+-------+
| Access Management | M1 | M1 |
| Content Type Indication | M | M |
| Converted Indication | - | M |
| Delivery Time Stamp Indication | - | M |
| IP-message Identification | M | M |
| Message Identification | - | M |
| Non-delivery Notification | M | - |
| Original Encoded Information | | |
| Types Indication | M | M |
| Submission Time Stamp Indication | M | M |
| Typed Body | M | M |
| User/UA Capabilities Registration (1988) | - | M1 |
+----------------------------------------------+------+-------+
| Notes |
| 1 In the case of a collocated UA/MTA or collocated |
| UA/MS, the method and extent to which this Element of |
| Service is provided is a local matter; it is not |
| necessarily testable in the absence of support for the |
| P3 or P7 protocol. |
+-------------------------------------------------------------+
52
Table 24 - IPM kernel: IPM service optional user facilities
+----------------------------------------------+------+-------+
| Element of Service1 | Orig | Recep |
+----------------------------------------------+------+-------+
| Alternate Recipient Allowed | O | - |
| Alternate Recipient Assignment | - | O |
| Authorizing Users Indication | O | M |
| Auto-forwarded Indication | O | M |
| Blind Copy Recipient Indication | O | M |
| Body Part Encryption Indication | O | M |
| Conversion Prohibition | M | M |
| Conversion Prohibition in Case of Loss of | | |
| Information (1988) | O | O |
| Cross Referencing Indication | O | M |
| Deferred Delivery | M | - |
| Deferred Delivery Cancellation | OM | - |
| Delivery Notification | M | - |
| Disclosure of Other Recipients | O | M |
| DL Expansion History Indication (1988) | - | M |
| DL Expansion Prohibited (1988) | M | - |
| Expiry Date Indication | O | M |
| Explicit Conversion | O | - |
| Forwarded IP-message Indication | O | M |
| Grade of Delivery Selection | M | M |
| Hold for Delivery | - | O- |
| Implicit Conversion | - | O |
| Importance Indication | O | M |
| Incomplete Copy Indication (1988) | O | O |
| Language Indication (1988) | O | M |
| Latest Delivery Designation (1988) | O | - |
| Multi-Destination Delivery | M | - |
| Multi-part Body | OM | M |
| Non-receipt Notification Request | O | M2 |
| Obsoleting Indication | O | M |
| Originator Indication | M | M |
| Originator Requested Alternate | | |
| Recipient (1988) | O | - |
| Prevention of Non-delivery Notification | O | - |
| Primary and Copy Recipients Indication | M | M |
| Probe | O | - |
| Receipt Notification Request Indication | O | O |
| Redirection Disallowed by Originator (1988) | OM | - |
| Redirection of Incoming Messages (1988) | - | O |
| Reply Request Indication | O | M |
| Replying IP-message Indication | M | M |
| Requested Delivery Method (1988) | MO | - |
+----------------------------------------------+------+-------+
53
Table 25 - IPM kernel: IPM service optional user facilities
(concluded)
+----------------------------------------------+------+-------+
| Element of Service | Orig | Recep |
+----------------------------------------------+------+-------+
| Restricted Delivery (1988) | - | O |
| Return of Content | O | - |
| Sensitivity Indication | O | M |
| Subject Indication | M | M |
| Use of Distribution List (1988) | OM3 | - |
+----------------------------------------------+------+-------+
| Notes |
| 1 Other UA Elements of Service are listed in Table 4. |
| 2 Support of Non-Receipt Notification Request on |
| reception does not require the capability to generate |
| a non-receipt notification in the case of an |
| implementation in which a non-receipt condition cannot |
| occur. |
| 3 Use of a DL on submission is always possible as DLs |
| cannot be distinguished from other O/R addresses. |
+-------------------------------------------------------------+
13.3 Interpersonal messaging protocol (P2)
The requirements for support of Interpersonal Messaging Protocol
(P2) elements are detailed in clause A.2.
13.4 Body part support
This clause specifies the requirements for support of IPM body
part types by a UA conforming to this Agreement.
The requirements for support of IPM body part types for
origination and reception are distinguished. Body part types
which are new in the 1988 MHS standards are indicated as (1988).
A UA must support those IPM body part types defined in Annex E of
X.420 (1988) as listed and qualified in table 33 of Annex A of
this part. If an implementation supports a particular body part
type for reception, it should also be able to support that body
part type for reception if it is part of a forwarded message. If
an implementation supports origination of forwarded messages, it
must be capable of forwarding every body part that is supported
on reception. The reception requirements on the UA do not
necessarily include the ability to render (display) all of the
characters received. If the message is forwarded, the UA must
transmit exactly equivalent characters, but not necessarily from
the same character set.
54
Any basic body part type that is supported on reception must be
supported as integer encoding (ASN.1 context-specific identifier)
and as object identifier (externally-defined) encoding.
All body parts with integer-encoded identifiers in the range 0 up
to and including 16K-1 are legal. Body part integer-encoded
identifiers corresponding to X.121 country codes should be
interpreted as described in figure 10. These privately-defined
body part types are specified as an interim measure to provide
backward compatibility with 1984 MHS implementations. For
interworking between UAs based on the 1988 (or later) MHS
standards, it is strongly recommended that the externally-defined
body part be used instead.
55
+-------------------------------------------------------------+
| BodyPart ::= CHOICE { |
| ia5-text [0] IA5TextBodyPart, |
| . |
| oda-1984 [12] IMPLICIT OCTET STRING, |
| iso-6937 [13] ISO6937BodyPart, |
| bilaterally-defined [14] Unidentified, |
| externally-defined [15] ExternallyDefinedBodyPart, |
| . |
| . |
| [310] IMPLICIT |
| USAPrivatelyDefinedBodyParts,|
| . } |
| |
| Unidentified := OCTET STRING |
| |
| The content of the ODA OCTET STRING will contain a value of |
| type ODABodyPart as follows: |
| |
| ODABodyPart ::= SEQUENCE { |
| ODABodyPartParameters, |
| ODAData } |
| |
| The Parameters and Data components are defined in Annex E |
| of CCITT Recommendation T.411 (1988) (ISO 8613-1). |
| |
| USAPrivatelyDefinedBodyParts are defined as: |
| |
| SEQUENCE {BodyPartNumber, ANY} |
| |
| BodyPartNumber ::= INTEGER |
| |
| These privately-defined body part types are specified as an |
| interim measure to provide backward compatibility with 1984 |
| MHS implementations. For interworking between UAs based on |
| the 1988 (or later) MHS standards, it is strongly |
| recommended that the externally-defined body part be used |
| instead. |
| |
| The undefined bit in P1 EncodedInformationTypes must be set |
| when a message contains a privately defined body part. Each |
| UA that expects such body parts should include undefined in |
| the set of deliverable EncodedInformationTypes it registers |
| with the MTA. |
| |
| Body part numbers are interpreted relative to the body part |
| type in which they are used. OIW registers body part |
| numbers for privately-defined formats within the United |
| States. |
+-------------------------------------------------------------+
56
Figure 10 - Privately-defined body parts
13.5 MS attributes
The IPM MS provides more flexible access to the general
attributes (see clause A.8, table 43, enhanced column) as well as
supporting IPM attributes (see clause A.10).
IPM UAs can make use of either the Basic MS or the IPM MS.
Clause A.10 is to be read in accordance with annex C or
Recommendation X.420 (1988).
An IPM MS requires support from both the General Attributes and
IPM Attributes as specified in clauses A.8 and A.10,
respectively.
13.5.1 Implementation of the IPM MS with 1984 systems
While the Message Store is part of the 1988 MHS standards,
implementation of MS services with a 1984 MTA is possible. In
order to interoperate with other 1984 MHS systems,
implementations with this configuration should adhere to the
following guidelines:
a) The UA must generate 1984 P2 PDUs;
b) The UA must identify the content protocol as integer 2
to the MS;
c) The MS must be collocated with the MTA unless 1988 P3
support is provided on the 1984 MTA as well.
To meet these guidelines, the UA may be implemented as follows:
a) The UA could conform to X.420 (1984), with 1988 UA
extensions for utilizing the MS services;
b) The UA could be a 1988 UA with restrictions on protocol
elements generated and by identifying the content type as
integer 2 rather than 22. No 1988-specific elements should
be generated.
Details of the interface between the 1988 MS and the 1984 MTA
when collocated are beyond the scope of these Agreements.
57
13.6 Body part conversion functional group
13.6.1 General
The Body Part Conversion Functional Group supports the
functionality required to perform the action of message body part
conversion. The Element of Service "Conversion Prohibition" is
made mandatory in the MT Kernel.
13.6.2 Elements of service
The Body Part Conversion Functional Group provides support for
the following Elements of Service.
Table 25 - Conversion: MT elements of service
+------------------------------------------+------------------+
| Element of Service | Support |
+------------------------------------------+------------------+
| Conversion Prohibition in Case | |
| of Loss of Information (1988) | M |
| Explicit Conversion | M1 |
| Implicit Conversion | O1 |
+------------------------------------------+------------------+
| Notes |
| 1 At least one of explicit or implicit conversion must |
| be supported for conformance to this functional group. |
+-------------------------------------------------------------+
Operational Notes
Conversions to and from General Text can only be performed
through implicit conversion. Among possible implicit conversions
are the following:
a) Teletex to General Text;
b) IA5 Text to General Text;
c) General Text to Teletex;
d) General Text to IA5 Text.
13.6.3 Conformance
An implementation conforming to this functional group shall
conform to the procedures for the Elements of Service in clause
13.6.2, and shall obey the rules defined in clauses 14.3.5 and
14.3.9 of X.411 / ISO/IEC 10021-4.
58
The PICS shall document which body part conversions the
implementation can perform, both for implicit and explicit
conversion, and whether "Conversion Prohibition in Case of Loss
of Information" is supported. Conformance to this functional
group does not mandate conversion between any two specific body
part types.
If conversion has to take place and the Element of Service
"Conversion Prohibition in Case of Loss of Information" is
requested, then the MTA is not allowed to perform the conversion
if loss of information may occur, according to the classification
in clause 2.1 of X.408.
If the General Text body part type is supported, the
implementation must support two-way conversion between the
General Text IA5 subrepertoire and the IA5 Text body part.
If a UA is registered to receive multiple Encoded Information
Types and its MTA receives a message for it containing any of
those registered EITs, the corresponding body parts shall not be
converted prior to delivery.
13.7 Security
There are no security requirements to support IPM, above and
beyond those specified in clause 10.
13.8 Error handling
NOTE - For further study.
13.9 Physical delivery
Table 26 specifies the support for physical delivery elements of
service as required by IPM.
59
Table 26 - Physical delivery: IPM elements of service
+-----------------------------------+-------------+-----------+
| | Origination | Reception |
| Element of Service | (IPM UA) | (PDAU) |
+-----------------------------------+-------------+-----------+
| | | |
| Additional Physical Rendition | O | O |
| Basic Physical Rendition | O1 | M |
| Counter Collection | M | M |
| Counter Collection with Advice | O | O |
| Delivery via Bureaufax Service | O | O |
| EMS (Express Mail Service) | M | M2 |
| Ordinary Mail | O1 | M |
| Physical Delivery Notification | | |
| by MHS | O | O |
| Physical Delivery Notification | | |
| by PDS | O | M |
| Physical Forwarding Allowed | O1 | M |
| Physical Forwarding Prohibited | M | M |
| Registered Mail | O | O |
| Registered Mail to Addressee | | |
| in Person | O | O |
| Request for Forwarding Address | O | O |
| Special Delivery | M | M2 |
| Undeliverable Mail with Return | | |
| of Physical Message | O1 | M |
+-----------------------------------+-------------+-----------+
| Notes |
| 1 Provided by default (when using a physical delivery |
| address). |
| 2 Must support EMS and/or Special Delivery. |
+-------------------------------------------------------------+
14 EDI messaging service
14.1 Introduction
This clause specifies the requirements for an EDI Messaging
Service (EDIMS). These requirements are based on
Recommendations X.435 and F.435 which define the P(edi) content
type and outline various EDIMS operational scenarios.
This EDIMS Implementation Agreement separates the functions of
the base standard into a Kernel and optional Functional Groups
(FGs). These functional groups may be used to support the
different scenarios of the EDIMS.
The following functional groups are defined:
60
- EDIMS Security
- EDIMS Forwarding
- EDIMS Multipart Body
- EDIMS Physical Delivery
These agreeements classify the support of these functional groups
as follows:
Table 27 - EDIMS functional groups
+------------------------------------------+------------------+
| Functional Group | Support |
+------------------------------------------+------------------+
| EDIMS Forwarding | O |
| EDIMS Security | O |
| EDIMS Multi Part Body | O |
+------------------------------------------+------------------+
| Notes |
+-------------------------------------------------------------+
14.2 EDIMS Elements of service
Tables 28.1 and 29 specify the requirements for support of EDIMS
EoS by a UA conforming to the EDIMS functional group of this
Agreement. The classification scheme for support of EoS is as
defined in clause 5.2.
61
Table 28 - EDIMS: Basic EDI elements of service
+----------------------------------------------+------+-------+
| Element of Service | Orig | Recep |
+----------------------------------------------+------+-------+
| Access Management | M1 | M1 |
| Content Type Indication | M | M |
| Converted Indication | - | M |
| Delivery Time Stamp Indication | - | M |
| EDI Message Identification | M | M |
| Message Identification | M | M |
| Non-delivery Notification | M | - |
| Original Encoded Information | | |
| Types Indication | M | M |
| Submission Time Stamp Indication | M | M |
| Typed Body | M | M |
| User/UA Capabilities Registration (1988) | - | M1 |
+----------------------------------------------+------+-------+
| Notes |
| 1 In the case of a collocated UA/MTA or collocated |
| UA/MS, the method and extent to which this Element of |
| Service is provided is a local matter; it is not |
| necessarily testable in the absence of support for the |
| P3 or P7 protocol. |
+-------------------------------------------------------------+
62
Table 29 - EDIMS: Optional EDI elements of service
+--------------------------------+----------+-----------------+
| | Kernel | Func. Group |
+--------------------------------+-----+----+-------+----+----+
| Element of Service |Orig |Rec | FG |Orig|Rec |
+--------------------------------+-----+----+-------+----+----+
| Alternate Recipient Allowed | M | M | | | |
| Alternate Recipient Assignment | - | O | | | |
| Application Security Element | O | O1 | SEC-C | M | M |
| Character Set | M | M | | | |
| Content Confidentiality | O | O |SEC-A,B| C7 | C |
| Content Integrity5 | O | O |SEC-A,B| C7 | C |
| Conversion Prohibition | M | M | | | |
| Conversion Prohibition in Case | | | | | |
| of Information Loss (1988) | O | O | | | |
| Cross Reference Information | O | M | MPB | M | M |
| Deferred Delivery | M | - | | | |
| Deferred Delivery Cancellation | M | - | | | |
| Delivery Notification | M | - | | | |
| Designation of Recipient by | | | | | |
| Directory Name | O | - | | | |
| Disclosure of Other Recipients | M | M | | | |
| DL Expansion History Ind.(1988)| - | M | | | |
| DL Expansion Prohibited | M | - | | | |
| EDI Forwarding | O | - | FWD | M | - |
| EDI Message Type(s) | M | M | | | |
| EDI Notification Request | M | M | | | |
| EDI Standard Indication | M | M | | | |
| EDIM Responsibility Forwarding | | | | | |
| Allowed Indication | M | M | | | |
| EDIN Receiver | O | M | FWD | M | M |
| Expiry Date/Time Indication | O | M | | | |
| Explicit Conversion | O | - | | | |
| Grade of Delivery Selection | M | M | | | |
| Hold for Delivery | - | O4 | | | |
| Implicit Conversion | - | O | | | |
| Incomplete Copy Indication | O | M | FWD | O2 | M |
| Interchange Header | M | M | | | |
| Latest Delivery Designation | O | - | | | |
| Message Flow Confidentiality | O | - | | | |
| Message Origin Authentication5 | O | O |SEC-A,B| C7 | C |
| Message Security Labelling | O | O |SEC-A,B| C7 | C |
| Message Sequence Integrity | O | O | | | |
| Multi-Destination Delivery | M | - | | | |
| Multi-Part Body | O | M | MPB | M | M |
| Non-repudiation of Content | | | | | |
| Originated | O | O | SEC-B | M | M |
| Non-repudiation of Content | | | | | |
| Received | O | O | SEC-B | M | M |
| Non-repudiation of Content | | | | | |
63
| Received Request | O | O | SEC-B | M | M |
| Non-repudiation of Delivery | O | O |SEC-A,B| C7 | C |
| Non-repudiation of EDI | | | | | |
| Notification | O | O | SEC-B | M | M |
| Non-repudiation of EDI | | | | | |
| Notification Request | O | O | SEC-B | M | M |
+-------------------------------------------------------------+
Table 29 - EDIMS: Optional EDI elements of service (concluded)
+--------------------------------+----------+-----------------+
| | Kernel | Func. Group |
+--------------------------------+-----+----+-------+----+----+
| Element of Service |Orig |Rec | FG |Orig|Rec |
+--------------------------------+-----+----+-------+----+----+
| Non-repudiation of Origin6 | O | O |SEC-A,B| C7 | C |
| Non-repudiation of Submission | O | O | | | |
| Obsoleting Indication | O | M | | | |
| Originator Indication | M | M | | | |
| Originator Requested Alternate | | | | | |
| Recipient (1988) | O | - | | | |
| Prevention of Non Delivery | | | | | |
| Notification | O | - | | | |
| Probe | O | - | | | |
| Probe Origin Authentication | O | - | | | |
| Proof of Content Received | O | O |SEC-A,B| M | M |
| Proof of Content Received | | | | | |
| Request | O | O |SEC-A,B| M | M |
| Proof of Delivery | O | O | | | |
| Proof of EDI Notification | O | O |SEC-A,B| M | M |
| Proof of EDI Notification | | | | | |
| Request | O | O |SEC-A,B| M | M |
| Proof of Submission | O | - | | | |
| Recipient Indication | M | M | | | |
| Redirection Disallowed by | | | | | |
| Originator | O | - | | | |
| Redirection of Incoming | | | | | |
| Messages (1988) | - | O | | | |
| Related Message(s) | O | M | | | |
| Report Origin Authentication | O | O | | | |
| Requested Delivery Method | M | - | | | |
| Restricted Delivery (1988) | - | O | | | |
| Return of Content3 | O | - | | | |
| Secure Access Management | O | O | | | |
| Services Indication | O | O | | | |
| Stored EDI Message Auto-forward| - | O | | | |
| Use of Distribution List (1988)| O | - | | | |
+--------------------------------+-----+----+-------+----+----+
| Notes |
| 1 This EOS requires a bilateral agreement. |
| 2 Mandatory when an implementation supports the removal |
64
| of body parts. |
| 3 A defect report was submitted to CCITT/ISO by EWOS/ETSI, |
| since the Return of Contents EoS was omitted from the |
| list of EDIMS EoS in F.435. |
| 4 Mandatory if P3 is supported. |
| 5 SEC-A or SEC-B EoS may require the use of these services.|
| 6 SEC-B EoS may require the use of this service. |
| 7 Support of this EOS is dependent on the MHS Security |
| Class implemented to support security class EDI-A |
| (SEC-A) or EDI-B (SEC-B). See clause 10. |
+-------------------------------------------------------------+
14.3 P(EDI) protocol
The requirements for EDI-UA support of the EDI protocol (Pedi)
elements are defined in clause A.11.
14.4 EDIMS Multi-Part Body functional group
14.4.1 General
The EDIMS Multi-Part Body functional group defines the services
and functionality required to support the generation of multiple
body parts in an EDIM. Note that support on reception of Multi-
Part Body is mandatory in the EDIMS Kernel.
14.4.2 Elements of service
The EDIMS Multi-Part Body functional group constitutes support of
the following Elements of Service on origination:
- Cross Reference Information
- Multi-Part Body
14.5 EDI Message Store (EDI-MS)
14.5.1 MS Attributes
65
14.6 Conversion
14.7 EDIMS security functional group
The EDIMS Security functional group defines the services and
functionality required to provide security for EDIMs and EDINs.
These security features are specific to the EDIMS, and are
described in X.435.
As the interface between the EDI Messaging (EDIMG) user and the
EDI-UA is outside the scope of this document, implementations of
the security mechanisms can be implemented as a discrete
hardware/software component or within the EDI-UA.
NOTE - There are alternative methods of providing security
to the EDIMG user. For example, the EDI-UA may just avail
itself of the (content-type independent) security services
provided or supported by the (1988) MHS and described in
section 10 (e.g., content confidentiality, proof of
delivery), without using the additional services of this
functional group. Finally, security services may be
provided within the EDI interchange itself, while possibly
using the EDI Application Security Element to convey some
(bilaterally agreed) security arguments (e.g., key IDs) in
the EDIM header.
The EDIMS Security functional group is specified as two security
classes, denoted EDI-A and EDI-B. Note that the services
provided below are provided, in some cases, by 1988 MHS security
elements in the P1 (and P3) envelope. For example, depending on
the security policy in force, the proof and non repudiation
services below use the Content Integrity Check or Message Origin
Authentication Check protocol elements.
See Section 10 of these Agreements for a description of the 1988
MHS Security functional group and classes. Annex A of these
Agreements outlines support of the security protocol elements by
the MTS.
The security classes EDI-A and EDI-B need the Message Origin
Authentication and Content Integrity EoS. This shall be achieved
either by supporting security class S0, or any other security
class in clause 10, depending on the security policy in force.
NOTE - In order to counter the threat that a message could
be stolen and its value credited to a third party, the use
of content confidentiality is recommended. When using S0A,
the base security EoS shall be used in the following way:
- the Content integrity check shall be generated from the
66
clear content;
- the Content integrity check shall be carried in the
message token;
- Content confidentiality shall be used. Encryption of
the content prevents re-generation of the Content
integrity check by a third party.
14.7.1 EDIMS security class EDI-A (SEC-A)
This class provides proof services; the recipient of an EDI
information object can be assured that it was originated by the
specified EDIMG user. Table 29 outlines support for the EoS
contained in this class.
14.7.2 EDIMS security class EDI-B (SEC-B)
This class provides non repudiation services. These are
"stronger" than the corresponding proof services in the sense
that the recipient of an EDI information object can prove to a
third party that the object was originated by the specified EDIMG
user. Table 29 outlines support for the EoS contained in this
class.
14.7.3 EDIMS security class EDI-C (SEC-C)
The security class EDI-C offers the following Element of Service:
- Application Security Element
This security class mandates that the above service is provided
by an EDIMS end system.
14.8 EDIMS Physical Delivery functional group
14.9 EDIMS Forwarding functional group
14.9.1 General
The EDIMS Forwarding functional group defines the services and
functionality required to perform forwarding of an EDI message by
or on behalf of an EDIMG user.
An EDI-UA or EDI-MS claiming conformance to the EDI Forwarding
functional group shall understand the semantics of the EDIMS
67
abstract operations and service with regard to forwarding, EDI
Notifications and EDIN reasons/diagnostic codes. The EDI-UA or
EDI-MS shall generate appropriate EDI notifications when
accepting, forwarding, or refusing responsibility for the EDI
message. These notifications may be generated automatically by
an EDI-MS or EDI-UA based on the presence or absence of an EDI-MS
in the configuration. In addition, notifications may be
generated as a result of a request by the EDIMG user. Please
refer to Section 17.3.3 of X.435 for a full description of EDI
Forwarding.
An EDI-UA that claims conformance to the EDIMS Forwarding
functional group shall conform to clause A.12, Table 47, as
regards protocol elements required by this functional group.
14.9.2 Elements of service
The EDIMS Forwarding functional group constitutes support of the
following Elements of Service:
- EDI Forwarding
- EDIN Receiver
Conditional on the support of removal of body parts, the EDIMS
Forwarding functional group offers the additional element of
service:
- Incomplete Copy Indication
14.10 Use of Directory
15 Use of underlying layers
15.1 MTS transfer protocol (P1)
The P1 protocol is mapped onto the Reliable Transfer Service
Element (RTSE) either in X.410-1984 mode or in normal mode, as
specified in clause 5.3. In X.410-1984 mode, the RTSE makes
direct use of the services provided by the Session Layer, as
specified in part 5 (Upper Layers) of the Stable Implementation
Agreements. In normal mode, the RTSE makes use of the services
provided by the Association Control Service Element (ACSE) and
Presentation Layer, as defined in part 5 (Upper Layers) of these
Agreements.
68
15.2 MTS access protocol (P3) and MS access protocol (P7)
The P3 and P7 protocols make use of the services provided by the
Remote Operations Service Element (ROSE), Association Control
Service Element (ACSE), Presentation Layer, and, optionally, the
Reliable Transfer Service Element (RTSE), as defined in part 5
(Upper Layers) of these Agreements. It is recommended that RTSE
be used for recovery purposes when the implementation does not
use Transport Class 4 or there is a high probability of an
association failure.
16 Error handling
This clause describes appropriate actions to be taken upon
receipt of protocol elements which are not supported in these
Implementation Agreements: malformed PDUs, unrecognized O/R Name
forms, content errors, errors in reports, and unexpected values
for protocol elements.
An implementation must be able to report all error conditions
which may occur with the appropriate error information as defined
in the referenced base standards. An implementation must be able
to handle receipt of all error indications which are defined in
the referenced base standards. An implementation must also be
tolerant of any additional error indications which are not
currently defined, but is not required to be able to interpret
such error information.
16.1 PDU encoding
Various distinguished integer values will be defined in future
versions of the X.400 standard that are not defined in the 1988
version. When an unknown distinguished value is encountered in
an integer or an enumerated type, it should, in general, not
result in an error. The value should be treated transparently or
ignored, wherever possible.
Editor's Note - It is intended that this section will
specify any special error handling required when unknown
distinguished values are encountered.
69
16.2 Envelope
NOTE - For further study.
16.3 Reports
NOTE - For further study.
16.4 Pragmatic constraints
If an implementation detects a pragmatic constraint violation,
then it may generate an appropriate error indication but is not
required to do so.
17 Conformance
For this clause, the term conformance is as defined in ISO 9646.
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.
In order to achieve a more precise definition of conformance
requirements according to the functionality supported by an
implementation, the concept of Functional Groups has been
introduced. A Functional Group is a set of related Elements of
Service and associated protocol elements which provide a discrete
area of functionality.
Conformance to this Agreement requires as a minimum that all
Mandatory Elements of Service listed in this part are supported
in the manner defined in the MHS standards, as qualified in this
Agreement, for each of the Functional Groups claimed. Any
Optional Elements of Service for which support is claimed must
also be supported as defined in the MHS standards and as
qualified in this Agreement. Pragmatic constraints shall be
observed as specified in the CCITT X.400 (1988) Series of
Recommendations. It is not necessary to implement the recommended
practices of annex D in order to claim conformance to this
Agreement.
Conformance requirements for support of Functional Groups by
particular configuration types (see clause 1) are listed in table
30. An implementation may claim conformance to multiple
configuration types (e.g. "MTA+UA" and "Class B MTA only").
70
Table 30 - Conformance requirements
+------------------------+------------------------------------+
| | Configuration3 |
| +---+---+-----------+---+----+-------+
| |MTA|MTA| MTA Only1 |MS | |UA Only|
| | + | + +---+---+---+ + | MS +---+---+
| Functional Group |UA2|MS | A | B | C | UA|Only|P7 |P3 |
+------------------------+---+---+---+---+---+---+----+---+---+
| MT Kernel | M2| M | M | M | M | - | - | - | - |
| Message Store4 | - | M | - | - | - | M | M | M | - |
| Remote UA | - | - | - | M | - | - | - | - | M |
| Distribution List | O | O | O | O | O | * | - | * | * |
| Directory | O | O | O | O | O | O | O | O | O |
| MHS Management | * | * | * | * | * | * | * | * | * |
| Security | O | O | O | O | O | O | O | O | O |
| Redirection | * | * | * | * | * | * | * | * | * |
| Physical Delivery | * | * | * | * | * | * | * | * | * |
| Other Access Units | * | * | * | * | * | * | * | * | * |
| IPM Service6 | O5| O | O | O | O | O5| O | O5| O5|
| EDI Service6 | O5| O | O | O | O | O5| O | O5| O5|
+------------------------+---+---+---+---+---+---+----+---+---+
| Notes |
| 1 There are three conformance classes defined for the |
| MT Kernel in clause 17.1. |
| 2 Optional elements of a context-specific UA need not be |
| supported in the MT Kernel in this configuration, for |
| example Probe and Deferred Delivery Cancellation. |
| 3 The designation of a '+' in a configuration (e.g., |
| 'MTA+MS') implies that there is no exposed protocol in |
| the interface between the two components. |
| 4 There are two conformance levels defined in clause |
| 17.2 for MS support. |
| 5 At least one of the content-specific functional groups |
| must be supported. |
| 6 The content-specific functional groups may include |
| requirements for levels of support by an MS and/or MTA |
| (e.g., in terms of attributes supported, conversion |
| requirements, etc.). In table 29, the support of a |
| content-specific functional group by the MS only implies |
| support of the MS requirements for that content type |
| (i.e., attribute). Similarly, support in the MTA for a |
| content-specific functional group only implies support |
| for the MTA requirements for that content type (e.g., |
| conversion). |
+-------------------------------------------------------------+
71
17.1 MT Kernel Conformance Classes
The MT Kernel conformance classes are:
a) A class "A" MT Kernel implementation conveys a message,
probe, or report to another MT Kernel using standard means.
A class "A" MT Kernel is specifically implemented in order
to transfer messages, probes, and reports which have
previously been transferred and need not support submission
and delivery. A class "A" MT Kernel may perform other
activities such as originate reports, expand distribution
lists, and perform conversions.
b) A class "B" MT Kernel implementation supports
submission, delivery, and transfer using standard means,
i.e., P3 and P1. A class 'B' MT Kernel need not support the
transfer of previously transferred messages, probes, or
reports.
c) A class "C" MT Kernel implementation requires support
for transfer of messages, probes, and reports to another MT
Kernel using standard means. A class "C" MT Kernel does not
require support for the transfer of previously transferred
messages, probes, and reports, and message submission and
delivery is achieved by non-standard means.
An MTA may conform to one or more of the MT Kernel classes. For
example, a class "B" or "C" MT Kernel which supports the transfer
of previously transferred messages, probes, and reports is also
conformant to a class 'A' MT Kernel. Figure 11 illustrates
several combinations of MT Kernel conformance classes. Additional
combinations are possible.
+------------------------------------------------------+
| +--+ +-------+ +-------+ +--------+ +--+ |
| |UA+----+ MTA | | MTA | | MTA +----+UA| |
| +--+ | +----+ +----+ | +--+ |
| |MS+----+Class B| |Class A| |Class AB+----+MS| |
| +--+ +-------+ +-------+ +---+----+ +--+ |
| | |
| +---+----+ +--+ |
| ---- Standard | MTA +----+UA| |
| | | +--+ |
| ---- Non-standard |Class C +----+MS| |
| +--------+ +--+ |
+------------------------------------------------------+
Figure 11 - MT kernel conformance classes
72
17.2 MS conformance levels
The MS conformance levels are:
a) A Basic MS only requires support for the General
Attributes as specified in clause A.8, basic column of table
43;
b) An enhanced MS requires support for more of the General
Attributes as specified in clause A.8 (enhanced column);
c) A Secure MS additionally requires support for the
attributes as specified in clause A.9.
For content-specific MS requirements, see the appropriate
content-specific clauses.
17.3 EDI-UA conformance
The EDI functional group requires the support of the EDIFACT and
ANSI X12 EDI syntaxes.
18 Management domain agreements
The sections above describe agreements among implementors of
particular X.400 components (e.g., MTAs, UAs, MSs). There are
some agreements that don't apply to a single X.400 component, but
instead apply to an entire domain of X.400 components. This
section details any requirements for X.400 domains, independent
of those for individual X.400 components. A single X.400
component cannot be conformance tested for these domain
requirements, but for a domain to claim to be "operationally OIW
compliant," it must abide by the rules stated below.
18.1 Management domain names
This section contains requirements on matters being considered by
the U. S. CCITT Study Group D for national decisions. Such
decisions are likely to supersede the relevant portions of this
clause.
The Implementation Agreements for 1984-based MHS implementations
requires that all Management Domain Names (both Private and
Administration) shall be unique within the U. S. This is also a
requirement for 1988-based MHS implementations.
A "Construction Syntax" is defined, which uses a registered OSI
73
Organization Name from the ANSI US Register of Organization Names
as a "root" in the construction of MHS Management Domain Names
e.g., ADMD and PRMD). The constructed combinations based on this
"root" will be guaranteed to be unique, and thus be safely used
as MHS MD names in the United States. Other countries may wish to
adopt these same rules.
MHS MD (PRMD and ADMD) names shall be constructed according to
the Extended BNF grammar shown in figure 12.
+----------------------------------------------------------------
------+
| <ADMDName> ::= <MDName>
|
|
|
| <PRMDName> ::= <MDName>
|
|
|
| <MDName> ::=
|
| <NationalOrganizationName> |
|
| <ConstructedName> |
|
| <NationalOrganizationNumber>
|
|
|
| <ConstructedName> ::=
|
|
<NationalOrganizationName>"+"<OrganizationallyDeterminedPart> |
+----------------------------------------------------------------
------+
Figure 12 - Management domain name construction
Subject to all of the following rules:
Rule 1. The entire <MDName> must not exceed 16 bytes
(including any constructor operators that may be included,
and shall be composed entirely of PrintableString
characters.
Rule 2. The <NationalOrganizationName> shall be drawn from
the alphanumeric names registered in the US Register. It
shall contain at least one non-numeric character, and not
contain the constructor operator "+" (plus sign).
74
Rule 3. Each <NationalOrganizationName> obtained from the US
Registry will be accompanied by a NumberForm (numeric value)
which shall be bound as the <NationalOrganizationNumber> to
the <NationalOrganizationName>.
Rule 4. In a <ConstructedName>, the
<OrganizationallyDeterminedPart> shall be certified to be
unique under the <NationalOrganizationName> (sub)authority,
by the <NationalOrganizationName> registration authority.
Rule 5. A <NationalOrganizationNumber> shall be obtained
from the US Register and bound to the <ConstructedName>.
Rule 6. A Private Management Domain's
PrivateDomainIdentifier shall be the same as its
PrivateDomainName.
NOTES
1 The PRMD names resulting from the <ConstructedName>
syntax (those having a "+" in them) are atomic values from
the point of view of the MTA -- in particular, it is not
permissible for the MTA to route on components of the PRMD
name.
2 The construction rules are such that if ABC is a
Registered National Organization Name, then the owner of
that name controls the MHS Domain Name space including "ABC"
and "ABC+<anything>," but not "ABC<anything>."
3 A "+" is legal in an ANSI provided name.
4 If a Registered Organization Name already contains the
construction operator ("+" sign), then in order to use the
name as an <MDName>, its owner must also register the "root"
which precedes the first "+" sign, with the US Register of
Organization Names. (e.g., company B+Z+P would need to
register "B" to be able to use the "constructed" name of
B+Z+P.)
5 For the special case of the construction operator ("+"
sign) being the first character of a Nationally Registered
Name, no special action is required beyond its normal
registration with the US Registry of Organization Names.
6 If the sub-authority determined by
<NationalOrganizationName> so wishes, the
<OrganizationallyDeterminedPart> can be constructed using
rules similar to the above, resulting in a hierarchical
construction separated by "+"s. In particular, the sub-
75
authority must maintain its own registry and might (for
example) define the <OrganizationallyDeterminedPart> using
the syntax
+----------------------------------------------------------------
-------+
| <OrganizationallyDeterminedPart> ::= <DivisionName>
|
| | <DivisionName> "+" <DivisionallyDeterminedPart>
|
+----------------------------------------------------------------
-------+
Figure 13 - Name construction by subauthorities
where the <DivisionName> is drawn from the sub-authority's
registry (and does not contain a "+"). Thus the sub-authority can
delegate the use of the prefix
+----------------------------------------------------------------
-------+
| <NationalOrganizationName>+<DivisionName>
|
+----------------------------------------------------------------
-------+
Figure 14 - Prefix
to someone else.
18.2 Use of ADMD names
This subsection was developed by an X.400 SIG working group in
April, 1990. It contains extremely controversial positions that
invoke national, commercial, and quality of service issues. The
OIW may not be the correct forum to make these national
decisions. Until these decisions can be reached or a national
forum established, this section remains as a placeholder in the
OIW X.400 SIG Working Text document only.
NOTE - Version 2 of the CCITT X.400 Implementors Guide,
dated 16 March 1990, allows for a single zero ("0")
character as the ADMD name for the case of a PRMD that is
not reachable from any ADMD. The following discussion does
not apply to such PRMDs.
A PRMD may be directly connected to more than one ADMD. Since a
PRMD may not alter the originators ORAddress, the Country/ADMD
name pair provided in the Originator ORAddress may not match
those of the first ADMD to receive the message from the PRMD. The
first ADMD is required to accept such messages and may not alter
76
the originator's ORAddress.
Any message originated by a PRMD must have an Originator's
ORAddress that either uses the single space ADMD name or uses a
Country/ADMD name pair for an ADMD to which the PRMD is
connected. (In both cases the Country name is required.)
The X.400 Recommendations have defined a mechanism that enables
PRMDs connected to multiple ADMDs to enter a single space as the
ADMD name. To support this, these agreements recognize two
classes of ADMDs. ADMDs in the first class, "space-supporting"
ADMDs, must be able to route on PRMD name, independently from the
ADMD name. Furthermore, the space-supporting ADMDs must arrange
their routing configuration such that all PRMDs are reachable
from all ADMDs. PRMDs using the single space ADMD name must be
connected to at least one space-supporting ADMD.
ADMDs in the other class, "non-space-supporting" ADMDs, must, at
a minimum, route messages for which the ADMD name is a single
space to a space-supporting ADMD (in the indicated country). It
is hoped that in the long term, all ADMDs will be able to route
on the PRMD name when the ADMD name is a single space.
18.3 Uniqueness of MTS Identifiers within a management domain
When generating an IA5String in an MTS Identifier, each MTA in a
domain must ensure that the string is unique within the domain.
This shall be done by providing an MTA designator with a length
of 12 octets which is unique within the domain, to be
concatenated to a per message string with maximum length of 20
octets.
Two pieces of information, the MTA name and MTA designator, need
to be registered within an MD to guarantee uniqueness. This
registration facility need not be automated. If the MTA name is
less than or equal to 12 characters, it is recommended that it
also be used as the MTA designator.
77
Annex A (normative)
MHS protocol specifications
Tables 31 through 48 specify the requirements for support of MHS
protocol elements for conformance to this Agreement. It should be
noted that the tables specify minimum support for conformance to
the relevant Kernel functional groups and where appropriate also
specify enhanced support requirements where one or more further
functional groups are claimed. All element support is subject to
further review and may be upgraded in later versions of this
Agreement.
Within the classification tables (32-48), the column "S"
indicates the classification from the base standards. This is
provided for reference purposes only and is intended to be in
agreement with the base standards.
The protocol support classification scheme used in this version
of this Agreement is described below. However, it should be noted
that the scheme is currently under review both within the OIW
X.400 SIG and in the EWOS/ETSI MHS groups and is likely to be
revised for later versions of this Agreement.
The classification of support for a protocol element specifies
the requirements for implementations conforming to this Agreement
to be able to generate, receive and process that protocol
element, as appropriate (the 'receiving' role includes relaying
where appropriate). The classification of support for each
protocol element is relative to that for its containing element.
Where sub-elements within a containing element are not listed,
then their support classification shall be assumed to be that of
the containing element. Where the range of values to be supported
for an element is not specified, then all values defined in the
base standard shall be supported.
The classifications have been revised. The former classifications
relate to the classifications in Part 7 of the Stable Agreements
as shown in table 31.
78
Table 31 - Classification changes
+------------------+-------------------------------+
| | New |
| +---------------+---------------+
| Former | Originator | Recipient |
| Category | Category | Category |
+------------------+---------------+---------------+
| Generatable (G) | Mandatory (M) | Mandatory (M) |
| Supported (H) | Optional (O) | Mandatory (M) |
| Mandatory (M) | Mandatory (M) | Mandatory (M) |
| Required (R) | Mandatory (M) | Mandatory (M) |
| Unsupported (X) | Optional (O) | Optional (O) |
+------------------+---------------+---------------+
The support classifications are stated for both Origination and
Reception (O/R) in the following tables (32-48). The defined
support for each is stated within each classification.
Implementations conforming to this Agreement must be capable of
accepting the syntax of every protocol element of a protocol for
which support is claimed. When an MS or MTA receives a protocol
element that according to the base standard should be conveyed to
another MHS entity (MTA, MS, or UA), the MS or MTA is required to
preserve the semantics of that protocol element in the PDU
conveyed. Notwithstanding the above, criticality must be observed
according to the base standard.
Mandatory (M) on Origination: Implementations conforming to
this Agreement shall generate this element in all
information objects in which, according to the base
standards, it shall occur.
Mandatory (M) on Reception: Implementations conforming to
this Agreement shall process this element appropriately
according to its semantics.
Optional (O) on Origination: Where this element is not
conveyed from one MHS entity to another, implementations
conforming to this Agreement may optionally be capable of
generating this protocol element, but are not required to do
so.
Optional (O) on Reception: Implementations conforming to
this Agreement may, but are not required to be capable of
processing this protocol element.
NOTE - Some protocol elements may not be conveyed, if
downgrading rules are applied.
To Be Determined (*): the support classification for this
79
protocol element has yet to be determined.
Not Applicable (-): The protocol element is not applicable
in the particular context according to the base standard.
Where the dynamic behavior of protocol elements need to be
specified, the following classification scheme is used:
Mandatory (m): The protocol element shall always be
implemented and generated. On reception, correct action
shall be taken as specified in the base standard, or as
qualified or specified in these Agreements. Absence of the
corresponding protocol element shall cause the appropriate
abstract error to be generated.
Excluded (x): The protocol element shall not be present or
it must be possible to prevent its use. Its presence shall
cause the appropriate abstract error to be generated.
Dynamic conformance classifications are indicated in a single
column of each of the Protocol Element tables. The classification
applies to the usage only of the protocol elements which have a
static classification.
There are two types of tables defining support for protocol
elements: the first is a base table that contains and classifies
all protocol elements, and the second is a delta table for a
functional group.
Functional group tables need only list those protocol elements
for which the functional group has changed the support
requirements from the base table. Additional containing
constructor elements may be listed in order to provide context
information.
If the functional group changes the support requirements for a
given element it must be classified in the delta table. Changes
should only place more restrictions on the required support, for
example changing an optional element to be either mandatory,
excluded, or out of scope. If an element in the delta table is
not classified, it is only listed for context information and the
required support for it is the same as its classification in the
base table.
The Dynamic column is only filled in if the profile changes the
requirements for use of the element in every PDU, for example, if
support for the element is required, but use of the element is
optional in a given PDU. However, if you are supporting a
functional group that element will always (or never) be used.
80
A.1 MTS transfer protocol (P1)
Within Table 32, the columns under "Support by MT Kernel Class"
refer to the MT Kernel Conformance Classes defined in clause
17.1.
81
Table 32 - Classification of the P1 protocol elements
+------------------------------------------------------+---------
------+
| MTS Transfer Protocol (P1) | Part 1
of 9 |
+-------------------------------------------+----------+---------
------+
| Support by MT Kernel Class | Comments/References
|
+---------------------------------+-+B/C| A
+--------------------------+
| Protocol Element |S|O/R|O/R| See Note 1
|
+---------------------------------+-+---+---+--------------------
------+
| Operations | | | |
|
| | | | |
|
| MTABind |M|M/M|M/M| MTABind
|
| MTAUnbind |M|M/M|M/M|
|
| | | | |
|
| MTSE | | | |
|
| MessageTransfer |M|M/M|M/M|
|
| ProbeTransfer |M|M/M|M/M|
|
| ReportTransfer |M|M/M|M/M| See Note 7
|
| | | | |
|
+---------------------------------+-+---+---+--------------------
------+
| Arguments/Results | | | |
|
| | | | |
|
| MTABind | | | |
|
| ARGUMENT | | | |
|
| <NULL> |O|O/M|O/M| See Note 2
|
| <SET> |O|M/M|M/M|
|
| initiator-name |M|M/M|M/M|
82
|
| initiator-credentials |M|M/M|M/M|
|
| simple |O|M/M|M/M|
|
| strong |O|O/O|O/O|
|
| security-context |O|O/O|O/O|
|
| RESULT | | | |
|
| <NULL> |O|O/M|O/M| See Note 2
|
| <SET> |O|M/M|M/M|
|
| responder-name |M|M/M|M/M|
|
| responder-credentials |M|M/M|M/M|
|
| simple |O|M/M|M/M|
|
| strong |O|O/O|O/O|
|
| | | | |
|
| MTS-APDU | | | |
|
| message |M|M/M|O/M|
|
| envelope |M|M/M|M/M|
MessageTransferEnvelope |
| content |M|M/M|M/M|
|
| probe |M|M/M|O/M|
ProbeTransferEnvelope |
| report |M|M/M|M/M|
|
| envelope |M|M/M|M/M|
ReportTransferEnvelope |
| content |M|M/M|M/M|
ReportTransferContent |
| | | | |
|
| MessageTransferEnvelope | | | |
|
| message-identifier |M|M/M|M/M| MTSIdentifier
|
| originator-name |M|M/M|M/M| ORName
|
| original-encoded-information- | | | |
83
|
| types |O|M/M|O/O|
EncodedInformationTypes |
| content-type |M|M/M|M/M|
|
| built-in |O|M/M|O/O|
|
| external |O|O/M|O/O|
|
+---------------------------------+-+---+---+--------------------
------+
84
Table 32 - Classification of the P1 protocol elements (continued)
+------------------------------------------------------+---------
------+
| MTS Transfer Protocol (P1) | Part 2
of 9 |
+-------------------------------------------+----------+---------
------+
| Support by MT Kernel Class | Comments/References
|
+---------------------------------+-+B/C| A
+--------------------------+
| Protocol Element |S|O/R|O/R| See Note 1
|
+---------------------------------+-+---+---+--------------------
------+
| content-identifier |O|O/M|O/O|
|
| priority |O|M/M|O/M| All values
|
| per-message-indicators |O|M/M|O/M|
|
| disclosure-of-recipients |O|O/M|O/M|
|
| implicit-conversion-prohibited|O|M/M|O/M|
|
| alternate-recipient-allowed |O|M/M|O/O|
|
| content-return-request |O|O/O|O/O|
|
| deferred-delivery-time |O|O/O|O/O|
|
| per-domain-bilateral- | | | |
|
| information |O|O/O|O/O|
PerDomainBilateralInfo |
| trace-information |M|M/M|M/M| TraceInformation
|
| extensions |O|M/M|M/M| ExtensionField
|
| recipient-reassignment- | | | |
|
| prohibited |O|M/M|M/M|
|
| dl-expansion-prohibited |O|M/M|O/M|
|
| conversion-with-loss- | | | |
|
| prohibited |O|O/M|O/M|
|
| latest-delivery-time |O|O/O|O/O| See X.411, 14.1.1
85
note 2 |
| originator-return-address |O|O/O|O/O|
|
| originator-certificate |O|O/O|O/O|
|
| content-confidentiality- | | | |
|
| algorithm-identifier |O|M/M|M/M| See Note 6
|
| message-origin- | | | |
|
| authentication-check |O|O/O|O/O|
|
| message-security-label |O|O/O|O/O| See Note 5
|
| security-policy-identifier |O|M/M|M/M|
|
| security-classification |O|M/M|M/M|
|
| privacy-mark |O|O/O|O/O|
|
| security-categories |O|M/M|M/M|
|
| content-correlator |O|O/O|O/O|
|
| dl-expansion-history |O|O/M|O/M| DLExpansionHistory
|
| internal-trace-information |O|M/M|M/M| InternalTraceInfo
|
| per-recipient-fields |M|M/M|M/M|
|
| recipient-name |M|M/M|M/M| ORName
|
| originally-specified- | | | |
|
| recipient-number |M|M/M|M/M|
|
| per-recipient-indicators |M|M/M|M/M|
|
| explicit-conversion |O|O/O|O/O|
|
| extensions |O|O/M|O/M| ExtensionField
|
| originator-requested- | | | |
|
| alternate-recipient |O|O/O|O/O|
|
| requested-delivery-method |O|M/M|O/M|
|
| physical-forwarding- | | | |
86
|
| prohibited |O|O/O|O/O|
|
| physical-forwarding-address- | | | |
|
| request |O|O/O|O/O|
|
| physical-delivery-modes |O|O/O|O/O|
|
+---------------------------------+-+---+---+--------------------
------+
87
Table 32 - Classification of the P1 protocol elements (continued)
+------------------------------------------------------+---------
------+
| MTS Transfer Protocol (P1) | Part 3
of 9 |
+-------------------------------------------+----------+---------
------+
| Support by MT Kernel Class | Comments/References
|
+---------------------------------+-+B/C| A
+--------------------------+
| Protocol Element |S|O/R|O/R| See Note 1
|
+---------------------------------+-+---+---+--------------------
------+
| registered-mail-type |O|O/O|O/O|
|
| recipient-number-for-advice |O|O/O|O/O|
|
| physical-rendition-attributes|O|O/O|O/O|
|
| physical-delivery-report- | | | |
|
| request |O|O/O|O/O|
|
| message-token |O|O/O|O/O|
|
| asymmetric-token |O|M/M|M/M| See Note 5
|
| signature-algorithm- | | | |
|
| identifier |M|M/M|M/M|
|
| name |M|M/M|M/M|
|
| time |M|M/M|M/M|
|
| sign-data |O|M/M|M/M|
|
| content-confidentiality- | | | |
|
| algorithm-identifier |O|M/M|M/M|
|
| content-integrity-check |O|M/M|M/M|
|
| message-security-label |O|O/O|O/O|
|
| proof-of-delivery-request |O|M/M|M/M|
|
| message-sequence-number |O|O/O|O/O|
88
|
| encryption-algorithm- | | | |
|
| identifier |O|M/M|M/M|
|
| encrypted-data |O|M/M|M/M|
|
| content-confidentiality-key|O|M/M|M/M|
|
| content-integrity-check |O|M/M|M/M|
|
| message-security-label |O|O/O|O/O|
|
| content-integrity-key |O|O/O|O/O|
|
| message-sequence-number |O|O/O|O/O|
|
| content-integrity-check |O|M/M|M/M| See Note 6
|
| proof-of-delivery-request |O|M/M|M/M| See Note 6
|
| redirection-history |O|O/M|O/M|
|
| | | | |
|
| ProbeTransferEnvelope | | | |
|
| probe-identifier |M|M/M|M/M| MTSIdentifier
|
| originator-name |M|M/M|M/M| ORName
|
| original-encoded-information- | | | |
|
| types |O|M/M|O/O|
EncodedInformationTypes |
| content-type |M|M/M|M/M|
|
| built-in |O|M/M|O/O|
|
| external |O|O/M|O/O|
|
| content-identifier |O|O/M|O/O|
|
| content-length |O|M/M|O/O|
|
| per-message-indicators |O|M/M|O/M|
|
| disclosure-of-recipients |O|O/O|O/O|
|
| implicit-conversion-prohibited|O|M/M|O/M|
89
|
| alternate-recipient-allowed |O|M/M|O/O|
|
| content-return-request |O|O/O|O/O|
|
| per-domain-bilateral- | | | |
|
| information |O|O/O|O/O|
PerDomainBilateralInfo |
+---------------------------------+-+---+---+--------------------
------+
90
Table 32 - Classification of the P1 protocol elements (continued)
+------------------------------------------------------+---------
------+
| MTS Transfer Protocol (P1) | Part 4
of 9 |
+-------------------------------------------+----------+---------
------+
| Support by MT Kernel Class | Comments/References
|
+---------------------------------+-+B/C| A
+--------------------------+
| Protocol Element |S|O/R|O/R| See Note 1
|
+---------------------------------+-+---+---+--------------------
------+
| trace-information |M|M/M|M/M| TraceInformation
|
| extensions |O|M/M|M/M| ExtensionField
|
| recipient-reassignment- | | | |
|
| prohibited |O|O/O|O/O|
|
| dl-expansion-prohibited |O|M/M|O/M|
|
| conversion-with-loss- | | | |
|
| prohibited |O|O/O|O/O|
|
| originator-certificate |O|O/O|O/O|
|
| message-security-label |O|O/O|O/O|
|
| content-correlator |O|O/O|O/O|
|
| probe-origin-authentication- | | | |
|
| check |O|O/O|O/O|
|
| dl-expansion-history |O|O/M|O/M| DLExpansionHistory
|
| internal-trace-information |O|M/M|M/M| InternalTraceInfo
|
| per-recipient-fields |M|M/M|M/M|
|
| recipient-name |M|M/M|M/M| ORName
|
| originally-specified- | | | |
|
| recipient-number |M|M/M|M/M|
91
|
| per-recipient-indicators |M|M/M|M/M|
|
| explicit-conversion |O|O/O|O/O|
|
| extensions |O|O/M|O/M| ExtensionField
|
| originator-requested- | | | |
|
| alternate-recipient |O|O/O|O/O|
|
| requested-delivery-method |O|M/M|O/M|
|
| physical-rendition-attributes|O|O/O|O/O|
|
| redirection-history |O|O/M|O/M|
|
| | | | |
|
| ReportTransferEnvelope | | | |
|
| report-identifier |M|M/M|M/M| MTSIdentifier
|
| report-destination-name |M|M/M|M/M| ORName
|
| trace-information |M|M/M|M/M| TraceInformation
|
| extensions |O|M/M|M/M| ExtensionField
|
| message-security-label |O|O/O|O/O|
|
| originator-and-DL-expansion- | | | | OriginatorAndDL
|
| history |O|M/M|O/O| ExpansionHistory
|
| reporting-DL-name |O|O/O|O/O|
|
| reporting-MTA-certificate |O|O/O|O/O|
|
| report-origin-authentication- | | | |
|
| check |O|O/O|O/O|
|
| internal-trace-information |O|M/M|M/M| InternalTraceInfo
|
| | | | |
|
| ReportTransferContent | | | |
|
| subject-identifier |M|M/M|M/M| MTSIdentifier
92
|
| subject-intermediate-trace- | | | |
|
| information |O|M/M|M/M| TraceInformation
|
| original-encoded-information- | | | |
|
| types |O|M/M|M/M|
EncodedInformationTypes |
+---------------------------------+-+---+---+--------------------
------+
93
Table 32 - Classification of the P1 protocol elements (continued)
+------------------------------------------------------+---------
------+
| MTS Transfer Protocol (P1) | Part 5
of 9 |
+-------------------------------------------+----------+---------
------+
| Support by MT Kernel Class | Comments/References
|
+---------------------------------+-+B/C| A
+--------------------------+
| Protocol Element |S|O/R|O/R| See Note 1
|
+---------------------------------+-+---+---+--------------------
------+
| content-type |O|M/M|M/M|
|
| built-in |O|M/M|M/M|
|
| external |O|M/M|M/M|
|
| content-identifier |O|M/M|M/M|
|
| returned-content |O|O/M|O/O|
|
| additional-information |O|O/O|O/O|
|
| extensions |O|O/M|O/M| ExtensionField
|
| content-correlator |O|O/M|O/M|
|
| per-recipient-fields |M|M/M|M/M|
|
| actual-recipient-name |M|M/M|M/M| ORName
|
| originally-specified- | | | |
|
| recipient-number |M|M/M|M/M|
|
| per-recipient-indicators |M|M/M|M/M|
|
| last-trace-information |M|M/M|M/M|
|
| arrival-time |M|M/M|M/M|
|
| converted-encoded- | | | |
|
| information-types |O|M/M|M/M|
EncodedInformationTypes |
| report |M|M/M|M/M|
94
|
| delivery |O|M/M|O/O|
|
| message-delivery-time |O|M/M|M/M|
|
| type-of-MTS-user |O|M/M|O/O|
|
| non-delivery |O|M/M|M/M|
|
| non-delivery-reason-code |O|M/M|M/M|
|
| non-delivery-diagnostic- | | | |
|
| code |O|O/M|O/M|
|
| originally-intended-recipient-| | | |
|
| name |O|M/M|M/M| ORName
|
| supplementary-information |O|O/O|O/O|
|
| extensions |O|M/M|M/M| ExtensionField
|
| redirection-history |O|M/M|M/M| RedirectionHistory
|
| physical-forwarding-address |O|O/O|O/O|
|
| recipient-certificate |O|O/O|O/O|
|
| proof-of-delivery |O|O/O|O/O|
|
| | | | |
|
| Common Data Types | | | |
|
| EncodedInformationTypes | | | |
|
| built-in-encoded-information- | | | |
|
| types |M|M/M|M/M| See Note 3
|
| non-basic-parameters |O|O/O|O/O|
|
| external-encoded-information- | | | |
|
| types |O|O/M|O/M|
|
| | | | |
|
| MTSIdentifier | | | |
95
|
| global-domain-identifier |M|M/M|M/M|
GlobalDomainIdentifier |
| local-identifier |M|M/M|M/M|
|
| | | | |
|
| | | | |
|
+---------------------------------+-+---+---+--------------------
------+
96
Table 32 - Classification of the P1 protocol elements (continued)
+------------------------------------------------------+---------
------+
| MTS Transfer Protocol (P1) | Part 6
of 9 |
+-------------------------------------------+----------+---------
------+
| Support by MT Kernel Class | Comments/References
|
+---------------------------------+-+B/C| A
+--------------------------+
| Protocol Element |S|O/R|O/R| See Note 1
|
+---------------------------------+-+---+---+--------------------
------+
| | | | |
|
| PerDomainBilateralInfo | | | |
|
| country-name |M|M/M|M/M|
|
| administration-domain-name |O|M/M|M/M| DomainName
|
| private-domain-identifier |O|M/M|M/M| DomainName
|
| | | | | (only encoded as
SEQ if |
| | | | | both present)
|
| bilateral-information |M|M/M|M/M|
|
| | | | |
|
| TraceInformation | | | |
|
| TraceInformationElement |M|M/M|M/M|
|
| global-domain-identifier |M|M/M|M/M|
GlobalDomainIdentifier |
| domain-supplied-information |M|M/M|M/M|
|
| arrival-time |M|M/M|M/M|
|
| routing-action |M|M/M|M/M|
|
| relayed |O|M/M|M/M|
|
| rerouted |O|O/M|O/M|
|
| attempted-domain |O|O/M|O/M|
97
GlobalDomainIdentifier |
| deferred-time |O|M/M|M/M|
|
| converted-encoded- | | | |
|
| information-types |O|O/M|O/M|
EncodedInformationTypes |
| other-actions |O|O/M|O/M|
|
| redirected |O|O/M|O/M|
|
| dl-operation |O|O/M|O/M|
|
| | | | |
|
| ExtensionField | | | |
|
| type |M|M/M|M/M|
|
| criticality |O|O/M|O/M|
|
| for-submission |O|O/O|O/O|
|
| for-transfer |O|M/M|M/M|
|
| for-delivery |O|M/M|M/M|
|
| value |M|M/M|M/M|
|
| | | | |
|
| DLExpansionHistory | | | |
|
| DLExpansion |M|M/M|M/M|
|
| ORAddressAndOptionalDirectory | | | |
|
| Name |M|M/M|M/M| ORName
|
| dl-expansion-time |M|M/M|M/M|
|
+---------------------------------+-+---+---+--------------------
------+
98
Table 32 - Classification of the P1 protocol elements (continued)
+------------------------------------------------------+---------
------+
| MTS Transfer Protocol (P1) | Part 7
of 9 |
+-------------------------------------------+----------+---------
------+
| Support by MT Kernel Class | Comments/References
|
+---------------------------------+-+B/C| A
+--------------------------+
| Protocol Element |S|O/R|O/R| See Note 1
|
+---------------------------------+-+---+---+--------------------
------+
| InternalTraceInformation | | | |
|
| InternalTraceInformationElement|M|M/M|M/M|
|
| global-domain-identifier |M|M/M|M/M|
GlobalDomainIdentifier |
| mta-name |M|M/M|M/M|
|
| mta-supplied-information |M|M/M|M/M|
|
| arrival-time |M|M/M|M/M|
|
| routing-action |M|M/M|M/M|
|
| relayed |O|M/M|M/M|
|
| rerouted |O|O/M|O/M|
|
| attempted |O| | |
|
| mta |O|O/M|O/M|
|
| domain |O|O/M|O/M|
GlobalDomainIdentifier |
| deferred-time |O|O/M|O/M|
|
| converted-encoded-information| | | |
|
| -types |O|O/M|O/M|
EncodedInformationTypes |
| other-actions |O|O/M|O/M|
|
| redirected |O|O/M|O/M|
|
| dl-operation |O|O/M|O/M|
99
|
| | | | |
|
| OriginatorAndDLExpansionHistory | | | |
|
| originator-or-dl-name |M|M/M|M/M|
|
| origination-or-expansion-time |M|M/M|M/M|
|
| | | | |
|
| RedirectionHistory | | | |
|
| Redirection |M|M/M|M/M|
|
| intended-recipient-name |M|M/M|M/M|
|
| ORAddressAndOptionalDirectory| | | |
|
| Name |M|M/M|M/M| ORName
|
| redirection-time |M|M/M|M/M|
|
| redirection-reason |M|M/M|M/M|
|
| | | | |
|
| ORName | | | |
|
| address |M|M/M|M/M|
|
| standard-attributes |M|M/M|M/M|
|
| country-name |O|M/M|O/M| CountryName
|
| administration-domain-name |O|M/M|O/M| DomainName
|
| network-address |O|M/M|O/M|
|
| terminal-identifier |O|M/M|O/M|
|
| private-domain-name |O|M/M|O/M| DomainName
|
| organization-name |O|M/M|O/M|
|
| numeric-user-identifier |O|M/M|O/M|
|
| personal-name |O|M/M|O/M|
|
| surname |M|M/M|O/M|
100
|
| given-name |O|M/M|O/M|
|
| initials |O|M/M|O/M| See Note 4
|
| generation-qualifier |O|M/M|O/M|
|
| organizational-unit-names |O|M/M|O/M|
|
+---------------------------------+-+---+---+--------------------
------+
101
Table 32 - Classification of the P1 protocol elements (continued)
+------------------------------------------------------+---------
------+
| MTS Transfer Protocol (P1) | Part 8
of 9 |
+-------------------------------------------+----------+---------
------+
| Support by MT Kernel Class | Comments/References
|
+---------------------------------+-+B/C| A
+--------------------------+
| Protocol Element |S|O/R|O/R| See Note 1
|
+---------------------------------+-+---+---+--------------------
------+
| OrganizationUnitName |M|M/M|O/M|
|
| domain-defined-attributes |O|M/M|O/M|
|
| DomainDefinedAttribute |M|M/M|O/M|
|
| type |M|M/M|M/M|
|
| value |M|M/M|M/M|
|
| extension-attributes |O|O/M|O/M| ExtensionAttribute
|
| common-name |O|O/M|O/M|
|
| teletex-common-name |O|O/M|O/M|
|
| teletex-organization-name |O|M/M|O/M|
|
| teletex-personal-name |O|M/M|O/M|
|
| teletex-organizational-unit- | | | |
|
| names |O|M/M|O/M|
|
| teletex-domain-defined- | | | |
|
| attributes |O|M/M|O/M|
|
| pds-name |O|O/M|O/M|
|
| physical-delivery-country- | | | |
|
| name |O|O/M|O/M|
|
| postal-code |O|O/M|O/M|
102
|
| physical-delivery-office-name|O|O/M|O/M|
|
| physical-delivery-office- | | | |
|
| number |O|O/M|O/M|
|
| extension-OR-address- | | | |
|
| components |O|O/M|O/M|
|
| physical-delivery-personal- | | | |
|
| name |O|O/M|O/M|
|
| physical-delivery- | | | |
|
| organization-name |O|O/M|O/M|
|
| extension-physical-delivery- | | | |
|
| address-components |O|O/M|O/M|
|
| unformatted-postal-address |O|O/M|O/M|
|
| street-address |O|O/M|O/M|
|
| post-office-box-address |O|O/M|O/M|
|
| poste-restante-address |O|O/M|O/M|
|
| unique-postal-name |O|O/M|O/M|
|
| local-postal-attributes |O|O/M|O/M|
|
| extended-network-address |O|O/M|O/M|
|
| terminal-type |O|O/M|O/M|
|
| directory-name |O|O/O|O/O|
|
| | | | |
|
| ExtensionAttribute | | | |
|
| extension-attribute-type |M|M/M|M/M|
|
| extension-attribute-value |M|M/M|M/M|
|
| | | | |
103
|
| GlobalDomainIdentifier | | | |
|
| country-name |M|M/M|M/M| CountryName
|
| administration-domain-name |M|M/M|M/M| DomainName
|
| private-domain-identifier |O|M/M|O/M| DomainName
|
+---------------------------------+-+---+---+--------------------
------+
104
Table 32 - Classification of the P1 protocol elements (concluded)
+------------------------------------------------------+---------
------+
| MTS Transfer Protocol (P1) | Part 9
of 9 |
+-------------------------------------------+----------+---------
------+
| Support by MT Kernel Class | Comments/References
|
+---------------------------------+-+B/C| A
+--------------------------+
| Protocol Element |S|O/R|O/R| See Note 1
|
+---------------------------------+-+---+---+--------------------
------+
| | | | |
|
| CountryName | | | |
|
| x121-dcc-code |O|O/M|O/M|
|
| iso-3166-alpha2-code |O|M/M|O/M|
|
| | | | |
|
| DomainName | | | |
|
| numeric |O|O/M|O/M|
|
| printable |O|M/M|O/M|
|
| | | | |
|
+---------------------------------+-+---+---+--------------------
------+
| Notes
|
| 1 The MT Kernel implementation classes are defined in
|
| clause 17.1.
|
| 2 The action to be taken on receipt of null MTABind
|
| authentication is that an implementation must understand the
|
| semantics, but the form of authentication that is acceptable
|
| is a local matter.
|
| 3 An implementation is only required to generate EITs that
105
|
| correspond to the body parts it is capable of generating.
|
| 4 If the initials component of personal-name attribute is
used, |
| it should comprise all of the person's initials (including
the |
| given name) except the person's surname, as specified in
|
| X.402/IS 10021-2.
|
| 5 All S0 services may be provided without using the message
token, |
| e.g., using per-message extensions.
|
| 6 In secure messaging, use of elements within the message
token is |
| preferred to use of equivalent elements in the subject
message |
| envelope. A security policy shall define which other
elements |
| are dynamically mandated and shall define which message
security |
| labels are used for security context checking.
|
| 7 In the absence of any specific processing requirements for a
|
| particular element in the Message Transfer or Probe
Transfer, |
| the action to be taken is simply the creation of the
|
| corresponding element in the Report Transfer and is subject
to |
| constraints specified in X.411.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
106
|
|
|
+----------------------------------------------------------------
------+
A.2 Interpersonal messaging protocol (P2)
107
Table 33 - Classification of the P2 protocol elements
+----------------------------------------------------+-----------
--+
| Interpersonal Messaging Protocol (P2) | Part 1 of
3 |
+---------------------------------------+------------+-----------
--+
| Support by |
|
+---------------------------------+-+UA
+--------------------------+
| Protocol Element |S|O/R| Comments/References
|
+---------------------------------+-+---+------------------------
--+
| InformationObject | | |
|
| ipm |O|M/M| IPM
|
| ipn |O|M/M| IPN - see Note 4
|
| | | |
|
| IPM | | |
|
| heading |M|M/M|
|
| this-IPM |M|M/M| IPMIdentifier
|
| originator |O|M/M| ORDescriptor
|
| authorizing-users |O|O/M| ORDescriptor
|
| primary-recipients |O|M/M| RecipientSpecifier
|
| copy-recipients |O|M/M| RecipientSpecifier
|
| blind-copy-recipients |O|O/M| RecipientSpecifier
|
| replied-to-IPM |O|M/M| IPMIdentifier
|
| obsoleted-IPMs |O|O/M| IPMIdentifier
|
| related-IPMs |O|O/M| IPMIdentifier
|
| subject |O|M/M| See Note 1, 8
|
| expiry-time |O|O/M|
|
| reply-time |O|O/M|
108
|
| reply-recipients |O|O/M| ORDescriptor
|
| importance |O|O/M|
|
| sensitivity |O|O/M|
|
| auto-forwarded |O|O/M|
|
| extensions |O|O/M| HeadingExtension
|
| incomplete-copy |O|O/O|
|
| languages |O|O/M|
|
| body |M|M/M| BodyPart
|
| | | |
|
| IPN | | |
|
| common-fields |M|M/M|
|
| subject-ipm |M|M/M|
|
| ipn-originator |O|M/M| ORDescriptor
|
| ipm-preferred-recipient |O|M/M| ORDescriptor
|
| conversion-eits |O|O/M| EncodedInformationTypes
|
| non-receipt-fields |O|M/M| See Note 5
|
| non-receipt-reason |M|M/M|
|
| discard-reason |O|M/M|
|
| auto-forward-comment |O|O/M|
|
| returned-ipm |O|O/O| See Note 2
|
| receipt-fields |O|O/M|
|
| receipt-time |M|M/M|
|
| | | |
|
+---------------------------------+-+---+------------------------
--+
109
Table 33 - Classification of the P2 protocol elements (continued)
+----------------------------------------------------+-----------
--+
| Interpersonal Messaging Protocol (P2) | Part 2 of
3 |
+---------------------------------------+------------+-----------
--+
| Support by |
|
+---------------------------------+-+UA
+--------------------------+
| Protocol Element |S|O/R| Comments/References
|
+---------------------------------+-+---+------------------------
--+
| acknowledgment-mode |O|O/M|
|
| suppl-receipt-info |O|O/O|
|
| | | |
|
| HeadingExtension | | |
|
| type |M|M/M|
|
| value |M|M/M|
|
| IPMIdentifier | | |
|
| user |O|O/M|
|
| user-relative-identifier |M|M/M|
|
| | | |
|
| ORDescriptor | | |
|
| formal-name |O|O/M| ORName - see Note 3
|
| free-form-name |O|O/M| See Note 8
|
| telephone-number |O|O/M|
|
| | | |
|
| RecipientSpecifier | | |
|
| recipient |M|M/M| ORDescriptor
|
| notification-requests |O|O/M|
110
|
| reply-requested |O|O/M|
|
| | | |
|
| BodyPart | | |
|
| ia5-text |O|M/M|
|
| parameters |M|M/M|
|
| repertoire |O|O/M| See Note 6
|
| data |M|M/M|
|
| voice |O| * | See Note 7
|
| g3-facsimile |O|O/O|
|
| parameters |M|M/M|
|
| number-of-pages |O|O/M|
|
| non-basic-parameters |O|O/M|
|
| data |M|M/M|
|
| g4-class1 |O|O/O|
|
| teletex |O|O/M|
|
| parameters |M|M/M|
|
| number-of-pages |O|O/O|
|
| telex-compatible |O|O/O|
|
| non-basic-parameters |O|O/O|
|
| data |M|M/M|
|
| videotex |O|O/O|
|
| parameters |M|M/M|
|
| syntax |O|O/M|
|
| data |M|M/M|
|
| encrypted |O| * | See Note 7
111
|
| | | |
|
+---------------------------------+-+---+------------------------
--+
112
Table 33 - Classification of the P2 protocol elements (concluded)
+----------------------------------------------------+-----------
--+
| Interpersonal Messaging Protocol (P2) | Part 3 of
3 |
+---------------------------------------+------------+-----------
--+
| Support by |
|
+---------------------------------+-+UA
+--------------------------+
| Protocol Element |S|O/R| Comments/References
|
+---------------------------------+-+---+------------------------
--+
| message |O|O/M|
|
| parameters |M|M/M|
|
| delivery-time |O|O/M|
|
| delivery-envelope |O|O/M| See P3 OtherMessage
|
| | | | DeliveryFields
|
| data |M|M/M|
|
| mixed-mode |O|O/O|
|
| bilaterally-defined |O|O/O|
|
| nationally-defined |O|O/O|
|
| externally-defined |O|O/M| See Note 10
|
| parameters |M|M/M|
|
| data |M|M/M|
|
| | | |
|
| GeneralTextBodyPart |O|O/M| See Note 9
|
| ODA1984BodyPart |O|O/O|
|
| ISO6937BodyPart |O|O/O|
|
| BilaterallyDefinedBodyPart |O|O/O|
|
| USAPrivatelyDefinedBodyPart |O|O/O|
113
|
+---------------------------------+-+---+------------------------
--+
| Notes
|
| 1 The ability to generate the maximum size subject is not
|
| required.
|
| 2 May only be included if specifically requested by the
|
| originator.
|
| 3 The ORName should be specified wherever possible.
|
| 4 The ability to generate an IPN is optional in the case of
|
| an implementation in which a non-receipt condition cannot
|
| occur and receipt notification is not supported.
|
| 5 The ability to generate non-receipt-fields is optional in
|
| the case of an implementation in which a non-receipt
|
| condition cannot occur (see note 4).
|
| 6 Only the IA5 repertoire has to be supported for an
|
| ia5-text body part on reception.
|
| 7 The definition of these body parts is for further study in
|
| CCITT and ISO.
|
| 8 Only the IA5 subset of the T.61 character repertoire need
|
| be generated. All T.61 characters should be supported on
|
| reception.
|
| 9 If General Text is supported, an implementation's PICS must
|
| identify which character repertoires can be generated on
|
| origination and supported on reception.
|
| 10 Any basic body part type that is supported on reception as
|
| an integer encoding must also be supported as an object
114
|
| identifier encoding. Support for all other externally
|
| defined body parts is optional.
|
+----------------------------------------------------------------
--+
Editor's Note - The draft text note regarding the meaning of
"support" on reception was missing from the editing
instructions.
115
A.3 MTS access protocol (P3)
NOTE - The support classifications for the UA, MS and MTA
below indicate the minimum level of support required by
implementations conforming to these Agreements, and should
not be misconstrued as a redefinition of any of the MHS
application contexts.
116
Table 34 - Classification of the P3 protocol elements
+----------------------------------------------------------+-----
----------+
| MTS Access Protocol (P3) | Part
1 of 12 |
+-----------------------------------------------+----------+-----
----------+
| Support by: |
|
+---------------------------------+-+UA |MS
|MTA+--------------------------+
| Protocol Element |S|O/R|O/R|O/R|
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| Operations | | | | |
|
| | | | | |
|
| MTSBind |M|M/M|M/M|M/M| MTSBind
|
| MTSUnbind |M|M/M|M/M|M/M|
|
| | | | | |
|
| MSSE | | | | |
|
| message-submission |M|M/-|M/M|-/M|
MessageSubmission |
| probe-submission |M|O/-|M/M|-/M| ProbeSubmission
|
| cancel-deferred-delivery |M|O/-|M/M|-/M|
CancelDeferredDelivery |
| submission-control |M|-/M|M/M|O/-|
SubmissionControl |
| | | | | |
|
| MDSE | | | | |
|
| message-delivery |M|-/M|M/M|M/-| MessageDelivery
|
| report-delivery |M|-/M|M/M|M/-| ReportDelivery
|
| | | | | | See Note 10
|
| delivery-control |M|M/-|M/-|-/M| DeliveryControl
|
| | | | | |
|
| MASE | | | | |
117
|
| register |M|O/-|M/M|-/M| Register
|
| change-credentials | | | | |
|
| (MTS to MTSuser) |M|-/M|M/M|O/-|
ChangeCredentials |
| (MTSuser to MTS) |M|O/-|M/M|-/M|
ChangeCredentials |
| | | | | |
|
+---------------------------------+-+---+---+---+----------------
----------+
|
|
| Note - A Message Store must pass through all MSSE and MASE
|
| operations unaltered.
|
|
|
+----------------------------------------------------------------
----------+
118
Table 34 - Classification of the P3 protocol elements (continued)
+----------------------------------------------------------+-----
----------+
| MTS Access Protocol (P3) | Part
2 of 12 |
+-----------------------------------------------+----------+-----
----------+
| Support by: |
|
+---------------------------------+-+UA |MS
|MTA+--------------------------+
| Protocol Element |S|O/R|O/R|O/R|
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| Arguments/Results | | | | |
|
| | | | | |
|
| MTSBind | | | | | MTS to MTS User
|
| ARGUMENT | | | | |
|
| initiator-name |M|-/M|-/M|M/-|
|
| MTS-user |-|-/-|-/-|-/-|
|
| MTA |O|-/O|-/M|M/-|
|
| isMessageStore |-|-/-|-/-|-/-|
|
| messages-waiting |O|-/M|-/M|M/-|
|
| initiator-credentials |M|-/M|-/M|M/-|
|
| simple |O|-/M|-/M|M/-|
|
| strong |O|-/O|-/O|O/-|
|
| security-context |O|-/O|-/O|O/-|
|
| RESULT | | | | |
|
| responder-name |M|M/-|M/-|-/M|
|
| MTS-user |O|M/-|M/-|-/M|
|
| MTA |-|-/-|-/-|-/-|
|
| ismessagestore |O|M/-|M/-|-/M|
119
|
| messages-waiting |-|-/-|-/-|-/-|
|
| responder-credentials |M|M/-|M/-|-/M|
|
| simple |O|M/-|M/-|-/M|
|
| strong |O|O/-|O/-|-/O|
|
| | | | | |
|
| MTSBind | | | | | MTS User to MTS
|
| ARGUMENT | | | | |
|
| initiator-name |M|M/-|M/-|-/M|
|
| mTS-user |O|M/-|M/-|-/M|
|
| mTA |-|-/-|-/-|-/-|
|
| isMessageStore |O|M/M|M/-|-/M|
|
| messages-waiting |-|-/-|-/-|-/-|
|
| initiator-credentials |M|M/-|M/-|-/M|
|
| simple |O|M/-|M/-|-/M|
|
| strong |O|O/-|O/-|-/O|
|
| security-context |O|O/-|O/-|-/O|
|
| RESULT | | | | |
|
| responder-name |M|-/M|-/M|M/-|
|
| mTS-user |-|-/-|-/-|-/-|
|
| mTA |O|-/M|-/M|M/-|
|
| isMessageStore |-|-/-|-/-|-/-|
|
| messages-waiting |O|-/M|-/M|M/-|
|
| responder-credentials |M|-/M|-/M|M/-|
|
| simple |O|-/M|-/M|M/-|
|
| strong |O|-/O|-/O|O/-|
120
|
| | | | | |
|
+---------------------------------+-+---+---+---+----------------
----------+
121
Table 34 - Classification of the P3 protocol elements (continued)
+----------------------------------------------------------+-----
----------+
| MTS Access Protocol (P3) | Part
3 of 12 |
+-----------------------------------------------+----------+-----
----------+
| Support by: |
|
+---------------------------------+-+UA |MS
|MTA+--------------------------+
| Protocol Element |S|O/R|O/R|O/R|
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| MessageSubmission | | | | |
|
| ARGUMENT | | | | |
|
| envelope |M|M/-|M/-|-/M|
MessageSubmission |
| | | | | | Envelope
|
| content |M|M/-|M/-|-/M|
|
| RESULT | | | | |
|
| message-submission-identifier |M|-/M|-/M|M/-| MTSIdentifier
|
| message-submission-time |M|-/M|-/M|M/-|
|
| content-identifier |O|-/M|-/M|M/-|
|
| extensions |O|-/O|-/O|O/-|
|
| originating-MTA-certificate |O|-/O|-/O|O/-|
|
| proof-of-submission |O|-/O|-/O|O/-|
|
| | | | | |
|
| ProbeSubmission | | | | |
|
| ARGUMENT | | | | |
|
| envelope |M|M/-|M/-|-/M| ProbeSubmission
|
| | | | | | Envelope
|
| RESULT | | | | |
122
|
| probe-submission-identifier |M|-/M|-/M|M/-| MTSIdentifier
|
| probe-submission-time |M|-/M|-/M|M/-|
|
| content-identifier |O|-/M|-/M|M/-|
|
| | | | | |
|
| CancelDeferredDelivery | | | | |
|
| ARGUMENT | | | | |
|
| message-submission-identifier |M|M/-|M/-|-/M| MTSIdentifier
|
| | | | | |
|
| SubmissionControl | | | | |
|
| ARGUMENT | | | | |
|
| controls |M|-/M|-/M|M/-| See Note 1
|
| restrict |O|-/M|-/M|M/-|
|
| permissible-operations |O|-/M|-/M|O/-|
|
| permissible-maximum-content- | | | | |
|
| length |O|-/M|-/M|O/-|
|
| permissible-lowest-priority |O|-/M|-/M|O/-|
|
| permissible-security-context |O|-/O|-/O|O/-|
|
| RESULT | | | | |
|
| waiting |M|M/-|M/-|-/M| See Note 2
|
| waiting-operations |O|O/-|O/-|-/M|
|
| waiting-messages |O|O/-|O/-|-/M|
|
| waiting-content-types |O|O/-|O/-|-/M|
|
| waiting-encoded-information- | | | | |
|
| types |O|O/-|O/-|-/M|
EncodedInformationTypes |
| | | | | |
123
|
| | | | | |
|
+---------------------------------+-+---+---+---+----------------
----------+
124
Table 34 - Classification of the P3 protocol elements (continued)
+----------------------------------------------------------+-----
----------+
| MTS Access Protocol (P3) | Part
4 of 12 |
+-----------------------------------------------+----------+-----
----------+
| Support by: |
|
+---------------------------------+-+UA |MS
|MTA+--------------------------+
| Protocol Element |S|O/R|O/R|O/R|
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| MessageDelivery | | | | |
|
| ARGUMENT | | | | |
|
| envelope |M|-/M|-/M|M/-|
MessageDeliveryEnvelope |
| content |M|-/M|-/M|M/-|
|
| RESULT | | | | |
|
| recipient-certificate |O|O/-|O/-|-/O|
|
| proof-of-delivery |O|O/-|O/-|-/O|
|
| | | | | |
|
| ReportDelivery | | | | |
|
| ARGUMENT | | | | |
|
| envelope |M|-/M|-/M|M/-|
ReportDeliveryEnvelope |
| returned-content |O|-/M|-/M|O/-|
|
| | | | | |
|
| DeliveryControl | | | | |
|
| ARGUMENT | | | | |
|
| controls |M|M/-|M/-|-/M| See Note 3
|
| restrict |O|M/-|M/-|-/M|
|
| permissible-operations |O|O/-|O/-|-/M|
125
|
| permissible-maximum-content- | | | | |
|
| length |O|O/-|O/-|-/M|
|
| permissible-lowest-priority |O|O/-|O/-|-/M|
|
| permissible-content-types |O|O/-|O/-|-/M|
|
| permissible-encoded- | | | | |
|
| information-types |O|O/-|O/-|-/M|
EncodedInformationTypes |
| permissible-security-context |O|O/-|O/-|-/O|
|
| RESULT | | | | |
|
| waiting |M|-/M|-/M|M/-| See Note 4
|
| waiting-operations |O|-/M|-/M|O/-|
|
| waiting-messages |O|-/M|-/M|O/-|
|
| waiting-content-types |O|-/M|-/M|O/-|
|
| waiting-encoded-information- | | | | |
|
| types |O|-/M|-/M|O/-|
EncodedInformationTypes |
| | | | | |
|
| Register | | | | | See Note 5
|
| ARGUMENT | | | | |
|
| user-name |O|O/-|O/-|-/O| See X.411,
8.4.1.1.1.1 |
| user-address |O|O/-|O/-|-/O|
|
| deliverable-encoded- | | | | |
|
| information-types |O|O/-|M/-|-/M|
EncodedInformationTypes |
| deliverable-maximum-content- | | | | |
|
| length |O|O/-|M/-|-/M|
|
| default-delivery-controls |O|O/-|O/-|-/O|
|
| restrict |O|O/-|O/-|-/M|
126
|
| | | | | |
|
+---------------------------------+-+---+---+---+----------------
----------+
127
Table 34 - Classification of the P3 protocol elements (continued)
+----------------------------------------------------------+-----
----------+
| MTS Access Protocol (P3) | Part
5 of 12 |
+-----------------------------------------------+----------+-----
----------+
| Support by: |
|
+---------------------------------+-+UA |MS
|MTA+--------------------------+
| Protocol Element |S|O/R|O/R|O/R|
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| permissible-operations |O|O/-|O/-|-/M|
|
| permissible-maximum-content- | | | | |
|
| length |O|O/-|O/-|-/M|
|
| permissible-lowest-priority |O|O/-|O/-|-/M|
|
| permissible-content-types |O|O/-|O/-|-/M|
|
| permissible-encoded- | | | | |
|
| information-types |O|O/-|O/-|-/M|
EncodedInformationTypes |
| deliverable-content-types |O|O/-|M/-|-/M|
|
| labels-and-redirections |O|O/-|O/-|-/O|
|
| user-security-label |O|O/-|O/-|-/O|
|
| recipient-assigned-alternate-| | | | |
|
| recipient |O|O/-|O/-|-/O|
|
| | | | | |
|
| ChangeCredentials | | | | | MTS to MTSuser
|
| ARGUMENT | | | | |
|
| old-credentials |M|-/M|-/M|M/-| Note 8
|
| simple |O|-/M|-/M|O/-|
|
| strong |O|-/O|-/O|O/-|
128
|
| new-credentials |M|-/M|-/M|M/-| Note 8
|
| simple |O|-/M|-/M|O/-|
|
| strong |O|-/O|-/O|O/-|
|
| | | | | |
|
| ChangeCredentials | | | | | MTSuser to MTS
|
| ARGUMENT | | | | |
|
| old-credentials |M|M/-|M/-|-/M| Note 8
|
| simple |O|O/-|O/-|-/M|
|
| strong |O|O/-|O/-|-/O|
|
| new-credentials |M|M/-|M/-|-/M| Note 8
|
| simple |O|O/-|O/-|-/M|
|
| strong |O|O/-|O/-|-/O|
|
| | | | | |
|
+---------------------------------+-+---+---+---+----------------
----------+
| MessageSubmissionEnvelope | | | | | See Note 6
|
| originator-name |M|M/-|M/-|-/M| ORName
|
| original-encoded-information- | | | | |
|
| types |O|M/-|M/-|-/M|
EncodedInformationTypes |
| content-type |M|M/-|M/-|-/M|
|
| built-in |O|O/-|M/-|-/M|
|
| external |O|O/-|M/-|-/M|
|
| content-identifier |O|O/-|M/-|-/M|
|
| priority |O|M/-|M/-|-/M| All values
|
| per-message-indicators |O|M/-|M/-|-/M|
|
| disclosure-of-recipients |O|O/-|M/-|-/M|
129
|
| | | | | |
|
+---------------------------------+-+---+---+---+----------------
----------+
130
Table 34 - Classification of the P3 protocol elements (continued)
+----------------------------------------------------------+-----
----------+
| MTS Access Protocol (P3) | Part
6 of 12 |
+-----------------------------------------------+----------+-----
----------+
| Support by: |
|
+---------------------------------+-+UA |MS
|MTA+--------------------------+
| Protocol Element |S|O/R|O/R|O/R|
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| implicit-conversion-prohibited|O|M/-|M/-|-/M|
|
| alternate-recipient-allowed |O|M/-|M/-|-/M|
|
| content-return-request |O|O/-|M/-|-/M|
|
| deferred-delivery-time |O|O/-|O/-|-/M|
|
| extensions |O|M/-|M/-|-/M|
|
| recipient-reassignment- | | | | |
|
| prohibited |O|O/-|M/-|-/M|
|
| dl-expansion-prohibited |O|M/-|M/-|-/M|
|
| conversion-with-loss- | | | | |
|
| prohibited |O|O/-|M/-|-/M|
|
| latest-delivery-time |O|O/-|M/-|-/M|
|
| originator-return-address |O|O/-|M/-|-/M|
|
| originator-certificate |O|O/-|O/-|-/O|
|
| content-confidentiality- | | | | |
|
| algorithm-identifier |O|O/-|O/-|-/O|
|
| message-origin- | | | | |
|
| authentication-check |O|O/-|O/-|-/O|
|
| message-security-label |O|O/-|O/-|-/O|
131
|
| proof-of-submission-request |O|O/-|O/-|-/O|
|
| content-correlator |O|O/-|M/-|-/M|
|
| forwarding-request |O|O/-|O/-|-/M| MS Abstract
Service only |
| PerRecipientMessageSubmission | | | | |
|
| Fields |M|M/-|M/-|-/M|
|
| recipient-name |M|M/-|M/-|-/M| ORName
|
| originator-report-request |M|M/-|M/-|-/M|
|
| explicit-conversion |O|O/-|M/-|-/M|
|
| extensions |O|M/-|M/-|-/M|
|
| originator-requested- | | | | |
|
| alternate-recipient |O|O/-|O/-|-/O|
|
| requested-delivery-method |O|O/-|O/-|-/O| Note 9
|
| physical-forwarding- | | | | |
|
| prohibited |O|O/-|O/-|-/O|
|
| physical-forwarding-address- | | | | |
|
| request |O|O/-|O/-|-/O|
|
| physical-delivery-modes |O|O/-|O/-|-/O|
|
| registered-mail-type |O|O/-|O/-|-/O|
|
| recipient-number-for-advice |O|O/-|O/-|-/O|
|
| physical-rendition-attributes|O|O/-|O/-|-/O|
|
| physical-delivery-report- | | | | |
|
| request |O|O/-|O/-|-/O|
|
| message-token |O|O/-|O/-|-/O|
|
| content-integrity-check |O|O/-|O/-|-/O|
|
| proof-of-delivery-request |O|O/-|O/-|-/O|
132
|
| | | | | |
|
+---------------------------------+-+---+---+---+----------------
----------+
133
Table 34 - Classification of the P3 protocol elements (continued)
+----------------------------------------------------------+-----
----------+
| MTS Access Protocol (P3) | Part
7 of 12 |
+-----------------------------------------------+----------+-----
----------+
| Support by: |
|
+---------------------------------+-+UA |MS
|MTA+--------------------------+
| Protocol Element |S|O/R|O/R|O/R|
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| ProbeSubmissionEnvelope | | | | | See Note 6
|
| originator-name |M|M/-|M/-|-/M| ORName
|
| original-encoded-information- | | | | |
|
| types |O|M/-|M/-|-/M| Encoded
InformationTypes |
| content-type |M|M/-|M/-|-/M|
|
| built-in |O|O/-|M/-|-/M|
|
| external |O|O/-|M/-|-/M|
|
| content-identifier |O|O/-|M/-|-/M|
|
| content-length |O|M/-|M/-|-/M|
|
| per-message-indicators |O|M/-|M/-|-/M|
|
| implicit-conversion-prohibited|O|M/-|M/-|-/M|
|
| alternate-recipient-allowed |O|O/-|M/-|-/M|
|
| extensions |O|M/-|M/-|-/M|
|
| recipient-reassignment- | | | | |
|
| prohibited |O|M/-|M/-|-/M|
|
| dl-expansion-prohibited |O|M/-|M/-|-/M|
|
| conversion-with-loss- | | | | |
|
| prohibited |O|O/-|M/-|-/M|
134
|
| originator-certificate |O|O/-|O/-|-/O|
|
| message-security-label |O|O/-|O/-|-/O|
|
| content-correlator |O|O/-|M/-|-/M|
|
| probe-origin-authentication- | | | | |
|
| check |O|O/-|O/-|-/O|
|
| PerRecipientProbeSubmission | | | | |
|
| Fields |M|M/-|M/-|-/M|
|
| recipient-name |M|M/-|M/-|-/M| ORName
|
| originator-report-request |M|M/-|M/-|-/M|
|
| explicit-conversion |O|O/-|M/-|-/M|
|
| extensions |O|M/-|M/-|-/M|
|
| originator-requested- | | | | |
|
| alternate-recipient |O|O/-|O/-|-/O|
|
| requested-delivery-method |O|M/-|O/-|-/O| See Note 9
|
| physical-rendition-attributes|O|O/-|O/-|-/O|
|
| | | | | |
|
| MessageDeliveryEnvelope | | | | | See Note 7
|
| message-delivery-identifier |M|-/M|-/M|M/-| MTSIdentifier
|
| message-delivery-time |M|-/M|-/M|M/-|
|
| other-fields |M|-/M|-/M|M/-|
|
| content-type |M|-/M|-/M|M/-|
|
| built-in |O|-/M|-/M|M/-|
|
| external |O|-/M|-/M|M/-|
|
| originator-name |M|-/M|-/M|M/-| ORName
|
| | | | | |
135
|
+---------------------------------+-+---+---+---+----------------
----------+
136
Table 34 - Classification of the P3 protocol elements (continued)
+----------------------------------------------------------+-----
----------+
| MTS Access Protocol (P3) | Part
8 of 12 |
+-----------------------------------------------+----------+-----
----------+
| Support by: |
|
+---------------------------------+-+UA |MS
|MTA+--------------------------+
| Protocol Element |S|O/R|O/R|O/R|
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| original-encoded-information- | | | | |
|
| types |O|-/M|-/M|M/-|
EncodedInformationTypes |
| priority |O|-/M|-/M|M/-| All values
|
| delivery-flags |O|-/M|-/M|M/-|
|
| implicit-conversion- | | | | |
|
| prohibited |O|-/M|-/M|M/-|
|
| other-recipient-names |O|-/M|-/M|M/-| ORName
|
| this-recipient-name |M|-/M|-/M|M/-| ORName
|
| originally-intended-recipient-| | | | |
|
| name |O|-/M|-/M|M/-| ORName
|
| converted-encoded-information-| | | | |
|
| types |O|-/M|-/M|M/-|
EncodedInformationTypes |
| message-submission-time |M|-/M|-/M|M/-|
|
| content-identifier |O|-/M|-/M|M/-|
|
| extensions |O|-/M|-/M|M/-|
|
| conversion-with-loss- | | | | |
|
| prohibited |O|-/M|-/M|M/-|
|
| requested-delivery-method |O|-/M|-/M|M/-| See Note 9
137
|
| physical-forwarding- | | | | |
|
| prohibited |O|-/-|-/-|M/-|
|
| physical-forwarding-address- | | | | |
|
| request |O|-/-|-/-|M/-|
|
| physical-delivery-modes |O|-/-|-/-|M/-| 0-16
|
| registered-mail-type |O|-/-|-/-|M/-| 0-256
|
| recipient-number-for-advice |O|-/-|-/-|M/-| 1-32
|
| physical-rendition-attributes|O|-/-|-/-|M/-|
|
| physical-delivery-report- | | | | |
|
| request |O|-/-|-/-|M/-| 0-256
|
| originator-return-address |O|-/-|-/-|M/-|
|
| originator-certificate |O|-/O|-/O|O/-|
|
| message-token |O|-/O|-/O|O/-|
|
| content-confidentiality- | | | | |
|
| algorithm-identifier |O|-/O|-/O|O/-|
|
| content-integrity-check |O|-/O|-/O|O/-|
|
| message-origin- | | | | |
|
| authentication-check |O|-/O|-/O|O/-|
|
| message-security-label |O|-/O|-/O|O/-|
|
| proof-of-delivery-request |O|-/O|-/O|O/-|
|
| redirection-history |O|-/M|-/M|M/-|
|
| dl-expansion-history |O|-/M|-/M|M/-|
|
| | | | | |
|
| | | | | |
|
+---------------------------------+-+---+---+---+----------------
138
----------+
139
Table 34 - Classification of the P3 protocol elements (continued)
+----------------------------------------------------------+-----
----------+
| MTS Access Protocol (P3) | Part
9 of 12 |
+-----------------------------------------------+----------+-----
----------+
| Support by: |
|
+---------------------------------+-+UA |MS
|MTA+--------------------------+
| Protocol Element |S|O/R|O/R|O/R|
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| ReportDeliveryEnvelope | | | | | See Note 7
|
| subject-submission-identifier |M|-/M|-/M|M/-| MTSIdentifier
|
| content-identifier |O|-/O|-/O|M/-|
|
| content-type |O|-/M|-/M|M/-|
|
| built-in |O|-/M|-/M|M/-|
|
| external |O|-/M|-/M|M/-|
|
| original-encoded-information- | | | | |
|
| types |O|-/M|-/M|M/-|
EncodedInformationTypes |
| extensions |O|-/M|-/M|M/-|
|
| message-security-label |O|-/O|-/O|O/-|
|
| content-correlator |O|-/M|-/M|M/-|
|
| originator-and-DL-expansion- | | | | | OriginatorAndDL
|
| history |O|-/M|-/M|M/-|
ExpansionHistory |
| reporting-DL-name |O|-/M|-/M|M/-|
|
| reporting-MTA-certificate |O|-/O|-/O|O/-|
|
| report-origin-authentication- | | | | |
|
| check |O|-/O|-/O|O/-|
|
| PerRecipientReportDelivery- | | | | |
140
|
| Fields |M|-/M|-/M|M/-|
|
| actual-recipient-name |M|-/M|-/M|M/-| ORName
|
| report |M|-/M|-/M|M/-|
|
| delivery |O|-/M|-/M|M/-|
|
| message-delivery-time |M|-/M|-/M|M/-|
|
| type-of-MTS-user |O|-/M|-/M|M/-|
|
| non-delivery |O|-/M|-/M|M/-|
|
| non-delivery-reason-code |M|-/M|-/M|M/-|
|
| non-delivery-diagnostic-code|O|-/M|-/M|M/-|
|
| converted-encoded-information-| | | | |
|
| types |O|-/M|-/M|M/-|
EncodedInformationTypes |
| originally-intended-recipient-| | | | |
|
| name |O|-/M|-/M|M/-| ORName
|
| supplementary-information |O|-/M|-/M|M/-|
|
| extensions |O|-/M|-/M|M/-|
|
| redirection-history |O|-/M|-/M|M/-|
RedirectionHistory |
| physical-forwarding-address |O|-/O|-/O|O/-|
|
| recipient-certificate |O|-/O|-/O|O/-|
|
| proof-of-delivery |O|-/O|-/O|O/-|
|
| | | | | |
|
| ORName | | | | | MTS User to MTS
|
| standard-attributes | | | | |
|
| country-name |O|M/-|M/-|-/M| CountryName
|
| administration-domain-name |O|M/-|M/-|-/M| DomainName
|
| network-address |O|M/-|M/-|-/M|
141
|
| terminal-identifier |O|M/-|M/-|-/M|
|
+---------------------------------+-+---+---+---+----------------
----------+
142
Table 34 - Classification of the P3 protocol elements (continued)
+----------------------------------------------------------+-----
----------+
| MTS Access Protocol (P3) | Part
10 of 12 |
+-----------------------------------------------+----------+-----
----------+
| Support by: |
|
+---------------------------------+-+UA |MS
|MTA+--------------------------+
| Protocol Element |S|O/R|O/R|O/R|
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| private-domain-name |O|M/-|M/-|-/M| DomainName
|
| organization-name |O|M/-|M/-|-/M|
|
| numeric-user-identifier |O|M/-|M/-|-/M|
|
| personal-name |O|M/-|M/-|-/M|
|
| surname |M|M/-|M/-|-/M|
|
| given-name |O|M/-|M/-|-/M|
|
| initials |O|M/-|M/-|-/M|
|
| generation-qualifier |O|M/-|M/-|-/M|
|
| organizational-unit-names |O|M/-|M/-|-/M|
|
| OrganizationUnitName |M|M/-|M/-|-/M|
|
| domain-defined-attributes |O|M/-|M/-|-/M|
|
| DomainDefinedAttribute |M|M/-|M/-|-/M|
|
| type |M|M/-|M/-|-/M|
|
| value |M|M/-|M/-|-/M|
|
| extension-attributes |O|M/-|M/-|-/M|
ExtensionAttribute |
| common-name |O|M/-|M/-|-/M|
|
| teletex-common-name |O|O/-|O/-|-/M|
|
| teletex-organization-name |O|O/-|O/-|-/M|
143
|
| teletex-personal-name |O|O/-|O/-|-/M|
|
| teletex-organizational-unit- | | | | |
|
| names |O|O/-|O/-|-/M|
|
| teletex-domain-defined- | | | | |
|
| attributes |O|O/-|O/-|-/M|
|
| pds-name |O|O/-|O/-|-/M|
|
| physical-delivery-country-name|O|O/-|O/-|-/M|
|
| postal-code |O|O/-|O/-|-/M|
|
| physical-delivery-office-name |O|O/-|O/-|-/M|
|
| physical-delivery-office- | | | | |
|
| number |O|O/-|O/-|-/M|
|
| extension-OR-address- | | | | |
|
| components |O|O/-|O/-|-/M|
|
| physical-delivery-personal- | | | | |
|
| name |O|O/-|O/-|-/M|
|
| physical-delivery- | | | | |
|
| organization-name |O|O/-|O/-|-/M|
|
| extension-physical-delivery- | | | | |
|
| address-components |O|O/-|O/-|-/M|
|
| unformatted-postal-address |O|O/-|O/-|-/M|
|
| street-address |O|O/-|O/-|-/M|
|
| post-office-box-address |O|O/-|O/-|-/M|
|
| poste-restante-address |O|O/-|O/-|-/M|
|
| unique-postal-name |O|O/-|O/-|-/M|
|
| local-postal-attributes |O|O/-|O/-|-/M|
144
|
| extended-network-address |O|O/-|O/-|-/M|
|
| terminal-type |O|O/-|O/-|-/M|
|
| | | | | |
|
| ORName | | | | | MTS to MTS User
|
| standard-attributes | | | | |
|
| country-name |O|-/M|-/M|M/-| CountryName
|
+---------------------------------+-+---+---+---+----------------
----------+
145
Table 34 - Classification of the P3 protocol elements (continued)
+----------------------------------------------------------+-----
----------+
| MTS Access Protocol (P3) | Part
11 of 12 |
+-----------------------------------------------+----------+-----
----------+
| Support by: |
|
+---------------------------------+-+UA |MS
|MTA+--------------------------+
| Protocol Element |S|O/R|O/R|O/R|
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| administration-domain-name |O|-/M|-/M|M/-| DomainName
|
| network-address |O|-/M|-/M|M/-|
|
| terminal-identifier |O|-/M|-/M|M/-|
|
| private-domain-name |O|-/M|-/M|M/-| DomainName
|
| organization-name |O|-/M|-/M|M/-|
|
| numeric-user-identifier |O|-/M|-/M|M/-|
|
| personal-name |O|-/M|-/M|M/-|
|
| surname |M|-/M|-/M|M/-|
|
| given-name |O|-/M|-/M|M/-|
|
| initials |O|-/M|-/M|M/-|
|
| generation-qualifier |O|-/M|-/M|M/-|
|
| organizational-unit-names |O|-/M|-/M|M/-|
|
| OrganizationUnitName |M|-/M|-/M|M/-|
|
| domain-defined-attributes |O|-/M|-/M|M/-|
|
| DomainDefinedAttribute |M|-/M|-/M|M/-|
|
| type |M|-/M|-/M|M/-|
|
| value |M|-/M|-/M|M/-|
|
| extension-attributes |O|-/M|-/M|M/-|
146
ExtensionAttribute |
| common-name |O|-/M|-/M|M/-|
|
| teletex-common-name |O|-/M|-/M|M/-|
|
| teletex-organization-name |O|-/M|-/M|M/-|
|
| teletex-personal-name |O|-/M|-/M|M/-|
|
| teletex-organizational-unit- | | | | |
|
| names |O|-/M|-/M|M/-|
|
| teletex-domain-defined- | | | | |
|
| attributes |O|-/M|-/M|M/-|
|
| pds-name |O|-/O|-/M|M/-|
|
| physical-delivery-country-name|O|-/O|-/M|M/-|
|
| postal-code |O|-/O|-/M|M/-|
|
| physical-delivery-office-name |O|-/O|-/M|M/-|
|
| physical-delivery-office- | | | | |
|
| number |O|-/O|-/M|M/-|
|
| extension-OR-address- | | | | |
|
| components |O|-/O|-/M|M/-|
|
| physical-delivery-personal- | | | | |
|
| name |O|-/O|-/M|M/-|
|
| physical-delivery- | | | | |
|
| organization-name |O|-/O|-/M|M/-|
|
| extension-physical-delivery- | | | | |
|
| address-components |O|-/O|-/M|M/-|
|
| unformatted-postal-address |O|-/O|-/M|M/-|
|
| street-address |O|-/O|-/M|M/-|
|
| post-office-box-address |O|-/O|-/M|M/-|
147
|
| poste-restante-address |O|-/O|-/M|M/-|
|
| unique-postal-name |O|-/O|-/M|M/-|
|
| local-postal-attributes |O|-/O|-/M|M/-|
|
| extended-network-address |O|-/O|-/M|M/-|
|
| terminal-type |O|-/O|-/M|M/-|
|
+---------------------------------+-+---+---+---+----------------
----------+
148
Table 34 - Classification of the P3 protocol elements (concluded)
+----------------------------------------------------------+-----
----------+
| MTS Access Protocol (P3) | Part
12 of 12 |
+-----------------------------------------------+----------+-----
----------+
| Support by: |
|
+---------------------------------+-+UA |MS
|MTA+--------------------------+
| Protocol Element |S|O/R|O/R|O/R|
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| EncodedInformationTypes | | | | |
|
| built-in-encoded-information- | | | | |
|
| types |M|M/M|M/M|M/M| See Note 3
|
| non-basic-parameters |O|O/O|O/O|O/O|
|
| external-encoded-information- | | | | |
|
| types |O|O/M|O/M|M/O|
|
| MTSIdentifier | | | | |
|
| global-domain-identifier |M|M/M|M/M|M/M|
GlobalDomainIdentifier |
| local-identifier |M|M/M|M/M|M/M|
|
| OriginatorAndDLExpansionHistory | | | | |
|
| originator-or-dl-name |M|M/M|M/M|M/M|
|
| origination-or-expansion-time |M|M/M|M/M|M/M|
|
| RedirectionHistory | | | | |
|
| Redirection |M|M/M|M/M|M/M|
|
| intended-recipient-name |M|M/M|M/M|M/M|
|
| ORAddressAndOptionalDirectory| | | | |
|
| Name |M|M/M|M/M|M/M| ORName
|
| redirection-time |M|M/M|M/M|M/M|
149
|
| redirection-reason |M|M/M|M/M|M/M|
|
+---------------------------------+-+---+---+---+----------------
----------+
| Notes
|
| 1 The MTS-user may interpret any restriction as simply
withhold |
| `all' submissions.
|
| 2 No explicit action needs to be taken by the MTA.
|
| 3 The MTA may interpret any restriction as simply withhold
`all' |
| deliveries.
|
| 4 No explicit action needs to be taken by the MTS-user.
|
| 5 The Register operation may be performed locally (see X.411).
|
| Although not required for the UA for conformance, it is
|
| considered to be a useful service and support is
recommended. |
| 6 The action to be taken by a submitting MTA is as defined in
|
| X.411 (ISO 10021-4). In the absence of any specific
processing |
| requirements for a particular element in a submission
envelope, |
| the action to be taken is simply the faithful mapping of
such |
| element to the corresponding element of the appropriate
transfer |
| envelope.
|
| 7 The action to be taken by a delivering MTA is as defined in
X.41 |
| (ISO 10021-4). In the absence of any specific processing
|
| requirements for a particular element in a delivery
envelope, the |
| action to be taken is simply the creation of such element
from |
| the corresponding element of the appropriate transfer
envelope. |
| 8 At least one of simple and/or strong must be specified.
|
| 9 Applies to ORNames containing Directory Names and/or
150
ORAddresses |
| See Recommendation X.411, section 8.2.1.1.1.14.
|
| 10 In the absence of any specific processing requirements for a
|
| particular element in the Message Submission, or Probe
Submission, |
| the action to be taken is simply the creation of the
corresponding |
| element in the ReportDelivery (subject to any constraints
specified |
| in X.411).
|
| 11 Applicable only to reception by a PDAU.
|
+--------------------------------------------------------------------------+
A.4 MS access protocol (P7)
151
Table 35 - Classification of the P7 protocol elements
+------------------------------------------------------+---------
------+
| MS Access Protocol (P7) | Part 1
of 6 |
+-------------------------------------------+----------+---------
------+
| Support by: |
|
+---------------------------------+-+UA |MS
+--------------------------+
| Protocol Element |S|O/R|O/R| Comments/References
|
+---------------------------------+-+---+---+--------------------
------+
| Operations | | | |
|
| | | | |
|
| MSBind |M|M/-|-/M| MSBind
|
| MSUnbind |M|M/-|-/M|
|
| | | | |
|
| MSSE | | | |
|
| message-submission |M|M/-|-/M| See P3
MessageSubmission |
| probe-submission |M|O/-|-/M| See P3
ProbeSubmission |
| cancel-deferred-delivery |M|O/-|-/M| See P3
CancelDeferred |
| | | | | Delivery
|
| submission-control |M|-/M|M/-| See P3
SubmissionControl |
| | | | |
|
| MASE | | | |
|
| register |M|O/-|-/M| See P3 Register
|
| change-credentials (MS to UA) |M|-/M|M/-| See P3
ChangeCredentials |
| change-credentials (UA to MS) |M|O/-|-/M| See P3
ChangeCredentials |
| | | | |
|
| MRSE | | | |
152
|
| summarize |M|M/-|-/M| Summarize
|
| list |M|M/-|-/M| List
|
| fetch |M|M/-|-/M| Fetch
|
| delete |M|M/-|-/M| Delete
|
| register-ms |M|O/-|-/M| Register-MS
|
| alert |M|-/O|O/-| Alert
|
+---------------------------------+-+---+---+--------------------
------+
| Arguments/Results | | | |
|
| | | | |
|
| MSBind | | | |
|
| ARGUMENT | | | |
|
| MSBindArgument |M|M/-|-/M|
|
| initiator-name |M|M/-|-/M|
|
| initiator-credentials |M|M/-|-/M|
|
| simple |O|M/-|-/M|
|
| strong |O|O/-|-/O|
|
| security-context |O|O/-|-/O|
|
| fetch-restrictions |O|O/-|-/M|Opt'l in Basic
MS(Note 5) |
| allowed-content-types |O|O/-|-/M|
|
| allowed-EITs |O|O/-|-/M|
|
| maximum-content-length |O|O/-|-/M|
|
| MS-configuration-request |O|O/-|-/M|
|
+---------------------------------+-+---+---+--------------------
------+
153
Table 35 - Classification of the P7 protocol elements (continued)
+------------------------------------------------------+---------
------+
| MS Access Protocol (P7) | Part 2
of 6 |
+-------------------------------------------+----------+---------
------+
| Support by: |
|
+---------------------------------+-+UA |MS
+--------------------------+
| Protocol Element |S|O/R|O/R| Comments/References
|
+---------------------------------+-+---+---+--------------------
------+
| RESULT | | | |
|
| MSBindResult |M|-/M|M/-|
|
| responder-credentials |M|-/M|M/-|
|
| simple |O|-/M|M/-|
|
| strong |O|-/O|O/-|
|
| available-auto-actions |O|-/O|M/-|
|
| available-attribute-types |O|-/O|M/-|
|
| alert-indication |O|-/O|O/-|
|
| content-types-supported |O|-/O|M/-|
|
| | | | |
|
| Summarize | | | |
|
| ARGUMENT | | | |
|
| SummarizeArgument |M|M/-|-/M|
|
| information-base-type |O|O/-|-/M| InformationBase
|
| selector |M|M/-|-/M| Selector
|
| summary-requests |O|O/-|-/M|
|
| RESULT | | | |
|
| SummarizeResult |M|-/M|M/-|
154
|
| next |O|-/M|M/-|
|
| count |M|-/M|M/-|
|
| span |O|-/M|M/-|
|
| lowest |M|-/M|M/-|
|
| highest |M|-/M|M/-|
|
| summaries |O|-/M|M/-|
|
| absent |O|-/M|M/-|
|
| present |O|-/M|M/-|
|
| type |M|-/M|M/-|
|
| value |M|-/M|M/-|
|
| count |M|-/M|M/-|
|
| | | | |
|
| List | | | |
|
| ARGUMENT | | | |
|
| ListArgument |M|M/-|-/M|
|
| information-base-type |O|O/-|-/M| InformationBase
|
| selector |M|M/-|-/M| Selector
|
| requested-attributes |O|O/-|-/M| AttributeSelection
|
| RESULT | | | |
|
| ListResult |M|-/M|M/-|
|
| next |O|-/M|M/-|
|
| requested |O|-/M|M/-| EntryInformation
|
| | | | |
|
| | | | |
|
| | | | |
155
|
+---------------------------------+-+---+---+--------------------
------+
156
Table 35 - Classification of the P7 protocol elements (continued)
+------------------------------------------------------+---------
------+
| MS Access Protocol (P7) | Part 3
of 6 |
+-------------------------------------------+----------+---------
------+
| Support by: |
|
+---------------------------------+-+UA |MS
+--------------------------+
| Protocol Element |S|O/R|O/R| Comments/References
|
+---------------------------------+-+---+---+--------------------
------+
| Fetch | | | |
|
| ARGUMENT | | | |
|
| FetchArgument |M|M/-|-/M|
|
| information-base-type |O|O/-|-/M| InformationBase
|
| item |M|M/-|-/M|
|
| search |O|O/-|-/M| Optional in Basic
MS |
| precise |O|O/-|-/M|
|
| requested-attributes |O|O/-|-/M| AttributeSelection
|
| RESULT | | | |
|
| FetchResult |M|-/M|M/-|
|
| entry-information |O|-/M|M/-| EntryInformation
|
| list |O|-/O|M/-|
|
| next |O|-/O|M/-|
|
| Delete | | | |
|
| ARGUMENT | | | |
|
| DeleteArgument |M|M/-|-/M|
|
| information-base-type |O|O/-|-/M| InformationBase
|
| items |M|M/-|-/M|
157
|
| selector |O|O/-|-/M| Optional in Basic
MS |
| sequence-numbers |O|M/-|-/M|
|
| RESULT | | | |
|
| DeleteResult |M|-/M|M/-|
|
| | | | |
|
| Register-MS | | | |
|
| ARGUMENT | | | |
|
| Register-MSArgument |M|M/-|-/M|
|
| auto-action-registrations |O|O/-|-/O|
|
| type |M|M/-|-/M|
|
| registration-identifier |O|M/-|-/M|
|
| registration-parameter |M|M/-|-/M| See auto action
|
| | | | | registration
parameters |
| auto-action-deregistrations |O|O/-|-/O|
|
| type |M|M/-|-/M|
|
| registration-identifier |O|M/-|-/M|
|
| list-attribute-defaults |O|O/-|-/O| Optional in Basic
MS |
| fetch-attribute-defaults |O|O/-|-/O| Optional in Basic
MS |
| change-credentials |O|M/-|-/M| See Note 1
|
| old-credentials |M|M/-|-/M|
|
| new-credentials |M|M/-|-/M|
|
| user-security-labels |O|O/-|-/O|
|
| RESULT | | | |
|
| Register-MSResult |M|-/M|M/-|
|
| | | | |
158
|
| | | | |
|
+---------------------------------+-+---+---+--------------------
------+
159
Table 35 - Classification of the P7 protocol elements (continued)
+------------------------------------------------------+---------
------+
| MS Access Protocol (P7) | Part 4
of 6 |
+-------------------------------------------+----------+---------
------+
| Support by: |
|
+---------------------------------+-+UA |MS
+--------------------------+
| Protocol Element |S|O/R|O/R| Comments/References
|
+---------------------------------+-+---+---+--------------------
------+
| Alert | | | |
|
| ARGUMENT | | | |
|
| AlertArgument |M|-/M|M/-|
|
| alert-registration-identifier|M|-/M|M/-|
|
| new-entry |O|-/O|M/-| EntryInformation
|
| RESULT | | | |
|
| AlertResult |O|M/-|-/M|
|
| | | | |
|
+---------------------------------+-+---+---+--------------------
------+
| Auto Action Registration | | | |
|
| Parameters | | | |
|
| | | | |
|
| AutoForwardRegistrationParameter| | | |
|
| filter |O|O/-|-/M| Filter
|
| auto-forward-arguments |M|M/-|-/M|
|
| originator-name |M|M/-|-/M|
|
| content-identifier |O|O/-|-/M|
|
| priority |O|O/-|-/M|
160
|
| per-message-indicators |O|M/-|-/M| See P3
MessageSubmission |
| | | | | -Envelope
|
| deferred-delivery-time |O|O/-|-/M|
|
| extensions |O|O/-|-/M| See P3
MessageSubmission |
| | | | | -Envelope
|
| per-recipient-fields |M|M/-|-/M|
|
| recipient-name |M|M/-|-/M|
|
| originator-report-request |M|M/-|-/M|
|
| explicit-conversion |O|O/-|-/M|
|
| extensions |O|O/-|-/M| See P3
MessageSubmission |
| | | | | -Envelope
|
| delete-after-auto-forwarding |O|O/-|-/M|
|
| other-parameters |O|O/-|-/M| See Note 2
|
| auto-forwarding-comment |O|O/-|-/M|
|
| cover-note |O|O/-|-/M|
|
| this-ipm-prefix |O|O/-|-/M|
|
| | | | |
|
| AutoAlertRegistrationParameter | | | |
|
| filter |O|O/-|-/M| Filter
|
| alert-addresses |O|O/-|-/O|
|
| address |M|M/-|-/M|
|
| alert-qualifier |O|O/-|-/O|
|
| requested-attributes |O|M/-|-/M| AttributeSelection
|
| | | | |
|
+---------------------------------+-+---+---+--------------------
161
------+
162
Table 35 - Classification of the P7 protocol elements (continued)
+------------------------------------------------------+---------
------+
| MS Access Protocol (P7) | Part 5
of 6 |
+-------------------------------------------+----------+---------
------+
| Support by: |
|
+---------------------------------+-+UA |MS
+--------------------------+
| Protocol Element |S|O/R|O/R| Comments/References
|
+---------------------------------+-+---+---+--------------------
------+
| Common Data Types | | | |
|
| | | | |
|
| AttributeSelection | | | |
|
| type |M|M/-|-/M|
|
| from |O|O/-|-/M|
|
| count |O|O/-|-/M|
|
| | | | |
|
| AttributeValueAssertion | | | |
|
| type |M|M/-|-/M|
|
| value |M|M/-|-/M|
|
| | | | |
|
| EntryInformation | | | |
|
| sequence-number |M|-/M|M/-|
|
| attributes |O|-/M|M/-|
|
| type |M|-/M|M/-|
|
| values |M|-/M|M/-|
|
| | | | |
|
| Filter | | | |
163
|
| item |O|M/-|-/M| FilterItem
|
| and |O|O/-|-/M| See Note 3
|
| or |O|O/-|-/M| See Note 3
|
| not |O|M/-|-/M| See Note 4
|
| | | | |
|
| FilterItem | | | |
|
| equality |O|O/-|-/M|
AttributeValueAssertion |
| | | | | (Support is
Optional if |
| | | | | ORName)
|
| substrings |O|O/-|-/O|
|
| type |M|M/-|-/M|
|
| strings |M|M/-|-/M|
|
| initial |O|O/-|-/M|
|
| any |O|O/-|-/M|
|
| final |O|O/-|-/M|
|
| greater-or-equal |O|O/-|-/M|
AttributeValueAssertion |
| less-or-equal |O|O/-|-/M|
AttributeValueAssertion |
| present |O|O/-|-/M|
|
| approximate-match |O|O/-|-/O|
|
| | | | |
|
| InformationBase | | | |
|
| stored-messages |O|M/-|-/M|
|
| inlog |O|O/-|-/O|
|
| outlog |O|O/-|-/O|
|
| | | | |
164
|
+---------------------------------+-+---+---+--------------------
------+
165
Table 35 - Classification of the P7 protocol elements (concluded)
+------------------------------------------------------+---------
------+
| MS Access Protocol (P7) | Part 6
of 6 |
+-------------------------------------------+----------+---------
------+
| Support by: |
|
+---------------------------------+-+UA |MS
+--------------------------+
| Protocol Element |S|O/R|O/R| Comments/References
|
+---------------------------------+-+---+---+--------------------
------+
| Range | | | | See Note 6
|
| sequence-number-range |O|O/-|-/M|
|
| from |O|O/-|-/M|
|
| to |O|O/-|-/M|
|
| | | | |
|
| creation-time-range |O|O/-|-/M|
|
| from |O|O/-|-/M|
|
| to |O|O/-|-/M|
|
| | | | |
|
| Selector | | | |
|
| child-entries |O|O/-|-/M|
|
| range |O|O/-|-/M| Range
|
| filter |O|O/-|-/M| Filter
|
| limit |O|M/-|-/M|
|
| override |O|M/-|-/M| Opt'l in Basic MS-
Note 5 |
+---------------------------------+-+---+---+--------------------
------+
| Notes
|
| 1 At least one of simple and/or strong must be specified.
166
|
| 2 The specified syntax of other-parameters is context-specific
|
| - see X.413 section 12.1.
|
| 3 For recursive use of filter, only support of the "item" and
the |
| "not" fields is required; there is only one level of
recursion. |
| 4 For recursive use of filter, only support of the "item"
field |
| is required; there is only one level of recursion.
|
| 5 If one of fetch-restrictions of MSBind and override of
Selector |
| is implemented, the other must also be implemented.
|
| 6 At least one of From or To must be implemented.
|
+----------------------------------------------------------------
------+
167
A.5 Classification of the P1 protocol elements for security
classes
The protocol element classifications used in tables 36 and 37
should be viewed as a delta to the lower security class or, if
there is no lower security class, to the kernel as classified in
table 33. Thus, table 36 shows the additional support required in
P1 to conform to security class S1. Table 37 indicates the
additional support required to support security class S2 (above
and beyond that for security class S1).
NOTES
1 There are no additional classifications for security
class S0.
2 The addition of mandatory content confidentiality does
not affect the P1 protocol.
168
Table 36 - Conformance classification of the P1 protocol elements
for security class S1
+--------------------------------------------------------+-------
--------+
| MTS Transfer Protocol (P1) for Security Class S1 | Part
1 of 2 |
+-----------------------------------------+---+----------+-------
--------+
| MT Kernel Static Support by MTS Class | |
|
+---------------------------------+B/C| A | |
|
| Protocol Element |O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+------------------
--------+
| MTABind | | | |
|
| ARGUMENT | | | |
|
| <SET> | | | |
|
| initiator-credentials | | | M |
|
| simple |O/O|O/O| X |
|
| strong |M/M|M/M| M |
|
| bind-token |M/M|M/M| M |
|
| certificate |O/O|O/O| |
|
| security-context |M/M|M/M| M |
|
| RESULT | | | |
|
| <SET> | | | |
|
| responder-credentials | | | M |
|
| simple |O/O|O/O| X |
|
| strong |M/M|M/M| M |
|
| bind-token |M/M|M/M| M |
|
| certificate |O/O|O/O| |
|
| | | | |
|
169
| MessageTransferEnvelope | | | |
|
| extensions | | | |
|
| message-security-label |M/M|M/M| M |
|
| | | | |
|
+---------------------------------+---+---+---+------------------
--------+
170
Table 36 - Conformance classification of the P1 protocol elements
for security class S1 (concluded)
+--------------------------------------------------------+-------
--------+
| MTS Transfer Protocol (P1) for Security Class S1 | Part
2 of 2 |
+-----------------------------------------+---+----------+-------
--------+
| MT Kernel Static Support by MTS Class | |
|
+---------------------------------+B/C| A | |
|
| Protocol Element |O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+------------------
--------+
| | | | |
|
| ReportTransferEnvelope | | | |
|
| extensions | | | |
|
| message-security-label |M/M|M/M| | See Note 2
|
| per-recipient-fields | | | |
|
| extensions | | | |
|
| message-token |O/O|O/O| M |
|
| asymmetric-token | | | |
|
| signed-data | | | |
|
| message-security-label |M/M|M/M| M | See Note 2
|
| encrypted-data | | | |
|
| message-security-label |M/M|M/M| | See Note 2
|
| | | | |
|
| bind-token | | | |
|
| asymmetric-token | | | | See Note 1
|
| signature-algorithm-identifier|M/M|M/M| M |
|
| name |M/M|M/M| M |
|
171
| time |M/M|M/M| M |
|
| signed-data |M/M|M/M| M |
|
| encryption-algorithm- | | | |
|
| identifier |M/M|M/M| |
|
| encrypted-data |M/M|M/M| |
|
| message-security-label |M/M|M/M| |
|
| content-integrity-key |M/M|M/M| |
|
| | | | |
|
| message-security-label |M/M|M/M| M | See Note 2
|
| security-policy-identifier |M/M|M/M| M |
|
+---------------------------------+---+---+---+------------------
--------+
| Notes
|
| 1 In line with the CCITT MHS Implementors' Guide, the
asymmetric |
| token can be used by symmetric and asymmetric techniques as
|
| identified by the algorithm identifier.
|
| 2 The message security label may appear in any or all of the
|
| indicated locations in the envelope. However the Security
context |
| service applies only to the label in the "extensions" and/or
token |
| signed-data as defined by the security policy in force.
Labels in th|
| token encrypted data have only end-to-end (UA-to-UA)
significance. |
+----------------------------------------------------------------
--------+
172
Table 37 - Conformance classification of the P1 protocol elements
for security class S2
+--------------------------------------------------------+-------
--------+
| MTS Transfer Protocol (P1) for Security Class S2 | Part
1 of 2 |
+-----------------------------------------+---+----------+-------
--------+
| MT Kernel Static Support by MTS Class | |
|
+---------------------------------+B/C| A | |
|
| Protocol Element |O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+------------------
--------+
| MessageTransferEnvelope | | | |
|
| extension | | | |
|
| originator-certificate |M/M|M/M| |
|
| certificate |M/M|M/M| |
|
| certification-path |M/M|M/M| |
|
| message-origin-authentication-| | | |
|
| check |M/M|M/M| M |
|
| algorithm-identifier |M/M|M/M| |
|
| content |M/M|M/M| |
|
| content-identifier |M/M|M/M| |
|
| message-security-label |M/M|M/M| |
|
| | | | |
|
| ProbeTransferEnvelope | | | |
|
| extensions | | | |
|
| originator-certificate |M/M|M/M| |
|
| certificate |M/M|M/M| |
|
| certification-path |M/M|M/M| |
|
173
| probe-origin-authentication- | | | |
|
| check |M/M|M/M| M |
|
| algorithm-identifier |M/M|M/M| |
|
| content-identifier |M/M|M/M| |
|
| message-security-label |M/M|M/M| |
|
| | | | |
|
| ReportTransferEnvelope | | | |
|
| extensions | | | |
|
| reporting-MTA-certificate |M/M|M/M| |
|
| certificate |M/M|M/M| |
|
| certification-path |M/M|M/M| |
|
| report-origin-authentication- | | | |
|
| check |M/M|M/M| M |
|
| algorithm-identifier |M/M|M/M| |
|
| content-identifier |M/M|M/M| |
|
| message-security-label |M/M|M/M| |
|
| per-recipient |M/M|M/M| |
|
| actual-recipient-name |M/M|M/M| |
|
| originally-intended-recipient-| | | |
|
| name |O/O|O/O| |
|
| delivery |O/O|O/O| |
|
| message-delivery-time |M/M|M/M| |
|
| type-of-MTS-user |M/M|M/M| |
|
| recipient-certificate |M/M|M/M| |
|
| proof-of-delivery |M/M|M/M| |
|
174
| non-delivery |O/O|O/O| |
|
| non-delivery-reason-code |M/M|M/M| |
|
| non-delivery-diagnostic-code|O/O|O/O| |
|
+---------------------------------+---+---+---+------------------
--------+
175
Table 37 - Conformance classification of the P1 protocol elements
for security class S2 (concluded)
+--------------------------------------------------------+-------
--------+
| MTS Transfer Protocol (P1) for Security Class S2 | Part
2 of 2 |
+-----------------------------------------+---+----------+-------
--------+
| MT Kernel Static Support by MTS Class | |
|
+---------------------------------+B/C| A | |
|
| Protocol Element |O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+------------------
--------+
| Certificate | | | |
|
| version |M/M|M/M| |
|
| serialNumber |M/M|M/M| |
|
| signature |M/M|M/M| |
|
| algorithm |M/M|M/M| |
|
| parameters |O/O|O/O| |
|
| issuer |M/M|M/M| |
|
| validity |M/M|M/M| |
|
| notBefore |M/M|M/M| |
|
| notAfter |M/M|M/M| |
|
| subject |M/M|M/M| |
|
| subjectPublicKeyInfo |M/M|M/M| |
|
| algorithm |M/M|M/M| |
|
| subjectPublicKey |M/M|M/M| |
|
+---------------------------------+---+---+---+------------------
--------+
176
A.6 Classification of the P3 protocol elements for security
classes
The protocol element classifications in tables 38, 39, and 40
should be viewed as a delta to the lower security class or, if
there is no lower security class, to the kernel as classified in
table 34. Thus, table 38 shows the additional support required in
P3 to conform to security class S0. Table 39 indicates the
additional support required to support security class S1 (above
and beyond that for security class S0). Table 40 indicates the
additional support required to support security class S2 (above
and beyond that for security class S1).
NOTE - There are no dynamic conformance classifications
required by security class S0 (table 38).
177
Table 38 - Conformance classification of the P3 protocol elements
for security class S0
+------------------------------------------------------------+---
------------+
| MTS Access Protocol (P3) for Security Class S0 |
Part 1 of 2 |
+---------------------------------------------+---+----------+---
------------+
| Static Support by: | |
|
+---------------------------------+UA |MS |MTA| |
|
| Protocol Element |O/R|O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+---+--------------
------------+
| MessageDelivery | | | | |
|
| RESULT | | | | |
|
| proof-of-delivery |M/-|M/-|-/O| |
|
| | | | | |
|
| MessageSubmissionEnvelope | | | | |
|
| PerRecipientMessageSubmission | | | | |
|
| Fields | | | | |
|
| extensions | | | | |
|
| message-token |M/-|M/-|-/O| |
|
| asymmetric-token |M/-|M/-|-/O| |
|
| signature-algorithm- | | | | |
|
| identifier |M/-|M/-|-/O| |
|
| name |M/-|M/-|-/O| |
|
| time |M/-|M/-|-/O| |
|
| signed-data |M/-|M/-|-/O| |
|
| content-confidentiality- | | | | |
|
| algorithm-identifier |O/-|O/-|-/O| |
|
178
| content-integrity-check |M/-|M/-|-/O| | See Note 1
|
| message-security-label |O/-|O/-|-/O| |
|
| proof-of-delivery-request |M/-|M/-|-/O| | See Note 1
|
| message-sequence-number |O/-|O/-|-/O| |
|
| encryption-algorithm- | | | | |
|
| identifier |O/-|O/-|-/O| |
|
| encrypted-data |M/-|M/-|-/O| |
|
| content-confidentiality- | | | | |
|
| key |O/-|O/-|-/O| |
|
| content-integrity-check |M/-|M/-|-/O| | See Note 1
|
| message-security-label |O/-|O/-|-/O| |
|
| content-integrity-key |O/-|O/-|-/O| |
|
| message-sequence-number |O/-|O/-|-/O| |
|
| content-integrity-check |M/-|M/-|-/O| | See Note 1
|
| proof-of-delivery-request |M/-|M/-|-/O| | See Note 1
|
+---------------------------------+---+---+---+---+--------------
------------+
179
Table 38 - Conformance classification of the P3 protocol elements
for security class S0 (concluded)
+------------------------------------------------------------+---
------------+
| MTS Access Protocol (P3) for Security Class S0 |
Part 2 of 2 |
+---------------------------------------------+---+----------+---
------------+
| Static Support by: | |
|
+---------------------------------+UA |MS |MTA| |
|
| Protocol Element |O/R|O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+---+--------------
------------+
| MessageDeliveryEnvelope | | | | |
|
| other-fields | | | | |
|
| extensions | | | | |
|
| message-token |-/M|-/M|O/-| |
|
| asymmetric-token |-/M|-/M|O/-| |
|
| signature-algorithm- | | | | |
|
| identifier |-/M|-/M|O/-| |
|
| name |-/M|-/M|O/-| |
|
| time |-/M|-/M|O/-| |
|
| signed-data |-/M|-/M|O/-| |
|
| content-confidentiality- | | | | |
|
| algorithm-identifier |-/O|-/O|O/-| |
|
| content-integrity-check |-/M|-/M|O/-| | See Note 1
|
| message-security-label |-/O|-/O|O/-| |
|
| proof-of-delivery-request |-/M|-/M|O/-| | See Note 1
|
| message-sequence-number |-/O|-/O|O/-| |
|
| encryption-algorithm- | | | | |
|
180
| identifier |-/O|-/O|O/-| |
|
| encrypted-data |-/M|-/M|O/-| |
|
| content-confidentiality- | | | | |
|
| key |-/O|-/O|O/-| |
|
| content-integrity-check |-/M|-/M|O/-| | See Note 1
|
| message-security-label |-/O|-/O|O/-| |
|
| content-integrity-key |-/O|-/O|O/-| |
|
| message-sequence-number |-/O|-/O|O/-| |
|
| content-integrity-check |-/M|-/M|O/-| | See Note 1
|
| proof-of-delivery-request |-/M|-/M|O/-| | See Note 1
|
| | | | | |
|
| ReportDeliveryEnvelope | | | | |
|
| PerRecipientReportDelivery- | | | | |
|
| Fields | | | | |
|
| extensions | | | | |
|
| proof-of-delivery |-/M|-/O|O/-| |
|
+---------------------------------+---+---+---+---+--------------
------------+
| Notes
|
| 1 Implementations shall generate no more that one instance of
these |
| identically-named protocol elements in a single message.
|
+----------------------------------------------------------------
------------+
181
Table 39 - Conformance classification of the P3 protocol elements
for security class S1
+------------------------------------------------------------+---
------------+
| MTS Access Protocol (P3) for Security Class S1 |
Part 1 of 3 |
+---------------------------------------------+---+----------+---
------------+
| Static Support by: | |
|
+---------------------------------+UA |MS |MTA| |
|
| Protocol Element |O/R|O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+---+--------------
------------+
| MTSBind | | | | | MTS to MTS
User |
| ARGUMENT | | | | |
|
| initiator-credentials | | | | M |
|
| simple |-/O|-/O|O/-| X |
|
| strong |-/M|-/M|M/-| M |
|
| bind-token |-/M|-/M|M/-| M |
|
| certificate |-/O|-/O|O/-| |
|
| security-context |-/M|-/M|M/-| M |
|
| RESULT | | | | |
|
| responder-credentials | | | | M |
|
| simple |O/-|O/-|-/O| X |
|
| strong |M/-|M/-|-/M| M |
|
| bind-token |M/-|M/-|-/M| M |
|
| certificate |O/-|O/-|-/O| |
|
| | | | | |
|
| MTSBind | | | | | MTS User to
MTS |
| ARGUMENT | | | | |
|
182
| initiator-credentials | | | | M |
|
| simple |O/-|O/-|-/O| X |
|
| strong |M/-|M/-|-/M| M |
|
| bind-token |M/-|M/-|-/M| M |
|
| certificate |O/-|O/-|-/O| |
|
| security-context |M/-|M/-|-/M| M |
|
| RESULT | | | | |
|
| responder-credentials | | | | M |
|
| simple |-/O|-/O|O/-| X |
|
| strong |-/M|-/M|M/-| M |
|
| bind-token |-/M|-/M|M/-| M |
|
| certificate |-/O|-/O|O/-| |
|
| | | | | |
|
| SubmissionControl |-/M|M/M|M/-| |
|
| ARGUMENT | | | | |
|
| controls | | | | |
|
| permissible-security-context |-/M|-/M|M/-| |
|
| | | | | |
|
| DeliveryControl |M/-|M/-|-/M| |
|
| ARGUMENT | | | | |
|
| controls | | | | |
|
| permissible-security-context |M/-|M/-|-/M| |
|
| | | | | |
|
| Register | | | | |
|
| ARGUMENT | | | | |
|
183
| user-name |M/-|M/-|-/M| |
|
| labels-and-redirections | | | | |
|
| user-security-label |M/-|M/-|-/M| |
|
+---------------------------------+---+---+---+---+--------------
------------+
184
Table 39 - Conformance classification of the P3 protocol elements
for security class S1 (continued)
+------------------------------------------------------------+---
------------+
| MTS Access Protocol (P3) for Security Class S1 |
Part 2 of 3 |
+---------------------------------------------+---+----------+---
------------+
| Static Support by: | |
|
+---------------------------------+UA |MS |MTA| |
|
| Protocol Element |O/R|O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+---+--------------
------------+
| ChangeCredentials | | | | | MTS to
MTSuser |
| ARGUMENT | | | | |
|
| old-credentials | | | | M |
|
| simple |-/O|-/O|O/-| X |
|
| strong |-/M|-/M|M/-| M |
|
| bind-token |-/M|-/M|M/-| M |
|
| certificate |-/O|-/O|O/-| |
|
| new-credentials | | | | M |
|
| simple |-/O|-/O|O/-| X |
|
| strong |-/M|-/M|M/-| M |
|
| bind-token |-/M|-/M|M/-| M |
|
| certificate |-/O|-/O|O/-| |
|
| | | | | |
|
| ChangeCredentials | | | | | MTSuser to
MTS |
| ARGUMENT | | | | |
|
| old-credentials | | | | M |
|
| simple |O/-|O/-|-/O| X |
|
185
| strong |M/-|M/-|-/M| M |
|
| bind-token |M/-|M/-|-/M| M |
|
| certificate |O/-|O/-|-/O| |
|
| new-credentials | | | | M |
|
| simple |O/-|O/-|-/O| X |
|
| strong |M/-|M/-|-/M| M |
|
| bind-token |M/-|M/-|-/M| M |
|
| certificate |O/-|O/-|-/O| |
|
| | | | | |
|
| MessageSubmissionEnvelope | | | | |
|
| extensions | | | | |
|
| message-token |M/-|M/-|-/M| |
|
| signed-data | | | | |
|
| message-security-label |M/-|M/-|-/M| | See Note 1
|
| security-policy-identifier |M/-|M/-|-/M| M |
|
| encrypted-data | | | | |
|
| message-security-label |O/-|O/-|-/O| |
|
| content-integrity-check |M/-|M/-|-/M| M |
|
| message-security-label |M/-|M/-|-/M| | See Note 1
|
| security-policy-identifier |M/-|M/-|-/M| M |
|
| | | | | |
|
| MessageDeliveryEnvelope | | | | |
|
| extensions | | | | |
|
| message-security-label |-/M|-/M|M/-| | See Note 1
|
| security-policy-identifier |-/M|-/M|M/-| M |
|
186
| message-token |-/M|-/M|M/-| |
|
| signed-data | | | | |
|
| message-security-label |-/O|-/O|O/-| | See Note 1
|
| encrypted-data | | | | |
|
| message-security-label |-/O|-/O|O/-| | See Note 1
|
+---------------------------------+---+---+---+---+--------------
------------+
Table 39 - Conformance classification of the P3 protocol elements
for security class S1 (concluded)
+------------------------------------------------------------+---
------------+
| MTS Access Protocol (P3) for Security Class S1 |
Part 3 of 3 |
+---------------------------------------------+---+----------+---
------------+
| Static Support by: | |
|
+---------------------------------+UA |MS |MTA| |
|
| Protocol Element |O/R|O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+---+--------------
------------+
| ReportDeliveryEnvelope | | | | |
|
| extensions | | | | |
|
| message-security-label |-/M|-/M|M/-| M | See Note 1
|
| | | | | |
|
| bind-token | | | | |
|
| asymmetric-token | | | | |
|
| signature-algorithm-identifier|-/M|-/M|M/-| M |
|
| name |-/M|-/M|M/-| M |
|
| time |-/M|-/M|M/-| M |
|
| signed-data |-/M|-/M|M/-| M |
|
| encryption-algorithm- | | | | |
187
|
| identifier |-/M|-/M|M/-| |
|
| encrypted-data |-/M|-/M|M/-| |
|
| message-security-label |-/M|-/M|M/-| |
|
| content-integrity-key |-/M|-/M|M/-| |
|
| | | | | |
|
+---------------------------------+---+---+---+---+--------------
------------+
| Notes
|
| 1 The message-security-label may appear in any or all of the
indicated |
| locations in the envelope. However, the security labelling
context |
| services apply only to the label in the "extensions" field.
Labels in th|
| message token have only end-to-end (UA-to-UA) significance.
|
+----------------------------------------------------------------
------------+
188
Table 40 - Conformance classification of the P3 protocol elements
for security class S2
+------------------------------------------------------------+---
------------+
| MTS Access Protocol (P3) for Security Class S2 |
Part 1 of 2 |
+---------------------------------------------+---+----------+---
------------+
| Static Support by: | |
|
+---------------------------------+UA |MS |MTA| |
|
| Protocol Element |O/R|O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+---+--------------
------------+
| MessageSubmission | | | | |
|
| RESULT | | | | |
|
| extensions | | | | |
|
| originating-MTA-certificate |-/M|-/O|M/-| |
|
| certificate |-/-|-/O|-/-| |
|
| certification-path |-/-|-/O|-/-| |
|
| proof-of-submission |-/M|-/O|M/-| |
|
| | | | | |
|
| MessageDelivery | | | | |
|
| RESULT | | | | |
|
| recipient-certificate |M/-|M/-|-/O| |
|
| certificate |M/-|M/-|-/M| |
|
| certification-path |M/-|M/-|-/M| |
|
| | | | | |
|
| MessageSubmissionEnvelope | | | | |
|
| extensions | | | | |
|
| originator-certificate |M/-|O/-|-/M| |
|
189
| certificate |-/-|-/O|-/-| |
|
| certification-path |-/-|-/O|-/-| |
|
| message-origin- | | | | |
|
| authentication-check |M/-|O/-|-/M| M |
|
| algorithm-identifier |M/-|M/-|-/M| |
|
| content |M/-|M/-|-/M| |
|
| content-identifier |M/-|M/-|-/M| |
|
| message-security-label |M/-|M/-|-/M| |
|
| proof-of-submission-request |M/-|O/-|-/M| |
|
| | | | | |
|
| ProbeSubmissionEnvelope | | | | |
|
| extensions | | | | |
|
| originator-certificate |M/-|O/-|-/M| |
|
| certificate |-/-|-/O|-/-| |
|
| certification-path |-/-|-/O|-/-| |
|
| probe-origin-authentication- | | | | |
|
| check |M/-|O/-|-/M| M |
|
| algorithm-identifier |M/-|M/-|-/M| |
|
| content-identifier |M/-|M/-|-/M| |
|
| message-security-label |M/-|M/-|-/M| |
|
+---------------------------------+---+---+---+---+--------------
------------+
190
Table 40 - Conformance classification of the P3 protocol elements
for security class S2 (concluded)
+------------------------------------------------------------+---
------------+
| MTS Access Protocol (P3) for Security Class S2 |
Part 2 of 2 |
+---------------------------------------------+---+----------+---
------------+
| Static Support by: | |
|
+---------------------------------+UA |MS |MTA| |
|
| Protocol Element |O/R|O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+---+--------------
------------+
| MessageDeliveryEnvelope | | | | |
|
| extensions | | | | |
|
| originator-certificate |-/M|-/M|M/-| |
|
| certificate |-/M|-/M|M/-| |
|
| certification-path |-/M|-/M|M/-| |
|
| message-origin- | | | | |
|
| authentication-check |-/M|-/M|M/-| M |
|
| algorithm-identifier |-/M|-/M|M/-| |
|
| content |-/M|-/M|M/-| |
|
| content-identifier |-/M|-/M|M/-| |
|
| message-security-label |-/M|-/M|M/-| |
|
| | | | | |
|
| ReportDeliveryEnvelope | | | | |
|
| extensions | | | | |
|
| reporting-MTA-certificate |-/M|-/O|M/-| |
|
| certificate |-/-|-/O|-/-| |
|
| certification-path |-/-|-/O|-/-| |
|
191
| report-origin-authentication- | | | | |
|
| check |-/M|-/O|M/-| M |
|
| PerRecipientReportDelivery- | | | | |
|
| Fields | | | | |
|
| extensions | | | | |
|
| recipient-certificate |-/M|-/M|O/-| |
|
| certificate |-/M|-/M|M/-| |
|
| certification-path |-/M|-/M|M/-| |
|
| | | | | |
|
| Certificate | | | | |
|
| version |-/M|-/M|M/-| |
|
| serialNumber |-/M|-/M|M/-| |
|
| signature |-/M|-/M|M/-| |
|
| algorithm |-/M|-/M|M/-| |
|
| parameters |-/O|-/O|O/-| |
|
| issuer |-/M|-/M|M/-| |
|
| validity |-/M|-/M|M/-| |
|
| notBefore |-/M|-/M|M/-| |
|
| notAfter |-/M|-/M|M/-| |
|
| subject |-/M|-/M|M/-| |
|
| subjectPublicKeyInfo |-/M|-/M|M/-| |
|
| algorithm |-/M|-/M|M/-| |
|
| subjectPublicKey |-/M|-/M|M/-| |
|
+---------------------------------+---+---+---+---+--------------
------------+
Table 41 presents the classification delta to classification
192
tables 38, 39, and 40, for the addition of mandatory content
confidentiality in the static conformance classification.
NOTE - There are no dynamic conformance classification
required by the addition of content confidentiality.
193
Table 41 - Conformance classification of the P3 protocol elements
for security classes S0a, S1a, or S2a
+------------------------------------------------------------+---
------------+
| MTS Access Protocol (P3) for Security Classes S0a, S1a, S2a|
Part 1 of 1 |
+---------------------------------------------+---+----------+---
------------+
| Static Support by: | |
|
+---------------------------------+UA |MS |MTA| |
|
| Protocol Element |O/R|O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+---+--------------
------------+
| MessageSubmissionEnvelope | | | | |
|
| extensions | | | | |
|
| content-confidentiality- | | | | |
|
| algorithm-identifier |M/-|O/-|-/O| | See Note 1
|
| message-token | | | | |
|
| asymmetric-token | | | | |
|
| signed-data |M/-|-/-|-/-| |
|
| content-confidentiality- | | | | |
|
| algorithm-identifier |M/-|-/-|-/-| | See Note 1
|
| encrypted-data | | | | |
|
| content-confidentiality- | | | | |
|
| key |M/-|-/-|-/-| |
|
| | | | | |
|
| MessageDeliveryEnvelope | | | | |
|
| extensions | | | | |
|
| message-token |-/M|-/M|O/-| |
|
| asymmetric-token | | | | |
|
194
| signed-data |-/M|-/M|-/-| |
|
| content-confidentiality- | | | | |
|
| algorithm-identifier |-/M|-/M|-/-| | See Note 1
|
| encrypted-data | | | | |
|
| content-confidentiality- | | | | |
|
| key |-/M|-/M|-/-| |
|
| content-confidentiality- | | | | |
|
| algorithm-identifier |-/M|-/M|O/-| | See Note 1
|
+---------------------------------+---+---+---+---+--------------
------------+
| Notes
|
| 1 Implementors shall generate no more than one instance of
these |
| identically named protocol elements in a single message.
|
+----------------------------------------------------------------
------------+
A.7 Classification of the P7 Protocol Elements for Security
Classes
The protocol element classifications in table 42 should be viewed
as a delta to the lower security class or, if there is no lower
security class, to the kernel as classified in table 35. Thus,
table 42 shows the additional support required in P7 to conform
to security class S1.
NOTES
1 There are no additional classifications for security
classes S0 and S2.
2 The addition of mandatory content confidentiality does
not affect the P7 protocol.
195
Table 42 - Conformance classification of the P7 protocol elements
for security class S1
+--------------------------------------------------------+-------
--------+
| MS Access Protocol (P7) for Security Class S1 | Part
1 of 1 |
+-----------------------------------------+---+----------+-------
--------+
| Static Support by: | |
|
+---------------------------------+UA |MS | |
|
| Protocol Element |O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+------------------
--------+
| MSBind | | | |
|
| ARGUMENT | | | |
|
| initiator-credentials | | | M |
|
| simple |O/-|-/O| X |
|
| strong |M/-|-/M| M |
|
| bind-token |M/-|-/M| M |
|
| certificate |O/-|-/O| |
|
| security-context |M/-|-/M| M |
|
| RESULT | | | |
|
| responder-credentials | | | M |
|
| simple |-/O|O/-| X |
|
| strong |-/M|M/-| M |
|
| bind-token |-/M|M/-| M |
|
| certificate |-/O|O/-| |
|
| | | | |
|
| Register-MS | | | |
|
| ARGUMENT | | | |
|
196
| Register-MSArgument | | | |
|
| changeCredentials | | | M |
|
| old-credentials |M/-|-/M| M |
|
| simple |O/-|-/O| M |
|
| strong |M/-|-/M| X |
|
| bind-token |M/-|-/M| M |
|
| certificate |O/-|-/O| |
|
| new-credentials |M/-|-/M| M |
|
| simple |O/-|-/O| X |
|
| strong |M/-|-/M| M |
|
| bind-token |M/-|-/M| M |
|
| certificate |O/-|-/O| |
|
| user-security-labels |M/-|-/M| M |
|
| | | | |
|
| message-security-label | | | |
|
| security-policy-identifier |M/-|-/M| M |
|
| security-classification |M/-|-/M| |
|
| privacy |O/-|-/O| |
|
| security-categories |M/-|-/M| |
|
+---------------------------------+---+---+---+------------------
--------+
197
A.8 Message store general attribute support
Table 43 specifies the classification of the Message Store
General Attributes.
198
Table 43 - Classification of the message store general attributes
+------------------------------------------------------------+---
----------+
| Message Store General Attribute Support |
Part 1 of 2 |
+---------------------------------------+---+----------------+---
----------+
| Support by: |Bas|Enchanced
|
+---------------------------------+-+UA |MS |MS
+--------------------------+
| Attribute |S| R | O | O |
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| child-sequence-numbers |M| M | M | M |
|
| content |M| M | M | M |
|
| content-confidentiality- | | | | |
|
| algorithm-identifier |O| O | O | O |
|
| content-correlator |O| O | O | M |
|
| content-identifier |O| O | O | M |
|
| content-integrity-check |O| O | O | O |
|
| content-length |O| O | M | M |
|
| content-returned |O| O | O | M |
|
| content-type |M| M | M | M |
|
| conversion-with-loss-prohibited |O| O | O | M |
|
| converted-eits |O| O | O | M |
|
| creation-time |M| M | M | M |
|
| delivered-eits |O| O | M | M |
|
| delivery-flags |O| O | O | M |
|
| dl-expansion-history |O| O | O | M |
|
| entry-status |M| M | M | M |
|
| entry-type |M| M | M | M |
199
|
| intended-recipient-name |O| O | O | M |
|
| message-delivery-envelope |M| M | M | M |
|
| message-delivery-identifier |O| O | O | M |
|
| message-delivery-time |O| O | O | M |
|
| message-origin-authentication- | | | | |
|
| check |O| O | O | O |
|
| message-security-label |O| O | O | O |
|
| message-submission-time |O| O | O | M |
|
| message-token |O| O | O | O |
|
| original-eits |O| O | O | M |
|
| originator-certificate |O| O | O | O |
|
| originator-name |O| O | O | M |
|
| other-recipient-names |O| O | M | M |
|
| parent-sequence-number |M| M | M | M |
|
| per-recipient-report-delivery- | | | | |
|
| fields |M| M | M | M |
|
| priority |O| O | M | M |
|
| proof-of-delivery-request |O| O | O | O |
|
| redirection-history |O| O | O | M |
|
| report-delivery-envelope |M| M | M | M |
|
| reporting-dl-name |O| O | O | M |
|
| reporting-mta-certificate |O| O | O | O |
|
+---------------------------------+-+---+---+---+----------------
----------+
200
Table 43 - Classification of the message store general attributes
(concluded)
+------------------------------------------------------------+---
----------+
| Message Store General Attribute Support |
Part 2 of 2 |
+---------------------------------------+---+----------------+---
----------+
| Support by: |Bas|Enhanced
|
+---------------------------------+-+UA |MS |MS
+--------------------------+
| Attribute |S| R | O | O |
Comments/References |
+---------------------------------+-+---+---+---+----------------
----------+
| report-origin-authentication- | | | | |
|
| check |O| O | O | O |
|
| security-classification |O| O | O | O |
|
| sequence-number |M| M | M | M |
|
| subject-submission-identifier |M| M | M | M |
|
| this-recipient-name |O| O | O | M |
|
+---------------------------------+-+---+---+---+----------------
----------+
| Note - Enhanced MS support for optional Functional Groups
is for |
| further study. Attributes which are relevant to these areas
are |
| currently specified as Unsupported.
|
+----------------------------------------------------------------
----------+
201
A.9 Classification of the MS General Attributes for Security
Classes
The classification of the attributes in table 44 is a delta to
the Enhanced MS column of the MS General Attributes in table 43.
Table 44 indicates the additional attributes that must be
supported in the MS for each of the security classes. There is no
support required for security attributes in the basic MS.
Table 44 - MS security attribute support
+-------------------------------------+--------------------------
-------+
| | Security Class
|
|
+----+-----+----+-----+-----+-----+
| Attribute | S0 | S0a | S1 | S1a | S2
| S2a |
+-------------------------------------+----+-----+----+-----+----
-+-----+
| content-confidentiality-algorithm- | | | | |
| |
| identifier | O | M | O | M | O
| M |
| content-integrity-check | M | M | M | M | M
| M |
| message-security-label | O | O | M | M | M
| M |
| message-origin-authentication-check | M | M | M | M | M
| M |
| message-token | M | M | M | M | M
| M |
| origination-certificate | O | O | O | O | M
| M |
| proof-of-delivery | M | M | M | M | M
| M |
| reporting-mta-certificate | O | O | O | O | M
| M |
| report-origin-authentication-check | O | O | O | O | M
| M |
| security-classification | O | O | M | M | M
| M |
+-------------------------------------+----+-----+----+-----+----
-+-----+
202
A.10 Message store IPM attribute support
Table 45 specifies the classification of the Message Store IPM
attributes. This clause is to be read in accordance with Annex C
of X.420 (1988). For support of MS General Attributes, see table
43, enhanced MS column.
203
Table 45 - Classification of the message store IPM attributes
+--------------------------------------------------------+-------
------+
| Message Store IPM Attribute Support | Part 1
of 2 |
+---------------------------------------+---+------------+-------
------+
| Support by: IPM|IPM|
|
+---------------------------------+-+UA |MS
+--------------------------+
| Attribute |S| R | O | Comments/References
|
+---------------------------------+-+---+---+--------------------
------+
| Summary Attributes: | | | |
|
| ipm-entry-type |M| M | M |
|
| ipm-synopsis |O| O | M |
|
| | | | |
|
| Heading Attributes: | | | |
|
| authorizing-users |O| O | M |
|
| auto-forwarded |O| O | M |
|
| blind-copy-recipients |O| O | M |
|
| copy-recipients |O| O | M |
|
| expiry-time |O| O | M |
|
| heading |M| M | M |
|
| importance |O| O | M |
|
| incomplete-copy |O| O | O |
|
| languages |O| O | M |
|
| nrn-requestors |O| O | M |
|
| obsoleted-ipms |O| O | M |
|
| originator |O| O | M |
|
| primary-recipients |O| O | M |
204
|
| related-ipms |O| O | M |
|
| replied-to-ipm |O| O | M |
|
| reply-recipients |O| O | M |
|
| reply-requestors |O| O | M |
|
| reply-time |O| O | M |
|
| rn-requestors |O| O | M |
|
| sensitivity |O| O | M |
|
| subject |O| O | M |
|
| this-ipm |M| M | M |
|
| | | | |
|
| Body Attributes: | | | |
|
| bilaterally-defined-body- | | | |
|
| parts |O| O | O |
|
| body |M| M | M |
|
| encrypted-body-parts |O| O | O |
|
| encrypted-data |O| O | O |
|
| encrypted-parameters |O| O | O |
|
| extended-body-part-types |O| O | M |
|
+---------------------------------+-+---+---+--------------------
------+
205
Table 45 - Classification of the message store IPM attributes
(concluded)
+--------------------------------------------------------+-------
------+
| Message Store IPM Attribute Support | Part 2
of 2 |
+---------------------------------------+---+------------+-------
------+
| Support by: IPM|IPM|
|
+---------------------------------+-+UA |MS
+--------------------------+
| Attribute |S| R | O | Comments/References
|
+---------------------------------+-+---+---+--------------------
------+
| g3-facsimile-body-parts |O| O | O |
|
| g3-facsimile-data |O| O | O |
|
| g3-facsimile-parameters |O| O | O |
|
| g4-class1-body-parts |O| O | O |
|
| ia5-text-body-parts |O| O | M |
|
| ia5-text-data |O| O | O |
|
| ia5-text-parameters |O| O | O |
|
| message-body-parts |O| O | M |
|
| message-data |O| O | O |
|
| message-parameters |O| O | O |
|
| mixed-mode-body-parts |O| O | O |
|
| nationally-defined-body-parts|O| O | O |
|
| teletex-body-parts |O| O | O |
|
| teletex-data |O| O | O |
|
| teletex-parameters |O| O | O |
|
| videotex-body-parts |O| O | O |
|
| videotex-data |O| O | O |
|
206
| videotex-parameters |O| O | O |
|
| voice-body-parts |O| O | O |
|
| voice-data |O| O | O |
|
| voice-parameters |O| O | O |
|
| oda-1984-body-parts |-| O | O |
|
| iso6937-body-parts |-| O | O |
|
| bilaterally-defined-body- | | | |
|
| parts |-| O | O |
|
| usa-privately-defined-body- | | | |
|
| parts |-| O | O |
|
| | | | |
|
| Notification Attributes: | | | |
|
| acknowledgment-mode |O| O | M |
|
| auto-forward-comment |O| O | M |
|
| conversion-eits |O| O | M |
|
| discard-reason |O| O | M |
|
| ipm-preferred-recipient |O| O | M |
|
| ipn-originator |O| O | M |
|
| non-receipt-reason |O| O | M |
|
| receipt-time |O| O | M |
|
| returned-ipm |O| O | O |
|
| subject-ipm |M| M | M |
|
| suppl-receipt-info |O| O | O |
|
+---------------------------------+-+---+---+--------------------
------+
207
A.11 EDI messaging service protocol (Pedi)
208
Table 46 - Classification of the Pedi protocol elements
+--------------------------------------------------------------+-
------------+
| EDI Messaging Service Protocol (Pedi) |
Part 1 of 6 |
+---------------------------------------+----------------------+-
------------+
| Support by EDI |
|
+---------------------------------+-+UA
+------+---+-------------------------+
| Protocol Element |S|O/R| FGs |O/R|
Comments/References |
+---------------------------------+-+---+------+---+-------------
------------+
| InformationObject | | | | |
|
| edim |M|M/M| | |
|
| edin |M|M/M| | |
|
| | | | | |
|
| EDIMIdentifier | | | | |
|
| user |M|M/M| | |
|
| user-relative-identifier |M|M/M| | |
|
| | | | | |
|
| ExtensionField | | | | |
|
| type |M|M/M| | |
|
| criticality |M|M/M| | |
|
| value |M|M/M| | |
|
| | | | | |
|
| EDIM | | | | |
|
| heading |M|M/M| | |
|
| body |M|M/M| | |
|
| | | | | |
|
| Heading | | | | |
209
|
| this-EDIM |M|M/M| | |
|
| originator |O|M/M| | |
|
| recipients |O|M/M| | |
|
| edin-receiver |O|O/M| FWD |M/M|
|
| responsibility-forwarded |O|O/M| FWD |M/M|
|
| edi-bodypart-type |O|M/M| | |
|
| incomplete-copy |O|O/M| FWD |O/M| See Note 2
|
| expiry-time |O|O/M| | |
|
| related-messages |O|O/M| | |
|
| obsoleted-EDIMs |O|O/M| | |
|
| edi-application-security- | | | | |
|
| elements |O|O/O|SEC-C |M/M|
|
| cross-referencing-information |O|O/M| MBP |M/M|
|
| edi-message-type |O|M/M| | |
|
| service-string-advice |O|M/M| | |
|
| syntax-identifier |O|M/M| | |
|
| interchange-sender |O|M/M| | |
|
| date-and-time-of-preparation |O|M/M| | |
|
| application-reference |O|M/M| | |
|
| heading-extensions |O|O/M| | | See Note 3
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
+---------------------------------+-+---+------+---+-------------
------------+
210
Table 46 - Classification of the Pedi protocol elements
(continued)
+--------------------------------------------------------------+-
------------+
| EDI Messaging Service Protocol (Pedi) |
Part 2 of 6 |
+---------------------------------------+----------------------+-
------------+
| Support by EDI |
|
+---------------------------------+-+UA
+------+---+-------------------------+
| Protocol Element |S|O/R| FGs |O/R|
Comments/References |
+---------------------------------+-+---+------+---+-------------
------------+
| RecipientSubfield | | | | |
|
| recipient |M|M/M| | |
|
| action-request |O|O/M| | |
|
| edi-notification-requests-field|O|M/M| | |
|
| responsibility-passing-allowed |O|M/M| | |
|
| interchange-recipient |O|M/M| | |
|
| recipient-reference |O|M/M| | |
|
| interchange-control-reference |O|M/M| | |
|
| processing-priority-code |O|M/M| | |
|
| acknowledgement-request |O|M/M| | |
|
| communications-agreement-id |O|M/M| | |
|
| test-indicator |O|M/M| | |
|
| authorization-information |O|M/M| | |
|
| recipient-extensions |O|O/M| | | See Note 3
|
| | | | | |
|
| EDINotificationRequestsFields | | | | |
|
| edi-notification-requests |O|M/M| | |
|
211
| edi-notification-security |O|O/O|SEC-A |M/M|
|
| | | |SEC-B |M/M|
|
| edi-reception-security |O|O/O|SEC-A |M/M|
|
| | | |SEC-B |M/M|
|
| | | | | |
|
| InterchangeRecipientField | | | | |
|
| recipient-identification |M|M/M| | |
|
| identification-code-qualifier |O|M/M| | |
|
| routing-address |O|M/M| | |
|
| | | | | |
|
| RecipientReferenceField | | | | |
|
| recipient-reference |M|M/M| | |
|
| recipient-reference-qualifier |O|M/M| | |
|
| | | | | |
|
| EDINReceiverField | | | | |
|
| edin-receiver-name |M|M/M| | |
|
| original-edim-identifier |O|O/M| FWD |M/M|
|
| first-recipient |O|O/M| FWD |M/M|
|
| | | | | |
|
| RelatedMessagesField | | | | |
|
| RelatedMessageReference |M|M/M| | |
|
| edi-message-reference |O|M/M| | |
|
| external-message-reference |O|M/M| | |
|
| | | | | |
|
| EDIApplicationSecurityElements- | | | | |
|
212
| Field | | | | |
|
| edi-application-security- | | | | |
|
| element |O|M/M| | |
|
| edi-encrypted-primary-bodypart |O|M/M| | |
|
| edi-application-security- | | | | |
|
| extensions |O|O/M| | | See Note 3
|
| | | | | |
|
+---------------------------------+-+---+------+---+-------------
------------+
213
Table 46 - Classification of the Pedi protocol elements
(continued)
+--------------------------------------------------------------+-
------------+
| EDI Messaging Service Protocol (Pedi) |
Part 3 of 6 |
+---------------------------------------+----------------------+-
------------+
| Support by EDI |
|
+---------------------------------+-+UA
+------+---+-------------------------+
| Protocol Element |S|O/R| FGs |O/R|
Comments/References |
+---------------------------------+-+---+------+---+-------------
------------+
| CrossReferencingInformation- | | | | |
|
| Subfield | | | | |
|
| application-cross-reference |M|M/M| | |
|
| message-reference |O|M/M| | |
|
| body-part-reference |M|M/M| | |
|
| | | | | |
|
| ServiceStringAdviceField | | | | |
|
| component-data-element- | | | | |
|
| separator |M|M/M| | |
|
| data-element-separator |M|M/M| | |
|
| decimal-notation |M|M/M| | |
|
| release-indicator |O|M/M| | |
|
| reserved |O|M/M| | |
|
| segment-terminator |M|M/M| | |
|
| | | | | |
|
| SyntaxIdentifierField | | | | |
|
| syntax-identifier |M|M/M| | |
|
214
| syntax-version |M|M/M| | |
|
| | | | | |
|
| InterchangeSenderField | | | | |
|
| sender-identification |M|M/M| | |
|
| identification-code-qualifier |O|M/M| | |
|
| address-for-reverse-routing |O|M/M| | |
|
| | | | | |
|
| AuthorizationInformationField | | | | |
|
| authorization-information |M|M/M| | |
|
| authorization-information- | | | | |
|
| qualifier |O|M/M| | |
|
| | | | | |
|
| Body | | | | |
|
| primary-body-part |M|M/M| | |
|
| additional-body-parts |O|O/M| MBP |M/M|
|
| | | | | |
|
| PrimaryBodyPart | | | | |
|
| edi-body-part |O|M/M| | |
|
| forwarded-EDIM |O|O/M| FWD |M/M|
|
| | | | | |
|
| EDIMBodyPart | | | | |
|
| parameters |O|O/M| FWD |M/M|
|
| message-data |M|M/M| | |
|
| | | | | |
|
| MessageParameters | | | | |
|
215
| delivery-time |O|O/M| FWD |M/M| See Note 1
|
| delivery-envelope |O|O/M| FWD |M/M| See Note 1
|
+---------------------------------+-+---+------+---+-------------
------------+
Table 46 - Classification of the Pedi protocol elements
(continued)
+--------------------------------------------------------------+-
------------+
| EDI Messaging Service Protocol (Pedi) |
Part 4 of 6 |
+---------------------------------------+----------------------+-
------------+
| Support by EDI |
|
+---------------------------------+-+UA
+------+---+-------------------------+
| Protocol Element |S|O/R| FGs |O/R|
Comments/References |
+---------------------------------+-+---+------+---+-------------
------------+
| other-parameters |O|O/O| | | See Note 4
|
| | | | | |
|
| MessageData | | | | |
|
| heading |M|M/M| | |
|
| body |M|M/M| | |
|
| | | | | |
|
| BodyOrRemoved | | | | |
|
| primary-or-removed |M|M/M| | |
|
| additional-body-parts |O|O/M| FWD |M/M|
|
| | | | | |
|
| PrimaryOrRemoved | | | | |
|
| removed-edi-body |O|O/M| | | See Note 5
|
| primary-body-part |O|M/M| | |
|
| | | | | |
216
|
| AdditionalBodyParts | | | | |
|
| external-body-part |O|M/M| | |
|
| place-holder |O|O/M| | | See Note 5
|
| | | | | |
|
| EDIM-ExternallyDefinedBodyPart | | | | |
|
| body-part-reference |O|M/M| | |
|
| external-body-part |M|M/M| | |
|
| | | | | |
|
| EDIN | | | | |
|
| positive-notification |O|M/M| | |
|
| negative-notification |O|M/M| | |
|
| forwarded-notification |O|O/M| FWD |M/M|
|
| | | | | |
|
| CommonFields | | | | |
|
| subject-edim |M|M/M| | |
|
| edin-originator |M|M/M| | |
|
| first-recipient |O|M/M| | |
|
| notification-time |M|M/M| | |
|
| notification-security-elements |O|O/O|SEC-A |M/M| See Note 8
|
| | | |SEC-B |M/M| See Note 8
|
| | | |SEC-C |M/M| See Note 8
|
| edin-initiator |M|M/M| | |
|
| notifications-extensions |O|O/M| | | See Note 3
|
| | | | | |
|
| SecurityElementField | | | | |
217
|
| original-content |O|O/O|SEC-A |M/M| See Note 6
|
| | | |SEC-B |M/M|
|
| original-content-integrity- |O|O/O|SEC-A |M/M| See Note 6
|
| check | | |SEC-B |M/M|
|
| edi-application-security- | | | | |
|
| elements |O|O/O|SEC-C |M/M|
|
| security-extensions |O|O/M| | | See Note 3
|
+---------------------------------+-+---+------+---+-------------
------------+
218
Table 46 - Classification of the Pedi protocol elements
(continued)
+--------------------------------------------------------------+-
------------+
| EDI Messaging Service Protocol (Pedi) |
Part 5 of 6 |
+---------------------------------------+----------------------+-
------------+
| Support by EDI |
|
+---------------------------------+-+UA
+------+---+-------------------------+
| Protocol Element |S|O/R| FGs |O/R|
Comments/References |
+---------------------------------+-+---+------+---+-------------
------------+
| PositiveNotificationFields | | | | |
|
| pn-common-fields |M|M/M| | |
|
| pn-supplementary-information |O|O/M| | |
|
| pn-extensions |O|O/M| | | See Note 3
|
| | | | | |
|
| NegativeNotificationFields | | | | |
|
| nn-common-fields |M|M/M| | |
|
| nn-reason-code |M|M/M| | |
|
| nn-supplementary-information |O|M/M| | |
|
| nn-extensions |O|O/M| | | See Note 3
|
| | | | | |
|
| NNReasonCodeField | | | | |
|
| nn-ua-ms-reason-code |O|M/M| | |
|
| nn-user-reason-code |O|M/M| | |
|
| nn-pdau-reason-code |O|O/M| | |
|
| | | | | |
|
| NNUAMSReasonCodeField | | | | |
|
219
| nn-ua-ms-basic-code |M|M/M| | |
|
| nn-ua-ms-diagnostic |O|M/M| | |
|
| | | | | |
|
| NNUserReasonCodeField | | | | |
|
| nn-user-basic-code |M|M/M| | |
|
| nn-user-diagnostic |O|M/M| | |
|
| | | | | |
|
| NNPDAUReasonCodeField | | | | |
|
| nn-pdau-basic-code |M|M/M| | |
|
| nn-pdau-diagnostic |O|M/M| | |
|
| | | | | |
|
| ForwardNotificationFields | | | | |
|
| fn-common-fields |M|M/M| | |
|
| forwarded-to |M|M/M| | |
|
| fn-reason-code |M|M/M| | |
|
| fn-supplementary-information |O|O/M| FWD |M/M|
|
| fn-extensions |O|O/M| | | See Note 3
|
| | | | | |
|
| FNReasonCodeField | | | | |
|
| fn-ua-ms-reason-code |M|O/M| | | See Note 7
|
| fn-user-reason-code |O|O/M| | | See Note 7
|
| fn-pdau-reason-code |O|O/M| | |
|
| | | | | |
|
| FNUAMSReasonCodeField | | | | |
|
| fn-ua-ms-basic-code |M|M/M| | |
|
220
| fn-ua-ms-diagnostic |O|M/M| | |
|
| fn-security-check |O|O/O|SEC-A |M/M|
|
| | | |SEC-B |M/M|
|
| | | | | |
|
+---------------------------------+-+---+------+---+-------------
------------+
Table 46 - Classification of the Pedi protocol elements
(concluded)
+--------------------------------------------------------------+-
------------+
| EDI Messaging Service Protocol (Pedi) |
Part 6 of 6 |
+---------------------------------------+----------------------+-
------------+
| Support by EDI |
|
+---------------------------------+-+UA
+------+---+-------------------------+
| Protocol Element |S|O/R| FGs |O/R|
Comments/References |
+---------------------------------+-+---+------+---+-------------
------------+
| FNUserReasonCodeField | | | | |
|
| fn-user-basic-code |M|M/M| | |
|
| fn-user-diagnostic |O|O/M| FWD |M/M|
|
| | | | | |
|
| FNPDAUReasonCodeField | | | | |
|
| fn-pdau-basic-code |M|M/M| | |
|
| fn-pdau-diagnostic |O|M/M| | |
|
| | | | | |
|
+---------------------------------+-+---+------+---+-------------
------------+
| Notes
|
| 1 M on origination if the implementation supports forwarding
of a multi |
| part EDIM without accepting responsibility.
221
|
| 2 Mandatory (on origination) when an implementation supports
the |
| removal of body parts.
|
| 3 Critical extensions must be supported in order to accept
|
| responsibility.
|
| 4 Use of supplementary information fields requires bilateral
agreement. |
| 5 Mandatory on origination if removal of body parts is
supported. |
| 6 One of these two elements must be supported on origination
when using |
| the SEC-A or SEC-B EDI security class.
|
| 7 One of these two elements must be supported on origination.
|
| 8 M on origination if EDI-notification-security or EDI-
reception-security |
| (of the EDINotificationRequestsFields) are supported on
reception. |
+----------------------------------------------------------------
------------+
A.12 Message store EDIMS attribute support
A.13 Classification of the P3 protocol elements for physical
delivery
The protocol elements used in Table 48 should be viewed as a
delta to the kernel as classified in Table 34. Thus, Table 48
shows the additional supported required in P3 to conform to the
Physical Delivery functional group.
222
Table 48 - Classification of the P3 protocol elements for
physical delivery
+------------------------------------------------------------+---
------------+
| MTS Access Protocol (P3) for Physical Delivery |
Part 1 of 1 |
+---------------------------------------------+---+----------+---
------------+
| Static Support by: | |
|
+---------------------------------+UA |MS |MTA| |
|
| Protocol Element |O/R|O/R|O/R|Dyn|
Comments/References |
+---------------------------------+---+---+---+---+--------------
------------+
| MessageSubmissionEnvelope | | | | |
|
| extensions | | | | |
|
| originator-return-address |M/-|M/-|-/M| |
|
| PerRecipientMessageSubmission | | | | |
|
| Fields | | | | |
|
| extensions | | | | |
|
| physical-forwarding- | | | | |
|
| prohibited |M/-|M/-|-/M| |
|
| certification-path |M/-|M/-|-/M| |
|
| | | | | |
|
| ORName | | | | |
|
| extension-attributes | | | | |
|
| physical-delivery-country- | | | | |
|
| name |M/-|M/-|-/M| |
|
| postal-code |M/-|M/-|-/M| |
|
| unformatted-postal-code |M/-|M/-|-/M| |
|
+---------------------------------+---+---+---+---+--------------
------------+
223
224
Annex B (normative)
Object identifiers
B.1 X.400 SIG object identifiers
The X.400 SIG object identifiers all allocated under the mhsig
node in the OIW object identifier subtree, as defined in part 6
of the Stable Implementors Agreements document. This definition
is duplicated in figure 15.
+----------------------------------------------------------------
------------+
|
|
| id-mhsig OBJECT IDENTIFIER ::=
|
| { iso (1) identified-organization (3) oiw (14)
mhsig (6) } |
|
|
+----------------------------------------------------------------
------------+
Figure 15 - Definition of the mhsig object identifier
The X.400 SIG has defined several categories of object
identifiers. Their definition is provided in figure 16.
225
+----------------------------------------------------------------
------------+
|
|
| id-mhsig-content-types OBJECT IDENTIFIER ::=
|
| { id-mhsig content-types (0) }
|
|
|
| id-mhsig-body-part-types OBJECT IDENTIFIER ::=
|
| { id-mhsig body-part-types (1) }
|
|
|
+----------------------------------------------------------------
------------+
Figure 16 - Defintion of the X.400 SIG Object Identifier
Categories.
B.2 Content types
There are presently no object identifiers for content types
allocated by the X.400 SIG.
B.3 Body part types
The object identifiers for the external body part types allocated
by the X.400 SIG are defined in figure 17.
226
+----------------------------------------------------------------
------------+
|
|
| id-privacy-enhanced-mail OBJECT IDENTIFIER ::=
|
| { id-mhsig-body-part-types pem (0)
} |
|
|
+----------------------------------------------------------------
------------+
Figure 17 - Definition of the External body part object
identifiers
B.4 Security classes
The ASN.1 expressed in figure 18 defines the security Object
Identifiers specified by these Implementation Agreements. These
are the same as defined in the EWOS/ETSI A/3311 profile.
227
+----------------------------------------------------------------
------------+
| id-mhs-security OBJECT IDENTIFIER ::= { iso (1)
|
| identified-organization (3) ewos (16) eg (2) mhs (4)
security (4) } |
|
|
| id-policy-id OBJECT IDENTIFIER ::= { id-mhs-
security 1 } |
| id-category-id OBJECT IDENTIFIER ::= { id-mhs-
security 2 } |
|
|
| -- Security Policy Object Identifiers --
|
|
|
| security-class-0 OBJECT IDENTIFIER ::= { id-policy-
id 0 } |
| security-class-0a OBJECT IDENTIFIER ::= { id-policy-
id 0 1 } |
| security-class-1 OBJECT IDENTIFIER ::= { id-policy-
id 1 } |
| security-class-1a OBJECT IDENTIFIER ::= { id-policy-
id 1 1 } |
| security-class-2 OBJECT IDENTIFIER ::= { id-policy-
id 2 } |
| security-class-2a OBJECT IDENTIFIER ::= { id-policy-
id 2 1 } |
|
|
| -- Security Category Object Identifiers --
|
|
|
| private-id OBJECT IDENTIFIER ::= { id-category-
id 0 } |
| confidence-id OBJECT IDENTIFIER ::= { id-category-
id 1 } |
| commercial-in-confidence-id OBJECT IDENTIFIER ::= { id-category-
id 2 } |
| management-in-confidence-id OBJECT IDENTIFIER ::= { id-category-
id 3 } |
| personal-in-confidence-id OBJECT IDENTIFIER ::= { id-category-
id 4 } |
+----------------------------------------------------------------
------------+
Figure 18 - Security object identifiers
228
Annex C (informative)
Interpretation of elements of service
The objective of this clause is to provide clarification, where
required, on the functionality of Elements of Service where the
MHS standards are unclear or ambiguous. It is not the intent of
this clause to define how information should be made available or
presented to an MHS user, nor is it intended to define how
individual vendors should design their products.
The following MHS Elements of Service require further text to be
added to their definitions to represent the proposed
implementation of these Elements of Service for conformance to
this Agreement. Elements of Service which are not referenced in
this clause are as defined in the MHS base standards.
Reply Request Indication: The reply-recipients and the reply-time
may be specified without any explicit reply being requested.
This may be interpreted by the recipient as an implicit reply
request.
NOTE - For an auto-forwarded message an explicit or implicit
reply request may not be meaningful.
Forwarded IP-message Indication: The following use of the
original encoded information type in the context of forwarded
messages is clarified:
a) The encoded information types of the message being
forwarded should be reflected in the new original encoded
information types being generated.
b) If forwarding a privately defined body part (see figure
10), the originator of the forwarding message shall set the
original encoded information types in the P1 envelope to
Undefined for that body part.
229
Annex D (informative)
Recommended practices
This clause provides guidelines on areas not addressed by the
base standards. These guidelines have been produced in order to
promote awareness of interim solution to problems as agree by
members of the OIW X.400 SIG. However implementors of these
recommended practices should note that it is not necessary to
follow the recommended practices when claiming conformance to
these agreements.
Implementors should also note that future standardization by
CCITT and ISO/IEC on area covered by this clause may result in
different solutions to those proposed in this clause.
D.1 Printable String
There are existing mail systems that include a small set of non-
Printable String characters in their identifiers. For these
systems to communicate with MHS systems, either for pass-through
service or delivery to MHS users, gateways will be employed to
encode these special characters into a sequence of Printable
String characters. This conversion should be performed by the
gateway according to a common scheme and before insertion in
Domain Defined Attributes, which are intended to carry electronic
mail identifiers. MHS UAs may also perform such conversions.
It is recommended that the following symmetrical encoding and
decoding algorithm for non-Printable String characters be
employed. The encoding algorithm maps an ASCII representation to
a PrintableString representation. Any non-printable string
characters not specified in table 49 are covered by the category
"other."
Table 49 - Printable String to ASCII mapping
+--------------------+----------------------------+
| ASCII Character | Printable String Character |
+--------------------+----------------------------+
| % (percent) | (p) |
| @ (at sign) | (a) |
| ! (exclamation) | (b) |
| " (quote mark) | (q) |
| _ (underline) | (u) |
| ( (left paren.) | (l) |
| ) (right paren.) | (r) |
| other | (3DIGIT) |
+--------------------+----------------------------+
230
where 3DIGIT has the range 000 to 377 and is interpreted as the
octal encoding of an ASCII character.
To encode an ASCII representation to a PrintableString, table 48
and the algorithm in figure 19 should be used.
+-------------------------------------------------------+
| IF current character is in the encoding set THEN |
| encode the character according to table 48 |
| ELSE |
| write the current character; |
| continue reading; |
+-------------------------------------------------------+
Figure 19 - ASCII to PrintableString algorithm
To decode a PrintableString representation to an ASCII
representation, table 48 and the algorithm in figure 20 should be
used.
+-------------------------------------------------------+
| IF current character is not "(" THEN |
| write character |
| ELSE |
| { |
| look ahead appropriate characters; |
| IF composite characters are in table 48 THEN |
| decode per table 48 |
| ELSE |
| write current character; |
| } |
| continue reading; |
+-------------------------------------------------------+
Figure 20 - PrintableString to ASCII algorithm
D.2 Rendition of IA5Text
The characters that may be used in an IA5String are the graphic
characters (including Space), control characters and Delete of
the IA5 character repertoire ISO 646.
The graphic characters that may be used with a guaranteed
rendition are those related with positions 2/0 to 2/2, 2/5 to
3/15, 4/1 to 5/10, 5/15 and 6/1 to 7/10 in the basic 7-bit code
table.
The other graphic characters may be used but have no guaranteed
rendition.
The control characters that may be used but have no guaranteed
231
effect are a subset consisting of the format effectors 0/10 (LF),
0/12 (FF) and 0/13 (CR) provided they are used in one of the
following combinations as defined in table 50.
Table 50 - Interpretation of format effector combinations
+-------------+----------------------------------------------+
| Combination | Interpretation |
+-------------+----------------------------------------------+
| CR LF | to start a new line |
| CR FF | to start a new page (and line) |
| LF .. LF | to show empty lines (always after one of the |
| | preceding combinations). |
+-------------+----------------------------------------------+
The other control characters or the above control characters in
different combinations may be used but have no guaranteed effect.
The character Delete may occur but has no guaranteed effect. The
IA5String in a P2 IA5Text BodyPart represents a series of lines
which may be divided into pages. Each line should contain from 0
to 80 graphic characters for guaranteed rendition. Longer lines
may be arbitrarily broken for rendition.
NOTE - X.408 states that for conversion from IA5Text to
Teletex, the maximum line length is 77 characters.
D.3 EDI use of MHS
D.3.1 P0 recommended practice
This section outlines a recommended method for interworking
between a P(edi) UA with a UA implementing the Recommended
Practice (EDI Use of X.400) in parts 7 and 8 of the OIW Stable
Implementation Agreements. That Recommended Practice is
commonly referred to as the "P0" approach to EDI use of the X.400
MTS.
This section does not define where the conversion between the two
content types occurs. It is possible for the conversion to be
performed by the P0 UA, the P(edi) UA, or a gateway. The
Recommended Practice outlined in this section only attempts to
document the rules that should be followed to ensure a conversion
which retains the maximum amount of information.
232
D.3.1.1 P0 to P(edi) conversion
The converting entity may assume that the P0 content contains
only one EDI interchange. This interchange will become the first
and only body part of the EDIM.
The content type field of the message will have the value
"undefined" before the conversion and will have the integer value
"35" or the object identifier value for P(edi) which is specified
in X.435 after conversion. The EDIM Heading fields can be formed
using the following rules:
EDIMIdentifier: Originator ORName concatenated with the UTCTime
at which the conversion from P0 to P(edi) was performed.
Originator: Originator ORName.
Recipients: Recipients from the P1 envelope. EDI Notification
Requests are not specified as none are requested when using the
P0 approach.
EDIBodyPartType: This element may have one of deveral values
depending on the encoded information type (EIT) value of the P0
message or the ability of the converting entity to determine
which EDI syntax is present in the content:
a) X.435-defined value for ANSI X12/EBCDIC if the EIT field
of the P1 envelope has the value "undefined".
b) X.435-defined value for ANSI X12/ISO 646 if the EIT
field of the P1 envelope has the value "IA5String".
c) Any other valid value if the entity performing the
conversion can determine which EDI syntax is contained in
the content and which character encoding is used for the EDI
syntax.
Other heading fields will only be set if the entity performing
the conversion is capable of parsing the EDI Interchange and
discovering the correct values of EDI Heading fields.
As the P0 message will not contain requests for EDI
Notifications, an EDI UA will never create an EDIN when it
receives an EDIM converted from P0 .
D.3.1.2 P(edi) to P0 conversion
When converting a P(edi) content to a P0 content, the following
rules apply:
233
The first body part of the EDIM will be copied to the content.
All other body parts of the EDIM will be discarded.
The P1 envelope fields shall have the following values:
Content Type: Value for "undefined".
Originator: Originator ORName.
Recipients: Recipients from the EDIM Heading. An NN EDIN with NN
Reason Code set to the value "unspecified" is created for each
Recipient for whom a Notification Request was specified. The
EDIN Originator is set to the Recipient ORName. It is
recommended that the supplementary information field of the NN be
used to provide additional information on the disposition of the
EDIM.
Encoded Information Types (EITs): This element may have one of
several values depending on the value of the EDI Body Part Type:
a) The EIT is set to "undefined" if the EDI Body Part Type
is encoded with the EBCDIC character set.
b) The EIT is set to "IA5String" if the EDI Body Part Type
is encoded using the ISO 646 (ASCII) character set.
c) A value is not present for the EIT if EDI Body Part Type
does not contain one of the above mentioned values.
D.3.2 P2 recommended practice
As there are a substantial number of users in the NIST OIW
community that implemented the CEC TEDIS "P2" approach to EDI use
of the X.400 MTS, this section will also include text that
describes interworking between a P(edi) UA and a P2 UA. This
text is not maintained by the EDI Working Group of the NIST OIW
X.400 SIG but is included for the convenience of our user
community. Users intending to interwork between P2 and P(edi)
User Agents should consult the current version of the EWOS/ETSI
document "A/3331 - Functional Profile of an Electronic Data
Interchange User Agent." This will ensure that the most up to
date technical information is obtained.
D.3.2.1 Conversion from IPMS to EDIMS (P2 to P(edi))
It is assumed that there is one and only one body part in the IPM
Message, and that this body part contains an EDI interchange.
234
The IPM becomes the first, and only, body part of the EDIM.
The EDIM Heading fields are set as follows:
EDIMIdentifier: Originator ORName concatenated with the
LocalIPMIdentifier portion of the IPM Identifier.
Originator: Originator ORName.
Recipients: Recipient ORNames from the IPM Heading. The edi-
notification-requests-field is not coded.
EDIBodyPartType: The value is a local implementation issue. If
the entity performing the conversion can identify the EDI syntax
of the EDI Interchange then it can specify an appropriate value.
Otherwise, the entity must be assuming a specific encoding and
will specify the value for the syntax it is assuming.
Other heading fields may be set if the entity performing the
conversion is capable of parsing the EDI Interchange and
discovering the correct values of the EDIM Heading fields.
Since there are not notification requests, the EDI UA will never
create an EDIN when it receives a converted EDIM and therefore
the action for handling EDINs in the reverse direction does not
need to be considered.
D.3.2.2 Conversion from EDIMS to IPMS (P(edi) to P2)
NOTE - The verification of authority to perform a particular
conversion is outside the scope of this annex. It is
assumed that such conversion will be done with the full
knowledge of the originating and recipient parties.
The EDIBodyPart of the EDIM will be copied to the IPM body as an
IA5TextBodyPart. All other body parts of the EDIM will be
discarded.
The IPM Heading fields are set as follows:
IPM Identifier: EDIMIdentifier.
Originator: Originator ORName.
Recipients: Recipients from the EDIM Heading. All recipients
become IPM Primary Recipients. An NN EDIN with NN Reason Code
set to the value "unspecified" is created for each Recipient for
whom a Notification Request was specified. The EDIN Originator
is set to the Recipient ORName. The EDIN Originator is set to
235
the Recipient ORName. IPM Notifications shall not be requested.
Subject: Not present or set to a single blank character.
If EDINs have been requested the originator will always receive
an NN. Since no IPM notifications are requested, the IPM UA will
never create an IPM notification when it receives an IPM
converted from an EDIM and therefore handling of notifications in
the reverse direction does not need to be considered and is not
an option for generating EDINs.
D.4 ODA transfer
To ease interworking with 1984 implementations when transferring
Office Document Architecture (ODA) documents, the following are
recommended for 1988 implementations:
a) Origination UA implementing 1988 Implementation
Agreements. The 1988 will generate the ODA according to
CCITT Recommendation T.411 Annex E for the destination UA(s)
implementing 1988 Implementation Agreements. If the
destination UA supports 1984 Implementation Agreements, the
approach as described in section 7.12.8 is recommended.
b) Recipient UA implementing 1988 Implementation
Agreements. The recipient system will be able to handle the
ODA bodypart in P2 (1984) as defined in part 7, B.8.1 for
interworking with 1984 implementation, and will also be able
to handle the ODA bodypart as defined in the appropriate
base standards.
c) MTA downgrading rules. When transferring an P22 with ODA
body part in P22 as described in T.411 to an 1984 MTA, the
EITs identified by ODA Object Identifiers are mapped to bits
0 and 10 of the built-in EITs.
If the UA does not register to support P22 or ODA bodypart, a
Non-Delivery-Report will be generated as required.
D.5 Use of externally defined body part
D.5.1 General
An Externally Defined body part represents an information object
whose semantics and abstract syntax are denoted by an Object
Identifier which the body part carries. This body part type
enables the exchantge of information objects of all kinds, each
236
unambiguously and uniquely identified.
The Externally Defined Body Part definition is reproduced in
figure 22.
237
+----------------------------------------------------------------
------------+
|
|
| ExternallyDefinedBodyPart ::= SEQUENCE {
|
| parameters [0]
ExternallyDefinedParameters OPTIONAL,|
| data ExternallyDefinedData }
|
|
|
| ExternallyDefinedParameters ::= EXTERNAL
|
| ExternallyDefinedData ::= EXTERNAL
|
|
|
| EXTERNAL ::= [UNIVERSAL 8] IMPLICIT
SEQUENCE { |
| direct-reference OBJECT IDENTIFIER OPTIONAL,
|
| indirect-reference INTEGER OPTIONAL,
|
| data-value-descriptor ObjectDescriptor OPTIONAL,
|
| encoding CHOICE {
|
| single-ASN1-type [0] ANY,
|
| octet-aligned [1] IMPLICIT OCTET STRING,
|
| arbitrary [2] IMPLICIT BIT STRING }
} |
+----------------------------------------------------------------
------------+
| Note - In the case of transfer of EXTERNAL in P2 BodyPart,
the |
| direct-reference component is mandatory and the indirect-
reference and |
| data-value-descriptor components must be absent.
|
+----------------------------------------------------------------
------------+
Figure 22 - Externally Defined body part definition
On the basis of the Externally Defined body part type, all body
part types are divided into two important classes as follows:
a) basic: Said of any body part type except Externally
238
Defined. All basic body part types are denoted by an
integer (an ASN.1 context-specific tag) and are defined in
section 7.3 of X.420.
b) extended: Said of the Externally Defined body part type
restricted to any one value of the Direct-reference
component of the Data component of such a body part.
Denoted by an Object Identifier.
Annex B of Recommendation X.420 defines some (but not necessarily
all) extended body part types.
D.5.2 Use of equivalents of basic body part types
For each basic body part types, section B.1 of Recommendation
X.420 defines an equivalent extended body part type. In order to
facilitate interworking with 1984 systems, use of these extended
body part types is not recommended; the basic body part types
should be used instead.
Editor's Note: The requirements of this clause may change when
interworking with 1984 systems is no longer
critical.
D.5.3 Use of General Text body part type
Unless otherwise specified in these agreements (e.g., IA5Text,
6937Text, Teletex) the General Text body part as defined in ISO
10021-7 Annex B.2 is the preferred means of supporting
unstructured text body parts. The character set registration
referred to in that annex is provided by ECMA.
D.5.4 Use of File Transfer body part type
The File Transfer body part type is the recommended mechanism for
the exchange of complex computer data via intra- and inter-
company X.400 messages. It enables automatic type recognition
for the file being sent and, possibly, automatic invocation of
the appropriate application necessary to process the data.
D.5.4.1 Encoding of General Identifier
In order to optimize the machine-processing of information
encoded in the Parameters and to enable registration, it is
recommended that, if present, General Identifiers should be
encoded as Object Identifiers.
239
D.5.4.2 Encoding of Contents Type
It is recommended that the Contents Type parameter be encoded as
document type. The encoding as constraint-set-and-abstract-
syntax has been provided only for backward compatibility with
FTAM and its use is discouraged.
D.5.4.3 Encoding of application specific information
The type of a file can be considered from several perspectives:
a) As a specific data structure consisting of a sequence of
presentation data values - the position taken by the FTAM
standard;
b) As the output of a certain application - the position
taken by e-mail users requiring the interchange of office
documents.
The fact that registered OSI document types have to be recognized
by FTAM implementations and be described according to the
requirements of ISO/IEC 9834-2 "Registration procedures for OSI
document types" makes use of the Contents Type parameter
inappropriate for expressing point of view (b).
Considering that the environment parameter "application-
reference" could describe not only the application that generated
a document but, more generally, the application-level format of
the document, it is recommended that the values given to the
"application-reference" parameter component be Object Identifiers
associated with such a format.
Example: If an Object Identifier has been associated with a
certain word-processing file format then this Object Identifier
should be used as the value of "application-reference" when a
file of that format is carried by a File Transfer body part,
while the Content Type parameter should have as its value the
Object Identifier associated with the "unstrucutred-binary"
document type.
D.5.4.4 EITs for the File Transfer body part
It is recommended to use only the id-eit-file-transfer Object
Identifier in association with the File Transfer body part.
The use of EITs describing other parameters of the File Transfer
240
body part such as contents types, application references, etc.
would force all potential recipients to register a possibly large
number of EITs in order to avoid non-delivery of messages.
D.5.5 Use of other extended body part types
The following are guidelines regarding the use of Externally
Defined body part types not defined in the X.400 or other
standards:
a) Use of Parameters component: In simple cases, to ease
the integration of applications to X.400 systems, the
Parameters component need not be used.
b) Use of Data component: For each different format of
data, different Object Identifiers for the Data component
are recommended. If an application chooses to use ASN.1 to
format the data to achieve a single representation across
platforms, the single-ASN1-type encoding choice should be
used. Otherwise:
1) The octet- (i.e., byte) aligned choice is used if
the data format is octet-aligned; or,
2) The arbitrary choice is used if the data is bit-
aligned.
c) Assignment of Object Identifiers: Object Identifiers
need to be assigned for the EXTERNALs, and these identifiers
for the Parameters and Data components should be different.
The Object Identifier for an EXTERNAL also indicates the
syntax of the data encoding, i.e., whether single-ASN1-type
or octet-aligned or bit-aligned is being used.
NOTE - Use of proprietary Externally Defined body part types
is recommended only if the extended body part types already
defined in the standards do not provide the apporpriate
functionality.
In order to communicate with 1984 systems, the use of the
Bilaterally Defined body part is recommended.
D.5.6 Obtaining object identifiers
There are many ways to obtain object identifiers. One such way is
described as follows:
a) The application provider obtains a unique Numeric Name
241
form for their organization from ANSI, as described in ANSI
ISSB 840 and ISSB 843, and appends this number form to {iso
(1) member-body (2) US (840)} to form an object identifier
denoting their organization.
b) The application provider (organization) allocates a
series of numbers to identify the application data format;
these numbers are appended to the object identifier
constructed in step (i) to form an object identifier that is
globally unique. It is recommended that the application
provider (organization) use a hierarchical structure for
identifying their data types to ease the administration of
the identifiers.
For example, company PCSoftware Inc. obtains the organization
number "999" from ANSI. The PCSoftware SpreadSheet file for MS-
DOS might be assigned the following object identifier.
NOTE - ASN.1 notation is used. The numbers in parentheses
form the identifier, the associated words describe the
number.
{ iso (1) member-body (2) US (840) PCSoftware Inc. (999) MS-
DOS-Application (1) SpreadSheet (3) Data (1) }
D.6 Privacy Enchanced Mail body part
This clause describes a mechanism to convey an Internet Privacy
Enhanced Mail (PEM) message across an X.400 MHS. PEM is described
in Internet RFCs 1113, 1114, and 1115 and their successors.
The general Internet mail message format is described in RFC 822.
Mapping of RFC 822 messages to and from X.400 Inter Personal
Messages is described in RFC 987 for 1984 X.400 and in RFC 1148
for 1988 X.400.
The PEM message is conveyed as a P2(2) body part. All of the RFC
822 header information is conveyed in the P1 envelope and P2
header per RFC 987 and RFC 1148. The PEM message (encapsulated
security header and, possibly encrypted, message text as
described in RFC 1113) is conveyed in a single body part. On the
X.400 side, this body part may be manipulated like any other body
part; e.g., it may be included in a multi-part body.
For 1988 (P22), the PEM body part is externally defined and does
not require parameters. This definition is provided in figure 23.
242
+----------------------------------------------------------------
------------+
|
|
| privacy-enhanced-mail EXTENDED-BODY-PART-TYPE
|
| DATA OCTET STRING
|
| ::= id-privacy-enhanced-mail
|
|
|
| -- The object identifier is defined in annex B.
|
|
|
+----------------------------------------------------------------
------------+
Figure 23 - Definition of the Privacy Enhanced Mail body part
type
For interworking with 1984 (P2) systems, a USA body part
(integer) will be allocated by NIST as described in figure 10.
D.7 Selection of OR name attributes
To support the transition to addresses with Teletex components,
it is recommended that a printable string alternative address be
established for each address containing Teletex strings.
D.8 Use of the Teletex body part
The Teletex body part should be used purely for structured
teletex documents, as described in F.200 and T.60, obeying page
rules, etc. It should not be used to transfer T.61 characters,
in a general sense, across the MTS. If only IA5 characters are
being used, the IA5Text body part should be used, especially when
interworking with 1984 UAs is relevant. Otherwise, the
GeneralText body part should be used to transfer unstructured
character data.
243
D.9 Provision of security class S0A using asymmetric
algorithms
This clause describes one method of providing the security
services of class S0A when using asymmetric (public key)
cryptographic algorithms. It is recommended that this method be
used unless the security requirements or policy specifies
otherwise. Asymmetric cryptographic algorithms such as RSA are
used to provide digital signatures in support of the content
integrity and (end-to-end) message origin authentication
services, as well as proof of delivery. Since asymmetric
algorithms are used, the non repudiation of origin and non
repudiation of delivery services of security class S2 are also
provided. Content confidentiality is provided using a combination
of symmetric and asymmetric encryption. The following paragraphs
discuss the protocol elements used to provide these services, as
well as certificate management and other issues.
D.9.1 Protocol elements
The following protocol elements are provided by the originating
UA in the submission envelope in support of the S0A security
services.
Content: If the content confidentiality services is required,
the message content is encrypted under the content
confidentiality key.
Content Integrity Check: This per-recipient security element is
a signature over the message content, and provides the content
integrity, message origin authentication, and non repudiation of
origin services if content confidentiality is not required. (If
the message is encrypted, the content integrity check is included
in the message token.)
NOTE - The message origin authentication check provides a
single signature, rather than a signature per recipient,
thus reducing total message size in the case where multiple
recipients are present. However, support for this protocol
element is optional for security class S0. In addition, it
is computed over the message content as sent (i.e., the
encrypted content if content confidentiality is used). If
the content is encrypted, this protocol element does not
truly provide non repudiation of the unencrypted content.
In this case, smaller message size was traded off for the
additional service of non repudiation.
Proof Of Delivery Request: This per-recipient security element
is used to request the recipient to generate a proof of delivery,
244
in the case where content confidentiality is not used. (Where
content confidentiality is used, the proof of delivery request is
included in the message token, as shown below.)
Originator Certificate: This security element is a set of one or
more certificates which the recipient may use to obtain the
originator's public key. For example, it might contain the chain
of certificates from the originator, through the certification
hierarchy to a top-level certification authority.
Message Token: The asymmetric message token conveys security
information from an originator to a single recipient. It is a
signed structure, some of whose fields may be encrypted. The
message token is used only when content confidentiality is
desired, and supports the content integrity, message origin
authentication, content confidentiality, and non repudiation of
origin services. The following fields are required, and all
other fields are optional:
- Signature Algorithm Identifier: The algorithm identifier
of the asymmetric algorithm used to sign the token.
- Recipient Name: The OR Address and/or Directory Name of
the recipient with whom the token is associated. Since the
encrypted portion of the token is encrypted under the
recipient's public key, it is recommended that the directory
name be included, since the recipient's certificate contains
his/her directory name rather than OR Address.
- Time: The time of day when the token was generated.
- Signed Data: The following fields are signed but not
encrypted:
a) Content Confidentiality Algorithm Identifier: The
algorithm to be used to encrypt the message content.
b) Proof of Delivery Request: This element is used to
request the recipient to compute a proof of delivery over
the received message.
- Encrypted Data: These fields are encrypted under the
recipient's public key:
c) Content Confidentiality Key: The symmetric key used to
encrypt the message content.
d) Content Integrity Check: A signature on the unencrypted
message content. If content confidentiality is required,
this element provides the content integrity, message origin
245
authentication, and non repudiation of origin services.
This signature is encrypted in order to protect against the
"low entropy" attack described in Internet RFC 1113. (In
RFC 1113, the signature is encrypted under the content
confidentiality key.)
NOTE - The encrypted portion of the token will then comprise
two RSA encryption blocks.
The following element of service is generated by the recipient,
if requested by the originator.
Proof Of Delivery: This security element provides proof and non
repudiation of delivery. It is a digital signature computed over
the received (possibly encrypted) message content and various
delivery envelope fields, as defined in the base standard.
D.9.2 Algorithm selection
This clause makes no recommendation as to hash algorithms,
asymmetric encryption algorithms, or symmetric encryption
algorithms. The implementor must select appropriate algorithms,
based on factors such as performance, cost, and licensing and
export restrictions. A fairly complete list of algorithms can be
found in clause 7 (Security Algorithms) of Part 12 of these
Agreements. In some cases, the implementor must also specify
certain algorithm-dependent information. For example, when using
the symmetric algorithm DES-CBC, the implementor must specify the
padding mechanism used, since this algorithm operates on 8-byte
input blocks. Internet RFC 1115 defines such padding rules for
DES and RSA in various modes, and these mechanisms are
recommended unless security requirements dictate otherwise. PKCS
#1 (see Bibliography, Annex F) discusses such matters in more
detail.
D.9.3 Certificate management
Management of public key certificates is beyond the scope of this
recommended practice. X.509 provides a generic authentication
framework which uses the Directory to store certificates. In the
absence of a ubiquitous Directory, local means may be used to
obtain certificates. For example, the recipient of a message
might choose to cache those certificates received in the
OriginatorCertificate protocol element of the delivery envelope.
Each community of interest will define its own policy regarding
certificate management and the associated trust model. An
246
example of a centralized trust model can be found in Internet RFC
1114, while the most complete example of a decentralized trust
model can be found in the paper on Digital's Distributed System
Security Architecture cited in the Bibliography (Annex F).
D.9.4 Other issues
In the case of the P2 content type, addressing information may be
protected by replicating the P1/P3 recipient names in the P2
heading fields (To:, CC:, and BCC:). The X.400 security services
discussed above are applied to the entire P2 IPM, including the
heading and all body parts. Additional protection of heading and
envelope fields may be provided using double enveloping.
When using X.400 (1988) distribution lists (DLs), one might
choose to distribute the private key associated with the DL to
all members of the DL. This allows an originator to create a
single message token in which the content confidentiality key is
encrypted under the DL's public key. (This requires support of
the DL expansion history protocol element on delivery, so that
the recipient may select the proper private key for decryption.
Alternatively, the originating UA may expand the DL locally and
generate a message token for each member (recursively). There is
no architected support for this mechanism in the base standard,
nor is there architected support for performance of this function
by an MTA when expanding a DL.
247
Annex E (informative)
Secure messaging guidelines
E.1 Introduction
The purpose of the security functional group is to define an
approach to the provision of secure messaging with Message
Handling systems within the general framework of these
Implementation Agreements.
E.2 Message handling vulnerabilities
The message handling vulnerabilities (threats) which can be
protected using security measures are defined in Annex D
(Security Threats) to Recommendation X.402 (1988):
a) Masquerading;
b) Message sequencing;
c) Modification of information;
d) Denial of service;
e) Repudiation;
f) Leakage of information.
Other specific threats exist if there is a failure to maintain
information separation, which includes:
a) Manipulation;
b) Misrouting.
Some of these threats are defined in ISO standard IS 7498, OSI
Reference Model, Part 2: Security Architecture. The ISO standard
also specifies other threats, not all of which are relevant to
message handling systems.
Annex D to CCITT Recommendation X.402 (1988) also indicates which
MHS security services may provide protection against such
threats.
Some threats to message handling systems cannot be easily
prevented, merely detected, others are not appropriated for
248
standardization.
E.3 General principles
E.3.1 Security policy
A general security policy can be defined as the set of laws,
rules, and practices that regulate how an organization manages,
protects, and distributes sensitive information. Thus a security
policy defines an organization's overall approach to security and
must cover all security aspects.
Security within an organization is not only the concern of
message handling service and must be viewed in a more global and
general sense. The wider aspects of a security policy would
therefore include personnel security (such as the vesting and
confidence placed in staff), end-user access control, physical,
procedural and documentation security. These Implementation
Agreements however are only concerned with Electronic Information
Security (EIS), specifically in the areas of communications
(COMSEC) and computer (COMPUSEC) as applicable to standardization
of a secure message handling system operating in a store and
forward environment.
E.3.2 Security classes
In the X.400 (1988) Recommendations, some threats are countered
by EIS measures, these measures are realized by providing
security services and implemented using security elements.
These Implementation Agreements groups together security features
of a message handling system defined by the base standards into
separate classes. A security class can be viewed as a tool which
can be used to implement a security policy, and is not a security
policy in its own right but a component of a security policy.
These Implementation Agreements includes a set of security
classes; each class stipulates a set of mandatory and optional
security services. The security classes are incremental subsets
of the security features in the MHS Base Specifications:
Security Class S0 only requires support of end-to-end
security services between UAs (content integrity, message
origin authentication, proof of delivery), and hence can be
used to provide some protection even in the case of transit
through an intermediary MTS which may not be trusted.
249
Security Class S1 additionally requires support and use of
secure access management within the MTS so as to allow the
enforcement of a label-based security policy and enable
trusted interworking between security domains.
Security Class S2 additionally requires support and use of
origin authentication checks within the MTS to verify the
origin of messages, probes, and reports, thereby making it
possible to provide non-repudiation within the MTS.
Mandatory security services within a security class can be
selected by the subscriber or user, either on a per-message
basis, or for an agreed contractual period of time. It is a local
issue to determine when a mandatory security service is offered
for user selection or when it is permanently invoked. Facilities
and mechanisms to support the mandatory security services must
always be provided within the security class, which specifies the
services as "mandatory."
E.3.3 Dynamic behavior requirements
The use of some security services is always required for certain
security classes. This is specified in these Implementation
Agreements by imposing additional dynamic requirements, to those
specified in the base standards, ensuring that the corresponding
protocol elements are always present.
Similarly, use of some security services are prohibited for
certain security classes. This is specified in these
Implementation Agreements by imposing additional dynamic
requirements to those specified in the base standards, ensuring
that the protocol elements are never present.
E.3.4 Encryption techniques
The secure messaging facilities defined in the base standards are
provided using three basic security techniques, namely:
a) Symmetric encryption;
b) Asymmetric encryption;
c) Trusted functionality (i.e., COMPUSEC measures).
The base standards permit the use of the techniques on an
individual basis to provided security services or they can be
combined in support of a security policy. These Implementation
Agreements combine the techniques in order to provide a
250
comprehensive set of security facilities, which are intended to
counter various combinations of the vulnerabilities of a
messaging service. In some cases the security services defined in
the base standards can only be implemented using one of the
techniques above, namely asymmetric encryption. However, the
actual technique employed shall be dependent on the algorithms,
which shall be registered by a security authority for the domain.
It is the intention of these Implementation Agreements that
implementations will not be restricted to asymmetric techniques.
All the mandatory security services can be implemented using
trusted functionality in combination with symmetric, asymmetric,
or both encryption techniques.
Although the base standards defines the syntax of an asymmetric
token, these Implementation Agreements takes into account the
ISO/CCITT MHS Implementors' Guide, which permits the use of both
asymmetric and symmetric techniques for both the signed and
encrypted data.
The actual technique employed depends on the algorithm used.
Algorithms are assumed to be bilaterally agreed or registered by
a registration authority. However, the algorithm-identifier must
be unique and unambiguously define the algorithm.
It is recommended that a conforming ASN.1 BIT STRING is normally
used to contain the encrypted data (as generated by use for the
ENCRYPTED macro), thereby ensuring insertion of padding zero bits
which may be necessary for correct operation of certain
algorithms. Alternatively, the implementation should take such
action explicitly.
It is recommended that, in the absence of any requirement for
support of other specific algorithms, implementations shall as a
default support algorithms identified in CCITT X.509 (ISO/IEC
9594-8). It is also strongly recommended that implementations are
capable of using any encryption-based technique on a "plug-in" or
modular basis.
In the case of verification of SIGNATUREs (e.g., proof of
delivery, MOAC, POAC, or ROAC), implementations should assume
that all relevant data present in the subject message, probe, or
report has been included in the signature.
251
E.3.5 Implementation considerations
E.3.5.1 Peer Entity authentication
Peer entity authentication is provided using the strong
authentication mechanisms on the various Bind operations, using
either asymmetric or symmetric techniques. The key management
information necessary for symmetric peer entity authentication is
outside the scope of these Implementation Agreements.
E.3.5.2 Confidentiality
Connection confidentiality is provided using the underlying OSI
layers and is outside the scope of these Implementation
Agreements. Mechanisms to support connection confidentiality are
subject to bilateral agreement between peers (i.e., connection
confidentiality may even be achieved by trusting the connection
to the peer OSI entity).
Content Confidentiality may be achieved by either symmetric or
asymmetric encryption techniques. It should be noted that use of
asymmetric techniques precludes submission of messages to
multiple recipients.
E.3.5.3 Integrity
Connection Integrity is provided using the underlying OSI layers
and is outside the scope of these Implementation Agreements.
Mechanisms to support Connection Integrity are subject to
bilateral agreement between peers. It should be noted that the
integrity of a connection can be increased by use of RTSE.
Content Integrity is achieved by computing a content integrity
check as a function of the entire message content. When symmetric
techniques are used to compute the content integrity check a
secret key is required. This content integrity key may be
confidentially sent to the message recipient using the message
argument confidentiality security element in the message token
(i.e., there may be other keys or parts of the key not sent by
the originator with the message, but the key management of such
external keys is outside the scope of these Implementation
Agreements). It should be noted that placing the content
integrity check in the encrypted data of the message token will
provide additional protection against masquerade threats.
NOTE - Content Integrity can also provide integrity of
receipt and non-receipt notifications (IPNs) and can assist
252
in the provision of "non-repudiation of receipt" since non-
repudiation of delivery may be insufficient where delivery
is to a Message Store.
E.3.5.4 Message origin authentication
End-to-end (i.e., UA to UA) Message Origin Authentication is
automatically provided by content integrity. Security classes S2
and S2a provide additional protection (i.e., of the integrity of
the label) by requiring support of origin authentication checks
within the MTS.
E.3.5.5 Non-Repudiation
If asymmetric techniques are used for content integrity it can
also provide non-repudiation of origin (UA to UA) depending on
the level of trust placed in the certificate. If symmetric
techniques are used, content integrity can also provide non-
repudiation of origin, but only by using a trusted notary to
validate the content integrity and provide trusted key management
facilities. A degree of non-repudication can be provided by the
use of trusted accountability services.
NOTE - It is assumed that an originating UA will ensure that
delivery notification is requested when proof of delivery is
requested.
E.3.5.6 Secure access management
Secure Access Management can be implemented by a combination of
Multi-Level Security (MLS) functionality by assurance of the
various MHS components to support such functionality. MLS
functionality is supported in the base standards by the use of
security labels, security context and the security token and can
be applied in a hierarchical and/or role manner depending on the
policy requirements of a domain.
MLS assurance will generally also require other (COMPUSEC)
measures and is outside the scope of the base standards and these
Implementation Agreements. Reference should be made to the
appropriate security authority and any applicable security
evaluation criteria (e.g., U. S. DoD Orange Book, UK -
Netherlands - Germany - France draft Evaluation Criteria).
253
E.3.5.7 Implications for the use of distribution lists
An MTA performing distribution list expansion must create all the
per-recipients fields for the members of the distribution list.
It may either generate a new token for each DL member (i.e.,
using the recipient name of that DL member) or alternatively it
may copy the same token (i.e., containing the recipient name of
the DL itself) into the per-recipient fields for each DL member.
In the former case, the content-integrity-check should not be
changed if it is to be used to provide message origin
authentication. Also in such case, the DL expansion point must
have at least the same security class as the originator and must
have trusted functionality. The choice of which approach to use
will therefore need to be determined in accordance with the
security policy which may prohibit the use of distribution lists
altogether.
E.3.5.8 Implications on redirection
The Security Functional Group has the effect of either requiring
trust in any redirection facilities or prohibiting the use of
redirection. If the Redirection facility is to be trusted, it
must be subject to the security policy and obey the security
labels as defined in the base standards. It is recommended that
the token is not altered on redirection (i.e., it will contain
the originally-specified recipient name).
E.3.5.9 Implications for 1984 interworking
Interworking between implementations conforming to Security
Functional Groups and 1984 systems is not supported. The Double
Enveloping technique can be used to traverse an 1984 system.
E.3.5.10 Implications for use of Directory
The X.400 security services use of the directory service does not
require a trusted directory because the information that is
retrieved is certified and can be validated independently of the
directory.
Other threats (e.g., malicious corruption of directory
information) may arise from the broader use of the directory,
however these are outside of the scope of the X.400 base standard
and this Implementors Agreement.
Work continues within CCITT and ISO to improve the security
inherent in the Directory standards.
254
E.3.5.11 Implications for conversion
Implementation of the Security functional group may additionally
either require that any conversion facilities are highly trusted
to regenerate the appropriate security elements (notably the
content integrity check) or prohibit the use of conversion within
the MTS altogether. In particular, it should be noted that use of
conversion facilities will invalidate any origin authentication
based on the original content.
E.3.5.12 Accountability
Accountability depends on the identification and authentication
of users, then subsequent records being kept on the actions taken
by users. Therefore, accountability depends on all the relevant
information being properly stored or recorded.
Accountability features provided by domains (or MTAs) are subject
to bilateral agreement between domains (or MTAs) and may
optionally provide non-repudiation services. Accountability
features include pervasive mechanisms such as security logs,
audit trails and archives, or they may be mechanisms supported by
protocol. Protocols to support accountability will be subject to
bilateral agreement.
E.3.5.13 Double enveloping
Double enveloping can be used with each secure messaging security
class. For each security class it is an optional extension to the
security features which can be used to counter specific
vulnerabilities. When double enveloping is used, it shall be
applied at the boundary of a domain, and obey the rules of an MTA
at management domain boundaries. Figure 24 illustrates the
technique.
255
+-------------------------------------------------+
| |
| +-----------------------------------------+ |
| | Outer Envelope 2 | |
| | +---------------------------------+ | |
| | | Content 2 | | |
| | | +-------------------------+ | | |
| | | | Inner Envelope 1 | | | |
| | | | +-----------------+ | | | |
| | | | | Content 1 | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | +-----------------+ | | | |
| | | +-------------------------+ | | |
| | +---------------------------------+ | |
| +-----------------------------------------+ |
+-------------------------------------------------+
Figure 24 - Double enveloping technique
Address information in envelope 1 and 2 are not necessarily the
same.
Trace information in envelope 1 and 2 are not necessarily the
same.
The double envelope technique can be used in 1984 and 1988 MTS
environments. When used in an 1988 environment, any security
class can be applied to the outer envelope. It is recommended
that the inner envelope is encrypted. When the double envelope
technique is used as a secure relay path via an 1984 domain, any
encryption of the content 2 is subject to bilateral agreement.
Trace information is not passed between inner and outer
envelopes. It is recommended that trace information on the outer
envelope is always archived when the double envelope technique is
used.
E.4 Security class S0
E.4.1 Rationale
Security class S0 is confined to security functionality operating
between MTS-Users on an end-to-end basis. It is designed to
minimize the required functionality in the MTS to support
submission of elements associated with these services. Security
services which must be supported (i.e., must be made available)
are those which are considered in any secure messaging
256
environment, i.e.:
a) Content Integrity;
b) Message Origin Authentication (end-to-end);
c) Proof of Delivery.
Other security services, such as Content Confidentiality, may
optionally be supported.
E.4.2 Technical implications
The technical implications for security class S0 are:
a) It is necessary to provide mechanisms in a UA which can
generate the signed, signature and encrypted macros on
message submission; and,
b) It is necessary to provide mechanisms in a UA which can
handle the signed, signature and encrypted macros on message
delivery.
E.5 Security class S1
E.5.1 Rationale
The S1 security class is a superset of security class S0 and
introduces the basic requirement for security functionality not
only within the MTS-User but also within the MTS. This security
functionality within the MTS is designed to support the
enforcement of a security policy within a security domain. As a
consequence, S1 enables trusted routing to be implemented.
NOTE - The level of trust in the route will depend on the
level of trust in the security label and security context.
E.5.2 Technical implications
The technical implications of security class S1 are:
a) It is necessary to provide mechanisms in a UA which can
generate the signed, signature and encrypted macros on
message submission;
b) It is necessary to provide mechanisms in a UA which can
257
handle the signed, signature and encrypted macros on message
delivery;
c) It is necessary to provide mechanisms in the MTA for
registration, change-credentials and bind abstract
operations (i.e., signed macro for bind);
d) It is necessary to provide mechanisms in the MS for MS-
registration and MS-bind operation (i.e., signed macro for
MS-Bind);
e) It is necessary to support message security labelling
(the level of assurance is subject to individual security
domain requirements);
f) It is necessary that reliable access is always
supported;
g) It is necessary for the MTAs to check the existence of
the security elements which are classified as "dynamic
mandatory";
h) It is necessary to provide a trusted connection between
peers to provide adequate confidentiality, integrity and
peer entity authentication.
E.6 Security class S2
E.6.1 Rationale
Security Class S2 is a superset of Security Class S1. It enhances
the facilities of the MTAs in order to check the origination of
messages, probes, and reports within the MTS and to provide
enhanced integrity checks on the security label while in the MTS.
The extra security services provided by this security class can
help to provide trusted routing within an MTS.
Additionally, it is possible to provide non-repudiation within an
MTS.
E.6.2 Technical implications
The extra security services specified by Security Class S2 use
asymmetric techniques exclusively.
The technical implications are as in Security Class S1, plus:
258
a) It is necessary to provide mechanisms in an MTA and UA
that can process the signed macro of certificates;
b) The constraint that the option of supporting Content
Confidentiality cannot be allowed when the message origin
authentication check (MOAC) is used to provide non-
repudiation services. Under this condition Content
Confidentiality is not supported. If the MOAC is not used
for this purpose, Content Confidentiality can be supported
as an optional security service;
c) It is necessary to provide mechanisms in a MTA which can
generate and process the signature macro of a message,
probe, and report authentication check (MOAC, POAC and
ROAC);
d) It is necessary to provide mechanisms in a UA and MTA
that can interface with an X.500 directory supporting the
Authentication Framework as defined in X.509/ISO 9594-8 or
can distrubute public keys by other trusted means which is
compliant with X.509;
e) It is necessary to provide a trusted means of generating
certificates;
f) It is necessary to provide mechanisms in the MTA which
can process a proof of submission request and generate the
proof of submission signature;
g) It is necessary to provide a mechanism in an MTA which
will generate ROAC signatures with reports;
h) Connection confidentiality is only provided by this
security class when the message-origin-authentication-check
is computed using clear content to provide non-repudiation
of origin security service (i.e., non-repudiation is
provided only on the clear content of the message);
i) The irrevocable proof required to provide non-
repudiation within the MTS is achieved by the management of
asymmetric keys. The explicit definition of asymmetric key
management is outside the scope of these Implementors
Agreements.
259
E.7 Confidential security class variants (S0a, S1a, and S2a)
E.7.1 Rationale
These security class variants are supersets of S0, S1, and S2,
adding the requirement for support of end-to-end content
confidentiality. The rationale for these variants is to avoid the
implementation cost and processing overhead involved in
encrypting the entire message content unless there is a definite
requirement. It is also possible to protect the encryption
techniques and mechanisms (i.e., algorithms, key lengths, key
versions, etc.) by Secure Access Management.
E.7.2 Technical implications
The technical implications of the confidential security class
variants are the same as those for the corresponding primary
security class, plus:
a) It is necessary to provide mechanisms in a UA which can
use the encrypted macros to encrypt and decrypt the message
content.
260
Annex F (informative)
Bibliography
F.1 ANSI
Procedures for Registering Organization Names in the United
States of America, ISSB 843, December 5, 1989.
Procedures for Registering Names in the United States of America,
ISSB 840, December 5, 1989. The U. S. Register is included.
F.2 Internet
Message Encipherment and Authentication Procedures, RFC 1113.
Certificate-based Key Management, RFC 1114.
Algorithms, Modes, and Identifiers, RFC 1115.
261
Annex G (informative)
Defense message handling profiles
G.1 Introduction
Several additional requirements for Message Handling Systems
(MHS) in the U.S. Department of Defense (DoD) are currently being
investigated by the Data Communications Protocol Standards (DCPS)
Technical Management Panel (DTMP). This annex describes the DoD
Standardized Profile(s) (DSP) that are required for Defense
Message System (DMS) use.
Two multipart DoD profiles are currently defined, namely:
- DSP AMH1n(D) - Information Technology - Defense
Standardized Profiles AMH1n(D) - Message Handling Systems -
Common DoD Messaging
- DSP AMH2n(D) - Information Technology - Defense
Standardized Profiles AMH1n(D) - Message Handling Systems -
Military Messaging
These profiles will be published as part of the MIL-STD-2045
series. The AMH1n(D) profile consists of a DoD delta to the
AMH1n ISP. AMH2n(D) is a standalone profile of a new military
messaging content type (P772) based on the IPM content type.
These extensions support military-unique functionality required
by the DMS.
For further information on these profiles, contact:
DTMP WG/2 Chairman
c/o Defense Information Systems Agency (DISA)
Joint Interoperability Engineering Office (JIEO)
Code TBBD
Fort Monmouth, NJ 07703-5000
Phone: 908-532-7726
262
Annex H (informative)
Differences between OIW Agreements and EWOS/ETSI Draft Profile
A/3312
H.1 P7
The "and," "or," and "not" elements of Filter are optional in
A/3312.
The "equal," "greater-or-equal," "less-or-equal," and "present"
elements of FilterItem are optional in A/3312; however, at least
one must be implemented.
The List and Summarize operations are optional for the UA Kernel
in A/3312.
The "precise" element in the Fetch operation is optional for the
UA Kernel in A/3312.
263
264
Index
Abstract Services nSubfield 111
Abandon 21 DeleteArgument 87
Add Entry 21 DeleteResult 87
Bind 21 DLExpansion 66
Compare 21 DLExpansionHistory 62,
List 21 64, 66
Modify Entry 21 DomainDefinedAttribute
Modify RDN 21 68, 82, 83
Read 21 DomainName 66-69
Remove Entry 21 EDIApplicationSecurityElem
Search 21 entsField 110
Unbind 21 EDIM 109
Application Contexts EDIM-ExternallyDefinedBody
ms-access 14 Part 112
ms-reliable-access 14 EDIMBodyPart 111
mts-access 14, 16 EDIMIdentifier 109
mts-forced-access 14, 16 EDIN 112
mts-forced-reliable-access EDINotificationRequestsFie
14, 16 lds 110
mts-reliable-access 14, EDINReceiverField 110
16 EncodedInformationTypes
mts-transfer 9 61, 63-66, 84
mts-transfer-protocol 9 EntryInformation 89
mts-transfer-protocol-1984 ExtensionAttribute 68
9 ExtensionField 62, 64-66,
ASN.1 Types 109
AdditionalBodyParts 112 FetchArgument 87
AlertArgument 88 FetchResult 87
AlertResult 88 Filter 89
AttributeSelection 89 FilterItem 89
AttributeValueAssertion FNPDAUReasonCodeField 114
89 FNReasonCodeField 113
AuthorizationInformationFi FNUAMSReasonCodeField 113
eld 111 FNUserReasonCodeField 114
Auto 88 ForwardNotificationFields
AutoAlertRegistrationParam 113
eter 88 GeneralTextBodyPart 72
AutoForwardRegistrationPar GlobalDomainIdentifier
ameter 88 65-68, 84
Body 111 Heading 109
BodyOrRemoved 112 HeadingExtension 71
BodyPart 71 InformationBase 89
Certificate 94, 101 InformationObject 70, 109
Common 65 InterchangeRecipientField
CommonFields 112 110
CountryName 67-69 InterchangeSenderField
CrossReferencingInformatio 111
265
InternalTraceInfo 62, 64 PrimaryBodyPart 111
InternalTraceInformation PrimaryOrRemoved 112
67 ProbeSubmissionEnvelope
InternalTraceInformationEl 79, 100
ement 67 ProbeTransferEnvelope 61,
IPM 70 63, 93
IPMIdentifier 71 Range 90
IPN 70 RecipientReferenceField
ListArgument 86 110
ListResult 86 RecipientSpecifier 71
MessageData 112 RecipientSubfield 110
MessageDeliveryEnvelope Redirection 67, 84
79, 96, 98, 101, 102 RedirectionHistory 65,
MessageParameters 111 67, 84
MessageSubmissionEnvelope Register-MSArgument 87,
77, 95, 98, 100, 102 103
MessageTransferEnvelope Register-MSResult 87
61, 91, 93 RelatedMessageField 110
MS-configuration-request RelatedMessageReference
85 110
MSBindArgument 85 ReportDeliveryEnvelope
MTA 74 81, 96, 99, 101
MTS-user 74 ReportTransferContent 61,
MTSIdentifier 61, 63-65, 64
84 ReportTransferEnvelope
NegativeNotificationFields 61, 64, 92, 93
113 SecurityElementField 112
NNPDAUReasonCodeField 113 Selector 90
NNReasonCodeField 113 ServiceStringAdviceField
NNUAMSReasonCodeField 113 111
NNUserReasonCodeField 113 SummarizeArgument 86
ORAddressAndOptionalDirect SummarizeResult 86
oryName 66, 67, 84 SyntaxIdentifierField 111
ORDescriptor 71 TraceInformation 62, 64,
OrganizationUnitName 68, 66
82, 83 TraceInformationElement
OriginatorAndDLExpansionHi 66
story 64, 67, 84 ASN.1 Values
ORName 61-67, 81, 82, 84 absent 86
Parameters 88 acknowledgement-request
PerDomainBilateralInfo 110
62, 63, 66 acknowledgment-mode 71
PerRecipientMessageSubmiss action-request 110
ionFields 78, 95 actual-recipient-name 65,
PerRecipientProbeSubmissio 81, 93
nFields 79 additional-body-parts
PerRecipientReportDelivery 111, 112
Fields 81, 96, 101 additional-information 65
PositiveNotificationFields address 67, 88
113 address-for-reverse-routin
266
g 111 body-part-reference 111,
administration-domain-name 112
66-68 built-in 61, 63, 65, 77,
alert-addresses 88 79, 81
alert-indication 86 built-in-encoded-informati
alert-qualifier 88 on-types 65, 84
alert-registration-identif certificate 91, 93, 97,
ier 88 98, 100, 101, 103, 115
algorithm 94, 101 certification-path 93,
algorithm-identifier 93, 100, 101, 115
100, 101 change-credentials 87
allowed-content-types 85 changeCredentials 103
allowed-EITs 85 child-entries 90
alternate-recipient-allowe common-fields 70
d 62, 63, 78, 79 common-name 68
and 89 communications-agreement-i
any 89 d 110
application-cross-referenc component-data-element-sep
e 111 arator 111
application-reference 109 content 61, 75, 76, 93,
approximate-match 89 100, 101
arrival-time 65-67 content-confidentiality-al
asymmetric-token 63, 92, gorithm-identifier 62,
95, 96, 99, 102 63, 78, 80, 95, 96, 102
attempted 67 content-confidentiality-ke
attempted-domain 66 y 63, 95, 96, 102
attributes 89 content-correlator 62,
authorization-information 64, 65, 78, 79, 81
110, 111 content-identifier 62,
authorization-information- 63, 65, 75, 77, 79-81,
qualifier 111 88, 93, 100, 101
authorizing-users 70 content-integrity-check
auto-action-deregistration 63, 78, 80, 95, 96, 98
s 87 content-integrity-key 63,
auto-action-registrations 92, 95, 96, 99
87 content-length 63, 79
auto-forward-arguments 88 content-return-request
auto-forward-comment 70 62, 63, 78
auto-forwarded 70 content-type 61, 63, 65,
auto-forwarding-comment 77, 79, 81
88 content-types-supported
available-attribute-types 86
86 controls 75, 76, 97
available-auto-actions 86 conversion-eits 70
bilateral-information 66 conversion-with-loss-prohi
bilaterally-defined 72 bited 62, 64, 78-80
bind-token 91, 92, 97-99, converted-encoded-informat
103 ion-types 65, 66, 80,
blind-copy-recipients 70 81
body 70, 109, 112 copy-recipients 70
267
count 86, 89 xtensions 110
country-name 66-68 edi-body-part 111
cover-note 88 edi-bodypart-type 109
creation-time-range 90 edi-encrypted-primary-body
criticality 66, 109 part 110
cross-referencing-informat edi-message-reference 110
ion 109 edi-message-type 109
data 71, 72 edi-notification-requests
data-element-separator 110
111 edi-notification-requests-
date-and-time-of-preparati field 110
on 109 edi-notification-security
decimal-notation 111 110
default-delivery-controls edi-reception-security
76 110
deferred-delivery-time edim 109
62, 78, 88 edin 109
deferred-time 66, 67 edin-initiator 112
delete-after-auto-forwardi edin-originator 112
ng 88 edin-receiver 109
deliverable-content-types edin-receiver-name 110
77 encrypted 71
deliverable-encoded-inform encrypted-data 63, 92,
ation-types 76 95, 96, 98, 99, 102
deliverable-maximum-conten encryption-algorithm-ident
t-length 76 ifier 63, 92, 95, 96,
delivery 65, 81, 93 99
delivery-envelope 72, 111 entry-information 87
delivery-flags 80 envelope 61, 75, 76
delivery-time 72, 111 equality 89
directory-name 68 expiry-time 70, 109
discard-reason 70 explicit-conversion 62,
disclosure-of-recipients 64, 78, 79, 88
62, 63, 77 extended-network-address
dl-expansion-history 62, 68
64, 80 extension 93
dl-expansion-prohibited extension-attribute-type
62, 64, 78, 79 68
dl-expansion-time 66 extension-attribute-value
dl-operation 66, 67 68
domain 67 extension-attributes 68,
domain-defined-attributes 83, 115
68 extension-OR-address-compo
domain-supplied-informatio nents 68
n 66 extension-physical-deliver
edi-application-security-e y-address-components
lement 110 68
edi-application-security-e extensions 62, 64, 65,
lements 109, 112 70, 75, 78-81, 88,
edi-application-security-e 91-93, 95, 96, 98-102,
268
115 highest 86
external 61, 63, 65, 77, ia5-text 71
79, 81 identification-code-qualif
external-body-part 112 ier 110, 111
external-encoded-informati implicit-conversion-prohib
on-types 65, 84 ited 62, 63, 78-80
external-message-reference importance 70
110 incomplete-copy 70, 109
externally-defined 72 information-base-type 86,
fetch-attribute-defaults 87
87 initial 89
fetch-restrictions 85 initials 67
filter 88, 90 initiator-credentials 61,
final 89 74, 85, 91, 97, 103
first-recipient 110, 112 initiator-name 61, 74, 85
fn-common-fields 113 inlog 89
fn-extensions 113 intended-recipient-name
fn-pdau-basic-code 114 67, 84
fn-pdau-diagnostic 114 interchange-control-refere
fn-pdau-reason-code 113 nce 110
fn-reason-code 113 interchange-recipient 110
fn-security-check 113 interchange-sender 109
fn-supplementary-informati internal-trace-information
on 113 62, 64
fn-ua-ms-basic-code 113 ipm 70
fn-ua-ms-diagnostic 113 ipm-preferred-recipient
fn-ua-ms-reason-code 113 70
fn-user-basic-code 114 ipn 70
fn-user-diagnostic 114 ipn-originator 70
fn-user-reason-code 113 isMessageStore 74
for-delivery 66 iso-3166-alpha2-code 69
for-submission 66 issuer 94, 101
for-transfer 66 item 87, 89
formal-name 71 items 87
forwarded-EDIM 111 labels-and-redirections
forwarded-notification 77, 97
112 languages 70
forwarded-to 113 last-trace-information 65
forwarding-request 78 latest-delivery-time 62,
free-form-name 71 78
from 89, 90 less-or-equal 89
g3-facsimile 71 limit 90
g4-class 71 list 87
generation-qualifier 67 list-attribute-defaults
given-name 67 87
global-domain-identifier local-identifier 65, 84
65-67, 84 local-postal-attributes
greater-or-equal 89 68
heading 70, 109, 112 lowest 86
heading-extensions 109 maximum-content-length 85
269
message 61, 72 nn-user-reason-code 113
message-data 111 non-basic-parameters 65,
message-delivery-identifie 71, 84
r 79 non-delivery 65, 81, 93
message-delivery-time 65, non-delivery-diagnostic-co
79, 81, 93 de 65, 81, 93
message-identifier 61 non-delivery-reason-code
message-origin-authenticat 65, 81, 93
ion-check 62, 78, 80, non-receipt-fields 70
93, 100, 101 non-receipt-reason 70
message-reference 111 not 89
message-security-label notAfter 94, 101
62-64, 78-81, 91-93, notBefore 94, 101
95, 96, 98-101, 103 notification-requests 71
message-sequence-number notification-security-elem
63, 95, 96 ents 112
message-submission-identif notification-time 112
ier 75 notifications-extensions
message-submission-time 112
75, 80 number-of-pages 71
message-token 63, 78, 80, numeric 69
92, 95, 96, 98, 102 numeric-user-identifier
messages-waiting 74 67
mixed-mode 72 obsoleted-EDIMs 109
mta 67, 74 obsoleted-IPMs 70
mta-name 67 old-credentials 77, 87,
mta-supplied-information 98, 103
67 or 89
mTS-user 74 organization-name 67
name 63, 92, 95, 96, 99 organizational-unit-names
nationally-defined 72 67
negative-notification 112 original-content 112
network-address 67 original-content-integrity
new-credentials 77, 87, -check 112
98, 103 original-edim-identifier
new-entry 88 110
next 86, 87 original-encoded-informati
nn-common-fields 113 on-types 61, 63, 64,
nn-extensions 113 77, 79-81
nn-pdau-basic-code 113 originally-intended-recipi
nn-pdau-diagnostic 113 ent-name 65, 80, 81,
nn-pdau-reason-code 113 93
nn-reason-code 113 originally-specified-recip
nn-supplementary-informati ient-number 62, 64, 65
on 113 originating-MTA-certificat
nn-ua-ms-basic-code 113 e 75, 100
nn-ua-ms-diagnostic 113 origination-or-expansion-t
nn-ua-ms-reason-code 113 ime 67, 84
nn-user-basic-code 113 originator 70, 109
nn-user-diagnostic 113 originator-and-DL-expansio
270
n-history 64, 81 name 68, 115
originator-certificate physical-delivery-modes
62, 64, 78-80, 93, 100, 62, 78
101 physical-delivery-office-n
originator-name 61, 63, ame 68
77, 79, 88 physical-delivery-office-n
originator-or-dl-name 67, umber 68
84 physical-delivery-organiza
originator-report-request tion-name 68
78, 79, 88 physical-delivery-personal
originator-requested-alter -name 68
nate-recipient 62, 64, physical-delivery-report-r
78, 79 equest 63, 78
originator-return-address physical-forwarding-addres
62, 78, 115 s 65, 81
ORName 115 physical-forwarding-addres
other-actions 66, 67 s-request 62, 78
other-fields 79, 96 physical-forwarding-prohib
other-parameters 88, 112 ited 62, 78, 115
other-recipient-names 80 physical-rendition-attribu
outlog 89 tes 63, 64, 78, 79
override 90 place-holder 112
parameters 71, 72, 94, pn-common-fields 113
101, 111 pn-extensions 113
pds-name 68 pn-supplementary-informati
per-domain-bilateral-infor on 113
mation 62, 63 positive-notification 112
per-message-indicators post-office-box-address
62, 63, 77, 79, 88 68
per-recipient 93 postal-code 68, 115
per-recipient-fields 62, poste-restante-address 68
64, 65, 88, 92 precise 87
per-recipient-indicators present 86, 89
62, 64, 65 primary-body-part 111,
permissible-content-types 112
76, 77 primary-or-removed 112
permissible-encoded-inform primary-recipients 70
ation-types 76, 77 printable 69
permissible-lowest-priorit priority 62, 77, 80, 88
y 75-77 privacy 103
permissible-maximum-conten privacy-mark 62
t-length 75-77 private-domain-identifier
permissible-operations 66, 68
75-77 private-domain-name 67
permissible-security-conte probe 61
xt 75, 76, 97 probe-identifier 63
PerRecipientMessageSubmiss probe-origin-authenticatio
ionFields 115 n-check 64, 79, 93,
personal-name 67 100
physical-delivery-country- probe-submission-identifie
271
r 75 replied-to-IPM 70
probe-submission-time 75 reply-recipients 70
processing-priority-code reply-requested 71
110 reply-time 70
proof-of-delivery 65, 76, report 61, 65, 81
81, 93, 95, 96 report-destination-name
proof-of-delivery-request 64
63, 78, 80, 95, 96 report-identifier 64
proof-of-submission 75, report-origin-authenticati
100 on-check 64, 81, 93,
proof-of-submission-reques 101
t 78, 100 reporting-DL-name 64, 81
range 90 reporting-MTA-certificate
receipt-fields 70 64, 81, 93, 101
receipt-time 70 requested 86
recipient 71, 110 requested-attributes
recipient-assigned-alterna 86-88
te-recipient 77 requested-delivery-method
recipient-certificate 65, 62, 64, 78-80
76, 81, 93, 100, 101, rerouted 66, 67
115 reserved 111
recipient-extensions 110 responder-credentials 61,
recipient-identification 74, 86, 91, 97, 103
110 responder-name 61, 74
recipient-name 62, 64, responsibility-forwarded
78, 79, 88 109
recipient-number-for-advic responsibility-passing-all
e 63, 78 owed 110
recipient-reassignment-pro restrict 75, 76
hibited 62, 64, 78, 79 returned-content 65, 76
recipient-reference 110 returned-ipm 70
recipient-reference-qualif routing-action 66, 67
ier 110 routing-address 110
recipients 109 search 87
redirected 66, 67 security-categories 62,
redirection-history 103
63-65, 80, 81 security-classification
redirection-reason 67, 84 62, 103
redirection-time 67, 84 security-context 61, 74,
registered-mail-type 63, 85, 91, 97, 103
78 security-extensions 112
registration-identifier security-policy-identifier
87 62, 92, 98, 103
registration-parameter 87 segment-terminator 111
related-IPMs 70 selector 86, 87
related-messages 109 sender-identification 111
relayed 66, 67 sensitivity 70
release-indicator 111 sequence-number 89
removed-edi-body 112 sequence-number-range 90
repertoire 71 sequence-numbers 87
272
serialNumber 94, 101 teletex-personal-name 68
service-string-advice 109 telex-compatible 71
sign-data 63 terminal-identifier 67
signature 94, 101 terminal-type 68
signature-algorithm-identi test-indicator 110
fier 63, 92, 95, 96, this-EDIM 109
99 this-IPM 70
signed-data 92, 95, 96, this-ipm-prefix 88
98, 99, 102 this-recipient-name 80
simple 61, 74, 77, 85, time 63, 92, 95, 96, 99
86, 91, 97, 98, 103 to 90
span 86 trace-information 62, 64
standard-attributes 67, type 66, 68, 71, 82, 83,
81, 82 86, 87, 89, 109
stored-messages 89 type-of-MTS-user 65, 81,
street-address 68 93
strings 89 unformatted-postal-address
strong 61, 74, 77, 85, 68
86, 91, 97, 98, 103 unformatted-postal-code
subject 70, 94, 101 115
subject-edim 112 unique-postal-name 68
subject-identifier 64 user 71, 109
subject-intermediate-trace user-address 76
-information 64 user-name 76, 97
subject-ipm 70 user-relative-identifier
subject-submission-identif 71, 109
ier 81 user-security-label 77,
subjectPublicKey 94, 101 97
subjectPublicKeyInfo 94, user-security-labels 87,
101 103
substrings 89 validity 94, 101
summaries 86 value 66, 68, 71, 82, 83,
summary-requests 86 86, 89, 109
suppl-receipt-info 71 values 89
supplementary-information version 94, 101
65, 81 videotex 71
surname 67 voice 71
syntax 71 waiting 75, 76
syntax-identifier 109, waiting-content-types 75,
111 76
syntax-version 111 waiting-encoded-informatio
telephone-number 71 n-types 75, 76
teletex 71 waiting-messages 75, 76
teletex-common-name 68 waiting-operations 75, 76
teletex-domain-defined-att x121-dcc-code 69
ributes 68 Attributes
teletex-organization-name acknowledgment-mode 108
68 authorizing-users 107
teletex-organizational-uni auto-forward-comment 108
t-names 68 auto-forwarded 107
273
bilaterally-defined-body-p ipm-entry-type 107
arts 107 ipm-preferred-recipient
blind-copy-recipients 107 108
body 107 ipm-synopsis 107
child-sequence-numbers ipn-originator 108
104 languages 107
commonName 22 message-body-parts 108
content 104 message-data 108
content-confidentiality-al message-delivery-envelope
gorithm-identifier 104
104, 106 message-delivery-identifie
content-correlator 104 r 104
content-identifier 104 message-delivery-time 104
content-integrity-check message-origin-authenticat
104, 106 ion-check 104, 106
content-length 104 message-parameters 108
content-returned 104 message-security-label
content-type 104 104, 106
conversion-eits 108 message-submission-time
conversion-with-loss-prohi 104
bited 104 message-token 104, 106
converted-eits 104 mhs-deliverable-content-le
copy-recipients 107 ngth 21
creation-time 104 mhs-deliverable-content-ty
delivered-eits 104 pes 21
delivery-flags 104 mhs-deliverable-eits 21
discard-reason 108 mhs-dl-members 21
dl-expansion-history 104 mhs-dl-submit-permissions
encrypted-body-parts 107 21
encrypted-data 107 mhs-message-store 21
encrypted-parameters 107 mhs-or-addresses 21
entry-status 104 mhs-preferred-delivery-met
entry-type 104 hods 21
expiry-time 107 mhs-supported-automatic-ac
extended-body-part-types tions 21
107 mhs-supported-content-type
g3-facsimile-body-parts s 21
108 mhs-supported-optional-att
g3-facsimile-data 108 ributes 21
g3-facsimile-parameters mixed-mode-body-parts 108
108 nationally-defined-body-pa
g4-class1-body-parts 108 rts 108
heading 107 non-receipt-reason 108
ia5-text-body-parts 108 nrn-requestors 107
ia5-text-data 108 obsoleted-ipms 107
ia5-text-parameters 108 original-eits 104
importance 107 origination-certificate
incomplete-copy 107 106
intended-recipient-name originator 107
104 originator-certificate
274
104 Mandatory 6, 7
originator-name 104 Not Applicable 6
other-recipient-names 104 Optional 6
parent-sequence-number Out of Scope 6
104 To Be Determined 6
per-recipient-report-deliv Cross References
ery-fields 104 Access Units 6
primary-recipients 107 Access Units, Other 3
priority 104 Attributes, General MS
proof-of-delivery 106 Security 13
proof-of-delivery-request Attributes, MS General
104 13, 40, 53
receipt-time 108 Attributes, MS General,
redirection-history 104 Security 106
related-ipms 107 Attributes, MS IPM 40
replied-to-ipm 107 Classification Scheme 12,
reply-recipients 107 15, 17, 20, 26, 33, 36,
reply-requestors 107 43
reply-time 107 Conformance 3
report-delivery-envelope Conversion 6
104 Directory, Use of 3, 5
report-origin-authenticati Distribution Lists 3, 5,
on-check 105, 106 8
reporting-dl-name 104 EDIMS 3
reporting-mta-certificate Interworking, 1988/84 6
104, 106 IPM Kernel 3, 15
returned-ipm 108 Management 3
rn-requestors 107 Message Store 3, 5, 15
security-classification MS Conformance Levels 52
105, 106 MS: General Attributes
sensitivity 107 Security 13, 53
sequence-number 105 MT Kernel 3, 15, 17
subject 107 MT Kernel Conformance
subject-ipm 108 Levels 52, 69
subject-submission-identif MTS Transfer Protocol 50
ier 105 P1 Classification 9
suppl-receipt-info 108 P2 Classification 38
teletex-data 108 P3 Classification 14, 15,
teletex-parameters 108 35
this-ipm 107 P7 Classification 13, 35
this-recipient-name 105 Part 11, Directory
videotex-body-parts 108 Services 18, 21
videotex-data 108 Part 5, Upper Layers 50
videotex-parameters 108 Part 7, 1984 X.400 Based
voice-body-parts 108 MHS 1
voice-data 108 Part 7, Loop Suppression
voice-parameters 108 within a PRMD 10
Base standards 1 Part 7, Protocol Elements
Classification (EoS) Supported for EDI 122,
Excluded 7 123, 124
275
Part 7, Recommended Conversion Prohibition in
Practices 121 Case of Loss of
Part 7, Routing within a Information 37, 41
PRMD 10 Conversion Prohibition in
PDAU 3 Case of Loss of
Pedi Classification 47 Information (1988) 8
Redirection 3 Converted Indication 7,
Remote User Agent 3, 5, 36, 44
12 Counter Collection 34, 42
Scope 51 Counter Collection with
Security 3, 5, 23, 42 Advice 34, 42
Underlying Layers, Use of Cross Reference
9, 14, 16 Information 45
Elements of Service Cross Referencing
Access Management 7, 15, Indication 37
36, 44 Deferred Delivery 8, 37,
Additional Physical 45
Rendition 34, 42 Deferred Delivery
Alternate Recipient Cancellation 8, 37, 45
Allowed 8, 37 Delivery Notification 8,
Alternate Recipient 37, 45
Assignment 8, 37, 45 Delivery Time Stamp
Application Security Indication 7, 36, 44
Element 45 Delivery via Bureaufax
Authorizing Users Service 34, 42
Indication 37 Designation of Recipient
Auto-forwarded Indication by Directory Name 20,
37 45
Basic Physical Rendition Disclosure of Other
34, 42 Recipients 8, 37, 45
Blind Copy Recipient DL Expansion History
Indication 37 Indication 8, 17, 37,
Body Part Encryption 45
Indication 37 DL Expansion Prohibited
Change Credentials 28, 31 8, 17, 37
Character Set 45, 46 EDI Forwarding 45
Connection Confidentiality EDI Message Type 45
28 EDI Notification Request
Connection Integrity 28 45
Content Confidentiality EDI Standard Indication
28, 29, 32, 33, 45 45
Content Integrity 28, 31, EDIM Responsibility
45 Forwarding Allowed 45
Content Type Indication EDIN Receiver 45
7, 36, 44 EMS (Express Mail Service)
Conversion Prohibition 8, 34, 42
37, 45 Expiry Data Indication 37
Conversion Prohibition in Expiry Date/Time
Case of Information Indication 45
Loss 45 Explicit Conversion 8,
276
37, 41, 45 Non-repudiation of EDI
Forwarded IP-message Notification Request
Indication 37 45
Grade of Delivery Non-Repudiation of Origin
Selection 8, 37, 45 28, 32, 46
Hold for Delivery 8, 15, Non-Repudiation of
37, 45 Submission 28, 32, 46
Implicit Conversion 8, Obsoleting Indication 37,
37, 41, 45 46
Importance Indication 37 Ordinary Mail 34, 42
Incomplete Copy Indication Original Encoded
37, 45 Information Types
Interchange Header 45 Indication 7, 36, 44
IP-message Identification Originator Indication 37,
36, 44 46
Language Indication 37 Originator Requestd
Latest Delivery Alternate Recipient 46
Designation 37, 45 Originator Requested
Latest Delivery Alternate Recipient 37
Designation (1988) 8 Originator Requested
M e s s a g e F l o w Alternate Recipient
Confidentiality 28, 45 (1988) 8
Message Identification 7, Peer Entity Authentication
36, 44 28, 31
Message Origin Physical Delivery
Authentication 28, 31, Notification by MHS 34
32, 45 Physical Delivery
Message Security Labelling Notification by PDS
28, 31, 45 34, 42
Message Sequence Integrity Physical Forwarding
28, 45 Allowed 34, 42
MS-Register 28, 31 Physical Forwarding
Multi Destination Delivery Prohibited 34, 42
8, 45 Physical Physical Delivery
Multi-Destination Delivery Notification by MHS 42
37 Prevention of Non-delivery
Multi-part Body 37 Notification 8, 37
Multipart Body 45 Primary and Copy
Non Repudiation of Content Recipients Indication
Received 45 37
Non-delivery Notification Probe 8, 37
7, 36, 44 P r o b e O r i g i n
Non-receipt Notification Authentication 28, 32,
Request 37 46
Non-repudiation of Content Proof of Content Received
Received Request 45 46
Non-Repudiation of Proof of Content Received
Delivery 28, 32, 45 Request 46
Non-repudiation of EDI Proof of Delivery 28, 46
Notification 45 Proof of EDI Notification
277
46 Stored Message Auto
Proof of EDI Notification Forward 13
Request 46 Stored Message Deletion
Proof of Submission 28, 13
32, 46 Stored Message Fetching
Receipt Notification 13
Request Indication 37 Stored Message Listing 13
Recipient Indication 46 Stored Message Summary 13
Redirection Disallowed by Subject Indication 38
Originator 37, 46 Submission Time Stamp
Redirection Disallowed by Indication 7, 36, 44
Originator (1988) 8 Typed Body 36, 44
Redirection of Incoming Undeliverable Mail with
Messages 37, 46 Return of Physical
Redirection of Incoming Message 34, 42
Messages (1988) 8 Use of Distribution List
Register 28, 31 17, 38, 46
Registered Mail 34, 42 User/UA Capabilities
Registered Mail to Registration 15
Addressee in Person User/UA Capabilities
34, 42 Registration (1988) 7,
Related Message 46 36, 44
Reply Request Indication Not Applicable 3
37 Not Defined 3
Replying IP-message O/R Address Attributes
Indication 37 administration-domain-name
R e p o r t O r i g i n 81, 83
Authentication 28, 32, common-name 82, 83
46 country-name 81, 82
Request for Forwarding domain-defined-attributes
Address 34, 42 82, 83
Requested Delivery Method extended-network-address
37, 46 82, 83
Requested Delivery Method extension-attributes 82
(1988) 8 extension-OR-address-compo
Restricted Delivery 38, nents 82, 83
46 extension-physical-deliver
Restricted Delivery (1988) y-address-components
8 82, 83
Return of Content 8, 38, generation-qualifier 82,
46 83
Secure Access Management given-name 82, 83
46 initials 82, 83
Security Context 28, 31 local-postal-attributes
Sensitivity Indication 38 82, 83
Services Indication 46 network-address 81, 83
Special Delivery 34, 42 numeric-user-identifier
Stored EDI Message 82, 83
Auto-forward 46 organization-name 82, 83
Stored Message Alert 13 organizational-unit-names
278
82, 83 organizationalPerson 22
pds-name 82, 83 organizationalRole 22
personal-name 82, 83 organizationalUnit 22
physical-delivery-country- residentialPerson 22
name 82, 83 Object Identifiers
physical-delivery-office-n commercial-in-confidence-i
ame 82, 83 d 117
physical-delivery-office-n confidence-id 117
umber 82, 83 id-category-id 117
physical-delivery-organiza id-mhs-security 117
tion-name 82, 83 id-policy-id 117
physical-delivery-personal management-in-confidence-i
-name 82, 83 d 117
post-office-box-address personal-in-confidence-id
82, 83 117
postal-code 82, 83 private-id 117
poste-restante-address security-class 117
82, 83 security-class-0a 117
private-domain-name 82, security-class-1a 117
83 security-class-2a 117
street-address 82, 83 Operations
surname 82, 83 alert 85, 88
teletex-common-name 82, cancel-deferred-delivery
83 73, 85
teletex-domain-defined-att CancelDeferredDelivery 75
ributes 82, 83 change-credentials 73, 85
teletex-organization-name ChangeCredentials 77, 98
82, 83 delete 85, 87
teletex-organizational-uni delivery-control 73
t-names 82, 83 DeliveryControl 76, 97
teletex-personal-name 82, fetch 85, 87
83 list 85, 86
terminal-identifier 81, message-delivery 73
83 message-submission 73, 85
terminal-type 82, 83 MessageDelivery 76, 95,
unformatted-postal-address 100
82, 83 MessageSubmission 75,
unique-postal-name 82, 83 100, 115
Object Classes MessageTransfer 61
groupOfNames 22 MSBind 85, 103
locality 22 MSUnbind 85
MHS Distribution List 22 MTABind 61, 91
MHS User 22 MTAUnbind 61
mhs-distribution-list 22 MTSBind 73, 74, 97
mhs-message-store 22 MTSUnbind 73
mhs-message-transfer-agent probe-submission 73, 85
22 ProbeSubmission 75
mhs-user 22 ProbeTransfer 61
mhs-user-agent 22 register 73, 76, 85, 97
organization 22 register-ms 85, 87, 103
279
report-delivery 73
ReportDelivery 76
ReportTransfer 61
submission-control 73, 85
SubmissionControl 75, 97
summarize 85, 86
P1 118
Port Types
MASE 73, 85
MDSE 73
MRSE 85
MSSE 73, 85
Support 3
280