Table 9.14 introduces PID_DIRECTED_WRITE and PID_ORIGINAL_WRITER_INFO but they are not described in the subsequent sections.

Add description for PID_ORIGINAL_WRITER_INFO and deprecate PID_DIRECTED_WRITE

A missing description for PID_ORIGINAL_WRITER_INFO has been added and PID_DIRECTED_WRITE type has been updated to match common practice with note to ignore when the format is not known.

Section 9.4.2.12 should clearly state where the alignment begins. Is it before the encapsulation header or after the encapsulation header?

Note that 9.4.2.11 already talks about it for the ParameterList encapsulation so 9.4.2.12 should use the same approach.

The language in 9.4.2.11 should also be improved to make it less ambiguous, specifically stating that the reset of the alignment occurs after the parameterID before the parameter data is serialized.

Clarify the start alignment for the SerializedPayload SubmessageElement

The SerializedPayload SubmessageElement has been updated to clearly state that the CDR stream is logically reset after the encapsulation header, similar to what is already described in section 9.4.2.11. Section 9.4.2.11 has also been improved for clarity, with no change to semantics.

DDS Security updated the RTPS version to 2.3. Consequently this revision should update it to 2.4. See also DDSIRTP23-56

Update protocol version from 2.2 to 2.4

Replace all the version 2.2 with 2.4 in all places except Section 9.3.1.4 '9.3.1.4 Deprecated EntityIds in version 2.2 of the Protocol' and Section 9.6.4 'ParameterIds Deprecated by the Protocol'

Currently it is RELIABLE. The problem is that this channel is used to send the Liveliness assertions. Being reliable if one is lost, future assertions cannot make it through even if they are written by the DataWriter. Rather it has to wait for the repair packet which depends on timing for HeartBeat and repair which may be longer than the assertion period.

Since the assertion message is small, it is more efficient to send it faster than rely on faster heartbeats and ACKNACKs.

This change would be backwards compatible since the DataWriter would still have reliability kind RELIABLE.

*Add Flags to the BuiltinEndpointSet to Facilitate Communication of Configuration Options *

It is useful to be able to configure the builtin endpoints and then communicate the configurations. A new PID has been defined that will allow communication of these specific configurations. One of the new flags will be used to communicate the Reliability kind of the inter-participant DataReader.

Currently the domainId is not propagated with the ParticipantBuiltinTopicData as a result there could be situations where Participant accidentally discovers another one on a different DomainId as a result of port overlaps.

This issue requests the domainId to be propagated in the ParticipantBuiltinTopicData so it can be checked independently of port numbers.

Propagate DomainId as part of Participant Discovery

Add domainId as an additional field in ParticipantProxy
Add PID_DOMAIN_ID with value 0x000f containing a domainId
Add PID_DOMAIN_TAG with value 0x4014 containing a domainTag

Section 10 was written before there was a good reference for the data representation used by DDS. Now that we have the DDS-XTYPES specification the section should updated to indicate the minimal requirements to comply with RTPS and reference XTYPES for full DDS type interoperability.

Note that we should not make RTPS depend on XTYPES. The intent is just to clarify where different things are, not to change the things required for compliance.

Update Section 10 (Data Encapsulation)

Replace Section 10 to more precisely define the Encapsulation Identifiers and and reference the Data Representation formats in DDS-XTYPES section 7.4.

Include an example for builtin Topic and one for an application-defined Topic.

Describe how to create a WITH_KEY or NO_KEY RTPS Endpoint from DDS. The RTPS endpoints have a with_key attribute, but it is not clear how this attribute can be set

Describe how to create a WITH_KEY or NO_KEY RTPS Endpoint from DDS

The text has been clarified to describe how an RTPS Writer and RTPS Reader can be defined as either WITH_KEY or NO_KEY from DDS.

The Xtypes Specification uses some of the protocol-specific PIDs, we should note that these PIDs are reserved in the RTPS spec.

Reference the PIDs that are reserved by the XTypes Spec in RTPS

The Xtypes Spec uses PIDs 0x0072, 0x0073, 0x0074, and 0x0075, we have noted in RTPS that these PIDs are reserved.

The UML figures in the specification are created as low-resolution bitmaps. They should be changed to a vector format.

Update the figures using a vector format

Update all the figures using a vector format (e.g. SVG) rather than the current bitmap formats which have too low resolution.

See https://issues.omg.org/browse/DDSSEC12-33 for background.
Since this revision of RTPS will take into account the extensions for DDS-Security, define a flag in Data/Frag submessages to indicate that the SerializedPayload submessage element was modified for security.

Reserve a flag in DATA and DATA_FRAG Submessages to indicate the SerializedPayload has been transformed

A flag in DATA and DATA_FRAG Submessages was reserved to indicate that the SerializedPayload has been transformed.

The role of Table 9.12 is "...the list of ParameterIds used to encapsulate the data for the built-in Entities" (9.6.2.2.2).

The following ParameterIds are not used for built-in entities and therefore do not belong in this table: PID_BUILTIN_ENDPOINT_SET, PID_PROPERTY_LIST, PID_TYPE_MAX_SIZE_SERIALIZED, PID_ENTITY_NAME, PID_KEY_HASH, PID_STATUS_INFO (the last six rows). Some of them are already in Table 9.14.

Remove ParameterIds incorrectly listed Table 9.12 and Add Missing Usage for PID_TYPE_MAX_SIZE_SERIALIZED

PID_KEY_HASH and PID_STATUS_INFO are incorrectly listed in Table 9.12 which lists the data for the builtin entities. They are already listed in Table 9.14 'Inline QoS parameters' so they have been removed from Table 9.12. A new optional attribute has been added to WriterProxy for PID_TYPE_MAX_SIZE_SERIALIZED.

There are protocol messages that have sample-specific inlineQoS that comes from the higher layers (for example the original writer info) we need to add this to the CacheChange.inlineQos and the virtual machine should be updated that in addition to getting inlineqos from the writer, it should also get it form the cache change itself

Retrieve inlineQoS from CacheChange

InlineQos can come from a CacheChange as well as from the writer. CacheChange has been updated to include inlineQos and the virtual machine has been updated to retrieve this inlineQoS as well.

"All implementations must support the Wirter Liveliness Protocol", Wirter should be Writer

Fix typo

Replace "Wirter" with "Writer"

The figures and captions are identical. Figure 8.29 should be removed.

This issue is already included in DDSIRTP23-23

Already handled in DDSIRTP23-23

The ParticipantMessageData appears defined in 3 places:

Figure 8.26 - ParticipantMessageData

Section 9.6.2.1 (Data Representation for the ParticipantMessageData Built-in Endpoints) in the IDL

Section 9.6.2.1 In the CDR encoded representation.

These definitions are not consistent. The IDL definition appears to be the correct one. This should be verified and the others should be adjusted to match it.

Already covered by DDSIRTP23-23

Close as duplicate as it is already covered by DDSIRTPS23-23

The presence of the final three rows of the table with "Reserved for future use" is confusing, why is it in the specification if all (non-vendor-specific) PIDs are effectively reserved?

Remove PID_GROUP_ENTITYID and PID_PARTICIPANT_ENTITYID

PID_GROUP_ENTITYID and PID_PARTICIPANT_ENTITYID are not currently used for any purpose and are not being sent by any known implementors. They have therefore been removed from the specification.

Section 9.3.2 largely consists of a single 5-page table (Table 9.4). This creates a usability issue for the spec where important lists of constants (like the BuiltinEndpointSet_t values) need to be found within the huge table instead of directly being referred to by other parts of this spec or other specs (Security).

Split Table 9.4

When current rows of Table 9.4 contain their own tables of constants (beyond just trivial constants that we don't expect to change in future minor versions), make these constants their own tables.

Section 9.4.2.6 (SequenceNumberSet)

Specifies that

A valid SequenceNumberSet must satisfy the following conditions:
• bitmapBase >= 1
• 0 < numBits <= 256
• there are M=(numBits+31)/32 longs containing the pertinent bits

This is seems like an error in how the spec is worded.
What it was trying to say is that for the bitset to represent a set f bits then it must be that 0 < numBits <= 256

However the case with numBits=0 is still valid. It represents an empty set, but the bitmapBase still carries information since. This is use by the ACKNAK sub-message to acknowledges al sequence numbers less or equal to bitmapBase without Nacking anything.

*Update SequenceNumberSet definition to explicitly allow 0-bits *

The current definition of the SequenceNumberSet requires at least 1 bit in the bitset but there are use cases where 0 bits are needed so the definition will be updated.

Users found that OpenDDS and CoreDX did not interoperate due to different interpretations of the Final Flag in AckNack.

The use of FinalFlag in Heartbeat is pretty clear, but its extension to AckNack seems to be under-specified.

This section tells us little:

The FinalFlag indicates whether a response by the Writer is expected by the Reader or if the decision is left to the Writer. The use of this flag is described in 8.4.

That last sentence is unhelpful as section 8.4 takes up about 60 pages. Searching through 8.4 results in very little about the AckNack's Final Flag.

The key question is what is meant by "response by the Writer". Considering AckNacks that are both Final and have at least one "1" bit in the bitmap, is the Writer obligated to send the nacked DATA?

a. One interpretation is that the Final Flag is a simple (constant-time) indication that the Writer need not resend DATA even with a "1" in the bitmap – in this scenario the Writer need not even read the bitmap. The AckNack is still useful because the bitmapBase can bump up the acknowledge sequence number.

b. The other interpretation is that the presence of a "1" in the bitmap overrides the Final flag and the Writer must reply with DATA. In this interpretation the Final flag is used to indicate whether or not another HEARTBEAT is sent "soon" (instead of waiting for periodic heartbeat), but has no impact on sending DATA.

Clarify the meaning of the ACKNACK Final Flag

The description of the ACKNACK final flag is not clear as to what is the expected behavior. The description needs to be updated to make clear that the absence of the Final Flag requires that the Writer send a HB and the presence of the flag leaves the decision up to the Writer.

The DDS-Security 1.1 specification updated the RTPS minor version to 3. Consequently the result of the RTPS 2.3 RTF should be update the Minor version to 4 (not 3), assuming there are changes to the protocol.

The section that states the RTPS minor revision should also reference DDS-Security so is clear that that specification may also update the minor versions and future revisions of RTPS take it into consideration.

Incorporate changes made by the DDS-Security specification to RTPS into the RTPS spec

The DDS-Security specification reserves new ParameterIds and submessageIds which need to be included as reserved in the RTPS spec. Also, due to these changes, the DDS-Security Spec updated the RTPS minor version to 3, therefore the newest version of the RTPS spec shall be 2.4.

The DDS-Security specification reserved a range of parameter IDs. Specifically section 7.4.1.3 (Reserved RTPS parameter IDs) of DDS-Security 1.1 states:

This specification reserves the RTPS Simple Discovery Protocol ParameterIDs in the range: 0x1000 to 0x1FFF and 0x5000 to 0x5FFF.
The second interval covers the same range of parametersID, except they have the must-understand bit set.
This reserved range applies to RTPS version 2.3 (see 7.3.6.1) and higher minor revisions of RTPS. Future revisions of the DDS-RTPS specification shall take into consideration this fact.

This reserved range should be included into the RTPS specification itself and a reference to DDS-Security so future revisions of RTPS can respect this reservation.

Duplicates DDSIRTP23-39

The proposal for issue DDSIRTP23-39 covers all changes required by the next version of the RTPS specification as a result of the most recent DDS-Security spec.

Figure 8.1 shows a DataReader and DataWriter but these classes are not explained in Table 8.1 as all other are.

These classes seem unnecessary to the explanations on section 8.2.1 so they should be removed from the figure. They are already explained in Figure 7.3.

In addition the explanation of the attributes in Table 8.2 mentions GUID_t, GuidPrefix_t, EntityId_t, Locator_t, VendorId_t, and ProtocolVersion_t which are not shown in the figure.

Figure 8.1 should be updated to show were those attributes are used.

Figures 8.2 and 8.5 are missing the Participant attribute guidPrefix and the Endpoint attribute endpointId

Update figure 8.1, 8.2, and 8.5

Update figure 8.1. Remove DataWriter and DataReader and adding the missing attributes as described in the issue.
Update figures 8.2 and 8.5 adding the missing attributes

Table 9.4
Property_t and EntityName_t are unused, so these can be removed without making any actual changes to the protocol

Table 9.12
PID_PROPERTY_LIST is unused, remove it from the table

Do not remove Property_t and EntityName_t

There are open issues to add EntityName_t and Property_t to the DDS specification and Property_t is already being used in the DDS-Security Spec. These two types and PIDs have therefore not been removed from RTPS as they will be used once they have been added to the DDS specification.

Table 8.73 "availableBuiltinEndpoints" describes the PIM's datatype BuiltinEndpointSet_t using 6 constants (note: change text in this table to indicate that each constant denotes a potential member of the Set not the Set itself). The PIM also maps these constants to EntityId_t values in 8.5.4.2.

The PSM fails to directly reference these constants for BuiltinEndpointSet_t in Table 9.4.

To satisfy the PIM, the PSM must also describe how vendors add extensions to this list. Perhaps the best way to do that is to use a separate vendor-specific PID, but that should be described in the PSM to avoid vendors using reserved bits.

It would be good if the spec was consistent about naming for the PSM constants. Some start with DISC_ while others don't. Some use the brand new terms "announcer" and "detector", others don't.

Clarify the PIM-PSM mapping for BuiltinEndpoints

There are some inconsistencies between the PIM and PSM with regards to the builtin endpoints which have bits reserved in the availableBuiltinEndpoints. Some possible values are missing from the PIM that are referenced in the PSM and vice versa. Because the PIM and PSM use different names, the mapping between the constants that are defined in the PIM and their corresponding constants in the PSM has also been clarified.

resendDataPeriod is listed in Figure 8.15, Table 8.49, and pseudocode 8.4.7.2.1
The issue is that nothing in the definition of StatelessWriter's behavior (8.4.8) describes how resendDataPeriod is used.

Remove resendDataPeriod from the StatelessWriter reference implemenation

The member resendDataPeriod of the StatelessWriter is not referenced in the described StatelessWriter's behavior and seems unnecessary. It will therefore be removed.

It seems as though implementations are using PID_BUILTIN_ENDPOINT_SET instead of PID_PARTICIPANT_BUILTIN_ENDPOINTS for the ParticipantProxy::availableBuiltinEndpoints.

Some implementations accept both, but from the information we have so far, all implementations are sending PID_BUILTIN_ENDPOINT_SET.

We can add this PID to Table 9.17 as described in DDSIRTP23-48.

Merged with resolution of DDSIRTP23-11

The resolution of DDSIRTP23-11 was to deprecate a number of PIDs, the resolution of this issue was therefore added to that proposal by adding the deprecated PID_PARTICIPANT_BUILTIN_ENDPOINTS to the table described in DDSIRTP23-48.

Per the resolution of http://issues.omg.org/browse/DDSXTY12-10 the lower 2 bits of the encapsulation options shall be use to encode how many padding bits were added.

This informations should be added to section 10.2.1.2 and an issue should be added to XTYPES 1.3 to remove it from there.

Furthermore to avoid confusion/ambiguities we should be explicit about the endianess used to encode the "ushort options".

Unless this would cause problems to existing implementations I would suggest we either state that the "ushort options" is always serialized using BigEndian or equivalently we change the type to octet[2] instead of "ushort".

The reason is that the alternative interpretation, namely use the endianness implied by EncapsulationIdentifier is not well defined in all cases. Not all EncapsulationIdentifier kinds explicitly select an Endianness. The ones referenced in RTPS: CDR_BE, CDR_LE, PL_CDR_BE, and PL_CDR_LE that are defined in do. But others, including the "XML" defined in XTYPES do not. So RTPS could not make a general statement about the encoding of the "ushort options" unless the statement is to fix the endianess independent of the EncapsulationIdentifier.

Merged with resolution of DDSIRTP23-42

The resolution of this issue has been merged with the resolution of DDSIRTP23-42

The seconds portion of the Time_t structure used for InfoTimestamp is limited to 32 bits, so it can't represent dates past 2038.

Update Time_t to have an unsigned seconds field

To support time stamps past the year 2038. the type of the seconds member in Time_t has been updated from a signed integer to unsigned. This will not rollover until the year 2106.

The previous RTF (2.2) had an issue (#7) that cleaned up IDL syntax. A note in the resolution of that issue indicated that RTPS should have a normative for this. Back then, that reference was to formal/11-11-01, a chapter of CORBA. Today we can use IDL 4.1 formal/17-05-07.

Similarly, the spec is not implementable without knowledge of the CDR encoding. This is defined in formal/12-11-14, chapter 9.

Add missing normative references

There are some missing normative references which should be added in section 3. They are:

• IDL 4.1
• CDR
• IETF RFC 1305 (NTP Time)
• IETF RFC 1321 (MD5)

In section 8.4.12.1 Best-Effort StatefulReader Behavior the state machine does not handle the GAP message.

Best-Effort readers also process GAP messages so this should be reflected in the state machine.

Add transition for when Best Effort Readers Receive GAP messages

The Best-Effort Stateful Reader Behavior should include logic for when a GAP message is received, similar to the logic already present for its Reliable counterpart.

The Locator_t contains an integer field that identifies the type of locator. Currently only the values -1, 0, 1, 2 are defined. Which correspond to reserved values as well as UDPv4 and UDPv6.

Future revisions of the protocol may define additional kinds for things like TCP v4, TCPv6, shared memory and other transports.

At the same time vendors are using this field to identify their own custom transports.

To avoid collisions with future revisions of the protocol, the RTPS specification should reserve a range. For example, all kinds with values less than 0x00008000. These values should be reserved for future revisions of the protocol. Vendors that want to define their custom transport should use Locator_t kind with values between 0x00008000 and 0x0000FFFF (inclusive). And these values should be interpreted in the context of the RTPS vendorId so that different vendors can use the same value to mean different things.

Reserve protocol and vendor specific ranges for the Locator_t kind

To avoid future conflicts with vendor-specific Locator_t kinds, ranges have been reserved for the protocol, for vendors, and for users.
0x00000003 - 0x000001f are reserved for vendors
0x00000020 - 0x00007ffff for future use by the spec.
0x00008000-0x01FFFFFF (inclusive) for use by vendors.
0x02000000 and greater are reserved for third-party add-ons

Sending a HeartBeat message when a writer has no data to announce is unspecified.

Update the definition of the HeartBeat Submessage to allow situations in which the Writer has no data to announce

The HeartBeat submessage has been updated to better handle the situation in which a Writer has no data in its cache to announce.

The web link pointed to by the specification: http://www.omgwiki.org/dds/content/page/dds-rtps-vendor-andproduct-ids results in a page not found returned from the server. A brief search of the internet for the list of VendorIds results in nothing found.

*Update URL for assigned vendor ids *

The URL for the assigned vendor and product IDs has been updated to point to a valid location with that information.