From 70e8c06730ac0c436c134e42b72044369a91e7b8 Mon Sep 17 00:00:00 2001
From: Dean Eigenmann <dean.eigenmann@icloud.com>
Date: Thu, 5 Dec 2019 05:13:25 +0100
Subject: [PATCH] spec/fix-rpl-abnf (#52)

* fixes

* indent

* rearranged

* Update waku.md

* commit
---
 waku.md | 83 ++++++++++++++++++++++++++++++---------------------------
 1 file changed, 44 insertions(+), 39 deletions(-)

diff --git a/waku.md b/waku.md
index 960862b7..9720df12 100644
--- a/waku.md
+++ b/waku.md
@@ -75,57 +75,61 @@ Waku is a RLPx subprotocol called `waku` with version `0`. The version number co
 Using [Augmented Backus-Naur form (ABNF)](https://tools.ietf.org/html/rfc5234) we have the following format:
 
 ```
-bytes            = [repeat] OCTET
-
 ; Packet codes 0 - 127 are reserved for Waku protocol
-packet-code      = 0 / 1 / 2 / 3 / [ x4-127 ]
+packet-code     = 1*3DIGIT
 
-packet-format    = "[" packet-code packet-format "]"
-
-; packet-format needs to be paired with its corresponding packet-format
-packet           = "[" required-packet / [ optional-packet ] "]"
-
-required-packet  = 0 status / 1 messages / 2 pow-requirement / 3 bloom-filter
-
-optional-packet  = 126 p2p-request / 127 p2p-message
-
-packet-format    = "[" packet-code packet-format "]"
-
-status           = "[" version pow-requirement [ bloom-filter ] [ light-node ] "]"
+status          = "[" version pow-requirement [ bloom-filter ] [ light-node ] "]"
 
 ; version is "an integer (as specified in RLP)"
-version          = DIGIT
+version         = DIGIT
 
-messages         = *waku-envelope
-
-; pow is "a single floating point value of PoW. This value is the IEEE 754 binary representation of 64-bit floating point number. Values of qNAN, sNAN, INF and -INF are not allowed. Negative values are also not allowed."
-pow-requirement  = pow
+; pow is "a single floating point value of PoW. 
+; This value is the IEEE 754 binary representation 
+; of a 64-bit floating point number. 
+; Values of qNAN, sNAN, INF and -INF are not allowed.
+; Negative values are also not allowed."
+pow-requirement = pow
 
 ; bloom filter is "a byte array"
-bloom-filter     = bytes
+bloom-filter    = *OCTET
 
-light-node       = BIT
+light-node      = BIT
 
-p2p-request      = waku-envelope
-
-p2p-message      = waku-envelope
-
-whisper-envelope = "[" expiry ttl topic data nonce "]"
+waku-envelope   = "[" expiry ttl topic data nonce "]"
 
 ; 4 bytes (UNIX time in seconds)
-expiry           = bytes
+expiry          = 4OCTET
 
 ; 4 bytes (time-to-live in seconds)
-ttl              = bytes
+ttl             = 4OCTET
 
 ; 4 bytes of arbitrary data
-topic            = bytes
+topic           = 4OCTET
 
-; byte array of arbitrary size (contains encrypted message)
-data             = bytes
+; byte array of arbitrary size 
+; (contains encrypted message)
+data            = OCTET
 
-; 8 bytes of arbitrary data (used for PoW calculation)
-nonce            = bytes
+; 8 bytes of arbitrary data 
+; (used for PoW calculation)
+nonce           = 8OCTET
+
+messages        = 1*waku-envelope
+
+p2p-request     = waku-envelope
+
+p2p-message     = 1*waku-envelope
+
+packet-format   = "[" packet-code packet-format "]"
+
+required-packet = 0 status / 1 messages / 2 pow-requirement / 3 bloom-filter
+
+optional-packet = 126 p2p-request / 127 p2p-message
+
+; packet-format needs to be paired with its corresponding packet-format
+packet          = "[" required-packet [ optional-packet ] "]"
+
+packet-format   = "[" packet-code packet-format "]"
 ```
 
 All primitive types are RLP encoded. Note that, per RLP specification, integers are encoded starting from `0x00`.
@@ -233,8 +237,9 @@ The Data field contains the encrypted message of the envelope. In case of symmet
 Using [Augmented Backus-Naur form (ABNF)](https://tools.ietf.org/html/rfc5234) we have the following format:
 
 ```
-; 1 byte; first two bits contain the size of auxiliary field, third bit indicates whether the signature is present.
-flags           = 1*OCTET
+; 1 byte; first two bits contain the size of auxiliary field, 
+; third bit indicates whether the signature is present.
+flags           = 1OCTET
 
 ; contains the size of payload.
 auxiliary-field = 4*OCTET
@@ -246,12 +251,12 @@ payload         = *OCTET
 padding         = *OCTET
 
 ; 65 bytes, if present.
-signature       = 65*OCTET
+signature       = *65OCTET
 
 ; 2 bytes, if present (in case of symmetric encryption).
-salt            = 2*OCTET
+salt            = 2OCTET
 
-envelope        = flags auxiliary-field payload padding [signature] salt
+envelope        = flags auxiliary-field payload padding [signature] [salt]
 ```
 
 Those unable to decrypt the message data are also unable to access the signature. The signature, if provided, is the ECDSA signature of the Keccak-256 hash of the unencrypted data using the secret key of the originator identity. The signature is serialised as the concatenation of the `R`, `S` and `V` parameters of the SECP-256k1 ECDSA signature, in that order. `R` and `S` are both big-endian encoded, fixed-width 256-bit unsigned. `V` is an 8-bit big-endian encoded, non-normalised and should be either 27 or 28.