ftp.cse.unsw.edu.au

home *** CD-ROM | disk | FTP | other *** search

/ ftp.cse.unsw.edu.au / 2014.06.ftp.cse.unsw.edu.au.tar / ftp.cse.unsw.edu.au / pub / doc / standards / posix / p1003.0 / d13 / all < prev next >

Wrap

Text File | 1992-10-18 | 770.6 KB | 23,695 lines

IEEE P1003.0 Draft 13 - September 1991 Copyright (c) 1991 by the Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street New York, NY 10017, USA All rights reserved as an unpublished work. This is an unapproved and unpublished IEEE Standards Draft, subject to change. The publication, distribution, or copying of this draft, as well as all derivative works based on this draft, is expressly prohibited except as set forth below. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities only, and subject to the restrictions contained herein. Permission is hereby also granted for member bodies and technical committees of ISO and IEC to reproduce this document for purposes of developing a national position, subject to the restrictions contained herein. Permission is hereby also granted to the preceding entities to make limited copies of this document in an electronic form only for the stated activities. The following restrictions apply to reproducing or transmitting the document in any form: 1) all copies or portions thereof must identify the document's IEEE project number and draft number, and must be accompanied by this entire notice in a prominent location; 2) no portion of this document may be redistributed in any modified or abridged form without the prior approval of the IEEE Standards Department. Other entities seeking permission to reproduce this document, or any portion thereof, for standardization or other activities, must contact the IEEE Standards Department for the appropriate license. Use of information contained in this unapproved draft is at your own risk. IEEE Standards Department Copyright and Permissions 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331, USA +1 (908) 562-3800 +1 (908) 562-1571 [FAX] P1003.0 Draft 13 STANDARDS PROJECT Draft Guide to the POSIX Open Systems Environment Sponsor Technical Committee on Operating Systems and Application Environments of the IEEE Computer Society Abstract: IEEE Std 1003.0-199x presents an overview of open system concepts and their application. Information is provided to persons evaluating systems on the existence of, and interrelationships among, application software standards, with the objective of enabling application portability and system interoperability. A framework is presented that identifies key information system interfaces involved in application portability and system interoperability and describes the services offered across these interfaces. Standards or standards activities associated with the services are identified where they exist, or are in progress. Gaps are identified where POSIX Open Systems Environment (OSE) requirements are not being addressed currently. Finally, the OSE profile concept is discussed with examples from several application domains. Keywords: application portability, open systems environments, profiles, POSIX P1003.0 / D13 September 1991 Copyright (c) 1991 by the Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street New York, NY 10017, USA All rights reserved. _T_h_i_s _i_s _a_n _u_n_a_p_p_r_o_v_e_d _I_E_E_E _S_t_a_n_d_a_r_d_s _D_r_a_f_t, _s_u_b_j_e_c_t _t_o _c_h_a_n_g_e. _P_e_r_m_i_s_s_i_o_n _i_s _h_e_r_e_b_y _g_r_a_n_t_e_d _f_o_r _I_E_E_E _S_t_a_n_d_a_r_d_s _C_o_m_m_i_t_t_e_e _p_a_r_t_i_c_i_p_a_n_t_s _t_o _r_e_p_r_o_d_u_c_e _t_h_i_s _d_o_c_u_m_e_n_t _f_o_r _p_u_r_p_o_s_e_s _o_f _I_E_E_E _s_t_a_n_d_a_r_d_i_z_a_t_i_o_n _a_c_t_i_v_i_t_i_e_s. _P_e_r_m_i_s_s_i_o_n _i_s _a_l_s_o _g_r_a_n_t_e_d _f_o_r _m_e_m_b_e_r _b_o_d_i_e_s _a_n_d _t_e_c_h_n_i_c_a_l _c_o_m_m_i_t_t_e_e_s _o_f _I_S_O _a_n_d _I_E_C _t_o _r_e_p_r_o_d_u_c_e _t_h_i_s _d_o_c_u_m_e_n_t _f_o_r _p_u_r_p_o_s_e_s _o_f _d_e_v_e_l_o_p_i_n_g _a _n_a_t_i_o_n_a_l _p_o_s_i_t_i_o_n. _O_t_h_e_r _e_n_t_i_t_i_e_s _s_e_e_k_i_n_g _p_e_r_m_i_s_s_i_o_n _t_o _r_e_p_r_o_d_u_c_e _t_h_i_s _d_o_c_u_m_e_n_t _f_o_r _s_t_a_n_d_a_r_d_i_z_a_t_i_o_n _o_r _o_t_h_e_r _a_c_t_i_v_i_t_i_e_s, _o_r _t_o _r_e_p_r_o_d_u_c_e _p_o_r_t_i_o_n_s _o_f _t_h_i_s _d_o_c_u_m_e_n_t _f_o_r _t_h_e_s_e _o_r _o_t_h_e_r _u_s_e_s, _m_u_s_t _c_o_n_t_a_c_t _t_h_e _I_E_E_E _S_t_a_n_d_a_r_d_s _D_e_p_a_r_t_m_e_n_t _f_o_r _t_h_e _a_p_p_r_o_p_r_i_a_t_e _l_i_c_e_n_s_e. _U_s_e _o_f _i_n_f_o_r_m_a_t_i_o_n _c_o_n_t_a_i_n_e_d _i_n _t_h_i_s _u_n_a_p_p_r_o_v_e_d _d_r_a_f_t _i_s _a_t _y_o_u_r _o_w_n _r_i_s_k. IEEE Standards Department Copyright and Permissions 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331, USA +1 (908) 562-3800 +1 (908) 562-1571 [FAX] _S_e_p_t_e_m_b_e_r _1_9_9_1 _S_H _X_X_X_X_X BEGIN_RATIONALE _E_d_i_t_o_r'_s _N_o_t_e_s This section will not appear in the final document. It is used for editorial comments concerning this draft. Comments in italics are not intended to form part of the final guide; they are editor's or coordinator comments for the benefit of reviewers. This draft uses small numbers in the right margin in lieu of change bars. d ``D'' denotes changes from Draft 12 to Draft 13. Per request of the d working group, I have removed all old diff-marks from Drafts 3 through d 12. Purely editorial changes such as grammar, spelling, cross references, or removals of editorial notes are not diff-marked. Unfortunately, it is not possible to accurately diff-mark the figures. To make draft handling in the meetings easier, each significant clause is set up to print starting on a recto page. This means that there is a larger number of blank pages than in previous drafts (assuming that the copy room handled the print master correctly). Just doing our bit for deforestation ... This draft has not yet been converted to use proper normative reference d and bibliographic entries and cross references. Since this will entail a d large amount of detailed work, I have been awaiting some degree of text d stability. For Draft 13, three major sections were replaced in their d entirety (and, interestingly enough, all three were received d approximately one month after the input cutoff date), so I believe the d required stability has not yet been achieved. d Hal Jespersen d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. _E_d_i_t_o_r_i_a_l _C_o_n_t_a_c_t_s Please send comments regarding the content and approach of this document to: Fritz Schulz Open Software Foundation 620 Herndon Parkway - Suite 200 Herndon, VA 22070 +1 (703) 481-9851 FAX: +1 (703) 437-0680 E-Mail: fschulz@osf.ORG Please report typographical errors (and index suggestions) to: Hal Jespersen POSIX Software Group 447 Lakeview Way Redwood City, CA 94062 +1 (415) 364-3410 FAX: +1 (415) 364-4498 E-Mail: hlj@Posix.COM (Electronic mail is preferred.) Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. _O_n_l_i_n_e _A_c_c_e_s_s d This draft is available in various electronic forms to assist the review d process. Our thanks to Andrew Hume of AT&T Bell Laboratories for d providing online access facilities. Note that this is a limited d experiment in providing online access; future drafts may be provided in d other forms, such as diskettes or a bulletin board arrangement, but the d instructions shown here are the only methods currently available. Please d also observe the additional copyright restrictions that are described in d the online files. d Assuming you have access to the Internet, the scenario is approximately d ftp research.att.com # research's IP address is 192.20.225.2 d <login as netlib; password is your email address> d cd posix/p1003.0/d13 d get toc index d binary d get p11-20.Z d The draft is available in several forms. The table of contents can be d found in toc, pages containing a particular section are stored under the d section number, sets of pages are stored in files with names of the form d p_n-_m, and the entire draft is stored in all. By default, files are d ASCII. A .ps suffix indicates PostScript. A .Z suffix indicates a d compress'_e_d file. The file index contains a general description of the d files available. d These files are also available via electronic mail by sending a message d like d send 3.4 4.6 6.2 from posix/p1003.0/d13 d to netlib@research.att.com. If you use email, you should _n_o_t ask for the d compressed version. For a more complete introduction to this form of d _n_e_t_l_i_b, send the message d send help d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. _P_O_S_I_X._0 _C_h_a_n_g_e _H_i_s_t_o_r_y This section is provided to track major changes between drafts. Since it was first added in Draft 10, earlier entries have been omitted. Draft 13 [September 1991] d - _T_o _B_e _P_r_o_v_i_d_e_d d Draft 12 [June 1991] - Clause 4.9: Separated OLTP model discussion into d two parts: the part consistent with the POSIX OSE d Model; and the ``real world'' part dealing with d System Integration Interfaces. d - Section 6: Further clarified ``base standard'' and d ``profile'' definitions. Renamed profile ``types''. d - _A_d_d_i_t_i_o_n_a_l _T_o _B_e _P_r_o_v_i_d_e_d d Draft 11 [March 1991] - _T_o _B_e _P_r_o_v_i_d_e_d _H_L_J: _I _d_o_n'_t _d_o _t_h_i_s _a_u_t_o_m_a_t_i_c_a_l_l_y _b_e_c_a_u_s_e _I _d_o_n'_t _k_n_o_w _w_h_a_t _i_s_s_u_e_s _y_o_u _c_o_n_s_i_d_e_r _i_m_p_o_r_t_a_n_t. _T_h_i_s [_v_e_r_y _b_r_i_e_f] _t_e_x_t _s_h_o_u_l_d _b_e _p_r_o_v_i_d_e_d _b_y _e_a_c_h _S_e_c_t_i_o_n _L_e_a_d_e_r _a_l_o_n_g _w_i_t_h _t_h_e _r_e_g_u_l_a_r _s_u_b_m_i_s_s_i_o_n_s. _I_t _i_s _m_e_a_n_t _t_o _p_r_o_v_i_d_e _c_a_s_u_a_l _r_e_a_d_e_r_s _o_f _t_h_e _g_u_i_d_e (_s_u_c_h _a_s _i_n _W_G_1_5, _w_h_e_r_e _t_h_e_y _d_o_n'_t _g_e_t _e_v_e_r_y _d_r_a_f_t) _w_i_t_h _a _b_r_o_a_d _o_v_e_r_v_i_e_w _o_f _t_h_e _b_i_g _c_h_a_n_g_e_s. Draft 10 [December 1990] - _T_o _B_e _P_r_o_v_i_d_e_d END_RATIONALE Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. IEEE Standards documents are developed within the Technical Committees of the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Board. Members of the committees serve voluntarily and without compensation. They are not necessarily members of the Institute. The standards developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE that have expressed an interest in participating in the development of the standard. Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applications. When the need for interpretations is brought to the attention of the IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of all concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, the IEEE and the members of its technical committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE Standards Board 445 Hoes Lane P.O. Box 1331 Piscataway, NJ 08855-1331 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. __________________________________________________________________ |IEEE Standards documents are adopted by the Institute of | |Electrical and Electronics Engineers without regard | |to whether their adoption may involve patents | |on articles, materials, or processes. | |Such adoption does not assume any liability to any patent owner, | |nor does it assume any obligation whatever to parties adopting | _||t_h_e__s_t_a_n_d_a_r_d_s__d_o_c_u_m_e_n_t_s_.__________________________________________|| Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Contents PAGE Introduction........................................................ ii Purpose.......................................................... ii The POSIX Open System Environment Reference Model................ ii Goals............................................................ ii Benefits......................................................... ii Related Standards Activities..................................... ii Section 1: General.................................................. 1 1.1 Scope...................................................... 1 1.2 Normative References....................................... 2 1.3 Conformance................................................ 3 Section 2: Terminology and General Requirements..................... 5 2.1 Conventions................................................ 5 2.2 Definitions................................................ 5 2.2.1 Terminology......................................... 5 2.2.2 General Terms....................................... 7 2.2.3 Abbreviations....................................... 13 Section 3: POSIX Open System Environment............................ 15 3.1 POSIX Open System Environment - General Requirements....... 16 3.2 POSIX Open System Environment Reference Model.............. 19 3.3 POSIX Open System Environment Services..................... 28 3.4 POSIX Open System Environment Standards.................... 29 3.5 POSIX Open System Environment Profiles..................... 32 3.6 Application Platform Implementation Considerations......... 33 Section 4: POSIX Open System Environment Services................... 39 4.1 Language Services.......................................... 43 4.2 System Services............................................ 53 4.3 Network Services........................................... 77 4.4 Database Services.......................................... 103 4.5 Data Interchange Services.................................. 117 4.6 Windowing System Services.................................. 125 4.7 Graphics Services.......................................... 145 4.8 Character-Based User Interface Services.................... 167 4.9 User Command Interface Services............................ 173 4.10 Transaction Processing Services............................ 183 4.11 Software Development Environments.......................... 197 Section 5: POSIX OSE Cross-Category Services........................ 207 5.1 Internationalization....................................... 209 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. ii PAGE 5.2 System Security Services................................... 229 5.3 Information System Management.............................. 235 5.4 Fault Management........................................... 245 Section 6: Profiles................................................. 249 6.1 Scope...................................................... 249 6.2 Profile Concepts........................................... 250 6.3 Guidance to Profile Writers................................ 252 Section 7: POSIX SP Profiling Efforts............................... 261 7.1 Introduction............................................... 261 7.2 General Purpose POSIX SPs.................................. 261 Annex A (informative) Considerations for Developers of POSIX SPs.... 273 A.1 Introduction............................................... 273 A.2 Scope...................................................... 273 A.3 The Role of POSIX SPs...................................... 274 A.4 Special Rules for POSIX SPs................................ 275 A.5 Other Issues............................................... 277 A.6 Conformance to a POSIX SP.................................. 279 A.7 Structure of Documentation for POSIX SPs................... 279 A.8 Rules for Drafting and Presentation of POSIX SPs........... 281 Annex B (informative) Bibliography.................................. 287 Annex C (informative) Standards Infrastructure Description.......... 289 C.1 Introduction............................................... 289 C.2 The Formal Standards Groups................................ 291 C.3 The Informal Standards Organizations....................... 306 Annex D (informative) Electronic-Mail............................... 321 Alphabetic Topical Index............................................ 323 FIGURES Figure 3-1 - POSIX OSE Reference Model............................ 20 Figure 3-2 - POSIX OSE Reference Model - Entities................. 22 Figure 3-3 - POSIX OSE Reference Model - Interfaces............... 24 Figure 3-4 - POSIX OSE Reference Model - Distributed Systems...... 28 Figure 3-5 - Distributed System Environment Model................. 29 Figure 3-6 - Service Components and Interfaces.................... 33 Figure 3-7 - Application Platform Implementation - Subdivision.... 35 Figure 3-8 - Application Platform Decomposition II - Layering..... 36 Figure 3-9 - Application Platform Decomposition III - Redirection...................................................... 36 Figure 4-1 - Language Service Reference Model..................... 44 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. iii Figure 4-2 - System Services Reference Model...................... 54 Figure 4-3 - Realtime Metrics..................................... 57 Figure 4-4 - POSIX Networking Reference Model..................... 78 Figure 4-5 - ISO Networking Reference Model....................... 81 Figure 4-6 - Relationship of ISO and POSIX OSE Network Reference Models........................................................... 83 Figure 4-7 - Multiple POSIX OSE APIs to Different OSI Layers...... 84 Figure 4-8 - Basic Network Services Model......................... 85 Figure 4-9 - Directory Services Architecture...................... 87 Figure 4-10 - OSI Network Services Standards...................... 101 Figure 4-11 - The Traditional Database Model...................... 105 Figure 4-12 - POSIX Database Reference Model...................... 106 Figure 4-13 - Data Interchange Reference Model.................... 118 Figure 4-14 - Windowing Reference Model........................... 127 Figure 4-15 - Computer Graphics Reference Model Level Structure... 149 Figure 4-16 - POSIX OSE Graphics Service Reference Model.......... 150 Figure 4-17 - POSIX OSE Graphics Service Reference Model Standards........................................................ 156 Figure 4-18 - Character-based Terminal Reference Model............ 168 Figure 4-19 - POSIX OSE Reference Model for Command Interfaces.... 174 Figure 4-20 - The Conventional Transaction Processing Model....... 186 Figure 4-21 - The POSIX OSE Transaction Processing Reference Model............................................................ 187 Figure 4-22 - Software Development Model.......................... 199 Figure 4-23 - Software Development Reference Model................ 200 Figure 6-1 - Development of a Profile............................. 258 Figure A-1 - Universe of Profiles and Standards................... 274 Figure C-1 - International and National Standards Bodies.......... 291 Figure C-2 - Selected Major Standards and Standards-Influencing Bodies........................................................... 292 Figure C-3 - IEEE Standards Diagram............................... 302 TABLES Table 4-1 - Language Standards Activities......................... 49 Table 4-2 - System Services Standards Activities.................. 67 Table 4-3 - Functionality of POSIX.1 Standard..................... 69 Table 4-4 - Current Networking Standards.......................... 98 Table 4-5 - Emerging Networking Standards......................... 99 Table 4-6 - Gaps in Networking Standards.......................... 100 Table 4-7 - Database Standards.................................... 111 Table 4-8 - Data Interchange Standards............................ 121 Table 4-9 - Windowing Standards................................... 140 Table 4-10 - Shell and Utilities Standards Activities............. 179 Table 4-11 - Transaction Processing Standards Activities.......... 192 Table 4-12 - Transaction Processing Standards Language Bindings... 193 Table 4-13 - Software Development Standards Activities............ 202 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. iv Table 7-1 - POSIX SPs In Progress................................. 262 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. v Introduction (This Introduction is not a normative part of P1003.0 Guide to the POSIX Open Systems Environment, but is included for information only.) Purpose There are many standards efforts going on throughout the world today. Standards are being developed in many areas of computing technology such as: - Electrical Connectors - Disk Interfaces - Network Interfaces - Application Program Interfaces Each standards effort typically addresses a very small portion of the overall needs of an information processing system. This guide is an attempt bring together many different standards sufficient to address the scope of an entire information processing system. This combination of standards and specifications that are sufficient to address all of the user requirements of an information processing system is called an Open System Environment. User requirements and standards to meet those requirements are continuously expanding. As such, this guide will need regular revision to incorporate new user requirements and the new standards that evolve to meet those user requirements. This guide is not a standard itself; it merely identifies standards that can be used when constructing a complete information processing system. It may never be necessary to implement an information processing system that provides every standard in the POSIX Open System Environment. Typically a subset of the standards is sufficient to satisfy the particular user requirements in each situation. This process of selecting standards for a particular application is called profiling. Recommendations for the production of different types of profiles are included in the guide. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. vi Introduction This guide is intended to be used by any computer user interested in using standards in their information processing systems including: consumers, systems integrators, application developers, systems providers, and procurement agencies. Taken as a whole, the guide maps existing and emerging standards onto the general requirements of a complete information processing system. In addition to listing and categorizing existing standards efforts, the guide identifies important requirements that standards efforts have not yet addressed. The POSIX Open System Environment Reference Model To describe the POSIX Open System Environment, the guide develops a reference model used to classify information processing standards. The reference model breaks standards into three general categories: - Platform External Interface Standards--These standards affect how an information processing system interacts with its external environment. These standards affect system interoperability, user interface look and feel, and data portability. - Application Program Interface Standards--These standards affect how application software interacts with the computer system. These standards affect application portability. - System Integration Interface Standards--These interfaces have no direct impact on the external interface of a system or the application program interface to the system. These interfaces are between the various parts of an information processing system. These standards are very important because they allow a user to independently procure portions of their information processing systems from multiple vendors according to each user's needs. The information processing system is broken into major component areas. Using the reference model, a general set of requirements for each component area is developed. For each of the requirements existing or emerging standards are identified that address the requirement. If a requirement is not completely met by an existing or emerging standard, this gap in the standards is noted. Goals There are three goals of the POSIX OSE: portability, interoperability, and user portability. (While these terms are formally defined later in this guide and within various referenced standards, the following descriptions provide an overview of their meaning.) Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Goals vii Portability Portability is accomplished through the use of the respective system/application interface standards and their extensions, thus allowing a user's application to operate on a wide range of systems. It is important to note that the aforementioned phrase ``wide range of systems'' connotes diverse hardware as well as software platforms. Using standards to provide application portability also will allow an application to be moved to systems with varying compute capabilities based on the performance needs of the application. Interoperability Interoperability is characterized by the cooperative operation of applications resident on dissimilar computer systems. This cooperative operation is illustrated by data and functionality exchange. User Portability User portability will allow users to move from system to system and between different applications on the same system with a minimum of retraining. Benefits The benefits derived in the use of the POSIX Open System Environment are real and quantifiable. Simplified Vendor Mixing System Integration As the standards for system integration and system interoperability are produced and implemented, the users will have the choice of mixing software and equipment from multiple vendors. This will allow users to tailor their information processing system to their particular needs by selecting their hardware based on the application needs rather than its ability to interoperate with their existing equipment. Efficient Development and Implementation Normally, systems users and providers have development and implementation activities that utilize personnel possessing skills in a specific computer environment. As a result of this specialization, a change in the target computer environment for a developer requires significant retraining expense. As standards for application portability, system interoperability, Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. viii Introduction and system integration are developed, computer personnel will begin to develop skills in working with these standards. When these standards are widely used there will be large pool of personnel who are familiar with working with the standards. This will allow a company to hire personnel with existing skills which can be put to use in their operation. In addition, within a company, resources can be redeployed between development efforts with a minimum of retraining. As the basic interfaces are developed and well defined, higher level standardized interfaces can be developed that add value to the basic interfaces. Using the higher level interfaces may speed development efforts. Efficient Porting of Applications The difficulty of moving an application from one hardware/software environment to another is widely known. The porting of an application that uses standards-based interfaces to another system that provides the same standards-based interfaces is considerably simpler than ports involving completely different systems. The amount of system tailoring (i.e., changes to either the operating or application system required to make them work well together) is greatly reduced. Broadened Basis for Computer System Procurement Decisions Computer users can now select and match hardware and software components from potentially different suppliers to fulfill an application requirement. This in turn allows decisions regarding computer systems procurements to be based less upon constraints imposed by incumbent vendors' products. The basis for competition will refocus on such factors as price, quality, value-added features, performance, and support. The stimulation of competition will benefit providers and users. Reduced Personnel Training Both providers and users of computer systems face high training costs when they switch hardware/software environments within which their application exists. Usage of standards makes inroads into reducing the costs of retraining users of all types. Reduced training will be incurred for developers and end-users alike. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Benefits ix Related Standards Activities The Standards Subcommittee of the IEEE Technical Committee on Operating Systems and Application Environments has authorized other standards activities that are related to the content of this guide. The following areas are under active consideration at this time, or are expected to become active in the near future:1) (1) Language-independent service descriptions of the POSIX.1 {2} system application program interface (API) (2) C, Ada, and FORTRAN Language bindings to (1) (3) Shell and Utility facilities (4) Verification testing methods (5) Realtime facilities (6) Secure/Trusted System considerations (7) Network interface facilities (8) System Administration (9) Graphical User Interfaces (10) Profiles describing application- or user-specific combinations of Open Systems standards for: supercomputing, multiprocessor, and batch extensions; transaction processing; realtime systems; and multiuser systems based on historical models Extensions are approved as ``amendments'' or ``revisions'' to this document, following the IEEE and ISO/IEC Procedures. Approved amendments are published separately until the full document is reprinted and such amendments are incorporated in their proper positions. __________ 1) A _S_t_a_n_d_a_r_d_s _S_t_a_t_u_s _R_e_p_o_r_t that lists all current IEEE Computer Society standards projects is available from the IEEE Computer Society, 1730 Massachusetts Avenue NW, Washington, DC 20036-1903; Telephone: +1 202 371-0101; FAX: +1 202 728-9614. Working drafts of POSIX standards under development are also available from this office. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. x Introduction If you have interest in participating in the TCOS working groups addressing these issues, please send your name, address, and phone number to the Secretary, IEEE Standards Board, Institute of Electrical and Electronics Engineers, Inc., P.O. Box 1331, 445 Hoes Lane, Piscataway, NJ 08855-1331, and ask to have this forwarded to the chairperson of the appropriate TCOS working group. If you have interest in participating in this work at the international level, contact your ISO/IEC national body. P1003.0 was prepared by the 1003.0 working group, sponsored by the Technical Committee on Operating Systems and Application Environments of the IEEE Computer Society. At the time this standard was approved, the membership of the 1003.0 working group was as follows: Technical Committee on Operating Systems and Application Environments (TCOS) Chair: Jehan-Franc,ois Pa^ris TCOS Standards Subcommittee Chair: Jim Isaak Vice Chairs: Ralph Barker Robert Bismuth Hal Jespersen Lorraine Kevra Pete Meier Treasurer: Quin Hahn Secretary: Shane McCarron 1003.0 Working Group Officials Chair: Allen Hankinson Vice Chair: Kevin Lewis Document Editor: Hal Jespersen (sponsored by Mike Lambert) Technical Editor: Fritz Schulz Secretary: Charles Severance Working Group <_N_a_m_e _t_o _b_e _p_r_o_v_i_d_e_d> <_N_a_m_e _t_o _b_e _p_r_o_v_i_d_e_d> <_N_a_m_e _t_o _b_e _p_r_o_v_i_d_e_d> Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. xi The following persons were members of the 1003.0 Balloting Group that approved the standard for submission to the IEEE Standards Board: <_N_a_m_e> <_I_n_s_t_i_t_u_t_i_o_n> _I_n_s_t_i_t_u_t_i_o_n_a_l _R_e_p_r_e_s_e_n_t_a_t_i_v_e <_N_a_m_e _t_o _b_e _p_r_o_v_i_d_e_d> <_N_a_m_e _t_o _b_e _p_r_o_v_i_d_e_d> <_N_a_m_e _t_o _b_e _p_r_o_v_i_d_e_d> When the IEEE Standards Board approved this standard on <_d_a_t_e _t_o _b_e _p_r_o_v_i_d_e_d>, it had the following membership: (to be pasted in by IEEE) Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. xii Introduction P1003.0/D13 Guide to the POSIX Open Systems Environment Section 1: General _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _K_e_v_i_n _L_e_w_i_s 1.1 Scope This guide identifies parameters for an open system environment using the POSIX operating system/application interface as the platform. These parameters are determined in three basic ways: (1) By specifying building blocks identified as components Currently these components are: system services, networking, human/computer interaction (HCI), graphics, system security and privacy, database, data interchange, and language requirements. This guide identifies the standards required within each component to achieve the goals of a POSIX open system. (2) By identifying intra- and intercomponent issues These issues involve the relationships that should exist between and among the different components. It is in the attempt to lay out and address these relationships that the concept of profiles (see 2.2.2 and Section 6) arises. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 1.1 Scope 1 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS (3) By identifying voids A void is determined by the absence, or lack of maturity, of formal standards development efforts. Voids may exist within available standards or may be an entire component. This guide provides assistance to those users who have already constructed, or plan to construct, profiles and to those users who currently use, or plan to use, profiles. The profile concept allows users to identify those standards that address their specific needs. The profile also serves to identify the need for future standards development in a specific area. This guide explains the manner in which these standards relate to each other. 1.2 Normative References _H_L_J: _A _l_i_s_t _o_f _r_e_f_e_r_e_n_c_e_d _s_t_a_n_d_a_r_d_s _a_n_d _o_t_h_e_r _p_u_b_l_i_c_a_t_i_o_n_s _n_e_e_d_s _t_o _b_e _p_r_o_v_i_d_e_d, _c_o_n_t_r_a_s_t_e_d _a_g_a_i_n_s_t _t_h_e _l_i_s_t _o_f _i_n_t_e_r_e_s_t_i_n_g _b_a_c_k_g_r_o_u_n_d _d_o_c_u_m_e_n_t_s _t_h_a_t _s_h_o_u_l_d _g_o _i_n_t_o _t_h_e _b_i_b_l_i_o_g_r_a_p_h_y, _i_n_c_l_u_d_e_d _a_s _A_p_p_e_n_d_i_x _C. _I _h_a_v_e _i_n_c_l_u_d_e_d _s_o_m_e _d_u_m_m_y _r_e_f_e_r_e_n_c_e_s _h_e_r_e, _s_o _y_o_u _c_a_n _s_e_e _t_h_e _s_t_y_l_e; _t_h_e_s_e _s_t_a_n_d_a_r_d_s _n_e_e_d _n_o_t _b_e _a_p_p_r_o_p_r_i_a_t_e _n_o_r_m_a_t_i_v_e _r_e_f_e_r_e_n_c_e_s. The following standards contain provisions which, through references in this text, constitute provisions of this guide. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this part of this International Standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards. {1} ISO 8859-1: 1987, _I_n_f_o_r_m_a_t_i_o_n _p_r_o_c_e_s_s_i_n_g--_8-_b_i_t _s_i_n_g_l_e-_b_y_t_e _c_o_d_e_d _g_r_a_p_h_i_c _c_h_a_r_a_c_t_e_r _s_e_t_s--_P_a_r_t _1: _L_a_t_i_n _a_l_p_h_a_b_e_t _N_o. _1.1) {2} ISO/IEC 9945-1: 1990, _I_n_f_o_r_m_a_t_i_o_n _t_e_c_h_n_o_l_o_g_y--_P_o_r_t_a_b_l_e _o_p_e_r_a_t_i_n_g _s_y_s_t_e_m _i_n_t_e_r_f_a_c_e (_P_O_S_I_X)--_P_a_r_t _1: _S_y_s_t_e_m _a_p_p_l_i_c_a_t_i_o_n _p_r_o_g_r_a_m_m_i_n_g _i_n_t_e_r_f_a_c_e (_A_P_I) [_C _L_a_n_g_u_a_g_e] __________ 1) ISO documents can be obtained from the ISO office, 1, rue de Varembe', Case Postale 56, CH-1211, Gene`ve 20, Switzerland/Suisse. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 2 1 General ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 1.3 Conformance Not applicable. d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 1.3 Conformance 3 P1003.0/D13 Section 2: Terminology and General Requirements _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _J_o_h_n _W_i_l_l_i_a_m_s 2.1 Conventions This guide uses the following typographic conventions: - The _i_t_a_l_i_c font is used for cross references to defined terms within 1.3, 2.2.1, and 2.2.2. d In some cases tabular information is presented ``inline;'' in others it is presented in a separately labeled Table. This arrangement was employed purely for ease of typesetting and there is no normative difference between these two cases. The typographic conventions listed above are for ease of reading only. Editorial inconsistencies in the use of typography are unintentional and have no normative meaning in this guide. NOTEs provided as parts of labeled Tables and Figures are integral parts of this guide (normative). Footnotes and NOTEs within the body of the text are for information only (nonnormative). 2.2 Definitions 2.2.1 Terminology For the purposes of this guide, the following definitions apply: 2.2.1.1 implementation defined: An indication that the implementation shall define and document the requirements for correct program constructs and correct data of a value or behavior. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 2.2 Definitions 5 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 2.2.1.2 informative: Providing or disclosing information; instructive. d Used in standards to indicate a portion of the text that poses no d requirements; the opposite of _n_o_r_m_a_t_i_v_e. d 2.2.1.3 may: An indication of an optional feature. With respect to implementations, the word _m_a_y is to be interpreted as an optional feature that is not required in this guide, but can be provided. 2.2.1.4 normative: Of, pertaining to, or prescribing a norm or d standard. d Used in standards to indicate a portion of the text that poses d requirements. d 2.2.1.5 should: With respect to implementations, an indication of an implementation recommendation, but not a requirement. 2.2.1.6 POSIX: The term ``POSIX'' has been evolving recently into a generally positive term with, unfortunately, a number of different meanings. This subclause attempts to define the word and some related terms. The intent is to insure that the term POSIX is used in a useful and predictable manner in this document. As background, note that POSIX is sometimes used to denote the formal standard IEEE Standard 1003.1-1990, sometimes to denote that standard plus related standards and drafts emerging from IEEE P1003.x working groups, and sometimes to denote the groups themselves. In all those cases, it should be noted, POSIX is used as a noun. This document will use the term ``POSIX'' only as an adjective, and will use it only in well defined ways. This subclause serves as a preview of the usages in this book of POSIX terms. (These terms are defined, formally, or informally in subsequent clauses, and you will be referred to those clauses as appropriate.) The original POSIX standard will be referred to by its name, ISO 9945, and not by the term POSIX. The IEEE groups developing standards related to ISO 9945 are called, in this document, _P_O_S_I_X _w_o_r_k_i_n_g _g_r_o_u_p_s. Examples are the IEEE working groups P1003.2, P1003.3, etc. The groups' names will be abbreviated POSIX.2, POSIX.3, etc. The standards emerging out of the POSIX working groups will be referred to by their formal names (e.g., IEEE P1003.2 Draft 9) and are called Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6 2 Terminology and General Requirements ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 either _P_O_S_I_X _B_a_s_e _S_t_a_n_d_a_r_d_s or _P_O_S_I_X _S_t_a_n_d_a_r_d_i_z_e_d _P_r_o_f_i_l_e_s (POSIX SPs). 2.2.2 General Terms For the purposes of this guide, the following definitions apply: 2.2.2.1 application: The use of capabilities (services/facilities) provided by an information system specific to the satisfaction of a set of user requirements. NOTE: These capabilities include hardware, software, and data. 2.2.2.2 application platform: A set of resources that support the services on which an application or application software will run. The application platform provides services at its interfaces that, as much as possible, make the specific characteristics of the platform transparent to the application. 2.2.2.3 application program interface (API): The interface between the applications software and the applications platform, across which all services are provided. The application program interface is primarily in support of application portability, but system and application interoperability are also supported via the communications API. 2.2.2.4 application software: Software that is specific to an application and is composed of programs, data, and documentation. 2.2.2.5 Applications Environment Profile (AEP): A profile, specifying a d complete and coherent subset of an OSE, in which standards, options, and d parameters chosen are necessary to support a class of applications. d AEPs are intended for use in procurement, conformance testing, and designating a software engineering target. 2.2.2.6 base standard: A standard or specification that is recognized as appropriate for normative reference in a profile by the body adopting that profile. 2.2.2.7 Communications Interface: The boundary between application software and the external environment, such as other application software, external data transport facilities, and devices. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 2.2 Definitions 7 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS The services provided are those whose protocol state, syntax, and format all must be standardized for interoperability. 2.2.2.8 domain: A field of influence, such as office or industrial automation, transaction processing, or realtime control systems. 2.2.2.9 External Environment Interface (EEI): The interface between the application platform and the external environment across which information is exchanged. The External Environment Interface is defined primarily in support of system and application interoperability. The primary services present at the External Environment Interface comprise: - Human/Computer Interaction Services - Information Services - Communications Services 2.2.2.10 external environment: A set of external entities to the application platform in which information is exchanged. These devices include displays, disk drives, sensors, and effectors directly accessible within the system. 2.2.2.11 hardware: Physical equipment used in data processing as opposed to programs, procedures, rules, and associated documentation. 2.2.2.12 Human/Computer Interface: The boundary across which physical interaction between a human being and the application platform takes place. 2.2.2.13 Information Interchange Interface: The boundary across which external, persistent storage service is provided. Only the format is required to be specified for data portability and interoperability. 2.2.2.14 interface: The shared boundary between two functional units, defined by functional characteristics and other characteristics, as appropriate. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 8 2 Terminology and General Requirements ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 2.2.2.15 internationalization: The process of designing and developing a product with a set of features, functions, and options intended to facilitate the adaptation of the product to satisfy a variety of cultural environments. 2.2.2.16 interoperability: The ability of two or more systems to exchange information and to mutually use the information that has been exchanged. 2.2.2.17 language-binding API: The interface between applications and d application platforms based on language-independent binding APIs and d consistent with the paradigms used for a specific programming language. d 2.2.2.18 language-independent service specification: A specification d that facilitates the management and development of consistent language- d binding standards. d 2.2.2.19 locale: A description of a cultural environment. 2.2.2.20 localization: The process of utilizing the internationalization features to create a version of the product for a specific culture. 2.2.2.21 local adaptation: The process of modifying a product that has hard-coded biases of one culture to the hard-coded biases of another culture. 2.2.2.22 open specifications: Public specifications that are maintained by an open, public consensus process to accommodate new technologies over time and that are consistent with international standards. 2.2.2.23 Open System Application Program Interface: A combination of standards-based interfaces specifying a complete interface between an application program and the underlying application platform. This is divided into the following parts: - Human/Computer Interaction Services API - Information Services API - Communications Services API - System Services API Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 2.2 Definitions 9 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 2.2.2.24 open system: A system that implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered applications software: - to be ported with minimal changes across a wide range of systems - to interoperate with other applications on local and remote systems - to interact with users in a style that facilitates user portability. 2.2.2.25 Open System Environment (OSE): The comprehensive set of d interfaces, services, and supporting formats, plus user aspects for d interoperability or for portability of applications, data, or people, as d specified by information technology standards and profiles. d 2.2.2.26 performance: A measure of a computer system or subsystem to perform its functions; for example, response time, throughput, number of transactions per second. 2.2.2.27 performance evaluation: The technical assessment of a system or system component to determine how effectively operating objectives have been achieved. 2.2.2.28 performance requirement: A requirement that specifies a performance characteristic that a system or system component must possess; for example, speed, accuracy, frequency. 2.2.2.29 portability: The ease with which software can be transferred from one information system to another. 2.2.2.30 POSIX Open System Environment (POSIX OSE): The Open System d Environment in which the standards included are International, Regional, d and National Information Technology Standards and profiles that are in d accord with ISO/IEC 9945 (POSIX). d This guide represents the POSIX OSE as it existed when the guide was approved. 2.2.2.31 POSIX OSE Cross-Category Services: A set of tools and/or features that has a direct effect on the operation of one or more component of the POSIX Open System Environment, but is not in and of itself a stand-alone component. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 10 2 Terminology and General Requirements ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 2.2.2.32 POSIX Standardized Profile (POSIX SP): A Standardized Profile that specifies the application of certain POSIX base standards in support of a class of applications and does not require any departure from the structure defined by the POSIX.0 Reference Model for POSIX systems. NOTE: Which POSIX base standards form the basis of the POSIX SPs is still open. Annex A discusses some of the issues involved. 2.2.2.33 process: An address space and single thread of control that d executes within that address space, and its required system resources. A process is created by another process issuing the _f_o_r_k() function. The process that issues _f_o_r_k() is known as the parent process, and the new process created by the _f_o_r_k() as the child process. 2.2.2.34 profile: A set of one or more base standards, and, where applicable, the identification of chosen classes, subsets, options, and parameters of those base standards, necessary for accomplishing a d particular function. d 2.2.2.35 programming language API: The interface between applications d and application platforms traditionally associated with programming d language specifications, such as program control, math functions, string d manipulation, etc. d 2.2.2.36 protocol (OSI): A set of semantic and syntactic rules that determine the behavior of [OSI-] entities in the same layer in performing communication functions. 2.2.2.37 redirection: A system profile construction method of starting at a base platform and adding new services by allowing a service component to ask the base platform to redirect all requests for that type of service to the service component. 2.2.2.38 public specifications: Specifications that are available to d anyone for implementation and distribution (i.e., sale) of that d implementation without restriction. d 2.2.2.39 reference model: A simplified description or representation of something. 2.2.2.40 scaleability: The ease with which software can be transferred d from one graduated series of application platforms to another. d A simplified description or representation of something. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 2.2 Definitions 11 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 2.2.2.41 security: The protection of computer hardware and software from accidental or malicious access, use, modification, destruction, or disclosure. Tools for the maintenance of security are focused on availability, confidentiality, and integrity. 2.2.2.42 service delivery latency: The interval between (a) context switch from an application context to the operating system context, and (b) satisfaction of the service request. 2.2.2.43 service request latency: The interval between (a) context switch from an application context to the operating system context, and (b) the reverse context switch from the operating system context to the application context for a given service request. 2.2.2.44 software: The programs, procedures, rules, and any associated documentation pertaining to the operation of a data processing system. 2.2.2.45 specification: A document that prescribes, in a complete, d precise, verifiable manner, the requirements, design, behavior, or d characteristics of a system or system component. d 2.2.2.46 standardized profile: A balloted, formal, harmonized document d that specifies a profile. d 2.2.2.47 standards: Documents, established by consensus and approved by d a recognized body, that provide, for common and repeated use, rules, guidelines, or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context. NOTE: Standards should be based on the consolidated results of science, technology, and experience, and aimed at the promotion of optimum community benefits. 2.2.2.48 System Internal Interface (SII): The interface between d application platform service components within that platform; it may be d standardized or nonstandard. d 2.2.2.49 system services: Firmware and software that provide an aggregation of network element functions into a higher level function; provide an interface to the data contained in the system. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 12 2 Terminology and General Requirements ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 2.2.2.50 System Services API: An interface providing access to services associated with the application's internal resources. The System Services API has two parts: Language Specifications and Processing Services API. 2.2.2.51 system software: Application-independent software that supports the running of application software. 2.2.2.52 transaction: A unit of work consisting of an arbitrary number of individual operations all of which will complete successfully (or be of no effect) on the intended resources. A transaction has well defined boundaries. A transaction starts with a request from the application program and either completes successfully (commits) or has no effect (abort). Both the commit and abort signify a transaction completion. 2.2.2.53 transaction application program: A program written to meet the d requirements of a chosen Transaction Processing (TP) application. Such programs allow a sequence of operations that involve resources such as terminals and databases. The transaction AP specifies transaction boundaries. The transaction AP as defined here is a logical entity and may involve an arbitrary number of processes. 2.2.2.54 validation: The process of evaluating a ported application, software, or system to ensure compliance with requirements. 2.2.3 Abbreviations For the purposes of this guide, the following abbreviations apply: 2.2.3.1 API: Application Program Interface 2.2.3.2 EEI: External Environment Interface 2.2.3.3 POSIX.0: This guide. 2.2.3.4 POSIX._nnnn: An IEEE POSIX working group, where the number _n represents the decimal notation in the IEEE P1003 series. Alternatively, when apparent from context, the latest standard issued, or under development, by that working group. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 2.2 Definitions 13 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 2.2.3.5 SII: System Internal Interface. d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 14 2 Terminology and General Requirements P1003.0/D13 Section 3: POSIX Open System Environment _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _F_r_i_t_z _S_c_h_u_l_z The POSIX Open System Environment (OSE) is a collection of concepts that provide a context for user requirements and standards specification. It provides a minimum, standard set of conceptual information system building blocks with associated interfaces and functionality. The POSIX OSE consists of a reference model, service definitions, standards, and profiles. These OSE concepts are also intended to be conventional within computer science. The intention is not to break new ground, but to establish a minimum and unambiguous terminology and set of concepts for identification and resolution of portability and interoperability issues. The POSIX Open System Environment is defined in five parts: (1) General requirements are identified that apply to the POSIX OSE as a whole in 3.1. (2) A reference model is developed that unambiguously identifies the system under consideration for purposes of specification. The POSIX OSE reference model described in 3.2 defines system elements to identify interfaces across which service requirements should be satisfied. The elements are chosen to expose those interfaces that are significant to the profile writer or user. (3) Using the interfaces identified in the reference models, each subclause of Section 4 categorizes and describes the basic services available to users across each interface. The services are defined in a generic way, based on the reference model, user requirements, and current industry practice, rather than any given implementation. Definition of the service requirements is not constrained by the availability of standards. Service requirements that are not currently satisfied via standards are discussed in either the Emerging Standards subclause, or under Gaps. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3 POSIX Open System Environment 15 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Each clause of Section 4 begins with a more detailed and specialized version of the reference model to provide a context for service specification. After defining the interfaces and services, each of the Section 4 clauses concludes with a discussion of standards that are related to the services. (4) Section 5 discusses issues and requirements that directly affect all of the service categories, such as internationalization, security, and administration. (5) Section 6 provides guidelines for creating profiles that address various application domains. This is a brief description of how the reference model and services are applied to a variety of existing types of systems. Section 7 describes current POSIX profiles and profiling activities. The text emphasizes the concept of service requirements (rather than services) to emphasize that the POSIX OSE only includes requirements, not solutions which satisfy those requirements. It is the standards and profiles listed in the subclauses of Sections 4 and 5 that will satisfy these requirements. Definition of the service requirements is not constrained by the availability of standards. Services requirements that are not currently satisfied via standards are discussed in either the Emerging Standards subclause, or under Gaps. 3.1 POSIX Open System Environment - General Requirements The POSIX Open System Environment should satisfy the requirements in the following list: (1) Application Portability at the Source Code Level The POSIX OSE shall enable application software portability at the source code level. Rationale: Comprehensive and consistent source code level service specifications allow porting of applications among processors (ideally without modification). Binary portability requires too tight a coupling with the processor implementation. (2) System Interoperability The POSIX OSE shall enable application software and system service interoperability. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 16 3 POSIX Open System Environment ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Rationale: Communications services and format specifications d allow two entities participating in a distributed system to exchange and make mutual use of data, including: - Homogeneous systems - Heterogeneous systems (i.e., a wide variety of hardware/software platforms) - POSIX-OSE-based and non-OSE-based systems (3) User Portability The POSIX OSE shall enable human users to operate on a wide range of systems without retraining. Rationale: Standard methods and services for supporting human/computer interaction are a key aspect of the definition of an open system (see Section 2). Elimination of gratuitous differences in the interface that the application platform presents to the user via standards is a significant aspect of this task. (4) Accommodation of Standards The POSIX OSE shall accommodate existing, imminent, and new information technology standards. Rationale: If the POSIX OSE were constrained to current technology, it would quickly become obsolete. It would also not be capable of providing a complete set of applicable standards and profiles, as efforts to-date have not yet provided a full suite of applicable standards. The POSIX OSE must evolve as standards emerge and technology changes. An inevitable tension exists between establishing fixed standards and providing for technology enhancement. Therefore, the POSIX OSE must be sufficiently general to allow for technology growth and yet specific enough to act as a guide for standards development. (5) Accommodation of New Information System Technology The POSIX OSE shall accommodate new Information System Technology. Rationale: The POSIX OSE must strive to satisfy the full range of the users' functional requirements. This is undoubtedly a requirement that will only be fully realized over time, but it Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3.1 POSIX Open System Environment - General Requirements 17 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS reflects the goal of the POSIX OSE. (6) Application Platform Scalability The POSIX OSE shall be scalable to platforms of varying power and implementation complexity. Rationale: This reflects the realities of the potential users of the POSIX OSE. This requirement affects individual standards as well as the conditions under which various of the standards can or should be combined into profiles. For example, where similar services are provided by both workstation type application platforms and supercomputers, the same standards should be applied to each if possible. This would enable a greater degree of portability across these specialized implementations of the application platform. (7) Distributed System Scalability The POSIX OSE shall provide for distributed system scalability. Rationale: The number of distributed system components connected should not be limited by any structural aspects of the POSIX OSE. For example, in the area of network services, the OSE standards should be such that it is possible to construct profiles (and therefore systems) in which remote and local operation and utilization of information system resources are indistinguishable, with the exception of unavoidable message transit delay. In other words, it should be possible for applications to be unaware of whether the application platform on which they are executing is local or distributed and that lack of awareness should not affect their proper operation. (8) Implementation Transparency The POSIX OSE shall provide implementation technology transparency. Rationale: The mechanism for implementation of services is not visible to the service user; i.e., only the service is visible to the service user. (9) User's Functional Requirements The POSIX OSE shall reflect the full scope of the user's functional requirements, within the context of the other Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 18 3 POSIX Open System Environment ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 requirements above. Rationale: The POSIX OSE will provide the context within which application software portability can be addressed and it is the set of user's functional requirements that defines the scope of transportable service needs. 3.2 POSIX Open System Environment Reference Model The POSIX OSE is based on a reference model with the full information system as its scope. As such, it spans the gap between requirement specification and the design of any specific information system. The reference model provides a set of conventions and concepts, mutually agreed upon between the information system user and provider communities. This common understanding is key to achieving application software portability, system interoperability, and may encourage software reuse. It will certainly allow for more compact and correct procurement specifications. The definition of this reference model is an engineering and management task and not a scientific one. There are many possible models and, while it might be interesting to contemplate an optimal one, a reference model that satisfies the requirements is all that is necessary. An information system reference model must satisfy conflicting requirements similar to those encountered in traditional architectural disciplines. The reference model must be structured enough to encourage the generation and use of standards and standard components. Yet it must also be flexible enough to accommodate tailored and special purpose components necessary to meet realworld needs. The POSIX OSE Reference Model is a set of concepts, interfaces, entities, and diagrams that provides a basis for specification of standards. The POSIX OSE Reference Model will provide guidance and direction for future standardization and integration efforts. In order for the POSIX OSE to evolve and mature, it will be necessary for the reference model to provide insights into those services and capabilities for which standards do not currently exist and for which appropriate standardization activities cannot be identified. The POSIX OSE Reference Model is described from the user perspective; i.e., the reference model records the application platform user's perception (mental model) of the overall large distributed system used to support the user enterprise. This point of view will assure that the: - Information technology users will have the proper services to meet their requirements, and Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3.2 POSIX Open System Environment Reference Model 19 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Information technology vendor implementations will not be constrained unnecessarily. _________________________________________________________________________ _________________________________________________________________________ Figure 3-1 - POSIX OSE Reference Model Figure 3-1 depicts the basic elements of the POSIX Open System Environment Reference Model. These include three entities (Application Software, Application Platform, and External Environment) and two interfaces between them, identified as the Application Program Interface (API) and the External Environment Interface (EEI). The application platform provides API and EEI services across the associated interfaces. This model has been generalized to such a degree that it can accommodate a wide variety of general and special purpose systems. More detailed requirements exist for each service category described in Section 4. The service specification has been defined to be robust and flexible enough to allow subsets or extensions for each category as needed. As a result, the POSIX OSE reference model is able to accommodate a variety of architectures and standardization approaches. It should be possible to show where any relevant standard fits within the reference model. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 20 3 POSIX Open System Environment ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Standards (in the sense of formally adopted consensus specifications) address only interfaces between entities, as well as services and supporting formats offered across those interfaces. The interface specification defines a convention adopted to represent the function offered across the interface in both directions. Note that no set of standards can, by itself, assure portability of specific applications. Applications must be properly engineered with an explicit portability objective in order to achieve it. The Reference Model is not a layered model. The application platform provides services to a variety of users across both platform interfaces. d A human being invokes the platform services at the External Environment d Interface. If an application developer is the application platform user, d the services offered at the application program interface (API) are invoked at the source code level. All of these features may be available locally or remotely if the system is connected to a larger distributed system. All other resources and objects can be conceptualized as being contained within the application platform. d Note that the actual implementation of any given system element may differ greatly from the reference model presented. The intention is to define a conceptual reference model that the widespread design, implementation, and integration communities may assume in executing their activities. Partitioning of function for purposes of discussion or specification does not imply or endorse similar partitioning for design or implementation. 3.2.1 Reference Model Entities and Elements Figure 3-2 expands Figure 3-1 to identify elements of the Reference Model entities. For the purposes of this discussion, the term ``entities'' will be used when discussing the classification of items (i.e., ``things'') related to application portability. The term ``component'' will only be used when an entity is further decomposed into constituent parts. The application software entity is the only entity that is decomposed into components. Application Software is defined (see 2.2.2.4) as software specific to an application. It is composed of: - Programs (source code, command/script files, etc.) - Data (user data, application parameters, screen definitions, etc.), and Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3.2 POSIX Open System Environment Reference Model 21 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 3-2 - POSIX OSE Reference Model - Entities - Documentation (online documentation only; hardcopy not included). An application program is represented by source code, produced according d to a specific programming language and a set of language bindings (i.e., d API specifications) for the required services. These specifications may be public standards or other open specifications. An application program may be divided into two parts: - An _i_n_v_a_r_i_a_n_t portion of source code, requiring no change when ported, and - A _v_a_r_i_a_n_t portion of source code, which requires changes when ported. The objective of any effective application software portability method d should be to minimize the ``variant'' portion of the application software d via creation and use of API standards. This would ideally allow d application software components to be moved to a different (but Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 22 3 POSIX Open System Environment ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 portability-standard compliant) system and run without source code modification. However, since standards exist for which strictly conforming application software requires modification (e.g., memory requirements, processor-specific COBOL statements), this can only be approximated. Separate but related standards may be required to support the portability of each of the elements listed above. Examples of application software are the familiar word-processing, spreadsheet, or accounting packages, as developed by the consumer or a commercial application software developer. Each of these packages appears as an application software entity when executed on an application platform. One or more applications may run on a given application platform simultaneously, as represented by the boxes at the top of Figure 3-2. Each application can be thought of as an independent application entity, communicating and synchronizing with other applications, if necessary, via a variety of communications mechanisms. The Application Platform is defined (see 2.2.2.2) as the set of resources that support the services on which an application or application software will run. It provides services at its interfaces that, as much as possible, make the implementation-specific characteristics of the platform transparent to the application software. In order to assure system integrity and consistency, application software entities competing for application platform resources must access all resources via service requests across the API. Examples of application platform elements could include an operating system kernel, a realtime monitor program, and all hardware and peripheral drivers. The application platform concept does not imply or constrain any specific implementation beyond the basic requirement to supply services at the interfaces. For example, the platform might be a single processor shared by a group of applications, or it might be a large distributed system with each application dedicated to a single processor. (See 3.2.4.) The application platform for systems built to the POSIX OSE will differ greatly depending upon the requirements of the system and its intended use. It is expected that application platforms defined to be consistent with the POSIX OSE will not necessarily provide all the features discussed here, but will use tailored subsets for a particular set of application software. The External Environment contains the external entities with which the application platform exchanges information. These entities are classified into the general categories of human users, information interchange entities, and communications entities. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3.2 POSIX Open System Environment Reference Model 23 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Human users are not further classified, but are treated as an abstract, or average, person. Information interchange entities include removable disk packs, floppy disks, and security badges. Communications entities include phone lines, local area networks, and packet switching equipment 3.2.2 Reference Model Interfaces _________________________________________________________________________ _________________________________________________________________________ Figure 3-3 - POSIX OSE Reference Model - Interfaces Figure 3-3 expands Figure 3-1 to identify the services available at the reference model interfaces. Between these three classes of entities there are two types of interface where standards and other open system specifications are required to enable application software portability and interoperability. These two interface types are labeled as the Application Program Interface (API) and the External Environment Interface (EEI). Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 24 3 POSIX Open System Environment ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 3.2.2.1 External Environment Interface (EEI) The External Environment Interface is defined (see 2.2.2.9) as the interface between the application platform and the external environment across which information is exchanged. It is defined primarily in support of system and application software interoperability. User and data portability are directly provided by the EEI, but application software portability also is indirectly supported by reference to common concepts linking specifications at both interfaces. The services available at the EEI comprise: - Human/Computer Interaction Services - Information Services - Communications Services The Human/Computer Interaction EEI is the boundary across which physical interaction between the human being and the application platform takes place. Examples of this type of interface include CRT displays, keyboards, mice, and audio input/output devices. Standardization at this interface will allow users to access the services of compliant systems without costly retraining. The Information Services EEI defines a boundary across which external, persistent storage service is provided, where only the format and syntax d is required to be specified for data portability and interoperability. The Communications Services EEI provides access to services for interaction between internal application software entities and application platform external entities, such as application software entities on other application platforms, external data transport facilities, and devices. The services provided are those where protocol state, syntax, and format all must be standardized for application interoperability. 3.2.2.2 Application Program Interface (API) The Application Program Interface (API) is defined (see 2.2.2.3) as the interface between the application software and the application platform across which all services are provided. It is defined primarily in support of application portability, but system and application software interoperability also are supported via the communications services API. The POSIX OSE API is a combination of a number of standards-based interfaces. It can be thought of as a bookshelf containing several standards-based APIs, with each API a separate book on the bookshelf. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3.2 POSIX Open System Environment Reference Model 25 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS The POSIX OSE API specifies a complete interface between the application software and the underlying application platform, and may be divided into the following parts: - Human/Computer Interaction Services API - Information Services API - Communications Services API - System Services API The first three APIs listed are required to provide the application software with access to services associated with each of the external environment entities. The fourth API is required to provide access to services associated with the application platform internal resources, identified as the System Services API. This interface may be divided into two types of specifications; i.e., Language Service and System Services API specifications. Definitions of services at the API take the form of programming-language specifications, language-independent service specifications, and language bindings for the service specifications. These specifications may be d described as follows: d (1) Those traditionally associated with the language specifications, such as program control (if ... then ... else), math functions, string manipulation, etc., defined as _t_h_e _p_r_o_g_r_a_m_m_i_n_g _l_a_n_g_u_a_g_e _A_P_I, and (2) Services provided by the underlying application platform defined independent of language, such as interprocess communications, interobject messages, access to the user interface, and data storage. Specifications of for these services are defined d independently of any programming language, and are identified as d _l_a_n_g_u_a_g_e-_i_n_d_e_p_e_n_d_e_n_t _s_e_r_v_i_c_e _s_p_e_c_i_f_i_c_a_t_i_o_n_s. d (3) The language-independent service specifications are translated d into language-specific specifications used by programmers in d writing applications. These specifications provide access to d the services using methods consistent with a specific d programming language. Such language-specific specifications are d called _l_a_n_g_u_a_g_e-_b_i_n_d_i_n_g _A_P_I_s. d Creation of a _l_a_n_g_u_a_g_e-_i_n_d_e_p_e_n_d_e_n_t _s_e_r_v_i_c_e _s_p_e_c_i_f_i_c_a_t_i_o_n facilitates the management and development of consistent language binding standards. The language-binding specifications are used directly by programmers and Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 26 3 POSIX Open System Environment ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 application platform suppliers in implementing application software and platforms. The ``programming language''/``language binding'' dichotomy may be a result of the way Information Technology standards are currently developed. Programming language specifications are developed with the goal of being ``system independent'' (e.g., C, COBOL, FORTRAN, etc.). Language Binding specifications (e.g., POSIX.1 {2}, MOSI, etc.) are being translated into ``language-independent'' specifications, with one or more bindings for specific languages. 3.2.3 EEI-API Service Relationships The relationships between similarly named services provided at the API d and the EEI are not simple one-to-one relationships. For example, a data d storage service interface may provide an application with transparent d access to a remote file via network services. In this case, the d completion of the data storage service provided at the API is dependent d upon, and can be thought of as having been ``translated'' into, d communication services provided at the EEI. d Fortunately, it is not essential for the purpose of satisfying the requirements of the POSIX OSE to specify these relationships in detail. In fact, a detailed definition could unnecessarily constrain the implementation. A given implementation of the application platform will define the relationship between the API and EEI in different ways. 3.2.4 POSIX OSE-Based Distributed Systems d In a distributed environment, multiple application platforms may interact by way of a network external to the platforms, but connected to them via the communications EEI, as in Figure 3-4. For an application software entity to gain access to the EEI services, communications services are requested at the API. The implementation of the application platform translates these API requests into appropriate action at the EEI. Communication occurs between application platforms via external entities that implement the data transport function. These can use a wide variety of implementation methods and protocols, providing access to distributed data and services via the network. Distributed Systems are manifest in this model primarily through the use of the distributed system network services API. As can be seen in Figure 3-5, distributed systems are a refinement of the POSIX Network Environment Model shown in Figure 4-4. As such, a perceived Application Platform may in fact be comprised of several (or many) individual d application platforms. However, in the distributed environment, they d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3.2 POSIX Open System Environment Reference Model 27 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 3-4 - POSIX OSE Reference Model - Distributed Systems operate and are viewed as a single entity by the using applications. Within this extended application platform are the embedded network services necessary for the elements of a distributed environment to function. Within the distributed environment, network access between the platforms that make up the ``perceived'' application platform are handled using the Distributed Systems Network Services APIs. Network services for access between ``perceived'' application platforms will use the Network Services EEI between the platforms. 3.3 POSIX Open System Environment Services This guide defines a uniform set of standard services provided to users of application platforms in support of POSIX objectives of application portability and system interoperability. These services are available to users across specified interfaces keyed to the POSIX reference model defined in 3.2. The POSIX OSE services are divided into categories described by the d clauses in Section 4. Each category begins by defining a more detailed and specialized version of the OSE reference model (see 3.2) to provide context for service specification. Services and associated standards are d then defined for each category. Finally, POSIX OSE Cross-Category d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 28 3 POSIX Open System Environment ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _________________________________________________________________________ _________________________________________________________________________ Figure 3-5 - Distributed System Environment Model Services affecting each category are discussed. The service descriptions for each category are intended to be complete and not merely representative. Further refinement through successive releases of this document will lead to a complete specification. 3.4 POSIX Open System Environment Standards The identification of a complete, consistent suite of standards for the POSIX OSE will, by necessity, draw from many forums. One of the criteria for judging completeness is the satisfaction of the full range of services required by the application platform user. The factors used to select standards will be described followed by the selection precedence. Note that while the services are stated with a clear partitioning in mind, the standards reflect the current partitioning. These standards were created within disparate organizations and projects, which were in many cases carried out in isolation from the others. As a result, mapping of services to standards is not a simple relationship. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3.4 POSIX Open System Environment Standards 29 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 3.4.1 Factors in Standards Selection The selection criteria for standards to be included in the POSIX OSE are based upon four concepts. Those concepts are Those concepts are openness, Stage of Completion, stability, Geographic Scope of Consensus, Functional Scope Addressed within this guide, Consistency with POSIX.1 {2}, and Availability for Unencumbered Implementation. (1) Openness Standards development organizations can differ from one another by virtue of their ``openness.'' That is, some standards development bodies utilize an open forum for the development of standards while other bodies use a closed forum. The result is a varying degree of consensus in the technical content of the standards across development bodies. As a general rule, standards developed by accredited standards development organizations (all of which use an open forum) are preferred over those standards developed by bodies using a closed forum. (2) Stage of Completion Another factor involved in the selection of standards for inclusion in the POSIX OSE is ``stage of completion.'' That is, there is a standards development life cycle process whose effects need to be taken into account. Most standards follow a sequence from approved development, through draft, and on to approved standard. As a general rule, where choices were made among standards, the more complete standards were favored. (3) Stability A third factor in determining which standards are included in the POSIX OSE is stability. This factor refers to anticipated change in the standard over time. This change may expand or contract the technical coverage of the standard. As a general rule the more stable standards are preferred over those subject to change. (4) Geographic Scope of Consensus There are differences among standards development bodies with respect to the scope of their geographic consensus. Some among those bodies are formal standards bodies (i.e., accredited as Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 30 3 POSIX Open System Environment ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 standards developers by a recognized body). It is typical for those bodies to be authorized to develop standards for a particular technical topic and have their standards applicable to some defined geographic area. Formal standards development bodies are typically empowered to develop standards for either international, regional or national standards coverage. The general rule applied in the selection of standards for inclusion in the POSIX Open System Environment is to select standards developed by those bodies that have the greatest scope of coverage. This results in a precedence for standards selection of international, followed by regional, followed by national body developed standards. (5) Functional Scope Addressed within this guide A specification is listed only if it addresses some service requirement listed in this guide. Standards and/or specifications listed are not, however, limited to one per set of services. (6) Consistency with POSIX.1 {2} Standards listed in this guide are suitable for inclusion in a profile with POSIX.1 {2}, and do not contradict that standard in any way. (7) Availability for Unencumbered Implementation A standard or specification is listed only if it is available for implementation to the specification and distribution of that implementation is unencumbered. The specification qualifies for inclusion in the guide even if the document itself is a salable item. 3.4.2 Selection Precedence The list below shows the precedence of standards and specifications as used for inclusion in the POSIX OSE. The order from top to bottom is from most to least preferred. (1) Approved standards developed by accredited international bodies (2) Approved standards developed by accredited regional bodies (3) Approved standards developed by accredited national bodies Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3.4 POSIX Open System Environment Standards 31 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS (4) Draft standards developed by accredited international bodies (5) Draft standards developed by accredited regional bodies (6) Draft standards developed by accredited national bodies. (7) Recognized de facto standards and specifications developed by nonaccredited bodies using an open forum (8) Approved standards and specifications developed by nonaccredited international standards bodies using a closed forum (9) Approved standards and specifications developed by nonaccredited national standards bodies using a closed forum. Standards projects for which there is no draft or approved standard are never selected for inclusion in the POSIX OSE. ``Equivalent'' or ``derived'' standards lower in the precedence hierarchy are correlated in an annex. _F_E_S: _D_o _w_e _s_t_i_l_l _w_a_n_t _t_o _d_o _t_h_i_s? Only the highest precedence specification is listed or discussed in the main text. This guide only cites government and de facto standards and specifications in discussion of gaps in available standards. 3.5 POSIX Open System Environment Profiles The results of Open System specification projects are collected into an expanding set of ``Base Standards,'' addressing a growing subset of functional requirements. Profile projects then select among these base standards to create a tailored, consistent set of standards addressing a more specific type (or instance) of system or set of application software. Profiles satisfy the requirements of application ``domains'' such as office or industrial automation, transaction processing, or realtime control systems. This framework provides a way to characterize the functionality of profile activities. The current OSI profiles tend to focus strictly on d the communications EEI. Other profiles might focus on a single component d or span multiple interface types. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 32 3 POSIX Open System Environment ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 3.6 Application Platform Implementation Considerations _H_L_J: _A_l_l _i_n_s_t_a_n_c_e_s _o_f ``_S_y_s_t_e_m _I_n_t_e_g_r_a_t_i_o_n _I_n_t_e_r_f_a_c_e'' _i_n _t_h_i_s _c_l_a_u_s_e d _h_a_v_e _b_e_e_n _c_h_a_n_g_e_d _t_o ``_S_y_s_t_e_m _I_n_t_e_r_n_a_l _I_n_t_e_r_f_a_c_e'' _w_i_t_h_o_u_t _f_u_r_t_h_e_r _d_i_f_f d _m_a_r_k_s. d Profile writers need to be aware that in an open system environment, the application platform can be decomposed into independently procurable components. While standards are interface specifications, and as such are independent of implementation, there are aspects of platform implementation or construction that may affect the specification of standards, and that profile writers may want to address. For each case, the portion of the application platform that implements any particular independently procurable service is described as the service component. Figure 3-6 shows an application platform made up of several service components. If components interact, the specification of the interface between service components within the application platform may be standardized or nonstandard (including proprietary). _________________________________________________________________________ _________________________________________________________________________ Figure 3-6 - Service Components and Interfaces An intercomponent interface is labeled in Figure 3-6 as ``System Internal Interface'' because it may be used to assemble an application platform from multiple components. Figure 3-6 shows how a System Internal Interface is shown in the reference model. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3.6 Application Platform Implementation Considerations 33 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS A standards-based SII between the application platform service components addresses portability and interoperability of the application platform service components, not portability and interoperability of application software and systems. Development of an SII would also require a consensus to emerge on the ``best'' design and implementation of system software/hardware. Very little consensus has developed on the partitioning of the platform into components and consequent allocation of function to each. In fact, this aspect of system design has been in a constant and accelerating state of innovation for decades. One of the major objectives of the API is to provide a more stable interface that decouples application software from the constantly changing platform. This enables the migration of application software to platforms based on constantly upgraded technology. (See 3.1 ``Accommodation of New Information System Technology''.) The relationship and services exchanged among the components may be quite complex and varied in different implementations. This complexity and variety would, of necessity, be reflected in an SII. It would not, however, be visible to the application software at the API, since one of the major objectives of the API is to hide this complexity. (See 3.1 ``Implementation Transparency''.) Since SII specifications - do not affect application portability and interoperability, and - do not affect specification of the API and EEI, and - are primarily driven by specific implementations of the application platform, SII specification is beyond the scope of this guide. d Specification of SII in this guide would represent an unnecessary constraint on the implementation of the application platform, and are unnecessary for the specification of the API and EEI. There are a number of ways which the Application Platform can be divided into separate service components. The main decomposition methods are division, layering, and redirection. These methods are indistinguishable to the application software and external entities, in that they all interface to the application platform via the API and EEI, respectively. They assume a starting base application platform, which provides a subset of the required services. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 34 3 POSIX Open System Environment ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 3.6.1 Subdivision In this commonly used method, the application platform is simply subdivided into a base and one or more service components. See Figure 3-7. _________________________________________________________________________ _________________________________________________________________________ Figure 3-7 - Application Platform Implementation - Subdivision One possible implementation of this is to link the appropriate service modules directly into the system kernel. The internal interfaces used in this method are normally proprietary, and hence normally imply that both components will come from the same vendor. In this case the Application Platform and the Application Platform Base are the same entity. 3.6.2 Layering In layering, the service is interposed as a layer between the application software and the base application platform. See Figure 3-8. This is the most common method of supplying a service component that is independent of the base. One possible implementation is to provide the service component as a set of library routines. Whether the interface between the service layer and the base application platform conforms to any standards affects the portability of the service component. Note that specifying a standard API for this interface guarantees only that this component will be portable at the source level. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3.6 Application Platform Implementation Considerations 35 P1003.0/D13 _________________________________________________________________________ _________________________________________________________________________ Figure 3-8 - Application Platform Decomposition II - Layering _________________________________________________________________________ _________________________________________________________________________ Figure 3-9 - Application Platform Decomposition III - Redirection 3.6.3 Redirection Redirection allows a service component to ask the base application platform to redirect all requests for that type of service to the service component. See Figure 3-9. Possible examples of such services are device drivers, network protocol handlers, and database engines. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 36 3 POSIX Open System Environment ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 In actual implementation, the service component may or may not be a separate process. Possible implementations are: dynamically loadable kernel modules, library routines layered over IPC, and lightweight kernel processes. Note that there are three interfaces. The application software normally sees a complete, standard API to the base. The service component has two interfaces--one to effect the redirection, and one to provide base services to the service application software entity. Considerations for portability discussed under Layering also apply here. Note also that no POSIX standardization activity currently exists for the redirection interface. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3.6 Application Platform Implementation Considerations 37 P1003.0/D13 Section 4: POSIX Open System Environment Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _F_r_i_t_z _S_c_h_u_l_z This section describes the services required in support of the objectives identified in this guide. The services are grouped in major categories defined in Section 3, with more detailed breakdowns within each category as appropriate. These categories are: Fundamental System Services 4.1 Language Services 4.2 System Services Communications Services 4.3 Network Services Information Services 4.4 Database Services 4.5 Data Interchange Services Human-Computer Interaction Services 4.6 Windowing System Services d 4.7 Graphic Services 4.8 Character-Based User Interface Services 4.9 User Command Interface Services Domain Services 4.10 Transaction Processing Services d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4 POSIX Open System Environment Services 39 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.11 Software Development Environment Services Criteria used to partition services are outlined in 3.2, and discussed at the beginning of each clause. The discussion for each of the service category subclauses follows the same outline, and is as follows: 4._n.1 4._n.2 Overview and Rationale, Scope This text introduces the scope of this service category, and the criteria used to identify the services within it. 4._n.3 Reference Model This subclause builds on the model of clause 3.2 and gives additional detail related to the interfaces and services discussed there. An optional subclause may discuss implementation considerations, similar to the discussion of 3.6. 4._n.4 Service Requirements This text provides the definition of service requirements within the scope described in 4._n.2. 4._n.5 Standards, Specifications, and Gaps A table lists the standards and specifications available to meet the service requirements listed in 4._n.4. This is followed by a brief discussion of services for which standards are not available. 4._n.5.1 Current Standards The following subclauses cite existing specifications that have been approved as standards by accredited standards bodies, in the order of precedence identified in 3.4.2. When d service requirements are satisfied at a higher precedence d level, specifications at a lower level are not listed. d d 4._n.5.2 Emerging Standards The following subclauses list specifications and/or activities that address the functional areas within the 4._n section, but which have not yet been completed. Where a d group or activity is cited, the charter of the group may address the functionality, but it is possible that a draft may not be available. Only those services not currently Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 40 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 addressed by existing standards are to be discussed in this subclause. It is expected that documents will migrate from 4._n.5.2 to 4._n.5.1 as they complete the consensus process. d 4._n.5.3 Gaps in Available Standards This subclause identifies those service requirements that have not been satisfied by existing or emerging standards. If all service requirements in this category have been met by existing or emerging standards, this subclause will be empty. Text in this subclause will be minimal. 4._n.5.3.1 Public Specifications This subclause lists any specification outside of the formal standards community that is available to anyone (e.g., no membership required) for implementation and distribution (including sale) without restriction, including all government and de facto standards. 4._n.5.3.2 Unsatisfied Service Requirements This subclause lists the services for which no specification has been cited in this guide. Products may be cited here to illustrate capabilities that are not addressed by standards. 4._n.6 POSIX OSE Cross-Category Services This subclause contains any discussion of the Cross-Category Services in Section 5 that is specific to subclause 4._n. 4._n.7 Related Standards This subclause is optional and may identify interdependencies among standards that should be taken into account when selecting among them. 4._n.8 Open Issues This subclause is optional and may identify issues under discussion in the open systems community. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4 POSIX Open System Environment Services 41 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 42 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.1 Language Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _D_o_n _F_o_l_l_a_n_d _4._1._1 Overview and Rationale While a consistent interface to the operating system is essential for applications portability, the application will have been developed using language and system development tools that, in turn, require to be supported by standards to achieve source code portability. Those responsible for system or software development will wish to write programs in code supported by an international standard and compile the code using a compiler that has a certificate of conformance issued by an accredited test center. Noncompliant extensions must be avoided if applications portability is to be maintained. Compilers should identify nonstandard-compliant code. The languages that have been identified in this document are those seen to be in most popular use today for software development. The POSIX.2 d shell command language is discussed in 4.9. The standards identified are d the most widely recognized today, with significant use in the Information Technology industry on a broad range of processors, or where a large installed base of a particular version is known to exist. 4.1.2 Scope The services described in this clause cover the most widely used third- generation computer languages in use today for the development of applications; i.e., the languages used to write application programs. Fourth-generation languages are not currently addressed in this guide. In order for a program to address an API to the services described in other clauses of this guide, an appropriate language binding to that interface is required. References to those bindings will be found in the clause describing the relevant service. 4.1.3 Reference Model This subclause identifies the entities and interfaces supporting language services. The reference model based on the reference model in Figure 3-1 is illustrated in Figure 4-1, but because the language services directly support the binding of the applications to the API, there is no EEI. However, the EEI is shown in Figure 4-1 for consistency. At the simplistic level, the programmer developing an application that requires only basic operating system services will use a compiler that Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.1 Language Services 43 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 4-1 - Language Service Reference Model meets both the fundamental language standard (e.g., ISO 1989: 1985 for COBOL, ISO 1359: 1990 for Fortran) and the binding established for the d relevant system calls in POSIX.1 {2}. As identified in 4.10, an application program may also require database services that will be provided by the Database Manager API. The database vendor will offer an API to meet the requirements for the popular programming languages. In a POSIX Open System Environment the intention is that support is provided for all languages identified in 4.1.4. 4.1.4 Service Requirements Programming language services provide the basic syntax and semantic definition for use by a software developer to describe the desired application software function. While most clauses in this guide provide a comprehensive list of services, in the case of languages many services are a unique function of the language specification. Rather than extend the size of this guide, the detail is more appropriately found in the relevant language manuals and supporting standards. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 44 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.1.4.1 Application Program Services Programmers require the ability to compile a program in the language of d their choice. The selection of a particular programming language for the d development of an application may depend on a variety of factors, including the capability to provide some of the functions listed here: - Arithmetic operation - Code structure - Data definition - Data representation - Error handling - I/O operations - Mathematical functions - Program control logic The programming languages identified in this clause are: Ada APL BASIC C C++ COBOL Common LISP FORTRAN Pascal PL/1 Prolog As well as making reference to the relevant language standard, where a d programmer requires to call other services, e.g., seeks access to d graphics kernel system, it will be necessary to refer to the relevant d language binding to those services. Language bindings are identified in d the Standards subclause, 4._n.10, of each service clause in Chapter 4. d 4.1.4.1.1 Ada Ada is a procedural language based on the Pascal programming language. It is capable of processing both numerical and textual data, and has the key attributes of: Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.1 Language Services 45 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Strong data typing - Data abstraction - Structured constructs - Multitasking - Concurrent processing Although Ada was developed initially for military purposes, it is considered suitable for a variety of business and industrial applications. 4.1.4.1.2 APL APL is a language and interactive programming environment oriented around multidimensional arrays of characters and numbers. It uses an extremely compact notation based on powerful primitive functions and function- combining operators. Revisions to the language are in preparation to permit single array elements to contain arrays. 4.1.4.1.3 BASIC BASIC is an interactive and procedural language with some similarity to FORTRAN. It is readily learned by non-computer-literate individuals. Commonly used for educational purposes, it has also been adopted in a variety of business and commercial applications running on small business systems. BASIC offers: - Conversational statements - Free style input - Segmentation of complex statements - Six significant digits of accuracy - Mathematical functions 4.1.4.1.4 C C is a general purpose procedural language that was developed for the UNIX operating system. It offers the control and data structure of a high-level language and the efficiency of primitive operators that have made it very suitable for system programming. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 46 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.1.4.1.5 C++ C++ has evolved as a superset of C and may be viewed as a procedural language, while at the same time offering the capability for object- oriented programming. The concept of an object-oriented language is to define data objects that include sets of operations to manipulate the data, and so direct these objects to apply the necessary operations which comprise the application. 4.1.4.1.6 COBOL COBOL is a procedural language designed originally to meet the needs of business. It permits use of natural words and phrases, enabling the language to be adopted by non-technical writers with a basic appreciation of information processing. The language offers file organization features, variable data length, input/output procedures, and report generation. 4.1.4.1.7 Common LISP LISP is an interactive nonprocedural language. The basic entity is the symbolic expression which is either an atomic symbol or a list structure. A list is a set of items in a specific order. Lists can be variable length and dynamically adjusted; the items can be of different type. 4.1.4.1.8 FORTRAN Though originally developed for processing scientific problems the language is widely used in commercial and educational applications. It is a procedural language whose grammar, symbols, rules, and syntax are simple mathematical and English-language conventions. Its focus is on numerical computation, using simple concise statements, operating on small amounts of input data and little text. 4.1.4.1.9 Pascal This is a procedural language that is particularly effective in structured programming and was designed to help programmers in rapid error detection. It is highly efficient, handling both numerical and textual data. It is considered very suitable for small system applications such as typesetting, editorial work, computer aided design d (CAD), and manufacturing processes. d 4.1.4.1.10 PL/1 This is a procedural language introduced to offer in one language the strengths of both COBOL and FORTRAN; i.e., serving both the business and scientific communities. It has the FORTRAN strength of simple statements, coupled with the ability, as in COBOL, to manipulate data and Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.1 Language Services 47 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS organize files. It is block structured, facilitating good programming techniques. 4.1.4.1.11 Prolog This language, like LISP, is nonprocedural and has an emphasis on description rather than on action. It is described as pattern-directed role-based programming using definitions of conditions established within the program to satisfy a query. It is of particular value in applications of artificial intelligence, for constructing expert or knowledge-based systems. 4.1.4.2 External Environment Interface Services Not applicable. 4.1.4.3 Interapplication Software Entity Services Not applicable. 4.1.4.4 Language Resource Management Services Not applicable. 4.1.5 Standards, Specifications, and Gaps 4.1.5.1 Current Standards in the POSIX OSE Most of the languages referenced in this clause are supported by International Standards; Table 4-1 provides a summary. 4.1.5.1.1 International Standards _A_d_a ISO 8652: 1987 is the current version of the international standard for Ada, which was an endorsement of the ANSI standard 1815A-1983. _A_P_L ISO 8485 is the current version of the international standard for APL. _B_A_S_I_C ISO 6373: 1984 is the current version of the international standard for minimal BASIC. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 48 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Table 4-1 - Language Standards Activities __________________________________________________________________________________________________________________________________________________ Service Specification Subclause ________________________________________ Ada ISO 8652 4.1.5.1.1 APL ISO 8485 4.1.5.1.1 BASIC ISO 6373 4.1.5.1.1 C ISO/IEC 9899 4.1.5.1.1 C++ n/a 4.1.5.3.2 COBOL ISO 1989 4.1.5.1.1 Common LISP n/a 4.1.5.3.2 FORTRAN ISO 1539 4.1.5.1.1 Pascal ISO 7185 4.1.5.1.1 PL/1 ISO 6160 4.1.5.1.1 ISO 6522 4.1.5.1.1 PROLOG n/a 4.1.5.3.2 __________________________________________________________________________________________________________________________________________________ _C ISO/IEC 9899 is the current version of the international standard for the C language. _C_O_B_O_L ISO 1989: 1985 is the latest version of the international standard for COBOL, which was an endorsement of the ANSI standard X3.23-1985. An Addendum is in process at present entitled ``Intrinsic function module.'' _F_o_r_t_r_a_n d ISO 1539: 1990 is the latest revision of the international standard for d Fortran. d _P_a_s_c_a_l ISO 7185: 1983 is the current version of the international standard for Pascal, which was an endorsement of the British standard BS 6192-1982. _P_L_/_1 ISO 6160: 1979 is the current version of the international standard for PL/1, which was an endorsement of the ANSI standard X3.53-1976. ISO 6522: 1985 is the current version of the international standard for a General Purpose subset of PL/1, which is an endorsement of ANSI standard X3.74-1981. A revision of this standard is at Draft IS stage. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.1 Language Services 49 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.1.5.1.2 Regional Standards 4.1.5.1.3 National Standards 4.1.5.2 Emerging Standards in the POSIX OSE 4.1.5.2.1 International Standards _B_A_S_I_C DP 10279 is a proposal for Full BASIC. _P_a_s_c_a_l DIS 10206 is a draft international standard for extended Pascal. 4.1.5.2.2 Regional Standards 4.1.5.2.3 National Standards 4.1.5.3 Gaps in Available Standards 4.1.5.3.1 Standards and Specifications outside the POSIX OSE 4.1.5.3.2 Unsatisfied Service Requirements There is a requirement for standardization of the following languages: C++ LISP Prolog 4.1.6 OSE Cross-Category Services Not applicable. d 4.1.7 Related Standards Many of the services within the POSIX OSE require APIs with bindings to languages identified in this clause; e.g., Graphics, Database. Reference to the particular language binding standard is to be found in the relevant service clause. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 50 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.1.8 Open Issues While there are occasional calls for 4GL standards, there has been little effort applied so far. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.1 Language Services 51 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 52 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.2 System Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _P_a_t_r_i_c_i_a _O_b_e_r_n_d_o_r_f _d 4.2.1 Overview and Rationale This clause describes the system services component of the application platform. It presents a reference model for this component and describes the services provided to application software. Those services are those usually considered as part of an operating system or executive and also those services that may be provided by system level entities such as spoolers and device drivers. Standards, current and emerging, that specify the interface to those system services are also described. System services are a key component of the application platform and represent the focus of the IEEE effort to produce POSIX base standards. A common set of system services provides support for the portability and the interoperability of application software. While other common services can aid application reuse, system services are those that are common to the largest number of applications. 4.2.2 Scope System services cover those features that users have come to expect from operating systems or executives. They cover the areas of process management, file management, input/output, memory management, and print spoolers. Because there is a wide variety of platform users, ranging from large general purpose time-shared systems to small time-critical, special-purpose systems, services such as timers and clocks, event management, logical device drivers, and system initialization/reinitialization are included. Services related to distributed systems are also discussed, since application software sees these capabilities through the platform. d 4.2.3 POSIX OSE System Services Reference Model d 4.2.3.1 Reference Model d This subclause identifies the entities and interfaces specific to the system services of the POSIX OSE. The reference model presented here is consistent with and expands upon the reference model of Section 3. It provides the context for the discussion of System Services in this clause. The basis System Services model is shown in Figure 4-2. d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 53 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 4-2 - System Services Reference Model This clause describes the system services portion of the application platform as viewed by a software developer (not necessarily the viewpoint of the end user). This view corresponds to the program design level of abstraction. The system services API provides the interface between the application software and the system services from the source code point of view. The API defines the program designer's means of accessing the functions, objects, and services of the system. d In order for the platform to protect system integrity and ensure system database consistency, application software competing for system resources must access all system resources via system service requests. The formal definition of these requests (or system calls) defines the system services portion of the API. All of the system services may be available locally or remotely. Some of the system services may be performed remotely if the system is a distributed system with multiple processor nodes. Such distribution is not reflected in Figure 4-2 because it is transparent to users of the System Services. The platform's device drivers and other software entities are seen as d being available to an application program via invocation of the system d services. Local devices include sensors, effectors, and connections to d independent computing systems. The local devices themselves are a part of the external entities element of the system services reference model. The interfaces used by the application software are the logical device Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 54 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 interfaces and are part of the system services. It should be noted that, even though the device drivers are represented within the system services portion of the application platform and the devices themselves are represented within the external entities, there is no unique system service interface illustrated at the EEI in Figure 3-3. This is not an oversight; it is due to the belief that such interfaces are not within the scope of this guide. 4.2.3.2 Implementation Aspects Although this reference model for system services appears to make no distinction, there are some very important real-world considerations for system services brought on by the essential differences between realtime and nonrealtime systems. One of the best ways to understand these differences is to examine the performance requirements for system services. Several metrics are associated with the performance of system services. _S_e_r_v_i_c_e _R_e_q_u_e_s_t _L_a_t_e_n_c_y is defined as the interval between (a) context switch from an application context to the operating system context and (b) the reverse context switch from the operating system context to the application context for a given service request. Note that for asynchronous services, the service request may not have been satisfied within the latency interval. In error situations, return of an error status or dispatch of the error handler shall be the terminating event for the measurement. _S_e_r_v_i_c_e _D_e_l_i_v_e_r_y _L_a_t_e_n_c_y is the interval between (a) context switch from an application context to the operating system context and (b) satisfaction of the service request. In some contexts, the most important metric is the wall clock time from the point that an external, high-priority event occurs to the time the application actually responds to the event. However, response time exclusively need not always provide an appropriate metric. It is also necessary to take into account what must be done within that time. For example, one system with a one-second response time may be high-powered enough to handle and coordinate many tasks within that time. Another system with a faster response time might not be handling the same amount of processing. _R_e_a_l_t_i_m_e__M_e_t_r_i_c_s Since a realtime system is defined as one that performs its functions within a bounded response time, the evaluation of a realtime system has two distinct requirements. First, it must have the right functions. Second, each function must be able to guarantee a certain level of Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 55 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS performance. Two major metrics that are concerned with priority interrupts and scheduling are interrupt latency and context switch time. These are the metrics most commonly associated with realtime systems. Interrupt latency is the longest time interval possible for an interrupt to be received and acknowledged and a process scheduled to service it (see Figure 4-3). The context switching time is the time required to switch from the task that is scheduled to service the interrupt. It is determined by the time the operating system takes to store the state (context) of the current process so it can continue processing its previous task after servicing the interrupt. 4.2.4 Service Requirements This subclause identifies those processor-oriented system services required to support application portability and system interoperability. Subclause 4.2.4.1 describes those system services directly available to an application program via the System Services API. Other processor- oriented services are described in 4.2.4.4. Subclause 4.2.5 identifies the applicable standards. This subclause describes the major groups of system services that an application may require of a platform. Not all of these services require a programming interface; therefore, services are described as either explicit or implicit services. Explicit services are those that can be accessed from an application program (via the API) and generally are only provided when requested. Implicit services, on the other hand, are services that the platform provides without a direct request. An example of an implicit service is the prevention of one program from writing over the memory of another. An example of an explicit service is a call to a system service routine to output the contents of a block of memory to some device. 4.2.4.1 Application Program Interface Services This subclause describes the major categories of system services available at the System Services API. These services include: - Process Management Services - Task Management Services Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 56 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _________________________________________________________________________ _________________________________________________________________________ Figure 4-3 - Realtime Metrics Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 57 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Environment Services - Node Internal Communication and Synchronization Services - Generalized Input/Output Services - File Oriented Services - Event, Error, and Exception Management Services - Time Services - Memory Management Services - Logical Naming Services - System Initialization, Reinitialization, and Shutdown Services 4.2.4.1.1 Process Management Services These services relate to the creation, management, and deletion of processes executing within the scope of an operating system. These processes are distinguished from ``tasks'' via the following characteristics: - They have a single thread of execution per address space. - There is substantial overhead for context switches. - Specific attributes are associated only with processes. In this context, ``management'' consists of those services that affect the execution of a process: - Stop and restart execution of a process (e.g., suspend, resume) - Modify processor allocation to a process (e.g., priority, timeslice) - Modify scheduling of the process based on timer (or other) events - Protect the process from interruption during critical periods - Create a process and make it ready for execution - Destroy a process and recover its resources - Evaluate a reference to a process Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 58 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Evaluate a connection to a process, where a connection is a logical communication path between any two processes These services schedule or arbitrate the usage of various resources of the OS, particularly the central processing unit (CPU). The scheduling d services must be able to queue up requests to use a particular resource. This situation is made more complicated by the common need to schedule processes to run cyclically at a fixed period. When a resource becomes idle, the scheduler must select one of the ``requesters'' of the resource to grant use of the resource. These services are listed separately rather than under the services that use scheduling to emphasize that there should be uniformity and consistency of scheduling across the range of resources. Typically, there are at least two types of scheduling occurring in an operating system: short-term and long-term. Long-term schedulers determine which possible requesters at a given time may actually request a resource. The short-term scheduler selects from among the active ``requesters'' that currently have need of the resource and allocates the resource to the selected ``requester.'' For example, if the requesters are processes and the resource is the CPU, the long-term scheduler manages the movement of processes from inactive (waiting in batch queues or in hibernation) to active (in wait or execute). The short-term scheduler, on the other hand, would determine which process should execute next on the CPU. Hybrid services between the two may also be available in the operating system. When a request for a resource is submitted to the operating system (at some local operating system node), it is not always serviced at that local node. The most advantageous way to service the request may result in part or all of the work being performed at a different processor node. Several reasons may cause this to occur, including load balancing, resource availability, computation speedup, hardware preference, and software preference. These services may hide from the application the fact that the functionality was being performed at a different node. This has the advantage that the code needs to know little about the system on which it is running. Alternately, the services may allow the user to specify directly on which logical resource the function should be executed. The priority scheduling of resources allows the requester to have associated with it its importance to use the service. More complex schemes also have a criticalness of the request that is used for graceful degradation purposes. The scheduler(s) will use the priority information to arbitrate resource requests and to queue requests in the specific order. A priority scheduler may need to support multilevel queues to support proper execution. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 59 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Preemptive schedulers will deallocate a resource from a requester when certain events occur. Usually this is when a requester of a higher priority or importance requests the resource or a specified time limit for the resource has expired. 4.2.4.1.2 Task Management Services These services relate to the creation, management, and deletion of tasks executing within the scope of an operating system. These tasks are distinguished from ``processes'' via the following characteristics: - There may be multiple threads of execution per address space. - There is low overhead for context switches between threads located in the same address space. In this context, ``management'' consists of those services that affect the execution of a task: - Stop and restart execution of a task (e.g., suspend, resume). - Modify processor allocation to a task (e.g., priority, timeslice). - Modify scheduling of the task based on timer (or other) events. - Protect the task from interruption during critical periods. - Create a task and make it ready for execution. - Destroy a task. - Evaluate a reference to a task. - Evaluate a connection to a task, where a connection is a logical communication path between any two tasks. 4.2.4.1.3 Environment Services These services provide an application access to a variety of information relating to the operating system environment in which the application is executing. The specific characteristics are: - Process-specific attributes (process identification, priority, stack size, scheduling attributes, status, memory allocation). - Task-specific attributes (task identification, priority, scheduling attributes, status, memory allocation). Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 60 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Processor-specific attributes (node identification, electronic nameplate information). - User-specific attributes (user identification and terminal ID, user interaction profile). - Environment variables (command-line arguments, menu selections). - Current time and date 4.2.4.1.4 Node Internal Communication and Synchronization Services One or more applications and application subcomponents may run on a d processor within an application platform simultaneously. The d applications run as independent software entities and communicate among d themselves via a variety of mechanisms provided or managed by the system d services (see Figure 3-2). An important class of system services relates d to the coordination and synchronization of these software entities. In d traditional systems, entities execute on a single hardware processor. d However, it is becoming common to have multiple processors and networked d processors that place more requirements on the system services to provide d coordination and synchronization among the many truly concurrent software d entities. d When a platform has several software entities executing concurrently, the d applications need system services so that the entities can be coordinated d and synchronized with each other. With respect to applications written d using concurrency, there are two levels of concurrency that are usually d seen by the application developer. The first level of concurrency, task d level concurrency, is seen when the application is split into multiple d subcomponents (tasks) that share access to the data and subprograms of d the application. Concurrency services at this level concern the relative d priorities and scheduling of tasks within a single application program d and their communication with each other. At the second level of d concurrency, application level concurrency, a unit is a single d application including all its subcomponents. Concurrency services at d this level concern the relative importance of the individual applications d competing for and sharing system resources. d These services are used to communicate among processes, among tasks, and among processes and tasks residing on the same node. The methods outlined do not include the network specific services described in 4.3, but are limited to methods open to entities executing within the scope of a single operating system. Both synchronous and asynchronous services are defined. The specific services are: - Create, delete, open, close, read, and write shared memory. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 61 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Create, delete, read, and write event flags. - Create, delete, set, and wait on semaphores. - Create/send and receive signals. - Create, delete, open, close, send to, get from, and control message queues. - Create, delete, send, and receive streams. 4.2.4.1.5 Generalized Input/Output Services These services are used by an application to perform generalized device I/O operations. These operations include synchronous and asynchronous operations for device and class specific functions. Specifically, these form the services needed to implement or include logical device drivers in a system. These services are device initialization, device attachment, asynchronous operation, and error notification. In addition, they include those services that are used to directly access specific device capabilities, particularly those services often referred to as ``raw I/O.'' 4.2.4.1.6 File Oriented Services Mass storage in the form of hierarchy of directories, subdirectories and files will be available to an application executing within the application platform. The following paragraphs describe the services available for creating, accessing, managing, and deleting these entities with mass storage. Both synchronous and asynchronous services are defined. _N_a_m_i_n_g__a_n_d__D_i_r_e_c_t_o_r_y__S_e_r_v_i_c_e_s These services allow the access of files and directories through logical names rather than the actual hardware device naming conventions. The services allow sharing of files at various levels. For example, the services may not allow any shared naming of files and directories between systems, or they may allow shared files by explicit naming, or they may allow shared files by implicit naming. The directory services present a view or views of the directory structure to the application or target system operator. _F_i_l_e__M_o_d_i_f_i_c_a_t_i_o_n__P_r_i_m_i_t_i_v_e_s Primitive services for files and directories are: - Read a portion of the file. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 62 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Write to a portion of the file. - Open access to a file. - Create a new file. - Close access to a file. - Delete a file. - Copy a file. - Merge two or more files. - Append one file to another. - Split one file into two or more files. - Support read and write locks at both the record and file levels. These services may be very complex. For example, the access to read or write may be direct (by record number), sequential (one record at a time), or indexed (by a key). The services must also support a variety of file structures, including linked, segmented, contiguous, serial, and directory. _F_i_l_e__S_u_p_p_o_r_t__S_e_r_v_i_c_e_s Additional services support the physical devices on which the files and directory reside. These services include the dismounting/mounting of medium, the formatting of medium, and the partitioning of media. _R_e_a_l_t_i_m_e__F_i_l_e_s Realtime systems often need special files to ensure fast, bounded, and consistent performance in time critical situations. The need for a bounded response time for a given I/O function drives the design of these files and services. One service preallocates the complete disk space needed for a file at creation time, while another guarantees that records within files are aligned in an optimal way (such as along word boundaries). Services support the access of records within the file in ways that make response time constant or bounded, including by direct access. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 63 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.2.4.1.7 Event, Error, and Exception Management Services These services provide a common facility for the generation and communication of asynchronous events among the system and application programs. A major use of the event services is to report error conditions, but they are also used by device drivers and the platform to provide an indication of some condition to the application programs. These services are: - Event and error receipt. - Event and error distribution. - Event and error management, including user-selectable error processing alternatives (filtering, retry, ignore, accumulate occurrences). - Event logging. - Enable/disable and mask/unmask interrupts. 4.2.4.1.8 Time Services Timers may be a static or dynamic resource on the system, necessitating a variety of allocation and management strategies. These services are used by applications to perform a variety of services based on absolute and relative time. These services are: - Create a timer. - Delete a timer. - Initiate the measurement of an arbitrary specified time duration. - Receive an indication when the specified duration has elapsed. - Read the current value of a timer. - Initialize a timer with a value and count direction (i.e., increment or decrement). - Trigger a timer to begin incrementing or decrementing. - Associate with a timer some action to be taken when the specified duration has elapsed. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 64 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.2.4.1.9 Memory Management Services These services are used by application processes and tasks to request additional memory and return it to the processor for reuse. They cover the services required to fulfill the needs of both virtual and fixed memory. Specifically, there is a service for locking pages in real memory to support the needs of virtual memory systems. 4.2.4.1.10 Logical Naming Services These services allow the usage of system resources through logical names rather than the actual hardware device naming conventions. Furthermore, they allow the resources of other processor nodes to be accessed via a logical name so that no knowledge of the resource's location is needed and the resource's location may change over time. Logical names are also used by security services to hide resources from unauthorized processes by only letting authorized processes know the logical name that is needed to use the physical resource. The logical name to physical name relationship can be one to many, many to one, or many to many. Many times, one physical resource may have multiple logical names as well as one logical name representing a ``bank'' of available physical resources. These services must provide the proper resolution of names, logical and physical, in all of these cases. 4.2.4.1.11 System Initialization, Reinitialization, and Shutdown Services System initialization consists of services for a complete restarting of the software, starting up the attached hardware subsystems devices, doing subsystem and system self tests, and completely initializing the database. System reinitialization consists of services for restarting the software while using the existing database information. The software may have to be reloaded and the database may have been reestablished by a system recovery. Attached hardware subsystems may also need to be reinitialized. Reinitialization also includes a function to restart applications redistributed to other processors after a processor module failure. Within a processor, there is a service to initialize applications in a system with the existing software, but with the database reinitialized. Also within a processor, there is a service to restart the applications in a system with the existing software and database retained. Shutdown services are those required to perform planned orderly shutdown at the local and remote levels for each and all processor(s) throughout a Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 65 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS system. These services support both crisis and non-crisis situations that call for system shutdown. They make sure that the persistent store is in a consistent state, see to the clean termination of all processes, programs, devices, etc., and take care of user notification. They also provide for the running of system diagnostics. 4.2.4.2 External Environment Interface Services Data Interchange External Environment Interface Services are required by the System Services. Of particular interest are the formats, locations, and procedures for using system administration files, such as password files, system startup files, and configuration files. 4.2.4.3 Interapplication Software Entity Services This could include support for generalized network/multisession services, such as message handling between system components, global object definition specification, and intermediate language definition. 4.2.4.4 Resource Management Services These services provide general management functions across the entire platform. They consist primarily of system administration-oriented functions (i.e., management of system interfaces within the scope of the administrator, such as setting up defaults and limits.) 4.2.4.4.1 System Operator Services The system operator needs to access and control the system services in order to allow the platform to perform properly. If a system has an operator, the major functions that need to be supported are system control, reconfiguration, and status reporting. Currently, these services are usually made available to an operator through a command language interpreter, which is an application program that accesses these system services. Note that the Windowing Services provide the building blocks (menu utilities, command parsers, etc.) for building the user interface while the System Operator Services make available operating system status and control functions to appropriate application programs with the proper security level. These services support general conventions and specifications for interaction between system components. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 66 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.2.4.4.2 System Administration These services and procedures are those required to assure management and allocation of system services to system users, both local and remote. They consist primarily of those services required to establish authorized users of the system, with associated allocation of processor resources, including memory, processor time, priority, and mass storage space. These services are both static (as in the establishment of a new user identification) and dynamic (as in login/logout). 4.2.5 Standards, Specifications, and Gaps Table 4-2 - System Services Standards Activities __________________________________________________________________________________________________________________________________________________ Service Specification Subclause d _________________________________________________________________________ d Process Management ISO/IEC 9945-1 4.2.5.1.1.1 ddd Task Management ISO/IEC 9945-1 4.2.5.1.1.1 ddd Environment Services ISO/IEC 9945-1 4.2.5.1.1.1 ddd Node Internal Comm/Synch ISO/IEC 9945-1 4.2.5.1.1.1 ddd Generalized I/O ISO/IEC 9945-1 4.2.5.1.1.1 ddd OSF AES - OSC 4.2.5.3.1 ddd SVID 4.2.5.3.1 ddd File Oriented Services ISO/IEC 9945-1 4.2.5.1.1.1 ddd Event, Error, and Exception ISO/IEC 9945-1 4.2.5.1.1.1 ddd OSF AES - OSC 4.2.5.3.1 ddd SVID 4.2.5.3.1 ddd Time Services ISO/IEC 9945-1 4.2.5.1.1.1 ddd Memory Management ISO/IEC 9945-1 4.2.5.1.1.1 ddd Logical Naming ISO/IEC 9945-1 4.2.5.1.1.1 ddd System Init/Reinit/Shutdown ISO/IEC 9945-1 4.2.5.1.1.1 ddd OSF AES - OSC 4.2.5.3.1 ddd SVID 4.2.5.3.1 ddd __________________________________________________________________________________________________________________________________________________ d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 67 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.2.5.1 Current Standards in the POSIX OSE 4.2.5.1.1 International Standards 4.2.5.1.1.1 _P_o_r_t_a_b_l_e__O_p_e_r_a_t_i_n_g__S_y_s_t_e_m__I_n_t_e_r_f_a_c_e__(_P_O_S_I_X_)__P_a_r_t__1 ISO/IEC 9945-1 (IEEE Std 1003.1) is the first in a set of planned international POSIX standards. It defines services and characteristics that need to be in the platform for portable applications, as do some of the other planned standards. Another type of POSIX-related standard is bindings for those services to specific languages. The third type deals with concepts that cross between various groupings of services, such as security and distributed processing. _O_b_j_e_c_t_i_v_e_s The purpose of the ISO/IEC 9945-1 standard is to define a standard operating system interface based on the UNIX Operating System documentation to support application portability at the source level. The document is intended for systems implementors and applications software developers. In addition to ISO/IEC 9945-1, ISO is planning to publish ISO/IEC 9945-3 Conformance Test Procedures (which will be identical to IEEE 1003.3). This standard will cover conformance testing procedures for 9945-1. _F_u_n_c_t_i_o_n_a_l_i_t_y Table 4-3 outlines the contents of the current document. This document is identical in its ISO/IEC form (ISO/IEC 9945-1) and the US national standard form (IEEE Std 1003.1). Revisions are currently in progress to deal with: - A language-independent services specification - A unified data interchange format - Service interfaces for control of character cell terminals - Miscellaneous functions identified in comments on the current standard. _O_p_t_i_o_n_s__a_n_d__V_a_r_i_a_t_i_o_n_s The ISO/IEC 9945-1 standard draws heavily upon major implementations of the UNIX Operating System, including System V and the Berkeley versions. Where a specific behavior was clearly needed (e.g., signals), only a single behavior was permitted. However, there are points where functions were considered optional and others where two different behaviors were Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 68 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Table 4-3 - Functionality of POSIX.1 Standard __________________________________________________________________________________________________________________________________________________ File system organization, and file naming conventions System configuration and file system configuration characteristics Error messages and reporting mechanism (_e_r_r_n_o) Application environment information (_e_n_v_i_r_o_n) Process creation, management, and termination: _e_x_e_c(), _f_o_r_k(), _w_a_i_t() Process environment: user ID, process ID, Group ID Exception conditions and handling (signals) Timer operations File and Directory operations: FIFO files, pipes, status, open/close, read/write File protection mechanisms Record and file locking mechanism Device specific functions: Terminal controls: Processing modes: echo, baud rate, modem termination C language specific routines: _s_e_t_l_o_c_a_l_e(), nonlocal jumps User and Group database information (excluding password information) Data interchange formats (USTAR and CPIO) Also included is a rationale appendix that provides insight on the selection of various functions and features, including some guidance to developers to understand what types of variations may exist and how that can impact portability. __________________________________________________________________________________________________________________________________________________ considered acceptable. However, in many cases, a solid technical argument favoring one approach over the other was not established. In Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 69 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS this case, two behaviors (usually System V and BSD) are defined as being permitted. This is of benefit in writing portable applications, since those that can tolerate both behaviors will run on a wider range of systems. It is also a slight disadvantage in writing such applications, since it can mean handling a wider range of implementations. NOTE: In a related U.S. national standard, the United States Government Department of Commerce National Institute of Standards and Technology has adopted the ISO/IEC 9945-1 standard as a Federal Information Processing Standard (FIPS 151-1) for use in computer systems procurement. FIPS 151-1 requires options and characteristics that have not been required by ISO/IEC 9945-1, requiring implementations to function in a specific way in many of these cases. While buyers may want to make such requirements, the impact should be understood. Applications written for FIPS systems may only run on FIPS systems, whereas applications written for full ISO/IEC 9945-1 implementations will run on both FIPS systems and POSIX conforming systems that are not FIPS conforming. FIPS systems will run applications written either way. FIPS 151-1 requires all three POSIX.1 options. In addition, it eliminates several additional possible behaviors, thus narrowing the variation between conforming implementations. 4.2.5.1.2 Regional Standards None. 4.2.5.1.3 National Standards None. 4.2.5.2 Emerging Standards in the POSIX OSE 4.2.5.2.1 International Standards None. 4.2.5.2.2 Regional Standards None. 4.2.5.2.3 National Standards The IEEE P1003.4 Group is defining realtime extensions to ISO/IEC 9945-1. Draft 9 of the realtime POSIX extensions proposes standardized interfaces to the following functions: Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 70 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Response to asynchronous events - Priority interrupts and scheduling - Preemptive scheduling - Memory locking - High-performance file system (contiguous or other) - Realtime timers (with nanosecond resolution times) - Shared memory - Semaphores - Interprocess communications (message passing) - Asynchronous event notification - Synchronous input and output. The P1003.4 group is also specifying an interface to threads (P1003.4a). 4.2.5.3 Gaps in Available Standards While ISO/IEC 9945-1 and P1003.4 both represent very important work, they do not yet address all of the services indicated in 4.2.4. Areas of particular shortfall include Event, Error, and Exception Management Services, some Generalized I/O Services (particularly concerning services for device drivers), and System Initialization, Reinitialization, and Shutdown Services. In addition, Security (see 5.2) and Reliability, Adaptability, and Maintainability (Fault Tolerance; see 5.4) services are not reflected in these two base standards, and some capabilities are explicitly considered to be implementation defined. For some of the services discussed here, adequate consideration is not given to the implications of multiprocessor and distributed implementations of the services and interface provided. Finally, since these are intended to be base standards (or, in the case of P1003.4, an extension to a base standard), profiles are needed in order to select appropriate features and provide appropriate combinations with other related capabilities. 4.2.5.3.1 Public Specifications d The following are public specifications that define interfaces to d services for which no formal standards are currently available. d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 71 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _O_S_F_/_1 d The Open Software Foundation (OSF) ``Application Environment d Specification (AES)--Operating System Component'' (OSC). d Service Gaps Addressed: d - Generalized I/O d - Event, Error, and Exception d - System Init/Reinit/Shutdown d _S_V_I_D d The AT&T System V Interface Definition (SVID), Issue 3. d Service Gaps Addressed: d - Generalized I/O d - Event, Error, and Exception d - System Init/Reinit/Shutdown d 4.2.5.3.2 Unsatisfied Service Requirements There are two significant areas of the services described above for which no standards currently exist. One is the considerations implied by the use of multiprocessors to implement some or all of the services described herein. The other area is that of interfaces to logical device drivers. 4.2.5.3.3 Standards/Specifications Outside the POSIX OSE 4.2.6 OSE Cross-Category Services 4.2.6.1 Capability and Security Services These services support the ability of the system to control usage such that system integrity is protected from inadvertent or malicious misuse. These protection services provide a mechanism for the enforcement of the policies governing resource usage. Note that many of the security services are implicit services; i.e., they are provided without an explicit request to the operating system. There are two distinct classes of system access with which operating system services must be concerned: physical access and logical access. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 72 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Security services at the physical level are used to protect against security compromise, given unauthorized personnel may have physical access to system hardware. Typically, the physical access is to a terminal and/or terminal/display cables; however, physical access may also include network cables, central processing units, disk drives, or tape drives. Prevention of physical access by unauthorized personnel may require different operating system services under different circumstances. Logical access is the ability to interact with the operating system via a terminal/display. Security services at the logical level can be implemented through passwords and watchdog timers. Capability services attach operation lists that limit a process's ability to act on resource objects. This is to ensure the resources are not misused. Access to resources can be protected by services using capability lists as well as access lists, lock/key mechanisms, global tables, or through dynamic protection structure services. _P_r_e_v_e_n_t_i_o_n__o_f__U_n_a_u_t_h_o_r_i_z_e_d__A_c_c_e_s_s The system may need to be guarded from attempted access by unauthorized personnel. The point of access to the operating system that is typically of concern is through the API. Given the mode of operation (system high, multilevel, open) at which the system is operating, these services differ and have differing implications on other system services (such as reliability and naming) and system performance. _P_r_e_v_e_n_t_i_o_n__o_f__D_a_t_a__C_o_m_p_r_o_m_i_s_e These services prevent access of data by users not authorized to the data. These services may be implemented using access lists on files (and directories) and/or encryption of data or in other ways. _P_r_e_v_e_n_t_i_o_n__o_f__S_e_r_v_i_c_e__D_e_n_i_a_l These services ensure that a service request will be met by the operating system in a reasonable time if the requester is authorized to use the service. These services ensure that a bandit user or process cannot cause system malfunction by monopolizing system services or resources. _S_e_c_u_r_i_t_y__A_d_m_i_n_i_s_t_r_a_t_i_o_n This category involves services to allow the management of the security system, including the administration of permissions to personnel, data, and services as well as capability lists. In addition, it permits the administration access mechanisms (most often passwords and capability lists) and services that allow the system to switch modes of operation. The services will likely be accessed by the target system operator with Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 73 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS security responsibilities through the target system operator services. 4.2.6.2 Fault Management Many of the fault management capabilities described in 5.4 are normally the responsibility of the operating system and fall under the sorts of services described in this clause. 4.2.7 Related Standards The following emerging standards are related to the services covered in d this clause, in as much as they address at some level services either explicitly listed in or implied by the services found in 4.2.4: P1003.6 Security Interface for POSIX. P1003.12 Protocol Independent Interfaces (for networks). P1238 OSI Application Program Interfaces (initial effort is to provide at least sufficient facilities for the support of FTAM API specifications). 4.2.8 Open Issues [_P_O: _P_C_T_E _a_n_d _C_A_I_S-_A _h_a_v_e _b_e_e_n _m_o_v_e_d _h_e_r_e _l_a_r_g_e_l_y _b_e_c_a_u_s_e _i_t _i_s _n_o_t _c_l_e_a_r _w_h_a_t _t_o _d_o _w_i_t_h _t_h_e_m. _T_h_e_y _a_r_e _n_o_t _a_d_e_q_u_a_t_e_l_y _a_c_c_o_m_m_o_d_a_t_e_d _b_y _t_h_i_s _m_o_d_e_l. _T_h_e_y _a_r_e _b_o_t_h _h_y_b_r_i_d_s _o_f _o_p_e_r_a_t_i_n_g _s_y_s_t_e_m _a_n_d _d_a_t_a_b_a_s_e _m_a_n_a_g_e_m_e_n_t _s_y_s_t_e_m _c_a_p_a_b_i_l_i_t_i_e_s _t_h_a_t _s_e_e_m _t_o _b_e_l_o_n_g _e_i_t_h_e_r _e_v_e_r_y_w_h_e_r_e _o_r _n_o_w_h_e_r_e. _T_h_e_y _c_o_u_l_d _b_o_t_h _w_e_l_l _b_e _u_s_e_d _i_n _c_o_n_j_u_n_c_t_i_o_n _w_i_t_h _a _P_1_0_0_3._1 _i_m_p_l_e_m_e_n_t_a_t_i_o_n, _b_u_t _t_h_e_y _c_o_u_l_d _a_l_s_o _b_e _i_m_p_l_e_m_e_n_t_e_d _o_n _o_t_h_e_r _b_a_s_e _o_p_e_r_a_t_i_n_g _s_y_s_t_e_m_s, _o_r _i_m_p_l_e_m_e_n_t_a_t_i_o_n_s _c_o_u_l_d _e_v_e_n _e_x_p_a_n_d _t_h_e_i_r _c_a_p_a_b_i_l_i_t_i_e_s _t_o _p_r_o_v_i_d_e _f_u_l_l _o_p_e_r_a_t_i_n_g _s_y_s_t_e_m_s. _P_1_0_0_3._0 _m_u_s_t _d_e_c_i_d_e _w_h_a_t _t_o _d_o _w_i_t_h _t_h_e_m.] _P_C_T_E An effort by the European Computer Manufacturers Association (ECMA) has resulted in the definition by Technical Committee 33 of the Basis for the Portable Common Tools Environment (PCTE). This is now an ECMA standard and is referred to as Standard ECMA-149. _C_A_I_S_-_A MIL-STD-1838A (CAIS-A) was developed by the US Department of Defense to provide a common foundation for Ada Programming Support Environments. Similar in nature to PCTE (see above), it too covers many of the system services covered by 4.2.4. In addition, it provides data management Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 74 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 services such as those discussed in 4.4 and data interchange services (specifically, a Common External Form) similar to those discussed in 4.5. d _X_/_O_p_e_n [_P_O: _T_h_e _f_o_l_l_o_w_i_n_g _t_e_x_t _o_n _X_P_G _w_a_s _g_i_v_e_n _t_o _m_e _a_t _t_h_e _l_a_s_t _m_e_e_t_i_n_g. _H_o_w_e_v_e_r, _I _c_a_n_n_o_t _t_e_l_l _f_r_o_m _t_h_e _t_e_x_t _w_h_e_t_h_e_r _X_P_G _i_s _m_o_r_e _l_i_k_e _t_h_i_s _g_u_i_d_e _o_r _m_o_r_e _l_i_k_e _P_1_0_0_3._1. _I_f _i_t _i_s _t_h_e _f_o_r_m_e_r, _i_t _d_o_e_s _n_o_t _b_e_l_o_n_g _h_e_r_e. _I_f _i_t _i_s _t_h_e _l_a_t_t_e_r, _t_h_e_n _t_h_i_s _t_e_x_t _s_h_o_u_l_d _b_e _m_o_v_e_d _i_n_t_o _4._2._5._3._1._2.] X/Open is a consortium formed to create interface definitions and guidelines that will provide portability and interoperability to its members' products. Its primary output is the X/Open Portability Guide. The functional content of this guide is heavily based on the AT&T SVID. The current version is XPG3. [_P_O: _D_o_c_u_m_e_n_t_a_t_i_o_n _o_f _o_p_e_n _i_s_s_u_e: _w_h_a_t _a_r_e _w_e _g_o_i_n_g _t_o _d_o _w_i_t_h _F_I_P_S? _F_o_r _t_h_i_s _s_e_c_t_i_o_n, _t_h_e _d_e_c_i_s_i_o_n _w_a_s _m_a_d_e _i_n _C_h_i_c_a_g_o _t_o _s_t_i_c_k _F_I_P_S _1_5_1-_1 _i_n _t_h_e _s_e_c_t_i_o_n _o_n _9_9_4_5-_1, _b_u_t _t_h_i_s _p_r_o_v_e_d _q_u_i_t_e _a_w_k_w_a_r_d: _i_t _c_o_u_l_d_n'_t _b_e _p_l_a_c_e_d _i_n _t_h_e _r_e_g_u_l_a_r _t_e_x_t _b_e_c_a_u_s_e _i_t _d_i_d_n'_t _p_e_r_t_a_i_n _d_i_r_e_c_t_l_y _t_o _9_9_4_5-_1 (_i._e., _i_t _w_a_s _i_n_a_p_p_r_o_p_r_i_a_t_e _t_o _d_i_s_c_u_s_s _i_t _i_n _t_h_e _t_e_x_t _t_h_a_t _w_a_s _t_o _b_e _d_e_v_o_t_e_d _t_o ``_i_n_t_e_r_n_a_t_i_o_n_a_l _s_t_a_n_d_a_r_d_s''), _s_o _i_t _e_n_d_e_d _u_p _i_n _a_n _i_n_f_o_r_m_a_t_i_v_e _n_o_t_e. _I _d_o_n'_t _f_i_n_d _t_h_i_s _a _s_a_t_i_s_f_a_c_t_o_r_y _a_n_s_w_e_r. _I _t_h_i_n_k _t_h_a_t _i_t _p_r_o_p_e_r_l_y _b_e_l_o_n_g_s _u_n_d_e_r _G_o_v_e_r_n_m_e_n_t/_L_e_g_a_l _S_t_a_n_d_a_r_d_s; _t_h_e ``_g_a_p'' _i_t _f_u_l_f_i_l_l_s _i_s _o_n_e _o_f _p_r_o_f_i_l_i_n_g. _D_o_c_u_m_e_n_t_a_t_i_o_n _o_f _n_e_w _o_p_e_n _i_s_s_u_e: _W_e _a_r_e _b_e_g_i_n_n_i_n_g _t_o ``_u_s_e _o_u_r _h_e_a_d_s,'' _a_s _i_n_d_i_c_a_t_e_d _b_y _t_h_e _d_i_s_c_u_s_s_i_o_n_s _w_e _h_a_d _o_n _t_h_i_s _s_e_c_t_i_o_n _i_n _C_h_i_c_a_g_o. _I_t _i_s _e_s_s_e_n_t_i_a_l _t_h_a_t _w_e _c_a_p_t_u_r_e _t_h_e _r_a_t_i_o_n_a_l_e _f_o_r _o_u_r _d_e_c_i_s_i_o_n_s, _p_a_r_t_i_c_u_l_a_r_l_y _f_o_r _o_u_r _i_n_c_l_u_s_i_o_n_s _a_n_d _e_x_c_l_u_s_i_o_n_s. _I _h_a_v_e _t_r_i_e_d _t_o _d_o _t_h_a_t _h_e_r_e _t_o _s_o_m_e _e_x_t_e_n_t, _b_u_t _w_h_a_t _i_s _o_u_r _o_v_e_r_a_l_l _p_l_a_n _f_o_r _m_a_k_i_n_g _s_u_r_e _t_h_a_t _o_u_r _r_a_t_i_o_n_a_l_e_s _a_r_e _n_o_t _l_o_s_t?] Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 75 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 76 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.3 Network Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _C_h_a_r_l_e_s _S_e_v_e_r_a_n_c_e _d _H_L_J: _T_h_i_s _i_s _a _c_o_m_p_l_e_t_e _c_l_a_u_s_e _r_e_p_l_a_c_e_m_e_n_t _i_n _D_r_a_f_t _1_3. _I_t _i_s _n_o_t _d _f_u_r_t_h_e_r _d_i_f_f-_m_a_r_k_e_d. _d 4.3.1 Overview and Rationale This clause describes the network services component of the application platform. It also describes the services provided to application programs and users, and it describes current and emerging standards that are standardizing these services. Applications gain direct access to network services via the POSIX API. The network is just another system resource (albeit an important one) allocated among the competing processes. 4.3.2 Scope Network services include those capabilities required to allow application programs to execute on platforms that may be connected via a network. They cover the areas of file transfer, namespace and directory services, services in support of distributed environments such as remote procedure call, distributed time management, transparent file access, and data representation services. The application programs using these services should be able to access them via a high-level, context-insensitive or low-level, context-dependent interface. In the open systems and distributed systems environments, interoperability is of equal or greater importance than portability. The interfaces provided by the network services must be network protocol independent and provide for this level of interoperability. The network protocols defined for both Open Systems Interconnect (OSI) and Internet Protocol Suite (IPS) for TCP/IP should provide the basis for the open networking interfaces; however, these interfaces should not preclude the use of some subsequent networking protocol in the future. Rationale: It is important for an open system to interoperate with more systems than just other open systems. Many open systems users will have requirements to interoperate with non-ISO networks for the near future. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 77 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.3.3 POSIX OSE Network Services Reference Model _________________________________________________________________________ _________________________________________________________________________ Figure 4-4 - POSIX Networking Reference Model This subclause identifies the entities and interfaces specific to the construction of an POSIX Network Environment. This environment is consistent with and extends the environment of Section 3. As illustrated in Figure 4-4, the components of a network architecture that require standardization are divided into two groups called external environment interfaces (EEI) and application program interfaces (API). There may be some correspondence between services offered to the application across the API and the interfaces available at the EEI. It is quite possible for an API service to have no corresponding effect at the EEI. A good example of this is an interapplication communication service provided by the Network API between two applications on the same application platform. There may also be services available at the EEI provided by the Application Platform that are not available at the API such as remote login services. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 78 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.3.3.1 Network Application Program Interface (API) Services The API is concerned with the interfaces and associated standards that apply to the interface between the application and the application platform. The services available at the API are: - Directory Services - Application to Platform Services - Application to Application Communication Services - Data Representation Services Services - Distributed System Services - Network Management and Security Services Directory Services are those services associated with identifying and naming network elements. Application to Platform Services provide an application with a very high level interface to networking capabilities. This interface provides applications with capabilities such as ``mail this file to this address'' or ``transfer user xxx file from host yyy to the local host.'' These services do not require the application to be aware of any of the low level network details. Application to Application Services are the services provided by the Application Platform that allow an application to communicate with another application to exchange information. These interfaces support applications that range from having extremely simple networking requirements to the most complicated applications that must make full use of every possible network capability. Data Representation Services provide the application with network oriented data representation services to insure the application can interchange information with other entities in the proper format. Distributed system services provide the application with the ability to make use of multiple physical computer systems resources. Network management and security services allow the application to control and configure the network resources. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 79 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.3.3.2 External Environment Interface Elements 4.3.3.2.1 User Interface EEI Elements The User interface EEI elements include the commands that users can use to perform network functions such as: - File transfer - Electronic Mail - Remote printing These commands are considered to be beyond the scope of this clause and will be covered in 4.9. The User interface EEI elements that will be covered in this section are the commands that are used to perform network management and security functions. 4.3.3.2.2 Communication EEI Elements The primary focus of the network EEI is the network protocols and supporting formats for network communication. The entities in the external environment may be other application platforms or user interface equipment connected to the network using the open networking protocols. The standards at the EEI will be in several areas including: - Physical connections - Network protocols and formats - Distributed systems services The standards at the EEI will impact system interoperability but also may have an effect on application portability because certain applications may require particular types of network access to operate. 4.3.3.3 Implementation Aspects The POSIX OSE Network reference model focuses on the requirements of application portability and system interoperability. As such, the model does not represent how systems are actually put together. In the network area, there is much effort dedicated to the design of network standards to allow network components to be re-usable. This subclause shows how some of these network standards are related within Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 80 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 the POSIX Network Reference Model. Other network models are also related to the POSIX OSE Network Reference models. None of these other models are in conflict with the POSIX OSE Network Reference model. These models show much more detail in the area of how different standards work together. 4.3.3.3.1 Relationship Between the OSI Reference Model and the POSIX OSE Network Reference Model _________________________________________________________________________ _________________________________________________________________________ Figure 4-5 - ISO Networking Reference Model Figure 4-5 shows the OSI seven layer model for networking as standardized by ISO [ref]. There are many aspects of network architecture that are specified by the OSI Network Model model: - The number of layers in the model and the roles for each layer. - An indication of which layers are logically end to end and which layers are simply to the next physical network node. - The protocols between the layers and the protocols between the peers within the same layer. This has an impact on the actual format of the information transferred between nodes at the physical layer. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 81 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS In addition, this model specifies how networks of computer systems can be assembled using the routing capabilities of intermediate nodes. The POSIX OSE Network Reference Model has a much more limited scope than the OSI network model. The POSIX OSE reference model only looks at two interfaces to an application platform: the interface between application software and the application platform (API) and the interface between the application Platform and the External Environment (EEI). At both the API and EEI, the POSIX OSE network model describes the services that are provided to the application or external environment at the interface. Figure 4-6 shows how the two models could be related for one of the POSIX OSE Network Reference Model Application Programming Interfaces and three of the External Environment Interfaces. The POSIX OSE reference model focuses on a single application platform rather than a whole network. The POSIX Network API includes the API provided to interface to the application layer of the OSI model. Because the OSI portions of the Application Platform External Environment Interface depend on the format, protocol, and services of what is produced at the physical level of the OSI reference model, the EEI technically depends on all seven layers the OSI model plus the services added on top of the application layer such as platform provided services or network management services. This guide will not call out all of the standards that specify the protocols, formats, and options for all seven layers of the ISO network standards. Instead, this guide will focus on the services provided at the EEI using all of those formats and protocols. Figure 4-7 shows an API interface to only layer seven of the OSI Network interface, which is intended to be the primary API for accessing network services. It is possible to define APIs that interact directly with any of the seven layers. There are a number of pragmatic reasons to provide APIs that access layers below layer 7. The cost of using one of these lower layer APIs is that the applications may sacrifice portability and/or interoperability. It is important to note that while these APIs are represented as a part of a layered network architecture, from the point of view of the application interacting with the application platform, this layering is not critical to the use of the services. From the application perspective, there are simply three different types of network services, each with a different set of capabilities and requirements. Whether or not there is any actual layering or code common to the three services is implementation dependent. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 82 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _________________________________________________________________________ _________________________________________________________________________ Figure 4-6 - Relationship of ISO and POSIX OSE Network Reference Models 4.3.3.3.2 POSIX Network Standards Efforts The current POSIX approach to networking focuses on producing Application Program Interface (API) specifications. Most of the network connectivity specifications at the External Environment Interface are well covered on other standardization areas such as ISO (OSI networking) and the RFC process (TCP/IP). Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 83 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 4-7 - Multiple POSIX OSE APIs to Different OSI Layers One important aspect of the POSIX networking approach is that it is not focusing solely on producing standard APIs for OSI Network services. The POSIX Simple Network Interface (P1003.12 SNI) is explicitly designed so to be implemented transparently on a wide variety of networks. At the current time the possible list includes: - OSI Application Layer - OSI Transport Layer - TCP/IP - Other networks including proprietary networks The current POSIX API standardization efforts include: - P1003.12 -- Simple Network API Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 84 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - P1003.12 -- Detailed Network API - P1003.17 -- Directory Services API - P1238.0 -- OSI Application Layer API (ASCE) - P1238.1 -- OSI Application Layer API (FTAM) _________________________________________________________________________ _________________________________________________________________________ Figure 4-8 - Basic Network Services Model Figure 4-8 shows how the basic network services can be related. The Simple Network Services API is designed so that a Simple Network Services Implementation can be done using the services available using the Detailed Network Interface API. An application can use the Detailed Network Interface to access multiple network transports but there may be Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 85 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS differences between networks visible at the API. Applications that need to be portable across different types of network transports should be written using the Simple Networking Interface. It is important to note that while the SNI API and DNI API standards have been designed so that the SNI Services can make use of the DNI API to access transport services, it is not a requirement that every implementation of SNI Services be written using the DNI API to access transport services. From the point of view of the application program, it is only important that the application platform provide an API for both the SNI and DNI services. This interface between the SNI Services and the Transport Services is an example of a Systems Integration Interface as described in 3.6. Another example of Systems Integration Interface that is the subject of discussion in the POSIX Network area is the interface between the OSI Network Services and the transport services. This may or not be required to be the DNI API. This is an example of an interface that should have no impact on user application portability but may have great impact on the ability to procure the different types of network services from different vendors. The area of Directory Services (P1003.17) is also specified so to be able to make use of different types of Directory Services including: - X.500 Directory Services - TCP/IP Directory Services - POSIX P1003.7 System Administration and Management Services Figure 4-9 shows how the Directory Services are related to the other network services. All of the APIs and SIIs from the previous figure have been eliminated to reduce the number of interfaces shown on the figure. 4.3.4 Service Requirements The service requirements for the network component of an open system are very wide ranging. Many of the other components of the application platform make implicit or explicit use of network services. Much standardization effort has gone into the aspects of networking that are available at the external environment interface. Effective networking standards at the external interface are fundamental to providing system interoperability. The service requirements for both the API and EEI are described in this section. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 86 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _________________________________________________________________________ _________________________________________________________________________ Figure 4-9 - Directory Services Architecture _C_R_S: _C_o_m_m_e_n_t _t_o _m_o_c_k _b_a_l_l_o_t _r_e_v_i_e_w_e_r_s: _T_h_i_s _s_e_c_t_i_o_n _i_s _s_u_p_p_o_s_e_d _t_o _s_t_a_t_e _t_h_e _s_e_r_v_i_c_e_s _r_e_q_u_i_r_e_d _b_y _a_n _a_p_p_l_i_c_a_t_i_o_n _a_t _t_h_e _A_P_I _a_n_d _t_h_e _r_e_q_u_i_r_e_m_e_n_t_s _t_h_a_t _u_s_e_r_s _a_n_d _n_e_t_w_o_r_k_s _p_l_a_c_e _o_n _t_h_e _e_x_t_e_r_n_a_l _i_n_t_e_r_f_a_c_e _o_f _t_h_e _c_o_m_p_u_t_e_r _s_y_s_t_e_m. _W_e _h_a_v_e _f_o_u_n_d _t_h_a_t _a_n _e_f_f_e_c_t_i_v_e _w_a_y _t_o _s_t_a_t_e _t_h_e_s_e _r_e_q_u_i_r_e_m_e_n_t_s _i_n _a _g_e_n_e_r_a_l _w_a_y _i_n _t_o _u_s_e _t_h_e _p_h_r_a_s_e ``_a_b_i_l_i_t_y _t_o ....'' _C_o_m_m_e_n_t_s _a_r_e _w_e_l_c_o_m_e_d _t_o _a_d_d _s_e_r_v_i_c_e _r_e_q_u_i_r_e_m_e_n_t_s _t_o _t_h_e_s_e _s_e_c_t_i_o_n_s. _W_e _k_n_o_w _t_h_e_r_e _a_r_e _g_e_n_e_r_a_l _s_e_r_v_i_c_e _r_e_q_u_i_r_e_m_e_n_t_s _t_h_a_t _c_o_u_l_d _b_e _a_d_d_e_d. _C_o_m_m_e_n_t_s _a_d_d_i_n_g _s_e_r_v_i_c_e _r_e_q_u_i_r_e_m_e_n_t_s (_e_s_p_e_c_i_a_l_l_y _t_h_o_s_e _u_s_i_n_g _o_u_r _t_e_r_m_i_n_o_l_o_g_y) _a_r_e _g_r_e_a_t_l_y _a_p_p_r_e_c_i_a_t_e_d. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 87 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.3.4.1 Application Program Interface Services 4.3.4.1.1 Directory Services _C_R_S: _R_o_b, _a_n_y _a_d_d_i_t_i_o_n_a_l _s_e_r_v_i_c_e _d_e_s_c_r_i_p_t_i_o_n_s _w_o_u_l_d _b_e _a_p_p_r_e_c_i_a_t_e_d. _Y_o_u _k_n_o_w _t_h_i_s _a_r_e_a _m_u_c_h _b_e_t_t_e_r _t_h_a_n _I _d_o. Directory services allow an application to find the names and addresses of objects and services available to the application. These services include: - Ability to look up the name to be used to access a particular service - Ability to look up the address of a named object 4.3.4.1.2 Application to System Services These are the services requested by the application that are performed by the Application Platform on behalf of the application without the application actually communicating directly with another application. Many of these services may actually connect to some remote application but the details of the connection are left up to the application platform. These services will be provided by a relatively simple high level API. These services include: (1) File transfer (2) Remote execution of commands (3) Mail delivery (4) Remote login (5) Remote printer access (6) Network status - Ability to access remote or local systems using remote procedure calls (RPC). When this type of access is provided, nearly all of the details of the network connection and interaction are masked from the application. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 88 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.3.4.1.3 Application to Application Service There are three areas of application to application service requirements: - RPC Services - Simple Network Services - Detailed Network Services The RPC services allow an application to register with the network application platform as the provider for a particular RPC Service. Once the service has been properly registered, other applications can transparently request services using a subroutine call. The details of communicating the service request to the application that is registered to provide the service and the return of the response to the requesting application are handled transparently by the Application Platform. Applications making use of RPC services may not even be aware that the service are being provided via an RPC mechanism. The Simple Network Services are application to application services provided using a simple set of interface routines. These will allow a wide variety of networking applications to be written that do not need to exercise control their network access at a very complex level of detail. In addition, these services should be provided over a wide variety of network transport mechanisms. Applications written exclusively using the simple services should be portable across a wide variety of networking environments. Applications written using the simple network services may not be able to make use of unique advantages of a particular physical networking scheme. To make use of these network-specific features the Detailed Network Services must be used. The service requirements for the simple network services are intended to be the minimum requirements to write a large subset of network applications. The Simple Network Services sacrifice the capability to control every detail of the network services in the interest of portability across networking environments and applications simplicity. The Detailed Network Services API allows the application to control over much more detail of the network services. In addition, using the Detailed Network Services an application may be able to make use of unique networking capabilities available in particular networking environments. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 89 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.3.4.1.3.1 _R_P_C__S_e_r_v_i_c_e_s These service requirements include: - Ability to register as an RPC service provider - Ability to wait for incoming requests - Ability for an application using RPC services to control parameters such as timeout _C_R_S: _S_o_m_e_o_n_e _w_h_o _i_s _a_n _R_P_C _w_h_i_z _s_h_o_u_l_d _b_e_e_f _t_h_i_s _u_p _w_i_t_h _m_o_r_e _d_e_t_a_i_l_e_d _R_P_C _s_e_r_v_i_c_e_s 4.3.4.1.3.2 _S_i_m_p_l_e__N_e_t_w_o_r_k__S_e_r_v_i_c_e_s The services provided at the simple network interface are: (1) Name resolution (2) Connection oriented services - Ability to indicate willingness to accept incoming connections - Establishing and destroying connections - Data transfer over connections +o Read +o Read with timeout +o Write +o Write with timeout - Simple error handling +o Connection dropped notification +o Connection read failure +o Connection write failure - Ability to close a connection +o Unconditionally Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 90 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 +o Only after all data has been received (3) Connectionless services - Ability to indicate willingness to accept incoming requests - Ability to send requests +o With acknowledgment +o Without acknowledgment +o Specified timeout - Ability to receive requests +o Wait unconditionally +o Wait with timeout - Ability to query as to whether any requests are available - Simple event notification +o Lost request +o Request acknowledgment - Simple error handling +o General network failure (4) Support for server applications - Ability to register as the provider for a service (5) Simple status inquiry - General network availability 4.3.4.1.3.3 _D_e_t_a_i_l_e_d__N_e_t_w_o_r_k__S_e_r_v_i_c_e__R_e_q_u_i_r_e_m_e_n_t_s The services provided at the Detailed Networking Interface include all of the service requirements in the Simple Network Service Requirements plus the following: (1) Ability to query the network services to get detailed information about network configuration and status Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 91 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS (2) Ability to specify performance metrics (3) Ability to control routing (4) Ability to select between different network protocols (5) Ability to negotiate capabilities - Required capabilities - Optional capabilities - Ability to determine the results of the negotiation (6) Capability to deliver information with different priorities (7) Ability to request and process extended event notification (8) Ability to request and process extended error recovery including allowing the application to completely control error recovery. (9) Ability to make full use of network resources for performance critical applications This should provide the application with the ability to completely control connection oriented services and connectionless services. 4.3.4.1.4 Data Representation Services - Ability to access all of the data representation and format conversion services to allow an application to communicate with a wide variety of computer systems. 4.3.4.1.5 Distributed System Services The services provided in this area include: - The ability to identify available resources in a distributed system - The ability to dynamically make use of the resources in a distributed system. - The ability to access files regardless of the physical location of the files. - The ability to have reliable time services across all of the resources of the distributed system. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 92 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.3.4.1.6 Network Management Services The services provided at the Network Management API are: (1) The ability to manage - Network objects - Network relationships - Network security (2) The ability to monitor and report on - Network events - Network service alarms - Network security alarms (3) The ability to log - Network events - Network availability - Network load - Network performance (4) The ability to test network performance and reliability 4.3.4.2 External Environment Interface Services At the external interface, there are several types of services that are provided. These include: - Data transfer and connectivity - Routing and relay services - Services provided by the application platform directly to an incoming connection - Network management and security services provided to other networks and other nodes within a network Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 93 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Network management user interface This clause does not address the user interface to the general network services such as file transfer or mail sending. That is covered by the command interface clause, 4.9. As stated above, this clause covers the network management user interface. In addition, there are a number of other areas of external interface requirements that are not covered in this guide. They include: - Physical network interface connections - Electrical specifications for network connections - Specifications for physical network construction These are important requirements that need to be specified when describing the complete external interface of a computer system. There is a great deal of important standardization in this area, but it is beyond the scope of this guide to cover the subject. For more detail on these areas of the external environment interface, see the ``OMNICOM book.'' _C_R_S: _T_h_i_s _i_s _i_n_t_e_n_d_e_d _t_o _b_e _a _r_e_f_e_r_e_n_c_e _t_o _t_h_e _3 _i_n_c_h _t_h_i_c_k _b_o_o_k _t_h_a_t _A_n_d_y _b_r_o_u_g_h_t _i_n... 4.3.4.2.1 Data Transfer and Connectivity Services required at the EEI in the area of data transfer and connectivity include: - The ability to connect and interoperate with other standards-based systems using standards-based protocols including X.25 and OSI. - The ability to connect and interoperate with systems using de facto networking interfaces such as TCP/IP and UUCP - The ability to connect and interoperate with personal computer and workstation networks. - The ability to interoperate with industry leading networking interfaces. 4.3.4.2.2 Routing and Relay Services Services required at the EEI in the area of routing and relay capabilities include: Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 94 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 (1) Ability to relay information through a system between like networks. (2) Ability to gateway information through a system between unlike networks at a data transfer level. Examples of this type of gateway include: - Local Area Network (LAN) to LAN - LAN to Wide Area Network (WAN) - WAN to Global Area Network (GAN) - Networks to point-to-point connections - Point-to-point connections to networks (3) Ability to convert information from one format to another when transferring between unlike computer systems or networks. Information that may need to be converted includes: - Mail messages - File contents - Printer file contents The primary requirement for the routing and gateway services is to make any necessary relays and gateways transparent to the applications and systems using the network. This requires complete gateways and relays. 4.3.4.2.3 Services Provided by the Application Platform at the EEI These EEI services are those provided to incoming connections that are not directed to an end-user application or server. These incoming connections are directed to standard services that can be provided by systems. These services include: - Remote logon and terminal emulation - Remote execution of commands - File transfer services - Remote authentication - Remote data access Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 95 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Remote status information - Mail delivery services - Directory services To access these services each user does not need to provide an application on the remote host. Simply by connecting to the service, the application platform will provide the service. 4.3.4.2.4 Network Management and Security Services These EEI Services allow remote systems to be managed and monitored. Network management services include: - The ability to get network status information - The ability to get network configuration information - The ability to test network functionality - The ability to make network configuration changes The security services allow the system management to control access to system resources and system information. Security services include: - The ability to protect the system from intruders - The ability to provide selective access to sensitive system resources - The ability to manage the network security 4.3.4.2.5 Network Management and Security User Services These EEI Services allow users and/or network administrators to control and configure their network. These network management services include: - The ability to get network status information - The ability to get network configuration information - The ability to test network functionality - The ability to make network configuration changes The security services allow the system management to control access to system resources and system information. Security services include: Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 96 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - The ability to protect the system from intruders - The ability to provide selective access to sensitive system resources - The ability to manage the network security 4.3.5 Standards, Specifications, and Gaps 4.3.5.1 Current Standards in the POSIX OSE _C_R_S: _T_h_e_s_e _a_r_e _t_h_e _b_e_g_i_n_n_i_n_g _o_f _t_h_e _s_t_a_n_d_a_r_d_s _s_e_c_t_i_o_n_s. _I _s_t_i_l_l _h_a_v_e _y_e_t _t_o _t_y_p_e _i_n _a_l_l _o_f _t_h_e _s_t_a_n_d_a_r_d_s _d_e_s_c_r_i_p_t_i_o_n_s. _P_l_e_a_s_e _p_r_o_v_i_d_e _c_o_m_m_e_n_t_s _r_e_g_a_r_d_i_n_g _o_t_h_e_r _s_e_r_v_i_c_e_s _l_i_s_t_e_d _a_b_o_v_e _t_h_a_t _h_a_v_e _c_u_r_r_e_n_t _o_r _e_m_e_r_g_i_n_g _s_t_a_n_d_a_r_d_s. _C_R_S: _F_i_g_u_r_e _4-_6 _f_r_o_m _d_r_a_f_t _1_2 _i_s _r_e_t_a_i_n_e_d _i_n _t_h_i_s _s_e_c_t_i_o_n. _T_h_e _b_o_x ``_p_o_s_i_x _a_p_p_l_i_c_a_t_i_o_n _i_n_t_e_r_f_a_c_e'' _i_s _r_e_m_o_v_e_d. _T_h_e _f_i_g_u_r_e _i_s _r_e_f_e_r_e_n_c_e_d _a_s _p_a_r_t _o_f _t_h_e _O_S_I _p_r_o_t_o_c_o_l _s_t_a_c_k _i_n _t_h_e _s_t_a_n_d_a_r_d_s _t_a_b_l_e. See Table 4-4. 4.3.5.2 Emerging Standards See Table 4-5. 4.3.5.3 Gaps in Available Standards See Table 4-6. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 97 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Table 4-4 - Current Networking Standards __________________________________________________________________________________________________________________________________________________ Service API/EEI Specification Subclause ____________________________________________________________________________________ Protocol Stack E ISO/OSI 4.3.? (See Figure 4-10) Local Area Networking E ISO 802.3 4.3.? E ISO 802.4 E ISO 802.5 Wide Area Networking E CCITT X.25 4.3.? Directory Services E X.500 4.3.? File Transfer E OSI FTAM 4.3.? Message Handling E ISO/CCITT X.400 4.3.? A APIA ? Virtual Terminal E OSI/VT 4.3.? Network Management E ISO 9596 4.3.? E ISO 9593 E ISO/NMF Network Security E ISO 803.10 4.3.? Distributed System Services E? ISO DP 4.3.? Distributed Transaction Services E? ISP 10026, ISO 8587 4.3.? __________________________________________________________________________________________________________________________________________________ Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 98 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Table 4-5 - Emerging Networking Standards __________________________________________________________________________________________________________________________________________________ Service API/EEI Specification Subclause _____________________________________________________________________________________ Mainframe Networking A IEEE P1003.10 4.3.? A IEEE P1003.11 Network Security Both? IEEE P1003.6 4.3.? Both? SIRS 233 ? X3T4 Simple Network Interface A IEEE P1003.12 4.3.? Detailed Network Interface A IEEE P1238.1 4.3.? A X.400, APIA A IEEE P1003.10 Distributed File Management A IEEE P1003.8 TFA 4.3.? Directory Services A IEEE P1003.17 4.3.? File Transfer A IEEE P1238 Bindings 4.3.? A IEEE P1237 ? ECMA 127 Message Handling E IEEE P1224 Bindings 4.3.? A IEEE P1003.13 Remote Procedure Call (RPC) A ECMA 127 4.3.? A? ISO DIS 10148 A IEEE P1237 Distributed System Services ? ECMA 127 4.3.? Remote Data Access Both? SAG X3.T2 4.3.? Distributed Transaction Services Both? IEEE P1003.11 4.3.? Print Services E? X3H3 4.3.? __________________________________________________________________________________________________________________________________________________ Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 99 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Table 4-6 - Gaps in Networking Standards __________________________________________________________________________________________________________________________________________________ Service API/EEI Specification Subclause ______________________________________________________________________________________ Local Area Networking E MIL-STD-1777 (IP) 4.3.? E MIL-STD-1778 (TCP) PC Networking E X/Open PCI:SMB 4.3.? E X/Open PCI:(PC)NFS Wide Area Networking E TCP/IP 4.3.? E UUCP Mainframe Networking ? X/Open CPIC 4.3.? Network Management Both? X/Open System Management 4.3.? E RFC-1098 (SNMP) Simple Network Interface A X/Open XTI 4.3.? Detailed Network Interface A System V Streams 4.3.? A Berkeley Sockets Directory Services E RFC-1034 (TCP/IP Domain 4.3.? Naming) System Status E RFC-1194 (TCP/IP Finger) 4.3.? File Transfer E MIL-STD-1780 (TCP/IP FTP) 4.3.? Message Handling E MIL-STD-1781 (TCP/IP SMTP) 4.3.? Virtual Terminal E MIL-STD-1782 (TCP/IP Telnet) 4.3.? Network Time Protocol E RFC-1129 (Internet Time) 4.3.? Distributed Transaction Services Both? X/Open XTP 4.3.? __________________________________________________________________________________________________________________________________________________ Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 100 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _________________________________________________________________________ _________________________________________________________________________ Figure 4-10 - OSI Network Services Standards Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.3 Network Services 101 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 102 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.4 Database Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _S_a_n_d_r_a _S_w_e_a_r_i_n_g_e_n 4.4.1 Overview and Rationale This subclause describes an overview of an architectural framework for discussing database management. It also describes the services provided to application programs and users, and it describes standards, current and emerging, that standardize those database services. Database management is an important component of the POSIX Open System Environment; in a large class of application programs, especially those used in business, database access through a database management system plays a key role. For portability and interoperability, an application using a database must be isolated from the hardware and software retrieval methods as much as possible. Otherwise the application must have the data manipulation capability coded in its own programs. This might be done if performance is a key issue and the data is very unique. The cost is portability and interoperability. The following metrics can be used to measure the performance of specific implementations of Database Management Systems. In some cases there are standardized benchmarks, such as the Transaction Processing Council (TPC-A) performance benchmark, that allow rigorous comparison of competing products. - Time to load a database - Time to recover a database after a failure - Database throughput in ``transactions per second'' - Maximum size database in bytes - Maximum size of a table in rows - Service response time - Concurrency - Maximum number of concurrent users - Maximum number of concurrent transactions Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.4 Database Services 103 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.4.2 Scope Included within the component of database management are various structured ``data models,'' including indexed files and network, relational, semantic, and object-oriented databases. Specifically excluded from consideration are services for accessing data that is not part of a database. This subclause discusses database management services from both the application program and user points of view. Database services provided to application programs by this component, for example, include the ability to create, alter, or drop tables, records, and fields and the ability to insert, select, and update data included in the structures above. Included within this component are also utility capabilities such as database administration services. The list of standards below is comprehensive: there are no standards or emerging standards in the database area that are excluded from the POSIX OSE. There are no standards in this area that are known to be inconsistent with POSIX.1 {2}. 4.4.3 POSIX OSE Database Services Reference Model d 4.4.3.1 Reference Model d In this subclause, the conventional view of Database Management is related to the POSIX reference model described earlier. The application programmer's view of the database model is introduced first. Quite simply, an application program, through a _D_a_t_a_b_a_s_e _A_P_I, requests database services. For convenience in the following discussion, the agent responsible for providing those services is called the _D_a_t_a_b_a_s_e _M_a_n_a_g_e_r. The database manager is responsible for providing the application access to the _D_a_t_a_b_a_s_e. See Figure 4-11. This figure also demonstrates the concept of a _D_a_t_a_b_a_s_e _U_t_i_l_i_t_y _P_r_o_g_r_a_m: one or more special application programs, usually provided by a database vendor, that perform utility services on the database. Such utilities might reorganize the database, recover the database after a system failure, etc. The traditional database model can be incorporated into the POSIX reference model, as in Figure 4-12. This depiction of the model shows that the database manager is really just part of the overall POSIX Open System Environment and is available to the application through the POSIX OSE API. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 104 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _________________________________________________________________________ _________________________________________________________________________ Figure 4-11 - The Traditional Database Model The model depicted in Figure 4-12. is sufficient to describe an application developer's view of the POSIX OSE API in general, and the database API specifically. The four lines labeled ``Database API'' represent the Database Applications Program Interface services, which are discussed in 4.4.4.1. 4.4.3.2 Implementation Aspects d Some real world considerations of the POSIX Reference Model were discussed in 3.6. One of the real-world approaches described is ``layering.'' Note that in the marketplace, Database Managers are often independently purchasable components that are effectively implemented as layers. Another consideration is Database Manager portability. It is not a requirement that a a database manager sit on top of a POSIX OSE API, but there is very important value to the user in terms of portability if the database manager implementation does indeed sit on a POSIX API. This means that the database manager itself is portable. It should be noted that there will probably be implementations available of database managers that do not, in fact, sit on top of a POSIX API (or sit only partially on top of a POSIX API), that nonetheless provide the user the same database API. Such an implementation, using both POSIX API services and non-POSIX API services was described as ``expansion'' (see 3.6.1). Note that even though the model is drawn with only a single database manager, that does not imply that there may only be a single database manager available to an application. In fact, the coexistence Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.4 Database Services 105 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 4-12 - POSIX Database Reference Model of several database managers on the same system is consistent with this model, as is the ability of a single application to access two or more different database managers. The following extensions to the above model are specifically accommodated: - There may be more than one database API. For example, there may be an ``SQL'' API and an ``ISAM'' API. - There may be more than one database manager implementation for each different API. (For example, by two competing database vendors.) - Applications may access more than one database manager. This document has not described how a database manager is implemented in a POSIX Open System Environment, nor is it within the scope of this document to do so. It should be noted, though, that this model is very general and does not constrain the implementor. This model supports a number of varying real world implementation techniques, including: - Application and database manager linked into a single process. - Database manager consisting of more than one process. - Database manager consisting of a client part linked into the application process and a server part running as a process on the Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 106 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 same or another system. 4.4.4 Service Requirements The Database Manager described in the previous subclause provides services to the Application Program via the Database API, and the Database Utility Programs provide other services (e.g., to human users such as a ``Database Administrator''). This subclause describes the service requirements of all service users of the system. It is intended to be a complete list of service requirements rather than examples. Database Services are the specialized data services required to create, access, and manage databases located on a processor node. A uniform use of database services shall be available across POSIX-compliant machines. Users of these services include end users and those charged with the ongoing management of the information processing and database infrastructure. 4.4.4.1 Application Program Interface Services This subclause describes the major categories of database services available at the POSIX Application Program Interface (API). These services include: - Data Definition and Manipulation Services - Data Access Services - Data Integrity Services - Miscellaneous Services The following paragraphs clarify that these services should be provided for a large class of objects, access methods, and types of database systems. Types of Data Objects Ability to perform the above operations on a variety of types of data objects, such as text, graphics, image, documents, and voice. Types of Access Methods Ability to perform the above operations using a variety of access methods, such as indexed sequential access, nonindexed sequential access, and direct access. Types of Database Management Systems Ability to perform the above operations on a variety of types of file and database management systems, and database Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.4 Database Services 107 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS management systems, such as relational, network, semantic, and object oriented databases, and heterogeneous combinations of these database management systems. 4.4.4.1.1 Data Definition and Manipulation Services These services relate to the ability of application programs to define and manipulate data. These services are: - Data definition -- ability to create, alter, or drop tables, views, records, fields, and/or data - Data Manipulation -- ability to insert, select, update, and delete tables, views, records, fields, and data 4.4.4.1.2 Data Access Services These services relate to the ability of application programs to interrogate databases. These services are: - Data Query Facilities -- ability to specify search conditions, consisting of a combination of select lists, predicates, and comparison operators - Data Transparency -- ability to transparently access data regardless of the location of that data. - Remote Data Access -- ability to access and update remote data 4.4.4.1.3 Data Integrity Services These services relate to the ability of database management systems to protect the databases from hardware and software malfunctions. - Locking -- ability to specify locking of data to some degree of granularity - Consistency -- ability to specify and execute check and referential constraints that help ensure data correctness - Transaction Control -- ability to specify commit and rollback commands and guarantee serializability - Synchronous Writes (Durability?) -- ability to force the writing of data to nonvolatile storage Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 108 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.4.4.1.4 Miscellaneous Services These services relate to other services required for the automated management of databases. - Privilege Administration -- ability to grant and revoke privileges for accessing and administering data - Exception Handling -- ability to have applications that are interrupted and notified of exception conditions, to receive control of the machine and take action in response to these exception conditions--even if the action is to ``continue'' - Screen Definitions -- ability to create screen definitions, and define, display, and/or paint screens - Reporting -- ability to create formatted reports. - Dynamic Facilities -- ability to temporarily turn control of a database to the end user for interactive access and manipulation of data, and then return control to the application. - Data Dictionary Services -- ability to get data about the data (i.e., metadata) stored in the database. This allows users and applications to use the database contents in a much more flexible way. These services allow a user to create, access, and manage this metadata much in the same way as other databases are maintained. 4.4.4.2 External Environment Interface Services External Environment Interface services are required for distributed database management systems. Also, to enable two or more databases to communicate with each other, a common interchange format is required. See 4.5. d 4.4.4.3 Database Resource Management Services These services are not visible to the application programmer at the Database API. These services are usually provided by Database Utility Programs. These services include: - Database Administration Services - Database Recovery Services Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.4 Database Services 109 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Distributed Database Management Services - Heterogeneous Environment Support Services 4.4.4.3.1 Database Administration Services Ability for a designated data administrator to structure and configuration manage a database as a whole. The administrator allocates resources and monitors utilization to assure that authorized users receive the proper services. Archive functions, journaling, and logging services are available to the user and administrator on a selective basis. 4.4.4.3.2 Database Recovery Services Ability to decide that there has been a failure, allow recovery from failure, and permit a slave copy to become a master copy. 4.4.4.3.3 Distributed Database Management Services Supports the partitioning and partial replication of the databases. 4.4.4.3.4 Heterogeneous Environment Support Services Permits local database systems to be of different types (e.g., inverted list, hierarchical, network, relational) by providing translators between the local database form and a general ``network language.'' 4.4.4.3.5 Flagger Ability for programmers to be alerted about any code that does not conform to the standard in question, or about any code that is not processed in a conforming manner. 4.4.5 Standards, Specifications, and Gaps There are currently four database standards, either completed or under development. These are the relational data language SQL, a network data language called NDL, the Information Resource Dictionary System (IRDS) for data dictionary work, and a Remote Data Access (RDA) protocol. Table 4-7 summarizes the service requirements provided by the various standards. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 110 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Table 4-7 - Database Standards __________________________________________________________________________________________________________________________________________________ Service Specification Subclause _________________________________________________________________________ Data Definition and SQL: ISO 9075 4.4.5.1 Manipulation Services ANSI X3.135 Data Access Services ANSI X3.168 Data Integrity Services Data Definition and NDL: ISO 8907 4.4.5.1 Manipulation Services Data Access Services Data Integrity Services Miscellaneous Services IRDS: ISO DP 10027.N2642, 4.4.5.2 (Data Security and (IRDS Framework) Integrity, Exception ISO DP 8800 N2132, Handling, Screen (IRDS Interfaces) Definitions, Reporting, ANSI X3.138 Dynamic Facilities, Data Dictionary Services) Database Resource Management Services (Database Administration, Recovery From Failure) External Environment RDA: ISO/IEC DP 9759 4.4.5.2 Interface Services __________________________________________________________________________________________________________________________________________________ 4.4.5.1 Current Standards in the POSIX OSE This subclause describes the current accepted standards that apply to this area. _S_Q_L__S_t_a_n_d_a_r_d__D_a_t_a_b_a_s_e__L_a_n_g_u_a_g_e ANSI X3.135.1 (ISO 9075, FIPS 127) ANSI X3.168 There is a lot of activity by ANSI and ISO in this area. The standards referenced above are all related, but may not all be ``current'' at the time you read this guide. The base document is the 1989 ANSI document. ISO and FIPS documents based on it should be used. Earlier ISO and FIPS documents are based on earlier versions of the ANSI document and consequently may not be consistent with the latest ANSI document. Beware Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.4 Database Services 111 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS of this in making decisions about which of the standards are relevant to your decisions. These standards, developed in 1982-1989 by the ANSI X3H2 Database Committee, specify data access capabilities based on ``structured query language'' and the relational database model. The X3.135 standard provides for many of the services described in 4.4.4, including Data Definition, Manipulation, and Integrity. It provides for two levels of compliance: the weaker Level 1 and the more capable Level 2. While X3.135 deals with SQL independently of programming language, X3.168 binds, or embeds SQL within the programming languages COBOL, FORTRAN, Pascal, PL/1, C, and Ada. Work is currently planned by ANSI and ISO to include ``generalized triggers,'' ``generalized assertions,'' ``recursive expressions,'' ``escape from SQL,'' subtables, and support tools for object oriented and knowledge-based systems. _N_D_L__S_t_a_n_d_a_r_d__D_a_t_a_b_a_s_e__L_a_n_g_u_a_g_e ISO 8907 ANSI X3.133 This standard, developed in 1981-1986 by the ANSI X3H2 Database Committee, specifies a data definition language (DDL) and data manipulation language (DML) for network model databases. This work is an outgrowth of the 1978 CODASYL specifications. This standard provides for many of the services described in 4.4.4, including Data Definition, Manipulation, Access, and Integrity. The above services apply only to network databases (i.e., not to relational or semantic databases.) No follow-on NDL activities are being conducted by ISO or ANSI. 4.4.5.2 Emerging Standards in the POSIX OSE This subclause describes the activities currently in progress to further standardize this area. _R_e_m_o_t_e__D_a_t_a__A_c_c_e_s_s__(_R_D_A_)__P_r_o_t_o_c_o_l ISO DP 9579: Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 112 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Part I, _G_e_n_e_r_i_c _R_e_m_o_t_e _D_a_t_a_b_a_s_e _A_c_c_e_s_s -- DP 2 Part II, _S_Q_L _S_p_e_c_i_a_l_i_z_a_t_i_o_n -- DP 1 This standard, developed by the ECMA Technical Committee on Database Standards, TC22, submitted to ISO in 1985, specifies a protocol that allows remote access and updating, via OSI communications protocols, of relational databases or of database systems that support SQL. This standard provides for the Data Transparency, Remote Data Access, and Support for Heterogeneous Environment requirements described in 4.4. This protocol is aimed at relational databases and other database types that provide access via relational interfaces such as SQL. Much work is planned on in this area by the ISO committee ISO TC97/SC21/WG3. A specific area of current interest is a generic RDA that uses a nonspecific database language (i.e., not SQL.) _I_n_f_o_r_m_a_t_i_o_n__R_e_s_o_u_r_c_e__D_i_c_t_i_o_n_a_r_y__S_y_s_t_e_m__(_I_R_D_S_) ANSI X3.138 FIPS Pub 156, April 5, 1989 ANSI X3H4/90-28 (draft, 4 Apr 90) IRDS Export/Import File Format ISO DP 10027 N2642 (1988) IRDS Framework ISO DP 8800 N2132 (1988) IRDS Services Interfaces These standards are being developed by the ANSI X3H4 Database Group and the ISO/IEC /JTC 1/SC21 Working Group 3. Both groups are addressing the general area of data dictionaries, but, as described below, the emphases of the activities differ. The ANSI group addresses, primarily, the user interface area, that is, how does a human user access the Data Dictionary Services described in 4.4.4. The ISO groups concentrate more on the service interfaces (APIs) among lower level components and utilities of the database model. Differences in scope and incompatibilities exist between the model being developed by ISO and the model approved by ANSI. They are independently developing the Services Interface, and an export/import facility. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.4 Database Services 113 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.4.5.3 Gaps in Available Standards There are two significant areas described in 4.4.4 as requirements that are not addressed by standards: - Methods to access data such as hashing and indexed sequential access to data is not currently standardized. There is no consensus in the standards community as to whether such standardization would be beneficial. - Standardization of semantic and object oriented models have also not taken place, though groups like the ANSI Database system study group (DBSSG) are currently investigating the feasibility of standardization in these areas. - I/O Services such as screen generation. - Management and control of database services. Also include all gaps (all services without standards). 4.4.6 OSE Cross-Category Services d 4.4.6.1 Security Ability to specify access control mechanisms. 4.4.7 Related Standards The standards and activities described in this subclause are related to the above and may also be relevant to your activities. There are several areas closely related to the Database area that are worth considering with respect to standardization. The first area to consider is the communications and networking area. Interoperability for distributed applications or the use of distributed databases may indicate the use of communications software adhering to networking standards. See 4.3 for further discussion of that area. (Specifically consider the following standards described in that subclause: ISO/IEC 9804.3 (OSI CCR services) Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 114 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 ISO/IEC 9805.3 (OSI CCR protocol) ISO 8824 _I_n_f_o_r_m_a_t_i_o_n _P_r_o_c_e_s_s_i_n_g _S_y_s_t_e_m_s--_O_S_I-- _S_p_e_c_i_f_i_c_a_t_i_o_n _o_f _A_b_s_t_r_a_c_t _S_y_n_t_a_x _N_o_t_a_t_i_o_n _O_n_e (_A_S_N._1) ISO 8825 _I_n_f_o_r_m_a_t_i_o_n _P_r_o_c_e_s_s_i_n_g _S_y_s_t_e_m_s--_O_S_I-- _S_p_e_c_i_f_i_c_a_t_i_o_n _o_f _B_a_s_i_c _E_n_c_o_d_i_n_g _R_u_l_e_s _f_o_r _A_b_s_t_r_a_c_t _S_y_n_t_a_x _N_o_t_a_t_i_o_n _O_n_e (_A_S_N._1) The second area to consider is transaction processing. That area goes further in addressing the total requirements for distributed applications. See 4.10. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.4 Database Services 115 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 116 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.5 Data Interchange Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _R_i_c_h_a_r_d _S_c_o_t_t 4.5.1 Overview and Rationale The Data Interchange/Information Exchange components of the POSIX Open System Environment provide specialized support for the exchange of data between applications or components of applications. Without support for data interchange, problems can arise when attempts are made to move data between different operational environments or between two related applications. More specifically, data interchange problems arise in each of the five following situations: - Movement of a single application program and its associated data between operational environments, - Movement of data between cooperating application software within the same operational environment, - Movement of data between cooperating application software operating in differing operational environments, - Movement of data between related, but not cooperating, application software within a single operational environment, and across differing operational environments. From the global view, the data interchange components can provide the means to satisfy the needs in each of these situations. These standards need to define physical formats, data formats, code sets, and data descriptions that are consistent across all implementations of the POSIX Open System Environment. 4.5.2 Scope The data interchange component of the POSIX Open System Environment includes standard services, protocols, and data formats required to ensure that data can be interchanged between related application software. Physical media formats are beyond the scope of the POSIX Open System Environment. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.5 Data Interchange Services 117 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.5.3 Reference Model _________________________________________________________________________ _________________________________________________________________________ Figure 4-13 - Data Interchange Reference Model The Data Interchange Services relate directly to the POSIX Open System Environment reference model that was presented in Figure 3-1. Figure 4- 13 shows the components of the reference model that are significant for data interchange. The reference model defines the conceptual relationships required to provide these facilities. It should not be viewed as a description of an implementation. The key entities within the figure are the Application Software, the Application Platform, and the External Environment. To satisfy the data interchange service requirements, the POSIX Open System Environment must permit application software to transfer data to and from the external environment. The application software requests this transfer through the Application Program Interface. In response to those requests, the data interchange components of the Application Platform handle conversions to and from standard formats and the transfer of the information across the External Environment Interface (EEI). The EEI, which defines the format specifications required to support data interchange, can be divided into Data Description Protocols and Data Format Protocols. Data Description Protocols provide a means to identify the data that is present. Data Format Protocols provide the storage representation of the actual data. Today, this model is only partially supported by standards. Physical formats are fairly well standardized. Some work is beginning on data Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 118 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 format protocols standards, particularly in the networking area. At this time, no general standards exist to support Data description protocols. 4.5.4 Service Requirements This subclause details the Data Interchange Services and protocols that are required to support application portability and interoperability. Subclause 4.5.4.1 describes the API service requirements. 4.5.4.2 describes the EEI service (i.e., protocol) requirements. Data interchange is one of the components of the POSIX Open System Environment that is now just beginning to evolve. At this time, the general requirements for services are understood, but there is little general existing practice that can be pointed to as showing that current service requirements are both necessary and complete. Most existing practice is limited to a specific application domain. As a developing area, data interchange represents gaps in both the definition of service requirements and standards. The data interchange component is, none the less, critical for supporting application portability and interoperability. The data interchange service requirements are currently described to the extent possible at this time in their evolution. More detail will be added in future revisions of this guide. 4.5.4.1 Application Program Interface Services The API services to support data interchange need to provide the ability to store and retrieve data using the formats and protocols provided at the data interchange EEI. At this time little work has been directed at defining API-level service requirements for data interchange. Data interchange API services need to provide a means to request that specific data be represented using the EEI services defined below. Progress in this area is similar to the development of the networking area. Initial standards defined protocols and only after those were in use has attention shifted to providing a standard mechanism for requesting those networking services. 4.5.4.2 External Environment Interface Services This section identifies the EEI services required to support data interchange. These services are all in the form of protocol and format d definitions. As shown in Figure 4-13, these protocols include: - Character Sets and Data Representation - Data Format Protocols Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.5 Data Interchange Services 119 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Data Description Protocols These protocols are required to support the exchange of information between application software entities, both within a single application platform and between application platforms. 4.5.4.2.1 Character Sets and Data Representation The ability to support Character Sets and Data Representation is crucial to providing effective data interchange between application software operating under differing language and cultural conventions. These services add facilities to the POSIX Open System Environment to identify the character set and data representations associated with textual data. A detailed description of the requirements in this area can be found in 5.1. 4.5.4.2.2 Data Format Protocols The data format protocols need to provide the ability to identify the representation of the data in a manner that is independent of the specific execution environment. The data format protocol layer adds attributes that describe the physical characteristics of the data that must be known to properly retrieve the data value, given the storage formats that are native on the hardware/software environment where the data is used. The complete attribute information required to decipher that data value includes: - Detailed storage format for the value - The data value in an environment-neutral format The data format protocols protect applications from hardware/software differences between environments. Specifically, the protocols ensure that data remains stable when moving between environments where the character set, word size, or byte ordering may differ. 4.5.4.2.3 Data Description Protocols Data description protocols provide the ability to share data between related application software entities, even if they were not specifically written to cooperate. Building upon the facilities provided by the previous two Data Interchange EEI Services, data description protocols provide a means of associating a name or other identifier with the individual data elements in a standard manner. This permits an application program to correctly identify data that was created by an unrelated application. To date, most standards in this area have limited themselves to specific application areas and no general solution has been provided. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 120 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.5.5 Standards, Specifications, and Gaps See Table 4-8. Table 4-8 - Data Interchange Standards __________________________________________________________________________________________________________________________________________________ Service Specification Subclause ______________________________________________________________________ Data Description Protocols ODA/ODIF ISO 8613 Parts 1-8 4.5.5.? d SGML ISO 8879 4.5.5.? d EDIFACT ISO 9735 4.5.5.? d STEP ISO DP 10303 4.5.5.? d EDIFACT ANSI X.12 4.5.5.? d IGES NBSIR 86 4.5.5.? d VHDL VHSIC IEEE P1076 4.5.5.? d Data Format Protocols ODA/ODIF ISO 8613 Parts 1-8 4.5.5.? d SGML ISO 8879 4.5.5.? d CGM ISO 8632 4.5.5.? d CGM ANSI X3.122-1986 4.5.5.? d STEP ISO DP 10303 4.5.5.? d EDIFACT ISO 9735 4.5.5.? d EDIFACT ANSI X.12 4.5.5.? d d IGES NBSIR 86-3359 4.5.5.? d VHDL VHSIC IEEE P1076 4.5.5.? d CDIF 4.5.5.? d GDSII 4.5.5.? d __________________________________________________________________________________________________________________________________________________ 4.5.5.1 Current Standards in the POSIX OSE 4.5.5.1.1 International Standards _O_p_e_n__D_o_c_u_m_e_n_t__A_r_c_h_i_t_e_c_t_u_r_e__(_O_D_A_)_/_O_p_e_n__D_o_c_u_m_e_n_t__I_n_t_e_r_c_h_a_n_g_e__F_o_r_m_a_t__(_O_D_I_F_) The ODA/ODIF standard (ISO 8613 Parts 1-8) provides a standard for the structures used to represent documents. The ODA model defines a comprehensive description of a documents format. It supports both reproduction of the original document and also editing and formatting of the document. Part 5 of the ISO ODA standard specifies the interchange format for ODA documents; specifically ODIF. ODIF is an ASN.1 (ISO 8825) based presentation of the ODA document. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.5 Data Interchange Services 121 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _S_t_a_n_d_a_r_d__G_e_n_e_r_a_l_i_z_e_d__M_a_r_k_u_p__L_a_n_g_u_a_g_e__(_S_G_M_L_) SGML (ISO 8879) is a language that allows users to precisely define the structure of a document. The key difference between SGML and ODA/ODIF is that the former provides the flexibility to define custom document types. _C_o_m_p_u_t_e_r__G_r_a_p_h_i_c_s__M_e_t_a_f_i_l_e__(_C_G_M_) CGM (ISO 8632, ANSI X3.122-1986) provides a standard means for the storage and exchange of computer graphics. Graphic information is stored in a device- and resolution-independent fashion that can support both the display and the manipulation of the data. _E_l_e_c_t_r_o_n_i_c__D_a_t_a__I_n_t_e_r_c_h_a_n_g_e__(_E_D_I_) The EDI standards [ISO 9735 (EDIFACT), ANSI X.12] provide support for the exchange of structured business data. EDI is typically used to transfer business documents such as purchase orders, invoices, promotional announcements, and electronic funds transfer information. 4.5.5.1.2 Regional Standards None. 4.5.5.1.3 National Standards None. 4.5.5.2 Emerging Standards in the POSIX OSE 4.5.5.2.1 International Standards _S_t_a_n_d_a_r_d__f_o_r__t_h_e__E_x_c_h_a_n_g_e__o_f__P_r_o_d_u_c_t__M_o_d_e_l__D_a_t_a__(_S_T_E_P_) d STEP (ISO DP 10303) is a neutral mechanism capable of completely d representing product data throughout the life cycle of a product. The d completeness of this representation makes it suitable not only for file d exchange, but also as a basis for implementing and sharing databases of d archiving. d 4.5.5.2.2 Regional Standards None. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 122 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.5.5.2.3 National Standards None. 4.5.5.3 Gaps in Available Standards 4.5.5.3.1 Standards and Specifications Outside the POSIX OSE Most standards activity in the data interchange area has been isolated to specialized application areas. These activities have attempted to support data interchange by limiting the scope of the effort to a specific type of data. These industry standards include: 4.5.5.3.1.1 _G_o_v_e_r_n_m_e_n_t_/_L_e_g_a_l__S_t_a_n_d_a_r_d_s _I_n_i_t_i_a_l__G_r_a_p_h_i_c_s__E_x_c_h_a_n_g_e__S_p_e_c_i_f_i_c_a_t_i_o_n__(_N_B_S_I_R__8_6_-_3_3_5_9_) IGES is used heavily in the exchange of graphical information between applications. 4.5.5.3.1.3 _D_e__F_a_c_t_o__S_t_a_n_d_a_r_d_s _C_A_S_E__D_a_t_a__I_n_t_e_r_c_h_a_n_g_e__F_o_r_m_a_t__(_C_D_I_F_) d The CDIF Technical Committee is developing a data interchange format to d serve as an industry standard for exchanging information between d Computer-Aided Software Engineering (CASE) tools. CDIF is an EIA- d endorsed initiative. It assumes that two or more tools may interface d asynchronously with each other and will transfer information from one to d another via ``CDIF files.'' The types of information that may be d contained in these files is defined by the CDIF Conceptual Models. d _G_r_a_p_h_i_c__D_e_s_i_g_n__S_y_s_t_e_m__I_I__(_G_D_S_I_I_)__C_A_D__E_x_c_h_a_n_g_e__F_o_r_m_a_t CAD exchange format. _H_a_r_d_w_a_r_e__D_e_s_c_r_i_p_t_i_o_n__L_a_n_g_u_a_g_e__(_V_H_D_L__V_H_S_I_C_) The VHDL standard (IEEE P1076) defines a representation for the exchange of CAD representations of electronic circuits. 4.5.5.3.2 Unsatisfied Service Requirements None of these standards addresses a general means to handle application data in a manner to ensure portability between environments. The closest attempt is the effort just beginning in POSIX.8 to define a means within the network interface to provide data portability. However, even this effort is not attempting to solve the broader issue of interoperability of multiple applications. The existing standards have all evolved to Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.5 Data Interchange Services 123 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS support the interchange of specific types of data between separate applications. Support for general data portability is not addressed by existing standard, except for ISIS, which does not appear to have caught on. 4.5.6 OSE Cross-Category Services Not applicable. d 4.5.7 Related Standards The following standards are related to the services covered in this clause as they address some of the services described in section 4.6.4 at some level. Each of these related standards are addressed fully as part of another service category. ASN.1 ISO 8824 Abstract Syntax Notation (Clause 4.3) ISO 8825 ASN.1 Basic Encoding Rules (Clause 4.3) MHS ISO/CCITT X.400-1984 Message Handling System (Clause 4.3) ISO/CCITT X.400-1988 Message Handling System (Clause 4.3) 4.5.8 Open Issues Data interchange support must address hardware/software differences between environments. The key concerns in transporting data that must be addressed will include the character set, word size, and byte ordering for the operating environment along with a accurate identification of the data value. The data portability standards adopted within POSIX Open System Environment need to define data formats that will enable applications to create data that can be used read and properly interpreted on differing operating environments and by other application software. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 124 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.6 Windowing System Services d _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _M_a_r_t_i _S_z_c_z_u_r _a_n_d _R_u_t_h _K_l_e_i_n 4.6.1 Overview and Rationale Human user interface standards are considered in this clause. The user interface is a key component of all computer systems that support direct human-machine interaction. Until recently, most computer operating systems interpreted commands that were typed in from the keyboard of an alphanumeric computer terminal. Special purpose applications, such as those for CAD/CAM, have always presented user interfaces based on series of menus or pointing at visual displays with tablets and lightpens. The availability of low-cost bitmapped graphic workstations and personal computers has lead to the proliferation of graphical user interfaces (GUIs), windowing technologies, generic commands, and an assortment of selection techniques (e.g., mouse, track ball, tablets). In several of these technologies de facto standards are emerging and becoming informally accepted by the user community, and with more frequency, mandated for use in systems being developed within government agencies and private industry. The primary motivations for considering human/computer interaction standards and their relation to POSIX standards include: - The existence and popularity of windowing systems - The requirement for development of applications that take advantage of the windowing system environment - The requirement of many users and manufacturers for a basic consistency in the presentation and behavior of human computer interaction across multiple graphics platforms As the windowing system technology evolves within the graphics environment, the differences between windowing services and graphic services becomes less distinct. The distinction for purposes of this document is that graphic services are associated with providing general purpose interfaces for creating virtually any kind of two- and three- dimensional graphics (e.g., GKS for 2-D and PHIGS for 3-D). HCI services certainly utilize graphic technologies, but are limited to providing graphics related to window-based user interfaces and specifications on how human users may interact with an application within a window environment. The graphic services are addressed independently in 4.7. Performance metrics are used in the specification of HCI components. It is intended that (eventually) a set of metrics that will be sufficient to characterize all of the services defined above. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Windowing System Services 125 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Screen width--effective horizontal width of screen - Screen height--effective vertical height of screen - Screen depth--effective depth of screen (i.e., bit width, gray scale) - Screen resolution--size in units of 106 - Application display latency--time to satisfy a display request measured in units of milliseconds; the interval begins with release of the request from the (possibly remote) application. The interval ends with completion of requested service. 4.6.2 Scope Standards and standards initiatives in the user interface area cover a wide area, ranging from keyboard layout to screen management. In this clause, the following specific standards are considered: - Protocols for window management on a local or remote display device - Application Program Interfaces (API) for such protocols - HCI drivability features that define a common subset of ``look and feel''; i.e., appearance, screen positioning, and behavior of human/computer interaction objects within windows on a graphic screen - Language-independent functional specifications and appropriate associated language bindings for the display, manipulation, and management of interaction objects within windows on a graphic screen - Command-language interface that may be entered interactively by the human user or retrieved from a stored procedure. - Language-independent functional specifications and appropriate associated language bindings required to support character (non- bitmapped) terminals. - Language-independent functional specifications and appropriate associated language bindings for the translation, manipulation, and management of command statements (or messages). Standards relating to the following are not considered: Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 126 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Graphics; see 4.7. - Keyboard layout (out of scope for HCI Services) - Network transport protocols; see 4.3. - Hardware device interfaces (out of scope for HCI Services) 4.6.3 Reference Model This subclause identifies the entities and interfaces specific to the construction of an HCI architecture. This architecture is consistent with, and extends the architecture of, Section 3. As illustrated in Figure 4-14, the interface components involved in the user interface process are divided into two groups, called the external environment interface (EEI) and the application program interface (API). _________________________________________________________________________ _________________________________________________________________________ Figure 4-14 - Windowing Reference Model d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Windowing System Services 127 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS The EEI is concerned with the communication with the user via the physical HCI devices (e.g., keyboard terminal, mouse, display screen). The applicable EEI standards are driven primarily in support of user and data portability across different application platforms. standards and guidelines are intended to define a minimal set of commonality in human user interfaces, which will eliminate problem areas such as: - Error provoking inconsistencies - Misleading expectations about the results of user actions - Gross inconsistencies in the high level user model or metaphor - Incompatible motor control tendencies The drivability concept derives its name from the concept of ``driving'' an interface. A frequently cited analogy is the automobile. Having a standard location for the clutch, brake, accelerator pedals, ignition key, and steering wheel allows a driver to move between car models with relative ease (until he/she has to roll down the window, turn on the lights or windshield wipers!) Similarly, the EEI drivability guidelines will provide standards for human user interfaces that will ensure ease of moving between application platform models. For example, which mouse click causes an interaction object (e.g., radio button) to be selected or how a scroll bar should behave would be candidates for standard EEI specification. The API is concerned with the interface between the application semantics and the HCI services. It is the interface between the application software and the application platform and is defined primarily in support of application portability. These services provide functions for creation and manipulation of visual display objects such as menus, buttons, scrollbars, and dialog boxes. In addition, these functions allow information about user actions to flow back to the application software; for example, when the user has selected an item from a menu. This information about user actions is known as an event. Applications that require communication with the human user are inherently event- driven. That is, associated with an application's dialog window (i.e., a window in which a user response is expected) is a main event loop waiting for the user to make a selection that will trigger an operation to be performed by the application. The API will support a specific user interface policy, which will define the application's ``look and feel.'' Although the specific look and feel need not be standard across application platforms (i.e., different implementations of the API may have unique styles) the API definition shall ensure that the application software can be ported across POSIX platforms; and the API shall support the EEI drivability guidelines, enabling human users to easily operate the application across platforms. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 128 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Elements of the HCI Architecture are Application Software elements, Application Program Interface (API) elements, and External Environment Interface (EEI) elements. These elements are linked by the use of common concepts and definitions associated with the HCI entities, interfaces, services, and standards. 4.6.3.1 Application Software Elements Application Entity Elements include: (1) Window System Server The Window System Server provides a function that handles communication connections from clients, demultiplexes graphics requests onto the screens, and multiplexes input back to the appropriate client. Applications and other programs that use basic windowing services are called ``clients.'' Many clients may talk to the same server. All application requests to write to the screen must go through the server via the basic windowing services. The server is independent of operating system, programming languages, or network communication. (2) Window Manager A Window Manager provides a uniform method for manipulating windows, which includes a basic set of window management capabilities that allow for development of alternative and/or user-preferred window managers. Required human user capabilities shall include but are not limited to: - Resize window - Move window - Push/pop window to top/bottom - Shrink window to a reduced visual representation of window (i.e., frequently referred to as an icon of the window) (3) Local and Remote Applications These applications are clients that provide the functions required to perform the specific task(s) that the human user needs to achieve (e.g., spreadsheets, scientific analysis systems, CASE tools, process and control tasks.) Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Windowing System Services 129 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.6.3.2 Application Program Interface (API) Elements The API are language binding specifications that define the services available to the application programmer. API Elements are: basic window services, toolkit window services, and dialog services. 4.6.3.3 External Environment Interface (EEI) Elements The EEI elements are specifications (and in some cases, aspects of physical objects) that define how the application platform interacts with the external world. Note that application software, as defined here, interacts with the outside world only via the application platform. External Environment Interface Elements include: - Display Device Specifications - Data Protocol Format - User Drivability Guidelines (e.g., ``look and feel'' of window interface) - Keyboard Device Specification - Selection Device Specification (e.g., mouse, graphics tablet, touch screen) - Command-language Definition (syntax and semantics guidelines) 4.6.4 Service Requirements Human-Computer Interaction (HCI) Services provide a controlled interface between the application-specific software and the user-interface-specific (i.e., HCI) software, allowing each to be designed and implemented separately. Users of these services include all POSIX system users and those charged with maintaining the processor and human interface communication. A common, standardized human/computer interaction for applications shall be available to users across all POSIX Open Systems Environments. Services shall support raster (i.e., bitmapped) graphics displays. Methods for supporting vector graphics displays can be addressed, but are not mandatory. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 130 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.6.4.1 Application Program Interface Services Application services include those services made available to the application developer to separate the application functions from the HCI functions as much as possible. They include such areas as screen management, windowing, and user input device services. These standard services support requirements for application portability, software commonality, application interoperability and data communications transparency. A programmer shall have access to the following services from an application via language bindings. 4.6.4.1.1 Basic Window Services The basic window services, callable from client applications, support a window-based user interface. They should be based on a ``client-server'' model. The server is a program that handles communication connections from clients, demultiplexes graphics requests onto the screens, and multiplexes input back to the appropriate client. Many clients may talk to the same server. All application requests to write to the screen must go through the server via the basic windowing services. The major functional areas are: - Window Management - Presentation Management - Event Handling - Error Handling - Interclient Communications - Input Device Management: Keyboard, Pointing Device - Screen Management - User Preferences Management - Server Connection Management The following functions are available under each functional area. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Windowing System Services 131 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _W_i_n_d_o_w__M_a_n_a_g_e_m_e_n_t Functions available for Window Management are: - Create a window, map a window onto the screen, delete a window (includes support for character-based emulator window) - Manipulate a window (move, resize, change view precedence) - Manipulate window attributes (set, get, change; attributes may be related to appearance, redraw performance, event handling, or change authority) - Seize and relinquish control over the Server for display purposes (permits uninterrupted client output; output requests from other clients will be queued and displayed later) _P_r_e_s_e_n_t_a_t_i_o_n__M_a_n_a_g_e_m_e_n_t Functions available for Presentation Management are: - Associate data with a window (context manager functions and association table functions) - Manipulate the graphics context for a given object (create a graphics context, obtain current graphics context, change graphics context, etc.) - Get and set fonts (load font, list fonts, unload font, etc.) - Draw graphics primitives (draw arc, draw line, fill rectangle, clear rectangular window, clear entire window, etc.) - Manipulate window cursors (create, destroy, assign, change, etc.) - Draw text and obtain text metric information _E_v_e_n_t__H_a_n_d_l_i_n_g The basic window services support application requirements to respond to the human user's actions, rather than forcing the human user to respond to the application in a rigid, serialized manner. This requirement necessitates that a program either (1) be capable of handling any one of a number of events at any single point in time, or (2) attach a routine to each event to be called automatically when that event occurs. There is a separate set of events for each window used by the application. An application selects the events for a particular window, maps the selected events to the window, and reads events from the event queue as they occur. There are three major types of events: Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 132 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Input device events (button press event, keypress event, etc.) - Window management events (window exposure event, colormap event, etc.) - Client message events (selection data transferred (by another application) event, private interclient communication event, etc.) Functions available for Event Handling are: - Select events - Map events to a window - Get information about events - Send events _E_r_r_o_r__H_a_n_d_l_i_n_g Functions available for Error Handling are: - Get error message - Get error description - Set error event handler routine _I_n_t_e_r_c_l_i_e_n_t__C_o_m_m_u_n_i_c_a_t_i_o_n The basic window services are required to be network transparent to an application or client. This means that an application on one host may write to the display screen connected to another host without being aware that networking is involved. The basic window services handle the network connections and follow the protocols necessary for the application to interact with the display. This convention allows redistribution of applications in a networked system with no effect on the application software. Therefore, an application client cannot assume that another client can open the same files or seize the same processing environment. Interclient communication via the server has three forms: - Properties Clients may associate arbitrary information with a window; generally used for communication between a client and the window manager. - Selections Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Windowing System Services 133 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Selections are selected by the user out of one client's window, then ``sent'' to another client and displayed in the second client's window. - Cut Buffers Cut Buffers are a specialized form of communication. It is possible to receive notification when a cut buffer (property) is set. Functions available for Interclient Communication are: - Manipulate window properties (list, delete, change, get, etc.) - Set and get selections - Manipulate cut buffers _I_n_p_u_t__D_e_v_i_c_e__M_a_n_a_g_e_m_e_n_t Functions available for Input Device Management are: - Receive keyboard input and pointing device button events - Gain exclusive control of keyboard or pointing cursor - Track the pointing cursor - Change Server-wide keyboard mappings - Set and get keyboard and pointing device preferences _S_c_r_e_e_n__M_a_n_a_g_e_m_e_n_t Functions available for Screen Management are: - Manipulate color using colormaps (copy, change, install, deinstall, get default, etc.) - Get, display, and manipulate bitmapped screen images - Screen saver functions (blanking screen on idle) - Retrieve display information (default colormap, number of display planes, screen width and height, etc.) Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 134 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _U_s_e_r__P_r_e_f_e_r_e_n_c_e_s__M_a_n_a_g_e_m_e_n_t The services and data structures used for managing user preferences are provided and collectively referred to as User Resource Management. There may be up to four sets of options that need to be read and merged: - The human user's defaults stored in the root window's user resource manager property - The human user's defaults stored in a user's defaults file - The application program's defaults - The command line arguments Functions available for User Preferences Management are: - Set and get preference data _S_e_r_v_e_r__C_o_n_n_e_c_t_i_o_n__M_a_n_a_g_e_m_e_n_t Functions available for Server Connection Management are: - Control access to the Server [add host to the access control list (ACL), list ACL, disable ACL, etc.] - Connect and disconnect a client from a Server (and the display controlled by the Server) - Obtain Server implementation information - Flush output buffer to Server and wait for Server to process all events in the output buffer 4.6.4.1.2 Toolkit Window Services The Toolkit Window services provide a mechanism for runtime access to a library of visual objects. A visual object is a graphical display object (i.e., interaction object) with associated software that receives input from human users (typically via a keyboard and a pointing device) and communicates with applications and other visual object software. The graphical representation of a visual object can be modified to reflect the results of application processing. Examples of visual objects are graphical push buttons, check boxes, and editing boxes. (Note: The term used within the X Window System community to define visual objects is ``widgets.'') Toolkit Window services are provided for two reasons: Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Windowing System Services 135 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - To allow application software to directly utilize a visual object library - To allow application-specific visual objects to be created and added to the widget library (Note: creating a visual object includes writing software that uses the Toolkit services) Therefore, Toolkit services may be logically divided into two categories, with some overlap: Visual Object Interface Services, which are called by an application or dialog service, and Visual Object Programming Services, which are called by the visual object software. An application may use Toolkit Window services to: - Perform toolkit initialization/exit - Set up visual object resources - Create/delete a visual object - Display a visual object - Add/remove application-specific routines to be called by a visual object (event callbacks) - Retrieve/modify the state of a visual object - Turn control over to the toolkit for user input processing A visual object software program may use Toolkit Window services to: - Manage child visual objects (a child visual object is a visual object that is displayed inside of another visual object) - Manage window events, timer events, and file input events - Handle visual object geometry (sizing, positioning, child visual object placement) - Handle user input - Manage visual object resources - Translate an event into an action - Manipulate graphics contexts - Manipulate pixmaps (pixel arrays--used to display a graphical object by turning pixels on and off) Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 136 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Manage memory associated with HCI - Handle errors associated with HCI - Allow inter-visual object communication (via the selection mechanism) - Initiate other visual object routines (visual object event callbacks) - Initiate application-specific routines that have been associated with the visual object by the application (application event callbacks) 4.6.4.1.3 Dialog Services Dialog services provide functions to support high-level HCI management for applications with the primary goal of delivering human user inputs to the application program and application-driven information to the human user. The dialog services allow for a separation of the user interface specifications from the application program. For example, there are many applications that are not concerned with whether a user entry object is a pull-down menu or a scrollable list. These applications are only interested in what the user specified or selected from the user entry object (i.e., the parameter value), which will then trigger some action by the application. To support this notion, a single dialogue function might be specified for displaying a window made up of a composite of visual display objects, such as radio buttons, text key-in objects, and scrollable text lists. The application program does not need to manage or understand what the look, location, or visual feedback of any of these items will be. The dialog function has access to the presentation information required to display the specified window and it handles the display of the application specified window. Another dialog service would provide a high-level event loop that returns the user specified input as an application parameter value. The services provide simplicity over the degree of freedom available in Basic and Toolkit Window Services. Most User Interface Management Systems (UIMSs) provide dialog services to fulfill their requirement of separation of user interface from application software. These services are subdivided into: - Window services: provide services used to initialize the window service, create and delete windows with predefined associated visual objects, and manipulation of the pointing cursor. They include services that allow the application to communicate directly with the human user via modal or modeless windows. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Windowing System Services 137 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Visual object manipulation services: provide services used to access the HCI designed by the application HCI designer, display the visual objects defined by the HCI, and associate them with application-tied inputs and outputs. - Event control services: provide services to allow the application to define a set of events and handle triggered events in one of two ways: (1) Wait on the occurrence of any event, processing triggered events one at a time from an input queue (event-driven method) (2) Attach to each event a function that is automatically executed when the event is triggered (callback method) 4.6.4.2 External Environment Interface Services These services provide support for the actual elements with which the human user physically interacts. These functions provide services in three areas: - HCI: provides definition of the presentation and behavior of the visual display objects, command language definition (syntax and semantics), specifications related to keyboards, selection devices, audio and video input/output devices. - Information Interfaces: provides specification of user resource data formats, containing presentation and action information pertaining to visual display objects. - Network Interfaces: provides protocol services for data transport, which is basically the bottom six layers of the OSI model 4.6.4.3 Interapplication Entity Services These services provide support for general conventions and specifications for interaction between HCI components. The services provide support for generalized network/multisession services, such as message handling between HCI components, intermediate language definition, and a standard definition of the format used for saving the presentation, behavior, and action information about HCI objects. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 138 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.6.4.4 Windowing Resource Management Services These services provide general management functions across the HCI components, which include system administration-oriented functions (i.e., management of human/computer interfaces within the scope of the administrator, such as setting up defaults and human user customization functions. For instance, it is important to allow reconfiguration and addition of terminals and displays without affecting the application interface.) These resource management services are independent from the OLTP Resource Management Services defined in 4.10.4.4. 4.6.5 Standards, Specifications, and Gaps Standards that relate to the user reference model presented earlier are considered here. Related standards that might be relevant for one or more of the interface components will also be mentioned. 4.6.5.1 Current Standards in the POSIX OSE No current international or national standards exist for the HCI Services, primarily due to the recent emergence of the windowing technology. However, several standard activities are underway and referenced under 4.6.5.2. There is a de facto standard for the base window system. The X Window System windowing protocol and the Xlib functional interface to the protocol were developed at Massachusetts Institute of Technology. Development is continuing under the aegis of the X Consortium, a group of interested parties in the computer industry and computer manufacturers. Relevant documents from the X Consortium are ``X Window System Protocol, X Version 11,'' ``Xlib - C language X Interface,'' ``X Toolkit Intrinsics - C Language Interface,'' and ``Bitmap Distribution Format 2.1.'' The X Window System protocol and functional interface are considered to be de facto standards in the base window system area because of their widespread adoption by major computer vendors and industry groups. Within the government, the National Institute of Standards and Technology (NIST) issues Federal Information Processing Standards (FIPS) that require purchases made by the United States Government to adhere to certain standards. NIST has adopted the X Window System Version 11 Release 3's X Window System protocol, Xlib, Xt Intrinsics, and Bitmap Distribution Format as FIPS 158. This is a noncompulsory (i.e., voluntary) standard. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Windowing System Services 139 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Table 4-9 - Windowing Standards __________________________________________________________________________________________________________________________________________________ Service Specification Subclause ________________________________________________________________________________ Basic Window Services de facto: X Window System 4.6.5.? d emerging: ANSI X3K13.6 d Toolkit Window Services de facto: X Window System 4.6.5.? d emerging: ANSI X3K13.6 d emerging: IEEE POSIX.2 {_r_e_f} d emerging: IEEE POSIX.1 {2} d Dialog Services Gap 4.6.5.? d EEI Services emerging: ANSI X3V1.9 4.6.5.? d emerging: ISO/IEC JTC 1/SC18/WG19 d emerging: ANSI HSF-HCI d emerging: ISO TC159/SC4/WG5 d emerging: P1201.2 d Interapplication Entity Services Gap 4.6.5.? d Window/Character Resource Gap 4.6.5.? d Management Services d __________________________________________________________________________________________________________________________________________________ d 4.6.5.2 Emerging Standards in the POSIX OSE _M_R_S: _T_h_i_s _s_u_b_c_l_a_u_s_e _s_t_i_l_l _n_e_e_d_s _w_o_r_k. - ANSI X3K13.6. Currently developing an X Protocol standard. - ANSI X3V1.9. User-System Interfaces and Symbols: Working on a ISO/IEC Standard 9995, Keyboard Layouts for Text and Office Systems. Also working on the Voice Messaging User Interface Forum (VMUIF). This is a mirror standards effort with ISO/IEC JTC 1/SC18/WG19. - ISO/IEC JTC 1/SC18/WG19. User-System Interfaces and Symbols. Working on developing standards for user interfaces and symbols associated with text and office systems. - ANSI HFS-HCI. Working on drafts on the design process, information presentation, forms-based dialogs, and window-based interaction. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 140 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - ISO TC159/SC4/WG5. Software Ergonomics and Man-Machine Dialog: Working on developing parts of the ISO Standards 9241, Ergonomics of Visual Display Terminals. Their areas of concentration are software ergonomics, dialogue principles, dialogue styles, methods for evaluating software usability, coding and formatting of information, and terminology - IEEE P1201. Application and User Portability: Chartered to develop standards that facilitate application and user portability in the X Windows environment. P1201.1 is involved in defining a set of virtual toolkit services that would be independent of any windowing system. P1201.2 is involved in defining drivability guidelines. - ANSI CODASYL. Working draft available for Forms Interface Management Systems (FIMS), which covers the interface between a programming language and any form fill-in application on a computer or terminal screen. 4.6.5.3 Gaps in Available Standards - Object Definition File Format: There are no standards addressing the format used for describing the ``look and feel'' of HCI objects. - Toolkit Services - Dialog Services - Interapplication Entity Services - Window/Character Resource Management Services: A standard definition of the format used for saving the presentation, behavior and action information about HCI objects would provide a vehicle for exchanging HCI information between software tools, such as User Interface Management Systems (UIMSs) and Interface Design Tool (ITDs). 4.6.6 OSE Cross-Category Services 4.6.6.1 Security This section should address the security aspects of HCI and would include: - Authentication of person at login Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Windowing System Services 141 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Authentication of person when a service request is made to a client application - Provisions for visual labeling of sensitive material - Option selections available in support of sensitive activities - Prevention of moving data (cut/past) from a more protected security environment to a less protected environment 4.6.7 Related Standards d Currently, the basic windowing services provide a certain level of graphics functionality, but the existing and proposed graphics standards (e.g., PHIGS, GKS) provide a much more comprehensive solution to graphic support. As the graphics and windowing technologies evolve, this distinction between the windowing and graphics services will continue to be blurred. For instance, proposals are already being developed that provide extensions to the X Window System that support 3-D graphics (i.e., PEX, PHIGS EXtensions), and implementations of GKS are currently available that use the X Window System to create the graphics. 4.6.8 Open Issues - Audio input/output - Video input/output - Security - Desktop The Desktop, or HCI graphical shell, is a specification for the HCI work surface (i.e., the whole display screen). The desktop provides the user with a visual interface to available computer resources. A desktop may be characterized as a visual analog of the POSIX shell. It provides access to system resources, such as devices and files, and provides methods to start applications. Desktops typically also provide a set of often used utilities such as a calendar, a notepad, etc. The desktop is an important component of the look and feel of a human user interface, but the current state of the industry is too immature for any standardization to materialize on a desktop specification in the immediate future. NOTE: There are some valid arguments for defining some requirements for standards at this level. The goal is to enable a Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 142 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 user to easily go between application platforms and operate common functions in a similar manner. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.6 Windowing System Services 143 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 144 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.7 Graphics Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _J_o_h_n _W_i_l_l_i_a_m_s _H_L_J: _T_h_i_s _i_s _a _f_u_l_l _c_l_a_u_s_e _r_e_p_l_a_c_e_m_e_n_t _f_o_r _D_r_a_f_t _1_3. _I_t _i_s _n_o_t _f_u_r_t_h_e_r _d _d_i_f_f _m_a_r_k_e_d. _d 4.7.1 Overview and Rationale Graphics Services are key components and play an important role in the POSIX Open Systems Environment as it is used today in many different areas of industry, business, government, education, entertainment, and most recently, the home. The number of applications is growing rapidly, with increasing graphics capabilities. Some of these areas are user interfaces, computer-aided drafting and design, electronic publishing, plotting, simulation, animation, scientific visualization, art, and process control. The use of pictorial graphics provides a more intuitive interface and thus facilitates man/machine interaction. Graphics has become a routine part of most organizations today, ranging from hardcopy graphs and charts to user interfaces and complex 3-D visualizations incorporating video and sound. The graphics technology of rendering objects has become dramatically more realistic and hence is used by engineers, architects, artists etc., to enable them to see precisely what their final products, whether automobiles or buildings, will look and behave like under real-world conditions. Graphics has allowed dramatic improvements in the ``look and feel'' of user interfaces and the trend is towards increasing use of these interfaces to interact with computers graphically, via windows and icons and this reduces the time involved in learning to use a computer. Standardization of graphics services has many benefits for application developers, users, and systems integrators. The underlying motivations for considering graphics standards and their relation to the POSIX Open Systems Environment include: (1) Portability: In order to protect investment and achieve independence from a particular technology and a particular supplier of technology, portability at both hardware and software levels is necessary. There are many aspects of portability within graphics, all of which are potential money and time savers. - Applications portability - Graphics package portability Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphics Services 145 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Host machine independence - Device independence +o input devices: dials, mouse, tablets etc. +o output devices: plotters, raster, vector etc. - Window system independence - Programming language independence - Programmer portability - User portability (2) Interoperability/Distributed Graphics: In order to allow applications to execute on one machine and display graphics on remote display servers, standard graphics protocols are necessary. This allows for display of graphics on machines that are incapable of executing particular types of applications and it also facilitates graphics conferencing. (3) Graphics Data Exchange: In order to share or exchange graphical information between diverse applications, standard graphics data exchange mechanisms are necessary. This clause presents a reference model for this component and describes the services provided to application programmers and users. It also describes the current national/international standards, emerging standards, de facto standards, and any existing gaps that need new standardization efforts. 4.7.2 Scope Included within this component are standards in the graphics area that address the following topics : - Application Program Interface (API) Standards - Language Bindings Standards - Metafile and Archive Standards - Device Independent Interface/Protocol Standards - Computer Graphics Reference Model Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 146 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Conformance Testing of Implementations of Graphics Standards - Distributed Graphics Standards - Imaging Standards - Performance Metrics Standards The standards not addressed here are: - Data Exchange Standards - Graphical User Interface Standards - Window Management System Standards 4.7.3 Reference Model Over the past decade many computer graphics standards have been developed. While they are similar in concepts, their underlying reference models are different. This restricts the degree to which the standards are compatible. By producing a reference model to which all future graphics standards are to adhere, compatibility of graphics standards is assured. Formal work on the Computer Graphics Reference Model (CGRM) standard is in progress within the ANSI X3H3.2 committee. It is an international standard that explains the relationships between existing graphics standards and defines relationships between standards in computer graphics and those in other areas. It will form the basis for the next generation of computer graphics standards. Broadly speaking, CGRM provides a framework within which relationships between standards can be described. There are five types of standards in the current family: - _A_p_p_l_i_c_a_t_i_o_n _P_r_o_g_r_a_m _I_n_t_e_r_f_a_c_e (_A_P_I) _S_t_a_n_d_a_r_d_s: These define a programming interface for application programmers. GKS, GKS-3D, PHIGS, and Xlib are examples of standards in this area. - _M_e_t_a_f_i_l_e _a_n_d _A_r_c_h_i_v_e _S_t_a_n_d_a_r_d_s: These standards define representations of graphics for storage and transfer between systems. These are basically file format and file transfer encoding standards. CGM (Computer Graphics Metafile) and PHIGS Archive files are of this type. - _D_e_v_i_c_e _I_n_d_e_p_e_n_d_e_n_t _I_n_t_e_r_f_a_c_e _S_t_a_n_d_a_r_d_s: These standards define the interface between device-independent graphics systems software and Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphics Services 147 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS one or more device-dependent graphics device drivers. CGI (Computer Graphics Interface) is the standard in this area. - _L_a_n_g_u_a_g_e _B_i_n_d_i_n_g _S_t_a_n_d_a_r_d_s: API and device interface standards are functional specifications defined independently from particular programming languages. Each standard has attached language binding standards that state how the functionality should be accessed from a variety of programming languages. - _F_r_a_m_e_w_o_r_k _S_t_a_n_d_a_r_d_s: These include the standardization of a reference model for computer graphics, conformance criteria, and the registration of graphical items. The CGRM describes the current family of graphics standards in terms of the following four levels of abstraction: - _A_p_p_l_i_c_a_t_i_o_n _L_e_v_e_l: This is the level at which applications-related information is composed into abstract graphics related to the application. - _V_i_r_t_u_a_l _L_e_v_e_l: At this level, the graphical output to be displayed is described in terms of output primitives - _L_o_g_i_c_a_l _L_e_v_e_l: At this level, the information necessary to render a primitive on a particular device is assembled. - _P_h_y_s_i_c_a_l _L_e_v_e_l: This level is associated with a particular output device and a collection of input devices. The physical level need not correspond to real devices such as a pen plotter. There could be further layers of the system between the physical level and the hardware, such as the window system. The Application Program Interface (API) is the interface between the application and the graphics system. There are also interfaces to metafiles and archives and to the operator. Here the operator need not mean human operator, but the user of the graphics system; for example, the window system. The Computer Graphics Reference Model can be incorporated into the POSIX OSE reference model as depicted in Figure 4-16. It provides the context for the discussion of graphics services and shows that the graphics services is a component of the overall POSIX OSE and is available to the the application through the POSIX OSE API. The entities and interfaces specific to the graphics services are identified in this clause. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 148 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _________________________________________________________________________ _________________________________________________________________________ Figure 4-15 - Computer Graphics Reference Model Level Structure The entities are: (1) Application Software, such as CAD/CAM/CAE applications, imaging applications, electronic publishing, etc. (2) Application Platform, which consists of graphics libraries such as GKS, PHIGS and Xlib. (3) External Environment, consisting of external entities with which the application platform exchanges information such as input devices, X/PEX servers, hardware buffers, etc. The interfaces are: (1) Application Program Interface (API), which is the programming interface between the application and the application platform. It standardizes the conceptual model, calling sequence, functions, and syntax that a programmer uses to develop a graphics application. Each API standard has an attached Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphics Services 149 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 4-16 - POSIX OSE Graphics Service Reference Model language-binding standard that allows the functionality to be accessed from a variety of programming languages. A standard API in conjunction with a standard language binding promotes application portability, by isolating the programmer from most hardware peculiarities and providing language features readily implemented on a broad range of processors. Examples of APIs in the graphics services area are GKS, PHIGS, PIK, PostScript, etc. (2) External Environment Interface (EEI), which is the interface between the application platform and the External Environment described earlier. In the graphics services area these can be device drivers that are used for communication between the device-independent and the device-dependent functions as well as protocols and file formats. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 150 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 The standardization efforts in the graphics area focus on these two interfaces. 4.7.4 Service Requirements 4.7.4.1 Graphics Concepts Computer Graphics Services can be discussed in terms of the following fundamental graphics concepts: _O_u_t_p_u_t__P_r_i_m_i_t_i_v_e_s The output primitives are the building blocks used to construct graphical objects for display or storage in an archive file. Common output primitives are: - _L_i_n_e - _P_o_l_y_l_i_n_e used to represent a series of straight lines from a set of points. - _M_a_r_k_e_r is a special symbol used to represent semantics of graphical objects. - _F_i_l_l _a_r_e_a is an area with an edge and an interior which may be filled with a solid color or some form of pattern or hash. - _T_e_x_t is an output primitive used to represent strings in two or three dimensional space. - _A_n_n_o_t_a_t_i_o_n _t_e_x_t is text that is always displayed facing the viewer. - _C_e_l_l _a_r_r_a_y_s are areas with rectangular grids which can take on individual colors. - _T_r_i_a_n_g_l_e _s_t_r_i_p is a set of triangles defined by a particular ordering of vertices. - _Q_u_a_d_r_i_l_a_t_e_r_a_l _m_e_s_h is a set of quadrilaterals defined by a grid of vertices. - _S_u_r_f_a_c_e_s: NURBS (Nonuniform Rational B-Spline) - _C_u_r_v_e_s: NURBS (Nonuniform Rational B-Spline) - _C_o_n_i_c_s: Circles, ellipses, parabolas, and hyperbolas Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphics Services 151 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _P_r_i_m_i_t_i_v_e__A_t_t_r_i_b_u_t_e_s Attributes of primitives determine the style of the display of the primitive. For example, lines and edges may have different line styles such as dotted or dashed, text may have different fonts, orientation, and character spacing. A polymarker may be an asterisk or a small triangle. They all may be red in color. General type attributes that apply to almost any output primitive are color, visibility, pickability, and highlight method. _I_n_p_u_t__P_r_i_m_i_t_i_v_e_s Input primitives or logical devices are virtual devices designed to insulate the application from the real input devices. Logical devices include picking devices, locator devices, choice devices, valuator devices, etc. In terms, of actual devices, a locator device might be associated with the first mouse button. _I_n_p_u_t__M_o_d_e_l The input model describes how input primitives and logical devices are related to physical input devices and the degree of control provided to the application over the devices. For example, one control choice might be how feedback is echoed to the operator when a logical locator device is attached to a depressed mouse button. The feedback might be a rectangular cursor or the highlighting of geometry as a cross-hair cursor moves over it. When the button is released the device coordinates are placed in the locator data record and an event is placed in an event queue for which the application can check asynchronously. The method the application uses to determine if a device has data for it is usually described in terms of modes. A common mode is event mode. The application waits a finite time for some event to appear in a queue. If no event comes in the finite time, the application does other processing and eventually comes back to check the queue with the wait for some event. If an event appears, the application determines what type it is and gets the data for that type of event. For a pick device, the data might be all possible graphical primitives that could intersect some aperture, possibly specified in the device coordinate system. _C_o_o_r_d_i_n_a_t_e__S_y_s_t_e_m_s__a_n_d__C_l_i_p_p_i_n_g Part of the graphics services is a means to utilize various coordinate systems. Graphical output has to be described to the graphics system in terms of some coordinate system, relevant to the application and presented to the display device in terms of its own coordinate system, the device coordinate system. It is unlikely that these two coordinate systems will be the same. A graphics system may therefore involve a number of coordinate systems and hence the need to define transformations between them. Some standard types of transformations are scaling, Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 152 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 rotating, translating, reflecting, and projection, such as parallel and perspective. They are used to manipulate objects in a coordinate system and to map from one coordinate system to another. The coordinate systems commonly used are modeling coordinates, world coordinates, view-reference coordinates, normalized projection coordinates, and device coordinates. Clipping is the process of specifying a region in space and restricting graphical output to that region. Only those primitives that define objects in that region will have their output displayed. _O_u_t_p_u_t__M_o_d_e_l The output model is the concept of how graphics objects are created, displayed, and controlled on output devices. The output model defines how to position and organize objects on the screen, and the visual state of these objects such as visible or invisible, hidden lines removed or not removed, picture matches retained structure, picture not consistent with retained structure, etc. More specifically, the output model concept is made up of the: - Transformation pipeline - Rendering pipeline - Retained structures - Nonretained structures - Graphics state - Window systems _E_r_r_o_r__H_a_n_d_l_i_n_g _T_B_D _S_t_o_r_a_g_e_/_A_r_c_h_i_v_i_n_g _T_B_D 4.7.4.2 Graphics Requirements The graphics service requirements of all users of this system can be generalized as: - The ability to create, delete, and modify output primitives. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphics Services 153 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - The ability to specify and edit the primitive attributes globally and individually. - The ability to transform (i.e., scale, translate, rotate, reflect, project, etc.) primitives for construction of more complex objects and for arrangement in the viewing space. - The ability to create and manipulate a database of primitives, to define and edit attributes, to create and combine transformations, and to selectively control the display of graphics primitives. - The ability to display graphical objects constructed in a retained database, or the ability to display primitives immediately, or to display from both a retained database and immediately. - The ability to apply lighting and shading algorithms to collections of graphical objects with multiple light types and sources. - The ability to prepare display data and control the timing of the actual display of the display data. On some systems this is referred to as frame buffer control. - The ability to store and retrieve graphical objects from files. - The ability to control input devices and retrieve data from input devices. - The ability to direct output to a meta-file and retrieve graphics data from a meta-file. - The ability to inquire about all aspects of the graphics environment; e.g., the state of the system at any given time, the actual capabilities of a given hardware platform, the attributes and primitives supported by a given implementation, etc. - The ability to distribute graphics. - The ability to control errors. 4.7.4.3 Application Program Interface Services The major categories of graphics services available in the POSIX OSE API area include: - 2-D graphics API services - 3-D graphics API services Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 154 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Device interface API services - Image processing API services For most of these API standards there exist standard language bindings so that applications using different programming languages can access the same functionality. The choice of which graphics standard API to use will depend on a number of factors: application profile, overall system architecture, equipment available, existing application database interaction, system performance considerations, user interface requirements, management policy, and other external factors. The aim of producing a compatible set of graphics standards in GKS, GKS-3D, PHIGS, PHIGS PLUS, etc. (described in the Standards subclause) is to allow that choice to be made in the most flexible way. 4.7.4.4 External Environment Interface Services The major categories of graphics services in the POSIX OSE EEI area include: - Protocols - File Formats - Device Drivers The choice of which standard to use depends on a number of factors: application profile, system architecture, equipment available, system performance considerations, and other factors 4.7.4.5 Interapplication Software Entity Services _T_B_D 4.7.4.6 Graphics Resource Management Services _T_B_D 4.7.5 Standards, Specifications, and Gaps There are several major standards existing in the computer graphics industry today, that have been approved by National/International organizations such as ANSI, ISO, and IEEE. There are also standards efforts going on in related areas such as application data exchange. These official graphics standards are complemented by de facto standards Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphics Services 155 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS that have been accepted by the graphics industry at large. This document provides a general explanation of these standards, their specifications, and interrelationships. _________________________________________________________________________ _________________________________________________________________________ Figure 4-17 - POSIX OSE Graphics Service Reference Model Standards 4.7.5.1 Current Standards in the POSIX OSE _N_a_t_i_o_n_a_l_/_I_n_t_e_r_n_a_t_i_o_n_a_l PHIGS -- ISO 9592 Parts 1-3 Fortran Language Binding -- ISO 9593-1 Ada Language Binding -- ISO 9593-3 C Language Binding -- DIS 9593-4 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 156 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 The Programmer's Hierarchical Interactive Graphics Standard (PHIGS) is a functional specification of the interface between an application program and its graphics support system. It is an ANSI/ISO standard and provides the following graphics functionality: - A high degree of interactivity - Multilevel, hierarchical structuring of graphics data - Easy modification of graphics data and the relationships among the data - 3-D, as well as 2-D, graphical input and output - Offline storage (and retrieval) of graphics data PHIGS controls the definition, modification, and display of hierarchical graphics data and specifies functional descriptions of systems capabilities, including the definition of internal data structures, editing capabilities, display operations, and device control functions. PHIGS manages the organization and display of data in a centralized database, allowing programmers to define and organize graphical data in a manner most convenient to the application. Such a hierarchical approach is a big benefit and is not available in GKS, another international standard. Objects are defined in the PHIGS graphical database by a sequence of elements, including output primitives, attributes, transformations, and invocations of other object and object part definitions. These elements are grouped into entities called structures. Structures may be related in a number of ways, including geometrically, hierarchically, or according to inherent properties or characteristics, as defined by an application. PHIGS provides tools to use hierarchical data structures with minimal effort by the application programmer. Pictures constructed from geometric models often have a clearly evident structure. This structure can sometimes be easily seen in the repeated use of symbols, in the connections and geometric relationships between objects, or in the overall organization of a complex image. Even if the object's structure is not evident, its underlying data organization may be quite rigorous, well defined, and well understood by the application. PHIGS supports both these cases by separating the definition of graphics data from the actions required to display them. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphics Services 157 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS The structured definition of graphics data inherently reduces repetition and connectivity problems. The repeated use of component objects and the relationships between them can automatically be made a part of an object's definition. The structured definition of data allows images to share component objects, making it faster and easier for application programs to define and modify picture descriptions. Sharing component objects will also reduce storage requirements for graphics data. PHIGS permits rapid dynamic access to a centralized graphics database. This allows PHIGS to support interactive end user application programs and, depending on the capability of the hardware, realtime definition, and modification of graphics data. PHIGS is capable of performing three-dimensional modeling transformations, workstation transformations, and viewing. It also handles two dimensions through a shorthand functionality of three dimensions. In workstation transformations, PHIGS provides another level of display control after the viewing operation that can isolate a section of an image for pan and zoom operations. The National Institute of Standards and Technology (NIST) has developed a test system to help determine whether implementations of PHIGS conform to the specifications of the ANSI standard X3.144. The PHIGS Validation Test (PVT) suite consists of highly portable Fortran programs which examine test conditions and report the results. PHIGS PLUS -- DIS 9592-4 PHIGS Plus Lumiere Und Surfaces (PLUS) specifies a set of extensions to PHIGS that addresses some of the deficiencies in the graphics functionality provided by PHIGS. PHIGS does not include ``higher level'' primitives such as curves and surfaces, and techniques for lighting and shading. Recognizing this, an ad hoc working group was formed to propose a set of extensions to PHIGS to enable these capabilities to be addressed in a standard manner, compatible with the overall philosophy of PHIGS. This set of proposed extensions was submitted to ISO and has since been developed into PHIGS PLUS. PHIGS PLUS enhances PHIGS by providing: - Primitives for defining curves and surfaces - Lighting models Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 158 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Shading of surfaces - Depth cueing - Color mapping and direct color specification PHIGS PLUS is not an international standard yet and is currently at the stage of committee draft. GKS -- ISO 7942; FIPS 120 Fortran Language Bindings -- ISO 8651-1 Pascal Language Bindings -- ISO 8651-2 Ada Language Bindings -- DIS 8651-3 C Language Bindings -- DIS 8651-4 GKS Information Bulletin The Graphical Kernel System (GKS) is a 2-D graphics system and provides no support for 3-D. It is a 2-D graphics API that shields the programmer from differences among various computers and graphic devices. It allows for portability of graphics applications by standardizing the basic graphic functions and the method and syntax for accessing these functions. GKS is an ANSI, ISO standard and is widely used today. It has standard language bindings for Fortran and Pascal. Language bindings for C, Ada, and LISP are currently being worked on. GKS supports the grouping of logically related primitives such as lines, polygons, strings, and their attributes into collections called segments, which cannot be nested. GKS supports many graphical input and output devices such as black/white and color displays, printers, plotters, mice, data tablets, joysticks, and digitizers. GKS-3D -- ISO 8805 Fortran Language Bindings -- DIS 8806-1 Pascal Language Bindings -- CD 8806-2 Ada Language Bindings -- DIS 8806-3 C Language Bindings -- DIS 8806-4 Graphical Kernel System for Three Dimensions (GKS-3D) is an ISO standard and specifies extensions to GKS for defining and viewing three-dimensional wire-frame objects. In addition, the GKS input model has been extended to provide three-dimensional locator and stroke input. GKS-3D allows the operator to obtain information from three-dimensional input devices and to perform hidden line/hidden surface removal (HLHSR) at the workstation. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphics Services 159 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS It does not, however, provide specific functions for controlling rendering techniques such as light source, shading, texturing, and shadow computations that must be done locally at the workstation. Conceptually, all workstations are three- dimensional in GKS-3D, which is made possible by shielding the hardware peculiarities as in GKS. CGI -- DIS 9636 Parts 1-6 Fortran Language Bindings -- DIS 9638-1 C Language Bindings -- CD 9638-4 The Computer Graphics Interface (CGI) specifies a standard functional and syntactical specification of the control and data exchange between device-independent graphics software and one or more device-dependent graphics device drivers. Unlike the graphics standards discussed earlier, CGI specifies an interface at the device-driver level, rather than at the application level. Unlike CGM, which only handles graphical output, CGI handles both input and output, which makes all devices appear as identical, virtual graphics devices. Therefore, this protocol is also known as the Virtual Device Interface (VDI). It provides a standard graphics escape mechanism to access nonstandard graphics device capabilities. CGI allows programmers to write portable device-driver software that is independent of the physical graphics device characteristics. This makes the software portable and compatible with a wide variety of devices. CGM -- ISO 8632 Parts 1-4 The Computer Graphics Metafile for storage and transfer of picture description information (CGM) is a mechanism for retaining and/or transporting graphics data and control information. This information contains a device-independent description of a picture at the level of the Computer Graphics Virtual Device Interface described above. It provides a standard graphics escape mechanism to access nonstandard graphics device capabilities via the metafile. Pictures are described in CGM as a collection of elements of different kinds, representing, for example, primitives, attributes, and control information. It is multipart ANSI, ISO standard. Part 1 contains the semantics of all the elements. Parts 2, 3, and 4 contain the syntax of three different bindings of the standard, namely: character-coded, binary, and clear- text encodings. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 160 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 PHIGS Archive files -- ISO 9592 Parts 2-3 Parts 2 and 3 of the PHIGS standard define an archive file format for storage and transfer of PHIGS structures and structure network definitions from the CSS (Central Structure Store). Part 2 describes the file format and Part 3 a clear text encoding. This encoding is constructed using the same techniques as used by CGM. 4.7.5.2 Emerging Standards in the POSIX OSE IPI -- JTC1# 1002 Image Processing and Interchange is a functional specification and several language bindings for an Application Programmer Interface to Imaging. The standard defines the data objects, primitive operations, and a reference model. The API supplies the basic building blocks upon which applications requiring imaging functionality can be built within conventional, distributed, and image oriented computing environments. The International Standard for Image Processing and Interchange includes three parts: Part 1 Common Imaging Architecture Part 2 Programmer's Imaging Kernel (PIK) Part 3 Image Interchange Format PEX -- PHIGS Extensions to X PEX is a network protocol extension to the X Window System. As many applications require 3-D graphics and other forms of input devices such as dials and button boxes, all of which are not supported by X, it became necessary to extend the X Protocol to include 3-D graphics. PHIGS was selected as the application program interface because of its acceptance as a 3-D standard, its high degree of input ability, and its powerful database editing capabilities. In 1988, the MIT X Consortium contracted to add 3-D and extended input extensions to the X protocol and the first release of PEX as a sample implementation (PEX-SI) was made in January 1991 but is not yet available commercially. Using PEX, PHIGS workstations would be defined as X Windows. For the programmer, X, PHIGS, and PEX standards provide portability. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphics Services 161 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Conformance Testing of Implementations of Graphics Standards -- DIS 10641 The existence of any standard brings up the question of how one can be sure whether a product claiming to conform to the standard does in fact conform. If this question is not addressed then the process of standardization becomes pointless. The general approach to software validation is through testing. The method is to subject the software to a collection of test cases and observe the results. If the results are different from what is expected, the software does not conform to the specification. The ANSI X3H3.7 committee is working on a standard that specifies the characteristics of standardized test sets for use in determining the conformance of implementations of graphics standards. It will also provide guidance to functional standards developers concerning the content of their standards and the conformance rules within standards. 4.7.5.3 Gaps in Available Standards (1) Applications have different behaviors for similar functions which hinders user portability. By adopting a uniform approach (Graphics_Style_Guide) users can switch between applications without a lot of training. (2) Current existing standards allow a wide interpretation for implementors of the standards thus denying the applications useful controls. In order to achieve true portability in a distributed environment, applications will need control and deterministic functionality. (3) How window standard fits into CGRM (4) Current existing standards do not address solids. (5) The ability in a standard defined way to perform cut and paste between applications. (6) Current standards do not allow nonretained graphic methods to do lighting and shading. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 162 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.7.6 OSE Cross-Category Services Not applicable. 4.7.7 Related Standards IGES, NBSIR 86-3359 See 4.5. X Window System Data Stream Definition Parts 1-4 (Being worked on in ANSI X3H3.6) Part 1: Functional specification Part 2: Data Stream Encoding Part 3: KEYSYM Encoding Part 4: Mapping onto Open Systems Interconnection (OSI) Services The X Window System is a network based windowing and 2-D graphics system. It uses the client-server model. The client and server can reside on the same or different platforms. The client is an application program executing anywhere on the network and displaying on the screen. It does this by making calls to a library called Xlib to generate protocols. The X server is the software that accepts protocols sent by the client and processes them for display. It also accepts input from a mouse or keyboard for return to the application program. The X protocol specifies the data stream encoding between the server and the clients. The X Protocol originally developed by the X Consortium at MIT, is being standardized by the ANSI X3H3.6 committee. The encoding will provide a standard interface for applications running on both distributed and nondistributed environments having high-speed, reliable, network based communications. X Protocol is designed to work in a heterogeneous network environment. Below the X Protocol, any lower layer of network can be used, as long as it is bidirectional. Currently TCP/IP and DECnet are the two network protocols commonly supported in X servers. Part 4 of this standard specifies the mapping of X Windows onto the OSI Services. XLIB Xlib--C Language X Interface is the common component of X Windows and resides on all X-based systems. Although X is fundamentally defined by a network protocol, application Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphics Services 163 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS programmers do not interface directly with the X Protocol. Instead, they interface to the X Protocol through Xlib. The X Window System uses the client-server model. The client is an application program executing anywhere on the network and displaying on the screen. It does this by making calls to Xlib to generate protocols. The X server is the software that accepts protocols sent by the client and processes them for display. From a graphics perspective, Xlib is a 2-D graphics library and provides graphics primitives like points, lines, and arcs. It has a Graphics Context (GC) to allow modification of graphics attributes such as line type, line width, color, and font type. The Xlib developed initially at MIT is in the Public Domain and is a de facto standard for windowing and 2-D graphics. It has been adopted by major computer vendors and industry groups. It is currently being considered for standardization by the IEEE P1201 committee. PostScript The PostScript language from Adobe Systems Incorporated is a simple interpretative programming language with powerful graphics capabilities that has become a de facto industry standard. It is a high-level, device independent language that is primarily used to describe the appearance of text, graphical shapes, and images on printed pages or screens. Programs written in this language may be used to communicate information from a composition system to a printing system. PostScript programs are created, transmitted, and interpreted in the form of source text and there is no compiled or encoded form of this language. SGML, ISO 8879: 1986 See 4.5. IGES/PDES Organization (IPO) See 4.5. ISO/IEC TC184/SC4 (STEP) See 4.5. ISO/IEC TC130 (Color Prepress) Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 164 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 ISO/IEC JTC1/SC18 (Text and Office Systems ISO/IEC JTC1/SC29 (Multimedia Coding) 4.7.8 Open Issues None. 4.7.9 Performance and Capacity Specification Metrics Picture-Level Benchmark -- (Developed by the GPC Committee) The Picture-Level Benchmark (PLB), developed by the GPC (Graphics Performance Characterization) Committee, is a software package that provides a standard method of measuring graphics display performance for different hardware platforms. The GPC Committee consists of the following member companies: DEC, DuPont Pixel Systems, Evans & Sutherland, HP/Apollo, IBM, Intel, Integraph, Megatek, Prime Computer, Silicon Graphics, Sun, and Tektronix. NCGA (National Computer Graphics Association) is the administrator for the GPC work. The PLB is a part of ongoing work by the GPC Committee to develop standardized methods of measuring graphics performance. The PLB was developed to clear the confusion regarding graphics performance measurement. Vectors or polygons per second can vary greatly according to size, orientation and other parameters. With the PLB, graphics display performance for the user's specific application can be evaluated using the same methodology and measurement criteria for different hardware systems. This allows ``apple-to-apple'' comparisons of graphics display performance. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphics Services 165 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 166 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.8 Character-Based User Interface Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _C_h_a_r_l_e_s _S_e_v_e_r_a_n_c_e 4.8.1 Overview and Rationale This clause describes the system services that are related to character- based terminals. It describes both the application program interfaces to character-based terminals and also the look and feel of the interaction between the user and the user interface equipment. This clause is one portion of the User Interface API and EEI as described in Section 3. 4.8.2 Scope The scope of this clause is limited to the services and standards required to support character (non-bitmapped) terminals. 4.8.3 Reference Model This subclause identifies the entities and interfaces specific to the character-based terminal services of an OSE. As illustrated in Figure 4-18, the components of character-based interfaces are broken into two groups: those specifications that impact the application programming interface and those that impact the external user interface. This reference model is consistent with and expands on the reference model in Section 3. 4.8.4 Service Requirements The fundamental service requirements for character-based terminals are to allow applications to be written that make use of the features of a wide variety of terminals using a single terminal-independent interface. The look and feel of user interactions should be similar between applications to make moving between applications as simple as possible. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.8 Character-Based User Interface Services 167 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 4-18 - Character-based Terminal Reference Model 4.8.4.1 Application Program Interface Services The service requirements at the Application Program interface are as follows: - Ability to support a wide variety of character-based terminals using a single terminal-independent API. - Ability to support a wide variety of block mode terminals using a single terminal-independent API. - Ability to support all types of terminals using a forms-based API. These interfaces should be complete enough to allow a wide range of applications to be implemented using the interfaces. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 168 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.8.4.2 External Environment Interface Services The look and feel of user interactions with applications should be standardized to make moving between applications as simple as possible. The areas that require standardization are: - Placement of text on the screen - Style of selecting commands - Ways of using online help - Ways to do common functions such as page forward and page backwards. These interactions will differ slightly between different types of terminals because of limitations of the terminals. 4.8.4.3 Related Service Requirements To be provided. 4.8.5 Standards, Specifications, and Gaps 4.8.5.1 Current Standards in the POSIX OSE None. 4.8.5.2 Emerging Standards in the POSIX OSE _F_I_M_S ANSI CODASYL. Working draft available for Forms Interface Management System (FIMS), which covers the interface between a programming language and any form-filling application on a computer or terminal screen. This specification addresses some of the services requirements for a forms-based user interface. _C_R_S: _P_a_r_t_s _o_f _P_O_S_I_X._2 _m_i_g_h_t _b_e_l_o_n_g _h_e_r_e. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.8 Character-Based User Interface Services 169 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.8.5.3 Gaps in Available Standards 4.8.5.3.1 Standards/Specifications Outside the POSIX OSE 4.8.5.3.1.1 _G_o_v_e_r_n_m_e_n_t_/_L_e_g_a_l__S_t_a_n_d_a_r_d_s None. 4.8.5.3.1.2 _D_e__F_a_c_t_o__S_t_a_n_d_a_r_d_s _C_u_r_s_e_s Curses is a set of subroutines that provide a terminal-independent interface to applications. Many different types of character-based terminals are supported. Curses lacks complete support for flexible user input. This standard satisfies some of the service requirements for character mode terminals. _S_A_A SAA is an interface specification to a large class of block mode terminals. This standard satisfies some of the service requirements for controlling block mode terminals. 4.8.6 OSE Cross-Category Services d 4.8.6.1 Security 4.8.6.2 Administration It is important to allow the system management personnel to configure the system to designate where each terminal is connected. Also needed is the ability to add support for new terminals without affecting the application interface. 4.8.6.3 Configuration Management Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 170 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.8.6.4 Fault Management 4.8.6.5 Performance 4.8.6.6 Accounting 4.8.6.7 Training 4.8.6.8 Systems Integration Interface Requirements None. 4.8.7 Related Standards None. 4.8.8 Open Issues None. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.8 Character-Based User Interface Services 171 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 172 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.9 User Command Interface Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _W_e_n_d_y _R_a_u_c_h _H_L_J: _W_e_n_d_y _h_a_s _p_r_o_v_i_d_e_d _a _f_u_l_l _c_l_a_u_s_e _r_e_p_l_a_c_e_m_e_n_t _f_o_r _D_r_a_f_t _1_3; _i_t _i_s _d _n_o_t _f_u_r_t_h_e_r _d_i_f_f _m_a_r_k_e_d. _d 4.9.1 Rationale and Overview Although system-level services are necessary for application portability and interoperability, they are insufficient for many users' system needs. To maximize portability, users also require the commands, command interpreter (shell), compilers, editors, and other utilities that have been traditionally associated with many operating systems. These command interface services facilitate a successful port and help users to manage and maintain applications and to solve problems on an ad hoc basis. The standardization of these utilities allows users and programmers to move from platform to platform without having to relearn the command interface for each application platform. 4.9.2 Scope This clause describes how a user interacts with an application platform by executing general purpose commands. This command interface is also available to applications so that applications also can execute commands. A standardized command interface provides a consistent, interactive environment across platforms for users and programmers. Commands that are outside the scope of this clause are: - System administration and installation commands - Text formatting programs - Database commands - Networking and communications commands - Graphical user interfaces Networking commands and graphical user interfaces are described in other clauses of the POSIX Open Systems Environment Guide. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.9 User Command Interface Services 173 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.9.3 Reference Model The use of the command interface services presented in this clause is consistent with the reference model in Section 3. The POSIX OSE reference model for the command interface also is consistent with typical implementations for user command languages in traditional UNIX-based systems. _________________________________________________________________________ _________________________________________________________________________ Figure 4-19 - POSIX OSE Reference Model for Command Interfaces As Figure 4-19 shows, the command interface is available both to users (through the External Environment Interface) and to applications (through the Application Programming Interface). Any operating system implementation can reside underneath the APIs and EEIs. The API and EEI command interfaces provide access to a software component (known as a command interpreter or shell) that interprets the commands issued by either the user or the application. The command interpreter acts as an intermediary between the command API and EEI and the base application platform's system-level services. The command interpreter reads the commands entered and parses them. Depending on the type of command (e.g., utility or built-in shell command), the command interpreter either executes the command for the user or application, using the base application platform's system-level services, or it calls on the system-level services to create a new process which executes the command. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 174 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 None of the methods of executing commands have an impact on the API or EEI specifications. The commands interfaces may be available to users and applications either locally or remotely. Remote invocation of a system's command interfaces is provided through networking and data interchange capabilities. These are described in 4.3 and 4.5. Alternatively, remote access to a system's command interfaces may be available through certain interapplication services. 4.9.4 Service Requirements There are three major aspects of command interface services that must be addressed for practical support of multivendor application portability and system interoperability. The first aspect consists of the basic functionality and interfaces provided for generally usefulness. The second aspect of command interface services concerns the ability to move applications, such as script files, between platforms. The third aspect concerns user portability so that the same user interface is available on different platforms. Since most command interfaces are available at the API and EEI, the service requirements for the API and the EEI are very similar. This clause, therefore, discusses primarily the EEI command interface requirements. The API service subclause discusses only the additional service requirements for applications. 4.9.4.1 External Environment Interface Services Users need a number of capabilities in order to work on a system. On a traditional system, these are implemented by providing interactive commands entered via a keyboard. However, as graphical user interfaces evolve, these commands may also be implemented by clicking on a mouse in a particular area of the screen, by a ``touchie-feelie'' screen, a tablet, or other input device. The major services at the EEI provide the following abilities: - Capture the output of a command or application into a file - Redirect the input for a command from a file - Direct the output of a command to be used as the input to another command - Execute applications Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.9 User Command Interface Services 175 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Get online help for commands or applications - Manipulate file contents: +o Cutting +o Pasting +o Concatenating +o Converting +o Sorting +o Reformatting +o Comparing +o Searching for regular expression - Edit files +o Interactive editors +o Batch or ``stream'' editors - Display files +o Pausing when necessary +o Display only selected ranges of files - Manipulate files +o Create +o Delete +o Rename +o Move +o Copy - Print files - Perform network functions Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 176 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 +o File transfer +o Remote execution of commands +o Remote file printing - Manipulate and display directories +o Create +o Delete +o Display +o Destroy (Delete a directory and all its subdirectories and files) - Control file and directory permissions - Communicate with other users +o Electronic mail +o Online interaction where two or more users communicate with each other simultaneously - Control the application execution environment +o Execute applications in the background +o Abort applications running in the foreground or background +o Suspend an application +o Move an application running in foreground mode to the background - Schedule commands for periodic execution - Control the users' input equipment, such as a terminal or graphical user interface - Manage local environment and configuration information - Query local environment and configuration data - Configure an environment for an international locale. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.9 User Command Interface Services 177 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.9.4.2 Application Program Interface Services In a command API, the output syntax of the commands and command responses (such as error messages) need to be standardized, in addition to the calling sequence and allowable inputs. Such standardization is necessary to allow applications executing a command to reliably parse the output of that command. The API should be able to access all of the services available to the user at the EEI. The additional service requirements for the API are as follows; - Ability to provide the input to the command and access the output of the command when necessary - Ability for the application to detect and correct errors as the command is executed - Ability to abort or suspend the command as it is executing. It is also important to have the ability to create script files which are combinations of commands. The scripting language developed for this purpose is an application development language. The scripting language has the following requirements: - Conditional execution primitives - Repeated execution primitives - Ability to display output - Ability to prompt the user for input - Ability to execute commands and obtain error information. The services and standards for the scripting language are described in this clause, rather than in the Languages clause 4.1, because it is so closely related to the command interface. 4.9.4.3 Interapplication Entity Services These services enable remote users and applications to access and execute a system's command interfaces as if they were directly connected to that system. The major categories of interapplication entity services include the following: - Login and use hosts on a network as if the users logging-in were directly connected to the local terminal Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 178 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Remotely execute a system's shell commands as if the user were directly connected to a local terminal - Copy files between hosts without going through a network file transfer program - Find out who else is logged into the machines on a local-area network - Query the status and uptime of all machines on a local-area network. 4.9.5 Standards, Specifications, and Gaps There are currently no formal standards for command interfaces. There are, however, several command-interface standards-development activities underway. In addition, there are several consortia-defined specifications and de facto specification standards for commands, shell, and utilities services and interfaces. Table 4-10 summarizes the shell and utilities standards and specifications and work in progress. Table 4-10 - Shell and Utilities Standards Activities __________________________________________________________________________________________________________________________________________________ Service Specification Subclause ____________________________________________________________________ Shell and Utilities IEEE POSIX.2 {_r_e_f} 4.9.5.? User Portability Extension (UPE) IEEE POSIX.2a {_r_e_f} 4.9.5.? Shell, Utilities, and UPE X/Open XPG 4.9.5.? OSF OSF/1 System V: 1989 SVID Berkeley BSD 4.x UNIX __________________________________________________________________________________________________________________________________________________ 4.9.5.1 Current Standards 4.9.5.1.1 International and National Standards There are no currently completed or approved international or national standards for commands and utilities. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.9 User Command Interface Services 179 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.9.5.2 Emerging Standards 4.9.5.2.1 International and Other Formal Standards When completed, the IEEE POSIX.2 {_r_e_f} standard will define a source code interface to command interpretation or shell services and common utility programs for application programs. These services and programs are complementary to those specified by POSIX.1 {2}. The IEEE POSIX.2a {_r_e_f} User Portability Extension will supplement POSIX.2 {_r_e_f} by extending the specifications to promote the portability of users and programmers, in addition to applications, across conforming systems. Toward this end, the POSIX.2a {_r_e_f} specifications expand the number and type of utilities specified, and enhance the features of a number of POSIX.2-specified utilities, to provide a consistent interactive environment. The consistent interactive environment does not include emerging technologies such as graphical user interfaces, which are under development by different standards groups. Parts of POSIX.2 {_r_e_f} go beyond the current service requirements and include a number of software development and debugging commands and utilities services. These are included in the POSIX.2 specification because of the traditional development orientation of UNIX systems. These software development and debugging services are not included in this clause because this clause includes more general and universal services, such as copying a file and reading a directory. Although the POSIX.2 {_r_e_f} and POSIX.2a {_r_e_f} specifications are still in draft stages, they are relatively complete, and portions of the emerging standard are believed to be mature and stable. When the commands, shell, and utilities specifications are completed and approved, the resulting IEEE POSIX.2 {_r_e_f} and POSIX.2a {_r_e_f} standards will be submitted to ISO/IEC JTC1 for adoption as international standards. At that time, POSIX.2 and POSIX.2a will be combined into a single integrated international standard (ISO/IEC 9945-2). 4.9.5.3 Gaps in Available Standards There are no formal interapplication standards that address the remote access and execution of a system's command interfaces. The Berkeley BSD UNIX de facto standard addresses all these service requirements, however. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 180 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.9.5.3.1 Public Specifications Public specifications that include the POSIX.2 {_r_e_f} and POSIX.2a {_r_e_f}, and go beyond these standards to also include the traditional UNIX-based command interfaces for software development, system administration, the UUCP (UNIX-to-UNIX Communications Protocol) utilities, and parts of the POSIX.4 realtime extensions are available from a number of organizations. These include: - X/Open's XPG3 specifications, Volume 1 and part of Volume 3 - OSF's OSF/1 Application Environment Specifications (AES), software documentation, and software - University of California at Berkeley BSD UNIX - AT&T System V Interface Definition (SVID) and System V UNIX. 4.9.6 POSIX OSE Cross-Category Services 4.9.6.1 Internationalization The ANSI C, IEEE POSIX.1, and IEEE POSIX.2 specifications contain limited capabilities for obtaining and defining locale-specific information. In addition, some of the utilities described in the POSIX.2 specifications contain requirements for standardized multilingual and multicultural support (e.g., localization requirements such as date formats and collation sequences, and support for international character sets). 4.9.7 Related Standards Several standards activities are in progress to address additional commands interfaces that are traditionally included in UNIX and UNIX-like systems. The following standards are examples: - IEEE 1003.4 Realtime Extensions for POSIX - IEEE 1003.7 POSIX System Administration Extensions - IEEE 1003.18 Platform Environment Profile (PEP) standard, which identifies and combines the standards dealing with POSIX.1, POSIX.2, POSIX.2a, and the related standards Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.9 User Command Interface Services 181 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.9.8 Open Issues _C_o_n_f_o_r_m_a_n_c_e__T_e_s_t_i_n_g Command interface standards must address conformance testing. Although the POSIX.2 standard is still in a draft stage, work has already begun in the IEEE 1003.3.2 Conformance Test Methods Group to define test assertions for the POSIX.2 standard. _U_U_C_P The UUCP (UNIX-to-UNIX Copy Protocol) services and commands, for electronic mail and file copying, which are traditionally included in UNIX and UNIX-like systems are not addressed by any standards effort. Among other reasons, UUCP is not currently being addressed because of the inability of the POSIX groups to decide whether the UUCP services and commands should be standardized in the POSIX.2 Group (since UUCP is a traditional UNIX service with traditional command interfaces) or in the networking groups (since UUCP is an electronic mail and file copying facility that works on networks). Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 182 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.10 Transaction Processing Services d _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _B_o_b _G_a_m_b_r_e_l _B_a_s_e_d _o_n _i_n_p_u_t _c_r_e_a_t_e_d _b_y _C_a_r_l _H_a_l_l _o_f _P_1_0_0_3._1_1, _w_i_t_h _c_o_n_t_r_i_b_u_t_i_o_n_s _f_r_o_m _J_e_r_e_m_y _D_e_n_n_y, _J_o_h_n _P_e_n_n_y, _P_a_t_r_i_c_k _P_r_a_n_g_e, _a_n_d _J_e_f_f _D_e_M_e_n_t _R_e_v_i_s_e_d _i_n _d _D_r_a_f_t _1_3 _w_i_t_h _i_n_p_u_t _f_r_o_m _D_o_r_m _F_u_l_t_o_n _o_f _P_1_0_0_3._1_1. _d 4.10.1 Overview and Rationale The database management clause (see 4.4) described some transaction processing service requirements (specific to databases). This clause d describes the complete set of transaction processing services from the d application software point of view. Note that transaction processing d services have long been been regarded, variously, to be within the domain d of databases or within the domain of operating systems, and more recently d within the domain of interconnect. These services are more broadly d applicable and so are treated here as a separate clause. d Transactions (``units of work'') have boundaries (start points and end d points) that are determined by the action of the transaction application d program. The transaction application program can request to either d commit or rollback the work done in the transaction when it identifies d the end point. The system will complete a commit operation only if all operations performed during the transaction can complete successfully. Otherwise the system will abort the transaction (rollback the work done d by it) and notify the transaction application program of this action. d d The following is quoted with a few editorial changes from ISO/IEC DP 10026-1 {_r_e_f}, the ISO Distributed Transaction Processing standard draft: A transaction is characterized by four properties: atomicity, consistency, isolation, and durability. These are the _A_C_I_D properties. Atomicity implies that the operations of a unit of work are either all performed, or none of them are performed. Consistency implies that the operations of a unit of work, if performed at all, are performed accurately, correctly, and with validity, with respect to application semantics. Isolation implies that the partial results of a unit of work are not accessible, except by operations which are part of the unit of work. Isolation also implies that units of work which share bound data are serializable. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.10 Transaction Processing Services 183 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Durability implies that all the effects of a completed unit of work are not altered by any sort of failure. d 4.10.2 Scope This clause deals with the transaction processing services needed for a d large number of styles of transaction processing including the following: d - Transactional access to a single database manager on a single d machine d - Transaction access to nondatabase ``resource managers'' (such as d the software managing the cash in an automatic teller machine d - Distributed Databases--databases spanning multiple machines, but d accessed by application programs as if just a single database d - Online Transaction Processing (OLTP)--the scheduling of d ``transaction programs'' based on terminal input with consolidated d recovery of the database updates and the terminal messages d - Distributed Transaction Processing (DTP)--different machines d running multiple application programs with multiple databases, d using a client/server or conversational application-to-application d communications paradigm d Note that Transaction Processing Services are used in all of the above d situations, and others too. d Finally, it should be noted that ``transactions'' are not really d ``messages,'' but rather ``units of work'' that may encompass multiple d messages. Furthermore, while traditionally, ``transaction processing'' d has usually been synonymous with ``OLTP'' where so-called ``immediate d transactions'' are the norm, other types of transactions are also d covered: ``batch transactions'' (where the work is done in the d ``background'') and ``deferred transactions'' where there may be a time d dependence on the transaction, such as a fixed start time. d This clause addresses the current work in progress in groups such as ISO and others. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 184 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.10.3 Reference Model This subclause addresses the conventional Transaction Processing Reference Model, the POSIX OSE Reference Model (incorporating transaction d processing considerations), and other important real world considerations d introduced by Transaction Processing. d 4.10.3.1 Conventional Transaction Processing Reference Model d A model for transaction processing is developed here to complement the POSIX system model. Current work in progress by the POSIX.11 Transaction Processing Working Group and other groups such as ISO/IEC JTC 1/SC21 Open Systems Interconnection--Distributed Transaction Processing may result in a Transaction Processing Reference Model more suitable than the one developed here. At that time, such a model will be referenced and incorporated into the POSIX OSE reference model. Until that time, the current model will be used as a convenient means for describing the services needed in this domain. While transaction processing services have usually been thought of as d applying to databases, the applicability goes further. Nonetheless, the d description given here of the transaction processing model shows how the d transaction processing program can view the transaction services as an d extension of the the Database view of the POSIX OSE reference model as d shown in Figure 4-11. From the transaction application program point of view, a transaction processing system has additional capabilities that go beyond those provided by database systems. These services to the transaction application program are provided at an API that is called the d _T_r_a_n_s_a_c_t_i_o_n _M_a_n_a_g_e_r _A_P_I. (See Figure 4-20.) For convenience in d discussing the model, the provider of those services is called the _T_r_a_n_s_a_c_t_i_o_n _M_a_n_a_g_e_r (TM). The transaction application program requests services provided by the _T_P d _r_e_s_o_u_r_c_e _m_a_n_a_g_e_r (e.g., a database manager) via the _T_P _r_e_s_o_u_r_c_e _m_a_n_a_g_e_r d _A_P_I. The transaction manager API and the TP resource manager API are d called the _t_r_a_n_s_a_c_t_i_o_n _s_e_r_v_i_c_e_s _A_P_I and provide all the services needed d by transaction application programs. d The ACID properties are maintained for each managed resource by a _T_P _R_e_s_o_u_r_c_e _M_a_n_a_g_e_r (_T_P_R_M), coordinated by a _T_r_a_n_s_a_c_t_i_o_n _M_a_n_a_g_e_r. The interface between the TP Resource Manager and the Transaction Manager will be called the _T_r_a_n_s_a_c_t_i_o_n _M_a_n_a_g_e_r/_T_P _R_e_s_o_u_r_c_e _M_a_n_a_g_e_r _S_I_I (_T_M/_T_P_R_M _S_I_I). The ACID properties can be applied not only to resources such as databases, but also to other resources that might not be obvious. For instance, a transaction that dispenses cash may wait until the cash dispensing machine has signaled completion before considering the transaction complete and updating involved accounts. This illustration Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.10 Transaction Processing Services 185 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 4-20 - The Conventional Transaction Processing Model d also shows the limits of transaction processing resource management. The d machine could signal completion, but a mechanical problem could prevent the cash from being dispensed correctly, undetected by the system. Besides database TPRMs and miscellaneous nondatabase TPRMs, a third class d of of TPRMs exist: Communications TPRMs (cTPRM). Services provided by d cTPRMs are used when two cooperating transaction application programs d need to communicate with each other in the context of the same d transaction. At least two communications paradigms have been identified d as beneficial to cooperating transaction applications programs: d client/server (RPC, single request/response) and conversational (peer- d to-peer, dialog). d 4.10.3.2 POSIX OSE Reference Model (with Transaction Processing) The conventional transaction processing model is shown integrated into d the POSIX OSE Reference Model in Figure 4-21. Because the POSIX OSE Reference Model does not address System Integration Interfaces (SIIs) per se, they are not shown in the integrated model. What is shown are the d transaction processing services APIs and EEIs. d d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 186 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _________________________________________________________________________ _________________________________________________________________________ Figure 4-21 - The POSIX OSE Transaction Processing Reference Model d 4.10.3.3 Real World Considerations The POSIX OSE Reference Model does not provide for a way to expose the details of the Application Platform. In the Transaction Processing world, as shown in the conventional Transaction Processing Reference Model (see 4.10.3.1), the existence of Transaction Managers and multiple TP Resource Managers connected by the TM/TPRM SII is important. One way d to think about the real world implications of this is that TP Resource d Managers and the Transaction Managers could both be implemented in the d Application Platform as separate entities, connected to each other by the d TM/TPRM SII. This does not, however, imply that the two must be d implemented as separate entities, though there are advantages to the user d if they are separate. d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.10 Transaction Processing Services 187 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.10.4 Service Requirements Services provided via the Transaction Processing Services API are d described in 4.10.4.1. Services to enable the distribution of d transaction processing are described in 4.10.4.2. General services, mostly performing administrative functions, are described in 4.10.4.4. d Services provided across the TM/TPRM SII are briefly described in d 4.10.4.5. d 4.10.4.1 Application Program Interface Services This subclause describes the major categories of services available at d the POSIX API. d The Transaction Services API provides various services to the application d programmer: d Transaction Demarcation d Ability to indicate the start of a transaction. d Ability to indicate a transaction has ended successfully (commit) d or unsuccessfully (rollback). d Ability to indicate the beginning and ending of nested d ``subtransactions'' whose commitment is independent of the ``parent d transaction''. (Nested within a parent transaction can be multiple d subtransactions. Subtransactions are independent of each other, d and whether subtransactions commit or not does not affect the d commitment of the parent.) d The ability to suspend and resume transaction mode (to do work d which is not be committed or rolled back when the transaction is d completed). This can be thought of as nesting nontransaction work d within a transaction. d Ability to explicitly include or exclude items from a transaction. d _R_J_G: _P_O--_t_h_i_s _w_a_s _y_o_u_r_s. _I_s_n'_t _t_h_i_s _r_e_a_l_l_y _t_h_e _a_b_o_v_e _n_e_s_t_i_n_g d _i_t_e_m? d Communications Between Transaction Application Programs d Ability to call another transaction application program (possibly d remote) within the context of a transaction. d Ability to open a dialog and send and receive ``messages'' to and d from another transaction application program (possibly remote) d within the context of a transaction. d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 188 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 NOTE: The above services provide ``Distributed Transaction d Processing.'' The above services often go by shorthand names such d as ``Remote Procedure Call (RPC),'' ``Single Request/Response,'' or d ``Client/Server,'' in the first case, and ``Dialogs,'' d ``Conversations,'' or ``Peer-to-Peer'' in the second case. d Terminal Communications d Ability to send and receive messages to and from terminals within d the context of a transaction (i.e., messages sent to terminals are d not to be actually delivered unless the transaction commits. d Transaction Program Scheduling d Ability to cause to be started another transaction application d program outside of the context of this transaction. Involved here d are two transactions: one starts the other. The actual scheduling d of the second transaction can be dependent on the completion or not d of the original transaction. d Transaction Message Queuing d Ability to define a ``message'' (based, possibly, on screen input d from the end user) that, from the application point of view, d precisely defines a unit of work to be done by this transaction or d another transaction. d Ability to ``send'' a message to another transaction application d program. d Ability to retrieve the next message (and then act upon it) d Ability to prioritize and associate start times with messages d NOTE: The actual handling of messages can be dependent on the d completion or not of the original transaction. d NOTE: Several of the above services are similar to but semantically d different from similar sounding services in other clauses of this d section. They are listed here because they are ``transactional''; i.e., d the concept of a transaction and the ACID properties are provided by d these services. d TP Resource Managers provide services usable by the transaction application program and are made visible by the TP Resource Manager API. An example of this is the Database API covered earlier in this document. NOTE: TP Resource Managers, in general, ``protect'' a critical resource. Databases are good examples of TP resource managers where the resource actually being protected is the data, for example, of an enterprise. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.10 Transaction Processing Services 189 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Often the data of an enterprise reflects the amount of a real resource such as cash holdings. In this case a tangible resource is indirectly protected by a TP resource manager. The importance to the enterprise in insuring that the data (quantifying money) is accurate, should be obvious. Other TP resource managers, on the other hand, could protect an actual, tangible resource. An example of such a TP resource manager is the program that controls the cash drawer of an automated teller machine. The resource protected is the cash in the drawer. The actual application program interface of the TP resource manager protecting that resource could include the ability to reduce the amount of money in the drawer (by pushing it out of the machine). A transaction application program using two TP resource managers (a conventional database manager that keeps track of the balance in accounts, and the teller machine's cash drawer TP resource manager) would want to insure that the two TP resource managers decrement both the cash and the balance of the correct account in the context of a single transaction (i.e., with the ACID properties.) The TP Resource Manager API, then, generally provides the following services: (1) Ability to increment or decrement a valuable resource by a certain amount. (2) Ability to determine the amount of a valuable resource that remains. Specific capabilities for the very wide variety of specific TP resource managers, cannot, of course, be documented here. d 4.10.4.2 External Environment Interface Services When two or more machines are involved in the same transaction, the d following service is required: d - The ability for two application platforms to interoperate with each d other (pass along global transaction identifiers, participate with each other in commitment process, participate with each other in recovery). 4.10.4.3 Interapplication Software Entity Services Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 190 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.10.4.4 OLTP Resource Management Services The services listed in this subclause are not provided by application program interfaces or external environment interfaces. d - Management Services -- Ability to control the operation of the d transaction processing services, including the ability to assign d dispatching priorities to individual transaction application d programs. d - Monitoring Services -- Ability to collect data on resource utilization for purposes such as performance analysis and accounting (data on utilization of the transaction processing d services resources: processes, connection pools, ...). d - Modeling Services -- Ability to predict the system resources needed d to process a given transaction processing workload. d - Directory/Namespace Services -- Ability to map names to addresses. - Recovery/Restart Services -- Ability to recover and restart d transactions involving one or more transaction application programs d using one or more TP Resource Managers. d - Test Services -- Ability to automatically generate tests for d workload simulation, etc. d - System Configuration Services -- Ability to replace or add d transaction application programs without the need to shut down the d execution environment. d 4.10.4.5 Services Provided at the TM/TPRM SII _H_L_J: _R_J_G _a_s_k_e_d _f_o_r _t_h_i_s _t_o _b_e _a_n ``_i_n_f_o_r_m_a_t_i_v_e _s_u_b_c_l_a_u_s_e.'' _T_h_e _o_n_l_y d _w_a_y _t_o _d_o _t_h_a_t _i_s _t_o _m_a_k_e _i_t _a _N_O_T_E: d NOTE: For application portability it is not required that the d application platform actually consist of Transaction Managers and TP d Resource Managers, but in the new age of Open Systems, there are clear d advantages in doing so. Two advantages seem obvious: the ability to d ``mix and match'' Transaction Managers and TP Resource Managers from d different vendors; and the ability of a user to construct his/her own TP d Resource Manager to manage particular critical resources. A market has d already developed for ``plug compatible'' TMs and TPRMs. All TPRMs at d this printing are Database type TPRMs. It is expected that a market will d also develop for Communications type TPRMs. It is not at all clear that d the industry will develop other types of widely applicable TPRMs, thus d forcing users to develop their own. Users could use the interface d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.10 Transaction Processing Services 191 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS described here to do such development work. d This NOTE very briefly describes the services that should be provided at d such an interface. d The TM/TPRM interface must provide the ability of TMs and TPRMs to: d register with each other; obtain recovery status information; pass along d transaction identifier information; rollback, prepare to commit, and d commit the transaction. The interface must provide for the needs of the d full range of transaction processing including distributed transaction d processing with multiple TPRMs. d Finally it should be noted that the industry recognizes the need for d standardization of components as well as the standardization of d portability and interoperability. At least one industry group is d standardizing and several vendors are implementing products utilizing an d interface as described here. d 4.10.5 Standards, Specifications, and Gaps There are currently three transaction processing standards development activities, either completed or in the draft stage. Table 4-11 summarizes the service requirements provided by the various standards. Table 4-11 - Transaction Processing Standards Activities __________________________________________________________________________________________________________________________________________________ ________S_e_r_v_i_c_e_______________________S_p_e_c_i_f_i_c_a_t_i_o_n_______________S_u_b_c_l_a_u_s_e_ Transaction Demarcation Emerging (P1003.11 {_r_e_f}) 4.10.5.? dd Communications Gap 4.10.5.? d Terminal Communications Gap 4.10.5.? d Program Scheduling Gap 4.10.5.? d Message Queuing Gap 4.10.5.? d EEI Services Emerging (ISO/IEC DIS 4.10.5.? 10026-1,2,3 {_r_e_f}) Management Gap 4.10.5.? d Monitoring Gap 4.10.5.? d Modeling Gap 4.10.5.? d Directory/Namespace Gap 4.10.5.? d Recovery/Restart Gap 4.10.5.? d Test Gap 4.10.5.? d System Configuration Gap 4.10.5.? d TM/TPRM SI Emerging (P1003.11 {_r_e_f}) 4.10.5.? dd __________________________________________________________________________________________________________________________________________________ d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 192 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Table 4-12 summarizes the applicability of the various standards to the various programming languages supported by the POSIX Open System Environment. Table 4-12 - Transaction Processing Standards Language Bindings d __________________________________________________________________________________________________________________________________________________ Standard N/A LIS Ada APL BASIC C C++ ________________________________________________________________________ ISO/IEC DIS 10026-1 {_r_e_f} +o ISO/IEC DIS 10026-2 {_r_e_f} +o ISO/IEC DIS 10026-3 {_r_e_f} +o POSIX.11 {_r_e_f} +o +o ________S_t_a_n_d_a_r_d____________C_O_B_O_L___C_-_L_I_S_P____F_o_r_t_r_a_n___P_a_s_c_a_l___P_L_/_1___P_r_o_l_o_g_ dd ISO/IEC DIS 10026-1 {_r_e_f} d ISO/IEC DIS 10026-2 {_r_e_f} d ISO/IEC DIS 10026-3 {_r_e_f} d POSIX.11 {_r_e_f} d __________________________________________________________________________________________________________________________________________________ d NOTE: N/A -- Language bindings are not appropriate for this standard. LIS -- Language-independent specification is available. Ada, APL, BASIC, -- Language-dependent specifications exist. 4.10.5.1 Current Standards in the POSIX OSE 4.10.5.1.1 International Standards None. d 4.10.5.1.2 Regional Standards None. d 4.10.5.1.3 National Standards None. d 4.10.5.2 Emerging Standards in the POSIX OSE _O_S_I__D_i_s_t_r_i_b_u_t_e_d__T_r_a_n_s_a_c_t_i_o_n__P_r_o_c_e_s_s_i_n_g__(_D_T_P_) Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.10 Transaction Processing Services 193 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS ISO/IEC DIS 10026-1 {_r_e_f} ISO/IEC DIS 10026-2 {_r_e_f} ISO/IEC DIS 10026-3 {_r_e_f} These standards, developed by ISO/IEC JTC 1/SC21/WG5, deal expressly with the OSI services and protocols for transaction mode communications in an OSI environment. These standards provide for some of the communications services described d in 4.10.4.1. d _P_O_S_I_X_._1_1__P_O_S_I_X__T_r_a_n_s_a_c_t_i_o_n__P_r_o_c_e_s_s_i_n_g POSIX.11 {_r_e_f} The POSIX.11 working group, formed in 1989, is chartered to work on a profile for Transaction Processing within the POSIX OSE. In the process of developing that profile, it has identified a number of gaps in the standards coverage and is in the process of proposing base standardization activities to address those gaps. Specifically, P1003.11 is currently working on the following services identified earlier: - Transaction Manager (TM) Services provided at the Transaction API. - Services provided at the Transaction Manager/TP Resource Manager (TM/TPRM) SII. A typical TPRM is a database manager (e.g., SQL). _R_J_G: _T_h_e _a_b_o_v_e _l_i_s_t _s_h_o_u_l_d _b_e _a_d_j_u_s_t_e_d _l_a_t_e_r _t_o _r_e_f_l_e_c_t _t_h_e _t_h_e_n _c_u_r_r_e_n_t _s_t_a_t_e _o_f ._1_1'_s _a_c_t_i_v_i_t_i_e_s (_i_n _t_e_r_m_s _o_f _a_p_p_r_o_v_e_d _P_A_R_s.) _I_f _n_o _P_A_R _i_s _d _a_p_p_r_o_v_e_d _b_y _t_h_e _b_e_g_i_n_n_i_n_g _o_f _f_o_r_m_a_l _b_a_l_l_o_t, _I'_l_l _f_i_x _t_h_i_s _p_r_o_s_e _a_n_d _m_o_v_e _d _i_t _t_o _t_h_e _G_a_p _s_e_c_t_i_o_n. _d POSIX.11 is working to assure that POSIX Transaction Processing work is consistent with the emerging work of OSI DTP (cited above), certain ongoing work of X/Open TP, several related POSIX activities (POSIX.1 {2}, POSIX.4 {_r_e_f}, POSIX.8 {_r_e_f}) and the work of ANSI X3T5.5 (RPC). 4.10.5.3 Gaps in Available Standards 4.10.5.3.1 Standards/Specifications Outside the POSIX OSE Existing standards and emerging standards do not adequately address all the requirements identified earlier. While POSIX.11 is addressing some of the gaps, there are many other gaps still not being addressed by formal standards committees. Most notable is the work of X/Open TP. While not formally a standards making body, it is addressing most of the gaps, and its output will be potentially useful as the basis of a formal standard. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 194 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _X_/_O_p_e_n__T_P This group published an ``Online Transaction Processing Reference Model'' in 1987 and in 1990 published ``Preliminary Specification--Distributed Transaction Processing: The XA Specification.'' The group is studying the use of OSI DTP, two-phase commit, and global transaction identifiers. The group is also actively exploring APIs in support of peer-to-peer distributed transactions. The work of this group addresses several of the services addressed in this clause, including transaction demarcation and conversation services. Consideration is also being given to allowing alternative interoperability standards including proprietary mechanisms. Additional APIs are being defined by X/Open TP to facilitate this. 4.10.5.3.2 Unsatisfied Service Requirements Other than the work of X/Open TP, the following areas are not currently d being addressed by standardization activities: communications, terminal d communications, program scheduling, message queueing, management, d monitoring, modeling, directory/namespace, recovery/restart, test, and d system configuration. d 4.10.6 OSE Cross-Category Services Not applicable. d 4.10.7 Related Standards _C_C_R The following standards relating to commitment are related to the ISO/IEC DIS 10026 series and are referenced in DIS 10026: ISO/IEC DIS 9804-3 {_r_e_f} ISO/IEC DIS 9805-3 {_r_e_f} See 4.3 for more information. _R_e_m_o_t_e__P_r_o_c_e_d_u_r_e__C_a_l_l ECMA-127 {_r_e_f} See 4.3 for more information. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.10 Transaction Processing Services 195 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _S_Q_L__S_t_a_n_d_a_r_d__D_a_t_a_b_a_s_e__L_a_n_g_u_a_g_e d The following standards for SQL also provide transaction demarcation d services for relational database access: d ANSI X3.135.1 (ISO 9075, FIPS 127) d ANSI X3.168 d See 4.4 d 4.10.8 Open Issues None. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 196 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.11 Software Development Environments _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _D_o_n _F_o_l_l_a_n_d 4.11.1 Overview and Rationale Software Development Environments are dealt with as a particular application area needing special attention for the following reasons: - The domain of Software Development Environments is one of prime importance. Software development is a major area of expenditure for government and large commercial organizations. - The need for standardization is being driven not only by the SDE vendors and users, but also by the Independent tool developers who want to get their tool products on as many vendor platforms as possible. - The SDE domain calls not only for portability, but also for particular integration and interoperability requirements. - The domain is primarily of interest to that user community that has large complex software development requirements, but it is also of interest to all application areas as software development is an enabling technology for all applications. Software engineers seek more powerful assistance to improve productivity and quality in the software development process. Considered opinion currently favors Project Support Environments (PSE) underpinned in such a way that the facilities are capable of being implemented on different machines. A PSE needs a base holding information such as specifications, designs, code, schedules, configuration plans, tests, etc., to support the developers. The interface between the base and the tools must ensure portability of the tools. Again, these tools will be supported by relevant language standards. Certain design methodologies themselves have been modeled formally to establish their degree of rigor and self-consistency. Function Point Analysis is one method of measuring software systems and computing productivity that is increasing in use. It measures inputs, outputs, and entities accessed to determine transaction size; it gauges technical complexity by reference to 19 characteristics. These are combined to give a measure of systems size. Productivity is the ratio of system size in function points to the effort required to produce or maintain the system. Generally, software support for the development process is in its infancy and effective metrics have not yet been developed. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.11 Software Development Environments 197 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.11.2 Scope The problem domain is complex software development, from the generation of an idea to the delivery and ongoing support of a solution product set. Thus, an SDE may include some or all of the following: (1) Software Development Life Cycle (a) Requirements analysis (b) Logical design (c) Physical design (d) Functional and interface specification (2) Activity support (a) Prototyping (b) Program development and testing (c) Quality assurance and regression testing (d) Generation of user documentation (e) User training (f) Problem report tracking and maintenance (g) Maintenance and tracking of schedules (3) Configuration Management (a) Automatic version management (b) Integrity management (c) Traceability (4) Project Management (5) Data Administration (a) Access control In the context of developing software for a POSIX Open System Environment, design will take account of portability and interoperability Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 198 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 requirements. The SDE tools themselves should be portable. The software development activities may be provided with a large set of tools and applications. The SDE must provide the necessary support for the integration of all of these tools. 4.11.3 Reference Model _________________________________________________________________________ _________________________________________________________________________ Figure 4-22 - Software Development Model In this clause the conceptual view of software development is related to the POSIX Reference Model (Figure 3-1). The software developer's view is shown in Figure 4-22. The tools used to develop software can be viewed as applications in their own right in the context of the POSIX Reference Model, requiring the same services from the platform as for Database Management. In the Software Development Model, the Environment Adaptation and Project Support Tools ``layer'' provides the essential link between the programmer, designer or analyst, the design method, and the development infrastructure. At this level are provided the tools and applications that are unique to the project or methodology; e.g., project management workbench. It requires support from a consistent human-computer interface to the Functional Tools. The Functional Tools and Integration Mechanisms embrace the essential tool set to enable software developers to build software. It includes Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.11 Software Development Environments 199 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 4-23 - Software Development Reference Model simple tools such as editors, tools for tool-building, and integration mechanisms. There will be tools for Configuration Management, Version Management, and System Administration. It is not within the scope of this guide to discuss these in detail. The whole software development environment is underpinned by essential management systems, such as object management system, a data dictionary, a user interface management system, and environment management. A database will frequently be established to hold specifications, designs, configuration plans, etc. In the POSIX Open System Environment, the software development model can be incorporated into the POSIX Reference Model as in Figure 4-23. The model shows that the tools and services required by the software developer are part of the POSIX Open System Environment and are available through the POSIX OSE API. 4.11.4 Services Requirements Software developers, i.e., designers, analysts, and programmers, use software applications to facilitate the complex task of software development. A tool will require services from the application platform and will frequently require support from another application in the application set. There are many possible implementations of tool sets. Descriptions of these are beyond the scope of this guide. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 200 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.11.4.1 Application Program Interface Services The services required at the API are essentially similar to those described for Database Management in 4.4.4.1; i.e., Data Definition and Manipulation, Data Access, Data Integrity, and such Miscellaneous Services as Data Dictionary. 4.11.4.2 External Environment Interface Services A consistent human-computer interface to the tool set is required. Some of the programmer's tool set will be explicitly focused on windowing 4 services (such as 4.6 and 4.7) and provide assistance to develop software 4 with improved usability. Resource data formats must be specified in order to ensure effective information interchange [for example, CASE Data Interchange Format (CDIF)], for which standards are currently under development under the aegis of the CDIF Technical Committee (see also 4.11.5.2 and 4.5). Protocol services are required for the transport of data (see 4.3). 4.11.4.3 Interapplication Software Entity Services Many of the tools depend for interface between one another upon the data dictionary/repository, which is a key software component and which may conceptually be regarded as part of the Applications Platform. Included in this category will be utilities for servicing the DBMS, such as recovery, reorganization, and restructure: - Object management system - User interface management system - Database management system - Transaction processing management system Details of these management systems may be recorded in the data dictionary/repository. 4.11.4.4 Software Development Resource Management Services These services are generally not visible to the programmer or software developer at the Tools API, usually being provided by the tool building and other software development utilities. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.11 Software Development Environments 201 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 4.11.5 Standards, Specifications, and Gaps This subclause describes current accepted standards that are relevant to this area in addition to the language standards in 4.1.5 and the database standards in 4.4.5. Table 4-13 - Software Development Standards Activities __________________________________________________________________________________________________________________________________________________ Service Specification Subclause ____________________________________________________________________________ Miscellaneous Services: Labeling of magnetic tape ISO 1001 {_r_e_f}4.11.5.? d Labeling of cassette and cartridge ISO 4341 {_r_e_f}4.11.5.? d Labeling of flexible disks ISO 7665 {_r_e_f}4.11.5.? d Volume and file structure for flexible disks ISO 9293 {_r_e_f}4.11.5.? d Volume and file structure for CD-ROM ISO 9660 {_r_e_f}4.11.5.? d Documentation symbols and flowchart conventions ISO 5807 {_r_e_f}4.11.5.? d Documentation of applications ISO 6592 {_r_e_f}4.11.5.? d Program flow for sequential files ISO 6593 {_r_e_f}4.11.5.? d Data descriptive file for information interchangeISO 8211 {_r_e_f}4.11.5.? d Program constructs and conventions ISO 8631 {_r_e_f}4.11.5.? d User documentation ISO 9127 {_r_e_f}4.11.5.? d __________________________________________________________________________________________________________________________________________________ 4.11.5.1 Current Standards in the POSIX OSE This subclause briefly identifies the current standards in this area. _D_E_F: _T_h_e _f_o_l_l_o_w_i_n_g _p_r_o_v_i_d_e_s _p_l_a_c_e _h_o_l_d_e_r_s _f_o_r _f_u_r_t_h_e_r _t_e_x_t _t_o _b_e _i_n_s_e_r_t_e_d - _a_s_s_i_s_t_a_n_c_e _r_e_q_u_i_r_e_d _p_l_e_a_s_e. 4.11.5.1.1 International Standards _L_a_b_e_l_i_n_g__a_n_d__F_i_l_e__S_t_r_u_c_t_u_r_e__o_f__M_a_g_n_e_t_i_c__M_e_d_i_a The following standards refer to the labeling of magnetic media and for the file structure on such media to facilitate information interchange: Labeling of magnetic tape ISO 1001 {_r_e_f} Labeling of cassette and cartridge ISO 4341 {_r_e_f} Labeling of flexible disks ISO 7665 {_r_e_f} Volume and file structure for flexible disks ISO 9293 {_r_e_f} Volume and file structure for CD-ROM ISO 9660 {_r_e_f} Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 202 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Data descriptive file for information interchange ISO 8211 {_r_e_f} _D_E_F: _T_h_e _a_b_o_v_e-_m_e_n_t_i_o_n_e_d _s_t_a_n_d_a_r_d_s _m_i_g_h_t _b_e _m_o_r_e _s_u_i_t_a_b_l_y _c_a_l_l_e_d _o_u_t _i_n _R_i_c_h_a_r_d _S_c_o_t_t'_s _s_e_c_t_i_o_n _4._5. _S_o_f_t_w_a_r_e__D_o_c_u_m_e_n_t_a_t_i_o_n There are several standards dealing with documentation to assist with the task of software development, and therefore potentially facilitating programmer and designer portability, as well as user documentation. Documentation symbols and conventions ISO 5807 {_r_e_f} for data, program and system flowcharts, program network charts, and system resources charts Guidelines for the documentation of ISO 6592 {_r_e_f} computer-based application systems Program flow for processing sequential ISO 6593 {_r_e_f} files in terms of record groups Program constructs and conventions for ISO 8631 {_r_e_f} their representation User documentation and cover information ISO 9127 {_r_e_f} for consumer software packages 4.11.5.1.2 Regional Standards ECMA has approved ECMA-149 as the standard for the Portable Common Tool Environment (PCTE). 4.11.5.1.3 National Standards _T_o _B_e _P_r_o_v_i_d_e_d 4.11.5.2 Emerging Standards in the POSIX OSE This subclause describes the activities currently in progress to further standardize this area. 4.11.5.2.1 International Standards _T_o _B_e _P_r_o_v_i_d_e_d 4.11.5.2.2 Regional Standards _T_o _B_e _P_r_o_v_i_d_e_d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.11 Software Development Environments 203 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _C_A_S_E__D_a_t_a__I_n_t_e_r_c_h_a_n_g_e__F_o_r_m_a_t__(_C_D_I_F_) The CDIF Technical Committee is developing a data interchange format to serve as an industry standard for exchanging information between Computer-Aided Software Engineering (CASE) tools. CDIF is an EIA- endorsed initiative. It assumes that two or more tools may interface asynchronously with each other and will transfer information from one to another via ``CDIF files.'' The types of information that may be contained in these files is defined by the CDIF Conceptual Models. _P_o_r_t_a_b_l_e__C_o_m_m_o_n__T_o_o_l__E_n_v_i_r_o_n_m_e_n_t__(_P_C_T_E_) ECMA TC33 has responsibility for the development and maintenance of PCTE. The committee formed a Task Group in 1988 to develop a Reference Model which would assist the standardization process. Such a model has been developed totally independent of PCTE, and is described in ECMA Technical Report 55. The model provides a way to describe, compare, and contrast CASE environment frameworks. 4.11.5.2.3 National Standards _T_o _B_e _P_r_o_v_i_d_e_d 4.11.5.2.4 National Standards _T_o _B_e _P_r_o_v_i_d_e_d 4.11.5.3 Gaps in Available Standards 4.11.5.3.1 Standards and Specifications Outside the POSIX OSE _T_o _B_e _P_r_o_v_i_d_e_d 4.11.5.3.2 Unsatisfied Service Requirements _T_o _B_e _P_r_o_v_i_d_e_d 4.11.6 OSE Cross-Category Services Not applicable. d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 204 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 4.11.7 Related Standards _T_o _B_e _P_r_o_v_i_d_e_d 4.11.8 Open Issues - Relationship between methodology and formats Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.11 Software Development Environments 205 P1003.0/D13 Section 5: POSIX OSE Cross-Category Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _F_r_i_t_z _S_c_h_u_l_z The POSIX reference model defines a set of conceptual system building blocks that collectively describes the Open System Environment. Each building block provides a specific set of interfaces for access to their associated facilities and services. There is another class of services and requirements, however, that may influence and/or impact the basic architectural building blocks; these are referred to as OSE Cross- Category Services. An OSE Cross-Category Service is a set of tools and/or features that, when applied, may have a direct affect on the operation of one or more of the Open System Components, but it is not in and of itself a standalone OSE component. Examples of OSE Cross-Category Services include internationalization, security and privacy, administration, etc. Internationalization has a number of attributes that influence multiple OSE components; supporting multiple coded character sets, for example, will affect end-user interfaces, operational message input and output, screen display, data collating sequences in programming languages and database systems, etc. This section will deal with the general characteristics of OSE Cross- Category Services as applied to the OSE architectural components and to the profiles and domains that characterize application environments. The specific impact/influence of an OSE Cross-Category Service will be described in the appropriate subclause of Section 4 that deals with individual OSE Components. Initially, this section will address Internationalization, Security and Privacy, and System Administration; however, it is anticipated that other OSE Cross-Category Services will be identified as the concept is applied to the model. This section describes issues that should be considered in writing profiles, and is organized so that subclauses for each OSE Cross-Category Service points to, and addresses issues adjacent to each of the service categories identified in Section 4. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5 POSIX OSE Cross-Category Services 207 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS These issues defined areas that need to be traded off to arrive at balanced solutions for a specific profile. It is expected that the specific trades would be made by the profiler, but that this clause could give guidance for trading and could also be used to accumulate lessons learned. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 208 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 5.1 Internationalization _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _R_a_l_p_h _B_a_r_k_e_r d 5.1.1 Overview and Rationale Historically, information systems intended for use within a particular national or cultural market have been designed specifically for the requirements of that market. If the vendor or developer was based in a country other than that of the target market, this was typically accomplished through substantial re-engineering the features of an existing system designed for some other country, and doing so at considerable cost. As the developer desired to market the system in additional countries, the process of re-engineering was repeated for each new national or cultural market. Application software developers were faced with the same problem. The very nature of this style of development produced little concern for portability across national or cultural boundaries, or interoperability between them. Users or organizations that needed to operate in multiple national or cultural markets typically did so with multiple, generally incompatible, information processing systems. The interfaces provided by the POSIX Open Systems Environment (POSIX OSE) can be generalized, however, through the use of internationalization, to extend across national and cultural boundaries. Such a model provides the foundation for international portability of application software, increased user portability, and enhanced interoperability and data exchange capabilities. The task of internationalization is to ensure that the services provided by the POSIX OSE, and the interfaces between such services, are specified in such a way that they can be easily used all over the world. Additionally, as the user is likely to require services from any or all of the service categories of the POSIX OSE, internationalization impacts all areas of the POSIX OSE, and should be viewed as an OSE Cross-Category Service. Since the internationalization aspects of general OSE services and application program interface (API) services are similar for all of the POSIX OSE service categories, they are discussed here rather than repeating them in each of the services sections within this guide. The ability of the service categories of the POSIX OSE to support multiple natural languages, and the underlying cultural conventions, is a two step process. These two steps are generally referred to as ``internationalization'' and ``localization.'' First, the interfaces between the service categories are generalized, so that they are not oriented to the requirements of any particular natural language or set of cultural conventions (internationalization). Then, facilities are provided by the POSIX OSE that allow the user to select the desired natural language and cultural conventions (localization). Tools are Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.1 Internationalization 209 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS provided to facilitate this process. Within this context, cultural conventions, while discussed more fully later in this clause, may be viewed as various aspects of how information is presented to the user. Different cultures, for example, use different formats for dates and numeric values and use different currency symbols. The interfaces provided by the POSIX OSE should allow the information to be presented to the user in the appropriate format as well as the appropriate natural language. 5.1.2 Scope The POSIX OSE provides services that are necessary to support users, irrespective of their particular natural language or cultural conventions. While it is not expected that every implementation of the POSIX OSE would provide support for all possible natural languages and cultural conventions, the specification of the services and the interfaces within the POSIX OSE should not preclude such support. In addition to the service and interface requirements described here, it should be noted that internationalization is affected by a number of elements that are beyond the scope of this guide. Actual implementations of the internationalized POSIX OSE, for example, may need to consider the impact of multiple sets of governmental and regulatory agencies, international data communication standards and other elements which are presently not specified within the POSIX OSE, such as data portability between localized information processing systems. Service requirements differ from country to country and even between users within one country. Many users, for example, may require the simultaneous support of multiple natural languages and cultural convention sets. Therefore, the basic internationalization requirement within the POSIX OSE is to provide a set of services and interfaces that allow the user to define, select, and change between different culturally related application operating environments supported by the particular implementation. Specifically: - The POSIX OSE must provide the means of adjusting the output of specific functions and utilities to support different natural languages, cultural conventions and character sets as may be required by the supported natural languages. - A user should have the capability to select an internationalized user environment that specifies a particular set of data presentation characteristics, including cultural conventions, character sets and native language. - An implementation of the POSIX OSE should be able to concurrently support different applications functioning in different Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 210 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 internationalized user environments, supplying different sets of natural languages, cultural conventions and character sets for different users. - The capability of supporting different internationalized user environments, and the associated natural languages, cultural conventions and character sets, should not require any changes to the logic of existing application programs. - The effect of the user selecting a new internationalized user environment, and its associated natural language, cultural conventions and character set, should be transparent to application programs. - The model should be flexible, to support future extensions and requirements. 5.1.3 Reference Model Internationalization is an OSE Cross-Category Service, spanning all OSE service categories. While various reference models have been used in published technical papers to depict internationalization issues, the internationalization services described in this clause conform to the POSIX OSE Reference Model. 5.1.4 Service Requirements The POSIX OSE must provide services on different levels: general service requirements to be satisfied for any requesting program; API service requirements to be satisfied at the application program interface for a specific program; and a set of tools to support the localization of systems and applications. This subclause (5.1.4) will discuss these different service requirements in detail. In examining these service requirements, it is helpful to draw a distinction between those services which are required to support the portability of an application platform across cultural boundaries, and those services which are required to support the portability of an application across one or more sets of cultural conventions which may be supported on a single application platform. 5.1.4.1 General Service Requirements, Application Platform Internationalization requirements are focused on support and handling of: - Character sets and data representation Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.1 Internationalization 211 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Cultural conventions - Natural language support 5.1.4.1.1 Character Sets and Data Representation The character set for the English language can easily be satisfied by the standard ASCII character set (American Standard Code for Information Interchange). The ASCII code uses 7 bits to uniquely identify each of the 95 available characters. For European and American languages beside English, the number of local characters is much larger. The far-east requirements for thousands of pictograms add yet another dimension to the coding rules and techniques. Different standards address the methods by which the local character repertoires can be coded for unique identification. While replacement of seldom-used characters in the 7-bit codings can support a single additional language besides English, 8-bit coding schemes are used to satisfy multiple languages concurrently by assigning an additional 96 graphic characters to the available repertoire. An example is ISO 8859-1 (the extended ASCII code), which can support all of western Europe, America, Australia, and other English speaking countries all over the world. For Eastern Europe, Greece, Russia, Arabia, and many other countries, other 8-bit codes are defined. Japan, China, Korea, and Taiwan have so many characters in their repertoire that 16 bits are needed to identify them clearly. Work is under way to develop a multi- octet character set with up to 32 bits per coded character; this method will allow concurrent use of all possible languages in the same application. Because different coding schemes are used, it is important that the application platform have the potential capability of supporting all of them. It is also important that the application platform has the d capability to represent (display, print) the data correctly. It is also d important that an application be able to determine in which coded d character set data items are stored on disk or tape. Otherwise, it is d impossible for the application to interpret the data correctly. d Currently the user must control the consistent use of the same coded d character set within an application, but in the future the application d platform should be able to provide identification methods for the coded d character sets used for data storage, processing, communication, and d presentation. It might also be advantageous for the application to be d able to prohibit users from updating data stored in one coded character d set with data in another coded character set since this would immediately d corrupt data bases or flat files. Therefore it may be necessary in the d future to provide a method of announcing the coded character set in which d data are stored, processed, communicated, and presented. d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 212 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 The general service for support of character sets and data representation in an international environment are: (1) Coded character set independence: the ability of the application platform to input, store, manipulate, retrieve, communicate, and present data independent from the coding scheme used. This includes 7-bit, 8-bit, 16-bit, and multi-octet coded character sets. d (2) Character set repository: the ability of the application platform to maintain and access a central character set repository. This repository contains all coded character sets used throughout the platform and specifies relevant information about them: - Code format: the repository contains information, if characters are coded in 7 bits, 8 bits, 16 bits, or any other format. - Data class definition: the definition that a character is considered numeric, alpha, etc., by the programming languages. This classification can vary for the same character from country to country. - Collating rules: different character sets have different coding for characters. Thus, comparison of strings of such coded characters must follow rules defined for the specific character set. Culturally dependent additional collating rules are discussed in 5.1.4.1.2. - Lower- to uppercase mapping: this defines the rules of mapping, if for a specific character no upper- or lowercase is available. Examples are the lower case umlauts which do not have uppercase representations in Switzerland; the uppercase forms are A, O, or U, respectively, followed by a lowercase ``e''. - Escapement rules: some languages like Hebrew and Arabic are written from right to left; numbers within text in these languages are written from left to right. It is necessary to store these escapement rules with the character set. - Presentation rules: the application platform should have the ability of providing fallback presentation rules for the presentation of coded characters that have no associated graphic shape. (3) Character set identifier: the application platform should provide the ability to uniquely identify each coded character Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.1 Internationalization 213 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS set to allow compatibility checks and translation or transliteration to and from other registered character sets. This ensures data integrity in the communication of data across computers and networks. (4) Character set selection: the application platform should allow the end-user or the application to select the coded character set to be used; otherwise, the application must automatically select a default coded character set according to preset parameters. It must be possible to switch to other coded character sets and to invoke translation routines where required. _E_d_i_t_o_r'_s _N_o_t_e: _F_r_o_m _h_e_r_e _t_o _t_h_e _e_n_d _o_f _5._1, _t_h_e _t_e_r_m _d ``[_o_p_e_r_a_t_i_n_g] _s_y_s_t_e_m'' _h_a_s _b_e_e_n _r_e_p_l_a_c_e_d _n_u_m_e_r_o_u_s _t_i_m_e_s _w_i_t_h _d ``_a_p_p_l_i_c_a_t_i_o_n _p_l_a_t_f_o_r_m'', _w_i_t_h_o_u_t _f_u_r_t_h_e_r _d_i_f_f _m_a_r_k_s. _d (5) Data announcement: the application platform could benefit from _d having the ability to recognize the coded character set of data _d entities (files, messages, etc.). One way of doing this is to store the character set identifier together with the data; standardization efforts are under way to formalize this process, with consideration being given to the level of granularity of such identification (e.g. file, word, character). The announcement enables the application to prohibit updates with data coded in other character sets, thus ensuring data integrity even in distributed systems. (6) Data presentation: the application platform should be able to d present data on different display or output devices, potentially d according to rules in a repository, including escapement of d characters and selection of different shapes. Preparing data for presentation may involve extensive translation and transliteration due to potential hardware limitations of the printers and displays used in a particular installation. (7) Data communication: the application platform should be able to d transmit and receive data from communication systems and to maintain the integrity of the information. In an d internationalized environment, this capability might include d data translation due to different coded character sets being used by different service categories of the application platform. (8) Data input: the ability to enter data is not necessarily controlled by the application platform. The complexity of the input of Asian languages though might strongly support the idea of a standardized input mechanism interface. Depending on how d other internationalization service requirements are met, it d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 214 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 might also be beneficial for input data to carry some form of d character set identification. d 5.1.4.1.2 Cultural Conventions Besides using different characters and different languages, countries throughout the world have also developed quite different cultural conventions. Even within one country we can find significantly different cultural environments. The prime example is Switzerland, where French, German, Italian, and Rhaeto Romanic are officially accepted languages. Combined with the language preferences are conventions about the formats of time, date, numeric values, and measuring systems. Currency symbols, paper formats, hyphenation, and collating are dependent on cultural conventions. End-user-oriented applications have to address these issues to provide a familiar local view, which helps to prevent operating errors. The general service requirements for cultural conventions are: (1) Cultural convention repository: The application platform must have the ability to store and access rules and conventions for cultural entities. These might be areas with a common language, geographic areas, or areas with common cultural or historic background. The repository should contain specifications and presentation rules for: - Date and time formats: indicating the formats associated with the particular cultural entity. For example, while in the US the date is expressed in the format month/day/year, the European preferred format is year-month-day for data processing purposes and day-month-year in personal use. Japan counts the years according to the reign of the current emperor. Additionally, twenty-four-hour clocks, which are prevalent in Europe, are commonly used only in military circles in the US, while the terms ``am'' and ``pm'', denoting morning and afternoon, are used by the general public. These are only a few examples for the cultural differences in this area. The application platform must be able to store the preferred forms for date and time for a specific cultural entity and make it available upon request in this format. - Week and day numbering: in Europe, the week starts on Monday, in the US on Sunday. The application platform should d be able to supply the requesting program with the needed d information, potentially from a repository according to d specified rules. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.1 Internationalization 215 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Formats of numeric fields: handling of numeric fields in unfamiliar formats is one of the major reasons for human errors. The application platform must provide the service to format the values according to specifications in the repository. The characters that signify the decimal point (comma, period, etc.) must be defined, as well as the number of decimals, the grouping of digits before the decimal point and the presentation of negative values. - Currency symbols and field length: the handling of currency symbols in the different cultural areas must be provided by the general internationalization services. The currency symbols might be more than one digit long and can appear before or after the currency field. The format of currency fields might differ from that of numeric fields; for example, in Portugal the $-sign is used as the decimal point. Information about these conventions must be stored in the repository and be used by the application platform for local formatting of currency fields. Not necessarily a service, but similarly important, is the understanding, that due to the value of different currencies, the field lengths must be considered carefully. Also some currencies do not have decimals (e.g., Italian Lira). d - Paper formats: internationally usable and portable applications must be able to print on different paper formats. While quart format is predominant in the US and the far east, the DIN standardized A-formats are used in Europe. Printer drivers must be able to adjust their output to local formats, defined in the cultural convention repository. (2) Cultural repository selection: these repositories must be available to all applications. Users and applications must be able to select a repository from the application platform; a default value must be provided if no selection is made. An additional service allows dynamic switching to other repositories upon user or program requests. (3) Collating rules: besides the generic binary and character-set- dependent sorting rules, the application platform must have the ability to sort data according to local rules, defined in the repository. An example for culture-dependent collating rules is the handling of umlauts; while they are sorted with the base characters in Austria, they are sorted at the end of the alphabet in Sweden. Adding complexity, they can be sorted differently within one country between normal business use, such as dictionaries, and in telephone books. Other idiosyncrasies Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 216 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 are the sorting of one character as two (the German ``sharp-s'' sorts as ``sz'' in Austria and ``ss'' in Germany), or two characters as one (the Spanish ``ch'' sorts as one character), or the position of accented characters in a string, and more. User-defined collating tables in the cultural convention repository allow culture or application-dependent sorting services. 5.1.4.1.3 Natural Language Support The POSIX OSE must give users the ability to select a natural language for their dialogue with the system and applications. While it is unrealistic to expect all application platforms to support all possible natural languages, error messages, online documentation and help facilities, selection menus, and the relevant user interaction with these services must be prepared for translation into the supported user- selectable natural language. Additionally, the POSIX OSE must support differences between the natural language selected by the user for interaction with the application platform and that selected for use within a particular application. For word- and text-processing, the service includes hyphenation and spell checking with possible thesaurus support in different languages. The problem is complicated by the fact that data can contain text in different languages in the same document. The service requirements for natural language support are: (1) Multilingual capability: the application platform should be d able to support more than one language simultaneously. For d example, one process might be providing French language d capabilities while another process operated in Japanese. The d application platform must be able to let users select their d preferred languages for communication with the application and allow them to switch dynamically to another language. The application platform must also have the capability to assign a default language, based on parameters for the application platform, the specific workstation, the user identification, or the application. (2) Natural language message system: the application platform must have the capability to present (display, print, ...) messages, menus, forms, and online documentation in the language, selected by the user. The application platform must be able to support multiple languages simultaneously for different users and it must allow the user to switch from one language to another. The following problems must also be handled correctly: - The program code of the application should be able to be d independent from any particular natural language, presenting d messages in the natural language used within the d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.1 Internationalization 217 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS internationalized user environment selected by the user. - Variable message length: the application platform should support the presentation of messages of variable length, as translation into other languages changes the length of the message; English text is usually quite short compared to the same text in, e.g., German or Finnish. Ample room must be available in the display field to accommodate this variation. - Inserted parameters and word order: the application platform should have the capability of inserting variable parameters into messages at the location appropriate for the user selected natural language. d (3) Support of local keyboards: the application platform must be able to correctly interpret the input from keyboards that have been modified locally to support the local character sets. (4) Local language user interaction: the application must be able to accept solicited input from the user in the language selected by the user, without dependence within the application logic on a particular natural language or set of cultural conventions. For example, many applications use the first characters of prompts to make selections; this method is not acceptable in an internationalized system. The translation process changes the prompts and with them their first character; more than one prompt could have the same start-character and the program logic would not work. Multiple languages must be supported simultaneously. d 5.1.4.2 API Service Requirements d All the general services defined in 5.1.4.1 must be accessible from the d applications through requests to the application program interface. The d API service requirements can be structured in the same way as the general d requirements, which they call for. d d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 218 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 5.1.4.2.1 Cultural Conventions - Cultural convention invocation: the application platform must allow the application to invoke a specific cultural convention from the repository. It must automatically invoke the default convention set, if no selection is made by the application. - Cultural convention change: when requested by the application or the user, the application platform must change the used cultural convention dynamically. - Provide local values: upon request from the application, the application platform must return local formats for time, date, calendar, numeric fields, currency fields and symbols. d - Local sort and comparison: when requested by the application, the application platform must compare and sort data according to the local collating rules defined in the cultural convention repository. 5.1.4.2.2 Natural Language Support - Language selection: the application platform must present messages, menus, forms, online documentation, and user interaction in the natural language selected by the user or automatically by the system based on preset parameters for the application, the session, the user, or the system. - Change of language: upon request from the user, the application d platform should be able to dynamically change, prior to the d invocation of a particular user application, the language used for d messages, menus, forms, online documentation, and user d interactions. 5.1.4.3 Localization Tools Requirements Internationalization of application platforms and applications is the basis for their localization in the different countries. It is important for the user that this localization can be performed in a well prepared, organized way without the need to know the internal structure of the application platform or the application. The following requirements for localization tools are key to successful localization of application platforms and applications: - Character set repository tools: tools should be provided to set up d and maintain character set repositories. They must also allow the addition of new character sets to the repository. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.1 Internationalization 219 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Cultural convention repository tools: tools should be provided to d set up and maintain the cultural convention repositories. Addition d of new cultural environments must be possible. User-definable collation tables are essential parts of these repositories; tools to define and maintain them must be offered. - Translation support tools: facilities for the set-up and maintenance of local language message files, menus, forms, online documentation, and user interaction tables should be provided. The d addition of new supported languages should be allowed by such d tools. Additionally, any such translation tools should allow d revision control, so that only new or changed text would require d translation for new software releases. d 5.1.5 Performance and Capacity Values The POSIX OSE provides a foundation for implementations of application platforms to support multiple cultural conventions. It is expected that the specific sets of supported cultural conventions will be implementation defined. While ideally localization should not impact the performance of applications or application platforms, extensive character set translation and complex sorting operations might impact the performance of localized systems. The application platform must allow the implementation of as many cultural conventions and character sets as are necessary to accommodate the different market environments in which it will be used. 5.1.6 Standards, Specifications, and Gaps There are not many standards available that deal with internationalization. The majority of current standards describe character sets, both for control characters and for graphic characters in different coding schemes (7-bit, 8-bit, etc.). A few standards address the formats of time and date, and some standards touch peripherally on the subject of data announcement. An example of how cultural conventions and languages are currently supported is the _l_o_c_a_l_e() function. It allows the application developer to select portions or all of predefined support features for national languages and local cultural conventions. The portions, called categories, correspond to the areas of functionality; presently supported are LC_CTYPE, LC_COLLATE, LC_TIME, LC_MONETARY, and LC_NUMERIC. Other categories, like message handling, are likely to be implemented, too. Other systems have started to implement similar philosophies of general services to support local cultural conventions. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 220 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 5.1.6.1 Current Standards in the POSIX OSE 5.1.6.1.1 International Standards - ISO 646: 1983, _I_S_O _7-_B_i_t _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t _f_o_r _I_n_f_o_r_m_a_t_i_o_n _I_n_t_e_r_c_h_a_n_g_e Defines the binary representation of 128 control, (Latin) alphabet, digit, and symbol characters. Describes in general the use of the control characters. Describes option of national replacement characters. - ISO 2014: 1976, _W_r_i_t_i_n_g _o_f _C_a_l_e_n_d_a_r _D_a_t_e_s _i_n _A_l_l-_n_u_m_e_r_i_c _F_o_r_m This international standard specifies the writing of dates of the Gregorian calendar in all-numeric form, signified by the elements year, month, and day. - ISO 2022: 1986, _I_S_O _7-_B_i_t _a_n_d _8-_B_i_t _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s--_C_o_d_e _E_x_t_e_n_s_i_o_n _T_e_c_h_n_i_q_u_e_s Defines techniques for expanding the number of characters represented by the base character set. - ISO 3307: 1975, _R_e_p_r_e_s_e_n_t_a_t_i_o_n _o_f _T_i_m_e _o_f _t_h_e _D_a_y This international standard is designed to establish uniform time representation based upon the 24-hour timekeeping system. It provides a means for representing local time of the day and Universal Time in digital form for the purpose of interchanging information among data systems. - ISO 4031: 1987, _R_e_p_r_e_s_e_n_t_a_t_i_o_n _o_f _L_o_c_a_l _T_i_m_e _D_i_f_f_e_r_e_n_t_i_a_l_s This international standard specifies a standard means for representing local time differentials to facilitate interchange of data among data systems. - ISO 4217: 1987, _C_o_d_e_s _f_o_r _t_h_e _R_e_p_r_e_s_e_n_t_a_t_i_o_n _o_f _C_u_r_r_e_n_c_i_e_s _a_n_d _F_u_n_d_s Specifies the representation of currencies and currency symbols - ISO 4873: 1986, _I_S_O _8-_B_i_t _C_o_d_e _f_o_r _I_n_f_o_r_m_a_t_i_o_n _I_n_t_e_r_c_h_a_n_g_e-- _S_t_r_u_c_t_u_r_e _a_n_d _R_u_l_e_s _f_o_r _I_m_p_l_e_m_e_n_t_a_t_i_o_n Outlines the structure of the ISO 8-bit code and rules for implementation. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.1 Internationalization 221 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - ISO 6093: 1985, _P_r_e_s_e_n_t_a_t_i_o_n _o_f _N_u_m_e_r_i_c_a_l _V_a_l_u_e_s _i_n _C_h_a_r_a_c_t_e_r _S_t_r_i_n_g_s _f_o_r _I_n_f_o_r_m_a_t_i_o_n _I_n_t_e_r_c_h_a_n_g_e Specifies three presentations of numerical values, which are represented in character strings in a form readable by machine, for use in interchange between data processing systems. Also provides guidance for developers of programming languages standards and Implementor's of programming products. These representations are recognizable by humans, and thus may be useful in communication between humans. - ISO 6429: 1988, _I_S_O _7-_B_i_t _a_n_d _8-_B_i_t _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s--_C_o_n_t_r_o_l _F_u_n_c_t_i_o_n_s _f_o_r _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s Defines control functions and their coded representations for use in a 7-bit code, an extended 7-bit code, an 8-bit code, or an extended 8-bit code. Specifies a C0 set, a C1 set, control functions derived there from, and a number of independent control functions. - ISO 6936: 1988, _C_o_n_v_e_r_s_i_o_n _b_e_t_w_e_e_n _t_h_e _T_w_o _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s _o_f _I_S_O _6_4_6 _a_n_d _I_S_O _6_9_3_7-_2 _a_n_d _t_h_e _C_C_I_T_T _I_n_t_e_r_n_a_t_i_o_n_a_l _T_e_l_e_g_r_a_p_h _A_l_p_h_a_b_e_t _N_o. (_I_T_A) _2 Specifies the rules for conversion between ITA 2 representation of 58 characters and the ISO 646 representation of 128 characters. - ISO 6937-1: 1983, _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s _f_o_r _T_e_x_t _C_o_m_m_u_n_i_c_a_t_i_o_n--_P_a_r_t _1: _G_e_n_e_r_a_l _I_n_t_r_o_d_u_c_t_i_o_n Defines terms and concepts used in describing and using code representations of character sets. - ISO 6937-2: 1983, _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s _f_o_r _T_e_x_t _C_o_m_m_u_n_i_c_a_t_i_o_n--_P_a_r_t _2: _L_a_t_i_n _A_l_p_h_a_b_e_t_i_c _a_n_d _N_o_n-_a_l_p_h_a_b_e_t_i_c _G_r_a_p_h_i_c _C_h_a_r_a_c_t_e_r_s Defines a repertoire of Latin alphabetic and non-alphabetic characters. Specifies binary representation of the characters. Specifies rules for the definition and use of character sets that are subsets of the repertoire. - ISO 7350: 1984, _R_e_g_i_s_t_r_a_t_i_o_n _o_f _G_r_a_p_h_i_c _C_h_a_r_a_c_t_e_r _S_u_b_r_e_p_e_r_t_o_i_r_e_s Specifies the procedures for preparing, registering, publishing, and maintaining the register of graphic character sets that are composed from the character repertoire of ISO 6937 and the procedures for assigning identifiers to the sets. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 222 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - ISO 8601: 1988, _R_e_p_r_e_s_e_n_t_a_t_i_o_n _o_f _D_a_t_e_s _a_n_d _T_i_m_e_s Specifies the representation of dates A.D. in the Gregorian calendar and times and representation of periods of times. Applicable whenever dates and times are included in information interchange. - ISO 8859-x: 1987, _8-_B_i_t _S_i_n_g_l_e-_B_y_t_e _C_o_d_e_d _G_r_a_p_h_i_c _C_h_a_r_a_c_t_e_r _S_e_t_s Specifies a set of up to 191 graphic characters by means of a single 8- bit byte. The versions (``-x'') indicate different coded character sets: -1 Latin Alphabet No. 1 -2 Latin Alphabet No. 2 -3 Latin Alphabet No. 3 -4 Latin Alphabet No. 4 -5 Latin/Cyrillic Alphabet -6 Latin/Arabic Alphabet -7 Latin Greek Alphabet -8 Latin/Hebrew Alphabet - CCITT T.61, 1985: _C_h_a_r_a_c_t_e_r _R_e_p_e_r_t_o_i_r_e _a_n_d _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s _f_o_r _t_h_e _I_n_t_e_r_n_a_t_i_o_n_a_l _T_e_l_e_t_e_x _S_e_r_v_i_c_e Describes detailed definitions of the repertoires of graphic characters and control functions to be used in the international Teletex service. The means by which supplementary character repertoires are defined are also described. 5.1.6.1.2 Regional Standards Presently, no regional internationalization standards which relate to the scope of this guide have been adopted. 5.1.6.1.3 National Standards Many of the international ISO standards have ``twins'' in the national standards bodies; i.e., the same text is given a local standard identification. Also, national standards bodies have often developed standards for local representation of time, date, and currency. The implementation of these standards into an internationalized system is a Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.1 Internationalization 223 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS prime example of localization. Here are some standards that have no international equivalent: - GB 2312: 1980, Chinese national character set standard - JIS X 0208: 1983, Japanese national character set standard - KS C 5601: 1987, Korean national character set standard 5.1.6.2 Emerging Standards in the POSIX OSE 5.1.6.2.1 International Standards The rapid development of business opportunities in the Pan-European and the Asian market has spawned a wealth of activities to develop standards for the support of internationalization in the field of information technology. These emerging standards deal with character sets, language neutral user interfaces, and communication. - ISO DIS 10646: _M_u_l_t_i_p_l_e _O_c_t_e_t _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t This standard will permit the presentation of all of the world's scripts in computer based systems, and their unambiguous interchange between one system or person and another. It is applicable to the representation, processing, storage and presentation of the written form of the languages of the world. - ISO/IEC DIS 10367: _R_e_p_e_r_t_o_i_r_e _o_f _S_t_a_n_d_a_r_d_i_z_e_d _C_o_d_e_d _G_r_a_p_h_i_c _C_h_a_r_a_c_t_e_r _S_e_t_s _f_o_r _U_s_e _i_n _8-_B_i_t _C_o_d_e_s This standard specifies a unique graphic character set for use as G0 set and a series of coded graphic character sets of up to 96 characters for use as the G1, G2, and G3 sets in versions of ISO 4873. All sets specified in this standard are shown as elements of an 8-bit code. - ISO/IEC CD 9995-x: _I_n_f_o_r_m_a_t_i_o_n _T_e_c_h_n_o_l_o_g_y--_K_e_y_b_o_a_r_d _L_a_y_o_u_t_s _f_o_r _T_e_x_t _a_n_d _O_f_f_i_c_e _S_y_s_t_e_m_s This family of standards defines the layout of keyboards so that they can be used for input of multilingual information. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 224 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 5.1.6.2.2 Regional Standards The European Community is in the process to define European standards, called EN (Europaeische Norm). No internationalization standards have yet been adopted. To be supplied 5.1.6.2.3 National Standards National standards under development which relate to internationalization include: - CSA-Z243.200-88: _C_a_n_a_d_i_a_n _N_a_t_i_o_n_a_l _K_e_y_b_o_a_r_d _S_t_a_n_d_a_r_d _f_o_r _t_h_e _E_n_g_l_i_s_h _a_n_d _F_r_e_n_c_h _L_a_n_g_u_a_g_e_s _i_n _T_e_x_t _a_n_d _O_f_f_i_c_e _S_y_s_t_e_m_s 5.1.6.3 Gaps in Available Standards 5.1.6.3.1 Standards and Specifications Outside the POSIX OSE The PC character set was defined at a time, when the international standards for single-byte, 8-bit character sets were not available yet. Therefore, the PC character set was accepted and still is a de facto standard in the PC world. The concept of different code pages has been implemented in MS-DOS and WINDOWS-3 is using ISO 8859-1 internally for compatibility reasons with other systems. Some companies have gone similar routes and developed their own, multilingual character sets for specific applications, the general trend is clearly towards ISO standards wherever they exist. A consortium of software and hardware companies is developing ``Unicode,'' a 16-bit character set standard for worldwide use. 5.1.6.3.2 Unsatisfied While the character set arena is heavily populated, very little work is done in other areas of internationalization of products. Standards should be developed for: - Cultural conventions repository - Application program interface services for cultural conventions - Application program interface services for character set handling - Multilingual collating rules - Input methods interface for Asian languages Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.1 Internationalization 225 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Standards for message delivery systems - Data announcement standards Additionally, no standards currently exist that support the following d character set and data representation functionality: d (1) Character set invocation: the application platform must allow d the application to invoke a specific character set from the d character set repository. It must automatically invoke the d default character set, if no selection is made by the d application. d (2) Character set changes: When requested by the application, the d character set must be changed dynamically. d (3) Character set identifier: the application program must be able d to write the character set identifier to data and must be able d to retrieve the identifier for requested data. d (4) Character set identifier comparison: the application platform d must, upon request from the application or automatically, d compare the character set identifiers of interacting data in the d application (input, processing, data storage, communication, and d output). d (5) Character set translation: the application platform must d provide translation of character sets, when requested by the d application or automatically, when detecting a mismatch in the d comparison process. d 5.1.7 OSE Cross-Category Services Not applicable. 5.1.8 Related Standards The nature of internationalization as being a cross-component facility is that it affects just about every element in the information processing world. Thus, almost all standards in this environment are related to the subject. Here we will point out a few major families of standards, strongly related to internationalization. - ISO DIS 8613: Office Document Architecture and Interchange Format (ODA) Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 226 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 This family of standards, ODA/ODIF, consist of: 1.2 Introduction and General Principles 2.2 Document Structures 3 Document Processing Reference Model 4.2 Document Profile 5.2 Office Document Interchange Format 6.2 Character Content Architectures 7 Raster Graphics Content Architectures 8 Geometric Graphics Content Architectures - ISO 8824: 1987, _S_p_e_c_i_f_i_c_a_t_i_o_n _o_f _A_b_s_t_r_a_c_t _S_y_n_t_a_x _N_o_t_a_t_i_o_n _O_n_e _A_S_N._1 Specifies a notation for the definition of abstract syntaxes, enabling Application Layer standards to define the types of information they need to transfer using the Presentation service. It also specifies a notation for the specification of values of a defined type. - ISO 8825: 1987, _S_p_e_c_i_f_i_c_a_t_i_o_n _o_f _B_a_s_i_c _E_n_c_o_d_i_n_g _R_u_l_e_s _f_o_r _A_b_s_t_r_a_c_t _S_y_n_t_a_x _N_o_t_a_t_i_o_n _O_n_e (_A_S_N._1) Defines a set of encoding rules that can be applied to values of types defined using the notation specified in ASN.1. Application of these encoding rules produce a transfer syntax for such values. It is implicit in the specification of these encoding rules that they are also be used for decoding. - All programming language standards, since programming languages have to support internationalization, and have to work correctly in localized environments. Their generated code itself has to work ``localized.'' 5.1.9 Open Issues See 5.1.6.3. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.1 Internationalization 227 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 228 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 5.2 System Security Services d _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _M_i_c_h_e_l_l_e _A_d_e_n d _H_L_J: _T_h_i_s _i_s _a _c_o_m_p_l_e_t_e _c_l_a_u_s_e _r_e_p_l_a_c_e_m_e_n_t _f_o_r _D_r_a_f_t _1_3. _I_t _i_s _n_o_t d _f_u_r_t_h_e_r _d_i_f_f-_m_a_r_k_e_d _t_o _a_v_o_i_d _c_l_u_t_t_e_r. d 5.2.1 Overview and Rationale Information is the key to successful use of a system. For example, if used effectively and efficiently, information may be used to underpin enhanced service and to aid the derivation of strategic plans. Much of this information, for example, personal customer details and business financial plans, will be of a sensitive nature. Although authorized users may be able to take advantage of the POSIX Open System Environment (OSE) to increase productivity and efficiency, unauthorized individuals may also be able to take advantage of the OSE to steal, manipulate or to deny others access to information held within the system, or to deny involvement in some transaction performed via the system. Security services must therefore be provided within the system if it is to prevent these unauthorized activities. To achieve an optimum degree of confidence in the correctness and effectiveness of a system's security services, a system specific security policy must be derived and appropriate security functionality designed into the system at the beginning of its life cycle. A relatively high degree of protection for ordinary computer systems can be achieved if system administrators correctly configure and maintain the system according to recommended security guidelines and practice, such as those described within the _X/_O_p_e_n _S_e_c_u_r_i_t_y _G_u_i_d_e {_r_e_f}. However, additional security facilities must be supported within the system to achieve protection against the small percentage of attackers who are noncasual, and who are determined to breach the security of the system. It is the intent of the security extensions to the base POSIX interface standard to support these additional security facilities. The four basic security objectives of a system are to maintain: - Confidentiality. The system must prevent unauthorized viewing of data. - Integrity. The system must prevent unauthorized alteration or deletion of data. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.2 System Security Services 229 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Availability. The system must ensure that authorized users are not prevented from accessing and processing data. - Accountability. The system must ensure that users are made accountable for their actions, for example to ensure that users are correctly billed for system usage. Different user groups may place different emphases upon these four basic security objectives. For example, the military security sector may place more importance upon confidentiality than accountability while, correspondingly, the commercial sector may place more importance upon accountability than confidentiality. 5.2.2 Scope One of the goals of system security is to provide defense in depth, such that if one layer of security is breached then further layers of security will limit and/or prevent unauthorized activities within the system. To achieve a high degree of confidence in the correctness and effectiveness of the security of a system that will be processing sensitive information, security must be designed into the system at the beginning of its life cycle. A System Security Policy (SSP) defines what it means for a specific system to be ``secure'' and, as such, forms the basic security input into the system lifecycle. Specification of an SSP is therefore axiomatic to the design of a secure system. Although the SSP defines what security measures will be provided within the system, it is the system design documentation that defines how these security measures will actually be implemented. One aspect of an SSP may be that it mandates conformance with the POSIX security extensions. The IEEE POSIX security group (P1003.6) has responsibility for defining the security extensions to the base POSIX interface standard. The POSIX security interface specifications are intended to assist in the construction of a secure system. They do not, in isolation, provide any protection against threats to a system. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 230 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 5.2.3 Reference Model The POSIX Reference Model partitions the Application Program Interface and the External Environment Interface into a collection of services, each one of which may have a security component. These individual components may operate independently or cooperatively with other security components. For example, a user identification and authentication operation may include elements of the User Interface Services, Communication Services, and Database Services. 5.2.4 Service Requirements Through an analysis of the potential threats and requirements of the system, the system security objectives and hence the necessary System Security Policy (SSP) rules may be derived. This analysis must also take into account appropriate corporate, legal, and standardization requirements. System confidentiality, integrity, availability, and accountability may be supported by the following security objectives: _T_e_c_h_n_i_c_a_l__S_e_c_u_r_i_t_y__O_b_j_e_c_t_i_v_e_s - Identification And Authentication. A system entity, such as a user or system element, must prove that its claimed identity is legitimate, such that another system entity may place confidence in that claimed identity. - Access Control. Access to system resources will be restricted to authorized entities only. Residual data contained within an object will be securely erased before it may be reused by a system entity. - Accountability And Audit. System users must be made accountable for their actions. Audit trails of these actions will then be maintained and utilized such that unauthorized system activity will be detected. - Accuracy. The system must ensure that the correctness and consistency of security-relevant information is maintained. - Availability. System resources will be provided to users in a consistent and reliable manner. - Data Exchange. Data transmitted between system users and/or elements will be protected from unauthorized interference or viewing. Originators and recipients of data will be authenticated and will be able to mutually prove their respective participation in the transaction. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.2 System Security Services 231 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _N_o_n_t_e_c_h_n_i_c_a_l__S_e_c_u_r_i_t_y__O_b_j_e_c_t_i_v_e_s - Assurance. The security of the system must be specified, designed, implemented, tested, and maintained in such a way that confidence can be placed in the correct and effective operation of the system. Also, procedures must be specified to ensure continued confidence in the security of the system in the event that the system is modified in some manner. - Security Roles And Responsibilities. Security activities must be partitioned and allocated to identifiable security administrators who will then be responsible for ensuring that their allocated task is satisfactorily performed. - Secure Operating Procedures. Procedures must be written that will guide system administrators and users as to the correct procedure to follow in the event of some security-relevant occurrence. 5.2.4.1 Application Programming Interface Services _P_O_S_I_X__S_e_c_u_r_i_t_y__I_n_t_e_r_f_a_c_e_s The P1003.6 scope is limited to security extensions for those interfaces defined within the base POSIX interface specification (POSIX.1 {2}). Issues not addressed within the P1003.6 scope include noninterface- specific architectural assurance issues and communications security. _P_O_S_I_X__S_e_c_u_r_i_t_y__I_n_t_e_r_f_a_c_e_s The POSIX security interfaces will support Audit, Privilege, Discretionary Access Control (DAC), Mandatory Access Control (MAC), and Information Labels (ILs). Implementation support for these POSIX security interfaces is optional. The audit interfaces support the concept of accountability wherein all system users are made accountable for their actions through the recording of user identities and associated actions within an audit trail. The audit interfaces support both portable audit generating and processing applications. The privilege interfaces support the enforcement of a least privilege security policy wherein system administration responsibilities and associated privileges are allocated to a number of discrete roles, in order to compartmentalize the security impact of a subverted security administrator or of unauthorized usage of a security administrator role. The DAC interfaces support the imposition of a fine granularity of user specified access control to objects. The DAC interfaces supplement the user-group-other permission bits that currently exist within the UNIX Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 232 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 system through the use of Access Control Lists (ACLs). The MAC and IL interfaces support the imposition of system specified policies for labeling. A MAC label is associated with an object (e.g., a file) and is typically used for access control purposes. An information label is associated with the data contained within the actual object itself and may therefore be used as a more accurate label for the purposes of hard copy printing. Further, an IL may contain information that is not related to logical access control and that is therefore not suitable for inclusion within a MAC label; e.g., physical document handling restrictions. 5.2.4.2 External Environment Interface Services _F_G_P: _T_h_i_s _s_u_b_c_l_a_u_s_e _w_i_l_l _c_o_n_t_a_i_n _t_h_e _s_e_r_v_i_c_e_s _f_r_o_m _s_u_b_c_l_a_u_s_e _4._5._3 (_s_u_p_p_l_i_e_d _b_y _P_O_S_I_X._6) _t_h_a_t _a_p_p_l_y _s_p_e_c_i_f_i_c_a_l_l_y _t_o _t_h_e _A_P_I. _F_o_r _e_x_a_m_p_l_e, _A_c_c_e_s_s _C_o_n_t_r_o_l _s_e_r_v_i_c_e_s _w_i_l_l _b_e _i_n _t_h_i_s _c_o_l_l_e_c_t_i_o_n. 5.2.4.3 Interapplication Software Entity Services _F_G_P: _T_h_i_s _s_u_b_c_l_a_u_s_e _w_i_l_l _c_o_n_t_a_i_n _t_h_e _s_e_r_v_i_c_e_s _f_r_o_m _s_u_b_c_l_a_u_s_e _4._5._3 (_s_u_p_p_l_i_e_d _b_y _P_O_S_I_X._6) _t_h_a_t _a_p_p_l_y _s_p_e_c_i_f_i_c_a_l_l_y _t_o _t_h_e _A_P_I. _F_o_r _e_x_a_m_p_l_e, _A_c_c_e_s_s _C_o_n_t_r_o_l _s_e_r_v_i_c_e_s _w_i_l_l _b_e _i_n _t_h_i_s _c_o_l_l_e_c_t_i_o_n. 5.2.4.4 Component Management Services _F_G_P: _T_h_i_s _s_u_b_c_l_a_u_s_e _w_i_l_l _c_o_n_t_a_i_n _t_h_e _s_e_r_v_i_c_e_s _f_r_o_m _s_u_b_c_l_a_u_s_e _4._5._3 (_s_u_p_p_l_i_e_d _b_y _P_O_S_I_X._6) _t_h_a_t _a_p_p_l_y _s_p_e_c_i_f_i_c_a_l_l_y _t_o _t_h_e _A_P_I. _F_o_r _e_x_a_m_p_l_e, _A_c_c_e_s_s _C_o_n_t_r_o_l _s_e_r_v_i_c_e_s _w_i_l_l _b_e _i_n _t_h_i_s _c_o_l_l_e_c_t_i_o_n. 5.2.5 Standards, Specifications, and Gaps 5.2.5.1 Related Standards in the POSIX OSE ISO 7498-2, _I_n_f_o_r_m_a_t_i_o_n _P_r_o_c_e_s_s_i_n_g _S_y_s_t_e_m_s--_O_p_e_n _S_y_s_t_e_m_s _I_n_t_e_r_c_o_n_n_e_c_t_i_o_n _R_e_f_e_r_e_n_c_e _M_o_d_e_l, _S_e_c_u_r_i_t_y _A_r_c_h_i_t_e_c_t_u_r_e. _I_n_f_o_r_m_a_t_i_o_n _R_e_t_r_i_e_v_a_l, _T_r_a_n_s_f_e_r _A_n_d _M_a_n_a_g_e_m_e_n_t _F_o_r _O_S_I--_D_r_a_f_t _A_c_c_e_s_s _C_o_n_t_r_o_l _F_r_a_m_e_w_o_r_k, _I_S_O/_I_E_C _S_C_2_1/_W_G_1. _I_S_O/_I_E_C _8_6_1_3, _I_n_f_o_r_m_a_t_i_o_n _T_e_c_h_n_o_l_o_g_y--_T_e_x_t _a_n_d _O_f_f_i_c_e _S_y_s_t_e_m_s--_O_f_f_i_c_e _D_o_c_u_m_e_n_t _A_r_c_h_i_t_e_c_t_u_r_e (_O_D_A) _A_n_d _I_n_t_e_r_c_h_a_n_g_e _F_o_r_m_a_t. Draft Addendum to ISO 8613 On Security Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.2 System Security Services 233 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS CCITT X.509, _M_e_s_s_a_g_e _H_a_n_d_l_i_n_g _S_y_s_t_e_m, _I_S_O/_C_C_I_T_T _X._4_0_0 _D_i_r_e_c_t_o_r_y _A_u_t_h_e_n_t_i_c_a_t_i_o_n _F_r_a_m_e_w_o_r_k. ECMA CMA 138, _S_e_c_u_r_i_t_y _I_n _O_p_e_n _S_y_s_t_e_m_s--_D_a_t_a _E_l_e_m_e_n_t_s _A_n_d _S_e_r_v_i_c_e _D_e_f_i_n_i_t_i_o_n_s. _C_a_r_d _A_n_d _C_a_r_d _T_e_r_m_i_n_a_l_s, _E_u_r_o_p_e_a_n _T_e_l_e_c_o_m_m_u_n_i_c_a_t_i_o_n_s _S_t_a_n_d_a_r_d_s _I_n_s_t_i_t_u_t_e, _T_e_r_m_i_n_a_l _E_q_u_i_p_m_e_n_t _T_E_9 5.2.5.2 Related Documents in the POSIX OSE _T_h_e _I_n_f_o_r_m_a_t_i_o_n _T_e_c_h_n_o_l_o_g_y _S_e_c_u_r_i_t_y _E_v_a_l_u_a_t_i_o_n _C_r_i_t_e_r_i_a, Version 1.2, 28 June 1991. US DoD, DOD 5200.28-STD, _T_r_u_s_t_e_d _C_o_m_p_u_t_e_r _S_y_s_t_e_m _E_v_a_l_u_a_t_i_o_n _C_r_i_t_e_r_i_a. Trusted Network Interpretation Trusted Database Interpretation Computer Security Subsystem Interpretation 5.2.5.3 Emerging Standards in the POSIX OSE To be provided. 5.2.5.4 Related Standards To be provided. 5.2.5.5 Gaps in Available Standards To be provided. 5.2.6 OSE Cross-Category Services d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 234 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 5.3 Information System Management _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _D_o_n _F_o_l_l_a_n_d, _N_e_i_l _C_r_o_f_t _d _D_E_F: _T_h_e _f_o_l_l_o_w_i_n_g _i_s _o_u_t_l_i_n_e _m_a_t_e_r_i_a_l _a_s _p_l_a_c_e-_h_o_l_d_e_r _f_o_r _m_o_r_e _s_u_b_s_t_a_n_t_i_v_e _t_e_x_t. 5.3.1 Overview and Rationale The following issues should be addressed in subclauses 5.3.1 and/or 5.3.2: - should support a variety of system management support scenarios (central management, dispersed management, or hybrid) - this section should address both distributed systems and standalone systems. - could be applied to Application Software or software components of the application platform. - support automated management and operation of the IT infrastructure - should address a wide variety of licensing scenarios 5.3.2 Scope This category includes services and policies that address the administration of the overall information system required by any organization, including: - Information Management - Processor Management (e.g., Add new user) - Network Management - Configuration Management - Security Management (e.g., Authentication, Key Management) - Accounting Management - Performance Management Administration services accessible from the API may have Programming Language or Language Binding service specifications associated with them. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.3 Information System Management 235 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS These services are defined to provide system and network administrator portability. 5.3.3 Reference Model < Consistent with Draft 11 Section 3.0 > 5.3.4 Service Requirements The following services are required: 5.3.4.1 Software Installation and Distribution d The main types of software to be installed and distributed are d application programs developed in-house, bought-in applications, and d utility software and personal computer software packages. All software d needs to be managed effectively from development or purchase through to d the live environment. Unless the distribution and implementation process d can be controlled automatically, or from the center using software tools, d procedures must be in place to ensure that distributed software arrives d when expected and is checked for authenticity in whatever way is d practical, and that the software is brought into use when required. The d main procedures involved in software distribution and installation are: d - Central Software Control and Distribution (SC&D) staff to inform d remote staff when to expect distribution software to arrive. d - Recipients to report to central SC&D staff when the distributed d software has arrived successfully. d - Central SC&D staff to check that all software is received as d expected at locations. d - Central SC&D staff to issue clear instructions about when the d software is to be implemented. d - Location staff to report to SC&D when the software has been d implemented. The release record on the Configuration Management d Database will state which installations are to receive the release. d This database must be updated to reflect the receipt and d implementation of the release at each site. d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 236 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 5.3.4.2 License Services d The terms and conditions relating to the supply of software may place d legal restrictions on the organization (e.g., no unauthorized copies to d be made). It is particularly important therefore that the Configuration d Management Database is updated with details of who holds copies of d software items. This assists the organization in discharging its legal d obligations and assists auditors in checking for the existence of d unauthorized copies. d All authorized copies of licensed or purchased software that are made by d SC&D staff must be allocated a unique copy number and recorded in the d Configuration Management Database together with where they are located d and who is responsible for them. Procedural restrictions should be d introduced to prohibit the unauthorized copying of software, and regular d software audits should include a check for any unauthorized copies. d 5.3.4.3 Print Output and Distribution Services d Output and distribution packages control output production and d distribution from the moment the output is planned to the time the user d receives the print. The working criteria need to be set up first; e.g., d define who receives the report and how much of the report the user gets. d The main functions are d - The report can be limited to parts wanted by the user. d - Multiple copies of the entire report, or of selected sections can d be produced. d - Reports are grouped by recipient within delivery location. d - Reports for each job are spooled as a group when the job is d complete. d - The number of whole reports and individual pages received by each d user are recorded. d - Report production can be monitored and managed efficiently. d Output and Distribution packages should contain the following minimum d characteristics: d - Printing and distribution of whole and part reports d - Status (queued, printing etc) of the report tracked d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.3 Information System Management 237 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Online viewing of reports d - Ability to archive report files d - Ability to support a wide range of printers d - Costing and charging functionality d - Security facilities d By using an output distribution package, the delivery of reports to the d correct person at the correct location can be ensured. Paper, time, and d IT resource are saved as the users receive only the parts of reports that d they need, and can also view the reports online. The number of pages d printed can be controlled. Reports can be tracked from the time they are d created to the time they are delivered to the user, allowing good d security monitoring. d 5.3.4.4 Office Media Management and Backup/Restore d The main functions of magnetic tape and data cartridge management systems d are: d - To provide automated support for tape housekeeping and maintenance d including: d +o Allocating tapes and releasing them for reuse helping d +o To ensure even patterns of use where appropriate d +o Constructing and triggering cleaning schedules d +o Maintaining the security of data d - To help automate archiving (vault management) for offsite storage d - To help identify growth requirements d Vault management is concerned with controlling the movement of tape d cycles from one storage location to another. As a tape cycle is used, d the tape management system automatically logs a different vault d identifier against each tape. d A backup strategy is required to control the frequency of backups and the d way in which they are created; e.g., whole volumes to cartridge or d individual files to tape. d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 238 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 The backups and restores of system and application software should be d separate from the backups and restores of data. Software and library d backups should be explicitly scheduled and the complete software item or d library backed up. The schedule for backing up files must be fully d documented, properly maintained and adequately safeguarded as the d contents of the schedule are required for disaster recovery purposes. d 5.3.4.5 Online Disk Management d The operation of disk management systems requires that they take account d of a range of factors such as retention period, recovery, space d fragmentation, disk overflow, file and record activity levels, and d channel use. Some systems merely report against values or thresholds d set, but increasingly they invoke corrective action. Typically, the d corrective action is file and disk reorganization or file and data d archiving. d If a disk management system is used, the constant monitoring and d actioning of requests for disk space can be minimized. Disk space may be d collectively pooled and unused space constantly reclaimed. d 5.3.4.6 Job Scheduling d Scheduling involves the continuous organization of jobs and processes d into the most efficient sequence, maximizing throughput and utilization d to meet the targets set in service level agreements (SLA). Jobs are d scheduled to ensure: d - SLAs and user requirements are met; e.g., certain jobs need to be d run by a certain time d - Available capacity is used effectively; e.g., the workload run at d any given time does not exceed the practical capacity. d The minimum functionality of a scheduler should include: d - A high upper limit for the number of relationships allowed between d jobs d - The ability to schedule by calendar and criteria d - Workload balancing support d - Levels of security d - Ability to restart jobs d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.3 Information System Management 239 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Operator override capability d - Capability to model future workloads. d 5.3.4.7 Processor Configuration Management d Configuration management consists of four basic functions: d identification, control, status accounting, and verification. d Identification involves specifying and identifying all components of an d IT infrastructure. d Control implies the ability to agree and ``freeze'' configuration items d (CIs) and then to make changes only with agreement of the appropriate d named authorities. Control is concerned with ensuring that none of the d CIs shown is altered or replaced, and that no CIs are added without d appropriate authorization. d Status accounting involves the recording and reporting of all current and d historical data concerned with each CI. Status accounting maintains d records of the current, previous and planned states and attributes of the d CIs and tracks these states and attributes: for example, as the status d of a CI changes from ``development'' through to ``test,'' ``scheduled to d go live,'' ``live,'' and through to ``archived.'' d Verification consists of a series of reviews and audits to ensure that d there is conformity between all CIs and the authorized state of CIs as d recorded in the configuration management database (CMDB). It is d concerned with checking that the physical CIs actually match the d authorized system as described in the CMDB. d 5.3.4.8 Network Configuration Management d To ensure the viability of network services the configuration of systems d and services must be controlled and managed. Effective configuration d management will produce a minimum risk environment. d Configuration management procedures must ensure that details are provided d for network equipment and systems covering: d - Configuration activities--how to configure the network equipment d - Security controls d - Access controls d - Configuration history log d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 240 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Configuration authority d - Build details d - Fall-back and test records d - Management reporting requirements. d 5.3.4.9 Distributed System Configuration Management - authentication services for a distributed system environment - distributed Naming Service Configuration - distributed Time Service Configuration - X Window system configuration - Window/Session Manager configuration 5.3.4.10 Accounting d An effective cost management system should: d - Provide assistance in developing a sound investment strategy which d recognizes and evaluates the options and flexibility available from d modern technology. d - Provide targets for performance and measure that performance d against targets. It should also enable management to monitor d actual costs against budget. d - Facilitate prioritization of resource usage. d - Ensure the sound stewardship of all the assets employed in the d organization, including the maintenance of appropriate records for d control purposes. d - Assist management in their day to day decision making and enable d them to make considered decisions as regards forward plans with the d minimum of risk. d - Be flexible and capable of providing a fast response to changing d business circumstances. d The essential objectives of apportioning costs are to: d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.3 Information System Management 241 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Recover from users the full cost of (IT) services, including the d cost of capital. d - Ensure that IT users are aware of the costs which they impose on d the IT systems. d - Ensure that IT providers have an incentive to deliver an agreed d quality and quantity of economic and effective service. d 5.3.4.11 Performance Management - ensure that users have satisfactory performance, workload throughput, and terminal response times in accordance with their service level agreements 5.3.4.12 Capacity Management d An effective and efficient capacity management function contains at least d the following elements: d - Performance management to monitor and optimize the use of current d systems. d - A capacity management database that contains current and historic d data of technical and business related interest. This database d forms the basis for the provision of both tactical and strategic d reports on performance and capacity. d - Workload management to identify and understand the applications d that make use of the system. The understanding of workloads has d both a technical and business related nature. This involves d application sizing to accurately predict the performance and d required capacity of new applications. d - Capacity planning to accurately plan the required hardware resource d and associated cost for the future and to predict the effect on d performance and capacity of both tactical and strategic plans. d 5.3.4.13 Availability Management - measures taken to ensure availability and reliability - automated or manual measures taken to recover a failed system Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 242 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 5.3.4.14 Security Management - configuration of appropriate ACLs for System, User Interface, Storage, Network, and application software services. 5.3.5 Standards, Specifications, and Gaps To be provided. 5.3.6 OSE Cross-Category Services - Security for remote print jobs 5.3.7 Related Standards To be provided. 5.3.8 Open Issues Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.3 Information System Management 243 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 244 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 5.4 Fault Management _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _R_i_c_h _B_e_r_g_m_a_n The trade-offs in this subclause involve: - Testability and Verifiability vs. simplicity and time - Confidence and reliability vs. cost vs. risk - Downtime vs. availability - Maintainability vs. higher system cost These services allow the system to react to the loss or incorrect operation of system components at various levels (hardware, logical, services, etc.). The classical model of fault tolerance has a three-step approach. The three steps are fault detection, fault isolation, and fault recovery. Typically implementations divide these steps into multiple steps or integrate them into one or two steps. Additionally, fault diagnosis services support the other steps in the treatment of a fault. Various fault tolerance strategies, such as checkpointing and voting, are implemented as a collection of services comprising one or more of the steps in the fault tolerance classical model. For example, services involved in implementing a three-node voting scheme will include a vote comparator service (fault detection), vote analyzer service (fault isolation/fault diagnosis), a service to pass the majority ``answer'' through (fault recovery) as well as a service to disable the faulty resource and reconfigure the voters (fault recovery/reconfiguration). _F_a_u_l_t__D_e_t_e_c_t_i_o_n Fault detection services are concerned with determining when a fault has occurred in the system. Fault detection services are both passive and active. Active services are those that attempt to determine the status of various system components by testing those components. Passive services, on the other hand, try to ascertain system components by passively gathering information and watching the behavior of the system. _F_a_u_l_t__I_s_o_l_a_t_i_o_n_; Fault isolation services attempt to determine the component at fault and segregate the faulty component from the rest of the system. Services may be shared between the fault detection and isolation service library in that they perform both functions. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.4 Fault Management 245 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _F_a_u_l_t__R_e_c_o_v_e_r_y Fault recovery services attempt to bring the system into a consistent state. These services may be very interrelated to the scheduling services, network services, and data base services, depending on the recovery scheme used. Redundancy of resources is many times needed to support fault recovery. Resources may include data, process, processor, disk drive, etc. As parts of the system fail, it may no longer be possible to satisfy all the requirements of the application. Services to support graceful degradation may be used to ensure that critical activities do not fail. _F_a_u_l_t__D_i_a_g_n_o_s_i_s These services deal with the system's ability to analyze the attributes of a system fault and determine its cause. These services tend to be very interrelated with fault detection and fault isolation services. _F_a_u_l_t__A_v_o_i_d_a_n_c_e These services involve the avoidance of faults before a failure in the system component occurs. If a system can detect that the operation of a component is approaching the edge of its operational range, a standby or backup component could be phased in to replace it. Another form of fault avoidance is logging of shocks, temperature extremes, etc., so that it can be predicted that a component will not meet its original expected service life. _S_o_f_t_w_a_r_e__S_a_f_e_t_y These services involve the system's ability to keep application software from causing harm to the system's software, hardware, or user. For instance, a process may attempt to write into another process's memory space without permission. A good example of a reliability method that may provide software safety is a bounds checker. The checker compares an answer supplied against the bounds. If it is not within the bounds, the bounds checker will not allow the answer to propagate, possibly causing damage to the system's integrity. Additionally, it may send a fault message (or security violation information, depending on the type of answers expected) to the proper service. To enhance software safety, other services and processes should be only given the resources necessary to complete their job. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 246 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _S_t_a_t_u_s__o_f__S_y_s_t_e_m__C_o_m_p_o_n_e_n_t_s These services involve the obtrusive and nonobtrusive diagnosis of the state of system components. For further explanation of these services, see Fault Detection and Fault Diagnosis services. These services may additionally need to record and/or display information concerning performance, configuration, and general system information. _R_e_c_o_n_f_i_g_u_r_a_t_i_o_n These services allow the system to reconfigure its view of the world. This services allow the system to substitute different resources to perform system functions such as substituting a new physical I/O channel to support a logical channel. These services are part of the API but their use may be restricted to specially authorized programs such as those used by the target system operator. _M_a_i_n_t_a_i_n_a_b_i_l_i_t_y Maintainability services provide support for the maintenance of a system. A major component of that support is the collection and logging of information about the operation of the system. Typical information to be logged is: - Software and hardware errors during operation - Processes that failed or almost failed to meet scheduled deadlines - Performance metrics for system tuning - Times when the system operated in extreme environmental conditions - Errors reported during startup self-testing - Attempts to violate rules of the system's security policy. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.4 Fault Management 247 P1003.0/D13 Section 6: Profiles _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _F_r_i_t_z _S_c_h_u_l_z This section targets those who want to know more about what profiles are and those who are in the process of developing their own profiles. The latter group consists of those developing formal ``Standardized Profiles'' and those developing less formal profiles for their industry group (e.g., a banking trade association) or their own company or enterprise for procurement or strategic planning purposes. Those not involved in the development of profiles should read 6.2. Parts of 6.3 also may be useful, especially the earlier subclauses that give definitions of terms and explain concepts more precisely. Developers of profiles that are not formal POSIX Standardized Profiles (POSIX SPs) should read all of Section 6. Developers of profiles that are formal POSIX SPs should read all of Section 6 and Annex A. 6.1 Scope The information presented here about profiles is limited in scope to assist those needing to understand profile concepts as they apply to the POSIX Open System Environment. Covered are profiles constructed from standards (and profiles) listed within this guide (that, by design, are consistent with POSIX.1). The goal is to create a common approach and documentation scope and style for POSIX-oriented profiles. Annex A goes further by giving specific guidance to developers of formal POSIX SPs. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6.1 Scope 249 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 6.2 Profile Concepts _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _B_o_b _G_a_m_b_r_e_l _I_n_t_r_o_d_u_c_t_i_o_n This guide is designed to assist in the selection of standards in the procurement process or as a target application environment. Profiles also assist in the selection of standards. A profile is a suite of base standards with specified options. Profiles can be created by software developers to describe the environment they target or by buyers to identify their purchasing objectives. _B_a_s_i_c__T_e_r_m_i_n_o_l_o_g_y See 2.2.2 for relevant terms that will be used in this section: base standard, application environment profile, profile, standardized profile, and POSIX standardized profile. There are two general classes of standards documents: - Base standards - Profiles (including AEPs, standardized profiles, and POSIX SPs) As used in this guide, base standards specify functionality, syntax, protocols, data formats, etc., in detail, while profiles do not. Instead, profiles identify which base standards are applicable. Since base standards often consist of a base or mandatory part and a number of selectable optional parts and values, profiles may also (or may not) choose, for each base standard, specific options or values. A profile may also identify other profiles, allowing the construction of ``larger'' profiles based on both base standards and other ``smaller'' profiles. NOTE: Profiles go by many names throughout the world including ``functional standards,'' ``implementation agreements,'' and ``specifications.'' In the context of internationalization, the term d ``national profile'' is frequently used and will be found, for example, d in POSIX.1 {2} and POSIX.2 {_r_e_f}. Its meaning is consistent with the d definitions in 2.2.2, but in many cases such profiles reflect national d cultural conventions. For example, Denmark and Japan both have specified d a national character profile. d Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 250 6 Profiles ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 6.2.1 Relationships Between This Guide and Profiles Key to the understanding of profiles is a discussion of the relationships that exist among profiles, this guide, and the base standards. There exist many thousands of base standards, each addressing a particular, usually narrowly scoped, area of application portability or interoperability. Many of the base standards, developed over the years, are simultaneously narrow in scope (for example, a C binding of SQL), but broadly applicable (for example, applicable to Operating Systems that have ``POSIX'' interfaces and those that do not.) The base standards listed in 1.2 form the basis of the POSIX Open System d Environment. The list is comprehensive, in that its coverage is broad enough to cover most modern day application development, and the base standards selected have been determined to be consistent with POSIX.1 {2}. While this guide does not list all base standards, it is still a large list, and in fact the list contains base standards that might not be consistent with each other (choose any two standards from the POSIX OSE and they might not be consistent with each other.) The process of profile writing addresses this. The profile writer reduces even further the list of base standards to just the (relatively) few that are needed to provide portability and interoperability in a given functional area. In the process, the profile writer grapples with the coherence of the selected base standards by choosing only those that will work together to get the particular job done. Profile writers should also deal with _h_a_r_m_o_n_i_z_a_t_i_o_n, which means making the profiles consistent with each other where they overlap. This can often be done among profiles even where the functional areas served differ greatly. Procurements specifying two profiles that have been harmonized by their authors have the benefit of knowing that the two will not conflict with each other. By specifying compliance to a particular profile in a procurement, a consumer easily references a set of multiple base standards that have been determined to: serve a particular purpose; work together; and be consistent with POSIX.1 {2}. The benefits and relationships do not end here, however. Since profiles can be constructed to reference profiles as well as base standards, future profile writing will be even easier. NOTE: An analogy is in the construction of electronic equipment such as computers. The basic building blocks are ``components,'' such as memory chips and capacitors, which can be fabricated into larger building blocks such as printed circuit boards, which can be fabricated (with other components or printed circuit boards) into larger building blocks, such Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6.2 Profile Concepts 251 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS as standalone computers, which can be fabricated into larger building blocks such as department wide networks of computers, etc. Likewise, a few base standards (the basic building blocks), can be gathered together into ``component'' profiles, which can then be gathered together (with other base standards or component profiles) into larger ``platform'' profiles, which can be gathered together into larger ``application area'' profiles. (See 6.3.3.5.) The development of profiles from the primary building blocks (base standards) results in larger building blocks (profiles) that can then be incorporated into future profiles and also into future versions of this guide. _T_h_e__I_m_p_o_r_t_a_n_c_e__O_f__P_r_o_f_i_l_e_s Profiles are important for a number of reasons: - Profiles select one or more base standards or profiles and specify options and parameters within these. This provides a clear statement of specifications that describe the standards for the target functional objective(s). - Profiles include information about the relationship between the standards included (i.e., coherency is an objective). - Profiles are a clear method of communication about the specific standards needed for an application domain and can be used in procurement, in conformance testing, and as a target for applications development. 6.3 Guidance to Profile Writers _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _B_o_b _G_a_m_b_r_e_l This clause expands the concept of profiling in the manner needed by profile writers and provides detailed guidance to those writers. It includes a description of the basis for this guidance, expands on the purposes served by profiles, and finishes with more detailed guidance specifically aimed at those writing profiles. Using this guide as a basis, profile writers can develop their own informal profiles, suited to their own needs, or formal standards bodies can develop formal, balloted profiles. This clause details the requirements that should be met by developers of profiles whether they are POSIX SPs, standardized profiles, or less formal profiles. Standardized profiles are formal profiles that meet the requirements of a sponsoring standards body. Standardized profiles that also meet the Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 252 6 Profiles ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 requirements for POSIX-based profiles (rules established by IEEE) are called POSIX standardized profiles (POSIX SPs.) For more information about writing POSIX SPs, see Annex A. 6.3.1 Basis for This Guidance Many of the ideas and concepts for profiling described in this section derive from the work of ISO/IEC JTC 1 SGFS as documented in ISO/IEC TR 10000-1 {_r_e_f}. Some items specified in that document that are not covered here include: - International standardization considerations - Conformance issues - Processes and procedures - Maintenance - Taxonomy Additionally, some consideration was given in this guidance above and beyond that given in ISO/IEC TR 10000 {_r_e_f}: - Standardized profiles and POSIX standardized profiles as a conceptual extension to International Standardized Profiles (ISP). - IEEE basis, not ISO basis, for formatting rules; see Annex A Writers of profiles following the guidance of this clause should refer to Annex A if they intend to propose IEEE acceptance as a POSIX SP and to ISO/IEC TR 10000 {_r_e_f} if they intend to propose acceptance as an ISP. 6.3.2 Purpose of Profiles Profiles define combinations of base standards and profiles for the purpose of: - Identifying the base standards, together with appropriate classes, subsets, options, and parameters, that are necessary to accomplish identified functions for purposes such as interoperability and portability. - Providing a system of referencing the various uses of base standards that is meaningful to both users and suppliers Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6.3 Guidance to Profile Writers 253 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - Enhancing the availability for procurement of consistent implementations of functionally defined groups of base standards that are expected to be the major components of real application systems - Promoting uniformity in the development of conformance tests for systems that implement the functions associated with the profiles 6.3.3 Detailed Guidance to Profile Writers 6.3.3.1 The Relationship to Base Standards Base standards specify procedures and formats that facilitate application portability and interoperability. They provide options, anticipating the needs of a variety of applications and taking into account different capabilities of real systems and networks. Profiles further promote portability and interoperability by defining how to use a combination of base standards for a given function or application area. Profiles, by definition, do not define new application interfaces. In addition to the selection of base standards, a choice may be made of permitted options for each base standard and of suitable values for parameters left unspecified in the base standard. Profiles should not contradict base standards, but should make specific choices where options and ranges of values are available. Profiles must include all of the items made ``mandatory'' by the standard. The choice of the base standard options should be restricted so as to maximize the probability of interworking between systems implementing different selections of such profile options, consistent with achieving the objectives of the profile. A profile makes explicit the relationships between a set of base standards used together (relationships that are implicit in the definitions of the Base Documents themselves) and may also specify particular details of each base standard being used. A profile may contain conformance requirements that are more specific and limited in scope than those of the base standards to which it refers. While the capabilities and behavior specified in a profile will always be valid in terms of the Base Documents, a profile may exclude some valid optional capabilities and optional behavior permitted in those base standards. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 254 6 Profiles ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Thus, conformance to a profile implies, by definition, conformance to the set of base standards that it references. However, conformance to that set of Base Documents does not necessarily imply conformance to the profile. 6.3.3.2 Main Elements of a Profile Definition Document The definition of a profile should comprise the following elements: - A concise definition of the scope of the function for which the profile is created and of its purpose - Reference to a set of base standards and other profiles, including precise identification of the actual texts of the base standards and profiles being used and of any approved amendments and technical errata, conformance to which is identified as potentially having an impact on achieving portability and interoperation using the profile - Specifications of the application of each referenced base standard and profile, covering recommendations on the choice of classes or subsets and on the selection of options, ranges of parameter values, etc. - A statement defining the requirements to be observed by systems claiming conformance to this profile, including any remaining permitted options of the referenced base standards and profiles, which thus become options of this profile Systems that interoperate can perform different but complementary roles (e.g., an initiator-responder or a master-slave relationship). In such a situation the profile should identify the separate roles that may be adopted by a system, and these should be stated as either mandatory requirements or options of the profile, as appropriate. 6.3.3.3 Profile Objectives _C_o_m_p_l_e_t_e_n_e_s_s A profile should be complete with respect to its functionality objectives. This may well be an iterative process, since the understanding of the requirements and standards will evolve. Completeness means that all areas where standards should be applied have been identified and the requirements defined. Where standards exist, they have been included, and the options within those standards have been addressed. Where standards do not exist, but are needed, this has been documented in the profile. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6.3 Guidance to Profile Writers 255 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS It may be appropriate to document (probably in a nonnormative appendix) specifications and alternatives available in areas where standards have not been defined. The meaning of this concept will be relative to the forum for acceptance of the profile. If the profile is targeted at ISO acceptance, then ISO DIS and IS standards should be the reference point, where as a US Government profile might be focused on FIPS and ANSI standards. Within private industry, consortium and even vendor specific specifications could be incorporated, keeping these as examples and not explicit requirements, which will simplify harmonization with formal standards as they emerge. Where standardized profiles are being developed and gaps are identified, the profile writer should identify the requirements that are not satisfied by a standard. If there is a preliminary specification available that addresses many of the requirements, that specification should be referred to informatively. _C_l_e_a_r__C_o_m_m_u_n_i_c_a_t_i_o_n_s A key objective for the profile is clear communications between the affected parties. Users, software developers, and platform suppliers all need to have the same terms and specifications. The application software developers and system vendors need a common set of specifications to target for their development efforts. _H_a_r_m_o_n_i_z_a_t_i_o_n Harmonization means making the profiles consistent with each other where they overlap. This can often be done among profiles even where the functional areas served differ greatly. This assures that the maximum practical agreement exists between different profiles, maximizing the implementations of that common ground. _V_a_l_i_d_a_t_i_o_n A profile addresses validation in two different ways. Firstly, by selecting options and parameters within the profile, validation is potentially made simpler. Secondly, by including more than one base standard, validation potentially becomes more difficult. Now validation extends beyond just insuring a single standard is being complied with into the area of insuring that the interactions between and among multiple base standards is also being complied with. _C_o_h_e_r_e_n_c_e The simple selection of a group of standards does not assure that they will work together on a platform in a predictable way. A profile should contain a matrix of all standard components compared to each other and Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 256 6 Profiles ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 state what relationship exists between them. A profile may be coherent if it states that between two standards no relationship needs to exist, that none shall exist, or that a specified relation shall exist. Not to speak to an intersection in the matrix would indicate that the issue of coherence has not been addressed. _G_a_p__I_d_e_n_t_i_f_i_c_a_t_i_o_n In the process of developing profiles, there may be gaps in coverage by standards that become apparent. These may exist in terms of the characteristics available with one standard that need to be made available from another, or missing standards, or additional functionality that is needed for a specific applications activity. So, an additional objective for a profile effort is to document the requirements for such additional work and forward it to the appropriate standards effort. Profile groups in industry should consider providing expertise to the associated standards groups to assure that the resulting standards meet the needs of that applications area. 6.3.3.4 Defining a Profile The process of creating a specific profile is broken down into three stages. These are the creation of a generic information system model, creation of an open system environment that supports application portability and interoperability, and the creation of a application- area-specific profile (see Figure 6-1). In the first stage, a generic model for an information system is constructed by abstracting the properties and functionality common to all possible information systems and choosing specific system features based on the application requirements of an enterprise, department, or application. Such a model is neither new nor earthshaking; it has been used for more than twenty years to understand, design, and specify a system, as well as to test, redesign, and refine that system. What is new is the refinement of generic models to design open systems for specific application areas. The second stage of the profile creation process requires the profile developer to identify and choose the functionality, standards or specifications, and interfaces required for application portability and interoperability. The profile developer should probably choose at most one base standard for each service identified. The criteria used for selecting base standards should take into account openness, completeness (maturity), stability, geographic coverage and publicness of the standard. The profile writer should also have in mind a precedence (e.g., international standards take precedence over national standards). There may also be other considerations, of course, such as performance, cost, design, etc. Examples of such considerations, that were used in selecting standards for this guide, can be found in 3.4.2. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6.3 Guidance to Profile Writers 257 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 6-1 - Development of a Profile To ensure that the open system environment produced is not just a paper standard, it is necessary to check that the component standards and specifications chosen are practical for users, marketable for vendors, integratable with each other, achievable in a short time, and have a good likelihood of widespread acceptance. The X/Open Common Application Environment and the IEEE POSIX.0 POSIX Open System Environment have been (or are being) produced in this way. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 258 6 Profiles ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 The third stage of the profile-creation process requires making further choices of functionality, standards, mandatory options within standards, subsets of standards, and interfaces to meet the open-systems requirements of a specific application area. As with open system environments, standards for a profile should be chosen based on international standards, national standards, formal professional group standards, consensus-defined consortia specifications, and de facto specifications. Also, where no standards exist for a particular functionality necessary to the application area in question, the profile developer should come up with a plan to produce the missing standard. In addition, the profile's component standards should be selected bearing in mind practicality, marketability, integration of component standards with each other, and user and vendor acceptance. The choice of functions and standards applicable to an application area results in a standardized application-area-specific profile. The MAP, TOP, and GOSIP profiles of OSI, as well as the POSIX.10 (supercomputing), POSIX.11 (transaction processing), and POSIX.13 (embedded realtime) profiles have been (or are being) defined in this way. 6.3.3.5 Types of Profiles Three different types of profiles have been, or are being, defined by the procedures described above: - Component Profiles - Application Area Profiles - Platform Profiles A Component profile is mostly a subset of a single standard. The profile d developers specify mandatory options for a specific domain, options that are not desirable for that domain, gaps in that parent standard, and, if necessary, specifications to fill that gap. Examples of such profiles are MAP, TOP, and GOSIP profiles and possibly the POSIX.13 embedded realtime POSIX profile if it continues to be based exclusively on functions chosen from the POSIX.4 realtime standard. An Application Area Profile is created from multiple standards that specify multiple, diverse types of functionality needed for a particular application area (e.g., database, networking, graphics, operating system). The application area profile developers specify all the diverse standards necessary for the application area in question. Within each standard, they identify mandatory options, functions and options that are not needed, gaps in the standards, and, if necessary, specifications to fill the gaps. Examples of application area profiles are the POSIX.10 supercomputing and POSIX.11 transaction processing profiles. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6.3 Guidance to Profile Writers 259 P1003.0/D13 A Platform Profile focuses on the functionality and interfaces needed for a particular type of platform. The platforms could be traditional platforms (such as time sharing systems) or relatively new or emerging platforms (e.g., workstations, personal computers, or symmetric multiprocessing systems). A platform profile could be created from one or multiple diverse standards. As with other types of profiles, the profile developers have to specify the standards, options, standards gaps, and if necessary, specifications to fill the gaps. Examples of platform profiles are the POSIX.18 Platform Profile for Traditional Multiuser UNIX systems and the POSIX.14 Multiprocessing profile. All three types of profiles can be seen in the next section. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 260 6 Profiles P1003.0/D13 Section 7: POSIX SP Profiling Efforts _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _W_e_n_d_y _R_a_u_c_h 7.1 Introduction This section maintains the list of currently known POSIX Standardized Profiles (POSIX SPs). This list is a factual record of which POSIX SPs exist, or are in preparation, together with a summary description of the scope, scenario, and model for each profile. These POSIX SPs might be useful as building blocks for other profiles. 7.1.1 Approved POSIX Standardized Profiles There are currently no approved POSIX SPs. 7.1.2 POSIX Standardized Profiles In-Progress The current efforts to develop POSIX SPs are summarized in Table 7-1. They are all being done by IEEE 1003 POSIX working groups. A brief summary of each effort is given in clauses 6.4 and 6.5. 7.2 General Purpose POSIX SPs 7.2.1 POSIX Platform Environment Profile (PEP) 7.2.1.1 Rationale and Overview The POSIX Platform Environment Profile (PEP), IEEE POSIX.18, is a platform profile based on POSIX.1 {2} and related standards. It defines the functionality and standards needed for a system that is as similar as possible to the traditional UNIX operating system's interactive, multiuser development and run-time environment. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 7.2 General Purpose POSIX SPs 261 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Table 7-1 - POSIX SPs In Progress __________________________________________________________________________________________________________________________________________________ Project Profile Profile Name Taxonomy Name Type _____________________________________________________________________________________________ IEEE P1003.10 Supercomputing Application profile IEEE P1003.11 Transaction Processing Application profile IEEE P1003.13 Realtime Full Function Application-oriented profile IEEE P1003.13 Realtime Embedded Control System Application-oriented profile IEEE P1003.13 Realtime Intermediate Application-oriented profile IEEE P1003.14 Multiprocessing Application Support Platform profile IEEE P1003.18 USI-P001 POSIX Platform Environment Profile Platform profile NOTES: (1) At this time it is not known whether the three realtime profiles will be contained within a single multipart POSIX SP, or separate single-part POSIX SPs. (2) While the issue of a taxonomy for POSIX SPs has not been decided, a placeholder has been provided and a proposed taxonomical name for one profile has been listed. __________________________________________________________________________________________________________________________________________________ The PEP is valuable for many users, vendors, programmers, and procurement officers who do not have the time or desire to analyze and specify all the individual interfaces for a system they need. The PEP obviates this analysis by enabling the users to point to a single document that specifies exactly what they should order to obtain a system that looks like traditional UNIX systems, except that the PEP will be totally based on formal standards. 7.2.1.2 Content of the Platform Environment Profile The POSIX Platform Environment Profile consists of: - All of POSIX.1 {2} along with options that correspond to the US Government's Application Portability Profile (APP) (FIPS 151-1); - All of the POSIX.2 {_r_e_f} (Shell and Utilities) and POSIX.2a (User Portability Extension); and - All of ANSI X3.159 C. To reflect the goals and intent of the POSIX.18 working group, the PEP document also commits to specifying additional specifications in the Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 262 7 POSIX SP Profiling Efforts ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 future, when those specifications are completed and approved as standards. These specifications include system administration, secure/trusted systems extensions, realtime facilities, verification testing facilities, Ada and FORTRAN language bindings, graphical user interfaces, and network interface facilities. The PEP is expected to be the pioneer Application Environment Profile submitted to ISO for international approval. The concept of Application Environment Profiles and Platform Profiles is new. How ISO handles the international standardization of the PEP, and the profile issues resolved, will likely set a precedent followed in the development of other profile standards. 7.2.2 Multiprocessing Systems Platform Profiles 7.2.2.1 Rationale and Overview The POSIX Multiprocessing Systems Profile (IEEE POSIX.14) is a platform profile. Like the POSIX PEP (POSIX.18), the Multiprocessing Systems profile defines the functionality, standards, and options within standards that are needed for development and execution on a multiprocessing platform. The Multiprocessing Systems profile is intended for use by multiprocessor vendors, application developers, users, and system administrators. It is important because it is designed to support portability of multiprocessing applications, as well as users and system administrators in multiprocessing environments. The Multiprocessing Systems Profile has two major goals. The first one is to make POSIX safe for multiprocessing. This goal requires the POSIX.14 working group to identify and address the caveats, problems, and failings of POSIX base standards for multiprocessing platforms. Examples of these failings range from reentrant-function problems to potential problems with threads. The second goal is to make POSIX useful for multiprocessing. This goal requires the POSIX.14 working group to ensure that POSIX supports the functionality needed by multiprocessing platforms. An example of this is ensuring that POSIX has capabilities to allow vendors to parallelize software functions. In the absence of parallelizing standards, the details of what happens when the same software functions are used on different multiprocessor system vary. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 7.2 General Purpose POSIX SPs 263 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 7.2.2.2 Content of the Multiprocessing Systems Profile The Multiprocessing Systems platform profile identifies standards, options, and gaps in the standards relevant to multiprocessing. It also identifies additional requirements not satisfied by existing standards and, in an informative annex, suggests interfaces to extended services that can satisfy some of these requirements. In addition, the POSIX.14 Multiprocessing Systems Group will propose changes and amendments to a variety of relevant standards in order to encourage the specifiers of these standards to add functions and options that accommodate multiprocessing requirements. Standards particularly relevant to the Multiprocessing System Profile include the POSIX Pthreads extension (IEEE POSIX.4a), the supercomputing batch scheduling standard (IEEE POSIX.15), and the supercomputing proposed checkpoint and restart facilities (IEEE POSIX.10). Since checkpoint and restart facilities will be added to the POSIX.1 {2} standard, POSIX.1 {2} is also of concern to the Multiprocessing Profile. The Multiprocessing Systems profile will specify both general-purpose- computing and multiprocessor-specific standards. General-purpose standards planned or under consideration for the Multiprocessing Systems profile include: - The IEEE POSIX.1 core POSIX system, POSIX.2 POSIX Shell and Utilities, and POSIX.2a User Portability Extension; - The IEEE POSIX.4 realtime extension; - The IEEE POSIX.4a: POSIX Pthreads extension; - The IEEE POSIX.6 POSIX security standard and POSIX.7 system administration standard; - The Ada language bindings (IEEE POSIX.5) and FORTRAN language bindings (IEEE POSIX.9) to POSIX; - The IEEE POSIX.10 Supercomputing Profile, POSIX.11 Transaction Processing Profile, and POSIX.13 Realtime Applications Profiles. As other standards emerge, they too will be incorporated in the Multiprocessing Systems profile. An annex of this document will deal with, and list, relevant emerging standards to provide an idea of the Multiprocessing Systems profile's direction. Multiprocessing-specific requirements identified by the POSIX.14 Multiprocessing working group include: Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 264 7 POSIX SP Profiling Efforts ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - System administration tools for multiprocessors; - Parallelizing compilers; - Explicit parallelism; - Threads; - Thread-safe libraries; - Message-passing IPC; - Parallel utilities (e.g., find, grep, make, etc.); - Scheduler controls; - Processor allocation: mandatory/advisory; - Processor binding; - Degree of symmetry: I/O, computation, memory. Standards will be needed for many of these requirements. Many of these requirements will, therefore, become the subject of a POSIX.14 working group proposal for a new standardized function or an option in other standards. 7.2.3 Supercomputing 7.2.3.1 Rationale and Overview The Supercomputing Applications Environment Profile (IEEE POSIX.10) is a profile designed to support application and programmer portability in POSIX-based supercomputer environments. The profile's goal is to allow supercomputer application code to be ported to other sites, reduce the learning curve of users, and encourage production of timely third-party applications. The need exists for such a profile because of the differences between supercomputing environments and traditional application environments. One difference is that supercomputing jobs are computationally intensive, very long running, and very demanding of resources. Another is that the cost of the supercomputer CPU and many of its peripheral resources is extremely high. Ordinary POSIX standards are not applicable in their entirety to supercomputer environments because the traditional UNIX-based POSIX functions are not adequate to meaningfully manage the use of, and Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 7.2 General Purpose POSIX SPs 265 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS accounting for, a supercomputer or its resources. Furthermore, supercomputers need much better tape handling, multiprocessing, and other capabilities than POSIX or UNIX specifications presently support. 7.2.3.2 Content of the Supercomputing Profile The Supercomputing Application Environment Profile identifies POSIX base standards and other relevant standards that support supercomputing requirements. Where none exist, the POSIX.10 working group will define the functionality itself, or instigate the formation of a new group to define it. In addition, the POSIX.10 working group is taking some of the traditional modifications built to allow UNIX systems to run on supercomputers, and making those modifications both consistent across supercomputers and portable to users, system administrators, and applications. Base computing standards specified by the supercomputing profile (or planned for specification when the standards are completed) include: - The IEEE POSIX.1 {2} core POSIX system, POSIX.2 POSIX Shell and Tools, and POSIX.2a User Portability Extensions (and the corresponding FIPS standards); - The IEEE POSIX.4 realtime work (particularly the use of its asynchronous I/O facility); - The IEEE POSIX.6 POSIX security standard and POSIX.7 system administration standard; - Several graphics standards, including ISO GKS, PHIGS, and CGM, ANSI IGES, and the X Consortium's PEX. - X3H2.6 (also called X11) for windowing; - Several programming languages, including ISO, ANSI, and the NIST's FIPS for C, FORTRAN-77, Pascal, Ada, Common LISP, and COBOL. - TCP/IP protocol stacks and network applications (e.g., file transfer and messaging) now and OSI in the long-term; - The IEEE POSIX.8 Transparent File Access standard for distributed file management; +o The X3T5.5 Remote Procedure Call (RPC). The nonstandardized and nonavailable supercomputing functions identified in the POSIX.10 profile include: Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 266 7 POSIX SP Profiling Efforts ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 - Batch system scheduling, administration, and network definition; - Checkpoint recovery; - A resource manager; - A better tape management facility; - Better mass storage/archiving facilities. There are no existing standards for batch scheduling and administration facilities. Batch scheduling and administration extensions to POSIX base standards are currently being defined by the IEEE POSIX.15 working group- --a group spawned by the Supercomputing profile working group. To meet recovery and archiving requirements, the POSIX.10 working group defined system interfaces for functions that perform ``checkpoint,'' ``restart,'' and better magnetic tape handling (e.g., to rewind a tape under program control). These interfaces have been submitted to the POSIX.1 working group for inclusion in the next POSIX.1 {2} revision. 7.2.4 Transaction Processing 7.2.4.1 Rationale and Overview The Transaction Processing Applications Environment Profile (IEEE 1003.11) is intended to support the development of portable online transaction processing (OLTP) applications in POSIX environments. This profile is targeted at application developers and open system services suppliers. It is important because transaction processing is a major area of business for most large computer vendors and it plays a major role in the daily operations of most users. There are currently no existing POSIX functions that specifically address OLTP needs. 7.2.4.2 Content of the Transaction Processing Profile The Transaction Processing profile's goal is to identify the interfaces and standards relevant to OLTP, and optional functions in existing standards that must be made mandatory for OLTP applications. The profile will specify general-purpose standards, as well as standards unique to OLTP. The Transaction Processing Profile's specifications include or plan the following generic and transaction processing-specific standards: - The ISO/IEC 9945-1: 1990 (POSIX 1003.1) core POSIX system interfaces (including required options, minimum values for certain Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 7.2 General Purpose POSIX SPs 267 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS variables, and particular environment variables needed for OLTP applications); - The IEEE 1003.2 Shell and Utilities' software development utilities option, C language development utilities option, and C language bindings option; - The IEEE 1003.2 getconf utility; - The realtime files and asynchronous input and output features from the IEEE 1003.4 Realtime POSIX Extensions; - The IEEE 1003.6 POSIX security standard; - The ISO/IEC, ANSI, and FIPS C and COBOL programming languages; - TCP/IP networking in the short term and OSI in the long-term; - The X3T5.5 Remote Procedure Call (RPC) - The ISO SQL database language; - The ISO Distributed Transaction Processing 10026.1, .2, and .3 for communication of transaction information. The Transaction Processing profile also identifies extensions needed to existing standards to support distributed transaction processing. Important extensions that need to be defined include those related to the two-phase commit, as well as others related to making RPCs robust. The P1003.11 working group is working with the ISO RPC Group to add transaction semantics to the Networking working group's RPC specifications. These extensions will be incorporated in the Transaction Processing profile. Plans are also for the 1003.11 profile to draw on the transaction processing work being produced by the X/Open consortium, particularly on the XA interfaces (the interface between a Transaction Manager and a Resource Manager). 7.2.5 Realtime Application Profiles 7.2.5.1 Rationale and Overview Different types of realtime applications have different characteristics and diverse requirements. For example, embedded systems generally do not need the full functionality of an operating system, nor do they require all the IEEE POSIX.4 realtime extensions. Compliance with the entire realtime standard and/or POSIX operating system interfaces could reduce the embedded system's responsiveness and increase the amount of memory Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 268 7 POSIX SP Profiling Efforts ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 needed for systems that need to be embedded in limited space. High-end realtime systems, on the other hand, have softer realtime requirements. However, they need the full operating system and realtime functionality. Therefore, the POSIX.13 working group was formed to define profiles for various types of realtime applications. The realtime profiles defined will determine which interfaces must be implemented for a given type of realtime system to claim conformance to the realtime standard. 7.2.5.2 Content of the Realtime Application Profiles The POSIX.13 working group is defining three different realtime application profiles: - Low-end, embedded systems (often known as ``hard'' realtime systems); - Mid-range realtime systems with medium-level critical realtime constraints; - High-end realtime systems. 7.2.5.2.1 Minimal Embedded Realtime Profiles Embedded realtime systems are typically standalone systems used for robot controllers, automated systems controllers, instrumentation, high-speed data acquisition, satellite subsystem control, some process control, and some testing. Time-critical responsiveness is a key requirement of embedded systems. In the absence of a standard, the realtime functionality required for embedded systems is generally provided by a proprietary realtime kernel or a simple home-grown monitor using memory mapped I/O. Since low-end embedded systems need only minimal functionality, the POSIX.13 working group will select a relatively small number of POSIX.4 and POSIX.1 {2} functions that will be required for portable realtime embedded systems. These functions will be selected for three types of embedded applications, each of which comprise a sort of embedded system ``subprofile.'' One type of embedded application has no requirements for a file system or multiple processes. The second type of embedded application requires a file system, but not multiple processes. The third type of application requires multiple processes, but no file system. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 7.2 General Purpose POSIX SPs 269 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS 7.2.5.2.2 Mid-Range Realtime Profiles The mid-range, or intermediate-level realtime systems profile is designed to support distributed realtime applications. These applications are distributed across multiple processors sharing a high-speed communication channel (e.g., a backplane) or across a local network. Mid-range realtime applications typically are used in a controller for a group of robots, to control a subsystem on the factory floor, or in a relatively small simulation system. Distributed realtime control systems have many of the same needs as embedded systems. However, mid-range realtime systems require more functionality than do systems used for embedded realtime control. At a minimum, distributed realtime systems require support for transparent, external processor-to-processor communications to support connectivity between the realtime system and other types of applications, as well as support for multiple flows of control (via multiprocessing or multithreading). To satisfy the requirements of distributed realtime systems, the mid- range application environment profile is specifying most of the POSIX.4 functionality, along with the relevant options from the POSIX.4 and POSIX.1 {2} standards. This profile is applicable to either a process or a thread model. 7.2.5.2.3 High-End Realtime Profiles The high-end realtime application profile is applicable to complex realtime systems. Such high-end realtime systems are typically used in military command and control, in space station control systems, in systems that control robot or factory subsystems, and as the operating system for a high-end simulation system. Because of the great complexity of high-end realtime applications and the large number of users typically involved, high-end realtime applications require a number of realtime and nonrealtime capabilities. For example, besides realtime responsiveness and reliability, high-end realtime systems must support many languages, distributed processing, distributed file systems, and system security. Also, realtime support is often required for fault tolerance, distributed database management, networking, graphics facilities, and possibly parallel processing or multiprocessing. The level of realtime response that must be supported varies with the application. Since high-end realtime systems have a greater design complexity than embedded or mid-range systems, and need much greater functionality, they will most likely require all or most of the POSIX.4 and POSIX.1 {2} specifications. The POSIX.4a Threads extension is optionally required, particularly to support Ada programs which are multithreaded. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 270 7 POSIX SP Profiling Efforts ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 P1003.0/D13 Annex A (informative) Considerations for Developers of POSIX SPs A.1 Introduction _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _B_o_b _G_a_m_b_r_e_l The contents of this Annex are illustrative of rules that might be developed for the submitters of POSIX Standardized Profiles (SPs). This Annex contains modifications and comments relating to the use of the _T_C_O_S-_S_S_C _P_O_S_I_X _S_t_a_n_d_a_r_d_s _S_t_y_l_e _G_u_i_d_e {B6} in POSIX SPs. A.2 Scope While Section 6 addressed profiles generally, this Annex addresses considerations for developers of formal POSIX Standardized Profiles. It builds directly upon the concepts, principles, and guidance of Section 6. _R_J_G: _T_h_i_s _A_n_n_e_x _i_s _n_o_t _c_o_m_p_l_e_t_e, _i_n _t_h_a_t _m_o_r_e _w_o_r_k _i_s _r_e_q_u_i_r_e_d _i_n _t_h_e _d_o_m_a_i_n _o_f _P_O_S_I_X _p_r_o_f_i_l_e_s. _F_u_t_u_r_e _w_o_r_k _i_n _t_h_e _a_r_e_a _o_f _p_r_o_f_i_l_i_n_g _w_i_l_l _b_e _d_o_n_e _b_y _I_E_E_E _a_n_d _t_h_e _s_t_a_n_d_a_r_d_s _c_o_m_m_u_n_i_t_y. _T_h_i_s _d_o_c_u_m_e_n_t, _a_n_d _t_h_e _g_u_i_d_a_n_c_e _i_t _p_r_o_v_i_d_e_s, _w_i_l_l _b_e _u_p_d_a_t_e_d _a_s _a_p_p_r_o_p_r_i_a_t_e. _T_h_e _m_a_j_o_r _a_r_e_a_s _e_x_p_e_c_t_e_d _t_o _b_e _a_d_d_r_e_s_s_e_d _a_r_e: - _I_n_t_e_r_n_a_t_i_o_n_a_l _s_t_a_n_d_a_r_d_i_z_a_t_i_o_n _c_o_n_s_i_d_e_r_a_t_i_o_n_s - _C_o_n_f_o_r_m_a_n_c_e _i_s_s_u_e_s - _T_a_x_o_n_o_m_y _o_f _P_O_S_I_X _S_P_s - _R_e_g_i_s_t_r_a_t_i_o_n _o_f _P_O_S_I_X _S_P_s - _D_e_l_e_g_a_t_i_o_n _o_f _a_u_t_h_o_r_i_t_y _t_o _c_a_l_l _s_o_m_e_t_h_i_n_g _a _P_O_S_I_X _S_P (_N_o_t_e: _C_u_r_r_e_n_t_l_y, _t_h_i_s _d_o_c_u_m_e_n_t _d_o_e_s _n_o_t _p_r_o_h_i_b_i_t _a_n_o_t_h_e_r _g_r_o_u_p _b_e_s_i_d_e _I_E_E_E _f_r_o_m _c_a_l_l_i_n_g _t_h_e_i_r _d_o_c_u_m_e_n_t _a _P_O_S_I_X _S_P.) Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.2 Scope 273 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS - _C_l_a_r_i_f_i_c_a_t_i_o_n _o_f _b_a_s_e _s_t_a_n_d_a_r_d_s _r_e_f_e_r_e_n_c_i_n_g _i_s_s_u_e_s _s_u_c_h _a_s _s_u_b_s_e_t_t_i_n_g _a_n_d _t_h_e _h_a_n_d_l_i_n_g _o_f _o_p_t_i_o_n_s - _E_d_i_t_o_r_i_a_l _i_s_s_u_e_s _s_u_c_h _a_s _g_u_i_d_a_n_c_e _o_n _t_h_e _c_o_r_r_e_c_t _l_e_v_e_l _o_f _d_e_t_a_i_l - _A_d_d_i_t_i_o_n_a_l _g_u_i_d_a_n_c_e _o_n _r_e_f_e_r_e_n_c_i_n_g _b_a_s_e _s_t_a_n_d_a_r_d_s _a_n_d ``_s_t_a_n_d_a_r_d_s _i_n _p_r_o_g_r_e_s_s'' A.3 The Role of POSIX SPs In 6.3.3.5, a classification scheme was given for profiles in which 3 different ``types'' were identified. That scheme is based, essentially, on the scope covered by the profile. Another useful classification scheme, based on scope and on who develops the profiles, is presented in this annex. Figure A-1 shows these classes of profiles and the relationships between them and base standards. _________________________________________________________________________ _________________________________________________________________________ Figure A-1 - Universe of Profiles and Standards Base standards cover a universe of diverse needs. POSIX base standards (e.g., POSIX.1 {2}, P1003.4, ...) cover a narrower set of needs related to ``POSIX.'' In the figure, the POSIX base standards are shown as a Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 274 A Considerations for Developers of POSIX SPs ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 small subset of the larger world of base standards. At the other end of the spectrum, organization-specific (e.g., company- specific) profiles are large in number and range even more widely in their coverage. (There are many more organizations procuring systems, and effectively writing profiles, than there are committees writing standards.) Industry-specific profiles are based on specific industry needs. From the point of view of the organization-specific profile writer, industry specific profiles are applicable to many organizations (in the same industry), and hence are possibly not precisely what any specific individual organization needs. They address the broad consensus of the industry, from which there is usually deviation when you look at individual organizations whose needs range further. Standardized Profiles are formal balloted documents. POSIX SPs are the subset of standardized profiles that pertain to the POSIX base standards. While not limited to just POSIX base standards, POSIX SPs nonetheless provide a distinctly POSIX-oriented view of the base standards. An organization wishing to procure a ``POSIX'' based system, then, could first develop its own organization-specific profile, which it could base on POSIX-oriented industry-specific profiles (if available), which in turn could be based on POSIX SPs, which of course are based on the various POSIX base standards. POSIX SPs provide an industry-neutral building block for creating industry specific profiles. The developers of POSIX SPs do not have to have knowledge of any particular industry. They furthermore help ensure coherence among the many base standards referenced, particularly among the various POSIX base standards. As such, probably, most POSIX SPs will be created by the IEEE POSIX working groups meeting concurrently with IEEE POSIX base standards working groups. Meeting concurrently at the same place helps ensure the coherence of the base standards and the harmony among the POSIX SPs. A.4 Special Rules for POSIX SPs While no rules have yet been developed by IEEE for POSIX SPs, the remainder of this annex gives examples of what such rules might say and identifies some issues for which rules might be drafted. The following criteria for calling a profile a POSIX SP were developed according to some general principles that have the aim of giving definite value to the word ``POSIX'' when used with regards to profiles. The general principles are: Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.4 Special Rules for POSIX SPs 275 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS (1) There is minimum content. Specifically, a POSIX SP must reference some part of the suite of POSIX base standards. (Which part specifically is contentious.) (2) The POSIX SP must follow a specific approach to conformance (specifically the P1003.3.1 test methodology.) (3) The POSIX SP must adhere to the POSIX Reference Model. (4) There is maximum content; i.e., some consideration must be given to how the POSIX SP goes beyond the POSIX OSE as described in this guide. (5) Exceptions to the previous principles are expected, requiring a rule-making and enforcement body to make those exception decisions. POSIX SPs are Standardized Profiles that are related to ``POSIX.'' This subclause specifies the rules that need to be followed that distinguish POSIX SPs from ``Non-POSIX SPs''. Each POSIX SP is based on, and shall include, one of the following two base standards sets: (1) POSIX.1 {2} or POSIX.2 (as verified by the P1003.3 methodology), or (2) A particular subset of POSIX.1 {2} and P1003.4 that is being specified for a Minimal Realtime profile (as verified by the P1003.3 methodology.) Additionally, each POSIX SP adheres to the structure defined by the POSIX OSE reference model. An approved POSIX SP shall make reference only to base standards identified in this guide (1003.0) as being part of the POSIX OSE. Two specific exceptions to this general rule are allowed for as described here: (1) Reference can be made to required base standards that are clearly outside of the scope of the POSIX OSE. Examples of the functionality that may require the use of this expedient are: - Physical connectors - Electrical characteristics - Safety requirements Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 276 A Considerations for Developers of POSIX SPs ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Such reference to items outside the scope of the POSIX OSE shall be justified on a case-by-case basis. It shall be accompanied by details of the body responsible for the distribution and maintenance of the referenced base standard. (2) Reference can be made to required base standards that are being proposed for inclusion in a future version of the guide. Examples of this would be specification of a later version of a base standard that is already included within the POSIX OSE, or of an additional programming language base standard, not yet included within the POSIX OSE. In such cases, the POSIX SP should be identified as a POSIX Preliminary SP and the specific references should be clearly noted and justified on a case by case basis. A POSIX Preliminary Standardized Profile (POSIX Preliminary SP) is a POSIX SP that satisfies all requirements of a POSIX SP except that it is not a subset of the POSIX OSE. [It therefore contains at least one standard or profile that is outside the POSIX OSE. It is expected that application would be made to POSIX.0 to include the standard(s) or profile(s) in the POSIX OSE.] A further restriction of POSIX SPs is the necessity to (normatively) reference only standards that are recognized by the IEEE. This is limited to IEEE and ISO standards. Approval of a POSIX SP shall not change the status of any documents referenced by it. The development of a POSIX SP may indicate the need to modify or to add to the requirements specified in a base standard. In this case, it is necessary for the POSIX SP developer to liaise with the body responsible for that base standard so that the required changes may be made through established methods such as defect reporting, amendment procedures, or the introduction of new work. A.5 Other Issues A significant number of issues remain to be addressed concerning the management of POSIX SP development. Some of the issues and the concerns are summarized here. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.5 Other Issues 277 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Coherence The insurance of coherence among the many base standards referenced by a profile has been found by profile writers to be an onerous task. The profile writer's burden could be eased significantly if base standards writers address coherence at the outset. Specifically, all the P1003.x base standards should be developed to maximize their coherence. This is d seen as a management issue for TCOS-SEC, the sponsoring body of the d P1003.x standards. Conformance The development of conformance statements and test methods for profiles is a significant challenge for profile writers. The challenge is most acute in the area of conformance of standards that are being developed outside of P1003. A premise for the profile writing rules associated with conformance must be that the profile writers are not really experts in the referenced standards. Profile writers (especially at this early period in their development) must not be overburdened with untested conformance writing rules. A possible solution is to create a new project under the auspices of P1003.3 to actually generate new test methods and actually write the necessary assertions for the first profile. (This approach was used also for the initial POSIX base standard.) Base Standards Working Groups Because profile writers are in some sense the customers of base standards, it is important for base standards writers to address with priority and urgency the gaps identified in the development of POSIX SPs. Scope and Number of POSIX SPs How many different POSIX SPs are appropriate and how broadly ranging should be their scope? Should POSIX SPs be rather narrowly focused, spanning just a few base standards, or should they address a large number of base standards? Issues Pertaining to Referencing Base Standards Many practical writing issues pertain to referencing, for instance, parts of base standards. This includes not only referencing options, but even the concept of subsetting, or reducing the functionality of a base standard. Also an issue is how to reference multiple versions of the same standard (e.g., two different COBOL standards.) Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 278 A Considerations for Developers of POSIX SPs ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 POSIX SP Procedures and Rules What does it mean to be a POSIX SP? Rule making for use of the word ``POSIX'' must address criteria for such use. Also, many issues remain to be resolved in the area of ballot procedures. Should IEEE delegate to others the ability to develop POSIX SPs? If so, should IEEE maintain a registry of such efforts? A.6 Conformance to a POSIX SP A POSIX SP must address test methods for itself. In the simplest case, testing the base standards referenced is sufficient. In more complex cases, additional test methods will be necessary. In the worst case (if a base standard is subsetted, for example), the test methods for the base standards may have to be rewritten or expanded within the POSIX SP. At the same time, P1003.3 will have to consider revisions to the _T_e_s_t _M_e_t_h_o_d_s _f_o_r _M_e_a_s_u_r_i_n_g _C_o_n_f_o_r_m_a_n_c_e _t_o _P_O_S_I_X to address test methods for POSIX SPs (e.g., additional assertion types, minimum requirements for testing POSIX SPs, ...) _R_J_G: _I _t_h_o_u_g_h_t _a_b_o_u_t _a_d_d_i_n_g _s_t_u_f_f _h_e_r_e _f_r_o_m _T_R _1_0_0_0_0, _b_u_t _o_n _s_e_c_o_n_d _t_h_o_u_g_h_t _i_t _s_e_e_m_s _t_h_a_t _a _j_o_i_n_t _e_f_f_o_r_t _b_e_t_w_e_e_n _P_1_0_0_3._0 _a_n_d _P_1_0_0_3._3 _t_o _d_e_v_e_l_o_p _t_h_i_s _m_a_t_e_r_i_a_l _w_o_u_l_d _b_e _m_o_r_e _a_p_p_r_o_p_r_i_a_t_e. A.7 Structure of Documentation for POSIX SPs This clause gives specific format and content requirements to profile writers who are developing POSIX SPs. A.7.1 Principles The requirements for content and format of POSIX SPs are based on the following principles: (1) Profiles shall be directly related to base standards and conformance to profiles shall imply conformance to base standards. (2) POSIX SPs shall follow the rules for drafting and presentation of POSIX SPs detailed here. (3) POSIX SPs are intended to be concise documents that do not repeat the text of the base standards. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.7 Structure of Documentation for POSIX SPs 279 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS (4) Profiles making identical use of particular base documents shall be consistent, down to the level of identical wording in the POSIX SPs for identical requirements. A.7.2 Multipart POSIX SPs Many profiles will be documented and published as individual POSIX SPs. However, where close relationships exist between two or more profiles, a more appropriate technique can be used. Common text between related profiles is essential to ensure consistency, portability, and interworking, to avoid unnecessary duplication of text, and to aid writers and reviewers of POSIX SPs. A _s_i_n_g_l_e-_p_a_r_t _P_O_S_I_X _S_P shall not contain the definition of more than one profile. The following rules apply to _m_u_l_t_i_p_a_r_t _P_O_S_I_X _S_P_s: (1) A multipart POSIX SP shall contain the definition of a complete profile or of a related set of profiles. (2) A part of a multipart POSIX SP may contain a section of the definition of one or more profiles. (3) Where a multipart POSIX SP includes more than one profile, the part structure shall permit each profile to be the subject of a separate ballot; i.e., its constituent profiles shall be clearly identifiable, and the multipart structure shall ensure that this can be accomplished. (4) Wherever possible, the references made from one part to another should be to complete parts. However, controlled use of one-way references to sections of other parts is permitted in order to obtain a reasonable multipart structure. Because there may also be potential disadvantages from overuse of the multipart POSIX SP capability, such as difficulties in gaining approval for a complex linked set of parts, or reduction of the content of a part to a small amount of text, considerable care should be taken with its use. NOTES: (1) When a section of text appears in several profiles, possibilities exist for sharing the corresponding code (etc.) for the implementation of several profiles, and the tests applicable to the use of the referenced base standards will be applicable to the testing of several profiles. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 280 A Considerations for Developers of POSIX SPs ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 (2) It follows that it is in the interest of the implementors to promote the identification of common sections of text as parts of POSIX SPs, but even more to promote, in future standardization and profile work, the use of already defined parts of POSIX SPs, so that profiles fall into a few ``common molds.'' In particular, this allows implementation of a part of a POSIX SP with confidence that it may be used in the implementation of profiles as yet undefined, so that products are open to future development. (3) Possibilities exist for a complete profile to be referenced from within the definition of another profile. A.8 Rules for Drafting and Presentation of POSIX SPs Throughout this Annex, which is concerned with documentation content and layout, reference is made to POSIX SPs. A POSIX SP, or part thereof, may contain a whole profile definition or part of one or more profile definitions. The wording of the Annex assumes that it is describing an undivided POSIX SP that defines one profile in its entirety. Its application to the other cases is easily deduced. Note, however, that each part of a Multipart POSIX SP shall use the same format as far as appropriate. A.8.1 General Arrangement The elements that together form a POSIX SP are classified into three groups: (1) Preliminary elements are those elements that identify the POSIX SP, introduce its content, and explain its background, its development, and its relationship with other standards and POSIX SPs. (2) Normative elements are those elements setting out the provisions with which it is necessary to comply in order to be able to claim conformity with the POSIX SP. (3) Supplementary elements are those elements that provide additional information intended to assist the understanding or use of the POSIX SP. These groups of elements are described in the following clauses. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.8 Rules for Drafting and Presentation of POSIX SPs 281 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS A.8.2 Preliminary Elements A.8.2.1 Foreword The foreword shall appear in every POSIX SP. It consists of a general part giving information relating to the organization responsible and a specific part giving as many of the following as are appropriate: - An identification of the organization or committee that prepared the POSIX SP; information regarding the approval of the POSIX SP - A statement that the POSIX SP cancels or replaces other documents in whole or in part - A statement of significant technical changes from the previous edition - A statement of which annexes are normative and which are informative A.8.2.2 Introduction The introduction shall appear in every POSIX SP. It gives specific information about the process used to draft the POSIX SP and about the degree of international harmonization that it has received. A.8.3 General Normative Elements A.8.3.1 Title The title shall be composed of the following three elements: (1) An introductory element: _S_t_a_n_d_a_r_d _f_o_r _I_n_f_o_r_m_a_t_i_o_n _T_e_c_h_n_o_l_o_g_y (2) An identification element: _P_O_S_I_X _S_t_a_n_d_a_r_d_i_z_e_d _P_r_o_f_i_l_e (3) A main element indicating the subject matter of the POSIX SP. For a Multipart POSIX SP, this element shall be subdivided into a general title element common to all parts, and a specific title element for each part; where necessary, this specific element may include the identifier of an individual profile. The first word of this element should be the word ``POSIX''. Example: Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 282 A Considerations for Developers of POSIX SPs ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Standard for Information Technology -- POSIX Standardized Profile -- POSIX Transaction Processing A.8.3.2 Scope This element contains two subclauses as follows: (1) General This element shall appear at the beginning of the POSIX SP or POSIX SP part to define without ambiguity the purpose and subject matter of the document, thereby indicating the limits of its applicability. It shall not contain requirements. (2) Scenario If the POSIX SP or POSIX SP part defines a profile, it shall include (where appropriate) the ``scenario'' of the profile; i.e., an illustration of the environment within which it is applicable. This may show in a simplified graphic form how this fits within the POSIX Reference Model. A profile should first introduce the functional area being addressed and the applications activities within that area. The requirements that have been addressed should be delineated, as well as those areas outside of the scope of the profile. A.8.3.3 Normative References This element shall give a list of normative documents (base standards), with their titles and publication dates, to which reference is made in the text in such a way as to make them indispensable for the application of the POSIX SP. Where published amendments or technical errata to base standards are relevant to the definition of the profile in such a way as to have a potential impact on interworking or portability, they shall be explicitly referenced here. Reference shall also be made to this guide. A.8.4 Technical Normative Elements Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.8 Rules for Drafting and Presentation of POSIX SPs 283 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS A.8.4.1 Requirements This element includes clauses relating to the use made of each of the main base standards referenced in the profile definition. The content and layout of these clauses are not defined, but can be tailored to the type of material that has to be specified in each case. The information given shall not repeat the text of the base standards, but shall define the choices made in the profile of classes, subsets, options and ranges of parameter values. It shall be in the form of conformance requirements and may, where appropriate, be given in tabular form. See 6.3.3 for more detail concerning the nature of the content required in this element of a POSIX SP. A.8.4.2 Normative Annexes Normative annexes are integral sections of the POSIX SP that, for reasons of convenience, are placed after all other normative elements. The fact that an annex is normative (as opposed to informative) shall be made clear by the way in which it is referred to in the text, by a statement to this effect in the foreword, and by an indication at the head of the annex itself. A.8.5 Supplementary Elements A.8.5.1 Informative Annexes Informative annexes give additional information and are placed after the normative elements of a POSIX SP. They shall not contain requirements. The fact that an annex is informative (as opposed to normative) shall be made clear by the way in which it is referred to in the text, by a statement to this effect in the foreword, and by an indication at the head of the annex itself. Informative annexes provide a point for documenting useful information for the users of a profile that poses no requirements. Such annexes can include: (1) Specification of additional standards or options that will make the profile useful for specific locales (character sets, etc.) (2) Pointers to the referenced standards and information on ordering these Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 284 A Considerations for Developers of POSIX SPs ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 (3) Pointers to related specifications that may provide additional insight or potentially serve to fill gaps in the profile (4) Comments and concepts in using the profile for various target readers. This could include use in procurements (perhaps cross referencing related procurement standards like the FIPS in the US). The annex may be used to provide recommendations for use that are not warranted in the standard (e.g., ``Algol is not recommended for new applications development''). Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. A.8 Rules for Drafting and Presentation of POSIX SPs 285 P1003.0/D13 Annex B (informative) Bibliography _H_L_J: _T_h_i_s _a_n_n_e_x _s_h_o_u_l_d _i_n_c_l_u_d_e _r_e_f_e_r_e_n_c_e_s _t_o _s_t_a_n_d_a_r_d_s, _b_o_o_k_s, _a_r_t_i_c_l_e_s, _e_t_c., _t_h_a_t _a_r_e _n_o_t _r_e_q_u_i_r_e_d _f_o_r _a_n _i_n_t_e_g_r_a_l _u_n_d_e_r_s_t_a_n_d_i_n_g _o_f _t_h_e _d_o_c_u_m_e_n_t (_a_s _a_r_e _t_h_e _e_n_t_r_i_e_s _i_n _N_o_r_m_a_t_i_v_e _R_e_f_e_r_e_n_c_e_s). _I _h_a_v_e _e_n_c_l_o_s_e_d _s_o_m_e _s_a_m_p_l_e_s _t_h_a_t _y_o_u _s_h_o_u_l_d _m_a_t_c_h _i_n _s_t_y_l_e, _b_u_t _n_o_t _n_e_c_e_s_s_a_r_i_l_y _i_n _s_e_l_e_c_t_i_o_n _c_o_n_t_e_n_t: {B1} ISO 7498: 1984, _I_n_f_o_r_m_a_t_i_o_n _p_r_o_c_e_s_s_i_n_g _s_y_s_t_e_m_s--_O_p_e_n _S_y_s_t_e_m_s _I_n_t_e_r_- _c_o_n_n_e_c_t_i_o_n--_B_a_s_i_c _R_e_f_e_r_e_n_c_e _M_o_d_e_l.1) {B2} ISO 8072: 1986, _I_n_f_o_r_m_a_t_i_o_n _p_r_o_c_e_s_s_i_n_g _s_y_s_t_e_m_s--_O_p_e_n _S_y_s_t_e_m_s _I_n_t_e_r_- _c_o_n_n_e_c_t_i_o_n--_T_r_a_n_s_p_o_r_t _s_e_r_v_i_c_e _d_e_f_i_n_i_t_i_o_n. {B3} ISO/IEC 8073: 1988, _I_n_f_o_r_m_a_t_i_o_n _p_r_o_c_e_s_s_i_n_g _s_y_s_t_e_m_s--_O_p_e_n _S_y_s_t_e_m_s _I_n_t_e_r_c_o_n_n_e_c_t_i_o_n--_C_o_n_n_e_c_t_i_o_n _o_r_i_e_n_t_e_d _t_r_a_n_s_p_o_r_t _p_r_o_t_o_c_o_l _s_p_e_c_i_f_i_c_a_t_i_o_n.2) {B4} CCITT Recommendation X.25, _I_n_t_e_r_f_a_c_e _b_e_t_w_e_e_n _d_a_t_a _t_e_r_m_i_n_a_l _e_q_u_i_p_m_e_n_t (_D_T_E) _a_n_d _d_a_t_a _c_i_r_c_u_i_t-_t_e_r_m_i_n_a_t_i_n_g _e_q_u_i_p_m_e_n_t (_D_C_T) _f_o_r _t_e_r_m_i_n_a_l_s _o_p_e_r_a_t_i_n_g _i_n _t_h_e _p_a_c_k_e_t _m_o_d_e _a_n_d _c_o_n_n_e_c_t_e_d _t_o _p_u_b_l_i_c _d_a_t_a _n_e_t_w_o_r_k_s _b_y _d_e_d_i_c_a_t_e_d _c_i_r_c_u_i_t.3) {B5} CCITT Recommendation X.212, _I_n_f_o_r_m_a_t_i_o_n _p_r_o_c_e_s_s_i_n_g _s_y_s_t_e_m_s--_D_a_t_a _c_o_m_m_u_n_i_c_a_t_i_o_n--_D_a_t_a _l_i_n_k _s_e_r_v_i_c_e _d_e_f_i_n_i_t_i_o_n _f_o_r _O_p_e_n _S_y_s_t_e_m_s _I_n_t_e_r_c_o_n_n_e_c_t_i_o_n. __________ 1) ISO documents can be obtained from the ISO office, 1, rue de Varembe', Case Postale 56, CH-1211, Gene`ve 20, Switzerland/Suisse. 2) IEC documents can be obtained from the IEC office, 3, rue de Varembe', Case Postale 131, CH-1211, Gene`ve 20, Switzerland/Suisse. 3) CCITT documents can be obtained from the CCITT General Secretariat, International Telecommunications Union, Sales Section, Place des Nations, CH-1211, Gene`ve 20, Switzerland/Suisse. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Annex B Bibliography 287 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS {B5} ANSI X3.113-19874), _I_n_f_o_r_m_a_t_i_o_n _s_y_s_t_e_m_s--_P_r_o_g_r_a_m_m_i_n_g _l_a_n_g_u_a_g_e--_F_U_L_L _B_A_S_I_C. {B6} IEEE Computer Society Technical Committee on Operating Systems and Application Environments Standards Subcommittee. _T_C_O_S-_S_S_C _P_O_S_I_X _S_t_a_n_d_a_r_d_s _S_t_y_l_e _G_u_i_d_e. {B7} American Telephone and Telegraph Company. _S_y_s_t_e_m _V _I_n_t_e_r_f_a_c_e _D_e_f_i_n_i_t_i_o_n (_S_V_I_D), _I_s_s_u_e_s _2 _a_n_d _3. Morristown, NJ: UNIX Press, 1986, 1989. {B8} /usr/group Standards Committee. _1_9_8_4 /_u_s_r/_g_r_o_u_p _S_t_a_n_d_a_r_d. Santa Clara, CA: UniForum, 1984. {B9} X/Open Company, Ltd. _X/_O_p_e_n _P_o_r_t_a_b_i_l_i_t_y _G_u_i_d_e, _I_s_s_u_e _3. Englewood Cliffs, NJ: Prentice-Hall, 1989. __________ 4) ANSI documents can be obtained from the Sales Department, American National Standards Institute, 1430 Broadway, New York, NY 10018. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 288 B Bibliography P1003.0/D13 Annex C (informative) Standards Infrastructure Description _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _W_e_n_d_y _R_a_u_c_h _H_L_J: _O_n_c_e _a_g_a_i_n, _a _f_u_l_l _r_e_p_l_a_c_e_m_e_n_t _f_o_r _t_h_i_s _A_n_n_e_x, _s_o _n_o _f_u_r_t_h_e_r _d_i_f_f _d _m_a_r_k_s. _I _w_o_u_l_d _p_o_i_n_t _o_u_t _a _g_e_n_e_r_a_l _e_d_i_t_o_r_i_a_l _i_s_s_u_e _h_e_r_e: _I_S_O _s_t_a_n_d_a_r_d_s _d _a_n_d _t_e_c_h_n_i_c_a_l _r_e_p_o_r_t_s _d_o _n_o_t _a_l_l_o_w _r_e_f_e_r_e_n_c_e_s _t_o _c_o_m_m_e_r_c_i_a_l _o_r _a_c_a_d_e_m_i_c _d _o_r_g_a_n_i_z_a_t_i_o_n_s, _s_o _a _b_i_t _o_f _p_r_u_n_i_n_g _w_i_l_l _b_e _n_e_c_e_s_s_a_r_y _i_n _t_h_i_s _A_n_n_e_x. _I _d _w_o_u_l_d _a_l_s_o _r_e_c_o_m_m_e_n_d _r_e_m_o_v_i_n_g _a_n_y _t_i_m_e-_p_e_r_i_s_h_a_b_l_e _i_n_f_o_r_m_a_t_i_o_n: _n_u_m_b_e_r _o_f _d _m_e_m_b_e_r_s, _d_u_e_s, _m_e_e_t_i_n_g _s_c_h_e_d_u_l_e_s, _t_e_l_e_p_h_o_n_e _n_u_m_b_e_r_s, _e_t_c. _A_n_d _I _r_e_n_e_w _m_y _d _r_e_q_u_e_s_t _f_o_r _m_o_r_e _k_n_o_w_l_e_d_g_e_a_b_l_e _r_e_a_d_e_r_s _t_o _p_o_i_n_t _o_u_t _r_e_q_u_i_r_e_m_e_n_t_s _f_o_r _d _d_i_a_c_r_i_t_i_c_a_l _m_a_r_k_s _i_n _s_o_m_e _o_f _t_h_e _n_o_n-_E_n_g_l_i_s_h _n_a_m_e_s _a_n_d _a_d_d_r_e_s_s_e_s. _d _T_h_a_n_k_s. _d C.1 Introduction This annex provides a brief summary of the major national and international organizations working on the standardization of information technology. There are two major categories of open standards organizations. One consists of formally-recognized standards bodies, responsible for definition and dissemination of public standards. Their specifications are known as formal or de jure standards. International, national, and regional standards groups, and some professional and technical organizations' standards groups are examples of formal standards bodies. Organizations specifying standards for open system usually give precedence to international standards first, then regional, national, and finally professional group standards. The other standards organization category consists of informal bodies. Informal standards bodies are typically created by suppliers or users of information technology, usually using a consensus method, to enable the implementation of standards. They produce specifications known as industry standards or de facto standards. Certain trade associations, industry groups, vendor consortia, and user groups are examples of informal standards bodies. For informal specifications to be approved as Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.1 Introduction 289 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS formal standards (e.g., international or national standards) informal standards groups typically submit their specifications to formal standards organizations. The term ``de facto standard'' is sometimes applied to popular vendor- defined systems. Such systems, however, are closed systems, often controlled in a proprietary fashion. Although they have value, closed de facto standards are not the subject of this guide. Most standards bodies support three types of status for their standards or specifications--approved, draft, and work item. An approved standard is one that has been fully ratified by whatever means the approving standards body uses. A draft standard is one that has yet to be fully ratified, such as an ISO DIS (Draft International Standard) or a CEN ENV. Work item is a catch-all phrase for everything else, such as immature specifications, technical reports, etc., that have not yet achieved draft status. C.1.1 International Standards Bodies Overview Standards with the highest status are internationally agreed ones. In information technology, these are produced and published by the International Organization for Standardization (ISO). Other standards and/or recommendations are issued by the International Electrotechnical Commission (IEC), the International Telecommunication Union (ITU), and the CCITT. International standards bodies participants are normally countries and trade bodies, rather than individual suppliers or users. C.1.2 National Standards Bodies Overview Like the international standards bodies, most national bodies do not admit either suppliers or users directly, but receive representatives from interested trade bodies. In general, the national bodies support and adopt the international standards, developing national standards only if no international standards are available, or to meet special national requirements. Each country has a national body that is the formal representative to the international standards groups. The relationship between the major international and national standards groups is shown in Figure C-1. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 290 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _________________________________________________________________________ _________________________________________________________________________ Figure C-1 - International and National Standards Bodies C.1.3 International and National Standards Bodies Relationship Nongovernment standards organizations include trade associations, professional and technical societies, vendor consortia, user groups, and other special interest groups. Actual standards development occurs within these groups. The standards specified by formal standards groups within this category typically are subsequently submitted to national or international standards organizations for approval. Many informal bodies submit their specifications to formal bodies for approval as an accredited standard. (See Figure C-2). C.2 The Formal Standards Groups C.2.1 International and National Standards Organizations _A_F_N_O_R_:__A_s_s_o_c_i_a_t_i_o_n__F_r_a_n_c_a_i_s_e__d_e__N_o_r_m_a_l_i_z_a_t_i_o_n AFNOR is the French national standards body. Its responsibilities include sourcing, coordinating, approving, and promoting standards, representing the French at international meetings, and controlling the use of the NF label--a trademark that shows compliance with a French national standard. AFNOR publishes three types of standards documents-- AFNOR-approved standards that are mandatory for use in the public sector, experimental standards that use new processes or techniques and whose use is voluntary, and information or guide standards. For further information, contact Association Francaise de Normalization (AFNOR), Tour Europe - Cedex 7, 92080 Paris La Defense, Telephone: (1) 42 91 55 55, Telex: AFNOR 611 974F, Fax: (1) 42 91 56 56. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.2 The Formal Standards Groups 291 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure C-2 - Selected Major Standards and Standards-Influencing Bodies _A_N_S_I_:__A_m_e_r_i_c_a_n__N_a_t_i_o_n_a_l__S_t_a_n_d_a_r_d_s__I_n_s_t_i_t_u_t_e ANSI is the national standards coordinating and approval body for the United States. A voluntary organization founded in 1918, the ANSI performs three major types of functions. First, the ANSI approves standards and accredits standards development groups and certification programs. ANSI does not itself develop standards. Instead, it approves voluntarily-submitted specifications that were developed by technical and professional societies, trade associations, and special interest groups, if these specifications and/or groups meet ANSI criteria for due process and consensus. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 292 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 ANSI accredits three types of organizations. One is professional societies, such as the IEEE. The second is committees formed for the exclusive purpose of developing standards, such as X3. The third is accredited by ANSI to use the canvass method to develop standards. Such organizations prepare a standard using their internal procedures. Then they submit that standard to balloting by other organizations representing a variety of interests. Last, they reconcile comments and objections returned. The NIST is an organization accredited to use the canvass process for standards development. ANSI's second major function is to represent and coordinate US interests in international, nontreaty, and nongovernmental standards bodies. ANSI's third function is to be a clearinghouse for national, international, and foreign national standards. ANSI membership is open to manufacturers, organizations, users, and communications carriers. At present, more than 220 professional and technical societies and trade associations that develop standards in the US are ANSI members, as are 1000 companies. For further information, contact American National Standards Institute (ANSI), 1430 Broadway, New York, NY 10018, (212) 354-3300, Telex: 42 42 96 ANSI UI. _B_S_I_:__B_r_i_t_i_s_h__S_t_a_n_d_a_r_d_s__I_n_s_t_i_t_u_t_e BSI is the British national standards body and is responsible for promulgation of national standards. The BSI determines the overall UK view toward international standards and conveys that back to the secretariat of the international committee. For further information, contact British Standards Institute, 2 Park Street, London W1A2BS, United Kingdom, Telephone: 44 1 629 90 00, Fax: 44 1 629 05 06. _C_a_n_a_d_i_a_n__S_t_a_n_d_a_r_d_s__A_s_s_o_c_i_a_t_i_o_n__(_C_S_A_) The Canadian Standards Association (CSA), in conjunction with regulatory agencies and with the provincial and national governments of Canada, provides a single source for consensus-based standards development, conformance testing, and standards-based regulations creation. The CSA has no single counterpart in the US. Instead, the CSA handles selected functions from US testing organizations, the FCC, and ANSI. Membership in the CSA is open to any Canadian citizen, business, or organization. Members of the CSA's technical committees developing standards are volunteers, drawn from consumers, manufacturers, government, labor, and consultants. Membership is based on expertise in the field, and not, as in the US, mainly on having a vested commercial interest. The CSA has over 900 committees handling various aspects of Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.2 The Formal Standards Groups 293 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS standards in areas such as the environment, electrical and electronics, communications and information processing, construction, energy, transportation and distribution, materials technology, and production management. CSA programs support Canadian industry and Canadian consumers where safety and quality of merchandise sold or made in Canada are concerned. To assure product quality and safety, the CSA offers fee-based testing services. In performing such services, the CSA assumes that most manufacturers have the facilities to test their products before submitting them to the CSA for certification and approval. If they do not, the CSA provides this service. CSA certification involves the submission of the product or service by the supplier, the verification of that product or capability by the CSA, and then continued follow-up audits by the CSA to ensure that the quality of the product or service is maintained. For further information, contact (Address and phone number TBD). _C_C_I_T_T_:__C_o_m_i_t_e__C_o_n_s_u_l_t_a_t_i_f__I_n_t_e_r_n_a_t_i_o_n_a_l__d_e__T_e_l_e_g_r_a_p_h_i_e__e_t__T_e_l_e_p_h_o_n_i_e An international organization, the CCITT is part of the International Telecommunications Union, which is a United Nations treaty organization formed in 1865. It is now a specialized agency of the United Nations. The CCITT's primary mission is to develop standards supporting the international interconnection and interoperability of telecommunications networks at interfaces with end-user systems, carriers, information and enhanced-service providers, and customer premises equipment. Every four years, the CCITT publishes the results of its work as ``Recommendations.'' Its recommendations are law where communications in Europe are nationalized. Membership and participation in the CCITT are open to private companies; scientific and trade associations; and postal, telephone, and telegraph administrations. CCITT's principal participants are telecommunications administrations and carriers. Scientific and industrial organizations can participate as observers. The US representative is the Department of State. For further information, contact International Consultative Committee on Telegraphy and Telephone, Central Administration Office, CH-1211, 2 rue de Varembe', Geneva, Switzerland, _C_E_N_/_C_E_N_E_L_E_C_/_C_E_P_T The Comite Europeen de Normalisation (CEN), Comite Europeen de Normalisation Electrotechnique (CENELEC), and the European Committee for Post and Telecommunications Administration are European regional Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 294 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 standards committees responsible for developing and publishing European standards. CEN is an association of EC (European Community) and EFTA (European Free Trade Association) members. It is active in making members' standards into ISO standards and European standards. CENELEC is the counterpart of CEN that deals exclusively with electrotechnical matters. CEPT is the CEN counterpart that deals with telecommunications matters. CEN, CENELEC, and CEPT can be considered the European regional equivalent of ISO for two reasons. First, they have as members the national standards bodies of their eighteen EC and EFTA member states. Second, standards adopted by these organizations must be implemented in full as national standards, regardless of the way in which the member voted, and regardless of any standards that conflict with them must be withdrawn. CEN members, for example, agree to use its published standards in preference to national standards, wherever possible. CEN, CENELEC, and CEPT were created to improve the competitiveness of European enterprise by removing technical barriers to trade and facilitating the free movement of goods within Europe. To accomplish its aims, CEN, CENELEC, and CEPT perform the following tasks: - Create and promote European Standards (EN). - Rapidly create prestandards (ENV) in technology areas in which there is a high level of innovation or where it is felt that future standardization requires basic guidance. ENVs are subjected to an experimental period of up to three years. - Create harmonization documents (HD) that are more flexible than European Standards so that the technical, historical, or legal circumstances pertaining to each country can be taken into account. - Set up a framework for European certification that supports the issuing of a European mark of conformity to certain standards and the mutual recognition of test results and inspections. - Promote the application within Europe of ISO standards and accelerate their production. - Work in liaison with European professional federations and numerous technical organizations to establish priority standards programs and contribute to the technical work. For further information, contact the European Committee for Standardization (CEN), European Committee for Post and Telecommunications Administration, 2 rue Brederode, Buite 5, B-1000 Brussels, Belgium, Telephone: +322 519 6860, Telex: 26257 CENLEC. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.2 The Formal Standards Groups 295 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _D_I_N_:__D_e_u_t_s_c_h_e_s__I_n_s_t_i_t_u_t__f_u_r__N_o_r_m_u_n_g DIN is the German national standards body. Its functions include those performed by the US's ANSI (e.g., developing national standards and representing Germany in international and European standards bodies such as ISO, the IEC, CEN, and CENELEC), in addition to test and certification functions that are not handled by US consensus standards organizations. Since a key DIN objective is eliminating technical barriers to free trade, DIN plays an active role in the international standards arena to ensure that German products can be used and accepted internationally. DIN standards are not mandatory within Germany. DIN claims that it relies on the technical excellence of its standards to win converts. Further incentive for accepting DIN standards is provided because DIN standards serve as the basis for regulatory technical law in Germany. Also, without the DIN testing and inspection mark, no insurance carrier in Germany will write insurance for a product. DIN members include groups within Germany representing manufacturers, the academic community, user groups, user organizations (e.g., consumer advocate groups), the government, and trade unions. Many DIN staff are supported by organizations or companies, rather than by DIN. DIN presently has over 20000 standards. For further information, contact Deutsches Institut fur Normung, Burggrafenstrasse 6, Postfach 1107, D-1000 Berlin 30, Telephone: 49 30 26 01-1, Fax: 49 30 260 12 31. _I_E_C_:__I_n_t_e_r_n_a_t_i_o_n_a_l__E_l_e_c_t_r_o_t_e_c_h_n_i_c_a_l__C_o_m_m_i_s_s_i_o_n The International Electrotechnical Committee is the equivalent of ISO, but for electrotechnical standards. ISO and the IEC have converged many of their information technology efforts to form JTC1. For further information, contact International Electrotechnical Commission (IEC), 3, rue de Varembe', CH-1211 Geneva 20, Switzerland, Telephone: 41 22 34 01 50, Fax: 41 22 33 38 43. _I_S_O_:__I_n_t_e_r_n_a_t_i_o_n_a_l__O_r_g_a_n_i_z_a_t_i_o_n__f_o_r__S_t_a_n_d_a_r_d_i_z_a_t_i_o_n ISO was established in its present form in 1947 with the aim of reaching international agreement on standards. A voluntary, non-United Nations treaty, ISO's membership consists of delegations from standards bodies in participating nations. ISO solicits comments from other groups as well, including ECMA, the IEEE, the NIST, and the CCITT. ISO has a close relationship with the CCITT, which is, perhaps, the most influential of all the observer groups within ISO. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 296 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 ISO is responsible for the development and standardization of the Open Systems Interconnection (OSI) model. It also considers items for standardization that were developed in other standards bodies, such as ANSI. At present, for example, it is considering the core POSIX standard (P1003.1). For further information, contact the International Organization for Standardization, Central Secretariat, 1, rue de Varembe', CH-1211, Geneva, Switzerland-40. _J_I_S_C_:__J_a_p_a_n_e_s_e__I_n_d_u_s_t_r_i_a_l__S_t_a_n_d_a_r_d_s__C_o_m_m_i_t_t_e_e The Japanese Industrial Standards Committee (JISC) is the national standards body of Japan. The JISC represents Japan at ISO and IEC, develops Japanese standards, and monitors and liases with the standards- developing activities of other national organizations, especially those of the US. The goal of the JISC is to ensure that Japanese industry can compete internationally in the information technology and telecommunications industries. The JISC has no true counterpart in other nations since the JISC has a special relationship with the Japanese government and major manufacturers. For example, the JISC's secretariat is the Agency of Industrial Science and Technology, a division of the Ministry of International Trade and Industry (MITI), which plays a central role in Japanese industry. The influence of this centralized national planning structure eliminates many areas of contention, including among companies with multinational branches, and facilitates the ability for Japanese standards groups to gain a consensus. Major Japanese manufacturers help plan and develop standards. Foreign companies' involvement in the JISC is limited because of geographic and linguistic differences and because of restrictions on their meaningful participation. Although large-scale manufacturers may participate, user groups and small manufacturers find participation very difficult. For information, contact Japanese Industrial Standards Committee, c/o Standards Department, Agency of Industrial Science and Technology, Ministry of International Trade and Industry, 1-3-1 Kasumigaseki, Chiyoda-ku, Telephone: 813 501 92 95/6, Fax: 81 3 580 14 18. _J_T_C_1_:__J_o_i_n_t__T_e_c_h_n_i_c_a_l__C_o_m_m_i_t_t_e_e__1 The JTC1, established in 1987, is the first joint committee of the ISO TC97 (Information Processing Systems) and its subcommittees, with the IEC Technical Committee 83 (Information Technology Equipment) and the subcommittee IEC SC47B (Microprocessor systems). The joint committee was formed to eliminate much of the two groups' standardization-activities' overlap and prevent the creation of incompatible standards for the same Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.2 The Formal Standards Groups 297 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS device or technology area. Although ISO and IEC are equal partners in the management of JTC1, most of JTC1's standards work grew out of ISO's information processing work. In fact, JTC1 has become one of the most important information technology standards organizations today because so many of the major ISO information technology standards being developed today are actually being produced by JTC1 groups. The JTC1's purpose is to develop international standards in the areas of information technology systems (including microprocessor systems) and equipment. Microprocessor systems include, but are not limited to, microprocessor assemblies, and related hardware and software for controlling the flow of signals at the terminals of microprocessor assemblies. The JTC1 initially organized its standards work into four major groupings, each of which contains subcommittees that, in turn contain working groups. The four main groupings and their subcommittees are: JTC1 Application Elements Group SC1: Vocabulary SC7: Software Engineering SC14: Representation of Data Elements SC22: Languages JTC1 Equipment and Media Group SC11: Flexible Magnetic Media for Digital Data Interchange SC15: Labeling and File Structure SC17: Identification and Credit Cards SC23: Optical Disk Cartridges for Information Interchange SC28: Office Equipment JTC1 Systems Group SC6: Telecommunications and Information Exchange Between Systems SC13: Interconnection of Equipment Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 298 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 SC18: Text and Office Systems SC21: Information Retrieval, Transfer, and Management for OSI JTC1 Systems Support Group SC2: Character Sets and Information Coding SC24: Computer Graphics SC25: Interconnection of Information Technology Equipment (formerly IEC TC83) SC26: Microprocessor Systems (formerly IEC TC47B) SC27: Security Techniques (grew out of JTC1 SC20: Data Cryptographic Techniques) POSIX standardization work is being done within SC22's Working Group 15 (SC22/WG15). A JTC1 Special Working Group on Strategic Planning is performing a technical study on Application Portability (AP). This study's goal is to identify the standards that need to be written or revised to support application portability between hardware and software environments. The JTC1 is not involved in application-specific information technology areas, such as banking and industrial automation systems, nor is it concerned with microprocessor subsystems covered by the scopes of IEC TC22 on power electronics or TC86 on fiber optics. The JTC1 has liaison relationships with numerous ISO and IEC Technical Committees, as well as with the CCITT. Like ISO, membership in JTC1 consists of delegations from standards organizations in member countries. At present, 23 countries participate in JTC1, and there are another 11 observer countries. The ANSI holds the secretariat for JTC1. For further information, contact: American National Standards Institute (ANSI), 1430 Broadway, New York, NY 10018, (212) 354-3300, Telex: 42 42 96 ANSI UI, or International Organization for Standardization (ISO), Central Secretariat, 1, rue de Varembe', CH-1211, Geneva, Switzerland-40. _S_G_F_S__(_S_p_e_c_i_a_l__G_r_o_u_p__o_n__F_u_n_c_t_i_o_n_a_l__S_t_a_n_d_a_r_d_i_z_a_t_i_o_n_) The Special Group on Functional Standardization (SGFS) is an ISO group, under JTC1, which is responsible for the international standardization process of profiles or functional standards. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.2 The Formal Standards Groups 299 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS C.2.2 Nongovernment Formal Standards Organizations _E_C_M_A_:__E_u_r_o_p_e_a_n__C_o_m_p_u_t_e_r__M_a_n_u_f_a_c_t_u_r_e_r_s__A_s_s_o_c_i_a_t_i_o_n Established in 1961 to develop data processing standards, ECMA is a trade organization, open to any computer firm developing, manufacturing, or selling in Europe. The ECMA has about 20 members, and approximately 13 active Technical Committees. ECMA contributes to the ISO standards development efforts, in addition to issuing its own standards. ECMA is particularly active in the development of higher layer protocols for OSI networking. It also is developing a standard for a Portable Common Tool Environment (PCTE). For further information, contact European Computer Manufacturers Association, 114 rue du Rhone, CH-1204 Geneva, Switzerland, Telephone: 41-22-735-36-34, Telex: 41 3237, Fax: 41 22 786 53 31. _E_I_A_:__E_l_e_c_t_r_o_n_i_c__I_n_d_u_s_t_r_i_e_s__A_s_s_o_c_i_a_t_i_o_n The EIA is a US trade organization, whose membership consists primarily of manufacturers. The EIA has been a standards developer in the areas of electrical and electronic products and components since 1926. Many of its standards have been submitted to ANSI and approved as ANSI standards. The EIA is best known for the RS-232-C standard. For further information, contact John Kinn, Vice President - Engineering, Electronic Industries Association (EIA), 2001 I Street NW, Washington, DC 20036, (202) 467-4961. _I_E_E_E_:__I_n_s_t_i_t_u_t_e__o_f__E_l_e_c_t_r_i_c_a_l__a_n_d__E_l_e_c_t_r_o_n_i_c__E_n_g_i_n_e_e_r_s The IEEE is a professional scientific, engineering, and educational society that develops and publishes standards and specifications in a variety of computer and engineering areas. The standards and specifications published are of three types: true standards, recommended practices, and guides. ``Standards'' are specifications with mandatory requirements. Recommended practices are specifications of procedures and positions preferred by the IEEE. Guides are specifications that suggest alternative approaches to good practice, but make no clear-cut recommendations. The IEEE is accredited by ANSI, and can, therefore, submit its standards directly to the ANSI board of Standards Review. All new and revised IEEE standards are submitted to ANSI for review and adoption as ANSI standards. The IEEE Standards Board authorizes, coordinates, and approves all standards projects, and coordinates cooperation with other standards Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 300 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 organizations. Standards are proposed and sponsored by technical committees of the IEEE Societies, standards committees, or Standards Coordinating Committees (SCC), depending on the scope of the work. Either these committees or standards subcommittees manage the actual standards development and balloting. The individual draft standards are specified in working groups inside the subcommittees--one working group per standard (see Figure C-3). _H_L_J: _T_h_i_s _i_s _t_h_e _f_i_g_u_r_e _f_r_o_m _p_r_e_v_i_o_u_s _d_r_a_f_t_s. _W_e_n_d_y'_s _i_n_p_u_t _t_o _m_e _d_u_p_l_i_c_a_t_e_d _t_h_e _C-_2 _f_i_g_u_r_e, _w_h_i_c_h _s_e_e_m_e_d _l_e_s_s _c_o_r_r_e_c_t. IEEE membership is open to any dues-paying individuals. Standards participants are individuals, not companies or organizations. IEEE membership is required for voting, but not for participating in the development of draft standards. Approximately 30000 members are active in standards development. More than 500 IEEE standards exist, and more than 800 standards projects are underway. The IEEE also administers the secretariat or cosecretariat of 17 American National Standards committees. The most well known IEEE standards are the IEEE 802.3 CSMA/CD and 802.4 token bus LANS, IEEE-488 bus, the National Electrical Safety Code, and the P1003.n POSIX standards. The 802.3 and 802.4 standards are also approved ISO standards. The core POSIX standard (POSIX.1 {2}) has been approved by ISO, and is now an ISO, as well as an IEEE, standard. The POSIX.0 specifications, with which this document is concerned, will be, in IEEE parlance, a ``Guide'' to a POSIX Open Systems Environment. For further information, contact the Institute of Electrical and Electronics Engineers, Inc., 345 East 47th Street, New York, NY 10017, USA. _N_I_S_T_:__N_a_t_i_o_n_a_l__I_n_s_t_i_t_u_t_e__o_f__S_t_a_n_d_a_r_d_s__a_n_d__T_e_c_h_n_o_l_o_g_y The National Institute of Standards and Technology (formerly the National Bureau of Standards) was established by an act of the US Congress on March 3, 1901 to advance, and facilitate the application of, US science and technology for public benefit. Toward this end, the Institute for Computer Sciences and Technology (ICST) within the NIST, conducts research and provides technical advisory services to help Federal agencies acquire and apply computer technology. The NIST is a major driving force behind standards development. Through the Institute for Computer Sciences and Technology, the NIST develops and publishes Federal Information Processing Standards (FIPS) for the United States. Federal agencies to use in their computer equipment procurements. Federal agencies are obligated to use these standards, where applicable. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.2 The Formal Standards Groups 301 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure C-3 - IEEE Standards Diagram Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 302 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Federal computer standards also are widely used by the private sector, and often are adopted as ANSI standards. Besides defining standards, the NIST has defined an Application Portability Profile (APP), which comprises a series of nonmandatory specifications and a guide for US government users to use in developing a portable, interoperable architecture and environment. The development and evolution of both FIPS and the APP is carried out in conjunction with users and vendors through an ongoing series of NIST- conducted Implementor Workshops and User Workshops (e.g., OSI implementors workshops, APP workshops, and Integrated Software Engineering Environment workshops). The workshops provide forums for user and vendor feedback and comments on evolving NIST standards, and help ensure that there is a general commitment among vendors to building products that conform to the evolving NIST specifications. Additionally, the NIST develops test methods and performance measures to help users and vendors implement standards and to test the conformance of vendor implementations to FIPS specifications. Among others, the NIST has test suites for most FIPS programming languages, FIPS Database SQL, and POSIX.1 {2}. The POSIX.1 {2} conformance test suite, however, is based on the conformance-test assertions developed in the POSIX Test and Methods working group (P1003.3.1). Besides developing its own standards, NIST staff members participate in a number of other standards activities and organizations, including the ANSI X3 Committee on Information Processing Systems, ISO/IEC JTC1, CCITT, ECMA, and the IEEE. For further information, contact the National Institute of Standards and Technology, Gaithersburg, MD 20899, Telephone: (301) 975-2000. The cognizant person for P1003.0 information is Allen Hankinson at (301) 975-3290. _T_1 T1, established in 1984, is an ANSI-accredited standards body that is developing standards and technical reports. The standards and reports are intended to support interconnection and interoperability of telecommunications networks at interfaces with end-user systems, carriers, information and enhanced-service providers, and customer premises equipment. Six T1 technical subcommittees are currently developing these standards and reports under the T1 Advisory Group. The subcommittees also recommend positions on matters under consideration by other North American and international standards bodies. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.2 The Formal Standards Groups 303 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS T1 Membership and full participation is available to all interested parties. For further information, contact Alvin Lai, Exchange Carriers Standards Association, c/o T1 Secretariat, 5430 Grosvenor Lane, Suite 200, Bethesda, Maryland 20814-2122, or call (301) 654-4505. _X_3 X3, established in 1961, is an ANSI-accredited standards body that develops computer, information processing, and office systems standards. X3 also participates in the development of international standards in these areas. In addition, it serves as a Technical Advisory Group (TAG) to ANSI for most of the subcommittees working on international standardization projects within JTC1. The Computer and Business Equipment Manufacturers Association (CBEMA) functions as X3's secretariat. X3 membership is open to all organizations, upon payment of a service fee. The current membership includes computer manufacturers, communications carriers, user groups, and government agencies. More than 3200 volunteers from these organizations participate in the X3 standards work. They are organized into about 85 technical groups, working on 700 projects. Three standing committees report to X3: the Standards Planning and Requirements Committee (SPARC), the Strategic Planning Committee (SPC), and the Secretariat Management Committee (SMC). The following are the major X3 technical committees: Recognition X3A1 Optical Character Recognition Media X3B5 Digital Magnetic Tape X3B6 Instrumentation Tape X3B7 Magnetic Disks X3B8 Flexible Disk Cartridges X3B9 Paper/Forms Layout X3B10 Credit/Identification Cards X3B11 Optical Digital Data Disks Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 304 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 Data Management and Graphics X3H2 Database X3H3 Computer Graphics X3H3.6 Windowing Interfaces X3H4 Information Resource & Dictionary Languages X3J1 PL/1 X3J2 Basic X3J3 Fortran X3J4 COBOL X3J7 APT X3J9 Pascal X3J10 APL X3J11 C X3J12 Dibol X3J13 Common Lisp X3J14 Forth X3J15 Databus Documentation X3K1 Computer Documentation X3K5 Vocabulary Data Representation X3L2 Codes and Character Sets X3L5 Labels and file Structure Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.2 The Formal Standards Groups 305 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS X3L8 Data Representation Communication X3S3 Data Communications Systems Technology X3T1 Data Encryption X3T2 Data Interchange X3T5 Open Systems Interconnection X3T9 I/O Interface Text X3V1 Office and Publishing Systems For more information, contact CBEMA, c/o X3 Secretariat, 311 First Street NW, Suite 500, Washington, DC 20001-2178, Telephone: (212) 626-5740. C.3 The Informal Standards Organizations The following organizations are some of the major trade associations, user groups, and professional bodies active in either promoting, implementing, or reviewing information technology standards. _B_C_S_:__B_r_i_t_i_s_h__C_o_m_p_u_t_e_r__S_o_c_i_e_t_y The BCS is a professional institution that participates in standards work, organizing specialist groups on specific subjects for input to BSI. For further information, contact (information TBD). _C_B_E_M_A_:__C_o_m_p_u_t_e_r__a_n_d__B_u_s_i_n_e_s_s__E_q_u_i_p_m_e_n_t__M_a_n_u_f_a_c_t_u_r_e_r_s__A_s_s_o_c_i_a_t_i_o_n CBEMA is a trade organization whose primary function is to represent large manufacturers of hardware-based information technologies equipment in lobbying about public policy. In addition, it provides education programs, information exchange forums, and deals with the industry's public image. CBEMA has long had an interest in standards. It serves as the secretariat for X3. It also offers a standards and technology program where its members can exchange information on standards issues and industry standards. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 306 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 CBEMA's members are mostly large manufacturers because its dues are tied to corporate revenues and structured in a way that makes it too expensive for small companies to join. Members are either American companies or US subsidiaries of non-American companies. For more information, contact CBEMA, 311 First Street, NW, Suite 500, Washington, DC 20001-2178, Telephone: (202) 626-5740. _C_O_D_A_S_Y_L_:__T_h_e__C_o_n_f_e_r_e_n_c_e__o_n__D_a_t_a__S_y_s_t_e_m_s__L_a_n_g_u_a_g_e_s The Conference on Data Systems Language (CODASYL) has been active since 1960 in the development of the COBOL language, through its COBOL Committee (CC). Since 1969, it also has been active in the development of a common Data Description Language for defining schemas and subschemas, and in a data manipulation language, through the DBTG Data Base Task Group of the CC. The activities of the CC are documented in the COBOL Journal of Development, which serves as the official COBOL language specification. In 1969, ANSI (then the United States of America Standards Institute) issued the first COBOL standard. At that time, the X3.4 committee stated that X3.4 recognizes the CODASYL COBOL Committee as the development and maintenance authority for COBOL. In practice, this meant that ANSI agreed not to make any changes to the CODASYL-defined language specification. Although this agreement has been challenged over the years, the CODASYL-ANSI agreement is still strong. As a result, the CODASYL has enormous influence upon the COBOL language. Toward the end of 1971, a new CODASYL committee was established--the Data Description Language Committee (DDLC). The DDLC was formed to serve the same functions for the schema DDL as the CC does for COBOL. That is, since the schema DDL is a conceptual schema and network-model database language for use with many programming languages, not just COBOL, the DDLC continues the schema DDL development and publishes its own Journal of Development documenting the language's current status. The COBOL DML and subschema DDL (for defining an external view) of the DBTG are COBOL-specific and have remained part of the CC under the name ``The COBOL Data Base Facility.'' The CODASYL membership is composed of voluntary representatives, mostly from computer manufacturers and users in industry and the US Federal government. _C_O_S_:__C_o_r_p_o_r_a_t_i_o_n__f_o_r__O_p_e_n__S_y_s_t_e_m_s COS is a US-based, international, nonprofit association of vendors and users, formed in 1985 to promote and accelerate the adoption of interoperable, multivendor products and services based on OSI and ISDN Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.3 The Informal Standards Organizations 307 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS standards. To accomplish its goals, COS provides a user-vendor forum for the statement of user requirements and the discussion and management of the issues surrounding the deployment of open systems. COS also identifies test requirements, and sponsors test tools development and conformance and interoperability testing to verify that computer products and services conform to OSI or ISDN standards. COS's membership consists of more than 60 prominent manufacturer, user, and telecommunication service organizations worldwide. COS cooperates with similar organizations such as SPAG Services in Europe and POSI in Japan. Other key groups in the worldwide promotion, implementation and testing of OSI and ISDN standards are affiliated with COS under its Alliance Associate program. For further information, contact the Corporation for Open Systems, 1750 Old Meadow Road, Suite 400, McLean, VA 22102-4306, USA, Telephone: (703) 883-2700, Fax: (703) 848-8933. In Europe contact Corporation for Open Systems, Avenue des Arts 1-2, bte 11, 1040 Bruxelles, Belgique, Telephone: 32 2 210 08 11, Fax: 32 2 210 08 00. _E_M_U_G_/_O_S_I_T_O_P_:__E_u_r_o_p_e_a_n__U_s_e_r_s__G_r_o_u_p_s These groups are involved in promoting and developing the MAP and TOP specifications (see below for MAP/TOP). _E_P_R_I_:__E_l_e_c_t_r_i_c__P_o_w_e_r__R_e_s_e_a_r_c_h__I_n_s_t_i_t_u_t_e The Electric Power Research Institute's (EPRI) is an industry association concerned with electric power utilities. Its membership comprises more than 673 publicly and privately owned utilities in the United States. Besides providing a variety of utility-specific services to its membership, EPRI's latest mission is to facilitate the use of open systems technology in the utility industry. Toward this end, EPRI has developed a Utilities Communication Architecture (UCA), which is similar to the National Institute for Standards and Technology's (NIST) Government Open Systems Interconnect Profile (GOSIP) Version 2.0. Much of the UCA was developed by EPRI with the cooperation of Honeywell and Anderson Consulting. EPRI's specific open system interests span realtime UNIX, expert systems, and database access using RDA and SQL. Because of the financial structure of the utilities industry, EPRI wants to encourage these and other open systems technologies for equipment with a 12 to 15 year life cycle. For further information, contact EPRI's headquarters at 3412 Hillview Avenue, P.O. Box 10412, Palo Alto, CA 94303, Telephone: (415) 934-4212. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 308 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 _E_S_P_R_I_T (_E_u_r_o_p_e_a_n _S_t_r_a_t_e_g_i_c _P_r_o_g_r_a_m_m_e _f_o_r _R_e_s_e_a_r_c_h _a_n_d _D_e_v_e_l_o_p_m_e_n_t _i_n _I_n_f_o_r_m_a_t_i_o_n _T_e_c_h_n_o_l_o_g_y) The European Strategic Programme for Research and development in Information Technology is a European research programme initiative, started in 1982 and sponsored by the Commission of the European Communities. About 227 projects were implemented during the first phase of the project in five major work areas: advanced microelectronics, software engineering and technology, advanced information processing, office automation, and computer integrated manufacturing. Nearly thirty projects have enabled substantial advances to be made in establishing internationally recognized standards. Examples of the Portable Communications Tool Environment (PCTE) project, the Communication Network for Manufacturing Applications (CNMA) project, and the Herode project, which has prepared an Office Document Architecture standard for adoption as an ISO standard. The second phase of the Esprit programme will be concerned mainly with three areas--microelectronics and peripheral technologies; the creation of technologies and tools for the design of information processing systems; and enhancing the capacity for using and integrating information technology to extend the scope of its applications. For further information contact ESPRIT, Director General, DG XIII, CEC, rue de la Loi 200, B-1049 Brussels, Belgium, Telephone: (32 2) 235 11 11, and Telex: 21877 comeu b. _E_T_S_I_:__E_u_r_o_p_e_a_n__T_e_l_e_c_o_m_m_u_n_i_c_a_t_i_o_n_s__S_t_a_n_d_a_r_d_s__I_n_s_t_i_t_u_t_e The European Telecommunications Standards Institute (ETSI), founded in 1988, is a voluntary standards organization involved in producing the telecommunications standards necessary to achieve a European unified market. ETSI was established outside the CEN/CENELEC framework. ETSI, however, works with CEN, CENELEC, and the European Broadcasting Union (EBU) in areas of mutual interest. ETSI's voting membership consists of postal administrations, along with manufacturers and trade associations, in each of the CEPT countries. Membership is not restricted to official representatives of member countries. The United States and US companies have been granted observer status. Standards approved by ETSI are voluntary standards known as ETS (European Telecommunications Standards). ETSI also conducts prestandardization studies, develops technical reports and guidelines, holds conferences, workshops, seminars, and conducts interviews. ETSI's interim standards are designated I-ETS. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.3 The Informal Standards Organizations 309 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS For further information, contact the European Telecommunications Standards Institute, B.P. No. 52, F-06561 Valbonne CEDEX, France, Telephone: (33 92) 94 42 00, Telex: 470 040 F, and Fax Number: (33 93) 65 47 16. _E_W_O_S_:__E_u_r_o_p_e_a_n__W_o_r_k_s_h_o_p__f_o_r__O_p_e_n__S_y_s_t_e_m_s The EWOS is an ongoing regional workshop, formed in 1987, to provide and coordinate European input to the international standard profiles process. It was formed as the result of an initiative of SPAG, in conjunction with EMUG, OSITOP, CEN/CENELEC, CEPT, RARE/COSINE, and ECMA, and it assumes some of the responsibilities previously held by CEN/CENELEC. Membership in EWOS is not open to the United States. EWOS is the focal point in Europe for the study and development of OSI profiles and corresponding conformance test specifications. EWOS documents have only to be submitted to public enquiry by CEN and CENELEC before becoming European Standards. EWOS's is active in numerous networking and communications areas including File Transfer, Access, and Management (FTAM); Office Document Architecture (ODA); Message Handling Systems (MHS); Virtual Terminal (VT); Directory services; and Manufacturing Messaging Services (MMS). For further information contact European Workshop on Open Systems (EWOS), rue de Brederode 13, B-1000 Brussels, Belgium, Telephone: 32 2 511 74 55. _F_O_C_U_S_:__F_O_C_U_S__C_o_m_m_i_t_t_e_e This UK committee was established in 1981 to identify issues on information technology standards and to determine action needed to promote effective progress. It makes recommendations to the Department of Trade and Industry on actions to fill gaps, prevent duplication, and remove incompatibilities. _I_N_T_A_P (_I_n_t_e_r_o_p_e_r_a_b_i_l_i_t_y _T_e_c_h_n_o_l_o_g_y _A_s_s_o_c_i_a_t_i_o_n _f_o_r _I_n_f_o_r_m_a_t_i_o_n _P_r_o_c_e_s_s_i_n_g) The Interoperability Technology Association for Information Processing, in Japan, is a national agency, funded by MITI. It deals with information technology, and specifically OSI products and advanced projects. INTAP is developing and providing conformance testing tools and services in Japan in cooperation with POSI. _M_A_P/_T_O_P _U_s_e_r _G_r_o_u_p: (_M_a_n_u_f_a_c_t_u_r_i_n_g _A_u_t_o_m_a_t_i_o_n _P_r_o_t_o_c_o_l _a_n_d _T_e_c_h_n_i_c_a_l _a_n_d _O_f_f_i_c_e _P_r_o_t_o_c_o_l) The MAP Task Force was formed in 1980 by engineers from seven General Motors (GM) divisions, to identify a common OSI-based networking standard Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 310 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 for plant-floor systems. The Task Force grew to include all GM divisions, many other users, and many vendors. Its specifications are known as Manufacturing Automation Protocol (MAP). The MAP specifications mostly reference OSI standards, but they also draw on ANSI, IEEE, EIA, CCITT, and various industry standards. Where standards do not exist, as in the case of the manufacturing messaging protocol, the MAP Task Force is either defining its own or instigating their formation by industry standards bodies. In 1984, the MAP Users Group was formed, under the auspices of GM, with the Society of Manufacturing Engineers as its Secretariat. Its objective is to promote knowledge and use of MAP, and to insure input from users. In 1985, Boeing sponsored a similar effort to specify common networking protocols, known as the Technical and Office Protocols (TOP), for the engineering and business offices. TOP is largely compatible with MAP, differing only at the lower two layers and the application layer where TOP addresses requirements of the technical and office user, rather than factory users. Later in 1985, a TOP Users Group was formed. The entire effort became an international effort known as MAP/TOP, and the user group became the MAP/TOP User Group, which meets twice a year. Today, the MAP/TOP User Group is an independent, self-funded organization that represents thousands of users worldwide, tied together through a worldwide federation of MAP/TOP user groups. Membership is open to either users or companies. The Industry Cooperative Services (ICS) is the worldwide secretariat. The MAP/TOP User Group also is a member of the Corporation for Open Systems (COS) and in North America, COS acts as the MAP/TOP User Group secretariat. The MAP/TOP User Group is a Requirements Interest Group (RIG) of the Corporation for Open Systems (COS). This means that the MAP/TOP User Group generates requirements that vendors can use to built products. COS serves as the coordinator between users and vendors. The MAP/TOP Task Force and User Group also is a major contributor of technical and conceptual ideas and specifications to the NIST, COS, and many of the IEEE POSIX Groups. For further information contact the World Federation of MAP/TOP Users Groups, P.O. Box 1457, Ann Arbor, MI 48106, Telephone: (313) 769-4571, Fax: (313) 769-4064. In North America, also contact the Corporation for Open Systems at 1750 Old Meadow Road, Suite 400, McLean, VA 22102-4306, Telephone: (703) 883-2700, Fax: (703) 848-8933. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.3 The Informal Standards Organizations 311 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS _N_C_C_:__N_a_t_i_o_n_a_l__C_o_m_p_u_t_i_n_g__C_e_n_t_r_e The NCC, centered in Manchester, England, though not a standardizing body, is active in developing codes of practice and providing testing and certification services for information technologies. It is currently leading a consortium to establish a harmonized European Test service for POSIX. For further information contact National Computing Centre Ltd., Oxford Road, Manchester M17ED, UK, Telephone: (061) 228-6333. _N_e_t_w_o_r_k__M_a_n_a_g_e_m_e_n_t__F_o_r_u_m A vendor-driven group, the Network Management Forum is chartered to produce a commonly agreed-upon specification subset of ISO's network management protocols and the command sets to implement this subset. The promise of the NMF is that all of the network management products that its members come up with will conform to this common specification. The NMF itself will produce no products nor will it specify implementations. Rather, the NMF will specify interfaces. Major vendors belong to the NMF from both the computer (e.g., IBM, DEC, HP, Unisys) and telecommunications industries (e.g., AT&T, Northern Telecom, Telecom Canada). The NMF has published Release 1 of its specifications (1990). Member firms are developing products that conform to Release 1. NMF information may be had from the organization at 40 Morristown Road, Bernardsville, NJ 07924. Telephone: (201) 766-1544. _N_P_S_C_:__N_a_t_i_o_n_a_l__P_r_o_t_o_c_o_l__S_u_p_p_o_r_t__C_e_n_t_e_r An Australian organization, the National Protocol Support Center was formed in 1986 as a joint effort between industry and the government. Like SPAG, COS, and POSI, the NPSC is promoting the adoption of OSI standards in information technology products and will be supporting a conformance testing capability in Australia. The Australian government, however, provides approximately 50 percent of the NPSC funding. For further information, contact (contact address and other information TBD). _O_b_j_e_c_t__M_a_n_a_g_e_m_e_n_t__G_r_o_u_p Founded in 1989 and headquartered in Framingham, MA, with marketing operations in Boulder, CO, the Object Management Group (OMG) is an international organization of more than 146 systems vendors, software developers and users. The OMG was founded to promote the theory and practice of object management technology in the development of software. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 312 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 The OMG's goal is to develop a common framework, based on industry- derived guidelines, that is suitable for object-oriented applications. The adoption of this framework will make it possible to develop a heterogeneous applications environment across all major hardware and operating systems. The OMG members are quick to form a consensus on certain object management issues because they see these issues directly affecting their software sales. For example, the OMG's object request broker design--key software needed to allow disparate open systems to request object services from remote sites--is supported by all the major object-oriented software vendors (e.g., IBM, Apple, Sun, DEC, HP, NCR, AT&T). Further information is available from the OMG at 492 Old Connecticut Path, Framingham, MA 01701. Telephone: (508) 820-4300. _O_S_F_:__O_p_e_n__S_o_f_t_w_a_r_e__F_o_u_n_d_a_t_i_o_n The Open Software Foundation is a nonprofit, international vendor organization. Formed in 1988 by seven sponsoring computer manufacturers, its goals are to develop specifications for an open computing environment, develop software based on the specifications, and sponsor research and development in open systems. OSF specifications are defined, and software developed, using an open process into which vendors and users have input and access. The specifications will be available, and the software licensable, to OSF members and nonmembers. Both members and nonmembers can also submit technologies to the OSF for consideration as an OSF specification and/or offering. Only OSF members, however, can participate in the selection of technologies or get early access to the software offerings. OSF's specifications and software will be based on IEEE's core POSIX system (POSIX.1 {2}). Other specifications and software will be based on a variety of international and national, as well as industry standards (e.g., AT&T System V.2 UNIX, Berkeley BSD UNIX, Massachusetts Institute of Technology's (MIT) X Window System and Kerberos Security System, Carnegie Mellon University's Mach Kernel, and X/Open's Transport Independent Interface). The remainder of OSF software will based on technologies contributed by numerous companies as part of OSF's Request for Technology (RFT) process. In addition to its specification and software work, the OSF has created and funded a research institute to innovate and transfer open systems technology from universities and research labs to commercial companies. OSF active-participation membership is open to computer hardware and software companies, government agencies, educational institutions, and other interested organizations worldwide. Memberships range from $25,000 a year for profit-making organizations to $5,000 a year for nonprofit Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.3 The Informal Standards Organizations 313 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS organizations. The OSF currently has more than 65 sponsors and members, and more than $150 million in funding commitments through 1991. For further information, contact OSF at Eleven Cambridge Center, Cambridge, MA, Telephone: (617) 621-8700. Alternatively, contact European headquarters at Open Software Foundation/Europe, Stefan-George- Ring 29, 8000 Munich 81, Germany, Telephone: (49 89) 930 920, or Open Software Foundation/Japan, ABS Building, 2-4-16 Kudan Minami, Chiyoda-Ku, Tokyo 102, Japan, (81 3) 3 221 9770. _P_e_t_r_o_c_h_e_m_i_c_a_l__O_p_e_n__S_o_f_t_w_a_r_e__F_o_u_n_d_a_t_i_o_n Founded in Oct., 1990, the Petrochemical Open Software Corporation (POSC) was started by BP Exploration, Chevron, Elf Aquitane, Mobil and Texaco to facilitate the development of integrated computing technology for the exploration and production (E & P) segment of the international petroleum industry. Today, membership is open to all entities interested in the E & P industry. These members include other petroleum companies, E & P service companies, software vendors, computer manufacturers, and research institutes. POSC's primary mission is the development of an industry-standard, open systems-based, software integration profile for E & P applications. This platform will be the interface between petrochemical software applications, database management systems, workstations and users. POSC activities focus on the development of an integrated E & P data model, a common look and feel user front-end, and a set of test suites enabling developers to evaluate their offerings against selected industry standards. POSC is moving quickly and has sent out two public requests for inputs in several technical areas. Project teams for base standards, the E & P data model, and data access are in place. Staffing is in progress for other projects and special interest groups have been formed. POSC offerings will be released to industry for production over the next few years. POSC is headquartered in Houston, TX at 10777 Westheimer, Suite 275, Houston, 77042. Telephone: (713) 784-1880. _P_O_S_I_:__P_r_o_m_o_t_i_n_g__C_o_n_f_e_r_e_n_c_e__f_o_r__O_S_I The Promoting Conference for OSI was formed in Japan in November 1985 by six major computer manufacturers and the Nippon Telephone and Telegraph Corporation. Its raison d'etre is to promote the adoption of OSI standards by cooperating with other international groups that have the same objective, such as the European-based SPAG and the US-based COS. But conformance testing in Japan is being developed and will be provided by the INTAP. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 314 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 For further information, contact (contact information TBD). _S_P_A_G_:__S_t_a_n_d_a_r_d_s__P_r_o_m_o_t_i_o_n__a_n_d__A_p_p_l_i_c_a_t_i_o_n__G_r_o_u_p The Standards Promotion and Application Group (SPAG), founded in 1983, is a nonprofit, international research and development consortium of about 65 information technology manufacturers and users. In 1986, it became a company registered under Belgian law as SPAG Services s.a. SPAG's goals are to promote multivendor, interoperable products based on international standards, particularly OSI, and to keep its members informed about the latest developments in functional standards and conformance testing of products. To achieve its goals, SPAG plays a leading role in the European Workshop on Open Systems (EWOS), publishes the Guide to the Use of Standards (GUS) regularly, and participates in the development of International Standard Profiles (ISPs). SPAG is particularly active in the development and marketing of test tools for manufacturing applications. Through its SPAG-CCT efforts, (a collaboration of European organizations) which arose out of the ESPRIT Project 955, SPAG is developing, and will be providing, conformance test tools for testing MAP/TOP 3.0, and conformance testing services to industry. SPAG also is working within Europe to implement the certification infrastructure for OSI products, and is involved in a number of Conformance Test Services (CTS) projects within the Commission of European Communities (CEC). In addition, SPAG is active in Telecommunications areas and is leading a consortium developing verification services for the Broadband Networks project RACE. Twelve shareholder companies make up SPAG's board of directors. The original founding companies--Bull, ICL, Nixdorf, Olivetti, Philips, Siemens, and STET--occupy seven seats on SPAG's twelve member board. The shareholder membership was subsequently expanded to include Alcatel, British Telecom, Digital Equipment Corp., Hewlett-Packard, and IBM, who occupy the five remaining board seats. SPAG has close working relationships with its counterparts in North America (COS) and the Far East (POSI). For further information, contact Graham Knight, at SPAG Services s.a., Standards Promotion and Application Group (SPAG), Avenue des Arts, 1-2 bte 11, 1040 Brussels, Belgium, Telephone: 32 2 210 08 11, Fax 32 2 210 08 00. _S_Q_L__A_c_c_e_s_s__G_r_o_u_p The SQL Access Group is a vendor group formed by a number of people in the ISO Remote Data Access (RDA) Group. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.3 The Informal Standards Organizations 315 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS The SQL Access Group's charter is several fold. First, the Group is chartered to define a common subset of SQL functions to get around the many SQLs that exist. The specifications will include an SQL data format, as well as protocols for moving data within a multivendor SQL environment. Also included will be specifications for an enhanced SQL programming interface that will let developers write a single application that can access a variety of SQL databases. These SQL Access specifications are scheduled to be published in late 1991. The SQL Access Group's second charter is to accelerate the work of the RDA group. Third, the SQL Access Group is working on putting more distributed functionality into RDA. Toward this end, each thing accomplished by the SQL Access group is fed back into the RDA group. For further information, contact the SQL Access Group at (Address TBD). _U_N_I_X__I_n_t_e_r_n_a_t_i_o_n_a_l UNIX International (UI) is a nonprofit industry organization formed to represent hardware manufacturers, system integrators, independent software vendors, value-added resellers, end-users, government agencies worldwide, industry standards bodies, and academic and research institutions who want to direct the evolution of System V UNIX. It has since expanded its scope to provide a framework for UNIX-based open systems work in the areas of desktop computing, corporate hub computing, and distributed computing. Unlike X/Open, OSF, AT&T, and the IEEE, UI does not produce specifications, software, or standards. Its functions range from specifying technical and timing requirements for future System V versions and making suggestions about specific function designs to influencing AT&T UNIX licensing policies. Using its ``one-member, one-vote'' approach, UI members formulate a consensus regarding the requirements and technical specifications for new System V UNIX versions. UI delivers its requirements to UNIX System Laboratories (USL), the AT&T spinoff that develops, distributed, and licenses UNIX. UI is USL's primary input source on technical requirements, conformance, and timing of releases. USL is committed to implement software to satisfy UI's requirements, unless there is a reason not to. UI accomplishes its requirements and UNIX roadmap work through a series of work groups. UI members get early access to AT&T UNIX source code. UI also offers its members business opportunities seminars, porting guides and the use of member companies' porting centers, technical courses on various aspects of UNIX, and loaner or discounted systems from member companies. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 316 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 For further information, contact UNIX International, Waterview Boulevard, Parsippany, NJ 07054, (201) 263-8400 or (800) 848-6495. In Europe contact UNIX International, Avenue de Beautieu 25, 1160 Brussels, Belgium, (32-2-672-3700). In the Asian Pacific region, contact Karufuru-Kanda Bldg. 8F, 1-2-1 Kanda Suda-cho, Chiyoda-du Tokyo 101, Japan, (81) 3-5256-6959. _U_s_e_r__A_l_l_i_a_n_c_e__f_o_r__O_p_e_n__S_y_s_t_e_m_s The user Alliance for Open Systems was formed from two informal organizations (the Atlanta 17 and the Houston 30). The Alliance is currently a Requirements Interest Group (RIG) of the Corporation for Open Systems International (COS). The Alliance is dedicated to overcoming barriers to open systems and speeding the development and deployment of open systems products. It intends to act as a catalyst toward the development and use of open systems. It will develop no specifications or products. Rather, the Alliance will create and support processes to influence and accelerate the availability of open systems technology (e.g., a repository of information about the cost benefits of open systems). In 1990 the organization began its work by identifying barriers to open systems and global actions to eliminate those barriers. In 1991 the organization intends to start bringing resources to bear to achieve its goals. The Alliance has had one formal meeting (Dallas, March 1991) and will have its second formal meeting in McLean, Virginia in Nov. 1992. Alliance committee work is ongoing throughout this period with three major subgroups in the formative stages. For further information, contact the Corporation for Open Systems, 1750 Old Meadow Road, Suite 400, McLean, VA 22102-4306, Telephone: (703) 883-2700. _X_._4_0_0__A_P_I__A_s_s_o_c_i_a_t_i_o_n The X.400 API (Application Programming Interface) Association is an industry association formed initially to bring X.400 messaging into the PC LAN world. There are more than twenty companies in the association, and they include most of the current X.400 players. Among its activities, the X.400 API Association developed an X.400 Application Programming Interface specification in conjunction with X/Open. These interfaces, completed in September 1990, are jointly owned by the X.400 API Association and X/Open. The two organizations contributed these interface specifications to the P1224 Group to use as a basis for the P1224 standard. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.3 The Informal Standards Organizations 317 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS For further information contact (Address and other contact information: TBD) _X_/_O_p_e_n X/Open is an independent, nonprofit, consortium formed in 1984 to specify a complete, source-level-portable application environment. Although its members were initially vendors, X/Open's membership now encompasses users, system integrators, value-added resellers, government agencies worldwide, other industry-standards groups, and academic and research institutions. Through an extensive market research program, X/Open works with members and nonmembers X/Open to identify user and market requirements for computer systems and software, prioritize the functional areas for X/Open to focus on, and determine the actual specifications for the X/Open environment. The prioritized requirements, identified directly drive X/Open's specification process. The X/Open user requirements process, called the ``Xtra'' process determines requirements through one-on-one interviews and a series of market requirements conferences. The X/Open specifications are published in a series of books known as the X/Open Portability Guide. The X/Open environment includes specifications for an operating system interface, networking, data management, programming languages, floppy disk formats, and internationalization, and distributed transaction processing. The X/Open Group does not normally define standards for these areas. Instead, it chooses from existing and emerging standards. The underpinnings of the X/Open environment is based on the IEEE core POSIX (POSIX.1 {2}) standard and parts of AT&T's System V Interface Definition (SVID). Most of the remainder of the specifications are formal international standards that are already accepted or likely to be accepted. However, to rapidly get standards into the field for practical use, where no formal standards exist, X/Open specifies industry standards and widely-accepted de facto standards (including some based on real- world products that have achieved consensus in the marketplace). In some instances where neither formal nor de facto specifications exist but there is a strong need for standards (e.g., internationalization and transaction processing), X/Open has itself defined specifications. Besides producing specifications, X/Open cooperates technically with international standards bodies and private specification groups. To help users identify X/Open-compliant systems, the X/Open Group has developed a set of verification tests and a branding program. X/Open was founded in Europe by Bull, Nixdorf, Olivetti, International Computers Ltd. (ICL) and Siemens. Its vendor membership was Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 318 C Standards Infrastructure Description ENVIRONMENT INTERIM DOCUMENT P1003.0/D13 subsequently expanded to include AT&T, Digital Equipment Corp., Fujitsu, Hewlett-Packard, IBM, NCR, Nokia Data, Philips, Sun Microsystems, and Unisys. These vendors establish the X/Open specifications, although User and Independent Software Vendor (ISV) Advisory councils, which meet on a regular basis, as well as the ``Xtra'' process, provide the means for input from both users and ISVs. The user advisory council is composed of senior executives from Fortune 500 and International 1000 companies, as well as large government agencies in the US and Europe. The X/Open advisory council is composed of senior management of large software firms who have responsibility for planning and implementing corporate business strategies. All members of X/Open are committed to supporting the environment defined. More than 100 software companies worldwide building compliant software products. For further information, contact X/Open Company Ltd. at Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, UK, Telephone: 44 734 508 311. In the US, contact X/Open at 1010 El Camino Real, Menlo Park, CA 94025, Telephone: (415) 323-7992. Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. C.3 The Informal Standards Organizations 319 P1003.0/D13 Annex D (informative) Electronic-Mail _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _K_e_v_i_n _L_e_w_i_s The following table lists currently-known e-mail addresses for active working group members. To correct your entry, send e-mail directly to Hal Jespersen, listed below. Michelle Aden Sun Microsystems aden@ebay.sun.com Ralph Barker UniForum ...uunet!usrgrp!ralph Carolyn Baker MITRE cgb@d74sun.mitre.org Timothy Baker Ford Aerospace Rich Bergman NOSC rich@tecr.nosc.mil Andy Bihain GTE Telops arb1@gte.bunny.com Joseph Cote Treasury Board of Canada Bernard Cox NASA JSC Don Folland CCTA def@cctal.co.uk Thomas Ford USAF tford@xpt.ssc.af.mil Bob Gambrel Unisys rjg@rsvl.unisys.com Al Hankinson NIST/NCSL alhank@swe.ncsl.nist.gov Jim Isaak DEC isaak@decvax.dec.com Petr Janecek X/Open p.janecek@xopen.co.uk Hal Jespersen POSIX Software Group hlj@posix.com Lorraine Kevra AT&T L.Kevra@att.com Ruth Klein AT&T ruthlk@attunix.att.com Doris Lebovits AT&T lebovits@attunix.att.com Kevin Lewis DEC klewis@gucci.dec.com Heinz Lycklama Interactive Systems heinz@ism.isc.com Randolph Lynwood NASA Doug MacDonald General Electric Roger Martin NIST rmartin@swe.ncsl.nist.gov Dick McNaney SAIC saic-02@huachuca-emh2.army.mil d Pete Meier IBM ...uunet!aixsm!meier Mary Lynne Nielsen IEEE m.nielsen@ieee.org Patricia Oberndorf NADC tricia@nadc.navy.mil Jim Oblinger NUSC oblinger@nusc.ada.arpa Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Annex D Electronic-Mail 321 P1003.0/D13 GUIDE TO THE POSIX OPEN SYSTEMS Pat Patterson NASA patterso@gmuvax2.gmu.edu David Pruett NASA JSC dpruett@nasamail.nasa.gov Wendy Rauch Emerging Technologies ...uunet!etg!wrauch Group Brad Reed EDS reed@eds.com Carl Schmiedekamp NADC schmiede@nadc.navy.mil Fritz Schulz OSF fschulz@osf.org Richard Scott Chemical Abstracts uunet!osu-cis!chemabs!rls27 Service Glen Seeds Systemhouse Charles Severance Mich. State Univ. crs@convex.cl.msu.edu Lewis Shannon NCR lew.shannon@dayton.ncr.com Peter Smith DEC psmith@decvax.dec.com Sandra Swearingen USAF tic-tisc@afcc-oal.af.mil Marti Szczur NASA/GSFC msxcxur@postman.gsfc.nasa.gov Martial Van Neste CGI Group vanneste@bond.crim.ca d Robert Voigt Space & Naval Warfare voigt@nusc.ada.arpa Systems Command Gentry Watson UNIX Int'l glw@ui.org Alan Weaver IBM ...uunet!aixsm!weaver d John Williams GM-CPC Hdqts. ...uunet!edscws!rphroy! gmcpcl!jrw Arnold Winkler Unisys George Zerdian Hughes george@eos.wel.scg.hac.com Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 322 D Electronic-Mail P1003.0/D13 Alphabetic Topical Index A Application Platform Implementation Considerations Abbreviations ... 13 ... 33 ABS ... 314 application platform Accounting ... 171, 241 definition of ... 7 ACID ... 183, 185, 189-190 Application Program Interface ACL ... 135 (API) Elements ... 130 Ada ... 45, 48 Application Program Interface Administration ... 170 (API) ... 20, 25 AEP ... 7 application program interface AES ... 67, 72, 181 (API) AFNOR: Association Francaise de definition of ... 7 Normalization ... 291 Application Program Interface AFNOR ... 291 Services ... 56, 88, 107, 119, Alphabetic Topical Index ... 323 131, 154, 168, 178, 188, 201 ANSI: American National Standards Application Program Interface Institute ... 292 ... 24 ANSI X3.122 ... 121-122 Application Program Services ANSI X3.133 ... 112 ... 45 ANSI X3.135 ... 110-111, 196 Application Programming Interface ANSI X3.138 ... 110, 113 Services ... 232 ANSI X3.159 ... 262 Application Software Elements ANSI X3.168 ... 110-111, 196 ... 129 ANSI/ISO ... 157 application software entities ANSI ... 48-49, 111-114, 121-122, ... 25 140, 147, 155, 158-160, 162- application software 163, 194, 256, 266, 268, 288, definition of ... 7 292-293, 296-297, 299-300, Application to Application Service 303-304, 307, 311 ... 89 API Service Requirements ... 218 Application to System Services API ... 88 definition of ... 13 application APIA ... 98-99 definition of ... 7 API/EEI ... 98-100 Applications Environment Profile APL ... 46, 48 (AEP) APL ... 45-46, 48, 193, 305 definition of ... 7 Application Platform Decomposition APP ... 262, 303 III - Redirection ... 36 Approved POSIX Standardized Application Platform Decomposition Profiles ... 261 II - Layering ... 36 APT ... 305 Application Platform ASCE ... 85 Implementation - Subdivision ASCII ... 212 ... 35 ASN.1 ... 115, 121, 124, 227 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Alphabetic Topical Index 323 P1003.0/D13 AT&T ... 72, 75, 181, 312-313, CASE Data Interchange Format 316, 318-319 (CDIF) ... 123, 204 Availability Management ... 242 CASE ... 123, 129, 201, 204 CBEMA: Computer and Business Equipment Manufacturers B Association ... 306 CBEMA ... 304, 306-307 background ... 2, 6, 177, 184, CCITT: Comite Consultatif 215, 281 International de Telegraphie et base standard Telephonie ... 294 definition of ... 7 CCITT ... 97, 222-223, 234, 287, Base Standards Working Groups 290, 294, 296, 299, 303, 311 ... 278 CCR ... 195 Basic Network Services Model CCR ... 114-115, 195 ... 85 CDIF ... 121, 123, 201, 204 Basic Terminology ... 250 CD-ROM ... 202-203 Basic Window Services ... 131 CEC ... 309, 315 BASIC ... 46, 48, 50 CEDEX ... 310 BASIC ... 45-46, 48, 50, 193, 288 CEN/CENELEC/CEPT ... 294 Basis for This Guidance ... 253 CEN/CENELEC/CEPT ... 294 BCS: British Computer Society CEN/CENELEC ... 309-310 ... 306 CENELEC ... 294-296, 309-310 BCS ... 306 CENLEC ... 295 Bibliography ... 287 CEN ... 290, 294-296, 309-310 B.P ... 310 CEPT ... 295, 309-310 BSD ... 70, 179-181, 313 CGI ... 148, 160 BSI: British Standards Institute CGM ... 121-122, 147, 160-161, ... 293 266 BSI ... 293, 306 CGRM ... 147-148, 162 built-in ... 174 CH-1211 ... 2, 287 Character Sets and Data Representation ... 120, 212 C Character-based Terminal Reference Model ... 168 C Standard ... 141, 169, 181, 300 Character-Based User Interface C-2 ... 301 Services ... 167 C ... 46, 49 Clear Communications ... 256 CAD/CAM/CAE ... 149 C-LISP ... 193 CAD/CAM ... 125 CMA ... 234 CAD ... 47, 123 CMDB ... 240 CAIS-A ... 74 CNMA ... 309 CAIS-A ... 74 COBOL ... 47, 49 Canadian Standards Association COBOL ... 23, 27, 44-45, 47-49, (CSA) ... 293 112, 193, 266, 268, 278, 305, Capability and Security Services 307 ... 72 CODASYL: The Conference on Data Capacity Management ... 242 Systems Languages ... 307 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 324 Alphabetic Topical Index P1003.0/D13 CODASYL-ANSI ... 307 COS ... 307-308, 311-312, 314- CODASYL ... 112, 307 315, 317 Coherence ... 256, 278 CPIC ... 97 Common LISP ... 47 CPIO ... 69 Communication EEI Elements ... 80 CPU ... 59, 265 Communications Interface C++ ... 45, 47-48, 50 definition of ... 7 CRS ... 87-88, 90, 94, 97, 169 Communications Services API CRT ... 25 ... 26 CSA ... 293-294 Communications Services ... 25 CSA-Z243 ... 225 Completeness ... 255 CSMA/CD ... 301 Component Management Services CSS ... 161 ... 233 CTS ... 315 Computer Graphics Metafile (CGM) Cultural Conventions ... 215, 219 ... 122 Current Networking Standards Computer Graphics Reference Model ... 98 Level Structure ... 149 Current Standards in the POSIX OSE Configuration Management ... 170 ... 48, 68, 97, 111, 121, 139, Conformance Testing ... 182 156, 169, 193, 202, 221 Conformance to a POSIX SP ... 279 Current Standards ... 179 Conformance ... 3, 278 Curses ... 170 conformance ... 3, 7, 43, 68, 147-148, 162, 182, 230, 252- 255, 269, 273, 276, 278-279, D 284, 293, 303, 308, 310, 312, 314-316 DAC ... 232 Considerations for Developers of Data Access Services ... 108 POSIX SPs ... 273 Data Definition and Manipulation Content of the Multiprocessing Services ... 108 Systems Profile ... 264 Data Description Protocols Content of the Platform ... 120 Environment Profile ... 262 Data Format Protocols ... 120 Content of the Realtime Data Integrity Services ... 108 Application Profiles ... 269 Data Interchange Reference Model Content of the Supercomputing ... 118 Profile ... 266 Data Interchange Services ... 117 Content of the Transaction Data Interchange Standards Processing Profile ... 267 ... 121 Conventional Transaction Data Representation Services Processing Model ... 186 ... 92 Conventional Transaction Data Transfer and Connectivity Processing Reference Model ... 94 ... 185 Database Administration Services Conventions ... 5 ... 110 Coordinate Systems and Clipping Database API ... 104 ... 152 Database Manager ... 104 COS: Corporation for Open Systems Database Recovery Services ... 307 ... 110 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Alphabetic Topical Index 325 P1003.0/D13 Database Resource Management 233-234, 239, 249-250, 253-257, Services ... 109 262, 264, 273, 275, 277, 279- Database Services ... 103 284, 287-288, 291, 295, 301, Database Standards ... 111 305, 307, 309-310 Database Utility Program ... 104 DOD ... 234 DBMS ... 201 domain DBSSG ... 114 definition of ... 8 DBTG ... 307 DTE ... 287 DCT ... 287 DTP ... 184, 193-195 DDLC ... 307 DDL ... 112, 307 De Facto Standards ... 123, 170 E DEC ... 165, 312-313 Defining a Profile ... 257 EBU ... 309 Definitions ... 5 ECMA: European Computer definitions ... 7 Manufacturers Association DEF ... 202-203, 235 ... 300 Detailed Guidance to Profile ECMA-127 ... 195 Writers ... 254 ECMA-149 ... 74, 203 Detailed Network Service ECMA ... 74, 97, 99, 113, 203- Requirements ... 91 204, 234, 296, 300, 303, 310 Development of a Profile ... 258 EDIFACT ... 121-122 Dialog Services ... 137 EDI ... 122 DIN: Deutsches Institut fur EEI Normung ... 296 definition of ... 13 DIN ... 216, 296 EEI-API Service Relationships Directory Services Architecture ... 27 ... 87 EEI-API ... 27 Directory Services ... 88 EEI ... 8, 13, 20, 24-25, 27-28, directory ... 62-63, 69, 73, 77, 32, 34, 43, 55, 78, 80, 82, 86, 79, 85-88, 96-97, 177, 180, 94-96, 118-120, 127-130, 140, 191-192, 195, 234, 309-310, 315 150, 155, 167, 174-175, 178, DIS ... 50, 156, 158-160, 162, 192 195, 256, 290 EFTA ... 295 Distributed Database Management EIA: Electronic Industries Services ... 110 Association ... 300 Distributed System Configuration EIA ... 123, 204, 300, 311 Management ... 241 Electronic Data Interchange (EDI) Distributed System Environment ... 122 Model ... 29 Electronic-Mail ... 321 Distributed System Services Emerging Networking Standards ... 92 ... 99 DML ... 112, 307 Emerging Standards in the POSIX DNI ... 86 OSE ... 50, 70, 112, 122, 140, document ... 2, 5-8, 12, 22, 29, 161, 169, 193, 203, 224, 234 31, 41, 43, 68, 75, 106-107, Emerging Standards ... 97, 180 111, 121-122, 125, 139, 156, EMUG/OSITOP: European Users Groups 181, 189-190, 198, 202-203, ... 308 217, 219-220, 226-227, 230, Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 326 Alphabetic Topical Index P1003.0/D13 EMUG/OSITOP ... 308 Fault Diagnosis ... 246 EMUG ... 310 Fault Isolation; ... 245 _e_n_v_i_r_o_n ... 69 Fault Management ... 74, 171, 245 Environment Services ... 60 Fault Recovery ... 246 ENV ... 290, 295 FCC ... 293 EPRI: Electric Power Research FES ... 32 Institute ... 308 FGP ... 233 EPRI ... 308 FIFO ... 69 _e_r_r_n_o ... 69 File Modification Primitives Error Handling ... 133, 153 ... 62 ESPRIT (European Strategic File Oriented Services ... 62 Programme for Research and File Support Services ... 63 Development in Information file system ... 69, 71, 269-270 Technology) ... 309 FIMS ... 169 ESPRIT ... 309, 315 FIMS ... 141, 169 ETSI: European Telecommunications find ... 265 Standards Institute ... 309 FIPS 120 ... 159 ETSI ... 309 FIPS 127 ... 111, 196 ETS ... 309 FIPS 151-1 ... 70, 75, 262 Event Handling ... 132 FIPS 158 ... 139 EWOS: European Workshop for Open FIPS ... 70, 75, 111, 113, 139, Systems ... 310 256, 266, 268, 285, 301, 303 EWOS ... 310, 315 Flagger ... 110 _e_x_e_c() ... 69 FOCUS: FOCUS Committee ... 310 External Environment Interface FOCUS ... 310 (EEI) Elements ... 130 foreground ... 177 External Environment Interface Foreword ... 282 (EEI) ... 25 _f_o_r_k() ... 11, 69 definition of ... 8 Formal Standards Groups ... 291 External Environment Interface FORTRAN-77 ... 266 Elements ... 80 FORTRAN ... 47 External Environment Interface Fortran ... 49 Services ... 48, 66, 93, 109, FORTRAN ... 27, 45-48, 112, 119, 138, 155, 169, 175, 190, 263-264 201, 233 FTAM ... 74, 85, 97, 310 External Environment Interface FTP ... 97 ... 20 FULL ... 288 external environment Functionality of POSIX.1 Standard definition of ... 8 ... 69 Functionality ... 68 F G Factors in Standards Selection ... 30 GAN ... 95 Fault Avoidance ... 246 Gap Identification ... 257 Fault Detection ... 245 Gaps in Available Standards ... 50, 71, 97, 114, 123, 141, 162, 170, 180, 194, 204, 225, Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Alphabetic Topical Index 327 P1003.0/D13 234 HFS-HCI ... 140 Gaps in Networking Standards High-End Realtime Profiles ... 100 ... 270 GDSII ... 121, 123 HLHSR ... 159 General Arrangement ... 281 HLJ ... 2, 33, 77, 145, 173, 191, General Normative Elements 229, 287, 289, 301 ... 282 HSF-HCI ... 140 General Purpose POSIX SPs ... 261 Human/Computer Interaction General Service Requirements Services API ... 26 Application Platform ... 211 Human/Computer Interaction General Terms ... 7 Services ... 25 General ... 1 Human/Computer Interface Generalized Input/Output Services definition of ... 8 ... 62 getconf ... 268 GKS-3D ... 147, 155, 159-160 I GKS ... 125, 142, 147, 149-150, 155, 157, 159-160, 266 IBM ... 165, 312-313, 315, 319 GOSIP ... 259, 308 ICL ... 315, 318 Government/Legal Standards ICS ... 311 ... 123, 170 ICST ... 301 GPC ... 165 IEC: International Graphic Design System II (GDSII) Electrotechnical Commission CAD Exchange Format ... 123 ... 296 graphical user interface ... 125 IEEE 1003.11 ... 267 Graphics Concepts ... 151 IEEE 1003.18 ... 181 Graphics Requirements ... 153 IEEE 1003.2 ... 268 Graphics Resource Management IEEE 1003.3.2 ... 182 Services ... 155 IEEE 1003.3 ... 68 Graphics Services ... 145 IEEE 1003.4 ... 181, 268 grep ... 265 IEEE 1003.6 ... 268 Guidance to Profile Writers IEEE 1003.7 ... 181 ... 252 IEEE 1003 ... 261 GUS ... 315 IEEE 802.3 ... 301 IEEE: Institute of Electrical and Electronic Engineers ... 300 H IEEE P1003.0 ... 74, 279, 303 IEEE P1003.10 ... 97, 99, 262 Hardware Description Language IEEE P1003.11 ... 97, 99, 183, (VHDL VHSIC) ... 123 192, 194, 262, 268 hardware IEEE P1003.12 ... 74, 84-85, 97 definition of ... 8 IEEE P1003.13 ... 99, 262 harmonization ... 251 IEEE P1003.14 ... 262 Harmonization ... 256 IEEE P1003.17 ... 85-86, 97 HCI ... 1, 125-131, 137-139, IEEE P1003.18 ... 262 141-142 IEEE P1003.1 ... 74-75, 297 Heterogeneous Environment Support IEEE P1003.2 ... 6 Services ... 110 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 328 Alphabetic Topical Index P1003.0/D13 IEEE P1003.3 ... 6, 276, 278-279, Informative Annexes ... 284 303 informative IEEE P1003.4 ... 70-71, 274, 276 definition of ... 6 IEEE P1003.4a ... 71 Initial Graphics Exchange IEEE P1003.6 ... 74, 97, 230, 232 Specification (NBSIR 86-3359) IEEE P1003.7 ... 86 ... 123 IEEE P1003.8 ... 97 Input Device Management ... 134 IEEE P1003. ... 6 Input Model ... 152 IEEE P1003 ... 13 Input Primitives ... 152 IEEE P1076 ... 121, 123 INTAP (Interoperability Technology IEEE P1201.1 ... 141 Association for Information IEEE P1201.2 ... 140-141 Processing) ... 310 IEEE P1201. ... 141 INTAP ... 310, 314 IEEE P1201 ... 164 Interapplication Entity Services IEEE P1224 ... 97 ... 138, 178 IEEE P1237 ... 99 Interapplication Software Entity IEEE P1238.0 ... 85 Services ... 48, 66, 155, 190, IEEE P1238.1 ... 85, 97 201, 233 IEEE P1238 ... 97 Interclient Communication ... 133 IEEE Std 1003.1 ... 68 interface IEEE-488 ... 301 definition of ... 8 IEEE ... 6, 13, 53, 140, 155, International and National 179-181, 230, 253, 258, 261, Standards Bodies Relationship 263-268, 273, 275, 277, 279, ... 291 288, 293, 296, 300-303, 311, International and National 313, 316, 318 Standards Bodies ... 291 IEEE Standards Diagram ... 302 International and National IGES/PDES ... 164 Standards Organizations IGES ... 121, 123, 163, 266 ... 291 III ... 36 International and National implementation agreements ... 250 Standards ... 179 Implementation Aspects ... 55, International and Other Formal 80, 105 Standards ... 180 implementation defined ... 5, 71, International Standards Bodies 220 Overview ... 290 definition of ... 5 International Standards ... 48, Importance Of Profiles ... 252 50, 68, 70, 121-122, 193, 202- Informal Standards Organizations 203, 221, 224 ... 306 Internationalization ... 181, 209 Information Interchange Interface internationalization definition of ... 8 definition of ... 9 Information Interchange Services interoperability API ... 26 definition of ... 9 Information Resource Dictionary Introduction ... 250, 261, 273, System (IRDS) ... 113 282, 289 Information Services ... 25 IPC ... 37, 265 Information System Management IPI ... 161 ... 235 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Alphabetic Topical Index 329 P1003.0/D13 IPO ... 164 ISO 8651-1 ... 159 IPS ... 77 ISO 8651-2 ... 159 IRDS ... 110, 113 ISO 8652 ... 48 ISAM ... 106 ISO 8805 ... 159 ISDN ... 307-308 ISO 8824 ... 115, 124, 227 ISIS ... 124 ISO 8825 ... 115, 121, 124, 227 ISO 1001 ... 202 ISO 8859-1 ... 2, 212, 225 ISO 1359 ... 44 ISO 8859- ... 223 ISO 1539 ... 48-49 ISO 8879 ... 121-122, 164 ISO 1989 ... 44, 48-49 ISO 8907 ... 110, 112 ISO 2014 ... 221 ISO 8- ... 221 ISO 2022 ... 221 ISO 9075 ... 110-111, 196 ISO 3307 ... 221 ISO 9127 ... 202-203 ISO 4031 ... 221 ISO 9293 ... 202 ISO 4217 ... 221 ISO 9592 ... 156, 161 ISO 4341 ... 202 ISO 9593-1 ... 156 ISO 4873 ... 221, 224 ISO 9593-3 ... 156 ISO 5807 ... 202-203 ISO 9593 ... 98 ISO 6093 ... 222 ISO 9596 ... 97 ISO 6160 ... 48-49 ISO 9660 ... 202-203 ISO 6373 ... 48 ISO 9735 ... 121-122 ISO 6429 ... 222 ISO 9945 ... 6 ISO 646 ... 221-222 ISO DIS 10148 ... 99 ISO 6522 ... 48-49 ISO DIS 10646 ... 224 ISO 6592 ... 202-203 ISO DIS 8613 ... 226 ISO 6593 ... 202-203 ISO DP 10027 ... 110 ISO 6936 ... 222 ISO DP 10303 ... 121-122 ISO 6937-1 ... 222 ISO DP 8800 ... 110 ISO 6937-2 ... 222 ISO DP 9579 ... 112 ISO 6937 ... 222 ISO: International Organization ISO 7185 ... 48-49 for Standardization ... 296 ISO 7350 ... 222 ISO/CCITT X.400 ... 97, 124, 234 ISO 7498-2 ... 233 ISO/IEC 8073 ... 287 ISO 7498 ... 287 ISO/IEC 8613 ... 233 ISO 7665 ... 202 ISO/IEC 9804 ... 114 ISO 7942 ... 159 ISO/IEC 9805 ... 115 ISO 7- ... 221-222 ISO/IEC 9899 ... 48-49 ISO 802 ... 97-98 ISO/IEC 9945-1 ... 2, 67-68, 70- ISO 803 ... 97 71, 267 ISO 8072 ... 287 ISO/IEC 9945-3 ... 68 ISO 8211 ... 202-203 ISO/IEC 9945 ... 10 ISO 8485 ... 48 ISO/IEC CD 9995- ... 224 ISO 8587 ... 97 ISO/IEC DIS 10026-1 ... 192-194 ISO 8601 ... 223 ISO/IEC DIS 10026-2 ... 193-194 ISO 8613 ... 121, 233 ISO/IEC DIS 10026-3 ... 193-194 ISO 8631 ... 202-203 ISO/IEC DIS 10026 ... 195 ISO 8632 ... 121-122, 160 ISO/IEC DIS 10367 ... 224 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 330 Alphabetic Topical Index P1003.0/D13 ISO/IEC DIS 9804-3 ... 195 Language Services ... 43 ISO/IEC DIS 9805-3 ... 195 Language Standards Activities ISO/IEC DP 10026-1 ... 183 ... 49 ISO/IEC DP 9759 ... 110 language-binding API ISO/NMF ... 97 definition of ... 9 ISO/OSI ... 97 language-independent service ISO Networking Reference Model specification ... 81 definition of ... 9 ISP ... 97, 253 LAN ... 95, 317 Issues Pertaining to Referencing LANS ... 301 Base Standards ... 278 Layering ... 35 ISV ... 319 LC_COLLATE ... 220 ITA ... 222 LC_CTYPE ... 220 ITU ... 290 LC_MONETARY ... 220 LC_NUMERIC ... 220 LC_TIME ... 220 J License Services ... 237 LISP ... 45, 47-48, 50, 159, 266 JISC: Japanese Industrial LIS ... 193 Standards Committee ... 297 local adaptation JISC ... 297 definition of ... 9 JIS ... 224 locale Job Scheduling ... 239 definition of ... 9 JTC1: Joint Technical Committee 1 _l_o_c_a_l_e() ... 220 ... 297 locale ... 9, 69, 177, 181, 220, JTC1 ... 161, 165 284 Localization Tools Requirements ... 219 K localization definition of ... 9 KEYSYM ... 163 Logical Naming Services ... 65 KornShell ... 25, 303, 309-310, 315, 319 M L MAC ... 232-233 Main Elements of a Profile Labeling and File Structure of Definition Document ... 255 Magnetic Media ... 202 Maintainability ... 247 language binding ... 9, 22, 26- make ... 265 27, 43, 45, 50, 126, 130-131, MAP ... 259, 308, 310-311 146, 148, 150, 155-156, 159- MAP/TOP User Group: (Manufacturing 161, 193, 235, 263-264, 268 Automation Protocol and Language Resource Management Technical and Office Protocol) Services ... 48 ... 310 Language Service Reference Model MAP/TOP ... 308, 310-311, 315 ... 44 may definition of ... 6 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Alphabetic Topical Index 331 P1003.0/D13 Memory Management Services ... 65 NDL Standard Database Language MHS ... 124, 310 ... 112 Mid-Range Realtime Profiles NDL ... 110, 112 ... 270 Network Application Program MIL-STD-1777 ... 97 Interface (API) Services MIL-STD-1778 ... 100 ... 79 MIL-STD-1780 ... 97 Network Configuration Management MIL-STD-1781 ... 97 ... 240 MIL-STD-1782 ... 97 Network Management and Security MIL-STD-1838A ... 74 Services ... 96 Minimal Embedded Realtime Profiles Network Management and Security ... 269 User Services ... 96 Miscellaneous Services ... 109 Network Management Forum ... 312 MITI ... 297, 310 Network Management Services MIT ... 161, 163-164, 313 ... 93 MMS ... 310 Network Services ... 77 MOSI ... 27 NFS ... 100 MRS ... 140 NIST: National Institute of MS-DOS ... 225 Standards and Technology Multipart POSIX SPs ... 280 ... 301 Multiple POSIX OSE APIs to NIST ... 139, 158, 266, 293, 296, Different OSI Layers ... 84 301, 303, 308, 311 Multiprocessing Systems Platform NMF ... 312 Profiles ... 263 Node Internal Communication and Synchronization Services ... 61 N Nongovernment Formal Standards Organizations ... 300 Naming and Directory Services Nontechnical Security Objectives ... 62 ... 232 naming services Normative Annexes ... 284 logical ... 65 Normative References ... 2, 283 N/A ... 193 normative National Standards Bodies Overview definition of ... 6 ... 290 NOTE ... 191-192 National Standards ... 50, 70, NPSC: National Protocol Support 122-123, 193, 203-204, 223, 225 Center ... 312 National/International ... 156 NPSC ... 312 Natural Language Support ... 217, NURBS ... 151 219 NBSIR 86-3359 ... 121, 123, 163 NBSIR 86 ... 121 O NCC: National Computing Centre ... 312 Object Management Group ... 312 NCC ... 312 Objectives ... 68 NCGA ... 165 ODA/ODIF ... 121-122, 227 NCR ... 313, 319 ODA ... 121, 226, 233, 310 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 332 Alphabetic Topical Index P1003.0/D13 ODASYL ... 141, 169 Other Issues ... 277 ODIF ... 121 Output Model ... 153 Office Media Management and Output Primitives ... 151 Backup/Restore ... 238 OLTP Resource Management Services ... 191 P OLTP ... 139, 184, 191, 267-268 OMG ... 312-313 P1003.4 ... 70-71 OMNICOM ... 94 P.10 ... 45 Online Disk Management ... 239 P.5 ... 41 Open Document Architecture PAR ... 194 (ODA)/Open Document Interchange Pascal ... 47, 49-50 Format (ODIF) ... 121 PCI ... 97, 100 Open Issues ... 51, 74, 124, 142, PCTE ... 74 165, 171, 182, 196, 205, 227, PCTE ... 74, 203-204, 300, 309 243 PEP ... 181, 261-263 open specifications Performance and Capacity definition of ... 9 Specification Metrics ... 165 Open System Application Program Performance and Capacity Values Interface ... 220 definition of ... 9 performance evaluation Open System Environment (OSE) definition of ... 10 definition of ... 10 Performance Management ... 242 open system performance requirement definition of ... 10 definition of ... 10 OSC ... 67, 72 Performance ... 171 OSE Cross-Category Services performance ... 50, 72, 114, 124, 141, definition of ... 10 163, 170, 195, 204, 226, 234, Petrochemical Open Software 243 Foundation ... 314 OSF: Open Software Foundation PEX ... 142, 161, 266 ... 313 PEX-SI ... 161 OSF/1 ... 72 PHIGS PLUS ... 155, 158 OSF/1 ... 72, 179, 181 PHIGS ... 125, 142, 147, 149-150, OSF ... 67, 72, 179, 181, 313- 155-159, 161, 266 314, 316 PIK ... 150, 161 OSI Distributed Transaction pipe ... 69, 153 Processing (DTP) ... 193 pipes ... 69 OSI ... 11, 32, 74, 77, 81-86, PL/1 ... 47, 49 94, 97, 101, 113-115, 138, 163, PL/1 ... 45, 47-49, 112, 193, 305 193-195, 233, 259, 266, 268, PLB ... 165 297, 299-300, 303, 307-308, PLUS ... 158-159 310-312, 314-315 P.O ... 308, 311 OSI Network Services Standards portability ... 101 definition of ... 10 OSITOP ... 310 Portable Common Tool Environment OSI/VT ... 97 (PCTE) ... 204 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Alphabetic Topical Index 333 P1003.0/D13 Portable Operating System POSIX.0 Interface (POSIX) Part 1 definition of ... 13 ... 68 POSIX.0 ... 11, 13, 258, 277, 301 POSC ... 314 POSIX.10 ... 259, 264-267 POSI: Promoting Conference for OSI POSIX.11 POSIX Transaction ... 314 Processing ... 194 POSI ... 308, 310, 312, 314-315 POSIX.11 ... 185, 193-194, 259, POSIX Network Standards Efforts 264 ... 83 POSIX.13 ... 259, 264, 269 POSIX Open System Environment - POSIX.14 ... 260, 263-265 General Requirements ... 16 POSIX.15 ... 264, 267 POSIX Open System Environment POSIX.18 ... 260-263 (POSIX OSE) POSIX.1 ... 27, 30-31, 44, 70, definition of ... 10 104, 140, 180-181, 194, 232, POSIX Open System Environment 249-251, 261-262, 264, 266-267, Profiles ... 32 269-270, 274, 276, 301, 303, POSIX Open System Environment 313, 318 Reference Model ... 19 POSIX.2 ... 6, 43, 140, 169, POSIX Open System Environment 179-182, 250, 262, 264, 266, Services ... 28, 39 276 POSIX Open System Environment POSIX.3 ... 6 Standards ... 29 POSIX.4 ... 181, 194, 259, 264, POSIX OSE Cross-Category Services 266, 268-270 ... 181, 207 POSIX.5 ... 264 definition of ... 10 POSIX.6 ... 233, 264, 266 POSIX OSE Database Services POSIX.7 ... 264, 266 Reference Model ... 104 POSIX.8 ... 123, 194, 266 POSIX OSE Network Services POSIX.9 ... 264 Reference Model ... 78 POSIX POSIX OSE Reference Model (with definition of ... 6 Transaction Processing) POSIX._n ... 186 definition of ... 13 POSIX OSE System Services POSIX-OSE ... 17 Reference Model ... 53 POSIX Database Reference Model POSIX OSE-Based Distributed ... 106 Systems ... 27 POSIX Networking Reference Model POSIX Platform Environment Profile ... 78 (PEP) ... 261 POSIX Open System Environment POSIX Security Interfaces ... 232 ... 15 POSIX SP Procedures and Rules POSIX OSE Graphics Service ... 279 Reference Model Standards POSIX SP Profiling Efforts ... 156 ... 261 POSIX OSE Graphics Service POSIX Standardized Profile (POSIX Reference Model ... 150 SP) POSIX OSE Reference Model - definition of ... 11 Distributed Systems ... 28 POSIX Standardized Profiles In- POSIX OSE Reference Model - Progress ... 261 Entities ... 22 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 334 Alphabetic Topical Index P1003.0/D13 POSIX OSE Reference Model - R Interfaces ... 24 POSIX OSE Reference Model for RACE ... 315 Command Interfaces ... 174 RARE/COSINE ... 310 POSIX OSE Reference Model ... 20 RDA ... 110, 112-113, 308, POSIX OSE Transaction Processing 315-316 Reference Model ... 187 Real World Considerations ... 187 POSIX SPs In Progress ... 262 Realtime Application Profiles Preliminary Elements ... 282 ... 268 Presentation Management ... 132 Realtime Files ... 63 Prevention of Data Compromise Realtime Metrics ... 55, 57 ... 73 Reconfiguration ... 247 Prevention of Service Denial Redirection ... 36 ... 73 redirection Prevention of Unauthorized Access definition of ... 11 ... 73 Reference Model Entities and Primitive Attributes ... 152 Elements ... 21 Principles ... 279 Reference Model Interfaces ... 24 Print Output and Distribution Reference Model ... 43, 53, 104, Services ... 237 118, 127, 147, 167, 174, 185, process ID ... 69 199, 211, 231, 236 Process Management Services reference model ... 58 definition of ... 11 process Regional Standards ... 50, 70, definition of ... 11 122, 193, 203, 223, 225 Processor Configuration Management regular expression ... 176 ... 240 Related Documents in the POSIX OSE Profile Concepts ... 250 ... 234 Profile Objectives ... 255 Related Service Requirements profile ... 169 definition of ... 11 Related Standards in the POSIX OSE Profiles ... 249 ... 233 programming language API ... 26 Related Standards ... 50, 74, definition of ... 11 114, 124, 142, 163, 171, 181, Prolog ... 45, 48, 50 195, 205, 226, 234, 243 PROLOG ... 48 Relationship Between the OSI protocol (OSI) Reference Model and the POSIX definition of ... 11 OSE Network Reference Model PSE ... 197 ... 81 Public Specifications ... 71, 181 Relationship of ISO and POSIX OSE public specifications Network Reference Models definition of ... 11 ... 83 Purpose of Profiles ... 253 Relationship to Base Standards PVT ... 158 ... 254 Relationships Between This Guide and Profiles ... 251 Remote Data Access (RDA) Protocol ... 112 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Alphabetic Topical Index 335 P1003.0/D13 Remote Procedure Call ... 195 SC4 ... 140-141, 164 Requirements ... 284 SC6 ... 298 Resource Management Services SC7 ... 298 ... 66 scaleability RFC-1034 ... 97 definition of ... 11 RFC-1098 ... 100 SCC ... 301 RFC-1129 ... 97 SC&D ... 236-237 RFC-1194 ... 97 Scope and Number of POSIX SPs RFC ... 83 ... 278 RFT ... 313 Scope ... 1, 43, 53, 77, 104, RG1 ... 319 117, 126, 146, 167, 173, 184, RIG ... 311, 317 198, 210, 230, 235, 249, 273, RJG ... 188, 191, 194, 273, 279 283 Role of POSIX SPs ... 274 Screen Management ... 134 Routing and Relay Services ... 94 SDE ... 197-199 RPC Services ... 90 Security Administration ... 73 RPC ... 88-90, 97, 186, 189, 194, Security Management ... 243 266, 268 Security ... 114, 141, 170 Rules for Drafting and security Presentation of POSIX SPs definition of ... 12 ... 281 Selected Major Standards and Standards-Influencing Bodies ... 292 S Selection Precedence ... 31 Server Connection Management SAA ... 170 ... 135 SAA ... 170 Service Components and Interfaces SAG ... 97 ... 33 SC11 ... 298 Service Delivery Latency ... 55 SC13 ... 298 service delivery latency SC14 ... 298 definition of ... 12 SC15 ... 298 Service Request Latency ... 55 SC17 ... 298 service request latency SC18 ... 140, 165, 299 definition of ... 12 SC1 ... 298 Service Requirements ... 44, 56, SC20 ... 299 86, 107, 119, 130, 151, 167, SC21 ... 113, 185, 194, 233, 299 175, 188, 211, 231, 236 SC22 ... 298-299 Services Provided at the TM/TPRM SC23 ... 298 SII ... 191 SC24 ... 299 Services Provided by the SC25 ... 299 Application Platform at the EEI SC26 ... 299 ... 95 SC27 ... 299 Services Requirements ... 200 SC28 ... 298 session ... 66, 138, 219, 241 SC29 ... 165 _s_e_t_l_o_c_a_l_e() ... 69 SC2 ... 299 SGFS (Special Group on Functional SC47B ... 297 Standardization) ... 299 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 336 Alphabetic Topical Index P1003.0/D13 SGFS ... 253, 299 SQL Standard Database Language SGML ... 121-122, 164 ... 111, 196 Shell and Utilities Standards SQL ... 106, 110-113, 194, 196, Activities ... 179 251, 268, 303, 308, 315-316 shell ... 43, 142, 173-174, 179- SSP ... 230-231 180, 262, 264, 266, 268 Standard for the Exchange of should Product Model Data (STEP) definition of ... 6 ... 122 SII Standard Generalized Markup definition of ... 14 Language (SGML) ... 122 SII ... 12, 14, 34, 185, 187-188, standardized profile 191, 194 definition of ... 12 Simple Network Services ... 90 Standards and Specifications SIRS ... 99 outside the POSIX OSE ... 50 SLA ... 239 Standards and Specifications SMB ... 97 Outside the POSIX OSE ... 123, SMC ... 304 204, 225 SMTP ... 97 Standards Infrastructure SNI ... 84, 86 Description ... 289 SNMP ... 100 standards Software Development Environments definition of ... 12 ... 197 Standards/Specifications Outside Software Development Model the POSIX OSE ... 72, 170, 194 ... 199 Status of System Components Software Development Reference ... 247 Model ... 200 STD ... 234 Software Development Resource STEP ... 121-122, 164 Management Services ... 201 STET ... 315 Software Development Standards Storage/Archiving ... 153 Activities ... 202 Structure of Documentation for Software Documentation ... 203 POSIX SPs ... 279 Software Installation and Subdivision ... 35 Distribution ... 236 Supercomputing ... 265 Software Safety ... 246 Supplementary Elements ... 284 software SVID ... 72 definition of ... 12 SVID ... 67, 72, 75, 179, 181, SPAG: Standards Promotion and 288, 318 Application Group ... 315 System Administration ... 67 SPAG-CCT ... 315 System Internal Interface (SII) SPAG ... 308, 310, 312, 314-315 definition of ... 12 SPARC ... 304 System Operator Services ... 66 SPC ... 304 System Security Services ... 229 Special Rules for POSIX SPs System Services API ... 26 ... 275 definition of ... 13 specification System Services Reference Model definition of ... 12 ... 54 SQL Access Group ... 315 System Services Standards Activities ... 67 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Alphabetic Topical Index 337 P1003.0/D13 System Services ... 53 TFA ... 97 system services Time Services ... 64 definition of ... 12 Title ... 282 system software TM/TPRM ... 185, 187-188, 191- definition of ... 13 192, 194 System V ... 68, 70, 72, 97, 139, TOC ... 1, 5, 15, 39, 207, 249, 179, 181, 288, 313, 316, 318 261, 289, 321 Systems Integration Interface Toolkit Window Services ... 135 Requirements ... 171 TOP ... 259, 308, 311 TPC-A ... 103 TPRM ... 185-186, 194 T TR 10000 ... 253 Traditional Database Model T1 ... 303 ... 105 T.61 ... 223 Training ... 171 TAG ... 304 transaction application program Task Management Services ... 60 definition of ... 13 TBD ... 153, 155, 294, 306, 312, Transaction Manager API ... 185 315-316, 318 Transaction Processing Services TC130 ... 164 ... 183 TC159 ... 140-141 Transaction Processing Standards TC184 ... 164 Activities ... 192 TC22 ... 113, 299 Transaction Processing Standards TC33 ... 204 Language Bindings ... 193 TC47B ... 299 Transaction Processing ... 267 TC83 ... 299 transaction TC86 ... 299 definition of ... 13 TC97 ... 113, 297 Types of Access Methods ... 107 TCOS-SEC ... 278 Types of Data Objects ... 107 TCOS-SSC ... 273, 288 Types of Database Management TCP/IP ... 77, 83-84, 86, 94, 97, Systems ... 107 163, 266, 268 Types of Profiles ... 259 TCP ... 100 TE9 ... 234 Technical Normative Elements U ... 283 Technical Security Objectives UCA ... 308 ... 231 undefined ... 281 terminal ... 13, 61, 68-69, 73, Universe of Profiles and Standards 95, 97, 125-126, 128, 139, 141, ... 274 167-170, 177-179, 184, 189, UNIX International ... 316 192, 195, 234, 242, 287, 298, UNIX ... 46, 68, 174, 179-182, 310 233, 260-262, 265-266, 288, Terminology and General 308, 313, 316-317 Requirements ... 5 Unsatisfied Service Requirements Terminology ... 5 ... 50, 72, 123, 195, 204 terms ... 7 Unsatisfied ... 225 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 338 Alphabetic Topical Index P1003.0/D13 unspecified ... 254 Windowing System Services ... 125 UPE ... 179 WINDOWS-3 ... 225 USA ... 301, 308 User Alliance for Open Systems ... 317 X User Command Interface Services ... 173 X Window System ... 139 User Interface EEI Elements X.12 ... 121-122 ... 80 X.212 ... 287 User Interface Management Systems X.25 ... 94, 97, 287 (UIMS) ... 137 X3 ... 304 user interface ... 125 X.400 API Association ... 317 User Preferences Management X.400 ... 99, 317 ... 135 X.500 ... 86, 97 USI-P001 ... 262 X.509 ... 234 USL ... 316 XIII ... 309 U.S ... 70 XLIB ... 163 USTAR ... 69 X/Open TP ... 195 UUCP ... 182 X/Open ... 75, 318 UUCP ... 94, 100, 181-182 X/Open ... 75, 97, 100, 179, 181, 194-195, 229, 258, 268, 288, 313, 316-319 V X/PEX ... 149 XPG3 ... 75, 181 Validation ... 256 XPG ... 75, 179 validation XTI ... 97 definition of ... 13 XTP ... 97 VDI ... 160 VHDL ... 121, 123 VHSIC ... 121, 123 VMUIF ... 140 W _w_a_i_t() ... 69 WAN ... 95 WG15 ... 299 WG19 ... 140 WG1 ... 233 WG3 ... 113 WG5 ... 140-141, 194 Window Management ... 132 Windowing Reference Model ... 127 Windowing Resource Management Services ... 139 Windowing Standards ... 140 Copyright c 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. Alphabetic Topical Index 339 P1003.0/D13 Acknowledgments We wish to thank the following organizations for donating significant computer, printing, and editing resources to the production of this standard: the X/Open Company, Ltd. Also we wish to thank the organizations employing the members of the Working Group and the Balloting Group for both covering the expenses related to attending and participating in meetings, and donating the time required both in and out of meetings for this effort. _E_d_i_t_o_r'_s _N_o_t_e: _T_h_i_s _l_i_s_t _s_h_o_u_l_d _b_e _t_h_e _u_n_i_o_n _o_f _t_h_e _c_o_m_p_a_n_i_e_s _s_p_o_n_s_o_r_i_n_g _W_o_r_k_i_n_g _G_r_o_u_p _a_t_t_e_n_d_e_e_s _a_n_d _B_a_l_l_o_t_i_n_g _G_r_o_u_p _m_e_m_b_e_r_s. _I_t _w_i_l_l _a_p_p_e_a_r _a_f_t_e_r _b_a_l_l_o_t_i_n_g _b_e_g_i_n_s. <_t_o _b_e _p_r_o_v_i_d_e_d> <_t_o _b_e _p_r_o_v_i_d_e_d> In the preceding list, the organizations marked with an asterisk (*) have hosted 1003 Working Group meetings since the group's inception in 1985, providing useful logistical support for the ongoing work of the committees. 340