From 48905571978742906e3ea40f47295ae5f0cd681d Mon Sep 17 00:00:00 2001 From: Sasha Date: Mon, 27 May 2024 17:47:34 +0200 Subject: [PATCH] init spec --- informational/protocol-composition.md | 69 +++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 informational/protocol-composition.md diff --git a/informational/protocol-composition.md b/informational/protocol-composition.md new file mode 100644 index 0000000..00c0793 --- /dev/null +++ b/informational/protocol-composition.md @@ -0,0 +1,69 @@ +--- +title: TEMPLATE +name: Specification Template +category: (Standards Track|Informational|Best Current Practice) +tags: an optional list of tags, not standard +editor: Jimmy Debe +contributors: +--- + +### (Info, remove this section) + +This section contains meta info about writing specifications. +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. + +* `core` for Waku protocol definitions +* `application` for applications built on top of Waku protocol, +* `informational` for general guidelines, background information etc. + +## Abstract + + +## Background / Rationale / Motivation + +This section serves as an introduction providing background information and a motivation/rationale for the specification. + +## Theory / Semantics + +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 +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, +“NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). + +This section SHOULD not contain explanations of semantics and focus on concisely defining the wire format. +Implementations SHOULD 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. + + +## Implementation Suggestions (optional) +An optional *implementation suggestions* section may provide suggestions on how to approach implementation details, and, +if available, point to existing implementations for reference. + + +## (Further Optional Sections) + + +## Security/Privacy Considerations + +If there are none, this section MAY 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 + +A list of references.