Data Distribution Service Avatar
  1. OMG Specification

Data Distribution Service — Open Issues

  • Acronym: DDS
  • Issues Count: 472
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSSEC13-84 Changes related to key regeneration DDS-SECURITY 1.2 open
DDS15-332 Rules for evaluating liveliness by DataReader need to be clarified DDS 1.4 open
DDSXTY14-84 Make the format of annotation parameters more robust DDS-XTypes 1.3b1 open
DDSXTY14-16 Section 7.3.1.2.1.11 is unclear DDS-XTypes 1.3b1 open
DDSSEC13-52 Table 29 description of is_write_protected DDS-SECURITY 1.1b1 open
DDSSEC13-16 SecureSubmessageCategory_t in normative IDL DDS-SECURITY 1.1b1 open
DDSSEC13-83 Modify XSD to make the elements i version 1.2 optional DDS-SECURITY 1.2 open
DDSXTY14-82 Support optional for union members, add exception DDS-XTypes 1.3 open
DDSXTY14-83 Wrong type name used: VehiclePositionType DDS-XTypes 1.3 open
DDSXTY14-81 Inconsistent specification of where annotations can apply DDS-XTypes 1.3b1 open
DDSXTY14-80 Clarify behavior of @range and @unit with respect to type comptibility DDS-XTypes 1.3b1 open
DDS15-320 Missing escaping rules for filter expression, topic expression, query expression DDS 1.4 open
DDSXTY14-79 Typo fixes DDS-XTypes 1.3 open
DDSXTY14-78 Misspellings of "aggregated" DDS-XTypes 1.3 open
DDSXTY14-77 Inheritance rule regarding keys is overly restrictive DDS-XTypes 1.3 open
DDSJSON11-2 Validation errors in JSON Schemas DDS-JSON 1.0 open
DDSSEC13-82 Incorrect property names used DDS-SECURITY 1.2 open
DDSXTY14-76 Does @try_contruct(TRIM) leave strings with valid UTF-8 and UTF-16? DDS-XTypes 1.3 open
DDSXTY14-75 create_sample can't indicate failure DDS-XTypes 1.3 open
DDSSEC13-78 Operation: set_permissions_credential_and_token DDS-SECURITY 1.1b1 open
DDSSEC13-72 Builtin Auth dependency on Access Control details DDS-SECURITY 1.1b1 open
DDSSEC13-74 Misleading description of Crypto Key Exchange (8.5.1.8) DDS-SECURITY 1.1b1 open
DDSSEC13-73 Add explanation of how to use the secureWriterSet to support GROUP ordered access DDS-SECURITY 1.1b1 open
DDSSEC13-76 validate_remote_permissions interaction with Authentication Plugin DDS-SECURITY 1.1b1 open
DDSSEC13-71 Inconsistent descriptions of Data Tagging DDS-SECURITY 1.1b1 open
DDSSEC13-77 get_topic_sec_attributes 3rd parameter type DDS-SECURITY 1.1b1 open
DDSSEC13-75 IDL struct ParticipantSecurityAttributes contains ac_endpoint_properties DDS-SECURITY 1.1b1 open
DDSSEC13-70 serialized_local_participant_data passed to Auth plugin DDS-SECURITY 1.1b1 open
DDSSEC13-63 class_id string in Authentication/Permissions Tokens should include spec version DDS-SECURITY 1.1b1 open
DDSSEC13-64 Authentication Protocol: Make what is validated in the messages more explicit DDS-SECURITY 1.1b1 open
DDSSEC13-66 Add support for ChaCha20 DDS-SECURITY 1.1b1 open
DDSSEC13-69 Multiple grants in a permissions document DDS-SECURITY 1.1b1 open
DDSSEC13-67 Invalid IETF RFC document reference. DDS-SECURITY 1.1b1 open
DDSSEC13-65 Protecting the Source Timestamp DDS-SECURITY 1.1b1 open
DDSSEC13-68 IDL should be updated to match IDL 4.2 DDS-SECURITY 1.1b1 open
DDSSEC13-62 The Qos used to publish the BuiltinLoggingTopic is not specicified DDS-SECURITY 1.1b1 open
DDSSEC13-56 encode_rtps_message/decode_rtps_message error and status reporting DDS-SECURITY 1.1 open
DDSSEC13-60 Size of permission file sent on authentication can exceed max IP packet size DDS-SECURITY 1.1b1 open
DDSSEC13-55 Provide efficient way to skip encrypted implementation-specific content DDS-SECURITY 1.1b1 open
DDSSEC13-58 Add return_permissions_handle to the AccessControl interface DDS-SECURITY 1.1 open
DDSSEC13-57 Update parameters of check_remote_datawriter_register_instance DDS-SECURITY 1.1 open
DDSSEC13-61 Builtin Access Control operations (Table 63) missing entries DDS-SECURITY 1.1 open
DDSSEC13-59 Add best practice/implementation guidelines to the CryptoTransform plugin DDS-SECURITY 1.1b1 open
DDSSEC13-54 Provide a way for multiple vendors to extend the algorithms and interoperate DDS-SECURITY 1.1b1 open
DDSSEC13-53 Problematic use of multiple INFO_SRC within an RTPS DDS-SECURITY 1.1b1 open
DDSSEC13-50 Parsing messages generated by encode_serialized_payload (auth only) DDS-SECURITY 1.1b1 open
DDSSEC13-51 check_remote_topic domainId parameter DDS-SECURITY 1.1b1 open
DDSSEC13-49 AES-GCM doesn't add padding DDS-SECURITY 1.1b1 open
DDSSEC13-48 Builtin Crypto message authentication codes DDS-SECURITY 1.1b1 open
DDSSEC13-47 XML Schema defines boolean literals as "true" / "false" DDS-SECURITY 1.1b1 open
DDSSEC13-39 register_local_datareader and Data Protection Kind DDS-SECURITY 1.1b1 open
DDSSEC13-40 Replace "CryptoKeyTransform" with "CryptoTransform" DDS-SECURITY 1.1b1 open
DDSSEC13-43 Clarify the configuration and use of certificate chains for Identity DDS-SECURITY 1.1b1 open
DDSSEC13-44 Builtin CryptoKeyFactory direct dependency on AccessControl's config details DDS-SECURITY 1.1b1 open
DDSSEC13-42 Inconsistent Flag Name PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_BUILTIN_IS_DISCOVERY_ENCRYPTED DDS-SECURITY 1.1b1 open
DDSSEC13-45 Participant2ParticipantKxKeyMaterial DDS-SECURITY 1.1b1 open
DDSSEC13-46 9.5.3.3.4.3 should refer to the footer, not header DDS-SECURITY 1.1b1 open
DDSSEC13-41 "atributes" typo DDS-SECURITY 1.1b1 open
DDSSEC13-32 Modify Security's QoS changes for compatibility with RTPS DDS-SECURITY 1.1b1 open
DDSSEC13-38 IDL ParticipantSecurityAttributes::plugin_participant_attributes DDS-SECURITY 1.1b1 open
DDSSEC13-36 Reduce the range of Reserved RTPS parameter IDs DDS-SECURITY 1.1b1 open
DDSSEC13-35 Return types in CryptoKeyFactory interface description DDS-SECURITY 1.1b1 open
DDSSEC13-34 AuthRequestMessageToken future_challenge property DDS-SECURITY 1.1b1 open
DDSSEC13-37 Various Typos DDS-SECURITY 1.1b1 open
DDSSEC13-33 Broken cross-references DDS-SECURITY 1.1b1 open
DDSSEC13-26 Security for DDS-RPC DDS-SECURITY 1.1b1 open
DDSSEC13-27 Authentication behavior use of built-in endpoints DDS-SECURITY 1.1b1 open
DDSSEC13-28 Use a submessage flag to indicate Data/Frag submessage has a transformed payload DDS-SECURITY 1.1b1 open
DDSSEC13-29 Wrong XML tag in description of Enable Read Access Control DDS-SECURITY 1.1b1 open
DDSSEC13-30 Description of the PluginEndpointSecurityAttributes DDS-SECURITY 1.1b1 open
DDSSEC13-31 Description of the EndpointSecurityAttributes DDS-SECURITY 1.1b1 open
DDSSEC13-21 IDL get_topic_sec_attributes parameter typo DDS-SECURITY 1.1b1 open
DDSSEC13-24 Determining when to use DCPSParticipantMessageSecure DDS-SECURITY 1.1b1 open
DDSSEC13-23 ParticipantStatelessMessage definition DDS-SECURITY 1.1b1 open
DDSSEC13-22 IDL SubscriptionBuiltinTopicDataSecure inheritance DDS-SECURITY 1.1b1 open
DDSSEC13-25 8.4.2.9.24 section name typo DDS-SECURITY 1.1b1 open
DDSSEC13-15 Allow expressions to be used in the data-tag permissions DDS-SECURITY 1.1 open
DDSSEC13-14 Authentication interface begin_handshake_reply() DDS-SECURITY 1.1b1 open
DDSSEC13-17 decode_datawriter_submessage uses "in" for SecurityException DDS-SECURITY 1.1b1 open
DDSSEC13-18 get_datawriter/reader_sec_attributes inconsistent IDL DDS-SECURITY 1.1b1 open
DDSSEC13-19 Authentication interface set_permissions_credential_and_token DDS-SECURITY 1.1b1 open
DDSSEC13-20 IDL LongLongSeq unused DDS-SECURITY 1.1b1 open
DDSSEC13-13 DataHolder IDL inconsistent DDS-SECURITY 1.1b1 open
DDSSEC13-8 The specification should not duplicate (copy) the machine readable XSD files DDS-SECURITY 1.0 open
DDSSEC13-7 Section 3 (Normative References) should be updated and expanded DDS-SECURITY 1.0 open
DDSSEC13-12 Avoid sending permissions as part of Authentication Handshake DDS-SECURITY 1.1 open
DDSSEC13-11 Instance-Level access-control DDS-SECURITY 1.1 open
DDSSEC13-10 say explicitly that is_valid is set to zero if that is case DDS-SECURITY 1.1b1 open
DDSSEC13-9 Issues with the UML model used in the specification DDS-SECURITY 1.0 open
DDSSEC13-2 Built-in Authentication and Cryptography plugins tied together by SharedSecretHandle implementation DDS-SECURITY 1.0b1 open
DDSSEC13-3 Examples of Wildcard permissions DDS-SECURITY 1.0 open
DDSSEC13-4 The UML model should be cleaned up DDS-SECURITY 1.0 open
DDSSEC13-5 Remove Jira-issue related comments from machine-readable files DDS-SECURITY 1.0 open
DDSSEC13-6 The DDS-Security specification makes some modifications to the DDSI-RTPS protocol that should be taken into consideration DDS-SECURITY 1.0 open
DDSSEC13-1 Complexity of Authentication Plugin Model DDS-SECURITY 1.0b1 open
DDSIRTP26-39 writing error DDSI-RTPS 2.5 open
DDSXTY14-74 Clarify the intended member ID of a union's discriminator DDS-XTypes 1.3b1 open
DDSXTY14-73 Ambiguous definition and/or usage of PUSH(ORIGIN=0) DDS-XTypes 1.3b1 open
DDSXTY13-86 Clarify the intended member ID of a union's discriminator DDS-XTypes 1.3 open
DDSWEB11-3 Correct inconsistency on the URLs for the machine readable documents in the FTF2 report DDS-WEB 1.0 open
DDSXTY14-56 XCDR2 serialization of sequences of non-primitive elements DDS-XTypes 1.3b1 open
DDSXTY14-72 XCDR2 serialization of non-trivial maps DDS-XTypes 1.3b1 open
DDSXML11-5 DDS::Time_t/Duration_t changes DDS-XML 1.0 open
DDS15-13 DDS defines Time_t with seconds as long, this is 32bit. This will give an issue after 2038 DDS 1.2 open
DDS15-331 Proper interpretation of Duration_t for negative values DDS 1.4 open
DDSXTY14-69 Section contains a duplicate sentence from the next section. DDS-XTypes 1.3 open
DDSXTY13-85 Ambiguous definition and/or usage of PUSH(ORIGIN=0) DDS-XTypes 1.3 open
DDSXML11-4 How to describe the locator information in XML DDS-XML 1.0 open
DDSIRTP26-38 Extend InfoSource to contain RTPS HeaderExtension fields DDSI-RTPS 2.5 open
DDSXTY14-68 Update IDL definition of union TypeIdentifier in Annex B to account for primitive types DDS-XTypes 1.3b1 open
DDSXTY14-59 Clarify accessing discriminator of a DynamicData union DDS-XTypes 1.3 open
DDSIRTP26-37 Specify how a discovery service could be used to bootstap discovery DDSI-RTPS 2.5 open
DDSXTY14-38 Data Representation for RTPS's Serialized Key DDS-XTypes 1.3 open
DDSIRTP26-3 SequenceNumberSet validity could be too strict DDSI-RTPS 2.3 open
DDSXTY14-67 Typos in DynamicData UML Diagrams DDS-XTypes 1.3 open
DDSXTY14-66 Conflicting Order of Minimal Struct and Union Members in TypeObject DDS-XTypes 1.3 open
DDSXTY14-64 Should the TypeObject mark key members as must understand DDS-XTypes 1.3b1 open
DDSXTY14-65 Typo in DataRepresentationMask DDS-XTypes 1.3 open
DDSPSMC11_-4 DynamicData should be value type, not a reference type DDS-PSM-Cxx 1.0b2 open
DDSXTY14-47 Encoding of TypeInformation in SEDP DDS-XTypes 1.3 open
DDSXTY14-53 Description on how to encode Participant GUID in dds::rpc::RequestHeader seems wrong DDS-XTypes 1.3b1 open
DDSXTY14-54 Impossible to handle @must_understand AND @optional fields in an @appendable struct correctly DDS-XTypes 1.3b1 open
DDSXTY14-63 bitset types not defined DDS-XTypes 1.3b1 open
DDSIRTP26-36 Minor Typo in SubmessageKind IDL DDSI-RTPS 2.5 open
DDSXTY14-61 DynamicTypeSupport IDL defnition is invalid IDL DDS-XTypes 1.3 open
DDSIRTP26-35 DataFrag submessage element naming DDSI-RTPS 2.5 open
DDSIRTP26-34 Version number is inconsistent DDSI-RTPS 2.5 open
DDSIRTP26-4 Inconsistent notation used to represent bit positions pictorially DDSI-RTPS 2.5 open
DDSXTY14-60 Table 9 is missing BITMASK_TYPE DDS-XTypes 1.3 open
DDSIRTP26-33 Typo in 9.4.5.7.1 Flags in the Submessage Header DDSI-RTPS 2.5 open
DDS15-329 set_listener behavior is underspecified DDS 1.4 open
DDSIRTP26-6 Network amplification DDSI-RTPS 2.5 open
DDSXTY14-28 IDL's fixed data type is required in XTypes DDS-XTypes 1.3 open
DDSXTY14-36 Representing union case labels in TypeObject DDS-XTypes 1.3 open
DDSXTY14-35 Anonymous Types in Strongly Connected Components DDS-XTypes 1.3 open
DDSIRTP26-31 Inconsistency in the wire representation of SequenceNumber type fields DDSI-RTPS 2.5 open
DDSIRTP26-32 Typo in Table 9.18 (PID__DOMAIN_ID) DDSI-RTPS 2.5 open
DDSIRTP26-30 Incorrect definition of a user-defined within EntityId_t DDSI-RTPS 2.5 open
DDSXTY14-24 TypeFlags usage in normative IDL DDS-XTypes 1.3 open
DDSXTY14-58 Dynamic Binding: equals() for DynamicType/DynamicTypeMember and related types DDS-XTypes 1.3 open
DDSXTY14-57 Annex C: BoundSeq IDL type not defined DDS-XTypes 1.3 open
DDS15-250 Align with XTYPES 1.3 and IDL 4.2 DDS 1.4 open
DDS15-315 InstanceHandle_t underspecified DDS 1.4 open
DDSIRTP26-29 Wrong data type for serializedPayload in DATAFRAG DDSI-RTPS 2.5 open
DDS15-328 Annex A: Ownership Profile is unclear DDS 1.4 open
DDSIRTP26-28 Introduce a concept of Partitions at the DomainParticipant level DDSI-RTPS 2.5 open
DDSIRTP26-27 The specs and illustration of the ChangeForReader are missing / have been removed DDSI-RTPS 2.5 open
DDSIRTP26-26 Error in formatting pseudo code DDSI-RTPS 2.5 open
DDSIRTP26-25 Handling of non-existent cache changes in logical action DDSI-RTPS 2.5 open
DDS15-327 The "depth" QoS setting does not have any bounds set DDS 1.4 open
DDSXML11-3 Missing DDS-XTypes extensions (which should be part of DDS 1.5) DDS-XML 1.0 open
DDSIRTP26-24 Inconsistent use of higuest_sent_seq_num and highestSentChangeSN DDSI-RTPS 2.5 open
DDSIRTP26-23 Inconsistent use of SEQUENCE_NUMBER_INVALID; for highestSentChangeSN DDSI-RTPS 2.5 open
DDSXTY14-55 Add support for data-level compression during serialization DDS-XTypes 1.3b1 open
DDSIRTP26-17 Fields writerSet and secureWriterSet are missing in wire representation: DDSI-RTPS 2.5 open
DDSIRTP26-16 Paramter id and length should be unsigned short DDSI-RTPS 2.5 open
DDSIRTP26-14 Masks in table 9.6 (ParameterId subspaces) should be hexadecimal DDSI-RTPS 2.5 open
DDSIRTP26-13 Note on the message wide CRC check DDSI-RTPS 2.5 open
DDSIRTP26-11 Textual error in section 9.4.5.2.1 DDSI-RTPS 2.5 open
DDSIRTP26-10 Description incomplete DDSI-RTPS 2.5 open
DDSIRTP26-12 CRC computation for Checksum128_t undefined DDSI-RTPS 2.5 open
DDSIRTP26-15 Please ignore Implementation Work Blocked flag in issue INBOX-1375 DDSI-RTPS 2.5 open
DDSXTY14-17 Typo or editing issue DDS-XTypes 1.3b1 open
DDSXTY14-44 Default value and @default annotations DDS-XTypes 1.3 open
DDSJSON11-1 JSON Representation of Unions DDS-JSON 1.0 open
DDSIRTP26-9 Unclear how to discover GROUP_GUID/GROUP_ENTITY_ID from a coherent Publisher DDSI-RTPS 2.5 open
DDS15-326 Incorporate the lookup_topicdescription change added in XTYPES 1.3 DDS 1.4 open
DDSPSMC11_-96 dds::core::status::StatusMask should allow you to set mutiple Status bits by using the logical OR operation DDS-PSM-Cxx 1.0 open
DDS15-245 Clarify the PartitionQosPolicy DDS 1.4 open
DDSIRTP26-7 Provide a pre-shared key protection mechanism DDSI-RTPS 2.5 open
DDSXTY14-52 Missing TK_INT8 and TK_UINT8 in the IDL machine readable file DDS-XTypes 1.3b1 open
DDSXTY14-51 Extensibility of inherited structures DDS-XTypes 1.3b1 open
DDSXTY14-20 Inconsistent Definitions of RTPS Encapsulation DDS-XTypes 1.3b1 open
DDSXTY14-50 Integrate annotations for range/min/max with try_construct DDS-XTypes 1.3b1 open
DDSXTY14-49 Remove all IDL42 specified parts DDS-XTypes 1.3 open
DDSXTY14-48 8 bit types mising in 7.2.1 DDS-XTypes 1.3 open
DDS15-316 find_topic/delete_topic underspecified DDS 1.4 open
DDS15-325 Read / Take with max_samples = 0 DDS 1.4 open
DDSXTY14-39 TypeLookup IDL Inconsistency DDS-XTypes 1.3 open
DDSRPC11-5 Common Types contains invalid IDL DDS-RPC 1.0 open
DDSXTY14-46 Typo in Member of AnnotationParameterValue DDS-XTypes 1.3 open
DDSIRTP26-5 Section 9.4.2.9 Timestamps shows 'seconds' as 'long' instead of 'unsigned long' DDSI-RTPS 2.5 open
DDS15-324 sample lost/rejected should be clarified and extended DDS 1.4 open
DDS11-15 DDS should use typed modules DDS 1.2 open
DDS15-323 Order in which implied IDL and language mappings interact DDS 1.4 open
DDS15-322 Incorrect value for GROUPDATA_QOS_POLICY_NAME DDS 1.2 open
DDSXTY14-45 The list of valid KEY types does not include String types DDS-XTypes 1.3 open
DDSOPCU11-3 IDL keywords used as interface/module DDS-OPCUA 1.0 open
DDSOPCU11-2 Don't use anonymous types DDS-OPCUA 1.0 open
DDSXML11-2 No mapping for uint8/int8, map, bitset DDS-XML 1.0 open
DDSIRTP26-2 Support transport-level RTPS message compression DDSI-RTPS 2.3b1 open
DDSIRTP26-1 Interoperability of Transient/Persistent data DDSI-RTPS 2.3b1 open
DDS15-321 Example class table seems to violate written convention DDS 1.4 open
DDS15-28 DDS Entities should have a name DDS 1.2 open
DDSXTY14-42 Table 60 - RTPS encapsulation identifier DDS-XTypes 1.3 open
DDS15-319 create_querycondition with a query with string parameters DDS 1.4 open
DDSXTY14-41 Unknown behavior of explicitly negated key in nested struct DDS-XTypes 1.3b1 open
DDSXTY14-40 Type Consistency Enforcement QoS Policy ignore_member_names DDS-XTypes 1.3 open
DDS15-318 Extend SampleLostStatus with last_reason DDS 1.4 open
DDSXTY14-37 Ambiguous effect of using annotations on attributes with multiple declarators. DDS-XTypes 1.3b1 open
DDS15-317 behaviour of create_topic with duplicate topic_name DDS 1.4 open
DDS15-46 Default built-in ReaderDataLifecycle values DDS 1.2 open
DDS15-314 Change the default value for DataWriterLifecycle::autodispose_unregistered_instances and behavior when a DataWriter is deleted DDS 1.4 open
DDSXTY14-33 Enums with different holder types should not be assignable DDS-XTypes 1.3 open
DDSXTY14-25 7.4.3.5.3 contradictory rules for collections DDS-XTypes 1.3 open
DDSXTY14-27 DataRepresentationQosPolicy default DDS-XTypes 1.3 open
DDSXTY14-29 Specify that TypeLookup Service uses XCDR2 DDS-XTypes 1.3 open
DDSXTY14-26 XTypes spec is missing topic names for TypeLookupService DDS-XTypes 1.3 open
DDSXTY14-23 Missing alignment for XCDR1 mutable's sentinel DDS-XTypes 1.3b1 open
DDSRPC11-1 Mapping of one single Topic per Service does not work well with DDS Security DDS-RPC 1.0 open
DDSPSMC11_-95 Listener model breaks API design goal of automatic resource management DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-93 Typo fixes DDS-PSM-Cxx 1.0 open
DDSXTY14-21 Can structures contain constant declarations? DDS-XTypes 1.3b1 open
DDS15-313 Editorial corrections DDS 1.4 open
DDS15-199 Typo DDS 1.4 open
DDS15-312 Default value for WRITER_DATA _LIFECYCLE v should be FALSE DDS 1.4 open
DDSPSMC11_-94 DynamicType should be a value type, not a reference type DDS-PSM-Cxx 1.0b2 open
DDSXTY14-19 Confusing description of FINAL on 7.2.3 TypeExtensibilityandMutability DDS-XTypes 1.3b1 open
DDS15-311 Add a function that allows releasing any resources created by the DomainParticipantFactory DDS 1.4 open
DDSXTY14-14 Define Implied Keys Behavior DDS-XTypes 1.3b1 open
DDSXTY14-18 7.4.3.5.3 doesn't define OPTIONS DDS-XTypes 1.3b1 open
DDSXTY14-13 Be more precise on meaning of string lengths and bounds DDS-XTypes 1.3b1 open
DDSXTY14-15 Implementation Defined Default Nested Behavior DDS-XTypes 1.3b1 open
DDS15-310 get_discovered_participant_data() should return BAD_PARAMETER instead of PRECONDITION_NOT_MET DDS 1.4 open
DDSXTY14-12 Need to add an ignore_enum_literal_names in TypeConsistencyEnforcement QosPolicy DDS-XTypes 1.3b1 open
DDSXTY14-11 Clarify whether the algorithm to compute KeyHash is specific to XTYPES DDS-XTypes 1.3b1 open
DDSXTY14-10 Missing parameter in Annex C operation DynamicDataFactory::create_data DDS-XTypes 1.3b1 open
DDSXTY14-8 Extra text left in section 7.2.2.4.4.4.4 Member IDs DDS-XTypes 1.3b1 open
DDSOPCU11-1 Typos and Inconsistencies DDS-OPCUA 1.0 open
DDSXRCE11-3 Extra fields in IDL of 7.8.2.1 create_client DDS-XRCE 1.0 open
DDSXTY14-6 Extra fields in IDL of 7.8.2.1 create_client DDS-XTypes 1.3b1 open
DDS15-256 Define InstanceHandle_t and DomainId_t portably DDS 1.4 open
DDS15-5 InstanceHandle_t/Domain ID DDS 1.2 open
DDS15-240 The start time of type Time_t is not defined DDS 1.4 open
DDS15-251 Wrong name for DataRepresentationQosPolicy field DDS 1.4 open
DDS15-246 Collection of longs misrepresented in 2.2.1.1 MyClass DDS 1.4 open
DDS15-247 Names of listener operations are incorrect in UML diagrams DDS 1.4 open
DDS15-249 Consider replacing @Choice annotation with XTYPES 1.2 unions DDS 1.4 open
DDS15-195 Typo in section 2.2.2.5 Subscription Module DDS 1.4 open
DDS15-188 DATAWRITER_QOS_USE_TOPIC_QOS and DATAREADER_QOS_USE_TOPIC_QOS DDS 1.2 open
DDS15-51 Invalid DURABILITY_SERVICE reference on the DataWriter DDS 1.2 open
DDS15-20 The DDS Specification should define legal DDS Topic Types DDS 1.4 open
DDS15-185 Invalid DURABILITY_SERVICE reference on the DataWriter DDS 1.1 open
DDS15-186 subset of OMG IDL DDS 1.1 open
DDS15-181 Typo on description of class TopicDescription DDS 1.2 open
DDS15-182 Clarification of create_multitopic behavior DDS 1.2 open
DDS15-184 create_contentfilteredtopic Method Prototype and Description Out DDS 1.2 open
DDS15-178 Clarification of instance_state -- Section: 2.1.2.5.1.3 DDS 1.2 open
DDS15-179 Clarify behavior of register_type operation DDS 1.2 open
DDS15-174 Typo in Section: 2.1.3 DDS 1.2 open
DDS15-176 Typo on descripton of "read" operation DDS 1.2 open
DDS15-172 Typo in Section: 2.2.3.14 DDS 1.2 open
DDS15-173 Typo in description of "persistence" service responsibility DDS 1.2 open
DDS15-34 'synchronous' and 'asynchronous' switched DDS 1.2 open
DDS15-35 Specify the allowed IDL Types within DDS Topic structs DDS 1.2 open
DDS15-37 DDS typos and omissions DDS 1.2 open
DDS15-153 Definition of BuiltinTopicKey_t DDS 1.2 open
DDS15-235 DURABILITY history depth should be de-coupled from the KEEP_LAST history depth used for reliability DDS 1.4 open
DDS15-32 No specific package definition for the entities of the model in case of JAVA language binding DDS 1.4 open
DDS15-33 Deprecated usage of IDL in the DDS spec DDS 1.2 open
DDS15-31 Mapping of OMG IDL to C++ for DDS DDS 1.2 open
DDS15-25 History and Reliability should be orthogonally independent concerns DDS 1.4 open
DDS15-21 Wrong definition of GROUPDATA_QOS_POLICY_NAME constant in IDL DDS 1.4 open
DDS15-14 : #define HANDLE_TYPE_NATIVE long typedef HANDLE_TYPE_NATIVE InstanceHandle_t; DDS 1.2 open
DDS15-15 For ContentFilteredTopic::get_expression_parameters the argument name is not given in the spec DDS 1.2 open
DDS15-16 Introduce new typedef for anonymous types DDS 1.2 open
DDS15-17 The get_sample_lost method seems to be part of the Subscriber class DDS 1.1 open
DDS15-8 DDS should require to annotate IDL to indicate which IDL types are used for dds DDS 1.2 open
DDS15-9 DDS specification should be more precise on NATIVE defines DDS 1.2 open
DDS15-10 Add DDS::STATUS_MASK_NONE DDS 1.2 open
DDS15-12 Add new mask which will let DDS callback on the listener to gets its mask DDS 1.2 open
DDSXTY14-5 Consider referencing DDS-XML for the XML type and data representations DDS-XTypes 1.3b1 open
DDS15-309 Extend SampleInfo with sequenceNumber and reception_timestamp DDS 1.4 open
DDS15-4 Spec lacks definition regarding uniqueness of InstanceHandle_t DDS 1.2 open
DDSRPC11-4 Consider replacing @Choice annotation with XTYPES 1.2 unions DDS-RPC 1.0 open
DDS15-197 Legal characters and length of Topic Name DDS 1.4 open
DDS15-1 TypeSupport::get_type_name should be precisely specified DDS 1.2 open
DDS15-27 behaviour of redefining multiple times the same topic with different QoS not clearly specified DDS 1.2 open
DDS15-26 Missing APIs for (read|take)_instance_w_condition DDS 1.4 open
DDS15-43 DDS DCPS Issue: PRESENTATION=GROUP and QoS DDS 1.2 open
DDS15-24 The compatibility rules for the Presentation QoS are too strict DDS 1.2 open
DDS15-303 PARTITION PolicyQos should be in DataReader/DataWriter DDS 1.4 open
DDS15-194 Coherent updates with best efforts DDS 1.4 open
DDS15-183 Clarification of resource management DDS 1.2 open
DDS15-177 Section: 2.1.2.5.3 clarification of parameters to 'read/take' operation DDS 1.2 open
DDS15-248 Deprecate Basic Service Mapping DDS 1.4 open
DDSXTY14-4 Wrong name for DataRepresentationQosPolicy field DDS-XTypes 1.3b1 open
DDS15-36 DURABILITYSERVICE_POLICY_NAME DDS 1.2 open
DDS15-23 When using GROUP access scope presentation QoS, allow for read/take outside of begin_access and end_access block DDS 1.2 open
DDS15-22 Allow for more optimized list returned by get_datareaders() DDS 1.2 open
DDS15-266 Organize definitions of Time_t, Duration_t and other common types in the PIM DDS 1.4 open
DDS15-7 Add several with_profile methods DDS 1.2 open
DDS15-6 get_type_name, class or object method DDS 1.2 open
DDS15-258 Add a DomainTag to the PSM DDS 1.4 open
DDS15-3 Write with handle_nil underspecified DDS 1.2 open
DDS15-2 ContentFilteredTopics should be removed. Filtering belongs to DataReaders DDS 1.2 open
DDSXTY14-2 Specify more clearly which types have a name and how it is constructed DDS-XTypes 1.3b1 open
DDSXTY14-1 Add Unions to types supported in Queries and Filters DDS-XTypes 1.3b1 open
DDS15-255 What can be done with a disabled Topic? DDS 1.4 open
DDS15-254 Specify the behavior of instance state machine in case of a disconnect-reconnect scenario DDS 1.4 open
DDS15-253 Consider adding some of the concepts in the new PSMs to the PIM DDS 1.4 open
DDSPSMC11_-3 Missing get_discovered_participants and get_discovered_participant_data functions DDS-PSM-Cxx 1.0b2 open
DDS15-252 Clarify definition of counts in Plain Communication Status DDS 1.4 open
DDSPSMC11_-86 Instance handle constructor for TopicInstance should be deleted. DDS-PSM-Cxx 1.0 open
DDSPSMC11_-77 Unintuitive way to access extension member functions DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-69 Condition classes should only be used with WaitSets DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-71 Remove templatization for datatype from TopicDescription DDS-PSM-Cxx 1.0 open
DDSPSMC11_-82 MERGE CONFLICT: Modify Topic inheritance DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-25 Inheritance hierarchy of C++11 PSM conflicts with inheritance hierarchy from DDS PIM DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-73 Use consistent way to refer to vendor specific Delegate DDS-PSM-Cxx 1.0 open
DDSPSMC11_-7 Inconsistent ways to set functor in Condition types DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-79 MERGE CONFLICT: Modify description of additional StatusCondition constructor. DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-70 StatusCondition should have a singleton delegate DDS-PSM-Cxx 1.0 open
DDS15-52 DataReader semantics for historical data are insufficient DDS 1.2 open
DDSPSMC11_-75 MAP_TYPE enumeration constant should be redefined due to clash with POSIX macro DDS-PSM-Cxx 1.0b2 open
DDSJAVA11_-1 DataReader.read should return an Iterable collection, not an Iterator DDS-Java 1.0b2 open
DDSPSMC11_-1 API correction required to dds/sub/find.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-72 Transform AnyDataWriter and AnyDataReader from wrappers into parent classes. DDS-PSM-Cxx 1.0 open
DDSPSMC11_-74 Define relationship between Query and QueryCondition DDS-PSM-Cxx 1.0 open
DDSXRCE11-2 CREATE_CLIENT example: typo in hex representation of submessageLength DDS-XRCE 1.0b1 open
DDSXRCE11-1 Serial Transport (section C.1) should be a subsection of 11 DDS-XRCE 1.0b1 open
DDSIRTP23-136 Erratum DDSI-RTPS 2.2 open
DDSRPC11-3 Remove the 'default' case in Requst and Return union types DDS-RPC 1.0 open
DDSXML11-1 Fix a number of typos in specification document DDS-XML 1.0 open
DDS15-244 Communication Status changes for multiple events DDS 1.4 open
DDSPSMC11_-66 Make use of C++11 final/override/delete DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-68 Small correctes to the specification DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-67 Normative references not complete and out of date DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-64 Missing TBuiltinTopicTypes DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-63 Provide extension constructors for standard classes DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-65 EntityQos is overly general DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-62 Names of the generated headers DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-61 Default Constructors DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-53 API corrections required to src/hpp/dds/core/Exception.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-51 API corrections required to src/hpp/dds/core/TQosProvider.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-52 API corrections required to src/hpp/dds/core/TInstanceHandle.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-50 Documentation comments corrections required to src/hpp/dds/domain/discovery.hpp & find.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-60 API correction required to src/hpp/dds/dds.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-55 API correction required to src/hpp/dds/core/status/TStatus.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-59 API correction required to src/hpp/dds/core/status/State.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-57 API correction required to src/hpp/dds/core/policy/TCorePolicy.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-56 API correction required to src/hpp/dds/sub/AnyDataReaderListener.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-54 Missing file dds/pub/detail/find.hpp referenced in src/hpp/dds/pub/find.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-47 Documentation comments corrections to src/hpp/dds/pub/TPublisher.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-48 API correction required to src/hpp/dds/sub/LoanedSamples.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-58 DataReader.hpp, ContentFilteredTopic.hpp, Topic.hpp, TopicDescription.hpp o not compile with MS Visual Studio DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-49 API correction required to src/hpp/dds/core/cond/detail/GuardCondition.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-28 Inconsistent use of Type/type - fix compilation DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-31 API correction required to src/hpp/dds/core/Optional.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-43 Example vendor code is incorrect DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-29 API correction required to src/hpp/dds/core/cond/TWaitSet.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-45 API correction required to src/hpp/dds/core/cond/StatusCondition.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-33 Code in src/hpp/dds/core/array.hpp does not compile DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-41 API correction required to src/hpp/dds/pub/AnyDataWriter.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-34 API correction required to src/hpp/dds/domain/qos/detail/DomainParticipantQos.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-32 API correction required to src/hpp/dds/domain/TDomainParticipant.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-42 src/hpp/dds/domain/TDomainId.hpp should be removed from the API DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-40 API correction required to src/hpp/dds/core/types.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-30 API correction required to src/hpp/dds/core/ref_traits.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-39 API correction required to src/hpp/dds/core/detail/conformance.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-44 API correction required to src/hpp/dds/pub/qos/detail/DataWriterQos.hpp & PublisherQos.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-36 Documentation comments corrections to src/hpp/dds/pub/discovery.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-35 API correction required to src/hpp/dds/pub/TSuspendedPublication.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-46 API correction required to src/hpp/dds/sub/TDataReader.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-37 API correction required to src/hpp/dds/sub/SubscriberListener.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-38 API correction required to src/hpp/dds/sub/DataReaderListener.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-27 API correction required to src/hpp/dds/sub/SharedSamples.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-23 API needs a standardized way of downcasting API entities DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-26 Name clash between Topic discovery functions DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-24 dds::topic::TBuiltinTopicKey should be completely customizable. DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-19 dds/core/cond/TCondition.hpp should have virtual methods DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-22 Ownership label SHARED is already defined as a macro in some SUN compilers DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-21 Compilation error in dds/core/policy/PolicyKind.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-20 dds/core/array.hpp is licensed under LGPL DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-12 Reference should provide comparison operators DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-15 Missing constants/functions to obtain the built-in topic names DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-14 API corrections required to dds/core/Duration.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-17 API correction required to dds/core/Time.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-8 API corrections required to dds/sub/AnyDataReader.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-13 API does not provide functionality from the DomainParticipantFactory DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-9 Correction required to dds/sub/ddssub.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-11 API correction required to dds/topic/TBuiltinTopic.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-16 Selector missing next_instance() function DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-18 dds/pub/find.hpp is incomplete DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-10 Declaring Reference::operator new() private causes undesired side effects DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-5 Generic InstanceHandle constructor should be explicit DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-2 Method SampleInfo::valid() should be renamed SampleInfo::valid_data() DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-6 API corrections required to ManipulatorSelector and related functions DDS-PSM-Cxx 1.0b2 open
DDS15-243 Dispose for topics without key DDS 1.4 open
DDSIRTP23-135 Use of Stateful versus Stateless Endpoints DDSI-RTPS 2.2 open
DDSRPC11-2 Errors in non-normative IDL of section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types DDS-RPC 1.0 open
DDS15-242 set_expression_parameters on ContentFilteredTopic, MultiTopic DDS 1.4 open
DDS15-241 Clarify when a dispose or unregister may be omitted for a Reader DDS 1.4 open
DDS15-238 Add restrictions and guidelines that are required when writing GROUP coherent sets DDS 1.4 open
DDS15-239 Add resource limits related to coherent changes DDS 1.4 open
DDS15-237 How to handle some GROUP ordered Subcriber scenarios DDS 1.4 open
DDS15-236 Request/Offered behavior of DURABILITY Qos does not match use-cases DDS 1.4 open
DDS15-234 Incorporate common elements from DDS Security to the Builtin Topics DDS 1.4 open
DDS15-208 Add DataTagQosPolicy DDS 1.4 open
DDS15-209 Define ranges of QosPolicyId_t DDS 1.4 open
DDS15-50 Add name attribute to Entity DDS 1.2 open
DDS4CCM11-15 Schema appears to be missing root element DDS4CCM 1.1 open
DDS15-207 Durability section typos DDS 1.4 open
DDS15-206 BuiltinTopicKey_t should be completely customizable. DDS 1.4 open
DDS15-205 Specify behavior of filters and queries relative of lifecycle events DDS 1.4 open
DDS15-204 Add API for "directed writes" DDS 1.4 open
DDS15-203 Topic Names are Restricted to Characters, Digits, and Hyphens DDS 1.4 open
DDSSEC_-190 Multiple DataReaders per topic on secured Participant DDS-SECURITY 1.0 open
DDS15-202 Relationship between begin/end coherent changes and presentation.coherent_access==true DDS 1.4 open
DDS15-201 No specification for unregister_type for TypeSupport interface DDS 1.4 open
DDS4CCM11-14 Remove key_fields DDS4CCM 1.1 open
DDS15-200 Syntax for Topic Names DDS 1.4 open
DDS15-198 Add a write_sequence() operation to DataWriter DDS 1.4 open
DDSJAVA11-17 Correct inconsistency on the URLs for the machine readable documents DDS-Java 1.0 open
DDS15-175 Clarify behavior of "take" operation DDS 1.2 open
DDS15-180 Behavior of multiple calls to create_topic -- Section: 2.1.2.3.2 DDS 1.2 open
DDS15-196 Clarify RxO behavior for DURABILITY Qos DDS 1.4 open
DDS15-30 [DDS] Data types permissible as topic key fields DDS 1.2 open
DDS15-171 Force KEEP_ALL to be RELIABLE Section: 2.1.3.18 DDS 1.2 open
DDS15-45 Cancel coherent update DDS 1.2 open
DDS15-190 Specify Publishers with PRESENTATION access_scope GROUP should use same order for DataWriters DDS 1.4 open
DDSWEB11-2 The file dds-xtypes_type_definition.xsd should not define a targetNamespace DDS-WEB 1.0b1 open
DDSWEB11-1 JSON Missing DDS-WEB 1.0b1 open
DDSIRTP2-60 missing space "eachother" DDSI-RTPS 2.0b1 open
DDS15-49 Semantics instance liveliness and ownership unclear DDS 1.2 open
DDS15-44 Get entity enabled state DDS 1.2 open
DDS15-29 All IDL should use local interfaces DDS 1.4 open
DDS15-47 Inconsistent lookup semantics DDS 1.2 open
DDS15-48 Missing TypeSupport operations DDS 1.2 open
DDS15-11 Extend Topic with method to retrieve key fields DDS 1.2 open
DDS11-10 Attributes_on_the_data DDS 1.0b1 open
DDS4CCM11-5 Make all arguments inout DDS4CCM 1.0 open
DDS4CCM11-7 DDS_TopicBase connector lacks type_name DDS4CCM 1.0 open
DDS4CCM11-1 Name patterns should support underscores and scoping DDS4CCM 1.0 open
DDS11-2 Ref-232 Allow_reader_to_access_partition_of_writer DDS 1.0b1 open
DDS11-3 ref-1053 Missing is_composition DDS 1.0 open
DDS4CCM11-4 Make topic_name changeable DDS4CCM 1.1 open
DDS4CCM11-9 Section 8.4.4 talks about threading, but this section is really under specified DDS4CCM 1.0b1 open
DDS11-4 Detection_of_dynamic_qos_failure Issue DDS 1.0b1 open
DDS4CCM11-8 Let the user be able to instantiate one dds connector DDS4CCM 1.0 open
DDS11-12 Extension_to_the_query_language DDS 1.0b1 open
DDS11-1 Ref-167 Malloc_required_for_get_default_qos DDS 1.0b1 open
DDS11-5 Additional_qos_THROUGHPUT Issue DDS 1.0b1 open
DDS11-8 DDS ISSUE# 50] Multiple observers sharing a datareader DDS 1.0b1 open
DDS11-11 Filtered_out_lifecycle_state Issue DDS 1.0b1 open
DDS4CCM11-3 StateListenerControl:: is_filter_interpreted should be documented as optional DDS4CCM 1.0 open
DDS4CCM11-6 Layout issue test DDS4CCM 1.0 open
DDS11-9 DDS ISSUE# 51] Avoid use of dynamic memory for manipulating QoS DDS 1.0b1 open
DDS4CCM11-2 attributes as part of porttype do appear on port and mirrorport DDS4CCM 1.0 open
DDS11-7 Key_separate_from_data Issue DDS 1.0b1 open
DDS11-6 DDS ISSUE# 47] Allow application to not specify a timstamp DDS 1.0b1 open
DDS4CCM11-11 proposed simple spec extension for common DDS use case DDS4CCM 1.1 open
DDS4CCM11-10 The model file ptc/11-02-11 is not valid UML – it has eclipse namespace and extraneous elements DDS4CCM 1.0 open
DDS11-14 'synchrobnous' and 'asynchronous' switched DDS 1.1 open
DDS11-13 section 2.1.2.5.2.16 "get_default_datareader_qos" DDS 1.1 open
DDSJAVA11-6 Inconsistency in close() operations wrt. "throw java.io.IOException" declaration DDS-Java 1.0 open
DDSJAVA11-5 Operations with Collection as parameter should provide a "varargs" alternative DDS-Java 1.0 open
DDSJAVA11-12 StatusCondition should be immutable and have fluent API DDS-Java 1.0 open
DDSJAVA11-11 Error in Javadoc of DomainParticipantFactory.createParticipant(domain, qos, listener, statuses) DDS-Java 1.0 open
DDSJAVA11-8 In DomainParticipantFactoryQoS interface withPolicy() and withPolicies() have wrong parameters types DDS-Java 1.0 open
DDSJAVA11-7 The PolicyFactory class misses operations for Presentation and TopicData creation DDS-Java 1.0 open
DDSJAVA11-16 Missing "not" DDS-Java 1.0b1 open
DDSJAVA11-15 The resolution of the FTF Issue 15966 was partially applied DDS-Java 1.0 open
DDSJAVA11-10 The DataReaderQos interface misses a getReliability() operation DDS-Java 1.0 open
DDSJAVA11-9 Error in implementation of TypeSupport.newTypeSupport() DDS-Java 1.0 open
DDSJAVA11-14 In WaitSet all waitForCondition() operations should return the triggered conditions DDS-Java 1.0 open
DDSJAVA11-13 WaitSet should be aligned to the ISO C++ IDDS PSM DDS-Java 1.0 open
DDSJAVA11-2 ModifiableInstanceHandle should be removed DDS-Java 1.0 open
DDSJAVA11-1 The current Java PSM makes an implicit assumptions on member ordering DDS-Java 1.0b1 open
DDSJAVA11-4 Bucket accessors shall be removed DDS-Java 1.0 open
DDSJAVA11-3 RequestOffered.requestedOfferedContract() semantic should be removed DDS-Java 1.0 open
DDS15-187 Durability Implementation Description does not consider the role of partitions DDS 1.4 open

Issues Descriptions

Changes related to key regeneration

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Use of CryptoTransformKeyRevisionIntHolder alias in operation parameters

    The DDS Security Specification 1.2 defines the CryptoTransformKeyRevisionIntHolder type as:

    typedef int32 CryptoTransformKeyRevisionIntHolder;

    The SPIs should use this type consistently where appropriate.
    For example, activate_key_revision SPI uses CryptoTransformKeyRevisionIntHolder to type its key_revision parameter. However, the key_revision parameter of create_local_datawriter_crypto_tokens, create_local_datareader_crypto_tokens and create_local_datareader_crypto_tokens is an int32.

    This should be changed so all these operations use CryptoTransformKeyRevisionIntHolder

    Clarify section “9.8.10.2 Key Exchange with remote DataReader

    The description in page 182 should clarify that that the participant can call create_local_datawriter_crypto_tokens multiple times (to get a crypto token sequence for different revisions).

  • Reported: DDS-SECURITY 1.2 — Thu, 10 Oct 2024 19:00 GMT
  • Updated: Thu, 21 Nov 2024 13:21 GMT

Rules for evaluating liveliness by DataReader need to be clarified

  • Key: DDS15-332
  • Status: open  
  • Source: Unity Foundation, NP ( Mr. Justin Wilson)
  • Summary:

    2.2.3 (p. 96) The DataReader requests that liveliness of
    the writers is maintained by the requested
    means and loss of liveliness is detected with
    delay not to exceed the lease_duration.
    The DataWriter commits to signalling its
    liveliness using the stated means at
    intervals not to exceed the lease_duration.

    Since both the DataReader and DataWriter have a lease duration, the reference to lease_duration is ambiguous.

    2.2.3.11 (p. 107) Changes in LIVELINESS must be detected by the Service with a time-granularity greater or equal to the lease_duration. This
    ensures that the value of the LivelinessChangedStatus is updated at least once during each lease_duration and the related
    Listeners and WaitSets are notified within a lease_duration from the time the LIVELINESS changed.

    Same problem, the reference to lease_duration could refer to the writer or the reader.

    Other sections not mentioning the lease_duration may have similar problems.

    The language around on_liveliness_changed implies that changes (listener, wait set) must be communicated at least once for every lease_duration of the DataReader.

    The spec should clarify three things:
    1. How often does the DataReader evaluate the liveliness of a DataWriter? Is this at a period of at most the DataReader's lease_duration or a period of at most the DataWriter's lease_duration?
    2. When the DataReader evaluates the liveliness of a DataWriter, which lease_duration should it use, the lease_duration of the DataReader or the lease_duration of the DataWriter?
    3. Are the rules for evaluating liveliness for the purpose of ownership the same as for listeners and waitsets? This question is particularly vexing because it can lead to inconsistency where ownership should be eventually consistent.

    To illustrate the problem, consider the following a system using exclusive ownership.

    • Writer 1 has a lease_duration of 1 second but only writes/asserts every 4 seconds. Ownership strength of 1.
    • Writer 2 has a lease_duration of 1 second but only writes/asserts every 4 seconds. Ownership strength of 2.
    • Reader 1 has a lease_duration of 2 seconds.
    • Reader 2 has a lease_duration of 4 seconds.

    Let events happen according to this sequence:

    Time Writer 1 Writer 2 Reader 1 Reader 2
    1. assert      
    2.     eval  
    3.   assert    
    4.     eval eval
    5. assert      
    6.     eval  
    7.   assert    
    8.     eval eval
    9. assert      
    10.     eval  

    If we assume that the readers evaluate liveliness at a period of their own lease_duration using their own lease_duration, then Reader 2 will always see Writer 2 as the owner while Reader 1 will toggle ownership between the writers. Thus, there is no eventual consistency of exclusive ownership.

    If we assume that the readers evaluate liveliness at a period of their own lease_duration using the lease_duration of the writer, then both readers will consistently toggle and never see a live writer.

    If we assume that the readers evaluate liveliness independently for each writer at the lease_duration of the writer, then the readers will see ownership toggling but periods where writers are alive.

    Ideally, liveliness would be objective and not subjective. That is, liveliness should be based on the behavior of the writer interpretted by its lease_duration. Different readers may observe different things leading to temporary inconsistency, but eventual consistency would be guaranteed.

    If the spec choose a subjective approach, then language should be added that warns the reader of the problem and the consequences like ownership not working as expected.

  • Reported: DDS 1.4 — Tue, 12 Nov 2024 16:49 GMT
  • Updated: Thu, 14 Nov 2024 18:26 GMT

Make the format of annotation parameters more robust

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    When an annotation application definition has a simpgle paramater the application can omit the paramater name.

    When an annotation application specifies multiple parameters it is possible to commit the parameter name for the parameter named "value" ,

    This means that an annotation that was specified with a single parameter (not called value) which is then extended will need to be modified if a second paramater is added.

    Instead it would be more flexible to say that the first paramater can be unnamed regardless of the name.

  • Reported: DDS-XTypes 1.3b1 — Wed, 30 Oct 2024 16:48 GMT
  • Updated: Wed, 30 Oct 2024 16:48 GMT

Section 7.3.1.2.1.11 is unclear

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    There are three problems.

    1. The beginning of 7.3.1.2.1.11 says “Table 18. In some cases, this is not desirable. This default behavior may be modified using the @ignore_literal_names annotation.” It is unclear what exactly may not be desirable. Perhaps this was referring to the fact that enumerator names are used in the assignability check which indeed may be undesirable.

    2. There is no way for `@ignore_literal_names` to be encoded in TypeObjects which means they are not used during discovery and cannot be used in assignability checks.

    3. The text should clarify if this is an annotation that is only applied locally and/or applied to remotes.

  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 14:03 GMT
  • Updated: Fri, 25 Oct 2024 16:55 GMT

Table 29 description of is_write_protected

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The description of is_write_protected starts with "Indicates if read access". This should be "Indicates if write access."

  • Reported: DDS-SECURITY 1.1b1 — Thu, 31 May 2018 16:49 GMT
  • Updated: Fri, 18 Oct 2024 19:15 GMT

SecureSubmessageCategory_t in normative IDL

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The normative IDL doesn't have SecureSubmessageCategory_t, but it does have SecureSumessageCategory_t which appears to be a typo.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 18:51 GMT
  • Updated: Fri, 18 Oct 2024 18:54 GMT

Modify XSD to make the elements i version 1.2 optional

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    DDS Security 1.2 added two elements to the Governance XSD: enable_key_revision and rtps_psk_protection_kind.
    These elements were added without specifying a value for minOccurs which according the XSD rules it would default to 1. The result of this is that existing governance documents would not be valid according to the XSD. This was not the intent

    Instead the elements should have been added specifying minOccurs="0".

    This change impacts the machine-readable file omg_shared_ca_governance.xsd

  • Reported: DDS-SECURITY 1.2 — Mon, 7 Oct 2024 16:11 GMT
  • Updated: Mon, 7 Oct 2024 16:11 GMT

Support optional for union members, add exception

  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Would be useful to have support for @optional for union members. As IDL exceptions can be used through DDS-RPC also add exception members to this table, very likely to the ones that also are supported by structures

  • Reported: DDS-XTypes 1.3 — Wed, 11 Sep 2024 13:29 GMT
  • Updated: Fri, 27 Sep 2024 18:23 GMT

Wrong type name used: VehiclePositionType

  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    In the spec this section reads:

    7.2.1.1 Type Evolution Example

    Assume a DDS-based distributed application has been developed that uses the Topic “Vehicle
    Location” of type VehicleLocationType. The type VehiclePositionType itself was defined
    using the following IDL:

    (quote)
    // Initial Version
    struct VehicleLocationType {
    (quote)

    VehiclePositionType in the second sentence should be replaced with VehicleLocationType

  • Reported: DDS-XTypes 1.3 — Fri, 13 Sep 2024 17:04 GMT
  • Updated: Fri, 27 Sep 2024 14:01 GMT

Inconsistent specification of where annotations can apply

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification is not consistent regarding which elements can be annotated. Specifically regarding typedef declartions.

    Section 7.2.2.6 "Annotations" says:
    "An annotation describes a piece of metadata attached to a type or an element/member/literal of an aggregated/collection/enumerated type. Annotations can also be attached to the related_type of an alias type."

    However
    section 7.3.1.2.1 (Built-in Annotations) says:

    In IDL, an annotation may be applied to any construct or sub-construct
    (see Sub Clause 7.4.15.2, [IDL]). This specification restricts the applicability of annotations to constructed types, bitmask constants, enumerated type literals, and members of aggregated types.

    I believe the intent all along was to allow annotations, such as @range and @unit in typedef. Also would be nice to align with whet IDL4 says.

    At a minimum in XTYPES we should remove the specification of where annotations apply from section 7.3.1.2.1 and instead reference 7.2.2.6.

  • Reported: DDS-XTypes 1.3b1 — Tue, 17 Sep 2024 08:38 GMT
  • Updated: Tue, 17 Sep 2024 14:21 GMT

Clarify behavior of @range and @unit with respect to type comptibility

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not state clearly if a writer and and reader that have types with incompatible values of @unit or @range should match?

    Also it is not clear as if both a complete TypeObject and a minimal TypeObject should be sent or just one and how it is decided.

    It would seem like.a good idea to allow application (DataReaders) to opt in or out of matching writers that have types with incompatible @range and/or @unit. If so mechanisms should be provided to configure this and make sure the complete TypeIdentifier is propagated in those cases as the corresponding TypeObject is the only one that has the information of @range and @unit.

  • Reported: DDS-XTypes 1.3b1 — Wed, 11 Sep 2024 15:37 GMT
  • Updated: Wed, 11 Sep 2024 15:37 GMT

Missing escaping rules for filter expression, topic expression, query expression

  • Key: DDS15-320
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification should specify how string parameters should be escaped when used withing a query string, for example a query_expression of "name = 'bar'", but what if bar is a string with a single quote, newline, tab, etc? The specification should specify the escaping rules for that.

  • Reported: DDS 1.4 — Thu, 4 Mar 2021 07:04 GMT
  • Updated: Fri, 6 Sep 2024 19:21 GMT

Typo fixes

  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    Pg 48 7.2.2.4.6 first sentence

    For each Aggergated Type "T" the type system defines a related [...]

    -> Aggregated


    Pg 48 7.2.2.4.6 first sentence

    [...] obtainied from "T" by removing the key designation

    -> obtained


    Pg 50 7.2.2.4.7 first sentence

    [...] obtainied from "T" as follows:

    -> obtained


    Pg 54 Figure 19 label at aggregation arrow to AnnotationParameter

    +paramter_seq

    -> +parameter_seq


    Pg 133 Table 38 4th row column meaning

    Conditionally swaps the bytes [...] matches the native Endianess

    -> Endianness


    Pg 146 continuation of 7.4.3.5.3 4th line from top

    // FMMEBER can be NOPT_FMEMBER [...]

    -> FMEMBER


    Pg 215 Table 60 4th column, header

    Endianess

    -> Endianness


    Pg 248 continuation of Annex A 2nd para from top

    <xs:simpleType name="autoIdKind">
      <xs:restriction base="xs:string">
        <xs:enumeration value="hash"/>
          <xs:enumeration value="sequencial"/>
    

    -> <xs:enumeration value="sequential"/>


    Pg 263 continuation of Annex B bottom of page

    // Flags that apply to type declarationa and DO affect assignability
    

    -> declarations


    Pg 266 continuation of Annex B 3rd para from top

    // Used for Types that have cyclic depencencies with other types
    

    -> dependencies


    Pg 268 continuation of Annex B approx 10 lines down

    // ============ Plain collectios - use TypeIdentifierKind =========
    

    -> collections

  • Reported: DDS-XTypes 1.3 — Tue, 20 Aug 2024 10:13 GMT
  • Updated: Wed, 4 Sep 2024 14:13 GMT

Misspellings of "aggregated"

  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    Pg 43 7.2.2.4.4.4.3 Member Index 2nd sentence

    [...] of the member within the Aggegated type.

    Pg 47 7.2.2.4.5 Inheritance of Aggregated Types 1st sentence

    The Type System supports single inheritance of Aggegated Types.

    Pg 49 continuation of 7.2.2.4.6 comment before union Command_TypeErased

    // The related KeyErased type definition only applies to aggegated types.

    Pg 51 continuation of 7.2.2.4.7 comment before union Command__KeyHolder

    // The related KeyHolder type definition only applies to aggegated types.

    On this last occurrence, is the double underscore in union Command__KeyHolder intentional?

  • Reported: DDS-XTypes 1.3 — Tue, 20 Aug 2024 09:14 GMT
  • Updated: Wed, 4 Sep 2024 14:12 GMT

Inheritance rule regarding keys is overly restrictive

  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    The Resolution Summary of DDSXTY13-23 states:

    Structure types can inherit from other structure types as long as:

    • [...]
    • The derived type does not define any key fields.
      Is this really what we want to do. Will it break some definition where the "base type" is just being reused as a "header"?

    I propose to change the first sentence to

    • The derived type does not define any key fields if any of its ancestor types is non nested.

    This restores viability for the mentioned use case where the base type(s) are just being used as header(s).
    It hinges on the assumption that if all base types are nested then the question of assignability does not arise at the topic level.

  • Reported: DDS-XTypes 1.3 — Sun, 18 Aug 2024 09:43 GMT
  • Updated: Wed, 4 Sep 2024 14:03 GMT

Validation errors in JSON Schemas

  • Status: open  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    Some JSON schemas contain lack certain restrictions that are enforced in strict validations.

  • Reported: DDS-JSON 1.0 — Fri, 30 Aug 2024 11:58 GMT
  • Updated: Fri, 30 Aug 2024 11:58 GMT

Incorrect property names used

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section 10 and its subsections there are two properties that are named incorreclty in that a "." has been used instead of a "_". Specifically there are places in the section that use the names
    "rtps_psk.secret_passphrase" and "rtps_psk.symmetric_cipher_algorithm"

    These should be replaced with:
    "rtps_psk_secret_passphrase" and
    "rtps_psk_symmetric_cipher_algorithm"

    Which are the names that appear in the "Configuration Properties" tables in the "Property Name" column.

  • Reported: DDS-SECURITY 1.2 — Tue, 20 Aug 2024 00:48 GMT
  • Updated: Tue, 20 Aug 2024 00:48 GMT

Does @try_contruct(TRIM) leave strings with valid UTF-8 and UTF-16?

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    This is related to https://issues.omg.org/issues/DDSXTY14-13, and it might actually be covered by it, but I can't read into the comments at the moment to see if this specific issue was mentioned. As mentioned in 7.2.2.2.1, strings should be either UTF-8 or UTF-16. @try_construct(TRIM) can cause strings to be truncated. If they are truncated in the middle of a UTF-8 multi-byte code point or UTF-16 surrogate pair, then it would leave invalid data at the end of the string. Ideally an implementation could read trim the strings intelligently, but the spec should say what the behavior is.

  • Reported: DDS-XTypes 1.3 — Wed, 5 Jun 2024 18:19 GMT
  • Updated: Mon, 1 Jul 2024 15:12 GMT

create_sample can't indicate failure

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    As defined create_sample can only return the sample object. This doesn't allow the API to indicate that there was an error unlike other calls in DDS. Other operations either can't normally fail, return an interface that can be null, or return a ReturnCode_t. At least in the C++ Language Mapping, create_sample can return a struct or a union by value, so it can't be null in those cases (section 5.11). I imagine this might be different in other mappings though.

  • Reported: DDS-XTypes 1.3 — Wed, 5 Jun 2024 17:28 GMT
  • Updated: Mon, 1 Jul 2024 15:12 GMT

Operation: set_permissions_credential_and_token

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Section 8.3.2.11.11 has no description of the permissions_token parameter

  • Reported: DDS-SECURITY 1.1b1 — Fri, 6 Jul 2018 21:42 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Builtin Auth dependency on Access Control details

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    (This may be a moot point depending on the resolution of DDSSEC12-13.)

    The row of Table 52 that describes validate_local_identity states that the QoS it receives must contain the properties defined in section 9.3.1. These properties are the ones starting with dds.sec.auth.

    The problem is that for begin_handshake_* (either variant) to work, validate_local_identity must also receive the property dds.sec.access.permissions. This should be noted in the requirements for validate_local_identity: it must store the QoS, or at least this property, in a location that can be looked up by IdentityHandle so that handshake tokens can be created. Alternatively, the begin_handshake_* operations could be extended to receive this info separately.

    Another connection between the two plugins is made by the PermissionsCredentialToken. If the intent is to use this data when generating handshake handles, that should be noted in tables 49-50 (c.perm) instead of referencing QoS policies there.

  • Reported: DDS-SECURITY 1.1b1 — Mon, 23 Jul 2018 16:19 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Misleading description of Crypto Key Exchange (8.5.1.8)

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Section 8.8.9 specifies that when the crypto tokens are sent on the network,
    BuiltinParticipantVolatileMessageSecureWriter is used so they are not sent in the clear. This detail is also described in 8.5.1.8.1 and other parts of 8.5.1.8.

    Section 8.5.1.8.1 (2nd pgh) contains
    ...intended for transmission in "clear text" to the remote...
    which contradicts 8.8.9.

    To resolve this issue, remove a few unnecessary parts of 8.5.1.8:

    • 8.5.1.8.1 2nd sentence of 2nd pgh "The returned CryptoToken sequence is intended..."
    • 8.5.1.8.2 latter half of 2nd pgh starting "The CryptoToken sequence may contain..."
    • 8.5.1.8.4 (similar content to 8.5.1.8.2)
    • 8.5.1.8.6 (similar content to 8.5.1.8.2)
  • Reported: DDS-SECURITY 1.1b1 — Fri, 13 Jul 2018 17:02 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Add explanation of how to use the secureWriterSet to support GROUP ordered access

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    RTPS 2.4 added support for GROUP ordered access and coherent access. Part of this work added fields to the heartbeat submessage, one of which is a secureWriterSet.

    This field shall contain the 32-bit xxHash32 of all of the writer EntityIds that are sent via secure discovery.

    The use of this field should be mentioned somewhere in the security spec as the RTPS spec refers to the security specification to define the use of this field.

    A new inline QoS was also added: PID_SECURE_WRITER_GROUP_INFO. This inline QoS should also be added to the security spec.

    See the revised RTPS text here: DDSIRTP23-117

  • Reported: DDS-SECURITY 1.1b1 — Fri, 20 Jul 2018 16:44 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

validate_remote_permissions interaction with Authentication Plugin

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Table 63's entry for validate_remote_permissions describes a required interaction with the authentication plugin in order to obtain an AuthenticatedPeerCredentialToken. This appears to be an artifact of a previous spec revision, since the current API for validate_remote_permissions already provides the AuthenticatedPeerCredentialToken.

    So that validate_remote_permissions makes more sense, remove the auth_plugin and remote_identity_handle parameters (Table 32, section 8.4.2.9.2, Table 63, IDL).

  • Reported: DDS-SECURITY 1.1b1 — Fri, 6 Jul 2018 21:56 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Inconsistent descriptions of Data Tagging

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Section 8.7 specifies the optional Data Tagging model, but the details of how this works really reside in the Access Control plugin. Sections 1.2 and 2.3 need to be updated to remove references to a Data Tagging "Plugin." Also update section 8.1.1. For clarity, update section 8.7.2 to add a reference to Access Control.

  • Reported: DDS-SECURITY 1.1b1 — Mon, 6 Aug 2018 16:58 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

get_topic_sec_attributes 3rd parameter type

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In the IDL get_topic_sec_attributes's 3rd parameter has type TopicSecurityAttributes. In table 32 it appears as EndpointSecurityAttributes which seems to be an error.

    Also Figure 10 calls this method get_topic_security_attributes instead of using "sec".

  • Reported: DDS-SECURITY 1.1b1 — Fri, 6 Jul 2018 21:47 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

IDL struct ParticipantSecurityAttributes contains ac_endpoint_properties

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The name of field ac_endpoint_properties in ParticipantSecurityAttributes should be ac_participant_properties as specified in Table 27.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Jul 2018 16:47 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

serialized_local_participant_data passed to Auth plugin

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    When the middleware calls Auth plugin operations begin_handshake_request and begin_handshake_reply, it must provide serialized_local_participant_data as an OctetSeq according to serialization rules described in 8.3.2.11.4-5. However, these sections do not specify that padding bytes in the serialized data should be initialized to 0. This is desirable so that the OctetSeq can be hashed with consistent results.

    Alternatively, revisit the choice to use OctetSeq here in the plugin API. It seems like it would be fine to pass the structure ParticipantBuiltInTopicDataSecure directly to the plugin, as is already done with Access Control.

  • Reported: DDS-SECURITY 1.1b1 — Thu, 9 Aug 2018 16:01 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

class_id string in Authentication/Permissions Tokens should include spec version

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The class_id attribute in various Tokens includes the Plugin Name and a version number. The intention was that the version number would track the specification version so that it could be used to understand the format of the Token.

    However this is not done consistently. Currently the following class_id are used:

    token class_id
    IdentityToken "DDS:Auth:PKI-DH:1.0"
    AuthenticatedPeerCredentialToken "DDS:Auth:PKI-DH:1.0"
    AuthRequestMessageToken "DDS:Auth:PKI-DH:1.0+AuthReq"
    HandshakeRequestMessageToken "DDS:Auth:PKI-DH:1.0+Req"
    HandshakeReplyMessageToken "DDS:Auth:PKI-DH:1.0+Reply"
    HandshakeFinalMessageToken "DDS:Auth:PKI-DH:1.0+Final”
    PermissionsToken "DDS:Access:Permissions:1.0"
    PermissionsCredentialToken "DDS:Access:PermissionsCredential"
    CryptoToken "DDS:Crypto:AES_GCM_GMAC"

    As it can be seen some class_ids are missing the version number. The ones that have it use "1.0" instead of "1.1" which is the version of the spec. Finally when there are multiple tokens with the same class ID a suffix preceded by a "+" is uses to differentiate them, but this is not done in all cases.

    The goal of this issue is to correct this irregularities. So DDS Security version 1.2 should modify the Token as follows:

    token class_id
    IdentityToken "DDS:Auth:PKI-DH:1.2"
    AuthenticatedPeerCredentialToken "DDS:Auth:PKI-DH:1.2+AuthPeer"
    AuthRequestMessageToken "DDS:Auth:PKI-DH:1.2+AuthReq"
    HandshakeRequestMessageToken "DDS:Auth:PKI-DH:1.2+Req"
    HandshakeReplyMessageToken "DDS:Auth:PKI-DH:1.2+Reply"
    HandshakeFinalMessageToken "DDS:Auth:PKI-DH:1.2+Final”
    PermissionsToken "DDS:Access:Permissions:1.2"
    PermissionsCredentialToken "DDS:Access:Permissions:1.2+Cred"
    CryptoToken "DDS:Crypto:AES_GCM_GMAC:1.2"

    Note that this change is not intended to break backwards interoperability. So the proposal could/should be adjusted to ensure that. Specifically the change in the name for the PermissionsCredentialToken should not impact interoperability as this token is not exchanged between participants. The same is true for the addition of the "+AuthPeer" to the AuthenticatedPeerCredentialToken.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 17 Dec 2019 00:26 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Authentication Protocol: Make what is validated in the messages more explicit

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Builtin Authentication Protocol described in 9.3.4.2 'Protocol description' as well as in Table 52 'Actions undertaken by the operations of the builtin Authentication plugin' should be more explicit about how each of the protocol messages is validated.

    Specifically it should prescribe that:

    • Participant_A shall check the fields inside HandshakeReplyMessageToken and ensure that {Challenge1, Hash(C1), DH1}

      match what Participant A sent in the HandshakeRequestMessageToken.

    • Participant_B shall check the fields inside HandshakeFinalMessageToken and ensure that {Hash(C1), Hash(C2), DH1, DH2, Challenge1, Challenge2}

      match what Participant B sent in the HandshakeRequestMessageToken.

    This should be made clear both in 9.3.4.2 'Protocol description' and in Table 52 'Actions undertaken by the operations of the builtin Authentication plugin'.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 6 Aug 2019 17:13 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Add support for ChaCha20

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The AES-CCM cypher suite used by the built-in authentication plugins is well suited for higher end processors that have hardware support for AES (e.g. the Intel AES-NI instructions and the the AES instructions in ARMv8).

    ARMv7 and other low-end processors don't have hardware support. In these AES can be quite slow.

    To better support lower end processors it would be good to add support for a cypher suite that has reasonable performance without hardware support. The industry seems to be converging around the ChaCha20. See:

    https://tools.ietf.org/html/rfc8439
    https://tools.ietf.org/html/rfc7905

    Gerardo

  • Reported: DDS-SECURITY 1.1b1 — Sat, 16 Mar 2019 05:31 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Multiple grants in a permissions document

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    There is only one <permissions> element in a permissions document, but it can contain multiple <grant> elements. Section 9.4.1.3.2.1 states "Each subject name can only appear in a single <permissions> Section"... which should be "single <grant> Section" and "A permissions Section with a subject name that doesn't match" should be "A grant Section with a subject name that doesn't match."

  • Reported: DDS-SECURITY 1.1b1 — Mon, 20 Aug 2018 15:41 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Invalid IETF RFC document reference.

  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The "Domain Governance Document" and "DomainParticipant permissions document" chapters contain references to "IETF RFC 5761". This doesn't seem correct.

    It seems that it should be "IETF RFC 2633". At least then the mentioned RFC sections fit.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 4 Sep 2018 10:56 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Protecting the Source Timestamp

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently the INFO_SOURCE can only be protected by RTPS protection. This makes anyone on the Domain able to modify it. Moreover it must be left unprotected when communicating with unsecured participants.

    It would be better if it was included into the DATA / DATA_FRAG submessge as an inlineQos

  • Reported: DDS-SECURITY 1.1b1 — Fri, 27 Jul 2018 12:32 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

IDL should be updated to match IDL 4.2

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The IDL used by the specification should be updated to the latest IDL 4.2 syntax.

    This specially impacts annotations. For example @Extensibility(MUTABLE_EXTENSIBILITY) has been replace with @mutable.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 29 Aug 2018 00:44 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

The Qos used to publish the BuiltinLoggingTopic is not specicified

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 9.6 'Builtin Logging Plugin' should specify the Qos used to publish and subscribe to the BuiltinLoggingTopic, similar to how it is done for other builtin topics introduced by DDS-Security.

    See for example how it is done for the DCPSParticipantMessageSecure builtin Topic (section 7.4.2) where it refers to the Qos of other builtin Topics and also how it is done for the TopicBuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader (section 7.4.4.2 ) where it defines it explicitly.

  • Reported: DDS-SECURITY 1.1b1 — Thu, 26 Mar 2020 16:48 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

encode_rtps_message/decode_rtps_message error and status reporting

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    8.5.1.9.4 (4th pgh) describes that encode_rtps_message may determine that no encoding is necessary. This is currently an awkward fit with the common API design of returning a boolean and "setting" or "not setting" an exception struct. What does "not setting" the exception struct mean in practice? How does an implementation portably handle this?

    It would be better to have an enum or integer return type so that the plugin can more directly influence the implementation's control flow, with distinct return values for OK_ENCODED, OK_NOT_ENCODED, ERROR, possibly others.

    A similar issue occurs with decode_rtps_message (8.5.1.9.5). Because key exchange happens asynchronously with respect to encoded message transmission, the plugin may not be able to decode a given message. Simply "returning an exception" in this case is not ideal since the calling code should probably log this exception and it may raise alarms.

    Extending this idea of enum (or integer constants) return types instead of boolean to other CryptoTransform operations may also be useful. For example, the other encode operations could return a OK_NOT_ENCODED instead of copying data.

  • Reported: DDS-SECURITY 1.1 — Tue, 17 Sep 2019 21:53 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Size of permission file sent on authentication can exceed max IP packet size

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Permission File is an XML file. The signature is also encoded as text. For large systems with a lot of Topics the size can grow to be quite big. This is amplified by the fact that it is possible and convenient to combine the permissions of multiple participants into a single file. This size can exceed the 64KB max size of IP.

    An additional problem is that the permissions file is sent during the authentication handshake. The authentication handshake uses a special "best efforts stateless" that does not support fragmentation of large packets. This is done on purpose to make the channel to be robust to sequence number attacks but it results on the inability to send these large permission files.

    This could be addressed by separating the permissions from the authentication handshake and there is already an issue filed for this, see DDSSEC12-13.

    However there is a simple solution that can make the current approach more scalable. The proposed approach is to send the Permissions document compressed rather than in their current text form.

    Users are already hitting this limit so this issue requests that capability to send the permissions compressed is added with high priority, even if later a more general solution is developed as requested in DDSSEC12-13.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 1 Sep 2020 17:50 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Provide efficient way to skip encrypted implementation-specific content

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The RTPS specification allows implementations to send implementation-specific RTPS sub-messages inside an RTPS message. These submessages are distinguished by having submessageId's within a specific range.

    Prior to DDS security skipping implementation-specific RTPS sub-messages was very efficient requiring only the receiver to jump their length indicated in. the header.
    However with DDS security the submessages can be encrypted inside a SRTPS_PREFIX/SUFFIX envelope this requires the receiver to always decrypt them even if it will end up skipping them.
    An extreme, but likely common case is when the SRTPS_PREFIX/SUFFIX contains exclusively implementation-specific RTPS sub-messages which makes the effort to decrypt the RTPS message fruitless.

    A way to resolve this would be to designate a flag in the SRTPA_PREFIX submessage to indicate that the content contains only vendor-specific submessages. A receiver can use this flag to skip the whole RTPS message avoiding the effort to decrypt i n the event that the sender vendorId does not match the receiver's.

    The proposal therefore is to designate the leftmost flag of the SRTPS_PREFIX submessage to indicate it contains only "vendor specific content".

  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Jun 2023 04:35 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Add return_permissions_handle to the AccessControl interface

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Handles that are allocated by plugins need to have a "return" operation so that the memory used by the plugin can be freed when the handle is no longer needed by the middleware.

    boolean return_permissions_handle(in PermissionsHandle handle,
      inout SecurityException ex);
    
  • Reported: DDS-SECURITY 1.1 — Thu, 1 Oct 2020 16:12 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Update parameters of check_remote_datawriter_register_instance

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    check_remote_datawriter_register_instance defined in 8.4.2.9.15 has these parameters: permissions_handle, reader, publication_handle, key, exception.

    In the IDL file and Table 32 in 8.4.2.9 there's also an instance_handle parameter, which should be removed.

  • Reported: DDS-SECURITY 1.1 — Fri, 24 Jun 2022 19:50 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Builtin Access Control operations (Table 63) missing entries

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The operations get_topic_sec_attributes, get_datareader_sec_attributes and get_datawriter_sec_attributes are missing from Table 63 - Actions undertaken by the operations of the bulitin AccessControl plugin.

  • Reported: DDS-SECURITY 1.1 — Mon, 27 Aug 2018 22:12 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Add best practice/implementation guidelines to the CryptoTransform plugin


Provide a way for multiple vendors to extend the algorithms and interoperate

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification provides mechanisms to extend the set of cryptographic algorithms in future revisions.
    The specification also provides mechanisms to extend the set of cryptographic algorithms by a single vendor without requiring a revision of the standard. Those extended algorithms will be understood by the vendor and ignored by others.
    What is not clear is if two vendors can agree to use another cryptographic algorithm and interoperate. This use-case may be relevant to an end-user that is using multiple vendors and wants to have those vendors work together to use a new crypto algorithm

    This issue requests some mechanism to support this last use case.

  • Reported: DDS-SECURITY 1.1b1 — Fri, 30 Jun 2023 16:34 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Problematic use of multiple INFO_SRC within an RTPS

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The RTPS spec allows a single RTPS message to contain multiple INFO_SRC submessages, effectively changing the Participant GUID of the sending Participant.

    This seems problematic for DDS Security since the cryptograophic material is tied to that Participant GUID (e.g. the RTPS protection).
    Also INFO_SRC does not work well with the new RTPS_HEADER_EXTENSION.

    How commonly is this capability used? It is worth finding a way to make DDS-Security work with it or would it be better to disallow it.

    Should it be disallowed just for DDS-Security or for DDS in general?

  • Reported: DDS-SECURITY 1.1b1 — Wed, 27 Sep 2023 13:24 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Parsing messages generated by encode_serialized_payload (auth only)

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    When "performing authentication only," the encode_serialized_payload operation wraps the SerializedPayload inside CryptoHeader and CryptoFooter. This resulting byte stream takes the place of the original SerializedPayload submessage element in a Data(Frag) submessage.

    On the receiving side, this modified submessage element is passed to decode_serialized_payload. The problem comes in parsing this CryptoHeader-SeralizedPayload-CryptoFooter group.

    The CryptoHeader is of fixed size and only contains octet-width data (therefore has no padding), so parsing it and determining where SerializedPaylod starts is trivial.

    Then the implementation needs to determine where SerializedPayload ends in order to determine which bytes to authenticate. There is no in-stream indication of where the SerializePayload ends.

    One possibility would be to look at the end of the byte sequence that decode_serialized_payload received and "step backwards" by the length of the CryptoFooter, however the CryptoFooter is variable length (with receiver_specific_macs). Even if the implementation has external knowledge that receiver_specific_macs are not in use, the alignment requirement of the plugin_sec_tag.receiver_specific_macs.length effectively makes this a variable-length element (also see issue #58).

    To resolve this, an additional element for "length" could be added before the SerializedPayload, just like the CryptoContent submessage element does. This would make parsing the encoded payload similar for the encrypt and auth-only cases.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 9 May 2018 15:38 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

check_remote_topic domainId parameter

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    domainId is not listed in section 8.4.2.9.12

  • Reported: DDS-SECURITY 1.1b1 — Thu, 10 May 2018 15:06 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

AES-GCM doesn't add padding

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In 9.5.3.3.4.2 remove this part:
    "Note that the cipher operations have 16-byte block-size and add padding when needed. Therefore the secure data.length (“N”) will always be a multiple of 16."

    AES-GCM doesn't add padding. The implication of this is that the CryptoContent Submessage Element may end at an arbitrary point in the stream (from the point of view of alignment). Bringing the stream "back into alignment" will depend on the usage context:

    • When encoding payload, the CryptoFooter follows directly after CryptoContent. This means that CryptoFooter's first element (common_mac) may start unaligned. Then receiver_specific_macs.length appears in the stream as a 32-bit value so it will be preceded by 0-3 padding bytes depending on the length of CryptoContent.
    • When encoding a submessage or full message, CryptoContent is followed by the start of another submessage which must be aligned to 4 per the RTPS spec.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 1 May 2018 15:10 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Builtin Crypto message authentication codes

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    9.5.3.3.6 "The message digest is computed on the crypto_header and the ciphertext."

    This statement appears to contradict the descriptions of common_mac and receiver_specific_macs in 9.5.3.3.4.4 (payload), 9.5.3.3.4.5 (submessage), and 9.5.3.3.4.6 (message).

  • Reported: DDS-SECURITY 1.1b1 — Thu, 19 Apr 2018 20:58 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT


register_local_datareader and Data Protection Kind

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In the Table 70 row for register_local_datareader, the ReaderKeyMaterial is created based on Data Protection Kind. This should be Metadata Protection Kind because the ReaderKeyMaterial signs/encrypts submessages and not data payloads.

  • Reported: DDS-SECURITY 1.1b1 — Fri, 9 Mar 2018 20:51 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Replace "CryptoKeyTransform" with "CryptoTransform"

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The term CryptoKeyTransform is used 3 times (section name of 9.5.3.3, text of 9.5.3.3.1, caption of Table 72). These should be CryptoTransform.

  • Reported: DDS-SECURITY 1.1b1 — Fri, 9 Mar 2018 21:19 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Clarify the configuration and use of certificate chains for Identity

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 9.3.1.3 (Identity Certificate) indicates it is possible to use certificate chains.

    However the language of this section is confusing because an X.509 v3 Certificate does not contain a chain. It is a single certificate. What can contain a chain of certificates is a file. E.g. the standard "PEM" file format referenced in Table 44 can contain a certificate chain.

    To clarify this the following modifications are suggested:
    (1) In table 44, row for "identity_certificate" change from:
    "URI to a X509 certificate signed by the IdentityCA in PEM format"...
    To
    "URI to a X509 certificate (or certificate chain) signed by the IdentityCA, either as the root CA or as an intermediate CA, in PEM format"

    (2) In section 9.3.1.3 change from:
    "An X.509 v3 Certificate [39] that chains up to the Identity CA (see 9.3.1.1)."
    To:
    "A X.509 v3 Certificate chain [39] that is signed by the Identity CA (see 9.3.1.1) either as the root or as an intermediate CA in the chain"

    (3) In section 9.3
    In bullet 3. Clarify it may not be a single X.509 rather it can be a chain.

    (4) In table 49, field "c.id" indicate this is not a single certificate but a certificate chain. As that is what was configured in the PropertyQosPolicy.

    (5) In table 50, field "c.id" indicate this is not a single certificate but a certificate chain. As that is what was configured in the PropertyQosPolicy.

    (5) In table 52, field "validate_local_identity" indicate this is not a single certificate but a certificate chain.

    (6) In Table 53 IdentityCertificate is undefined. Maybe it should be "identity_certificate" and refer to the property defined in Table 44.

  • Reported: DDS-SECURITY 1.1b1 — Mon, 9 Apr 2018 23:56 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Builtin CryptoKeyFactory direct dependency on AccessControl's config details

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The behavior of the built-in CryptoKeyFactory operations is described in Table 70. Many entries of this table include direct references to details of the built-in Access Control plugin's configuration file (an example, "see 9.4.1.2.5.6").

    It would be easier to follow and more modular if this was changed to instead reference the data structure that the CryptoKeyFactory can actually see, which in this case is ParticipantSecurityAttributes.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 16:41 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Inconsistent Flag Name PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_BUILTIN_IS_DISCOVERY_ENCRYPTED

  • Status: open  
  • Source: OCI ( Tim Simpson)
  • Summary:

    All the other flag names defined here take the form of "PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_IS_XXX_YYY". Should the BUILTIN part of this flag really be there? I believe this should instead read: PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_IS_DISCOVERY_ENCRYPTED.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 14 Feb 2018 22:02 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Participant2ParticipantKxKeyMaterial

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Table 70 introduces the term "Participant2ParticipantKxKeyMaterial" which isn't used anywhere else in the spec.

    It would be helpful to have a table that lists each "key material" object along with which operation creates it and how it's used.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 16:45 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

9.5.3.3.4.3 should refer to the footer, not header

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The last paragraph of 9.5.3.3.4.3 refers to the "CryptoHeader", this should be "CryptoFooter"

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 16:48 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

"atributes" typo

  • Status: open  
  • Source: OCI ( Tim Simpson)
  • Summary:

    participant_security_attributes is currently spelled participant_security_atributes on page 25 of the specification.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 14 Feb 2018 21:57 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Modify Security's QoS changes for compatibility with RTPS

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Section 7.2.5 changes QoS in ways that break RTPS compatibility, however minor modifications can fix this.

    Because the mapping for PropertyQosPolicy in Table 10 (is this an implied entry in Table 12 as well?) conflicts with RTPS's definition of PID 0x59, the Binary Property values may not be sent on the wire. Note that RTPS has no concept of appendable extensibility, and requires backwards compatibility for all 2.x versions.

    We can represent this restriction on PropertyQosPolicy in IDL4:

    @extensibility(FINAL)
    struct PropertyQosPolicy {
      PropertySeq value;
    
      @non-serialized
      BinaryPropertySeq binary_value;
    };
    

    The practical effect of this change is that any BinaryProperty entry with propagate == TRUE is not actually propagated inside PropertyQosPolicy. However a search through the specification indicates that there is no requirement for this, at least for built-in plugins. Any other plugins are necessarily vendor specific so those are not necessarily restricted from using an appendable policy, as long as they are aware of the compatibility issues (for allow_unauthenticated_participants == TRUE).

    Also, for consistency the Tag and DataTags structs could be made @extensibility(FINAL). This is not as important since only Security-aware implementations will know about DataTagQosPolicy.

  • Reported: DDS-SECURITY 1.1b1 — Mon, 19 Feb 2018 23:37 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

IDL ParticipantSecurityAttributes::plugin_participant_attributes

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In the normative IDL, the struct ParticipantSecurityAttributes's field plugin_participant_attributes has type ParticipantSecurityAttributesMask but it should have type PluginParticipantSecurityAttributesMask

  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Mar 2018 21:33 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Reduce the range of Reserved RTPS parameter IDs

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.4.1.3 'Reserved RTPS parameter IDs' reserves the whole 0x1000 to 0x1FFF (plus 0x5000 to 0x5FFF for must-understand) . That is 2 x 4096 PIDs. In reality DDS security only uses 6 PIDs... So this is a bit too much of a land grab.

    It would be better to be more conservative and reserve a smaller range which can then be expanded as needed.

    RTPS version 2.4 states that the reserved range for DDS security is 0x1000 to 0x10FF and 0x5000 to 0x50FF.

    Section 7.4.1.3 should be updated to reflect this reduced range.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 6 Mar 2018 23:34 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Return types in CryptoKeyFactory interface description

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In CryptoKeyFactory, all operations other than the unregister_* ones return handles. But the descriptions of register_matched_remote_participant and register_local_datawriter (8.5.1.7.2-3) end with "operation returns false". That should be "operation returns HandleNIL".

  • Reported: DDS-SECURITY 1.1b1 — Thu, 1 Mar 2018 19:31 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

AuthRequestMessageToken future_challenge property

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In Table 48 (9.3.2.4), "properties" should be "binary_properties" so that the property future_challenge is treated as binary, matching Table 49's challenge1.

  • Reported: DDS-SECURITY 1.1b1 — Thu, 1 Mar 2018 19:02 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Various Typos

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Section 7.4.4.2 "TopicSecurityAtributes" should be "Attributes"

    Section 8.8.9.1, 8.8.9.2, and 8.8.9.3 "cripto" should be "crypto"

    Section 8.8.3 "best-efforts" should be "best-effort"

    Section 8.8.4 "simultanepusly" should be "simultaneously"

    Table 63 caption: "bulitin" should be "built-in"

    Section 9.5 "BEST_EFFORTS" should be "BEST_EFFORT"

    Section 9.5.2.3 "indentifier" should be "identifier"

    Section 9.5.3.1 "ciphetext' should be "ciphertext"

    Normative IDL parameter 1 of create_local_data_crypto_tokens "cryto" should be "crypto"

  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Mar 2018 17:02 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Broken cross-references

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    There are a few cross-references that don't resolve, resulting in the text "see 0" or "in subclause 0" in the spec:

    • Table 30 plugin_endpoint_attributes column 3 contains "found in 0"
    • Table 52 get_authenticated_peer_credential_token contains "See section 0"
    • 9.4.1.2.6.7 right before the bullet list
    • Table 63 validate_remote_permissions
    • 9.5.3.3.4.1 final paragraph has "subclause 0"
  • Reported: DDS-SECURITY 1.1b1 — Wed, 21 Feb 2018 16:11 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Security for DDS-RPC

  • Status: open   Implementation work Blocked
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    DDS security does not provide any additional means to secure the DDS-RPC service calls. Absent this the protection would be based on the underlying DDS Topics.

    DDS-RPC maps all operations of an interface to two unkeyed Topics. One for the request and one for the reply. The request Topic is used for all operations and likewise the reply Topic.

    Thus relying on the underlying Topics would provide access control granularity at the level of the service and not allow to give narrower permissions. E.g. invoke certain operations and not others. This is not acceptable in some deployment situations.

    One solution may be to make the Topics keyed by the operation. This is possible now that IDL42 allows the discriminator of a union to act as the key.

    Alternatively DDS-Security could specify some other mechanism, for example designate a data-tag to indicate the operations that the request DataWriter may invoke. The receiver side would check that the operation invoked matches the DataWriter tag before processing the request.

  • Reported: DDS-SECURITY 1.1b1 — Sun, 11 Feb 2018 07:43 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Authentication behavior use of built-in endpoints

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In section 8.8.2.2, it's established that the BuiltinParticipantStatelessMessage built-in endpoints are used for exchanging the "authentication handshake" messages. This makes sense based on how those built-in endpoints are defined in 7.4.3 and how they're used in some parts of 8.3.2.9 and .11.

    However there are parts of 8.3.2.11 and 8.8.2 that describe this handshake using the names BuiltinParticipantMessageWriter / Reader (note the absence of "Stateless"). The name BuiltinParticipantMessageWriter is defined by the RTPS spec as the endpoint used to implement the participant scoped liveliness (see RTPS 2.2 section 8.4.13.2).

  • Reported: DDS-SECURITY 1.1b1 — Wed, 14 Feb 2018 21:41 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Use a submessage flag to indicate Data/Frag submessage has a transformed payload

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    If the crypto plugin transforms the payload but the layers containing the payload (submessage or message) are not transformed, the resulting Data/Frag submessage contains no indication that its payload has a nonstandard format.
    Since this spec is essentially defining a new minor version of RTPS (along with RTPS RTF process concurrent to this), one of the reserved flags in the submessage header of Data/Frag can be defined as FLAG_S meaning that the format of the SerializedPayload submessage element is defined by the security spec.

  • Reported: DDS-SECURITY 1.1b1 — Thu, 15 Feb 2018 19:38 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Wrong XML tag in description of Enable Read Access Control

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    9.4.1.2.6.4 describes Enable Read Access Control, however the bullet list within this section uses the xml tag <enable_write_access_control> (twice), it should be <enable_read_access_control>.

  • Reported: DDS-SECURITY 1.1b1 — Fri, 16 Feb 2018 22:33 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Description of the PluginEndpointSecurityAttributes

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The rows in Table 61 is_submessage_encrypted and is_payload_encrypted each have paragraphs starting "If is_*_encrypted is FALSE..." and including "GCM authenticated encryption", which should be "GMAC authentication transformation" like the corresponding rows of Table 59.

  • Reported: DDS-SECURITY 1.1b1 — Fri, 16 Feb 2018 23:06 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Description of the EndpointSecurityAttributes

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In Table 30, the entry for is_payload_protected says "If is_payload_protected is FALSE, then the CryptoKeyFactory, KeyExchange and CryptoTransform operations are called only if is_payload_protected is TRUE", but the last phrase should be "only if is_submessage_protected is TRUE".

  • Reported: DDS-SECURITY 1.1b1 — Fri, 16 Feb 2018 23:16 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

IDL get_topic_sec_attributes parameter typo

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    2nd parameter to get_topic_sec_attributes has type "String", should be "string".

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:07 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Determining when to use DCPSParticipantMessageSecure

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The last paragraph of 7.4.2 indicates that TopicSecurityAttributes::is_liveliness_protected is used to determine if a liveliness message should be sent using the new DCPSParticipantMessageSecure builtin endpoint or the old DCPSParticipantMessage builtin endpoint.

    However it is not clear which topic's TopicSecurityAttributes are to be used. The liveliness message essentially belongs to the participant and not any given topic (see RTPS v2.2 8.4.13.5). Should the security spec use ParticipantSecurityAttributes here instead?

  • Reported: DDS-SECURITY 1.1b1 — Thu, 1 Feb 2018 17:03 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

ParticipantStatelessMessage definition

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Section 7.4.3.2:

    The data type associated with these endpoints is ParticipantStatelessMessage defined
    below (see also 7.2.5):
    typedef ParticipantStatelessMessage ParticipantGenericMessage;

    Two issues:
    a. I don't see how this relates to 7.2.5, should that be 7.2.6?
    b. The typedef is backwards. Typedef declares a new name (second) from an existing type (first).

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:23 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

IDL SubscriptionBuiltinTopicDataSecure inheritance

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    SubscriptionBuiltinTopicDataSecure should inherit from SubscriptionBuiltinTopicData in the local module, not the one in the DDS:: module.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:10 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

8.4.2.9.24 section name typo

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Operation: get_datarwriter_sec_attributes
    should be
    Operation: get_datawriter_sec_attributes

  • Reported: DDS-SECURITY 1.1b1 — Fri, 9 Feb 2018 20:34 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Allow expressions to be used in the data-tag permissions

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The permissions document allow and deny rules contain a section for matching the data tags of the DataReader/DataWriter. The match is based on an exact match of the tag-name and tag-value.

    For consistency with the way we match the permissions for Topic and Partitions we should also allow an expression for the tag-value portion. This is only for the permission rule itself. Not for the DataTag QosPolicy.

    So to match the rule the DataTag name in the Qos must exactly match the name in the permissions document (no expressions here) and the DataTag value in the Qos should match (using fnmatch) the expression in the permissions document.

  • Reported: DDS-SECURITY 1.1 — Thu, 18 Jan 2018 23:24 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Authentication interface begin_handshake_reply()

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Normative IDL has no parameter handshake_message_in (from Table 23). It would be possible to use handshake_message_out to serve the purposes of "in" since it's an inout parameter in IDL, but is that the intention here?

  • Reported: DDS-SECURITY 1.1b1 — Wed, 10 Jan 2018 19:37 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

decode_datawriter_submessage uses "in" for SecurityException

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In the normative IDL interface CryptoTransform, the decode_datawriter_submessage operation uses the "in" parameter passing mode for SecurityException – should be "out" or "inout".

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 18:54 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

get_datawriter/reader_sec_attributes inconsistent IDL

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Table 32 (8.4.2.9) has a topic_name parameter for both get_datawriter_sec_attributes and get_datareader_sec_attributes, however this parameter is not present in the normative IDL.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 18:59 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Authentication interface set_permissions_credential_and_token

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In the normative IDL, the type of the 2nd parameter for set_permissions_credential_and_token is listed as PermissionsCredential but should PermissionsCredentialToken.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:04 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

IDL LongLongSeq unused

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    DDS::Security::LongLongSeq is not used so it should be removed from the normative IDL.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:06 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

DataHolder IDL inconsistent

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In 7.2.3.1, DataHolder is a struct annotated with @extensibility(APPENDABLE) and no optional fields.
    However in ptc/17-09-26 (normative IDL), DataHolder has no @extensibility annotation and two optional fields.

  • Reported: DDS-SECURITY 1.1b1 — Thu, 4 Jan 2018 21:38 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

The specification should not duplicate (copy) the machine readable XSD files

  • Key: DDSSEC13-8
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification contains full copies of the machine readable XSD files:

    • DDS Security Access Control Permissions XSD
    • DDS Security Access Control Governance XSD

    This causes problems as updates may not always be done consistently.

    Therefore it would be better if the specification removed this duplication and just referenced the external machine-readable files.

  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 09:30 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Section 3 (Normative References) should be updated and expanded

  • Key: DDSSEC13-7
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification depends on many other standards that appear referenced thought the specification and in Annex A (References) but do not appear in Section 3.

    Section 3 should be expanded to include the subset of those references that are used for normative behavior. [46], [47], and [52] are clear examples of references that should be moved to Section 3.

  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 07:02 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Avoid sending permissions as part of Authentication Handshake

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The authentication handshake requires participants to exchange their permission files. This is done as clear text.

    Visibility into the permissions file leaks information as to what the system Topic names are as well as what the application publishes and subscribes. This can be sensitive for some systems.

    Aside form this sending this document is potentially expensive as the knowledge could be available on a separate channel.

    The RTF should look share this information only with authenticated participants and possibly also avoid sending it if it is already known to the peer participant.

    Related this is the fact that permissions are "monolithic" of you need to add a permission to a Participant you need to create and sign a new document. Would be nice to have some way to grant/propagate incremental permissions. E.g. something that could be bundled into the propagation of the Endpoint discovery data itself.

  • Reported: DDS-SECURITY 1.1 — Sat, 18 Nov 2017 00:42 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Instance-Level access-control

  • Status: open   Implementation work Blocked
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Security plugin model supports being able to control access to each DDS Topic instance (instead of just controlling access to the DDS Topic). However the builtin plugin permission files do not provide a way to configure these permissions.

    This is important for many DDS-Security use-cases where each instance represents a different object and needs to separately indicate who has access to it. For example imaging a "CarPosition" topic that is used to publish the position of cars. Someone may be given permission to suscribe or publish its own car position, but not other cars. Likewise a manufactured or insurance company may be given permissions to the cars that they manage but not others.

  • Reported: DDS-SECURITY 1.1 — Fri, 17 Nov 2017 02:07 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

say explicitly that is_valid is set to zero if that is case

  • Status: open  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    At end of 2nd to last para document has (matching the errata):

    "sending the ParticipantSecurityInfo (the default value of zero has is_valid=0) or sending it with is_valid."

    It should probably be

    "sending the ParticipantSecurityInfo (the default value of zero has is_valid=0) or sending it with is_valid set to zero.”

  • Reported: DDS-SECURITY 1.1b1 — Tue, 31 Oct 2017 20:03 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Issues with the UML model used in the specification

  • Key: DDSSEC13-9
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The UML diagrams in the specification use UML stereotypes, such as <<discovery>>. However these are not documented anywhere in the specification nor do they appear in the XMI.

    Also the diagrams are non-standard UML in that they show superclasses in the top right corner. See for example Figure 10.

    These issues should be corrected.

  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 07:07 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Built-in Authentication and Cryptography plugins tied together by SharedSecretHandle implementation

  • Key: DDSSEC13-2
  • Status: open  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    An implementation of the built-in Cryptography plugin is not compatible with the local implementation of the built-in Authentication, unless it uses/understands the same type of SharedSecretHandle. (SharedSecretHandle is the interface defined at the architecture level.) Therefore, the two built-in plugins are tied together and you cannot replace one or another with any other implementation of the same built-in plugin.
    It is possible to make them independent in two possible ways (at least):

    1. Define a BuiltinSharedSecretHandle that extends SharedSecretHandle interface, and has 3 methods like this:
      • octet[] getChallenge1(): returns challenge1 from the authentication handshake
      • octet[] getChallenge2(): returns challenge2 from the authentication handshake
      • octet[] getSharedSecret(): returns the shared secret from the authentication handshake
    2. OR define a new type of Token (IDL structure) - e.g. HandshakeResultToken - for the final output of the Authentication handshake like this:
      • class_id DDS:Auth:PKI-DH:1.0+Result
      • binary_properties: challenge1, challenge2, SharedSecret

    In both cases, it would change the specs of the methods get_shared_secret() and return_shared_handle() of the Authentication plugin, section 9.3.3.

  • Reported: DDS-SECURITY 1.0b1 — Tue, 1 Mar 2016 17:36 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Examples of Wildcard permissions

  • Key: DDSSEC13-3
  • Status: open  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    It is not clear whether the Permissions XSD allows to express all kinds of wildcard permissions. Just to make sure we cover all cases, we should give examples of permissions XML that grant only...

    1. all permissions to any domain? ("all permissions" = join, pub/sub/relay to any topic/partition/data_tag, etc.)
    2. all permissions to a specific domain, e.g. domain 0?
    3. all permissions to all topics of domain 0? ("all permissions" = pub/sub/relay, etc.)
    4. all permissions to all partitions of domain 0?
    5. all permissions to a specific topic, e.g. "Circle1", of domain 0?
    6. all permissions to a specific partition, e.g. "P1", of domain 0?
    7. the permission to publish to any topic of domain 0? (but not subscribe/relay)
    8. the permission to publish to any partition of domain 0? (but not subscribe/relay)

    Such examples would be very useful in the spec as well.

  • Reported: DDS-SECURITY 1.0 — Tue, 11 Jul 2017 12:43 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT
  • Attachments:

The UML model should be cleaned up

  • Key: DDSSEC13-4
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    There are some issues with the UML model that should be improved. This came from the AB review of the RTF 1 report:

    ● SubmessageKind should be an Enumeration not a Class. And it’s missing its Literals. Tables 4,5 indicate Literals would include SEC_BODY, SEC_PREFIX, SEC_POSTFIX, SRTPS_PREFIX, SRTPS_POSTFIX
    ● SubmessageFlag is totally underspecified but probably should not be a PrimitiveType
    ● Likewise CryptoState. In fact there are far too many PrimitiveTypes, none of them documented, which should probably be Strings.

  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 17:53 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Remove Jira-issue related comments from machine-readable files

  • Key: DDSSEC13-5
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The machine-readable files have comments that trace their changes to the Jira issues that caused them. This hurts the use of the specification so they should be removed.

  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 10:24 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

The DDS-Security specification makes some modifications to the DDSI-RTPS protocol that should be taken into consideration

  • Key: DDSSEC13-6
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The following two sections in DDS-Security 1.1 affect future versions of DDSI-RTPS.

    The DDSI-RTPS should include language that makes sure future versions do not conflict with what DDS-Security and future revisions thereof may do.

    Specifically the following two sections of DDS-Security 1.1 should be taken into consideration

    7.3.6.1 Change to the RTPS minor version number
    Implementations of this specification shall set the RTPS protocol version number present in the RTPS Header. The RTPS Major version number shall be set to 2 and the RTPS Minor version number shall be set to 3. Future revisions of the DDS-RTPS specification shall take into consideration this fact.

    7.4.1.3 Reserved RTPS parameter IDs
    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.

  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 09:48 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Complexity of Authentication Plugin Model

  • Key: DDSSEC13-1
  • Legacy Issue Number: 19793
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The Authentication Plugin Model specifies a state machine to be implemented by the DDS middleware to manage the authentication of the remote Participants. The implementation of this state machine is complex because:

    • It is not specified when to call validate_remote_identity (for each received SPDP or only for the first received SPDP from a newly discovered Participant? What if a malicious Participant send a SPDP at first, usurping the GUID of a legit Participant?)
    • The handshake could be initiated from both sides at nearly the same time (nothing forbid this in §8.3)
    • There is no indication in the specification to tell how parallel handshakes between 2 Participants should interact
    • It is difficult to determine at which sense a received message belongs
    • In §8.3.2.8.1 it's specified that "The DDS security implementation shall pass to the AuthenticationPlugin any message received by the BuiltinParticipantStatelessMessageReader...". But there are states in the state machine where it's not specified how to pass those messages (e.g. when validate_remote_identity has not been called yet, and the state machine is not initialized)

    This results in quite complex code, and this is a weakness in a mechanism which needs to be very strong.

    Anyway, the state machine in the middleware is redundant with the one needed in the plugin. In addition, it has to deal with events where it doesn't know what is really going on. Only the plugin has the real information. Therefore, we think this middleware state machine is useless, add extra complexity which makes the authentication less robust, and consumes a lot of resources.

    Instead, we suggest to remove it and to change the mechanism to the following:

    • remove all the "_handshake" methods on the Authentication Plugin
    • add a treat_message method to the authentication plugin to handle any incoming authentication ParticipantStatelessMessage
    • add a send_message method to the authentication listener interface to tell the middleware to send an authentication ParticipantStatelessMessage
    • add a validated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is authenticated
    • add a invalidated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is not authenticated
    • once the authentication is initialised with validate_remote_identity, all the state machine is managed directly by the plugin which sends the appropriate messages and is given the received ones, until its decision is given to the DDS middleware through the authentication listener.

    This will provide the necessary functionality in a much simple, efficient and robust manner.

  • Reported: DDS-SECURITY 1.0b1 — Thu, 11 Jun 2015 04:00 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

writing error

  • Status: open   Implementation work Blocked
  • Source: Shanghai Action Technology Co., Ltd. ( Action Hao)
  • Summary:

    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

  • Reported: DDSI-RTPS 2.5 — Thu, 18 Apr 2024 10:36 GMT
  • Updated: Mon, 22 Apr 2024 15:53 GMT

Clarify the intended member ID of a union's discriminator

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Note: This issue was filed in RTF 3 by Idar Carlsen. As RTF3 is already close it is being copied into RTF4.


    // Unions with extensibility MUTABLE, version 2 encoding
    // see (22) for serialization of MMEMBER using version 2 encoding
    (27) XCDR[2] << {O : MUNION_TYPE} =
     XCDR
     << { DHEADER(O) : UInt32 }
     << { O.disc : MMEMBER }
     << { O.selected_member : MMEMBER }?
    

    The specification says the discriminator should be treated as an MMEMBER, but it is not clear what the member ID of the discriminator should be. This has caused interoperability issues as different vendors are using different IDs.

    In Kongsberg's implementation, we've been using 0 for the discriminant. The first member of the union has thus had the member ID 1 (assuming @autoid(SEQUENTIAL)).

  • Reported: DDS-XTypes 1.3b1 — Thu, 21 Mar 2024 03:51 GMT
  • Updated: Sat, 23 Mar 2024 14:23 GMT

Ambiguous definition and/or usage of PUSH(ORIGIN=0)

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Note: This issue was filed by Sam Nosenzo in RTF 3. As the RTF 3 is already close it has been copied to RTF4

    The description of PUSH states:
    ```
    Pushes the specified XCDR stream variable VARIABLE
    into the stack and sets the current value to <newvalue>.
    The notation <?> indicates that the new value can be
    chosen by the implementation.
    This action is reverted by the POP() operation
    ```
    However the first serialization rule that writes the HEADER calls

    `PUSH(ORIGIN=0)` after writing the ENCHEADER, even though it's already been set to 0 on initialization. PUSH(ORIGIN=0) is also called after writing PL_CDR headers. I'm confused as to what this is supposed to mean. Based off of the current definition of PUSH I would be lead to believe that it truly does set the origin equal to 0. However looking at it's usage I would think that PUSH(ORIGIN=0) should mean that the origin is reset to where the current offset is, and based of of what I've seen in PL_CDRv1 messages with 8 byte members, this has been a correct assumption.
    Another confusing element around the usage of PUSH is that I don't see POP used anywhere in the Serialization rules.

  • Reported: DDS-XTypes 1.3b1 — Thu, 21 Mar 2024 03:48 GMT
  • Updated: Thu, 21 Mar 2024 03:49 GMT

Clarify the intended member ID of a union's discriminator

  • Status: open  
  • Source: Kongsberg Defence & Aerospace ( Ms. Idar Carlsen)
  • Summary:
    // Unions with extensibility MUTABLE, version 2 encoding
    // see (22) for serialization of MMEMBER using version 2 encoding
    (27) XCDR[2] << {O : MUNION_TYPE} =
     XCDR
     << { DHEADER(O) : UInt32 }
     << { O.disc : MMEMBER }
     << { O.selected_member : MMEMBER }?
    

    The specification says the discriminator should be treated as an MMEMBER, but it is not clear what the member ID of the discriminator should be. This has caused interoperability issues as different vendors are using different IDs.

    In Kongsberg's implementation, we've been using 0 for the discriminant. The first member of the union has thus had the member ID 1 (assuming @autoid(SEQUENTIAL)).

  • Reported: DDS-XTypes 1.3 — Sun, 17 Mar 2024 17:45 GMT
  • Updated: Thu, 21 Mar 2024 03:43 GMT

Correct inconsistency on the URLs for the machine readable documents in the FTF2 report

  • Key: DDSWEB11-3
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The machine-readable file URLs on the
    FTF report (ptc/15-09-21) and FTF 2 convenience document
    (ptc/15-09-13) disagree.

    The correct ones are the ones used in the FTF 2 document because these are consistent which the reference schema files that appear in the XML files also included as part of the specification.

    If nothing is done the URLs on the cover of the report (ptc/15-09-21) take precedence over the ones in the FTF2 specification, so it is imperative to re-issue the report to correct this.

  • Reported: DDS-WEB 1.0 — Thu, 19 May 2016 00:40 GMT
  • Updated: Wed, 3 Jan 2024 20:38 GMT

XCDR2 serialization of sequences of non-primitive elements

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    When serializing a sequences of non-primitive elements, the XTYPES spec requires serializing a DHEADER ahead of serializing the number of elements and each element. This is rule (12)

    Arrays of non-primitive elements also serializing the DHEADER but not the number of elements. This is rule (9)

    I think it would make sense to modify or at least relax these rules.
    At a minimum arrays and sequeces of enumerated types and bitmask types should not have a DHEADER as it does not add information beyond what is available knowing the number of elements and size of each element. That it, they should behave as primitives (basically they are integers).

    Additionally it may be better to not have the DHEADER at all for sequences and arrays. Or at least for sequences or arrays whose elements are final.

    Basically the "extensibility" of the sequence is already handled by having the number of elements and having a DHEADER adds nothing and makes types that contain sequences of FINAL incompatible with XCDR1. This is a side-effect that we did not want or anticipate. Otherwise types that are constructed from only FINAL types would be compatible between XCDR1 and XCDR2 (except for 8-byte aligned types).

  • Reported: DDS-XTypes 1.3b1 — Wed, 4 May 2022 22:43 GMT
  • Updated: Fri, 15 Dec 2023 19:15 GMT

XCDR2 serialization of non-trivial maps

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This issue was raised by Idar Carlsen (Kongsberg Defence & Aerospace)

    In the X-Types 1.3 specification, under the “7.4.3.5.3 Complete Serialization Rules” section, it says that non-trivial maps should have a DHEADER when XCDR2 is used (rule 15). Notably, it only has the DHEADER – unlike the version 1 encoding, the size (in terms of numbers of entries) of the map is not serialized. This differs from how sequences are serialized, as they include the size as well. Is this correct, or should the size of the map also be serialized in addition to the DHEADER?

    It seems to me that some of the other DDS implementations include the size, even though the specification does not say so.

  • Reported: DDS-XTypes 1.3b1 — Tue, 5 Dec 2023 16:36 GMT
  • Updated: Wed, 6 Dec 2023 16:06 GMT

DDS::Time_t/Duration_t changes


DDS defines Time_t with seconds as long, this is 32bit. This will give an issue after 2038

  • Key: DDS15-13
  • Legacy Issue Number: 14166
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS defines Time_t with seconds as long, this is 32bit. This will give an issue after 2038, almost all operating systems are now defining time as 64bit, shouldn't DDS do the same?

    In addition, the the standard does not define the calendar time of Time_t at

    { sec = 0, nanosec = 0 }

    This is required in order to convert a Time_t to/from a system's native time (such the the type time_t on Unix systems which has the calendar start time 1970-01-01 00:00:00).

  • Reported: DDS 1.2 — Thu, 30 Jul 2009 04:00 GMT
  • Updated: Fri, 24 Nov 2023 07:59 GMT

Proper interpretation of Duration_t for negative values

  • Key: DDS15-331
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not fully define the meaning of a Duration_t when the second part is negative.

    struct Duration_t {
        long sec;
        unsigned long nanosec;
    };
    

    What is he interpretation of a value when sec <0?
    Does the nanosec part get interpreted to have the same sign?
    If so, then the number between 0 < x < -1 cannot be represented

    So the most logical way to interpret a negative value for the sec field appears to be:

    value = sec + nanosec 
    

    where sec can be positive or negative but nanosec is always positive.
    So the value of negative 1ms would be represented as:

    sec = -1
    nanosec = 999,000,000
    

    The specification should define the proper interpretation.

  • Reported: DDS 1.4 — Mon, 20 Nov 2023 21:13 GMT
  • Updated: Mon, 20 Nov 2023 21:13 GMT

Section contains a duplicate sentence from the next section.

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    Sections are:

    7.3.1.9 Map Types
    Map types as described in this specification are fully compatible with the IDL constructs of the
    same name defined in the Extended Data-Types Building Block of [IDL].
    Structures as defined by this specification are fully compatible with the IDL constructs of the
    same name.
    7.3.1.10 Structure Types
    Structures as described in this specification are fully compatible with the IDL constructs of the
    same name.

    "Structures as defined by..." is duplicated twice.

  • Reported: DDS-XTypes 1.3 — Fri, 1 Sep 2023 20:42 GMT
  • Updated: Fri, 8 Sep 2023 22:26 GMT

Ambiguous definition and/or usage of PUSH(ORIGIN=0)

  • Status: open  
  • Source: Foxglove Technologies Inc ( Sam Nosenzo)
  • Summary:

    The description of PUSH states:
    ```
    Pushes the specified XCDR stream variable VARIABLE
    into the stack and sets the current value to <newvalue>.
    The notation <?> indicates that the new value can be
    chosen by the implementation.
    This action is reverted by the POP() operation
    ```
    However the first serialization rule that writes the HEADER calls `PUSH(ORIGIN=0)` after writing the ENCHEADER, even though it's already been set to 0 on initialization. PUSH(ORIGIN=0) is also called after writing PL_CDR headers. I'm confused as to what this is supposed to mean. Based off of the current definition of PUSH I would be lead to believe that it truly does set the origin equal to 0. However looking at it's usage I would think that PUSH(ORIGIN=0) should mean that the origin is reset to where the current offset is, and based of of what I've seen in PL_CDRv1 messages with 8 byte members, this has been a correct assumption.
    Another confusing element around the usage of PUSH is that I don't see POP used anywhere in the Serialization rules.

  • Reported: DDS-XTypes 1.3 — Mon, 21 Aug 2023 18:44 GMT
  • Updated: Wed, 23 Aug 2023 20:18 GMT

How to describe the locator information in XML

  • Key: DDSXML11-4
  • Status: open   Implementation work Blocked
  • Source: Beijing Jingwei Hirain Technology Co., Ltd. ( Jun.Feng)
  • Summary:

    1. In the specification and xsd file,can not find that how to describe the locator information of the domain participant such as metatrafficUnicastLocator or defaultUnicastLocator.
    2. When the topicKind of a topic is WITH_KEY, how to describe the corresponding key-value information of the DateWriter in the "data_writer" part.
    3. If user can add some bolcks that user defined and if there are some rules?
    4. There are no "uint8" or "int8" in the the simpleType whose name is "allTypeKind" in the xsd file whose name is "dds-xml_type_definitions_nonamespace.xsd". But there are the definition in chapter "7.3.2.2 Basic Types" of the specification "Extensible and Dynamic Topic Types for DDS"(DDS-XTypes)

  • Reported: DDS-XML 1.0 — Mon, 21 Aug 2023 12:45 GMT
  • Updated: Wed, 23 Aug 2023 20:17 GMT

Extend InfoSource to contain RTPS HeaderExtension fields

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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

  • Reported: DDSI-RTPS 2.5 — Wed, 16 Aug 2023 23:00 GMT
  • Updated: Thu, 17 Aug 2023 04:06 GMT

Update IDL definition of union TypeIdentifier in Annex B to account for primitive types

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The union TypeIdentifier definitoon in Annex B contain several cases commended out. This is done because (per the comment in the IDL) union cases all have to have an associated member/value

    // All primitive types fall here.
    // Commented-out because Unions cannot have cases with no member.
    /*
    case TK_NONE:
    case TK_BOOLEAN:
    case TK_BYTE_TYPE:
    case TK_INT8_TYPE:
    case TK_INT16_TYPE:
    ...
    

    Since the union discriminator is an octet, it is possible to set it to the values shown in the comment (e.g. TK_INT8_TYPE) in this situation since the case member is not shown the discriminator will be set but no branch would be selected so there is no associated value.
    In other words, we can get the desired behavior of having the discriminator set but no value selected (so nothing beyond the discriminator is serialized), but we cannot express the expectation of all those cases in the IDL...

    This could be corrected in two ways:
    (1) We could use a enumerated value with @bit_bound(8) as the type of the discriminator instead of the octet. The list of literals would make it obvious what the expected values for the discriminator
    (2) We could keep the union discriminated by an octet and uncomment all the cases for the primitive types. Then we would need to add a "dummy" member so the case has an associated value, but we could mark it @non_serialized so it has no impact on the wire representation.

    It would seem that (1) is cleaner but (2) is less disruptive...

  • Reported: DDS-XTypes 1.3b1 — Sat, 12 Aug 2023 02:20 GMT
  • Updated: Wed, 16 Aug 2023 15:56 GMT

Clarify accessing discriminator of a DynamicData union

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    It's not clear how a user of a DynamicData object that represents a union gets the discriminator value. We derive the following:

    // see pgh 1 of 7.2.2.4.4.3 for use of "discriminator" as a magic string
    const MemberId id_disc = dyndata->get_member_id_by_name("discriminator"); 
    if (id_disc == MEMBER_ID_INVALID) { some error happened }
    // based on union_type_descriptor.discriminator_type->get_kind(), determine the type of the discriminator
    // in this example, let's say it's an IDL long
    int val;
    dyndata->get_int32_value(val, id_disc);
    

    It would be better for the spec to have a clearly defined way of getting a MemberId that represents the discriminator. It could be a new API in DynamicType or TypeDescriptor.

  • Reported: DDS-XTypes 1.3 — Mon, 8 Aug 2022 15:38 GMT
  • Updated: Mon, 14 Aug 2023 15:28 GMT

Specify how a discovery service could be used to bootstap discovery

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.5 — Wed, 7 Jun 2023 17:33 GMT
  • Updated: Wed, 7 Jun 2023 17:33 GMT

Data Representation for RTPS's Serialized Key

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    RTPS 2.3 section 9.4.5.3.1
    "D=0 and K=1 means that the serializedPayload SubmessageElement contains the serialized Key."

    XTypes section 7.4 "Data Representation" should define the rules for encoding an object of a type defined by the 7.2 "Type System" to a Key-only serialization.

    Using what's currently in the spec, there are two potential interpretations:

    a. follow all the encoding rules as for a full object (adding DHeader, EMHeader, etc.) but any part of that object that's not a key gets skipped, using 7.2.2.4.7 to determine what's a key

    b. use the rules in 7.6.8 (which are explicitly only for a KeyHash) to get a KeyHolder object and then encode that

  • Reported: DDS-XTypes 1.3 — Wed, 28 Oct 2020 19:43 GMT
  • Updated: Wed, 31 May 2023 09:23 GMT

SequenceNumberSet validity could be too strict

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.3 — Mon, 7 Jun 2021 22:55 GMT
  • Updated: Tue, 30 May 2023 22:53 GMT

Typos in DynamicData UML Diagrams

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    Both figures have get_member_id_by_index methods instead of get_member_id_at_index like the rest of the spec does.

  • Reported: DDS-XTypes 1.3 — Thu, 16 Mar 2023 05:38 GMT
  • Updated: Mon, 24 Apr 2023 18:25 GMT

Conflicting Order of Minimal Struct and Union Members in TypeObject

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    Section 7.3.4.5 specifies that all struct and union members in TypeObjects are to be ordered by member index/declaration order.

    •The elements in CompleteStructMemberSeq shall be ordered in increasing values of the member_index.
    •The elements in MinimalStructMemberSeq shall be ordered in increasing values of the member_index.
    •The elements in CompleteUnionMember shall be ordered in increasing values of the member_index.
    •The elements in MinimalUnionMember shall be ordered in increasing values of the member_index.

    There are comments in the IDL in front of the sequence typedefs for these members that also specify the order. The complete ones agree that they should be sorted by member index, but the minimal ones say they should be sorted by member id:

    // Ordered by common.member_id
    typedef sequence<MinimalStructMember> MinimalStructMemberSeq;
    ...
    // Ordered by MinimalUnionMember.common.member_id
    typedef sequence<MinimalUnionMember> MinimalUnionMemberSeq;

  • Reported: DDS-XTypes 1.3 — Wed, 29 Mar 2023 22:13 GMT
  • Updated: Wed, 5 Apr 2023 22:44 GMT

Should the TypeObject mark key members as must understand

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The spec states that @key members are always "must understand" does this mean that when represented in a TypeObject the member should also have the "must understand" flag set or is it enough with it being marked with the "key" flag as this would already imply its must understand nature?

    Either way it should not impact assignability but it would impact the TypeId computation.

  • Reported: DDS-XTypes 1.3b1 — Tue, 21 Mar 2023 15:27 GMT
  • Updated: Thu, 30 Mar 2023 18:23 GMT

Typo in DataRepresentationMask

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Typo, it says

    @posiiton(2) XCDR2

    but should say

    @position(2) XCDR2

  • Reported: DDS-XTypes 1.3 — Thu, 25 Mar 2021 07:54 GMT
  • Updated: Thu, 30 Mar 2023 18:21 GMT

DynamicData should be value type, not a reference type

  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The class DynamicData inherits from Reference, but this class shouldn't behave differently from any other topic-type T, which (including the built-in types) are always value types.

  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 13 Jul 2016 22:18 GMT
  • Updated: Wed, 29 Mar 2023 18:29 GMT

Encoding of TypeInformation in SEDP

  • Status: open  
  • Source: Kongsberg Defence & Aerospace ( Dr. Ornulf Staff)
  • Summary:

    The encoding of the TypeInformation member in the builtin topics should be explicitly specified. There is a normative comment on using XCDR2 for v1.3 types in the IDL, but this can be interpreted not to apply in the context of the builtin topics which are otherwise XCDR1.

  • Reported: DDS-XTypes 1.3 — Thu, 17 Jun 2021 13:04 GMT
  • Updated: Tue, 21 Mar 2023 15:39 GMT

Description on how to encode Participant GUID in dds::rpc::RequestHeader seems wrong

  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Section 7.6.3.3.4 states the following sentence on how to encode the Participant GUID into the dds::rpc::RequestHeader:

    The Service instanceName that appears in the dds::rpc::RequestHeader shall be set to the string obtained by concatenating the prefix “dds.builtin.TOS .” With the 16-character string version of the DomainParticipant GUID encoded using hexadecimal digits with lower case letters. There shall be no “0x” ahead of the hexadecimal digits. For example, “dds.builtin.TOS.123456789abcdf0”

    This seems to imply that you need to encode the Participant GUID as a 16 digit hexadedecimal string, which wouldn't allow you to represent the entire GUID. Probably the 16 bytes do no intend to refer to the hexadecimal digits of the string representation, but rather to the 16 bytes of the GUID itself. A couple of paragraphs further down it refers to the DDS-RPC spec, where indeed the 16 byte restriction is not mentioned:

    The dds::rpc::RequestHeader in the TypeLookup_Request and the TypeLookup_Reply shall be set as specified in the [DDS-RPC] specification.

  • Reported: DDS-XTypes 1.3b1 — Mon, 20 Dec 2021 16:09 GMT
  • Updated: Tue, 21 Mar 2023 15:36 GMT

Impossible to handle @must_understand AND @optional fields in an @appendable struct correctly

  • Status: open   Implementation work Blocked
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The XTypes spec seems to suggest that @must_understand fields are applicable to any non-final datatype. Section 7.3.1.2.1.9 mentions this:

    "By default, the assignment from an object of type T2 into an object of type T1 where T1 and T2 are non-final types will ignore any members in T2 that are not present in T1. This behavior may be changed by applying the @must_understand annotation to a member within a type definition."

    That would mean that @must_understand fields are also applicable to @appendable structs, but in this case there is no way for a field to be identified as must_understand field in its Delimited-CDR representation.

    Of course you could state that in case of @appendable structs, you should determine assignability at discovery time and not at run time, in which case you are not dependent on the availability of a must_understand bit in the serialized blob. However, in case a Writer publishes a sample with a field that is both @must_understand AND @optional, according Table 19 (section 7.2.4.4.8) there is no mismatch between this Writer and a Reader that is missing the field (that is only the case if the field has @optional set to FALSE), which means the sample needs to be matched at runtime.

    The spec is a little unclear of the semantics in this case: I guess that if the optional value is empty but must_understand you can slice it out of the projected type, but when it is not empty you are not allowed to slice the value out since it is a must_understand value and you will have to discard the whole sample instead. It would be nice if the spec could explicitly confirm or deny this.

    But working from the presumption that you are indeed allowed to slice out values that are both empty and must_understand, the next problem arises immediately: how does a Reader know that a sample containing an unfamiliar field actually represents an optional field that is must_understand?

    Let's consider a scenario where I have a Reader that is reading a type A with the following defintion:

    @appendable struct A {
        @key long id;
         long x;
    };
    

    Now this Reader can be matched against all sorts of Writers, including Writers that have appended all kinds of fields to the end of this datatype: its deserializer simply slices everything out that comes after field x.

    This works well for most appended versions of this datatype, but now suddenly an additional Writer joins the system with the following definition:

    @appendable struct A {
        @key long id;
         long x;
        @optional @must_understand long y;
    };
    

    This Writer will match the Reader according to Table 19 since although the @must_understand annotation is TRUE, the corresponding @optional field is NOT false. So now the deserializer for our Reader has to deserialize a sample for which it doesn't know what the payload after the x actually represents. It might represent a value that it can safely slice out, or it might represent a value that may not be sliced out.

    The spec states in rule number 20 of section 7.4.3.5.3 that in case of XCDRV2, an optional member is preceeded by a boolean called is_present. The problem here is that our deserializer doesn't know where the sample originates from therefore has no knowledge whether the byte following field x represent an is_present boolean or just some other sliceable field.

    So the basic question boils down to this:

    • Do we allow fields that are both must_understand and optional in case of Appendable extensibility?
    • If so, how do we indicate in this case that a field is both optional and must_understand in a preferably backward compatible way?
  • Reported: DDS-XTypes 1.3b1 — Mon, 10 Jan 2022 15:02 GMT
  • Updated: Tue, 21 Mar 2023 15:22 GMT

bitset types not defined

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Figure 16 defines bitset as another kind of aggregated type. One might assume that this has the semantics of an IDL4 bitset.

    The text after Figure 16 and the rest of the spec doesn't define how bitset works in the type system (assignability), type representation, and data representation.

  • Reported: DDS-XTypes 1.3b1 — Mon, 20 Mar 2023 19:15 GMT
  • Updated: Tue, 21 Mar 2023 14:39 GMT

Minor Typo in SubmessageKind IDL

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

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

  • Reported: DDSI-RTPS 2.5 — Fri, 3 Mar 2023 11:13 GMT
  • Updated: Fri, 17 Mar 2023 15:03 GMT

DynamicTypeSupport IDL defnition is invalid IDL

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    DynamicTypeSupport has the following IDL definition in Annex C:

    interface DynamicTypeSupport : TypeSupport {
      /* This interface shall instantiate the type FooTypeSupport
       * defined by the DDS specification where "Foo" is DynamicData.
       */
      /*static*/ DynamicTypeSupport create_type_support(
        in DynamicType type);
      /*static*/ DDS::ReturnCode_t delete_type_support(
        in DynamicTypeSupport type_support);
      DDS::ReturnCode_t register_type(
        in DDS::DomainParticipant participant,
        in ObjectName type_name);
      ObjectName get_type_name();
    };
    

    This definition can't be used in an XTypes implementation, at least in one using standard IDL. register_type and get_type_name can't use those names because a derived interface can't define operations that share names with ones in its base interfaces. This is described at the end of 7.4.3.4.3.2.1 in IDL 4.2. Another issue is the "static" operations. They get the point across as to what the author means but, they are also not usable as IDL can't define operations as static. DynamicTypeBuilderFactory and DynamicDataFactory also do this.

  • Reported: DDS-XTypes 1.3 — Fri, 28 Oct 2022 17:45 GMT
  • Updated: Thu, 8 Dec 2022 16:29 GMT

DataFrag submessage element naming

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.5 — Tue, 15 Nov 2022 22:36 GMT
  • Updated: Tue, 15 Nov 2022 22:36 GMT

Version number is inconsistent

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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
    
  • Reported: DDSI-RTPS 2.5 — Tue, 15 Nov 2022 22:25 GMT
  • Updated: Tue, 15 Nov 2022 22:25 GMT

Inconsistent notation used to represent bit positions pictorially

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.5 — Thu, 10 Jun 2021 22:20 GMT
  • Updated: Tue, 15 Nov 2022 22:10 GMT

Table 9 is missing BITMASK_TYPE

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Add BITMASK_TYPE to table 9

  • Reported: DDS-XTypes 1.3 — Tue, 15 Nov 2022 22:08 GMT
  • Updated: Tue, 15 Nov 2022 22:08 GMT

Typo in 9.4.5.7.1 Flags in the Submessage Header

  • Status: open  
  • Source: Georgia Institute of Technology ( Seulbae Kim)
  • Summary:

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

  • Reported: DDSI-RTPS 2.5 — Wed, 5 Oct 2022 02:55 GMT
  • Updated: Wed, 5 Oct 2022 15:14 GMT

set_listener behavior is underspecified

  • Key: DDS15-329
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Suppose the DATA_AVAILABLE StatusChangedFlag (see Figure 2.16) is set on a DataReader and then a listener (with DATA_AVAILABLE_STATUS in its mask) is attached to the DataReader by the user calling set_listener(). The specification does not specify if the listener should be invoked. If the decision is that the listener is not invoked, then guidance should be given to users that they may need to invoke the listener manually.

  • Reported: DDS 1.4 — Fri, 30 Sep 2022 18:21 GMT
  • Updated: Fri, 30 Sep 2022 18:21 GMT

Network amplification

  • Status: open  
  • Source: Trend Micro Inc. ( Federico Maggi)
  • Summary:

    Details available to RTF members

  • Reported: DDSI-RTPS 2.5 — Fri, 24 Sep 2021 13:16 GMT
  • Updated: Tue, 27 Sep 2022 17:20 GMT

IDL's fixed data type is required in XTypes

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Since "Core Data Types (Sub Clause 7.4.1 [IDL])" is included in the XTypes type system model, it needs to include "fixed"

  • Reported: DDS-XTypes 1.3 — Tue, 28 Jul 2020 19:40 GMT
  • Updated: Wed, 21 Sep 2022 20:22 GMT

Representing union case labels in TypeObject

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    TypeObject assumes that all union case labels are representable in a 32-bit integer:

    // Case labels that apply to a member of a union type
    // Ordered by their values
    typedef sequence<long> UnionCaseLabelSeq;
    

    Both IDL 4.2 and the general type system in XTypes (Figure 18, 7.2.2.4.4.3) allow 64-bit integer types as discriminators and therefore 64-bit values as case labels.

  • Reported: DDS-XTypes 1.3 — Tue, 29 Sep 2020 17:46 GMT
  • Updated: Wed, 21 Sep 2022 19:00 GMT

Anonymous Types in Strongly Connected Components

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Section 7.3.4.9.2 describes the algorithm for computing type identifiers for strongly connected components. Step 4b says

    If the Strongly Connected Component (SCC) has multiple types, then sort them using the lexicographic order of their fully qualified type name. Let SCCIndex(U) be the sort index of each type U belonging to the SCC starting with index 1 for the first type. For anonymous types concatenate the fully qualified name of the containing type with the member name using “.” as the separator, for example “MyModule::MyStruct.myMember”.

    This does not cover all possibilities for anonymous types. To illustrate, the following IDL with recursive types uses an anonymous type in a typedef:

    struct NodeData {
      long l_data;
    };
    struct TreeNode;
    typedef sequence<@external TreeNode> Children;
    struct TreeNode {
      NodeData data;
      Children children;
    };
    

    The algorithm requires a name for sequence<@external TreeNode>. In general, the rule for naming anonymous types in step 4b must be expanded to include anywhere an anonymous type may appear including structs, unions, typedefs, and other anonymous types.

    An additional, related, problem is that given the definition of Plain...
    7.3.4.1 “Plain types only have a TypeIdentifier. Non-plain types have both a TypeIdentifier and a TypeObject.”
    the children field of TreeNode of the SCC example in 7.3.4.8 is a Plain Collection and has no TypeObject

    struct NodeData {
      long l_data;
    };
    struct TreeNode {
      NodeData data;
      sequence<@external TreeNode> children;
    };
    

    Step 4(b)ii of the algorithm in 7.3.4.9.2 requires that all of the types in an SCC have a TypeObject 4(b)ii.
    Possible Solutions and Notes:
    The algorithm implies that all of the types involved in a Strongly Connected Component have a type identifier of TI_STRONGLY_CONNECTED_COMPONENT. The precludes the use of the Plain Collections in Strongly Connected Components. Thus, if the algorithm of 7.3.4.9.2 is not revised, then the definition of Plain Collections needs to be revised to exclude those involved in a Strongly-Connected Component.

  • Reported: DDS-XTypes 1.3 — Wed, 2 Sep 2020 16:25 GMT
  • Updated: Wed, 21 Sep 2022 18:45 GMT

Inconsistency in the wire representation of SequenceNumber type fields

  • Status: open  
  • Source: Georgia Institute of Technology ( Seulbae Kim)
  • Summary:

    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?

  • Reported: DDSI-RTPS 2.5 — Tue, 23 Aug 2022 15:31 GMT
  • Updated: Wed, 24 Aug 2022 17:03 GMT

Typo in Table 9.18 (PID__DOMAIN_ID)

  • Status: open  
  • Source: Georgia Institute of Technology ( Seulbae Kim)
  • Summary:

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

  • Reported: DDSI-RTPS 2.5 — Tue, 23 Aug 2022 19:30 GMT
  • Updated: Wed, 24 Aug 2022 16:08 GMT

Incorrect definition of a user-defined within EntityId_t

  • Status: open  
  • Source: Real Time Innovations ( Samuel Raeburn)
  • Summary:

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

  • Reported: DDSI-RTPS 2.5 — Mon, 22 Aug 2022 10:22 GMT
  • Updated: Wed, 24 Aug 2022 16:08 GMT

TypeFlags usage in normative IDL

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Enum and bitmask can have extensibility

        typedef TypeFlag   EnumTypeFlag;        // Unused. No flags apply
        typedef TypeFlag   BitmaskTypeFlag;     // Unused. No flags apply
    
  • Reported: DDS-XTypes 1.3 — Tue, 30 Jun 2020 19:25 GMT
  • Updated: Wed, 10 Aug 2022 22:24 GMT

Dynamic Binding: equals() for DynamicType/DynamicTypeMember and related types

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Definition of equality is based on the "Properties" of the class as defined by the UML models (for example, Table 54). However, associations/aggregations (which are not properties) are just as important for equality. An example is the TypeDescriptor that's associated with each DynamicType. While not a Property, the state of TypeDescriptor is effectively part of the state of DynamicType.

    A related issue is that DynamicTypeMembers can only be equal "if they belong to the same type." This seems to be both unnecessary and prevents certain valid use cases. An application may want to determine if two different structs each have a string member of a certain name. Based on the Type System model (sect 7.2) it would be natural to apply the equals() operation on the members to check their logical equality independent of which struct they're declared in.

  • Reported: DDS-XTypes 1.3 — Mon, 8 Aug 2022 14:26 GMT
  • Updated: Mon, 8 Aug 2022 14:26 GMT

Annex C: BoundSeq IDL type not defined

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The IDL defined in Annex C uses the type BoundSeq as a member of TypeDescriptor, but BoundSeq is not defined in the spec.

  • Reported: DDS-XTypes 1.3 — Tue, 26 Jul 2022 18:01 GMT
  • Updated: Thu, 28 Jul 2022 14:27 GMT

Align with XTYPES 1.3 and IDL 4.2

  • Key: DDS15-250
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This issue should be treated as blocker so that it is resolved ahead of other issues.

    • Align naming of annotations with the latest versions of said specifications.
    • Use the new size-aware typenames: int32_t, uint32_t etc. Instead of the classic ones.
    • Use bitmask where it makes sense. For example the StatusKind, InstanceStateKind, ViewStateKind and the corresponding
    • StatusMask, InstanceStateMask, ViewStateMask? Will this negatively impact /break the Java, C#, C++ APIs?
    • Use enum for ReturnCode_t, QosPolicyId_t? Will this negatively impact /break the Java, C#, C++ APIs?
    • Use template modules to model the Implied IDL related to type 'Foo'?
    • Apply the @extensibility annotation to the BuiltinTopicData types and the types they reference (e.g. QosPolicy types) since they are serialized to be sent to other peers. Note that this was already done in XTYPES so we can copy those definitions to the DDS spec and remove them from a future revision of XTYPES.
  • Reported: DDS 1.4 — Mon, 20 May 2019 22:47 GMT
  • Updated: Thu, 2 Jun 2022 00:59 GMT

InstanceHandle_t underspecified

  • Key: DDS15-315
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 2.2.2.1.1.8 the Instance handle is mentioned by the spec lacks some definition of InstanceHandle_t. In how far as instance handles unique and should they be comparable? Are they unique system wide or process wide? Is it legal to have two DDS entities (for example two domain participants) to have the same instance handle? This is important for users who for example store DDS entities in a std::map.

  • Reported: DDS 1.4 — Mon, 16 Nov 2020 07:30 GMT
  • Updated: Wed, 25 May 2022 23:42 GMT

Wrong data type for serializedPayload in DATAFRAG

  • Status: open  
  • Source: Atostek Oy ( Juhana Helovuo)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.5 — Tue, 17 May 2022 12:33 GMT
  • Updated: Thu, 19 May 2022 16:02 GMT

Annex A: Ownership Profile is unclear

  • Key: DDS15-328
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The bullet point for " This profile adds two things " goes on to list three things. The third is about History QoS, which makes it appear to the reader like this was added on later and not initially part of the profile. That itself is not a problem, but for clarity this section should provide a rationale as to why the History QoS Policy is involved in the definition of Ownership Profile.

  • Reported: DDS 1.4 — Thu, 7 Apr 2022 15:54 GMT
  • Updated: Thu, 7 Apr 2022 15:54 GMT

Introduce a concept of Partitions at the DomainParticipant level

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.5 — Wed, 16 Mar 2022 23:49 GMT
  • Updated: Wed, 16 Mar 2022 23:49 GMT

The specs and illustration of the ChangeForReader are missing / have been removed

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.5 — Thu, 3 Mar 2022 10:05 GMT
  • Updated: Mon, 7 Mar 2022 19:49 GMT

Error in formatting pseudo code

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

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

    { Receiver.multicastReplyLocatorList = InfoReply.multicastLocatorList } else { Receiver.multicastReplyLocatorList = <empty> }
    ```
    this should be:
    ```
    ReceiverReceiver.unicastReplyLocatorList = InfoReply.unicastLocatorList

    if ( MulticastFlag ){ Receiver.multicastReplyLocatorList = InfoReply.multicastLocatorList }

    else

    { Receiver.multicastReplyLocatorList = <empty> }

    ```

  • Reported: DDSI-RTPS 2.5 — Wed, 2 Mar 2022 13:07 GMT
  • Updated: Wed, 2 Mar 2022 21:43 GMT

Handling of non-existent cache changes in logical action

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.5 — Mon, 28 Feb 2022 08:47 GMT
  • Updated: Wed, 2 Mar 2022 21:42 GMT

The "depth" QoS setting does not have any bounds set

  • Key: DDS15-327
  • Status: open  
  • Source: Open Robotics ( William Woodall)
  • Summary:

    The description of the history depth QoS setting indicates it is optional and only used when KEEP_LAST is the history kind, and that it is a long (or sometimes referred to as an integer/int), and that the default value is 1, and that it needs to be consistent with related RESOURCE_LIMITS QoS settings, but it does not specify a bounds nor does it explicitly state that the bounds are actually any valid (signed) long value. So a few boundary cases are not well defined, for example:

    • is KEEP_LAST with depth 0 valid? If so, is it a special behavior?
    • what about negative values for depth?

    RTI's Connext Pro documentation limits it to values greater than zero and less than 100,000,000:

    > "[range] [1,100 million], <= DDS_ResourceLimitsQosPolicy::max_samples_per_instance"
    https://community.rti.com/static/documentation/connext-dds/6.0.1/doc/api/connext_dds/api_c/structDDS__HistoryQosPolicy.html#aef0fb3fd3579866be17d1a936f5e3729

    Other implementations like Cyclone DDS and Fast-DDS will accept values of zero, though it's not clear what they're behavior is in that case.

    Those are useful to imply what the behavior is, but I think the standard should probably take stance on the valid values for depth, and I think values >= 1 makes sense, though the "100 million" upper bound set by RTI's API seems kind of arbitrary, though I don't have a better alternative in mind.

  • Reported: DDS 1.4 — Thu, 24 Feb 2022 02:30 GMT
  • Updated: Wed, 2 Mar 2022 21:42 GMT

Missing DDS-XTypes extensions (which should be part of DDS 1.5)

  • Key: DDSXML11-3
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This specification lacks the XSD type definitions for the QoS extensions coming from DDSXTypes (at least DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy), these should be added to the DDS XML consolidated XML

  • Reported: DDS-XML 1.0 — Wed, 9 Feb 2022 15:05 GMT
  • Updated: Wed, 9 Feb 2022 17:10 GMT

Inconsistent use of higuest_sent_seq_num and highestSentChangeSN

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.5 — Mon, 7 Feb 2022 11:39 GMT
  • Updated: Mon, 7 Feb 2022 17:24 GMT

Inconsistent use of SEQUENCE_NUMBER_INVALID; for highestSentChangeSN

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    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?

  • Reported: DDSI-RTPS 2.5 — Mon, 7 Feb 2022 10:01 GMT
  • Updated: Mon, 7 Feb 2022 17:23 GMT

Add support for data-level compression during serialization

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Larga data types or types that contain compressible data (e.g. strings) can benefit from using compression at serialization time.
    This would reduce the size required to store the data in the reader/writer caches as well as the bandwidth used to send the data.

    This is complementary to transport-level compression and has the advanatage that the data is only compressed once (at serialization, instead of every time it is sent) as well as reducing memory requirements.

  • Reported: DDS-XTypes 1.3b1 — Tue, 1 Feb 2022 19:08 GMT
  • Updated: Tue, 1 Feb 2022 19:08 GMT

Fields writerSet and secureWriterSet are missing in wire representation:

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

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

  • Reported: DDSI-RTPS 2.5 — Tue, 25 Jan 2022 15:25 GMT
  • Updated: Tue, 25 Jan 2022 22:18 GMT

Paramter id and length should be unsigned short

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

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

  • Reported: DDSI-RTPS 2.5 — Mon, 24 Jan 2022 14:57 GMT
  • Updated: Tue, 25 Jan 2022 22:14 GMT

Masks in table 9.6 (ParameterId subspaces) should be hexadecimal

  • Status: open   Implementation work Blocked
  • Source: N/A ( Frans Schneider)
  • Summary:

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

  • Reported: DDSI-RTPS 2.5 — Mon, 24 Jan 2022 13:20 GMT
  • Updated: Tue, 25 Jan 2022 22:11 GMT

Note on the message wide CRC check

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.5 — Thu, 20 Jan 2022 14:01 GMT
  • Updated: Tue, 25 Jan 2022 22:07 GMT

Textual error in section 9.4.5.2.1

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    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

  • Reported: DDSI-RTPS 2.5 — Wed, 19 Jan 2022 10:29 GMT
  • Updated: Tue, 25 Jan 2022 21:56 GMT

Description incomplete

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

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

    • The GUIDs of Endpoint Groups within a Participant
  • Reported: DDSI-RTPS 2.5 — Tue, 11 Jan 2022 14:50 GMT
  • Updated: Tue, 25 Jan 2022 21:53 GMT

CRC computation for Checksum128_t undefined

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

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

  • Reported: DDSI-RTPS 2.5 — Wed, 19 Jan 2022 14:08 GMT
  • Updated: Tue, 25 Jan 2022 21:27 GMT

Please ignore Implementation Work Blocked flag in issue INBOX-1375

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    Sorry, had this flag checked by accident.

  • Reported: DDSI-RTPS 2.5 — Mon, 24 Jan 2022 14:22 GMT
  • Updated: Tue, 25 Jan 2022 20:39 GMT

Typo or editing issue

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    7.4.1.2.1 7th paragraph (maybe) / 3rd paragraph of page 126: : “The four bytes following the PID_EXTENDED and length shall be a serialized UINT32 value "eMemberHeader" that is constructed by combining four 1-bit flags with by the 28-bit member ID.”

    It seems like the second “by” should be removed.

  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 14:13 GMT
  • Updated: Fri, 21 Jan 2022 06:58 GMT

Default value and @default annotations

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    IDL4 defines @default as a way to specify a custom default value for an IDL element, but DDS XTypes defines it own default mechanism, shouldn't the value of @default be used when set?

  • Reported: DDS-XTypes 1.3 — Wed, 21 Apr 2021 10:28 GMT
  • Updated: Fri, 21 Jan 2022 02:59 GMT

JSON Representation of Unions

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Some union values are "empty" in that they have no case selected. Since discriminators are optional, is the JSON representation of such a union equivalent to an empty struct?

    // IDL
    union U switch (boolean) {
    case TRUE:
      long i;
    };
    

    When a value of this union has discriminator FALSE, there is no selected case.

  • Reported: DDS-JSON 1.0 — Tue, 18 Jan 2022 21:18 GMT
  • Updated: Tue, 18 Jan 2022 21:18 GMT

Unclear how to discover GROUP_GUID/GROUP_ENTITY_ID from a coherent Publisher

  • Status: open   Implementation work Blocked
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.5 — Wed, 12 Jan 2022 16:02 GMT
  • Updated: Wed, 12 Jan 2022 16:02 GMT

Incorporate the lookup_topicdescription change added in XTYPES 1.3

  • Key: DDS15-326
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.6.4.2 Operation: DomainParticipant::lookup_topicdescription
    in XTYPES 1.3 makes a changes to the DDS spec in the description of the Operation: DomainParticipant::lookup_topicdescription

    This change should be consolidated into the DDS specification.

  • Reported: DDS 1.4 — Tue, 4 Jan 2022 21:09 GMT
  • Updated: Tue, 4 Jan 2022 21:09 GMT

dds::core::status::StatusMask should allow you to set mutiple Status bits by using the logical OR operation

  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The current dds::core::status::StatusMask inherits from a bitset, but it does not allow you to use the logical OR ( operator | () ) to set multiple bits in the mask.

    Even though StatusMask inherits from std::bitset (which does allow you to use the | operator() ), any attempt to use it on the StatusMask (as in
    StatusMask | StatusMask) results in a compilation error because the resulting type is a bitset, not a StatusMask.

    This seems a bit weird, since using the logical OR seems the natural way in which people set bits in a mask, and it is a common pattern that is used extensively in its parent, the bitset.

    The current StatusMask does allow you to use the streaming operator << for the same purpose instead, but this does not feel like a natural way of doing it.

    Last but not least, some implementations are already supporting the | operator where others don't, so we might as well want to standardize is to keep application code portable across vendors.

  • Reported: DDS-PSM-Cxx 1.0 — Mon, 20 Dec 2021 21:02 GMT
  • Updated: Mon, 20 Dec 2021 21:02 GMT

Clarify the PartitionQosPolicy

  • Key: DDS15-245
  • Status: open  
  • Source: Brunvoll AS ( Havard Skjevling)
  • Summary:

    It is ambiguous whether or not the PartitionQosPolicy set for a Publisher or Subscriber should affect DataWriter and DataReader matching, and how an implementation should handle it.

    Since it is stated that failure to match partitions does not imply "incompatible" QoS, it would seem it does not affect matching.
    If so, the specification should be clearer with regards to

    • whether this is filtered on the publishing, or subscribing side (or both)
    • how partitions are tied to samples or instances e.g. when written from a DataWriter whose Publisher changes partitions intermittently
    • how it deals with late joiners and historical data
    • how this affects the "transient/persistent" services and their entities' QoS settings

    2.2.3 QosPolicy Table

    A DataWriter within a Publisher only communicates with a DataReader in a Subscriber if (in addition to matching the Topic and having compatible QoS) the Publisher and Subscriber have a common partition name string.

    2.2.3.13 Partitions

    For a DataReader to see the changes made to an instance by a DataWriter, not only the Topic must match, but also they must
    share a common partition. Each string in the list that defines this QoS policy defines a partition name. A partition name may
    contain wildcards. Sharing a common partition means that one of the partition names matches.
    Failure to match partitions is not considered an “incompatible” QoS and does not trigger any listeners nor conditions.

  • Reported: DDS 1.4 — Wed, 7 Nov 2018 11:03 GMT
  • Updated: Tue, 16 Nov 2021 20:21 GMT

Provide a pre-shared key protection mechanism

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.5 — Fri, 12 Nov 2021 16:24 GMT
  • Updated: Fri, 12 Nov 2021 16:24 GMT

Missing TK_INT8 and TK_UINT8 in the IDL machine readable file

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    https://issues.omg.org/browse/DDSXTY13-7 added these two constants and they were placed in the IDL that appears in Annex B. However they were left out of the separate machine readable file https://www.omg.org/spec/DDS-XTypes/20190301/dds-xtypes_typeobject.idl

    In addition, the comment:

        //   - COMMON indicates the TypeIdentifier identifies equivalent types
        //     according to both the MINIMAL and the COMMON equivalence relation.
        //     This means the TypeIdentifier is the same for both relationships
    

    Should say (replace second "COMMON" with "COMPLETE"):

        //   - COMMON indicates the TypeIdentifier identifies equivalent types
        //     according to both the MINIMAL and the COMPLETE equivalence relation.
        //     This means the TypeIdentifier is the same for both relationships
    
  • Reported: DDS-XTypes 1.3b1 — Tue, 12 Oct 2021 00:51 GMT
  • Updated: Tue, 12 Oct 2021 15:09 GMT

Extensibility of inherited structures

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification should state the behavior if a derived type extensibility kind is specified to be different from that of its parent.

    Furthermore for usability we should specify the behavior if the derived type does not specify any extensibility kind. Does it 'inherit' that of the parent or is it assumed to be the 'default'.

    Current thinking: It is an error to have a derived structure specify a different extensibility kind than its parent. Leaving it unspecified sets the derived type extensibility type to that of your parent.

    Basically the serialization of the derived class does not add its own header.

  • Reported: DDS-XTypes 1.3b1 — Thu, 30 Sep 2021 15:28 GMT
  • Updated: Tue, 5 Oct 2021 14:05 GMT

Inconsistent Definitions of RTPS Encapsulation

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    There are inconsistencies in the two definitions of the RTPS Encapsulation Header I've found so far. The major issue is that the values for the encoding identifiers are different between 7.4.3.4 and 7.6.3.1.2 for non-XCDR1 encodings. These are the big-endian values compared:

    Type 7.4.3.4 7.6.3.1.2
    Plain XCDR2 0x00, 0x10 0x00, 0x06
    Parameter List XCDR2 0x00, 0x12 0x00, 0x0a
    Delimited XCDR2 0x00, 0x14 0x00, 0x08
    XML 0x01, 0x00 0x00, 0x04

    The other issue is that while 7.6.3.1.2 describes the two options bytes of the encapsulation header that follow the encoding identifier and extends it for padding info, 7.4.3. is lacking in details as far as I can see. The serialization rules has them in 7.4.3.5.3 as `OPTIONS`, but doesn't define it in any of the tables before the rules like all the other symbols are. It does mention encapsulation in 7.4.3.5, but doesn't mention anything about extending the options bytes.

  • Reported: DDS-XTypes 1.3b1 — Thu, 4 Jun 2020 17:51 GMT
  • Updated: Sat, 2 Oct 2021 00:10 GMT

Integrate annotations for range/min/max with try_construct

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The range/min/max group of standard IDL annotations are not referenced in table 21 and its surrounding sections.

    It would seem like the try_construct behavior could be applied to range/min/max when the publisher and subscriber have different but compatible annotations.

  • Reported: DDS-XTypes 1.3b1 — Thu, 30 Sep 2021 14:45 GMT
  • Updated: Thu, 30 Sep 2021 14:45 GMT

Remove all IDL42 specified parts

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDSXTypes refers in section 3 to IDL4.2 but still duplicates a lot of things which are now part in IDL4. It is now very hard to determine what is part of IDL4 and what is DDSXTypes specific, for example bit_bound seems to be just for DDS, it is not part of IDL4.

  • Reported: DDS-XTypes 1.3 — Thu, 19 Aug 2021 09:38 GMT
  • Updated: Fri, 20 Aug 2021 06:52 GMT

8 bit types mising in 7.2.1

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 7.2.1 it says:

    Integral types of various bit lengths (16, 32, 64), both signed and unsigned

    8 bit types are missing, so updated this to

    Integral types of various bit lengths (8, 16, 32, 64), both signed and unsigned

  • Reported: DDS-XTypes 1.3 — Tue, 17 Aug 2021 11:22 GMT
  • Updated: Tue, 17 Aug 2021 22:16 GMT

find_topic/delete_topic underspecified

  • Key: DDS15-316
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    It is not clear what kind of restrictions there are to find_topic/delete_topic.

    Assume two software modules in the same process, order of instantiation is not fixed, also more modules could be loaded by a configuration file. All modules use find_topic to find topic Foo, the first module now calls create_topic to create the topic, second module gets topic Foo through find_topic.

    Each module now creates its own datareader/datawriters using the topic it retrieved. At the moment the module now ends it cleans the datareader/datawriter it has created and now calls delete_topic. It is not clear what at that moment delete_topic will return for the module that has successfully used find_topic to get the topic. Some DDS vendors return RETCODE_OK, some RETCODE_PRECONDITION_NOT_MET because there are still readers/writers related to that topic (but the other module did use create_topic). The shutdown order can also be swapped, so first the module that used create_topic will be removed, the one with find_topic keeps running.

    The description of find_topic should be extended to clarify how it behaves related to delete_topic? Personally I think RETCODE_OK should be returned when there is no DataReader, DataWriter, ContentFilteredTopic, or MultiTopic attached anymore to the topic returned by find_topic, independent of the entities attached to the topic as it was created by create_topic (or a different find_topic call)

  • Reported: DDS 1.4 — Mon, 16 Nov 2020 12:36 GMT
  • Updated: Thu, 22 Jul 2021 06:17 GMT

Read / Take with max_samples = 0

  • Key: DDS15-325
  • Status: open  
  • Source: eProsima ( Miguel Company)
  • Summary:

    It is not clear what should be done if the user calls read, take, or any of their variants when the following conditions are met:

    1. The method is called with max_samples = 0
    2. There is data available that would be returned with max_samples > 0

    I think we have two options here:

    1. Return NO_DATA
    2. Return OK with a resulting collection with len = 0

    The last sentence of the section seems to indicate the latter...

    If the DataReader has no samples that meet the constraints, the return value will be NO_DATA

    ... but the definition of NO_DATA on page 5 seems to indicate the former (as no data is returned)

    Indicates a transient situation where the operation did not
    return any data but there is no inherent error.

  • Reported: DDS 1.4 — Thu, 15 Jul 2021 09:02 GMT
  • Updated: Tue, 20 Jul 2021 13:20 GMT

TypeLookup IDL Inconsistency

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    TypeLookup IDL in 7.6.3.3.3 contains the following unsigned long constants in IDL:

    // computed from @hashid("getTypes")
    const unsigned long TypeLookup_getTypes_HashId = 0x018252d3;
    // computed from @hashid("getDependencies");
    const unsigned long TypeLookup_getDependencies_HashId = 0x05aafb31;
    

    However later in the IDL two unions called TypeLookup_Call and TypeLookup_Return which use those constants as branches are discriminated with a long. Since long is apparently specified by the RPC spec, then the type of the constants should be changed to long to match the unions.

    Other issues in this IDL:

    • TypeLookup_getTypes_Result and TypeLookup_getTypeDependencies_Result both use DDS_RETCODE_OK as an IDL constant. It should be DDS::RETCODE_OK (from the DDS core spec 2.3.3)
    • TypeLookup_Call and TypeLookup_Return both use IDL constants that end in the word "Hash" but should match the ones above (they are missing "Id")
    • TypeLookup_Reply contains a member of type RequestHeader which should be ReplyHeader
  • Reported: DDS-XTypes 1.3 — Tue, 10 Nov 2020 02:10 GMT
  • Updated: Wed, 16 Jun 2021 22:03 GMT

Common Types contains invalid IDL

  • Key: DDSRPC11-5
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    IDL identifiers may not reuse the same names (disregarding case) of types already in scope. This is a problem for "instanceName" in the RPC spec:

    struct RequestHeader {
      SampleIndentity_t requestId;
      InstanceName instanceName;
    };
    

    And SampleIndentity_t is misspelled. It should be SampleIdentity.

  • Reported: DDS-RPC 1.0 — Wed, 16 Jun 2021 21:32 GMT
  • Updated: Wed, 16 Jun 2021 21:32 GMT

Typo in Member of AnnotationParameterValue

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    AnnotationParameterValue has a members for integer types. uint_16_value is the only one that has an underscore between the int and the size and this appears to be a typo. Given that it seems that the name has no real bearing in this situation, it should be fixed by changing uint_16_value to uint16_value.

  • Reported: DDS-XTypes 1.3 — Mon, 14 Jun 2021 22:07 GMT
  • Updated: Mon, 14 Jun 2021 23:04 GMT

Section 9.4.2.9 Timestamps shows 'seconds' as 'long' instead of 'unsigned long'

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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                     | 
    +---------------+---------------+---------------+---------------+
    
  • Reported: DDSI-RTPS 2.5 — Thu, 10 Jun 2021 23:32 GMT
  • Updated: Thu, 10 Jun 2021 23:32 GMT

sample lost/rejected should be clarified and extended

  • Key: DDS15-324
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    when testing for sample lost/rejected between multiple DDS vendors we see different vendors to different things. The specification should be extended with more information when a sample is considered lost and when rejected with also more details how QoS settings would influence this. We see that vendors have extended the SampleLostStatus and SampleRejectedStatus and even have deprecated some of its members, this should be handled in the specification so that the user gets the same behavior when using multiple vendors

  • Reported: DDS 1.4 — Thu, 27 May 2021 16:27 GMT
  • Updated: Thu, 3 Jun 2021 18:53 GMT

DDS should use typed modules

  • Key: DDS11-15
  • Legacy Issue Number: 15430
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS specfication has typed interfaces (writer/reader/etc) which are currently not expressed in IDL. The DDS specification should use the typed modules as introduced in the dds4ccm specification to express all interfaces explicitly in IDL, including the typed ones.

  • Reported: DDS 1.2 — Mon, 23 Aug 2010 04:00 GMT
  • Updated: Fri, 21 May 2021 09:30 GMT

Order in which implied IDL and language mappings interact

  • Key: DDS15-323
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    There looks to be different interpretations between DDS vendors how implied IDL and language mappings interface. The specification lists in 2.3.3 the example of type Foo which results in the implied IDL DataWriter named FooDataWriter. On this implied IDL the concrete language mapping is applied, so with IDL to C++ we get FooDataWriter/FooDataWriter_ptr/FooDataWriter_var. But, what happens when the type is a IDL or C++ keyword, for example the type _public results in the implied IDL publicDataWriter, on which the IDL to C++ language mapping is implied, so to our idea you get _cxx_public/publicDataWriter/publicDataReader. The IDL to C++ language mapping only sees the identifiers as resulted by the implied IDL rules. Some vendors do generate _cxx_public/_cxx_publicDataWriter/_cxx_publicDataReader which means the implied IDL and IDL to C++ language mapping are strangely mixed. A generaic modeling tool for example only knows of implied IDL, a custom code generator generates the code for the specific language mapping.

    The specification should give an example for _public, what does the programmer now get in a specific programming language, for example C++

  • Reported: DDS 1.4 — Wed, 19 May 2021 11:54 GMT
  • Updated: Thu, 20 May 2021 20:27 GMT

Incorrect value for GROUPDATA_QOS_POLICY_NAME

  • Key: DDS15-322
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL file dds_dcps.idl has a wrong value

    const string GROUPDATA_QOS_POLICY_NAME = "TransportPriority";

    Shouldn't it say "GroupData"

  • Reported: DDS 1.2 — Wed, 12 May 2021 12:20 GMT
  • Updated: Wed, 12 May 2021 14:06 GMT

The list of valid KEY types does not include String types

  • Status: open  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    The text reads:

    "A type's key can only include members of the following types: primitive, aggregation,
    enumeration, bitmask, array, and sequence."

    It should include 'string' and 'wstring'.

  • Reported: DDS-XTypes 1.3 — Thu, 6 May 2021 15:53 GMT
  • Updated: Tue, 11 May 2021 13:56 GMT

IDL keywords used as interface/module

  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A module ATTRIBUTE and interface Attribute are both used in this spec, but attribute is a keyword in IDL and this will collide with it, IDL is case insensitive (see IDL 4.2, section 7.2.3 Identifiers) and check the IDL collision rules, see IDL 4.2, section 7.2.3.1 Collision Rules.

    Maybe more keywords are used in this spec, would recommend to compile the IDL of this specification with more IDL compilers.

  • Reported: DDS-OPCUA 1.0 — Sun, 25 Apr 2021 08:12 GMT
  • Updated: Fri, 30 Apr 2021 13:42 GMT

Don't use anonymous types

  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Some language mappings don't support anonymous types for various reasons. This specification does use some anonymous types which can easily be removed by adding some typedefs outside of the types. Please add some typedes and use these within the containing types.

  • Reported: DDS-OPCUA 1.0 — Sun, 25 Apr 2021 08:07 GMT
  • Updated: Fri, 30 Apr 2021 13:42 GMT

No mapping for uint8/int8, map, bitset

  • Key: DDSXML11-2
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL specification got extended with support for uint8/int8, map, bitset/mask, but there is no mapping for this in the DDS XML specification. The DDS XML specification should also define how these new IDL types are mapped in XML

  • Reported: DDS-XML 1.0 — Mon, 19 Apr 2021 07:28 GMT
  • Updated: Fri, 30 Apr 2021 13:36 GMT

Support transport-level RTPS message compression

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDSI-RTPS 2.3b1 — Mon, 14 Sep 2020 15:06 GMT
  • Updated: Fri, 9 Apr 2021 12:28 GMT


Example class table seems to violate written convention

  • Key: DDS15-321
  • Status: open  
  • Source: Air Force Institute of Technology, Student ( Nathaniel Peck)
  • Summary:

    Above the Myclass example table, the written text says that collections of types will be denoted by <type>[]. The example describes in: param4 as being a collection of longs, but the table defines the type as long rather than long[] as the written convention seems to imply.

  • Reported: DDS 1.4 — Tue, 30 Mar 2021 17:56 GMT
  • Updated: Thu, 1 Apr 2021 15:53 GMT

DDS Entities should have a name

  • Key: DDS15-28
  • Legacy Issue Number: 16029
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    DDS Entities (DomainParticipant, Publisher, Subscriber, DataReader and DataWriter) have associated GUID but the current API does not provide any way of associating them a symbolic name, such as "com.acme.mycoolapp.DomainParticipantFoo"

    The DDS PIM should be extended to support the explicit setting of entity names. When not set explicitly, vendors should be free to pick meaningful names.

  • Reported: DDS 1.2 — Wed, 16 Feb 2011 05:00 GMT
  • Updated: Tue, 16 Mar 2021 08:22 GMT

Table 60 - RTPS encapsulation identifier

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In this table, the row second from the bottom for "XCDR MUTABLE 2 Little Endian" has the wrong identifier.

  • Reported: DDS-XTypes 1.3 — Thu, 11 Mar 2021 15:44 GMT
  • Updated: Thu, 11 Mar 2021 15:44 GMT

create_querycondition with a query with string parameters

  • Key: DDS15-319
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We identified differences between DDS vendors how to handle a query condition that uses a string parameter. At the moment we have a query with "symbol = %0", what is the query parameter string we need to use when we want to match it with OMG. When using for example C++, RTI Connext DDS seems to require "'OMG'", so single quotes around the string itself, but OpenDDS/Opensplice seem to use "OMG" so without single quotes around the string.

    The specification should be clear about how strings are used when they are passed through a query parameter like %0.

  • Reported: DDS 1.4 — Fri, 26 Feb 2021 14:24 GMT
  • Updated: Thu, 4 Mar 2021 01:01 GMT

Unknown behavior of explicitly negated key in nested struct

  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    In section 7.6.8 it is stated that for a nested struct that is annotated as key for an embedding struct, you have to follow the following process to to generate its KeyHolder: "If there are any key members, then remove the non-key members from FooKeyHolder. Otherwise do not remove any members."

    So what if the struct has no explicit key members, but it has explicitly mentioned that a certain field should not act as key? Take for example the following example:

    struct Foo {
        long x;
        @key(false) long y;
    };
    
    struct Bar {
        @key Foo myFoo;
        string name;
    };
    

    There are three different ways to interpret the rules for this usecase:

    1. Both x and y will end up in the KeyHolder, since Foo did not specify any key members, so nothing gets removed.
    2. Only y will end up in the KeyHolder, since Foo specified explicitly that x should not act as key.
    3. Neither x nor y will end up in the KeyHolder, since some of the members have an explicit key annotation and so I remove all the members which are not keys, which is y (stated explicitly) and x (stated implicitly).

    So the big underlying question is: is explicitly stating @key(false) equal to not having a @key annotation at all, or does explicitly stating that a member is not a key have some more expressive power over implicitly determining its key status by absence of the @key annotation?

  • Reported: DDS-XTypes 1.3b1 — Wed, 27 Jan 2021 15:03 GMT
  • Updated: Fri, 5 Feb 2021 16:25 GMT

Type Consistency Enforcement QoS Policy ignore_member_names

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The paragraph that explains ignore_member_names defines its semantics as follows:

    • If the option is set to TRUE, member names are considered
    • If the option is set to FALSE (the default), then
      member names are not ignored

    The mode of "considering" would seem to be the same as "not ignoring." Thus the spec is currently stating that the two options are equivalent. Since the name is ignore_member_names, that indicates that setting TRUE should indeed ignore them.

    The spec should be changed to indicate that if the option is set to TRUE then member names are ignored.

  • Reported: DDS-XTypes 1.3 — Mon, 25 Jan 2021 21:40 GMT
  • Updated: Mon, 25 Jan 2021 21:40 GMT

Extend SampleLostStatus with last_reason

  • Key: DDS15-318
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Several DDS vendors have already extended SampleLostStatus with a last_reason, indicating why the last sample was lost. We would like to see this in the DDS specification so that all vendors provide this consistently

  • Reported: DDS 1.4 — Mon, 23 Nov 2020 12:11 GMT
  • Updated: Mon, 28 Dec 2020 17:03 GMT

Ambiguous effect of using annotations on attributes with multiple declarators.

  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    It is possible to put an annotation on an attribute with multiple declarators, like this:

    struct Foo {
      @key long x, y;
    };
    

    What is the effect of this? Does the annotation apply to both declarators? In that case, how do you interpret the following:

    struct Foo {
      @fieldid(0x01000) long x, y;
    };
    
  • Reported: DDS-XTypes 1.3b1 — Wed, 30 Sep 2020 14:49 GMT
  • Updated: Tue, 8 Dec 2020 15:59 GMT

behaviour of create_topic with duplicate topic_name

  • Key: DDS15-317
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    the DDS spec should define the behaviour when the create_topic is called multiple times with the same topic_name, I think the operation should fail at that moment, but that is not mentioned in the spec

  • Reported: DDS 1.4 — Mon, 16 Nov 2020 17:36 GMT
  • Updated: Tue, 17 Nov 2020 14:30 GMT

Default built-in ReaderDataLifecycle values

  • Key: DDS15-46
  • Legacy Issue Number: 10811
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    QoS settings of buildin Readers: according to section 2.1.5 builtin Readers should have its ReaderDataLifecycles delays set to infinite, meaning that builtin topics that are disposed and/or unregistered will never be removed from the system unless explicitly 'taken'. If an application never bothers to look at the builtin readers, they will never clean up resources and these readers will use up more and more memory if entities keep on joining and leaving the network.

    Solution:
    We propose to give the builtin-readers a finite duration for both auto_purge variables (for example something like 5 minutes).

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 12 Oct 2020 13:44 GMT

Change the default value for DataWriterLifecycle::autodispose_unregistered_instances and behavior when a DataWriter is deleted

  • Key: DDS15-314
  • Status: open  
  • Source: Real-Time Innovations ( Ms Erin McManus)
  • Summary:

    Unregistering and disposing instances have different semantics and the default association of these two operations through the usage of the autodispose_unregistered_instances may lead to behaviors that are unexpected and not desirable to DDS users.

    The unregister operation is meant to indicate that the DataWriter will no longer update the instance but does not indicate anything about the state of the instance itself. The dispose operation, on the other hand, is meant to indicate a change in the state of the instance, it indicates that the instance has been deleted. Because of this, we are proposing changing the default value of this QoS to FALSE. This is something that many of our customers end up doing explicitly.

    In addition to changing the default value for autodispose_unregistered_instances, we are also proposing that this QoS does not have any effect during the deletion of the DataWriter. Disposing of an instance should be an explicit operation (individual or bulk operation). In many cases, the user's intention is not to delete (dispose) an instance when a DataWriter is deleted and doing so explicitly ties the lifecycle of the instance to the lifecycle of the DataWriter.

  • Reported: DDS 1.4 — Wed, 2 Sep 2020 23:52 GMT
  • Updated: Thu, 3 Sep 2020 20:00 GMT

Enums with different holder types should not be assignable

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The row for ENUM_TYPE in Table 40 defines an enum's holder type.

    Footnote 3 on page 63 indicates that the type system is designed to allow a DataReader to consume a byte stream from a differently-typed (but assignable) DataWriter without "requiring the consultation of per-DataWriter type definitions during sample deserialization".

    The current definition of Enum Assignability fails in this respect. It needs to prevent enum types from being assignable when their holder types differ.

    Also relevant - pgh 2 of 7.2.4.2 "...Enumerated types (Enumeration and Bitmask) are delimited types as their serialized size is fixed"

  • Reported: DDS-XTypes 1.3 — Wed, 26 Aug 2020 18:09 GMT
  • Updated: Wed, 26 Aug 2020 22:09 GMT

7.4.3.5.3 contradictory rules for collections

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Arrays of all kinds/extensibilities are covered by rules 8-10. Following those we find the "comments" below:

    // Arrays with extensibility APPENDABLE use common APPENDABLE rules:
    // (29)-(30)
    // Arrays with extensibility MUTABLE are not allowed. Treated as APPENDABLE.
    

    Which is either redundant or contradictory. Same issue with Sequences (rules 11-13) and maps (rules 14-16).

    Due to this, the notes before rules 29-30 should be revised to remove "Collection or"

    // Extensibility APPENDABLE (Collection or Aggregated types), version ?
    // encoding
    
  • Reported: DDS-XTypes 1.3 — Tue, 30 Jun 2020 20:01 GMT
  • Updated: Tue, 25 Aug 2020 17:40 GMT

DataRepresentationQosPolicy default

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    7.6.3.1.1 ends with
    "The default value of the DataRepresentationQosPolicy shall be an empty list of preferences.
    An empty list of preferences shall be taken to be equivalent to a list containing the single element XCDR"

    This contradicts the rest of the section which describes how XCDR (v1) is optional. The default should be XCDR2.

  • Reported: DDS-XTypes 1.3 — Tue, 28 Jul 2020 19:37 GMT
  • Updated: Tue, 25 Aug 2020 16:15 GMT

Specify that TypeLookup Service uses XCDR2

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    7.6.3.3.3 defines built-in RTPS Endpoints for TypeLookup, but doesn't specify their Data Representation. Since TypeLookup is new, this should be XCDR2.

  • Reported: DDS-XTypes 1.3 — Tue, 28 Jul 2020 19:45 GMT
  • Updated: Mon, 24 Aug 2020 19:22 GMT

XTypes spec is missing topic names for TypeLookupService

  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    In section 7.6.2.3, that introduces the TypeLookupService, the datatypes used for exchanging TypeLookupRequests and TypeLookupResponse are introduced, and so are the endpoints used to exchange them.
    However, what is missing is the topic names used for the topics carrying these requests and their responses. Technically you might not need the topic names to build an interoperable implementation, because the endpoints are builtin endpoints and therefore don't need to be matched, but nevertheless, the topic will need to have a name and the name might as well be part of the spec.

  • Reported: DDS-XTypes 1.3 — Thu, 4 Jun 2020 20:51 GMT
  • Updated: Tue, 28 Jul 2020 19:28 GMT

Missing alignment for XCDR1 mutable's sentinel

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Rule 23 is missing "ALIGN(4)" before PID_SENTINEL

    // Structures with extensibility MUTABLE, version 1 encoding
    (23) XCDR[1] << {O : MSTRUCT_TYPE} =
    XCDR
    << { O.member[i] : MMEMBER }*
    << { PID_SENTINEL : UInt16 }
    << { length = 0 : UInt16 }
    
  • Reported: DDS-XTypes 1.3b1 — Mon, 29 Jun 2020 23:27 GMT
  • Updated: Wed, 8 Jul 2020 04:16 GMT

Mapping of one single Topic per Service does not work well with DDS Security

  • Key: DDSRPC11-1
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    This issue has also been entered into DDS-Security as the solution could also involve changes to that specification. See:
    https://issues.omg.org/browse/DDSSEC12-31

    DDS-RPC maps each DDS-Service to a single (unkeyed) Topic-pair (request topic & reply Topic).

    DDS-Security provides access control per Topic and per Instance (Key). Moreover, the builtin plugins only provide access control per Topic.

    With these mappings is it not possible to configure access control per operation/method in the service. This is a common requirement for many service definitions.

    One way to overcome this would be to provide a mapping where each a Service would map to multiple Topic pairs. E.g. one Topic pair per method/operation. That way it would be possible to separately grant permissions to call operations on a service or to implement operations on a service.

    The mapping of a Topic pair per method/operation would also setting different Qos per operation...

    Alternatively one could

  • Reported: DDS-RPC 1.0 — Tue, 28 Aug 2018 23:45 GMT
  • Updated: Wed, 24 Jun 2020 17:36 GMT

Listener model breaks API design goal of automatic resource management

  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The way the C++ PSM modeled listeners has proven problematic. While the whole language binding is designed to provide automatic resource management, listeners break that model. Listeners are assigned to a DDS Entity as a raw pointer and “retain” the Entity.

    Because an Entity with a listener is retained, the user must manually reset the listener to allow its automatic destruction or explicitly close the entity. This defeats the purpose of automatic resource management, forcing users to write exception-safe code or risk “leaking” the resource.

    RTI proposes a change in how listeners are set. In summary:

    1) Listeners are set as std::shared_ptr's. All APIs change to receive a std::shared_ptr<Listener> instead of a Listener*
    2) Listeners no longer retain the entity. (It's the other way around; the Entity keeps a reference to its listener, which ensures the listener is not deleted). 

    Note that an entity can be explicitly retained with the member function retain(), which allows preserving the old behavior quite easily.

    The changes, affecting all dds::core::Entity-derived types, are the following:
     

    Previous API (usable but deprecated) New API
    Constructor with Listener* argument Constructor with std::shared_ptr<Listener>
    Listener setter: listener(Listener*, StatusMask) Listener setter: set_listener(std::shared_ptr<Listener>, StatusMask)
     (not available) Listener setter with no mask, added for convenience: set_listener(std::shared_ptr<Listener>) // Defaults to all() when the listener is not null or none() when it’s null
    Listener getter: Listener * listener() const  Listener getter: std::shared_ptr<Listener> get_listener() const

    Notice the name change—the overloaded listener is now get_listener/set_listener. A new overload wasn’t possible because the getter would only differ on the return type.

    Implementations that do not support C++11 can offer the old listener model.
     
    Example:

    // Previous API:
    MyListener *my_listener = new MyListener();
    reader.listener(my_listener, StatusMask::all());
    // ...
    reader.listener(NULL, StatusMask::none()); // user must reset the listener to destroy entity
    delete my_listener;
    
    // New API:
    auto my_listener = std::make_shared<MyListener>();
    reader.set_listener(my_listener);// No manual resource management required anymore
    
    // Or simply:
    reader.set_listener(std::make_shared<MyListener>());
     

     

  • Reported: DDS-PSM-Cxx 1.0b2 — Sun, 14 Jun 2020 19:45 GMT
  • Updated: Mon, 15 Jun 2020 23:32 GMT

Typo fixes

  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    p3 section 5 table 1st row right column

    [...] Given two programming language type T and Q,

    -> types

    p5 7.1 1st para 3rd line

    [...] language today universally sup- ported by C++ compilers.

    -> supported

    p5 7.2 1st para 3rd sentence

    The specification defines
    type constructors, i.e., parameterized class, that delegate

    -> classes

    p6 7.2 cont'd

    Under no circumstances a vendor shall change [...]. The only action performed by
    type constructor is to delegate their implementation

    -> constructors

    p6 7.3 2nd bullet

    * Loand-based read/take operation shall be exception safe.

    -> Loan based

    p7 7.4.1 MappingClasses (title)
    -> Mapping Classes

    p10 7.4.5 3rd table

    [left column] PIM Native Return Type

    -> PIM Return Type

    [right column] One of the following, depending on wether

    -> whether

    p12 Table 7-2 Namespace 2nd column 2nd row

    pomain

    -> domain

    p13 7.5.2 end of 1st sentence and 2nd sentence

    (note that for immutable value-types the only form of change is to create
    a new value- type).
    The DDS-PSM-Cxx models all DDS PIM classes [...] as value- types.

    -> value-type, value-types (remove space after hyphen)

    p14 top of page sentence preceding 7.5.5

    The full set of status classes is includes in the mandatory standard headers [...]

    -> included

    p16 7.6.2.1 1st para 3rd sentence

    As an
    example, from the URI ” the QosProvider would deduce [...]

    Please clarify - the single quotation mark is not a valid URI.
    I suspect the following might be intended:
    {{As an example, from the URI "file://" the QosProvider would deduce [...]}

    p18 7.8 1st sentence

    The topic packaged defines the classes related to [...]

    -> package

    p18 7.8 6th para

    If the topic is to be created with a QoS different from the default, than the code [...]

    -> from the default then

  • Reported: DDS-PSM-Cxx 1.0 — Sun, 9 Feb 2020 19:39 GMT
  • Updated: Fri, 12 Jun 2020 06:31 GMT

Can structures contain constant declarations?

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.3.2.5.1 'Structures' states:

    Structures contain four kinds of declarations:
    • Applied annotations
    • Verbatim text
    • Members
    • Constants

    However section 7.3.1.10 'Structure Types' states:

    Structures as described in this specification are fully compatible with the IDL constructs of the same name.

    IDL (4.3) does not allow constant declarations inside structures. So these two statements are incompatible.

    Also the UML model in 7.2.2.4.4.2 'Structure Types' states structures contain only members. And constant declarations are not members.

    Therefore it seems like the text in Section 7.3.2.5.1 should be modified to remove the bullet about constants.

  • Reported: DDS-XTypes 1.3b1 — Wed, 10 Jun 2020 23:26 GMT
  • Updated: Wed, 10 Jun 2020 23:26 GMT

Editorial corrections

  • Key: DDS15-313
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    p2 5th para middle sentence

    The purpose of the DDS specification is to
    define the standardized interfaces and behaviors that enable applicaton portability.

    -> application



    p11 Figure 2.5 bottom right class box,
    p58 Figure 2.10 bottom middle class box,
    p125 Figure 2.19 middle right class box

    QueryConditon

    -> QueryCondition



    p61 2.2.2.5.1.4 1st para 3rd sentence

    change of state for an intance that was caused by some internal mechanism

    -> instance



    p61 2.2.2.5.1.4 1st para 4th sentence

    An example of this situation is when the Service [...] and changes the coresponding

    -> corresponding



    p61 2.2.2.5.1.4 2nd para 2nd sentence

    The application can distinguish wether a particular DataSample has data

    -> whether



    (DDS15-195)
    p61 2.2.2.5.1.4 3rd para 1st sentence

    To ensure corerctness and portability, the valid_data flag must be examined

    -> correctness

    p107 2.2.3.13 4th para 3rd sentence

    It may establish new "matchs" that did not exist before, or break existing matchs.

    -> "matches" , matches.



    p110 2nd para 2nd sentence

    [...] For example setting
    max_samples_per_instance to LENGH_UNLIMITED will cause the middleware to [...]

    -> LENGTH_UNLIMITED



    p120 2.2.4.2.2 enumerated list 2nd bullet 2nd sub-bullet

    • the DataWriter that owns it if OWNERSHIP QoS kind=EXLUSIVE, or by

    -> kind=EXCLUSIVE



    p121 Figure 2.16 statebox at right

    StatiusChangedFlag = TRUE

    -> StatusChangedFlag



    p166 top

    Selection        ::=    TOPICNAME
                     |      TOPICTNAME NaturalJoin JoinItem
    

    -> TOPICNAME NaturalJoin JoinItem

  • Reported: DDS 1.4 — Mon, 11 May 2020 03:39 GMT
  • Updated: Thu, 28 May 2020 20:35 GMT

Typo

  • Key: DDS15-199
  • Status: open  
  • Source: Netherlands Aerospace Centre ( Arnoud van Leeuwen)
  • Summary:

    Suspected typo in paragraph 4, last scentece:
    "In other words, the DataReader may miss some data-samples but it will never see the
    value of a data-object change from a newer value to an order value."

    Should the second to last word "order", not be: "older"? The context seems to suggest so.

  • Reported: DDS 1.4 — Fri, 19 Aug 2016 07:53 GMT
  • Updated: Mon, 11 May 2020 03:42 GMT

Default value for WRITER_DATA _LIFECYCLE v should be FALSE

  • Key: DDS15-312
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    According to the Qos table in 2.2.3 'Supported QoS' the default value for autodispose_unregistered_instance is TRUE. We have found a two issues with this

    (1) It is not semantically what people expect. Just because a DataWriter is deleted it does not mean all the instances should be deleted... It could be so for some use-cases, but we found that in the majority of the use-cases it is not an intuitive behavior.

    (2) It is not scalable. If writer with a lot of instances is deleted. it needs to send many messages and potentially wait until they are acknowledged before releasing the DataWriter resources. This makes the data-writer delete operation something that can block for an unbounded time which is not what applications expect.

    It sees it would be better to:
    (a) Change the default value of autodispose_unregistered_instance to FALSE.
    (b) Provide a better/more efficient/scalable way to communicate to the DataReaders that all the instances of a DataWriter have been deleted.

  • Reported: DDS 1.4 — Thu, 30 Apr 2020 21:02 GMT
  • Updated: Fri, 8 May 2020 12:32 GMT

DynamicType should be a value type, not a reference type

  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    A type description is conceptually a value type, not a reference type. A type doesn't have a special identity, like for example a DomainParticipant. A type description can be copied, compared for equality, passed by value, etc. That doesn't preclude applications from using a shared_ptr<DynamicType> if they want to.

  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 28 Apr 2020 21:26 GMT
  • Updated: Tue, 28 Apr 2020 21:26 GMT

Confusing description of FINAL on 7.2.3 TypeExtensibilityandMutability

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In this section there is a bullet stating:

    • A type may be FINAL, indicating that the range of its possible data values is strictly defined. In particular, it is not possible to add elements to members of collection or aggregated types while maintaining type assignability.

    This is confusing. What does it mean that " the range of its possible data values is strictly defined"?
    Moreover, it talks about collection types where Table 12 says that for these types the extensibility kind has no effect.

    It sis recommended that this bullet is rephrased to just say that members cannot be added, removed or reordered.

  • Reported: DDS-XTypes 1.3b1 — Sat, 4 Apr 2020 00:03 GMT
  • Updated: Sat, 4 Apr 2020 00:03 GMT

Add a function that allows releasing any resources created by the DomainParticipantFactory

  • Key: DDS15-311
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Domain Participant Factory may create resources (e.g. tables that allow looking up or manage created domain participants, etc.)

    These resources need to be released when the application shuts down so that they are not reported as "leaks" by the OS.

    A function should be added that forcefully releases all resources created by the DomainParticipantFactory. This function would have as a pre-requisite that all DomainParticipants have been deleted...

  • Reported: DDS 1.4 — Fri, 27 Mar 2020 21:46 GMT
  • Updated: Fri, 27 Mar 2020 21:46 GMT

Define Implied Keys Behavior

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    1. In 7.6.8, the algorithm for creating a KeyHolder states that:

    If there are any key members, then remove the non-key members from FooKeyHolder. Otherwise do not remove any members.

    This seems to say that if there are no fields marked as keys, leave all of them open to be able to be used as keys. That would be consistent with implied key behavior.

    2. There is an example of implied @key in Annex D, where the TopicData types specify BuiltinTopicKey_t as a key, but the single member of BuiltinTopicKey_t is not marked as a key.

    3. At the same time 7.2.2.4.4.4.8 says:

    If a given type has no members designated as key members, then the type—and any DDS Topic that is constructed using it as its type it—has no key.

    It also says that:

    In the event that the type K of a key member of a given type T itself defines key members, only the key of K, and not any other of its members, shall be considered part of the key of T.

    This doesn't go against implied keys, but would be a good place to mention them in addition to the previous sentence.

    4. 7.3.1.2.1.3 says that:

    To declare a member as part of the key, users shall apply the @key annotation...

    7.2.2.4.4.4.8 and 7.3.1.2.1.3 seem to have been written under the assumption that @keys can't be implied. If the specification actually requires this, which it appears that it does given Annex D, then it should say so in those two sections.

    Finally, a couple thoughts/questions came up about implied keys behavior since it is not defined in the spec:

    1. Given a situation like:

    @nested(TRUE)
    struct A

    { @key(FALSE) long a1; long a2; }

    ;

    @nested(FALSE)
    struct B

    { @key A b1; }

    ;

    Shouldn’t a2 be the only element of the key of B, because we’re explicitly saying a1 isn’t part of the key?

    2. Should implied key behavior (potentially including the behavior in the previous point) apply to union discriminators? For example:

    @nested(TRUE)
    union TestUnion switch (long)

    { // ... };

    @nested(TRUE)
    union KeyedTestUnion switch (@key long) { // ... }

    ;

    @nested(TRUE)
    union KeyedFalseTestUnion switch (@key(FALSE) long)

    { // ... }

    ;

    @nested(TRUE)
    struct A

    { TestUnion a1; // discriminator is implied to be part of the key of B KeyedTestUnion a2; // discriminator is explicitly part of the key of B KeyedFalseTestUnion a3; // Not part of the key of B }

    ;

    @nested(FALSE)
    struct B

    { @key TestUnion b1; // discriminator is implied to be part of the key @key KeyedTestUnion b2; // discriminator is explicitly part of the key @key KeyedFalseTestUnion b3; // Not part of the key, maybe an implementation could give a warning? @key A b4; }

    ;

  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 13:53 GMT
  • Updated: Tue, 24 Mar 2020 14:29 GMT

7.4.3.5.3 doesn't define OPTIONS

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    This section should have an explanation or cross-reference to describe what <OPTIONS> is (used in 1st encoding rule in the section)

  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 14:26 GMT
  • Updated: Tue, 24 Mar 2020 14:29 GMT

Be more precise on meaning of string lengths and bounds

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section 7.2.2.2.1.2.4 String<Char8> type
    The specification does not provide a description of the "length" and "bound" values shown in Figure 9.

    In the case of strings, specially String8, there is an ambiguity on whether the "bound" and "length" represent the number of characters, or the number of bytes in the UTF-8 encoding mentioned in 7.2.2.2.1.2.4, or something else.

    an interpretation of the length of the string.

  • Reported: DDS-XTypes 1.3b1 — Thu, 19 Mar 2020 20:23 GMT
  • Updated: Tue, 24 Mar 2020 14:01 GMT

Implementation Defined Default Nested Behavior

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    7.3.1.2.1.7 Nested Types

    By default, aggregated types and aliases to aggregated types defined in IDL are not considered to be nested types.

    ...

    If not present on a module, the value defaults to that of the enclosing module. If a top -level module is not annotated, the default is FALSE.

    ...

    In addition to the above annotations, IDL compilers shall provide the means to change the default value for non-annotated top-level modules.

    Given the fourth sentence, the first and third sentences should also say the nested status of a non-annotated type is implementation defined.

  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 13:55 GMT
  • Updated: Tue, 24 Mar 2020 13:55 GMT

get_discovered_participant_data() should return BAD_PARAMETER instead of PRECONDITION_NOT_MET

  • Key: DDS15-310
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This issue has to do with the proper code when the function
    get_discovered_participant_data gets passed an invalid handle.

    This function is analogous to get_matched_subscription_data() and get_matched_publication_data() except that that it retrieves information on the matching participant instead of the matching endpoint. All these functions take a handle as an input that refers to the "matching" entity for which information is
    being retrieved.

    Prior to version 1.2 get_matched_subscription_data() was returning PRECONDITION_NOT_MET and get_matched_publication_data BAD_PARAMETER.
    Returning BAD_PARAMETER seemed more appropriate so in version 1.2 (OMG issue 9500) we updated get_matched_subscription_data to also return BAD_PARAMETER.

    However get_discovered_participant_data() was not updated as part of is still returning PRECONDITION_NOT_MET.

    Therefore get_discovered_participant_data() should be updated to also return BAD_PARAMETER when an invalid handle is passed.

  • Reported: DDS 1.4 — Fri, 28 Feb 2020 20:31 GMT
  • Updated: Fri, 28 Feb 2020 20:31 GMT

Need to add an ignore_enum_literal_names in TypeConsistencyEnforcement QosPolicy