From BJSHEP@ausvmq.vnet.ibm.com Mon May  4 16:07:55 1992
Received: from vnet.ibm.com by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8)
	id AA26428; Mon, 4 May 92 16:07:55 +0200
Message-Id: <9205041407.AA26428@dkuug.dk>
Received: from AUSVMQ by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 4537;
   Mon, 04 May 92 10:07:27 EST
Date: Mon, 4 May 92 09:06:34 CDT
From: BJSHEP@ausvmq.vnet.ibm.com
To: sc24@dkuug.dk
X-Charset: ASCII
X-Char-Esc: 29

ISO ASKED FOR COMMENTS ON A COMPARISON OF JTC1 RULES AND THE NEW
IEC FAST RULES FOR STANDARDS DEVELOPMENT.  I WILL ACCEPT COMMENTS
ON MY PROPOSED INPUT UP TO MAY 25.  OTHER MEETINGS AND TRAVEL FORCE
THIS CUTOFF DATE.




TO: C J Favre
    ISO Deputy Secretary-General

FROM: B J Shepherd
      JTC1 SC24 Chairman

SUBJECT: Comments on "Procedures for accelerating the development
         of international standards"




It has not been possible to get formal review by SC24's membership of
the points below.  However, I believe the views expressed reflect the
opinions of a majority of SC24's participants.  The first comments
address the summary comparison of the procedures of IEC/ISO, new IEC,
and JTC1.

1.  During committee stage, three months is not sufficient for review of
a 500 page document (not uncommon for SC24) by informed experts, let
alone for a public review as typically done within some countries.

2.  With standards of 500 (or more) pages, it is impossible to produce
a new CD text during the course of a one week meeting.  For comments
from a first CD circulation, even two weeks is probably insufficient.

3.  For our standards, we must have the option (nearly always exercised)
of submitting camera ready text.

4.  Even when submitting camera ready text, the project editor needs the
opportunity to review proofs before publication.

5.  Finally, for projects in new/evolving areas of technology, three
years may be inadequate time to progress from NP registration to final
text (since the New IEC rules treat DIS as final---no comments allowed).

This leads me to the subject of other techniques to accelerate the
production of standards.  First, I think that quality should be given
equal weight with development schedule.  While timeliness of IS text is
important, sacrificing quality for the sake of schedule will not help the
reputation of ISO.

There is an additional special case which may apply to some projects in
JTC1 (including one or two in SC24).  At times, standards are needed in a
new/evolving area of technology to define a stable environment that will
encourage commercial implementations.  These "anticipatory" standards
require extra attention to detail to ensure their quality.

I have one more comment on the utility of standards.  SC24, as well as
some other JTC1 SCs, emphasise the acquisition of user requirements in
the early stage of project definition.  In this paragraph I call an
organization which inplements an interface standard an "implementor".
Other organizations which write applications which reside "above" the
Application Programming Interface are identified as "users".  While
the initial requirements phase includes input from both "users" and
"implementors", during development of a standard there is usually
minimum involvment from "users".  I believe increased user involvment
at all stages of the standardization process would be beneficial.