Diagram Definition Avatar
  1. OMG Specification

Diagram Definition — Open Issues

  • Acronym: DD
  • Issues Count: 460
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
DDS15-329 set_listener behavior is underspecified DDS 1.4 open
DDSSEC12-94 Provide pre-shared protection for unauthenticated messages DDS-SECURITY 1.1b1 open
DDSIRTP26-6 Network amplification DDSI-RTPS 2.5 open
DDSXTY14-38 Data Representation for RTPS's Serialized Key DDS-XTypes 1.3 open
DDSXTY14-54 Impossible to handle @must_understand AND @optional fields in an @appendable struct correctly DDS-XTypes 1.3b1 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
DDSSEC12-90 Meeting CNSSP-15 security requirements DDS-SECURITY 1.1b1 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
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-59 Clarify accessing discriminator of a DynamicData union 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
DDSSEC12-99 Update parameters of check_remote_datawriter_register_instance DDS-SECURITY 1.1 open
DDSSEC12-27 ParticipantStatelessMessage definition DDS-SECURITY 1.1b1 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
DDSXTY14-56 XCDR2 serialization of sequences of non-primitive elements DDS-XTypes 1.3b1 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
DDS15-320 Missing escaping rules for filter expression, topic expression, query expression 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
DDSXTY14-53 Description on how to encode Participant GUID in dds::rpc::RequestHeader seems wrong DDS-XTypes 1.3b1 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
DDSSEC12-29 Specify DDS Security uses XCDR serialization version 1 DDS-SECURITY 1.1b1 open
DDSSEC12-62 Indicate that AccessControl operations need to be called on a set_qos DDS-SECURITY 1.1b1 open
DDSSEC12-79 Built-in Access Control: interpretation of enable_read/write_access_control DDS-SECURITY 1.1 open
DDSSEC12-92 Underspecified RSASSA-PSS-SHA256 Salt Length DDS-SECURITY 1.1b1 open
DDSSEC12-53 Clarify meaning of "bit array" and specify number of constant bytes in HMAC input when computing SessionKey DDS-SECURITY 1.1b1 open
DDSSEC12-14 CryptoTransformIdentifier extensibility FINAL is not compatibly with its derived classes DDS-SECURITY 1.1 open
DDSSEC12-3 Provide mechanisms to extend Governance and Permissions files without breaking interoperability DDS-SECURITY 1.0b1 open
DDS15-245 Clarify the PartitionQosPolicy DDS 1.4 open
DDSSEC12-89 Add return_permissions_handle to the AccessControl interface DDS-SECURITY 1.1 open
DDSSEC12-56 Encoding of Diffie-Hellman Public Key DDS-SECURITY 1.1b1 open
DDSSEC12-55 Using string literals as binary_property values inside Handshake Tokens DDS-SECURITY 1.1b1 open
DDSIRTP26-7 Provide a pre-shared key protection mechanism DDSI-RTPS 2.5 open
DDSSEC12-93 Add best practice/implementation guidelines to the CryptoTransform plugin DDS-SECURITY 1.1b1 open
DDSSEC12-59 Parsing messages generated by encode_serialized_payload (auth only) DDS-SECURITY 1.1b1 open
DDSSEC12-33 Use a submessage flag to indicate Data/Frag submessage has a transformed payload DDS-SECURITY 1.1b1 open
DDSSEC12-91 How are 'subject_name' fields compared? DDS-SECURITY 1.1 open
DDSSEC12-85 check_remote_participant when default is ALLOW DDS-SECURITY 1.1b1 open
DDSSEC12-49 Mutability of PartitionQos DDS-SECURITY 1.1b1 open
DDSSEC12-28 Determining when to use DCPSParticipantMessageSecure DDS-SECURITY 1.1b1 open
DDSSEC12-32 Authentication behavior use of built-in endpoints DDS-SECURITY 1.1b1 open
DDSSEC12-18 Authentication interface begin_handshake_reply() DDS-SECURITY 1.1b1 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-47 Encoding of TypeInformation in SEDP DDS-XTypes 1.3 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
DDSIRTP26-4 Inconsiastent notation used to represent bit positions pictorially DDSI-RTPS 2.5 open
DDSIRTP26-3 SequenceNumberSet validity could be too strict DDSI-RTPS 2.3 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
DDSXTY13-84 Typo in DataRepresentationMask DDS-XTypes 1.3 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
DDSSEC12-15 DataHolder IDL inconsistent DDS-SECURITY 1.1b1 open
DDSSEC12-88 Size of permission file sent on authentication can exceed max IP packet size DDS-SECURITY 1.1b1 open
DDS15-314 Change the default value for DataWriterLifecycle::autodispose_unregistered_instances and behavior when a DataWriter is deleted DDS 1.4 open
DDSSEC12-86 Security for XTypes TypeLookup Service DDS-SECURITY 1.1 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
DDSSEC12-74 Builtin Access Control operations (Table 63) missing entries DDS-SECURITY 1.1 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
DDSSEC12-84 The Qos used to publish the BuiltinLoggingTopic is not specicified DDS-SECURITY 1.1b1 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-16 Spec text unclear 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
DDSSEC12-83 class_id string in Authentication/Permissions Tokens should include spec version DDS-SECURITY 1.1b1 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
DDSSEC12-82 encode_rtps_message/decode_rtps_message error and status reporting DDS-SECURITY 1.1 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
DDSSEC12-12 Instance-Level access-control DDS-SECURITY 1.1 open
DDS15-266 Organize definitions of Time_t, Duration_t and other common types in the PIM DDS 1.4 open
DDSSEC12-81 Authentication Protocol: Make what is validated in the messages more explicit DDS-SECURITY 1.1b1 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
DDSSEC12-70 Protecting the Source Timestamp DDS-SECURITY 1.1b1 open
DDSSEC12-58 AES-GCM doesn't add padding DDS-SECURITY 1.1b1 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
DDSSEC12-80 Add support for ChaCha20 DDS-SECURITY 1.1b1 open
DD12_-6 Consider possibility of adding Port concept to DI DD 1.0 open
DD12_-5 Constraints DD 1.0b1 open
DD12_-4 Why does A_style_canvas have no name? DD 1.1 open
DD12_-3 Small typo. DD 1.0 open
DD12_-2 Small typos. DD 1.0 open
DD12_-1 A_style_canvas Association is unnamed DD 1.1 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
DDSSEC12-42 Various Typos DDS-SECURITY 1.1b1 open
DDSXML11-1 Fix a number of typos in specification document DDS-XML 1.0 open
DDSSEC12-13 Avoid sending permissions as part of Authentication Handshake DDS-SECURITY 1.1 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_-4 DynamicData should be value type, not a reference type 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
DDSSEC12-77 Invalid IETF RFC document reference. DDS-SECURITY 1.1b1 open
DDSSEC12-75 Errors in non-normative IDL of section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types DDS-SECURITY 1.1b1 open
DDSSEC12-76 IDL should be updated to match IDL 4.2 DDS-SECURITY 1.1b1 open
DDS15-242 set_expression_parameters on ContentFilteredTopic, MultiTopic DDS 1.4 open
DDSSEC12-73 Multiple grants in a permissions document DDS-SECURITY 1.1b1 open
DDSSEC12-72 serialized_local_participant_data passed to Auth plugin DDS-SECURITY 1.1b1 open
DDS15-241 Clarify when a dispose or unregister may be omitted for a Reader DDS 1.4 open
DDSSEC12-71 Inconsistent descriptions of Data Tagging DDS-SECURITY 1.1b1 open
DDSSEC12-69 Builtin Auth dependency on Access Control details DDS-SECURITY 1.1b1 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
DDSSEC12-68 Add explanation of how to use the secureWriterSet to support GROUP ordered access DDS-SECURITY 1.1b1 open
DDSSEC12-67 Misleading description of Crypto Key Exchange (8.5.1.8) DDS-SECURITY 1.1b1 open
DDSSEC12-66 IDL struct ParticipantSecurityAttributes contains ac_endpoint_properties DDS-SECURITY 1.1b1 open
DDSSEC12-65 validate_remote_permissions interaction with Authentication Plugin DDS-SECURITY 1.1b1 open
DDSSEC12-64 get_topic_sec_attributes 3rd parameter type DDS-SECURITY 1.1b1 open
DDSSEC12-63 Operation: set_permissions_credential_and_token DDS-SECURITY 1.1b1 open
DDS15-237 How to handle some GROUP ordered Subcriber scenarios DDS 1.4 open
DDSSEC12-61 Table 29 description of is_write_protected DDS-SECURITY 1.1b1 open
DDSSEC12-60 check_remote_topic domainId parameter DDS-SECURITY 1.1b1 open
DDSSEC12-57 Builtin Crypto message authentication codes DDS-SECURITY 1.1b1 open
DDSSEC12-54 XML Schema defines boolean literals as "true" / "false" DDS-SECURITY 1.1b1 open
DDSSEC12-52 9.5.3.3.4.3 should refer to the footer, not header DDS-SECURITY 1.1b1 open
DDSSEC12-51 Participant2ParticipantKxKeyMaterial DDS-SECURITY 1.1b1 open
DDSSEC12-50 Builtin CryptoKeyFactory direct dependency on AccessControl's config details DDS-SECURITY 1.1b1 open
DDSSEC12-30 8.4.2.9.24 section name typo DDS-SECURITY 1.1b1 open
DDSSEC12-46 "atributes" typo DDS-SECURITY 1.1b1 open
DDSSEC12-48 Clarify the configuration and use of certificate chains for Identity DDS-SECURITY 1.1b1 open
DDSSEC12-41 Reduce the range of Reserved RTPS parameter IDs DDS-SECURITY 1.1b1 open
DDSSEC12-47 Inconsistent Flag Name PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_BUILTIN_IS_DISCOVERY_ENCRYPTED DDS-SECURITY 1.1b1 open
DDS15-236 Request/Offered behavior of DURABILITY Qos does not match use-cases DDS 1.4 open
DDSSEC12-38 Broken cross-references DDS-SECURITY 1.1b1 open
DDSSEC12-45 Replace "CryptoKeyTransform" with "CryptoTransform" DDS-SECURITY 1.1b1 open
DDSSEC12-44 register_local_datareader and Data Protection Kind DDS-SECURITY 1.1b1 open
DDSSEC12-43 IDL ParticipantSecurityAttributes::plugin_participant_attributes DDS-SECURITY 1.1b1 open
DDS15-234 Incorporate common elements from DDS Security to the Builtin Topics DDS 1.4 open
DDSSEC12-40 Return types in CryptoKeyFactory interface description DDS-SECURITY 1.1b1 open
DDSSEC12-39 AuthRequestMessageToken future_challenge property DDS-SECURITY 1.1b1 open
DDSSEC12-2 Built-in Authentication and Cryptography plugins tied together by SharedSecretHandle implementation DDS-SECURITY 1.0b1 open
DDSSEC12-37 Modify Security's QoS changes for compatibility with RTPS DDS-SECURITY 1.1b1 open
DDSSEC12-36 Description of the EndpointSecurityAttributes DDS-SECURITY 1.1b1 open
DDSSEC12-35 Description of the PluginEndpointSecurityAttributes DDS-SECURITY 1.1b1 open
DDSSEC12-34 Wrong XML tag in description of Enable Read Access Control DDS-SECURITY 1.1b1 open
DDSSEC12-31 Security for DDS-RPC DDS-SECURITY 1.1b1 open
DDSSEC12-25 IDL get_topic_sec_attributes parameter typo DDS-SECURITY 1.1b1 open
DDSSEC12-7 The DDS-Security specification makes some modifications to the DDSI-RTPS protocol that should be taken into consideration DDS-SECURITY 1.0 open
DDSSEC12-26 IDL SubscriptionBuiltinTopicDataSecure inheritance DDS-SECURITY 1.1b1 open
DDSSEC12-24 IDL LongLongSeq unused DDS-SECURITY 1.1b1 open
DDSSEC12-23 Authentication interface set_permissions_credential_and_token DDS-SECURITY 1.1b1 open
DDSSEC12-22 get_datawriter/reader_sec_attributes inconsistent IDL DDS-SECURITY 1.1b1 open
DDSSEC12-21 decode_datawriter_submessage uses "in" for SecurityException DDS-SECURITY 1.1b1 open
DDSSEC12-20 SecureSubmessageCategory_t in normative IDL DDS-SECURITY 1.1b1 open
DDSSEC12-19 Allow expressions to be used in the data-tag permissions DDS-SECURITY 1.1 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
DDSSEC12-16 Define rules for references between elements DDS-SECURITY 1.1 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
DDSSEC12-11 say explicitly that is_valid is set to zero if that is case DDS-SECURITY 1.1b1 open
DDSSEC12-5 The UML model should be cleaned up DDS-SECURITY 1.0 open
DDSSEC12-6 Remove Jira-issue related comments from machine-readable files DDS-SECURITY 1.0 open
DDSSEC12-9 The specification should not duplicate (copy) the machine readable XSD files DDS-SECURITY 1.0 open
DDSSEC12-10 Issues with the UML model used in the specification DDS-SECURITY 1.0 open
DDSSEC12-8 Section 3 (Normative References) should be updated and expanded DDS-SECURITY 1.0 open
DDSSEC12-4 Examples of Wildcard permissions DDS-SECURITY 1.0 open
DDSSEC12-1 Complexity of Authentication Plugin Model DDS-SECURITY 1.0b1 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
DDSWEB11-3 Correct inconsistency on the URLs for the machine readable documents in the FTF2 report DDS-WEB 1.0 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
DDC4RTC_-4 The model should us platform-independent data types DDC4RTC 1.0b1 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
DDC4RTC_-2 The XMI includes the UML state machine metamodel DDC4RTC 1.0b1 open
DDC4RTC_-3 All EA – specific content should be removed DDC4RTC 1.0b1 open
DDS4CCM11-3 StateListenerControl:: is_filter_interpreted should be documented as optional DDS4CCM 1.0 open
DDC4RTC_-5 It is not clear how much of the model is normative DDC4RTC 1.0b1 open
DDC4RTC_-1 The type of property RTComponentPortDescription DDC4RTC 1.0b1 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
DDC4RTC_-6 The XMI is invalid and produces many errors at http://syseng.nist.gov/se-interop/sysml/validator/ DDC4RTC 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

set_listener behavior is underspecified

  • Key: DDS15-329
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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

Provide pre-shared protection for unauthenticated messages

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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: DDS-SECURITY 1.1b1 — Fri, 12 Nov 2021 16:28 GMT
  • Updated: Tue, 27 Sep 2022 17:20 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

Data Representation for RTPS's Serialized Key

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( 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, 21 Sep 2022 21:49 GMT

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

  • Status: open   Implementation work Blocked
  • Source: ZettaScale Technology ( 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: Wed, 21 Sep 2022 20:37 GMT

IDL's fixed data type is required in XTypes

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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 ( 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 ( 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

Meeting CNSSP-15 security requirements

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

    The goal of this issues is to identify incorporate any additions that would allow systems built using DDS-Security to meet the CNSSP-15 security requirements.
    https://imlive.s3.amazonaws.com/Federal%20Government/ID151830346965529215587195222610265670631/CNSSP15.pdf)

    This is an important requirements for many systems and we are running into many users that are asking whether DDS-Security can be used to meet CNSSP-15 security requirements.

    It seems like currently the "builtin plugins" are not enough because they do not include support for stronger asymmetric key algorithms. For example when using ECDSA digital signatures the minimal requirement is using 384-bit keys (e,g, NITS's Curve P-384). However the builtin plugins only include support for 256 bit EC keys.

  • Reported: DDS-SECURITY 1.1b1 — Fri, 11 Jun 2021 01:34 GMT
  • Updated: Tue, 20 Sep 2022 02:13 GMT

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: Thu, 1 Sep 2022 18:23 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 ( 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

Clarify accessing discriminator of a DynamicData union

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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, 8 Aug 2022 15:38 GMT

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

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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 ( 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

Update parameters of check_remote_datawriter_register_instance

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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, 24 Jun 2022 19:50 GMT

ParticipantStatelessMessage definition

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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, 3 Jun 2022 20:01 GMT

Align with XTYPES 1.3 and IDL 4.2

  • Key: DDS15-250
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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

XCDR2 serialization of sequences of non-primitive elements

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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 mitmask types should npt 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 all 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: Tue, 10 May 2022 20:48 GMT

Annex A: Ownership Profile is unclear

  • Key: DDS15-328
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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 ( Gerardo Pardo-Castellote)
  • 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 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: Wed, 23 Feb 2022 16:26 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 ( Gerardo Pardo-Castellote)
  • 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 ( 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 ( 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 ( 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 ( Gerardo Pardo-Castellote)
  • 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

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

  • Status: open  
  • Source: ZettaScale Technology ( 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 Dec 2021 15:22 GMT

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

  • Status: open  
  • Source: ZettaScale Technology ( 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

Specify DDS Security uses XCDR serialization version 1

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

    Starting with DDS-XTYPES version 1.2 a data type can be serialized using XCDR version 1 or version 2. This impacts the serialization of APPENDABLE and MUTABLE types. It does not impact the serialization of FINAL types unless they contain 8-byte primitives (long long or double) or optional members.

    DDS-Security was written before DDS-XTYPES 1.2 came out. So all the products are using XCDR version 1.

    Going forward DDS-Security should specify that it always uses XCDR version 1 for serialization of the types defined in the specification.

  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Feb 2018 22:21 GMT
  • Updated: Tue, 14 Dec 2021 01:15 GMT

Indicate that AccessControl operations need to be called on a set_qos

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

    The operations
    check_create_participant
    check_create_datawriter
    check_create_datareader
    check_remote_participant
    check_remote_datawriter
    check_remote_datareader
    check_local_datawriter_match
    check_local_datareader_match

    Should be called when the Qos (or the discovery XXXBuiltinTopicData) change for the one of the involved entities.

    This should be added to the proper 8.4.2.9.x sections.

  • Reported: DDS-SECURITY 1.1b1 — Sat, 9 Jun 2018 00:16 GMT
  • Updated: Thu, 9 Dec 2021 19:16 GMT

Built-in Access Control: interpretation of enable_read/write_access_control

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

    The check_create_participant entry of "Table 63 - Actions undertaken..." in the case where is_access_protected is true and all topic entries in Governance have enable_read_access_control and enable_write_access_control both true specifies that check_create_participant returns false. Thus the participant can't be created and this configuration won't be usable.

    If the intent of enable_read/write_access_control is to defer to the Permissions document to determine both readability and write-ability of this participant (for the given topic) it would seem like this case should be supported and allowed by check_create_participant.

    As part of resolving this issue we should also address DDSSEC12-85, meaning state whether a <default> clause should always be present.

  • Reported: DDS-SECURITY 1.1 — Fri, 16 Nov 2018 23:24 GMT
  • Updated: Thu, 9 Dec 2021 19:03 GMT

Underspecified RSASSA-PSS-SHA256 Salt Length

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

    The DDS Security version 1.1 specification mentions:

    If the Participant Private Key is a RSA key, then:

    The value of the c.dsign_algo property shall be “RSASSA-PSS-SHA256”.
    The digital signature shall be computed using the RSASSA-PSS algorithm specified in PKCS #1 (IETF 3447) RSA Cryptography Specifications Version 2.1 [44], using SHA256 as hash function, and MGF1 with SHA256 (mgf1sha256) as mask generation function.
    This RFC is the one aforementioned. It states:

    This encoding method is parameterized by the choice of hash function, mask generation function, and salt length. These options should be fixed for a given RSA key, except that the salt length can be variable (see [31] for discussion). Suggested hash and mask generation functions are given in Appendix B.

    In the appendix, we can see an example where the salt length is the same as the hash length:

    RSASSA-PSS-params ::= SEQUENCE
    Unknown macro:
    Unknown macro:

    { hashAlgorithm [0] HashAlgorithm DEFAULT sha1, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, saltLength [2] INTEGER DEFAULT 20, trailerField [3] TrailerField DEFAULT trailerFieldBC }

    However, the salt length doesn't have to be the hash length. The WolfSSL and OpenSSL crypto libraries support several options (Openssl doc here and WolfSSL doc here). Our current approach is to use OpenSSL's default option: "maximum permissible value" (pkcsBlockLen - hLen - 2) when signing and auto (detect salt length from the signature) when verifying.

    proposed solution
    The specification should mention the salt length used when generating the signature. Otherwise, it should say that auto must be used when verifying the signature. This would allow interoperability (WolfSSL for example doesn't use auto by default).

  • Reported: DDS-SECURITY 1.1b1 — Thu, 21 Oct 2021 10:02 GMT
  • Updated: Thu, 9 Dec 2021 02:03 GMT

Clarify meaning of "bit array" and specify number of constant bytes in HMAC input when computing SessionKey

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

    The string literal "SessionKey" (and "SessionReceiverKey") is used without additional context as part of the binary input to HMAC. Add to this section that the ASCII encoding of "SessionKey" without a nul terminator is required.

    Section 9.3.3.3.2 talks about a "bit array" type, clarify what that is.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 18:07 GMT
  • Updated: Thu, 9 Dec 2021 01:54 GMT

CryptoTransformIdentifier extensibility FINAL is not compatibly with its derived classes

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

    Section 7.3.7.3 defines CryptoHeader as inheriting from CryptoTransformIdentifier. However CryptoHeader is APPENDABLE and CryptoTransformIdentifier is FINAL.

    This does not seem possible according to XTYPES.

    Other places of the spec (section 9.5.2.3 "DDS:Crypto:AES-GCM-GMAC CryptoHeader") define it as final.

  • Reported: DDS-SECURITY 1.1 — Sat, 16 Dec 2017 04:11 GMT
  • Updated: Tue, 7 Dec 2021 18:51 GMT

Provide mechanisms to extend Governance and Permissions files without breaking interoperability

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

    The specification does not state what to do when Permissions and Governance files contain "extra elements" that are not valid according to the XSD.

    This is expected to occur both as a result of vendor extensions as well as due to additions in future versions of DDS Security.

    Allowing these extensions/additions without breaking compatibility is important. So the spec should be clear in that they are allowed and also provide rules/guidelines on them.

    Some possibilities:

    • Simply state that elements that are not expected/understood should be ignored
    • Same as above but provide some structure for those elements. E.g. specify that they must have a "vendorId" attribute (used to avoid collisions) and a "mustUnderstand" attribute used to force failure in some cases.
    • Define an "extensions" element that has known structure (e.g. name/value pairs) which is the one used for the extensions.
    • Others to be proposed.

    Common approaches are described here: http://www.ibm.com/developerworks/library/x-xtendschema/
    This document also discusses various approaches: https://www.xml.com/pub/a/2004/10/27/extend.html

  • Reported: DDS-SECURITY 1.0b1 — Sat, 20 Feb 2016 01:36 GMT
  • Updated: Tue, 7 Dec 2021 17:15 GMT
  • Attachments:

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

Add return_permissions_handle to the AccessControl interface

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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, 12 Nov 2021 17:50 GMT

Encoding of Diffie-Hellman Public Key

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

    The HandshakeRequestMessageToken's dh1 property (Table 49) contains a Diffie-Hellman Public Key. The text of Table 49 says that this is encoded as a CDR Big Endian Serialization. However, the data type of the Public Key is neither a CDR Built-In type nor specified in IDL. Thus the encoding is underspecified.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 18:33 GMT
  • Updated: Fri, 12 Nov 2021 17:21 GMT

Using string literals as binary_property values inside Handshake Tokens

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

    In the definition of the various Handshake Tokens, certain property values are specified with literal strings in the spec (such as "RSASSA-PSA-SHA256"). Since these are inserted into binary_properties, the spec should describe the encoding: is there a length prefix (like CDR string?), is there a trailing nul (like CDR string?), assume the encoding is ASCII but it would be good to specify this.

  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 18:24 GMT
  • Updated: Fri, 12 Nov 2021 17:18 GMT

Provide a pre-shared key protection mechanism

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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

Add best practice/implementation guidelines to the CryptoTransform plugin

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

    It would be helpful to implementors to include some known implementation best-practices in the CryptoTransform

  • Reported: DDS-SECURITY 1.1b1 — Fri, 22 Oct 2021 08:43 GMT
  • Updated: Fri, 22 Oct 2021 08:46 GMT

Parsing messages generated by encode_serialized_payload (auth only)

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Thu, 21 Oct 2021 13:29 GMT

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

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Thu, 21 Oct 2021 13:11 GMT

How are 'subject_name' fields compared?

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

    In 9.4.1.3.2 Grant Section, the spec states:

    "A permissions [sic, should be grant] Section with a subject name that does not match the subject name given in the corresponding Authorization certificate shall be ignored."

    It is not clear what algorithm should be applied to determine if two subject_names "match"; and this has interoperability implications.

    A 'simple' approach would be a simple string comparison.

    A 'complex' approach would be to do the following:

    1) parse each subject_name as a series of name=value pairs,
    2) check that all name's exist in each subject_name
    3) check that for each name, the corresponding 'value' matches, using regex (for example fnmatch(), or similar) processing.

    The more complex approach might be beneficial, because it could support using a 'wildcard' Common Name. For example, in the permissions file, use a Subject Name like this:

          <subject_name>/C=US/ST=CO/O=Twin Oaks Computing/CN=*.twinoakscomputing.com/emailAddress=support@twinoakscomputing.com</subject_name>
    

    Then, the Identity Cert's could be constructed with a more specific Subject Name, like "CN=participant1.twinoakscomputing.com", and it would match.

  • Reported: DDS-SECURITY 1.1 — Tue, 22 Jun 2021 21:09 GMT
  • Updated: Thu, 21 Oct 2021 10:50 GMT

check_remote_participant when default is ALLOW

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

    The check_remote_participant row of Table 63 contains the text:

    If the Permissions document contains a Grant for the remote
    DomainParticipant and the Grant contains an allow rule on the
    DomainParticipant domain_id, then the operation shall succeed and
    return TRUE.

    It seems like the intent is to ensure that there is some possible Action that this participant can do in the domain. That should take into account a <default>ALLOW</default> permission.

    In general the <default> XML element seems to be not fully/consistently described in the section for Built-In Access Control. The xsd says it must be present, but section 9.4.1.3.2.3 says it may not be.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 23 Jun 2020 04:13 GMT
  • Updated: Thu, 21 Oct 2021 10:39 GMT

Mutability of PartitionQos

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

    In 7.3.5 (Immutability of Publisher Partition Qos in combination with non-volatile...)

    The criteria (1) is not consistent with the goal stated at the end of the section about "prevents data that was published while the DataWriter had associated a set of Partitions from being sent to DataReaders that were not matching before the Partition change and match after the Partition is changed."

    To accomplish this criteria (1) should be re-stated to say this impacts if the Topic associated with the DataWriter has TopicSecurityAttributes with is_read_protected set to TRUE.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 10 Apr 2018 00:03 GMT
  • Updated: Thu, 21 Oct 2021 09:34 GMT

Determining when to use DCPSParticipantMessageSecure

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Wed, 20 Oct 2021 14:30 GMT

Authentication behavior use of built-in endpoints

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Wed, 20 Oct 2021 13:56 GMT

Authentication interface begin_handshake_reply()

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Wed, 20 Oct 2021 13:46 GMT

Missing TK_INT8 and TK_UINT8 in the IDL machine readable file

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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 ( Gerardo Pardo-Castellote)
  • 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 ( 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 ( 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

Encoding of TypeInformation in SEDP

  • Status: open  
  • Source: Kongsberg Defence & Aerospace ( 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: Thu, 17 Jun 2021 20:19 GMT

TypeLookup IDL Inconsistency

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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 ( 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 ( 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 ( Gerardo Pardo-Castellote)
  • 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

Inconsiastent notation used to represent bit positions pictorially

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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: Thu, 10 Jun 2021 22:20 GMT

SequenceNumberSet validity could be too strict

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Mon, 7 Jun 2021 22:55 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. ( 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 ( Gerardo Pardo-Castellote)
  • 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

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, 1 Apr 2021 15:50 GMT

DDS Entities should have a name

  • Key: DDS15-28
  • Legacy Issue Number: 16029
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • 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 ( 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 ( 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 ( 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 ( 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

DataHolder IDL inconsistent

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Tue, 15 Sep 2020 18:38 GMT

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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: Sun, 13 Sep 2020 19:22 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 ( 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

Security for XTypes TypeLookup Service

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

    XTypes defines 4 new built-in endpoints for its TypeLookup Service. DDS-Security should define secure versions of these, just like the secure versions of discovery built-in endpoints.

  • Reported: DDS-SECURITY 1.1 — Fri, 26 Jun 2020 20:30 GMT
  • Updated: Fri, 28 Aug 2020 18:36 GMT

Enums with different holder types should not be assignable

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( Alex 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

Builtin Access Control operations (Table 63) missing entries

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Sun, 21 Jun 2020 22:40 GMT

Listener model breaks API design goal of automatic resource management

  • Status: open  
  • Source: Real-Time Innovations ( Alex 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 ( Oliver 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 ( Gerardo Pardo-Castellote)
  • 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 ( Oliver 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 ( Gerardo Pardo-Castellote)
  • 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 ( Alex 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 ( Gerardo Pardo-Castellote)
  • 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 ( Gerardo Pardo-Castellote)
  • 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

The Qos used to publish the BuiltinLoggingTopic is not specicified

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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: Thu, 26 Mar 2020 16:48 GMT

Define Implied Keys Behavior

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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 ( 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

Spec text unclear

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

    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.

  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 14:03 GMT
  • Updated: Tue, 24 Mar 2020 14:03 GMT

Be more precise on meaning of string lengths and bounds

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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 ( 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 ( Gerardo Pardo-Castellote)
  • 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

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

    The type assignability rules for Enumerated Types require knowledge of whether the literal names should be considered for assignability.

    Right now this can only be configured when the type is declared using the @ignore_literal_names annotation. However in some cases it may be necessary to change this behavior at run-time for a particular DataReader.

    To support this use-case it would be helpful to add a ignore_enum_literal_names field to the TypeConsistencyEnforcement QosPolicy

  • Reported: DDS-XTypes 1.3b1 — Sat, 2 Mar 2019 00:27 GMT
  • Updated: Fri, 21 Feb 2020 16:27 GMT

Clarify whether the algorithm to compute KeyHash is specific to XTYPES

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

    In 7.6.8 'Interoperability of Keyed Topics' it states:

    As described in [RTPS] Clause 9.6.3.8, “KeyHash (PID_KEY_HASH)”, the key hash for a given object of a keyed type is obtained by first serializing the values of the key members in their declaration order. The algorithm described in that clause shall be amended as described below.

    It is not clear whether the intent is that this modification impacts only implementors of the DDS-XTYPES or whether it is intended as a change in RTPS (which would require an issue filed on the DDSI-RTPS specification).

  • Reported: DDS-XTypes 1.3b1 — Fri, 8 Mar 2019 04:13 GMT
  • Updated: Fri, 21 Feb 2020 16:27 GMT

Missing parameter in Annex C operation DynamicDataFactory::create_data

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

    The IDL declaration of interface DynamicDataFactory in Annex C, declares the operation with no arguments.

    However according to section 7.5.2.10 'DynamicDataFactory' the operation takes a parameter of type DynamicType. Therefore the correct IDL declaration should have been:

            DynamicData create_data(in DynamicType);
    
  • Reported: DDS-XTypes 1.3b1 — Thu, 14 Mar 2019 04:11 GMT
  • Updated: Fri, 21 Feb 2020 16:26 GMT

Extra text left in section 7.2.2.4.4.4.4 Member IDs

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

    In DDS-XTYPES 1.3 there was an issue (https://issues.omg.org/browse/DDSXTY13-2) whose resolution added the precise specification of the computation of the memberId. This is now in section 7.3.1.2.1.1 'Member IDs' specifically the three-step algorithm towards the end of the section.

    This algorithm fully uses 32 bits. The 4 MSB are set to zero and the remaining 28 bits computed from a hash. Because of this there is no longer a 'reserved range' for memberIds.

    However the resolution of DDSXTY13-2 still left some text in section 7.2.2.4.4.4.4 that talks about reserved ranges. This text should also have been removed. In fact it seems that there was an instruction in DDSXTY13-2 to remove the paragraph but it either was not applied correctly or it missed a sentence that followed the paragraph. To correct it, the following text should be removed from section 7.2.2.4.4.4.4 'Member IDs'

    The remaining part of the member ID range—from 0 to 268,402,687 (0x0FFFBFFF)—is available for use by application-defined types compliant with this specification.

  • Reported: DDS-XTypes 1.3b1 — Fri, 21 Feb 2020 00:40 GMT
  • Updated: Fri, 21 Feb 2020 00:40 GMT

Typos and Inconsistencies

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

    Section 2 lists four conformance points that are later on explained in Table 2.1:

    • OPC UA to DDS Mapping Basic Conformance
    • OPC UA to DDS Mapping Complete Conformance
    • DDS to OPC UA Mapping Basic Conformance
    • OPC UA to DDS Mapping Complete Conformance

    The last bullet point should be "DDS to OPC UA Mapping Complete Conformance" instead of "OPC UA to DDS Mapping Complete Conformance".

  • Reported: DDS-OPCUA 1.0 — Tue, 11 Feb 2020 17:00 GMT
  • Updated: Tue, 11 Feb 2020 21:29 GMT

class_id string in Authentication/Permissions Tokens should include spec version

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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: Tue, 17 Dec 2019 00:51 GMT

Extra fields in IDL of 7.8.2.1 create_client

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

    The CLIENT_Representation contains an extra field client_timestamp that is not in the IDL defined in Annex A.

    The AGENT_Representation contains an extra field agent_timestamp that is not in the IDL defined in Annex A.

  • Reported: DDS-XRCE 1.0 — Tue, 29 Oct 2019 01:29 GMT
  • Updated: Tue, 29 Oct 2019 01:29 GMT

Extra fields in IDL of 7.8.2.1 create_client

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

    The CLIENT_Representation contains an extra field client_timestamp that is not in the IDL defined in Annex A.

    The AGENT_Representation contains an extra field agent_timestamp that is not in the IDL defined in Annex A.

  • Reported: DDS-XTypes 1.3b1 — Tue, 29 Oct 2019 01:04 GMT
  • Updated: Tue, 29 Oct 2019 01:04 GMT

Define InstanceHandle_t and DomainId_t portably

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

    Define InstanceHandle_t as a structure that contains native data
    Define DomainId_t as an integer

  • Reported: DDS 1.4 — Mon, 5 Aug 2019 11:57 GMT
  • Updated: Thu, 10 Oct 2019 00:04 GMT

InstanceHandle_t/Domain ID

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

    InstanceHandle_t is underspecified, The IDL PSM that should use a struct, so that argument passing is the same for all values

    In the IDL PSM, I see that copying and comparing instance handles is underspecified.

    The same issue applies to domain IDs, actually, which also have unspecified contents in that PSM.)

  • Reported: DDS 1.2 — Thu, 26 May 2011 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:04 GMT

The start time of type Time_t is not defined

  • Key: DDS15-240
  • Status: open   Implementation work Blocked
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    Section 2.3.2 on page 138 contains:

    The two types used to represent time: Duration_t and Time_t are mapped into structures that contain fields for the second and the nanosecond parts.

    However, 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.4 — Sat, 21 Jul 2018 07:19 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Wrong name for DataRepresentationQosPolicy field

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

    Section 7.6.3.1.3 'DataRepresentationQosPolicy: Platform-Specific API' states:

    The topic, publication, and subscription built-in topic data types shall each indicate the data representation of the associated entity with a new member:

    @id(0x0073) DDS::DataRepresentationQosPolicy representation;

    This does not follow the naming conventions for field names. Instead it should have said that the new member should be:
    @id(0x0073) DDS::DataRepresentationQosPolicy data_representation;

    Likewise in Annex D the declarations of structures TopicBuiltinTopicData, TopicQos, PublicationBuiltinTopicData, DataWriterQos, SubscriptionBuiltinTopicData, and DataReaderQos all have the member:

    @id(0x0073) DDS::DataRepresentationQosPolicy representation;
    

    This should be changed so the member is:

    @id(0x0073) DDS::DataRepresentationQosPolicy data_representation;
    
  • Reported: DDS 1.4 — Wed, 5 Jun 2019 23:44 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Collection of longs misrepresented in 2.2.1.1 MyClass

  • Key: DDS15-246
  • Status: open  
  • Source: Turkish Navy Research Center ( Akif Tokuz)
  • Summary:

    In MyClass table on page4 (pdf page 16/180), param4 is given type long. But the description says above:"‘param4,’ is also an input parameter of type collection of longs"
    So it must be "long []" instead of "long".

    I checked the DDS 1.2 spec (formal/07-01-01), it was correct in that version (pdf page 18/260).

    Akif,

  • Reported: DDS 1.4 — Thu, 3 Jan 2019 13:23 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Names of listener operations are incorrect in UML diagrams

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

    In Figures 2.9, 2.10, and 2.17, the Data*Listener classes in the UML incorrectly have functions called

    on_*_match()

    when in fact they should be

    on_*_matched()
  • Reported: DDS 1.4 — Thu, 14 Feb 2019 23:35 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Consider replacing @Choice annotation with XTYPES 1.2 unions

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

    The DDS-RPC added a @Choice annotation (see 7.5.1.2.1.1 @Choice Annotation) to indicate a Structure with the "single-member" semantics of a union. As stated in the aforementioned section the reason was:

    Using unions to indicate which operation is being invoked is brittle. Operations in an interface have set semantics and have no ordering constraints. Union, however, enforces strict association with discriminator values, which are too strict for set semantics. Further, use of unions leads to ambiguities in case of multiple inheritance of interfaces.

    However XTYPES 1.2 enhanced unions which now support inheritance and are not so brittle anymore. For this reason it makes sense to re-evaluate this decision.

    An advantage of using unions (beyond avoiding a extraneous annotation) is that their API is better oriented to identifying the one branch that is present; whereas in the case of structures there is no standard API available to determine which member is present other than iterating over every member. This would be unnatural for processing the RPC calls.

  • Reported: DDS 1.4 — Mon, 20 May 2019 22:45 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Typo in section 2.2.2.5 Subscription Module

  • Key: DDS15-195
  • Status: open  
  • Source: Technical University of Madrid ( Jesús Rodríguez-Molina)
  • Summary:

    While this is a very minor issue, it is a good idea to mention it. In the line starting with "To ensure corerctness and portability" I guess it is meant "To ensure correctness and portability", thus having a typo in "corerctness". Am I right?

    Kind regards,

    Jesús Rodríguez-Molina

  • Reported: DDS 1.4 — Wed, 16 Mar 2016 11:36 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

DATAWRITER_QOS_USE_TOPIC_QOS and DATAREADER_QOS_USE_TOPIC_QOS

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

    In 7.2.3 the defines DATAWRITER_QOS_USE_TOPIC_QOS
    and DATAREADER_QOS_USE_TOPIC_QOS do exist but they are not mentioned anywhere in the spec. Not sure if they should be removed, or documented

  • Reported: DDS 1.2 — Fri, 31 Oct 2014 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Invalid DURABILITY_SERVICE reference on the DataWriter

  • Key: DDS15-51
  • Legacy Issue Number: 10806
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    In the QoS table (Section 2.2.3 Supported QoS) the 'concern' row illegally specifies the DataWriter for the DURABILITY_SERVICE QoS.

    Solution:
    Section 2.1.3 Supported QoS, QoS Table:
    Entry for DURABILITY_SERVICE QoS, remove the word 'DataWriter' from the 'Concerns' column.
    If we do this it would need to be removed from the BuiltinPublicationData.

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

The DDS Specification should define legal DDS Topic Types

  • Key: DDS15-20
  • Legacy Issue Number: 19141
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • Summary:

    The DDS v1.2 specification does not explicitly define the subset of IDL that can be used to express Topic Types. From the specification, it can be inferred – and all vendor have done so – that a topic type is defined by means of a struct and that the IDL types that cannot be used for the attributes of this struct are Value-Types, Any Types and Object References.

    The DDS v1.2 should explicitly state this. Notice the the problem is not solved by the X-Types specification as that introduces a set of types, such as Maps, Optional types, etc. that are not supported by DDS v1.2 implementations.

    This is really a critical matter which is trivial to solve. Just state what is implicitly assumed and should be fixed ASAP.

  • Reported: DDS 1.4 — Thu, 12 Dec 2013 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Invalid DURABILITY_SERVICE reference on the DataWriter

  • Key: DDS15-185
  • Legacy Issue Number: 9547
  • Status: open  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    In the QoS table (section 2.1.3. Supported QoS) the 'concerns' row illegally specifies the DataWriter for the DURABILITY_SERVICE QoS.

    Proposed Resolution:

    Proposed Revised Text:
    Section 2.1.3 Supported QoS, QoS Table:
    Entry for DURABILITY_SERVICE QoS, remove the word 'DataWriter' from the 'concerns' column.

  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

subset of OMG IDL

  • Key: DDS15-186
  • Legacy Issue Number: 8892
  • Status: open  
  • Source: nswc.navy.mil ( Traci McDonald)
  • Summary:

    In the DDS specification version 05-03-09, page 2-1 specifies that the PSM is for the OMG IDL platform. In section 2.2.1 (page 2-193), more detail is given as to what this PSM looks like. One area I don't see covered is the subset of OMG IDL that the DDS specification supports from a user's perspective. When a user defines an IDL file, what data types should and shouldn't be used? It looks as though valuetypes are not supported, but is it possible to explicitly specify what OMG IDL types are supported by implementations of the DDS specification?

  • Reported: DDS 1.1 — Thu, 16 Jun 2005 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Typo on description of class TopicDescription

  • Key: DDS15-181
  • Legacy Issue Number: 10359
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    The class description for TopicDescription says "no attributes" but in fact two attributes are listed immediately below.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Clarification of create_multitopic behavior

  • Key: DDS15-182
  • Legacy Issue Number: 10358
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The resulting type is specified by the type_name argument." What happens if the specified type is inconsistent with the subscription_expression?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

create_contentfilteredtopic Method Prototype and Description Out

  • Key: DDS15-184
  • Legacy Issue Number: 9964
  • Status: open  
  • Source: Anonymous
  • Summary:

    I was looking at the DDS specification and saw that the name of the first parameter for DomainParticipant's create_contentfilteredtopic method is "name" in the table of methods (section 2.2.2.2.1) and it is "topic_name" in the method description (section 2.2.2.2.1.7). I assume the name should be consistent.

  • Reported: DDS 1.2 — Tue, 25 Jul 2006 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Clarification of instance_state -- Section: 2.1.2.5.1.3

  • Key: DDS15-178
  • Legacy Issue Number: 10362
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "For each instance the middleware internally maintains an instance_state." Obviously this instance_state could be different for different DomainParticipants. Might it be different for two Subscribers of the same DomainParticipant? How about two DataReaders of the same Subscriber?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Clarify behavior of register_type operation

  • Key: DDS15-179
  • Legacy Issue Number: 10361
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The application may pass nil as the value for the type_name. In this case the default typename as defined by the TypeSupport (i.e., the value returned by the get_type_name operation) will be used." What happens if register_type is given a type_name that differs from the result of get_type_name?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Typo in Section: 2.1.3

  • Key: DDS15-174
  • Legacy Issue Number: 10366
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "And three integers: history_depth, max_samples, max_instances, max_samples_ per_instance" There are four integers here.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Typo on descripton of "read" operation

  • Key: DDS15-176
  • Legacy Issue Number: 10364
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The use of this variant allows for zero-copy access to the data and the application will need to “return the loan” to the DataWriter using the return_loan operation (see Section 2.1.2.5.3.20 )." Should be DataReader?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Typo in Section: 2.2.3.14

  • Key: DDS15-172
  • Legacy Issue Number: 10368
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "In other words, the DataReader may miss some datasamples but it will never see the value of a data-object change from a newer value to an order value." You mean "older".

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Typo in description of "persistence" service responsibility

  • Key: DDS15-173
  • Legacy Issue Number: 10367
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The “persistence service” is the one responsible for implementing the DURABILITY kinds TRANSIENT and PERSISTENCE." You mean PERSISTENT

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

'synchronous' and 'asynchronous' switched

  • Key: DDS15-34
  • Legacy Issue Number: 12465
  • Status: open  
  • Source: Anonymous
  • Summary:

    While reading the DDS specification, 'Data Distribution Service for Real-time Systems Version 1.2 OMG Available Specification formal/07-01-01', I found that the 'synchronous' and 'asynchronous' was switched as highlighted in red in the below paragraph in the spec.

    <section 2.2.1.2.2 'Overall Conceptual Model', page 9, penultimate paragraph>
    On the subscriber's side however, there are more choices: relevant information may arrive when the application is busy doing something else or when the application is just waiting for that information. Therefore, depending on the way the application is designed, asynchronous notifications or synchronous access may be more appropriate. Both interaction modes are allowed, a Listener is used to provide a callback for synchronous access and a WaitSet associated with one or several Condition objects provides asynchronous data access.

  • Reported: DDS 1.2 — Wed, 14 May 2008 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Specify the allowed IDL Types within DDS Topic structs

  • Key: DDS15-35
  • Legacy Issue Number: 12360
  • Status: open  
  • Source: Department of Navy ( Paul Werme)
  • Summary:

    The DDS Spec (as of v1.2) does not specify the set of IDL types that are allowed in a DDS Topic struct. This should be defined and made normative instead of being left as an implementation detail.

    Discussion:

    Because the set of IDL types allowed in a DDS Topic struct is not defined, implementors are at liberty to decide what set of IDL types to support. Concerns about the impact of the lack of standardization in this area have been raised by the computing infrastructure teams on major Navy programs on several occasions particularly in regards to potential impact on code portability across DDS implementations and interoperability between DDS implementations.

    In reviewing the DDS C++ Native Language Mapping RFP, we commented that the RFP provided an opportunity to insert a requirement to define the allowed C++ types within a DDS Topic struct which would indirectly result in defining the set of allowed DDS IDL types due to the RFP requirement for the C++ mapping to be consistent with the IDL mapping. This suggestion was rejected because it was viewed that the correct forum and mechanism for resolving this issue was the DDS RTF. We were requested to submit this as an issue to the RTF since the RTF could probably resolve this issue within the next 6 months.

  • Reported: DDS 1.2 — Mon, 31 Mar 2008 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

DDS typos and omissions

  • Key: DDS15-37
  • Legacy Issue Number: 12212
  • Status: open  
  • Source: Anonymous
  • Summary:

    1. Section 2.2.4.4 Conditions and Wait-sets - Two paragraphs above figure 2.19 is "The blocking behavior of the WaitSet is illustrated in Figure 2.19" I think this is meant to reference figure 2.20 instead.

    2. Section 2.2.6.2.2 Notifications via Conditions and Wait-Sets - starts out with "The first part of Figure 2.22" I think it should be figure 2.23

    3. In section 2.3.3 DCPS PSM : IDL on pages 152 - 153 are definitions of all the IDs and names of the QOS Policies with the exception that "TRANSPORTPRIORITY" has an ID definition but is missing a name definition.
    4. Section 2.2.2.2.2.7 set_qos
    This operation sets the value of the DomainParticipantFactory QoS policies. These policies control the behavior of the object a factory for entities.

  • Reported: DDS 1.2 — Mon, 4 Feb 2008 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Definition of BuiltinTopicKey_t

  • Key: DDS15-153
  • Legacy Issue Number: 10581
  • Status: open  
  • Source: MilSOFT ( Ertan Deniz)
  • Summary:

    The PSM mapping of BuiltinTopicKey_t is defined to be as:

    struct BuiltinTopicKey_t { 
        BUILTIN_TOPIC_KEY_TYPE_NATIVE value[3]; 
    }; 
    

    But the DDS Interoperability Wire Protocol (RTPS) specifies that GUID consists of 12 bytes GuidPrefix and 4 bytes EntityId.

    In order to map GUID and BuiltinTopicKey, we should define BuiltinTopicKey as either

    typedef octet BuiltinTopicKey[16];
    

    or else if we really wanted to preserve the definition as an array of longs

    struct BuiltinTopicKey_t { 
        BUILTIN_TOPIC_KEY_TYPE_NATIVE value[4]; 
    }; 
    

    But the latter could cause problems due to different endianess unless we also specified how to place the octets that arrive at the protocol level into the array of long.

  • Reported: DDS 1.2 — Tue, 9 Jan 2007 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

DURABILITY history depth should be de-coupled from the KEEP_LAST history depth used for reliability

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

    The specification provides no way to way to specify a different history depth used for DURABILITY than the used for reliability...

    The HISTORY depth is sometimes needed for reliability in order to accommodate bursts. But this means that the amount of data kept for DURABILITY is affected.

    What is desirable is to have a setting that allows the DURABILITY depth to be decoupled from the RELIABILITY.

  • Reported: DDS 1.4 — Tue, 27 Mar 2018 16:37 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

No specific package definition for the entities of the model in case of JAVA language binding

  • Key: DDS15-32
  • Legacy Issue Number: 13448
  • Status: open  
  • Source: Selex ES ( Dario Di Crescenzo)
  • Summary:

    The DDS specification document does not prescribes a specific package definition for the entities of the model in case of JAVA language binding; in the IDL only a "DDS" module is defined which does not result in a strictly specified package structure (it might only imply that the entities belong to the DDS package/namespace). It would be useful to have a precise statement indicating at least for the JAVA binding the packages to which the DDS Entities must belong in order to have all implementations using the same packages for the same Entities (e.g org.omg.dds.infrastructure, org.omg.dds.domain, etc..)

  • Reported: DDS 1.4 — Fri, 6 Feb 2009 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Deprecated usage of IDL in the DDS spec

  • Key: DDS15-33
  • Legacy Issue Number: 12539
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    The CORBA specification (08-01-04) in section 7.11.6 deprecates the use of anonymous types, for example the type of the struct field "seq" below:
    struct Foo

    { sequence<octet> seq; }

    ;

    The DDS DCPS IDL uses these in multiple places (the first is DDS::UserDataQosPolicy). These should be replaced with non-deprecated usage such as:
    typedef sequence<octet> OctetSeq;
    struct Foo

    { OctetSeq seq; }

    ;

    This will also increase internal consistency of the DDS spec, since it already uses a DDS::StringSeq typedef in the PartitionQosPolicy struct.

    Furthermore, if the element type of the sequence is a Basic Type or a String Type, the CORBA module already provides these typedefs, so it would be preferable to use them. The example above becomes:
    struct Foo

    { CORBA::OctetSeq seq; }

    ;

  • Reported: DDS 1.2 — Fri, 20 Jun 2008 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Mapping of OMG IDL to C++ for DDS

  • Key: DDS15-31
  • Legacy Issue Number: 13839
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    The mapping of user written IDL to C++ is not described in the version 1.2 of the DDS standard.

    Is it expected that DDS use the existing CORBA C++ mapping for data types? If so then the standard should state this requirement.

    On the other hand, the CORBA IDL to C++ mapping is fairly old. The new DDS PSM for C++ would suggest a more modern mapping.

    For example, for bounded strings and bounded sequences, C++ classes inspired by the Standard Template Library (STL) could be used. These classes need not necessarily break the DCPS compatibility with the C language mentioned in 8.2.1.1. (Use fixed buffer, avoid virtual methods.) It is not clear whether unbounded data types need be supported, see issues 8892 and 12360.

    In case a new mapping is defined which is independent of the CORBA C++ mapping, there is a problem to address:
    Bridge applications which use both CORBA and DDS would need to translate a single IDL file twice, once for CORBA and again for DDS. Then there is an overlap in the generated names. This problem could be solved by encapsulating all C++ code generated for DDS from user IDL in an extra namespace.

  • Reported: DDS 1.2 — Fri, 27 Mar 2009 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

History and Reliability should be orthogonally independent concerns

  • Key: DDS15-25
  • Legacy Issue Number: 17284
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • Summary:

    The current DDSv1.2 specification provides a slightly different semantics for the history on the writer side and on the reader.

    In addition, the DDS v1.2 specification allows to use the data-writer history as the "reliability-send-queue" – this is combined with the fact that History is (correctly) not an RxO policy leads to a serious bug in the spec (luckily not all DDS implementations follow this path) . Let's try to understand why.

    Firs, it is important to comprehend that unless a data writer uses KeepAll history, reliable data delivery is not guaranteed to matching data readers. This can't be guaranteed even when using Reliable communication (obviously ignoring data-writer crashes for the time being).

    Essentially, under this scheme a DataWriter is allowed send/re-send only what is in its history cache. If a sample is out of history a DataWriter won't do anything, thus leading to potential inconsistencies in case some reader has lost the message.

    Things get very messy when a DataReader with KeepAll History is matching a DataWriter that does uses KeepLast(n). In this case, the poor DataReader which might legitimally expect to have on his history all the samples written by the writers – without holes – might finds him-/her-self surprised by the fact that some samples might be missing.

  • Reported: DDS 1.4 — Thu, 29 Mar 2012 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Wrong definition of GROUPDATA_QOS_POLICY_NAME constant in IDL

  • Key: DDS15-21
  • Legacy Issue Number: 18320
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    GROUPDATA_QOS_POLICY_NAME is given as "TransportPriority", and the corresponding *_POLICY_NAME from TRANSPORTPRIOIRTY is missing.

    Index: dds/DdsDcpsInfrastructure.idl
    ===================================================================
    --- dds/DdsDcpsInfrastructure.idl
    +++ dds/DdsDcpsInfrastructure.idl
    @@ -327,7 +327,8 @@
         const string WRITERDATALIFECYCLE_QOS_POLICY_NAME = "WriterDataLifecycle";
         const string READERDATALIFECYCLE_QOS_POLICY_NAME = "ReaderDataLifecycle";
         const string TOPICDATA_QOS_POLICY_NAME           = "TopicData";
    -    const string GROUPDATA_QOS_POLICY_NAME           = "TransportPriority";
    +    const string GROUPDATA_QOS_POLICY_NAME           = "GroupData";
    +    const string TRANSPORTPRIORITY_QOS_POLICY_NAME   = "TransportPriority";
         const string LIFESPAN_QOS_POLICY_NAME            = "Lifespan";
         const string DURABILITYSERVICE_POLICY_NAME       = "DurabilityService";
    
  • Reported: DDS 1.4 — Mon, 17 Dec 2012 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

: #define HANDLE_TYPE_NATIVE long typedef HANDLE_TYPE_NATIVE InstanceHandle_t;

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

    The DDS spec defines: #define HANDLE_TYPE_NATIVE long typedef HANDLE_TYPE_NATIVE InstanceHandle_t; We see that some vendors use long, other a struct containing an octet array. This is causing problems when integrating DDS into CCM. A CORBA::Long is passed by value, a struct is passed as const &. At least the way the InstanceHandle_t is passed to methods and returned should be the same. We propose to change this type to: struct NativeInstanceHandle_t

    { // Vendor defined }

    ; typedef NativeInstanceHandle_t InstanceHandle_t; That way we always have a struct passed as const&.

  • Reported: DDS 1.2 — Thu, 30 Jul 2009 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

For ContentFilteredTopic::get_expression_parameters the argument name is not given in the spec

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

    For ContentFilteredTopic::get_expression_parameters the argument name is not given in the spec, this way the IDL isn't complete and compilable Also MultiTopic::get_expression_parameters has the same issue Also DataWriter::get_liveliness_lost_status has this issue

  • Reported: DDS 1.2 — Mon, 8 Jun 2009 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Introduce new typedef for anonymous types

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

    UserDataQosPolicy, TopicDataQosPolicy, and GroupDataQosPolicy use an anonymous sequence, this is deprecated in IDL. A new typedef for this should be introduced

  • Reported: DDS 1.2 — Mon, 8 Jun 2009 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

The get_sample_lost method seems to be part of the Subscriber class

  • Key: DDS15-17
  • Legacy Issue Number: 10980
  • Status: open  
  • Source: KDA ( Ingvill Grefstad)
  • Summary:

    Page 2-70, The get_sample_lost method seems to be part of the Subscriber class. However, according to the UML-diagram page 2-62 and the idl-listing page 2-166 and , the get_sample_lost method should belong to the DataReader class - not the Subscriber.

  • Reported: DDS 1.1 — Wed, 2 May 2007 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

DDS should require to annotate IDL to indicate which IDL types are used for dds

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

    In a CCM/DDS4CCM based system not all IDL defined types are intended to be used with dds. At this moment there is not a standardized way to indicate that a type should be usable with DDS. If I now have a large file with a lot of types, DDS just assumes that everything should be transmittable through DDS and generates a lot of code. Just like can indicate the keys of a struct, I think DDS should define a standardized way to annotate the idl so that just some types in a file are handled by the dds tooling

  • Reported: DDS 1.2 — Wed, 17 Nov 2010 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

DDS specification should be more precise on NATIVE defines

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

    DDS leaves domainid, handle, and topic key to the dds vendor, each can define their own type for these. The specification has defines for them, but the default is long. If now a vendor uses for example a struct for the InstanceHandle_t, this leads to challenges when writing portable C++ code because the argument passing is different between a long (as value) or a fixed struct (const &). To my idea the dds specification should be more precise on the type, maybe fixed struct to achieve more portability of users code

  • Reported: DDS 1.2 — Wed, 17 Nov 2010 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Add DDS::STATUS_MASK_NONE

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

    We want to propose to extend the DDS status masks with DDS::STATUS_MASK_NONE which is defined as 0. This is cleaner for application code.

  • Reported: DDS 1.2 — Mon, 8 Feb 2010 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Add new mask which will let DDS callback on the listener to gets its mask

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

    DDS has several methods to create entities and pass a listener. With the listener than a mask has to be passed. It would be much cleaner for some C++ systems when we can pass a special mask which means that DDS will callback on the listener to gets its mask, this reduces the application code and could lead to a cleaner user code architecture

  • Reported: DDS 1.2 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Consider referencing DDS-XML for the XML type and data representations

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

    DDS-XML defines the XML data representation. See 7.2 of DDS-XML
    DDS-XML defines the XML type representation. See 7.3.3 of DDS-XML

    So these definitions could be removed from DDS-XTYPES and just reference those specs.

    Also the XSD type representation could be deprecated from DDS-XTYPES. This has not been popular in practice. The XML type representation is far more popular...

  • Reported: DDS-XTypes 1.3b1 — Wed, 25 Sep 2019 22:14 GMT
  • Updated: Thu, 26 Sep 2019 08:44 GMT

Extend SampleInfo with sequenceNumber and reception_timestamp

  • Key: DDS15-309
  • Status: open  
  • Source: ZettaScale Technology ( Erik Hendriks)
  • Summary:

    Many vendors already extend the SampleInfo with some additional fields:

    • The reception_timestamp
    • The writerSequence number.

    I would propose we make these part of the new standard.

  • Reported: DDS 1.4 — Wed, 25 Sep 2019 20:15 GMT
  • Updated: Wed, 25 Sep 2019 20:15 GMT

Spec lacks definition regarding uniqueness of InstanceHandle_t

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

    The spec defines the following:
    7.1.2.1.1.8 get_instance_handle
    This operation returns the InstanceHandle_t that represents the Entity.

    But it doesn't specify in how far this InstanceHandle_t has to be unique. When the user receives an InstanceHandle_t, is it than unique within the same domain participant, within the process or within the complete dds domain? If it is for example just unique within one domain participant, we can't use it for example as key in a map which could contain entities from multiple domain participants

  • Reported: DDS 1.2 — Fri, 8 Jun 2012 04:00 GMT
  • Updated: Wed, 25 Sep 2019 16:57 GMT

Consider replacing @Choice annotation with XTYPES 1.2 unions

  • Key: DDSRPC11-4
  • Status: open  
  • Source: Twin Oaks Computing, Inc. ( Clark Tucker)
  • Summary:

    The DDS-RPC added a @Choice annotation (see 7.5.1.2.1.1 @Choice Annotation) to indicate a Structure with the "single-member" semantics of a union. As stated in the aforementioned section the reason was:

    Using unions to indicate which operation is being invoked is brittle. Operations in an interface have set semantics and have no ordering constraints. Union, however, enforces strict association with discriminator values, which are too strict for set semantics. Further, use of unions leads to ambiguities in case of multiple inheritance of interfaces.

    However XTYPES 1.2 enhanced unions which now support inheritance and are not so brittle anymore. For this reason it makes sense to re-evaluate this decision.

    An advantage of using unions (beyond avoiding a extraneous annotation) is that their API is better oriented to identifying the one branch that is present; whereas in the case of structures there is no standard API available to determine which member is present other than iterating over every member. This would be unnatural for processing the RPC calls.

  • Reported: DDS-RPC 1.0 — Tue, 24 Sep 2019 13:26 GMT
  • Updated: Tue, 24 Sep 2019 13:26 GMT

Legal characters and length of Topic Name

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

    The DDS specification states a Topic name is a string but it does not state what the legal characters are. It would therefore be possible to use "unprintable" characters which could create difficulties with printing and logginf messages.
    Because of this it is also possible for multiple vendors to put in place restrictions that could cause incompatibilities.

    For this reason it is desirable that the specification states with characters are legal within a Topic name.

    In addition RTPS version 2.2 defines TopicName as string<256> this should also be reflected in DDS.

  • Reported: DDS 1.4 — Tue, 17 May 2016 21:54 GMT
  • Updated: Mon, 23 Sep 2019 15:42 GMT

encode_rtps_message/decode_rtps_message error and status reporting

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Tue, 17 Sep 2019 21:53 GMT

TypeSupport::get_type_name should be precisely specified

  • Key: DDS15-1
  • Legacy Issue Number: 18468
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • Summary:

    The description of the TypeSupport::get_type_name operation currently states:

    "This operation returns the default name for the data-type represented by the TypeSupport."

    The problem is that the default name for the data-type is not specified anywhere. One logical choice would be the fully qualified type as per the IDL syntax. As an example org::omg::dds::demo::ShapeType.

    If the specification does not clearly mandate the representation for the topic type interoperability may be hindered unless users explicitly override topic types.

    This is very unfortunate and a critical issue that should be addressed ASAP.

  • Reported: DDS 1.2 — Thu, 21 Feb 2013 05:00 GMT
  • Updated: Wed, 28 Aug 2019 19:37 GMT

behaviour of redefining multiple times the same topic with different QoS not clearly specified

  • Key: DDS15-27
  • Legacy Issue Number: 16098
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • Summary:

    The DDS v1.2 specification does not clearly specify the behaviour of redefining multiple times the same topic with different QoS. As a Topic represents a global assertion, having different applications associating different QoS with the same topic should be flagged as an error.

  • Reported: DDS 1.2 — Fri, 25 Mar 2011 04:00 GMT
  • Updated: Wed, 28 Aug 2019 00:08 GMT

Missing APIs for (read|take)_instance_w_condition

  • Key: DDS15-26
  • Legacy Issue Number: 16607
  • Status: open  
  • Source: Real-Time Innovations ( Kevin Jaeger)
  • Summary:

    For keyed topics, the core set of read or take APIs support read|take, read|take_instance, and read|take_next_instance.

    The corresponding set of API's for read or take with conditions only specified read|take_w_condition and read|take_next_instance_w_condition. The specification lacks the APIs for read|take_instance_w_condition.

    Lack of these APIs deprives the user from the ability to read or take from a specific instance while limiting the sample set to specific conditions.

  • Reported: DDS 1.4 — Fri, 14 Oct 2011 04:00 GMT
  • Updated: Tue, 27 Aug 2019 23:25 GMT

DDS DCPS Issue: PRESENTATION=GROUP and QoS

  • Key: DDS15-43
  • Legacy Issue Number: 10993
  • Status: open  
  • Source: OCI ( Don Busch)
  • Summary:

    Section 7.l.3.6 of the DCPS spec should indicate what happens under the PRESENTATION=GROUP policy when different DataWriters in the group have different QoS settings. Whose settings are followed by the group? The most stringent? The least stringent? Group membership is dynamic, so the group members are not knows until each write() happens

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Updated: Tue, 20 Aug 2019 00:23 GMT

The compatibility rules for the Presentation QoS are too strict

  • Key: DDS15-24
  • Legacy Issue Number: 17362
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Sanchez)
  • Summary:

    The compatibility rules for the Presentation QosPolicy, specified in section 2.2.3.6 of the DDS Specification prevent a subscriber configured using GROUP access scope from simultaneously matching a publisher configured using GROUP access scope and a publisher configured using TOPIC or INSTANCE access scope.

    Proposed Resolution:
    The addition of a new boolean field called "use_highest_offered_access_scope" to Presentation QosPolicy.

    This boolean is not propagated as part of the discovery information and remains local to the subscriber. Users configure the subscriber to the minimum accepted access scope. When the boolean field is set to true, the subscriber will provide the access_scope offered by the publisher as opposed to its own access_scope value.

    For example: a subscriber wanted to provide GROUP access scope when matched with a GROUP order publisher and with a publisher providing INSTANCE access scope, will use INSTANCE access scope and set the user_highest_offered_access_scope boolean to true.

  • Reported: DDS 1.2 — Tue, 8 May 2012 04:00 GMT
  • Updated: Mon, 19 Aug 2019 23:40 GMT

PARTITION PolicyQos should be in DataReader/DataWriter

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

    The logic of the PARTITION Qos applies separately to each DataReader/DataWriter and the propagation on the DCPS bultin Topics also happens along with each DataReader and DataWriter.

    Despite this the PARTITION Qos can only be set on the Publisher/Subscriber which impact all the DataWriters/DataReaders they contain. To overcome this we have seen many users create a separate Publisher/Subscriber per DataWriter/DataReader which unnecessarily consumes resources and couples them.

    The recommendation is to allow the PARTITION Qos to be set directly on the DataWriter and DataReader. This would not impact the behavior of partition matching. Just makes it more flexible to use.

    A question is whether we should still allow the Publisher/Subscriber to have a PARTITION Qos. This may be desirable to avoid braking existing code. In this case we could interpret as a 'default" unless ta DataWriter/DataReader specifies it explicitly. This would make current applications work without changes.

  • Reported: DDS 1.4 — Fri, 16 Aug 2019 00:54 GMT
  • Updated: Mon, 19 Aug 2019 14:27 GMT

Coherent updates with best efforts

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

    Clarify what happens if coherent updates involve best-effors writers. Would missing one sample cause the whole set to be discarded?

    Affects both TOPIC coherence and GROUP coherence if there are some best-efforts writers in the Publisher

  • Reported: DDS 1.4 — Tue, 15 Mar 2016 15:36 GMT
  • Updated: Fri, 16 Aug 2019 00:09 GMT

Clarification of resource management

  • Key: DDS15-183
  • Legacy Issue Number: 10357
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    I don't think that it is explicitly stated anywhere in this spec that each DataWriter and each DataReader maintains its own set of samples. Samples are not maintained by Publishers, Subscribers. It is implied in several places, e.g. the fact that RESOURCE_LIMITS applies to DataWriter and DataReader and not to Publisher and Subscriber. It took me a while to figure this out. It is possible for a Publisher to have more than one DataWriter with the same topic, and a Subscriber to have more than one DataReader with the same topic. The semantics of DataReader.take, for instance, are unclear unless it is understood that each DataReader has its own samples. Evidently a take operation on one DataReader does not disturb the samples of another DataReader with the same Publisher and Topic. Please clarify the specification in this regard. Figure 2-1 and accompanying text would be one place.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Thu, 15 Aug 2019 23:29 GMT

Section: 2.1.2.5.3 clarification of parameters to 'read/take' operation

  • Key: DDS15-177
  • Legacy Issue Number: 10363
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: DataReader.read operation Why are sample_states, view_states, and instance_states provided as separate parameters? Aren't they contained in sample_infos? More explanation required.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Thu, 15 Aug 2019 19:31 GMT

Deprecate Basic Service Mapping

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

    The Basic Service Mapping was included in the specification primarily to support implementations that did not support XTYPES. Now that most DDS support XTYPES this motivation is no longer there.

    Having both a Basic Service Mapping and an Enhance Service Mapping creates significant complexity and ambiguity. It becomes another choice the user must make and another way implementations may not interoperate.

    Furthermore when other specifications map to DDS Services, they must too make a choice of Service Mappings. Hence perpetuating complexity and interoperability issues.

    The Enhanced Service Mapping has significant advantages in terms of performance, scalability, and type-system simplicity. Fundamentally it allows the use of the same types for request reply and RPC, any extra information is added in meta-data so that the types themselves are unpolluted. This is in-line with what other middleware technologies (e.g. JMS) does.

    Therefore the most sensible thing is to deprecate the Basic Service Mapping.

  • Reported: DDS 1.4 — Mon, 20 May 2019 22:31 GMT
  • Updated: Thu, 15 Aug 2019 00:50 GMT

Wrong name for DataRepresentationQosPolicy field

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

    Section 7.6.3.1.3 'DataRepresentationQosPolicy: Platform-Specific API' states:

    The topic, publication, and subscription built-in topic data types shall each indicate the data representation of the associated entity with a new member:

    @id(0x0073) DDS::DataRepresentationQosPolicy representation;

    This does not follow the naming conventions for field names. Instead it should have said that the new member should be:
    @id(0x0073) DDS::DataRepresentationQosPolicy data_representation;

    Likewise in Annex D the declarations of structures TopicBuiltinTopicData, TopicQos, PublicationBuiltinTopicData, DataWriterQos, SubscriptionBuiltinTopicData, and DataReaderQos all have the member:

    @id(0x0073) DDS::DataRepresentationQosPolicy representation;
    

    This should be changed so the member is:

    @id(0x0073) DDS::DataRepresentationQosPolicy data_representation;
    
  • Reported: DDS-XTypes 1.3b1 — Thu, 15 Aug 2019 00:46 GMT
  • Updated: Thu, 15 Aug 2019 00:46 GMT

DURABILITYSERVICE_POLICY_NAME

  • Key: DDS15-36
  • Legacy Issue Number: 12276
  • Status: open  
  • Source: lmco.com ( Abdullah Sowayan)
  • Summary:

    noticed an inconsistency while I was reading the DDS spec (version 1.2) last night. My question relates to the following quality of service policy: DURABILITYSERVICE_POLICY_NAME

    The pattern in all QoS names is:

    *_QOS_POLICY_NAME, except for the DURABILITYSERVICE

    The pattern in all QoS IDs is:

    *_QOS_POLICY_ID

    The DURABILITYSERVICE does adhere to the pattern/convention for Qos IDs:

    DURABILITYSERVICE_QOS_POLICY_ID

    But the does NOT adhere to the pattern/convention for Qos names. So, is there a typo in DURABILITYSERVICE_POLICY_NAME, i.e., should it be DURABILITYSERVICE_QOS_POLICY_NAME, or is the lacking of 'QOS' intentional?

  • Reported: DDS 1.2 — Thu, 13 Mar 2008 04:00 GMT
  • Updated: Wed, 14 Aug 2019 19:18 GMT

When using GROUP access scope presentation QoS, allow for read/take outside of begin_access and end_access block

  • Key: DDS15-23
  • Legacy Issue Number: 17363
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Sanchez)
  • Summary:

    Problem: The DDS specification (section 2.2.2.5.2.8) does not allow access to the DDS cache when the application wants to access data, but does not care about the order across Data Writers.

    Proposed Resolution:
    When using GROUP access scope, allow both access patterns and do not return PRECONDITION_NOT_MET
    error code when called read, take, etc. without first called begin_access.

    Note: This also allows portability for applications which do not care about the order across topics.

  • Reported: DDS 1.2 — Tue, 8 May 2012 04:00 GMT
  • Updated: Fri, 9 Aug 2019 17:33 GMT

Allow for more optimized list returned by get_datareaders()

  • Key: DDS15-22
  • Legacy Issue Number: 17364
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Sanchez)
  • Summary:

    Found by: Fernando Crespo
    Severity:

    Problem:
    OMG DDS spec (section 2.2.2.5.2.10) states that the sequence returned by
    get_datareaders() will contain list containing each DataReader one or more times.
    For example, if multiple consecutive samples in a group belong to the same DataReader
    the DataReader is repeated in the list returned by get_datareaders().
    Having to process each element, even when they belong to the same DataReader is
    less performant.

    Proposed Resolution:
    Modify the specification to return one DataReader element, instead of a list where
    a DataReader is repeated multiple times, when multiple subsequent samples belong to
    the same DataReader. This allows for more optimized processing where the user calls
    read/take until the return code is NO_DATA.

  • Reported: DDS 1.2 — Tue, 8 May 2012 04:00 GMT
  • Updated: Fri, 9 Aug 2019 16:47 GMT

Instance-Level access-control

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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: Thu, 8 Aug 2019 09:27 GMT

Organize definitions of Time_t, Duration_t and other common types in the PIM

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

    The PIM contains definitions for most of the "reference semantic" classes. But it does not directly define the "value semantic" classes such as: Time_t, Duration_t, SequenceNumber_t, InstanceHandle_t, StatusKind, StatusMask, etc.

    Some types like ReturnCode_t are defined. But this is done in an odd place: (section 2.2.1.1 'Format and Conventions').

    The PIM would be more clear if these types were all defined clearly in a centralized place. For example the Infrastructure module.

    This issue should be treated as a "Blocker" so it is resolved ahead of other issues. That way the other issues can refer to the new definitions and organization.

  • Reported: DDS 1.4 — Wed, 7 Aug 2019 11:03 GMT
  • Updated: Wed, 7 Aug 2019 11:03 GMT

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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: Tue, 6 Aug 2019 17:13 GMT

Add several with_profile methods

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

    DDS4CCM adds support for qos xml files. There is no api in dds to create a dp/sub/pub/rd/wr with a qos given from the xml file. We propose to add the following methods to the DDS IDL to create dds entities with a qos xml profile.

        local interface DomainParticipant : Entity {
            Publisher create_publisher_with_profile(
                in string library_name,
                in string profile_name,
                in PublisherListener a_listener,
                in StatusMask mask);
            Subscriber create_subscriber_with_profile(
                in string library_name,
                in string profile_name,
                in SubscriberListener a_listener,
                in StatusMask mask);
            Topic create_topic_with_profile(
                in string topic_name,
                in string type_name,
                in string library_name,
                in string profile_name,
                in TopicListener a_listener,
                in StatusMask mask);
    };
    
    
        local interface DomainParticipantFactory {
            DomainParticipant create_participant_with_profile(
                in DomainId_t domain_id,
                in string library_name,
                in string profile_name,
                in DomainParticipantListener a_listener,
                in StatusMask mask);
            ReturnCode_t set_default_participant_qos_with_profile(
                in string library_name,
                in string profile_name);
    };
    
    
        local interface Publisher : Entity {
            DataWriter create_datawriter_with_profile(
                in Topic a_topic,
                in string library_name,
                in string probile_name,
                in DataWriterListener a_listener,
                in StatusMask mask);
    };
    
    
        local interface Subscriber : Entity {
            DataReader create_datareader_with_profile(
                in TopicDescription a_topic,
                in string library_name,
                in string profile_name,
                in DataReaderListener a_listener,
                in StatusMask mask);
    }; 
    
  • Reported: DDS 1.2 — Tue, 21 Dec 2010 05:00 GMT
  • Updated: Mon, 5 Aug 2019 13:38 GMT

get_type_name, class or object method

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

    It seems that DDS vendors are implementing get_type_name of the TypeSupport interfaces differently. Some do it as static class method in C++, some as a regular method. The spec uses regular IDL, which gives the idea that it is a regular method needed a concrete TypeSupport instance, but I doubt whether that is intended

  • Reported: DDS 1.2 — Tue, 24 May 2011 04:00 GMT
  • Updated: Mon, 5 Aug 2019 13:32 GMT

Add a DomainTag to the PSM

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

    RTPS 2.4 added a domainTag (see Table 8.73 - RTPS SPDPdiscoveredParticipantData attributes) this was done to support having the DDS RTF adding it to the next version of the Spec. This task should be completed.

    The domainTag is used to isolate domains even if they are on the same DDS domainId

  • Reported: DDS 1.4 — Mon, 5 Aug 2019 12:22 GMT
  • Updated: Mon, 5 Aug 2019 12:22 GMT

Write with handle_nil underspecified

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

    For write the DDS spec says:

    The special value HANDLE_NIL can be used for the parameter handle. This indicates that the identity of the instance
    should be automatically deduced from the instance_data (by means of the key).

    The case which is not specified is the case where the handle is HANDLE_NIL, but they key we use hasn't been registered with dds yet, will DDS than return an error, or automatically register a new instance?

  • Reported: DDS 1.2 — Fri, 8 Jun 2012 04:00 GMT
  • Updated: Mon, 5 Aug 2019 10:11 GMT

ContentFilteredTopics should be removed. Filtering belongs to DataReaders

  • Key: DDS15-2
  • Legacy Issue Number: 18311
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • Summary:

    The DDS v2.1 introduces the concept of a ContentFilteredTopic in order to express filtering on a DataReder. The ContentFilteredTopic is a local entity that is not distributed via discovery. In addition content filters are already distributed as part of DataReader discovery.

    As such it would be cleaner and more sensible to remove the ContentFilteredTopic and allow to express the filter directly through either DataReader QoS or as a Filter parameter (see DDS-PSM-Cxx for inspiration).

  • Reported: DDS 1.2 — Wed, 12 Dec 2012 05:00 GMT
  • Updated: Mon, 5 Aug 2019 10:09 GMT

Specify more clearly which types have a name and how it is constructed

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

    Section 7.2.2.1 'Namespaces' states:

    Modules are namespaces whose contained named elements are types. The concatenation of module names with the name of a type inside of those modules is referred to as the type’s “fully qualified name.”

    This is not enough to fully determine the fully qualified name. How is the "concatenation" done? What character is used to separate the successive module names?

    For example what should be the fully-qualified name of the type described in in the following IDL?

    module A {
    module B {
      struct Foo {
        ...
      };
    };
    };
    

    Assuming "::" is used to separate namespaces it would be "A::B::Foo"

    The issue of type names is a bit broader. Currently it is not so clear that every type has a name. Is that really so? What about anonymous types defined within a structure?

    The definition of MemberDescriptor (7.5.2.7) which is used to describe members of a Structure seems to imply every type must have a name. This is because each MemberDescriptor has an associated DynamicType (7.5.2.7.10 'Property: type') which according to 7.5.2.7.10 it cannot be null. And the DynamicType::get_name() should return the name of the type.

    On the other hand Figure 5 seems to indicate only Modules and ConstructedTypes (according to Fig 5 these are: Alias, AggregateTypes, EnumeratedType, Collection) have a "ScopedIdentifier" which is their name.

    This would mean that PrimitiveTypes, StringType do not have a ScopeIdentifyer/name. This seems problematic,

    • PrimitiveTypes do seem to have a name as it is used when defining struct members of that type.
    • CollectionTypes do not seem to have a name.

    However nothing really says that typenames should be globally unique. They only need to be unique within a compilation unit...

  • Reported: DDS-XTypes 1.3b1 — Sun, 4 Aug 2019 20:29 GMT
  • Updated: Mon, 5 Aug 2019 10:06 GMT

Add Unions to types supported in Queries and Filters

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

    "Member Names" (7.6.7.1) is missing support for Unions. Union members can be accessed by name as long as a reserved name is specified for the discriminator. A valid filter expression needs to check the discriminator before accessing another member name (for example u.disc = 3 AND u.val < 100), however the implementation doesn't need to check for this. If evaluating a filter expression causes access to an inactive element of a union, the result is undefined.

  • Reported: DDS-XTypes 1.3b1 — Mon, 22 Jul 2019 15:36 GMT
  • Updated: Mon, 22 Jul 2019 15:36 GMT

Protecting the Source Timestamp

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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: Tue, 16 Jul 2019 17:28 GMT

AES-GCM doesn't add padding

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Thu, 11 Jul 2019 22:02 GMT

What can be done with a disabled Topic?

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

    Since Topics are Entities, they can exist in a disabled state. Section 2.2.2.1.1.7 is insufficient to define what can (more importantly, can't) be done with a disabled Topic.
    That section defines which operations "may be invoked on it", but more interesting for Topics are the passive uses of these objects as arguments to other operations.
    In particular, it should be explicitly stated that a DataReader or Writer that references a disabled Topic (including, for readers, indirectly via ContentFilteredTopic or MultiTopic) cannot be enabled. In these cases, the enable() operation returns RETCODE_PRECONDITION_NOT_MET.

  • Reported: DDS 1.4 — Tue, 9 Jul 2019 15:56 GMT
  • Updated: Tue, 9 Jul 2019 15:56 GMT

Specify the behavior of instance state machine in case of a disconnect-reconnect scenario

  • Key: DDS15-254
  • Status: open  
  • Source: ZettaScale Technology ( Erik Hendriks)
  • Summary:

    The DDS specification is very clear what happens in case of a disconnect: the receiver will behave as if the sender unregistered all its instances. But what should the behavior be in case of a reconnect?

    For VOLATILE cases the behavior might still be intuitive: an instance stays NOT_ALIVE_NO_WRITERS until an update has been received, in which case it goes back to ALIVE. And because VOLATILE data is typically periodic data, eventually all my instances will come back alive.

    But what about non-volatile data, that is typically not periodic, or is periodic but with a very low update frequency? Consider the following scenario:

    • Writer A writers 10 samples belonging to 10 different instances.
    • Reader B takes all samples.
    • Writer A disconnects from Reader B.
    • Reader B receives invalid samples indicating all instances are now NOT_ALIVE_NO_WRITERS.
    • Reader B takes these samples.
    • A reconnection is established, and none of the instances have been updated by Writer A.

    You would expect that all instances in Reader B would go back to the ALIVE state, but how do I get them back into the ALIVE state? Since there are no more samples to piggy-bag this instance state change on.

    A couple of approaches are conceivable:

    • Use an invalid sample to bring the instance back alive.
    • Republish the last available sample
    • Do nothing.

    Every approach has its pro's and cons, but the DDS spec should clearly describe which behavior is intended here.

  • Reported: DDS 1.4 — Wed, 19 Jun 2019 12:15 GMT
  • Updated: Wed, 19 Jun 2019 12:15 GMT

Consider adding some of the concepts in the new PSMs to the PIM

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

    Examples:

    • Selector from C++ PSM
    • Cascading operations to set Qos policies qos.with().with().
    • Dispatch on waitset and conditions (attach a function)
    • "close" operation that is recursive and avoids having a handle to the factory.
      *
  • Reported: DDS 1.4 — Wed, 19 Jun 2019 10:00 GMT
  • Updated: Wed, 19 Jun 2019 10:00 GMT

Missing get_discovered_participants and get_discovered_participant_data functions

  • Status: open  
  • Source: Real-Time Innovations ( Alex Campos)
  • Summary:

    The C++ PSM doesn't provide the following DDS-standard functions:

    • DomainParticipant::get_discovered_participants
    • DomainParticipant::get_discovered_participant_data.

    Proposed resolution
    To be consistent with PSM functions like matched_publications and matched_publication_data, we should add the following functions in the dds::domain namespace:

    dds/domain/discovery.hpp
    dds::core::InstanceHandleSeq discovered_participants(
        DomainParticipant participant);
    
    template <typename FwdIterator>
    FwdIterator discovered_participants(
        DomainParticipant participant,
        FwdIterator begin,
        FwdIterator end);
    
    dds::topic::ParticipantBuiltinTopicData discovered_participant_data(
        DomainParticipant participant,
        const dds::core::InstanceHandle& handle);
    
  • Reported: DDS-PSM-Cxx 1.0b2 — Thu, 14 Jul 2016 18:21 GMT
  • Updated: Sat, 15 Jun 2019 01:16 GMT

Clarify definition of counts in Plain Communication Status

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

    The second table in 2.2.4.1 (the one that starts with "SampleLostStatus") has confusing definitions of the "counts" in various plain communication status.

    Certain "statuses" simply report events that occur within the Entities. Sample Lost is a good example of this. When a sample is lost, it's lost for good and not coming back. Therefore we expect total_count_change to be nonnegative. In this case the total_count definition is clear.

    Other "status" are ways to report some aspect of the state of the Domain to the application. Inconsistent Topic is an example of this. Since remote Entities can change at any time, the count of inconsistent topics may decrease (for example, when a Topic owned by a remote Participant is deleted). For the "statuses" in this category, the wording of the definition of total_count (and perhaps other attributes) is confusing since it starts with "Total cumulative count..." just like the one for Sample Lost.

  • Reported: DDS 1.4 — Fri, 7 Jun 2019 15:36 GMT
  • Updated: Fri, 7 Jun 2019 15:36 GMT

Instance handle constructor for TopicInstance should be deleted.

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

    The dds/topic/TopicInstance object is used as a holder for both a sample, and the instance handle to its corresponding instance. There are operations on the DataWriter that accept a TopicInstance as their parameter.

    However, it is possible to instantiate a TopicInstance without sample, by using a constructor that only accepts an instance handle. It is unclear what the behavior of the write operations should be in case they receive a TopicInstance without corresponding sample.

    I therefore propose to either delete the constructor that accepts only an instance handle, and remove the key_value() function that accepts TopicInstance as input parameter (it is already overloaded by another key_value() that accepts an InstanceHandle) or otherwise define an exception when passing a TopicInstance without sample to a write() operation.

  • Reported: DDS-PSM-Cxx 1.0 — Wed, 5 Jun 2019 12:01 GMT
  • Updated: Wed, 5 Jun 2019 12:01 GMT

Unintuitive way to access extension member functions

  • Status: open  
  • Source: Real-Time Innovations ( Alex Campos)
  • Summary:

    Invoking an extension function in a standard type requires using an overloaded arrow operator. For example:

    // Standard class (in dds namespace)
    dds::domain::DomainParticipant participant(MY_DOMAIN_ID);
    // Call a standard method
    participant.assert_liveliness();
    // Call an extension method:
    participant->vendor_specific_method(...);
    

    The use of the arrow operator is counterintuitive to most people (the variable is not a pointer) and didn't allow an IDE to show the available extensions if the regular dot operator was used.

    We propose adding an "extensions()" function to dds::core::Reference and dds::core::Value that can be used as follows:

    // Call an extension method:
    participant.extensions().register_durable_subscription(...);
    
  • Reported: DDS-PSM-Cxx 1.0b2 — Fri, 10 May 2019 18:32 GMT
  • Updated: Wed, 15 May 2019 16:12 GMT

Condition classes should only be used with WaitSets

  • Legacy Issue Number: 17063
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • Summary:

    The DataReader API provides methods to read samples with a condition. This condition can be either a ReadCondition or a QueryCondition, and in this case the samples returned are either filtered by the status (ReadCondition) or the content+status (QueryCondition).
    The ReadCondition is completely in overlap with the instance/status/view states and its use is really irrelevant when in combination with the DataReader. On the other end the only aspect of the QueryCondition that really matters to a DataReader are the query expression and parameters.

    By looking carefully at the API, it seems apparent that the ReadCondition and the QueryCondition really make sense only when used with a WaitSet. On the other end, their use in conjunction of a DataReader is a stretch and breaks the semantics of the "Condition". On principle a condition is used to "wait" for a particular status to be true, yet the DataReader "read" are – rightfully – always non-blocking. In addition, the API opens up for gratuitous runtime errors as I could write silly code as follows (in C++):

    auto rc = reader.create_readcondition();
    reader2.read(..., rc,...);

    This although silly is allowed by the API and on a proper DDS implementation should raise an exception.

    The same could happen with a QueryCondition!

    Resolution
    ---------------
    Limit the use of Read/QueryCondition to waitsets and put in place a more robust mechanism to do status and content filtering on a data-reader read.

    An example of what could be done is provided below, where I assume that the DataStatus is the former ReaderState:

    reader
    .filter_status(DataStatus::new_data())
    .filter_content(Query("x < 100 AND y < 100"))
    .read();

    Equally, one could write (again legal C++ below with little magic under-cover) :

    reader
    .instance(handle)
    .filter_status(DataStatus::new_data())
    .filter_content(Query("x < 100 AND y < 100"))
    .read();

    Notice that this code, not only is very declarative and thus shows very clearly the intent of the programmer, but in addition does not allow for the silly mistakes shown above. Further more, it really highlights he role of the Sample/Instance/View status as a "filter" on the status of data.

  • Reported: DDS-PSM-Cxx 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Wed, 15 May 2019 14:16 GMT

Remove templatization for datatype from TopicDescription

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

    In the current DDS-PSM-Cxx spec files, the TopicDescription is not only templatized for its Delegate, but also for its datatype. However, none of the functions exposed by the TopicDescription has a dependency on this datatype.

    I therefore suggest to remove the template parameter for the datatype from the TopicDescription.

  • Reported: DDS-PSM-Cxx 1.0 — Wed, 24 Apr 2019 13:01 GMT
  • Updated: Wed, 15 May 2019 14:13 GMT

MERGE CONFLICT: Modify Topic inheritance

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

    DDSPSMC11_-80 and DDSPSMC11_-81 result in a merge conflict: the definition of the TopicDescription base from which is now inherited no longer has a template parameter.

  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 15 May 2019 14:12 GMT
  • Updated: Wed, 15 May 2019 14:13 GMT

Inheritance hierarchy of C++11 PSM conflicts with inheritance hierarchy from DDS PIM

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

    In the DDS PIM the Topic inherits from two other classes: TopicDescription and Entity. However, in the C++11 PSM, this double inheritance relationship has been removed by making TopicDescription inherit from Entity, and making Topic only inherit from TopicDescription.

    Although this seems to simplify the inheritance hierarchy, it has a couple of unwanted side-effects, since all TopicDescriptions are now Entities. That means that ContentFilteredTopic and MultiTopic now offer all the operations that an Entity normally offers:

    • They have a StatusCondition
      • However, ContentFilteredTopic and MultiTopic have no statuses that are applicable to this StatusCondition.
    • They offer an operation to extract their instance handle
      • However, ContentFilteredTopic and MultiTopic are not discoverable and therefore do not have an instance handle.
    • Conceptually, Entities are supposed to offer Qos and Listeners, which ContentFilteredTopic and MultiTopic do not do.

    We want to correct for this by removing the inheritance relationship between TopicDescription and Entity and reinstating the double inheritance for Topic on both TopicDescription and Entity.

  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 16 Mar 2016 19:27 GMT
  • Updated: Wed, 15 May 2019 14:12 GMT

Use consistent way to refer to vendor specific Delegate

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

    The current DDS-PSM-Cxx spec often refers to the vendor specific Delegate in the following way:

    • A typedef refers Entity<T> to detail::Entity<T>, which is in a vendor specific file.
    • In detail::Entity, another typedef then substitutes the vendor specific Delegate for the template parameter.

    However, for some unknown reason this pattern is not followed for the DataWriter and QueryCondition classes.

    I propose to apply the same pattern to those classes as well.

  • Reported: DDS-PSM-Cxx 1