home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD1.mdf
/
nist
/
oiw
/
agreemnt
/
01w_9403.txt
< prev
next >
Wrap
Text File
|
1994-05-22
|
166KB
|
5,083 lines
Part 1 - WORKSHOP POLICIES AND PROCEDURES
Output from the March 1994 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 March 1994 (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.
ii
Part 1 - Workshop Policies and Procedures March 1994 (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 . . . . . . . . . . . . . . . . . . . . . . 21
4.8.1 FTAM SIG . . . . . . . . . . . . . . . . . 22
4.8.2 X.400 (MESSAGE HANDLING SYSTEMS) SIG . . . 23
4.8.3 LOWER LAYER SIG . . . . . . . . . . . . . . 24
4.8.4 OPEN SYSTEMS SECURITY SIG . . . . . . . . . 25
4.8.5 DIRECTORY SERVICES SIG . . . . . . . . . . 26
iii
Part 1 - Workshop Policies and Procedures March 1994 (Working)
4.8.6 VIRTUAL TERMINAL SIG . . . . . . . . . . . 27
4.8.7 UPPER LAYERS SIG . . . . . . . . . . . . . 29
4.8.8 NETWORK MANAGEMENT SIG . . . . . . . . . . 30
4.8.9 OFFICE DOCUMENT ARCHITECTURE SIG . . . . . 33
4.8.10 REGISTRATION SIG . . . . . . . . . . . . . 34
4.8.11 TRANSACTION PROCESSING SIG . . . . . . . . 35
4.8.12 MANUFACTURING MESSAGE SPECIFICATION (MMS)
SIG . . . . . . . . . . . . . . . . . . . . 35
4.8.13 REMOTE DATABASE ACCESS SIG . . . . . . . . 37
4.8.14 CONFORMANCE TESTING SIG . . . . . . . . . . 39
4.8.15 HEALTHCARE SIG . . . . . . . . . . . . . . 40
4.8.16 OPEN SYSTEMS ENVIRONMENT TECHNICAL
COMMITTEE . . . . . . . . . . . . . . . . . 41
4.8.17 CHARTER FOR OIW TECHNICAL LIAISON COMMITTEE
(TLC) . . . . . . . . . . . . . . . . . . . 43
4.8.18 LIBRARY APPLICATIONS DRAFT CHARTER . . . . 45
4.8.19 MULTIMEDIA DATA AND DOCUMENT INTERCHANGE
(MDDI) SIG . . . . . . . . . . . . . . . . 47
4.8.20 INTEGRATED SOFTWARE ENGINEERING
ENVIRONMENTS (ISEE) SIG . . . . . . . . . . 48
5 Secretariat . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Establishing and Changing Workshop Procedures . . . 49
5.2 Workshop Documents . . . . . . . . . . . . . . . . . 50
5.3 Modification of Workshop Agreements . . . . . . . . 51
5.4 Stable Document Maintenance . . . . . . . . . . . . 52
. . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.5 Distribution of Workshop Documents . . . . . . . . . 53
5.5.1 Publications . . . . . . . . . . . . . . . 53
5.5.2 SIG Correspondence and Working Documents . 53
5.5.3 Electronic Distribution . . . . . . . . . . 54
5.6 Payment Policy . . . . . . . . . . . . . . . . . . . 61
6 Regional Workshop Coordination . . . . . . . . . . . . . 61
6.1 RWS-CC Charter and Procedures . . . . . . . . . . . 61
6.1.1 Goals . . . . . . . . . . . . . . . . . . . 61
6.1.2 Abbreviations . . . . . . . . . . . . . . . 62
6.1.3 Coordination . . . . . . . . . . . . . . . 62
6.1.4 Coordination at Planning Level . . . . . . 62
6.2 RWS Coordinating Committee . . . . . . . . . . . . . 62
6.3 RWS-CC: Methods of Working . . . . . . . . . . . . . 63
6.4 Coordination at Technical Level . . . . . . . . . . 64
6.5 Implications for RWS . . . . . . . . . . . . . . . . 64
7 Accepting and Processing New Work . . . . . . . . . . . . 69
7.1 Processing User Requests . . . . . . . . . . . . . . 69
7.2 Publicly Available Specifications . . . . . . . . . 71
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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (Working)
2.3 Formation of New Special Interest Groups
Special Interest Groups are formed at the pleasure of the Plenary
Assembly. The formation requires two separate Workshop meetings.
At the first meeting, a proposal to establish a new SIG is made
at the Wednesday evening dinner meeting .
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) document history of standards development activity;
d) explain the OSE context of work;
e) state the "PROs" and CONs" of formulating a SIG;
f) identify a path towards stability of appropriate base
standards, or Public Domain specifications;
g) include a draft charter, statement of goals and plans
for reaching implementation agreements.
At the next Workshop meeting, a motion is considered at the
Voting Plenary Assembly. At the Dinner Meeting before the vote,
the proposal (to form a new SIG) is discussed. 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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (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 March 1994 (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;
g) SIGs' with appropriate assistance of the OIW Secretariat
should:
1) Provide electronic copies of all approved working
documents, profiles, and agreements to the OIW editor.
Where possible, identify locations(s) of or an index to
provisional draft international standardized profiles
available in electronic form;
2) Assist in making all standards referenced in the
20
Part 1 - Workshop Policies and Procedures March 1994 (Working)
aforementioned available in electronic form and on-line
in support of item 1;
3) Facilitate the timely development of reference
implementations. (Our objective is to have at least
two interoperable implementations available, with a
least on implementation in the public domain.);
4) Conformance test suites should be developed
concurrently with proposed profiles. (Our objective is
to have interoperable implementations available at the
same time as profiles.);
5) Assist in the development of additional on-line
registers of conformance/interoperability tested
products.
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
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.
21
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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;
22
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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;
23
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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.
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).
24
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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:
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:
25
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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
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);
26
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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.
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;
27
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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;
28
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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:
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
29
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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
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:
30
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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:
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
31
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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.
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.
32
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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
33
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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
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
34
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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;
35
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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
36
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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:
a) Develop implementors' agreements;
b) Provide input to national and international
standards organizations on RDA-related standards
and profiles;
c) Coordinate with other organizations on matters
relevant to RDA;
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
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
37
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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;
38
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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
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.
39
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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.
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.
40
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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;
41
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
d) Specifically:
1) Identify Organizations to Harmonize with (e.g..,
AOW, EWOS);
2) Develop Process for Issue Identification and
Notification;
42
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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;
43
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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
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.
44
Part 1 - Workshop Policies and Procedures March 1994 (Working)
4.8.18 LIBRARY APPLICATIONS DRAFT CHARTER
a) Background:
OSI application layer protocols have been standardized
for two library applications; Information Retrieval
(IR) and Interlibrary Loan (ILL). For IR, ISO 10162
and 10163 are the service definition and protocol
specification for "Search and Retrieve," known as SR.
Corresponding to SR, there is a U.S. standard,
ANSI/NISO Z39.50; SR is a compatible subset of Z39.50
(the term "IR" is generic and encompasses SR and
Z39.50). For LL, ISO 10160 and 10161 are the service
definition and protocol specifications.
Information Retrieval:
The distributed information retrieval application
supports the open interconnection of database
users with database providers. In the IR
client/server model, a database user interacts
with its local IR system, interfaced to the client
on the local system, which communicates with the
server on the remote system, interfaced with the
remote database search engine. The client and
server communicate according to the IR protocol,
which specifies basic information retrieval
operations as well as the means to express the
semantics of a query. Although the protocol was
originally intended for use with bibliographic
databases, it is planned to be used for retrieval
of various types of information including
chemical, patent, legal, public utility,
financial, medical, and full-text.
Interlibrary Loan:
The ILL protocol incorporates the sequences of
messages that occur in an ILL transaction between
a borrowing library and a lending library.
Interlibrary loan is a messaging application, and
as such, the ILL protocol requires support of a
messaging protocol (e.g., X.400). The protocol is
analogous to the X.400 P1 protocol.
b) Scope:
1) To provide an open forum for development of
implementation agreements based on standards and
45
Part 1 - Workshop Policies and Procedures March 1994 (Working)
profiles pertaining to IR and ILL protocols;
2) To develop stable agreements between vendors and
users for the implementation of interoperable products;
3) To examine IR and ILL use of and relation to other
upper layer protocols: ACSE, Presentation, Session,
Directory Services, FTAM, and X.400;
4) To develop application context definitions for the
IR and ILL protocols;
5) To contribute to the progression of ISPs for IR and
ILL;
6) To identify the need for OSI objects for IR,
including attribute sets, diagnostic sets, syntaxes,
resource report formats;
7) To act as registration authority for OIW IR and ILL
objects;
8) To conduct liaison with:
a) standards bodies such as NISO, ISO TC46, ISO
SC21, ANSI X3T5;
b) other implementor groups working on IR and ILL
harmonization such as ZIG, ZIT, IFOBS;
c) other regional workshops, namely, EWOS and
AOW;
d) SGFS;
e) other SIGs, as necessary, to develop
application contexts where ASEs are combined, such
as IR and Directory Services, or ILL and FTAM;
9) To provide input to the relevant standards bodies
concerning defects, provide feedback on proposed
changes to the standards, and where appropriate,
recommend changes and enhancements;
c) High Priority Work Items:
1) Contribute to the development of PDISP ALD11: for
IR in connection-oriented mode (see note);
46
Part 1 - Workshop Policies and Procedures March 1994 (Working)
2) Develop A-profile for IR using OSI upper layers
(ACSE, presentation, session) for use with TCP/IP;
3) Develop profile for IR directly over TCP/IP;
4) Develop profile for ILL using SMTP;
5) Contribute to the development o PDISP ALD22: for
ILL using IPMS (see note);
d) Low Priority Work Items:
1) Contribute to the development of PDISP ALD21: for
ILL in connection-oriented mode (see note);
2) Contribute to the development of PDISP ALD251: for
ILL in mixed mode, connection-oriented and IPMS (see
note);
3) Contribute to the development of PDISP ALD322: for
combined IR and ILL (see note);
4) Specify use of security functions for IR;
5) Specify use of directory functions for IR;
6) Specify use of directory functions for ILL.
NOTE - ALDxxx refers to the taxonomy for "Library and
Documentation" application profiles which has been proposed
for inclusion in TR-10000.
4.8.19 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;
47
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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) Postscript, PCL, SPDL;
3) ODA DTIF (Spreadsheet extension)
4.8.20 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);
48
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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 work items:
1) Profile for an open systems ISEE ;
2) Define the relationship of the OSE Reference Model
to the Framework and PSE Reference Models (NIST SP 500-
211 and 500-213);
3) Compile a list of standards and public
specifications relevant to specifying ISEEs.
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.
49
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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
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.
50
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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:
51
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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.
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
52
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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.
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
53
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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
54
Part 1 - Workshop Policies and Procedures March 1994 (Working)
"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
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
55
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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:
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:
56
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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.
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 new 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
57
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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:
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
58
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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)
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
59
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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
(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
60
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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
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
61
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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.
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.
62
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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.
63
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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;
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
64
Part 1 - Workshop Policies and Procedures March 1994 (Working)
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).
65
Part 1 - Workshop Policies and Procedures March 1994 (Working)
66
Part 1 - Workshop Policies and Procedures March 1994 (Working)
67
Part 1 - Workshop Policies and Procedures March 1994 (Working)
68
Part 1 - Workshop Policies and Procedures March 1994 (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
69
Part 1 - Workshop Policies and Procedures March 1994 (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
70
Part 1 - Workshop Policies and Procedures March 1994 (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
71
Part 1 - Workshop Policies and Procedures March 1994 (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
72
Part 1 - Workshop Policies and Procedures March 1994 (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;
73
