Internet Standards

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

/ Internet Standards / CD1.mdf / nist / oiw / agreemnt / 1993 / 01w_9312.txt < prev next >

Wrap

Text File | 1994-02-09 | 157KB | 4,818 lines

Part 1 - WORKSHOP POLICIES AND PROCEDURES Output from the December 1993 Open Systems Environment Implementors' Workshop (OIW) OIW Chairman: Ted Landberg, National Institute of Standards and Technology Workshop Editor: Brenda Gray, NIST Part 1 - Workshop Policies and Procedures December 1993 (Working) Foreword This part of the Working Implementation Agreements was prepared by the Chair of the Open Systems Environment Implementors' Workshop (OIW). Text in this part has been approved by the Plenary of the Workshop. This part replaces the previously existing chapter on this subject. ii Part 1 - Workshop Policies and Procedures December 1993 (Working) Table of Contents Part 1 - General Information . . . . . . . . . . . . . . . . 1 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Workshop Organization . . . . . . . . . . . . . . . 1 1.2 Workshop Cycle Plan . . . . . . . . . . . . . . . . 2 1.3 Workshop Outputs . . . . . . . . . . . . . . . . . . 3 1.4 Implications of Workshop Affiliation And Participation . . . . . . . . . . . . . . . . . . . 5 1.5 Relationship of the Workshop to the NIST Laboratories . . . . . . . . . . . . . . . . . . . . 6 2 Structure and Operation of the Workshop . . . . . . . . . 6 2.1 Workshop Weekly Agenda . . . . . . . . . . . . . . . 6 2.2 Relationship of a Special Interest Group to the Plenary Assembly . . . . . . . . . . . . . . . . . . 8 2.3 Formation of New Special Interest Groups . . . . . . 9 2.4 Liaison Procedures between Special Interest Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5 Technical Liaison Committee (TLC) . . . . . . . . . 10 2.6 Workshop Executive Committee . . . . . . . . . . . . 11 2.7 OSE Technical Committee . . . . . . . . . . . . . . 11 2.8 Liaison of Workshop to other Groups (ANSI, ISO, EWOS, AOW, etc.) . . . . . . . . . . . . . . . . . . 11 3 Plenary Assembly . . . . . . . . . . . . . . . . . . . . 12 3.1 Plenary Meetings . . . . . . . . . . . . . . . . . . 12 3.2 Plenary Chair Responsibilities . . . . . . . . . . . 12 3.3 Plenary Agenda . . . . . . . . . . . . . . . . . . . 13 3.4 Motion Handling . . . . . . . . . . . . . . . . . . 14 3.5 Voting Privilege and Responsibility . . . . . . . . 14 4 Technical Working Groups (SIG) . . . . . . . . . . . . . 16 4.1 Proposal Presentation . . . . . . . . . . . . . . . 16 4.2 Motion Handling . . . . . . . . . . . . . . . . . . 16 4.3 Voting Procedures . . . . . . . . . . . . . . . . . 16 4.4 SIG Chair Responsibilities . . . . . . . . . . . . . 17 4.5 Charter Definition . . . . . . . . . . . . . . . . . 17 4.6 SIG Chair Selection Procedures . . . . . . . . . . . 18 4.7 Other SIG Chair Meeting Procedures . . . . . . . . . 20 4.8 Charters . . . . . . . . . . . . . . . . . . . . . . 20 4.8.1 FTAM SIG . . . . . . . . . . . . . . . . . 21 4.8.2 X.400 (MESSAGE HANDLING SYSTEMS) SIG . . . 22 4.8.3 LOWER LAYER SIG . . . . . . . . . . . . . . 23 4.8.4 OPEN SYSTEMS SECURITY SIG . . . . . . . . . 24 4.8.5 DIRECTORY SERVICES SIG . . . . . . . . . . 25 iii Part 1 - Workshop Policies and Procedures December 1993 (Working) 4.8.6 VIRTUAL TERMINAL SIG . . . . . . . . . . . 27 4.8.7 UPPER LAYERS SIG . . . . . . . . . . . . . 28 4.8.8 NETWORK MANAGEMENT SIG . . . . . . . . . . 29 4.8.9 OFFICE DOCUMENT ARCHITECTURE SIG . . . . . 32 4.8.10 REGISTRATION SIG . . . . . . . . . . . . . 33 4.8.11 TRANSACTION PROCESSING SIG . . . . . . . . 34 4.8.12 MANUFACTURING MESSAGE SPECIFICATION (MMS) SIG . . . . . . . . . . . . . . . . . . . . 34 4.8.13 REMOTE DATABASE ACCESS SIG . . . . . . . . 36 4.8.14 CONFORMANCE TESTING SIG . . . . . . . . . . 38 4.8.15 HEALTHCARE SIG . . . . . . . . . . . . . . 39 4.8.16 OPEN SYSTEMS ENVIRONMENT TECHNICAL COMMITTEE . . . . . . . . . . . . . . . . . 40 4.8.17 CHARTER FOR OIW TECHNICAL LIAISON COMMITTEE (TLC) . . . . . . . . . . . . . . . . . . . 42 4.8.18 MULTIMEDIA DATA AND DOCUMENT INTERCHANGE (MDDI) SIG . . . . . . . . . . . . . . . . 44 4.8.19 INTEGRATED SOFTWARE ENGINEERING ENVIRONMENTS (ISEE) SIG . . . . . . . . . . 45 5 Secretariat . . . . . . . . . . . . . . . . . . . . . . . 46 5.1 Establishing and Changing Workshop Procedures . . . 46 5.2 Workshop Documents . . . . . . . . . . . . . . . . . 46 5.3 Modification of Workshop Agreements . . . . . . . . 47 5.4 Stable Document Maintenance . . . . . . . . . . . . 49 . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.5 Distribution of Workshop Documents . . . . . . . . . 49 5.5.1 Publications . . . . . . . . . . . . . . . 49 5.5.2 SIG Correspondence and Working Documents . 50 5.5.3 Electronic Distribution . . . . . . . . . . 51 5.6 Payment Policy . . . . . . . . . . . . . . . . . . . 57 6 Regional Workshop Coordination . . . . . . . . . . . . . 57 6.1 RWS-CC Charter and Procedures . . . . . . . . . . . 58 6.1.1 Goals . . . . . . . . . . . . . . . . . . . 58 6.1.2 Abbreviations . . . . . . . . . . . . . . . 58 6.1.3 Coordination . . . . . . . . . . . . . . . 58 6.1.4 Coordination at Planning Level . . . . . . 59 6.2 RWS Coordinating Committee . . . . . . . . . . . . . 59 6.3 RWS-CC: Methods of Working . . . . . . . . . . . . . 59 6.4 Coordination at Technical Level . . . . . . . . . . 60 6.5 Implications for RWS . . . . . . . . . . . . . . . . 61 7 Accepting and Processing New Work . . . . . . . . . . . . 65 7.1 Processing User Requests . . . . . . . . . . . . . . 65 7.2 Publicly Available Specifications . . . . . . . . . 67 iv Part 1 - General Information 1 Introduction Part 1 contains the policies and procedures used to run the Workshop. It describes the activities of the major organizational parts of the Workshop, relationships with other regional workshops and standards development organizations and the charters for the technical working groups called SIGs. This part is a living document reflecting the changes needed for a dynamic organization committed to making productive use of the participants time. The changes are shown as lineouts for deleted material and shaded text for additions. 1.1 Workshop Organization In February l983, the National Institute of Standards and Technology (NIST), [formerly the National Bureau of Standards (NBS)], organized a public international workshop at the request of implementors, users and suppliers of Open Systems Interconnection (OSI) protocols. The goal of the OSI Implementors Workshop was originally established by the need for interoperability among multiple vendors' systems. An implementors' workshop on the Open System Environment (OSE) addresses the additional goal of achieving common applications development environments supported on multiple vendors' systems. This goal is consistent with internationally agreed definitions. The workshop provides a technical forum for the timely development of implementation agreements based on emerging international OSE standards or specifications. The Workshop accepts as input the elements of these emerging standards or specifications and produces as output implementation agreements and testing details for these protocols or specifications. In support of the effectiveness of the functions described above, the Workshop will review abstract conformance test suites submitted to the workshop, and amend as appropriate, for the purpose of alignment with the requirements of the Workshop Implementation Agreements. Submission of abstract test suites is encouraged and welcomed. The workshop may also serve as a focal point for sharing information concerning conformance testing of OSI protocols or testing of OSE specifications. 1 Part 1 - Workshop Policies and Procedures December 1993 (Working) 1.2 Workshop Cycle Plan The OSE Implementors' Workshop is administered in a cycle that begins with the yearly scheduling of workshop meetings. Meeting dates are set as early as possible so that the physical meeting facilities can be reserved. Meeting schedules are announced in the U.S. Federal Register. Meetings held at the National Institute of Standards and Technology in Gaithersburg, Maryland usually require reservations one year in advance. The Workshop schedules its meetings to minimize conflicts with ISO, CCITT, ANSI and other events while producing timely agreements in concert with emerging ISO international standards (IS), draft international standards (DIS), CCITT recommendations, and other specification schedules. Preparation for the next Workshop begins as soon as the previous meeting adjourns. The minutes are prepared while the meeting is fresh in the recorder's mind. The Stable Document is edited, checked and submitted for editorial review to the National Institute of Standards and Technology where it is assigned a publication number and printed. The Working Document is edited, checked, and reviewed at NIST. A cover letter is prepared usually with 5 enclosures: a) Delegate material needed before arrival at the next meeting includes hotel accommodation information, maps and so forth; b) "Workshop at a Glance," is the next meeting's weekly schedule. Each SIG chair is contacted to verify meeting day and time schedules. Scheduling conflicts involving overlapping delegate interests, joint SIG meetings and so forth are resolved; c) minutes of the last Plenary Assembly and Wednesday evening Dinner Meeting are prepared; d) Implementation Agreements Documents, if appropriate, are included; e) announcements for the next workshop include the current Workshop Organization Chart; proposals for new business and other relevant material. 2 Part 1 - Workshop Policies and Procedures December 1993 (Working) 1.3 Workshop Outputs The Workshop produces implementation agreements and conformance criteria. The output of the Workshop is a set of several documents to be considered in parallel by an implementor . The first document is entitled "Working Implementation Agreements for an Open Systems Environment" (hereafter referred to as the "Working Document"). This records preliminary agreements and directions developed by the Special Interest Groups and approved by the Workshop Plenary. These Working Agreements are not considered stable enough for use in procurement reference; however, material that is in the Working Document may be used in prototyping and future planning. In general, the Working Document changes after each workshop, as technical work on new and existing topics is progressed. The Working Document is always released in complete form. As individual protocol specifications, public specifications (defined in subclause 2.2) and conformance criteria are completed and become seen as unchanging into the foreseeable future, with no technical changes to any of the work anticipated, the status of the relevant part is altered to stable. Stable text may be used as a basis for product procurement. No more than once per year and at their discretion, NIST will incorporate all stable text into a second document (Special Publication), known as the "Stable Implementation Agreements for an Open Systems Environment" (Hereafter referred to as the "Stable Document".) The text from this document may be used in procurement reference. Even after material is declared technically stable, errors (errata) may occur due to: a) Editorial; b) technical; c) alignment requirements. These errata, along with new stable material, will be collected into supplements to the stable document, with a more rigorous approval process for technical and alignment errata. Technical errata may occur due to: a) Interworking problems discovered through implementor experience; 3 Part 1 - Workshop Policies and Procedures December 1993 (Working) b) any other errors which may necessitate code changes. Alignment errata may occur to comply with evolving base standards, other Regional Workshop Agreements, or Public Domain Specifications. If there is a question as to whether an erratum is editorial or technical, it is considered technical; similarly, if a question arises as to whether an erratum is editorial or alignment, it is considered alignment. Errata may be approved with a specified date of inclusion in future Stable Agreements, and should be justified. Every attempt will be made to disseminate relevant information on applicability of various errata items to previous text, as well as any restrictions on backward compatibility with previous text. It is a goal that current Stable Agreements be backward compatible with previous stable agreements to the maximum extent possible, and that information on errata applicability be provided. Replacement page supplements are issued as necessary after each Workshop. They reflect activity at the previous meeting, and are issued between releases of successive base versions. Those above-referenced supplements will be issued in a loose-leaf "replacement page" form, such that these new pages reflecting errata may be inserted in place of appropriate pages in the Stable Document. The changes on these replacement pages will be clearly marked and dated. Thus an implementor gets a "current" picture of the status of Stable Agreements. After material is declared technically stable, no further changes to that text may occur except for correction of necessary errata. Published errata apply to the previous versions and editions of stable material as described in appropriate "Errata" text for each subject. The same is true for backward compatibility issues. Succeeding publications of the Stable Document are given version numbers, and supersede previous versions. At the discretion of NIST, editions may be issued if a sufficient number of replacement pages have accumulated within a Stable Document version. An implementor may need to study Stable and Working documents together . They have a common index; material is not duplicated but cross-referenced. It is recommended that released products conform to a specified level of a Stable Document. The Stable Document is published by the National Institute of Standards and Technology and is available for sale by the National Technical Information Service (NIST), the US Government Printing Office (GPO), and the IEEE Computer Society. The Draft Working Document is available to attendees at the Workshop. In 4 Part 1 - Workshop Policies and Procedures December 1993 (Working) addition, Stable Documentation and Working Documentation are both available on-line. Copies of the Stable Document are sent to libraries and repositories throughout the world. Tutorial text in Workshop Agreements is strongly discouraged; in exceptional instances where it must be present, it should be clearly identified with expiration date included. Recent Workshop documentation is being provided in a style consistent with latest ISO/IEC objectives. Whenever, possible, meeting announcements and other pertinent Workshop information are made available via electronic means. It is a Workshop goal to transact its business using electronic mail to the maximum extent permissible. 1.4 Implications of Workshop Affiliation And Participation The Workshops are held for those organizations expressing interest in implementing or procuring OSE protocols and open systems. Participation is open to all directly and materially affected interest. There are two general categories of participants: Implementors and Users. Other participation may include observers, liaisons, ex-officio persons, and invited guests. All individuals may participate in the working and ad-hoc groups. The OIW is open to the press. Only the Executive Steering Committee members can speak officially for the Workshop. Users are encouraged to participate in the activities of the Workshop and to champion their functional requirements in implementation agreements developed by the technical working groups. There is no formal commitment on the part of vendors and users participating in the Workshop to implement or use the Agreements reached at Workshop meetings. However, those who have no intention of using the agreements should consider themselves "observers," and should comply with any requirements for "observers" given in this document. Conformance to Workshop Agreements means conformance (Agreement) with a specified version (plus level of updates) of Stable Agreements. This refers to the previously and currently published documentation. Implementors should consult procurement documentation to understand precisely what level of stable functionality to reference; however, implementors are encouraged to reference the most recently available Stable functionality. The implementation specifications from the "Stable Implementation Agreements for Open System Interconnection Protocols" are 5 Part 1 - Workshop Policies and Procedures December 1993 (Working) referenced in Federal Information Processing Standard 146, "Government OSI Profile (GOSIP)." 1.5 Relationship of the Workshop to the NIST Laboratories As resources permit, NIST, with voluntary assistance from industry, develops formal protocol specifications, reference implementations, tests and test systems for the protocols agreed to in the Workshops. This is work made available to the industry volunteers and to others making valid commitments to organized events and activities such as NCC, AUTOFACT, and OSINET. As soon as this work can be adequately documented, it is placed in the public domain through submission to the National Technical Information Service. Any organization may then obtain the work at nominal charge. The NIST laboratories bear no other relationship to the Workshop. 2 Structure and Operation of the Workshop The business of Workshop should be conducted informally and cooperatively, since there are no corresponding formal commitments within the Workshop by participants to implement the decisions reached. The chart below depicts the Workshop organization and relationships of the major components. Those components are: (1) the Plenary; (2) three standing committees, OSE-TC, TLC, and Executive; and (3) Technical Working Groups, called SIGs . 2.1 Workshop Weekly Agenda The Workshop meets on a weekly schedule organized as illustrated in figure 1 below: 6 Part 1 - Workshop Policies and Procedures December 1993 (Working) MONDAY TUESDAY WEDNESDA THURSDAY FRIDAY Y AM SIG SIG SIG SIG PM SIG SIG SIG SIG TLC EC PLENARY Plenary Plenary DINNER (OSE TC) (OSE TC) (OSE TC) Figure 1 - Workshop Week at a Glance 7 Part 1 - Workshop Policies and Procedures December 1993 (Working) NOTE - Voting Plenary will be Thursday evening or Friday morning. Special Interest Groups and Technical Committees meet Monday through Thursday to develop appropriate draft text for the implementation agreements documents. The SIGs usually do not meet every day, but schedule meetings as needed. Individual SIG schedules are provided with delegate registration materials. Workshop delegates meet Wednesday evening for dinner to conduct Workshop Plenary business that does not require voting. Liaison reports, proposals for new Special Interest Groups and other discussions of interest are encouraged at the dinner meeting. The Voting Plenary Assembly conducts the voting business of the OSE Implementors' Workshop. Old business and new business motions are brought to the floor for Plenary consideration. SIG Chairs control the detailed agendas for their particular meetings. Each SIG Chair is required: a) to hold a SIG meeting during the week; b) to attend the whole of the Executive Committee meeting; c) to attend the Plenary and give a report of activities. 2.2 Relationship of a Special Interest Group to the Plenary Assembly The SIGs meet independently during the Workshop; they may also hold interim meetings between Workshops. As technical work is completed by a SIG, the work is presented to the Plenary for consideration. Companies participating in a SIG are expected to participate in the Plenary. Voting rules for SIGs are as described above. The SIGs propose their charters and work programs to, and receive instructions for their technical program of work from the Plenary Assembly. 8 Part 1 - Workshop Policies and Procedures December 1993 (Working) 2.3 Formation of New Special Interest Groups Special Interest Groups are formed at the pleasure of the Plenary Assembly. A proposal to establish a new SIG is made at the Wednesday evening dinner meeting and may be brought to a vote at the Friday Plenary session. Proposals for new SIGs should address the following topics: a) Demonstrate the timely need for implementation agreements; b) identify: 1) existence of Requirements as submitted to the Workshop by User Organizations; 2) relevant ISO, CCITT, ANSI or other organizations; 3) vendor interest in participating; 4) a relevant interest group (constituency); c) explain the OSE context of work; d) identify a path towards stability of appropriate base standards, or Public specifications; e) include a draft charter, statement of goals and plans for reaching implementation agreements. Proposals for new SIGs should be submitted to the Secretariat for distribution to participants prior to the Workshop. This will allow everyone to review material and impact submitter with questions. At this point the draft charter may be modified, with the consent of the presenter, and enhancements and/or modifications to the original proposal may be presented. Materials relating to SIG formation will be made available to participants at the Voting Plenary when the actual vote takes place. 9 Part 1 - Workshop Policies and Procedures December 1993 (Working) 2.4 Liaison Procedures between Special Interest Groups Following are procedures for cooperative work among Special Interest Groups. a) Any SIG (SIG 1) or individual having issues to discuss with or requirements of another SIG should bring the matter to the attention of the chair of that SIG (SIG 2); b) The SIG 2 Chair should bring the matter before SIG 2 for action; c) SIG 2 should respond to the concerns or needs of SIG 1 or the individual in a timely manner; d) If the matter cannot be satisfactorily resolved or if the request is outside the charter assigned to SIG 1, then it should be brought before the Technical Liaison Committee, or if a workshop administrative matter, before the Executive Committee; e) SIGs are expected to complete work in a timely manner and bring the results before the Plenary for disposition. However, the Plenary may elect to act on any issue within the scope of the Workshop at any time. 2.5 Technical Liaison Committee (TLC) A Technical Liaison Committee (TLC) has been formed to address the general technical and architectural requirements of the OSE Implementation Agreements.The responsibilities assigned to TLC include reaching Implementors' Agreements on OSE related matters that are not covered by existing SIG charter and/or may concern more than one SIG. Representation in the TLC is comprised of the SIG Chairs and/or two (2) assigned technical experts. Each SIG is encouraged to be represented at this meeting; those SIGs not in attendance will be noted. The Chair of this group is assigned per SIG Chair selection procedures (see 4.6). The TLC meets one day per Workshop week, if necessary, and reports to the Executive Committee if it has met. A report is also made to the Plenary on its work and progress. The voting rules of the TLC are subject to consensus approval of SIG representatives. Each SIG casts a single vote. Additionally, text created by TLC is subject to prevailing voting 10 Part 1 - Workshop Policies and Procedures December 1993 (Working) rules of the Workshop Plenary. 2.6 Workshop Executive Committee The Workshop Executive Committee, which meets Tuesday afternoon of the Workshop week, is charged with making decisions affecting the overall interests of the Workshop. Each SIG Chair is required to attend this meeting, which is run by the Workshop Chair. Matters considered by this group may involve technical and administrative direction of the Workshop. Agreement is reached by consensus of all participants. Guests may be invited at the discretion of the Workshop Chair. Occasionally presentations may be made to increase the information available to the meeting participants. SIG Chairs may provide inputs for discussion. The Executive Committee Meeting attendance is restricted to SIG Chairs, Workshop Administration, and invited guests. 2.7 OSE Technical Committee The Open Systems Environment Technical Committee in response to user requirements considers the scope and framework of an OSE; provides a meeting ground to generate interest in open system environment specifications; and allows for technical recommendations via the Technical Liaison Committee of what new work items might be needed in existing Special Interest Groups or new SIGs required to address new work items. Administratively and logistically the OSE Technical Committee will operate as a SIG. However, the purpose of the OSE Technical Committee is different from that of SIGs in that the focus of the OSE Technical Committee is not necessarily to reach Implementation Agreements. 2.8 Liaison of Workshop to other Groups (ANSI, ISO, EWOS, AOW, etc.) Special Interest Groups sometimes correspond with organizations performing related work, such as ANSI committees. Such correspondence is approved by the Plenary before sent to committees, such as ANSC X3S3. The Plenary assembly reserves the right to veto correspondence using normal voting rules. External liaisons, if approved for a SIG's charter, may be sent without explicit Plenary approval unless there is an objection; other liaisons may require explicit approval, and should be noted as being outside of a SIG's charter. SIG chairs are responsible for 11 Part 1 - Workshop Policies and Procedures December 1993 (Working) sending approved liaisons and for providing OIW Chair with final copies. 3 Plenary Assembly The workshop Plenary is composed of voting representatives from participating U.S. Corporations and Governmental Agencies. The Workshop develops internationally recognized and harmonized Function Profiles. As with all public standards development organizations, it uses a voting process to achieve consensus of the work presented by the technical working groups who represent a group of interested parties to the implementation agreements. 3.1 Plenary Meetings The Plenary meets twice during workshop week, after the Plenary Dinner where groups petition to form new SIGs and technical proposals are presented related by interested groups, and on friday, where consensus votes are taken Implementation Agreements and liaison statements to external organizations. The OSE Implementors' Workshop Plenary Assembly is called to order by the Workshop Chair at the end of the Workshop week. In the event of the chair's absence, the TLC Chair will preside over the voting Plenary meeting. 3.2 Plenary Chair Responsibilities The Chair has the following general duties: to open the session at the scheduled time by calling the assembly to order; to announce the business before the assembly and review the agenda; to put to vote all questions which arise in the course of the proceedings; to make appropriate announcements; and, to conduct other business as appropriate or needed. The order of business before the Plenary is planned with the Executive Committee. The Chair has the following specific duties: a) To maintain an accurate record of the OSE Implementors' Workshop Agreements; b) to appoint a Workshop Recorder; c) to identify the need for, and to encourage the formation of new relevant SIGs; 12 Part 1 - Workshop Policies and Procedures December 1993 (Working) d) to encourage SIG Chairs to develop an organization including a Vice Chair and a Secretary; e) to approve the appointment of the SIGs officers; f) to report on current SIG charters, work items, and recent accomplishments; g) to identify the completion of a SIG's work, and to encourage that SIG to disband when its goals are accomplished; h) to preside over the Executive Committee which attends to all administrative matters associated with the Workshop; i) to encourage SIG chairs to harmonize their agreements with other groups; j) to preside over the Workshop Plenary meetings. 3.3 Plenary Agenda The agenda usually includes: a) Introductory remarks and announcements; b) approval of the previous meeting minutes; c) old Business; d) new Business; e) SIG Chair Reports. Each SIG chair report reflects the business (requiring a Plenary vote) conducted by the SIG during all interim SIG meetings and meetings during the Workshop week. SIG Chairs are required to use this agenda time to introduce motions that reflect consensus reached in their meetings. Non-voting descriptive material is distributed to attendees outside of the main Plenary assembly. 13 Part 1 - Workshop Policies and Procedures December 1993 (Working) 3.4 Motion Handling All motions brought to the Plenary Assembly are recorded by the secretary along with the tallied vote including yes, no and abstain. Motions are automatically "seconded" if brought by SIG vote before Plenary. Motions representing consensus within a SIG are brought to the Plenary floor by the SIG's Chair. Before the Plenary entertains the motion, the SIG's vote on the motion is reviewed. This review provides the Plenary with the measure of consensus reached within the SIG. The Workshop Chair may challenge the vote of a SIG. The SIG vote must be recorded on all motions brought before the Plenary. A standard template is used for the SIGs to prepare their reports. SIG Chair reports should be brief and contain only voting material. Motions should be divided by document to be modified (if appropriate) and by type of change. Non-contentions issues should be "bundled" together as much as possible when a vote is requested. 3.5 Voting Privilege and Responsibility The pleasure of the Plenary is determined by voting privileges granted to the workshop delegates. Order is maintained through an interpretation of "Robert's Rules of Order,"... while it is important to every person in a free country to know something of parliamentary law, this knowledge should be used only to help, not to hinder business. One who is constantly raising points of order and insisting upon a strict observance of every rule in a peaceable assembly in which most of the members are ... [unfamiliar with] these rules and customs, makes himself a nuisance, hinders business, and prejudices people against parliamentary law. Such a person ... either ... [does not understand] its real purpose or else wilfully misuses his knowledge." Plenary voting privileges are: a) One vote per company; b) only companies that regularly attend vote; c) only companies that plan to sell, buy, test, certify, or register protocols or data stream formats vote on its implementation decisions; 14 Part 1 - Workshop Policies and Procedures December 1993 (Working) d) only companies knowledgeable of the issues vote; e) proxy votes are not admissible. A motion carries if and only if at least 2/3 of the total yes, no and abstain votes are yes.1 There is a special set of voting rules for alignment and technical changes to the Stable Document only, and applies to the first attempt at these changes. These rules are as follows: a) A unanimous vote (Y=100%, N=0, A=0) is required for passage; b) if (A>0 or N>0 or both) but Y> = 2/3 majority, then the proposal is tabled for one Workshop period (NOTE: At the next Plenary the motion is untabled, and resolved by at least 2/3 majority vote); c) if Y< 2/3 majority then the proposal will fail, and may be brought up again at the next Plenary as a completely new proposal; d) in the case of one or more negative votes as described in (b) above, the full explanation of each negative vote should be minuted. Representatives should use these special rules to give proposed errata items a proper time for consideration. Again, only items that are truly errata should be brought forth as changes to stable text. Any proposal that causes change to stable text in such a way as to change Implementations should be subject to these special rules. SIGs should maintain levels of functionality of agreements for as long as is appropriate, to satisfy user requirements. 1 These voting rules were created to provide knowledgeable voters an opportunity to abstain creating an equivalent negative vote. The abstaining delegate, after due consideration, indicates reluctance to reach consensus on an implementation agreement; the abstention, in effect, calls for further consideration of the issue. On the other hand, the rule suggests that delegates lacking concern for implementation detail or lacking knowledge of the issue might avoid the vote all together. 15 Part 1 - Workshop Policies and Procedures December 1993 (Working) The order of Plenary business is determined by the Workshop Chair. Voting privileges for SIGs are the same as general Plenary voting privileges, except that in order for a motion to pass, the total number of yes votes must be substantially more than the "no plus abstention" votes. Any exceptions or special interpretations of the above must be submitted to the Executive Committee for approval. Any Workshop participant with a question in this regard may bring the matter to the attention of the Workshop Chair, who will then notify the Executive Committee. It is suggested that a minimum requirement for "regular attendance" is for the company to have attended one of the previous three meetings. The SIG Chair will determine satisfaction of the "substantial" requirement. 4 Technical Working Groups (SIG) The SIG Chair is responsible for reaching the goals stated in the charter of the SIG. The business of the SIG is conducted in public meetings that generally follow the procedures of the Plenary Assembly. There is no minimum quorum requirement for a SIG. 4.1 Proposal Presentation Delegates are assured SIG agenda time to present proposals consistent with the goals and objectives outlined in the SIG's charter. 4.2 Motion Handling The business of the SIG is conducted by the SIG Chair. The Chair is encouraged to use"Robert's Rules of Order" in handling motions brought to the SIG's attention. 4.3 Voting Procedures Voting procedures used in the SIG are the same as those used in the Plenary, except for the special errata rules. The SIG Chair interprets the eligibility of each delegate following the guidelines in 4.2 "Voting Privilege and Responsibility." 16 Part 1 - Workshop Policies and Procedures December 1993 (Working) 4.4 SIG Chair Responsibilities Each SIG Chair is responsible for the activities of the special interest group. The Chair ensures that the charter of the group is upheld and that opportunities are exploited to reach consensus and make progress toward attaining implementation agreements. The Chair is obligated to work within the scope of the SIG's charter and to reach the SIG's stated goals in a timely manner. To accomplish this, the SIG Chair shall hold at least one meeting during the scheduled Workshop week except in unusual circumstances (upon prior notification to Workshop Chairman). The Chair is encouraged to hold interim meetings at any convenient time and place between Workshop weeks, provided there is adequate technical work to justify such meetings. Every attempt to publicize interim meetings should be made through mailing lists, phone calls and other means. Interim meetings may be held anywhere in the world. Representatives of other similar regional workshops are encouraged to attend these meetings. Each SIG Chair is responsible for attending the Executive Committee Meeting held during the Workshop week. The SIG Chair is also responsible for attending the Plenary Assembly and reporting on the activities of the SIG. The SIG Chair is encouraged to appoint a vice chair, secretary, and other officers as appropriate. The Workshop Chair accepts or rejects these appointees by the SIG Chair. It is expected that SIG Chairs will be available (by telephone or otherwise) to the Chairs constituency and to prospective attendees. SIG Chairs keep SIG document lists and SIG member lists, and determine the agenda of every SIG meeting. If the SIG Chair is unable to carry out assigned duties, the vice chair shall do so; if the vice chair is unable to serve, the secretary shall carry out this function, and so on. 4.5 Charter Definition All SIG Charters shall have the following generalized form: a) Scope; b) objectives (specific); c) high-priority work items; d) low-priority work items. 17 Part 1 - Workshop Policies and Procedures December 1993 (Working) Every Workshop SIG will have this charter form. All SIGs are responsible for keeping their charters current. Charters should be reviewed (and revised as necessary) twice a year. Charters should describe the activities of a SIG. 4.6 SIG Chair Selection Procedures a) As soon as a vacancy is determined, the OIW Chair should: 1) Accept nominees or volunteers; 2) evaluate them in reference to the qualifications listed below 3) present the qualified candidates to the Plenary for approval at the end of the Workshop week; b) SIG Chair qualifications are: 1) Knowledge of Parliamentary Procedure; 2) management experience; 3) organizational skills; 4) technical knowledge of the subject area; 5) professional credentials; 6) regular Workshop attendance (for existing SIGs); c) All applicants will submit to the OIW Chair a commitment letter of support from the applicant's corporate sponsor; d) All qualified candidates shall be announced by the OIW chair at the Wednesday evening dinner prior to their submission at the Voting Plenary. This is the only procedure in the selection process; e) If there is only one candidate, Plenary voting will be by acclamation. If more than one candidate is submitted, voting will be as given below: 1) The candidate with the largest number of "Yes" votes will win. Nominees will be excused during the voting. No demonstrations or "campaign speeches" will be allowed at the Plenary by candidates. 18 Part 1 - Workshop Policies and Procedures December 1993 (Working) Alternatively, for one candidate, voting may be by simple majority, but "acclamation" should be tried first; f) When selected, new Chairs shall serve for a one-year term, effective from the date of selection. A SIG Chair may not resign during this period, except in extraordinary circumstances; g) A SIG chair may be removed by the Executive Committee, due to illness or substandard performance. In order for this to happen, 2/3 of regular SIG attendees, or OIW Chair must submit a written request to OIW Executive Committee; h) The Executive Committee will make a determination; the OIW Chair has overall final authority in this matter; i) For existing chair positions, a list of candidates will be complied one year after the first meeting of the current SIG Chair, and the election process will proceed as described above; j) If a SIG Chair is temporarily unable to perform duties, the vice chair shall preside and conduct scheduled SIG meetings. In the absence of a vice chair, the Secretary shall fulfill this requirement; k) At no time shall a Vice Chair assume De Facto SIG Chairmanship without prior approval as described above; l) A SIG Chair may be elected (re-elected) to no more than three consecutive one-year terms; m) For new SIGs, until this process can be instituted, Acting Chairs will be assigned by NIST; n) Under exceptional circumstances, to be discussed at the Executive Committee Meeting, SIG Chair elections may be by secret ballot, or there may be opportunity for discussion by candidates at the Wednesday dinner meeting prior to voting (The OIW Chair has final authority in these matters). 19 Part 1 - Workshop Policies and Procedures December 1993 (Working) 4.7 Other SIG Chair Meeting Procedures The following is strongly recommended: a) The agenda for a SIG meeting should be prepared by the SIG chair taking into account suggestions by the SIG members and should be circulated to all members about a month before each meeting; b) any proposed changes to the Agreements should be clearly identified in the agenda distributed about a month prior to the meeting. The details of such proposals should be circulated with the agenda; c) at the opening of a SIG meeting the agenda should be subject to modification and should be formally approved, as is customary. However, any new proposed changes to the Agreements that are first introduced at the opening of the meeting (i.e., not circulated prior to the meeting with the agenda) should be included in the agenda for discussion and should subsequently be minuted, but should not be voted on during the meeting; d) once a SIG's agenda is approved, priority during the SIG meeting must be given to the items on the agenda, and changes should be limited to re-ordering to accommodate schedules. If it is foreseen that the agenda may need to be modified again subsequent to the opening of the meeting (e.g., to accommodate the scheduling of joint SIG meetings) then this activity should be specifically scheduled, perhaps at the end of the first day of a SIG meeting; e) voting in a SIG should be limited to companies who have been present for at least one of the previous three SIG meetings; f) SIG Chairs should make their room assignments on the last day of the Workshop week for the next workshop. 4.8 Charters Within the Workshop there are Special Interest Groups (SIGs). The SIGs receive their instructions for their technical program of work from the plenary. The SIGs meet independently, usually during the Workshop. As technical work is completed by a SIG, it is presented to the plenary for disposition. Companies participating in a SIG are expected to participate in the plenary. Voting rules for SIGS are as described in the 20 Part 1 - Workshop Policies and Procedures December 1993 (Working) Procedures Manual, section 5.3. Special Interest Groups sometimes correspond with organizations performing related work, such as ANSI committees. Such correspondence should be sent through the plenary to the parent committee, such as ANSI X3T5 or ANSI X3S3. When SIG meetings take place between Workshops, the correspondence from these meetings should be made known to the Workshop plenary. The procedures for cooperative work among Special Interest Groups are given in section 2.6 of the Procedures Manual. Following are the charters of the Special Interest Groups. NOTE - The charters of the Directory Services, Lower Layers, Network Management, Upper Layers, Transaction Processing, and Conformance Testing Special Interest Groups do not follow the format recommended in the Procedures Manual. 4.8.1 FTAM SIG The charter is given as follows: a) Scope: 1) to develop stable FTAM Agreements between vendors and users for the implementation of interoperable products; 2) in particular to maintain the FTAM Phase 2 and Phase 3 specifications with respect to experiences from implementations and from testing. It is a goal that FTAM Phase 3 will remain backward compatible with FTAM Phase 2; 3) to act as Registration Authority for OIW FTAM objects; 4) to define further FTAM functionality; 5) to conduct liaison with standardization bodies such as ISO SC 21 and ANSI X3T5.5; 6) to conduct liaison with and contribute to other bodies working on FTAM harmonization such as the Regional Workshops (EWOS, AOW) and the ISO SGFS to define Functional Standards; 21 Part 1 - Workshop Policies and Procedures December 1993 (Working) 7) to conduct liaison with vendor/user groups such as COS, MAP, TOP, and SPAG; b) High priority work items: 1) Maintain FTAM Phase 2 and Phase 3 Agreements; 2) Maintain OIW FTAM object register; 3) Contribute to development of FTAM ISPs; 4) Specify use of general Character Set Agreements; 5) Specify requirements of FTAM to a Directory Service; 6) Specify use of Filestore Management functions; 7) Specify use of "run-length" compression; c) Low priority work items: 1) Specify use of Security functions; 2) Specify use of Overlapped Access; 3) Specify use of ODA documents over FTAM; 4) Specify use of EDI documents over FTAM; 5) Specify use of Advanced Adaptive Compression Algorithm(s). 4.8.2 X.400 (MESSAGE HANDLING SYSTEMS) SIG The charter is given as follows: a) Scope of Work: 1) To develop Stable MHS Agreements among Vendors and Users for the implementation of interoperable products; 2) To conduct Liaison with Standardization Bodies, such as X3V1 as ANSI TAG to ISO/IEC JTC1 SC18, U. S. CCITT Study Group D for input to Study Group VII/Q18, and U. S. CCITT Study Group A for input to Study Group I; 22 Part 1 - Workshop Policies and Procedures December 1993 (Working) 3) To Actively work with other Regional Bodies, primarily (EWOS, AOW) but including others, to define International Standardized Profiles (ISPs) for CCITT X.400 MHS, and ISO/IEC MOTIS; 4) To Review Abstract Tests for X.400 and MOTIS and provide feedback to appropriate bodies; b) Current Work Items: 1) MHS use of X.500 Directory; 2) Body Parts / Content Types; 3) MHS Security Issues; 4) Access Units; 5) MHS Registration Issues; 6) Maintain 1984 MHS Stable Agreements; 7) Contribute to development of MHS ISPs; 8) MHS routing; c) Future Work Items for Next Year: 1) EDI over X.400 and MOTIS; 2) Distribution Lists over X.400 and MOTIS; 3) EDI Messaging; 4) MHS Management; 5) Character Sets and other Internationalization Considerations. 4.8.3 LOWER LAYER SIG The Lower Layer SIG will study OSI layers 1-4 and produce recommendations for implementations to support the projects undertaken by the workshop and the work of the other SIGs. Both connectionless and connection-oriented modes of operation will be studied. The SIG will accept direction from the plenary for work undertaken and the priority which it is assigned. 23 Part 1 - Workshop Policies and Procedures December 1993 (Working) The objectives of the Lower Layer SIG are: a) Study OSI layers 1-4 as directed by the plenary - such study is to include management objects, security, ISDN user- network interfaces for use in conjunction with OSI network services, routing exchange protocols, etc.; b) Produce and maintain recommendations for implementation of these layers; c) Where necessary, provide input to the relevant standards bodies concerning layers 1-4, in the proper manner; d) Review base standard abstract test suites with the goal of identifying the test cases required for the layer 1-4 Implementation Agreements. Develop test cases for Implementation Agreement functionality not present in the base standard (if any). 4.8.4 OPEN SYSTEMS SECURITY SIG The charter is as follows: a) Scope: 1) To study the requirements for security in Open Systems (OS), and where appropriate develop OS Security Implementation Agreements with regards to the applicable standards. To advise and support other SIGs on their inclusion of relevant security services and mechanisms in their implementation agreements. When necessary, provide input in the proper manner to the appropriate standards activities. To coordinate with other regional bodies to harmonize the inclusion of security services and mechanisms into International Standardized Profiles. b) Objectives: 1) To define security architectures and implementation profiles based on open systems security standards, including OSI security protocols, cryptographic algorithms and related key management systems. To actively work with other regional bodies to harmonize the inclusion of security services and mechanisms into International Standardized Profiles (ISPs). c) Standing Work Items: 24 Part 1 - Workshop Policies and Procedures December 1993 (Working) 1) Algorithm and Security Information Object Registration/Publication; 2) Register Security Algorithms, attributes and other objects as required/requested and list algorithms/objects registered by other authorities; 3) TP Security: a) Assist TP SIG in identifying security requirements, services and mechanisms for TP; 4) Labels: a) Define a Standard Security Label (SSL) Label Set for use at the Network level; 5) GULS: a) Liaison with other SIGs (e.g., TP, DIR) to develop Security Exchanges (SEs) and Security Transactions (STs) for use by these applications. Identify common SEs and STs. Register SEs and STs; 6) OIW Security Activity Matrix and Guideline: a) Develop a matrix and supporting guideline which describes the security and security-relevant activity for the OIW; 7) OSE Security Model (OSM): a) Develop in cooperation with other bodies a reference model of open systems security. In particular, to meet the security requirements of OIW SIGs who address security and/or security- related requirements in their LAs. 4.8.5 DIRECTORY SERVICES SIG The charter of the Directory Services SIG is described in this section. a) Scope: 1) To advance interoperability of Directory Services in an Open Systems Environment through the use of OSI 25 Part 1 - Workshop Policies and Procedures December 1993 (Working) Directory Services technology; b) Objectives: 1) Functional profiling resulting in technical agreements among Directory Services implementors; 2) Promoting interworking of OSI Directory Services with other directory systems, resulting in technical agreements among Directory Services implementors; 3) Consultation with other OIW SIGs and related groups on the use of Directory Services and definition of Directory objects; 4) Alignment with profiles and output of related groups, where appropriate, including that of Directory groups of other Regional Workshops (RWS); 5) Support of conformance and interoperability test activities; 6) Development of recommended procedures for administration and management of the Directory in an environment based on OSI Directory Services Technology; c) Current work items are as follows: 1) Continuing a leadership role in the development of International Standardized Profiles (ISPs) for Directory Services, specifically those for distributed operations, authentication, and 1993 extensions to OSI Directory functionality; 2) Contributing to and advising on current standards work underway in ISO/IEC/ITU regarding management of the Directory; 3) Proposing mechanisms for interworking, migration, coexistence, and synchronization of directory information between the OSI Directory and other systems and promoting alignment of these mechanisms with the work of related groups; 4) Revision and review of OSI Directory Services interoperability and conformance test suites. 26 Part 1 - Workshop Policies and Procedures December 1993 (Working) 4.8.6 VIRTUAL TERMINAL SIG The charter is as follows: a) Scope: 1) To develop agreements concerning implementation and testing of Virtual Terminal systems based on ISO 9040/9041 and their addenda. To monitor the X-window system and potentially develop implementors agreements for OSI compatibility; b) Objectives: 1) Develop VTE-profiles to support diverse interactive applications and environments; 2) Develop Control Objects which may be referenced and used within VTE-profiles; 3) Register and maintain OIW VT objects; 4) Conduct liaison with standards organizations, other regional workshops and vendor/user groups as necessary; 5) Review and, if necessary, generate abstract test cases for VTE-profiles; 6) Harmonize OIW VTE-profiles with those from other regional workshops; 7) Adopt ISP format for OIW VTE-profiles under development; 8) Migrate existing OIW VTE-Profiles to ISP format; 9) Develop X-OSI Implementors' Agreement, if necessary; 10) Register and Maintain OIW X-OSI Objects, if necessary; 11) Review and, if necessary, generate abstract test cases for X-windows; c) High Priority Work Items: 1) Maintain stabilized OIW VTE-profiles and Control Objects; 27 Part 1 - Workshop Policies and Procedures December 1993 (Working) 2) Develop fully general TELNET profile in ISP format; 3) Contribute toward the development of ISP parts for the Forms and Paged Profiles; 4) Develop interoperability test cases for the Generalized Telnet Profile. d) Low Priority Work Items: 1) Develop abstract test cases; 2) Migrate stable profiles to ISP format - X.3, Transparent; 4.8.7 UPPER LAYERS SIG The charter is as follows: a) Scope: 1) To develop common implementors agreements, which include both connection-oriented and connectionless modes, for non-application specific protocol stacks including Session, Presentation, ACSE, ROSE, and RTSE layer protocols, standards and recommendations which are compatible with the OSI Reference Model The Upper Layers SIG is the focal point for the resolution of all Upper Layers issues; 2) To develop common implementors agreements for the development of non-application specific APIs which address the encoding and decoding of the aforementioned protocols, standards, and recommendations; 3) To develop interface agreements to application specific APIs; 4) To coordinate work efforts with other regional workshop groups, standards bodies and industry consortia who are also developing implementors agreements and ISPs; 5) To make contributions to standards bodies which are developing these protocols, standards, recommendations and APIs; b) Objectives: 28 Part 1 - Workshop Policies and Procedures December 1993 (Working) 1) To approve the Common Upper Layer Requirements (CULR) specification produced by EWOS and to adopt it as part of our implementation agreements; 2) To develop implementors agreements for a minimum subset of functional requirements needed to perform basic data communications over a connection-oriented OSI protocol stack; 3) To develop implementors agreements for an API which encodes and decodes the functions of the "Skinny Stack;" 4) To develop implementors agreements for a minimum subset of functional requirements needed to perform basic communications over a connectionless OSI protocol stack; 5) To develop implementors agreements for the interface between the "Skinny Stack" API and application-specific APIs; 6) To harmonize all implementors agreements with similar special interest groups in EWOS and AOW; c) Priority of Work Items: 1) The priorities of the work items are the same as the order in which they are listed in the objectives section of this charter. 4.8.8 NETWORK MANAGEMENT SIG The OIW NMSIG may: a) Develop product level specifications and international Profiles for implementations, relating to common services/protocols for exchanging management information between OSI nodes; b) Develop product level specifications and associated international Profiles for implementations relating to systems management functions; c) Define, encourage and promote the development of requirements for new Managed Objects (MOs), MO Profiles and MO Ensembles (bundles of Profiles). As required, collect and/or disseminate this information to appropriate bodies in 29 Part 1 - Workshop Policies and Procedures December 1993 (Working) which it is expected that formal definition and registration of such management information can occur; d) Support and/or lead the development of definitions for new MOs, MO implementation agreements, MO Profiles and MO Ensembles; e) Support the cataloguing of new MOs, MO Profiles and MO Ensembles. f) Review and, possibly, develop profiles for implementations of application programming interfaces (APIs) for systems management functions and protocols. As necessary, the SIG will: a) Establish liaisons with various standards bodies and consortia; b) Provide feedback for additional/enhanced services and protocols for OSI management. Examples of Specific Activities: a) Requirements Definition Work: 1) Work with other OIW SIGs (potentially via TLC) and with EWOS & AOW NM groups to develop concepts/guidelines for developing internationally harmonized MO Profiles and MO Ensembles: Example: TAX 3 MO Profile Guidelines; 2) Actively solicit contributions that delineate new requirements for new MOs, MO Profiles, MO Ensembles, e.g., via letters to NMSIG membership, NMForum UAC, Open Systems User Alliance (Houston 30/Dallas 800), OIW membership, press releases, CBD announcements, ... Example: X.400 MTA contribution (NMSIG-92/178, -92/179) FAA Enterprise OA&M contribution (NMSIG-92/113); 3) Promote need to develop requirements for new MOs, Profiles, Ensembles, e.g., via OIW banquet presentations; b) MO, Profile, Ensemble Definition Activities: 30 Part 1 - Workshop Policies and Procedures December 1993 (Working) 1) On an as-interested basis (e.g., in response to requirements identified in example 1), the NMSIG may: a) Develop MO, Profile, and/or Ensemble definitions, when no relevant standards or consortia activities exist; Example: FAA Enterprise Management Information; b) Collaborate with other OIW SIGs, or consortia, to provide MO definition contributions to standards, or consortia, to accelerate progress, when standards, or consortia, activities are immature or stagnated; [Consider registering contributions when, in the judgment of the NMSIG, standards activities are lagging extremely behind (e.g., > 3 years) urgent requirements. This would allow associated products to have useful market life cycles.] Example: X.400 MTA MOs; c) Critique relevant MO, Profile, and Ensemble work ongoing in other groups; Example: OMNIpoint 1 Document Reviews; d) Lead/support MO implementation agreements, Profiles, Ensemble development, when supporting standards, or consortia, activities are sufficiently mature; Example: M.TA51; 2) On an as-interested basis (e.g., in response to requirements identified via example 1), the NMSIG may develop translation algorithms for automatically converting extant MO definitions from one community's object model (e.g., SNMP SMI) into OSI compatible, GDMO MOs; c) Catalogue: 1) Request EWOS & AOW to announce availability of catalogue; 2) Solicit further inputs to be fed to OPn cataloguer. 31 Part 1 - Workshop Policies and Procedures December 1993 (Working) d) API Activities: 1) Determine the requirements for systems management APIs; 2) Review proposed systems management APIs and provide comments; 3) Evaluate and select openly available systems management APIs; 4) Develop internationally harmonized profiles for implementations of systems management APIs. 4.8.9 OFFICE DOCUMENT ARCHITECTURE SIG The charter is as follows: a) Scope: 1) To develop agreements concerning implementation and testing of Office Document Architecture (ODA) systems based on ISO 8613, its addenda and related international standards; b) Objectives: 1) Develop ODA document application profiles to support a diverse set of applications and environments; 2) Register and maintain ODA document application profiles; 3) Conduct liaison with standards organizations, other groups developing ODA document application profiles, vendor/user groups and testing authorities as necessary; 4) Review and, if necessary, generate abstract test cases for ODA document application profiles; 5) Harmonize OIW ODA document application profiles with those from other international groups; 6) Participate, as necessary, in the ISO ISP processing of FOD-type profiles; 32 Part 1 - Workshop Policies and Procedures December 1993 (Working) c) High Priority: 1) Develop and maintain OIW ODA document application profiles; 2) Harmonize OIW ODA document application profiles with other international groups; 3) Assist in the progression of OIW ODA document application profiles through the ISO ISP process; d) Low Priority: 1) Develop abstract test cases; 2) Integrate addenda and extensions to the base standard into OIW ODA document application profiles; 3) Develop awareness of ODA in vendor and user groups. NOTE - The Registration SIG has effectively completed its work. The charter items below may be removed in the future. 4.8.10 REGISTRATION SIG The OSE Implementors' Workshop Registration Authority Special Interest Group (RA SIG) will deal with OSI Registration for the following areas: a) Registration of OSE Implementors' Workshop-Specified Objects; 1) The OSE Implementors' Workshop RA SIG will define the procedures for the operation of the NIST Registration Authority (i.e., NIST); a) Define policies and procedures for the registration of objects defined by the OSE Implementors' Workshop; b) Take account of currently existing OSE Workshop registration work; c) Establish policies for the publication and promulgation of registered objects; d) Liaise with other OSE Workshop SIGs, appropriate standards bodies (e.g., ANSI) and 33 Part 1 - Workshop Policies and Procedures December 1993 (Working) other appropriate organizations; 2) Support for ANSI (U.S.) Registration activities. Promote the registration of MHS Private and Administrative Management Domain Names, Network-Layer-Addresses, and other Administrative Objects by ANSI or a surrogate appointed by ANSI. If ANSI feels that it cannot serve as the Registration Authority or delegate its authority to another organization, then the OSE Implementors' Workshop RA SIG should actively support the search for another organization to carry out this work. This SIG will conduct a self-assessment, three OSE Implementors' Workshop Plenary Meetings after the Charter is approved, to determine if it has fulfilled its mission. Based on this assessment, the SIG will either be disbanded or continue. This procedure will continue until the SIG is disbanded. 4.8.11 TRANSACTION PROCESSING SIG The charter is as follows: a) reduce TR10000-format OSI TP Profile; b) Describe TP's use of other profile services: ACSE, CCR, Pres., Dir.; c) Produce CCR profile covering TP requirements; d) Liaise with other internal and external organizations as required; e) Communicate with EWOS and AOW to reach goal of an aligned profile; f) Act as registration authority for OIW TP objects, as necessary. 4.8.12 MANUFACTURING MESSAGE SPECIFICATION (MMS) SIG The charter is as follows: a) Scope: 1) To provide an open forum for discussion and agreements pertaining to MMS and issues related to MMS; 34 Part 1 - Workshop Policies and Procedures December 1993 (Working) b) Objectives: 1) To produce agreements for implementations of MMS (ISO 9506); 2) To participate in the MMS ISP process; 3) To produce implementation agreements on MMS Companion Standards (as recognized by ISO TC184/SC5/WG2) after those have reached ISO DIS or equivalent status; 4) Develop Conformance requirements; 5) Develop recommendations on MMS testing; c) As Necessary: 1) Respond to defect reports as accepted; 2) Provide feedback on Addendum material; 3) To produce implementation agreements on any ISO DIS (or higher level) or equivalent document defining alternate mappings of MMS to an OSI or other international standards based manufacturing communications architecture such as might be progressed from IEC SC 65; 4) To produce implementation agreements for IS implementations which enable existing DIS based implementations (such as specified in the MAP 3.0 specification) with minimal modifications to interoperate with IS implementations; d) High Priority Work Items: 1) Define implementation agreements on ISO-9506 based on vendor and user requirements; 2) To generate, edit, and maintain certain MMS ISPs in harmonization with the other regional workshops; 3) To review, provide input on, and harmonize with MMS ISPs produced in other regional workshops; 4) To review, provide input on, and harmonize with the common Upper Layer Requirements ISP; 35 Part 1 - Workshop Policies and Procedures December 1993 (Working) 5) Study ISO test methodologies and produce recommendations for MMS test implementations. If necessary, provide input on MMS specification requirements for the ISO test methodologies; 6) Provide input to ISO on Abstract Test Cases to facilitate conformance and interoperability testing; e) Low Priority Work Items: 1) Study and comment on CD level or equivalent documents relating to MMS activities defined in the objectives; 2) Provide input to ISO on the elaboration of service procedures for error conditions and on the relation of the use of specific error codes to these error conditions; 3) Provide input to ISO on MMS ASE specific management entities; 4.8.13 REMOTE DATABASE ACCESS SIG The charter is as follows: a) Scope: 1) For all RDA Implementations based on ISO 9579: 2) For all RDA implementations based upon ISO 9579, Parts 1 and 2: (Generic Model and SQL Specialization): a) Develop those RDA implementors' agreements and profiles which include functional elements defined in SQL (IS 9075-1992); b) Provide input to national and international standards organizations on RDA-SQL profiles and related standards and profiles; c) Coordinate with other organizations on matters related to distributed SQL data management services using RDA; b) Objectives: 1) Use ISO 9579-1 RDA Generic Model, Service, and 36 Part 1 - Workshop Policies and Procedures December 1993 (Working) Protocol, and ISO 9579-2 RDA SQL Specialization, as a basis for Implementors' Agreements on the RDA SQL ASE and its application contexts; 2) Contribute to the development of an RDA ISP; 3) Contribute to the development of an operational testbed for distributed database systems that inter- operate using RDA and SQL; c) High Priority Work Items: 1) To Produce Implementors' Agreements on the RDA TP Application Context, by performing the following: a) Develop a work plan with an associated time schedule; b) Review ULA agreements affecting RDA implementations, and harmonize with RDA and SQL requirements; c) Specify limits on encodings in RDA pdus; d) Specify profiles for RDA implementations; e) Identify and describe recommended practices in the implementation of RDA services and protocols; f) Identify implementor defined items in ISO 9579 (RDA) affecting interoperability; 2) Maintain OIW RDA Implementors' Agreements and profiles and harmonize them with those produced by other regional workshops such as EWOS and AOW to contribute towards the development of an RDA ISP; 3) Monitor and comment on the development of an ISP for ISO 9075 (SQL), for issues affecting interoperability; 4) Facilitate development and testing of one or more interoperability test suites for Distributed SQL Environments using RDA. Coordinate with other organizations on international harmonization of these test suites; 5) Implement a prototype RDA SQL interoperability testbed; 37 Part 1 - Workshop Policies and Procedures December 1993 (Working) d) Low Priority Work Items: 1) Evaluate alternate abstract syntaxes for transferring SQL argument values and SQL result values; 2) Evaluate requirements for RDA managed objects; 3) Develop Implementation Agreements for future RDA specializations, if any. 4) Monitor and comment on the development of TP APIs for any architectural issues related to RDA's use of OSI TP; 5) Monitor and comment on the development of SQL APIs such as the ISO CLI, for implications on their mapping to RDA. 4.8.14 CONFORMANCE TESTING SIG GOALS: To promote and participate in worldwide alignment of technical procedures based on ISO 9646 and other appropriate documents. This will include harmonization of text procedures and test specifications for use by conformance test laboratories. To provide direction to all OIW SIGs regarding conformance testing. To develop and maintain guidelines for and facilitate the resolution of conformance testing issues. Provide a forum for test labs to resolve issues specific to conformance testing. Achieve a consistent implementation of ISO 9646 in conformance testing to ensure equivalence of test reports. CHARTER: Harmonize work in the area of conformance methodology and procedures for use in the production of test specifications and conformance testing guidelines for OIW Stable Agreements, based on ISO 9646, TRI10000, and other appropriate documents. Provide advice on planning and coordination of conformance test specifications and testing issues. Provide, if required, specific conformance testing expertise to 38 Part 1 - Workshop Policies and Procedures December 1993 (Working) the OIW SIGs. Consider specific testing problems raised by the OIW SIGs, review these, and coordinate resolution. Coordinate the review by OIW SIGs of test specifications for their functional standards. Provide a focal point for representation of OIW SIGs in standards bodies on conformance testing matters. Build and enhance awareness within the workshop of the current status and plans for ISO 9646, ISO IEC TR10000, and other conformance documents. Liaise with other testing groups in other workshops where they exist, and with external groups, for purposes of development of harmonized agreements. Promote expansion of text cases and suites in alignment with ISO text suite structure and purposes to cover requirements of the OIW stable agreements. DELIVERABLES: Create and maintain a guidelines document for the OIW Workshop to be used by the other SIGs to resolve conformance testing issues. Maintain a log of testing issues for the SIGs. 4.8.15 HEALTHCARE SIG The charter is as follows: a) Scope: 1) Provide a technical forum for the development of implementation agreements based upon standards and profiles relative to the healthcare sector. b) Objectives: 1) Develop implementation agreements specific to the healthcare sector. 2) Coordinate and harmonize healthcare implementation agreements with those of other OIW SIG's. 39 Part 1 - Workshop Policies and Procedures December 1993 (Working) 3) Conduct liaison with other implementor's workshops and standards developing organizations concerned with the healthcare sector. 4) Contribute to the development of healthcare ISP's. 5) Register and maintain OIW healthcare objects. 6) Provide a focal point for sharing information relative to healthcare conformance testing. c) High Priority Work Items: 1) Develop detailed work plan. 2) Coordinate work plan with EWOS EG-MED. 3) Review available and developing standards and profiles. 4) Develop structure of implementation agreements. d) Low Priority Work Items: 1) Develop application profiles. 2) Review of abstract test cases. 4.8.16 OPEN SYSTEMS ENVIRONMENT TECHNICAL COMMITTEE The charter is as follows: a) Scope: The OSE-TC will coordinate the disposition of Users' OSE requirements and work requests within the OIW sphere of influence. Specifically the OSE-TC will: 1) Operate administratively and logistically as an OIW SIG (though not a SIG); 2) work closely with the other Regional Workshops and the OIW TLC in establishing additional OIW OSE work efforts (in response to User OSE requirements); 3) work OSE issues not addressed by implementation agreements; 40 Part 1 - Workshop Policies and Procedures December 1993 (Working) 4) establish, promote, and facilitate a process to be used in developing OSE profiles which are harmonized across other workshops; 5) encourage external agencies to collect, synthesize, prioritized and deliver Users' OSE requirements to the OIW; 6) assess User OSE requirements; 7) facilitate the effective use of Publicly Available Specifications (PAS); 8) work with Users to ensure orderly disposition of initial Users' work requests, and use this experience to evolve toward an internationally harmonized User Requirements process; b) Objectives: The Open Systems Environment Technical Committee (OSE-TC) in response to user requirements: 1) Considers the scope and framework of OSE (including profiles); 2) provides a forum to generate consensus in open system environment specifications; 3) allows for technical recommendations via the Technical Liaison Committee (TLC) of what new work items might be needed in existing Special Interest Groups (SIGs) or new SIGs required to address new work items; 4) encourage development of internationally harmonized User Requirements processes; c) Work Items: 1) Develop Profiling Methods; 2) Develop mechanism to process User' OSE requirements and work requests for the OIW; 3) Identify and Resolve Open Issues with PAS; 4) Develop Mechanism for Harmonizing OSE Work with other Organizations; 41 Part 1 - Workshop Policies and Procedures December 1993 (Working) d) Specifically: 1) Identify Organizations to Harmonize with (e.g.., AOW, EWOS); 2) Develop Process for Issue Identification and Notification; 3) Develop Process for Setting Issue Priority; 4) Develop Process for Setting Issue and Work Item Responsibility; 5) Develop Communication and Information Flow Mechanisms; 6) Develop Glossary of Terms Relevant to OSE-TC; 7) Develop OSE Procurement Guide; 8) Develop OSE Specifications; 9) Develop OSE Reference Model and User Forum. 4.8.17 CHARTER FOR OIW TECHNICAL LIAISON COMMITTEE (TLC) a) The OIW Technical Liaison Committee (TLC) was established by the OIW Plenary to deal with issues and problems that are beyond the scope of OIW Special Interest Groups (SIGs) ability to resolve by themselves, or by direct discussions and negotiations among themselves; b) Thus, the TLC is tasked to deal with such problems as may be brought before the TLC by any one or more SIGs; c) When an issue or problem is brought before the TLC, the TLC is obligated to address the problem in whatever way(s) it can to develop a resolution. The available tools include: 1) Direct discussion in a TLC meeting to produce a resolution; 2) Formation of a TLC Task Group to separately address it, which may lead to formation of a new SIG, using New SIG Formation Procedures; 42 Part 1 - Workshop Policies and Procedures December 1993 (Working) 3) Refer it to another body, such as the Regional WorkShops Coordinating Committee (RWS-CC) which consists of 3 delegations from each of OIW, EWOS, and AOW; 4) Ad Hoc mechanisms and methods that may be invented to meet specific needs, including mediation of disputes; 5) Referral of the issue back to its originating SIG, or to another SIG, as may be appropriate; d) The resources of the TLC consist of attendees who represent the active SIGs of the OIW. Each SIG is allowed to send 1 or 2 representatives, and SIG Chairs often attend; e) The TLC Chair is elected by the OIW Plenary, using SIG Chair Election Rules; f) The TLC is not tasked to address any problem that is being addressed in an OIW SIG, unless requested by that SIG, or another SIG requests assistance because of some cross SIG involvement with the issue; g) The TLC is tasked to administer the OIW ISO Object Identifier Register as defined in Part 6 of the OIW Stable Implementation Agreements: [iso (1) identified-organization (3) oiw (14)]. TLC is responsible for maintenance of the text in Part 6; h) The TLC Chair is designated to serve as a Member of the RWS-CC Delegation, although this is not a required obligation for every RWS-CC meeting. An alternate may be selected according to the OIW Delegate Selection Rules; i) The TLC reports to the OIW Executive Committee and to the OIW Plenary. It brings appropriate, TLC attendee approved motions before both the Executive Committee and the Plenary; j) The TLC also serves as a contact point for external liaison with other standards bodies and organizations that do not have a properly matching contact point among the active SIGs or with the OIW Chair; k) The TLC is the primary contact point for interactions with the EWOS Technical Liaison Group (TLG) which has corresponding the responsibilities within EWOS. The AOW 43 Part 1 - Workshop Policies and Procedures December 1993 (Working) does not have a matching group or committee, so these matters are addressed directly through the AOW Chair; l) The TLC also provides a measure of stability to the OIW over time by serving in an advisory capacity to assist new SIGs and SIG Chairs in the conduct of their work. 4.8.18 MULTIMEDIA DATA AND DOCUMENT INTERCHANGE (MDDI) SIG a) Scope: To develop implementation agreements concerning the interchange and processing of multimedia data/content objects, either in separate interchange or in structured collections such as documents -- this includes business and technical data (e.g., EDI, PDES/STEP). b) Objectives: 1) Develop regional application profiles; 2) Harmonize and progress ISPs for the application profiles; 3) Liaison with standards organizations, vendors, users, and testing authorities; 4) Review ATCs and generate as required; 5) Provide interoperability testing methodology; 6) Coordinate with related APP and FIPS development; c) High priority projects: ODA Raster, SGML/HyTime, CGM, EDI, Audio, JPEG, MPEG; 1) ISRs and ATCs for ODA; 2) Poscript, PCL, SPDL; 3) ODA DTIF (Spreadsheet extension) 44 Part 1 - Workshop Policies and Procedures December 1993 (Working) 4.8.19 INTEGRATED SOFTWARE ENGINEERING ENVIRONMENTS (ISEE) SIG a) Scope: The ISEE SIG's goal is to provide an open forum for developing environment profiles, implementation agreements and conventions for using environment integration standards and specifications. The ISEE SIG will adopt those profiles, agreements and conventions necessary for developing standards-compliant ISEEs or components of ISEEs that can better interoperate; b) Objectives: 1) Continue work started in NIST ISEE and NGCR PSESWG working groups; 2) Develop profiles for open system ISEE; 3) Develop implementation agreements supporting the implementation of those profiles; 4) Develop conventions for implementing ISEE standards; 5) Develop profiles and conventions for using ISEE standards in various contexts and application domains (e.g., MIS, scientific, embedded, large projects); 6) Work with standards organizations, consortia, vendors, users, researchers and evaluators involved in the development, implementation or conformance testing of ISEE standards to promote the development of useful and compatible ISEE standards; c) High priority projects: 1) Profile for an open sytems ISEE including the following standards and specifications; a) for data integration: PCTE, IRDS, ATIS, SQL, ODMG, CDIF, EDIF, SEDDI, PHIGS, GKS, PDES; b) for control integration: CORBA, IDL, OLE, BMS, X3H6 messaging standards (CCQ/CIA), OPENSTEP; c) for presentation integration: X, MOTIF, COSE; d) for platform integration: POSIX, PWI, COSE, 45 Part 1 - Workshop Policies and Procedures December 1993 (Working) DCE; 2) Define the relationship of the OSE Reference Model and the ISEE Reference Models. 5 Secretariat The Secretariat provides administrative support to the Workshop's Plenary, Standing Committees, and Technical Working Groups. NIST and the IEEE Computer Society cosponsor the Secretariat providing its Chairmen and small support staff. Planning and support of quarterly meetings, publication of implementation agreements, and on-going archival of the proceedings of the Workshop are handled by the staff. 5.1 Establishing and Changing Workshop Procedures Workshop procedures are established by the National Institute of Standards and Technology. As the Workshop grows to meet the needs of the participating vendors and users, modification of the procedures are suggested to NIST through the Plenary Assembly as formal business. NIST, acting in the best interest of the Workshop, carefully considers suggested changes and, when appropriate, institutes new Workshop procedures. 5.2 Workshop Documents The Workshop Documents are maintained and distributed by the Workshop Secretariat. The Plenary and dinner meeting minutes, Procedures Manual, and other correspondence detail the administration of the Workshop. Individual SIG documents are managed, maintained and distributed by the SIGs. Each SIG is encouraged to maintain a list of numbered (format XX SIG/year-no) documents, if appropriate. Each SIG is required to send a copy of SIG meeting minutes to the Workshop Chair. Working Agreements reached through consensus in the Workshop Special Interest Groups and approved by the Plenary, are documented in the Working Document. Additions, deletions and modifications to the Working Document regularly occur until the agreements stabilize, when the agreements may be moved to the Stable Document. Each part of the Stable and Working Documents represents a 46 Part 1 - Workshop Policies and Procedures December 1993 (Working) particular subject of interest. Each part may be in an ISO- defined format or defined as: a) Introduction; b) scope and Field of Application; c) status/Errata, e.g., ISO Defect Reports; d) portions dealing with agreements; e) conformance requirements; f) appendices, e.g., recommended practices. Each new version of the Stable Document highlights the additions and modifications as compared to previous versions and includes compatibility and interworking statements. Contact the Workshop Chair or Workshop Secretariat for order information for Workshop Documents. 5.3 Modification of Workshop Agreements Responsibility for the timely publication of accurate Workshop Agreements Documents rests with the National Institute of Standards and Technology. Modifications to these agreements are suggested to the Plenary Assembly by the Special Interest Group that writes the appropriate portion. Approval by the plenary is required for all changes. NIST maintains editorial license and approves all editorial changes to both the Working and the Stable Agreements Documents. Text proposed for stability must have been in the Working Document for at least one workshop period (except for editorial modifications). Procedures for modifying the Working Document are: a) SIG moves for change; SIG motion carries by substantial majority; b) SIG Chair presents motion at Plenary; motion carries by at least 2/3 majority; c) change made before next meeting. Procedures for adding new functionality to the "Stable" Document are: a) Text must previously exist in working document; 47 Part 1 - Workshop Policies and Procedures December 1993 (Working) b) SIG moves to stabilize new functionality; motion carries by substantial majority vote; c) SIG Chair presents motion at Plenary; motion carries by at least 2/3 majority vote; d) change made to Stable Document as indicated in motion or before next workshop; e) provision is made to identify new functionality as stable. Intention to move material to stability at the next Workshop should be given in the Working Document well in advance, by giving the particular portions of text affected. If possible, those portions will be mailed out before the next Workshop to allow maximum time for consideration. In addition, extensive time may be provided during Workshop week (usually on Thursday) for review of text that is a candidate for stability. Procedures for modifying the "Stable" Document are: a) SIG moves for change; SIG motion carries by substantial majority (change should be identified as technical, editorial, or alignment); b) SIG Chair presents motion at Plenary; motion carries according to special voting rules for technical or alignment errata, if necessary; c) Errata added to stable document as indicated in motion or before next meeting; d) Special voting rules for technical or alignment errata apply for Plenary vote, and all no or abstain votes on first attempt should be minuted. It is extremely important for Plenary attendees to be informed of the impact of potential decisions reached by the Plenary. Presenters should note such impact in proposals brought before the Plenary. The Workshop Chair will note this importance by having available all copies of affected documentation during Plenary discussion. Time may be made available during the week to discuss these and any other contentious issues before the Voting Plenary. 48 Part 1 - Workshop Policies and Procedures December 1993 (Working) 5.4 Stable Document Maintenance The Stable Document is dated and given a version and edition number. The version is issued no more often than once per year and is issued if and only if new functionality is added. In addition, the Executive Committee must unanimously approve the release of a new version. Implementation Agreements should state clearly, in the respective parts, the standards documents and/or direct reports upon which the implementations are based. Errata are added to the Stable Document using the procedures defined above. These errata may or may not be edited into a new edition of the "Stable" Document. A new edition may be issued by NIST at any time. Errata (changes to the Stable Document) are technical, alignment, or editorial. Editorial errata are appearance (clarification) changes which do not alter the meaning of the text. Alignment errata are errata which reflect consistency with other similar agreements or later versions of the base standard, Technical errata are changes which do affect the meaning of a piece of text. Each of these errata must be classified as described above. The Errata history of each part since the last version of the Stable Document may be given in tabular form for informational purposes. Material for a new Version could come from any of the following sources: a) The latest text from the previous version (automatic inclusion); b) possibly, some new material from the Working Document. No other sources of information are acceptable. Thus, it is a goal that material from the most recent version be subsumed into the new version. 5.5 Distribution of Workshop Documents 5.5.1 Publications The Workshop "Stable " Document is published by the U. S. 49 Part 1 - Workshop Policies and Procedures December 1993 (Working) Department of Commerce, National Institute of Standards and Technology and is available for sale from the National Technical Information Services, the U.S. Government Printing Office (GPO), and the IEEE Computer Society. The Draft "Working Document" is available to attendees at the Workshop of issuance; the "Stable" Document (or replacement pages) are also available to attendees. The Stable and Working Documents are available "on-line". The Stable Document is also distributed to libraries and repositories throughout the world. In addition, a permanent mailing list is maintained for certain individuals (such as delegates from other regional workshops, and voluntary standards participants), with whom communication on a regular basis is important; individuals on this list will receive copies of all Workshop Documentation. 5.5.2 SIG Correspondence and Working Documents Listed below are the preferred methods for OIW distribution: a) The preferred method of distribution is the NIST/OIW computer. Most correspondence from SIGs should be placed on the NIST OSI computer. Directories and FTP services for storing and retrieving large documents are available. Mail Exploder services for SIG email conference is also encouraged; b) Distribution of Documents outside of quarterly meeting. Mass distribution of paper documents should be confined to active SIG participants. Where possible email and FTP distribution should be used; c) Occasional first class letters (less than 5 pieces): These random, intermittent mailings should be borne by SIG organizations; d) Printing and Distribution Costs; There are two ways to distribute paper documents; 1) SIG chair mails documents at their own expense and submits request for reimbursement to OIW (Brenda). The SIG chair is the only one who can submit a request; 50 Part 1 - Workshop Policies and Procedures December 1993 (Working) 2) SIG may send electronic documents or camera ready hard copy to OIW with instructions on when and to which mailing list to use; e) Document distribution Budgets SIG chair will be responsible for submitting a request for reimbursement of document distribution. A rough estimate of the 1) number of mailings; 2) number of SIG members; 3) approximate weight of mailing. A budget will be negotiated for each SIG for planning purposes. Reasonable and planned overruns are permissible. 5.5.3 Electronic Distribution This section contains information needed to obtain Workshop documentation. Most of the publications listed in this document are available for "anonymous" file transfer from the machine NEMO.NCSL.NIST.GOV located at NIST in Gaithersburg, MD, USA. This service is accessible through the Internet. Files may be retrieved via FTP, SMTP mail, gopher, or WWW. NOTE - WordPerfect 5.1 files must be transferred in binary mode. A "LaserWriter" printer definition was used in creating the PostScript files. A commonly available set of fonts (for example, Helvetica 10-pt) must be available on your local printer for your local output to be correctly displayed. This applies to all WordPerfect 5.1 and PostScript files retrievable on-line as indicated below. The ".Z" file extension indicates that the files have been compressed using Lempel-Ziv ("LZ") coding (i.e., through the use of the "compress" utility commonly found on UNIX systems). FTP 51 Part 1 - Workshop Policies and Procedures December 1993 (Working) NEMO.NCSL.NIST.GOV (129.6.58.136) supports "anonymous" FTP as follows: login: ftp or anonymous password: your_name@your_site (SMTP mail address) cd ./pub/oiw/agreements Gopher Gopher allows you to browse through the documents, and to retrieve documents by downloading them through gopher, or by sending them by SMTP mail to the requestor. If your site already has gopher clients installed, type: gopher nemo.ncsl.nist.gov Otherwise, you can connect to gopher on NEMO.NCSL.NIST.GOV by typing: telnet nemo.ncsl.nist.gov login: gopher Password: gopher Go to the menu entry that says "OSE Implementors' Workshop", then go to the menu entry that says "Implementors' Agreements". You can browse through the ASCII versions of the documents, but you cannot save them. You can mail them back to yourself (but FTP will be faster). World Wide Web World Wide Web (WWW) allows browsing of documents served by Gopher servers, as well as documents in HTML format served by HTTP servers. If your site has WWW clients installed, you can use them to browse the information on NEMO.NCSL.NIST.GOV. The URL for the NEMO.NCSL.NIST.GOV server is: http://nemo.ncsl.nist.gov/ Using the WWW line-mode browser under UNIX, the command would be: 52 Part 1 - Workshop Policies and Procedures December 1993 (Working) www http://nemo.ncsl.nist.gov/ Select the "SST Gopher" entry to access the Gopher server. SMTP mail file server - NOT IMPLEMENTED The SMTP mail file server is not implemented yet. When it is, files may be requested as follows: Files may be requested by sending the SMTP mail messages to oiw@nemo.ncsl.nist.gov. The subject line can be blank, the body of the message will be: send ./pub/oiw/agreements/[filename] where [filename] is replaced with the name of the document desired. If you wanted to retrieve the 1993 Subnetworks agreement in ASCII, under UNIX you might type: mail oiw@nemo.ncsl.nist.gov Subject: nothing send ./pub/oiw/agreements/02S-9303.asc . Since some of the documents are very large, they will be split into multiple messages and sent individually. You will have to re-assemble them upon receipt. You can send a message containing: send help for additional instructions. Questions or comments regarding accessing these services should be sent via SMTP mail to oiw-request@nemo.ncsl.nist.gov. ! OSE Workshop Documentation The output of the OSE Implementors Workshop (OIW) is a pair of aligned documents, one representing Stable Implementation Agreements (SIA), the other containing Working Implementation Agreements (WIA) that have not yet gone into the stable document. Material is in either one or the other of these documents, but not both, and the documents have the same index structure. 53 Part 1 - Workshop Policies and Procedures December 1993 (Working) The SIA is reproduced in its entirety at the beginning of each calendar year, with an incremented version number. Replacement page sets are distributed subsequently three times during each year (after each Workshop), reflecting errata to the stable material, as well as new functionality declared stable. In this way an up-to-date document is maintained. The WIA is reproduced in its entirety at the beginning of each calendar year. Replacement page sets are distributed subsequently three times during each year (after each Workshop), reflecting errata to the Working material, as well as ne functionality. The Workshops are held in March, June, September and December). OIW attendees will not automatically receive the WIA or SIA, as well as the replacement pages to the WIA and SIA. In keeping with the new policy, anyone wishing to obtain paper copies of the WIA or SIA will must pay an extra fee during registration. These change page sets will be distributed after each Workshop. The 1993 OIW meeting dates are March 8-12, June 7-11, September 13-17, and December 6-10. All of the 1993 meetings are currently planned to be at NIST. SIA documentation is available from the U.S. Government Printing Office (GPO), and the National Technical Information Service (NTIS). SIA documentation is also online, as described below. Effective April 1991, WIA documentation is in draft form, and not sold to the public. It will be distributed to Workshop attendees as usual. WIA documentation is also online, as described below. NIST Points of Contact for the OIW: Ted Landberg -- management information OIW Chairman Brenda Gray --administrative information OIW Registrar SIA, Version 6. -------------- Version 6, Edition 1 of the SIA, Special Publication 500-206, has been published by NIST, and is currently available from the U.S. Government Printing Office and The National Technical Information Service. NIST Point of Contact: 54 Part 1 - Workshop Policies and Procedures December 1993 (Working) Brenda Gray hardcopy (Version 6): U.S. Government Printing Office GPO Stock Number: 903-015-00013-6 Price: $109.00 (base document plus updates) - domestic $136.25 (base document plus updates) - foreign hardcopy (Version 6): NTIS (base document) Order Number: PB 93-166809/AS Price: $147.00 (paper); $69 (microfiche) NTIS (March 92 Change Pages) Order Number: PB 92-190479/WCC NTIS (June 92 Change Pages) Order Number: PB 92-232321/WCC on-line (Version 5): available for anonymous file transfer from nemo.ncsl.nist.gov (129.6.58.136) (see preface for details) Individual Working and Stable Parts have been updated and placed on-line (Output from the March 1993 OIW) as WordPerfect 5.1 files, ASCII and Postscript files. Postscript files for 1992 were placed on-line after the December OIW. ./pub/oiw/agreements/XS-9212.asc -- ascii (stable) ./pub/oiw/agreements/Xs-9212.w51 -- WordPerfect 5.1 (stable) ./pub/oiw/agreements/XW-9212.asc -- ascii (working) ./pub/oiw/agreements/Xw-9212.w51 -- WordPerfect 5.1 (working) 55 Part 1 - Workshop Policies and Procedures December 1993 (Working) NOTE - For the entire stable document, reference "stable-out.All.Z" for the ASCII file, and "Stable_w51.All" for the WordPerfect 5.1 file. Helvetica fonts ranging in size from 8-pt through 30-pt were used in the preparation of the OIW files. In the above, "X" is part number (1 to 25), where a part describes a particular piece of OSI functionality, and corresponds to a chapter of a book. To access each piece of the book, retrieve filenames with syntax described above. "9212" refers to the month (Dec) and year (1992) of the agreements that are on-line. For the entire working document, reference "work-out.all.Z" for the ASCII file, and "Work_w51.All. Z" for the WordPerfect 5.1 file. The ".Z" mentioned above indicates compressed mode. In the above, "X" is as follows: X=1 (General Information), X=2 (Subnetworks), X=3 (Network Layer), X=4 (Transport), X=5 (Upper Layers), X=6 (Technical Registration Info), X=7 (1984 Message Handling Systems), X=8 (1988 Message Handling Systems), X=9 (FTAM Phase 2), X=10 (FTAM Phase 3), X=11 ( Directory Services), X=12 (OS Security), X=13 (more OS Security), X=14 (Virtual Terminal), X=15 (Transaction Processing), X=16 (Level 3 Office Document Architecture), X=17 (Level 2 Office Document Architecture), X=18 (Network Management), X=19 (Remote Database Access), X=20 (Manufacturing Message Specification), X=21 (Character Sets), X=22 (ODA Image DAP), X=23 (ODA Raster DAP), X=24 (Conformance Testing), and X=25 (Healthcare) Addresses and Telephone Numbers are as follows: Ted Landberg--management information (OIW) OIW Chairman NIST, Technology, B266 Gaithersburg, MD 20899 (301) 975-2245 Brenda Gray--administrative information (OIW) OIW Administrative Assistant Technology, B217 Gaithersburg, MD 20899 56 Part 1 - Workshop Policies and Procedures December 1993 (Working) (301) 975-3664 National Technical Information Service (NTIS) U.S. Department of Commerce 5285 Port Royal Road Springfield, VA 22161 (703)487-4650, FTS--737-4650 U.S. Government Printing Office Washington, DC 20402 (202) 783-3238 Standards Processing Coordinator (ADP) National Institute of Standards and Technology Technology Building, Room B-64 Gaithersburg, MD 20899 (301) 975-2816 5.6 Payment Policy In the event an attendee indicates that registration payment has been made but there is no record of receipt, payment must be rendered onsite. There MUST be some type of payment received from all attendees in order for them to participate in the workshop. The onsite payment will be returned to the attendee if the original registration payment is received by the end of workshop week. If the original payment is not received by the end of the week, the onsite payment will be processed. In the case of double payment, the attendee will be refunded as soon as possible. 6 Regional Workshop Coordination A Regional Workshop Coordinating Committee (RWS-CC) has been formed to monitor technical harmonization activities among the OSE Implementors' Workshop, the Asia-Oceania Workshop, and the European Workshop for Open Systems. The OSE Implementors' Workshop currently has a delegation consisting of a vendor representative, a user representative, the Technical Liaison Committee Chair, and the Workshop Chair. The Workshop has been granted S-Liaison status to ISO/IEC JTC1/SGFS through NIST; this indicates that (1) Workshop attendees may participate directly in specified ISO Subcommittees on particular subjects, and (2) Workshop attendees may participate extensively in profile development work; the result of this work may be a harmonized proposed draft International 57 Part 1 - Workshop Policies and Procedures December 1993 (Working) Standardized Profile (pDISP) submitted to SGFS. 6.1 RWS-CC Charter and Procedures Clause 2 is the RWS-CC charter document approved 3/6/89 and revised March 1990. Paragraphs have been renumbered to conform with the Part 1 numbering scheme. 6.1.1 Goals a) Interoperability of products from different vendors worldwide to be achieved on basis of worldwide harmonized implementation specifications to be approved by lSO/IEC environment (JTC 1/SG-FS). b) Specific form of implementation specifications to be harmonized and become the standards form of lSPs; Workshops to influence the 15P process, adaptation to future needs if necessary. c) Profile harmonization to concentrate primarily on 'new' profiles. d) Harmonization of already existing profiles to be handled pragmatically and oriented towards specific needs. 6.1.2 Abbreviations RWS = a regional workshop RSIG = SIG in a regional workshop SlG = Special interest Group (Technical Group charged with work in a particular area) 6.1.3 Coordination Coordination needs to be done at two levels - planning - technical Therefore, means have to be established to provide coordination at these levels. 58 Part 1 - Workshop Policies and Procedures December 1993 (Working) 6.1.4 Coordination at Planning Level Coordination at planning level involves the following: - notify on regional plans - identify work items of common interest - organize reasonable liaison among RSIGs - propose selected work items for assignment to Multi- RWS SIG and steer their work 6.2 RWS Coordinating Committee In order to properly deal with this coordination a RWS Coordination Committee (RWS-CC) should be established. It should have limited representation (<4) from each RWS. Though it is in the responsibility of each RVVS to nominate its delegates to the RWS-CC, it is desirable that both vendors and users be represented. Also, continuity of participants is desirable. The meeting frequency should be 2-3 times a year at rotating locations. In order to provide an identifiable point of contact, RWS-CC should elect from the Committee a chairperson on a year's term. The secretariat of RWS-CC is held by the secretariat of the chairperson's RWS-CC. 6.3 RWS-CC: Methods of Working a) Each RWS will apply for 5-liaison to JTC 1; b) Exchange RWS work item planning information at the earliest possible point in time; c) Based on this planning information, the following things may happen: 1) Only one RW5 can or wishes to work on the item; 2) More than one ~WS is interested and can supply manpower. Then the following cases need to be distinguished: a) The RSIGs work in parallel; 59 Part 1 - Workshop Policies and Procedures December 1993 (Working) b) If in favorable circumstances RSIGs can be combined into a Multi-RWS SIG then this should be strongly encouraged. In either case, output of the active RSlG(s) should be reviewed by the other RWS. For case b) above, RW5-CC provides for PWS harmonization in the following way: a) Encourage coordination at technical level (see below) and monitor the coordination progress towards Harmonized output; b) A Multi-RWS SlG's output should be presented to all RWSs, for review and final approval. RWS-CC takes actions if coordination at technical level fails. RWS-CC takes actions if voting in RWS leads to unharmonized results (for either case aa) or bb)). RWS-CC recommends to submit harmonized resultS to lSO/IEC JTC l. Any funding necessary to execute the coordination remains with each individual RWS. 6.4 Coordination at Technical Level Once an item has been identified as of interest beyond one region, technical coordination among RSIGs working on this subject should be encouraged: a) The conveners of the RSlGS (or any other designated persons) are responsible for maintaining close liaison with the objective of final international harmonization; RWS-CC to receive regular reports about liaison status; b) By cross-participation in RSlG meetings; c) If necessary, one of the RWS should be identified to act as "sponsor" of such a SIG secretariat; 60 Part 1 - Workshop Policies and Procedures December 1993 (Working) d) A Multi-RWS SIG is responsible for its own control and operation, in liaison with RWS-CC and the RWSs; e) Stable results of such a SIG are submitted to all RWSs for approval; f) Exchange documents and comment on them. 6.5 Implications for RWS The coordination mechanisms suggested above lead to some requirements on each RWS: a) RWS and RSIG documents related to pics considered in RWS-CC must be eligible for distribution to other RWSs or RWS-CC; b) The RWS planning process needs sufficient visibility; c) RWSs have to recognize implications on RSIG scheduling as a consequence of the coordination efforts; d) A Multi-RWS SIG requires acceptance in at least one RWS as one of its RSIG's; e) RSIG chairperson reporting to the RWS should include the status of coordination. NOTE - It is understood that "voting at RWS level" throughout this document means "voting on stable documents" rather than voting on intermediate steps (which still may be at the discretion of each individual RWS). 61 Part 1 - Workshop Policies and Procedures December 1993 (Working) 62 Part 1 - Workshop Policies and Procedures December 1993 (Working) 63 Part 1 - Workshop Policies and Procedures December 1993 (Working) 64 Part 1 - Workshop Policies and Procedures December 1993 (Working) 7 Accepting and Processing New Work The Workshop relies on external mechanisms to collect, synthesize, prioritized and deliver Users' OSE requirements to the OIW. The OSE Technical Committee works with Users to ensure orderly disposition of initial Users' work requests, and uses this experience to evolve toward an internationally harmonized User Requirements process. This section documents the procedures for introducing new work items into the Workshop. 7.1 Processing User Requests In order to avoid delay direct participation is encouraged, though not mandatory. Requirements submitted by outside organizations will be handled in the following manner: a) Acknowledgement: Upon arrival: 1) record and assign an OSE-TC Document number to the request; 2) the OSE-TC chair will send a letter to the submitter acknowledging receipt of the request; (No approval or disapproval of the request should be implied from the acknowledgement letter.); b) OSE-TC Action: Place Proposal on OSE-TC agenda for next meeting to discuss the following matters to: 1) identify existing work related to request; 2) identify potential Workshop technical work groups (SIGs) that would be involved in developing a technical solution; 3) If further action is required, a task group is created to prepare documents and recommendations for approval by the OSE-TC. with participation open to all interested parties. A task group lead is chosen to coordinate the activity; 4) The task group will be responsible for the following: a) drafting a response to the submitting group 65 Part 1 - Workshop Policies and Procedures December 1993 (Working) for approval by the OSE-TC; b) drafting a notice and information package for EWOS, AOW, and SGFS; c) review and modify the statement of requirement; d) prepare a new work item and/or SIG charter, as appropriate; e) draft a Request for Specifications all via the approved process; f) collect a list of candidate specifications as part of the work item; The call for specifications will go out to the OIW membership, and will be available electronically on the OIW electronic bulletin board. Notice will also be sent to a standing list of organizations that will liaison to the OSE-TC for this purpose. These organizations may include for example Standard Development; Organizations, User Requirement Definition Groups, and Information Industry Consortia; g) Notice will be placed in the CBD announcing the Request for Specifications, and that Workshop is considering a project to create an implementation agreement to satisfy the specified user requirements; c) Disposition: At a succeeding meeting of OSE-TC, a recommendation for a new work item and/or SIG will be delivered for consideration by the full OSE-TC. The recommendation should include the results of 2a, and 2b along with a recommended disposition and estimated start date of work if accepted. Comments from interested parties would be welcomed as part of the agenda item; d) SIG Activity: SIG activities proceed per existing OIW and SIG procedures; e) Evaluation: The completed implementors agreement is evaluated with respect to satisfaction of the original user requirement to determine if additional action is needed to satisfy the requirement. The procedures may be modified as 66 Part 1 - Workshop Policies and Procedures December 1993 (Working) a result of the experience to assure continued improvement of the process. 7.2 Publicly Available Specifications Users observe that increasingly there are specifications which provide needed extensions to the international standards, have broad consensus, and can meet user OSE business needs in advance of the completion of the formal standards process. Many users would like to be able to exploit this consensus in their procurement process sooner rather than later. When proposing the use of a Publicly Available Specifications, a SIG makes its case, using the following guidelines. The OIW Plenary would be responsible for accepting or rejecting the SIG's proposal using the voting rules of the OIW. The Publicly Available Specifications must neither overlap with nor conflict with an existing formal standard or formal standard under development. That is, if a formal standard exists or is under development that provides the same function as the proposed Publicly Available Specifications, then the Publicly Available Specifications may not be introduced as the basis for OIW Implementation Agreements; if a Publicly Available Specifications adds functionality then it must be engineered to augment the formal standards in such a way that interoperability among systems implementing the formal standards is not precluded. A SIG would only propose to reference a Publicly Available Specifications in an Implementation Agreement when it provides a technical function that meets a clear and widespread user requirement. The specific reference must be labelled as a "Publicly Available Specifications" in the agreement. In exceptional circumstances driven by user requirements, a SIG may propose to reference a de facto standard in an Implementation Agreement where the de facto standard does functionally overlap an existing formal standard but otherwise meets the criteria for a Publicly Available Specifications; this would be strictly limited to cases where the SIG can demonstrate that the agreement will expedite the migration (e.g., facilitating a gateway or interworking) from the de facto standard to a formal standard in multi-vendor environments. Where more than one Publicly Available Specifications might serve as the basis for OIW Implementation Agreements for the same technical function, the SIG proposing to use a Publicly Available Specifications will recommend which among the several candidates 67 Part 1 - Workshop Policies and Procedures December 1993 (Working) should be used and why. The OIW Plenary will make the final choice among competing Publicly Available Specifications in response to specific user requirements. Whenever possible only one Publicly Available Specifications should be used as the basis of Implementation Agreements for any specific technical function. In proposing the use of a Publicly Available Specifications as the basis of Implementation Agreements, the SIG must document that the specification meets the following criteria: a) Common description; the specification should be described using conventions, including conformance statements, appropriate for the existing formal standards which the specification augments. For example, a Publicly Available Specifications describing a new networking service and a supporting protocol should be described with a service and protocol specification using the conventions established for OSI standards; b) Stability: the specification will not change except as required to fix technical and editorial errors. The OIW must be free to change and amend the specification as required to fix technical and editorial errors and to make it suitable for submission to the formal standards process. c) Completeness; the specification must be sufficiently complete so as to allow useful and predictable implementation of the complete functionality from scratch. For example, an interface specification would not qualify if it simply permits standardized access to an otherwise proprietary implementation which provides the functionality. d) Proof of concept; the specification has been demonstrated in at least one actual implementation to meet the user requirement in question. e) Reasonable terms; the specification is available on terms consistent with ANSI, ISO and CCITT copyright and patent guidelines. When a Publicly Available Specifications is proposed as the basis of Implementation Agreements, the proposing SIG will describe what actions are being taken to initiate a formal standard by a standards development organization to provide the same technical functions. When a formal standard is in progress that provides functionality previously provided through Implementation Agreements about a Publicly Available Specifications, appropriate arrangements must 68 Part 1 - Workshop Policies and Procedures December 1993 (Working) be made to evolve from the Publicly Available Specifications to the formal standard. This will most likely mean that Implementation Agreements on the obsolete Publicly Available Specifications will be eliminated within a reasonable time. When a Publicly Available Specifications is proposed as the basis of Implementation Agreements, the proposing SIG must demonstrate that the proposed specification is an acceptable basis for work in AOW and EWOS, or demonstrate that neither AOW nor EWOS intend to work on the subject technical function within the near-term. When a Publicly Available Specifications is approved by the Plenary for use in an Implementors Agreement, the referenced version of the specification may not be modified except as required to fix technical and editorial errors, as noted above. If there is consensus in the SIG to reference a functionally enhanced version of an approved specification, the new version must be proposed following the same guidelines and criteria as for a new Publicly Available Specifications. The following open issues with regard to Publicly Available Specifications have been resolved: a) A special set of voting procedures apply to a vote to forward a proposal to use a Publicly Available Specification in an implementation agreement to the OIW Plenary. These procedures follow the special voting rules as identified in the above paragraph a-d. b) When OIW determined that vendor products based on formal standards are widely available, the related Publicly Available Specifications will be expunged from the Implementation Agreements; c) The ownership of the Publicly Available Specifications shall be documented on a case by case. Guidelines for Implementation of the ANSI Patent Policy shall be followed in documenting the Publicly Available Specifications; 69