1/COSS: New RFC Process (#4)

Making changes to COSS to reflect new RFC process. --------- Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com>
vacp2p · Aug 9, 2024 · ed2c68f · ed2c68f
1 parent eb25cd0
commit ed2c68f
Showing 1 changed file with 76 additions and 25 deletions.
diff --git a/vac/1/coss.md b/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 <oskarth@titanproxy.com>
+editor: Daniel Kaiser <danielkaiser@status.im>
 contributors:
+  - Oskar Thoren <oskarth@titanproxy.com>
   - Pieter Hintjens <ph@imatix.com>
   - André Rebentisch <andre@openstandards.de>
   - Alberto Barrionuevo <abarrio@opentia.es>
   - Chris Puttick <chris.puttick@thehumanjourney.net>
   - Yurii Rashkovskii <yrashk@gmail.com>
-  - 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,21 +23,23 @@ 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
+- raw specifications will not be assigned numbers
+- section explaining the [IFT](https://free.technology/) Request For Comments specification process managed by the Vac service department
 
 ## 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;
 either version 3 of the License, or (at your option) any later version.
 
-This Specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
+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.
 
@@ -70,52 +73,68 @@ 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
 
 COSS is designed around fast, easy to use communications tools.
 Primarily, COSS uses a wiki model for editing and publishing specifications texts.
 
-* The *domain* is the conservancy for a set of specifications in a certain area.
-* Each domain is implemented as an Internet domain, hosting a wiki and optionally other communications tools.
-* Each specification is a set of wiki pages, together with comments, attached files, and other resources.
-* Important specifications may also exist as subdomains, i.e. child wikis.
+* The *domain* is the conservancy for a set of specifications.
+* The *domain* is implemented as an Internet domain. 
+* Each specification is a document together with references and attached resources.
+* A *sub-domain* is a initiative under a specific domain.
 
-Individuals can become members of the domain by completing the necessary legal clearance.
+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.
-New versions of the same specification will have new numbers.
+Specifications exist as multiple pages, one page per version,
+(discussed below in "Branching and Merging"),
+which should be assigned URIs that MAY include an number identifier.
+
+Thus, we refer to new specifications by specifying its domain, its sub-domain and short name.
+The syntax for a new specification reference is:
+
+    <domain>/<sub-domain>/<shortname>
+
+For example, this specification should be **rfc.vac.dev/vac/COSS**, 
+if the status were **raw**.
+
+A number will be assigned to the specification when obtaining **draft** status. 
+New versions of the same specification will be assigned a new number.
 The syntax for a specification reference is:
 
-    <domain>/spec/<number>/<shortname>
+    <domain>/<sub-domain>/<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.
+Specifications (excluding raw specifications) carries a different number including branches.
 
 ## COSS Lifecycle
 
 Every specification has an independent lifecycle that documents clearly its current status.
+For a specification to receive a lifecycle status,
+a new specification SHOULD be presented by the team of the sub-domain.
+After discussion amongst the contributors has reached a rough consensus,
+as described in [RFC7282](https://www.rfc-editor.org/rfc/rfc7282.html),
+the specification MAY begin the process to upgrade it's status.
 
-A specification has six possible states that reflect its maturity and contractual weight:
+A specification has five possible states that reflect its maturity and contractual weight:
 
 ![Lifecycle diagram](./images/lifecycle.png)
 
 ### Raw Specifications
 
 All new specifications are **raw** specifications.
 Changes to raw specifications can be unilateral and arbitrary.
-Those seeking to implement a raw specification should ask for it to be made a draft specification.
+A sub-domain MAY use the **raw** status for new specifications that live under their domain.
 Raw specifications have no contractual weight.
 
 ### Draft Specifications
 
-When raw specifications can be demonstrated, they become **draft** specifications.
+When raw specifications can be demonstrated, 
+they become **draft** specifications and are assigned numbers.
 Changes to draft specifications should be done in consultation with users.
 Draft specifications are contracts between the editors and implementers.
 
@@ -143,7 +162,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,12 +176,17 @@ 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
 
 Any member of the domain MAY branch a specification at any point.
 This is done by copying the existing text, and creating a new specification with the same name and content, but a new number.
+Since **raw** specifications are not assigned a number,
+branching by any member of a sub-domain MAY differentiate specifications based on date, contributors, or 
+version number within the document.
 The ability to branch a specification is necessary in these circumstances:
 
 * To change the responsible editor for a specification, with or without the cooperation of the current responsible editor.
@@ -203,9 +227,36 @@ This will enable programmatic access to specification metadata.
 | **editor**       | editor name/email    | string | Oskar Thoren <oskarth@titanproxy.com>                                                                                                                                                                                                      |
 | **contributors** | contributors         | list   | - Pieter Hintjens <ph@imatix.com><br> - André Rebentisch <andre@openstandards.de><br> - Alberto Barrionuevo <abarrio@opentia.es><br> - Chris Puttick <chris.puttick@thehumanjourney.net><br> - Yurii Rashkovskii <yrashk@gmail.com> |
 
-### Specification Template
-
-Standards Track specifications SHOULD be based on the [Vac RFC template](./images/template.md).
+### IFT/Vac RFC Process
+
+> [!Note]
+This section is introduced to allow contributors to understand the IFT 
+(Institute of Free Technology) Vac RFC specification process.
+Other organizations may make changes to this section according to their needs.
+
+Vac is a department under the IFT organization that provides RFC (Request For Comments) specification services.
+This service works to help facilitate the RFC process, assuring standards are followed.
+Contributors within the service SHOULD assist a *sub-domain* in creating a new specification, 
+editing a specification, and promoting the status of a specification along with other tasks.
+Once a specification reaches some level of maturity by rough consensus,
+the specification SHOULD enter the [Vac RFC](rfc.vac.dev) process.
+Similar to the IETF working group adoption described in [RFC6174](https://www.rfc-editor.org/rfc/rfc6174.html), 
+the Vac RFC process SHOULD facilitate all updates to the specification.
+
+Specifications are introduced by projects, 
+under a specific *domain*, with the intention of becoming technically mature documents.
+The IFT domain currently houses the following projects:
+- [Status](status.app)
+- [Waku](https://waku.org/)
+- [Codex](https://codex.storage/)
+- [Nimbus](https://nimbus.team/)
+- [Nomos](https://nomos.tech/)
+
+When a specification is promoted to *draft* status, 
+the number that is assigned MAY be incremental 
+or by the *sub-domain* and the Vac RFC process.
+Standards track specifications MUST be based on the [Vac RFC template](../template.md) before obtaining a new status.
+All changes, comments, and contributions SHOULD be documented.
 
 ## Conventions