1/COSS: New RFC Process

vac/1/coss.md

@@ -4,14 +4,15 @@ title: 1/COSS
 name: Consensus-Oriented Specification System
 status: draft
 category: Best Current Practice
-editor: Oskar Thoren <[email protected]>
+editor: Daniel Kaiser <[email protected]>
 contributors:
+  - Oskar Thoren <[email protected]>
   - Pieter Hintjens <[email protected]>
   - André Rebentisch <[email protected]>
   - Alberto Barrionuevo <[email protected]>
   - Chris Puttick <[email protected]>
   - Yurii Rashkovskii <[email protected]>
-  - Daniel Kaiser <danielkaiser@status.im>
+  - Jimmy Debe <jimmy@status.im>
 ---
 
 This document describes a consensus-oriented specification system (COSS) for building interoperable technical specifications.
@@ -22,15 +23,15 @@ It is equivalent except for some areas:
 
 - 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.rfc-editor.org/rfc/rfc2026.txt],
+- 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;
 - standards track specifications SHOULD follow a specific structure that both streamlines editing,
   and helps implementers to quickly comprehend the specification
 - specifications MUST feature a header providing specific meta information
 
 ## License
 
-Copyright (c) 2008-22 the Editor and Contributors.
+Copyright (c) 2008-24 the Editor and Contributors.
 
 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;
@@ -70,7 +71,6 @@ Principles:
 * The process should allow deprecation of old specifications.
 
 Specifications should take minutes to explain, hours to design, days to write, weeks to prove, months to become mature, and years to replace.
-
 Specifications have no special status except that accorded by the community.
 
 ## Architecture
@@ -86,23 +86,37 @@ Primarily, COSS uses a wiki model for editing and publishing specifications text
 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.
 
-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.
+Specifications exist as multiple pages, one page per version,
+(discussed below in "Branching and Merging"). 
+which may be assigned URIs that MAY include an incremental number.
+
+Thus, we refer to new specifications by specifying its domain and short name.
+The syntax for a new specification reference is:
+
+    <domain>/project/<shortname>
+
+For example, this specification is **rfc.vac.dev/vac/COSS**, 
+if the current status is **raw**.
+
+When awarded **draft** status, a number will be assigned to the specification. 
 New versions of the same specification will have new numbers.
 The syntax for a specification reference is:
 
-    <domain>/spec/<number>/<shortname>
+    <domain>/project/<number>/<shortname>
 
-For example, this specification is **rfc.vac.dev/spec/1/COSS**.
+For example, this specification is **rfc.vac.dev/vac/1/COSS**.
 The short form **1/COSS** may be used when referring to the specification from other specifications in the same domain.
 
 Every specification (including branches) carries a different number.
 
 ## COSS Lifecycle
 
 Every specification has an independent lifecycle that documents clearly its current status.
-
-A specification has six possible states that reflect its maturity and contractual weight:
+For a specification to receive a lifecycle status,
+a new specification SHOULD be presented by the project team.
+After discussion amongst the contributors has occurred for an unspecific amount of time,
+the specification MAY begin the process to upgrade a status.
+A specification has five possible states that reflect its maturity and contractual weight:
 
 ![Lifecycle diagram](./images/lifecycle.png)
 
@@ -143,7 +157,7 @@ Retired specifications have no contractual weight.
 Deleted specifications are those that have not reached maturity (stable) and were discarded.
 They should not be used and are only kept for their historical value.
 Only Raw and Draft specifications can be deleted.
-
+ 
 ## Editorial control
 
 A specification MUST have a single responsible editor,
@@ -157,7 +171,9 @@ Unlike the original C4 process however, it is RECOMMENDED to use CC0 as a more p
 We SHOULD NOT use GPL or GPL-like license.
 One exception is this specification, as this was the original license for this specification.
 
-The editor is responsible for accurately maintaining the state of specifications and for handling all comments on the specification.
+The editor is responsible for accurately maintaining the state of specifications, 
+for retiring different versions that may live in other places and 
+for handling all comments on the specification.
 
 ## Branching and Merging
 
@@ -205,7 +221,7 @@ This will enable programmatic access to specification metadata.
 
 ### Specification Template
 
-Standards Track specifications SHOULD be based on the [Vac RFC template](./images/template.md).
+Standards Track specifications SHOULD be based on the [Vac RFC template](../template.md).
 
 ## Conventions