Clarification on the occurences of TLV records with the same type

Closes #776

01-messaging.md

@@ -135,7 +135,8 @@ according to the message-specific format determined by `type`.
 ### Requirements
 
 The sending node:
- - MUST order `tlv_record`s in a `tlv_stream` by monotonically-increasing `type`.
+ - MUST order `tlv_record`s in a `tlv_stream` by strictly-increasing `type`,
+   hence MUST not produce more than a single TLV record with the same `type`
  - MUST minimally encode `type` and `length`.
  - When defining custom record `type` identifiers:
    - SHOULD pick random `type` identifiers to avoid collision with other
@@ -151,7 +152,8 @@ The receiving node:
    - MUST stop parsing the `tlv_stream`.
  - if a `type` or `length` is not minimally encoded:
    - MUST fail to parse the `tlv_stream`.
- - if decoded `type`s are not monotonically-increasing:
+ - if decoded `type`s are not strictly-increasing (including situations when
+   two or more occurrences of the same `type` are met):
    - MUST fail to parse the `tlv_stream`.
  - if `length` exceeds the number of bytes remaining in the message:
    - MUST fail to parse the `tlv_stream`.
@@ -175,8 +177,8 @@ encoded element. Without TLV, even if a node does not wish to use a particular
 field, the node is forced to add parsing logic for that field in order to
 determine the offset of any fields that follow.
 
-The monotonicity constraint ensures that all `type`s are unique and can appear
-at most once. Fields that map to complex objects, e.g. vectors, maps, or
+The strict monotonicity constraint ensures that all `type`s are unique and can
+appear at most once. Fields that map to complex objects, e.g. vectors, maps, or
 structs, should do so by defining the encoding such that the object is
 serialized within a single `tlv_record`. The uniqueness constraint, among other
 things, enables the following optimizations: