82 lines
3.2 KiB
Markdown
82 lines
3.2 KiB
Markdown
|
---
|
||
|
|
title: XX/(WAKU2|LOGOS|CODEX|*)-TEMPLATE
|
||
|
|
name: (Waku v2 | Logos | Codex) RFC Template
|
||
|
|
status: (raw|draft|stable)
|
||
|
|
category: (Standards Track|Informational|Best Current Practice)
|
||
|
|
editor: Daniel Kaiser \<danielkaiser@status.im\>
|
||
|
|
contributors:
|
||
|
|
sidebar_position: 1
|
||
|
|
---
|
||
|
|
|
||
|
|
# (Info, remove this section)
|
||
|
|
|
||
|
|
This section contains meta info about writing RFCs.
|
||
|
|
This section (including its subsections) MUST be removed.
|
||
|
|
|
||
|
|
[COSS](https://rfc.vac.dev/spec/1/) explains the Vac RFC process.
|
||
|
|
|
||
|
|
## Tags
|
||
|
|
|
||
|
|
The `tags` metadata SHOULD contain a list of tags if applicable.
|
||
|
|
|
||
|
|
Currently identified tags comprise
|
||
|
|
|
||
|
|
* `waku/core-protocol` for Waku protocol definitions (e.g. store, relay, light push),
|
||
|
|
* `waku/application` for 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](https://creativecommons.org/publicdomain/zero/1.0/).
|
||
|
|
|
||
|
|
# 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](https://datatracker.ietf.org/doc/html/rfc3967#section-1.1).
|
||
|
|
|
||
|
|
## informative
|
||
|
|
A list of additional references.
|