Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification on the occurences of TLV records with the same type #777

Merged
merged 1 commit into from
Jul 7, 2020
Merged

Clarification on the occurences of TLV records with the same type #777

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions 01-messaging.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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`,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

strictly-increasing is not the same as "unique", which this sentence implies with "i.e."

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strictly increasing does imply unique, doesn't it? (the reverse isn't true)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Below we have:

The strict monotonicity constraint ensures that all types are unique and can at most once. Fields that map to complex objects, e.g. vectors, maps, or appear at most once

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed, but "i.e." implies that they are equivalent in that, as merriam-webster says "it introduces a rewording or a clarification". An implication is not a rewording.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is your suggestion to change i.e. MUST not produce to hence MUST not produce?
If so, @dr-orlovsky can you apply this small change and we can merge?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, that is a great idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done!

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
Expand All @@ -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`.
Expand All @@ -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:
Expand Down