extensions: misbehaving cases

Nobody has claimed this yet.

specification for gossipsub extensions, "test extension" and partial messages extension are not very well describing what should be considered as misbehavior (penalty).

for example:
- > If a peer supports any extension, the Extensions control message MUST be included in the first message on the stream
- if an extension control message is sent, but it is not the first message, is it misbehavior?

- > Extensions control message MUST NOT be sent more than once
- go-libp2p identifies this case as misbehavior

- > A node MUST omit the partialMessage field of the PartialMessagesExtension message when sending a message to this peer. In other words, it MUST NOT send this peer encoded partialMessage data since it did not request it.
- not clear if this should be misbehavior

in general, it would be better if specs had a better way of specifying what cases should be considered as misbehavior. for example, all documents (in gossipsub) could have an additional section where all misbehavior cases are listed.

---

edit: there are some cases when `MUST` is not use in spec. for example `partialMessage` rpc has `groupID` and `topic` fields which are mandatory for extensions to be set, but since they are optional (on protobuf) extensions should do senity checks on these fields and when those are not set, peer that sent message should be considered as misbehaving?

Start by reviewing the gossipsub extensions specification, especially the “test extension” and PartialMessagesExtension rules quoted in the issue. Identify which violations, including repeated or misplaced control messages and missing extension fields, should count as misbehavior. Done means the specification explicitly lists these cases and their penalties.

Written by the indexing model from the issue text.