[lsb-discuss] Proposal on LSB "Optional" components

[Nick Stoughton]

On Wed, 2007-09-19 at 12:23 -0400, Theodore Tso wrote:
> On Tue, Sep 18, 2007 at 08:54:00AM -0700, Wichmann, Mats D wrote:
> > 
> > 1. rename this concept as Trial Use Module (or
> > some similar name). I believe this conveys more 
> > of the transient intent than the term Optional.
> 
> I like this idea; how about using the term "Experimental"?  Long run
> we may end up wanting to adopt some of the RFC status tags, including
> at some point in the future, "Historic".  :-)

As a point of reference, IEEE uses "Trial Use Standard", ISO uses
"Technical Report type 2" (very descriptive!!), and IETF uses
"Experimental" and "Informational". If we pick one of these, (and please
don't say "Type 2 Technical Report"!), then certain classes of people
will have pre-conceived ideas about what that name means.

Each organization also has a set of policies and procedures around such
specifications, and it may help to see them (not that we have to follow
any of them):

IETF:
4.2.1  Experimental

   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).  An
   Experimental specification may be the output of an organized Internet
   research effort (e.g., a Research Group of the IRTF), an IETF Working
   Group, or it may be an individual contribution.

========================================================================
IEEE:


Trial-use standards 
Sometimes a standard doesn't follow this development path quite as
smoothly as it should. Perhaps your working group isn't able to come to
immediate agreement, or perhaps the technology being standardized is
evolving rapidly. When you feel you need to receive input from a broad
base in your technical community or if you're having difficulty
resolving certain negative ballots, you might want to consider the
option of distributing your standard as a trial-use standard. 

Trial-use standards are valid for a two-year period. They are
distributed in the same broad manner as full-status standards, but they
may not yet be at a final stage of development. At the end of the
two-year period, the standard can either be accepted as a full-status
standard (if no comments were received) if the sponsor recommends this,
or it can be returned to the working group for further development and
balloting. 

No ballot is required to upgrade a standard from trial use to full
status if no comments (or purely editorial comments) were received. The
sponsor merely submits a request to upgrade the standard to full-use to
RevCom. If technical comments were received and changes are required,
then a PAR for revision of the standard needs to be submitted to NesCom.
A cut-off date for comments is included in the published standard to
allow the working group time to revise and reballot the standard prior
to the end of the trial-use period should that be needed. 

The trial-use method has proven to be very effective for some sponsors.
It does allow broad use and adoption of a standard over which there is
general agreement but still some uncertainty. If you have reached an
impasse in your standards development activity, think of exploring the
benefits of the trial-use standard. 

========================================================================
ISO/IEC:
16.2.2 Type 2 Technical Report
When the subject in question is still under technical development or
where for any other reason there is the possibility of an agreement at
some time in the future, JTC 1 may decide that the publication of a TR
would be more appropriate.

16.2.4 Contents of Type 1 and Type 2 TRs
TRs of types 1 and 2 shall contain the following parts:
• Historical background;
• Explanation of the reasons why JTC 1 has considered it necessary to
publish a TR instead of an IS;
• Technical content.

16.4 Maintenance of Technical Reports
16.4.1 Type 1 and Type 2 TRs
16.4.1.1 TRs of types 1 and 2 shall be subject to review by JTC 1 not
later than three years after their publication. The aim of such a review
shall be to re-examine the situation which resulted in the publication
of a TR and if possible to achieve the agreement necessary for the
publication of an IS to replace the TR.
16.4.1.2 The SC responsible for the type 1 or type 2 TR project shall
make a recommendation to JTC 1 prior to the third year after
publication, stating whether the TR should be:
• Converted to an IS without change;
• Revised and published as an IS;
• Confirmed for continuation as a TR;
• Revised for publication as a revision to the TR;
• Withdrawn.
16.4.1.3 If the type 1 or type 2 TR is confirmed, there shall be another
JTC 1 review not more than three years later.

===========================================================================

-- 
Nick