In RTPS each entity has a so-called GUID_t. It consists of a 12 Byte GuidPrefix_and a 4-Byte EntityId_t and must be globally unique. In heterogeneous systems (with multiple RTPS implementations), the specification provides no mechanism or guidance to ensure global uniqueness.

A solution would be to make the vendorId part of the GuidPrefix_t.

Resolution:
The first two bytes of the GUID_t prefix should be the vendor id.

The first two bytes of the GUID_t prefix should be the vendor id, the rest can be
chosen by the vendors as they see fit, as long as they ensure uniqueness.
This approach avoids collisions between vendors, but has the drawback that it limits
the range of available GUID prefixes for each vendor. But as we can see below, this
limitation should not cause a problem as the remaining 10 Bytes are sufficient to
generate unique GUIDs even in very large DDS domains.
The GUID_t prefix is 12 bytes, after 2 are used for the vendor there remain only 10
bytes that can be used to generate unique DDS Entity GUIDs, this means there can
be S = 2^80 different GUID prefixes.
GUID prefixes are assigned in one-to-one correspondence with DDS
DomainParticipants as all the DDS Entities within a participant share the same GUID
Prefix.
Assume that a particular DDS domain has ‘n’ DDS participants, if a good algorithm is
used to generate GUID prefixes, the probability of a collision P (i.e. two or more
entities having the same GUID) can be approximated as: P ~ 1 – exp(-(n^2)/(2*S))
In a very large system with 1 Million DDS Participants the probability of a collision
would be extremely small: 4e-13
In a system with 1 Billion (10^9) DDS Participants the probability of a collision would
be 4e-7 also very small.
Therefore the solution requiring the first 2 bytes of the GUID_t Prefix to match the
vendorId will not prevent the generation of unique GUID prefixes.

Summary:
The set of proposed changes necessitates updating the protocol version.
Resolution:
Change protocol version from 2.0 to 2.1.

Change protocol version from 2.0 to 2.1.

Summary:
The statusInfo field of DATA submessage holds flags relating DDS-level concepts that are interpreted at higher layers than RTPS. Hence, it is not necessary to have statusInfo as an explicit field; rather, it can be included in the inlineQos SubmessageElement.

Resolution:
Replace all instances of the statusInfo field of DATA with the new statusInfo inline parameter.

Replace all instances of the statusInfo field of DATA with the new statusInfo inline parameter.

Summary:
The specification does not describe how the KeyHash is computed from the Key.

This implicates that key hashes in messages coming from different RTPS implementations can never be interpreted, because one implementation may utilize a different key hash algorithm then the other.

I would prefer that the hash algorithm becomes part of the specification. RTPS implementations can choose to implement the prescribed algorithm or simply use a zero-valued key.

Resolution:
The UDP PIM should mandate that the KeyHash is computed either as the serialized key or else as an MD5 digest, depending on whether the serialize key for the type can exceed the 128 that are used for the KeyHash.

The UDP PIM should mandate that the KeyHash is computed either as the serialized key or else as an MD5 digest, depending on whether the serialize key for the type can exceed the 128 that are used for the KeyHash.

The resolution of this issue depends on the presence of new section 9.6.3.3 titled "Key Hash" added as part of the resolution of issue. 12504. If issue 12504 is resolved in a way that does not add this section, then the resolution proposed here would not be valid.

Summary:
Section 9.4.5.1.1 leaves unspecified the list of vendor IDs
Resolution:
Modify section to include a reference to an appendix or table where all the vendor IDs are listed.

Modify section to specify that vendor ID’s are managed separately from the
specification and include a link to http://www.omgwiki.org/dds/content/page/ddsrtps-
vendor-and-product-ids

The submessages required to send Keyed and Unkeyed data are mapped in the PSM as two different submessages (DATA and NOKEY_DATA). These submessages have almost identical content so there is no reason to use two submessages for this. Furthermore having two different submessages at the PSM level and exposing the KeyHash as part of the submessage introduces problems with regards to the implementation and the extensibility of the protocol. For example, future versions of the protocol may want to support keyhashes that are either bigger or smaller than the 16 Bytes used today, and do that in an inter-operable manner without breaking backwards compatibility. They may also want to omit sending a key hash when the size of the key itself is small. As the key is always included as part of the data, sending the KeyHash for small keys is inefficient at best.
This could be resolved by combining the two PSM submessages and moving the KeyHash into the InlineQos.

Resolution:
Combine the DATA and NOKEY_DATA submessages. Also combine the DATA_FRAG and NOKEY_DATA_FRAG. Include additional fields in these submessages to enable extensibility for future submessage-specific options.

Combine the DATA and NOKEY_DATA submessages. Also combine the DATA_FRAG and NOKEY_DATA_FRAG. Include additional fields in these submessages to enable extensibility for future submessage-specific options

The inclusion of keyHashPrefix and keyHashSuffix fields in DATA and DATA_FRAG submessages should be optional. The keyHash is a DDS-level optimization whose interpretation by RTPS is unnecessary. Hence, it is logically better to reassign it as a parameter that may be included inline.
Resolution:
Replace mentioned instances of keyHashPrefix/Suffix with keyHash inline parameter.

Replace mentioned instances of keyHashPrefix/Suffix with keyHash inline parameter.

Some submessages can optionally include a payload. For example the DATA submessage includes a payload in most cases, except in some special cases where the submessage indicates unregistration and/or disposal of the data.

Currently the presence of the payload is tied to the value of the unregister and dispose flags. This is inflexible and also does not support some use-cases where it is desirable to send data with dispose messages. It would be much better to make the presence of the Data Payload separately configurable in the submessage.

Resolution:
Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information

Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information

The specification states in section 9.6.2.1 that the key portion of ParticipantMessageData is not serialized as part of the DATA submessage. The stated argument is that the key is already part of the DATA submessage. This argument is incorrect, the DATA message may optionally include a KeyHash which is not necessarily the same as the key. Moreover this makes the ParticipantMessageData special in the way it is serialized. The saving in bandwidth consumed do not justify all this "special code". It would be far better if the ParticipantMessageData was treated as any regular data message and the key was serialized along.
Resolution:
Change the description in Section 9.6.2.1 to not refrain from serializing the key of ParticipantMessageData.

Change the description in Section 9.6.2.1 to not refrain from serializing the key of ParticipantMessageData.

Simple discovery data has parameters containing redundant information. To not waste bandwidth, implementations should be able to refrain from sending redundant information. As such, the spec should include an implementation note on this matter.
Resolution:
Add text in PSM, Section 9.6.2.2 describing the general allowable case in which implementations may avoid serializing parameters with redundant information.
Revised Text:
Add to Section 9.6.2.2, right before section 9.6.2.2.1 the following paragraph::

For optimization, implementations of the protocol may refrain from include in the Data submessage a parameter if it contains information that is redundant with parameters present in that same Data submessage. As a result of this optimization an implementation can omit the serialization of the parameters listed in - ParameterId subspaces- ParameterId subspaces

Table 9.1 - ParameterId subspaces
BuiltinEndpoint Parameter which may be omitted Parameter where the information on the omitted parameter can be found
SPDPdiscoveredParticipantData ParticipantProxy::guidPrefix ParticipantBuiltinTopicData::key

DiscoveredReaderData ReaderProxy::remoteReaderGuid SubscriptionBuiltinTopicData::key

DiscoveredWriterData ReaderProxy::remoteWriterGuid PublicationBuiltinTopicData::key
.
For example, an implementation of the protocol sending DATA message containing the SPDPdiscoveredParticipantData may omit the parameter that contains the guidPrefix. If the guidPrefix is not present in the DATA message, the implementation of the protocol in the receiver side must derive this value from the "key" parameter which is always present in the DATA message.

Add text in PSM, Section 9.6.2.2 describing the general allowable case in which implementations may avoid serializing parameters with redundant information.

Usage of keyHash is currently underspecified. It is not clear whether its presence in the message is mandatory and how it should be processed.
Resolution:
Expanded descriptions of the intended usage of keyHash parameter are added.
Revised Text:
Insert new Section 8.7.8

8.7.8 "Key Hash"

The Key Hash provides a hint for the key that uniquely identifies the data-object that is being changed within the set of objects that have been registered by the RTPS Writer.

Nominally the key is part of the serialized data of a data submessage. Using the key hash benefits implementations providing a faster alternative than deserializing the full key from the received data-object.

When the key hash is not received by a DataReader, it should be computed from the data itself. If there is no data in the submessage, then a default zero-valued key hash should be used by the DataReader

If there is a KeyHash, if present, shall be computed as described in Section 9.6.3.3

Expanded descriptions of the intended usage of keyHash parameter are added