The targets of this specification are low resource devices which in some case will not be able to implement the TCP or UDP stack.
Instead, they will use serial communication to exchange data with the XRCE Agents.
For this reason, common Serial Transport Profile is purposed with the objective of packaging XRCE message over serial communication.
This Serial Transport has the following features:

• HDLC Framing: each serial framing begins with a ``begin_frame`` octet ``(0x7E)`` and the rest of the frame is byte stuffing using the ``space`` octet ``(0x7D)`` following by the original octet exclusive-or with ``0x20``.
  For example, if the frame contains the octet `0x7E` it is encoded as `0x7D, 0x5E`; and the same for the octet `0x7E` which is encoded as `0x7D, 0x5D`.
• CRC Calculation: serial frames end with a CRC-16 for detecting frame corruption. The CRC-16 is computed using the polynomial ``x^16 + x^12 + x^5 + 1`` after the frame stuffing for each octet of the frame and including the ``begin_frame``.
• Routing header: the Serial Transport provides ``source`` and ``remote`` address in the framing, which could be used for implement a routing protocol.

All the aforementioned features are addressed using the following frame format:

    0        8        16       24                40                 X                X+16
    +--------+--------+--------+--------+--------+--------//--------+--------+--------+
    |  FLAG  |  SADD  |  RADD  |       LEN       |   XRCE MESSAGE   |       CRC       |
    +--------+--------+--------+--------+--------+--------//--------+--------+--------+

• ``FLAG``: is a ``begin_frame`` octet for frame initialization.
• ``SADD``: is the address of the device which sent the message, that is, the ``source`` address.
• ``RADD``: is the address of the device which should receive the message, that is, the ``remote`` address.
• ``LEN``: is the length of the payload without framing. It is encoded as a 2-bytes array in little endian.
• ``PAYLOAD``: is the payload of the message.
• ``CRC``: is the CRC of the message after the stuffing.

Add Serial Transport mapping

Allows the communication over serial protocol such as I2C, SPI or RS-232

In the current specification, the XRCE Clients are not able to select the stream for input data,
that is, they are not able to tell which stream should be used by the Agents in order to send `DATA` submessages.
This feature could be very useful for XCRE Clients in order to manage the head-of-line blocking for input messages.

One possible solution to this issue could be to add a `stream_id` field in the `READ_DATA_Payload`.

@extensibility(FINAL)
struct READ_DATA_Payload : BaseObjectRequest {
    ReadSpecification read_specification;
};

@extensibility(FINAL)
struct ReadSpecification {
    StreamId    ref_stream;
    DataFormat  data_format;
    @optional string                content_filter_expression;
    @optional DataDeliveryControl   delivery_control;
};

Add a requested stream_id to the ReadSpecification

Allow the possibility if specifying a requested stream_id inside the ReadSpecification to be used by the Agent when sending the data messages in response.

Use the mechanism suggested in the issue description.

Taking into account that both `CREATE_CLIENT` and `STATUS_AGENT` are unfragmentable submessages,
they bound the minimum MTU of the protocol.
Therefore, it will be welcome a possible reduction of these submessages in order to reduce the minimum MTU.
For example, currently, the `CREATE_CLIENT` submessage has 34 bytes of minimum size (without `ClientKey` nor `properties`),
therefore, it could not be possible to use this protocol over version 4.0 of the BLE (Bluetooth Low Energy) protocol, which has only 27 bytes of maximum MTU.

According to the aforementioned, the following `CREATE_CLIENT` and `STATUS_AGENT` submessage modification are purpose:

1. Remove the `request_id` and `object_id` from both `CREATE_CLIENT` and `STATUS_AGENT` submessages.
Thas is, remove the inheritance from `BaseObjectRequest` and `BaseObjectReply` from `CREATE_CLIENT` and `STATUS_AGENT` respectively.
It should be noted that 1) the `object_id =

` is a redundant field and 2) the `request_id` has a similar behaviour to `sequence_nr` for unestablished session.
2. Remove the `client_timestamp` and `agent_timestamp` from `CREATE_CLIENT` and `STATUS_AGENT` respectively.
Both timestamps could be sent through a new `TIME` submessage which allows implementing clock synchronization protocols.

These modifications involve the following changes in the IDL:

@extensibility(FINAL)
struct CREATE_CLIENT_Payload {
    CLIENT_Representation client_representation;
};

@extensibility(FINAL)
struct CLIENT_Representation {
    XrceCookie   xrce_cookie;
    XrceVersion  xrce_version;
    XrceVendorId xrce_vendor_id;
    ClientKey    client_key;
    SessionId    session_id;
    @optional PropertySeq properties;
};

@extensibility(FINAL)
struct STATUS_AGENT_Payload {
    AGENT_Representation agent_info;
};

@extensibility(FINAL)
struct AGENT_Representation {
    XrceCookie   xrce_cookie;
    XrceVersion  xrce_version;
    XrceVendorId xrce_vendor_id;
    @optional PropertySeq properties;
};

With the aforementioned modifications, the `CREATE_CLIENT` message will have 22 bytes of minimum size,
while the `STATUS_AGENT` message will have only 17 bytes.

CREATE_CLIENT message
-----------------------------------
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   session_id  |   stream_id   |         sequence_nr           | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CREATE_CLIENT |     flags     |       submessage_length       | 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          xrce_cookie                          | 12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          xrce_version         |       xrce_vendor_id          | 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          client_key                           | 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  session_id   |  properties?  | 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

STATUS_AGENT message
----------------------------------
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   session_id  |   stream_id   |         sequence_nr           | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STATUS_AGENT  |     flags     |       submessage_length       | 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          xrce_cookie                          | 12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          xrce_version         |       xrce_vendor_id          | 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  properties?  | 17
+-+-+-+-+-+-+-+-+

Simplify the CREATE_CLIENT and STATUS_AGENT messages

Perform the simplifications suggested in the issue description.

Some of the most extended clock synchronization protocol such as PTP or NTP require the exchange of multiple timestamp messages between the master and the slave.
The current standard only supports the timestamp exchange using the `CREATE_CLIENT` and `STATUS_AGENT` submessages.
For this reason, a new kind of submessage called `TIME` is purposed.

This new `TIME` submessage, which could use the `stream_id` 0x00, requires the following changes in the IDL:

```
enum SubmessageId

;

@extensibility(FINAL)
struct TIME_Payload : Time_t {
};
```

An example of an XRCE message with a `TIME` submessage is shown below.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   session_id  |   stream_id   |         sequence_nr           | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     TIME      |     flags     |       submessage_length       | 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          timestamp (s)                        | 12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          timestamp (ns)                       | 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Add a TIME submessage

Introduce a TIMESTAMP and a TIMESTAMP_REPLY submessages. The TIMESTAMP contains a simple timestamp and the TIMESTAMP_REPLY contains a timestamp plus the additional timestamps needed to run a simple version of the NTP clock synchronization algorithm.

As a result of the AB review section 7.4 'Serial Transport' was moved to an Annex to make clear that it is non-normative. This was included in the Errata presented to the AB.

Even if this doesn't change the conformance points (serial transport is not listed in the conformance section 3), this change also requires requires a FTF vote, it cannot be considered editorial.

Therefore this issue performs the move.

Create Annex C. Move section 11.4 there

Perform the changes specified in the issue description.

According to the specification, the `MessageHeader` interpretation depends on whether the following submessage is an `ACKNACK` or a `HEARTBEAT` submessage.
In this case, the `sequenceNr` shall be interpreted as an epoch that may be used to discard the duplicate message.
This dichotomy allows us to save bandwidth but it has some drawbacks.

On the one hand, it prevents to send multiple `ACKNACK` and `HEARTBEAT` submessages, which refer to different streams, in a single message.

On the other hand, it obfuscates the message handling because it is not enough to read the `MessageHeader` in order to discard, process, or buffer the message into the stream, but it is necessary to read the first `SubmessageHeader`.

In order to avoid the aforementioned drawbacks, the following modifications are purposed:

1. Add a `stream_id` member to `ACKNACK` and `HEARTBEAT` submessages.

struct ACKNACK_Payload {
    short first_unacked_seq_num;
    octet[2] nack_bitmap;
    octet stream_id;
}

struct HEARTBEAT_Payload {
    short first_unacked_seq_nr;
    short last_unacked_seq_nr;
    octet stream_id;
}

2. Use the stream 0 (`STREAMID_NONE`) since `ACKNACK` and `HEARTBEAT` submessage do not belong to any stream, but they inform about the state of the streams.

This modification allows sending multiple `ACKNACK` and `HEARTBEAT` submessages in a single message and it simplifies the message handling.

Add StreamId to ACKNACK and HEARTBEAT

Do as proposed in the issue description

An erratum has been attached with some grammatical mistakes we found.

Correct grammatical errors and typos

Perform the corrections suggested in the issue description