3.3 KiB
| title | name | status | category | editor | contributors | sidebar_position |
|---|---|---|---|---|---|---|
| XX/(WAKU2|LOGOS|CODEX|*)-TEMPLATE | (Waku v2 | Logos | Codex) RFC Template | (raw|draft|stable) | (Standards Track|Informational|Best Current Practice) | Daniel Kaiser <danielkaiser@status.im> | 1 |
- Status: (raw|draft|stable)
- Category: (Standards Track|Informational|Best Current Practice)
- Editor: Daniel Kaiser <danielkaiser@status.im>
(Info, remove this section)
This section contains meta info about writing RFCs. This section (including its subsections) MUST be removed.
COSS explains the Vac RFC process.
Tags
The tags metadata SHOULD contain a list of tags if applicable.
Currently identified tags comprise
waku/core-protocolfor Waku protocol definitions (e.g. store, relay, light push),waku/applicationfor applications built on top of Waku protocol (e.g. eth-dm, toy-chat),
Abstract
Background / Rationale / Motivation
This section serves as an introduction providing background information and a motivation/rationale for why the specified protocol is useful.
Theory / Semantics
A standard track RFC in stable status MUST feature this section.
A standard track RFC in raw or draft status SHOULD feature this section.
This section SHOULD explain in detail how the proposed protocol works.
It may touch on the wire format where necessary for the explanation.
This section MAY also specify endpoint behaviour when receiving specific messages, e.g. the behaviour of certain caches etc.
Wire Format Specification / Syntax
A standard track RFC in stable status MUST feature this section.
A standard track RFC in raw or draft status SHOULD feature this section.
This section SHOULD not contain explanations of semantics and focus on concisely defining the wire format.
Implementations MUST adhere to these exact formats to interoperate with other implementations.
It is fine, if parts of the previous section that touch on the wire format are repeated.
The purpose of this section is having a concise definition of what an implementation sends and accepts.
Parts that are not specified here are considered implementation details. Implementors are free to decide on how to implement these details.
An optional implementation suggestions section may provide suggestions on how to approach implementation details, and, if available, point to existing implementations for reference.
Implementation Suggestions (optional)
(Further Optional Sections)
Security/Privacy Considerations
A standard track RFC in stable status MUST feature this section.
A standard track RFC in raw or draft status SHOULD feature this section.
Informational RFCs (in any state) may feature this section.
If there are none, this section MUST explicitly state that fact.
This section MAY contain additional relevant information, e.g. an explanation as to why there are no security consideration for the respective document.
Copyright
Copyright and related rights waived via CC0.
References
References MAY be subdivided into normative and informative.
normative
A list of references that MUST be read to fully understand and/or implement this protocol. See RFC3967 Section 1.1.
informative
A list of additional references.