1、INTERNATIONAL STANDARD ISO/IEC 14360 First edition 1996-06-01 Information technology - Open Systems Interconnection (OSI) abstract data manipulation - Application Program Interface (API) Language independent Technologies de Iinformation - Manipulation de don! 6.3.9 Put 6.3.10 Read 6.3.11 Remove . 6.
2、3.12 Write 6.4 Return Codes . . . . . . . . . . . . . . . . . . . . . . . 111 ISO/IEC 14360:1996(E) 0 ISOAEC Section 7: Object Management Package . 7.1 Class Hierarchy . . . . . 7.2 Class Definitions . . . . 7.2.1 Encoding . . . . . 7.2.2 External . . . . . 7.2.3 Object . . . . . . . . . . . . . . .
3、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4、 . . . . . . . 71 71 71 71 72 73 Section 8: Definitions of Constants . 8.1 Introduction . . . . . . 8.2 Object Management API . . 8.3 Object Management Package Annex A (informative) Bibliography Alnhabetic Tonical Index . . . . FIGURES Figure 3-l - Conceptual Model of Object Management . Figure 4-l
5、- Structure of an Object . . . . . . . TABLES Table 5-l Table 5-2 Table 5-3 Table 5-4 Table 5-5 Table 6-1 Table 6-2 Table 7-l Table 7-2 Table 7-3 Table 8-l Table 8-2 - String Syntax Identifiers . . . . . . . - Syntax for ASN.l Simple Types . . . . - Syntaxes for ASN.l Useful Types . . . . - Syntaxes
6、 for ASN.1 Character String Types - Syntaxes for ASN.1 Type Constructors . - Service Interface Operations . . . . - Service Interface Return Codes . . . - Attributes Specific to Encoding . . . - Attributes Specific to External . . . . - Attributes Specific to Object . . . . - Class Object Identifier
7、 Constant Suffixes - Attribute Type Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 75 75 75 77 79 18 22 31 32 32 32 33 47 67 71 72 73 75 76 iv 0 ISO/IEC I
8、SOiIEC 14360:1996(E) Foreword IS0 (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized sys- tem for worldwide standardization. National bodies that are members of IS0 or IEC participate in the development of International S
9、tan- dards through technical committees established by the respective or- ganization to deal with particular fields of technical activity. IS0 and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with
10、IS0 and IEC, also take part in the work. In the field of information technology, IS0 and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft International Stan- dards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an Internati
11、onal Standard requires approval by at least 75 % of the national bodies casting a vote. International Standard ISO/IEC 14360 was prepared by IEEE (as IEEE Std 1224-1993) and was adopted, under a special “fast-track pro- cedure”, by Joint Technical Committee ISO/IEC JTC 1, Information technology, in
12、parallel with its approval by national bodies of IS0 and IEC. Annex A of this International Standard is for information only. V ISO/IEC 14360:1996(E) 0 ISO/IEC Introduction 2 (This introduction is not a normative part of ISO/IEC 14360, Information technology-Open Systems 3 Interconnection (OSI) abst
13、ract data manipulation-Application Program Interface (API) Language 4 independent, but is included for information only.) 5 6 8 9 10 11 Related Standards 12 13 14 15 16 This International Standard, and the language bindings derived from it, are 17 intended to be used in the definition of application
14、-specific APIs that provide OS1 18 services, such as the X.400-based API defined in ISOKIEC 14361 (B3) and the API 19 to directory services defined in ISO/IEC 14392 (B6). 20 ISO/IEC 14362 (4) contains a set of requirements to be satisfied by test methods for 21 measuring conformance to this Internat
15、ional Standard. They are stated in terms 22 that are independent of any particular programming language, and they apply to 23 test methods for measuring conformance to all standards defining programming 24 language bindings to this International Standard. 25 Overview 26 This International Standard d
16、efines an information architecture that addresses 27 objects that are based on ASN.l. By providing tools for manipulating ASN.l 28 objects, the OM interface shields the application programmer from much of the 29 complexity of encoding and decoding ASN.l elements using the ASN. 1 Basic 30 Encoding Ru
17、les (BER). 31 The Object Management API provides a platform on which a range of application- 32 specific APIs can be built. An application program must format its data into objects 33 and then submit (or retrieve) these objects using programmatic “calls” that are 34 standardized by the OM interface.
18、 35 The OM API consists of the syntactical definition of an OM object and of the opera- 36 tions that an application can invoke to manipulate instances of OM objects. The purpose of this International Standard is to define a general-purpose OS1 Abstract Data Manipulation (OM) Application Program Int
19、erface (API) in terms that are independent of any particular programming language. The OM interface is designed to be used with application-specific APIs that provide OS1 services to allow the transfer of Abstract Syntax Notation One (ASN.l) protocol elements in an application-independent fashion. T
20、his International Standard is intended to provide the basis for the definition of programming language bindings to which implementations and applications can conform. Such a language binding, for the C programming language, is contained in ISOLIEC 14364 tB41. vi Introduction 0 ISO/IEC ISO/IEC 14360:
21、1996(E) 37 38 39 40 41 The representation hiding that the OM interface provides is not by itself fully ade- 42 quate to meet the needs of environments supporting several application-specific 43 APIs (e.g., where an X.400 Application API and a Directory Services API can co- 44 exist in the same run-t
22、ime environment). The different APIs may impose different, 45 even conflicting, requirements on the internal representations of objects, and they 46 might be implemented by different vendors. 47 However, the OM interface does allow any number of OM interface implementa- 48 tions to coexist, each rep
23、resenting objects differently. This is accomplished by 49 means of workspaces. 50 Related Standards Activities 51 The following areas are under active consideration at this time, or are expected to 52 become active in the near future, concerning standards for application APIs that 53 use the mechani
24、sm defined in this International Standard. Similar efforts can be 54 anticipated in the future:) 55 56 57 58 59 60 The OM API presents to the programmer a uniform model for information based on the concept of classes. A class is described by a collection of OM attributes; each attribute consists of
25、one or more values, each of which is characterized by a type and an OM syntax (e.g., Integer, Boolean, and String). (1) X.400-based message handling (2) Directory services (3) FTAMAPI (4) Verification testing methods (5) Network interface facilities (6) System administration. This International Stan
26、dard is based on IEEE Std 1224-1993 B7, which was prepared by the P1224 Working Group, sponsored by the Portable Applications Standards Committee of the IEEE Computer Society. 1) A Standards Status Report that lists all current IEEE Computer Society standards projects is available from the IEEE Comp
27、uter Society, 1730 Massachusetts Avenue NW, Washington, DC 20036-1903, USA, Telephone: +1202 371-0101; FAX: i-1 202 728-9614. Introduction vii INTERNATIONAL STANDARD OISO/IEC ISCYIEC 14360:1996(E) 1 Information technology-Open Systems 2 Interconnection (OSI) abstract data 3 manipulation- Application
28、 Program 4 Interface (API) Language independent 5 Section 1: General 6 7 8 9 10 11 12 13 This International Standard provides a language-independent specification of an 14 interface and environment to support application portability at the source-code 15 level. It is intended to be used by applicati
29、on developers, system implementors, 16 test method writers, and users. 17 This International Standard describes the external characteristics and facilities 18 that are of importance to applications developers, rather than the internal con- 19 struction techniques employed to achieve these capabiliti
30、es. Special emphasis is 20 placed on those functions and facilities that are needed in a wide variety of com- 21 mercial applications. 1.1 Scope This International Standard defines a standard interface supporting the manipula- tion of complex arguments and parameters used by X.400 and Directory Serv
31、ices ApIs. The interface supports manipulation of abstract data defined in ASN.l and is for use in conjunction with, but is otherwise independent of, the X.400 and Direc- tory Services ApIs. An application shall be able to link and use multiple implementations of this API. 1.1 Scope 1 ISO/IEC 14360:
32、1996(E) OISOLIEC 22 The following standards contain provisions which, through reference in this text, 23 constitute provisions of this International Standard. At the time of publication, 24 the editions indicated were valid. All standards are subject to revision, and parties 25 to agreements based o
33、n this International Standard are encouraged to investigate 26 the possibility of applying the most recent editions of the standards indicated 27 below. Members of IEC and IS0 maintain registers of currently valid Interna- 28 tional Standards. 29 30 31 32 33 34 35 36 37 38 39 40 41 42 1.3.1 Implemen
34、tation Conformance 43 44 45 46 (1) The implementation shall support all required behavior defined in this 47 International Standard. 48 (2) The implementation shall support all required interfaces defined in the 49 programming language binding specification. Those interfaces shall sup- 50 port the b
35、ehavior described in this International Standard and in the pro- 51 gramming language specification. 52 1) ISO/IEC documents can be obtained from the IS0 Central Secretariat, 1 Rue de Varembe, Case 53 Postale 56, CH-1211, Geneve 20, Switzerland/Suisse. 54 2) CCITT documents can be obtained from the
36、Telecommunication Standardization Bureau of the 55 International Telecommunication Union, Sales Section, Place des Nations, CH-1211, Geneve 20, 56 SwitzerlandMuisse. 1.2 Normative References (11 ISOKIEC 8824: 1990” (CCIM X.208: 19882), Information technology-Open Systems Interconnection-Specificatio
37、n of Abstract Syntax Notation One (ASN. 1). ISO/IEC 8825: 1990 (CCIIT X.209: 19881, Information technology-Open Systems Interconnection-Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). (31 ISO/IEC 9594-8: 1990 (CCITT X.509: 19881, Information technology-Open Systems In
38、terconnection-The Directory-Part 8: Authentication framework. (4) ISOLIEC 14362: 1996, Information technology-Test methods for measuring conformance to Open Systems Interconnection (OSI) abstract data manipulation-Application Program Interface (API) Language indepen- dent. 1.3 Conformance 1.3.1.1 Re
39、quirements A conforming implementation for a programming language binding specification for this International Standard shall meet all of the following criteria: 2 1 General OISO/IEC ISO/lEC 14360:1996(E) 57 58 59 60 61 62 63 64 65 66 67 (4) The implementation shall comprise one or more workspaces (
40、see 4.8), 68 which shall support the OM package (see Section 7). 69 (5) In its implementation of the Encode and Decode operations, the service 70 shall support the Basic Encoding Rules (BER) from ISO/IEC 8825 (21.3) 71 1.3.1.2 Documentation 72 A conformance document with the following information sh
41、all be available for an 73 implementation claiming conformance to a programming language binding 74 specification for this International Standard. The conformance document shall be 75 in two parts. The first part shall have the same structure as this International 76 Standard, with the information p
42、resented in the appropriately numbered sections, 77 clauses, and subclauses. The second part shall have the same structure as the pro- 78 gramming language binding specification, with the information presented in the 79 appropriately numbered sections, clauses, and subclauses. The conformance docu-
43、80 ment shall not contain information about extended features or capabilities outside 81 the scope of this International Standard and the programming language binding 82 specification. 83 The conformance document shall identify the programming language binding 84 specification to which the implement
44、ation conforms. 85 The conformance document shall contain a statement that indicates the full 86 names, numbers, and dates of the language-independent and programming 87 language binding specification standards that apply. 88 The conformance document shall state which of the optional features define
45、d in 89 this International Standard and in the programming language binding 90 specification are supported by the implementation. 91 The conformance document shall describe the behavior of the implementation for 92 all implementation-defined features defined in this International Standard and in 93
46、the programming language binding specification. This requirement shall be met 94 by listing these features and providing either a specific reference to the system 95 documentation or providing full syntax and semantics of these features, The con- 96 formance document may specify the behavior of the
47、implementation for those 97 3) The numbers in curly brackets correspond to those of the references in 1.2. (3) The implementation may provide additional functions or facilities not required by this International Standard or by the programming language binding specification. Each such nonstandard ext
48、ension shall be identified as such in the system documentation. Nonstandard extensions, when used, may change the behavior of functions or facilities defined by this International Standard or by the programming language binding specification. The conformance document shall define an environment in w
49、hich an application can be run with the behavior specified by this Inter- national Standard and the programming language binding specification. In no case shall such an environment require modification of a Strictly Conforming Application. 1.3 Conformance 3 ISO/lEC 14360:1996(E) OISO/IEC 98 99 100 101 102 103 The phrases “shall document” or “shall be documented” in this International Stan- 104 dard or in a programming language binding specification for this International 105 Standard mean that documentation of the feature shall appear in the conformance 106 document, as describ
