-
Notifications
You must be signed in to change notification settings - Fork 14
Conversation
I've commented on the wider issue of RFC structuring here: https://forum.vac.dev/t/rfc-categories-structure/125 |
content/docs/rfcs/42/README.md
Outdated
title: 42/WAKU2-STANDARD-Template | ||
name: Waku v2 Stadard Template | ||
status: raw | ||
category: WAKU standard |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use tags
not category
: https://rfc.vac.dev/spec/1/#appendix-b-metainformation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussed during offsite, let's use categories a la IETF
Tags can be used as optional meta information but shouldn't be imposed as it creates complexity/overhead and there also doesn't seem to be a good precedence for it in specs world (IETF etc)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'd have to update the 1 RFC to introduce the category
.
Updated as per our off-site discussion. This would make tagging, as introduced #368, optional. An alternative/addition to tagging for clarifying the usage of various protocols are BCP (best common practice) RFCs. |
We could add further information about writing RFCs in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM! Thanks. Will go a long way to make our RFCs more standardised and readable.
content/docs/rfcs/template/README.md
Outdated
@@ -0,0 +1,62 @@ | |||
--- | |||
slug: XX | |||
title: XX/(WAKU2|LOGOS|CODEX|...)-TEMPLATE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming RFCs that does not belong to a single project or applies to several (e.g. "RLN" without relay) would just not use a prefix at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could make the prefix optional (i.e. not mentioning it in the template at all).
Or, we could list a set of "known" prefixes, but also allow further prefixes / prefix-less RFCs.
The [...] could be replaced by "*": any or no prefix. README could explain this.
wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me! Don't think we need too overexplain this - a "*" would fully indicate the meaning, I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might differentiate between project's specific RFCs from general RFC (that apply to several projects) with a notation like
XX/WAKU2/A-TEMPLATE
<- specific to WAKU2
XX/ANOTHER-TEMPLATE
<- multi project
This avoids the double meaning of the "-" which separates prefix and suffix, but also multi-words suffixes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that :).
What I did in the template was to be backwards compatible. But... I'd have to update the RFCs adding the category
anyway. Ill put that into the restructure issue (yet to be opened, see #513)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I'm worried this complicates things? The optional prefix seems like most minimal KISS.
Do we have an example of some spec project using double namespacing? E.g. //.
What do we hope to gain from this, vs more informal prefix?
content/docs/rfcs/template/README.md
Outdated
|
||
# Wire Format Specification / Syntax | ||
|
||
A standard track RFC must feature this section. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps only when in draft
or higher? Perhaps we may want to relax requirements for raw
RFCs so we can standardise a bit quicker on semantics even if wire format is not yet fleshed out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. The the MUSTs are for "stable". Raw and draft "should". Done in 4186eb8.
A standard track RFC must 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this. This section is in other words the TL;DR for implementers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. An implementor who already understand the basic functioning and background of a protocol can go to this section directly.
I added a meta section for explaining things about the process of writing RFCs (it also links COSS). |
contributors: | ||
--- | ||
|
||
# (Info, remove this section) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder, should this be a template or in itself a spec? :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could remove this and put things into COSS exclusively.
However, Imo, like this the template is self-contained and I would add the info to COSS as well anyways.
(see my comment above). Could also change this in a future PR. Wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, and this will be helpful to spec writers!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM too! Great standardization job! I left a comment regarding how we can possibly differentiate between project-specific and general RFCs.
Further opinions on @s1fr0 suggestion? I like that. My comment inline |
- see RFC 29
* master: RFC16: add version call (#505) fix(noise): update RFC to implementation (#508) fixup: 37/WAKU2-NOISE fix images paths (#506) New RFC: 37/WAKU2-NOISE-SESSIONS (#504) 36/WAKU2-BINDINGS-API (#501) docs(16/WAKU2-RPC): add ENR to waku info (#502) Adding 35/WAKU2-NOISE to menu (#500) add RFC33 to index (#499) feat: 32/RLN raw spec New RFC: 35/WAKU2-NOISE (#496) Update on the rln registration figure to match the current spec (#497) 33/WAKU-DISCV5: Add first raw version (#487) Add pubsubTopic field to index (#492) Fix markdown links (#493) Categorize 22 & 31 (#490) Changed PB Timestamp index to 10 (#491) 13/14/16/21: Change in timestamp format (#483) add: RFC31 copyright statement (#489) 17/WAKU-RLN-RELAY: Revise spec for its draft version (#484)
8af9bb6
to
00bdd51
Compare
(The merge commit done by via Github was not signed, so I had to rebase and force commit.) |
This draft PR demonstrates an example structure for RFCs of the
WAKU standard
category as described in this forum post.