enhancement/max-size (#126)

* comments

* Update specs/waku/waku-1.md

Co-authored-by: Kim De Mey <kim.demey@gmail.com>

* Update specs/waku/waku-1.md

Co-authored-by: Kim De Mey <kim.demey@gmail.com>

* Update waku-1.md

* Update mailserver.md

* Update mailserver.md

* Update waku-1.md

* Update waku-1.md

* Update waku-1.md

Co-authored-by: Kim De Mey <kim.demey@gmail.com>

specs/waku/mailserver.md

@@ -69,7 +69,7 @@ If `Topics` is used the `Cursor` field MUST be specified for the argument order
 
 ### Receiving Historic Envelopes
 
-Historic envelopes MUST be sent to a peer as a packet with a P2P Message code (`0x7f`) followed by an array of Waku envelopes.
+Historic envelopes MUST be sent to a peer as a packet with a P2P Message code (`0x7f`) followed by an array of Waku envelopes. A Mailserver MUST limit the amount of messages sent, either by the `Limit` specified in the request or limited to the maximum [RLPx packet size](./waku#maximum-packet-size), whichever limit comes first.
 
 In order to receive historic envelopes from a mailserver, a node MUST trust the selected mailserver, that is allow to receive expired packets with the P2P Message code. By default, such packets are discarded.
 

specs/waku/waku-1.md

@@ -15,6 +15,7 @@ redirect_from:
 - [Underlying Transports and Prerequisites](#underlying-transports-and-prerequisites)
     - [Use of DevP2P](#use-of-devp2p)
     - [Gossip based routing](#gossip-based-routing)
+    - [Maximum Packet Size](#maximum-packet-size)
 - [Wire Specification](#wire-specification)
     - [Use of RLPx transport protocol](#use-of-rlpx-transport-protocol)
     - [ABNF specification](#abnf-specification)
@@ -77,6 +78,15 @@ This protocol needs to advertise the `waku/1` [capability](https://ethereum.gitb
 
 In Whisper, envelopes are gossiped between peers. Whisper is a form of rumor-mongering protocol that works by flooding to its connected peers based on some factors. Envelopes are eligible for retransmission until their TTL expires. A node SHOULD relay envelopes to all connected nodes if an envelope matches their PoW and bloom filter settings. If a node works in light mode, it MAY choose not to forward envelopes. A node MUST NOT send expired envelopes, unless the envelopes are sent as a [mailserver](./mailserver.md) response. A node SHOULD NOT send an envelope to a peer that it has already sent before.
 
+### Maximum Packet Size
+
+Nodes SHOULD limit the maximum size of both packets and envelopes. If a packet or envelope exceeds its limit, it MUST be dropped.
+
+- **RLPx Packet Size** - This size MUST be checked before a message is decoded.
+- **Waku Envelope Size** - Each envelope contained in an RLPx packet MUST then separately be checked against the maximum envelope size.
+
+Clients MAY use their own maximum packet and envelope sizes. The default values are `1.5mb` for the RLPx Packet and `1mb` for a Waku envelope.
+
 ## Wire Specification
 
 ### Use of RLPx transport protocol
@@ -404,7 +414,6 @@ In later versions this will be amended by nodes communication thresholds, settle
 
 ### General principles and policy
 
-
 The currently advertised capability is `waku/1`. This needs to be advertised in the `hello` `ÐΞVp2p` [packet](https://ethereum.gitbooks.io/frontier-guide/devp2p.html).
 If a node supports multiple versions of `waku`, those needs to be explicitly advertised. For example if both `waku/0` and `waku/1` are supported, both `waku/0` and `waku/1` MUST be advertised.
 
@@ -535,6 +544,7 @@ Known static nodes MAY also be used.
 - Add section on P2P Request Complete packet and update packet code table.
 - Correct the header hierarchy for the status-options fields.
 - Consistent use of the words packet, message and envelope.
+- Added section on max packet size
 
 ### Version 1.0