ANSI INCITS ISO IEC 14361-1996 Information technology - MHS-based electronic messaging - Application Program Interface (API) [Language independent] (Adopted by INCITS).pdf

《ANSI INCITS ISO IEC 14361-1996 Information technology - MHS-based electronic messaging - Application Program Interface (API) [Language independent] (Adopted by INCITS).pdf》由会员分享，可在线阅读，更多相关《ANSI INCITS ISO IEC 14361-1996 Information technology - MHS-based electronic messaging - Application Program Interface (API) [Language independent] (Adopted by INCITS).pdf（202页珍藏版）》请在麦多课文档分享上搜索。

1、INTERNATIONAL STANDARD ISO/IEC 14361 First edition 1996-06-01 Information technology - MHS-based electronic messaging - Application Program Interface (API) Language independent Technologies de /information - Messagerie Blectronique ba for example, those 41 for security. 42 Related Standards Activiti

2、es 43 44 45 46 47 48 49 50 0 ISOflEC ISOLIEC 14361:1996(E) The following areas are under active consideration at this time, or are expected to become active in the near future, concerning extensions to this International Stan- dard. Similar efforts can be anticipated in the future:) (1) Directory se

3、rvices (2) FTAM API (3) Verification testing methods (4) Network interface facilities (5) System administration. This International Standard is based on IEEE Std 1224.1-1993 (B8, which was prepared by the P1224 Working Group, sponsored by the Portable Applications Standards Committee of the IEEE Com

4、puter Society. 1) A Standards Status Report that lists all current IEEE Computer Society standards projects is available from the IEEE Computer Society, 1730 Massachusetts Avenue NW, Washington, DC 20036-1903, USA, Telephone: +1202 371-0101; FAX: +1202 728-9614. Introduction xi INIXXNATIONAL STANDAR

5、D OISO/IEC ISOREC 14361:1996(E) 1 Information technology-MHS-based 2 electronic messaging-Application Program 3 Interface (API) Language independent 4 5 6 The purpose of this International Standard is to provide APIs supporting the 7 development of applications that are users of the message transfer

6、 system, and 8 gateways that incorporate or use X.400 mail functionality. This includes gateways 9 between X.400 mail networks and proprietary mail systems. The interface sup- 10 ports access to X.400 services. 11 12 13 14 15 16 17 18 19 20 21 22 23 This International Standard provides a language-in

7、dependent specification. Section 1: General 1.1 Scope The interface is oriented towards the needs of gateways and applications that require full access to the features of the protocols. NOTE: There are industry-standard and proprietary APIs that can be used by simple applications that only require t

8、he main features of the protocols. This International Standard defines two application program interfaces to X.400- based electronic messaging systems. The interfaces are: (1) An X.400 API that makes the functionality of a message transfer system (MTS) accessible to a message store (MS) or user agen

9、t WA), or the func- tionality of a simple MS accessible to a UA (2) An X.400 Gateway API that divides a message transfer agent (MTA) into two software components, a messaging system gateway and an X.400 gateway service. 1.1 Scope 24 The following standards contain provisions which, through reference

10、 in this text, 25 constitute provisions of this International Standard. At the time of publication, 26 the editions indicated were valid. AI1 standards are subject to revision, and parties 27 to agreements based on this International Standard are encouraged to investigate 26 the possibility of apply

11、ing the most recent editions of the standards indicated 29 below. Members of IEC and IS0 maintain registers of currently valid Interna- 30 tional Standards. 31 32 ISO 639: 198 User Agent WA) and Message Transfer Agent 0: Access to an Administration Manage- ment Domain (ADMD), August 1987. 131 3) CEN

12、KXNLEX publications can be obtained from CEN/CENELEC, 2 Rue Brederode Bte.6, B- 132 1000 Brussels, Belgium. 4 1 General 133 OISO/IEC ISO/IEC 14361:1996(E) 1.3 Conformance 1.3.1 Implementation Conformance 134 1.3.1.1 Conformance Requirements 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149

13、 150 151 152 153 154 155 156 157 158 159 (4) Features. The manufacturer and product shall satisfy the following 160 requirements related to features: 161 - If the product implements the role of service for the MA or MT interface, 162 the manufacturer shall state which features it implements. 163 164

14、 165 166 167 168 169 4) The numbers in curly brackets correspond to those of the references in 1.2. A conforming implementation for a programming language binding specification for this International Standard shall meet all of the following criteria: (1) Support of defined behavior. The implementati

15、on shall support all required behavior defined in this International Standard. (2) Support of nonstandard extensions. The implementation may provide additional operations or facilities not required by this International Stan- dard or by the programming language binding specification. Each such nonst

16、andard extension shall be identified as such in the system documen- tation. Nonstandard extensions, when used, may change the behavior of operations or facilities defined by this International Standard or by the programming language binding specification. The conformance document shall define an env

17、ironment in which an application can be run with the behavior specified by this International Standard and the programming language binding specification. In no case shall such an environment require modification of a Strictly Conforming Application. (3) API requirements. The manufacturer and produc

18、t shall satisfy the fol- lowing requirements related to APIs: - The manufacturer shall identify the APIs (MA, MT, or both) the product implements and state what roles (client, service, or both) it plays for each. Those APIs shall support the behavior described in this International Standard and in t

19、he programming language binding specification. - The product shall implement the OM API defined in ISO/IEC 14360 (11,4 satisfying its conformance requirements, and implement the same roles for that API as it implements for the MA and MT interfaces. - If the product implements the role of service for

20、 the MA interface, it shall implement the Basic Access Functional Unit (FU) and the Submission FU, the Delivery FU, the Retrieval FU, or any combination of these. - If the product plays the role of service for the MT interface, it shall imple- ment the Basic Transfer FU and the Transfer In FU, the T

21、ransfer Out FU, or both. 1.3 Conformance 5 ISO/IEC 14361:1996(E) OISO/IEC 170 171 (5) Operations. The manufacturer and product shall satisfy the following 172 requirement related to operations: 173 174 175 (6) Classes. The manufacturer and product shall satisfy the following 176 requirements related

22、 to classes: 177 - If the product implements the IM 88 or MH 88 Package, the manufacturer 178 shall state which (if any) of its 1988 classes it implements. 179 - If the product implements the IM 88 or IM 84 Package, the manufacturer 180 shall state which (if any) immediate subclasses of the Body Par

23、t class the 181 product implements. 182 183 184 - If the product implements the MH 84 Package, it shall implement all of 185 those classes that are used by the functional units that it supports. 186 187 188 189 190 191 192 193 194 195 - If the product plays the role of service for the MT interface,

24、the manufac- 196 turer shall state whether or not it realizes the interface by means of the 197 Message Transfer Protocol (Pl) of X.400. 198 199 200 201 202 - If the product implements Pl (1988), P3 (1988), or P7 (1988), the 203 manufacturer and product shall satisfy the conformance requirements of

25、204 X.400 (1988) with respect to those protocols.” 205 NOTE: A 1988 package can be realized by means of the corresponding 1988 protocol 206 alone, but a 1984 package can be realized using either the 1984 or the 1988 protocol. - If the product plays the role of service for either interface, the produ

26、ct shall implement the MH 88 Package, the MH 84 Package, or both. - The product shall implement every aspect of every operation in each FU for which it plays the role of service. - If the product implements the IM 84 or SM 88 Package, it shall imple- ment every class the package contains. - The prod

27、uct shall implement the closures of all classes it implements. - The product shall state for which classes it provides the Encode and Decode operations. (7) Protocols. The manufacturer and product shall satisfy the following requirements related to protocols: - If the product plays the role of servi

28、ce for the MA interface, the manufac- turer shall state whether or not it realizes the interface by means of the Message Submission and Delivery Protocol (P3) or Message Retrieval Pro- tocol (P7) of x.400. - If the product plays the role of service for either interface and implements the IM 88 or IM

29、 84 Package, the manufacturer shall state whether or not the product realizes the interface by means of the Interpersonal Messag- ing Protocol (P2) of X.400. 1 General OISOLIEC ISO/IEC 14361:1996(E) 207 208 209 210 (9) Interpretation of any syntax. Wherever an any appears in the syntax 211 column of

30、 an attribute definition, this shall be treated as the correspond- 212 ing OM syntax wherever the underlying ASN.l encoding is a Universal 213 simple type, as listed in ISOfiEC 14360 (11). 214 1.3.1.2 Conformance Documentation 215 A conformance document with the following information shall be availa

31、ble for an 216 implementation claiming conformance to a programming language binding 217 specification for this International Standard. The conformance document shall be 218 in two parts. The first part shall have the same structure as this International 219 Standard, with the information presented

32、in the appropriately numbered sections, 220 clauses, and subclauses. The second part shall have the same structure as the pro- 221 gramming language binding specification, with the information presented in the 222 appropriately numbered sections, clauses, and subclauses. The conformance docu- 223 me

33、nt shall not contain information about extended features or capabilities outside 224 the scope of this International Standard and the programming language binding 225 specification. 226 The conformance document shall identify the programming language binding 227 specification to which the implementa

34、tion conforms. 228 The conformance document shall contain a statement that indicates the full 229 names, numbers, and dates of the language-independent and programming 230 language binding specification standards that apply. 231 The conformance document shall state which of the optional features def

35、ined in 232 this International Standard and in the programming language binding 233 specification are supported by the implementation. 234 The conformance document shall describe the behavior of the implementation for 235 all implementation-defined features defined in this International Standard and

36、 in 236 the programming language binding specification. This requirement shall be met 237 by listing these features and by providing either a specific reference to the system 238 documentation or full syntax and semantics of these features. The conformance 239 document may specify the behavior of th

37、e implementation for those features where 240 this International Standard or the programming language binding specification 241 states that implementations may vary or where features are identified as 242 undefined or unspecified. 243 No specifications other than those specified by this Internationa

38、l Standard and the 244 programming language binding specification shall be present in the conformance 245 document. 246 The phrases “shall document” or “shall be documented” in this International Stan- 247 dard or in a programming language binding specification for this International 248 Standard me

39、an that documentation of the feature shall appear in the conformance (8) Options. The manufacturer and product shall satisfy the following requirement related to implementation options: - If the product plays the role of service for the MA or MT interface, the manufacturer shall state the behavior o

40、f implementation-defined options. 1.3 Conformance 7 ISO/lEC 14361:1996(E) OISO/IEC 249 250 251 252 1.3.1.3 Conforming Implementation Options 253 254 255 256 257 258 259 260 261 262 264 (7) Which and how many sessions the mx-wait operation notifies of the 265 arrival of an object when several session

41、s provide access to a delivery, 266 retrieval, or input queue. 267 1.3.2 Application Conformance 268 All applications claiming conformance to a programming language binding 269 specification for this International Standard shall fall within one of the categories 270 defined in the following subclaus

42、es. 271 1.3.2.1 Strictly Conforming Application 272 A Strictly Conforming Application is an application that requires only the facilities 273 described in this International Standard, in the programming language binding 274 specification, and in the applicable language standards. Such an application

43、 shall 276 accept any behavior described in this International Standard or in the program- 276 ming language binding specification as unspecified or implementation defined and, 277 for symbolic constants, shall accept any value in the ranges permitted by this 278 International Standard and the progr

44、amming language binding specification. 279 280 281 1.3.2.2.1 ISO/IEC Conforming Application 282 An ISO/IEC Conforming Application of a programming language binding 283 specification for this International Standard is an application that uses only the 284 facilities described in this International St

45、andard, in the programming language document, as described previously, unless the system documentation is explicitly mentioned. The system documentation should also contain the information found in the confor- mance document. The following aspects of the behavior of the service are implementation de

46、fined: (1) The circumstances that define abnormal termination of a session (2) The features of a session that the mx-open operation supplies as defaults (3) Whether th e service will accept any circumstances as causes of temporary delivery failure (4) The maximum number of users that may be assigned

47、 to a single delivery queue (5) The maximum number of sessions that may exist simultaneously (6) Which qualifying object in the delivery or input queue (if there are several such objects) the ma-start-delivery or mt-stattJransferJn operation selects for delivery or transfer in 1.3.2.2 Conforming App

48、lication There is only one type of Conforming Application. 8 1 General 285 286 287 288 1.3.2.3 Conforming Application Using Extensions 289 A Conforming Application Using Extensions of a programming language binding 290 specification for this International Standard is an application that differs from

49、 a 291 Conforming Application only in that it uses nonstandard facilities that are con- 292 sistent with this International Standard and with the programming language 293 binding specification. Such an application shall fully document its requirements for 294 these extended facilities, in addition to the documentation required of a Conform- 295 ing Application. 296 1.4 Test Methods 297 Any measurement of conformance to a programming language binding 298 specification for this International Standard shall be performed using test methods 299 that conform to ISO/IEC 14363 (121 and to an