SC22/WG15 N687

16 Oct 1996

RE: Convener Action Items Report from May 96 WG15 Meeting

9605-07 Convener - write a cover letter to National Bodies to consider the general issue of subsetting base standards from within profiles during their review of 1003.13. (rolled over from 9510-34, which came from RGCPA issue #6)

OPEN; 1003.13 not yet received for review; however issue has been surfaced to SC22 in the Proposed profile taxonomy

9605-10 Convener - request SC22 to terminate subdivision projects JTC1.22.21.03.02 (Administered Systems: Batch Services) and JTC1.22.21.01.04 (C Language Bindings: Batch API Administration Amendment). (rolled over from 9510-50 which came from R 95-326)

Closed: action taken at Sept. SC22 meeting

9605-15 Convener - consolidate the national body comments on N633 and N634 and report to SC22.

Closed, incorporated into report to SC22

9605-27 Convener - investigate the ISO procedures for limits on the number of amendments and how this relates to how they are accepted by regional bodies (like CEN).

Closed: The JTC1 directives place no limit on amendments (they are online at http://www.iso.ch/dire/jtc1/directives.html), but give ITTF the right to determine when to publish separately or integrated with the main text. The ISO Directives part 1 state: "2.10.3 Avoidance of proliferation of modifications: No more than two separate documents in the form of technical corrigenda or amendments shall be published modifying a current International Standard. The development of a third such document shall result in publication of a new edition of the International Standard" This does not limit amendments, but calls for consolidation as these are generated.

The regional body response is in flux. There is some interest in eliminating EN standards where ISO standards exist. This also relates to the way in which JTC1 and CEN have (and have not) developed a synchronization program. There is no stable answer at this time.

9605-28 Convener - contact each national body to verify their participation status in WG15 and obtain / verify e-mail addresses for each.

OPEN - initiated, in Oct. 96, but not closed yet.

9605-29 Convener - inform SC22 of the WG15 procedures for electronic balloting within WG15.

Done, see SC22 report

9605-35 Convener - investigate how we get registration and ballot done for PDISP documents (ie profiles).

Closed; request made to SC22 and SGFS leadership 6 Sept. 96 - process appears to be:

(Based on feedback from the SGFS Chair, Willem Wakker)

"According to SC22/N1820 the first two logical steps are done:

1- SC22 gets a NP approved. This is done (see SC22/N2102)

2- WG15 requests subdivision of the above NP. This is also done (I understand),

approval in London?

Then it gets interesting. According to N1820 step 3 is:

3- WG15 produces a taxonomy change proposal and an explanatory

report for the ISP, and sends this as a proposed liaison statement

to SC22. This is approved by a (letter) ballot at SC22 level.

After approval, the liaison is sent to SGFS

I think that this can be done immediately after approval of step 2.

Step 4 is kind of SGFS internal (TR 10000 procedures etc), the final step 5

syas again something about things to be done by SC22:

5- WG15 produces the ISPs together with the explanatory report

(see SGFS procedures), and sends this for `CD' ballot to SC22.

When this is approved the documents are forwarded to SGFS for

informal review and the production of a review report, and then

to JTC1 for DISP ballot.

I see no problem in progressing along to above lines. The only thing that

need to be done once the sub-division is approved (step 2) that is not

specified above is the process to get the ISP number (or project number;

normally here Bill would get in touch with Keith Brannon to get the next

IS number). For ISP this process is normally handled by the SGFS secretary

Peter Bessems at NNI (Peter.Bessems@nni.nl). I would suggest that Bill

contacts Peter about this issue. What might be helpful in this process is

if Jim (WG15) gives some thought on the document structure of the planned

ISP: will there be one single ISP with possibly multiple parts, or will

there several individual ISPs or what? If there is a need for more than one

ISP (number) is it then useful to try to allocate a small range of numbers?"

9605-51 Convener - notify SC21/WG4 that we have terminated the position of liaison to their group on the recommendation of that liaison that no further liaison activities are expected for the foreseeable future. (R 96-330)

OPEN; convener contact is though:

Japanese Industrial Standards Committee

c/o Standards Department

Ministry of International Trade and Industry

1-3-1, Kasumigaseki, Chiyoda-ku

Tokyo 100

9605-52 convener - forward the nominations of the following persons: Stephe Walli - JTC1 22.39 and JTC1 22.41 Barry Hedquist - JTC1 22.14515 and JTC1 22.37 Keld Simonsen - JTC1 22.21.01.01 and JTC1 22.14677 as project editors to SC22 for confirmation. (R 96-332).

Done, see report to SC22; also included additional nominees proposed by U.S. and confirmed by email ballot of WG15.

9605-58 Convener - notify SC22 that the following projects: JTC1 22.21.02.02 (UPE) JTC1 22.21.01.02.01 (Real Time) JTC1 22.21.01.02.02 (Threads) have been completed and integrated into the primary document, and since future revisions will be done as part of the main document, these work items may be terminated. (R 96-338)

Done, see SC22 Report

9605-59 Convener - request that SC22 extend the deadline of the following projects which have not reached the CD/PDAM registration within the required 3 year time limit (R 96-339): 22.21.01.01 9945-0 Language Indepent 22.21.01.03.01 9945-1 Transp. File Access 22.21.01.03.03 9945-1 Protocol Ind. Interfaces 22.21.03.03 15068-4 Print Administration 22.21.04.031 14519 Ada Real Time Binding 22.39 9945-1 System API addendum 22.40 9945-1 Real Time addendum

Done, See SC22 report

9605-60 Convener - forward the draft Taxonomy Change Proposal prepared by the U.S. member body to the SC22 Secretariat with the recommendation that it be forwarded to SGFS with appropriate header information as defined in WG15 N651. (R 96-340)

Done, See SC22 report

9605-61 Convener - request SC22's approval of appropriate Division of Work items to permit the work on POSIX OSE profiles (IEEE 1003.10, 1003.13) as defined in the Taxonomy Change Proposal (WG15 N643) and also request an appropriate Division of Work item for 1003.1j (advanced realtime). (R 96-341)

Done, See SC22 report

9605-62 Convener - notify SC22 of WG15's proposal (N649) for decision making by email (using ISO 646 format for documents) whereby a response or a request for a 15 day extension is due within 45 days of transmission and reminders will be sent out to non-respondents after 15 and 30 days, and encourages SC22 to implement a similar proposal. (R 96-342)

Done, See SC22 report

9605-64 Convener - get approval of the SC22 on the new synchronization plan as amended by WG15 N676. (R 96-343)

Done, See SC22 report

9605-67 Convener - call and conduct an editing meeting to create, approve, and forward to the SC22 Secretariat, a disposition of comments for IEEE 1003.1a System API Amendment (JTC1 22.39). (R 96-345)

OPEN; Reg ballot closes 12/96

9605-69 Convener - call and conduct an editing meeting to create, approve, and forward to the SC22 Secretariat, a disposition of comments for IEEE 1003.1f Transparent File Access (JTC1 22.21.01.03.01). (R 96-345)

OPEN; Reg ballot closes 12/96

9605-71 Convener - call and conduct an editing meeting to create, approve, and forward to the SC22 Secretariat, a disposition of comments for IEEE 1003.1g Protocol Independent Interface (JTC1 22.21.01.03.03). (R 96-345)

OPEN; Concurrent PDAM reg & ballot closes 12/96 [note there are issues with thisone]

9605-73 Convener - call and conduct an editing meeting to create, approve, and forward to the SC22 Secretariat, a disposition of comments for IEEE 1387.4 Print Administration (JTC1 22.15068-4). (R 96-345)

OPEN; Reg ballot closes 12/96

9605-75 Convener - call and conduct an editing meeting to create, approve, and forward to the SC22 Secretariat, a disposition of comments for IEEE 1003.1j Advanced Real Time Extensions (JTC1 project number not yet assigned). (R 96-346)

OPEN; Division of work approved by SC22 - See SC22 Report; balloting not yet initiated

9605-78 Convener - forward the WG15 recommendation contained in resolution 96.348 to SC22.

(CEN work plan), Done, See SC22 Report

7 Aug 1996

WG15 Report to SC22 for Sept. 1996 Meeting

Action requested of SC22:

1. Appointment of Project Editors: [res 332]

2. Withdrawal of Projects

3. Extension for Projects that have not reached CD within 3 years

4. WG15 Synchronization plan

5. Taxonomy recommendation for SC22 Profiles

6. Request for Division of work items

7. Endorsement of Fasttrack for Ada Real time extensions Fasttrack

8. Comments on JTC1 N3826 / SC22 N2039 --Action Plans on Conformity Assessment

9. Comments on JTC1 N4039 - SC22 N2105 - Electronic presentation of Standards-

10. GII standard and SC22:

11. Information Sought from SC22 Member Bodies and Working Relations

For Information of SC22

Documents Currently in Balloting - (& Date of ballot closing)

WG15 report attachment #1

Proposed TR10000-3 Taxonomy additions for SC22 POSIX based Profiles

Scenario/relationship positioning of PSE variants:

The POSIX Application Environment Profiles are developed with application software portability at the source code level for specific environments as their objective. Source code portability requires specification of at least one computer language as well as the interfaces defined in the POSIX standards, so these profiles typically include computer languages, and potentially include API's (Application Program Interface) for other services beyond the operating system (communications, database access, graphics, etc.) All of these profiles include a normative reference to IS 9945-1, the POSIX System Interface API.

There are four major segments defined here: the Interactive Systems Environment, , two High Performance Application Environments and a set of Real Time Application Environments. The interactive system environment corresponds with the traditional multi-user operating system set of services, with language development in C (or Ada as an alternative).

The real time environments range from embedded real time applications (settop devices, guidance control systems, etc.) which might not have any "rotating media", with steps up to a full blown environment that includes all of the "interactive systems environment" and expands it to include most of the real time options as well.

	Title of Work	Reference document from IEEE
PSE 01-HIP	Interactive Systems Environment Profile	1003.18
PSE 10-HIP	Supercomputing Application Environment Profile	1003.10
PSE 14-HIP	Multiprocessor Application Environment Profile	1003.14
PSE 51-P	Minimal Realtime System Profile	1003.13
PSE 52-P	Realtime Controller System Profile	1003.13
PSE 53-P	Dedicated Realtime System Profile	1003.13
PSE 54-IP	Multipurpose Realtime System Profile	1003.13

WG15 Report, attachment #2

WG15 Electronic Decision Making Process

Proposal on WG15 decision making by EMAIL 23 May 96

Note, most "decisions" related to actual standards drafts are handled by SC22. However, WG15 has decisions that need to be made, from endorsing action (such as forwarding a document to SC22 for balloting) or agreeing to a disposition of comments. Such decisions are made, ideally, "with no objections" ... seeking to identify any concerns that might be raised, and also to achieve consensus. Here is our recommendation on how we conduct this via electronic means as a result of the May 1996 meeting (resolution 342, Doc 649r):

The primary question raised will be "do you have any objections to the stated position (or recommendation)?" with room to expand on comments related to the recommendation.

And the question will be raised: "is this the response for your member body?" --- (WG's are primarily nominated experts, and may or may not be speaking for the member body ... but objections at the WG level from any expert should be considered.)

WG15 report, attachment #3

Subject: (wg15tag 1364) (SC22WG15.872) WG15 Action Item 9605-14

Date: July 17, 1996

From: Barry Hedquist; Chair; PASC Test Methods Working Group

The following response to the Conformity Assessment Action Plan was generated by the PASC Test Methods Working Group in Nashua.

Re: ISO/IEC JTC 1/SWG-CA N 197

ISO/IEC JTC 1 N 3826

ISO/IEC JTC 1/ SC 22 N 2039

ISO/IEC JTC 1/ SC 22/ WG 15 N 633

1. ISO/IEC JTC 1/SC 22/WG 15 requested the US member body to respond to JTC1 N 3826, "Recommended Request from JTC1 for Action Plans and Information form SCs and SGFS on Implementation of JTC 1 Policy on Conformity Assessment and JTC 1 Policy on Interoperability".

2. The main body of work within WG15 has been the development of application portability interfaces (APIs) for POSIX. This work has been carried out by the IEEE Computer Society's Portable Applications Standards Committee (PASC). Since the focus of this work is on application portability interfaces, the answers given here are provided in the context of conformity assessment of those interfaces, rather than interoperability assessment.

3. Concerning the request for information on implementation methodologies:

3.1 Assessment Methodologies

a). What is the practice and experience with regard to conformity to standards and interoperability of IT systems?

IEEE/CS/PASC standards are written so they can be implemented and those implementations can be certified as conforming. These standards also require that implementations provide documentation describing specific details of the implementation. All of the standards contain a conformance section describing the conformance requirements. Some of the API standards have corresponding test method standards developed within IEEE, and forwarded to ISO, and test method implementations (test suites) developed by organizations outside the WG15 community (commercial and government).

b) To what extent is there a need to differentiate between conformity assessment and interoperability assessment?

We see the two as different activities. Our APIs do not define interoperability requirements, thus we focus only on conformity assessment.

c) Are reference implementations of standards used? If so...

Reference implementations are not used, however we have developed a standard that defines requirements for test method specifications and implementations.

d) Are formal specifications of standards used? If so...

No, formal description techniques have not yet been used for conformity assessment, however we have developed rigorous test method specifications.

e) What methodologies and tools (including formal techniques) already exist and are in use for assessment of conformity and interoperability.

There are existing test method specification standards, and conformance documents is use today by government and industry for the development of test method implementations (test suites) and use by accredited testing laboratories.

f) What is the standardization status of each of the methodologies and tools.

Some complete, some in process, some in planning. [See IS 13210 and 14515, wg15 convener]

g) To what extent, and in what manner is there a need for conformity assessment to be complimented by interoperability assessment.

None, for us.

h) What, if any, additional standardization is needed to cover interoperability assessment.

None for us - we don't define interoperability requirements.

i) To what extent, and in what manner is it possible to rely upon and recognize, transpose, or reference existing material form sources outside the SC/SGFS, e.g. publicly available specifications for existing test methods or suites.

We don't take nothing and use it blindly. Everything must be subjected to a public review process, and possible modification.

j) Are there areas which are important for current and future market needs, for which conformity assessment and/or interoperability assessment methodologies need to be developed and/or standardized, and if so, which are the high priority ones?

We believe that the area of greatest need and importance is for conformity assessment methodologies and standards for interface standards which promote application portability.

3.2 Key interfaces for Interoperability

These questions all deal with interoperability and are not applicable to our program of work. However, we do believe that application portability is required to promote interoperability. As such, the key standards are the POSIX Application Portability Interfaces (APIs) and their associated test method standards.

Other WG15 Member input:

The UK MB comments to WG15 are that, while the aims of the JTC1 papers are to be applauded, we believe that sourcing and directing the required effort at SC and WG level will be problematic.

Experts are drawn to contribute to the standards process usually because they (or their employers) see a need for a document to clarify existing practice or to point a way for emerging technology. The experts are volunteers but the costs to their employers are not insubstantial. These 'technology' experts are not necessarily the same group of people with expertise in conformity assessment, and JTC1 will need to attract people from that group in order to achieve its goals.

This implies extra costs, not just in financial terms, but also in terms of the management of the standardisation process, where different groups of experts may need to be shepherded through the sequence necessary to create a single 'conforming' standard.

Management of the process will have to take account, from the very start of a project, whether conformity assessment is likely to be a requirement of that project, and if so whether the necessary effort is available. In some circumstances, where a project is deemed to be of critical importance but where conformity experts are not available for whatever reason, JTC1 may have to decide whether to proceed at all, and if so whether to attempt to 'buy in' the conformity expertise; the effects here could be very extensive indeed.

WG15 report attachment #4

WG15 N676 CTN6-r0 --, 23 May 1996