Abstract
The payload concept offers a very flexible way to combine and encapsulate information in the IOTA protocol. This document proposes a basic payload type that allows the addition of arbitrary data.
Motivation
The most flexible way to extend an existing object is by the addition of arbitrary data. This payload provides a way to do just that. An optional tag can be used to categorize the data.
Specification
Serialized Layout
The following table describes the serialization of a Tagged Data Payload following the notation from TIP-21:
| Name | Type | Description |
|---|---|---|
| Payload Type | uint32 | Set to value 5 to denote an Tagged Data Payload. |
| Tag | (uint8)ByteArray | The tag of the data. A leading uint8 denotes its length. |
| Data | (uint32)ByteArray | Binary data. A leading uint32 denotes its length. |
It is important to note that Tag is not considered by the protocol, it just serves as a marker for second layer applications.
Syntactic Validation
length(Tag)must not be larger thanMax Tag Length.- Given the type and length information, the Tagged Data Payload must consume the entire byte array of the
Payloadfield of the encapsulating object.
Rationale
As the tag is not considered by the protocol, it could also be removed completely. However, Legacy IOTA and Chrysalis supported sending of arbitrary data indexed with a tag. Thus, in order to simplify the migration of second layer applications using these protocols, the optional Tag has been added which can be used in a similar manner.
Copyright
Copyright and related rights waived via CC0.