TIP-21 Serialization Primitives (#41)

* add RFC document

* reference in each serialization RFC

* Migrate to TIP-21

* Update tip-0021.md

* Add length type defs to ByteArray (#24)

* Add length type defs to ByteArray

* Add clarification to atMostOneOfEach subschema

Co-authored-by: Levente Pap <levente.pap@iota.org>

tips/TIP-0006/tip-0006.md

@@ -29,26 +29,15 @@ By making it possible to add and exchange payloads, an architecture is being cre
 
 # Detailed design
 
-## Data types
-
-The following are data types that will be used when we specify fields in the message and payloads.
-
-| Name         | Description                                                                   |
-| ------------ | ----------------------------------------------------------------------------- |
-| uint8        | An unsigned 8-bit integer encoded in Little Endian.                           |
-| uint16       | An unsigned 16-bit integer encoded in Little Endian.                          |
-| uint32       | An unsigned 32-bit integer encoded in Little Endian.                          |
-| uint64       | An unsigned 64-bit integer encoded in Little Endian.                          |
-| ByteArray[N] | A static size byte array of length N.                                         |
-| ByteArray    | A dynamically sized byte array. A leading uint32 denotes its length in bytes. |
-
 ## Structure
 
 ### Message ID
 
 The *Message ID* is the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash of the entire serialized message.
 
-### Serialized Layout
+### Serialized layout
+
+The following table describes the serialization of a _Message_ following the notation from [RFC-0041](https://iotaledger.github.io/protocol-rfcs/0041-serialization-primitives/0041-serialization-primitives.html):
 
 <table>
   <tr>

tips/TIP-0007/tip-0007.md

@@ -61,31 +61,7 @@ All values are serialized in little-endian encoding. The serialized form of the
 
 The *Transaction ID* is the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash of the entire serialized payload data including signatures.
 
-The following table structure describes the entirety of a _Transaction Payload_ in its serialized form:
-* Data Type Notation, see [TIP-6](../TIP-0006/tip-0006.md#data-types)
-* <details>
-    <summary>Subschema Notation</summary>
-    <table>
-        <tr>
-            <th>Name</th>
-            <th>Description</th>
-        </tr>
-        <tr>
-            <td><code>oneOf</code></td>
-            <td>One of the listed subschemas.</td>
-        </tr>
-        <tr>
-            <td><code>optOneOf</code></td>
-            <td>Optionally one of the listed subschemas.</td>
-        </tr>
-        <tr>
-            <td><code>anyOf</code></td>
-            <td>Any (one or more) of the listed subschemas.</td>
-        </tr>
-    </table>
-</details>
-
-<p></p>
+The following table describes the entirety of a _Transaction Payload_ in its serialized form following the notation from [TIP-21](../TIP-0021/tip-0021.md).
 
 <table>
   <tr>

tips/TIP-0008/tip-0008.md

@@ -31,9 +31,7 @@ In addition, a key rotation policy can also be enforced by limiting key validity
 
 ## Structure
 
-All values are serialized in little-endian encoding. The serialized form of the milestone is deterministic, meaning the same logical milestone always results in the same serialized byte sequence.
-
-The following table structure describes the entirety of a _Milestone Payload_ in its serialized form ([TIP-6 Data Types](../TIP-0006/tip-0006.md#data-types)):
+The following table describes the entirety of a _Milestone Payload_ in its serialized form following the notation from [TIP-21](../TIP-0021/tip-0021.md):
 
 <table>
   <tr>

tips/TIP-0021/tip-0021.md

@@ -0,0 +1,56 @@
+---
+tip: 21
+title: Serialization Primitives
+description: Introduce primitives to describe the binary serialization of objects.
+author: Wolfgang Welz (@Wollac) <wolfgang.welz@iota.org>
+discussions-to: https://github.com/iotaledger/tips/pull/41
+status: Draft
+type: Standards
+layer: Core
+created: 2021-11-22
+---
+
+# Summary
+
+This document introduces the primitives and concepts that are used throughout the IOTA protocol RFCs to describe the binary serialization of objects.
+
+# Motivation
+
+Prior to this document, each RFC contained its own section and version describing the serialization of its objects. This RFC introduces consistent serialization concepts and avoids duplication in other RFCs.
+
+# Detailed design
+## Schemas
+
+Serializable objects are represented by a _schema_. Each schema consists of a list of _fields_, which each have a name and a type. The type of a field can either be a simple data type or another schema, then called subschema.
+
+### Data types
+
+All the supported data types are described in the following table:
+
+| Name              | Description                                                                   |
+|-------------------|-------------------------------------------------------------------------------|
+| uint8             | An unsigned 8-bit integer encoded in Little Endian.                           |
+| uint16            | An unsigned 16-bit integer encoded in Little Endian.                          |
+| uint32            | An unsigned 32-bit integer encoded in Little Endian.                          |
+| uint64            | An unsigned 64-bit integer encoded in Little Endian.                          |
+| uint256           | An unsigned 256 bits integer encoded in Little Endian.                        |
+| ByteArray[N]      | A static size byte array of N bytes.                                          |
+| (uint8)ByteArray  | A dynamically sized byte array. A leading uint8 denotes its length in bytes.  |
+| (uint16)ByteArray | A dynamically sized byte array. A leading uint16 denotes its length in bytes. |
+| (uint32)ByteArray | A dynamically sized byte array. A leading uint32 denotes its length in bytes. |
+
+### Subschemas
+
+In order to create complex schemas, one or multiple subschemas can be included into an outer schema. The keywords that describe the allowed combinations of such subschemas is described in the following table:
+
+| Name                 | Description                                                 |
+|----------------------|-------------------------------------------------------------|
+| `oneOf`              | One of the listed subschemas.                               |
+| `optOneOf`           | One of the listed subschemas or none.                       |
+| `anyOf`              | Any (one or more) of the listed subschemas.                 |
+| `optAnyOf`           | Any (one or more) of the listed subschemas or none.         |
+| `atMostOneOfEach`    | At most one (none or one) of each of the listed subschemas. |
+
+# Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).