An SFF
Specification does not have a requirement for consensus
to justify publication. A technical error can cause a Specification
to delay until the error is corrected, unless it is an unresolvable
issue between members e.g a dimension difference. The omission
of a dimension is a technical error which would cause a
delay to include it, and a re-balloting.
A Specification
is eligible for Publishing when all outstanding technical
issues have been addressed. Members may participate in developing
a Specification and then vote against it for Publication
on political or marketing or some other grounds. These are
not sufficient to prevent publication e.g. an SFF Specification
may be published with only one member in favor if it is
technically accurate.
Readers
of the Specification can judge its value based on content
and the degree of support indicated on the second page of
the Specification.
Companies
which vote support of, or opposition to, an SFF Specification
will be identified in the early pages of the specification.
OEMs and other parties interested in knowing what combination
of functions and features are supported by which vendors
may use SFF specifications to help form a judgment on what
they prefer (there may be more than one specification to
address similar problems).
The
general sequence of developing an SFF Specification are:
-
Documented proposal submitted by a member. or SSWG proposed
to address an industry issue under leadership of a member.
-
Members vote on the proposal and if accepted, the proposal
becomes a Development project.
-
A document is prepared for members to critique and a vote
is balloted. If accepted, it becomes an Approved project
and control of the document moves from the SSWG leader
to the Chairman of the SFF Committee.
-
Editorial and technical changes as a result of member
comments result in a revision prepared for balloting prior
to Publication.
-
If accepted, the Specification is Published.
An SFF
Specification will be valid for one year after the members
of the SFF Committee approve the latest Published revision.
At the end of one year, the SFF Specification will be balloted
again for action:
-
Submittal to a standards organization to be incorporated
in a standard
-
Re-affirm it for continued publication as an SFF Specification
-
No action (the Specification will no longer be distributed)
SFF
Specifications are identified as follows:
| F
= Forwarded |
The
document has been approved by the members for forwarding
to a formal standards body. |
| P
= Published |
The
document has been balloted by members and is available
as a published SFF Specification. |
| A
= Approved |
The
document has been approved by ballot of the members
and is in preparation as an SFF Specification. |
| C
= Canceled |
The
project was canceled, and no Specification was Published. |
| D
= Development |
The
document is under development at SFF. |
| E
= Expired |
The
document has been published as an SFF Specification,
and the members voted against re- publishing it when
it came up for annual review. |
| e
= electronic |
Used
as a suffix to indicate an SFF Specification which
has Expired but is still available in electronic form
from SFF e.g. a specification has been incorporated
into a draft or published standard which is only available
in hard copy. |
| i
= information |
Information
The document has no SFF project activity in progress,
but it defines features in developing industry standards.
The document was provided by a company, editor of
an accredited standard in development, or an individual.
It is provided for broad review (comments to the author
are encouraged). |
| s
= submitted |
The
document is a proposal to the members for consideration
to become an SFF Specification. |
