1. OMG Mailing List
  2. DDSI-RTPS version 2.3 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: ddsi-rtps-rtf
  • Issues Count: 38

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSIRTP23-41 Link to RTPS VendorId web page is broken DDSI-RTPS 2.2 open
DDSIRTP23-40 Builtin Interparticipant Channel should have DataReader reliability kind BEST_EFFORTS DDSI-RTPS 2.2 open
DDSIRTP23-39 RTPS Minor version should take into consideration DDS-Security DDSI-RTPS 2.2 open
DDSIRTP23-38 Reference reserved ParameterIDs for DDS-Security and dependencies DDSI-RTPS 2.2 open
DDSIRTP23-37 Incorrect definition of SequenceNumberSet DDSI-RTPS 2.2 open
DDSIRTP23-36 Semantics of AckNack's Final Flag DDSI-RTPS 2.2 open
DDSIRTP23-3 Clarify start of alignment for SerializedPayload DDSI-RTPS 2.2 open
DDSIRTP23-20 Section 8.4.9.1.4: Best-Effort Stateful Writer GAP semantics DDSI-RTPS 2.0b1 open
DDSIRTP23-21 Section 8.4.8.1.4: When does Best-Effort Stateless Writer send a GAP DDSI-RTPS 2.0b1 open
DDSIRTP23-19 Section 8.4.14.1.1, Bullet 3: Put precise bounds on the fragment size DDSI-RTPS 2.0b1 open
DDSIRTP23-15 Section 9.6.2.2: What is the "key" parameter? DDSI-RTPS 2.0b1 open
DDSIRTP23-14 Section 9.6.2.2: Duration_t used in IDL, not defined DDSI-RTPS 2.0b1 open
DDSIRTP23-10 Section: 9.6.2.2.2, Table 9.12: Duration_t not defined by PSM DDSI-RTPS 2.0b1 open
DDSIRTP23-11 Section 9.6.2.2.2, Table 9.12: Specify IPv4Address_t and Port_t DDSI-RTPS 2.0b1 open
DDSIRTP23-18 Section 8.4.15.7: Scope of the count fields of Heartbeat and AckNack/NackFrag DDSI-RTPS 2.0b1 open
DDSIRTP23-13 Section 8.5.3.2, Table 8.73: Make defaultUnicastLocatorList optional DDSI-RTPS 2.0b1 open
DDSIRTP23-12 Section 9.6.2.2: Descirbe key-only encoding of built-in data types DDSI-RTPS 2.0b1 open
DDSIRTP23-16 Section 8.7.6: RTPS support for semantics not present in DDS DDSI-RTPS 2.0b1 open
DDSIRTP23-5 Referencing current version of DDS spec (was: Clarification of link comment) DDSI-RTPS 2.1 open
DDSIRTP23-9 Section: 9.6.2.2.2, Table 9.13: Missing ParameterId mappings for DDS fields DDSI-RTPS 2.0b1 open
DDSIRTP23-8 Section: 9.6.2.2.2, Table 9.13: Missing ParameterId mappings for RTPS fields DDSI-RTPS 2.0b1 open
DDSIRTP23-22 Section 8.4.7.3, Table 8.52: Describe ReaderLocator operations' semantics DDSI-RTPS 2.0b1 open
DDSIRTP23-30 RTF needs to agree any change of name and/or URL for specification DDSI-RTPS 2.1 open
DDSIRTP23-28 DDSI/RTPS Key MD5 Hash DDSI-RTPS 2.0b1 open
DDSIRTP23-24 Key attributes and Regular attributes of a topic should be individually de-serializable DDSI-RTPS 2.0b1 open
DDSIRTP2-60 missing space "eachother" DDSI-RTPS 2.0b1 open
DDSIRTP23-23 Editing issues DDSI-RTPS 2.0b1 open
DDSIRTP23-25 Use the term "Encapsulation" consistently and precisely DDSI-RTPS 2.0b1 open
DDSIRTP23-27 Remove the concept of Topic Kinds (With Key vs. No Key) DDSI-RTPS 2.0b1 open
DDSIRTP23-29 How should interoperable implementations deal with Group Coherent updates DDSI-RTPS 2.0b1 open
DDSIRTP23-26 How should interoperable implementations deal with Transient / Persistent data." DDSI-RTPS 2.0b1 open
DDSIRTP23-31 Must send GAP when filtering on writer-side DDSI-RTPS 2.0b1 open
DDSIRTP23-32 Incorrect/misleading description of KeyHash computation DDSI-RTPS 2.0b1 open
DDSIRTP23-4 Some constants specified in PSM table 9.4 conflict with the ones used in wireshark DDSI-RTPS 2.0b1 open
DDSIRTP23-6 Message Size should be included as part of DDSI/RTPS Messages DDSI-RTPS 2.1 open
DDSIRTP23-7 The Writer Liveliness Protocol should be removed DDSI-RTPS 2.1 open
DDSIRTP23-17 Section: 8.5.3.2, Figure 8.27 and Table 8.73 DDSI-RTPS 2.0b1 open
DDSIRTP23-2 Locator_t kind needs a reserved range and a range for vendor extensions DDSI-RTPS 2.2 open

Issues Descriptions


Builtin Interparticipant Channel should have DataReader reliability kind BEST_EFFORTS

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.2 — Mon, 21 Aug 2017 22:09 GMT
  • Updated: Mon, 21 Aug 2017 22:09 GMT

RTPS Minor version should take into consideration DDS-Security

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.2 — Sat, 8 Jul 2017 00:15 GMT
  • Updated: Sat, 8 Jul 2017 00:15 GMT

Reference reserved ParameterIDs for DDS-Security and dependencies

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.2 — Sat, 8 Jul 2017 00:12 GMT
  • Updated: Sat, 8 Jul 2017 00:12 GMT

Incorrect definition of SequenceNumberSet

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.2 — Wed, 30 Mar 2016 20:21 GMT
  • Updated: Wed, 30 Mar 2016 20:21 GMT

Semantics of AckNack's Final Flag

  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    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?

    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.

    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.

  • Reported: DDSI-RTPS 2.2 — Wed, 27 Jan 2016 16:06 GMT
  • Updated: Wed, 27 Jan 2016 16:06 GMT

Clarify start of alignment for SerializedPayload

  • Legacy Issue Number: 19660
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    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 improve to make it less ambiguous, specifically stating that the reset of the alignment occurs after the parameterID before the parameter data is serialized.

  • Reported: DDSI-RTPS 2.2 — Mon, 24 Nov 2014 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:55 GMT

Section 8.4.9.1.4: Best-Effort Stateful Writer GAP semantics

  • Legacy Issue Number: 16965
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:48 GMT

Section 8.4.8.1.4: When does Best-Effort Stateless Writer send a GAP

  • Legacy Issue Number: 16964
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:47 GMT

Section 8.4.14.1.1, Bullet 3: Put precise bounds on the fragment size

  • Legacy Issue Number: 16966
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    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).

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:46 GMT

Section 9.6.2.2: What is the "key" parameter?

  • Legacy Issue Number: 16980
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

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

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:45 GMT

Section 9.6.2.2: Duration_t used in IDL, not defined

  • Legacy Issue Number: 16978
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

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

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:44 GMT

Section: 9.6.2.2.2, Table 9.12: Duration_t not defined by PSM

  • Legacy Issue Number: 16982
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

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

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:44 GMT

Section 9.6.2.2.2, Table 9.12: Specify IPv4Address_t and Port_t

  • Legacy Issue Number: 16981
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

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

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:42 GMT

Section 8.4.15.7: Scope of the count fields of Heartbeat and AckNack/NackFrag

  • Legacy Issue Number: 16967
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 123
    Change: Scope of counts is underspecified: is a Heartbeat count scoped to one Writer; is an AckNack/NackFrag count scoped to a Reader itself or to a Reader's conversation with a given Writer?

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:39 GMT

Section 8.5.3.2, Table 8.73: Make defaultUnicastLocatorList optional

  • Legacy Issue Number: 16969
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 127
    Change: In the row for defaultUnicastLocatorList, "at least one Locator must be present" constrains implementations unnecessarily. As long as each Endpoint has a locator, there is no need for the participant to have a default locator

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:38 GMT

Section 9.6.2.2: Descirbe key-only encoding of built-in data types

  • Legacy Issue Number: 16979
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 181
    Change: This section under-specifies the key fields for all four data types. The "inherited" DDS structures do not provide a key field that is useful for RTPS because it is vendor-specific. This section should describe what a "key only" (KeyFlag==1) Data Submessage should contain as its payload for both SPDP and for all 3 types of SEDP. Table 9.13 indicates that Built-In Topic Keys can be encoded as a GUID, which has no correspondence to the actual definition of Built-In Topic Keys.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:37 GMT

Section 8.7.6: RTPS support for semantics not present in DDS

  • Legacy Issue Number: 16970
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 147
    Change: There is no such "directed" or "peer-to-peer" function described by the DDS spec, therefore none is available to the user. If such a function should be used by RTPS to implement DDS communication, its use by RTPS must be described here. Otherwise remove this section.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:25 GMT

Referencing current version of DDS spec (was: Clarification of link comment)

  • Legacy Issue Number: 19237
  • Status: open  
  • Source: gmail.com ( James Pope)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.1 — Tue, 11 Feb 2014 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:24 GMT

Section: 9.6.2.2.2, Table 9.13: Missing ParameterId mappings for DDS fields

  • Legacy Issue Number: 16983
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    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

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:19 GMT

Section: 9.6.2.2.2, Table 9.13: Missing ParameterId mappings for RTPS fields

  • Legacy Issue Number: 16984
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    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

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:19 GMT

Section 8.4.7.3, Table 8.52: Describe ReaderLocator operations' semantics

  • Legacy Issue Number: 16963
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

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

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:16 GMT

RTF needs to agree any change of name and/or URL for specification

  • Legacy Issue Number: 15885
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.1 — Thu, 9 Dec 2010 05:00 GMT
  • Updated: Wed, 27 Jan 2016 15:13 GMT

DDSI/RTPS Key MD5 Hash

  • Legacy Issue Number: 15912
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 5 Jan 2011 05:00 GMT
  • Updated: Tue, 22 Sep 2015 17:43 GMT

Key attributes and Regular attributes of a topic should be individually de-serializable

  • Legacy Issue Number: 16558
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.0b1 — Mon, 19 Sep 2011 04:00 GMT
  • Updated: Tue, 22 Sep 2015 17:43 GMT

missing space "eachother"

  • Legacy Issue Number: 19818
  • Status: open  
  • Source: Anonymous
  • Summary:

    There is a missing space in paragraph 5 of "eachother" should be "each other"

  • Reported: DDSI-RTPS 2.0b1 — Wed, 22 Jul 2015 04:00 GMT
  • Updated: Wed, 22 Jul 2015 16:01 GMT

Editing issues

  • Legacy Issue Number: 16957
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    The following collection of proposed changes represents fixes to problems in the editing of the specification.
    Section: 3
    Page: 1
    Change: DDS 1.1 is obsolete; CORBA should be referenced for IDL/CDR; IETF RFCs 1321 and 1305 should be referenced
    Section: 8.2.4.2, Paragraph 2
    Page: 21
    Change: First two octets of prefix are fixed due to issue 12509
    Section: 8.3.6.3, Bullet 2 and Footnote 2
    Page: 43
    Change: PROTOCOL_RTPS is not defined by PSM
    Section: 8.3.7.3.2, Table 8.35
    Page: 50
    Change: KeyFlag is missing from the table
    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".
    Section: 8.4.1
    Page: 63
    Change: Section 8.4.13 (Writer Liveliness) is missing from this list.
    Section: 8.4.7.1, Figure 8.15
    Page: 72
    Change: resendDataPeriod is unused, it should be removed
    Section: 8.4.7.2, Table 8.49
    Page: 75
    Change: resendDataPeriod is unused, it should be removed
    Section: 8.4.7.2, Table 8.50
    Page: 76
    Change: Locator_t in this table should be ReaderLocator
    Section: 8.4.7.2.1
    Page: 76
    Change: resendDataPeriod is unused, it should be removed
    Section: 8.4.7.2.2, 8.4.7.2.3
    Page: 76
    Change: Locator_t in these sections should be ReaderLocator
    Section: 8.4.7.3
    Page: 77
    Change: In figure 8.15, type of locator is Locator_t[*] but the [*] is missing from this table and the text should reflect the true cardinality.
    Section: 8.4.9.2
    Page: 93
    Change: The sentence fragment "Submessages are used…" is nonsensical, it should be removed.
    Section: 8.5.3.2, Table 8.73
    Page: 127
    Change: The six constants for BuiltInEndpoints (each constant describes an endpoint, not an endpoint set) are all missing from the PSM
    Section: 8.5.3.3, Figure 8.29
    Page: 128
    Change: Remove figure 8.29, it is a duplicate of figure 8.28
    Section: 9.3.1.5
    Page: 153
    Change: OMG Issue 12509 was resolved but the changed text is missing here
    Section: 9.3.2, Table 9.4
    Page: 153
    Change: OMG Issue 12507 was resolved but the assigned Vendor IDs are not listed. If they should not be listed in the spec, a URL to the appropriate omg.org web site should be listed here.
    Section: 9.3.2, Table 9.4
    Page: 156
    Change: ReliabilityKind_t is not used on the wire, it should be a PIM-only concept and removed from the PSM
    Section: 9.3.2, Table 9.4
    Page: 157
    Change: Property_t and EntityName_t are not used by the protocol, they should be removed
    Section: 9.3.2, Table 9.4
    Page: 158
    Change: Three problems with the constants for BuiltinEndpoints: 1. the constants don't match the table in the PSM, so the reader of the spec must guess to determine how they are used. 2. constants corresponding to propagation of Topic discovery data are missing. 3. constants for 'participant proxy' and 'participant state' need further explanation (or removal from the spec)
    Section: 9.4.5.3, block diagram
    Page: 170
    Change: Flag "K" is missing from the flags byte
    Section: 9.6.2.1
    Page: 180
    Change: The wire-representation diagram is missing the participantGuidPrefix and kind fields (also see OMG Issue 12501)
    Section: 9.6.2.2, Table 9.10
    Page: 181
    Change: remoteWriterGuid belongs to WriterProxy, not ReaderProxy
    Section: 9.6.2.2, Table 9.10
    Page: 181
    Change: Table 9.10 caption is incorrect
    Section: 9.6.2.2.2, Table 9.12
    Page: 184
    Change: 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.
    Section: 9.6.2.2.2, Table 9.13
    Page: 187
    Change: 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.
    Section: 9.6.3, Table 9.14
    Page: 188
    Change: PID_DIRECTED_WRITE and PID_ORIGINAL_WRITER_INFO are not described in the subsequent subsections.
    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.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT

Use the term "Encapsulation" consistently and precisely

  • Legacy Issue Number: 16955
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    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.”
    Section: 8.3.2, Table 8.13, Count_t row
    Page: 30
    Change: replace “encapsulate” with “encode”

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

    Section: 8.3.5.1
    Page: 37
    Change: replace “encapsulate” with “encode”

    Section: 8.3.5.9, Paragraph 1
    Page: 41
    Change: replace “encapsulate” with “encode”; replace “encapsulation” with “encoding”

    Section: 8.3.7.9.2, Table 8.41, protocolVersion and VendorId rows
    Page: 59
    Change: replace “encapsulate” with “encode”; replace “encapsulated” with “encoded”

    Section: 8.4.10.3
    Page: 105
    Change: replace “encapsulated” with “represented” (this use has nothing to do with encoding)

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

    Section: 9.4.2.11, Paragraphs 5, 7, 9
    Page: 165
    Change: replace “encapsulation” with “encoding”. Note that ParameterList itself is not an encapsulation. When it is used as the data payload for Discovery, it is the encapsulated data. When it is used as inlineQos it is not encapsulated. Each data value in the ParameterList is certainly not a CDR encapsulation.
    Section: 9.6.2.2, Paragraphs 4-5
    Page: 181
    Change: replace “encapsulates” with “encodes”; replace “encapsulated” with “encoded” (twice)

    Section: 9.6.2.2.2
    Page: 182
    Change: replace “encapsulate” with “encode”

    Section: 9.6.3
    Page: 187
    Change: replace “encapsulated” with “encoded”

    Section: 8.6.3.3
    Page: 190-191
    Change: replace “encapsulated” with “encoded” (twice); replace “encapsulation” with “encoding” (six times)
    Section: 10
    Page: 193
    Change: The introduction to section 10 (before the 10.1 header) should be removed. It adds no useful information and only confuses things with ambiguous use of the "encapsulate" term and the concept of a "type-plugin" which is nowhere to be found in the DDS specification. Since there is no 10.2, the contents of 10.1 can become 10. Regarding just the first sentence, data encapsulation must be part of RTPS or it would not be here, and different DDS implementations would not be able to interoperate.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT

Remove the concept of Topic Kinds (With Key vs. No Key)

  • Legacy Issue Number: 16954
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    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.
    Section: 8.2.1.2, Table 8.2
    Page: 14
    Change: remove the table row for TopicKind_t
    Section: 8.2.1.3, Figure 8.2
    Page: 16
    Change: remove the topicKind attribute in Endpoint
    Section: 8.2.5, Figure 8.5
    Page: 21
    Change: remove the topicKind attribute in Endpoint
    Section: 8.2.6, Table 8.9
    Page: 23
    Change: remove the table row for TopicKind_t
    Section: 8.2.9.1, Figure 8.6
    Page: 25
    Change: remove the if() statements for W::topicKind
    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).”
    Section: 8.3.3, Figure 8.8
    Page: 31
    Change: remove NoKeyData and NoKeyDataFrag
    Section: 8.3.7, Bullets 1-2,4
    Page: 43
    Change: remove the text “(NO_KEY Reader/Writer or WITH_KEY Reader/Writer)”
    Section: 8.3.7.2
    Page: 47
    Change: remove the text “(NO_KEY or WITH_KEY)”
    Section: 8.3.7.3
    Page: 49
    Change: remove the text “(NO_KEY or WITH_KEY)”
    Section: 8.3.7.2, 3rd Bullet
    Page: 63
    Change: remove the text referring to “keyed topics”
    Section: 8.4.4
    Page: 69-70
    Change: remove all references to topicKind, WITH_KEY, NO_KEY, etc.
    Section: 8.4.7.1, Figure 8.15
    Page: 72
    Change: remove the topicKind attribute in Endpoint
    Section: 8.4.8.1
    Page: 83
    Change: remove “WITH_KEY”
    Section: 8.4.8.1, Figure 8.16
    Page: 84
    Change: remove “WITH_KEY”

    Section: 8.4.8.2
    Page: 85
    Change: remove “WITH_KEY” and “NO_KEY”
    Section: 8.4.8.2, Figure 8.17
    Page: 86
    Change: remove “WITH_KEY”
    Section: 8.4.9.1
    Page: 90
    Change: remove “WITH_KEY” and “NO_KEY”
    Section: 8.4.9.1, Figure 8.18
    Page: 90
    Change: remove “WITH_KEY”
    Section: 8.4.9.2
    Page: 93
    Change: remove “WITH_KEY” and “NO_KEY”
    Section: 8.4.9.2, Figure 8.19
    Page: 94
    Change: remove “WITH_KEY”

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

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

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

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

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

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

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

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT

How should interoperable implementations deal with Group Coherent updates

  • Legacy Issue Number: 16100
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

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

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 Mar 2011 04:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT

How should interoperable implementations deal with Transient / Persistent data."

  • Legacy Issue Number: 16099
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

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

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 Mar 2011 04:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT

Must send GAP when filtering on writer-side

  • Legacy Issue Number: 11035
  • Status: open  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    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

    { long gapStartOffset; KeyHashPrefix keyHashPrefix; KeyHashSuffic keyHashSuffix; }

    ;
    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:

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT

Incorrect/misleading description of KeyHash computation

  • Legacy Issue Number: 19730
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    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,"

  • Reported: DDSI-RTPS 2.0b1 — Mon, 2 Mar 2015 05:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT

Some constants specified in PSM table 9.4 conflict with the ones used in wireshark

  • Legacy Issue Number: 19508
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In table 9.4 the the PSM RTPS define ReliabilityKind_t defines  RELIABLE as having the value 3. However the Wireshark packet dissector defines ReliabilityKind_t RELIABLE as having the value 2.

    In table 9.4 the PSM RTPS specification defines LOCATOR_KIND_UDPv6 having the value 2. However the Wireshark packet dissector defines LOCATOR_KIND_UDPv6 as having the value 8.Â

    The vendors interoperate and used Wireshark to fine-tune their discovery therefore they are actually using the Wireshark-defined values rather than the ones in table 9.4

    Proposed resolution:

    Modify Table 9.4 entry for ReliabilityKind_t from:
    #define RELIABLE 3

    to
    #define RELIABLE 2

    Modify Table 9.4 entry for Locator_t from:
    #define LOCATOR_KIND_UDPv6 2

    to
    #define LOCATOR_KIND_UDPv6 8

  • Reported: DDSI-RTPS 2.0b1 — Thu, 3 Jul 2014 04:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT

Message Size should be included as part of DDSI/RTPS Messages

  • Legacy Issue Number: 17286
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.1 — Fri, 30 Mar 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT

The Writer Liveliness Protocol should be removed

  • Legacy Issue Number: 17285
  • Status: open  
  • Source: PrismTech ( Angelo Corsaro)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.1 — Thu, 29 Mar 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT

Section: 8.5.3.2, Figure 8.27 and Table 8.73

  • Legacy Issue Number: 16968
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 126-127
    Change: In the figure and the table, BuiltinEndpointSet_t is already a "set" so it should not also be an array with "[*]"

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT

Locator_t kind needs a reserved range and a range for vendor extensions

  • Legacy Issue Number: 19694
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

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

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

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

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

  • Reported: DDSI-RTPS 2.2 — Thu, 18 Dec 2014 05:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT