The original text reads:
The RTPS protocol version 2.5 defines the following special values.
PROTOCOLVERSION_1_0
PROTOCOLVERSION_1_1
PROTOCOLVERSION_1_0 PROTOCOLVERSION_1_1
PROTOCOLVERSION_2_1
PROTOCOLVERSION_2_2
PROTOCOLVERSION_2_2
PROTOCOLVERSION_2_4

Two PROTOCOLVERSION_2_2 appeared
I think it should be PROTOCOLVERSION_2_3

The InfoSource is meant to hold the same information inside the RTPS message such that an RTPS message can be used to relay RTPS submessages from other sources and the RTPS submessages are interpreted in the correct content of the originating Participant.

The RTPS Header Extension submessage was added to extend the RTPS Header in a way that did not break interoperability with existing systems. So logically the information inside RTPS Header Extension belongs in the RTPS Header. Therefore it should also be added to the InfoSource

Primarily targets environments that don't have multicast. Implementations support using a "discovery" service. In some cases it operates "transparently".

The SIG and vendors have discussed this and the conclusion was that it would be best to add tome description in the RTPS spec that explains how the discovery service would work and interoperate.

9.4.2.6 SequenceNumberSet defines one of the rules for validity as
bitmapBase >= 1

We have observed that other implementations use bitmapBase 0 in AckNack submessages. There seems to be no downside to just accepting these as valid even though the spec currently says they are not.

The RTF should determine if this condition in 9.4.2.6 can just be removed.

IDL value annotation for GAP is @value(8x08) instead of @value(0x08).

Table 8.42 defines the elements that comprise a DataFrag submessage. It includes the dataSize as one of those elements.

Section 9.4.5.5 must map all elements of the submessage to the PSM types. However, it is lacking a dataSize. Instead it includes a sampleSize. SampleSize should be renamed dataSize and perhaps should use a well-defined type from 9.3.2 such as MessageLength_t.

Section 8.3.3.1.2 indicates which version of the protocol is specified in this document.
No other place in the document should attempt to do the same, all others should refer back to 8.3.3.1.2. 8.3.3.1.2 should define the constant "PROTOCOLVERSION" as a symbol that indicates the current version (2.6). Add a reference to section 8.6 which defines how different versions can interoperate.

In Table 8.2:
In the cell to the right of ProtocolVersion_t, remove the text from "The following values are reserved..." until the end of the cell. Replace it with a reference to 8.3.3.1.2.

In Section 8.3.5.3:
Remove the text from "The RTPS protocol version X.Y defines..." until the end of this subsection. Replace it with a reference to 8.3.3.1.2.

In Section 9.3.2.1:
Remove the IDL comment

// The implementations following this version of the document
// implement protocol version 2.4

The spec uses two numbering schemes for bits:

For example 9.4.1 (Overall Structure)

0...2...........7...............15.............23. .............31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

But then in 9.4.4 (Mapping of the RTPS Header)

0...2...........8...............16.............24.............. 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should be consistent. The more correct scheme appears to be:

0...2...........8...............16.............24. .............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

With this scheme the number represents the number of bits that appear before the number (the "." positions). The other scheme seems inconsistent. "0" is placed ahead of the bit of that order, but '7' and the rest are placed after.

LivelinessFlag in the last paragraph should be GroupInfoFlag, i.e.,
"The GroupInfoFlag is represented with the literal ‘G’. G=1 means the HeartBeat includes the currentGSN,
firstGSN, and lastGSN. The value of the LivelinessFlag can be obtained from the expression:"
should be changed to
"The GroupInfoFlag is represented with the literal ‘G’. G=1 means the HeartBeat includes the currentGSN,
firstGSN, and lastGSN. The value of the GroupInfoFlag can be obtained from the expression:"

Details available to RTF members

In the wire representation figures of 9.4.5.4 and 9.4.5.5, `SequenceNumber writerSN` is shown as:

+---------------+---------------+---------------+---------------+
+           SequenceNumber       writerSN                       +
+---------------+---------------+---------------+---------------+

as if it only occupies 4 bytes.

In all other places (9.4.2.6, 9.4.5.6, 9.4.5.7, 9.4.5.8, 9.4.5.14, and 9.6.4.7), SequenceNumbers are represented explicitly as 64-bit values:

+---------------+---------------+---------------+---------------+
|                                                               |
+           SequenceNumber       gapStart                       +
|                                                               |
+---------------+---------------+---------------+---------------+

In hindsight, the plus signs does indicate that the field is larger than it looks, but unless there is a clear reason, can those representations be unified to remove potential confusion and provide better readability?

`PID__DOMAIN_ID` in table 9.18 has an extra underscore. It should be `PID_DOMAIN_ID`.

Section 9.3.1.2 lists the three pre-defined values of the entity key field in EntityId_t as:

• ‘8 for user-defined entities.
• ‘11’ for built-in entities.
• ‘01’ for vendor-specific entities

The user-defined entities definition should be '00'.

Table 8.42 gives the Structure of the DataFrag Submessage. The last field is specified to have type "SerializedPayload". If this would be the case, the contents of that field should be decodable as a SerializedPayload object, as specified in Section 10, but really the field seems to contain just a fragment of a SerializedPayload. A complete series of fragments must be concatenated to get a valid SerializedPayload. Therefore, the type should be changed to indicate that it is a fragment, not a whole object.

A similar problem exists in Section 9.4.5.5 DataFrag Submessage.

More generally, there seems to be confusion in terminology between SerializedPayload / SerializedData / SerializedDataFragment.

The latter two seem to be suitable for use in the payload field of Data and DataFrag submessages, respectively, and they are defined in 8.3.5.17 -.18, but SerializedPayload is not defined in 8.3.5 at all.

Section 9.4.2 (PSM) again does not define a mapping for SerializedData / SerializedDataFragment, but for SerializedPayload instead.

Please clarify the relationship between the aforementioned terms.

At the wire-protocol level currently only DataWriters and DataReaders have Partitions.

It would be useful to have a similar concept/Qos at the DomainParticipant level. This would allow system deployments to control better participant matching.

While the same could be implemented by adding the the partitions to all Readers and Writers in the Participant the process would be tedious and far less efficient. For example with Participant partitions it would be possible for Participants that do not have a matching partition to avoid doing EndpointDiscovery.

In previous versions, ChangeForReader was specified and illustrated. The ChangeFromWriter (8.4.10.5) is still in place including its illustrated use (8.4.12.3). Is ChangeForReader removed on purpose or by accident? In my opinion, ChangeForReader should be defined as before.

The if statement on the second line should start on a new line.
Instead of:
```
ReceiverReceiver.unicastReplyLocatorList =
InfoReply.unicastLocatorList if ( MulticastFlag )

else

```

In the version 2.3 specs, a gap is inserted in case a cache change isn't available in the history cache. In the 2.5 specs, only the highest previously sent sequence number is taken into account to determine if agap should be inserted.
The shown logical actions will fail if the cache change with a_change_seq_num can't be located in the cache. in which case a gap should be inserted as well as in the 2.3 specs. Considering the explanation given for sending a gap because of the HISTORY QoS set to KEEP_LAST in the last paragraph on page 82, one should definitely consider the situation that a cache change is missing.

In 8.4.7.3 and 8.4.7.5, the variable highestSentChangeSN is used for the highest sequence number sent. In 8.4.8.1.4 and subsequent paragraphs, the variable highest_sent_seq_num is used for the same purpose.
Also, there is a spelling error in the variable's name higuest_sent_seq_num instead of highest_sent_seq_num.

On initialization of the ReaderLocator, the highestSentChangeSN is set to SEQUENCE_NUMBER_INVALID which is not defined in this specification. In 8.4.7.2 RTPS StatelessWriter the function unsent_changes_reset is defined as resetting highestSentChangeSN to the value 0. Either define SEQUENCE_NUMBER_INVALID as being the value 0 and use it also in function unsent_changes_reset or use the value 0 instead of SEQUENCE_NUMBER_INVALID. Or, is there a good erason to make a distinction between SEQUENCE_NUMBER_INVALID and 0?

In 8.3.8.6 Heartbeat, the fields writerSet and secureWriterSet are defined. The equivalent wire presentation is missing however.

Both the parameter id and length fields are defined as short. These should be unsigned short.

The masks used in table 9.6 should be written as 0x8000 and 0x4000 instead of 8000 and 4000

Using the header_extension submessage to pass the message's CRC seems to me the wrong place. It would be more logical to add the CRC at the end of the message for obvious reasons. First processing the whole potentially large message and then inserting the CRC somewhere in the front, requires extra resources. Also, this makes it unnecessary to first use zero's for the value of the CRC field while calculating the message's CRC. Adding the CRC just to the end of the message, maybe in a submessage of its own if you like, is a much better solution.

Moreover, the receiver has been designed in such a way that while processing a message it can hand off processed submessgaes right away, which is rather nice. With a message CRC ckheck, either in the header or the tail of the messgae, mitigates this feature since one first has to process the whole message before deciding if the message, and therefor the submessages, is valid. Iff some CRC checking should be implemented, do this at the level of a submessage.

With a 128 or just 64 bit CRC bit checksum, the designer clearly had huge message sizes in mind, which doesn't seem a good design decision to me.

The line

The value of the UExtension4Flag can be obtained from the expression:
T = SubmessageHeader.flags & 0x04

should read:

The value of the TimestampFlag can be obtained from the expression:
T = SubmessageHeader.flags & 0x04

In the bullet list, the text of second item seems to be incomplete. It now reads:

• The GUIDs of Endpoint Groups within a Participant

The algorithms for 32 and 64 bit crc checks are defined but the one for 128 bits is missing.

Sorry, had this flag checked by accident.

The RTPS V2.5 spec explains how to implement the Group ordering/coherency feature in section 8.7.5 and 8.7.6. In these sections it is explained that the scope of the coherent update (i.e. which coherent Writers the coherent Publishers contains) is communicated by means of the GroupDigest, which is the first part of an MD5 hash of an ordered list of CDR encoded EntityIDs of those Writers.

In order for the Subscribing side to validate whether all relevant Writers have successfully been discovered, it will create a digest from all EntityIDs of the writers discovered so far, and then compare that to the Digest received from the publisher. Only when the two digests are identical you know that you have successfully discovered all participating Writers.

Problem for this is that you need to know which Writers belong to which Publisher: you can't just calculate a digest over all discovered Writers because not all discovered Writers might be part of the same group coherent Publisher.

That means I need to to know the GROUP_GUID or at the very least the GROUP_ENTITY_ID of the Publisher of a Writer in order for me to determine which discovered Writer to include in the digest I calculate to do the comparison.

However, it is not clear from the spec how this GROUP_GUID or this GROUP_ENTITY_ID is communicated from the publishing side to the subscribing side. The spec introduces a separate PID for both the GROUP_GUID and and the GROUP_ENTITY_ID, but nowhere does it say which one to send out from the Publisher side, or to which message to attach this information. This information is necessary however in order to build an interoperable group coherent implementation.

There is an inherent DoS network amplification attack that exploits peer-to-peer discovery. See https://issues.omg.org/browse/DDSIRTP26-6

This issue should be addressed by DDS-Security. Likely using some pre-shared key mechanics to protect all messages not otherwise protected. For example, the authentication handshakes.

The CRC-64 polynomial selected in DDSIRTP25-12 (a.k.a. CRC-64-iso) has issues that make it inadequate for this specification:

• The "only" formal reference is ISO 3309 which has been "withdrawn". The ISO 3309 page (https://www.iso.org/standard/8561.html) says it has been revised by ISO/IEC 13239:2002. However ISO/IEC 13239 does not mention CRC 64 at all. Moreover the later versions of the (withdrawn) ISO 3309, for example ISO-IEC-3309:1993 only mention CRC-32 polynomials, no CRC-64 polynomials.
• It seems to have fallen out of use: The two references that Wikipedia says use this polynomial (Swiss-Prot/TrEMBL) and HDCL seems to no longer use the CRC64-ISO polynomial:
  1. Swiss-Prot/TrEMBL has changed to a different CRC-64 polynomial (see https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.368.2736&rep=rep1&type=pdf).

2. HDLC is defined in the ISO/IEC 13239 and it does not define CRC 64 bit polynomials.

Because of this the polynomial should be changes to the so called CRC-64-ECMA which as a specification that is not deprecated https://www.ecma-international.org/publications/standards/Ecma-182.htm. This polynomial is used in other relates specifications such as AUTOSAR: AUTOSAR 4.3 added CRC-64 with the ECMA polynomial (https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SWS_CRCLibrary.pdf).

Moreover specifying the polynomial coefficients is not enough to fully specify the checksum. Instead there are additional rules about padding etc. For this reason the specification should be amended to include all the additional information.

Replace the CRC-64 polynomial with the CRC-64/XZ checksum polynomial

Amend the resolution of DDSIRTP25-12 replacing the CRC-64 checksum polynomial and description with one that used the so called CRC-64/XZ checksum as utilized in AUTOSAR Classic Platform release R20-11, Specification of CRC Routines.

Expand the description of the CRC-32 and CRC-64 algorithms to define all the parameters needed to uniquely compute and validate the checksum, including the polynomial coefficients, whether the input data and output data are reflected, the initial value and the final XOR value.

The specification uses a field called remoteGroupEntityId (see Table 8.67) to identify Publishers and Subscribers.

Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

It seems that this is related to PID_GROUP_GUID.
But Table 9.14 says that PID_GROUP_GUID is "reserved for future versions"

The relationship between this should be clarified.
Furthermore the implementation of GROUP order and coherent access (8.7.5 and 8.7.6) require knowledge of which DataWriter belong to which Publishers. But how this is discovered is not specified.

Minimally we should say that:

A Publisher has a GUID that should be constructed from the GuidPrefix_t and an Entity_id.

The PublisherGUID shall be communicated vis discovery using either a PID_GROUP_ENTITYID or PID_GROUP_GUID

The WriterProxy::remoteGroupEntityId should contain the Publisher GUID

Duplicates DDSIRTP25-3

Duplicates DDSIRTP25-3

The specification uses a field called remoteGroupEntityId (see Table 8.67) to identify Publishers and Subscribers.

Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

It seems that this is related to PID_GROUP_GUID.
But Table 9.14 says that PID_GROUP_GUID is "reserved for future versions"

The relationship between this should be clarified.
Furthermore the implementation of GROUP order and coherent access (8.7.5 and 8.7.6) require knowledge of which DataWriter belong to which Publishers. But how this is discovered is not specified.

Minimally we should say that:

A Publisher has a GUID that should be constructed from the GuidPrefix_t and an Entity_id.

The PublisherGUID shall be communicated vis discovery using either a PID_GROUP_ENTITYID or PID_GROUP_GUID

The WriterProxy::remoteGroupEntityId should contain the Publisher GUID

Add information on the identification of Publisher and Subscriber

Indicate that the Publisher and Subscriber are identified by a GUID and that the GUID is propagated via the Publication and Subscription builtin Topic data.

The GAP message indicates a gap in sequence numbers that is "not available" to the DataReader. It may be caused by filters (time, content), history keep last, or lifespan.

In some cases the reason behind the gap is important to the receiving application. For example a missing sequence number caused by a writer-side content filter does not invalidate a coherent change. However if the gap is caused by keep-last history the coherent change must be discarded by the subscriber/reader.

Currently there is no way for the receiving application to tell the difference.

There may be also other situations where it may be desirable to account for the different reasons that cause a gap. For example if the reader maintains a "sample lost count" it needs some way to distinguish sample loss from things it it chose to not receive.

The RTF should address this issue and provide the means to discriminate these cases. A possible approach would be include the information in the flags of the GAP message.

Extend GAP submesage to provide information about the reasons for the samples gapped

Extend the GAP message with optional counters to indicate the numbers of samples that are gapped that fall into one of 3 categories:

• Non-relevant Samples
• Relevant Samples
• Unclassified Samples

Non-relevant samples are those that are intentionally not sent to the DataReader because they do not match some reader-specified criteria. These include samples filtered dues to a content-filtered topic, samples filtered due to a time-based filter, samples directed to other data readers, etc.
Non-relevant samples are not considered “lost” and do not invalidate coherent changes.

Relevant samples are those that should have been received by the DataReader but are not received due to various reasons. They include samples that are lost by the transport when using BEST_EFFORT datawriters, samples replaced in the DataWriter cache due to a HISTORY kind KEEP_LAST, samples removed from the DataWriter cache due to LIFESPAN, etc.
Relevant samples are considered “lost”. They are counted as such and invalidate coherent changes.

Unclassified samples are those that are not accounted for by the above two categories. This may be because the DataWriter cannot determine or does not keep track of the reason some sequence numbers are missing for a DataReader.
Unclassified samples are treated the same way we treat the samples missing dues to GAPs or HEARTBEATs in previous versions of the specification. That way the behavior is backwards compatible.

The updated GAP message would should like this:

0...2...........7...............15.............23...............31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   GAP      	|X|X|X|X|N|R|G|E| 	octetsToNextHeader      |
+---------------+---------------+---------------+---------------+
|        EntityId          	readerId                        |
+---------------+---------------+---------------+---------------+
|        EntityId          	writerId                        |
+---------------+---------------+---------------+---------------+
|                                                               |
+        SequenceNumber    	gapStart                        +
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
~        SequenceNumberSet	gapList                         ~
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
+        SequenceNumber    	gapStartGSN  [ only if G==1 ]   +
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
~        SequenceNumber    	gapEndGSN    [ only if G==1 ]   ~
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
+        ChangeCount             relevantCount      [if R==1]   +
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
+        ChangeCount             nonRelevantCount   [if N==1]   +
|                                                               |
+---------------+---------------+---------------+---------------+

Where the 'R' and 'N' are new flags and the added SequenceNumberCount sub-message elements are 64 bit counter encoded the same way as a sequence number:

+---------------+---------------+---------------+---------------+
|                      int32      low                           |
+   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   +
|                      int32      high                          |
+---------------+---------------+---------------+---------------+

If R==0, relevantCount shall be set to zero.
If N==0, nonRelevantCont shall be set to zero.

The number or unclassified samples shall be set by the formula:

unclassifiedCount  = (gapList.bitmapBase - gapStart) + gapList.numBits
                  -(relevantCount + nonRelevantCount)

In other words, any samples that appear as part of the GAP but are not covered by the relevant count and the irrelevant count.

The following issue https://issues.omg.org/browse/DDSIRTP23-6 was deferred in the last RTF so it should have been moved to this RTF. Since it didn't happen automatically we are entering this issue manually here.

For details on the previous discussion and what was proposed as a resolution see DDSIRTP23-6.

Overall Approach
-----------------------
Introduce a new RTPS submessage "RTPSHeaderExtension" with the following elements:

• messageLength

The messageLength indicates the length of the RTPS message
The rtpsSendTimestamp indicates the time when the message was sent
The messageChecksum

Mechanisms to add additional information in future revisions.

The RTPSHeaderExtension submessage, if present, shall follow immediately after the RTPS Header

The DDS Security specification will leave this RTPSHeaderExtension following the RTPS Header and before the SecureRTPSPrefixSubMsg. The length will be updated to the new length after processing by the security plugins.

Add CRC support via a HeaderExtension submessage

Introduce a new RTPS submessage "RTPSHeaderExtension" with the following elements:

• rtpsMsgLength (indicates the length of the RTPS message)
• rtpsPort (destination port for submessage)
• rtpsChecksum (message checksum)

The RTPSHeaderExtension submessage, if present, shall follow immediately after the RTPS Header.

7.6 enumerated list 5th bullet

• The transport will drop m essages if incomplete or corrupted during transfer

-> messages

8.2.4

Table 8.6 - RTPS Entity Attribues

-> Attributes

8.2.6

Table 8.9 - RTPS Endpoint configuration attribues

-> attributes

8.3.7.2.5 'Logical Interpretation' enumerated list 1st bullet (8.3.8.2.5 after revisions to the spec)

• If the DataFlag [...], the serializedPayload element is interpreted as
  the value of the dtat- object.

-> data-object

8.3.7.9.2 'Content' (8.3.8.10.2 after revisions) Table 8.42 (8.48 after revisions) 2nd row 3rd column (meaning)

Indicates the protocol used for subsequent Sudmessages.

-> Submessages

8.4.2.3.2 'Readers must respond eventually after receiving a HEARTBEAT that indicates a sample is missing' 1st para 2nd sentence

This requirement only applies if the Reader
can accomodate these missing samples in its cache [...]

-> accommodate

Replace "bandwith" with "bandwidth" in section 8.4.2, and 8.7.2.2.4 (2 times total).

8.6.2 enumerated list 3rd bullet

* The meaning of submessageIds cannot be modfied.

-> modified

8.7.2.2.4 1st sentence

Implementations may optimize bandwith usage by applying a time-based filter on the Writer side.

-> bandwidth

8.7.4 4th para 1st sentence

When RTPS sends a Data Submessge to communicate instance state changes it may include only the Key of

-> Submessage

8.7.4 6th para numbered list

1. If the previous update to the instance passed the filter, [...]
that either includes the data value, or else indicates the IntanceState is ALIVE_FILTERED.

-> InstanceState

8.7.9 3rd para

The RTPS protocol suports this forwarding of messages by including information of the original writer.

-> supports

9.1 enumerated list 4th bullet

• [...]; this allows multiple RTPS endpoints to
  share a single operat- ing-system UDP resource (socket/port) while

-> operating system

9.3.1.2 Mapping of the EntityId_t

typedef octet OctetArray3[3]; struct {
OctetArray3 entityKey; octet entityKind;
};

-->

typedef octet OctetArray3[3]; 
struct EntityId_t {
    OctetArray3 entityKey; 
    octet entityKind;
};

9.4.5.7.1 Flags in the Submessage Header

Reference to (8.3.6.2).

-> 8.3.8.6.2

9.4.5.15.1

The MulticastFlag is [...]. M=1 means the InfoReplyIp4 also includes a
multicastRLocator.

-> multicastLocator

9.6.2.3 1st sentence

The port number expresssions use the following parameters:

-> expressions

9.6.4.9, 7th para

The DisposeedFlag is represented with the literal 'D.'

-> DisposedFlag

Apply the typo corrections specified in the issue description

Perform the suggested corrections.

It seems that some ranges reserved by other specifications (e.g. XTypes type service) are missing from RTPS. They should be added:

9.4.5.1.1.1 for SubmessageIDs
to 9.3.1.3.1 for the EntityIDs
Table 9.12 for ParameterIDs

Maybe always list the same set of specs: DDS Security, XTypes, DDS-RPC? and indicate explicitly if a specification does not reserve anything.

Also figure out whether new builtin endooints show up under the "availableBuiltinEndpoints" see Table 8.73 also the IDL in 9.3.2
Right now there is a comment in the IDL that says:

/* Bits 12-15 have been reserved by the DDS-Xtypes 1.2 Specification
and future revisions thereof.
Bits 16-27 have been reserved by the DDS-Security 1.1 Specification
and future revisions thereof.
*/

Maybe this needs ti be more explicit and get its own section.

Be more explicit about submessageID, PatameterIDs and EndpointIDs reserved by other DDS specifications

Create a new subsection to describe the reserved bits in the availableBuiltinEndpoints.

Add information to section 9.3.1.3.1 'EntityIds Reserved by other Specifications' to include the endpoints reserved by XTYPES

Add a new subsection under 9.3.2 'Mapping of the Types that Appear Within Submessages or Built-in Topic Data' to fully describe the content of the 9.3.2.12 BuiltinEndpointSet_t

Create new subsection before 9.6.5 'ParameterIds Deprecated by the Protocol' to define parameter IDs reserved by other specifications.

XTYPE 1.3, section 7.6.8 "Interoperability of Keyed Topics" provided amended text for Clause 9.6.3.8 in the RTPS spec. This text should be applied to the RTPS spec.

Replace the text in 9.6.4.8 'KeyHash (PID_KEY_HASH)'

Replace the text in 9.6.4.8 KeyHash (PID_KEY_HASH) with the one provides in DDS-XTYPES 1.3, section 7.6.8 "Interoperability of Keyed Topics" p

In the message module, the submessage gap defines the flag GroupInfoFlag and the fields gapStartGSN and gapEndGSN. However, in the PSM, both this flag and the two fileds are not specified further.

Duplicates DDSIRTP25-7

Merged with DDSIRTP25-7

The previous version of the spec (formal/14-09-01) contained the following in Table 9.4
#define SEQUENCENUMBER_UNKNOWN {-1, 0}
However, the equivalent definition is missing in the 2018 "Beta" spec.

Add SEQUENCENUMBER_UNKNOWN

Add specification for SEQUENCENUMBER_UNKNOWN with definition matching previous versions of the protocol (high = -1, low = 0)

Some transports have limited bandwidth and may benefit from compressing the RTPS message prior to being sent over the transport.

This is something that could be added in a reasonably simple manner by considering this part of the transport PSM.

Defer to the next RTF.

Defer to the next RTF.

The INFO_AGE submessage is semantically similar to INFO_TS, but it contains a Duration_t instead of a Time_t. It assigns a time to subsequent submessages that the service may use for functionality like lifespan and sample ordering.

Transmitting a sample age gives the receiver an inexact timestamp. There will be an unknown time span between the time the sender calculates the age and the time the receiver transforms it back to a local time. If the receiver does no adjustment based on estimated latency, the calculated time will always be too high. However, the error will in practice be bounded and in many scenarios the receiver will have a time that is within one second of the actual sample time.

Kongsberg uses a submessage like this today for deployments where no correct time source is available. This might be because the system has to be fully operational before a good time source is ready, or because some systems have requirements that mandate that the system clock must be adjustable. We have found that this is a better solution than attempting to have some form of synchronized "DDS time" on the network, because coming up with a network time that works very quickly at startup and is robust to network fragmentation is challenging.

The use of the INFO_AGE message is enabled by a vendor specific configuration option to the participant containing the publisher. It may either be sent as an alternative to INFO_TS or in combination with INFO_TS to allow the subscriber to determine which time to use an also for compatibility with systems without support for INFO_AGE.

INFO_AGE allows two features on systems with no time synchronization:

• Full support for sample lifespan QoS, as long as lifespan is an order of magnitude larger than network latency
• Partial support for by source timestamp QoS. It may be used to determine that some samples are clearly older than others, in practical use when the time difference is on the order of seconds. When estimated times are within the uncertainty margin, the subscriber needs to treat them as by destination order QoS to avoid surprising behavior when e.g. a writer publishes several samples in quick succession.

It should be noted that a system based on INFO_AGE with multiple readers and writers on the same topic will have a non-deterministic sample order on the readers.

Merge with DDSIRTP25-12

This can be merged with DDSIRTP25-12

Section 6.3 'Acknowledgments' lists the companies that contributed to the spec. This list needs to be updated to include the companies that contributed to the latests revisions (e.g. as members of the RTF task forces). This includes TwinOaks, Kongsberg, OCI, ADLink, MITRE, NSWC, etc.

We may also want to list contributor's names as we do for other specs.

Section 6.4 'Statement of Proof ...' needs to be updated this text has been carried from the original version. Something much stronger can be said today.

Copyright should be updated to include the companies in the 'Acknowledgments'

Update section 6.3 'Acknowlegments' an copyrights

As stated in the issue description update the acknowledgments and copyright to include people that participated in the various RTFs

The last condition seems wrong. Shouldn't that be greater than instead of less than?
If GroupInfoFlag is set and:
• currentGSN.value is zero or negative
• firstGSN.value is zero or negative
• lastGSN.value is negative
• lastGSN.value < firstGSN.value - 1
• currentGSN.value < firstGSN.value
• currentGSN.value < lastGSN.value

*Correct section 8.3.7.6.3 'Validity' (Hearbeat) *

I section 8.3.7.6.3 'Validity' (Hearbeat). Change:
currentGSN.value < lastGSN.value
to
currentGSN.value > lastGSN.value

In the message module, the submessage heartbeat defines the flag GroupInfoFlag and the fields currentGSN, firstGSN, lastGSN. writerSet and secureWriterSet. A specification for this flag and the fileds is missing in the PSM.

Add information on the GroupInfoFlag to 9.4.5.7 'HeartBeat Submessage'

Add missing information on the GroupInfoFlag and elements currentGSN , firstGSN, and lastGSN to section 9.4.5.7 'HeartBeat Submessage'

The wire representation of the GAP message given in 9.4.5.5. does not match the logical PIM description given in the sub-clause 8.3.7.4 in the following points:

• Section 9.4.5.5.1 mentions that "This Submessage has no flags in addition to the EndiannessFlag". Section 8.3.7.4.2 describes "GroupInfoFlag" with the following text "Appears in the Submessage header flags"
• "gapStartGSN" and "gapEndGSN" sequence numbers do not appear in the wire representation

Add GapInfoFlag information to section 9.4.5.6 'Gap Submessage'

Add information about the GapInfoFlag, gapStartGSN and gapEndGSN to section 9.4.5.6 'Gap Submessage'.

The following issue https://issues.omg.org/browse/DDSIRTP23-26 was deferred in the last RTF so it should have been moved to this RTF. Since it didn't happen automatically we are entering this issue manually here.

Defer to the next RTF. Until DDS 1.5 is adopted.

The resolution of this issue depends on some decisions that need to be made on the DDS specification. These issues have been filed against the DDS also modifications to the DDS15 RTF which is still ongoing.

Therefore the resolution of this issue is deferred to the next DDSI-RTPS RTF, which will be able to take into consideration the result of the DDS15 RTF.

RTPS version 2.3 updated modified Time_t to have the 'seconds' be of type unsigned long so that there would be no rollover in 2038.

This matches when it is shown in the IDL definition in 9.3.2.1 'IDL Definitions'

However Section 9.4.2.9 Timestamps illustrates the 'Timestamp' sub-message element with a 'long' instead of 'unsigned long' for the seconds part. It should be changed to illustrate 'unsigned long' as in:

Timestamp:

0...2...........8...............16.............24. .............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                 unsigned long    seconds                      | 
+---------------+---------------+---------------+---------------+ 
|                 unsigned long    fraction                     | 
+---------------+---------------+---------------+---------------+

Some transports have limited bandwidth and may benefit from compressing the RTPS message prior to being sent over the transport.

This is something that could be added in a reasonably simple manner by considering this part of the transport PSM.

The following issue https://issues.omg.org/browse/DDSIRTP23-26 was deferred in the last RTF so it should have been moved to this RTF. Since it didn't happen automatically we are entering this issue manually here.

The DDSI-RTPS Specification v2.1 does not currently specify how interoperable implementations should deal with Transient / Persistent data."

Defer this issue until the next revision

This issue requires additional time to be resolved. In order not to delay the adoption of the other important issues that are already resolved the RTF recommend it is deferred to the next RTF.

Original Description

The DDSI/RTPS wire protocol currently expects the transport to provide the size for the message – said in other terms, the current version of the protocol can only work with message oriented transports, such as UDP/IP.

This assumptions should be dropped in order to enable the use of DDSI/RTPS over stream oriented transports such as TCP/IP.

One possible approach to overcome this limitation w/o breaking backward compatibility with other implementation is to add a new sub-message element, say MESSAGE_LEN structured as follows:

+--------+--------+--------+--------+
|   ID   | Flags  | octect2NextSME  |
+--------+--------+--------+--------+
|          Message Length           |
+-----------------------------------+

In addition, for efficient parsing, if the sub-message above, when used, should be always placed right after the RTPS header.

RTF 2.3 Discussion

The RTF is recommending this issue is deferred until the transports PSMs that need it (e.g. the RTPS TCP PSM) define the requirements in a more complete way. The point is that these PSMs will need more than just the message length and RTPS should include a mechanism that is sufficiently generic to accommodate it. We are not ready yet to define it.

The latest proposal we had developed is below. It is left here so future revisions of the specification can leverage these ideas.

Overall Approach
-----------------------
Introduce a new RTPS submessage "RTPSHeaderExtension" with the following elements:

• rtpsMsgLength

The rtpsMsgLength indicates the length of the RTPS message

The RTPSHeaderExtension submessage, if present, shall follow immediately after the RTPS Header

The DDS Security specification will leave this RTPSHeaderExtension following the RTPS Header and before the SecureRTPSPrefixSubMsg. The length will be updated to the new length after processing by the security plugins.

Another option would be that the RTPSHeaderExtension (therefore not a header extension) would go after the SecureRTPSPrefixSubMsg, but it would be useless there because it can't be used before applying security. The length is no longer serving its purpose, so this is therefore not an option.

RTF 2.3 Latest Proposed Revised Text

In section 7.6 'The RTPS Transport Model', update the following bullet point as shown:

• The transport provides a means to deduce the size of the received message.

Update Figure 8.8 'Structure of RTPS Messages' to include RTPSHeaderExtension as one if the Submessages.

In Section 8.3.2 (Type Definitions), Table 8.13 'Types used to define RTPS messages', update the 'Purpose' column for Type SubmessageKind to add RTPS_HE to the list of reserved kinds:
Enumeration used to identify the kind of Submessage.
The following values are reserved by this version of the protocol:
RTPS_HE, DATA, GAP, HEARTBEAT, ACKNACK, PAD, INFO_TS, INFO_REPLY, INFO_DST, INFO_SRC, DATA_FRAG, NACK_FRAG, HEARTBEAT_FRAG

In section 8.3.2 'Type Definitions' in Table 8.13 add the following row after the row for 'Count_t'

In section 8.3.3 'The Overall Structure of an RTPS Message' update the final paragraph as follows:
Each message sent by the RTPS protocol has a finite length. This length is not sent explicitly by the RTPS protocol but is part of the underlying transport with which RTPS messages are sent. This length is optionally sent in the RTPS HeaderExtension Submessage.

The length may also be sent by the underlying transport that carries the RTPS message and, in these cases, may be omitted from the HeaderExtension. In For example, in the case of a packet-oriented transport (like UDP/IP), the length of the message is already provided by the transport encapsulation.

A In contrast, a stream-oriented transport (like TCP) would need to insert the length ahead of the message include the length in the RTPS HeaderExtension in order to identify the boundary of the RTPS message.

Add the following subsection following subsection 8.3.5.10 (Count):
8.3.7.1.2 Checksum
Checksum is used in the HeaderExtension Submessage and enables the receiver to detect messages corrupted by the transport.

Table 29 – Structure of the Checksum SubmessageElement

Add the following subsection as the first subsection in section 8.3.7 'RTPS Submessages':
8.3.7.1 HeaderExtension
8.3.7.1.1 Purpose
The HeaderExtension Submessage is used to convey optional information about the RTPS Message. This submessage, if present, shall appear directly after the RTPS Header.

8.3.7.1.2 Content
The elements that form the structure of the HeaderExtension message are described in the table below.
Table 8.XX - Structure of the HeaderExtension Submessage

8.3.7.1.3 Validity
This Submessage is invalid when any of the following is true:

• submessageLength in the Submessage header is too small to fit the fields that are present as indicated by the submessage flags.
• rtpsMessageLength is too small.

8.3.7.1.4 Change in state of Receiver
None.

8.3.7.1.5 Logical Interpretation
The RTPSHeaderExtension may be sent to communicate the length of the RTPS Message. This information may be useful to for managing memory while receiving incoming RTPS Messages.

The rtpsMsgLength contains the entire length of the RTPS Message starting from the beginning of the RTPS Header.

In section 9.4.5.1.1 'SubmessageId', add RTPS_HE to the enum SubmessageKind and update the definition to use new IDL syntax:

enum SubmessageKind {
    @value(0x00)
    RTPS_HE,    /* RTPSHeaderExtension */
    @value(0x01)
    PAD, /* Pad */            
    @value(0x06)
    ACKNACK, /* AckNack */        
    @value(0x07)
    HEARTBEAT, /* Heartbeat */      
    @value(0x08)
    GAP, /* Gap */            
    @value(0x09)
    INFO_TS, /* InfoTimestamp */  
    @value(0x0c)
    INFO_SRC, /* InfoSource */     
    @value(0x0d)
    INFO_REPLY_IP4, /* InfoReplyIp4 */   
    @value(0x0e)
    INFO_DST, /* InfoDestination */
    @value(0x0f)
    INFO_REPLY, /* InfoReply */      
    @value(0x12)
    NACK_FRAG, /* NackFrag */       
    @value(0x13)
    HEARTBEAT_FRAG, /* HeartbeatFrag */  
    @value(0x15)
    DATA, /* Data */           
    @value(0x16)
    DATA_FRAG /* DataFrag */
};

Add the following subsection as the subsection directly following 9.4.5.1 'Submessage Header' in section 9.4.5 'Mapping of the RTPS Submessages':
9.4.5.2 RTPSHeaderExtension Submessage
Sub clause 8.3.7.1 in the PIM defines the logical contents of the RTPSHeaderExtension Submessage. The PSM maps the RTPSHeaderExtension Submessage into the following wire representation:

0...2...........8...............16..............24..............32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    RTPS_HE    |X|X|X|X|X|X|X|E|       octetsToNextHeader      |
+---------------+---------------+---------------+---------------+
|                          ulong rtpsMsgLength                  |
+---------------+---------------+---------------+---------------+

In section 9.3.2, add the following IDL following the IDL for:
typedef long Count_t;

typedef unsigned long Checksum_t;

Defer until we have a specification for the RTPS-TCP PSM

This requirement is mostly driven from the needs of additional transport PSMs (such as the RTPS-TCP) that are currently under development.

It is unclear whether these PSMs will just need this or also other information beyond the port number which can be addressed at the same time as suggested by some of the discussions and proposed resolutions.

Therefore the opinion of the RTF is to defer this issue until an additional RTPS Transport PSM is approved to better understand the requirements.

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.

The DDSI-RTPS Specification v2.1 does not currently specify how interoperable implementations should deal with Group Coherent updates

Define RTPS Mechanisms for Group Ordered Access and Group Coherent Sets

In order to support GROUP access scope as defined by the DDS specification, the RTPS spec has added the following elements:

• New in-line QoS
  • PID_GROUP_SEQ_NUM sent with DATA and (first) DATA_FRAG submessages
  • PID_GROUP_COHERENT_SET in-line QoS sent with DATA and (first) DATA_FRAG submessages
  • PID_WRITER_GROUP_INFO in-line QoS sent with DATA and (first) DATA_FRAG submessages
  • PID_SECURE_WRITER_GROUP_INFO in-line QoS sent with DATA and (first) DATA_FRAG submessages
• New SubmessageElement: GroupDigest
• Extended HB message
  • New G flag (group info)
  • New fields when G flag is set:
    • currentGSN : SequenceNumber
    • firstGSN : SequenceNumber
    • lastGSN : SequenceNumber
    • writerSet : GroupDigest
    • secureWriterSet : GroupDigest
• Extended GAP message
  • New G flag (group info)
  • New fields when G flag is set:
    • gapStartGSN : SequenceNumber
    • gapEndGSN : SequenceNumber
• New fields WriterProxy::remoteGroupEntityId, ReaderProxy::remoteGroupEntityId
  • Uses previously deprecated PID_GROUP_ENTITYID

The DDS interoperability protocol is also referred to as RTPS. OMG staff have received conflicting suggestions for the short name of the protocol (RTPS vs. DDSI). This short name determines (amongst other things) the URL by which the mist recent version of the specification is always accessible.

The RTF must decide what short name to use for this specification.

Yes/No vote to decide whether to keep DDSI-RTPS or change to DDS-RTPS

If we do nothing the name will remain DDSI-RTPS.

The proposed resolution to this issue is to change the acronym to DDS-RTPS. So if the issue is approved the acronym will change. If it is rejected it will stay the same.

Title: Must send GAP when filtering on writer-side regardless of reliability QoS setting
Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
This issue is not currently in a state to be resolved. What follows are various thoughts on the issue and possible solutions to be discussed. This issue will not be resolved in time for the finalization task force and is included here to be documented for the revision task force.
Discussion topic: what are DDS semantics for combining filtering with the deadline QoS?
Should the deadline be triggered when all samples during the deadline period were filtered out?
That is, does deadline require at least one sample to arrive every deadline period seconds that passed the filter?
Or is the deadline satisfied when any sample arrives within the period, whether filtered out or not?

If deadline only applies to samples that pass the filter, RTPS needs no changes, simply use the GAP subMessage to avoid incorrect onDataLost callbacks.
If not, we run into a problem when using keyed DataWriters and finite deadlines. As the deadline applies on a per instance basis, the Reader expects at least one update for every instance, even when none of the updates for a particular instance pass the filter. A GAP message does not indicate for which instance an update was filtered out, so it cannot be used by the Reader to verify the deadline constraint. Instead, we should consider using an empty DATA message instead, possibly with a flag that states the update did not pass any filter. This would also be useful to add a new instance state NOT_ALIVE_FILTERED or so later on to the DDS spec.
Another possibility would be to add a list of KeyHashes to the GAP message. SO that a GAP that is caused by a CFT actually encodes the instances that are being gapped. This would not cause incorrect firings of the DEADLINE and as a result would maintain ownership of instances even if they are filtered out…
There are two ways to do this.
Either we separate GAPs that correspond to filtered samples from those that correspond to irrelevant samples. So in effect we have two kinds of GAP messages
Or we list explicitly the sequence number of each filtered message along with its KeyHash.
Not clear what would be easier implementationwise. The samples that have been filtered are still on the writer so it appears that either implementation would work.
Option (1) would save putting the sequence number with each KeyHash. This can be 4 or 8 bytes per instance, depending on whether we put the sequence number as is, or we encode it as an increment
Option (2) would cause additional GAP submessages to be sent which is an overhead of 28 bytes. Not clear what is less costly…
Also, if we use Option(1), then the messages that represent real GAPs can be sent via multicast; but this is only likely to occur when late joiners appear as normally there would be no "irrelevant" gaps if data is published immediately. Moreover we can in practice still do this and separate the GAP messages that represent real GAPs from the ones that don't. Option 1 does not force us to combine, just provides the means to do so…
Option (2) has the problem that in certain edge cases the overhead is significant. For example if each we have a irrelevant-sample GAP followed by a filtered sample, followed by an irrelevant sample gap, etc. then we end up sending one GAP message per filtered sample with is 28 bytes of overhead per filtered sample versus a single GAP with 4 bytes of overhead per filtered sample. Also the processing is much more efficient as each GAP message is dispatched separately up the receiver's stack.
For this reason it appears that Option 1 is more flexible, and the overhead is more stable. Opt
Proposal(s):
Always send GAPs for filtered-out messages (both in the BestEffort and in the RELIABLE) cases
If the type is Keyed, then the GAP also includes at the end a sequence of :
struct FilteredSampleDesc

;
The GAP message gets two additional flags:
KeyHashFlag
indicates the presence of the KeyHashPrefix
FilteredSamplesFlag
Indicates the presence of the sequence< FilteredSampleDesc>
An issue needs to be filed against the DDS spec to clarify:
(a) Whether the deadline as specified by a DataReader should apply to the samples that pass the DataReader filter or to the samples sent by any writer?
(b) Whether a new instance_state ALIVE_FILTERED should be added such that the DataReader can determine that a sample was filtered and potentially take action on that.
(c) Whether an API or a QoS should be added to the DataReader to allow the DataReader to remove the instance information for instances with state ALIVE_FILTERED after all samples are taken. This allows resources to be conserved in the case where once filtered we expect the instance to remain filtered and also allows a reader to be notified if the instance becomes unfiltered.
(d) Weather to add a filtered_generation_count that the instance has becomed ALIVE after being in the ALIVE_FILTERED

Resolution:
T4 should include code and description that states that when the sample is not relevant, send a GAP…same for the stateful best effort writer.
Revised Text:

Introduce a mechanism to inform a Reader that an instance is filtered

Extend the StatusInfo_t that is sent via inline Qos (PID_STATUS_INFO) such that it can be used to indicate that an instance has been filtered by a reader. This extends the current usage to send DISPOSE and UNREGISTER messages.

Add an issue to the DDS RTF 1.5 to introduce the concept of ALIVE_FILTERED Instance state to complement the existing ones (ALIVE, NOT_ALIVE_DISPOSED, NOT_ALIVE_NO_WRITERS).

Define more precisely when a writer that does writer-side content filter should send the DISPOSE, UNREGISTER, and FILTERED messages.

1. Section: 8.3.6.3, Bullet 2 and Footnote 2
Page: 43
Change: PROTOCOL_RTPS is not defined by PSM

2. Section: 8.3.7.3.2, Table 8.35
Page: 50
Change: KeyFlag is missing from the table

3. Section: 8.3.7.3.2, Table 8.35
Page: 51
Change: Remove the line "Present only if DataFlag is set in the header", as DataFrag has no such flag. Remove the line "Present only if either the DataFlag or the KeyFlag are set in the header", as DataFrag has no DataFlag. In the first bullet point replace "If the DataFlag is set" with "If the KeyFlag is not set".

4. Section: 8.4.1
Page: 63
Change: Section 8.4.13 (Writer Liveliness) is missing from this list.

5. Section: 8.4.7.2
Page: 75
Change: The paragraph above the table should be changed from using Locator_t to ReaderLocator (the table was changed in a previous revision).

6. Section: 8.4.7.2.2, 8.4.7.2.3
Page: 76
Change: Locator_t in these sections should be ReaderLocator

7. Section: 8.4.7.3, Table 8.51
Page: 77
Change: In figure 8.15, type of locator is Locator_t[*] but the [*] is missing from this table (8.51) and the text should reflect the actual cardinality

8. Section: 8.4.9.2
Page: 93
Change: The sentence fragment "Submessages are used..." is nonsensical, it should be removed.

9. Section: 8.5.3.3, Figure 8.29
Page: 129
Change: Remove figure 8.29, it is a duplicate of figure 8.28

10. Section: 9.4.5.3, block diagram
Page: 170
Change: Flag "K" is missing from the flags byte

11. Section: 9.6.2.1
Page: 180
Change: The wire-representation diagram is missing the participantGuidPrefix and kind fields (also see OMG Issue 12501)

12. Section: 9.6.2.2, Table 9.10
Page: 182
Change: remoteWriterGuid belongs to WriterProxy, not ReaderProxy

13. Section: 9.6.2.2, Table 9.10
Page: 182
Change: Table 9.10 caption is incorrect, looks like it was copied from 9.11

14. Section: 9.6.3.2, Table 9.16
Page: 190
Change: KeyHashSuffix does not exist; remove this row from the table. The row for SerializedData should be sufficient to describe the use of PID_COHERENT_SET.

Fix Editorial Issues

There are a number of minor editorial issues that need to fixed. This issue was created to resolve them.

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

Key attributes and Regular attributes of a topic should be individually de-serializable (or at least make the keyhash compulsory)

[Nature] Architectural
[Severity] Major

[Description]
The "DDS Interoperability Wire Protocol v2.1" defines a a serialization format for topic types in which
it is not easy, nor efficient, to simply get access to the key of a given topic. This has to do with how CDR
serializes structs but could be worked around with the new X-Types specification.
In essence the problem is that some applications such as DDS routers (such as the PrismTech BlendBox)
require to perform some operations that while requiring a knowledge of the instance do not require the deserialization
of the data payload.

[Resolution]
For DDS implementation compatible with the X-Types ensure that the regular data attributes and the key attributes are serialized
in different chunks and thus individually accessible in an efficient manner – meaning to access the key I would prefer not to scan all
the regular attributes.

For non X-Types compatible DDS implementations make the KeyHash compulsory, meaning require DDS compliant implementation to
always send a key-hash along with a Data submessage.

No immediate need to add individual serialization of keys and regular attributes

The RTF does not see an immediate need to add the proposed functionality to the specification.

In section 8.7.9 of the DDSI/RTPS v2.1 protocol is described the KeyHash sub-message-element representing the MD5 hash of the key for the Data sub-message to which it belongs.

The specification does not mandate the use of the KeyHash all keyed topics – implementations are free to include it or not. However, if implementations are not including the KeyHash the only way to get a clue on the Topic Instance to which the received samples belongs is to de-serialize the payload.

This leads two at least two problems, (1) DDSI/RTPS routers are forced to de-serialize the data payload even if no content transformation have to be performed and (2) DDS Implementations are forced to deserialize eagerly in order to manage instances, thus preventing DDS implementations to do lazy deserialization (which is now possible with the API provided by the new C++/Java PSM).

The suggested resolution is to require that Data SubMessage for keyed topic shall always include the KeyHash submessage element.

No immediate need to require sending the Keyhash with each sample

The RTF does not see an immediate need to add the proposed functionality to the specification.

Page: 92
Change: Figure 8.18 notes that transition T4 can send a GAP, but this section doesn't describe when/how to send a GAP.

Add descriptions of when Best Effort Writers Send GAP messages

The Best-Effort Stateless and Stateful Writer Behaviors should include logic for when a GAP message is sent, similar to the logic already present for their Reliable counterparts.

Page: 77
Change: Unlike other tables of operations in this section, none of these operations are described in the text of the section

Add missing descriptions of the ReaderLocator operations in Table 8.52

Add missing descriptions of the ReaderLocator operations in Table 8.52, in a similar manner to the other kinds of operations that are defined in this section.

Encapsulation has a precise technical meaning from the CORBA spec (formal/11-11-02 section 9.3.3) and a similar meaning from chapter 10 of RTPS, neither of which matches most of the other uses of “encapsulation” throughout the RTPS spec. In general, encapsulation means adding specific prefix bytes to the on-the-wire representation of data. This prefix can be used by the receiver to understand the format of the following bytes. The majority of uses of “encapsulation” in the specification do not agree with this meaning. This issue seeks to fix that by using the simpler term of “encoding” in place of “encapsulation.”

Encapsulate
-----------------

Section: 8.3.2, Table 8.13, Count_t row
Page: 30
Change: replace “'encapsulate'” with “'hold”'

Section: 8.3.3.2, Table 8.15, flags row
Page: 34
Change: replace '“encapsulate”' with “'encode”' in two places

Section: 8.3.5.1
Page: 37
Change: replace “'encapsulate'” with '“contain'”

Section: 8.3.5.9, Paragraph 1
Page: 41
Change: replace “encapsulate” with “'contain'”

Section: 8.3.7.9.2, Table 8.41, protocolVersion and VendorId rows
Page: 59
Change: replace “'to encapsulate subsequent Submessages'” with “"for subsequent Submessages”"
Change 'vendor that encapsulated subsequent submessages' with “'vendor that originated the subsequent submessages' ”

Section: 8.4.10.3
Page: 105
Change: replace “'encapsulated”' with “'maintained”'

Section: 8.4.11.1.2
Page: 110
Change: replace 'the DATA message encapsulates' with 'the DATA message contains'

Section: 8.4.12.1.2
Page: 112
Change: replace 'the DATA message encapsulates' with 'the DATA message contains'

Section: 8.5.3.2, Table 8.73, expectesInlineQos row
Page: 126
Change: replace '“encapsulated”' with '“included'”

Section 9.4.2.12
Page: 166
Change: replace 'process used to encapsulate' with 'process used to encode'

Section: 9.6.2.2, Paragraphs 4-5
Page: 181
Change: replace “'encapsulates'” with “'contains'”; replace “'encapsulated'” with “'represented'” (twice)

Section: 9.6.2.2.2
Page: 182
Change: replace “'used to encapsulate the data'” with '“used for the data'”

Section: 9.6.3
Page: 187
Change: replace “'are encapsulated'” with “'are contained'”

Section: 9.6.3.3
Page: 190
Change: replace “'any unfilled bits in the KeyHash_t after all the key fields have been encapsulated shall be set to zero' with 'any unfilled bits in the KeyHash_t shall be set to zero”'

Page: 191
Change: replace “'encapsulated as' with 'represented as'

Section: 10
This is handled on a separate issue.

Encapsulation
-------------------

Section 6.2 change 'data encapsulation' to 'data representation' (twice)

Section 8.3.3 change 'transport encapsulation' to 'transport headers'

Section 8.3.5.9 change 'The encapsulation' to 'the representation'

Section 8.3.5.12 change 'For additional information on data encapsulation see ...' to 'For additional information see ...'
Section 8.3.5.13 change 'For additional information on data encapsulation see ...' to 'For additional information see ...'

Table 8.34 change 'contains the encapsulation of the ...' to 'contains the ...' (twice in serializedPayload row).

Table 8.35 serializedPayload row:
Change 'Encapsulation of a consecutive ...' with ' A consecutive ...'
Change 'contains the encapsulation of the ...' to 'contains the ...' (twice in serializedPayload row).

Section 8.4.11.1.1 and 8.4.11.1.2
Change 'The encapsulation is described' to 'The representation is described' (once on each section)

Section: 9.4.2.11, Paragraphs 5, 7, 9
Page: 165
Change: “'CDR encapsulation”' with 'CDR representation' and 'ParameterList encapsulation' with 'ParameterList representation'

Change 'These are two predefined values of the parameterId used for the encapsulation' with 'These are two predefined values of the parameterId:'

Section 9.5 Change title to "Mapping to UDP/IP Transport Messages"
Change body to:
When RTPS is used over UDP/IP, each UDP/IP datagram shall contain exactly one or more complete RTPS Messages.

Note: This is a change. Currently the requirement is one datagram one RTPS message.

Section: 9.6.3.3
Page: 190-191
Change: replace “'“encapsulation'” with '“representation'” (seven times)

Replace all uses of any form of 'Encapsulate'

Encapsulation has a precise technical meaning from the CORBA spec (formal/11-11-02 section 9.3.3) and a similar meaning from chapter 10 of RTPS, neither of which matches most of the other uses of “encapsulation” throughout the RTPS spec. We are therefore replacing all uses of any form of the word 'encapsulate' with a different word.
Three general rules of thumb were followed:

1. In cases describing the contents of SubmessageElements or messages, we have replaced encapsulate with 'contain'.
2. Anywhere that said 'data encapsulation' or 'CDR encapsulation' is replaced with 'data representation'.
3. We have removed the phrase containing encapsulation all together in places where it was used unnecessarily.

All other situations were dealt with on a case-by-case basis

This distinction is important for DDS, but not relevant for RTPS. There are places where RTPS deals with the Key as an independent unit of data (KeyFlag, etc.), but those are not relevant to the TopicKind_t which seems to be an artifact of an older version of the specification. The current protocol as written in this specification works the same way for both With Key and No Key topics. This issue seeks to remove the Topic Kind concept entirely from the specification.
1. Section: 8.2.1.2, Table 8.2
Page: 14
Change: remove the table row for TopicKind_t
2. Section: 8.2.1.3, Figure 8.2
Page: 16
Change: remove the topicKind attribute in Endpoint
3. Section: 8.2.5, Figure 8.5
Page: 21
Change: remove the topicKind attribute in Endpoint
4. Section: 8.2.6, Table 8.9
Page: 23
Change: remove the table row for TopicKind_t
5. Section: 8.2.9.1, Figure 8.6
Page: 25
Change: remove the if() statements for W::topicKind
6. Section: 8.2.9.1.3-4
Page: 26-27
Change: remove the if() statements for the_rtps_writer.topicKind and the paragraphs “This operation has no effect if the topicKind==NO_KEY).”
7. Section: 8.3.3, Figure 8.8
Page: 31
Change: remove NoKeyData and NoKeyDataFrag
8. Section: 8.3.7, Bullets 1-2,4
Page: 43
Change: remove the text “(NO_KEY Reader/Writer or WITH_KEY Reader/Writer)”
9. Section: 8.3.7.2
Page: 47
Change: remove the text “(NO_KEY or WITH_KEY)”
10. Section: 8.3.7.3
Page: 49
Change: remove the text “(NO_KEY or WITH_KEY)”
11. Section: 8.3.7.2, 3rd Bullet
Page: 63
Change: remove the text referring to “keyed topics”
12. Section: 8.4.4
Page: 69-70
Change: remove all references to topicKind, WITH_KEY, NO_KEY, etc.
13. Section: 8.4.7.1, Figure 8.15
Page: 72
Change: remove the topicKind attribute in Endpoint
14. Section: 8.4.8.1
Page: 83
Change: remove “WITH_KEY”
15. Section: 8.4.8.1, Figure 8.16
Page: 84
Change: remove “WITH_KEY”

16. Section: 8.4.8.2
Page: 85
Change: remove “WITH_KEY” and “NO_KEY”
17. Section: 8.4.8.2, Figure 8.17
Page: 86
Change: remove “WITH_KEY”
18. Section: 8.4.9.1
Page: 90
Change: remove “WITH_KEY” and “NO_KEY”
19. Section: 8.4.9.1, Figure 8.18
Page: 90
Change: remove “WITH_KEY”
20. Section: 8.4.9.2
Page: 93
Change: remove “WITH_KEY” and “NO_KEY”
21. Section: 8.4.9.2, Figure 8.19
Page: 94
Change: remove “WITH_KEY”

22. Section: 8.4.10.1, Figure 8.21
Page: 102
Change: remove the topicKind attribute in Endpoint

23. Section: 8.4.11.1
Page: 109
Change: remove “WITH_KEY” and “NO_KEY”
24. Section: 8.4.11.1, Figure 8.22
Page: 110
Change: remove “WITH_KEY”

25. Section: 8.4.12.1
Page: 111
Change: remove “WITH_KEY” and “NO_KEY”
26. Section: 8.4.12.1, Figure 8.23
Page: 111
Change: remove “WITH_KEY”

27. Section: 8.4.12.2
Page: 113
Change: remove “WITH_KEY” and “NO_KEY”

28. Section: 8.4.12.3, Figure 8.25
Page: 117
Change: remove “NOKEYDATA” alternative

29. Section: 8.5.3.3, Tables 8.74 and 8.75
Page: 129
Change: remove topicKind rows from both tables

30. Section: 9.3.2, Table 9.4
Page: 155
Change: remove the “TopicKind_t” row

Limit the use of TopicKind to the places where it matters

The protocol works the same whether or not a Topic is keyed; the distinction was therefore unnecessary in many places and was removed.

Section 9.6.3.3 KeyHash (PID_KEY_HASH) says that the KeyHash is either computed as the CDR Big-Endian encapsulation of all the Key fields in sequence, or else as the MD5 of that "CDR Big-Endian encapsulation of all the Key fields in sequence" the decision is based on whether the "CDR Big-Endian encapsulation of all the Key fields in sequence" for that data-type is known to always fit into the 16-byte KeyHash.

However the text in the first bullet says "If the maximum size of the sequential CDR encapsulation of all the key fields is guaranteed to be less than 128 bits, then the KeyHash shall be computed...

This is misleading as it leave indeterminate the case when the "the maximum size of the sequential CDR encapsulation of all the key fields" is exactly 128 bits. In this case if the sentence is interpreted to mean "strictly less than 128" then an MD5 should be used. If it is interpreted to mean "less or equal" then no MD5 should be applied.

Unfortunately this situation occurs on the builtin-topic types because the GUIDs are exactly 16 bytes.

Proposed Resolution:
In Section 9.6.3.3 KeyHash (PID_KEY_HASH). In the first bullet, replace:
"If the maximum size of the sequential CDR encapsulation of all the key fields is guaranteed to be less than 128 bits,"

With
"If the maximum size of the sequential CDR encapsulation of all the key fields is guaranteed to be less or equal than 128 bits,"

Clarify the KeyHash computation in the case of a CDR encapsulation of exactly 128 bits

The language describing when to use an MD5 to compute the KeyHash has been clarified to reflect that no MD5 should be used is the serialized length of the key fields is less that or equal to 128 bits, as opposed to strictly less than.

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.

Page: 120
Change: Fragment size should be allowed to be equal to (instead of strictly greater than) 1KB, also define KB as 1024 bytes to avoid the KB/KiB issue (1000 vs. 1024).

Remove the lower bound for fragment sizes

We see no need to specify the lower bound for fragment sizes so we will remove that requirement.

Page: 85
Change: Figure 8.16 notes that transition T4 can send a GAP, but this section doesn't describe when/how to send a GAP.

This issue is resolved as part of DDSIRTP23-20

This issue is resolved as part of DDSIRTP23-20

Please excuse my learning curve here.

Section 6.1 says that this formal is a supplement to Version 1.1 formal, However there is now a version 1.2. That MIGHT suggest that aspects of 1.2 is not within interoperability to this specification. and that this one is interoperable to 1.1. Which I understand is across major versions and not a mandate.

Anyway Please clareify.
Is there a document that has version differences overview. If so a reference to that would be value added as well.

Update references to the DDS Spec with the current 1.4 version

Replace references to DDS version 1.2 with the most current version, 1.4

The DDSI v2.1 specification describes in section 8.4.13 the Writer Liveliness Protocol as the mechanism used by participants to assess the liveliness of their contained data writers (with automatic liveliness).

The Writer Liveliness Protocol is specified as mandatory for compliant implementations.

The first remark is that the Writer Liveliness Protocol is not required at all for interoperability, thus it should not be a mandatory requirement for compliant implementation. This is not only easy to reason about, but wireshark captures made during the DDS interoperability demo of the past March 2012 showed how different DDS implementations could work w/o using this protocol.

Beyond that, the protocol is simply superfluous as DataWriter liveliness can be anyway asserted via the Participant Liveliness, this in turns is asserted by the participant discovery protocol.

Beyond the potential waste of resource required by yet another periodic information flow, what seems very odd is the choices of QoS for the built-in entities that write this periodic message. As described in section 8.4.13.3 these built-int entities communicate reliably and have a history set to KeepLast(1), along with TransientLocal durability.

This QoS settings only "works" best for those implementations that tie the reliability send queue to the writer history but is less than ideal for those that rightfully decouple history and reliability.

Anyway, however one looks at it this part of the specs seems bogus. In addition as mentioned above is not required for interoperability and generates yet another stream of periodic messages.

The recommendation is to remove this section from the next version of the standard.

No Need to remove the Writer Liveliness Protocol

The RTF does not see a need to remove the Writer Liveliness Protocol from the specification.

Page: 184-187
Change: The following RTPS fields lack a mapping: ParticipantProxy::guidPrefix, ReaderProxy::remoteReaderGuid, WriterProxy::remoteWriterGuid. Table 9.10 indicates that they are optional, but they are not possible to encode without a mapping. Also, DiscoveredReaderData::contentFilterProperty (AKA DiscoveredReaderData::contentFilter in the PIM: these should be consistent) is lacking a mapping

Cleanup up missing and unused ParameterId mappings

Add a missing PID_ENDPOINT_GUID and map SubscriptionBuiltinTopicData::key and PublicationBuiltinTopicData::key to it.

Add missing mapping of DiscoveredReaderData::contentFilterProperty, TopicBuiltinTopicData::topic_data, SubscriptionBuiltinTopicData::durability, PublicationBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::presentation

Remove the mapping of SubscriptionBuiltinTopicData::lifespan, which is not present in DDS

Page: 185
Change: The following DDS fields lack a mapping: TopicBuiltinTopicData::topic_data, SubscriptionBuiltinTopicData::durability, PublicationBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::presentation, and the "key" field in Publication, Subscription, and Topic. Also, the mapped DDS field SubscriptionBuiltinTopicData::lifespan does not exist in DDS

Duplicates DDSIRTP23-8

The resolution of DDSIRTP23-8 covers the resolutions of the missing/unnecessary mappings described in DDSIRTP23-9

Page: 184
Change: Duration_t (used for PID_PARTICIPANT_LEASE_DURATION) is not defined in the PSM. Use Time_t instead?

Define a PSM Mapping for Duration_t

A PSM mapping of Duration_t has been defined in Table 9.4, specifying that the representation on the wire should be NTP.

Page: 183-184
Change: IPv4Address_t and Port_t are not defined anywhere in the specification

*Deprecate PIDs *

There are a number of PIDs for address and port fields that are no longer necessary or used since the information that they identify is sent in the form of a Locator, we are therefore deprecating these PIDs:
PID_MULTICAST_IPADDRESS
PID_DEFAULT_UNICAST_IPADDRESS
PID_DEFAULT_UNICAST_PORT
PID_METATRAFFIC_UNICAST_IPADDRESS
PID_METATRAFFIC_UNICAST_PORT
PID_METATRAFFIC_MULTICAST_IPADDRESS
PID_METATRAFFIC_MULTICAST_PORT

PID_PARTICIPANT_BUILTIN_ENDPOINTS is also not used and will be deprecated. Implementations are using PID_BUILTIN_ENDPOINT_SET instead.

Page: 182
Change: This section refers to a non-existent "key parameter" in the Data submessage.