Waku: Clarify what to do with unknown option keys (#112)

* Waku: Clarify what to do with unknown option keys

* Change options key ignoring to SHOULD and add to changelog

* Update Nimbus supported spec version
This commit is contained in:
Kim De Mey 2020-04-08 12:25:09 +02:00 committed by GitHub
parent 6362d80423
commit 99b0ef9e9d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 3 deletions

View File

@ -218,7 +218,7 @@ the same state.
When a node is receiving other Waku messages from a peer before a Status
message is received, the node MUST ignore these messages and SHOULD disconnect from that peer. Status messages received after the handshake is completed MUST also be ignored.
The status message MUST contain an association list containing various options. All options within this association list are OPTIONAL, ordering of the key-value pairs is not guaranteed and therefore MUST NOT be relied on.
The status message MUST contain an association list containing various options. All options within this association list are OPTIONAL, ordering of the key-value pairs is not guaranteed and therefore MUST NOT be relied on. Unknown keys in the association list SHOULD be ignored.
#### Messages
@ -435,7 +435,8 @@ Waku is a different subprotocol from Whisper so it isn't directly compatible. Ho
It is desirable to have a strategy for maintaining forward compatibility between `waku/0` and future version of waku. Here we outline some concerns and strategy for this.
- **Connecting to nodes with multiple versions:** The way this SHOULD be accomplished in the future is by negotiating the versions of subprotocols, within the `hello` message nodes transmit their capabilities along with a version. As suggested in [EIP-8](https://eips.ethereum.org/EIPS/eip-8), if a node connects that has a higher version number for a specific capability, the node with a lower number SHOULD assume backwards compatiblity. The node with the higher version will decide if compatibility can be assured between versions, if this is not the case it MUST disconnect.
- **Adding new packet codes:** New packet codes can be added easily due to the available packet codes, upgrades that add new packet codes should implement some fallback mechanism if no response was received for nodes that do not yet understand this packet.
- **Adding new packet codes:** New packet codes can be added easily due to the available packet codes. Unknown packet codes SHOULD be ignored. Upgrades that add new packet codes SHOULD implement some fallback mechanism if no response was received for nodes that do not yet understand this packet.
- **Adding new options in `status-options`:** New options can be added to the `status-options` association list in the `status` and `status-update` packet as options are OPTIONAL and unknown option keys SHOULD be ignored. A node SHOULD NOT disconnect from a peer when receiving `status-options` with unknown option keys.
## Appendix A: Security considerations
@ -492,7 +493,7 @@ By default Devp2p runs on port `30303`, which is not commonly used for any other
| Client | Spec supported | Details |
|--------|----------------|---------|
| **Status-go** | 0.4 | [details](https://github.com/status-im/status-go/blob/develop/WAKU.md) |
| **Nimbus** | 0.3 | [details](https://github.com/status-im/nimbus/blob/master/waku/README.md#spec-support) |
| **Nimbus** | 0.4 | [details](https://github.com/status-im/nimbus/blob/master/waku/README.md#spec-support) |
### Recommendations for clients
@ -514,6 +515,10 @@ Known static nodes MAY also be used.
## Changelog
### Upcoming Version
- Clarify the preferred way of handling unknown keys in the `status-options` association list.
### Version 0.4
Released [February 21, 2020](https://github.com/vacp2p/specs/commit/17bd066e317bbe33af07146b721d73f24de47e88).