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.