recommending the use of a permissive licenses, such as CC0 (with the exception of this document); miscellaneous metadata, editor, and format/link updates; more inheritance from the [IETF Standards Process][https://www.">
recommending the use of a permissive licenses, such as CC0 (with the exception of this document); miscellaneous metadata, editor, and format/link updates; more inheritance from the [IETF Standards Process][https://www." />
Daniel Kaiser <ahref="mailto:danielkaiser@status.im">danielkaiser@status.im</a>
</li>
</ul><p>This document describes a consensus-oriented specification system (COSS) for building interoperable technical specifications.
COSS is based on a lightweight editorial process that seeks to engage the widest possible range of interested parties and move rapidly to consensus through working code.</p>
<p>This specification is based on <ahref="https://github.com/unprotocols/rfc/blob/master/2/README.md">Unprotocols 2/COSS</a>, used by the <ahref="https://rfc.zeromq.org/">ZeromMQ</a> project.
It is equivalent except for some areas:</p>
<ul>
<li>recommending the use of a permissive licenses, such as CC0 (with the exception of this document);</li>
<li>miscellaneous metadata, editor, and format/link updates;</li>
<li>more inheritance from the [IETF Standards Process][https://www.rfc-editor.org/rfc/rfc2026.txt],
e.g. using RFC categories: Standards Track, Informational, and Best Common Practice;</li>
<li>standards track specifications SHOULD follow a specific structure that both streamlines editing,
and helps implementers to quickly comprehend the specification</li>
<li>specifications MUST feature a header providing specific meta information</li>
</ul>
<h2id="license">
License
<aclass="anchor"href="#license">#</a>
</h2>
<p>Copyright (c) 2008-22 the Editor and Contributors.</p>
<p>This Specification is free software;
you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation;
either version 3 of the License, or (at your option) any later version.</p>
<p>This Specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.</p>
<p>You should have received a copy of the GNU General Public License along with this program;
if not, see <ahref="http://www.gnu.org/licenses">http://www.gnu.org/licenses</a>.</p>
<h2id="change-process">
Change Process
<aclass="anchor"href="#change-process">#</a>
</h2>
<p>This document is governed by the <ahref="spec/1">1/COSS</a> (COSS).</p>
<h2id="language">
Language
<aclass="anchor"href="#language">#</a>
</h2>
<p>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in
<p>The primary goal of COSS is to facilitate the process of writing, proving, and improving new technical specifications.
A “technical specification” defines a protocol, a process, an API, a use of language, a methodology,
or any other aspect of a technical environment that can usefully be documented for the purposes of technical or social interoperability.</p>
<p>COSS is intended to above all be economical and rapid, so that it is useful to small teams with little time to spend on more formal processes.</p>
<p>Principles:</p>
<ul>
<li>We aim for rough consensus and running code; <ahref="https://www.ietf.org/about/participate/tao/">inspired by the IETF Tao</a>.</li>
<li>Specifications are small pieces, made by small teams.</li>
<li>Specifications should have a clearly responsible editor.</li>
<li>The process should be visible, objective, and accessible to anyone.</li>
<li>The process should clearly separate experiments from solutions.</li>
<li>The process should allow deprecation of old specifications.</li>
</ul>
<p>Specifications should take minutes to explain, hours to design, days to write, weeks to prove, months to become mature, and years to replace.</p>
<p>Specifications have no special status except that accorded by the community.</p>
<h2id="architecture">
Architecture
<aclass="anchor"href="#architecture">#</a>
</h2>
<p>COSS is designed around fast, easy to use communications tools.
Primarily, COSS uses a wiki model for editing and publishing specifications texts.</p>
<ul>
<li>The <em>domain</em> is the conservancy for a set of specifications in a certain area.</li>
<li>Each domain is implemented as an Internet domain, hosting a wiki and optionally other communications tools.</li>
<li>Each specification is a set of wiki pages, together with comments, attached files, and other resources.</li>
<li>Important specifications may also exist as subdomains, i.e. child wikis.</li>
</ul>
<p>Individuals can become members of the domain by completing the necessary legal clearance.
The copyright, patent, and trademark policies of the domain must be clarified in an Intellectual Property policy that applies to the domain.</p>
<p>Specifications exist as multiple pages, one page per version of the specification (see “Branching and Merging”, below), which may be assigned URIs that include an incremental number.
Thus, we refer to a specification by specifying its domain, number, and short name.
New versions of the same specification will have new numbers.
<td>- Pieter Hintjens <ahref="mailto:ph@imatix.com">ph@imatix.com</a><!-- raw HTML omitted --> - André Rebentisch <ahref="mailto:andre@openstandards.de">andre@openstandards.de</a><!-- raw HTML omitted --> - Alberto Barrionuevo <ahref="mailto:abarrio@opentia.es">abarrio@opentia.es</a><!-- raw HTML omitted --> - Chris Puttick <ahref="mailto:chris.puttick@thehumanjourney.net">chris.puttick@thehumanjourney.net</a><!-- raw HTML omitted --> - Yurii Rashkovskii <ahref="mailto:yrashk@gmail.com">yrashk@gmail.com</a></td>
<p>Standards Track specifications SHOULD be based on the <ahref="https://github.com/vacp2p/rfc/blob/master/content/docs/rfcs/template/README.md">Vac RFC template</a>.</p>
<h2id="conventions">
Conventions
<aclass="anchor"href="#conventions">#</a>
</h2>
<p>Where possible editors and contributors are encouraged to:</p>
<ul>
<li>Refer to and build on existing work when possible, especially IETF specifications.</li>
<li>Contribute to existing specifications rather than reinvent their own.</li>
<li>Use collaborative branching and merging as a tool for experimentation.</li>
<li>Use Semantic Line Breaks: <ahref="https://sembr.org/">https://sembr.org/</a>.</li>
<p>It is RECOMMENDED to use color coding to indicate specification’s status. Color coded specifications SHOULD use the following color scheme:</p>
