mirror of https://github.com/vacp2p/rfc-index.git
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>
This commit is contained in:
Jimmy Debe
GitHub
parent
eb25cd06d6
commit
ed2c68f072
|
|
@ -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,7 +73,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
|
||||
|
|
@ -78,31 +80,47 @@ Specifications have no special status except that accorded by the community.
|
|||
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:
|
||||
|
||||
|
||||
|
||||
|
|
@ -110,12 +128,13 @@ A specification has six possible states that reflect its maturity and contractua
|
|||
|
||||
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
|
||||
### IFT/Vac RFC Process
|
||||
|
||||
Standards Track specifications SHOULD be based on the [Vac RFC template](./images/template.md).
|
||||
> [!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
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue