Diagram Definition Avatar
  1. OMG Specification

Diagram Definition — All Issues

  • Acronym: DD
  • Issues Count: 1,625
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
DDS15-332 Rules for evaluating liveliness by DataReader need to be clarified DDS 1.4 open
DDSSEC13-84 Changes related to key regeneration DDS-SECURITY 1.2 open
DDSXTY14-84 Make the format of annotation parameters more robust DDS-XTypes 1.3b1 open
DDSXTY14-16 Section 7.3.1.2.1.11 is unclear DDS-XTypes 1.3b1 open
DDSSEC13-52 Table 29 description of is_write_protected DDS-SECURITY 1.1b1 open
DDSSEC13-16 SecureSubmessageCategory_t in normative IDL DDS-SECURITY 1.1b1 open
DDSSEC13-83 Modify XSD to make the elements i version 1.2 optional DDS-SECURITY 1.2 open
DDSXTY14-82 Support optional for union members, add exception DDS-XTypes 1.3 open
DDSXTY14-83 Wrong type name used: VehiclePositionType DDS-XTypes 1.3 open
DDSXTY14-81 Inconsistent specification of where annotations can apply DDS-XTypes 1.3b1 open
DDSTSN-3 Minor clarifications and enhancements DDS-TSN 1.0a1 DDS-TSN 1.0b2 Resolved closed
DDSTSN-1 Update references to 802.1Qcc and 802.1Qcr, which have been merged into 802.1Q DDS-TSN 1.0a1 DDS-TSN 1.0b2 Resolved closed
DDSXTY14-80 Clarify behavior of @range and @unit with respect to type comptibility DDS-XTypes 1.3b1 open
DDS15-320 Missing escaping rules for filter expression, topic expression, query expression DDS 1.4 open
DDSXTY14-79 Typo fixes DDS-XTypes 1.3 open
DDSXTY14-78 Misspellings of "aggregated" DDS-XTypes 1.3 open
DDSXTY14-77 Inheritance rule regarding keys is overly restrictive DDS-XTypes 1.3 open
DDSJSON11-2 Validation errors in JSON Schemas DDS-JSON 1.0 open
DDSSEC12-94 Provide pre-shared protection for unauthenticated messages DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Resolved closed
DDSSEC13-82 Incorrect property names used DDS-SECURITY 1.2 open
DDSXTY14-76 Does @try_contruct(TRIM) leave strings with valid UTF-8 and UTF-16? DDS-XTypes 1.3 open
DDSXTY14-75 create_sample can't indicate failure DDS-XTypes 1.3 open
DDSSEC13-78 Operation: set_permissions_credential_and_token DDS-SECURITY 1.1b1 open
DDSSEC13-72 Builtin Auth dependency on Access Control details DDS-SECURITY 1.1b1 open
DDSSEC13-74 Misleading description of Crypto Key Exchange (8.5.1.8) DDS-SECURITY 1.1b1 open
DDSSEC13-73 Add explanation of how to use the secureWriterSet to support GROUP ordered access DDS-SECURITY 1.1b1 open
DDSSEC13-76 validate_remote_permissions interaction with Authentication Plugin DDS-SECURITY 1.1b1 open
DDSSEC13-71 Inconsistent descriptions of Data Tagging DDS-SECURITY 1.1b1 open
DDSSEC13-77 get_topic_sec_attributes 3rd parameter type DDS-SECURITY 1.1b1 open
DDSSEC13-75 IDL struct ParticipantSecurityAttributes contains ac_endpoint_properties DDS-SECURITY 1.1b1 open
DDSSEC13-70 serialized_local_participant_data passed to Auth plugin DDS-SECURITY 1.1b1 open
DDSSEC13-63 class_id string in Authentication/Permissions Tokens should include spec version DDS-SECURITY 1.1b1 open
DDSSEC13-64 Authentication Protocol: Make what is validated in the messages more explicit DDS-SECURITY 1.1b1 open
DDSSEC13-66 Add support for ChaCha20 DDS-SECURITY 1.1b1 open
DDSSEC13-69 Multiple grants in a permissions document DDS-SECURITY 1.1b1 open
DDSSEC13-67 Invalid IETF RFC document reference. DDS-SECURITY 1.1b1 open
DDSSEC13-65 Protecting the Source Timestamp DDS-SECURITY 1.1b1 open
DDSSEC13-68 IDL should be updated to match IDL 4.2 DDS-SECURITY 1.1b1 open
DDSSEC13-62 The Qos used to publish the BuiltinLoggingTopic is not specicified DDS-SECURITY 1.1b1 open
DDSSEC13-56 encode_rtps_message/decode_rtps_message error and status reporting DDS-SECURITY 1.1 open
DDSSEC13-60 Size of permission file sent on authentication can exceed max IP packet size DDS-SECURITY 1.1b1 open
DDSSEC13-55 Provide efficient way to skip encrypted implementation-specific content DDS-SECURITY 1.1b1 open
DDSSEC13-58 Add return_permissions_handle to the AccessControl interface DDS-SECURITY 1.1 open
DDSSEC13-57 Update parameters of check_remote_datawriter_register_instance DDS-SECURITY 1.1 open
DDSSEC13-61 Builtin Access Control operations (Table 63) missing entries DDS-SECURITY 1.1 open
DDSSEC13-59 Add best practice/implementation guidelines to the CryptoTransform plugin DDS-SECURITY 1.1b1 open
DDSSEC13-54 Provide a way for multiple vendors to extend the algorithms and interoperate DDS-SECURITY 1.1b1 open
DDSSEC13-53 Problematic use of multiple INFO_SRC within an RTPS DDS-SECURITY 1.1b1 open
DDSSEC12-59 Parsing messages generated by encode_serialized_payload (auth only) DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-50 Parsing messages generated by encode_serialized_payload (auth only) DDS-SECURITY 1.1b1 open
DDSSEC12-61 Table 29 description of is_write_protected DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-60 check_remote_topic domainId parameter DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-51 check_remote_topic domainId parameter DDS-SECURITY 1.1b1 open
DDSSEC12-58 AES-GCM doesn't add padding DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-49 AES-GCM doesn't add padding DDS-SECURITY 1.1b1 open
DDSSEC12-57 Builtin Crypto message authentication codes DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-54 XML Schema defines boolean literals as "true" / "false" DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-48 Builtin Crypto message authentication codes DDS-SECURITY 1.1b1 open
DDSSEC13-47 XML Schema defines boolean literals as "true" / "false" DDS-SECURITY 1.1b1 open
DDSSEC12-44 register_local_datareader and Data Protection Kind DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-45 Replace "CryptoKeyTransform" with "CryptoTransform" DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-46 "atributes" typo DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-39 register_local_datareader and Data Protection Kind DDS-SECURITY 1.1b1 open
DDSSEC13-40 Replace "CryptoKeyTransform" with "CryptoTransform" DDS-SECURITY 1.1b1 open
DDSSEC12-48 Clarify the configuration and use of certificate chains for Identity DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-43 Clarify the configuration and use of certificate chains for Identity DDS-SECURITY 1.1b1 open
DDSSEC12-50 Builtin CryptoKeyFactory direct dependency on AccessControl's config details DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-47 Inconsistent Flag Name PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_BUILTIN_IS_DISCOVERY_ENCRYPTED DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-44 Builtin CryptoKeyFactory direct dependency on AccessControl's config details DDS-SECURITY 1.1b1 open
DDSSEC12-51 Participant2ParticipantKxKeyMaterial DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-42 Inconsistent Flag Name PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_BUILTIN_IS_DISCOVERY_ENCRYPTED DDS-SECURITY 1.1b1 open
DDSSEC13-45 Participant2ParticipantKxKeyMaterial DDS-SECURITY 1.1b1 open
DDSSEC12-52 9.5.3.3.4.3 should refer to the footer, not header DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-46 9.5.3.3.4.3 should refer to the footer, not header DDS-SECURITY 1.1b1 open
DDSSEC13-41 "atributes" typo DDS-SECURITY 1.1b1 open
DDSSEC12-37 Modify Security's QoS changes for compatibility with RTPS DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-32 Modify Security's QoS changes for compatibility with RTPS DDS-SECURITY 1.1b1 open
DDSSEC12-38 Broken cross-references DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-43 IDL ParticipantSecurityAttributes::plugin_participant_attributes DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-38 IDL ParticipantSecurityAttributes::plugin_participant_attributes DDS-SECURITY 1.1b1 open
DDSSEC12-42 Various Typos DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-41 Reduce the range of Reserved RTPS parameter IDs DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-40 Return types in CryptoKeyFactory interface description DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-36 Reduce the range of Reserved RTPS parameter IDs DDS-SECURITY 1.1b1 open
DDSSEC12-39 AuthRequestMessageToken future_challenge property DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-35 Return types in CryptoKeyFactory interface description DDS-SECURITY 1.1b1 open
DDSSEC13-34 AuthRequestMessageToken future_challenge property DDS-SECURITY 1.1b1 open
DDSSEC13-37 Various Typos DDS-SECURITY 1.1b1 open
DDSSEC13-33 Broken cross-references DDS-SECURITY 1.1b1 open
DDSSEC12-31 Security for DDS-RPC DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-32 Authentication behavior use of built-in endpoints DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-26 Security for DDS-RPC DDS-SECURITY 1.1b1 open
DDSSEC12-33 Use a submessage flag to indicate Data/Frag submessage has a transformed payload DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-27 Authentication behavior use of built-in endpoints DDS-SECURITY 1.1b1 open
DDSSEC13-28 Use a submessage flag to indicate Data/Frag submessage has a transformed payload DDS-SECURITY 1.1b1 open
DDSSEC12-34 Wrong XML tag in description of Enable Read Access Control DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-29 Wrong XML tag in description of Enable Read Access Control DDS-SECURITY 1.1b1 open
DDSSEC12-35 Description of the PluginEndpointSecurityAttributes DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-36 Description of the EndpointSecurityAttributes DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-30 Description of the PluginEndpointSecurityAttributes DDS-SECURITY 1.1b1 open
DDSSEC13-31 Description of the EndpointSecurityAttributes DDS-SECURITY 1.1b1 open
DDSSEC12-25 IDL get_topic_sec_attributes parameter typo DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-21 IDL get_topic_sec_attributes parameter typo DDS-SECURITY 1.1b1 open
DDSSEC12-28 Determining when to use DCPSParticipantMessageSecure DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-27 ParticipantStatelessMessage definition DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-24 Determining when to use DCPSParticipantMessageSecure DDS-SECURITY 1.1b1 open
DDSSEC13-23 ParticipantStatelessMessage definition DDS-SECURITY 1.1b1 open
DDSSEC12-26 IDL SubscriptionBuiltinTopicDataSecure inheritance DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-30 8.4.2.9.24 section name typo DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-22 IDL SubscriptionBuiltinTopicDataSecure inheritance DDS-SECURITY 1.1b1 open
DDSSEC13-25 8.4.2.9.24 section name typo DDS-SECURITY 1.1b1 open
DDSSEC12-19 Allow expressions to be used in the data-tag permissions DDS-SECURITY 1.1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-15 Allow expressions to be used in the data-tag permissions DDS-SECURITY 1.1 open
DDSSEC12-18 Authentication interface begin_handshake_reply() DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-21 decode_datawriter_submessage uses "in" for SecurityException DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-20 SecureSubmessageCategory_t in normative IDL DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-14 Authentication interface begin_handshake_reply() DDS-SECURITY 1.1b1 open
DDSSEC13-17 decode_datawriter_submessage uses "in" for SecurityException DDS-SECURITY 1.1b1 open
DDSSEC12-22 get_datawriter/reader_sec_attributes inconsistent IDL DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-23 Authentication interface set_permissions_credential_and_token DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-24 IDL LongLongSeq unused DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-18 get_datawriter/reader_sec_attributes inconsistent IDL DDS-SECURITY 1.1b1 open
DDSSEC13-19 Authentication interface set_permissions_credential_and_token DDS-SECURITY 1.1b1 open
DDSSEC13-20 IDL LongLongSeq unused DDS-SECURITY 1.1b1 open
DDSSEC13-13 DataHolder IDL inconsistent DDS-SECURITY 1.1b1 open
DDSSEC12-9 The specification should not duplicate (copy) the machine readable XSD files DDS-SECURITY 1.0 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-8 Section 3 (Normative References) should be updated and expanded DDS-SECURITY 1.0 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-10 Issues with the UML model used in the specification DDS-SECURITY 1.0 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-8 The specification should not duplicate (copy) the machine readable XSD files DDS-SECURITY 1.0 open
DDSSEC13-7 Section 3 (Normative References) should be updated and expanded DDS-SECURITY 1.0 open
DDSSEC12-13 Avoid sending permissions as part of Authentication Handshake DDS-SECURITY 1.1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-12 Avoid sending permissions as part of Authentication Handshake DDS-SECURITY 1.1 open
DDSSEC12-12 Instance-Level access-control DDS-SECURITY 1.1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-11 Instance-Level access-control DDS-SECURITY 1.1 open
DDSSEC12-11 say explicitly that is_valid is set to zero if that is case DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC12-15 DataHolder IDL inconsistent DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-10 say explicitly that is_valid is set to zero if that is case DDS-SECURITY 1.1b1 open
DDSSEC13-9 Issues with the UML model used in the specification DDS-SECURITY 1.0 open
DDSSEC12-2 Built-in Authentication and Cryptography plugins tied together by SharedSecretHandle implementation DDS-SECURITY 1.0b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-2 Built-in Authentication and Cryptography plugins tied together by SharedSecretHandle implementation DDS-SECURITY 1.0b1 open
DDSSEC12-4 Examples of Wildcard permissions DDS-SECURITY 1.0 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-3 Examples of Wildcard permissions DDS-SECURITY 1.0 open
DDSSEC12-5 The UML model should be cleaned up DDS-SECURITY 1.0 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-4 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 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-5 Remove Jira-issue related comments from machine-readable files DDS-SECURITY 1.0 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 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-6 The DDS-Security specification makes some modifications to the DDSI-RTPS protocol that should be taken into consideration DDS-SECURITY 1.0 open
DDSSEC12-1 Complexity of Authentication Plugin Model DDS-SECURITY 1.0b1 DDS-SECURITY 1.2 Deferred closed
DDSSEC13-1 Complexity of Authentication Plugin Model DDS-SECURITY 1.0b1 open
DDSSEC12-90 Meeting CNSSP-15 security requirements DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-122 Provide mechanism for changing the session keys associated with the different DDS Entitites DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-101 Add support for DomainTag to DDS-Security DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-29 Specify DDS Security uses XCDR serialization version 1 DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-108 secure log topic has a year 2038 issue DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-53 Clarify meaning of "bit array" and specify number of constant bytes in HMAC input when computing SessionKey DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-110 Corrections to tables describing IdentityStatusToken, AuthenticatedPeerCredentialToken, AuthRequestMessageToken DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-86 Security for XTypes TypeLookup Service DDS-SECURITY 1.1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-56 Encoding of Diffie-Hellman Public Key DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-92 Underspecified RSASSA-PSS-SHA256 Salt Length DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Duplicate or Merged closed
DDSSEC12-115 Sectiob 8.2.1 Expand set of submessages that may be sent on TSN streams DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Closed; Out Of Scope closed
DDSSEC12-116 DDS-Security impact on DDS-TSN DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Closed; Out Of Scope closed
DDSSEC12-91 How are 'subject_name' fields compared? DDS-SECURITY 1.1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-62 Indicate that AccessControl operations need to be called on a set_qos DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-79 Built-in Access Control: interpretation of enable_read/write_access_control DDS-SECURITY 1.1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-49 Mutability of PartitionQos DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Resolved closed
DDSSEC12-55 Using string literals as binary_property values inside Handshake Tokens DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Duplicate or Merged closed
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 DDS-SECURITY 1.2 Closed; Out Of Scope closed
DDSSEC12-85 check_remote_participant when default is ALLOW DDS-SECURITY 1.1b1 DDS-SECURITY 1.2 Duplicate or Merged closed
DDSSEC12-16 Define rules for references between elements DDS-SECURITY 1.1 DDS-SECURITY 1.2 Closed; Out Of Scope closed
DDSSEC12-14 CryptoTransformIdentifier extensibility FINAL is not compatibly with its derived classes DDS-SECURITY 1.1 DDS-SECURITY 1.2 Duplicate or Merged closed
DDSSEC12-3 Provide mechanisms to extend Governance and Permissions files without breaking interoperability DDS-SECURITY 1.0b1 DDS-SECURITY 1.2 Resolved closed
DDSIRTP26-39 writing error DDSI-RTPS 2.5 open
DDSXTY14-74 Clarify the intended member ID of a union's discriminator DDS-XTypes 1.3b1 open
DDSXTY14-73 Ambiguous definition and/or usage of PUSH(ORIGIN=0) DDS-XTypes 1.3b1 open
DDSXTY13-86 Clarify the intended member ID of a union's discriminator DDS-XTypes 1.3 open
DDSWEB11-3 Correct inconsistency on the URLs for the machine readable documents in the FTF2 report DDS-WEB 1.0 open
DDSXTY14-56 XCDR2 serialization of sequences of non-primitive elements DDS-XTypes 1.3b1 open
DDSXTY14-72 XCDR2 serialization of non-trivial maps DDS-XTypes 1.3b1 open
DDSXML11-5 DDS::Time_t/Duration_t changes DDS-XML 1.0 open
DDS15-13 DDS defines Time_t with seconds as long, this is 32bit. This will give an issue after 2038 DDS 1.2 open
DDS15-331 Proper interpretation of Duration_t for negative values DDS 1.4 open
DDSXTY14-69 Section contains a duplicate sentence from the next section. DDS-XTypes 1.3 open
DDSXTY13-85 Ambiguous definition and/or usage of PUSH(ORIGIN=0) DDS-XTypes 1.3 open
DDSXML11-4 How to describe the locator information in XML DDS-XML 1.0 open
DDSIRTP26-38 Extend InfoSource to contain RTPS HeaderExtension fields DDSI-RTPS 2.5 open
DDSXTY14-68 Update IDL definition of union TypeIdentifier in Annex B to account for primitive types DDS-XTypes 1.3b1 open
DDSXTY14-59 Clarify accessing discriminator of a DynamicData union DDS-XTypes 1.3 open
DDSIRTP26-37 Specify how a discovery service could be used to bootstap discovery DDSI-RTPS 2.5 open
DDSXTY14-38 Data Representation for RTPS's Serialized Key DDS-XTypes 1.3 open
DDSIRTP26-3 SequenceNumberSet validity could be too strict DDSI-RTPS 2.3 open
DDSXTY14-67 Typos in DynamicData UML Diagrams DDS-XTypes 1.3 open
DDSXTY14-66 Conflicting Order of Minimal Struct and Union Members in TypeObject DDS-XTypes 1.3 open
DDSXTY14-64 Should the TypeObject mark key members as must understand DDS-XTypes 1.3b1 open
DDSXTY14-65 Typo in DataRepresentationMask DDS-XTypes 1.3 open
DDSPSMC11_-4 DynamicData should be value type, not a reference type DDS-PSM-Cxx 1.0b2 open
DDSXTY14-47 Encoding of TypeInformation in SEDP DDS-XTypes 1.3 open
DDSXTY14-53 Description on how to encode Participant GUID in dds::rpc::RequestHeader seems wrong DDS-XTypes 1.3b1 open
DDSXTY14-54 Impossible to handle @must_understand AND @optional fields in an @appendable struct correctly DDS-XTypes 1.3b1 open
DDSXTY14-63 bitset types not defined DDS-XTypes 1.3b1 open
DDSIRTP26-36 Minor Typo in SubmessageKind IDL DDSI-RTPS 2.5 open
DDSXTY14-61 DynamicTypeSupport IDL defnition is invalid IDL DDS-XTypes 1.3 open
DDSIRTP26-35 DataFrag submessage element naming DDSI-RTPS 2.5 open
DDSIRTP26-34 Version number is inconsistent DDSI-RTPS 2.5 open
DDSIRTP26-4 Inconsistent notation used to represent bit positions pictorially DDSI-RTPS 2.5 open
DDSXTY14-60 Table 9 is missing BITMASK_TYPE DDS-XTypes 1.3 open
DDSIRTP26-33 Typo in 9.4.5.7.1 Flags in the Submessage Header DDSI-RTPS 2.5 open
DDS15-329 set_listener behavior is underspecified DDS 1.4 open
DDSIRTP26-6 Network amplification DDSI-RTPS 2.5 open
DDSXTY14-28 IDL's fixed data type is required in XTypes DDS-XTypes 1.3 open
DDSXTY14-36 Representing union case labels in TypeObject DDS-XTypes 1.3 open
DDSXTY14-35 Anonymous Types in Strongly Connected Components DDS-XTypes 1.3 open
DDSIRTP26-31 Inconsistency in the wire representation of SequenceNumber type fields DDSI-RTPS 2.5 open
DDSIRTP26-32 Typo in Table 9.18 (PID__DOMAIN_ID) DDSI-RTPS 2.5 open
DDSIRTP26-30 Incorrect definition of a user-defined within EntityId_t DDSI-RTPS 2.5 open
DDSXTY14-24 TypeFlags usage in normative IDL DDS-XTypes 1.3 open
DDSXTY14-58 Dynamic Binding: equals() for DynamicType/DynamicTypeMember and related types DDS-XTypes 1.3 open
DDSXTY14-57 Annex C: BoundSeq IDL type not defined DDS-XTypes 1.3 open
DDS15-250 Align with XTYPES 1.3 and IDL 4.2 DDS 1.4 open
DDS15-315 InstanceHandle_t underspecified DDS 1.4 open
DDSIRTP26-29 Wrong data type for serializedPayload in DATAFRAG DDSI-RTPS 2.5 open
DDS15-328 Annex A: Ownership Profile is unclear DDS 1.4 open
DDSIRTP26-28 Introduce a concept of Partitions at the DomainParticipant level DDSI-RTPS 2.5 open
DDSIRTP26-27 The specs and illustration of the ChangeForReader are missing / have been removed DDSI-RTPS 2.5 open
DDSIRTP26-26 Error in formatting pseudo code DDSI-RTPS 2.5 open
DDSIRTP26-25 Handling of non-existent cache changes in logical action DDSI-RTPS 2.5 open
DDS15-327 The "depth" QoS setting does not have any bounds set DDS 1.4 open
DDSXML11-3 Missing DDS-XTypes extensions (which should be part of DDS 1.5) DDS-XML 1.0 open
DDSIRTP26-24 Inconsistent use of higuest_sent_seq_num and highestSentChangeSN DDSI-RTPS 2.5 open
DDSIRTP26-23 Inconsistent use of SEQUENCE_NUMBER_INVALID; for highestSentChangeSN DDSI-RTPS 2.5 open
DDSXTY14-55 Add support for data-level compression during serialization DDS-XTypes 1.3b1 open
DDSIRTP26-17 Fields writerSet and secureWriterSet are missing in wire representation: DDSI-RTPS 2.5 open
DDSIRTP26-16 Paramter id and length should be unsigned short DDSI-RTPS 2.5 open
DDSIRTP26-14 Masks in table 9.6 (ParameterId subspaces) should be hexadecimal DDSI-RTPS 2.5 open
DDSIRTP26-13 Note on the message wide CRC check DDSI-RTPS 2.5 open
DDSIRTP26-11 Textual error in section 9.4.5.2.1 DDSI-RTPS 2.5 open
DDSIRTP26-10 Description incomplete DDSI-RTPS 2.5 open
DDSIRTP26-12 CRC computation for Checksum128_t undefined DDSI-RTPS 2.5 open
DDSIRTP26-15 Please ignore Implementation Work Blocked flag in issue INBOX-1375 DDSI-RTPS 2.5 open
DDSXTY14-17 Typo or editing issue DDS-XTypes 1.3b1 open
DDSXTY14-44 Default value and @default annotations DDS-XTypes 1.3 open
DDSJSON11-1 JSON Representation of Unions DDS-JSON 1.0 open
DDSIRTP26-9 Unclear how to discover GROUP_GUID/GROUP_ENTITY_ID from a coherent Publisher DDSI-RTPS 2.5 open
DDS15-326 Incorporate the lookup_topicdescription change added in XTYPES 1.3 DDS 1.4 open
DDSPSMC11_-96 dds::core::status::StatusMask should allow you to set mutiple Status bits by using the logical OR operation DDS-PSM-Cxx 1.0 open
DDS15-245 Clarify the PartitionQosPolicy DDS 1.4 open
DDSIRTP26-7 Provide a pre-shared key protection mechanism DDSI-RTPS 2.5 open
DDSXTY14-52 Missing TK_INT8 and TK_UINT8 in the IDL machine readable file DDS-XTypes 1.3b1 open
DDSXTY14-51 Extensibility of inherited structures DDS-XTypes 1.3b1 open
DDSXTY14-20 Inconsistent Definitions of RTPS Encapsulation DDS-XTypes 1.3b1 open
DDSXTY14-50 Integrate annotations for range/min/max with try_construct DDS-XTypes 1.3b1 open
DDSXTY14-49 Remove all IDL42 specified parts DDS-XTypes 1.3 open
DDSXTY14-48 8 bit types mising in 7.2.1 DDS-XTypes 1.3 open
DDS15-316 find_topic/delete_topic underspecified DDS 1.4 open
DDS15-325 Read / Take with max_samples = 0 DDS 1.4 open
DDSIRTP25-34 Change the CRC-64 polynomial introduced in issue DDSIRTP25-12 DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-4 Unclear specification on how the Publisher GUID is communicated DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Duplicate or Merged closed
DDSIRTP25-3 Incomplete specification of how a Publisher and Subscriber are identified DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-2 Discriminating the reasons for a GAP DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-12 Address deferred issue: Inclusion of Message Size & CRC as part of DDSI/RTPS Messages DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-17 Editorial corrections DDSI-RTPS 2.3 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-25 Revise list of Submessages EntityIDs and PIDs reserved for other specifications DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-28 Apply modifications to Clause 9.6.3.8, “KeyHash (PID_KEY_HASH)" from XTYPES DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-9 Flag GroupInfoFlag and fields gapStartGSN and gapEndGSN unspecified in PSM DDSI-RTPS 2.3 DDSI-RTPS 2.5 Duplicate or Merged closed
DDSIRTP25-1 SEQUENCENUMBER_UNKNOWN missing from PSM DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-27 Support transport-level RTPS message compression DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Deferred closed
DDSIRTP25-24 Add an INFO_AGE submessage DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Duplicate or Merged closed
DDSIRTP25-6 Update Acknowledgemts, Copyright and Statement of Proof DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-11 currentGSN.value < lastGSN.value condition seems wrong DDSI-RTPS 2.3 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-10 8.3.7.5 / 9.4.5.6 HeartBeat Submessage DDSI-RTPS 2.3 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-7 PSM and PIM description of Gap message not matching DDSI-RTPS 2.3 DDSI-RTPS 2.5 Resolved closed
DDSIRTP25-13 Interoperability of Transient/Persistent data DDSI-RTPS 2.3b1 DDSI-RTPS 2.5 Deferred closed
DDSXTY14-39 TypeLookup IDL Inconsistency DDS-XTypes 1.3 open
DDSRPC11-5 Common Types contains invalid IDL DDS-RPC 1.0 open
DDSXTY14-46 Typo in Member of AnnotationParameterValue DDS-XTypes 1.3 open
DDSIRTP26-5 Section 9.4.2.9 Timestamps shows 'seconds' as 'long' instead of 'unsigned long' DDSI-RTPS 2.5 open
DDS15-324 sample lost/rejected should be clarified and extended DDS 1.4 open
DDS11-15 DDS should use typed modules DDS 1.2 open
DDS15-323 Order in which implied IDL and language mappings interact DDS 1.4 open
DDS15-322 Incorrect value for GROUPDATA_QOS_POLICY_NAME DDS 1.2 open
DDSXTY14-45 The list of valid KEY types does not include String types DDS-XTypes 1.3 open
DDSOPCU11-3 IDL keywords used as interface/module DDS-OPCUA 1.0 open
DDSOPCU11-2 Don't use anonymous types DDS-OPCUA 1.0 open
DDSXML11-2 No mapping for uint8/int8, map, bitset DDS-XML 1.0 open
DDSIRTP26-2 Support transport-level RTPS message compression DDSI-RTPS 2.3b1 open
DDSIRTP26-1 Interoperability of Transient/Persistent data DDSI-RTPS 2.3b1 open
DDS15-321 Example class table seems to violate written convention DDS 1.4 open
DDS15-28 DDS Entities should have a name DDS 1.2 open
DDSSEC11-82 OCSP stapling to enhance certificate status checking during handshake DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
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
DDSJSON-1 Handling Unsupported Numeric Values like Infinity and NaN DDS-JSON 1.0a1 DDS-JSON 1.0 Resolved closed
DDS15-314 Change the default value for DataWriterLifecycle::autodispose_unregistered_instances and behavior when a DataWriter is deleted DDS 1.4 open
DDSXTY14-33 Enums with different holder types should not be assignable DDS-XTypes 1.3 open
DDSXTY14-25 7.4.3.5.3 contradictory rules for collections DDS-XTypes 1.3 open
DDSXTY14-27 DataRepresentationQosPolicy default DDS-XTypes 1.3 open
DDSXTY14-29 Specify that TypeLookup Service uses XCDR2 DDS-XTypes 1.3 open
DDSXTY14-26 XTypes spec is missing topic names for TypeLookupService DDS-XTypes 1.3 open
DDSXTY14-23 Missing alignment for XCDR1 mutable's sentinel DDS-XTypes 1.3b1 open
DDSIRTP23-26 How should interoperable implementations deal with Transient / Persistent data? DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Deferred closed
DDSRPC11-1 Mapping of one single Topic per Service does not work well with DDS Security DDS-RPC 1.0 open
DDSPSMC11_-95 Listener model breaks API design goal of automatic resource management DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-93 Typo fixes DDS-PSM-Cxx 1.0 open
DDSXTY14-21 Can structures contain constant declarations? DDS-XTypes 1.3b1 open
DDS15-313 Editorial corrections DDS 1.4 open
DDS15-199 Typo DDS 1.4 open
DDS15-312 Default value for WRITER_DATA _LIFECYCLE v should be FALSE DDS 1.4 open
DDSPSMC11_-94 DynamicType should be a value type, not a reference type DDS-PSM-Cxx 1.0b2 open
DDSXTY14-19 Confusing description of FINAL on 7.2.3 TypeExtensibilityandMutability DDS-XTypes 1.3b1 open
DDS15-311 Add a function that allows releasing any resources created by the DomainParticipantFactory DDS 1.4 open
DDSXTY14-14 Define Implied Keys Behavior DDS-XTypes 1.3b1 open
DDSXTY14-18 7.4.3.5.3 doesn't define OPTIONS DDS-XTypes 1.3b1 open
DDSXTY14-13 Be more precise on meaning of string lengths and bounds DDS-XTypes 1.3b1 open
DDSXTY14-15 Implementation Defined Default Nested Behavior DDS-XTypes 1.3b1 open
DDS15-310 get_discovered_participant_data() should return BAD_PARAMETER instead of PRECONDITION_NOT_MET DDS 1.4 open
DDSXTY14-12 Need to add an ignore_enum_literal_names in TypeConsistencyEnforcement QosPolicy DDS-XTypes 1.3b1 open
DDSXTY14-11 Clarify whether the algorithm to compute KeyHash is specific to XTYPES DDS-XTypes 1.3b1 open
DDSXTY14-10 Missing parameter in Annex C operation DynamicDataFactory::create_data DDS-XTypes 1.3b1 open
DDSXTY14-8 Extra text left in section 7.2.2.4.4.4.4 Member IDs DDS-XTypes 1.3b1 open
DDSOPCU11-1 Typos and Inconsistencies DDS-OPCUA 1.0 open
DDSXRCE11-3 Extra fields in IDL of 7.8.2.1 create_client DDS-XRCE 1.0 open
DDSXTY14-6 Extra fields in IDL of 7.8.2.1 create_client DDS-XTypes 1.3b1 open
DDS15-256 Define InstanceHandle_t and DomainId_t portably DDS 1.4 open
DDS15-5 InstanceHandle_t/Domain ID DDS 1.2 open
DDS15-240 The start time of type Time_t is not defined DDS 1.4 open
DDS15-251 Wrong name for DataRepresentationQosPolicy field DDS 1.4 open
DDS15-246 Collection of longs misrepresented in 2.2.1.1 MyClass DDS 1.4 open
DDS15-247 Names of listener operations are incorrect in UML diagrams DDS 1.4 open
DDS15-249 Consider replacing @Choice annotation with XTYPES 1.2 unions DDS 1.4 open
DDS15-195 Typo in section 2.2.2.5 Subscription Module DDS 1.4 open
DDS15-188 DATAWRITER_QOS_USE_TOPIC_QOS and DATAREADER_QOS_USE_TOPIC_QOS DDS 1.2 open
DDS15-51 Invalid DURABILITY_SERVICE reference on the DataWriter DDS 1.2 open
DDS15-20 The DDS Specification should define legal DDS Topic Types DDS 1.4 open
DDS15-185 Invalid DURABILITY_SERVICE reference on the DataWriter DDS 1.1 open
DDS15-186 subset of OMG IDL DDS 1.1 open
DDS15-181 Typo on description of class TopicDescription DDS 1.2 open
DDS15-182 Clarification of create_multitopic behavior DDS 1.2 open
DDS15-184 create_contentfilteredtopic Method Prototype and Description Out DDS 1.2 open
DDS15-178 Clarification of instance_state -- Section: 2.1.2.5.1.3 DDS 1.2 open
DDS15-179 Clarify behavior of register_type operation DDS 1.2 open
DDS15-174 Typo in Section: 2.1.3 DDS 1.2 open
DDS15-176 Typo on descripton of "read" operation DDS 1.2 open
DDS15-172 Typo in Section: 2.2.3.14 DDS 1.2 open
DDS15-173 Typo in description of "persistence" service responsibility DDS 1.2 open
DDS15-34 'synchronous' and 'asynchronous' switched DDS 1.2 open
DDS15-35 Specify the allowed IDL Types within DDS Topic structs DDS 1.2 open
DDS15-37 DDS typos and omissions DDS 1.2 open
DDS15-153 Definition of BuiltinTopicKey_t DDS 1.2 open
DDS15-235 DURABILITY history depth should be de-coupled from the KEEP_LAST history depth used for reliability DDS 1.4 open
DDS15-32 No specific package definition for the entities of the model in case of JAVA language binding DDS 1.4 open
DDS15-33 Deprecated usage of IDL in the DDS spec DDS 1.2 open
DDS15-31 Mapping of OMG IDL to C++ for DDS DDS 1.2 open
DDS15-25 History and Reliability should be orthogonally independent concerns DDS 1.4 open
DDS15-21 Wrong definition of GROUPDATA_QOS_POLICY_NAME constant in IDL DDS 1.4 open
DDS15-14 : #define HANDLE_TYPE_NATIVE long typedef HANDLE_TYPE_NATIVE InstanceHandle_t; DDS 1.2 open
DDS15-15 For ContentFilteredTopic::get_expression_parameters the argument name is not given in the spec DDS 1.2 open
DDS15-16 Introduce new typedef for anonymous types DDS 1.2 open
DDS15-17 The get_sample_lost method seems to be part of the Subscriber class DDS 1.1 open
DDS15-8 DDS should require to annotate IDL to indicate which IDL types are used for dds DDS 1.2 open
DDS15-9 DDS specification should be more precise on NATIVE defines DDS 1.2 open
DDS15-10 Add DDS::STATUS_MASK_NONE DDS 1.2 open
DDS15-12 Add new mask which will let DDS callback on the listener to gets its mask DDS 1.2 open
DDSXTY13-22 Description of KeyHash computation needs update to CDR version 2 DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-21 Type compatibility when members types define keys DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-19 Representation of Built-in Annotations in Dynamic Types DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-15 Be explicit about which Types can be used for DDS Topics DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-73 Correct listed inconsistencies & missing items DDS-XTypes 1.2 DDS-XTypes 1.3 Duplicate or Merged closed
DDSXTY13-81 Correct XSD issues identified during AB review DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-52 Duplication of sections 7.3.1.2.3 and 7.3.1.2.6 DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-49 Add a Need @data_representation annotation DDS-XTypes 1.2 DDS-XTypes 1.3 Duplicate or Merged closed
DDSXTY13-46 Need @data_representation annotation and clean terminology in 7.4.x DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-60 Update Normative references to latest versions of IDL and DDS DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-64 Type compatibility rules for structs with keys DDS-XTypes 1.2 DDS-XTypes 1.3 Duplicate or Merged closed
DDSXTY13-40 Restructure Section 7.2 "Type System" to include the annotation semantics & align with IDL 4.2 DDS-XTypes 1.2 DDS-XTypes 1.3 Deferred closed
DDSXTY13-41 Rules for type compatibility are incomplete DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-24 Incomplete application of issue DDSXTY12-18 resolution DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-12 Further corrections DDS-XTypes 1.2b1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-11 DynamicType / DynamicTypeBuilder multiplicity of members DDS-XTypes 1.2b1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-7 Add support for signed and unsigned 8-bit integers DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-4 XSD for XML type representation should not specify default values for attributes representing annotations DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-2 Algorithm to compute autoid is missing from the specification DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-1 Inconsistencies and missing items DDS-XTypes 1.1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-18 Clarify which of the options bits are set to indicate padding bytes DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-29 Endianess bit in DHEADER causes innefficiencies DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-17 Annotation for denoting topic types DDS-XTypes 1.2b1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-5 Typographical corrections and minor rewordings DDS-XTypes 1.2b1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-27 Clarify valid ranges of memberIDs DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-26 Setting of @default with @optional members DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-20 Reseting the alignment after Encapsulation Header DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-23 Inheritance rules not sufficient regarding keys and memberID assignment DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-43 Organization of section 7.2.2.4.4 is confusing DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-36 Remove Endianness bit from DHEADER DDS-XTypes 1.2 DDS-XTypes 1.3 Duplicate or Merged closed
DDSXTY13-32 Ambiguity in Table 9 and Obsolete language in section 7.3.1.2.1.10 DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-42 Compatibility of Enum should be allowed even if there is just one common literal DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-10 Union discriminator value without associated member DDS-XTypes 1.2b1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-16 Provide a more efficient serialization for short strings and sequences DDS-XTypes 1.2 DDS-XTypes 1.3 Deferred closed
DDSXTY13-6 Restrictions on MAP key element type should include ENUM DDS-XTypes 1.2b1 DDS-XTypes 1.3 Closed; No Change closed
DDSXTY13-31 Redefinition of the LC=6 and LC=7 DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-28 Computation of KeyHash (7.6.7 Interoperability of Keyed Topics) needs additional detail DDS-XTypes 1.2 DDS-XTypes 1.3 Duplicate or Merged closed
DDSXTY13-8 The definition of ReliabilityQosPolicyKind in Annex D is inconsistent with RTPS DDS-XTypes 1.2 DDS-XTypes 1.3 Duplicate or Merged closed
DDSXTY13-13 Union default values (Table 9) DDS-XTypes 1.2b1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-9 Explicitly define the values for ReliabilityQosPolicyKind DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXRCE-6 Serial Transport profile DDS-XRCE 1.0b1 DDS-XRCE 1.0 Resolved closed
DDSXRCE-5 Read Data Stream DDS-XRCE 1.0b1 DDS-XRCE 1.0 Resolved closed
DDSXRCE-4 Possible CREATE_CLIENT and STATUS_AGENT reduction DDS-XRCE 1.0b1 DDS-XRCE 1.0 Resolved closed
DDSXRCE-3 New TIME submessage DDS-XRCE 1.0b1 DDS-XRCE 1.0 Resolved closed
DDSXRCE-14 Move section 11.4 'Serial Transport' to a new Annex C DDS-XRCE 1.0b1 DDS-XRCE 1.0 Resolved closed
DDSXRCE-2 StreamId in ACKNACK and HEARTBEAT DDS-XRCE 1.0b1 DDS-XRCE 1.0 Resolved closed
DDSXRCE-1 Erratum DDS-XRCE 1.0b1 DDS-XRCE 1.0 Resolved closed
DDSOPCU-3 Improve readability of a number of figures DDS-OPCUA 1.0b1 DDS-OPCUA 1.0 Resolved closed
DDSOPCU-1 Update Schema Files and XML files to Use DDS-XML 1.0 DDS-OPCUA 1.0b1 DDS-OPCUA 1.0 Resolved closed
DDSOPCU-5 Update dds-opcua_model.xmi and normative references to most recent versions DDS-OPCUA 1.0b1 DDS-OPCUA 1.0 Resolved closed
DDSXTY14-5 Consider referencing DDS-XML for the XML type and data representations DDS-XTypes 1.3b1 open
DDS15-309 Extend SampleInfo with sequenceNumber and reception_timestamp DDS 1.4 open
DDS15-4 Spec lacks definition regarding uniqueness of InstanceHandle_t DDS 1.2 open
DDSRPC11-4 Consider replacing @Choice annotation with XTYPES 1.2 unions DDS-RPC 1.0 open
DDS15-197 Legal characters and length of Topic Name DDS 1.4 open
DDS15-1 TypeSupport::get_type_name should be precisely specified DDS 1.2 open
DDS15-27 behaviour of redefining multiple times the same topic with different QoS not clearly specified DDS 1.2 open
DDS15-26 Missing APIs for (read|take)_instance_w_condition DDS 1.4 open
DDS15-43 DDS DCPS Issue: PRESENTATION=GROUP and QoS DDS 1.2 open
DDS15-24 The compatibility rules for the Presentation QoS are too strict DDS 1.2 open
DDS15-303 PARTITION PolicyQos should be in DataReader/DataWriter DDS 1.4 open
DDS15-194 Coherent updates with best efforts DDS 1.4 open
DDS15-183 Clarification of resource management DDS 1.2 open
DDS15-177 Section: 2.1.2.5.3 clarification of parameters to 'read/take' operation DDS 1.2 open
DDS15-248 Deprecate Basic Service Mapping DDS 1.4 open
DDSXTY14-4 Wrong name for DataRepresentationQosPolicy field DDS-XTypes 1.3b1 open
DDS15-36 DURABILITYSERVICE_POLICY_NAME DDS 1.2 open
DDS15-23 When using GROUP access scope presentation QoS, allow for read/take outside of begin_access and end_access block DDS 1.2 open
DDS15-22 Allow for more optimized list returned by get_datareaders() DDS 1.2 open
DDS15-266 Organize definitions of Time_t, Duration_t and other common types in the PIM DDS 1.4 open
DDS15-7 Add several with_profile methods DDS 1.2 open
DDS15-6 get_type_name, class or object method DDS 1.2 open
DDS15-258 Add a DomainTag to the PSM DDS 1.4 open
DDS15-3 Write with handle_nil underspecified DDS 1.2 open
DDS15-2 ContentFilteredTopics should be removed. Filtering belongs to DataReaders DDS 1.2 open
DDSXTY14-2 Specify more clearly which types have a name and how it is constructed DDS-XTypes 1.3b1 open
DDSXTY14-1 Add Unions to types supported in Queries and Filters DDS-XTypes 1.3b1 open
DDS15-255 What can be done with a disabled Topic? DDS 1.4 open
DDS15-254 Specify the behavior of instance state machine in case of a disconnect-reconnect scenario DDS 1.4 open
DDS15-253 Consider adding some of the concepts in the new PSMs to the PIM DDS 1.4 open
DDSPSMC11_-3 Missing get_discovered_participants and get_discovered_participant_data functions DDS-PSM-Cxx 1.0b2 open
DDS15-252 Clarify definition of counts in Plain Communication Status DDS 1.4 open
DDSPSMC11_-86 Instance handle constructor for TopicInstance should be deleted. DDS-PSM-Cxx 1.0 open
DDSPSMC11_-77 Unintuitive way to access extension member functions DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-69 Condition classes should only be used with WaitSets DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-71 Remove templatization for datatype from TopicDescription DDS-PSM-Cxx 1.0 open
DDSPSMC11_-82 MERGE CONFLICT: Modify Topic inheritance DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-25 Inheritance hierarchy of C++11 PSM conflicts with inheritance hierarchy from DDS PIM DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-73 Use consistent way to refer to vendor specific Delegate DDS-PSM-Cxx 1.0 open
DDSPSMC11_-7 Inconsistent ways to set functor in Condition types DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-79 MERGE CONFLICT: Modify description of additional StatusCondition constructor. DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-70 StatusCondition should have a singleton delegate DDS-PSM-Cxx 1.0 open
DDS15-52 DataReader semantics for historical data are insufficient DDS 1.2 open
DDSPSMC11_-75 MAP_TYPE enumeration constant should be redefined due to clash with POSIX macro DDS-PSM-Cxx 1.0b2 open
DDSJAVA11_-1 DataReader.read should return an Iterable collection, not an Iterator DDS-Java 1.0b2 open
DDSPSMC11_-1 API correction required to dds/sub/find.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-72 Transform AnyDataWriter and AnyDataReader from wrappers into parent classes. DDS-PSM-Cxx 1.0 open
DDSPSMC11_-74 Define relationship between Query and QueryCondition DDS-PSM-Cxx 1.0 open
DDSXRCE11-2 CREATE_CLIENT example: typo in hex representation of submessageLength DDS-XRCE 1.0b1 open
DDSXRCE11-1 Serial Transport (section C.1) should be a subsection of 11 DDS-XRCE 1.0b1 open
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-6 Message Size should be included as part of DDSI/RTPS Messages DDSI-RTPS 2.1 DDSI-RTPS 2.3 Deferred closed
DDSIRTP23-78 PID_DIRECTED_WRITE and PID_ORIGINAL_WRITER_INFO need further description DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-29 How should interoperable implementations deal with Group Coherent updates DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-30 RTF needs to agree any change of name and/or URL for specification DDSI-RTPS 2.1 DDSI-RTPS 2.3 Deferred closed
DDSIRTP23-31 GAP lack information on related (instance/key) needed for correct DDS behavior DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-23 Editing issues DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-3 Clarify start of alignment for SerializedPayload DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-119 Make sure all references to the RTPS version are updated to 2.4 DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-40 Builtin Interparticipant Channel should have DataReader reliability kind BEST_EFFORTS DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-118 DomainId should propagated in the ParticipantBuiltinTopicData DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-42 Update section 10 (Data Encapsulation) DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-113 Describe how to create a WITH_KEY or NO_KEY RTPS Endpoint from DDS DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-115 Reference the PIDs that are reserved by the XTypes Spec in RTPS DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-96 Update UML figures in the specification DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-110 Data/Frag submessage flag for security DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-76 Unused ParameterIds in Table 9.12 DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-108 Update state machine to allow retrieving inline qos from a CacheChange DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-101 Typo in 8.4.13 DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-104 Figure 8.29 duplicates 8.28 DDSI-RTPS 2.2 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-103 Inconsistent definitions of ParticipantMessageData DDSI-RTPS 2.2 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-24 Key attributes and Regular attributes of a topic should be individually de-serializable DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Closed; No Change closed
DDSIRTP23-28 DDSI/RTPS Key MD5 Hash DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Closed; No Change closed
DDSIRTP23-20 Section 8.4.9.1.4: Best-Effort Stateful Writer GAP semantics DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-22 Section 8.4.7.3, Table 8.52: Describe ReaderLocator operations' semantics DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-25 Use the term "Encapsulation" consistently and precisely DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-27 Remove the concept of Topic Kinds (With Key vs. No Key) DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-32 Incorrect/misleading description of KeyHash computation DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-77 Table 9.13 "reserved for future use" rows DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-90 Reorganizing section 9.3.2 DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-37 Incorrect definition of SequenceNumberSet DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-36 Semantics of AckNack's Final Flag DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-39 RTPS Minor version should take into consideration DDS-Security DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-38 Reference reserved ParameterIDs for DDS-Security and dependencies DDSI-RTPS 2.2 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-97 Figure 8.1 has extra classes. Figures 8.2 and 8.5 are missing attributes DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-75 Remove/deprecate Property_t, EntityName_t, PID_PROPERTY_LIST DDSI-RTPS 2.2 DDSI-RTPS 2.3 Closed; No Change closed
DDSIRTP23-74 PIM-PSM inconsistent BuiltInEndpoints DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-73 resendDataPeriod in StatelessWriter DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-72 Deprecate PID_PARTICIPANT_BUILTIN_ENDPOINTS DDSI-RTPS 2.2 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-71 Include the padded bits into the Encapsulation options DDSI-RTPS 2.2 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-70 InfoTimestamp dates past 2038 DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-69 Normative references for IDL and CDR DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-100 BestEffort StatefulReader behavior does not handle GAP DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-19 Section 8.4.14.1.1, Bullet 3: Put precise bounds on the fragment size DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-21 Section 8.4.8.1.4: When does Best-Effort Stateless Writer send a GAP DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-5 Referencing current version of DDS spec (was: Clarification of link comment) DDSI-RTPS 2.1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-7 The Writer Liveliness Protocol should be removed DDSI-RTPS 2.1 DDSI-RTPS 2.3 Closed; No Change closed
DDSIRTP23-8 Section: 9.6.2.2.2, Table 9.13: Missing ParameterId mappings for RTPS fields DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-9 Section: 9.6.2.2.2, Table 9.13: Missing ParameterId mappings for DDS fields DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-10 Section: 9.6.2.2.2, Table 9.12: Duration_t not defined by PSM DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-11 Section 9.6.2.2.2, Table 9.12: Specify IPv4Address_t and Port_t DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-15 Section 9.6.2.2: What is the "key" parameter? DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-12 Section 9.6.2.2: Describe key-only encoding of built-in data types DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-14 Section 9.6.2.2: Duration_t used in IDL, not defined DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Duplicate or Merged closed
DDSIRTP23-16 Section 8.7.6: RTPS support for semantics not present in DDS DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-13 Section 8.5.3.2, Table 8.73: Make defaultUnicastLocatorList optional DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Closed; No Change closed
DDSIRTP23-17 Section: 8.5.3.2, Figure 8.27 and Table 8.73 DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Closed; Out Of Scope closed
DDSIRTP23-18 Section 8.4.15.7: Scope of the count fields of Heartbeat and AckNack/NackFrag DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-2 Locator_t kind needs a reserved range and a range for vendor extensions DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-4 Some constants specified in PSM table 9.4 conflict with the ones used in wireshark DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-66 Sending a HeartBeat message when there is no data is unspecified DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-41 Link to RTPS VendorId web page is broken DDSI-RTPS 2.2 DDSI-RTPS 2.3 Resolved closed
DDSIRTP23-1 Rename BuiltinEndpointKind and add description DDSI-RTPS 2.0b1 DDSI-RTPS 2.3 Closed; No Change closed
DDSIRTP23-136 Erratum DDSI-RTPS 2.2 open
DDSRPC11-3 Remove the 'default' case in Requst and Return union types DDS-RPC 1.0 open
DDSXML11-1 Fix a number of typos in specification document DDS-XML 1.0 open
DDSXML-2 Namespace are uncompliant with OMG Policy for XML Namespaces in OMG Specifications DDS-XML 1.0b1 DDS-XML 1.0 Resolved closed
DDSXML-1 Fix inconsistent rules for references between elements DDS-XML 1.0b1 DDS-XML 1.0 Resolved closed
DDSXML-9 Add OMG URL to schemaLocation attributes DDS-XML 1.0b1 DDS-XML 1.0 Resolved closed
DDSXML-7 DDS System Block Set lacks Schema File and Example DDS-XML 1.0b1 DDS-XML 1.0 Resolved closed
DDSXML-5 Minor typos, inconsistencies, and updates in specification document DDS-XML 1.0b1 DDS-XML 1.0 Resolved closed
DDS15-244 Communication Status changes for multiple events DDS 1.4 open
DDSPSMC11_-66 Make use of C++11 final/override/delete DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-68 Small correctes to the specification DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-67 Normative references not complete and out of date DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-64 Missing TBuiltinTopicTypes DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-63 Provide extension constructors for standard classes DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-65 EntityQos is overly general DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-62 Names of the generated headers DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-61 Default Constructors DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-53 API corrections required to src/hpp/dds/core/Exception.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-51 API corrections required to src/hpp/dds/core/TQosProvider.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-52 API corrections required to src/hpp/dds/core/TInstanceHandle.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-50 Documentation comments corrections required to src/hpp/dds/domain/discovery.hpp & find.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-60 API correction required to src/hpp/dds/dds.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-55 API correction required to src/hpp/dds/core/status/TStatus.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-59 API correction required to src/hpp/dds/core/status/State.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-57 API correction required to src/hpp/dds/core/policy/TCorePolicy.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-56 API correction required to src/hpp/dds/sub/AnyDataReaderListener.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-54 Missing file dds/pub/detail/find.hpp referenced in src/hpp/dds/pub/find.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-47 Documentation comments corrections to src/hpp/dds/pub/TPublisher.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-48 API correction required to src/hpp/dds/sub/LoanedSamples.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-58 DataReader.hpp, ContentFilteredTopic.hpp, Topic.hpp, TopicDescription.hpp o not compile with MS Visual Studio DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-49 API correction required to src/hpp/dds/core/cond/detail/GuardCondition.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-28 Inconsistent use of Type/type - fix compilation DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-31 API correction required to src/hpp/dds/core/Optional.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-43 Example vendor code is incorrect DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-29 API correction required to src/hpp/dds/core/cond/TWaitSet.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-45 API correction required to src/hpp/dds/core/cond/StatusCondition.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-33 Code in src/hpp/dds/core/array.hpp does not compile DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-41 API correction required to src/hpp/dds/pub/AnyDataWriter.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-34 API correction required to src/hpp/dds/domain/qos/detail/DomainParticipantQos.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-32 API correction required to src/hpp/dds/domain/TDomainParticipant.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-42 src/hpp/dds/domain/TDomainId.hpp should be removed from the API DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-40 API correction required to src/hpp/dds/core/types.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-30 API correction required to src/hpp/dds/core/ref_traits.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-39 API correction required to src/hpp/dds/core/detail/conformance.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-44 API correction required to src/hpp/dds/pub/qos/detail/DataWriterQos.hpp & PublisherQos.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-36 Documentation comments corrections to src/hpp/dds/pub/discovery.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-35 API correction required to src/hpp/dds/pub/TSuspendedPublication.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-46 API correction required to src/hpp/dds/sub/TDataReader.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-37 API correction required to src/hpp/dds/sub/SubscriberListener.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-38 API correction required to src/hpp/dds/sub/DataReaderListener.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-27 API correction required to src/hpp/dds/sub/SharedSamples.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-23 API needs a standardized way of downcasting API entities DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-26 Name clash between Topic discovery functions DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-24 dds::topic::TBuiltinTopicKey should be completely customizable. DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-19 dds/core/cond/TCondition.hpp should have virtual methods DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-22 Ownership label SHARED is already defined as a macro in some SUN compilers DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-21 Compilation error in dds/core/policy/PolicyKind.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-20 dds/core/array.hpp is licensed under LGPL DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-12 Reference should provide comparison operators DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-15 Missing constants/functions to obtain the built-in topic names DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-14 API corrections required to dds/core/Duration.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-17 API correction required to dds/core/Time.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-8 API corrections required to dds/sub/AnyDataReader.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-13 API does not provide functionality from the DomainParticipantFactory DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-9 Correction required to dds/sub/ddssub.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-11 API correction required to dds/topic/TBuiltinTopic.hpp DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-16 Selector missing next_instance() function DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-18 dds/pub/find.hpp is incomplete DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-10 Declaring Reference::operator new() private causes undesired side effects DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-5 Generic InstanceHandle constructor should be explicit DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-2 Method SampleInfo::valid() should be renamed SampleInfo::valid_data() DDS-PSM-Cxx 1.0b2 open
DDSPSMC11_-6 API corrections required to ManipulatorSelector and related functions DDS-PSM-Cxx 1.0b2 open
DDS15-243 Dispose for topics without key DDS 1.4 open
DDSIRTP23-135 Use of Stateful versus Stateless Endpoints DDSI-RTPS 2.2 open
DDSRPC11-2 Errors in non-normative IDL of section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types DDS-RPC 1.0 open
DDS15-242 set_expression_parameters on ContentFilteredTopic, MultiTopic DDS 1.4 open
DDS15-241 Clarify when a dispose or unregister may be omitted for a Reader DDS 1.4 open
DDS15-238 Add restrictions and guidelines that are required when writing GROUP coherent sets DDS 1.4 open
DDS15-239 Add resource limits related to coherent changes DDS 1.4 open
DDS15-237 How to handle some GROUP ordered Subcriber scenarios DDS 1.4 open
DDS15-236 Request/Offered behavior of DURABILITY Qos does not match use-cases DDS 1.4 open
DDS15-234 Incorporate common elements from DDS Security to the Builtin Topics DDS 1.4 open
DDSDLRL-2 DDS DLRL Issue: Clarify behavior of a Composition DDS 1.2 $issue.fixedSpecification.name Deferred closed
DDSDLRL-1 DDS DLRL Issue: Clarification on the use of a Set in a DLRL Query DDS 1.2 $issue.fixedSpecification.name Deferred closed
DDS15-208 Add DataTagQosPolicy DDS 1.4 open
DDS15-209 Define ranges of QosPolicyId_t DDS 1.4 open
DDS15-50 Add name attribute to Entity DDS 1.2 open
DDS4CCM11-15 Schema appears to be missing root element DDS4CCM 1.1 open
DDSSEC11-19 Invalid domain_id tag used in multiple sections of the spec DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-112 No mechanism to free ParticipantSecurityAttributes or EndpointSecurityAttributes DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-38 Clarify whether governance settings for a DataWriter and a DataReader must be consistent for a match to occur DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-14 Clarify conditions for calling the operations on AccessControlPlugin DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-118 begin_handshake_request in the IDL Not Consistent with the Main Document DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-115 Add the concept of "data origin authentication" and clarify what DDS-Security provides DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-111 Unclear Effectiveness of is_rtps_protected=true allow_unauthenticated_participants=true DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-52 Specify Authentication Challenge Length DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-58 Clarify the receiver-specific MACs described in the Table 57 decode operations DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-137 Missing Mechanism for Detecting Incompatibilities in ParticipantSecurityAttributes DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-39 Use of Non-Existing Submessage SecureSubMsg and Flag MultiSubmsg DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-23 FIPS-196 reference to wrong chapter DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-48 Wrong Facility Value for Logging Plugin DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-47 Need to specify format of SubjectName used for adjusted_participant_key DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-106 Should differences in EndpointSecurityAttributesMask prevent matching? DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-96 dds_security_plugins_spis.idl has inheritance commented out DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-49 Apply sha256 to derived shared secret DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-41 Correct Figure 9 to match description of the authentication protocol DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-40 Remove duplicate of RTPS message inside the security envelope DDS-SECURITY 1.0 DDS-SECURITY 1.1 Closed; No Change closed
DDSSEC11-25 VALIDATION_PENDING_CHALLENGE_MESSAGE DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-21 Normative IDL does not match the documentation for Auth::validate_remote_identity DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-22 Normative IDL does not match documentation for Authentication::validate_remote_identity DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-27 Inconsistent Behavior for Secure Volatile Endpoints DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-110 Handling expiration of Permissions or Certificates during operation DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-81 Non-Recoverable Communication After Authentication Session Terminated DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-85 Additional typos/inconsistencies DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-70 Unnecessary Additional Authenticated Data in common_mac DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-66 Handling large numbers of receiver-specific MACs DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-62 Inconsistent format for Starting and End Dates in Validity Section DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-53 Specify a transformation_kind for BuiltinParticipantVolatileMessageSecure Endpoints DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-60 Wrong description of max_blocks_per_session DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-34 check_local_*_match publisher/subscriber partition not present in IDL DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-16 AccessControl behavior does not show check_local_datawriter/reader_match operations DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-17 Need a way to determine the builtinTopic used for the DataWriter automatic liveliness DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-123 Inconsistent IDL encode_serialized_data and decode_serialized_data DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-122 Spec does not explain how t would use different keys for the encode_serialized_payload versus encode_serialized_submessage DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-88 BuiltinTopicKey_t Inconsistent with current DDS Spec DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-44 Denial of Service Attack to DDS Security Participants by Injecting Participant Discovery Unregister&Dispose DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-43 Non Recoverable Communication After Asymmetric Liveliness Loss DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-36 get_endpoint_sec_attributes inconsistently specified DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-33 AccessControl::check_create_topic( str_properties ) only present in IDL DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-12 GUIDs for new builtin Topics do not comply with DDS-RTPS specification DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-31 Wrong ValidationResult_t VALIDATION_OK_WITH_FINAL_MESSAGE Used In Multiple Places DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-29 Inconsistent Definition of BuiltinLoggingType DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-15 SecurityExceptionCode is undefined DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-108 Participant's is_access_protected Functionality Overlaps with allow_unauthenticated_participants DDS-SECURITY 1.0 DDS-SECURITY 1.1 Duplicate or Merged closed
DDSSEC11-72 EndpointSecurity's is_payload_protected is Insufficient DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-55 Confusing Sentence about Builtin Endpoints Payload Encryption DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-56 Permissions grant rule with no specified topic DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-46 Missing a Way to Pass Participant Data to begin_handshake_request and begin_handshake_reply DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-35 get_*_token should not return non-boolean values DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-24 Inconsisten ReturnCode NOT_ALLOWED_BY_SEC DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-18 Issue on DDS Security metamodel DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-6 Permissions XSD and XML files are inconsistent with normative machine readable file DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-94 Unify treatment of builtin endpoints with that of regular endpoints DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-54 Specify Endianness to be Used in Ciphertext DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-57 Evaluation of data_tags when checking Permissions is unclear DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-45 discovery_protection_kind is Underspecified DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-42 Table 51 CryptoToken should specify endianness of binary properties DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-7 Inconsistency in SubMessage and SubMessageElement naming throughout document DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-8 Crypto factory plugin implementation key generation DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-4 Name of builtin topic is DCPSParticipantMessage not ParticipantMessage DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-3 How does the built-in Cryptographic plugin know whether to just Sign or EncryptThenSign? DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-2 DomainGovernance -> domain_rule -> rtps_protection_kind description is unclear DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Closed; No Change closed
DDSSEC11-1 Complexity of Authentication Plugin Model DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Deferred closed
DDSSEC11-5 Miscellaneous typos/inconsistencies DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-113 Examples of Wildcard permissions DDS-SECURITY 1.0 DDS-SECURITY 1.1 Deferred closed
DDSSEC11-11 How is single-MAC versus MAC-per-reader configured? DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Resolved closed
DDSSEC11-10 Provide mechanisms to extend Governance and Permissions files without breaking interoperability DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Deferred closed
DDSSEC11-9 Built-in Authentication and Cryptography plugins tied together by SharedSecretHandle implementation DDS-SECURITY 1.0b1 DDS-SECURITY 1.1 Deferred closed
DDSSEC11-93 Determining the wire version of the DDS Security Protocol DDS-SECURITY 1.0 DDS-SECURITY 1.1 Resolved closed
DDS15-207 Durability section typos DDS 1.4 open
DDS15-206 BuiltinTopicKey_t should be completely customizable. DDS 1.4 open
DDS15-205 Specify behavior of filters and queries relative of lifecycle events DDS 1.4 open
DDS15-204 Add API for "directed writes" DDS 1.4 open
DDS15-203 Topic Names are Restricted to Characters, Digits, and Hyphens DDS 1.4 open
DDSSEC_-190 Multiple DataReaders per topic on secured Participant DDS-SECURITY 1.0 open
DDSXTY12-145 Users should have more control over when and how types match DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-147 Computing the TypeObject and TypeId for recursive types DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-149 UML Model is not consistent with document and missing types DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-148 Fix a Number of Issues in Final Document DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-142 XTypes impacts on IDL and language mappings; optional conformance DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-18 Improving Extensible Types DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-15 Type Consistency Enforcement Policy does not allow to properly control type projection/widening DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-143 Enumerations should be represented as a Byte if the bit bound is small enough DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-131 Add a @non-serialized annotation DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-100 TypeObject IDL and its propagation suffers from significant problems DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-127 Consider expanding TypeId 16 octets rather than 8 DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-119 The current assignability rules are complex and too restrictive DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-41 Reserved parameter IDs in 7.4.1.2.1 are wrong DDS-XTypes 1.0b2 DDS-XTypes 1.2 Resolved closed
DDSXTY12-45 Extended PID is not clear enough what the 2 value lengths mean DDS-XTypes 1.0b2 DDS-XTypes 1.2 Resolved closed
DDSXTY12-19 Proposed type-naming scheme is far from Robust DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-113 The encoding of strings and wide strings should be standardized DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-118 Misleading formulation DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-40 Section 7.4.1.2.2 "Member ID-to-Parameter ID Mapping" is underspecified DDS-XTypes 1.0b2 DDS-XTypes 1.2 Resolved closed
DDSXTY12-38 ths XSD has many errors DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-28 Mapping of Map type underspecified for C DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-27 C++ shared member representation breaks safety mechanisms of the struct containing it DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-9 Contradictions in the assignability for collection types DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-12 Mapping of optional arrays in C/C++ DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-112 Unify name used for Aggregate and Enumerated types DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-42 Built-in annotations should be in DDS namespace DDS-XTypes 1.0b2 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-44 Rendering of UML diagrams in each of the figures is of poor graphical quality DDS-XTypes 1.0b2 DDS-XTypes 1.2 Closed; No Change closed
DDSXTY12-43 All IDL should use local interfaces DDS-XTypes 1.0b2 DDS-XTypes 1.2 Closed; No Change closed
DDSXTY12-39 Extended parameters should be aligned the same as non-extended ones DDS-XTypes 1.0b2 DDS-XTypes 1.2 Resolved closed
DDSXTY12-36 IDL annotation syntax fails to specify scoping rules for annotation type names DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-10 Deserialization issues with Extensible types DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-5 Issues with UNIONS assignability rules DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-20 Applicable key types not clearly specified DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-29 DataRepresentationQosPolicy is making the application responsible for transport DDS-XTypes 1.1 DDS-XTypes 1.2 Closed; No Change closed
DDSXTY12-17 A @Version annotation shall be added DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-16 Key order should be defined using the @Key annotation DDS-XTypes 1.1 DDS-XTypes 1.2 Closed; No Change closed
DDSXTY12-14 Allow empty structures DDS-XTypes 1.1 DDS-XTypes 1.2 Closed; Out Of Scope closed
DDSXTY12-23 member ID algorithm flawed DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-35 IDL annotation syntax does specify how to use Any member type DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-34 Annotation member default declaration not compatible with Legacy IDL DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-33 Builtin topics not backward compatible DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-48 Expose assignability options for ignoring member names and sequence lengths DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-47 Keyhash computation not well-defined for mutable types DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-46 specify language-specific bindings may exist DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-37 One sentence split in two bullets DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-6 Spec should allow any value for the Optional flag in TypeObject union members DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-13 Optional flag in TypeObject union members DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-11 Optional flag in TypeObject union members DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-4 The description for union types are not complete DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-32 lookup_topicdescription semantics make it unusable DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-30 Multiplicity mismatch between TypeName and TypeObject DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-21 Shareable members underspecified DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-8 Circular dependencies across types should be allowed DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-7 TypeId calculation errors/corrections DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-26 XML type description not orthogonal and not consistent DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-25 Type system severely underspecified DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-24 TypeObject semantics underspecified and inconsistent DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-22 Definition of "strongly assignable" seems to be used inconsitently DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-3 TypeId union is missing NO_TYPE from the possible values of the discriminator DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-2 Send TypeId independently of the TypeObject DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-31 Topic incosisstency only considered for incompatible types, not for incompatible qos DDS-XTypes 1.1 DDS-XTypes 1.2 Closed; No Change closed
DDSXTY12-1 Specification document cleanup DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-158 Inconsistencies and missing items DDS-XTypes 1.1 DDS-XTypes 1.2 Deferred closed
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
DDSSEC_-134 Builtin Access Control - Inadequate Validity datatypes in permissions schema DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDS4CCM11-14 Remove key_fields DDS4CCM 1.1 open
DDS15-200 Syntax for Topic Names DDS 1.4 open
DDSSEC_-182 Clean-up encode_serialized_payload and decode_serialized_payload DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-166 Typos in DDS Security DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-165 Document security error conditions and log messages DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-172 Update Figures to match new submessages introduced in DDSSEC-14 DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-164 Use standard Key Derivation functions from the SharedSecret DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-178 Remove spurious references to PermissionCredential DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-176 Additional Enhancement to Mutual Authentication following ISO/IEC 9798-3 standard DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-146 Enhance security of the Authentication Handshake DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-14 More explicit Authentication and Permissions configuration DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-168 Use standard format for subject name in permissions and identity DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-169 Use standard format for subject name in permissions and identity DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-127 (meta)data_protection_kind takes incorrect values DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-130 The example governance does not validate with the governance XSD DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-133 Builtin Access Control - Use of 'TopicExpression' in Domain Governance DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-136 Builtin Access Control - Useless BooleanKind in Domain Governance Schema DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-144 Typo - KxKeyCookie/KxCookie and KxMacCookie/KxMacKeyCookie DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-143 adjusted_participant_key renamed to effective_participant_key without notice DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-142 Typo CryptoTranformIdentifier instead of CryptoTranSformIdentifier DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-76 Construction of HandshakeRequestMessage is unclear DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-75 In DomainGovernance, what is default behaviour if a domain+topic topic_rule is not found DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-78 Contents of KeyMaterial_AES_CTR_HMAC structure unclear DDS-Security 1.0b1 DDS-Security 1.0 Closed; No Change closed
DDSSEC_-139 In DomainParticipant permissions XSD: minOccurs of in DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-36 Parameters of get_endpoint_sec_attributes DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-34 Parameters of get_participant_sec_attributes DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-33 Builtin Authentication plugin: RSA or DSA ? DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-27 PermissionsCredential in validate_local_permissions DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-29 Plugins per-process or per-participant ? DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-122 Default permissions for partitions are too broad DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-135 Builtin Access Control - Useless BooleanKind in Domain Governance Schema DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-137 Builtin Access Control - Inadequate XML type for 'domainId' in schemas DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-107 Wrong reference to "create_local_datawriter_crypto_tokens" and "create_local_datareader_crypto_tokens" in §8.8.6.3 DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-106 Typos in DDS-Security Specification (2) DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-104 Inconsistent naming "SingleSubmsgFlag", "SingleSubmessageFlag" versus "MultiSubmsgFlag" DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-109 Wrong reference to check_create_datareader in §9.4.1.2.5.4 DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-108 Wrong reference to BuiltinParticipantMessageSecureWriter in §9.4.1.2.4.5 DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-114 Size of NONCE (Challenge_A/Challenge_B) in Authentication handshake messages undefined DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-73 How to determine if creating a DomainParticipant is allowed DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-72 Use of 'partition' in access control is unclear DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-74 Is there implicit handling for builtin secure endpoints in the access control plugin? DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-35 Builtin Access Control plugin doesn't set is_rtps_protected DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-32 Which encryption algorithm for the SharedSecret ? DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-7 In Table 18: check_remote_datawriter() should have a subscriber_partition parameter DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-5 Announcement of the new secure builtin endpoints DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-18 Handle types are shared by some plugins DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-1 In register_matched_remote_datareader() relay_out parameter should be IN DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-97 Errors in §8.8.6.4 DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-96 Errors in 8.8.5.2 step 6, step 7, and step 11 DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-95 Typos in DDS-Security Specification DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-103 Replace encode_serialized_data with encode_serialized_payload DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-98 §8.8.7.1, §8.8.7.2, §8.8.7.3: "received by the BuiltinParticipantVolatileMessageSecureWriter" should be "received by the BuiltinParticipantVolatileMessageSecureReader" DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-82 9.4.1.2.5 Governance Document description typo DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-81 Data type for CryptoTransformIdentifier.transformation_kind_id is unclear DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-80 Do the encode operations prefix the CDR data with a CDR encapsulation header? DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-79 Parameters to register_matched_remote_datareader() inconsistent between spec and IDL. DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-77 Description of HandshakeReplyMessage has an error DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-57 Section 8.3.2.9.1 (Authentication plugin interface) should not be under 8.3.2.9 (Unauthenticated DomainParticipant entities) DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-38 The padding used when encrypting the shared secret is not specified DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-11 Confusion between is_access_protected and allow_unauthenticated_participants DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-10 Matching of ParticipantStatelessMessage builtin endpoints DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-8 In Figure 12: preprocess_rtps_submessage() should be preprocess_secure_submsg() DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-3 Replace "BuiltinParticipantStatelessMessager" with "state-machine" DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-4 The adjusted_participant_key must be a valid Participant GUID DDS-Security 1.0b1 DDS-Security 1.0 Closed; No Change closed
DDSSEC_-6 In Table 1 and Table 2: the "name" attribute should be renamed as "key" DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-9 In Table 18: check_create_topic should not have a "property" parameter DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-19 register_matched_remote_datawriter: wrong parameter name DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-31 Content of initialization_vector and hmac_key_id DDS-Security 1.0b1 DDS-Security 1.0 Duplicate or Merged closed
DDSSEC_-30 New callback for authentication failures DDS-Security 1.0b1 DDS-Security 1.0 Closed; No Change closed
DDSSEC_-23 Benefit of session keys: wrong sentence DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-26 How to find the MasterSessionSalt to decrypt ? DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-25 Typo in KeyMaterial_AES_CTR_HMAC: initilization_vector DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-24 CipherKind and HashKind enums both use NONE DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-21 Meaning of MasterHMACSalt DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-20 Extra parameter to register_local_datawriter DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-13 validate_remote_permissions cannot return TRUE DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-12 Typo: is_discoverye_protected DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-17 Value of HandshakeRequestMessageToken 1st property DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-16 Inconsistency between "BuiltinParticipantStateless" and "InterParticipantStateless" DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-15 Wrong bits indexes in effective_participant_key DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-28 Complexity of Authentication Plugin Model DDS-Security 1.0b1 DDS-Security 1.0 Deferred closed
DDSSEC_-22 Meaning of SessionId DDS-Security 1.0b1 DDS-Security 1.0 Resolved closed
DDSSEC_-128 How does the built-in Cryptographic plugin know whether to just Sign or EncryptThenSign? DDS-Security 1.0b1 DDS-Security 1.0 Deferred closed
DDSSEC_-83 DomainGovernance -> domain_rule -> rtps_protection_kind description is unclear DDS-Security 1.0b1 DDS-Security 1.0 Deferred closed
DDSSEC_-140 Name of builtin topic is DCPSParticipantMessage not ParticipantMessage DDS-Security 1.0b1 DDS-Security 1.0 Deferred closed
DDSRPC_-9 Collisions in the implied IDL DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-15 missing attribute exception specification mapping DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-13 Potentially redundant UnknowEx DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-1 Clarifications and simple technical corrections DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-7 Editorial corrections in the spec document DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-11 modules in IDL DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-25 QoS library name with profile filename DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-23 return code mapping in IDL2C++11 DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-21 Why do we need @Choice DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-19 Annotation Scope DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-17 potential hash collisions DDS-RPC 1.0b1 DDS-RPC 1.0 Duplicate or Merged closed
DDSRPC_-5 Inconsistent ParameterIDs DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDSRPC_-3 Review comments Remedy IT on RPC4DDS DDS-RPC 1.0b1 DDS-RPC 1.0 Resolved closed
DDS15-198 Add a write_sequence() operation to DataWriter DDS 1.4 open
DDSJAVA11-17 Correct inconsistency on the URLs for the machine readable documents DDS-Java 1.0 open
DDS15-175 Clarify behavior of "take" operation DDS 1.2 open
DDS15-180 Behavior of multiple calls to create_topic -- Section: 2.1.2.3.2 DDS 1.2 open
DDS15-196 Clarify RxO behavior for DURABILITY Qos DDS 1.4 open
DDSSEC_-187 Permissions XSD in section 9.4.1.3 and example in 9.4.1.4 are inconsistent with normative machine readable file DDS-Security 1.0b1 DDS-Security 1.0 Deferred closed
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
DDSWEB-25 Enhancement to resolution of DDSWEB-3 / DDSWEB-20 DDS-WEB 1.0b1 DDS-WEB 1.0 Resolved closed
DDSWEB-9 Missing HTTP return code for DDS_ERROR DDS-WEB 1.0b1 DDS-WEB 1.0 Resolved closed
DDSWEB-14 Inconsistent and incomplete specification of resource representations DDS-WEB 1.0b1 DDS-WEB 1.0 Resolved closed
DDSWEB-33 Correct minor inconsistencies in naming DDS-WEB 1.0b1 DDS-WEB 1.0 Resolved closed
DDSWEB-30 Use of WebSockets is underspecified DDS-WEB 1.0b1 DDS-WEB 1.0 Resolved closed
DDSWEB-8 X-Types Dependency DDS-WEB 1.0b1 DDS-WEB 1.0 Closed; No Change closed
DDSWEB-7 Access Control Relationship with DDS Security DDS-WEB 1.0b1 DDS-WEB 1.0 Resolved closed
DDSWEB-2 The title of the submission is misleading DDS-WEB 1.0b1 DDS-WEB 1.0 Closed; No Change closed
DDSWEB-6 Namespace are non aligned with new PSMs DDS-WEB 1.0b1 DDS-WEB 1.0 Closed; No Change closed
DDSWEB-5 Wrong Acknoledgment DDS-WEB 1.0b1 DDS-WEB 1.0 Resolved closed
DDSWEB-4 Copyright Violation DDS-WEB 1.0b1 DDS-WEB 1.0 Resolved closed
DDSWEB-1 The URL prefix of the specification documents is not consistent with the XSD targetNamespace DDS-WEB 1.0b1 DDS-WEB 1.0 Resolved closed
DDSWEB-21 Qos Profiles and Types are underspecified and inconsistent with XSD DDS-WEB 1.0b1 DDS-WEB 1.0 Resolved closed
DDSWEB-19 Inconsistent and incomplete specification of resource representations DDS-WEB 1.0b1 DDS-WEB 1.0 Duplicate or Merged closed
DDSWEB-17 Missing HTTP return code for DDS_ERROR DDS-WEB 1.0b1 DDS-WEB 1.0 Duplicate or Merged closed
DDSWEB-29 Incomplete specification of the GET operation on the DataReader (Section 7.4.8.1) DDS-WEB 1.0b1 DDS-WEB 1.0 Resolved closed
DDSWEB-3 JSON Missing DDS-WEB 1.0b1 DDS-WEB 1.0 Deferred closed
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
DDS-178 ref-1003: Section 3.1.3.2 (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-176 ref-1001: section 3.1.1 (editorial DDS 1.0b1 DDS 1.0 Resolved closed
DDS-175 Missing operations to allow the navigation described in the PIM DDS 1.0b1 DDS 1.0 Resolved closed
DDS-177 ref-1002: section 3.1.2.1 (editorial DDS 1.0b1 DDS 1.0 Resolved closed
DDS-174 Bad references DDS 1.0b1 DDS 1.0 Resolved closed
DDS-173 DDS editorial issues DDS 1.0b1 DDS 1.0 Resolved closed
DDS4CCM_-105 section 8.3.1 Base Connectors DDS4CCM 1.0b2 DDS4CCM 1.0 Resolved closed
DDS4CCM_-104 Section 8.2.2.1.1: what about making is_lifecycle_checked a regular attribute, so not read only? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDSXTY11-12 Not every application limits itself to only 1 representation of a topic DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY11-11 Semantics of overriding an attribute not clearly specified DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY11-10 Typo DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY11-9 Typo in opening sentence of section: Missing noun and verb DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDS4CCM_-103 issue create/addressed? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-102 ConnectorStatusListener::on_unexpected_stat DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-101 InstanceHandleManager, local? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-100 Supporting Content Filtered Topics DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-99 getter text should be clearer about the behavior DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-98 Typo, 09-10-25, ExtendePortType DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-97 read_last DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-96 IDL3+ keyword question/issue DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-95 csl::on_inconsistent_topic DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-94 DDS_TopicBase::key_fields DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-93 mirrorport in CCMComponentPortKind DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-92 DDS4CCM module name DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-88 topic_name attribute DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-91 DDS port interfaces should be local DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-90 readonly attribute DDS::StringSeq key_fields;? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-89 on_subscription_matched missing DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-87 Updater and instance handle DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-86 (Multi)Updater method names? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-85 Extended ports DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-84 MultiListener DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-83 QoS profile attribute name? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-82 Do we need the Multi* interfaces/ports? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-81 Sequence typedef leads to multiple sequences DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-80 NonExisting::indexes with Reader/Getter/Writer DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-79 non-keyed datatypes DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-78 Reader port question DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-77 Dds4ccm and includes DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-76 Reader interface DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-75 Typo, betwen DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-74 Typo, erroneaous DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-71 QueryFilter DDS4CCM 1.0b1 DDS4CCM 1.0b2 Closed; No Change closed
DDS4CCM_-70 Reader::read_all_history DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-73 Return value of operations on MultiUpdater/MultiWriter/ DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-72 Typo, 8.3.1 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-69 Destination module for implied template interfaces DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-68 Return type of the MultiWriter/MultiUpdater? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-67 or MultiUpdater the return value of unsigned long doesn't make sense DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-66 MultiWriter DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-63 For timestamp, is this the DDS source_timestamp? If yes, rename the member to source_timestamp DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-62 line 17 and 21 the exception NonExistent: under which conditions has this exception to be thrown? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-65 Line 14, change inees to fields DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-64 For line 44 and 20 I would recommend to have update/create/delete as bold font DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-61 if no key is specified the an_instance is supposed to be empty? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-60 One line 24 the spec uses BadParameter, but it doesn't describe when this exception has to be thrown. DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-59 We propose to change the tags to and DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-58 Lines 32-36 imply that value declarations and type declarations may be parameterized DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-57 On line 24, the term '' should be '+'. DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-56 The non-terminal 'extended_port_decl' appears as both a component export and a connector export. DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-55 What are the semantics of the 'primitive' keyword? Letting it match any primitive type seems too vague DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-54 Section 8.2.2.1.3: ListenerControl attribute DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-53 ListenerControl DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-52 SampleInfo DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-51 propose to read the AMI chapter that was part of the alpha spec DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-46 DDS4LwCCM - template interface body DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-50 the spec should be more clear for which constructs the $ can be used DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-49 DDS4LwCCM - concatentation symbol usage DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-48 DDS4LwCCM - standalone template interfaces? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-47 DDS4LwCCM - forward declared template interface? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-43 table 2 on page 16 (adobe number) on line 1 should have the same fonts as table 1 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-42 keywords that can't be used in other IDL anymore DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-41 The spec uses $ as string replacement for IDL3+ DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-45 DDS4LwCCM - template interface IDL grammar DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-44 The spec doesn't say anything about forward declared IDL3+ interfaces DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-39 Annex D: Font of line 20 not ok DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-38 Shouldnh't InternalError use DDS::ReturnCode_t DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-37 Section 9.2.2: Line 16 doesn't read, line 33 should also be clear DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-40 Section: 8.2.2.1.4 and annex A missing parameter name DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-36 Section 9.2.2: Line 13 says DCPOS, shouldn't this be DCPS? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-35 Section 9.2.1.1: line 39 should be indented DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-34 Section 9: Line 4 should start with a capital DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-33 Section 8.2.2.2.5: On line 5 DURATION_INFINITE_NSEC should be used DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-32 Section 8.4.2: For Table 12, Boolean, font of BOOLEAN_TRUE is not ok DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-28 why not use an exception instead of a return value for the methods in Getter<>? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-31 Section 8.4.2: On line 1, the annex numbers are lacking DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-30 Section 8.3.1: On line 19, after DDS_Base it should be a { DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-29 Section: 8.2.2.1.2 font DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-27 Section 7.2.4.5: this seems to lack a figure, line 7 ends with "extrat below:" but nothing is below line 7 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-26 Section 7.2.4.4: Line 3-4 doesn't read DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-25 Section: 7.2.4.2.1 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-19 DDS_Listen is never defined in this spec DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-18 this struct uses a StringSeq but the namespace is lacking DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-23 Section 7.2.1.2: Line 16 ends with two semi colons instead of 1 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-22 Section 7.1.2: Layout of figure 2 and 3 can be improved DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-21 Section: 6.1.2: It should be ExtendedPort and MirrorPort, not InversePort DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-20 For 3, check UML CCM reference, it says 5formal, is that ok? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-17 The usage of ULongSeq should be CORBA::ULongSeq DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-16 Figure 1 should say IDL3+ instead of Extended IDL3 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-15 Line 15,19, use CORBA::ULongSeq instead of ULongSeq Line 23, use an enum for the error_code? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-14 line 4, replace the with The (T upper case) DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-13 Line 13/16/21/24, shouldn't the DDS_ be removed from the kind? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-12 line 8, shouldn't DDS_KEEP_ALL_HISTORY_QOS be replaces with KEEP_ALL_HISTORY_QOS DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-11 line 27, change attributre to attribute also change StringSeq to CORBA::StringSeq DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-10 line 52, change DDS_StateLsisten to DDS_StateListen DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-9 line 29, change On_data to on_data (lower case) DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-8 Change on line 5 StringSeq to CORBA::StringSeq DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-6 wouldn't it be more maintainable to add to lines 35-40 a typedef for the return value (and other interfaces)? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-5 Should be as below (lower case) 7.2.3.4.1 set_configuration_values DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-4 Shouldn't table 10 take parameterized connectors into account? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-3 push operation should be push_T$ DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-7 change nb to number in the comment on line 29/32/35 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-2 inout data parameters DDS4CCM 1.0b2 DDS4CCM 1.0 Resolved closed
DDS4CCM_-1 Type, DDS Listen instead of DDS_Listen DDS4CCM 1.0b2 DDS4CCM 1.0 Resolved closed
DDS4CCM11-13 DDS4CCM RTF - proposed simple spec extension for common DDS use case DDS4CCM 1.0 DDS4CCM 1.1 Resolved closed
DDSXTY11-8 Inconsistent extensibility kind for enumerations DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSPSMC-24 Inconsistencies related to use of const& DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSXTY_-26 DynamicData interface of the Language Binding section DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSIRTP21-12 The specification does not state how to generate unique GUIDs DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-9 Update protocol version to 2.1 DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-8 Change StatusInfo from SubmessageElement to Parameter DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-11 Computation of KeyHash is unspecified DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-10 Properly assign vendor IDs DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-6 Some submessage kinds are logically redundant and not extensible DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-7 Change KeyHash from SubmessageElement to Parameter DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-5 Clarify when a Payload is present in a submessage DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-4 Include key in serialized ParticipantMessageData DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-3 Add implementation note on not serializing redundant info in builtin topic DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP21-2 Clarify usage of KeyHash DDSI-RTPS 2.0 DDSI-RTPS 2.1 Resolved closed
DDSIRTP2-28 Add Parameter ID for Original Writer Info DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-27 Add Max Sample Size Serialized Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSXTY_-25 Inconsistent generated code for DynamicType::descriptor DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-24 Circular reference in definition of specialized Primitive Types DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-19 Introduce the notional value "null" that may be used in a content-filter expression DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-23 Invalid data types applied to AnnotationDescriptor::value, DynamicData::descriptor, DynamicData::value DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-22 Conflicting data types applied to several Attributes, Operations and Parameters in UML notation DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-21 Non-standard UML notation on figures DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-20 Truncation of text in Figure 3 DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-18 New DDS-XTypes issue: inability to consume data using new base class DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-17 Object assignability rules should be more resilient DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-16 Definition of “strongly assignable” is incomplete DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-12 Incorrect default extensibility kind value in XSD file DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-15 Incorrect union assignability rules DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-14 Inconsistent bit set/integer equivalency DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-13 Ambiguous description of serializing discovery types DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-9 Difficult to apply automation to statically defined types DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-8 Changing a DynamicType object is ambiguous DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-11 Optional, must_understand members of non-mutable aggregation types cannot be accurately represented in CDR DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-10 New QoS policies don’t indicate whether they can be changed DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-7 Typographical errors DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-6 Type signature fields in built-in topic data shouldn't use unbounded strings DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-5 No way to get or set length of collection-typed DynamicData objects DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-4 Annex D (“DDS Built-in Topic Data Types”) is out of sync with IDL file DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-3 C++ mapping MAP type needs member access semantics specification DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-2 Restrictions on MAP key element type not (clearly) documented/specified DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-1 Anonymous types should not be used in IDL examples and the TypeObject representation IDL DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDS-170 ref-1054: Bad which_added operations in IDL DDS 1.0b1 DDS 1.0 Resolved closed
DDS-172 Changing the IDL module DDS 1.0b1 DDS 1.0 Resolved closed
DDS-171 ref-1053 Missing is_composition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-169 Missing operations on DomainParticipantFactory and need for helper values DDS 1.0b1 DDS 1.0 Resolved closed
DDS-168 New definition for Selections DDS 1.0b1 DDS 1.0 Resolved closed
DDS-167 ref-171 Rename_Topic_USER_DATA_to_TOPIC_DATA DDS 1.0b1 DDS 1.0 Resolved closed
DDS-166 Ref-170 Missing_description_of_OWNERSHIP_STRENGH DDS 1.0b1 DDS 1.0 Resolved closed
DDSJAVA-32 A Status is not an Event. An Event is not a Status, it notifies a status change DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-31 DataReader API DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-34 Statuses API shoud be improved and made typesafe DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-33 Avoid unncessary side-effects on the DataWriter API DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-30 DomainEntity should be removed DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-35 API Should Avoid Side-Effects, e.g. Remove Bucket Accessors DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-36 The Sample class should provide a method to check wether the data is valid DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-37 Misnamed Listener Helper DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSPSMCF2-2 ReaderState: the class name does not reflect the intent of the class DDS-PSM-Cxx 1.0b2 DDS-PSM-Cxx 1.0 Resolved closed
DDSPSMCF2-1 The Status API, e.g. sample_rejected_status, deadline_missed_status, etc., are missing from the DataReader DDS-PSM-Cxx 1.0b2 DDS-PSM-Cxx 1.0 Resolved closed
DDSPSMCF2-3 Useless ReaderQuery on DataReader read/take DDS-PSM-Cxx 1.0b2 DDS-PSM-Cxx 1.0 Resolved closed
DDSPSMCF2-4 Assignment Rule for Container Types DDS-PSM-Cxx 1.0b2 DDS-PSM-Cxx 1.0 Resolved closed
DDSJAVA-28 Get rid of the EntityQos Class DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-27 QoS DSL Needed DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-23 RxO QoS Policies should be Comparable (idem for QoS) DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-22 Getting rid of the Bootstrap Object DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-26 Large Number of Spurious Import DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-25 Constant Values SHALL be defined by the standard DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-24 Qos Policies ID class vs. numeric ID DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-21 Superfluous "QoSPolicy" Suffix on Policy Types DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-29 Entity class allows for breaking invariants DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSPSMC-11 Exception safety guarantees for the DataReader API DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-10 Portable exception-safety guarantees for DDS C++ PSM DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-3 Union/array/bounded types lacking DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-2 factory methods on the "parents" (e.g. create_topic, create_data_writer, etc.) DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-5 Compilation errors on Visual Studio 2008/2010 DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-4 Dividing a scalar in Duration and Time classes DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-1 XML-Based QoS Policy Settings (DDS-PSM-Cxx/DDS-PSM-Java) DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-7 Fixing bugs and improving usability of the InstanceHandle class DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-9 Use traits for topic/datareader/datawriter DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-8 Inheritance via dominance warning on Visual Studio DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-6 Improving usability of Reference class DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-12 General Exception Safety Considerations DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSJAVA-20 Modifiable Types should be removed and replaced by values (e.g. immutable types). DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-19 QosPolicy.Id enumeration is redundant DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-15 Remove unnecessary DataWriter.write overloads DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-14 Improve polymorphic sample creation DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-6 Improve usability of “bucket” accessors DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-5 Missing -behavioural- descriptions of the interface DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-8 Entity.setListener is missing listener mask DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-7 Update specification to reflect DDS-XTypes FTF1 issue resolutions DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-12 DynamicDataFactory.createData missing a parameter DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-11 Too many read/take overloads DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-18 DataReader.createReadCondition() is useless DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-17 Parent accessors should be uniform across Entities and Conditions DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-10 Incorrect topic type specification in DomainParticipant.createMultiTopic DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-9 Unclear blocking behavior for WaitSet.waitForConditions overloads that don’t specify timeout DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-13 Logically ordered types should implement java.lang.Comparable DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-16 copyFromTopicQos signatures are not correct DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-1 XML-Based QoS Policy Settings (DDS-PSM-Cxx/DDS-PSM-Java) DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSPSMC-23 read/take consistency for loaned and non-loaned samples DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-20 The tdds namespace should be merged into the dds namespace DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-22 Getter/Setter for member arrays DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-21 Expected use of AnyDataReader::get and its implication on AnyDataReader's template constructor DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSJAVA-4 Data access from DataReader using java.util.List DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSJAVA-3 duplicate put definition resulting in a name clash DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSPSMC-14 Supporting automatic conversion from value types to delegate types DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-13 Improving usability of EntityQoS API DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSJAVA-2 formal description of how topic types are mapped to Java classes needed DDS-Java 1.0b1 DDS-Java 1.0b2 Resolved closed
DDSPSMC-17 RadarTrack uses anonymous types DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-16 Typos in Value.hpp, Exception.hpp DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-19 IDL mapping for non-trivial struct fields DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-18 optional support DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSPSMC-15 Make parameter passing same for native/type parameters DDS-PSM-Cxx 1.0b1 DDS-PSM-Cxx 1.0b2 Resolved closed
DDSJAVAF2-3 Implement Java5 Closeable interface DDS-Java 1.0b2 DDS-Java 1.0 Resolved closed
DDSJAVAF2-2 Obsolete EntityQos interface name DDS-Java 1.0b2 DDS-Java 1.0 Resolved closed
DDSJAVAF2-1 Class for Query Expression DDS-Java 1.0b2 DDS-Java 1.0 Resolved closed
DDSJAVAF2-6 Implement java.io.Closeable in Sample.Iterator DDS-Java 1.0b2 DDS-Java 1.0 Resolved closed
DDSJAVAF2-4 Update specification for final DDS-XTypes DDS-Java 1.0b2 DDS-Java 1.0 Resolved closed
DDSJAVAF2-7 Redundant "QosPolicy" suffix on Policy Types DDS-Java 1.0b2 DDS-Java 1.0 Resolved closed
DDSPSMCF2-5 Update specification for final DDS-XTypes DDS-PSM-Cxx 1.0b2 DDS-PSM-Cxx 1.0 Resolved closed
DDSJAVAF2-5 Improve compile-time type safety of EntityQos DDS-Java 1.0b2 DDS-Java 1.0 Resolved closed
DDSXTY-29 Different applications in the same domain may associate the same Topic with different types DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-28 DDS-XTypes @Key annotation Issue DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-8 Can’t initialize TypeId from TypeKind DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-9 Identifiers TypeId and Module collide with IDL keywords DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-23 Don’t require CORBA namespace for primitive types in Plain Language Binding DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-22 Allow more flexible type consistency enforcement DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-21 Typographical errors DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-20 Mutable structures with an empty intersection should not be considered assignable DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-19 XML representations should define namespaces DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-25 Provide minimal backwards-compatible conformance point DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-24 Provide formal grammar for new IDL Type Representation constructs DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-27 Improve support for shared data DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-26 Reduce size of DynamicData API DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-16 Incorrect FooDataWriter overloads for built-in types DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-15 Missing definitions of TypeSupport specializations for built-in types DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-18 Allow IDL compatibility pragma declarations to nest DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-17 Consolidate IDL built-in annotations in machine-readable file DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-14 Updated QoS definitions should be provided DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-13 Extensibility kinds of new QoS policies are not specified in a consistent way DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-11 Unclear member names when programming language doesn’t support typedef DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-10 Definition of built-in IDL annotation @Shared is missing DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-12 Definition of type “Parameters” inadvertently missing DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DD11-16 DD 1.0 defines DI, DC, DG as Models which is not in the CMOF subset for MOF 2.4.1 DD 1.0 DD 1.1 Resolved closed
DD11-15 Styling capabilities of Canvas ambiguous DD 1.0 DD 1.1 Resolved closed
DD11-14 MarkedElement should be abstract in provided CMOF files DD 1.0 DD 1.1 Resolved closed
DD11-13 Use MOF Primitive Types DD 1.0 DD 1.1 Resolved closed
DD11-12 DG library for BNF parsing DD 1.0 DD 1.1 Resolved closed
DD11-9 Z-order in DC -> DI and DG DD 1.0 DD 1.1 Resolved closed
DD11-8 DiagramElement ownership DD 1.0 DD 1.1 Resolved closed
DD11-5 DiagramElements cannot represent multiple model Elements DD 1.0b1 DD 1.1 Resolved closed
DD11-11 DG library for string bounding DD 1.0 DD 1.1 Resolved closed
DD11-10 Multiple modelElements per diagram element DD 1.0 DD 1.1 Resolved closed
DD11-7 Figure A.1 multiplicities DD 1.0 DD 1.1 Resolved closed
DD11-6 CMOF version DD 1.0 DD 1.1 Resolved closed
DD-1 Simplify DI metamodel DD 1.0b1 DD 1.0 Resolved closed
DD-6 Interchange extension DD 1.0b1 DD 1.0 Resolved closed
DD-5 Diagram::resolution default DD 1.0b1 DD 1.0 Resolved closed
DD-4 Bounds should be optional DD 1.0b1 DD 1.0 Resolved closed
DD-3 Waypoints should be optional DD 1.0b1 DD 1.0 Resolved closed
DD-2 The Diagram metaclass should be abstract DD 1.0b1 DD 1.0 Resolved closed
DD-11 Update Annex A DD 1.0b1 DD 1.0 Resolved closed
DD-10 Merge DI diagrams DD 1.0b1 DD 1.0 Resolved closed
DD-9 Cascade specification in DG isn't as specific as DI DD 1.0b1 DD 1.0 Resolved closed
DD-8 Rename DG::Canvas::style to packagedStyle DD 1.0b1 DD 1.0 Resolved closed
DD-7 DG::GraphicalElement::local/sharedStyle should have unbounded upper multiplicity DD 1.0b1 DD 1.0 Resolved closed
DD-15 Optional bounds DD 1.0b1 DD 1.0 Resolved closed
DD-14 Cascading called inheritance DD 1.0b1 DD 1.0 Resolved closed
DD-13 Owning styles DD 1.0b1 DD 1.0 Resolved closed
DD-12 MOF Compliance DD 1.0b1 DD 1.0 Resolved closed
DD-18 Spurious question marks DD 1.0b1 DD 1.0 Resolved closed
DD-17 Optional waypoints DD 1.0b1 DD 1.0 Resolved closed
DD-19 Visibility markers not needed DD 1.0b1 DD 1.0 Resolved closed
DD-21 Diagram description DD 1.0b1 DD 1.0 Resolved closed
DD-20 Collections => sets DD 1.0b1 DD 1.0 Resolved closed
DD-16 Annex B DD 1.0b1 DD 1.0 Resolved closed
DDS4CCM11-12 Move generic interaction support (GIS) to the CCM specification DDS4CCM 1.0 DDS4CCM 1.1 Resolved closed
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
DDSIRTP2-5 Clarify Writer liveliness mechanism DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-4 Change structure of (Nokey)DataFrag DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-7 Add SerializedDataFragment as Submessage Element DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-6 Version number should be 2.0 DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-3 Remove length field in encapsulation chapter DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-2 Provide default timing parameters DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-25 DDS DURABILITY Persistent QoS DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-24 ChangeKind Has DDS Relationship DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-23 Clarify GAP usage DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-26 TOPICNAME parameter appears in PSM but not in PIM DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-22 Elaborate on Necessity and Usage of In-line QoS DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-21 Clarify Data Encapsulation Schemes DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-12 Clarify implementing Count submessage element DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-11 Reclaiming finite resources from inactive readers DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-17 Supporting Inline QoS by Stateful Readers DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-16 Add Directed Write Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-9 Clarify interoperability requirement 8.4.2.3.3 DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-8 Clarify interoperability requirement 8.4.2.3.4 DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-15 Interpreting Liveliness Heartbeats DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-14 Clarify Writer Response to ACKNACK DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-20 Add Max Sample Size Serialized Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-19 Add Property List Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-10 Define default multicast Reader behavior DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-13 Reader-side Heartbeat response suppression DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-18 Add Entity Name Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDS11-123 R#182) Clarify mapping of PIM 'out' to PSM 'inout' DDS 1.0 DDS 1.1 Resolved closed
DDS11-122 (R#181) Clarify listener and mask behavior with respect to built-in entitie DDS 1.0 DDS 1.1 Resolved closed
DDS11-121 R#180) Clarify which entities appear as instances to built-in readers DDS 1.0 DDS 1.1 Resolved closed
DDS11-120 R#179) Built-in DataReaders should have TRANSIENT_LOCAL durability DDS 1.0 DDS 1.1 Resolved closed
DDS11-118 (R#150) Ambiguous description of create_topic behavior DDS 1.0 DDS 1.1 Resolved closed
DDS11-117 (R#144) Default value for DataWriter RELIABILITY QoS DDS 1.0 DDS 1.1 Resolved closed
DDS11-119 R#178) Unclear behavior of coherent changes when communication interrupted DDS 1.0 DDS 1.1 Resolved closed
DDS11-124 (T#6) Inconsistent name: StatusKindMask DDS 1.0 DDS 1.1 Resolved closed
DDS11-125 Page: 2-8 DDS 1.0 DDS 1.1 Resolved closed
DDS11-62 (R#124) Clarification on the behavior of dispose DDS 1.0 DDS 1.1 Resolved closed
DDS11-61 Need an extra return code: ILLEGAL_OPERATION DDS 1.0 DDS 1.1 Resolved closed
DDS11-58 (R#119) Need lookup_instance method on reader and writer DDS 1.0 DDS 1.1 Resolved closed
DDS11-57 TransportPriority QoS range does not specify high/low priority values DDS 1.0 DDS 1.1 Resolved closed
DDS11-60 (R#122) Missing QoS dependencies in table DDS 1.0 DDS 1.1 Resolved closed
DDS11-59 (R#120) Clarify use of DATAREADER_QOS_USE_TOPIC_QOS DDS 1.0 DDS 1.1 Resolved closed
DDS11-56 R#115) Destination order missing from PublicationBuiltinTopicData DDS 1.0 DDS 1.1 Resolved closed
DDS11-55 R#114) Operations should not return void DDS 1.0 DDS 1.1 Resolved closed
DDS11-64 (R#127) Improve PSM mapping of BuiltinTopicKey_t DDS 1.0 DDS 1.1 Resolved closed
DDS11-63 (R#125) Additional operations that can return RETCODE_TIMEOUT DDS 1.0 DDS 1.1 Resolved closed
DDS11-66 (R#130) Unspecified behavior of delete_datareader with outstanding loans DDS 1.0 DDS 1.1 Resolved closed
DDS11-65 Unspecified behavior of DataReader/DataWriter creation w/t mismatched Topic DDS 1.0 DDS 1.1 Resolved closed
DDS11-68 Incorrect reference to LIVELINESS_CHANGED in DataWriter::unregister DDS 1.0 DDS 1.1 Resolved closed
DDS11-67 (R#131) Clarify behavior of get_status_changes DDS 1.0 DDS 1.1 Resolved closed
DDS11-53 Incorrect field name for USER_DATA, TOPIC_DATA, and GROUP_DATA DDS 1.0 DDS 1.1 Resolved closed
DDS11-52 (R#109) Unused types in IDL DDS 1.0 DDS 1.1 Resolved closed
DDS11-54 R#112) Incorrect SampleRejectedStatusKind constants DDS 1.0 DDS 1.1 Resolved closed
DDS11-72 (R#142) OWNERSHIP QoS policy should concern DataWriter and DataReader DDS 1.0 DDS 1.1 Resolved closed
DDS11-71 (R#139) Rename *MatchStatus to *MatchedStatus DDS 1.0 DDS 1.1 Resolved closed
DDS11-70 (R#138) Add instance handle to LivelinessChangedStatus DDS 1.0 DDS 1.1 Resolved closed
DDS11-69 (R#135) Add fields to PublicationMatchStatus and SubscriptionMatchStatus DDS 1.0 DDS 1.1 Resolved closed
DDS11-73 (R#145,146) Inconsistent description of Topic module in PIM DDS 1.0 DDS 1.1 Resolved closed
DDS11-77 (R#154) Undefined behavior if resume_publications is never called DDS 1.0 DDS 1.1 Resolved closed
DDS11-76 (R#153) Ambiguous SampleRejectedStatus::last_reason field DDS 1.0 DDS 1.1 Resolved closed
DDS11-75 (R#152) Extraneous WaitSet::wakeup DDS 1.0 DDS 1.1 Resolved closed
DDS11-74 (R#147) Inconsistent error code list in description of TypeSupport::registe DDS 1.0 DDS 1.1 Resolved closed
DDS11-83 ReadOnly exception on clone operations DDS 1.0 DDS 1.1 Resolved closed
DDS11-82 Bad cardinality on figure 3-4 DDS 1.0 DDS 1.1 Resolved closed
DDS11-81 Naming inconsistencies (IDL PSM vs. PIM) for Cache operation DDS 1.0 DDS 1.1 Resolved closed
DDS11-80 Naming inconsistencies (IDL PSM vs. PIM) for ObjectHome operations DDS 1.0 DDS 1.1 Resolved closed
DDS11-78 DTD Error (mainTopic DDS 1.0 DDS 1.1 Resolved closed
DDS11-79 get_all-topic_names operation missing on figure 3-4 DDS 1.0 DDS 1.1 Resolved closed
DDS11-92 Inconsistent naming for status parameters in DataReader operations. DDS 1.0 DDS 1.1 Resolved closed
DDS11-91 Behavior of DataReaderListener::on_data_available DDS 1.0 DDS 1.1 Resolved closed
DDS11-97 (T#46) History when DataWriter is deleted DDS 1.0 DDS 1.1 Resolved closed
DDS11-96 (T#38) request-offered behavior for LATENCY_BUDGET DDS 1.0 DDS 1.1 Resolved closed
DDS11-90 Remove operations badly put on implied classes DDS 1.0 DDS 1.1 Resolved closed
DDS11-89 Attach_Listener and detach_listener operations on ObjectHome are untyped DDS 1.0 DDS 1.1 Resolved closed
DDS11-93 (T#23) Syntax of partition strings DDS 1.0 DDS 1.1 Resolved closed
DDS11-95 (T#37) Clarification on the value of LENGTH_UNLIMITED constant DDS 1.0 DDS 1.1 Resolved closed
DDS11-94 Clarification of order preservation on reliable data reception DDS 1.0 DDS 1.1 Resolved closed
DDS11-86 templateDef explanation contains some mistakes DDS 1.0 DDS 1.1 Resolved closed
DDS11-85 Typo CacheUsage instead of CacheAccess DDS 1.0 DDS 1.1 Resolved closed
DDS11-98 (T#47) Should a topic returned by lookup_topicdescription be deleted DDS 1.0 DDS 1.1 Resolved closed
DDS11-84 Wrong definition for FooListener DDS 1.0 DDS 1.1 Resolved closed
DDS11-88 Parameter wrongly named "object" in implied IDL DDS 1.0 DDS 1.1 Resolved closed
DDS11-87 DlrlOid instead of DLRLOid in implied IDL DDS 1.0 DDS 1.1 Resolved closed
DDS11-44 (T#52) Allow to explicitly refer to the default QoS DDS 1.0 DDS 1.1 Resolved closed
DDS11-43 (T#45) Clarification of syntax of char constants within query expressions DDS 1.0 DDS 1.1 Resolved closed
DDS11-46 (T#55) Modification to how enumeration values are indicated in expressions DDS 1.0 DDS 1.1 Resolved closed
DDS11-45 (T#54) Performance improvement to WaitSet DDS 1.0 DDS 1.1 Resolved closed
DDS11-48 (T#57) Enable status when creating DomainParticipant DDS 1.0 DDS 1.1 Resolved closed
DDS11-47 (T#56) Return values of Waitset::detach_condition DDS 1.0 DDS 1.1 Resolved closed
DDS11-42 Explicit mention of static DomainParticipantFactory::get_instance operation DDS 1.0 DDS 1.1 Resolved closed
DDS11-41 (T#42) Behavior when condition is attached to WaitSet multiple times DDS 1.0 DDS 1.1 Resolved closed
DDS11-51 (R#107) Missing Topic operations in IDL PSM DDS 1.0 DDS 1.1 Resolved closed
DDS11-50 (R#106b) Parameter passing convention of Subscriber::get_datareaders DDS 1.0 DDS 1.1 Resolved closed
DDS11-49 Add autopurge_disposed_samples_delay to READER_DATA_LIFECYCLE QoS DDS 1.0 DDS 1.1 Resolved closed
DDS11-40 (T#41) Default value for RELIABILITY max_blocking_time DDS 1.0 DDS 1.1 Resolved closed
DDS11-39 Missing description of DomainParticipant::get_domain_id DDS 1.0 DDS 1.1 Resolved closed
DDS11-37 Confusing description of behavior of Publisher::set_default_datawriter_qos DDS 1.0 DDS 1.1 Resolved closed
DDS11-38 (T#33) Clarification in use of set_listener operation DDS 1.0 DDS 1.1 Resolved closed
DDS11-114 Clarify meaning of LivelinessChangedStatus fields and LIVELINESS le DDS 1.0 DDS 1.1 Resolved closed
DDS11-113 (R#126) Correction to DataWriter blocking behavior DDS 1.0 DDS 1.1 Resolved closed
DDS11-112 (R#117) No way to access Participant and Topic built-in topic data DDS 1.0 DDS 1.1 Resolved closed
DDS11-111 (R#115b) Incorrect description of QoS for built-in readers DDS 1.0 DDS 1.1 Resolved closed
DDS11-106 (T#65) Missing get_current_time() function DDS 1.0 DDS 1.1 Resolved closed
DDS11-105 (T#62, R#141) Unspecified TOPIC semantics DDS 1.0 DDS 1.1 Resolved closed
DDS11-116 (R#136) Additional operations allowed on disabled entities DDS 1.0 DDS 1.1 Resolved closed
DDS11-115 (R#133) Clarify meaning of LivelinessLost and DeadlineMissed DDS 1.0 DDS 1.1 Resolved closed
DDS11-104 (T#61) Restrictive Handle definition DDS 1.0 DDS 1.1 Resolved closed
DDS11-103 (T#60) Asynchronous write DDS 1.0 DDS 1.1 Resolved closed
DDS11-108 (T#69) Notification of unsupported QoS policies DDS 1.0 DDS 1.1 Resolved closed
DDS11-107 Read or take next instance, and others with an illegal instance_handle DDS 1.0 DDS 1.1 Resolved closed
DDS11-100 (T#53) Cannot set listener mask when creating an entity DDS 1.0 DDS 1.1 Resolved closed
DDS11-99 (T#51) Identification of the writer of a sample DDS 1.0 DDS 1.1 Resolved closed
DDS11-110 (R#104) Inconsistent naming of QueryCondition::get_query_arguments DDS 1.0 DDS 1.1 Resolved closed
DDS11-109 O#7966) Confusing terminology: "plain data structures" DDS 1.0 DDS 1.1 Resolved closed
DDS11-102 (T#59) Deletion of disabled entities DDS 1.0 DDS 1.1 Resolved closed
DDS11-101 (T#53) Cannot set listener mask when creating an entity DDS 1.0 DDS 1.1 Resolved closed
DDS-146 Ref-112 Value_of_data_for_DISPOSED_state DDS 1.0b1 DDS 1.0 Resolved closed
DDS-145 Ref-85 Garbage_collection_of_disposed_instances DDS 1.0b1 DDS 1.0 Resolved closed
DDS-144 DDS ISSUE# 53] Refactor lifecycle state DDS 1.0b1 DDS 1.0 Resolved closed
DDS-143 DDS ISSUE# 52] Provide for zero copy access to data DDS 1.0b1 DDS 1.0 Resolved closed
DDS-149 Ref-231 Provide_a_way_to_limit_count_returned_samples DDS 1.0b1 DDS 1.0 Resolved closed
DDS-148 DDS ISSUE# 54] Refactor or extend API used to access samples DDS 1.0b1 DDS 1.0 Resolved closed
DDS-147 Ref-113 Meta_sample_accounting_towards_resource_limits DDS 1.0b1 DDS 1.0 Resolved closed
DDS-161 Mapping DCPS-DLRL DDS 1.0b1 DDS 1.0 Resolved closed
DDS-160 New definition for ObjectFilter DDS 1.0b1 DDS 1.0 Resolved closed
DDS-159 clean_modified (in ObjectRoot, Relations...) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-142 DDS ISSUE# 49] Behavior_of_register_type DDS 1.0b1 DDS 1.0 Resolved closed
DDS-141 Rename DataType interface to TypeSupport DDS 1.0b1 DDS 1.0 Resolved closed
DDS-140 DDS ISSUE# 46] Use of RETCODE_NOT_IMPLEMENTED DDS 1.0b1 DDS 1.0 Resolved closed
DDS-139 DDS ISSUE# 45] Is OMG IDL PSM more correct than CORBA PSM? DDS 1.0b1 DDS 1.0 Resolved closed
DDS-138 DDS ISSUE# 44] Errors in figures DDS 1.0b1 DDS 1.0 Resolved closed
DDS-137 Ref-139 Bad_reference_to filter_expression DDS 1.0b1 DDS 1.0 Resolved closed
DDS-151 DDS ISSUE# 56] Missing fields in builtin topics DDS 1.0b1 DDS 1.0 Resolved closed
DDS-150 DDS ISSUE# 55] Rename DataType interface to TypeSupport DDS 1.0b1 DDS 1.0 Resolved closed
DDS-155 ObjectHome index and name DDS 1.0b1 DDS 1.0 Resolved closed
DDS-154 ref-1032: User-provided oid DDS 1.0b1 DDS 1.0 Resolved closed
DDS-136 DDS ISSUE# 43] Bad references DDS 1.0b1 DDS 1.0 Resolved closed
DDS-135 DDS ISSUE# 42] Clarify how counts in the status accumulate DDS 1.0b1 DDS 1.0 Resolved closed
DDS-134 DDS ISSUE# 41] Inconsistent use of instance in datawriter api DDS 1.0b1 DDS 1.0 Resolved closed
DDS-158 Naming of the private members DDS 1.0b1 DDS 1.0 Resolved closed
DDS-157 New structure for DLRLOid DDS 1.0b1 DDS 1.0 Resolved closed
DDS-156 ObjectRoot::is_modified (clarification) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-153 DDS ISSUE# 57] Clarify creation of waitset and conditions DDS 1.0b1 DDS 1.0 Resolved closed
DDS-152 Ref-224 Built_in_topics_not_in_PSM DDS 1.0b1 DDS 1.0 Resolved closed
DDS11-23 Operation DataWriter::register DDS 1.0 DDS 1.1 Resolved closed
DDS11-22 Spelling inconsistencies between the PIM and IDL PSM DDS 1.0 DDS 1.1 Resolved closed
DDS11-24 (T#4) Typo in section 2.1.2.4.2.10 (write) and section 2.1.2.4.12 (dispose) DDS 1.0 DDS 1.1 Resolved closed
DDS11-34 (T#29) Missing operations to Topic class DDS 1.0 DDS 1.1 Resolved closed
DDS11-33 (T#28) Typographical and grammatical errors DDS 1.0 DDS 1.1 Resolved closed
DDS11-31 Missing operations on DomainParticipantFactory DDS 1.0 DDS 1.1 Resolved closed
DDS11-30 Spell fully the names for the DataReader operations DDS 1.0 DDS 1.1 Resolved closed
DDS11-26 Default value for READER_DATA_LIFECYCLE DDS 1.0 DDS 1.1 Resolved closed
DDS11-25 Typo in section 2.1.2.5.2.5 DDS 1.0 DDS 1.1 Resolved closed
DDS11-28 No mention of DESTINATION_ORDER on DataWriterQos DDS 1.0 DDS 1.1 Resolved closed
DDS11-27 Incorrect reference to USER_DATA on TopicQos DDS 1.0 DDS 1.1 Resolved closed
DDS11-35 Formal parameter name change in operations of ContentFilteredTopic DDS 1.0 DDS 1.1 Resolved closed
DDS11-29 Formal parameter name improvement in IDL DDS 1.0 DDS 1.1 Resolved closed
DDS11-32 T#18,24,) Missing operations and attributes DDS 1.0 DDS 1.1 Resolved closed
DDS-163 Several instead one listener DDS 1.0b1 DDS 1.0 Resolved closed
DDS-162 clone + deref DDS 1.0b1 DDS 1.0 Resolved closed
DDS-165 New definition for ObjectListener DDS 1.0b1 DDS 1.0 Resolved closed
DDS-164 delete clone DDS 1.0b1 DDS 1.0 Resolved closed
DDS-67 Ref-37 Entity_ specialization_set_get_listener_in_idl DDS 1.0b1 DDS 1.0 Resolved closed
DDS-66 Ref-34 Incorrect_guard_condition_enabled_statuses DDS 1.0b1 DDS 1.0 Resolved closed
DDS-70 Ref-48 FooDataWriter_unregister_instance DDS 1.0b1 DDS 1.0 Resolved closed
DDS-69 Ref-46 ContentFilteredTopic_related_topic DDS 1.0b1 DDS 1.0 Resolved closed
DDS-65 Ref-28 IDL_entity_get_statuscondition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-68 Ref-42 DomainParticipantListener_on_requested DDS 1.0b1 DDS 1.0 Resolved closed
DDS11-21 Typographical and grammatical errors DDS 1.0 DDS 1.1 Resolved closed
DDS11-20 DDS 04-04-12 para. 2.1.1.1 Format and conventions DDS 1.0 DDS 1.1 Resolved closed
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
DDS11-16 no specific mention of interoperability in DDS 04-04-12 standard proposal DDS 1.0 DDS 1.1 Resolved closed
DDS11-17 DDS: DCPS generated interface FooTypeSupport DDS 1.0 DDS 1.1 Resolved closed
DDS11-19 2.1.3.20 WRITER_DATA_LIFECYCLE, itemized list, first bullet DDS 1.0 DDS 1.1 Resolved closed
DDS11-18 DDS: DCPS - define the term "plain data structures" DDS 1.0 DDS 1.1 Resolved closed
DDS-131 DDS ISSUE# 38] Allow application to install a clock DDS 1.0b1 DDS 1.0 Resolved closed
DDS-130 DDS ISSUE# 37] SAMPLE_LOST_STATUS on DataReader DDS 1.0b1 DDS 1.0 Resolved closed
DDS-121 Ref-106 Desc_of_Inconsistent_topic_status::total_count_change DDS 1.0b1 DDS 1.0 Resolved closed
DDS-120 Ref-156 Clarify_TIME_BASED_FILTER DDS 1.0b1 DDS 1.0 Resolved closed
DDS-119 Ref-104 Coupling_bwn_TIME_BASED_FILTER_and_RELIABILITY DDS 1.0b1 DDS 1.0 Resolved closed
DDS-116 DDS ISSUE# 36] QoS clarifications DDS 1.0b1 DDS 1.0 Resolved closed
DDS-115 Inconsistency on what operations may return NOT_ENABLED DDS 1.0b1 DDS 1.0 Resolved closed
DDS-114 DDS ISSUE# 34] Initial data when DataWriter appears DDS 1.0b1 DDS 1.0 Resolved closed
DDS-133 DDS ISSUE# 40] Expression syntax is missing enumeration DDS 1.0b1 DDS 1.0 Resolved closed
DDS-132 DDS ISSUE# 39] Combine module names DDS 1.0b1 DDS 1.0 Resolved closed
DDS-129 Ref-162 Separate_transient_into_two_kinds DDS 1.0b1 DDS 1.0 Resolved closed
DDS-128 Ref-142 Confusing_description_of_manual_by_participant DDS 1.0b1 DDS 1.0 Resolved closed
DDS-123 Ref-109 Destination_order_should_be_request_offered DDS 1.0b1 DDS 1.0 Resolved closed
DDS-122 Ref-108 Ownership_interaction_with_deadline DDS 1.0b1 DDS 1.0 Resolved closed
DDS-125 Ref-144 Wrong_description_of_compatible_DURABILITY DDS 1.0b1 DDS 1.0 Resolved closed
DDS-124 Ref-111 Default_values_for_qos DDS 1.0b1 DDS 1.0 Resolved closed
DDS-118 Ref-212 Qos_Coupling_TimeBasedFilter_deadline DDS 1.0b1 DDS 1.0 Resolved closed
DDS-117 Ref-210 Clarification_of_responsibility_of_RxO_qos DDS 1.0b1 DDS 1.0 Resolved closed
DDS-127 Ref-144 User_data_on_topic DDS 1.0b1 DDS 1.0 Resolved closed
DDS-126 Ref-165 Make_USER_DATA_changeable DDS 1.0b1 DDS 1.0 Resolved closed
DDS11-36 (T#30) Ambiguous description of TOPIC_DATA DDS 1.0 DDS 1.1 Resolved closed
DDS-92 Ref-118 Introduce_TIME_INVALID_constant DDS 1.0b1 DDS 1.0 Resolved closed
DDS-91 DDS ISSUE# 14] Helper addition to the IDL DDS 1.0b1 DDS 1.0 Resolved closed
DDS-90 Ref-31 Reason_and_use_of_enabled DDS 1.0b1 DDS 1.0 Resolved closed
DDS-89 Reason and use of enable DDS 1.0b1 DDS 1.0 Resolved closed
DDS-86 Duplicate use of domainId DDS 1.0b1 DDS 1.0 Resolved closed
DDS-85 Ref-02 Data_Available_status_transition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-88 Ref-40 Name_and_return_type_of_lookup_topic DDS 1.0b1 DDS 1.0 Resolved closed
DDS-87 Use of Topic versus TopicDescription DDS 1.0b1 DDS 1.0 Resolved closed
DDS-80 Ref-126 Inconsistent_parameter_order_to_get_datareaders DDS 1.0b1 DDS 1.0 Resolved closed
DDS-79 Ref-205 On_requested_deadline_missed_paramtype DDS 1.0b1 DDS 1.0 Resolved closed
DDS-78 Ref-88 Inconsistent_naming_PIM_IDL_instance_samples DDS 1.0b1 DDS 1.0 Resolved closed
DDS-77 Ref-79 Missing_StatusKind_liveliness_idl_constants DDS 1.0b1 DDS 1.0 Resolved closed
DDS-76 Ref-70 Missing_deadline_statuskind_from_pim DDS 1.0b1 DDS 1.0 Resolved closed
DDS-75 Ref-59 FooDataReader_read_take_parameter_order DDS 1.0b1 DDS 1.0 Resolved closed
DDS-84 Clarification of listener invocation and waitset signaling DDS 1.0b1 DDS 1.0 Resolved closed
DDS-83 Ref-229 IDL_rename_publisher_laxity_w_latency_budget DDS 1.0b1 DDS 1.0 Resolved closed
DDS-74 Ref-58 DataReader_read_take_w_condition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-73 Ref-56 Subscriber_notify_datareaders_parameters DDS 1.0b1 DDS 1.0 Resolved closed
DDS-82 Ref-63 QoS_USER_DATA_on_Publisher_and_Subscriber DDS 1.0b1 DDS 1.0 Resolved closed
DDS-81 Ref-135 Missing_accessor_for_SampleRejectedStatus DDS 1.0b1 DDS 1.0 Resolved closed
DDS-72 Ref-57 FooDataReader_get_key DDS 1.0b1 DDS 1.0 Resolved closed
DDS-71 Ref-49 DataWriter_get_key DDS 1.0b1 DDS 1.0 Resolved closed
DDS-94 DDS ISSUE# 15] Semantics of register and unregister instance DDS 1.0b1 DDS 1.0 Resolved closed
DDS-93 Ref-102 Addition_of time_related_constants DDS 1.0b1 DDS 1.0 Resolved closed
DDS-111 DDS ISSUE# 31] Topic QoS refactor DDS 1.0b1 DDS 1.0 Resolved closed
DDS-110 DDS ISSUE# 30] Setting of default qos on factories DDS 1.0b1 DDS 1.0 Resolved closed
DDS-109 DDS ISSUE# 29] Disposing a multi-topic DDS 1.0b1 DDS 1.0 Resolved closed
DDS-113 DDS ISSUE# 33] Initialization of resources needed DDS 1.0b1 DDS 1.0 Resolved closed
DDS-112 DDS ISSUE# 32] Create dependencies on type DDS 1.0b1 DDS 1.0 Resolved closed
DDS-99 DDS ISSUE# 20] Narrow the applicability of assert liveliness DDS 1.0b1 DDS 1.0 Resolved closed
DDS-98 DDS ISSUE# 19] Initial value of entity status changes DDS 1.0b1 DDS 1.0 Resolved closed
DDS-97 Behavior on creation failure DDS 1.0b1 DDS 1.0 Resolved closed
DDS-105 DDS ISSUE# 25] Addition of read and take to ReadCondition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-104 DDS ISSUE# 24] Clarification of status flag DDS 1.0b1 DDS 1.0 Resolved closed
DDS-96 DDS ISSUE# 17] Clarify consequence of changing partitions DDS 1.0b1 DDS 1.0 Resolved closed
DDS-95 DDS ISSUE# 16] Clarification of expression syntax DDS 1.0b1 DDS 1.0 Resolved closed
DDS-101 Ref-134 Additional_w_timestamp_operations DDS 1.0b1 DDS 1.0 Resolved closed
DDS-100 DDS ISSUE# 21] Helper operations DDS 1.0b1 DDS 1.0 Resolved closed
DDS-108 [DDS ISSUE# 28] Desirability to define "information model" in a file DDS 1.0b1 DDS 1.0 Resolved closed
DDS-107 DDS ISSUE# 27] Additional situations resulting in inconsistent QoS DDS 1.0b1 DDS 1.0 Resolved closed
DDS-106 DDS ISSUE# 26] Definition of DCPSKey DDS 1.0b1 DDS 1.0 Resolved closed
DDS-103 ISSUE# 23] Make Listener inheritance explicit in figures 2-9 and 2-10 DDS 1.0b1 DDS 1.0 Resolved closed
DDS-102 DDS ISSUE# 22] Details in the code generation DDS 1.0b1 DDS 1.0 Resolved closed
DDSIRTP22-24 Section: 10.1.1.2, 10.1.1.3 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDS14-189 The DDS specification should be separated into two documents DDS 1.2 DDS 1.4 Resolved closed
DDS14-188 Order of parameters incorrect in PSM DDS 1.1 DDS 1.4 Resolved closed
DDS14-187 DDS 04-04-12 Appendix B, C DDS 1.0 DDS 1.4 Closed; No Change closed
DDS12-72 String sequence should be a parameter and not return value DDS 1.1 DDS 1.2 Resolved closed
DDS12-5 Improper prototype for get_XXX_status() DDS 1.1 DDS 1.2 Resolved closed
DDS12-4 Mention of get_instance() operation on DomainParticipantFactory beingstatic DDS 1.1 DDS 1.2 Resolved closed
DDS12-3 String sequence should be a parameter and not return value DDS 1.1 DDS 1.2 Resolved closed
DDS12-2 Inconsistent prototype for Publisher's get_default_datawriter_qos() method DDS 1.1 DDS 1.2 Resolved closed
DDS12-1 Inconsistencies between PIM and PSM in the prototype of get_qos() methods DDS 1.1 DDS 1.2 Resolved closed
DDS12-70 read/take_next_instance() DDS 1.1 DDS 1.2 Resolved closed
DDS12-69 Clarify notification of ownership change DDS 1.1 DDS 1.2 Resolved closed
DDS12-59 Unlimited setting for Resource limits not clearly explained DDS 1.1 DDS 1.2 Resolved closed
DDS12-58 Small naming inconsistentcies between PIM and PSM DDS 1.1 DDS 1.2 Resolved closed
DDS12-68 Extended visibility of instance state changes DDS 1.1 DDS 1.2 Resolved closed
DDS12-67 Typo in section 2.1.2.5.1 DDS 1.1 DDS 1.2 Resolved closed
DDS12-71 instance resource can be reclaimed in READER_DATA_LIFECYCLE QoS section DDS 1.1 DDS 1.2 Resolved closed
DDS12-62 Incorrect description of enable precondition DDS 1.1 DDS 1.2 Resolved closed
DDS12-61 Resetting of the statusflag during a listener callback DDS 1.1 DDS 1.2 Resolved closed
DDS12-64 Clarify the meaning of locally DDS 1.1 DDS 1.2 Resolved closed
DDS12-63 invalid reference to delete_datareader DDS 1.1 DDS 1.2 Resolved closed
DDS12-57 PIM and PSM contradicting wrt "get_sample_lost_status" operation DDS 1.1 DDS 1.2 Resolved closed
DDS12-56 PIM description of "get_domain_id" method is missing DDS 1.1 DDS 1.2 Resolved closed
DDS12-66 Illegal return value register_instance DDS 1.1 DDS 1.2 Resolved closed
DDS12-65 Missing autopurge_disposed_sample_delay DDS 1.1 DDS 1.2 Resolved closed
DDS12-60 Inconsistent PIM/PSM for RETCODE_ILLEGAL_OPERATION DDS 1.1 DDS 1.2 Resolved closed
DDS12-21 Naming consistencies in match statuses DDS 1.1 DDS 1.2 Resolved closed
DDS12-20 Description of set_default_XXX_qos() DDS 1.1 DDS 1.2 Resolved closed
DDS12-19 Should write() block when out of instance resources? DDS 1.1 DDS 1.2 Resolved closed
DDS12-18 Clarify ownership with same-strength writers DDS 1.1 DDS 1.2 Resolved closed
DDS12-12 Naming of filter_parameters concerning ContentFilteredTopic DDS 1.1 DDS 1.2 Resolved closed
DDS12-11 Typos in built-in topic table DDS 1.1 DDS 1.2 Resolved closed
DDS12-10 Clarify PARTITION QoS and its default value DDS 1.1 DDS 1.2 Resolved closed
DDS12-9 Blocking of write() call DDS 1.1 DDS 1.2 Resolved closed
DDS12-17 Typos in PIM sections DDS 1.1 DDS 1.2 Resolved closed
DDS12-16 Typos in QoS sections DDS 1.1 DDS 1.2 Resolved closed
DDS12-8 Consistency between RESOURCE_LIMITS QoS policies DDS 1.1 DDS 1.2 Resolved closed
DDS12-15 Incorrect mention of INCONSISTENT_POLICY status DDS 1.1 DDS 1.2 Resolved closed
DDS12-14 Compatible versus consistency when talking about QosPolicy DDS 1.1 DDS 1.2 Resolved closed
DDS12-7 OWNERSHIP_STRENGTH QoS is not a QoS on built-in Subscriber of DataReaders DDS 1.1 DDS 1.2 Resolved closed
DDS12-6 Inconsistent naming in SampleRejectedStatusKind DDS 1.1 DDS 1.2 Resolved closed
DDS12-13 Incorect prototype for FooDataWriter method register_instance_w_timestamp() DDS 1.1 DDS 1.2 Resolved closed
DDS-56 Ref-87 Clarify_Topic_deletion_as_local_concept DDS 1.0b1 DDS 1.0 Resolved closed
DDS-55 Ref-20 Semantics_of_factory_delete_methods DDS 1.0b1 DDS 1.0 Resolved closed
DDS-54 Delete dependencies and semantics DDS 1.0b1 DDS 1.0 Resolved closed
DDS-58 Ref-22 Automatic_deletion_of_contained_entities DDS 1.0b1 DDS 1.0 Resolved closed
DDS-57 Ref-151 No_locally_duplicate_topics DDS 1.0b1 DDS 1.0 Resolved closed
DDS-60 Single waitset attached to condition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-59 Ref-15 Behavior_on_deletion_from_wrong_factory DDS 1.0b1 DDS 1.0 Resolved closed
DDS-62 Ref-36 Entity_specialization_set_get_qos DDS 1.0b1 DDS 1.0 Resolved closed
DDS-61 Entity specialization of set/get qos/listener DDS 1.0b1 DDS 1.0 Resolved closed
DDS-64 Ref-39 Entity_specialization_set_get_qos DDS 1.0b1 DDS 1.0 Resolved closed
DDS-63 Inconsistencies between PIM and PSM/IDL DDS 1.0b1 DDS 1.0 Resolved closed
DDS-30 Attributes_on_a_topic_description DDS 1.0b1 DDS 1.0 Resolved closed
DDS-29 Additional_communication_paradigms DDS 1.0b1 DDS 1.0 Closed; No Change closed
DDS-28 ref-1019: Name of the ObjectRoot::clone method (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-27 ref-1018: Name of the methods for ObjectListener (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-26 ref-1017: Section 3.1.4.4.2 topic (editorial DDS 1.0b1 DDS 1.0 Resolved closed
DDS-25 ref-1016: Page 3-65 t2 (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-24 ref-1015: Page 3-62 manual edition (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-19 ref-1010: Section 3.2.3.3 XML Model Tags of the example DDS 1.0b1 DDS 1.0 Resolved closed
DDS-18 ref-1009: Section 3.2.3.2 IDL Model description of the example DDS 1.0b1 DDS 1.0 Resolved closed
DDS-21 ref-1012: Section 3.2.3.3 Simplified XML of the example) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-20 ref-1011: Section 3.2.3.3 Introduction to figure 3.9 (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-13 ref-1004: Section 3.1.3.3 Metamodel (clarification) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-15 ref-1006: Page 3.11 (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-14 ref-1005: figure 3.2 (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-17 ref-1008: Bad annex reference (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-16 ref-1007: Section 3.1.6.3.4 CacheListener (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-23 ref-1014: Page 3-10, figure 3-2 min_topic (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-22 ref-1013: Section 3.1.6.3.9 Table for ObjectQuery (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS12-35 Cache and CacheAccess should have a common parent DDS 1.1 DDS 1.2 Resolved closed
DDS12-34 Simplify Relation Management DDS 1.1 DDS 1.2 Resolved closed
DDS12-39 Object State Transitions of Figure 3-5 and 3-6 should be corrected DDS 1.1 DDS 1.2 Resolved closed
DDS12-38 Introduce the concept of cloning contracts consistently in specification DDS 1.1 DDS 1.2 Resolved closed
DDS12-37 ObjectExtent and ObjectModifier can be removed DDS 1.1 DDS 1.2 Resolved closed
DDS12-36 Object notification in manual update mode required DDS 1.1 DDS 1.2 Resolved closed
DDS12-26 Operation dispose_w_timestamp() should be callable on unregistered instance DDS 1.1 DDS 1.2 Resolved closed
DDS12-25 Clarify valid handle when calling write() DDS 1.1 DDS 1.2 Resolved closed
DDS12-33 Corrections to Figure 2-19 DDS 1.1 DDS 1.2 Resolved closed
DDS12-32 Non intuitive constant names DDS 1.1 DDS 1.2 Resolved closed
DDS12-31 Example in 2.1.4.4.2 not quite correct DDS 1.1 DDS 1.2 Resolved closed
DDS12-28 Typo in copy_from_topic_qos DDS 1.1 DDS 1.2 Resolved closed
DDS12-27 Behavior of dispose with regards to DURABILITY QoS DDS 1.1 DDS 1.2 Resolved closed
DDS12-22 delete_contained_entities() on the Subscriber DDS 1.1 DDS 1.2 Resolved closed
DDS12-24 Need INVALID_QOS_POLICY_ID DDS 1.1 DDS 1.2 Resolved closed
DDS12-23 Return of get_matched_XXX_data() DDS 1.1 DDS 1.2 Resolved closed
DDS12-30 Operation wait() on a WaitSet should return TIMEOUT DDS 1.1 DDS 1.2 Resolved closed
DDS12-29 Typo in get_discovered_participant_data DDS 1.1 DDS 1.2 Resolved closed
DDS-42 CacheAccess operations (documentation) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-41 Depth of cloning (addition) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-40 Names of the ObjectRoot attributes DDS 1.0b1 DDS 1.0 Resolved closed
DDS-53 Ref-62 Return_type_of_set_query_operations DDS 1.0b1 DDS 1.0 Resolved closed
DDS-52 Naming_of_attribute_getter_operations DDS 1.0b1 DDS 1.0 Resolved closed
DDS-51 Potential problems in PSM mappings DDS 1.0b1 DDS 1.0 Resolved closed
DDS-36 Additional_qos_LIFESPAN Issue DDS 1.0b1 DDS 1.0 Resolved closed
DDS-35 Additional_qos_DATA_PRIORITY Issue DDS 1.0b1 DDS 1.0 Resolved closed
DDS-34 Navigation_of_connectivity_information Issue DDS 1.0b1 DDS 1.0 Resolved closed
DDS-33 Writer_notification_of_delivery_failure Issue DDS 1.0b1 DDS 1.0 Resolved closed
DDS-32 Transactional_reliability Issue DDS 1.0b1 DDS 1.0 Resolved closed
DDS-31 Extension_to_the_partition_qos DDS 1.0b1 DDS 1.0 Resolved closed
DDS-48 Operations on collections of objects (addition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-47 ObjectHome::get_all_topic_names (addition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-39 : Attributes and operations directly set on valuetypes DDS 1.0b1 DDS 1.0 Resolved closed
DDS-38 CacheFactory::find_cache (addition DDS 1.0b1 DDS 1.0 Resolved closed
DDS-37 Make_USER_DATA_an_array_and_mutable Issue DDS 1.0b1 DDS 1.0 Resolved closed
DDS-50 Obtaining the DomainParticipantFactory DDS 1.0b1 DDS 1.0 Resolved closed
DDS-49 Name of ObjectLink (consistency) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-46 ObjectHome::get_topic_name (editorial DDS 1.0b1 DDS 1.0 Resolved closed
DDS-45 stringSeq and longSeq (editorial) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-44 CacheAccess::deref (clarification) DDS 1.0b1 DDS 1.0 Resolved closed
DDS-43 CacheAccess::delete_access (editorial DDS 1.0b1 DDS 1.0 Resolved closed
DDS12-52 Support sequences of primitive types in DLRL Objects DDS 1.1 DDS 1.2 Resolved closed
DDS12-51 Clarify which Exceptions exist in DLRL and when to throw them DDS 1.1 DDS 1.2 Resolved closed
DDS12-43 Make the ObjectFilter and the ObjectQuery separate Selection Criterions DDS 1.1 DDS 1.2 Resolved closed
DDS12-42 Add the Set as a supported Collection type DDS 1.1 DDS 1.2 Resolved closed
DDS12-41 Harmonize Collection definitions in PIM and PSM DDS 1.1 DDS 1.2 Resolved closed
DDS12-40 Add Iterators to Collection types DDS 1.1 DDS 1.2 Resolved closed
DDS12-48 Representation of OID should be vendor specific DDS 1.1 DDS 1.2 Resolved closed
DDS12-47 Add Listener callbacks for changes in the update mode DDS 1.1 DDS 1.2 Resolved closed
DDS12-50 Merge find_object with find_object_in_access DDS 1.1 DDS 1.2 Resolved closed
DDS12-49 define both the Topic name and the Topic type_name separately DDS 1.1 DDS 1.2 Resolved closed
DDS12-54 Specification does not state how to instantiate an ObjectHome DDS 1.1 DDS 1.2 Resolved closed
DDS12-53 manual mapping key-fields of registered objects may not be changed DDS 1.1 DDS 1.2 Resolved closed
DDS12-46 Remove lock/unlock due to overlap with updates_enabled DDS 1.1 DDS 1.2 Resolved closed
DDS12-45 Make update rounds uninterruptable DDS 1.1 DDS 1.2 Resolved closed
DDS12-55 Raise PreconditionNotMet when changing filter expression on registered Obje DDS 1.1 DDS 1.2 Resolved closed
DDS12-44 Add a static initializer operation to the CacheFactory DDS 1.1 DDS 1.2 Resolved closed
DDSIRTP22-7 Use compliant OMG IDL syntax DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-6 Typographical errors DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-5 Add Entity Name Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-4 Interpreting Liveliness Heartbeats DDSI-RTPS 2.0b1 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-3 Reader-side Heartbeat response suppression DDSI-RTPS 2.0b1 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-2 Clarify interoperability requirement 8.4.2.3.3 DDSI-RTPS 2.0b1 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-10 Section: 8.3.7.3.5 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-9 Section: 8.3.5.8 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-8 Section: 8.2.1.2, Table 8.2, Locator_t row DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-17 Section: 9.3.2, Table 9.4 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-16 Section: 9.3.1.3, Table 9.2 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-19 Section: 9.4.5.1.3, Paragraph 3 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-18 Section: 9.4.2.6 and 9.4.2.8 (last lines of each section) DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-20 Section: 9.6.3.3 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-13 Section: 8.7.7 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-12 Section: 8.4.1.1, Item 16 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-22 Section: 10.1.1.1 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-21 Section: 10.1 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-14 Section: 8.7.8 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-23 Section: 10.1.1.1 and 10.1.1.2 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-11 Section: 8.4.1.1, Figure 8.14 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-15 Section: 9.3.1.2 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
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

Rules for evaluating liveliness by DataReader need to be clarified

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

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

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

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

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

    Other sections not mentioning the lease_duration may have similar problems.

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

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

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

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

    Let events happen according to this sequence:

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

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

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

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

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

    If the spec choose a subjective approach, then language should be added that warns the reader of the problem and the consequences like ownership not working as expected.
  • Reported: DDS 1.4 — Tue, 12 Nov 2024 16:49 GMT
  • Updated: Thu, 14 Nov 2024 18:26 GMT

Changes related to key regeneration

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

    Use of CryptoTransformKeyRevisionIntHolder alias in operation parameters

    The DDS Security Specification 1.2 defines the CryptoTransformKeyRevisionIntHolder type as:

    typedef int32 CryptoTransformKeyRevisionIntHolder;

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

    This should be changed so all these operations use CryptoTransformKeyRevisionIntHolder

    Clarify section “9.8.10.2 Key Exchange with remote DataReader

    The description in page 182 should clarify that that the participant can call create_local_datawriter_crypto_tokens multiple times (to get a crypto token sequence for different revisions).
  • Reported: DDS-SECURITY 1.2 — Thu, 10 Oct 2024 19:00 GMT
  • Updated: Thu, 14 Nov 2024 17:51 GMT

Make the format of annotation parameters more robust

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

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

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

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

    Instead it would be more flexible to say that the first paramater can be unnamed regardless of the name.
  • Reported: DDS-XTypes 1.3b1 — Wed, 30 Oct 2024 16:48 GMT
  • Updated: Wed, 30 Oct 2024 16:48 GMT

Section 7.3.1.2.1.11 is unclear

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

    There are three problems.

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

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

    3. The text should clarify if this is an annotation that is only applied locally and/or applied to remotes.
  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 14:03 GMT
  • Updated: Fri, 25 Oct 2024 16:55 GMT

Table 29 description of is_write_protected

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

    The description of is_write_protected starts with "Indicates if read access". This should be "Indicates if write access."
  • Reported: DDS-SECURITY 1.1b1 — Thu, 31 May 2018 16:49 GMT
  • Updated: Fri, 18 Oct 2024 19:15 GMT

SecureSubmessageCategory_t in normative IDL

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

    The normative IDL doesn't have SecureSubmessageCategory_t, but it does have SecureSumessageCategory_t which appears to be a typo.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 18:51 GMT
  • Updated: Fri, 18 Oct 2024 18:54 GMT

Modify XSD to make the elements i version 1.2 optional

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

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

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

    This change impacts the machine-readable file omg_shared_ca_governance.xsd
  • Reported: DDS-SECURITY 1.2 — Mon, 7 Oct 2024 16:11 GMT
  • Updated: Mon, 7 Oct 2024 16:11 GMT

Support optional for union members, add exception

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

    Would be useful to have support for @optional for union members. As IDL exceptions can be used through DDS-RPC also add exception members to this table, very likely to the ones that also are supported by structures
  • Reported: DDS-XTypes 1.3 — Wed, 11 Sep 2024 13:29 GMT
  • Updated: Fri, 27 Sep 2024 18:23 GMT

Wrong type name used: VehiclePositionType

  • Key: DDSXTY14-83
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    In the spec this section reads:

    7.2.1.1 Type Evolution Example

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

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

    VehiclePositionType in the second sentence should be replaced with VehicleLocationType
  • Reported: DDS-XTypes 1.3 — Fri, 13 Sep 2024 17:04 GMT
  • Updated: Fri, 27 Sep 2024 14:01 GMT

Inconsistent specification of where annotations can apply

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

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

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

    However
    section 7.3.1.2.1 (Built-in Annotations) says:

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

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

    At a minimum in XTYPES we should remove the specification of where annotations apply from section 7.3.1.2.1 and instead reference 7.2.2.6.
  • Reported: DDS-XTypes 1.3b1 — Tue, 17 Sep 2024 08:38 GMT
  • Updated: Tue, 17 Sep 2024 14:21 GMT

Minor clarifications and enhancements

  • Key: DDSTSN-3
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    In Clause 7.2.2, the term "network topology description" seems odd. The text should probably refer to the deployment configuration model.

    In Table 7.19, "DataFrameSpecification Definition", the second bullet point should only refer to UDP/IP, not "TCP/IP".

    In Clause 8.2.2 should clarify that endpoints in the context of DDS entities refer to DataReaders and DataWriters, the term may confuse readers coming from different backgrounds.

    In Clause B.1.2, the clarification on manual configurations that need to calculate a schedule should probably mention they need to calculate whether the requirements can be met (schedule may be a confusing term in that context).

    In B.2.1.1, "Square Stream Configuration", the destination-mac-address in the status response should be "01-00-5E-7F-FF-01" (given the destination multicast IP address).

    In B.2.1.2, "Triangle Stream Configuration", the destination-mac-address in the status response should be "01-00-5E-7F-FF-02" (given the destination multicast IP address).
  • Reported: DDS-TSN 1.0a1 — Sun, 31 Mar 2024 19:40 GMT
  • Disposition: Resolved — DDS-TSN 1.0b2
  • Disposition Summary:

    Apply minor clarifications and enhacements

    This resolution applies the suggested clarifications and enhancements.
  • Updated: Mon, 16 Sep 2024 14:17 GMT

Update references to 802.1Qcc and 802.1Qcr, which have been merged into 802.1Q

  • Key: DDSTSN-1
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    IEEE 802.1Q has recently (as of 2022) incorporated several specifications that have been developed in parallel. That is the case of 802.1Qcc, which this specification heavily relies on, and 802.1Qcr. This is part of the regular process of IEEE.

    At the time of publication of the revised submission, 802.1Q-2022 was being voted and finalized, so the Beta 1 version of DDS-TSN points to 802.1Q-2018, 802.1Qcc, and 802.1Qcr. We should update these references and point to 802.1Q-2022, which now includes both Qcc and Qcr.
  • Reported: DDS-TSN 1.0a1 — Sun, 31 Mar 2024 17:58 GMT
  • Disposition: Resolved — DDS-TSN 1.0b2
  • Disposition Summary:

    Update references to 802.1Qcc and 802.1Qcr

    As part of this resolution, we update references to 802.1Qcc and 802.1Qcr with references to IEEE 802.1Q (2022), which has merged these specifications into the core document.
  • Updated: Mon, 16 Sep 2024 14:17 GMT

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

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

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

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

    It would seem like.a good idea to allow application (DataReaders) to opt in or out of matching writers that have types with incompatible @range and/or @unit. If so mechanisms should be provided to configure this and make sure the complete TypeIdentifier is propagated in those cases as the corresponding TypeObject is the only one that has the information of @range and @unit.
  • Reported: DDS-XTypes 1.3b1 — Wed, 11 Sep 2024 15:37 GMT
  • Updated: Wed, 11 Sep 2024 15:37 GMT

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

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

    The specification should specify how string parameters should be escaped when used withing a query string, for example a query_expression of "name = 'bar'", but what if bar is a string with a single quote, newline, tab, etc? The specification should specify the escaping rules for that.
  • Reported: DDS 1.4 — Thu, 4 Mar 2021 07:04 GMT
  • Updated: Fri, 6 Sep 2024 19:21 GMT

Typo fixes

  • Key: DDSXTY14-79
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    Pg 48 7.2.2.4.6 first sentence

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

    -> Aggregated


    Pg 48 7.2.2.4.6 first sentence

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

    -> obtained


    Pg 50 7.2.2.4.7 first sentence

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

    -> obtained


    Pg 54 Figure 19 label at aggregation arrow to AnnotationParameter

    +paramter_seq

    -> +parameter_seq


    Pg 133 Table 38 4th row column meaning

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

    -> Endianness


    Pg 146 continuation of 7.4.3.5.3 4th line from top

    // FMMEBER can be NOPT_FMEMBER [...]

    -> FMEMBER


    Pg 215 Table 60 4th column, header

    Endianess

    -> Endianness


    Pg 248 continuation of Annex A 2nd para from top

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

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


    Pg 263 continuation of Annex B bottom of page

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

    -> declarations


    Pg 266 continuation of Annex B 3rd para from top

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

    -> dependencies


    Pg 268 continuation of Annex B approx 10 lines down

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

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

Misspellings of "aggregated"

  • Key: DDSXTY14-78
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    Pg 43 7.2.2.4.4.4.3 Member Index 2nd sentence

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

    Pg 47 7.2.2.4.5 Inheritance of Aggregated Types 1st sentence

    The Type System supports single inheritance of Aggegated Types.

    Pg 49 continuation of 7.2.2.4.6 comment before union Command_TypeErased

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

    Pg 51 continuation of 7.2.2.4.7 comment before union Command__KeyHolder

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

    On this last occurrence, is the double underscore in union Command__KeyHolder intentional?
  • Reported: DDS-XTypes 1.3 — Tue, 20 Aug 2024 09:14 GMT
  • Updated: Wed, 4 Sep 2024 14:12 GMT

Inheritance rule regarding keys is overly restrictive

  • Key: DDSXTY14-77
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    The Resolution Summary of DDSXTY13-23 states:

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

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

    I propose to change the first sentence to

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

    This restores viability for the mentioned use case where the base type(s) are just being used as header(s).
    It hinges on the assumption that if all base types are nested then the question of assignability does not arise at the topic level.
  • Reported: DDS-XTypes 1.3 — Sun, 18 Aug 2024 09:43 GMT
  • Updated: Wed, 4 Sep 2024 14:03 GMT

Validation errors in JSON Schemas

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

    Some JSON schemas contain lack certain restrictions that are enforced in strict validations.
  • Reported: DDS-JSON 1.0 — Fri, 30 Aug 2024 11:58 GMT
  • Updated: Fri, 30 Aug 2024 11:58 GMT

Provide pre-shared protection for unauthenticated messages

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

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

    This issue should be addressed by DDS-Security. Likely using some pre-shared key mechanics to protect all messages not otherwise protected. For example, the authentication handshakes.
  • Reported: DDS-SECURITY 1.1b1 — Fri, 12 Nov 2021 16:28 GMT
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Provide a layer of PSK protection

    Peovide the means to use a pre-shared secret to protect any RTPS message (e.g. bootstrap messges) that is not otherwise protected by the keys that the DomainParticipants exchange.

    Also define the "pre-shared" key mechanism as a separate "builtin" plugin
  • Updated: Tue, 20 Aug 2024 00:49 GMT
  • Attachments:

Incorrect property names used

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

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

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

    Which are the names that appear in the "Configuration Properties" tables in the "Property Name" column.
  • Reported: DDS-SECURITY 1.2 — Tue, 20 Aug 2024 00:48 GMT
  • Updated: Tue, 20 Aug 2024 00:48 GMT

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

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

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

create_sample can't indicate failure

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

    As defined create_sample can only return the sample object. This doesn't allow the API to indicate that there was an error unlike other calls in DDS. Other operations either can't normally fail, return an interface that can be null, or return a ReturnCode_t. At least in the C++ Language Mapping, create_sample can return a struct or a union by value, so it can't be null in those cases (section 5.11). I imagine this might be different in other mappings though.
  • Reported: DDS-XTypes 1.3 — Wed, 5 Jun 2024 17:28 GMT
  • Updated: Mon, 1 Jul 2024 15:12 GMT

Operation: set_permissions_credential_and_token

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

    Section 8.3.2.11.11 has no description of the permissions_token parameter
  • Reported: DDS-SECURITY 1.1b1 — Fri, 6 Jul 2018 21:42 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Builtin Auth dependency on Access Control details

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

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

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

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

    Another connection between the two plugins is made by the PermissionsCredentialToken. If the intent is to use this data when generating handshake handles, that should be noted in tables 49-50 (c.perm) instead of referencing QoS policies there.
  • Reported: DDS-SECURITY 1.1b1 — Mon, 23 Jul 2018 16:19 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Misleading description of Crypto Key Exchange (8.5.1.8)

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

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

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

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

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

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

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

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

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

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

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

    See the revised RTPS text here: DDSIRTP23-117
  • Reported: DDS-SECURITY 1.1b1 — Fri, 20 Jul 2018 16:44 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

validate_remote_permissions interaction with Authentication Plugin

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

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

    So that validate_remote_permissions makes more sense, remove the auth_plugin and remote_identity_handle parameters (Table 32, section 8.4.2.9.2, Table 63, IDL).
  • Reported: DDS-SECURITY 1.1b1 — Fri, 6 Jul 2018 21:56 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Inconsistent descriptions of Data Tagging

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

    Section 8.7 specifies the optional Data Tagging model, but the details of how this works really reside in the Access Control plugin. Sections 1.2 and 2.3 need to be updated to remove references to a Data Tagging "Plugin." Also update section 8.1.1. For clarity, update section 8.7.2 to add a reference to Access Control.
  • Reported: DDS-SECURITY 1.1b1 — Mon, 6 Aug 2018 16:58 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

get_topic_sec_attributes 3rd parameter type

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

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

    Also Figure 10 calls this method get_topic_security_attributes instead of using "sec".
  • Reported: DDS-SECURITY 1.1b1 — Fri, 6 Jul 2018 21:47 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

IDL struct ParticipantSecurityAttributes contains ac_endpoint_properties

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

    The name of field ac_endpoint_properties in ParticipantSecurityAttributes should be ac_participant_properties as specified in Table 27.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Jul 2018 16:47 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

serialized_local_participant_data passed to Auth plugin

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

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

    Alternatively, revisit the choice to use OctetSeq here in the plugin API. It seems like it would be fine to pass the structure ParticipantBuiltInTopicDataSecure directly to the plugin, as is already done with Access Control.
  • Reported: DDS-SECURITY 1.1b1 — Thu, 9 Aug 2018 16:01 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

class_id string in Authentication/Permissions Tokens should include spec version

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

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

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

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

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

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

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

    Note that this change is not intended to break backwards interoperability. So the proposal could/should be adjusted to ensure that. Specifically the change in the name for the PermissionsCredentialToken should not impact interoperability as this token is not exchanged between participants. The same is true for the addition of the "+AuthPeer" to the AuthenticatedPeerCredentialToken.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 17 Dec 2019 00:26 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

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

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

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

    Specifically it should prescribe that:

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

      match what Participant A sent in the HandshakeRequestMessageToken.

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

      match what Participant B sent in the HandshakeRequestMessageToken.

    This should be made clear both in 9.3.4.2 'Protocol description' and in Table 52 'Actions undertaken by the operations of the builtin Authentication plugin'.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 6 Aug 2019 17:13 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Add support for ChaCha20

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

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

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

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

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

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

Multiple grants in a permissions document

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

    There is only one <permissions> element in a permissions document, but it can contain multiple <grant> elements. Section 9.4.1.3.2.1 states "Each subject name can only appear in a single <permissions> Section"... which should be "single <grant> Section" and "A permissions Section with a subject name that doesn't match" should be "A grant Section with a subject name that doesn't match."
  • Reported: DDS-SECURITY 1.1b1 — Mon, 20 Aug 2018 15:41 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Invalid IETF RFC document reference.

  • Key: DDSSEC13-67
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

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

    It seems that it should be "IETF RFC 2633". At least then the mentioned RFC sections fit.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 4 Sep 2018 10:56 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Protecting the Source Timestamp

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

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

    It would be better if it was included into the DATA / DATA_FRAG submessge as an inlineQos
  • Reported: DDS-SECURITY 1.1b1 — Fri, 27 Jul 2018 12:32 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

IDL should be updated to match IDL 4.2

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

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

    This specially impacts annotations. For example @Extensibility(MUTABLE_EXTENSIBILITY) has been replace with @mutable.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 29 Aug 2018 00:44 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

The Qos used to publish the BuiltinLoggingTopic is not specicified

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

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

    See for example how it is done for the DCPSParticipantMessageSecure builtin Topic (section 7.4.2) where it refers to the Qos of other builtin Topics and also how it is done for the TopicBuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader (section 7.4.4.2 ) where it defines it explicitly.
  • Reported: DDS-SECURITY 1.1b1 — Thu, 26 Mar 2020 16:48 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

encode_rtps_message/decode_rtps_message error and status reporting

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

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

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

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

    Extending this idea of enum (or integer constants) return types instead of boolean to other CryptoTransform operations may also be useful. For example, the other encode operations could return a OK_NOT_ENCODED instead of copying data.
  • Reported: DDS-SECURITY 1.1 — Tue, 17 Sep 2019 21:53 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

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

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

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

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

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

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

    Users are already hitting this limit so this issue requests that capability to send the permissions compressed is added with high priority, even if later a more general solution is developed as requested in DDSSEC12-13.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 1 Sep 2020 17:50 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Provide efficient way to skip encrypted implementation-specific content

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

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

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

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

    The proposal therefore is to designate the leftmost flag of the SRTPS_PREFIX submessage to indicate it contains only "vendor specific content".
  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Jun 2023 04:35 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Add return_permissions_handle to the AccessControl interface

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

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

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

Update parameters of check_remote_datawriter_register_instance

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

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

    In the IDL file and Table 32 in 8.4.2.9 there's also an instance_handle parameter, which should be removed.
  • Reported: DDS-SECURITY 1.1 — Fri, 24 Jun 2022 19:50 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Builtin Access Control operations (Table 63) missing entries

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

    The operations get_topic_sec_attributes, get_datareader_sec_attributes and get_datawriter_sec_attributes are missing from Table 63 - Actions undertaken by the operations of the bulitin AccessControl plugin.
  • Reported: DDS-SECURITY 1.1 — Mon, 27 Aug 2018 22:12 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Add best practice/implementation guidelines to the CryptoTransform plugin

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

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

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

    This issue requests some mechanism to support this last use case.
  • Reported: DDS-SECURITY 1.1b1 — Fri, 30 Jun 2023 16:34 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Problematic use of multiple INFO_SRC within an RTPS

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

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

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

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

    Should it be disallowed just for DDS-Security or for DDS in general?
  • Reported: DDS-SECURITY 1.1b1 — Wed, 27 Sep 2023 13:24 GMT
  • Updated: Fri, 21 Jun 2024 22:35 GMT

Parsing messages generated by encode_serialized_payload (auth only)

  • Key: DDSSEC12-59
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

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

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

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

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

    To resolve this, an additional element for "length" could be added before the SerializedPayload, just like the CryptoContent submessage element does. This would make parsing the encoded payload similar for the encrypt and auth-only cases.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 9 May 2018 15:38 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Parsing messages generated by encode_serialized_payload (auth only)

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

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

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

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

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

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

    To resolve this, an additional element for "length" could be added before the SerializedPayload, just like the CryptoContent submessage element does. This would make parsing the encoded payload similar for the encrypt and auth-only cases.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 9 May 2018 15:38 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Table 29 description of is_write_protected

  • Key: DDSSEC12-61
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The description of is_write_protected starts with "Indicates if read access". This should be "Indicates if write access."
  • Reported: DDS-SECURITY 1.1b1 — Thu, 31 May 2018 16:49 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

check_remote_topic domainId parameter

  • Key: DDSSEC12-60
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    domainId is not listed in section 8.4.2.9.12
  • Reported: DDS-SECURITY 1.1b1 — Thu, 10 May 2018 15:06 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

check_remote_topic domainId parameter

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

    domainId is not listed in section 8.4.2.9.12
  • Reported: DDS-SECURITY 1.1b1 — Thu, 10 May 2018 15:06 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

AES-GCM doesn't add padding

  • Key: DDSSEC12-58
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

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

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

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

AES-GCM doesn't add padding

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

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

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

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

Builtin Crypto message authentication codes

  • Key: DDSSEC12-57
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

    This statement appears to contradict the descriptions of common_mac and receiver_specific_macs in 9.5.3.3.4.4 (payload), 9.5.3.3.4.5 (submessage), and 9.5.3.3.4.6 (message).
  • Reported: DDS-SECURITY 1.1b1 — Thu, 19 Apr 2018 20:58 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Builtin Crypto message authentication codes

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

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

    This statement appears to contradict the descriptions of common_mac and receiver_specific_macs in 9.5.3.3.4.4 (payload), 9.5.3.3.4.5 (submessage), and 9.5.3.3.4.6 (message).
  • Reported: DDS-SECURITY 1.1b1 — Thu, 19 Apr 2018 20:58 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

register_local_datareader and Data Protection Kind

  • Key: DDSSEC12-44
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In the Table 70 row for register_local_datareader, the ReaderKeyMaterial is created based on Data Protection Kind. This should be Metadata Protection Kind because the ReaderKeyMaterial signs/encrypts submessages and not data payloads.
  • Reported: DDS-SECURITY 1.1b1 — Fri, 9 Mar 2018 20:51 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Replace "CryptoKeyTransform" with "CryptoTransform"

  • Key: DDSSEC12-45
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The term CryptoKeyTransform is used 3 times (section name of 9.5.3.3, text of 9.5.3.3.1, caption of Table 72). These should be CryptoTransform.
  • Reported: DDS-SECURITY 1.1b1 — Fri, 9 Mar 2018 21:19 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

"atributes" typo

  • Key: DDSSEC12-46
  • Status: closed  
  • Source: OCI ( Tim Simpson)
  • Summary:

    participant_security_attributes is currently spelled participant_security_atributes on page 25 of the specification.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 14 Feb 2018 21:57 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

register_local_datareader and Data Protection Kind

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

    In the Table 70 row for register_local_datareader, the ReaderKeyMaterial is created based on Data Protection Kind. This should be Metadata Protection Kind because the ReaderKeyMaterial signs/encrypts submessages and not data payloads.
  • Reported: DDS-SECURITY 1.1b1 — Fri, 9 Mar 2018 20:51 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Replace "CryptoKeyTransform" with "CryptoTransform"

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

    The term CryptoKeyTransform is used 3 times (section name of 9.5.3.3, text of 9.5.3.3.1, caption of Table 72). These should be CryptoTransform.
  • Reported: DDS-SECURITY 1.1b1 — Fri, 9 Mar 2018 21:19 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Clarify the configuration and use of certificate chains for Identity

  • Key: DDSSEC12-48
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

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

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

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

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

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

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

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

    (6) In Table 53 IdentityCertificate is undefined. Maybe it should be "identity_certificate" and refer to the property defined in Table 44.
  • Reported: DDS-SECURITY 1.1b1 — Mon, 9 Apr 2018 23:56 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Clarify the configuration and use of certificate chains for Identity

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

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

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

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

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

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

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

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

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

    (6) In Table 53 IdentityCertificate is undefined. Maybe it should be "identity_certificate" and refer to the property defined in Table 44.
  • Reported: DDS-SECURITY 1.1b1 — Mon, 9 Apr 2018 23:56 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Builtin CryptoKeyFactory direct dependency on AccessControl's config details

  • Key: DDSSEC12-50
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

    It would be easier to follow and more modular if this was changed to instead reference the data structure that the CryptoKeyFactory can actually see, which in this case is ParticipantSecurityAttributes.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 16:41 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Inconsistent Flag Name PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_BUILTIN_IS_DISCOVERY_ENCRYPTED

  • Key: DDSSEC12-47
  • Status: closed  
  • Source: OCI ( Tim Simpson)
  • Summary:

    All the other flag names defined here take the form of "PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_IS_XXX_YYY". Should the BUILTIN part of this flag really be there? I believe this should instead read: PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_IS_DISCOVERY_ENCRYPTED.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 14 Feb 2018 22:02 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Builtin CryptoKeyFactory direct dependency on AccessControl's config details

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

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

    It would be easier to follow and more modular if this was changed to instead reference the data structure that the CryptoKeyFactory can actually see, which in this case is ParticipantSecurityAttributes.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 16:41 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Participant2ParticipantKxKeyMaterial

  • Key: DDSSEC12-51
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

    It would be helpful to have a table that lists each "key material" object along with which operation creates it and how it's used.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 16:45 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Inconsistent Flag Name PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_BUILTIN_IS_DISCOVERY_ENCRYPTED

  • Key: DDSSEC13-42
  • Status: open  
  • Source: OCI ( Tim Simpson)
  • Summary:

    All the other flag names defined here take the form of "PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_IS_XXX_YYY". Should the BUILTIN part of this flag really be there? I believe this should instead read: PLUGIN_PARTICIPANT_SECURITY_ATTRIBUTES_FLAG_IS_DISCOVERY_ENCRYPTED.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 14 Feb 2018 22:02 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Participant2ParticipantKxKeyMaterial

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

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

    It would be helpful to have a table that lists each "key material" object along with which operation creates it and how it's used.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 16:45 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

9.5.3.3.4.3 should refer to the footer, not header

  • Key: DDSSEC12-52
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The last paragraph of 9.5.3.3.4.3 refers to the "CryptoHeader", this should be "CryptoFooter"
  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 16:48 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

9.5.3.3.4.3 should refer to the footer, not header

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

    The last paragraph of 9.5.3.3.4.3 refers to the "CryptoHeader", this should be "CryptoFooter"
  • Reported: DDS-SECURITY 1.1b1 — Wed, 11 Apr 2018 16:48 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

"atributes" typo

  • Key: DDSSEC13-41
  • Status: open  
  • Source: OCI ( Tim Simpson)
  • Summary:

    participant_security_attributes is currently spelled participant_security_atributes on page 25 of the specification.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 14 Feb 2018 21:57 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Modify Security's QoS changes for compatibility with RTPS

  • Key: DDSSEC12-37
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

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

    We can represent this restriction on PropertyQosPolicy in IDL4:

    @extensibility(FINAL)
struct PropertyQosPolicy {
  PropertySeq value;

  @non-serialized
  BinaryPropertySeq binary_value;
};

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

    Also, for consistency the Tag and DataTags structs could be made @extensibility(FINAL). This is not as important since only Security-aware implementations will know about DataTagQosPolicy.
  • Reported: DDS-SECURITY 1.1b1 — Mon, 19 Feb 2018 23:37 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Modify Security's QoS changes for compatibility with RTPS

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

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

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

    We can represent this restriction on PropertyQosPolicy in IDL4:

    @extensibility(FINAL)
struct PropertyQosPolicy {
  PropertySeq value;

  @non-serialized
  BinaryPropertySeq binary_value;
};

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

    Also, for consistency the Tag and DataTags structs could be made @extensibility(FINAL). This is not as important since only Security-aware implementations will know about DataTagQosPolicy.
  • Reported: DDS-SECURITY 1.1b1 — Mon, 19 Feb 2018 23:37 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Broken cross-references

  • Key: DDSSEC12-38
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

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

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

IDL ParticipantSecurityAttributes::plugin_participant_attributes

  • Key: DDSSEC12-43
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In the normative IDL, the struct ParticipantSecurityAttributes's field plugin_participant_attributes has type ParticipantSecurityAttributesMask but it should have type PluginParticipantSecurityAttributesMask
  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Mar 2018 21:33 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

IDL ParticipantSecurityAttributes::plugin_participant_attributes

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

    In the normative IDL, the struct ParticipantSecurityAttributes's field plugin_participant_attributes has type ParticipantSecurityAttributesMask but it should have type PluginParticipantSecurityAttributesMask
  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Mar 2018 21:33 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Various Typos

  • Key: DDSSEC12-42
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Section 7.4.4.2 "TopicSecurityAtributes" should be "Attributes"

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

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

    Section 8.8.4 "simultanepusly" should be "simultaneously"

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

    Section 9.5 "BEST_EFFORTS" should be "BEST_EFFORT"

    Section 9.5.2.3 "indentifier" should be "identifier"

    Section 9.5.3.1 "ciphetext' should be "ciphertext"

    Normative IDL parameter 1 of create_local_data_crypto_tokens "cryto" should be "crypto"
  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Mar 2018 17:02 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Reduce the range of Reserved RTPS parameter IDs

  • Key: DDSSEC12-41
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

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

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

    Section 7.4.1.3 should be updated to reflect this reduced range.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 6 Mar 2018 23:34 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Return types in CryptoKeyFactory interface description

  • Key: DDSSEC12-40
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In CryptoKeyFactory, all operations other than the unregister_* ones return handles. But the descriptions of register_matched_remote_participant and register_local_datawriter (8.5.1.7.2-3) end with "operation returns false". That should be "operation returns HandleNIL".
  • Reported: DDS-SECURITY 1.1b1 — Thu, 1 Mar 2018 19:31 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Reduce the range of Reserved RTPS parameter IDs

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

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

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

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

    Section 7.4.1.3 should be updated to reflect this reduced range.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 6 Mar 2018 23:34 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

AuthRequestMessageToken future_challenge property

  • Key: DDSSEC12-39
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In Table 48 (9.3.2.4), "properties" should be "binary_properties" so that the property future_challenge is treated as binary, matching Table 49's challenge1.
  • Reported: DDS-SECURITY 1.1b1 — Thu, 1 Mar 2018 19:02 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Return types in CryptoKeyFactory interface description

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

    In CryptoKeyFactory, all operations other than the unregister_* ones return handles. But the descriptions of register_matched_remote_participant and register_local_datawriter (8.5.1.7.2-3) end with "operation returns false". That should be "operation returns HandleNIL".
  • Reported: DDS-SECURITY 1.1b1 — Thu, 1 Mar 2018 19:31 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

AuthRequestMessageToken future_challenge property

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

    In Table 48 (9.3.2.4), "properties" should be "binary_properties" so that the property future_challenge is treated as binary, matching Table 49's challenge1.
  • Reported: DDS-SECURITY 1.1b1 — Thu, 1 Mar 2018 19:02 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Various Typos

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

    Section 7.4.4.2 "TopicSecurityAtributes" should be "Attributes"

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

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

    Section 8.8.4 "simultanepusly" should be "simultaneously"

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

    Section 9.5 "BEST_EFFORTS" should be "BEST_EFFORT"

    Section 9.5.2.3 "indentifier" should be "identifier"

    Section 9.5.3.1 "ciphetext' should be "ciphertext"

    Normative IDL parameter 1 of create_local_data_crypto_tokens "cryto" should be "crypto"
  • Reported: DDS-SECURITY 1.1b1 — Thu, 8 Mar 2018 17:02 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Broken cross-references

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

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

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

Security for DDS-RPC

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

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

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

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

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

    Alternatively DDS-Security could specify some other mechanism, for example designate a data-tag to indicate the operations that the request DataWriter may invoke. The receiver side would check that the operation invoked matches the DataWriter tag before processing the request.
  • Reported: DDS-SECURITY 1.1b1 — Sun, 11 Feb 2018 07:43 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Authentication behavior use of built-in endpoints

  • Key: DDSSEC12-32
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

    However there are parts of 8.3.2.11 and 8.8.2 that describe this handshake using the names BuiltinParticipantMessageWriter / Reader (note the absence of "Stateless"). The name BuiltinParticipantMessageWriter is defined by the RTPS spec as the endpoint used to implement the participant scoped liveliness (see RTPS 2.2 section 8.4.13.2).
  • Reported: DDS-SECURITY 1.1b1 — Wed, 14 Feb 2018 21:41 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Security for DDS-RPC

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

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

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

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

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

    Alternatively DDS-Security could specify some other mechanism, for example designate a data-tag to indicate the operations that the request DataWriter may invoke. The receiver side would check that the operation invoked matches the DataWriter tag before processing the request.
  • Reported: DDS-SECURITY 1.1b1 — Sun, 11 Feb 2018 07:43 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

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

  • Key: DDSSEC12-33
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    If the crypto plugin transforms the payload but the layers containing the payload (submessage or message) are not transformed, the resulting Data/Frag submessage contains no indication that its payload has a nonstandard format.
    Since this spec is essentially defining a new minor version of RTPS (along with RTPS RTF process concurrent to this), one of the reserved flags in the submessage header of Data/Frag can be defined as FLAG_S meaning that the format of the SerializedPayload submessage element is defined by the security spec.
  • Reported: DDS-SECURITY 1.1b1 — Thu, 15 Feb 2018 19:38 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Authentication behavior use of built-in endpoints

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

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

    However there are parts of 8.3.2.11 and 8.8.2 that describe this handshake using the names BuiltinParticipantMessageWriter / Reader (note the absence of "Stateless"). The name BuiltinParticipantMessageWriter is defined by the RTPS spec as the endpoint used to implement the participant scoped liveliness (see RTPS 2.2 section 8.4.13.2).
  • Reported: DDS-SECURITY 1.1b1 — Wed, 14 Feb 2018 21:41 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

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

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

    If the crypto plugin transforms the payload but the layers containing the payload (submessage or message) are not transformed, the resulting Data/Frag submessage contains no indication that its payload has a nonstandard format.
    Since this spec is essentially defining a new minor version of RTPS (along with RTPS RTF process concurrent to this), one of the reserved flags in the submessage header of Data/Frag can be defined as FLAG_S meaning that the format of the SerializedPayload submessage element is defined by the security spec.
  • Reported: DDS-SECURITY 1.1b1 — Thu, 15 Feb 2018 19:38 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Wrong XML tag in description of Enable Read Access Control

  • Key: DDSSEC12-34
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    9.4.1.2.6.4 describes Enable Read Access Control, however the bullet list within this section uses the xml tag <enable_write_access_control> (twice), it should be <enable_read_access_control>.
  • Reported: DDS-SECURITY 1.1b1 — Fri, 16 Feb 2018 22:33 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Wrong XML tag in description of Enable Read Access Control

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

    9.4.1.2.6.4 describes Enable Read Access Control, however the bullet list within this section uses the xml tag <enable_write_access_control> (twice), it should be <enable_read_access_control>.
  • Reported: DDS-SECURITY 1.1b1 — Fri, 16 Feb 2018 22:33 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Description of the PluginEndpointSecurityAttributes

  • Key: DDSSEC12-35
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The rows in Table 61 is_submessage_encrypted and is_payload_encrypted each have paragraphs starting "If is_*_encrypted is FALSE..." and including "GCM authenticated encryption", which should be "GMAC authentication transformation" like the corresponding rows of Table 59.
  • Reported: DDS-SECURITY 1.1b1 — Fri, 16 Feb 2018 23:06 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Description of the EndpointSecurityAttributes

  • Key: DDSSEC12-36
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In Table 30, the entry for is_payload_protected says "If is_payload_protected is FALSE, then the CryptoKeyFactory, KeyExchange and CryptoTransform operations are called only if is_payload_protected is TRUE", but the last phrase should be "only if is_submessage_protected is TRUE".
  • Reported: DDS-SECURITY 1.1b1 — Fri, 16 Feb 2018 23:16 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Description of the PluginEndpointSecurityAttributes

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

    The rows in Table 61 is_submessage_encrypted and is_payload_encrypted each have paragraphs starting "If is_*_encrypted is FALSE..." and including "GCM authenticated encryption", which should be "GMAC authentication transformation" like the corresponding rows of Table 59.
  • Reported: DDS-SECURITY 1.1b1 — Fri, 16 Feb 2018 23:06 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Description of the EndpointSecurityAttributes

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

    In Table 30, the entry for is_payload_protected says "If is_payload_protected is FALSE, then the CryptoKeyFactory, KeyExchange and CryptoTransform operations are called only if is_payload_protected is TRUE", but the last phrase should be "only if is_submessage_protected is TRUE".
  • Reported: DDS-SECURITY 1.1b1 — Fri, 16 Feb 2018 23:16 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

IDL get_topic_sec_attributes parameter typo

  • Key: DDSSEC12-25
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    2nd parameter to get_topic_sec_attributes has type "String", should be "string".
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:07 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

IDL get_topic_sec_attributes parameter typo

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

    2nd parameter to get_topic_sec_attributes has type "String", should be "string".
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:07 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Determining when to use DCPSParticipantMessageSecure

  • Key: DDSSEC12-28
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

    However it is not clear which topic's TopicSecurityAttributes are to be used. The liveliness message essentially belongs to the participant and not any given topic (see RTPS v2.2 8.4.13.5). Should the security spec use ParticipantSecurityAttributes here instead?
  • Reported: DDS-SECURITY 1.1b1 — Thu, 1 Feb 2018 17:03 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

ParticipantStatelessMessage definition

  • Key: DDSSEC12-27
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Section 7.4.3.2:

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

    Two issues:
    a. I don't see how this relates to 7.2.5, should that be 7.2.6?
    b. The typedef is backwards. Typedef declares a new name (second) from an existing type (first).
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:23 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Determining when to use DCPSParticipantMessageSecure

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

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

    However it is not clear which topic's TopicSecurityAttributes are to be used. The liveliness message essentially belongs to the participant and not any given topic (see RTPS v2.2 8.4.13.5). Should the security spec use ParticipantSecurityAttributes here instead?
  • Reported: DDS-SECURITY 1.1b1 — Thu, 1 Feb 2018 17:03 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

ParticipantStatelessMessage definition

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

    Section 7.4.3.2:

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

    Two issues:
    a. I don't see how this relates to 7.2.5, should that be 7.2.6?
    b. The typedef is backwards. Typedef declares a new name (second) from an existing type (first).
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:23 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

IDL SubscriptionBuiltinTopicDataSecure inheritance

  • Key: DDSSEC12-26
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    SubscriptionBuiltinTopicDataSecure should inherit from SubscriptionBuiltinTopicData in the local module, not the one in the DDS:: module.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:10 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

8.4.2.9.24 section name typo

  • Key: DDSSEC12-30
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Operation: get_datarwriter_sec_attributes
    should be
    Operation: get_datawriter_sec_attributes
  • Reported: DDS-SECURITY 1.1b1 — Fri, 9 Feb 2018 20:34 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

IDL SubscriptionBuiltinTopicDataSecure inheritance

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

    SubscriptionBuiltinTopicDataSecure should inherit from SubscriptionBuiltinTopicData in the local module, not the one in the DDS:: module.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:10 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

8.4.2.9.24 section name typo

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

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

Allow expressions to be used in the data-tag permissions

  • Key: DDSSEC12-19
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

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

    So to match the rule the DataTag name in the Qos must exactly match the name in the permissions document (no expressions here) and the DataTag value in the Qos should match (using fnmatch) the expression in the permissions document.
  • Reported: DDS-SECURITY 1.1 — Thu, 18 Jan 2018 23:24 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Allow expressions to be used in the data-tag permissions

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

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

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

    So to match the rule the DataTag name in the Qos must exactly match the name in the permissions document (no expressions here) and the DataTag value in the Qos should match (using fnmatch) the expression in the permissions document.
  • Reported: DDS-SECURITY 1.1 — Thu, 18 Jan 2018 23:24 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Authentication interface begin_handshake_reply()

  • Key: DDSSEC12-18
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Normative IDL has no parameter handshake_message_in (from Table 23). It would be possible to use handshake_message_out to serve the purposes of "in" since it's an inout parameter in IDL, but is that the intention here?
  • Reported: DDS-SECURITY 1.1b1 — Wed, 10 Jan 2018 19:37 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

decode_datawriter_submessage uses "in" for SecurityException

  • Key: DDSSEC12-21
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In the normative IDL interface CryptoTransform, the decode_datawriter_submessage operation uses the "in" parameter passing mode for SecurityException – should be "out" or "inout".
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 18:54 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

SecureSubmessageCategory_t in normative IDL

  • Key: DDSSEC12-20
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The normative IDL doesn't have SecureSubmessageCategory_t, but it does have SecureSumessageCategory_t which appears to be a typo.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 18:51 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Authentication interface begin_handshake_reply()

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

    Normative IDL has no parameter handshake_message_in (from Table 23). It would be possible to use handshake_message_out to serve the purposes of "in" since it's an inout parameter in IDL, but is that the intention here?
  • Reported: DDS-SECURITY 1.1b1 — Wed, 10 Jan 2018 19:37 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

decode_datawriter_submessage uses "in" for SecurityException

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

    In the normative IDL interface CryptoTransform, the decode_datawriter_submessage operation uses the "in" parameter passing mode for SecurityException – should be "out" or "inout".
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 18:54 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

get_datawriter/reader_sec_attributes inconsistent IDL

  • Key: DDSSEC12-22
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Table 32 (8.4.2.9) has a topic_name parameter for both get_datawriter_sec_attributes and get_datareader_sec_attributes, however this parameter is not present in the normative IDL.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 18:59 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Authentication interface set_permissions_credential_and_token

  • Key: DDSSEC12-23
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In the normative IDL, the type of the 2nd parameter for set_permissions_credential_and_token is listed as PermissionsCredential but should PermissionsCredentialToken.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:04 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

IDL LongLongSeq unused

  • Key: DDSSEC12-24
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    DDS::Security::LongLongSeq is not used so it should be removed from the normative IDL.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:06 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

get_datawriter/reader_sec_attributes inconsistent IDL

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

    Table 32 (8.4.2.9) has a topic_name parameter for both get_datawriter_sec_attributes and get_datareader_sec_attributes, however this parameter is not present in the normative IDL.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 18:59 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Authentication interface set_permissions_credential_and_token

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

    In the normative IDL, the type of the 2nd parameter for set_permissions_credential_and_token is listed as PermissionsCredential but should PermissionsCredentialToken.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:04 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

IDL LongLongSeq unused

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

    DDS::Security::LongLongSeq is not used so it should be removed from the normative IDL.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 30 Jan 2018 19:06 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

DataHolder IDL inconsistent

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

    In 7.2.3.1, DataHolder is a struct annotated with @extensibility(APPENDABLE) and no optional fields.
    However in ptc/17-09-26 (normative IDL), DataHolder has no @extensibility annotation and two optional fields.
  • Reported: DDS-SECURITY 1.1b1 — Thu, 4 Jan 2018 21:38 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

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

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

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

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

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

    Therefore it would be better if the specification removed this duplication and just referenced the external machine-readable files.
  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 09:30 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Section 3 (Normative References) should be updated and expanded

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

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

    Section 3 should be expanded to include the subset of those references that are used for normative behavior. [46], [47], and [52] are clear examples of references that should be moved to Section 3.
  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 07:02 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Issues with the UML model used in the specification

  • Key: DDSSEC12-10
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

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

    These issues should be corrected.
  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 07:07 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

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

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

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

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

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

    Therefore it would be better if the specification removed this duplication and just referenced the external machine-readable files.
  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 09:30 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Section 3 (Normative References) should be updated and expanded

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

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

    Section 3 should be expanded to include the subset of those references that are used for normative behavior. [46], [47], and [52] are clear examples of references that should be moved to Section 3.
  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 07:02 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Avoid sending permissions as part of Authentication Handshake

  • Key: DDSSEC12-13
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

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

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

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

    Related this is the fact that permissions are "monolithic" of you need to add a permission to a Participant you need to create and sign a new document. Would be nice to have some way to grant/propagate incremental permissions. E.g. something that could be bundled into the propagation of the Endpoint discovery data itself.
  • Reported: DDS-SECURITY 1.1 — Sat, 18 Nov 2017 00:42 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Avoid sending permissions as part of Authentication Handshake

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

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

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

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

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

    Related this is the fact that permissions are "monolithic" of you need to add a permission to a Participant you need to create and sign a new document. Would be nice to have some way to grant/propagate incremental permissions. E.g. something that could be bundled into the propagation of the Endpoint discovery data itself.
  • Reported: DDS-SECURITY 1.1 — Sat, 18 Nov 2017 00:42 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Instance-Level access-control

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

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

    This is important for many DDS-Security use-cases where each instance represents a different object and needs to separately indicate who has access to it. For example imaging a "CarPosition" topic that is used to publish the position of cars. Someone may be given permission to suscribe or publish its own car position, but not other cars. Likewise a manufactured or insurance company may be given permissions to the cars that they manage but not others.
  • Reported: DDS-SECURITY 1.1 — Fri, 17 Nov 2017 02:07 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Instance-Level access-control

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

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

    This is important for many DDS-Security use-cases where each instance represents a different object and needs to separately indicate who has access to it. For example imaging a "CarPosition" topic that is used to publish the position of cars. Someone may be given permission to suscribe or publish its own car position, but not other cars. Likewise a manufactured or insurance company may be given permissions to the cars that they manage but not others.
  • Reported: DDS-SECURITY 1.1 — Fri, 17 Nov 2017 02:07 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

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

  • Key: DDSSEC12-11
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

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

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

    It should probably be

    "sending the ParticipantSecurityInfo (the default value of zero has is_valid=0) or sending it with is_valid set to zero.”
  • Reported: DDS-SECURITY 1.1b1 — Tue, 31 Oct 2017 20:03 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

DataHolder IDL inconsistent

  • Key: DDSSEC12-15
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In 7.2.3.1, DataHolder is a struct annotated with @extensibility(APPENDABLE) and no optional fields.
    However in ptc/17-09-26 (normative IDL), DataHolder has no @extensibility annotation and two optional fields.
  • Reported: DDS-SECURITY 1.1b1 — Thu, 4 Jan 2018 21:38 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

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

  • Key: DDSSEC13-10
  • Status: open  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

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

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

    It should probably be

    "sending the ParticipantSecurityInfo (the default value of zero has is_valid=0) or sending it with is_valid set to zero.”
  • Reported: DDS-SECURITY 1.1b1 — Tue, 31 Oct 2017 20:03 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Issues with the UML model used in the specification

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

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

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

    These issues should be corrected.
  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 07:07 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

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

  • Key: DDSSEC12-2
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

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

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

    In both cases, it would change the specs of the methods get_shared_secret() and return_shared_handle() of the Authentication plugin, section 9.3.3.
  • Reported: DDS-SECURITY 1.0b1 — Tue, 1 Mar 2016 17:36 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

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

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

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

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

    In both cases, it would change the specs of the methods get_shared_secret() and return_shared_handle() of the Authentication plugin, section 9.3.3.
  • Reported: DDS-SECURITY 1.0b1 — Tue, 1 Mar 2016 17:36 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Examples of Wildcard permissions

  • Key: DDSSEC12-4
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

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

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

    Such examples would be very useful in the spec as well.
  • Reported: DDS-SECURITY 1.0 — Tue, 11 Jul 2017 12:43 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT
  • Attachments:

Examples of Wildcard permissions

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

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

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

    Such examples would be very useful in the spec as well.
  • Reported: DDS-SECURITY 1.0 — Tue, 11 Jul 2017 12:43 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT
  • Attachments:

The UML model should be cleaned up

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

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

    ● SubmessageKind should be an Enumeration not a Class. And it’s missing its Literals. Tables 4,5 indicate Literals would include SEC_BODY, SEC_PREFIX, SEC_POSTFIX, SRTPS_PREFIX, SRTPS_POSTFIX
    ● SubmessageFlag is totally underspecified but probably should not be a PrimitiveType
    ● Likewise CryptoState. In fact there are far too many PrimitiveTypes, none of them documented, which should probably be Strings.
  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 17:53 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

The UML model should be cleaned up

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

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

    ● SubmessageKind should be an Enumeration not a Class. And it’s missing its Literals. Tables 4,5 indicate Literals would include SEC_BODY, SEC_PREFIX, SEC_POSTFIX, SRTPS_PREFIX, SRTPS_POSTFIX
    ● SubmessageFlag is totally underspecified but probably should not be a PrimitiveType
    ● Likewise CryptoState. In fact there are far too many PrimitiveTypes, none of them documented, which should probably be Strings.
  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 17:53 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Remove Jira-issue related comments from machine-readable files

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

    The machine-readable files have comments that trace their changes to the Jira issues that caused them. This hurts the use of the specification so they should be removed.
  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 10:24 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Remove Jira-issue related comments from machine-readable files

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

    The machine-readable files have comments that trace their changes to the Jira issues that caused them. This hurts the use of the specification so they should be removed.
  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 10:24 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

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

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

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

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

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

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

    7.4.1.3 Reserved RTPS parameter IDs
    This specification reserves the RTPS Simple Discovery Protocol ParameterIDs in the range:
    0x1000 to 0x1FFF and 0x5000 to 0x5FFF. The second interval covers the same range of parametersID, except they have the must-understand bit set. This reserved range applies to RTPS version 2.3 (see 7.3.6.1) and higher minor revisions of RTPS. Future revisions of the DDS-RTPS specification shall take into consideration this fact.
  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 09:48 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

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

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

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

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

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

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

    7.4.1.3 Reserved RTPS parameter IDs
    This specification reserves the RTPS Simple Discovery Protocol ParameterIDs in the range:
    0x1000 to 0x1FFF and 0x5000 to 0x5FFF. The second interval covers the same range of parametersID, except they have the must-understand bit set. This reserved range applies to RTPS version 2.3 (see 7.3.6.1) and higher minor revisions of RTPS. Future revisions of the DDS-RTPS specification shall take into consideration this fact.
  • Reported: DDS-SECURITY 1.0 — Mon, 25 Sep 2017 09:48 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Complexity of Authentication Plugin Model

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

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

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

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

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

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

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

    This will provide the necessary functionality in a much simple, efficient and robust manner.
  • Reported: DDS-SECURITY 1.0b1 — Thu, 11 Jun 2015 04:00 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Complexity of Authentication Plugin Model

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

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

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

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

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

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

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

    This will provide the necessary functionality in a much simple, efficient and robust manner.
  • Reported: DDS-SECURITY 1.0b1 — Thu, 11 Jun 2015 04:00 GMT
  • Updated: Fri, 21 Jun 2024 22:34 GMT

Meeting CNSSP-15 security requirements

  • Key: DDSSEC12-90
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Add support for additional crypto algorithms

    Reorganize specification separating the definition of the crypto algorithms from its use by the plugins, such that, it becomes possible to extend the algorithms used, specifically adding support for algorithms that meet CNSSP-15 top-secret requoirements.
  • Updated: Mon, 17 Jun 2024 13:36 GMT
  • Attachments:

Provide mechanism for changing the session keys associated with the different DDS Entitites

  • Key: DDSSEC12-122
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The builtin plugins create session keys for multiple DDS entities (DomainParticipant, DataWriter, DataReader) and share those with the matched Entities that successfully authenticate and have the proper authorization. The session key(s) are used to protect the messages sent by the entity using encryption and/or message-authentication codes.

    Importantly the same key (e.g. a DataWriter key) may be shared with multiple matched DataReaders.

    There are situations where an Entity may need to change is Session Key. E.g. if it has been used to encode too many messages, or if there is a need to "revoke" access for one or more existing matched Endpoints.

    The specification should provide and describe the mechanism that implementations may use to change session Keys such that they are able to interoperate across vendors.
  • Reported: DDS-SECURITY 1.1b1 — Wed, 25 Oct 2023 04:58 GMT
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Add a mechanism to change session keys

    Provide a mechanism to change session keys and send the modified keys to the authenticated authorized Participants
  • Updated: Mon, 17 Jun 2024 13:36 GMT
  • Attachments:

Add support for DomainTag to DDS-Security

  • Key: DDSSEC12-101
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    DomainTag was added to DDSI-RTPS as a mechanism to further identify/isolate DDS Domains beyond the separation provided by the DomainId. For two participants to be on the same domain both the DomainId and the DomainTag (a string) must match. The domain-tag string matching is literal (strcmp() character by character) there is no expressions.

    Resulting from this it makes sense to add support for them to DDS security, without this support there would be no way to have different governance or permissions for domains that differ only on the DomainTag.

    Adding support will impact the SPIs (e.g. extra parameters on validate_local_identity, validate_local_permissions, and most of thje check_operations. Operations that currently take the DomainId_t as a parameter should be expanded to also take a DomainTag.

    Adding support will impact Governance and Permissions files.
    E.g. the DomainIdSet should which is used on both files be expanded to incorporate domain tags.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 14 Mar 2023 19:48 GMT
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Add specification of domainTag to governance and permissions

    Extend governance and permissions documents to allow specifying the domain tags that identify the domain(s) to which the rules apply.
  • Updated: Mon, 17 Jun 2024 13:36 GMT
  • Attachments:

Specify DDS Security uses XCDR serialization version 1

  • Key: DDSSEC12-29
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Be precise about the XCDR version used for serialization

    Specify XCDR version f1 or serializing the data exchanged by DDS Security plugins.
  • Updated: Mon, 17 Jun 2024 13:36 GMT

secure log topic has a year 2038 issue

  • Key: DDSSEC12-108
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Topic uses the DDS::Time_t which rolls over at 2038.
    We should update to the newer definition to be adopted in DDS 1.6

    We may need to use a different type name to allow both to co-exist
    Curent definition is this:

    extensibility(APPENDABLE) // After DDSSEC12-29
struct BuiltinLoggingType {
    octet  facility;  // Set to 0x0A (10). Indicates sec/auth msgs
    LoggingLevel severity;
    Time_t timestamp; // Since epoch 1970-01-01 00:00:00 +0000 (UTC)
    string hostname;  // IP host name of originator
    string hostip;    // IP address of originator
    string appname;   // Identify the device or application 
    string procid;    // Process name/ID for syslog system
    string msgid;     // Identify the type of message
    string message;   // Free-form message

    // Note that certain string keys (SD-IDs) are reserved by IANA
    map<string, NameValuePairSeq>  structured_data; 
};
  • Reported: DDS-SECURITY 1.1b1 — Tue, 20 Jun 2023 22:49 GMT
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Modify BuiltinLoggingType to use 64 bits to hold the timestamp seconds

    Introduce a new Log topic that uses a 64-bit integer for the seconds.
    Since this is defined as an "application-level" topic discovery and type matching will take care of interoperability with earlier versions of the specification.

    Old topic name is deprecated but an implementation can support it for backwards compatibility.
  • Updated: Mon, 17 Jun 2024 13:36 GMT

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

  • Key: DDSSEC12-53
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. 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
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Change "bit array" to "octet array" and clarify string concatenation in 9.5.3.3.3

    Add clarification regarding how the strings are concatenated to create teh input to the HMAC256 functions
  • Updated: Mon, 17 Jun 2024 13:36 GMT

Corrections to tables describing IdentityStatusToken, AuthenticatedPeerCredentialToken, AuthRequestMessageToken

  • Key: DDSSEC12-110
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    IdentityStatusToken, AuthenticatedPeerCredentialToken, AuthRequestMessageToken are specified in Table 46, Table 47, Table 48 of the DDS Security 1.1 spec. as containing "properties".

    This is inconsistent with the description of HandshakeRequestMessageToken, HandshakeReplyMessageToken, and HandshakeFinalMessageToken. These specify binary_property.

    They should be consistent. In fact AuthRequestMessageToken specifies that the content of the property with key "future_challenge" should match what is sent in HandshakeRequestMessageToken "challenge1"

    It appears vendors are all using binary_properties as they are all interoperating. Therefore Table 46, Table 47, Table 48 should be modified to say "binary_property' for the attribute name.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 27 Jun 2023 23:10 GMT
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Modify attribute name in the tables for dentityStatusToken, AuthenticatedPeerCredentialToken, AuthRequestMessageToken

    Per the issue description, Attribute name "properties" in tables 46, 47, 48, defining IdentityStatusToken, AuthenticatedPeerCredentialToken, AuthRequestMessageToken should be modified to "binary_properties"
  • Updated: Mon, 17 Jun 2024 13:36 GMT

Security for XTypes TypeLookup Service

  • Key: DDSSEC12-86
  • Status: closed   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( Mr. 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
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Secure TypeLookup Built-In Endpoints

    Secure DDS deployments that make use of XTypes features including its TypeLookup Service must have a secure way of communicating TypeLookup information.
  • Updated: Mon, 17 Jun 2024 13:36 GMT

Encoding of Diffie-Hellman Public Key

  • Key: DDSSEC12-56
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. 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
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Explain the encoding of diffie-hellman keys in the handshake tokens

    Explain the encoding of public keys into octet sequences
  • Updated: Mon, 17 Jun 2024 13:36 GMT

Underspecified RSASSA-PSS-SHA256 Salt Length

  • Key: DDSSEC12-92
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.2
  • Disposition Summary:

    Specify how to configure the salt length for RSA digital signatures

    Merging with DDSSEC12-90 because the section referenced in the issue description ( 9.3.2.5.2) no longer describes algorithm-specific details, rather the crypto algorithms description are in a new dedicated section under section 8 "Common Cryptographic Algorithms" . So it is simpler to handle adding this detail to Issue 90.
  • Updated: Mon, 17 Jun 2024 13:36 GMT

Sectiob 8.2.1 Expand set of submessages that may be sent on TSN streams

  • Key: DDSSEC12-115
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 8.2.1 Message Module says:

    To provide a deterministic behavior and a deterministic message size, DataWriters associated with an TsnTalker in the Deployment configuration (see subclause 7.2.3.1) may need to limit their RTPS Message exchange to RTPS Messages that include the following RTPS Submessages:
    • InfoTimestamp
    • Data
    • DataFrag

    This should be expanded to include the RTPS HeaderExtension as well as GAP.

    Later in the section there is an explanation of why GAP may not be needed:

    RTPS Submessages responsible for achieving reliability or in-order delivery, such as Gap, AckNack, NackFrag; as well as the rest of Interpreter Submessages, may be sent as part of “Best Effort” Streams. However, given the guarantees of the underlying TSN system, this sort of traffic may be unnecessary for TSN-enabled DataReaders and DataWriters. Also, retransmissions and other types of aperiodic traffic may fail to meet the schedule and configuration of the TSN Streams associated with the delivery of time-critical data.

    However GAP is not just for reliability or in-order delivery. It is also used in best-efforts in situation where a sample is not relevant to a reader (e.g. because of writer-side content filtering), even if the sample is sent best-efforts.
    Gaps are needed to distinguish lost samples from samples that are intentionally-skipped. If the gap is not present, the reader side will interpret non sequential sequence numbers as sample loss, impacting status variables in in the DataReader.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 4 Jul 2023 23:48 GMT
  • Disposition: Closed; Out Of Scope — DDS-SECURITY 1.2
  • Disposition Summary:

    This issue was entered in the wrong RTF

    This issue was entered in the wrong RTF. Should have been entered in DDSTSN. Refiling there....
  • Updated: Mon, 17 Jun 2024 13:36 GMT

DDS-Security impact on DDS-TSN

  • Key: DDSSEC12-116
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not address whether DDS-Security can be deployed on top of TSN.
    The logical assumption would be yes, but then the use of the RTPS sub-messages introduced by DDS security (e.g. SRTPS_PREFIX) should be mentioned.

  • Reported: DDS-SECURITY 1.1b1 — Tue, 4 Jul 2023 23:51 GMT
  • Disposition: Closed; Out Of Scope — DDS-SECURITY 1.2
  • Disposition Summary:

    This issue was entered in the wrong RTF

    This issue was entered in the wrong RTF. Should have been entered in DDSTSN. Refiling there....
  • Updated: Mon, 17 Jun 2024 13:36 GMT

How are 'subject_name' fields compared?

  • Key: DDSSEC12-91
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. 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
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Specify format of subject name and rules for comparison

    The string format of the subject name should be specified. The proposal is to follow IETF RFC 4514 (https://datatracker.ietf.org/doc/html/rfc4514#section-3), that is a ","-separated sequence of <name>=<value> pairs. For example:

    "C=US, ST=CO, O=Twin Oaks, Computing, CN=*.twinoakscomputing.com/emailAddress=support@twinoakscomputing.com"

    The matching of subject names should check the list of names is the same and the corresponding values match using the fnmatch() function (POSIX 1003.2-1992, Section B.6)

    The order of the names does not impact the matching.

    Note that "," may be present in the value part. Likely we do not want to constrain this as it is generated from tools like openssl which may put those commas based on user input.
    However this can be unabiguously parsed making the following assumptions.

    • The character '=' is reserved. it can only appear to separate the name v. value pair.
    • Whitespace surrounding the "=" is ignored/removed for the purposes of comparison
    • The name can;t have whitespace. and can;' have ","
    • The value starts after the '=' skipping any whistapce that immediately follows the '=' abd ectends to the last "," before the next "="
  • Updated: Mon, 17 Jun 2024 13:36 GMT

Indicate that AccessControl operations need to be called on a set_qos

  • Key: DDSSEC12-62
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Indicate that AccessControl operations called on a change of Qos

    When the Qos of a local DDS Entity changes the corresponding operation on the Access Control that checks thet the Participant has the necessary permissions should be called.

    When the Qos of a remote DDS Entity changes the corresponding operation on the Access Control that checks that the remote Participant has the necessary permissions should be called.
  • Updated: Mon, 17 Jun 2024 13:36 GMT

Built-in Access Control: interpretation of enable_read/write_access_control

  • Key: DDSSEC12-79
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. 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
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Clarify interpretation of enable_read/write_access_control

    Clarify behavior as suggested in issue description
  • Updated: Mon, 17 Jun 2024 13:36 GMT

Mutability of PartitionQos

  • Key: DDSSEC12-49
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    *Change wording in 7.3.5 item (1) *

    Modify wording in 7.3.5 "Immutability of Publisher Partition Qos in combination with non-volatile Durability kind" item (1)
    to state that this applies if the the Topic has "is_read_protected" set to true.
  • Updated: Mon, 17 Jun 2024 13:36 GMT

Using string literals as binary_property values inside Handshake Tokens

  • Key: DDSSEC12-55
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. 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
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.2
  • Disposition Summary:

    Merge with DDSSEC12-90

    DDSSEC12-90 is already making similar clarifications and adds the following explanation to 7.3.3.1:

    When setting the BinaryProperty_t value octet sequence from an ASCII string, the length of the sequence shall be set to the number of characters in the string, counting the NUL terminating character, and each octet in the sequene shall be set to the ASCII value of the corresponding character in the string, including the NUL terminating character.
    For example, if an object the string “ECDSA-SHA256” shall result in an octet sequence value with length 13 where the first octet is 0x45 (ASCII code for ‘E’) and the last octet is 0x00.

    So we can mark this issue as duplicate of DDSSEC12-90
  • Updated: Mon, 17 Jun 2024 13:36 GMT

Errors in non-normative IDL of section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types

  • Key: DDSSEC12-75
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types cotntains the following IDL:

    @Choice @Autoid
struct RobotControl_command_Result { 
    RobotControl_command_Out result;
};@Choice @Autoid
struct RobotControl_stop_Result { 
    RobotControl_getSpeed_Out result;
};
};@Choice @Autoid
struct RobotControl_setSpeed_Result {
      RobotControl_setSpeed_Out result;
      TooFast toofast_ex;
};
};@Choice @Autoid
struct RobotControl_getSpeed_Result {
      RobotControl_getStatus_Out result;
};

    This IDL is not correct. It contains extra "};" preceding the @Choice annotations in several places. The correct IDL would be:

    @Choice @Autoid
struct RobotControl_command_Result { 
    RobotControl_command_Out result;
};

@Choice @Autoid
struct RobotControl_stop_Result { 
    RobotControl_getSpeed_Out result;
};

@Choice @Autoid
struct RobotControl_setSpeed_Result {
      RobotControl_setSpeed_Out result;
      TooFast toofast_ex;
};

@Choice @Autoid
struct RobotControl_getSpeed_Result {
      RobotControl_getStatus_Out result;
};
  • Reported: DDS-SECURITY 1.1b1 — Wed, 29 Aug 2018 00:41 GMT
  • Disposition: Closed; Out Of Scope — DDS-SECURITY 1.2
  • Disposition Summary:

    This was entered in the wrong RTF

    This issue was filed in the wrong RTF. It should have been filed on RPC over DDS 1.1 RTF. It has already been entered there. See https://issues.omg.org/browse/DDSRPC11-2.
  • Updated: Mon, 17 Jun 2024 13:36 GMT

check_remote_participant when default is ALLOW

  • Key: DDSSEC12-85
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. 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
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.2
  • Disposition Summary:

    Merge with DDSSEC12-79

    This issue impacts the same table/rules as https://issues.omg.org/browse/DDSSEC12-79

    we propose to handle them toguether.
  • Updated: Mon, 17 Jun 2024 13:36 GMT

Define rules for references between elements

  • Key: DDSSEC12-16
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The syntax in DDS-XML containes places where an object references another object. This is done normally using an attribute with type elementNameReference defined in http://www.omg.org/spec/DDS-XML/20170301/dds-xml_domain_definitions_nonamespace.xsd

    However the specification does not deny any rules/constraints on the references themselves. In fact those references must follow a precise syntax to uniquely select an element which require a full path down the containment hierarchy down to the selected element.

    The specification should define this and provide some examples.
  • Reported: DDS-SECURITY 1.1 — Sat, 6 Jan 2018 23:52 GMT
  • Disposition: Closed; Out Of Scope — DDS-SECURITY 1.2
  • Disposition Summary:

    This issue was entered here in error. It was an issue for a different FTF

    This issue should have been filed for http://issues.omg.org/browse/DDSXML

    Therefore it should be closed here (and filed in the other FTF).
  • Updated: Mon, 17 Jun 2024 13:36 GMT

CryptoTransformIdentifier extensibility FINAL is not compatibly with its derived classes

  • Key: DDSSEC12-14
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.2
  • Disposition Summary:

    Change CryptoHeader definition in 7.3.7.3. to final

    In section 7.3.7.3 "Mapping of the CryptoHeader SubmessageElement"
    modify the extensibility of CryptoHeader from "APPENDABLE" to "FINAL" resulting in the following IDL:

    @extensibility(FINAL)
struct CryptoHeader : CryptoTransformIdentifier  {
    // Extra plugin-specific information added below
    // PluginHeader   plugin_crypto_header_extra;
};
  • Updated: Mon, 17 Jun 2024 13:36 GMT

Provide mechanisms to extend Governance and Permissions files without breaking interoperability

  • Key: DDSSEC12-3
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Add mechanism to extend Governance and Permissions document

    Define how the Governance and Permission documents could be extended and the rules to apply when processing the document and encountering an extension.
  • Updated: Mon, 17 Jun 2024 13:36 GMT
  • Attachments:

writing error

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

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

    Two PROTOCOLVERSION_2_2 appeared
    I think it should be PROTOCOLVERSION_2_3
  • Reported: DDSI-RTPS 2.5 — Thu, 18 Apr 2024 10:36 GMT
  • Updated: Mon, 22 Apr 2024 15:53 GMT

Clarify the intended member ID of a union's discriminator

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

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

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

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

    In Kongsberg's implementation, we've been using 0 for the discriminant. The first member of the union has thus had the member ID 1 (assuming @autoid(SEQUENTIAL)).
  • Reported: DDS-XTypes 1.3b1 — Thu, 21 Mar 2024 03:51 GMT
  • Updated: Sat, 23 Mar 2024 14:23 GMT

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

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

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

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

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

Clarify the intended member ID of a union's discriminator

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

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

    In Kongsberg's implementation, we've been using 0 for the discriminant. The first member of the union has thus had the member ID 1 (assuming @autoid(SEQUENTIAL)).
  • Reported: DDS-XTypes 1.3 — Sun, 17 Mar 2024 17:45 GMT
  • Updated: Thu, 21 Mar 2024 03:43 GMT

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

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

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

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

    If nothing is done the URLs on the cover of the report (ptc/15-09-21) take precedence over the ones in the FTF2 specification, so it is imperative to re-issue the report to correct this.
  • Reported: DDS-WEB 1.0 — Thu, 19 May 2016 00:40 GMT
  • Updated: Wed, 3 Jan 2024 20:38 GMT

XCDR2 serialization of sequences of non-primitive elements

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

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

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

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

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

    Basically the "extensibility" of the sequence is already handled by having the number of elements and having a DHEADER adds nothing and makes types that contain sequences of FINAL incompatible with XCDR1. This is a side-effect that we did not want or anticipate. Otherwise types that are constructed from only FINAL types would be compatible between XCDR1 and XCDR2 (except for 8-byte aligned types).
  • Reported: DDS-XTypes 1.3b1 — Wed, 4 May 2022 22:43 GMT
  • Updated: Fri, 15 Dec 2023 19:15 GMT

XCDR2 serialization of non-trivial maps

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

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

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

    It seems to me that some of the other DDS implementations include the size, even though the specification does not say so.
  • Reported: DDS-XTypes 1.3b1 — Tue, 5 Dec 2023 16:36 GMT
  • Updated: Wed, 6 Dec 2023 16:06 GMT

DDS::Time_t/Duration_t changes

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

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

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

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

    { sec = 0, nanosec = 0 }

    This is required in order to convert a Time_t to/from a system's native time (such the the type time_t on Unix systems which has the calendar start time 1970-01-01 00:00:00).
  • Reported: DDS 1.2 — Thu, 30 Jul 2009 04:00 GMT
  • Updated: Fri, 24 Nov 2023 07:59 GMT

Proper interpretation of Duration_t for negative values

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

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

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

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

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

    value = sec + nanosec

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

    sec = -1
nanosec = 999,000,000

    The specification should define the proper interpretation.
  • Reported: DDS 1.4 — Mon, 20 Nov 2023 21:13 GMT
  • Updated: Mon, 20 Nov 2023 21:13 GMT

Section contains a duplicate sentence from the next section.

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

    Sections are:

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

    "Structures as defined by..." is duplicated twice.
  • Reported: DDS-XTypes 1.3 — Fri, 1 Sep 2023 20:42 GMT
  • Updated: Fri, 8 Sep 2023 22:26 GMT

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

  • Key: DDSXTY13-85
  • Status: open  
  • Source: Foxglove Technologies Inc ( Sam Nosenzo)
  • Summary:

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

How to describe the locator information in XML

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

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

Extend InfoSource to contain RTPS HeaderExtension fields

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

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

    The RTPS Header Extension submessage was added to extend the RTPS Header in a way that did not break interoperability with existing systems. So logically the information inside RTPS Header Extension belongs in the RTPS Header. Therefore it should also be added to the InfoSource
  • Reported: DDSI-RTPS 2.5 — Wed, 16 Aug 2023 23:00 GMT
  • Updated: Thu, 17 Aug 2023 04:06 GMT

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

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

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

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

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

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

    It would seem that (1) is cleaner but (2) is less disruptive...
  • Reported: DDS-XTypes 1.3b1 — Sat, 12 Aug 2023 02:20 GMT
  • Updated: Wed, 16 Aug 2023 15:56 GMT

Clarify accessing discriminator of a DynamicData union

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

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

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

    It would be better for the spec to have a clearly defined way of getting a MemberId that represents the discriminator. It could be a new API in DynamicType or TypeDescriptor.
  • Reported: DDS-XTypes 1.3 — Mon, 8 Aug 2022 15:38 GMT
  • Updated: Mon, 14 Aug 2023 15:28 GMT

Specify how a discovery service could be used to bootstap discovery

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

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

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

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

Data Representation for RTPS's Serialized Key

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

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

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

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

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

    b. use the rules in 7.6.8 (which are explicitly only for a KeyHash) to get a KeyHolder object and then encode that
  • Reported: DDS-XTypes 1.3 — Wed, 28 Oct 2020 19:43 GMT
  • Updated: Wed, 31 May 2023 09:23 GMT

SequenceNumberSet validity could be too strict

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

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

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

    The RTF should determine if this condition in 9.4.2.6 can just be removed.
  • Reported: DDSI-RTPS 2.3 — Mon, 7 Jun 2021 22:55 GMT
  • Updated: Tue, 30 May 2023 22:53 GMT

Typos in DynamicData UML Diagrams

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

    Both figures have get_member_id_by_index methods instead of get_member_id_at_index like the rest of the spec does.
  • Reported: DDS-XTypes 1.3 — Thu, 16 Mar 2023 05:38 GMT
  • Updated: Mon, 24 Apr 2023 18:25 GMT

Conflicting Order of Minimal Struct and Union Members in TypeObject

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

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

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

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

    // Ordered by common.member_id
    typedef sequence<MinimalStructMember> MinimalStructMemberSeq;
    ...
    // Ordered by MinimalUnionMember.common.member_id
    typedef sequence<MinimalUnionMember> MinimalUnionMemberSeq;
  • Reported: DDS-XTypes 1.3 — Wed, 29 Mar 2023 22:13 GMT
  • Updated: Wed, 5 Apr 2023 22:44 GMT

Should the TypeObject mark key members as must understand

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

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

    Either way it should not impact assignability but it would impact the TypeId computation.
  • Reported: DDS-XTypes 1.3b1 — Tue, 21 Mar 2023 15:27 GMT
  • Updated: Thu, 30 Mar 2023 18:23 GMT

Typo in DataRepresentationMask

  • Key: DDSXTY14-65
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Typo, it says

    @posiiton(2) XCDR2

    but should say

    @position(2) XCDR2
  • Reported: DDS-XTypes 1.3 — Thu, 25 Mar 2021 07:54 GMT
  • Updated: Thu, 30 Mar 2023 18:21 GMT

DynamicData should be value type, not a reference type

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

    The class DynamicData inherits from Reference, but this class shouldn't behave differently from any other topic-type T, which (including the built-in types) are always value types.
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 13 Jul 2016 22:18 GMT
  • Updated: Wed, 29 Mar 2023 18:29 GMT

Encoding of TypeInformation in SEDP

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

    The encoding of the TypeInformation member in the builtin topics should be explicitly specified. There is a normative comment on using XCDR2 for v1.3 types in the IDL, but this can be interpreted not to apply in the context of the builtin topics which are otherwise XCDR1.
  • Reported: DDS-XTypes 1.3 — Thu, 17 Jun 2021 13:04 GMT
  • Updated: Tue, 21 Mar 2023 15:39 GMT

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

  • Key: DDSXTY14-53
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

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

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

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

    The dds::rpc::RequestHeader in the TypeLookup_Request and the TypeLookup_Reply shall be set as specified in the [DDS-RPC] specification.
  • Reported: DDS-XTypes 1.3b1 — Mon, 20 Dec 2021 16:09 GMT
  • Updated: Tue, 21 Mar 2023 15:36 GMT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    So the basic question boils down to this:

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

bitset types not defined

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

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

    The text after Figure 16 and the rest of the spec doesn't define how bitset works in the type system (assignability), type representation, and data representation.
  • Reported: DDS-XTypes 1.3b1 — Mon, 20 Mar 2023 19:15 GMT
  • Updated: Tue, 21 Mar 2023 14:39 GMT

Minor Typo in SubmessageKind IDL

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

    IDL value annotation for GAP is @value(8x08) instead of @value(0x08).
  • Reported: DDSI-RTPS 2.5 — Fri, 3 Mar 2023 11:13 GMT
  • Updated: Fri, 17 Mar 2023 15:03 GMT

DynamicTypeSupport IDL defnition is invalid IDL

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

    DynamicTypeSupport has the following IDL definition in Annex C:

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

    This definition can't be used in an XTypes implementation, at least in one using standard IDL. register_type and get_type_name can't use those names because a derived interface can't define operations that share names with ones in its base interfaces. This is described at the end of 7.4.3.4.3.2.1 in IDL 4.2. Another issue is the "static" operations. They get the point across as to what the author means but, they are also not usable as IDL can't define operations as static. DynamicTypeBuilderFactory and DynamicDataFactory also do this.
  • Reported: DDS-XTypes 1.3 — Fri, 28 Oct 2022 17:45 GMT
  • Updated: Thu, 8 Dec 2022 16:29 GMT

DataFrag submessage element naming

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

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

    Section 9.4.5.5 must map all elements of the submessage to the PSM types. However, it is lacking a dataSize. Instead it includes a sampleSize. SampleSize should be renamed dataSize and perhaps should use a well-defined type from 9.3.2 such as MessageLength_t.
  • Reported: DDSI-RTPS 2.5 — Tue, 15 Nov 2022 22:36 GMT
  • Updated: Tue, 15 Nov 2022 22:36 GMT

Version number is inconsistent

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

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

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

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

    In Section 9.3.2.1:
    Remove the IDL comment 

    // The implementations following this version of the document
// implement protocol version 2.4
  • Reported: DDSI-RTPS 2.5 — Tue, 15 Nov 2022 22:25 GMT
  • Updated: Tue, 15 Nov 2022 22:25 GMT

Inconsistent notation used to represent bit positions pictorially

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

    The spec uses two numbering schemes for bits:

    For example 9.4.1 (Overall Structure)

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

    But then in 9.4.4 (Mapping of the RTPS Header)

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

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

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

    With this scheme the number represents the number of bits that appear before the number (the "." positions). The other scheme seems inconsistent. "0" is placed ahead of the bit of that order, but '7' and the rest are placed after.
  • Reported: DDSI-RTPS 2.5 — Thu, 10 Jun 2021 22:20 GMT
  • Updated: Tue, 15 Nov 2022 22:10 GMT

Table 9 is missing BITMASK_TYPE

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

    Add BITMASK_TYPE to table 9
  • Reported: DDS-XTypes 1.3 — Tue, 15 Nov 2022 22:08 GMT
  • Updated: Tue, 15 Nov 2022 22:08 GMT

Typo in 9.4.5.7.1 Flags in the Submessage Header

  • Key: DDSIRTP26-33
  • Status: open  
  • Source: Georgia Institute of Technology ( Seulbae Kim)
  • Summary:

    LivelinessFlag in the last paragraph should be GroupInfoFlag, i.e.,
    "The GroupInfoFlag is represented with the literal ‘G’. G=1 means the HeartBeat includes the currentGSN,
    firstGSN, and lastGSN. The value of the LivelinessFlag can be obtained from the expression:"
    should be changed to
    "The GroupInfoFlag is represented with the literal ‘G’. G=1 means the HeartBeat includes the currentGSN,
    firstGSN, and lastGSN. The value of the GroupInfoFlag can be obtained from the expression:"
  • Reported: DDSI-RTPS 2.5 — Wed, 5 Oct 2022 02:55 GMT
  • Updated: Wed, 5 Oct 2022 15:14 GMT

set_listener behavior is underspecified

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

    Suppose the DATA_AVAILABLE StatusChangedFlag (see Figure 2.16) is set on a DataReader and then a listener (with DATA_AVAILABLE_STATUS in its mask) is attached to the DataReader by the user calling set_listener(). The specification does not specify if the listener should be invoked. If the decision is that the listener is not invoked, then guidance should be given to users that they may need to invoke the listener manually.
  • Reported: DDS 1.4 — Fri, 30 Sep 2022 18:21 GMT
  • Updated: Fri, 30 Sep 2022 18:21 GMT

Network amplification

  • Key: DDSIRTP26-6
  • Status: open  
  • Source: Trend Micro Inc. ( Federico Maggi)
  • Summary:

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

IDL's fixed data type is required in XTypes

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

    Since "Core Data Types (Sub Clause 7.4.1 [IDL])" is included in the XTypes type system model, it needs to include "fixed"
  • Reported: DDS-XTypes 1.3 — Tue, 28 Jul 2020 19:40 GMT
  • Updated: Wed, 21 Sep 2022 20:22 GMT

Representing union case labels in TypeObject

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

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

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

    Both IDL 4.2 and the general type system in XTypes (Figure 18, 7.2.2.4.4.3) allow 64-bit integer types as discriminators and therefore 64-bit values as case labels.
  • Reported: DDS-XTypes 1.3 — Tue, 29 Sep 2020 17:46 GMT
  • Updated: Wed, 21 Sep 2022 19:00 GMT

Anonymous Types in Strongly Connected Components

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

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

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

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

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

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

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

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

    Step 4(b)ii of the algorithm in 7.3.4.9.2 requires that all of the types in an SCC have a TypeObject 4(b)ii.
    Possible Solutions and Notes:
    The algorithm implies that all of the types involved in a Strongly Connected Component have a type identifier of TI_STRONGLY_CONNECTED_COMPONENT. The precludes the use of the Plain Collections in Strongly Connected Components. Thus, if the algorithm of 7.3.4.9.2 is not revised, then the definition of Plain Collections needs to be revised to exclude those involved in a Strongly-Connected Component.
  • Reported: DDS-XTypes 1.3 — Wed, 2 Sep 2020 16:25 GMT
  • Updated: Wed, 21 Sep 2022 18:45 GMT

Inconsistency in the wire representation of SequenceNumber type fields

  • Key: DDSIRTP26-31
  • 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)

  • Key: DDSIRTP26-32
  • 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

  • Key: DDSIRTP26-30
  • 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

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

    Enum and bitmask can have extensibility

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

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

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

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

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

Annex C: BoundSeq IDL type not defined

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

    The IDL defined in Annex C uses the type BoundSeq as a member of TypeDescriptor, but BoundSeq is not defined in the spec.
  • Reported: DDS-XTypes 1.3 — Tue, 26 Jul 2022 18:01 GMT
  • Updated: Thu, 28 Jul 2022 14:27 GMT

Align with XTYPES 1.3 and IDL 4.2

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

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

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

InstanceHandle_t underspecified

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

    In 2.2.2.1.1.8 the Instance handle is mentioned by the spec lacks some definition of InstanceHandle_t. In how far as instance handles unique and should they be comparable? Are they unique system wide or process wide? Is it legal to have two DDS entities (for example two domain participants) to have the same instance handle? This is important for users who for example store DDS entities in a std::map.
  • Reported: DDS 1.4 — Mon, 16 Nov 2020 07:30 GMT
  • Updated: Wed, 25 May 2022 23:42 GMT

Wrong data type for serializedPayload in DATAFRAG

  • Key: DDSIRTP26-29
  • Status: open  
  • Source: Atostek Oy ( Juhana Helovuo)
  • Summary:

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

    A similar problem exists in Section 9.4.5.5 DataFrag Submessage.

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

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

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

    Please clarify the relationship between the aforementioned terms.
  • Reported: DDSI-RTPS 2.5 — Tue, 17 May 2022 12:33 GMT
  • Updated: Thu, 19 May 2022 16:02 GMT

Annex A: Ownership Profile is unclear

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

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

Introduce a concept of Partitions at the DomainParticipant level

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

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

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

    While the same could be implemented by adding the the partitions to all Readers and Writers in the Participant the process would be tedious and far less efficient. For example with Participant partitions it would be possible for Participants that do not have a matching partition to avoid doing EndpointDiscovery.
  • Reported: DDSI-RTPS 2.5 — Wed, 16 Mar 2022 23:49 GMT
  • Updated: Wed, 16 Mar 2022 23:49 GMT

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

  • Key: DDSIRTP26-27
  • 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

  • Key: DDSIRTP26-26
  • 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

  • Key: DDSIRTP26-25
  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the version 2.3 specs, a gap is inserted in case a cache change isn't available in the history cache. In the 2.5 specs, only the highest previously sent sequence number is taken into account to determine if agap should be inserted.
    The shown logical actions will fail if the cache change with a_change_seq_num can't be located in the cache. in which case a gap should be inserted as well as in the 2.3 specs. Considering the explanation given for sending a gap because of the HISTORY QoS set to KEEP_LAST in the last paragraph on page 82, one should definitely consider the situation that a cache change is missing.
  • Reported: DDSI-RTPS 2.5 — Mon, 28 Feb 2022 08:47 GMT
  • Updated: Wed, 2 Mar 2022 21:42 GMT

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

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

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

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

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

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

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

    Those are useful to imply what the behavior is, but I think the standard should probably take stance on the valid values for depth, and I think values >= 1 makes sense, though the "100 million" upper bound set by RTI's API seems kind of arbitrary, though I don't have a better alternative in mind.
  • Reported: DDS 1.4 — Thu, 24 Feb 2022 02:30 GMT
  • Updated: Wed, 2 Mar 2022 21:42 GMT

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

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

    This specification lacks the XSD type definitions for the QoS extensions coming from DDSXTypes (at least DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy), these should be added to the DDS XML consolidated XML
  • Reported: DDS-XML 1.0 — Wed, 9 Feb 2022 15:05 GMT
  • Updated: Wed, 9 Feb 2022 17:10 GMT

Inconsistent use of higuest_sent_seq_num and highestSentChangeSN

  • Key: DDSIRTP26-24
  • 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

  • Key: DDSIRTP26-23
  • 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

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

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

    This is complementary to transport-level compression and has the advanatage that the data is only compressed once (at serialization, instead of every time it is sent) as well as reducing memory requirements.
  • Reported: DDS-XTypes 1.3b1 — Tue, 1 Feb 2022 19:08 GMT
  • Updated: Tue, 1 Feb 2022 19:08 GMT

Fields writerSet and secureWriterSet are missing in wire representation:

  • Key: DDSIRTP26-17
  • 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

  • Key: DDSIRTP26-16
  • 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

  • Key: DDSIRTP26-14
  • 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

  • Key: DDSIRTP26-13
  • 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

  • Key: DDSIRTP26-11
  • 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

  • Key: DDSIRTP26-10
  • 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

  • Key: DDSIRTP26-12
  • 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

  • Key: DDSIRTP26-15
  • 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

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

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

    It seems like the second “by” should be removed.
  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 14:13 GMT
  • Updated: Fri, 21 Jan 2022 06:58 GMT

Default value and @default annotations

  • Key: DDSXTY14-44
  • 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

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

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

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

    When a value of this union has discriminator FALSE, there is no selected case.
  • Reported: DDS-JSON 1.0 — Tue, 18 Jan 2022 21:18 GMT
  • Updated: Tue, 18 Jan 2022 21:18 GMT

Unclear how to discover GROUP_GUID/GROUP_ENTITY_ID from a coherent Publisher

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

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

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

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

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

    However, it is not clear from the spec how this GROUP_GUID or this GROUP_ENTITY_ID is communicated from the publishing side to the subscribing side. The spec introduces a separate PID for both the GROUP_GUID and and the GROUP_ENTITY_ID, but nowhere does it say which one to send out from the Publisher side, or to which message to attach this information. This information is necessary however in order to build an interoperable group coherent implementation.
  • Reported: DDSI-RTPS 2.5 — Wed, 12 Jan 2022 16:02 GMT
  • Updated: Wed, 12 Jan 2022 16:02 GMT

Incorporate the lookup_topicdescription change added in XTYPES 1.3

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

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

    This change should be consolidated into the DDS specification.
  • Reported: DDS 1.4 — Tue, 4 Jan 2022 21:09 GMT
  • Updated: Tue, 4 Jan 2022 21:09 GMT

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

  • Key: DDSPSMC11_-96
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

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

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

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

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

    Last but not least, some implementations are already supporting the | operator where others don't, so we might as well want to standardize is to keep application code portable across vendors.
  • Reported: DDS-PSM-Cxx 1.0 — Mon, 20 Dec 2021 21:02 GMT
  • Updated: Mon, 20 Dec 2021 21:02 GMT

Clarify the PartitionQosPolicy

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

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

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

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

    2.2.3 QosPolicy Table

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

    2.2.3.13 Partitions

    For a DataReader to see the changes made to an instance by a DataWriter, not only the Topic must match, but also they must
    share a common partition. Each string in the list that defines this QoS policy defines a partition name. A partition name may
    contain wildcards. Sharing a common partition means that one of the partition names matches.
    Failure to match partitions is not considered an “incompatible” QoS and does not trigger any listeners nor conditions.
  • Reported: DDS 1.4 — Wed, 7 Nov 2018 11:03 GMT
  • Updated: Tue, 16 Nov 2021 20:21 GMT

Provide a pre-shared key protection mechanism

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

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

    This issue should be addressed by DDS-Security. Likely using some pre-shared key mechanics to protect all messages not otherwise protected. For example, the authentication handshakes.
  • Reported: DDSI-RTPS 2.5 — Fri, 12 Nov 2021 16:24 GMT
  • Updated: Fri, 12 Nov 2021 16:24 GMT

Missing TK_INT8 and TK_UINT8 in the IDL machine readable file

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

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

    In addition, the comment:

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

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

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

Extensibility of inherited structures

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

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

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

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

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

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

Inconsistent Definitions of RTPS Encapsulation

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

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

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

    The other issue is that while 7.6.3.1.2 describes the two options bytes of the encapsulation header that follow the encoding identifier and extends it for padding info, 7.4.3. is lacking in details as far as I can see. The serialization rules has them in 7.4.3.5.3 as `OPTIONS`, but doesn't define it in any of the tables before the rules like all the other symbols are. It does mention encapsulation in 7.4.3.5, but doesn't mention anything about extending the options bytes.
  • Reported: DDS-XTypes 1.3b1 — Thu, 4 Jun 2020 17:51 GMT
  • Updated: Sat, 2 Oct 2021 00:10 GMT

Integrate annotations for range/min/max with try_construct

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

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

    It would seem like the try_construct behavior could be applied to range/min/max when the publisher and subscriber have different but compatible annotations.
  • Reported: DDS-XTypes 1.3b1 — Thu, 30 Sep 2021 14:45 GMT
  • Updated: Thu, 30 Sep 2021 14:45 GMT

Remove all IDL42 specified parts

  • Key: DDSXTY14-49
  • 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

  • Key: DDSXTY14-48
  • 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

Change the CRC-64 polynomial introduced in issue DDSIRTP25-12

  • Key: DDSIRTP25-34
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

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

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

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

    Moreover specifying the polynomial coefficients is not enough to fully specify the checksum. Instead there are additional rules about padding etc. For this reason the specification should be amended to include all the additional information.
  • Reported: DDSI-RTPS 2.3b1 — Tue, 9 Feb 2021 13:38 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

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

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

    Expand the description of the CRC-32 and CRC-64 algorithms to define all the parameters needed to uniquely compute and validate the checksum, including the polynomial coefficients, whether the input data and output data are reflected, the initial value and the final XOR value.
  • Updated: Tue, 29 Jun 2021 12:54 GMT

Unclear specification on how the Publisher GUID is communicated

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

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

    Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

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

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

    Minimally we should say that:

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

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

    The WriterProxy::remoteGroupEntityId should contain the Publisher GUID
  • Reported: DDSI-RTPS 2.3b1 — Sat, 2 Mar 2019 19:57 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.5
  • Disposition Summary:

    Duplicates DDSIRTP25-3

    Duplicates DDSIRTP25-3
  • Updated: Tue, 29 Jun 2021 12:54 GMT

Incomplete specification of how a Publisher and Subscriber are identified

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

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

    Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

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

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

    Minimally we should say that:

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

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

    The WriterProxy::remoteGroupEntityId should contain the Publisher GUID
  • Reported: DDSI-RTPS 2.3b1 — Sat, 2 Mar 2019 19:56 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add information on the identification of Publisher and Subscriber

    Indicate that the Publisher and Subscriber are identified by a GUID and that the GUID is propagated via the Publication and Subscription builtin Topic data.
  • Updated: Tue, 29 Jun 2021 12:54 GMT
  • Attachments:

Discriminating the reasons for a GAP

  • Key: DDSIRTP25-2
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

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

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

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

    The RTF should address this issue and provide the means to discriminate these cases. A possible approach would be include the information in the flags of the GAP message.
  • Reported: DDSI-RTPS 2.3b1 — Thu, 28 Feb 2019 02:41 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

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

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

    • Non-relevant Samples
    • Relevant Samples
    • Unclassified Samples

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

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

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

    The updated GAP message would should like this:

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

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

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

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

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

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

    In other words, any samples that appear as part of the GAP but are not covered by the relevant count and the irrelevant count.
  • Updated: Tue, 29 Jun 2021 12:54 GMT
  • Attachments:

Address deferred issue: Inclusion of Message Size & CRC as part of DDSI/RTPS Messages

  • Key: DDSIRTP25-12
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

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

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

    • messageLength

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

    Mechanisms to add additional information in future revisions.

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

    The DDS Security specification will leave this RTPSHeaderExtension following the RTPS Header and before the SecureRTPSPrefixSubMsg. The length will be updated to the new length after processing by the security plugins.
  • Reported: DDSI-RTPS 2.3b1 — Fri, 20 Mar 2020 20:07 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add CRC support via a HeaderExtension submessage

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

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

    The RTPSHeaderExtension submessage, if present, shall follow immediately after the RTPS Header.
  • Updated: Tue, 29 Jun 2021 12:54 GMT
  • Attachments:

Editorial corrections

  • Key: DDSIRTP25-17
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    7.6 enumerated list 5th bullet

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

    -> messages



    8.2.4

    Table 8.6 - RTPS Entity Attribues

    -> Attributes



    8.2.6

    Table 8.9 - RTPS Endpoint configuration attribues

    -> attributes



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

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

    -> data-object



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

    Indicates the protocol used for subsequent Sudmessages.

    -> Submessages



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

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

    -> accommodate



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



    8.6.2 enumerated list 3rd bullet

    * The meaning of submessageIds cannot be modfied.

    -> modified



    8.7.2.2.4 1st sentence

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

    -> bandwidth



    8.7.4 4th para 1st sentence

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

    -> Submessage



    8.7.4 6th para numbered list

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

    -> InstanceState



    8.7.9 3rd para

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

    -> supports



    9.1 enumerated list 4th bullet

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

    -> operating system



    9.3.1.2 Mapping of the EntityId_t

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

    -->

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



    9.4.5.7.1 Flags in the Submessage Header

    Reference to (8.3.6.2).

    -> 8.3.8.6.2



    9.4.5.15.1

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

    -> multicastLocator



    9.6.2.3 1st sentence

    The port number expresssions use the following parameters:

    -> expressions



    9.6.4.9, 7th para

    The DisposeedFlag is represented with the literal 'D.'

    -> DisposedFlag
  • Reported: DDSI-RTPS 2.3 — Tue, 21 Apr 2020 08:05 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Apply the typo corrections specified in the issue description

    Perform the suggested corrections.
  • Updated: Tue, 29 Jun 2021 12:54 GMT

Revise list of Submessages EntityIDs and PIDs reserved for other specifications

  • Key: DDSIRTP25-25
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

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

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

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

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

    Maybe this needs ti be more explicit and get its own section.
  • Reported: DDSI-RTPS 2.3b1 — Wed, 24 Jun 2020 19:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

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

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

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

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

    Create new subsection before 9.6.5 'ParameterIds Deprecated by the Protocol' to define parameter IDs reserved by other specifications.
  • Updated: Tue, 29 Jun 2021 12:54 GMT

Apply modifications to Clause 9.6.3.8, “KeyHash (PID_KEY_HASH)" from XTYPES

  • Key: DDSIRTP25-28
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    XTYPE 1.3, section 7.6.8 "Interoperability of Keyed Topics" provided amended text for Clause 9.6.3.8 in the RTPS spec. This text should be applied to the RTPS spec.
  • Reported: DDSI-RTPS 2.3b1 — Tue, 8 Dec 2020 15:52 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Replace the text in 9.6.4.8 'KeyHash (PID_KEY_HASH)'

    Replace the text in 9.6.4.8 KeyHash (PID_KEY_HASH) with the one provides in DDS-XTYPES 1.3, section 7.6.8 "Interoperability of Keyed Topics" p
  • Updated: Tue, 29 Jun 2021 12:54 GMT

Flag GroupInfoFlag and fields gapStartGSN and gapEndGSN unspecified in PSM

  • Key: DDSIRTP25-9
  • Status: closed  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the message module, the submessage gap defines the flag GroupInfoFlag and the fields gapStartGSN and gapEndGSN. However, in the PSM, both this flag and the two fileds are not specified further.
  • Reported: DDSI-RTPS 2.3 — Fri, 7 Feb 2020 12:28 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.5
  • Disposition Summary:

    Duplicates DDSIRTP25-7

    Merged with DDSIRTP25-7
  • Updated: Tue, 29 Jun 2021 12:54 GMT

SEQUENCENUMBER_UNKNOWN missing from PSM

  • Key: DDSIRTP25-1
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The previous version of the spec (formal/14-09-01) contained the following in Table 9.4
    #define SEQUENCENUMBER_UNKNOWN {-1, 0}
    However, the equivalent definition is missing in the 2018 "Beta" spec.
  • Reported: DDSI-RTPS 2.3b1 — Tue, 22 Jan 2019 18:12 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add SEQUENCENUMBER_UNKNOWN

    Add specification for SEQUENCENUMBER_UNKNOWN with definition matching previous versions of the protocol (high = -1, low = 0)
  • Updated: Tue, 29 Jun 2021 12:54 GMT

Support transport-level RTPS message compression

  • Key: DDSIRTP25-27
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

    This is something that could be added in a reasonably simple manner by considering this part of the transport PSM.
  • Reported: DDSI-RTPS 2.3b1 — Mon, 14 Sep 2020 15:06 GMT
  • Disposition: Deferred — DDSI-RTPS 2.5
  • Disposition Summary:

    Defer to the next RTF.

    Defer to the next RTF.
  • Updated: Tue, 29 Jun 2021 12:54 GMT

Add an INFO_AGE submessage

  • Key: DDSIRTP25-24
  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Dr. Ornulf Staff)
  • Summary:

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

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

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

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

    INFO_AGE allows two features on systems with no time synchronization:

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

    It should be noted that a system based on INFO_AGE with multiple readers and writers on the same topic will have a non-deterministic sample order on the readers.
  • Reported: DDSI-RTPS 2.3b1 — Mon, 22 Jun 2020 12:27 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.5
  • Disposition Summary:

    Merge with DDSIRTP25-12

    This can be merged with DDSIRTP25-12
  • Updated: Tue, 29 Jun 2021 12:54 GMT

Update Acknowledgemts, Copyright and Statement of Proof

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

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

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

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

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

  • Reported: DDSI-RTPS 2.3b1 — Tue, 24 Sep 2019 21:23 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Update section 6.3 'Acknowlegments' an copyrights

    As stated in the issue description update the acknowledgments and copyright to include people that participated in the various RTFs
  • Updated: Tue, 29 Jun 2021 12:54 GMT

currentGSN.value < lastGSN.value condition seems wrong

  • Key: DDSIRTP25-11
  • Status: closed  
  • Source: N/A ( Frans Schneider)
  • Summary:

    The last condition seems wrong. Shouldn't that be greater than instead of less than?
    If GroupInfoFlag is set and:
    • currentGSN.value is zero or negative
    • firstGSN.value is zero or negative
    • lastGSN.value is negative
    • lastGSN.value < firstGSN.value - 1
    • currentGSN.value < firstGSN.value
    • currentGSN.value < lastGSN.value
  • Reported: DDSI-RTPS 2.3 — Mon, 10 Feb 2020 08:26 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    *Correct section 8.3.7.6.3 'Validity' (Hearbeat) *

    I section 8.3.7.6.3 'Validity' (Hearbeat). Change:
    currentGSN.value < lastGSN.value
    to
    currentGSN.value > lastGSN.value
  • Updated: Tue, 29 Jun 2021 12:54 GMT

8.3.7.5 / 9.4.5.6 HeartBeat Submessage

  • Key: DDSIRTP25-10
  • Status: closed  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the message module, the submessage heartbeat defines the flag GroupInfoFlag and the fields currentGSN, firstGSN, lastGSN. writerSet and secureWriterSet. A specification for this flag and the fileds is missing in the PSM.
  • Reported: DDSI-RTPS 2.3 — Fri, 7 Feb 2020 13:20 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add information on the GroupInfoFlag to 9.4.5.7 'HeartBeat Submessage'

    Add missing information on the GroupInfoFlag and elements currentGSN , firstGSN, and lastGSN to section 9.4.5.7 'HeartBeat Submessage'
  • Updated: Tue, 29 Jun 2021 12:54 GMT

PSM and PIM description of Gap message not matching

  • Key: DDSIRTP25-7
  • Status: closed  
  • Source: S2E Systems ( Joao Rebelo)
  • Summary:

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

    • Section 9.4.5.5.1 mentions that "This Submessage has no flags in addition to the EndiannessFlag". Section 8.3.7.4.2 describes "GroupInfoFlag" with the following text "Appears in the Submessage header flags"
    • "gapStartGSN" and "gapEndGSN" sequence numbers do not appear in the wire representation
  • Reported: DDSI-RTPS 2.3 — Mon, 11 Nov 2019 20:45 GMT
  • Disposition: Resolved — DDSI-RTPS 2.5
  • Disposition Summary:

    Add GapInfoFlag information to section 9.4.5.6 'Gap Submessage'

    Add information about the GapInfoFlag, gapStartGSN and gapEndGSN to section 9.4.5.6 'Gap Submessage'.
  • Updated: Tue, 29 Jun 2021 12:54 GMT

Interoperability of Transient/Persistent data

  • Key: DDSIRTP25-13
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The following issue https://issues.omg.org/browse/DDSIRTP23-26 was deferred in the last RTF so it should have been moved to this RTF. Since it didn't happen automatically we are entering this issue manually here.
  • Reported: DDSI-RTPS 2.3b1 — Fri, 20 Mar 2020 20:09 GMT
  • Disposition: Deferred — DDSI-RTPS 2.5
  • Disposition Summary:

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

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

    Therefore the resolution of this issue is deferred to the next DDSI-RTPS RTF, which will be able to take into consideration the result of the DDS15 RTF.
  • Updated: Tue, 29 Jun 2021 12:54 GMT

TypeLookup IDL Inconsistency

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

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

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

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

    Other issues in this IDL:

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

Common Types contains invalid IDL

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

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

    struct RequestHeader {
  SampleIndentity_t requestId;
  InstanceName instanceName;
};

    And SampleIndentity_t is misspelled. It should be SampleIdentity.
  • Reported: DDS-RPC 1.0 — Wed, 16 Jun 2021 21:32 GMT
  • Updated: Wed, 16 Jun 2021 21:32 GMT

Typo in Member of AnnotationParameterValue

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

    AnnotationParameterValue has a members for integer types. uint_16_value is the only one that has an underscore between the int and the size and this appears to be a typo. Given that it seems that the name has no real bearing in this situation, it should be fixed by changing uint_16_value to uint16_value.
  • Reported: DDS-XTypes 1.3 — Mon, 14 Jun 2021 22:07 GMT
  • Updated: Mon, 14 Jun 2021 23:04 GMT

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

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

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

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

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

    Timestamp:

    0...2...........8...............16.............24. .............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                 unsigned long    seconds                      | 
+---------------+---------------+---------------+---------------+ 
|                 unsigned long    fraction                     | 
+---------------+---------------+---------------+---------------+
  • Reported: DDSI-RTPS 2.5 — Thu, 10 Jun 2021 23:32 GMT
  • Updated: Thu, 10 Jun 2021 23:32 GMT

sample lost/rejected should be clarified and extended

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

    when testing for sample lost/rejected between multiple DDS vendors we see different vendors to different things. The specification should be extended with more information when a sample is considered lost and when rejected with also more details how QoS settings would influence this. We see that vendors have extended the SampleLostStatus and SampleRejectedStatus and even have deprecated some of its members, this should be handled in the specification so that the user gets the same behavior when using multiple vendors
  • Reported: DDS 1.4 — Thu, 27 May 2021 16:27 GMT
  • Updated: Thu, 3 Jun 2021 18:53 GMT

DDS should use typed modules

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

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

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

Order in which implied IDL and language mappings interact

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

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

    The specification should give an example for _public, what does the programmer now get in a specific programming language, for example C++
  • Reported: DDS 1.4 — Wed, 19 May 2021 11:54 GMT
  • Updated: Thu, 20 May 2021 20:27 GMT

Incorrect value for GROUPDATA_QOS_POLICY_NAME

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

    The IDL file dds_dcps.idl has a wrong value

    const string GROUPDATA_QOS_POLICY_NAME = "TransportPriority";

    Shouldn't it say "GroupData"
  • Reported: DDS 1.2 — Wed, 12 May 2021 12:20 GMT
  • Updated: Wed, 12 May 2021 14:06 GMT

The list of valid KEY types does not include String types

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

    The text reads:

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

    It should include 'string' and 'wstring'.
  • Reported: DDS-XTypes 1.3 — Thu, 6 May 2021 15:53 GMT
  • Updated: Tue, 11 May 2021 13:56 GMT

IDL keywords used as interface/module

  • Key: DDSOPCU11-3
  • 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

  • Key: DDSOPCU11-2
  • 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

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

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

    This is something that could be added in a reasonably simple manner by considering this part of the transport PSM.
  • Reported: DDSI-RTPS 2.3b1 — Mon, 14 Sep 2020 15:06 GMT
  • Updated: Fri, 9 Apr 2021 12:28 GMT

Example class table seems to violate written convention

  • Key: DDS15-321
  • Status: open  
  • Source: Air Force Institute of Technology, Student ( Nathaniel Peck)
  • Summary:

    Above the Myclass example table, the written text says that collections of types will be denoted by <type>[]. The example describes in: param4 as being a collection of longs, but the table defines the type as long rather than long[] as the written convention seems to imply.

  • Reported: DDS 1.4 — Tue, 30 Mar 2021 17:56 GMT
  • Updated: Thu, 1 Apr 2021 15:53 GMT

DDS Entities should have a name

  • Key: DDS15-28
  • Legacy Issue Number: 16029
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    DDS Entities (DomainParticipant, Publisher, Subscriber, DataReader and DataWriter) have associated GUID but the current API does not provide any way of associating them a symbolic name, such as "com.acme.mycoolapp.DomainParticipantFoo"

    The DDS PIM should be extended to support the explicit setting of entity names. When not set explicitly, vendors should be free to pick meaningful names.
  • Reported: DDS 1.2 — Wed, 16 Feb 2011 05:00 GMT
  • Updated: Tue, 16 Mar 2021 08:22 GMT

OCSP stapling to enhance certificate status checking during handshake

  • Key: DDSSEC11-82
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    Similarly to TLS OCSP stapling (RFC 6066, §8, improved by RFC 6961), OCSP stapling consists to send the certificate status (OCSP response) in the handshake message, saving roundtrips and resources. This would enhance handshake performance and energy saving in DDS security

    This requires to add a new (optional) binary property like c.status to HandshakeRequestMessageToken and HandshakeReplyMessageToken and value is a DER-encoded OCSP response (using the ASN.1 type OCSPResponse defined in RFC2560) that provides the status of the certificate in c.id property. Then begin_handshake_reply() and process_handshake() should honor this property if present.

    This issues has been merged with DDSSEC11-110. So the resolution to this issue should also address the certificate expiration issue raised in DDSSEC11-100.
  • Reported: DDS-SECURITY 1.0 — Mon, 22 May 2017 06:40 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add support for OCSP stapling

    The issue is addressed by adding two features:
    (1) The DomainParticipant will be able to attach (staple) the OCSP response during the Authentication Protocol, as an extra field in the Tokens that are exchanged. This ca be used to ensure freshness at the time the authentication occurs.

    (2) The DomainParticipant will be able to include the OCSP response in its ParticipantBultinTopicDataSecure. This would help ensure freshness after authentication completed.

    Details of the configuration for the freshness limits and handling of expired certificates are left to the implementors.

  • Updated: Thu, 11 Mar 2021 20:10 GMT
  • Attachments:

Table 60 - RTPS encapsulation identifier

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

    In this table, the row second from the bottom for "XCDR MUTABLE 2 Little Endian" has the wrong identifier.
  • Reported: DDS-XTypes 1.3 — Thu, 11 Mar 2021 15:44 GMT
  • Updated: Thu, 11 Mar 2021 15:44 GMT

create_querycondition with a query with string parameters

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

    We identified differences between DDS vendors how to handle a query condition that uses a string parameter. At the moment we have a query with "symbol = %0", what is the query parameter string we need to use when we want to match it with OMG. When using for example C++, RTI Connext DDS seems to require "'OMG'", so single quotes around the string itself, but OpenDDS/Opensplice seem to use "OMG" so without single quotes around the string.

    The specification should be clear about how strings are used when they are passed through a query parameter like %0.
  • Reported: DDS 1.4 — Fri, 26 Feb 2021 14:24 GMT
  • Updated: Thu, 4 Mar 2021 01:01 GMT

Unknown behavior of explicitly negated key in nested struct

  • Key: DDSXTY14-41
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    In section 7.6.8 it is stated that for a nested struct that is annotated as key for an embedding struct, you have to follow the following process to to generate its KeyHolder: "If there are any key members, then remove the non-key members from FooKeyHolder. Otherwise do not remove any members."

    So what if the struct has no explicit key members, but it has explicitly mentioned that a certain field should not act as key? Take for example the following example:

    struct Foo {
    long x;
    @key(false) long y;
};

struct Bar {
    @key Foo myFoo;
    string name;
};

    There are three different ways to interpret the rules for this usecase:

    1. Both x and y will end up in the KeyHolder, since Foo did not specify any key members, so nothing gets removed.
    2. Only y will end up in the KeyHolder, since Foo specified explicitly that x should not act as key.
    3. Neither x nor y will end up in the KeyHolder, since some of the members have an explicit key annotation and so I remove all the members which are not keys, which is y (stated explicitly) and x (stated implicitly).

    So the big underlying question is: is explicitly stating @key(false) equal to not having a @key annotation at all, or does explicitly stating that a member is not a key have some more expressive power over implicitly determining its key status by absence of the @key annotation?
  • Reported: DDS-XTypes 1.3b1 — Wed, 27 Jan 2021 15:03 GMT
  • Updated: Fri, 5 Feb 2021 16:25 GMT

Type Consistency Enforcement QoS Policy ignore_member_names

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

    The paragraph that explains ignore_member_names defines its semantics as follows:

    • If the option is set to TRUE, member names are considered
    • If the option is set to FALSE (the default), then
      member names are not ignored

    The mode of "considering" would seem to be the same as "not ignoring." Thus the spec is currently stating that the two options are equivalent. Since the name is ignore_member_names, that indicates that setting TRUE should indeed ignore them.

    The spec should be changed to indicate that if the option is set to TRUE then member names are ignored.
  • Reported: DDS-XTypes 1.3 — Mon, 25 Jan 2021 21:40 GMT
  • Updated: Mon, 25 Jan 2021 21:40 GMT

Extend SampleLostStatus with last_reason

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

    Several DDS vendors have already extended SampleLostStatus with a last_reason, indicating why the last sample was lost. We would like to see this in the DDS specification so that all vendors provide this consistently
  • Reported: DDS 1.4 — Mon, 23 Nov 2020 12:11 GMT
  • Updated: Mon, 28 Dec 2020 17:03 GMT

Ambiguous effect of using annotations on attributes with multiple declarators.

  • Key: DDSXTY14-37
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    It is possible to put an annotation on an attribute with multiple declarators, like this:

    struct Foo {
  @key long x, y;
};

    What is the effect of this? Does the annotation apply to both declarators? In that case, how do you interpret the following:

    struct Foo {
  @fieldid(0x01000) long x, y;
};
  • Reported: DDS-XTypes 1.3b1 — Wed, 30 Sep 2020 14:49 GMT
  • Updated: Tue, 8 Dec 2020 15:59 GMT

behaviour of create_topic with duplicate topic_name

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

    the DDS spec should define the behaviour when the create_topic is called multiple times with the same topic_name, I think the operation should fail at that moment, but that is not mentioned in the spec
  • Reported: DDS 1.4 — Mon, 16 Nov 2020 17:36 GMT
  • Updated: Tue, 17 Nov 2020 14:30 GMT

Default built-in ReaderDataLifecycle values

  • Key: DDS15-46
  • Legacy Issue Number: 10811
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    QoS settings of buildin Readers: according to section 2.1.5 builtin Readers should have its ReaderDataLifecycles delays set to infinite, meaning that builtin topics that are disposed and/or unregistered will never be removed from the system unless explicitly 'taken'. If an application never bothers to look at the builtin readers, they will never clean up resources and these readers will use up more and more memory if entities keep on joining and leaving the network.

    Solution:
    We propose to give the builtin-readers a finite duration for both auto_purge variables (for example something like 5 minutes).
  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 12 Oct 2020 13:44 GMT

Handling Unsupported Numeric Values like Infinity and NaN

  • Key: DDSJSON-1
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    As stated in ECMA-404, JSON does not provide native representation for values like "Infinity", "-Infinity", and "NaN":

    Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted.

    However, these are values that need to be handled by a JSON encoder and decoder. Therefore, we should provide a standard representation for such values so that all implementations of DDS-JSON can follow the same approach.
  • Reported: DDS-JSON 1.0a1 — Tue, 25 Feb 2020 11:55 GMT
  • Disposition: Resolved — DDS-JSON 1.0
  • Disposition Summary:

    Define mapping of numeric values that cannot be represented as digit sequences

    This resolution provides a mapping for numeric values (such as "Infinity", "-Infinity", and "Nan") that cannot be represented as digit sequences and are therefore invalid JSON according to [ECMA-404].
  • Updated: Fri, 18 Sep 2020 17:03 GMT

Change the default value for DataWriterLifecycle::autodispose_unregistered_instances and behavior when a DataWriter is deleted

  • Key: DDS15-314
  • Status: open  
  • Source: Real-Time Innovations ( Ms Erin McManus)
  • Summary:

    Unregistering and disposing instances have different semantics and the default association of these two operations through the usage of the autodispose_unregistered_instances may lead to behaviors that are unexpected and not desirable to DDS users.

    The unregister operation is meant to indicate that the DataWriter will no longer update the instance but does not indicate anything about the state of the instance itself. The dispose operation, on the other hand, is meant to indicate a change in the state of the instance, it indicates that the instance has been deleted. Because of this, we are proposing changing the default value of this QoS to FALSE. This is something that many of our customers end up doing explicitly.

    In addition to changing the default value for autodispose_unregistered_instances, we are also proposing that this QoS does not have any effect during the deletion of the DataWriter. Disposing of an instance should be an explicit operation (individual or bulk operation). In many cases, the user's intention is not to delete (dispose) an instance when a DataWriter is deleted and doing so explicitly ties the lifecycle of the instance to the lifecycle of the DataWriter.

  • Reported: DDS 1.4 — Wed, 2 Sep 2020 23:52 GMT
  • Updated: Thu, 3 Sep 2020 20:00 GMT

Enums with different holder types should not be assignable

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

    The row for ENUM_TYPE in Table 40 defines an enum's holder type.

    Footnote 3 on page 63 indicates that the type system is designed to allow a DataReader to consume a byte stream from a differently-typed (but assignable) DataWriter without "requiring the consultation of per-DataWriter type definitions during sample deserialization".

    The current definition of Enum Assignability fails in this respect. It needs to prevent enum types from being assignable when their holder types differ.

    Also relevant - pgh 2 of 7.2.4.2 "...Enumerated types (Enumeration and Bitmask) are delimited types as their serialized size is fixed"
  • Reported: DDS-XTypes 1.3 — Wed, 26 Aug 2020 18:09 GMT
  • Updated: Wed, 26 Aug 2020 22:09 GMT

7.4.3.5.3 contradictory rules for collections

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

    Arrays of all kinds/extensibilities are covered by rules 8-10. Following those we find the "comments" below:

    // Arrays with extensibility APPENDABLE use common APPENDABLE rules:
// (29)-(30)
// Arrays with extensibility MUTABLE are not allowed. Treated as APPENDABLE.

    Which is either redundant or contradictory. Same issue with Sequences (rules 11-13) and maps (rules 14-16).

    Due to this, the notes before rules 29-30 should be revised to remove "Collection or"

    // Extensibility APPENDABLE (Collection or Aggregated types), version ?
// encoding
  • Reported: DDS-XTypes 1.3 — Tue, 30 Jun 2020 20:01 GMT
  • Updated: Tue, 25 Aug 2020 17:40 GMT

DataRepresentationQosPolicy default

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

    7.6.3.1.1 ends with
    "The default value of the DataRepresentationQosPolicy shall be an empty list of preferences.
    An empty list of preferences shall be taken to be equivalent to a list containing the single element XCDR"

    This contradicts the rest of the section which describes how XCDR (v1) is optional. The default should be XCDR2.
  • Reported: DDS-XTypes 1.3 — Tue, 28 Jul 2020 19:37 GMT
  • Updated: Tue, 25 Aug 2020 16:15 GMT

Specify that TypeLookup Service uses XCDR2

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

    7.6.3.3.3 defines built-in RTPS Endpoints for TypeLookup, but doesn't specify their Data Representation. Since TypeLookup is new, this should be XCDR2.
  • Reported: DDS-XTypes 1.3 — Tue, 28 Jul 2020 19:45 GMT
  • Updated: Mon, 24 Aug 2020 19:22 GMT

XTypes spec is missing topic names for TypeLookupService

  • Key: DDSXTY14-26
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    In section 7.6.2.3, that introduces the TypeLookupService, the datatypes used for exchanging TypeLookupRequests and TypeLookupResponse are introduced, and so are the endpoints used to exchange them.
    However, what is missing is the topic names used for the topics carrying these requests and their responses. Technically you might not need the topic names to build an interoperable implementation, because the endpoints are builtin endpoints and therefore don't need to be matched, but nevertheless, the topic will need to have a name and the name might as well be part of the spec.
  • Reported: DDS-XTypes 1.3 — Thu, 4 Jun 2020 20:51 GMT
  • Updated: Tue, 28 Jul 2020 19:28 GMT

Missing alignment for XCDR1 mutable's sentinel

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

    Rule 23 is missing "ALIGN(4)" before PID_SENTINEL

    // Structures with extensibility MUTABLE, version 1 encoding
(23) XCDR[1] << {O : MSTRUCT_TYPE} =
XCDR
<< { O.member[i] : MMEMBER }*
<< { PID_SENTINEL : UInt16 }
<< { length = 0 : UInt16 }
  • Reported: DDS-XTypes 1.3b1 — Mon, 29 Jun 2020 23:27 GMT
  • Updated: Wed, 8 Jul 2020 04:16 GMT

How should interoperable implementations deal with Transient / Persistent data?

  • Key: DDSIRTP23-26
  • Legacy Issue Number: 16099
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

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

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 Mar 2011 04:00 GMT
  • Disposition: Deferred — DDSI-RTPS 2.3
  • Disposition Summary:

    Defer this issue until the next revision

    This issue requires additional time to be resolved. In order not to delay the adoption of the other important issues that are already resolved the RTF recommend it is deferred to the next RTF.
  • Updated: Wed, 24 Jun 2020 18:13 GMT

Mapping of one single Topic per Service does not work well with DDS Security

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

    This issue has also been entered into DDS-Security as the solution could also involve changes to that specification. See:
    https://issues.omg.org/browse/DDSSEC12-31

    DDS-RPC maps each DDS-Service to a single (unkeyed) Topic-pair (request topic & reply Topic).

    DDS-Security provides access control per Topic and per Instance (Key). Moreover, the builtin plugins only provide access control per Topic.

    With these mappings is it not possible to configure access control per operation/method in the service. This is a common requirement for many service definitions.

    One way to overcome this would be to provide a mapping where each a Service would map to multiple Topic pairs. E.g. one Topic pair per method/operation. That way it would be possible to separately grant permissions to call operations on a service or to implement operations on a service.

    The mapping of a Topic pair per method/operation would also setting different Qos per operation...

    Alternatively one could

  • Reported: DDS-RPC 1.0 — Tue, 28 Aug 2018 23:45 GMT
  • Updated: Wed, 24 Jun 2020 17:36 GMT

Listener model breaks API design goal of automatic resource management

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

    The way the C++ PSM modeled listeners has proven problematic. While the whole language binding is designed to provide automatic resource management, listeners break that model. Listeners are assigned to a DDS Entity as a raw pointer and “retain” the Entity.

    Because an Entity with a listener is retained, the user must manually reset the listener to allow its automatic destruction or explicitly close the entity. This defeats the purpose of automatic resource management, forcing users to write exception-safe code or risk “leaking” the resource.

    RTI proposes a change in how listeners are set. In summary:

    1) Listeners are set as std::shared_ptr's. All APIs change to receive a std::shared_ptr<Listener> instead of a Listener*
    2) Listeners no longer retain the entity. (It's the other way around; the Entity keeps a reference to its listener, which ensures the listener is not deleted). 

    Note that an entity can be explicitly retained with the member function retain(), which allows preserving the old behavior quite easily.

    The changes, affecting all dds::core::Entity-derived types, are the following:
     

    Previous API (usable but deprecated) New API
    Constructor with Listener* argument Constructor with std::shared_ptr<Listener>
    Listener setter: listener(Listener*, StatusMask) Listener setter: set_listener(std::shared_ptr<Listener>, StatusMask)
     (not available) Listener setter with no mask, added for convenience: set_listener(std::shared_ptr<Listener>) // Defaults to all() when the listener is not null or none() when it’s null
    Listener getter: Listener * listener() const  Listener getter: std::shared_ptr<Listener> get_listener() const

    Notice the name change—the overloaded listener is now get_listener/set_listener. A new overload wasn’t possible because the getter would only differ on the return type.

    Implementations that do not support C++11 can offer the old listener model.
     
    Example:

    // Previous API:
MyListener *my_listener = new MyListener();
reader.listener(my_listener, StatusMask::all());
// ...
reader.listener(NULL, StatusMask::none()); // user must reset the listener to destroy entity
delete my_listener;

// New API:
auto my_listener = std::make_shared<MyListener>();
reader.set_listener(my_listener);// No manual resource management required anymore

// Or simply:
reader.set_listener(std::make_shared<MyListener>());

     
  • Reported: DDS-PSM-Cxx 1.0b2 — Sun, 14 Jun 2020 19:45 GMT
  • Updated: Mon, 15 Jun 2020 23:32 GMT

Typo fixes

  • Key: DDSPSMC11_-93
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    p3 section 5 table 1st row right column

    [...] Given two programming language type T and Q,

    -> types

    p5 7.1 1st para 3rd line

    [...] language today universally sup- ported by C++ compilers.

    -> supported

    p5 7.2 1st para 3rd sentence

    The specification defines
    type constructors, i.e., parameterized class, that delegate

    -> classes

    p6 7.2 cont'd

    Under no circumstances a vendor shall change [...]. The only action performed by
    type constructor is to delegate their implementation

    -> constructors

    p6 7.3 2nd bullet

    * Loand-based read/take operation shall be exception safe.

    -> Loan based

    p7 7.4.1 MappingClasses (title)
    -> Mapping Classes

    p10 7.4.5 3rd table

    [left column] PIM Native Return Type

    -> PIM Return Type

    [right column] One of the following, depending on wether

    -> whether

    p12 Table 7-2 Namespace 2nd column 2nd row

    pomain

    -> domain

    p13 7.5.2 end of 1st sentence and 2nd sentence

    (note that for immutable value-types the only form of change is to create
    a new value- type).
    The DDS-PSM-Cxx models all DDS PIM classes [...] as value- types.

    -> value-type, value-types (remove space after hyphen)

    p14 top of page sentence preceding 7.5.5

    The full set of status classes is includes in the mandatory standard headers [...]

    -> included

    p16 7.6.2.1 1st para 3rd sentence

    As an
    example, from the URI ” the QosProvider would deduce [...]

    Please clarify - the single quotation mark is not a valid URI.
    I suspect the following might be intended:
    {{As an example, from the URI "file://" the QosProvider would deduce [...]}

    p18 7.8 1st sentence

    The topic packaged defines the classes related to [...]

    -> package

    p18 7.8 6th para

    If the topic is to be created with a QoS different from the default, than the code [...]

    -> from the default then
  • Reported: DDS-PSM-Cxx 1.0 — Sun, 9 Feb 2020 19:39 GMT
  • Updated: Fri, 12 Jun 2020 06:31 GMT

Can structures contain constant declarations?

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

    Section 7.3.2.5.1 'Structures' states:

    Structures contain four kinds of declarations:
    • Applied annotations
    • Verbatim text
    • Members
    • Constants

    However section 7.3.1.10 'Structure Types' states:

    Structures as described in this specification are fully compatible with the IDL constructs of the same name.

    IDL (4.3) does not allow constant declarations inside structures. So these two statements are incompatible.

    Also the UML model in 7.2.2.4.4.2 'Structure Types' states structures contain only members. And constant declarations are not members.

    Therefore it seems like the text in Section 7.3.2.5.1 should be modified to remove the bullet about constants.
  • Reported: DDS-XTypes 1.3b1 — Wed, 10 Jun 2020 23:26 GMT
  • Updated: Wed, 10 Jun 2020 23:26 GMT

Editorial corrections

  • Key: DDS15-313
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    p2 5th para middle sentence

    The purpose of the DDS specification is to
    define the standardized interfaces and behaviors that enable applicaton portability.

    -> application



    p11 Figure 2.5 bottom right class box,
    p58 Figure 2.10 bottom middle class box,
    p125 Figure 2.19 middle right class box

    QueryConditon

    -> QueryCondition



    p61 2.2.2.5.1.4 1st para 3rd sentence

    change of state for an intance that was caused by some internal mechanism

    -> instance



    p61 2.2.2.5.1.4 1st para 4th sentence

    An example of this situation is when the Service [...] and changes the coresponding

    -> corresponding



    p61 2.2.2.5.1.4 2nd para 2nd sentence

    The application can distinguish wether a particular DataSample has data

    -> whether



    (DDS15-195)
    p61 2.2.2.5.1.4 3rd para 1st sentence

    To ensure corerctness and portability, the valid_data flag must be examined

    -> correctness

    p107 2.2.3.13 4th para 3rd sentence

    It may establish new "matchs" that did not exist before, or break existing matchs.

    -> "matches" , matches.



    p110 2nd para 2nd sentence

    [...] For example setting
    max_samples_per_instance to LENGH_UNLIMITED will cause the middleware to [...]

    -> LENGTH_UNLIMITED



    p120 2.2.4.2.2 enumerated list 2nd bullet 2nd sub-bullet

    • the DataWriter that owns it if OWNERSHIP QoS kind=EXLUSIVE, or by

    -> kind=EXCLUSIVE



    p121 Figure 2.16 statebox at right

    StatiusChangedFlag = TRUE

    -> StatusChangedFlag



    p166 top

    Selection        ::=    TOPICNAME
                 |      TOPICTNAME NaturalJoin JoinItem

    -> TOPICNAME NaturalJoin JoinItem
  • Reported: DDS 1.4 — Mon, 11 May 2020 03:39 GMT
  • Updated: Thu, 28 May 2020 20:35 GMT

Typo

  • Key: DDS15-199
  • Status: open  
  • Source: Netherlands Aerospace Centre ( Arnoud van Leeuwen)
  • Summary:

    Suspected typo in paragraph 4, last scentece:
    "In other words, the DataReader may miss some data-samples but it will never see the
    value of a data-object change from a newer value to an order value."

    Should the second to last word "order", not be: "older"? The context seems to suggest so.
  • Reported: DDS 1.4 — Fri, 19 Aug 2016 07:53 GMT
  • Updated: Mon, 11 May 2020 03:42 GMT

Default value for WRITER_DATA _LIFECYCLE v should be FALSE

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

    According to the Qos table in 2.2.3 'Supported QoS' the default value for autodispose_unregistered_instance is TRUE. We have found a two issues with this

    (1) It is not semantically what people expect. Just because a DataWriter is deleted it does not mean all the instances should be deleted... It could be so for some use-cases, but we found that in the majority of the use-cases it is not an intuitive behavior.

    (2) It is not scalable. If writer with a lot of instances is deleted. it needs to send many messages and potentially wait until they are acknowledged before releasing the DataWriter resources. This makes the data-writer delete operation something that can block for an unbounded time which is not what applications expect.

    It sees it would be better to:
    (a) Change the default value of autodispose_unregistered_instance to FALSE.
    (b) Provide a better/more efficient/scalable way to communicate to the DataReaders that all the instances of a DataWriter have been deleted.
  • Reported: DDS 1.4 — Thu, 30 Apr 2020 21:02 GMT
  • Updated: Fri, 8 May 2020 12:32 GMT

DynamicType should be a value type, not a reference type

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

    A type description is conceptually a value type, not a reference type. A type doesn't have a special identity, like for example a DomainParticipant. A type description can be copied, compared for equality, passed by value, etc. That doesn't preclude applications from using a shared_ptr<DynamicType> if they want to.
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 28 Apr 2020 21:26 GMT
  • Updated: Tue, 28 Apr 2020 21:26 GMT

Confusing description of FINAL on 7.2.3 TypeExtensibilityandMutability

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

    In this section there is a bullet stating:

    • A type may be FINAL, indicating that the range of its possible data values is strictly defined. In particular, it is not possible to add elements to members of collection or aggregated types while maintaining type assignability.

    This is confusing. What does it mean that " the range of its possible data values is strictly defined"?
    Moreover, it talks about collection types where Table 12 says that for these types the extensibility kind has no effect.

    It sis recommended that this bullet is rephrased to just say that members cannot be added, removed or reordered.
  • Reported: DDS-XTypes 1.3b1 — Sat, 4 Apr 2020 00:03 GMT
  • Updated: Sat, 4 Apr 2020 00:03 GMT

Add a function that allows releasing any resources created by the DomainParticipantFactory

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

    The Domain Participant Factory may create resources (e.g. tables that allow looking up or manage created domain participants, etc.)

    These resources need to be released when the application shuts down so that they are not reported as "leaks" by the OS.

    A function should be added that forcefully releases all resources created by the DomainParticipantFactory. This function would have as a pre-requisite that all DomainParticipants have been deleted...
  • Reported: DDS 1.4 — Fri, 27 Mar 2020 21:46 GMT
  • Updated: Fri, 27 Mar 2020 21:46 GMT

Define Implied Keys Behavior

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

    1. In 7.6.8, the algorithm for creating a KeyHolder states that:

    If there are any key members, then remove the non-key members from FooKeyHolder. Otherwise do not remove any members.

    This seems to say that if there are no fields marked as keys, leave all of them open to be able to be used as keys. That would be consistent with implied key behavior.

    2. There is an example of implied @key in Annex D, where the TopicData types specify BuiltinTopicKey_t as a key, but the single member of BuiltinTopicKey_t is not marked as a key.

    3. At the same time 7.2.2.4.4.4.8 says:

    If a given type has no members designated as key members, then the type—and any DDS Topic that is constructed using it as its type it—has no key.

    It also says that:

    In the event that the type K of a key member of a given type T itself defines key members, only the key of K, and not any other of its members, shall be considered part of the key of T.

    This doesn't go against implied keys, but would be a good place to mention them in addition to the previous sentence.

    4. 7.3.1.2.1.3 says that:

    To declare a member as part of the key, users shall apply the @key annotation...

    7.2.2.4.4.4.8 and 7.3.1.2.1.3 seem to have been written under the assumption that @keys can't be implied. If the specification actually requires this, which it appears that it does given Annex D, then it should say so in those two sections.

    Finally, a couple thoughts/questions came up about implied keys behavior since it is not defined in the spec:

    1. Given a situation like:

    @nested(TRUE)
    struct A

    { @key(FALSE) long a1; long a2; }

    ;

    @nested(FALSE)
    struct B

    { @key A b1; }

    ;

    Shouldn’t a2 be the only element of the key of B, because we’re explicitly saying a1 isn’t part of the key?

    2. Should implied key behavior (potentially including the behavior in the previous point) apply to union discriminators? For example:

    @nested(TRUE)
    union TestUnion switch (long)

    { // ... };

    @nested(TRUE)
    union KeyedTestUnion switch (@key long) { // ... }

    ;

    @nested(TRUE)
    union KeyedFalseTestUnion switch (@key(FALSE) long)

    { // ... }

    ;

    @nested(TRUE)
    struct A

    { TestUnion a1; // discriminator is implied to be part of the key of B KeyedTestUnion a2; // discriminator is explicitly part of the key of B KeyedFalseTestUnion a3; // Not part of the key of B }

    ;

    @nested(FALSE)
    struct B

    { @key TestUnion b1; // discriminator is implied to be part of the key @key KeyedTestUnion b2; // discriminator is explicitly part of the key @key KeyedFalseTestUnion b3; // Not part of the key, maybe an implementation could give a warning? @key A b4; }

    ;
  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 13:53 GMT
  • Updated: Tue, 24 Mar 2020 14:29 GMT

7.4.3.5.3 doesn't define OPTIONS

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

    This section should have an explanation or cross-reference to describe what <OPTIONS> is (used in 1st encoding rule in the section)
  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 14:26 GMT
  • Updated: Tue, 24 Mar 2020 14:29 GMT

Be more precise on meaning of string lengths and bounds

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

    In section 7.2.2.2.1.2.4 String<Char8> type
    The specification does not provide a description of the "length" and "bound" values shown in Figure 9.

    In the case of strings, specially String8, there is an ambiguity on whether the "bound" and "length" represent the number of characters, or the number of bytes in the UTF-8 encoding mentioned in 7.2.2.2.1.2.4, or something else.

    an interpretation of the length of the string.
  • Reported: DDS-XTypes 1.3b1 — Thu, 19 Mar 2020 20:23 GMT
  • Updated: Tue, 24 Mar 2020 14:01 GMT

Implementation Defined Default Nested Behavior

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

    7.3.1.2.1.7 Nested Types

    By default, aggregated types and aliases to aggregated types defined in IDL are not considered to be nested types.

    ...

    If not present on a module, the value defaults to that of the enclosing module. If a top -level module is not annotated, the default is FALSE.

    ...

    In addition to the above annotations, IDL compilers shall provide the means to change the default value for non-annotated top-level modules.

    Given the fourth sentence, the first and third sentences should also say the nested status of a non-annotated type is implementation defined.
  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 13:55 GMT
  • Updated: Tue, 24 Mar 2020 13:55 GMT

get_discovered_participant_data() should return BAD_PARAMETER instead of PRECONDITION_NOT_MET

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

    This issue has to do with the proper code when the function
    get_discovered_participant_data gets passed an invalid handle.

    This function is analogous to get_matched_subscription_data() and get_matched_publication_data() except that that it retrieves information on the matching participant instead of the matching endpoint. All these functions take a handle as an input that refers to the "matching" entity for which information is
    being retrieved.

    Prior to version 1.2 get_matched_subscription_data() was returning PRECONDITION_NOT_MET and get_matched_publication_data BAD_PARAMETER.
    Returning BAD_PARAMETER seemed more appropriate so in version 1.2 (OMG issue 9500) we updated get_matched_subscription_data to also return BAD_PARAMETER.

    However get_discovered_participant_data() was not updated as part of is still returning PRECONDITION_NOT_MET.

    Therefore get_discovered_participant_data() should be updated to also return BAD_PARAMETER when an invalid handle is passed.

  • Reported: DDS 1.4 — Fri, 28 Feb 2020 20:31 GMT
  • Updated: Fri, 28 Feb 2020 20:31 GMT

Need to add an ignore_enum_literal_names in TypeConsistencyEnforcement QosPolicy

  • Key: DDSXTY14-12
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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

  • Key: DDSXTY14-11
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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

  • Key: DDSXTY14-10
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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

  • Key: DDSOPCU11-1
  • Status: open  
  • Source: Real-Time Innovations ( Mr. 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

Extra fields in IDL of 7.8.2.1 create_client

  • Key: DDSXRCE11-3
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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 ( Mr. Oliver M. 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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 ( Mr. 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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, PhD.)
  • 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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 ( Mr. 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 ( Mr. Oliver M. 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, PhD.)
  • 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 ( Mr. 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

Description of KeyHash computation needs update to CDR version 2

  • Key: DDSXTY13-22
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The [RTPS] version referenced in section 3 is version 2.2. It should be updated to version 2.3.
    The reference to [RTPS] in [RTPS] Clause 9.6.3.3, “KeyHash (PID_KEY_HASH)”, should change to [RTPS] Clause 9.6.3.8, “KeyHash (PID_KEY_HASH)”. This is because the section number changed in RTPS 2.3.

    Section 7.6.7 was not fully updated to account for CDR version 2. For example it does not clearly state whether DHEADER is serialized for the purposes of computing the KeyHash.

    Also the sentence about backwards compatibility is no longer relevant.

    The decision of whether to serialize DHEADER or not should be taken as soon as possible as it would affect interoperability.
  • Reported: DDS-XTypes 1.2 — Fri, 20 Apr 2018 12:56 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Update 7.6.7 with more complete description of KeyHash computation

    Update section 3 [RTPS] to reference version 2.3.

    Define the KeyHash computation in a more unambiguous as described below.

    Take the AggregatedType "Foo" that is the container of the key members for which we want to compute the key hash.
    For the purposes of computing the key hash, define a key holder type FooKeyHolder as follows.

    • Start with the original Foo type
    • Remove any no-key members
    • Reorder the key members in the order of memberId (this handles the cases where the AggregateType is Final/Appendable/Mutable).
    • Apply this recursively to the types of the key members if they are of an AggregatedType.

    Consider FooKeyHolder (and any KeyHolder types resulting from key members that were of an AggregatedType) as having @extensibility(FINAL).

    After FooKeyHolder has been constructed. We have two cases:

    (a) If the maximum Serialized Size of FooKeyHolder <= 16 then KeyHash = CDR_BigEndian(FooKeyHolder)
    (b) If the maximum Serialized Size of FooKeyHolder > 16, then KeyHash = MD5(CDR_BigEndian(FooKeyHolder))

    CDR_BigEndian uses XCDR version 2 encoding rules and assume serialization on a 4-byte aligned buffer.

    Therefore the resulting serialized type does not have any encapsulation header, not any DHEADER (from Appendable/Mutable types) nor any MemberHeader (from Mutable types), and uses a maximum alignment of 4-bytes.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Type compatibility when members types define keys

  • Key: DDSXTY13-21
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Assume the following:

    @appendable
struct T1 {
   @key long m1; 
}

@appendable
struct T2 {
  @key long m2;
  @key long m3;
}

struct MyType1  {
  T1 t1; 
  long ll1;
} 

struct MyType2  {
  T2 t1;
  long ll1;
}

    According to the type-compatibility rules MyType1 and MyType2 are not compatible because T1 is not compatible with T2.

    The reason T1 is not compatible with T2 is due to having different keys. But the keys of T1 and T2 do not play any role in MyType1 and MyType2 because these types did not declare those respective member as key.

    So the current compatibility rules are too restrictive. They should be amended to allow MyType1 and MyType2 to be compatible.
  • Reported: DDS-XTypes 1.2 — Fri, 20 Apr 2018 12:40 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Modify type compatibility rules for Aggregated Types

    Modify the type assignability rules to differentiate the requirements form members that are part of the key of the aggregated type from those that are not part of the key.

    The assignability of members that are not part of the key of the enclosing type should not take into consideration the key members of the nested type.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Representation of Built-in Annotations in Dynamic Types

  • Key: DDSXTY13-19
  • Status: closed  
  • Source: MilSOFT ( Mr. Serdar Baklan)
  • Summary:

    A dynamic type cannot be marked as final, mutable or nested and a dynamic type member cannot be marked as key, optional, shared or must_understand easily with the current specification. Only MemberDescriptor has a boolean field "union_default" to represent whether the union member is the default one. Annotations can be used of in the dynamic API but the usage is a bit cumbersome. Is it considerable to append TypeFlag and MemberFlag fields to TypeDescriptor and MemberDescriptor in order to represent built-in annotations in dynamic types as in TypeObject?
  • Reported: DDS-XTypes 1.2 — Wed, 11 Apr 2018 14:18 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    TypeDescriptor and MemberDescriptor with information about the built-in annotations.

    As indicated in the issue description, the MemberDescriptor and TypeDescriptor types need additional members that provide the value of the builtin annotations.

    Define an enum for TypeKind. This was referenced in TypeDescriptor and MemberDescriptor but never defined.
    Define an enum for ExtensibilityKind
    Define an enum for TryConstructKind
    Define VerbatimTextDecriptor

    Add the following fields to MemberDescriptor: is_key, is_optional, is_must_understand, is_shared, try_construct_kind

    Add the following fields to TypeDescriptor: is_nested, extensibility_kind
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Be explicit about which Types can be used for DDS Topics

  • Key: DDSXTY13-15
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification is not explicit about which Types may be used for a DDS Topic.

    By convention most DDS implementations have supported structures. However it is not clear if unions are allowed. And even less so if collections, strings, or primitives can be used.

    Annex E: Built-in Types defines as builtin the types: String, KeyedString, Bytes, and KeyedBytes.

    The DDS specification also does not say anything explicitly. However the fact that it talks about the type-specific code for a type "Foo" namely "FooSupport" "FooDatWriter", etc. may be taken to imply that this must be constructed types that are given a name. e.g. "Foo" by the user. And not primitive types.

    It would be better if the XTYPES spec was explicit about this.
  • Reported: DDS-XTypes 1.2 — Tue, 9 Jan 2018 12:58 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Specify that only Aggregated Types (structure and union types) may be used as a DDS Topic Type

    Aggregated Types are the only ones that have members and allow the possibility of specifying a Key. For this reason the are the only ones suitable for being Topic-Types.

    Specify this restriction following section 7.6.1 'Topic Model'.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Correct listed inconsistencies & missing items

Correct XSD issues identified during AB review

  • Key: DDSXTY13-81
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The AB review identified two critical issues with the XSD changes made by various issue resolutions that need to be fixed:

    • The resolution of DDSXTY13-1 modified the definition of xs:group moduleElements and changed the name of the first element from "include2" to "include" this causes the XSD to be invalid because it conflicts with the name of another element in the definition of xs:complexType moduleDecl
      . This change should be reverted.
    • The resolution of DDSXTY13-4 updated the file "DDS XTypes 1.3 XML Type Representation, No Namespace, Schema file" removing default values for attributes. However it failed to update the contents of Annex A with contain the same XSD definitions.
    • The attribute value minOccurs="1" is unnecessary for element declarations because it matches the default value when the attribute is not specified. It should be removed from Annex A and the file "DDS XTypes 1.3 XML Type Representation, No Namespace, Schema file"
  • Reported: DDS-XTypes 1.2 — Fri, 8 Mar 2019 07:26 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Update Annex A and the "XML Type Representation, No Namespace, Schema file"

    Apply the corrections indicated in the issue description.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Duplication of sections 7.3.1.2.3 and 7.3.1.2.6

  • Key: DDSXTY13-52
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Sections 7.3.1.2.3 'Alternative Annotation Syntax' and 7.3.1.2.6 'Alternative Syntax' contain identical contents. It seems like the section was moved and one was not properly removed.

    One of this two sections should be deleted.
  • Reported: DDS-XTypes 1.2 — Wed, 28 Nov 2018 07:37 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Remove 7.3.1.2.6 'Alternative Syntax'

    It is better to keep 7.3.1.2.3 'Alternative Annotation Syntax' and remove 7.3.1.2.6 'Alternative Syntax' because section 7.3.1.2.3 references the alternative annotation syntax.

    Therefore the resolution of this issue should just remove section 7.3.1.2.6 'Alternative Syntax'
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Add a Need @data_representation annotation

  • Key: DDSXTY13-49
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Add the @data_representation annotation as proposed in the issue description. Also clean up the terminology when talking about PLAIN_CDR, PL_CDR, etc. refer to those as "encodings" rather than "representations"
  • Reported: DDS-XTypes 1.2 — Wed, 28 Nov 2018 04:01 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.3
  • Disposition Summary:

    Duplicates DDSXTY13-46

    Close as duplicate
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Need @data_representation annotation and clean terminology in 7.4.x

  • Key: DDSXTY13-46
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently the DataRepresentation (XCDR1, XCDR2, XML) is controlled by a Qos Policy on the DataWriter. This is good to allow run-time configurability and enable systems to evolve.

    However when defining data models for systems that will be deployed it may be important to allow that representation to be declared and restricted in the data-model. This may be needed such that the users of that data model can be sure to interoperate with the deployed system. This also supports the use-case where systems are deployed with code that support only one representation as may be the case in some resoure-constained systems.

    A proposed solution is to add an annotation:

    enum DataRepresentationKind {
    XCDR_AND_XCDR2,
    XCDR,
    XCDR2,
    XML
};

@annotation data_representation {
    DataRepresentationKind value default XCDR1_AND_XCDR2;
};

    If @data_representation is not specified then the default is XCDR_AND_XCDR2. This allows the representation to be configured on the DataWriter and DataReader DataRepresentationQos policy.

    If a value other than XCDR_AND_XCDR2 is specified, then that setting overrides the DataRepresentationQos that may have been set on the DataWriter or DaraReader.

    In addition the terminology for 7.4.x could be cleaned up a bit. Fist it cases about XCDR and XML as being "Data Representations" however later on it talks about PLAIN_CDR and DELIMITED_CDR, PL_CDR2 also as "representations". It may be better to use a different word for this to avoid confusion.

    Keep "Representation" for XCDR, XCDR2, XML, etc. This is consistent with the Qos policy and the main definitions. Use another word. For example "encoding" to talk about PLAIN_CDR, PL_CDR, etc.
  • Reported: DDS-XTypes 1.2 — Tue, 27 Nov 2018 02:31 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Define a @allowed_data_representation annotation

    Add an annotation that can be applied to types and modules that restricts the data representations that a type may use.

    The definition should be as proposed in the issue description.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Update Normative references to latest versions of IDL and DDS

Type compatibility rules for structs with keys

  • Key: DDSXTY13-64
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The compatibility for structure in section 7.2.4.4.8 'Aggregated Types' would make two structures that have a key member of type string compatible even if the keys had different maximum lengths.

    This is problematic. It would result in potentially aliasing different objects and also in different decisions on how the KeyHash is computed.
  • Reported: DDS-XTypes 1.2 — Thu, 6 Dec 2018 16:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.3
  • Disposition Summary:

    Duplicates DDSXTY13-21

    Duplicates DDSXTY13-21
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Restructure Section 7.2 "Type System" to include the annotation semantics & align with IDL 4.2

  • Key: DDSXTY13-40
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.2.2 should include all the Type-System concepts that are related to all the "relevant" annotations in IDL 4.2 (likely groups for "General Purpose", "Data Modeling", "Units and Ranges", "Data Implementation", and "Code Generation") in addition to extra concepts in XTYPES that are not part of IDL4 like Try Construct Behavior, Non-Serialized.

    After 7.2.2.6 Annotations there should be a section on the "Builtin Annotations" these should references the ones IDL 4.2 as well as the extra ones in XTYPES.

    Much of the text in existing section 7.3.1.2.1 should me moved to 7.2.x. These are general concepts independent of the use of IDL.

    Table 7.3.1.2.2 Using Built-in Annotations should be also moved to 7.2.2.x.

    In place of 7.3.1.2.1 there should be a table that maps the "builtin" annotations in the XTYPES type system to their IDL4 syntax. For the most part this references the corresponding annotation in IDL 4.2 except for the new ones introduced by XTYPES.

    7.3.2.x and Annex A should define how the builtin annotations are represented in XML.

    Annex B should be augmented with any missing annotations. It appears @default is missing from the COMPLETE TypeObject.
  • Reported: DDS-XTypes 1.2 — Tue, 25 Sep 2018 21:34 GMT
  • Disposition: Deferred — DDS-XTypes 1.3
  • Disposition Summary:

    Defer to the next RTF

    This reorganization is worthwhile but it would introduce a lot of changes that overlap with those of other issue resolutions. Therefore it is best deferred to the next RTF.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Rules for type compatibility are incomplete

  • Key: DDSXTY13-41
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Table 19, on the compatibility of STRUCTURE_TYPE it says:

    AND if T1 is appendable, then any members whose member ID appears both in T1 and T2 have the same setting for the ‘optional’ attribute and the T1 member type is strongly assignable from the T2 member type.

    This is missing the rule about members having that have the same ID must also have the same index. This rule was present in version rsion xtypes v 1.1 and somehow was lost in version 1.2.
  • Reported: DDS-XTypes 1.2 — Wed, 26 Sep 2018 03:22 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    *Edit Table 19, rule for STRUCTURE_TYPE *

    Edit Table 19, rule for STRUCTURE_TYPE adding that for APPENDABLE and FINAL the member indices must match.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Incomplete application of issue DDSXTY12-18 resolution

  • Key: DDSXTY13-24
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The resolution of DDSXTY12-18 was not applied correctly to section In Section 7.6.2.1.1 (DataRepresentationQosPolicy: Conceptual Model).

    According to that resolution the bullet below:

    • Readers belonging to implementations of XTYPES version 1.2 and later:

    Should appear directly above the 3 sub-bullets that start with:

      • Shall generate or include run-time code that can deserialize version 2 encodings.

    However in the final document that bullet is missing.
  • Reported: DDS-XTypes 1.2 — Tue, 15 May 2018 00:16 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Add the missing bullet to Section 7.6.2.1.1

    Add the missing bullet per issue description.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Further corrections

  • Key: DDSXTY13-12
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    7.2.1.1 (Type Evolution Example) pg 13 first para

    > [ ...] However, not all components that publish or subscribe data of this
    > type will be upgraded to this new definition of VehicleLocationType
    > (or if they will not be upgraded, they will not be upgraded at the same
    > time)

    • (or if they will be upgraded, they will not be upgraded at the same time)

    7.2.1.3 (Sparse Types Example) pg 14 first para

    > [...] In its local programming language (say, C++ or Java), the
    > application can assign a pointer to null to omit a value for these fields.

    • the application can assign null to a pointer to omit [...]

    7.2.2.2 (Primitive Types) pg 18 Table 3 description for INT_16_TYPE

    > Signed integer minimally capable of representing values in the range
    > -32738 to +32737.

    • -32768 to 32767.

    7.2.2.2.1.2.1 (Use of Unicode) pg 20 fourth para

    > [...] The UTF-8 representation ISO-8859-1 characters that are not in the
    > ASCII subset uses two 8-bit code units.

    • The UTF-8 representation of ISO-8859-1 characters [...]

    7.2.2.2.1.2.5 (CHAR_16_TYPE) pg 21 Rationale second para

    > [...] Restricting to the BMP ensures that each coodepoint is [...]

    • codepoint

    7.2.2.7 (Try Construct behavior) pg 42 first para

    > [...] Similar to the structure examples there exist be objects of type
    > SEQ1024 [...]

    • [...] there may exist objects of type SEQ1024 [...]

    7.2.4.1 (Constructing objects of one type from objects of another type)
    pg 46 Table 13 column "Type compatibility" bottom

    > All objects of type T1 can either be used to
    > construct an object of type T1 or reliably de-
    > tected that that cannot initialize T1. .

    Please check - my guess is:

    • [...] construct an object of type T2 or it can be
      reliably detected which objects of type T1 cannot initialize T2.

    7.2.4.4.5.1 (Example: Strings) pg 49 first para

    > [...] If a
    > consumer of strings of narrow characters were to attempt to consume
    > that string, it might read
    > consider the first byte of the first character [...]

    • Omit the word "read" :
      [...] were to attempt to consume that string, it might consider [...]

    Table 19 (Definition of the is-assignable-from relationship for aggregated types)
    pg 53 second column fourth (i.e. last) bullet

    > If T1 (and therefore T2)
    > extensibility is final then the set of
    > labels are identical.

    • [...] then the set of labels is identical.

    7.3.1.1.1 (Backward Compatibility with Respect to Type Definitions)
    pg 60 bullet "Group of Annotations" fourth sub-bullet

    > * Code Generation (sub clause 8.3.5 [IDL41]) his specification retains
    > well-
    > established IDL type definition syntax, such as enumeration, structure,
    > union, and
    > sequence definitions.

    Appears to be a formatting problem, I think the last part of that phrase should be outside and after the end of the bullet enumeration:

    • Code Generation (sub clause 8.3.5 [IDL41])

    This specification retains well-established IDL type definition syntax, such as enumeration, [...]

    7.3.1.2.2 (Using Built-in Annotations) pg 70 first sentence

    > The application of the annotations listed above is restricted to the
    > elements of specified in Table 21.

    • [...] is restricted to the elements of IDL specified in Table 21.

    7.3.1.10 (Structure Types) pg 76 first sentence

    > Structures as described in this specification are in this specification are
    > fully compatible with the IDL constructs of the same name.

    • Structures as described in this specification are fully compatible [...]

    7.3.1.11 (Union Types) pg 76 first sentence

    > Unions as described in this specification are in this specification are
    > fully compatible with the IDL constructs of the same name.

    • Unions as described in this specification are fully compatible [...]

    7.3.2.4.3 (Map Types) pg 80 first bullet

    > * The map’s bound, if any, shall be indicated by the mapMaxLength
    > attribute. This attribute is required for all map types.

    For more fluent reading, I suggest:

    • The map's bound shall be indicated by the mapMaxLength attribute.
      This attribute is required for all map types.
      In case of an unbounded map, mapMaxLength shall be set to "-1".

    7.3.2.4.3 (Map Types) pg 81 non-normative example:

    > <struct name="MyStructure">
    > <member name="my_unbounded_maps_of_integers_to_floats"
    > type="int32"
    > mapKeyType="float32"
    > mapMaxLength="-1"/>

    The values for "type" and "mapKeyType" are swapped, they should be:

    • type="float32"
    • mapKeyType="int32"

    7.5 (Language Binding) pg 133 top of page (2nd sentence)

    > The main characteristics and motivation for each of these binding are
    > described in Table 41.

    • [...] for each of these bindings are described in Table 41.
  • Reported: DDS-XTypes 1.2b1 — Sun, 3 Dec 2017 21:11 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Perform the corrections suggested in the issue description

    Perform the corrections indicated in the issue description.
    Note that some of the issues indicated in the description were already resolved as part of the editorial corrections performed by OMG editors. This issue addresses the ones that were not caught in that step.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

DynamicType / DynamicTypeBuilder multiplicity of members

  • Key: DDSXTY13-11
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    In the DDS-XTypes 1.2beta1 document, the UML class diagram in section 7.5.2.8 Figure 30 on p. 175 does not show the multiplicity relationship between DynamicType and DynamicTypeMember for the case of aggregated types.
    In other words, the fact that a DynamicType struct/union/valuetype may have more than one member is not visible in the diagram.

    The section 7.5.2.9 DynamicTypeBuilder does define an operation add_member which can be used to add members to aggregated types. However, DynamicTypeBuilder also does not provide a method for iterating over the members thus added.

    If it is intended that the management of and iteration over the sequence of DynamicTypeMembers shall lie outside of DynamicType / DynamicTypeBuilder, I suggest adding an explanation to that end.
  • Reported: DDS-XTypes 1.2b1 — Sun, 3 Dec 2017 19:47 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Update Figure 30 'Dynamic Type' and operations of DynamicTypeBuilder and DynamicType

    Update the of multiplicity of DynamicTypeMember in Figure 30 'Dynamic Type' (section 7.5.2.8) from "0..1" to "0..*"

    Add operations to 7.5.2.9 'DynamicTypeBuilder' that allow figuring out the number of members and iterate over them.
    Add operations to 'DynamicType' to find the number of members and iterate over them.

    Order operations alphabetically.
  • Updated: Tue, 8 Oct 2019 17:55 GMT
  • Attachments:

Add support for signed and unsigned 8-bit integers

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

    The DDS Type System does not provide a way to represent signed and unsigned 8-bit integers. IDL 4.2 has introduced the int8 and uint8 types for this purpose, but DDS-XTYPES is still missing those in the model.

    Support for 8-bit signed and unsigned integers is required by some RFP submissions, such as the OPC UA/DDS Gateway RFP.
  • Reported: DDS-XTypes 1.2 — Thu, 30 Nov 2017 14:42 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Include support for signed and unsigned 8-bit integers

    Add two primitive types: Int8 and UInt8 (INT8_TYPE and UINT8_TYPE) to the type system in section 7.2.x

    Add these two types wherever Integer Types are used.

    Use the IDL int8 and uint8 to represent them in in the IDL Type Representation (section 7.3.1.x).

    In the XML Type Representation (section 7.3.2.x) use "int8" and "uint8" as the XML Type Representation name (Table 26).

    Add support for these two types to the TypeIdentifier and TypeObject (section 7.3.4.x)

    Add the rules to serialize those types to 7.4.x
    Add the language mappings to 7.5.1.1.x

    Add these two types to Annex A, Annex B, Annex C.

    Mention in F.1 that legacy implementations do not support int8 and uint8.
  • Updated: Tue, 8 Oct 2019 17:55 GMT
  • Attachments:

XSD for XML type representation should not specify default values for attributes representing annotations

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

    The XML type representation (Section 7.3.3) has an associated XSD that defines the legal XML documents that define DDS Types.

    In the XML type representation builtin annotations on members appear as "attributes" on the element that describes the member. For example see example in section 7.3.2.5.1.2 (Members):

    <struct name="structMemberDecl">
   <member name="my_key_field" type="int32" key="true" optional="false"/>
</struct>

    These builtin annotations (key, optional), have default values when they are not present. This is defined in the IDL4+ specification. For example when the annotation "key" is not present, the (default) value is "false" when annotation "optional" is not present, the (default) value is "false". There is also a "default" value when the annotation is present with no parameters, but this is not allowed in the XSD.

    According to the XSD syntax, e.g. see https://www.w3schools.com/xml/schema_simple_attributes.asp

    The "default" value specified for an attribute is the value interpreted when the attribute is not present. Therefore we have two options:

    • Have the XSD specify default values for these attributes to match the "IDL4+ defaults when the attribute is not present
    • Have the XSD specify no default value.

    Currently this is not done correctly for some annotations. For example the XSD for structure members has wrong defaults for all the attributes:

      <xs:complexType name="structMemberDecl">
    <xs:complexContent>
      <xs:extension base="memberDecl">
       <xs:attribute name="id"
                     type="memberId"
                     use="optional"/>

        <xs:attribute name="optional"
                      type="xs:boolean"
                      use="optional"
                      default="true"/>
        <xs:attribute name="mustUnderstand"
                      type="xs:boolean"
                      use="optional"
                      default="true"/>
        <xs:attribute name="nonSerialized"
                      type="xs:boolean"
                      use="optional"
                      default="true"/>
        <xs:attribute name="key"
                      type="xs:boolean"
                      use="optional"
                      default="true"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

    However it seems like the best solution is to remove the specification of a default value from the XSD. The problem is that when the default is specified the XSD parsers will fill the default value even if the attribute is not specified and it becomes impossible for the application that uses the parser to know if the attribute was there or not in the first place. This would make it impossible to transform between IDL and XML and back to IDL and get the same result back because all annotations would appear present to the XML parser even if they were not entered buy the user.

    Therefore we recommend removing the specification of 'default" value for all XML attributes that correspond to builtin annotations. This should be done both in Annex A and the machine readable dds-xtypes_type_definition_nonamespace.xsd
  • Reported: DDS-XTypes 1.2 — Mon, 24 Apr 2017 16:16 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    *Remove the 'default" value for all XML attributes that correspond to builtin annotations. *

    For the reasons listen in the issue description the XSD should not specify any default values for XSD attributes that correspond to builtin annotations.
  • Updated: Tue, 8 Oct 2019 17:55 GMT
  • Attachments:

Algorithm to compute autoid is missing from the specification

  • Key: DDSXTY13-2
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not define how memberIDs are computed in the case where the @autoid (or @hashid) annotations are used. This is needed for interoperability.

    Section 7.3.1.2.1.1 (Member IDs) specifies there are thee ways to set them:

    • Automatically following a progression that starts from the most-recently specified member ID.
    • Using the @id annotation
    • As a "hash" on the member name when @autoid(HASH) is specified
    • as a "hash" on a string-parameter when @hashid("string-parameter") is specified

    The use of @autoid refers to sub clause 8.3.1.2 in [IDL41]). But there also there is no specification of how the hash should be computed. Only that a "hashing" algorithm should be used.

    IDL working group discussed this and the preference was to leave it unspecified in IDL4 and instead put it in XTYPES or whichever specification depends on these IDs.

    A proposal would be to use an MD5 (as this is already used for key hashing).
    This needs to be done in a platform-independent manner, for example hashing a serialized representation of the string using a pre-specified endianness. Also per section 7.2.2.4.4.3 (Member IDs) the value/range must be representable in 28 bits.
  • Reported: DDS-XTypes 1.2 — Fri, 7 Apr 2017 00:44 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Use the same hash algorithm specified for the TypeObject (Minimal)

    The (normative) IDL for the TypeObject (Minimal Representation) already requires hashing of member names. This is exercised in the (non-normative) example serializations included as part of XTYPES 1.2.

    The algorithm used for this hashing of member names is described as a comment in the dds-xtypes_typeobject.idl

        // First 4 bytes of MD5 of of a member name converted to bytes
    // using UTF-8 encoding and without a 'nul' terminator.
    // Example: the member name "color" has NameHash {0x70, 0xDD, 0xA5, 0xDF}
    typedef octet NameHash[4];

    Although this hash algorithm is only specified for the TypeObject and not the MemberId it would make things simpler to use the same algorithm for the @autoid and @hashid. It is also more efficient that doing a CDR serialization because it saves the length and the trailing NUL.

    We still need to specify how to transform the octet[ 4 ] NameHash into a integer memberId with 28-bits of precision so we can all the 4 bits of flags specified in the MemberId format. This basically requires interpreting the NameHash as having a specific endianness.

    Section 7.6.2.3.3 'TypeLookup Types and Endpoints' provides some examples of NameHash that use Big Endian. For example it says that @hashid("getTypes") is a long with value = 0xd35282d1. Note that the md5("getTypes") is the octet sequence d35282d177f1c8e43144c7e65820d7ae. So value = 0xd35282d1 corresponds to the first 4 bytes interpreted as a BigEndian.

    Therefore an Endianess needs to be specified such that an octet[ 4 ] containing the first 4 bytes of the MD5 can be interpreted as an integer. For example if we had chosen Little Endian the NameHash =

    {0x70, 0xDD, 0xA5, 0xDF}

    would be interpreted as the integer: 0xDFA5DD70.

    We still need to zero 4 bits of this to truncate it to the 28 bits of the memberId and allow the addition of the must-understand flag (M_FLAG) and the length code (LC).

    Table 39 in section 7.4.3.3 specifies that the enhanced mutable header is computed as:

    EMHEADER1 =  (M_FLAG<<31) + (LC<<28) + M.id

    This means that we need to clear the 4 most significant bits from the member id (bits 29-32).

    The resolution is to explicitly provide the algorithm used to compute the member ID from a NameHash. This algorithm interprets the NameHash as a Big Endian integer. Using C pseudo code the construction of the member_id from a NameHash would be as follows:

        uint32_t  hash_as_int;
    uint32_t  member_id;

#ifdef (MACHINE_IS_BIG_ENDIAN)
    hash_as_int = *((uint32_t *) NameHash);
#else
    hash_as_int = *((uint32_t *)EndianessSwap4Bytes(NameHash));
#endif

// Truncate to 28 bits removing the 4 most significant bits
member_id = hash_as_int & 0x0FFFFFFF;

    In the case of member name "color" we would have:

    NameHash = { 0x70, 0xDD, 0xA5, 0xDF } 
hash_as_int = 0x70DDA5DF
member_id  = 0x00DDA5DF

    Assuming we have M_FLAG = 1, LC = 1, we would have:

    EMHEADER1 = 0x90DDA5DF

    EMHEADER1 is then serialized on the wire using Little Endian format (as specified by the TypeObject serialization) so the bytes on the wire would end up being:

    {0xDF, 0xA5, 0xDD, 0x90}


    Alternatively (currently favored by Task Force)
    We could define the transformation of NameHash to MemberId using LittleEndian. This will save the byte swap done at serialization time. An also save the initial on in LittleEndian machines (which are the most common). So this seems a more optimized approach.''

    In this case member name "color" we would have:

    NameHash = { 0x70, 0xDD, 0xA5, 0xDF } 
hash_as_int = 0xDFA5DD70
member_id  = 0x0FA5DD70

    If we go with this we need to change the examples in section 7.6.2.3.3 'TypeLookup Types and Endpoints'

    NameHash("getTypes") = {d3, 52, 82, d1}
    NameHash("getDependencies") = {31, fb, aa, 35}
    Also change the example to be unsigned long:

    const unsigned long TypeLookup_getTypes_Hash = 0x018252d3; // @hashid("getTypes")
const unsigned long TypeLookup_getDependencies_Hash = 0x05aafb31; //@hashid("getDependencies");
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Inconsistencies and missing items

  • Key: DDSXTY13-1
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 7.2.3, Table 12 in the rows for "Collection Types", "String Types", and "Primitive Types" should add that "For these types the extensibility kind has no effect in the type matching."

    In Section 7.2.3, Table 12 the row for "Bitmask" says it is always final. This seems limiting, should be like Enum and allow "final" or "appendable"

    In figure 11, 12 and the XSD it shows extensiblity_kind=FINAL for enumerations. This is wrong and inconsistent with 7.2.3.

    The XSD does nor allow setting the "extensibilty" for the "enumDecl". It should.

    In the submission document, Table 21 "IDL Built-in Annotations" does not list where the annotation @hashid can be applied.
    Also, the @id annotation is can be applied to both Structure members and union members (except union discriminator), so it should be moved to the second row on the table.

    In section 7.3.4.4 'Minimal TypeObject' the last paragraph starts with "The complete TypeObject" it should start with "The minimal TypeObject"

    In Annex B in the IDL comment for AppliedBuiltinMemberAnnotations refers to “@hash_id” as opposed to “@hashid”, which is the actual annotation name. Every reference to “@hash_id” should be modified to refer to "@hashid."

    Typo in section 7.2.3 (Type Extensibility and Mutability) it says "APENDABLE" instead of "APPENDABLE"

    Typo in XSD says "include2" instead of "include"
  • Reported: DDS-XTypes 1.1 — Thu, 16 Mar 2017 00:38 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Perform the corrections listed in the issue description

    Perform the corrections listed in the issue description
  • Updated: Tue, 8 Oct 2019 17:55 GMT
  • Attachments:

Clarify which of the options bits are set to indicate padding bytes

  • Key: DDSXTY13-18
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    As the spec is currently written, section 7.6.2.1.2
    'Use of the RTPS Encapsulation Identifier', it is ambiguous as to which bits are used to encode the padding bytes.

    RTPS 2.4 is redefining the options field to be an array of two octets rather than a ushort. So XTypes should specify that the lower-order two bits of options[1] are used to encode the number of padding bytes.
  • Reported: DDS-XTypes 1.2 — Wed, 7 Mar 2018 01:49 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Modify 7.6.2.1.2 'Use of the RTPS Encapsulation Identifier'

    Modify 7.6.2.1.2 'Use of the RTPS Encapsulation Identifier' to indicate that the options field is octet[2] and that the bits using for padding are the least significant bits of the second byte:

    0...2...........8...............16..............24..............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|   representation_identifier   |               |            X X| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Endianess bit in DHEADER causes innefficiencies

  • Key: DDSXTY13-29
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The presence of a bit indicating the endianess in the DHEADER causes serious inefficiencies in the serialization.

    • When mutable encapsulation is used, the length of the member can be shared between the MemberHeader and the MemberSerialization in the case where the MemberSerialization starts with a length. This would be the case for strings and octet sequences. If the DHEADER did not have the EndianessBit then this optimization would also apply to the @appendable members which is a very common use-case.
    • The processing of the Endianess bit (pack/unpack) and check takes CPU time. This would be avoided if the Endianess bit is not present.

    The reason why the Endianess Bit was put was to support embedding serialized data inside other serialized data even if the pieces came from different endianess. This is not a common use-case. Supporting this edge case is not worth hurting the performance of the common case.

    The proposal is to remove the Endianess Bit from the DHEADER.
  • Reported: DDS-XTypes 1.2 — Thu, 6 Sep 2018 02:10 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Remove E_FLAG from DHEADER

    Redefine the DHEADER used for Appendable and Mutable types to only contain the length of the serialized object that follows (O.ssize).

    This affects the following parts of the specification:

    • Table 39 ('Functions operating on objects and types'. The entry for DHEADER shall be changed to just say DHEADER(O) = O.ssize
    • Section 7.4.3.4.1 'Delimiter Header (DHEADER)' remove mentions of the
      E_FLAG.
    • Section 7.4.3.5.3 'Complete Serialization Rules'. Replace "DHEADER(O, <E>)" with "DHEADER(O)" this affects rules (9), (12), (15), (21), (27), (30).
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Annotation for denoting topic types

  • Key: DDSXTY13-17
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    In order to use an IDL type as a topic type, some additional methods are required to be generated (such as methods for creating DataReaders and DataWriters).

    Implementations have invented their own mechanisms in this area:

    • One product might support the notion that by default all structured types can be used as topic types, defining a mechanism to selectively switch off that assumption
    • Another product might require a pragma to be used for switching on the additional code generation for topic types

    A built in annotation should be added for distinguishing topic types from non topic types.
  • Reported: DDS-XTypes 1.2b1 — Mon, 12 Feb 2018 06:46 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Introduce a @DDSTopic annotation that allows marking DDS Topic Types

    Define a new annotation that can be used to indicate that certain types are intended to be used as DDS Topic Types.

    There are some related precedents:

    DDS-RPC

    This @DDSTopic annotation parallels the @DDSService annotation defined in DDS-RPC. The definition is of @DDSService 

    @annotation DDSService {
    string name default "";
};

    Note that DDS-RPC also defines the following annotations:

    module dds { module rpc {
@annotation DDSRequestTopic {
    string name;
};
@annotation DDSReplyTopic {
    string name;
};

};};

    IDL 4.2
    This specification which was released after DDS-RPC introduced a new notation for marking services:

    @annotation service {
string platform default "*";
};

    In IDL42 there are three pre-defined values of for the platform:

    • "CORBA" indicates that the service should be made accessible via CORBA.
    • "DDS" indicates that the service should be made accessible via DDS.
    • "*" (an asterisk) indicates any platform. This is the default value.

    So a definition that follows what was done in DDS-RPC could be:

    @annotation DDSTopic {
    string name default "";
};

    Whereas a definition that follows what was done in IDL 4.2 could be:

    @annotation topic {
   string platform default "*";
};

    Or some other name instead of "topic", perhaps "message" if we consider it sufficiently generic:

    Note that all MQTT (http://mosquitto.org/man/mqtt-7.html), Amazon Pub-Sub (https://aws.amazon.com/pub-sub-messaging/), and Google PubSub (https://cloud.google.com/pubsub/docs/overview) use the concept of messages sent to a Topic.

    If we used a @topic definition in IDL and we wanted to be able to specify the Topic name would need to combine it with another annotation (in DDS-XTYPES, not IDL) to do this. For example @DDSTopicName. So finally we would have:

    IDL4 -> @service , @topic. These allow specifying the platform, e.g. @service("DDS") or @topic("DDS"). If not parameter is specified the default is @service("*"), @topic("*").
    Then in DDS-RPC we have @DDSServiceName("MyService"), @DDSRequestTopic("MyServiceRequest"), @DDSReplyTopic("MyServiceReply")
    Ans in DDS-XTYPES we have @DDSTopicName("MyTopic").

    Alternatively we could try to eventually push all this into the IDL annotations. For example:

    @annotation service {
     string platform default "*";
     string name default "";
     string request_topic default "";
     string reply_topic default "";
};

@annotation topic {
     string platform default "*";
     string name default "";
};

    So for now we could add @topic to the DDS-XTYPES and push it to IDL4 later.

    How would annotations with parameters appear in XML? Is it legal to do something like:

    <struct name="Shape"  topic.name="Square" topic.platform="DDS">
    <member name="color" type=string"/>
 </struct>
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Typographical corrections and minor rewordings

  • Key: DDSXTY13-5
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    > 2.2.2 Basic Network Inteoperability Profile

    • "Interoperability"

    > 7.2.3 Type Extensibility and Mutability
    > [...]
    > • A type may be APENDABLE,

    • "APPENDABLE"

    > [...]
    > It is summarized more enerally in Table 12.

    • "generally"

    > 7.2.4.4.1 Assignability of Equivalent Types
    > If two types T1 and T2 are equivalent according to the MINIMAL relation (see Section 7.3.4.7),
    > then thery are mutually assignable,

    • "they"

    > Table 15 – Definition of the is-assignable-from relationship for primitive types
    > [...]
    > UINT64_TYPE
    > BITMASK_TYPE if and only if
    > T2.bound is between 33vand
    > 64, inclusive.

    • "between 33 and 64"

    > Table 20 – Alternative Type Representations
    > [...]
    > XSD [... 2nd column]
    > [...] No direct support for many of the
    > contructs (e.g keys) or the types in
    > the type model

    • "constructs"

    > 7.3.4.6.2 Hash TypeIdentifiers
    > Some TypeIdentifiers include within (directly or indirectly) hashes of one of mre
    > TypeObjects.
    Phrase is unclear, please reword.

    > 7.3.4.6.4 Indirect Hash TypeIdentifiers
    > These are the HASH [...] using a hash
    > TypeIdentifiers . They are distinghished byt:

    • "They are distinguished by:"

    > 7.4.1.1.1 Primitive types
    > [...]
    > • An endianness byte swap shall be performed in case the native system endianness is dif-
    > ferent from the one currently configured in the XCDR stream (XCDR.cendien).

    • "XCDR.cendian"
  • Reported: DDS-XTypes 1.2b1 — Sun, 10 Sep 2017 19:05 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Correct the typos

    Perform the typographical corrections indicated in the issue description.
    Note that some of the issues indicated in the description were already resolved as part of the editorial corrections performed by OMG editors. This issue addresses the ones that were not caught in that step.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Clarify valid ranges of memberIDs

  • Key: DDSXTY13-27
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.5.2.5 (MemberId) states that

    The type MemberId is an alias to UInt32 and is used for the purpose of representing the ID of a member of a structured type.

    However it is clear from the serialization rules in 7.4.3.4 and specifically the definition of EMHEADER1 in table 39:

    EMHEADER1 = (M_FLAG<<31) + (LC<<28) + M.id 

Where:
M_FLAG is the value of the Must Understand option for the member
LC is the value of the Length Code for the member.

    That MemberId are restricted to a 28-bit range. This should be clarified in the specification.

    Furthermore the specification should make it clear that the M_FLAG is not introducing a separate "space" of member IDs. So a type cannot have two members with the same value of the 28-bit memberID even if one has M_FLAG=1 and the other M_FLAG=0.

    Additionally in section 7.4.1.2.1 (Interpretation of Parameter ID Values) where it talks about PID_EXTENDED it states:

    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. The flags occupy the 4 most significant bits of the UINT32 value. The flags are combined with the memberId as shown below:
    FLAG_1 = 0x80000000
    FLAG_2 = 0x40000000
    FLAG_3 = 0x20000000
    FLAG_4 = 0x10000000
    eMemberHeader = FLAG_1 + FLAG_2 + FLAG_3 + FLAG_4 + memberId

    This text does not specify the reserved bit for the "FLAG_MUST_UNDERSTAND" and also in the case this is used for RTPS Discovery, the mapping for the "FLAG_IMPL_EXTENSION".

    For compatibility with existing deployed systems the specification should state that FLAG_1 is the FLAG_IMPL_EXTENSION and FLAG_2 is FLAG_MUST_UNDERSTAND.
  • Reported: DDS-XTypes 1.2 — Fri, 6 Jul 2018 00:09 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    *Add a note to 7.5.2.5 'MemberId' indicating the range of member IDs. *

    In section 7.5.2.5 (MemberId) add a reference to 7.2.2.4.4.4.4.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Setting of @default with @optional members

  • Key: DDSXTY13-26
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The default value of an member defined with @optional is "not set".

    However it is possible to also apply the @optional annotation. In this situation should the value specified in the @default override the "not set" default?

    For example if MyStruct is specified as:

    @mutable
struct myStruct {
  long m1;
  @optional @default(2) long m2;
}

    Would the default value of m2 be "not set" or 2?

    At first glance it would seem that @default should override since if that was not the desired behavior then the user could just as well omit it. On the other hand, there seems to be a bit of ambiguity. Imagine m2 is not set by the sender, would the receiver then get "not set" or 2. If it gets 2, then how would a user ever detect the lack of m2 being set which is one of the goals of optionality.
  • Reported: DDS-XTypes 1.2 — Tue, 3 Jul 2018 15:27 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Do not allow a @default on an @optional member

    The @optional annotation is incompatible with the @default annotation. When both are set it should cause an error or at least a warning that @default is ignored.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Reseting the alignment after Encapsulation Header

  • Key: DDSXTY13-20
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    RTPS version 2.3 (see https://issues.omg.org/browse/DDSIRTP23-63) specifies that the alignment should be reset after the encapsulation header.

    Consequently the serialization rules in 7.4.3.5.3 should be updated to include this.
    Specifically in rule (1) after:

    << PUSH( MAXALIGN = MAXALIGN(<eversion>) )

    We should add:

    << PUSH( ORIGIN=0 )
  • Reported: DDS-XTypes 1.2 — Fri, 20 Apr 2018 11:45 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    In section 7.4.3.5.3, rule (1) add alignment reset

    Perform the change suggested in the issue description.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Inheritance rules not sufficient regarding keys and memberID assignment

  • Key: DDSXTY13-23
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    XTYPES should specify that if a type declares key members then derived types cannot add additional key members.

    The reason is that the derived type will never be compatible with the base type according to the compatibility rules so there is no purpose on allowing that inheritance which would mislead the user.

    Semantically it seems that extending the key breaks the substitution principle where a derived class can be used in place of a base-class anywhere. If we allowed key extension two different objects could appear to be the same when viewed as a "base class"

    Additionally in section 7.3.1.2.1.1 'Member IDs' there is no mention of how inheritance impacts the automatic assignment of member IDs.
  • Reported: DDS-XTypes 1.2 — Fri, 20 Apr 2018 13:02 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Specify rules for inheritance

    The rules for inheritance could be added to a subsection following *7.2.2.4.4 'Aggregated Types'*. This new subsection should state that:

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

    • The derived structure either has same extensibility kind or leaves the extensibility kind unspecified
    • The derived type does not have a member with the same name or the same memberId as the base type or any of the ancestor types (i.e. recursively applying this rule to the parent)
    • The derived type does define any key fields. Is this really what we want to do. Will it break some definition where the "base type" is just being reused as a "header"? All to think about it and come up with a preferred approach.

    Also mention in 7.3.1.2.1.1 'Member IDs' that the memberId are continuing from the base class.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Organization of section 7.2.2.4.4 is confusing

  • Key: DDSXTY13-43
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.2.2.4.4 'Aggregated Types' has a confusing organization of its sub-sections. It mixes at the same level description of common aspects of Aggregated types (e.g. members names, types, properties like being optional etc). With the classification of 'Aggregated Types' into "Structures' and 'Unions'.

    Moreover the concept of "member index" is not explicitly defied even if it appears in the figures and UML model. The text does talk about a "declaration order" for members but does not tie it to the "member_index" concept.

    It would be better if the subsections were reorganized. Rather than:

    7.2.2.4.4.2 Structure Types
    7.2.2.4.4.3 Union Types
    7.2.2.4.4.4 Member IDs
    7.2.2.4.4.5 Members That Must Be Understood by Consumers
    7.2.2.4.4.6 Optional Members
    7.2.2.4.4.7 Key Members

    It would be better if it was:
    7.2.2.4.4.1 General
    7.2.2.4.4.2 Structure Types
    7.2.2.4.4.3 Union Types
    7.2.2.4.4.4 Members of an Aggregated Type
    7.2.2.4.4.4.1 Member Name
    7.2.2.4.4.4.2 Member Type
    7.2.2.4.4.4.3 Member Index
    7.2.2.4.4.4.4 Member ID
    7.2.2.4.4.4.5 Must Understand Members
    7.2.2.4.4.4.6 Optional Members
    7.2.2.4.4.4.7 Key Members

    This reorganization should be applied before other issue resolutions that affect the section as they would benefit from the more logical section numbering.
  • Reported: DDS-XTypes 1.2 — Wed, 7 Nov 2018 18:21 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Reorganize section 7.2.2.4.4 as suggested in the issue description

    Apply the suggested reorganization
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Remove Endianness bit from DHEADER

  • Key: DDSXTY13-36
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Redefine the DHEADER used for Appendable and Mutable types to only contain the length of the serialized object that follows (O.ssize).

    This affects the following parts of the specification:

    • Table 39 ('Functions operating on objects and types'. The entry for DHEADER shall be changed to just say DHEADER(O) = O.ssize
    • Section 7.4.3.4.1 'Delimiter Header (DHEADER)' remove mentions of the
      E_FLAG.
    • Section 7.4.3.5.3 'Complete Serialization Rules'. Replace "DHEADER(O, <E>)" with "DHEADER(O)" this affects rules (9), (12), (15), (21), (27), (30).
  • Reported: DDS-XTypes 1.2 — Tue, 25 Sep 2018 02:38 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.3
  • Disposition Summary:

    Close because it duplicates DDSXTY-29

    Duplicates DDSXTY-29
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Ambiguity in Table 9 and Obsolete language in section 7.3.1.2.1.10

  • Key: DDSXTY13-32
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The first paragraph 7.3.1.2.1.10 (Default Literal for Enumeration) says:

    Normally the default value for an object of a type is pre-defined based on the generic rules based on the characteristics of the type. For example, for an integer it would be the value zero and for an enumeration it is the literal with the lowest member ID.

    This language is obsolete. In XTYPES 1.2 Enumerated types are not considered to have memberId. Only AggregatedTypes have memberIds.

    Instead this paragraph should reference Table 9 (Table 9 – Default values for non-optional members). Which in the case of the enumeration says it is the first value in the enumeration.

    In addition, Table 9 (Default values for non-optional members) on the row for Enumerations says the default is:

    The first value in the enumeration.

    This is a bit ambiguous. Most likely it should be interpreted as the first literal that appears in the enumeration. But the word "value" may be interpreted by some as meaning the "lowest value" of any literals in the enumeration. It shuld be reworded to avoid confusion.
  • Reported: DDS-XTypes 1.2 — Sat, 22 Sep 2018 00:03 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Update Table 9 and section 7.3.1.2.1.10

    Update the text as suggested in the issue description.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Compatibility of Enum should be allowed even if there is just one common literal

  • Key: DDSXTY13-42
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The compatibility rule for ENUM_TYPE Table 18 'Definition of the is-assignable-from relationship for bitmask and enumerated types' states:

    • If extensibility is final the set of literals should be identical. Otherwise the two types should have at least one other literal (in addition to the default one) in common.

    This will break types that were compatible in xtypes v1. Namely enumerated types that just had one literal in common.

    Defining enumerations with a single literal which is then expanded is a common patten in a surprising number of applications. So this change is quite disruptive.

    The proposal is to not require the minimum of two literals in common. In other words change the quoted paragraph to:

    • If extensibility is final the set of literals should be identical.

    In addition some people dislike the fact that we make enums that have different default values incompatible. This will make two enums like the ones shown below incompatible. There is a strong opinion that this will break a lot of existing systems:

    enum Enum1 {
   @value(1) RED,
   @value(2) BLUE
};

enum Enum2 {
   @value(2) BLUE,
   @value(1) RED
};

enum Enum3 {
   @value(2) BLUE,
   @value(1) RED,
   @value(0) ORANGE
};

    So the proposal is to also remove the requirement:

    • The default literal has the same value.

    Lastly there question/request to have the TypeEnforcementPolicy attribute ignore_member_names apply to Enum as well... Alternatively it could be a different policy attribute, e.g. ignore_enum_literal_names.
    We have several customers that have this requirement.
  • Reported: DDS-XTypes 1.2 — Wed, 26 Sep 2018 03:39 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Modify compatibility for enum types and non-final extensibility

    Apply the changes suggested in the issue description.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Union discriminator value without associated member

  • Key: DDSXTY13-10
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    The DDS-XTypes 1.2-beta1 document section 7.2.2.4.4.2 (Union Types) on page 34 first paragraph states:

    > [...]
    > (Note that it is not required for every potential discriminator value to be
    > associated with a member.)

    Supporting this, 7.4.3.5.1 (Notation used for the match criteria) on p.121 states:

    > O : UNION_TYPE An object "O" of a Union type as defined in 7.2.2.4.4.2
    > [...]
    > * O.selected_member is the member of the union selected
    > based on the value of the discriminator. Note that certain
    > discriminator values may select no member.

    However, 7.4.1.2.3 (Omission and Reordering of Members of Aggregated Types) on page 110 third para states:

    > Because union members are identified based on a discriminator value,
    > the value of the discriminator member must be serialized before the
    > value of the current non-discriminator member.
    > Neither member value may be omitted.

    I suggest replacing "Neither member value may be omitted" by:

    " The discriminator value may not be omitted.
    If the discriminator value has an associated member then the member value may not be omitted. "

    Section 7.5.2.11.6 (Operation: get_item_count) on page 185 states:

    > The "item count" of the data depends on the type of the object.
    > * If the object is of a union type, return the number of members in the
    > object. This value will always be two: the discriminator and the current
    > member corresponding to it.

    I suggest replacing the last sentence by:

    " This value will be two if the discriminator value has a corresponding member. It will be one if the discriminator value has no corresponding member. "
  • Reported: DDS-XTypes 1.2b1 — Wed, 29 Nov 2017 16:12 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Modify the 7.4.1.2.3 description of union serializarion

    Indicate that in the case of a union the only mandatory thing to serialize is the discriminator. The member may be omitted if no branch is selected.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Provide a more efficient serialization for short strings and sequences

  • Key: DDSXTY13-16
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    XCDR serialization rules for strings and sequences serialize the length as an uint32 ahead of serializing each of the elements.

    For short strings and sequences this can be a significant overhead. For example a 4 element sequence of octets would use 4 bytes for the sequence length and 4 bytes for the sequence content. That is 100% overhead. Worse since the serialized uint32 length must be serialized at a 4-byte offset, in some cases 3 additional padding bytes would be required. This would result on 7 bytes of overhead for 4 bytes of payload, or 175% overhead!!

    It would be better is short sequences, that is those whose maximum length is less than 255 could be serialized using an uint8 length instead of a uint32. With this the overhead of the previous example would be 1 byte (or 25%).

    An additional optimization would be to just serialize the string characters without the terminating NUL since this information is redundant with the length.

    This encoding would affect type compatibility in that a "short" sequence would not be compatible with a longer one. This is different from the current situation where string/sequence length would not affect compatibility. With the new encoding short strings would be compatible with each other (regardless of their length) and likewise long strings would also be compatible with each other (regardless of length) as well as compatible with unbounded ones.

    So therefore we would need an annotation to indicate we want to serialize it as a short string... Perhaps we could reuse @bit_bound. For example:

    struct ShapeType {
    @bit_bound(8) string<32> color;
    long x;
    long y;
};

    Disadvantage is that the only valid values when applied to strings/sequences would be @bit_bound(8) and @bit_bound(32).

    Alternatively we could also a new annotation like @compact, @pack, @short, @small, ...
  • Reported: DDS-XTypes 1.2 — Wed, 17 Jan 2018 11:29 GMT
  • Disposition: Deferred — DDS-XTypes 1.3
  • Disposition Summary:

    Defer until we can determine weather the optimization is worth the added complexity

    The RTF thinks is is best to wait and see if the need for this kind of optimization is sufficient to justify the added complexity to the user, and the implementation

    he concern is that this effectively introduces new sets of incompatible collection types:
    "short" strings are now incompatible with regular strings
    "short" sequences are incompatible with regular sequences,
    and so on.

    Note that two strings with a maximum length of say 20 would be incompatible if one is defined as a "sort" string and the other not. The one not defined as a "short" string would be compatible with (non-short) strings of any length. The one defined as short with short strings of any length.

    This will increase the complexity to the user who must now decide whether their strings (and sequences) should be defined as short or not to save some bytes, but then live with the consequence that it will not be possible to extend them...
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Restrictions on MAP key element type should include ENUM

  • Key: DDSXTY13-6
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    DDS-XTypes 1.2 section 7.2.2.4.3 (Collection Types) on page 30 bottom states:

    > * Element type: The concrete type to which all elements conform. (Collection Elements
    > that are of a subtype of the element type rather than the element type itself may be
    > truncated when they are serialized into a Data Representation.)
    > In the case of a map type, this attribute corresponds to the type of the value elements.
    > Map types have an additional attribute, the key element type, that indicates the type of the
    > may key objects.

    I believe there is a typo in "type of the may key objects" - drop the word "may" ?

    The paragraph continues:

    > Implementers of this specification need only support key elements of
    > signed and unsigned integer types and of narrow and wide string types; the behavior of
    > maps with other key element types is undefined and may not be portable.

    Is there a particular reason why enums were excluded from the supported key types?
  • Reported: DDS-XTypes 1.2b1 — Fri, 15 Sep 2017 13:51 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.3
  • Disposition Summary:

    Corrections were already applied in the formal document

    The typo mentioned in the description was already corrected in the formal DDS-XTYPES 1.2 document.

    Allowing enum to be used as key discriminator would introduce problems with type interoperability or data reception. Given that a similar behavior can be achieve at the application level (using the ordinal value associated with each enumeration literal) it seems better to leave the specification with the existing limitation.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Redefinition of the LC=6 and LC=7

  • Key: DDSXTY13-31
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently LC=6 indicates the length is multiplied by 2 and LC=7 indicates it should be multiplied by 4.

    It would be better if LC=6 indicated the length is multiplied by 4 and LC=7 indicated it should be multiplied by 8.

    The reason is that members of length 8 (INT64) and DOUBLE are far more common that members of length 2 (INT16 and CHAR16).
  • Reported: DDS-XTypes 1.2 — Thu, 6 Sep 2018 02:21 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Change the interpretation of LC=6 and LC=7

    Change de interpretation of the Length Code (LC) for values LC=6 and LC=7. The new interpretation shall be:

    • LC = 6 = 0b110 indicates serialized member length is 4*NEXTINT
    • LC = 7 = 0b111 indicates serialized member length is 8*NEXTINT

    This impacts only de LC definitions that appear in section 7.4.3.4.2 'Member Header (EMHEADER), Length Code (LC) and NEXTINT'
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Computation of KeyHash (7.6.7 Interoperability of Keyed Topics) needs additional detail

  • Key: DDSXTY13-28
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.6.7 (Interoperability of Keyed Topics) states that:

    As described in [ RTPS ] Clause 9.6.3.3, “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 such that key member values shall be serialized in the ascending orders of their member IDs. For calculation of KeyHash for mutable types, the key members shall be serialized without any parameter encapsulation.

    This statement does not explicitly say what to do about the DHEADER.

    The section should be amended to state that the DHEADER should also not be serialized for the purpose of the KeyHash computation. This is consistent with the stated "design rationale" of making the computation should be platform independent. The DHEADER could create an ambiguity as it allows to specify an endianess which would result in different hashes if different endianess are used.

    In addition it would be desirable to include examples where the types containing the keys are @appendable and @mutable. E.g.

    @mutable
struct MyKeyedStruct {
    @key string name;
    @key long id;
    @long x;
    @long y;
};

    Also we there should be an examples where the key fields themselves are declared as structures with extensibility @appendable or @mutable. E.g.

    @mutable
struct MyOuterKeyedStruct {
    @key MyKeyedStruct inner_struct;
    @key long  another_key;
    @long z;
};
  • Reported: DDS-XTypes 1.2 — Wed, 5 Sep 2018 02:08 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.3
  • Disposition Summary:

    Subsumed by DDSXTY13-22

    This issue has already been addressed by DDSXTY13-22
  • Updated: Tue, 8 Oct 2019 17:55 GMT

The definition of ReliabilityQosPolicyKind in Annex D is inconsistent with RTPS

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

    In the RTPS spec the values of ReliabilityQosPolicyKind are defined to be:
    BEST_EFFORT_RELIABILITY_QOS = 1
    BEST_EFFORT_RELIABILITY_QOS = 2

    However, in appendix D the ReliabilityQosPolicyKind is defined as:

    enum ReliabilityQosPolicyKind {
    BEST_EFFORT_RELIABILITY_QOS,
    RELIABLE_RELIABILITY_QOS
};

    To match what the RTPS specifies this should be modified to:

    enum ReliabilityQosPolicyKind {
    @value(1)  BEST_EFFORT_RELIABILITY_QOS,
    @value(2)  RELIABLE_RELIABILITY_QOS
};
  • Reported: DDS-XTypes 1.2 — Tue, 5 Dec 2017 18:07 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.3
  • Disposition Summary:

    Duplicates DDSXTY13-9

    Duplicates DDSXTY13-9
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Union default values (Table 9)

  • Key: DDSXTY13-13
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In Table 9 " Default values for non-optional members".

    For type kind UNION_TYPE, the default value may require the discriminator to be set to the "lowest value associated with any member", however the "lowest" relation isn't defined for all possible discriminator types.
    Boolean: use false (based on Table 9)
    Byte: undefined (based on Table 3)
    Char<N>: undefined
    UInt<N>: well defined
    Int<N>: need to define/clarify for negative numbers
    Enum: treat as Int32 per Table 4
  • Reported: DDS-XTypes 1.2b1 — Thu, 14 Dec 2017 20:17 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Modify the definition of the UNION_TYPE default value

    In table 9 set the union according to these rules:

    • Set the discriminator to the default value for the discriminator type
    • If that discriminator value does not select a branch, then there is nothing else to set
    • If that discriminator value selects a branch, then set the selected member to the default value for that corresponding member type

    Note that even if there is no explicit "default" brach, it is still possible to set discriminator to a value they is not covered in the explicit cases. This selects the so-called "implicit" default which has an empty branch.
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Explicitly define the values for ReliabilityQosPolicyKind

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

    The RTPS Spec defines BEST_EFFORT and RELIABLE_RELIABILITY as:
    #define BEST_EFFORT 1
    #define RELIABLE 2 (as of RTPS2.4, previously it was defined as 3)

    The XTypes Spec should align itself with these values by defining ReliabilityQosPolicyKind as follows in Annex D - DDS Built-in Topic Data Types:

    enum ReliabilityQosPolicyKind {
    BEST_EFFORT_RELIABILITY_QOS = 1,
    RELIABLE_RELIABILITY_QOS = 2
};
  • Reported: DDS-XTypes 1.2 — Fri, 8 Dec 2017 17:55 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Update the definition of enum ReliabilityQosPolicyKind in Annex D

    Modify the definition of enum ReliabilityQosPolicyKind in Annex D to match what is shown below:

    enum ReliabilityQosPolicyKind {
    @value(1) BEST_EFFORT_RELIABILITY_QOS,
    @value(2) RELIABLE_RELIABILITY_QOS 
};
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Serial Transport profile

  • Key: DDSXRCE-6
  • Status: closed  
  • Source: eProsima ( Mr. Jaime Martin-Losa)
  • Summary:

    The targets of this specification are low resource devices which in some case will not be able to implement the TCP or UDP stack.
    Instead, they will use serial communication to exchange data with the XRCE Agents.
    For this reason, common Serial Transport Profile is purposed with the objective of packaging XRCE message over serial communication.
    This Serial Transport has the following features:

    • HDLC Framing: each serial framing begins with a ``begin_frame`` octet ``(0x7E)`` and the rest of the frame is byte stuffing using the ``space`` octet ``(0x7D)`` following by the original octet exclusive-or with ``0x20``.
      For example, if the frame contains the octet `0x7E` it is encoded as `0x7D, 0x5E`; and the same for the octet `0x7E` which is encoded as `0x7D, 0x5D`.
    • CRC Calculation: serial frames end with a CRC-16 for detecting frame corruption. The CRC-16 is computed using the polynomial ``x^16 + x^12 + x^5 + 1`` after the frame stuffing for each octet of the frame and including the ``begin_frame``.
    • Routing header: the Serial Transport provides ``source`` and ``remote`` address in the framing, which could be used for implement a routing protocol.

    All the aforementioned features are addressed using the following frame format:

        0        8        16       24                40                 X                X+16
    +--------+--------+--------+--------+--------+--------//--------+--------+--------+
    |  FLAG  |  SADD  |  RADD  |       LEN       |   XRCE MESSAGE   |       CRC       |
    +--------+--------+--------+--------+--------+--------//--------+--------+--------+
    • ``FLAG``: is a ``begin_frame`` octet for frame initialization.
    • ``SADD``: is the address of the device which sent the message, that is, the ``source`` address.
    • ``RADD``: is the address of the device which should receive the message, that is, the ``remote`` address.
    • ``LEN``: is the length of the payload without framing. It is encoded as a 2-bytes array in little endian.
    • ``PAYLOAD``: is the payload of the message.
    • ``CRC``: is the CRC of the message after the stuffing.
  • Reported: DDS-XRCE 1.0b1 — Wed, 16 Jan 2019 11:09 GMT
  • Disposition: Resolved — DDS-XRCE 1.0
  • Disposition Summary:

    Add Serial Transport mapping

    Allows the communication over serial protocol such as I2C, SPI or RS-232
  • Updated: Tue, 8 Oct 2019 17:54 GMT

Read Data Stream

  • Key: DDSXRCE-5
  • Status: closed  
  • Source: eProsima ( Mr. Jaime Martin-Losa)
  • Summary:

    In the current specification, the XRCE Clients are not able to select the stream for input data,
    that is, they are not able to tell which stream should be used by the Agents in order to send `DATA` submessages.
    This feature could be very useful for XCRE Clients in order to manage the head-of-line blocking for input messages.

    One possible solution to this issue could be to add a `stream_id` field in the `READ_DATA_Payload`.

    @extensibility(FINAL)
struct READ_DATA_Payload : BaseObjectRequest {
    ReadSpecification read_specification;
};

@extensibility(FINAL)
struct ReadSpecification {
    StreamId    ref_stream;
    DataFormat  data_format;
    @optional string                content_filter_expression;
    @optional DataDeliveryControl   delivery_control;
};
  • Reported: DDS-XRCE 1.0b1 — Wed, 16 Jan 2019 10:37 GMT
  • Disposition: Resolved — DDS-XRCE 1.0
  • Disposition Summary:

    Add a requested stream_id to the ReadSpecification

    Allow the possibility if specifying a requested stream_id inside the ReadSpecification to be used by the Agent when sending the data messages in response.

    Use the mechanism suggested in the issue description.

  • Updated: Tue, 8 Oct 2019 17:54 GMT
  • Attachments:

Possible CREATE_CLIENT and STATUS_AGENT reduction

  • Key: DDSXRCE-4
  • Status: closed  
  • Source: eProsima ( Mr. Jaime Martin-Losa)
  • Summary:

    Taking into account that both `CREATE_CLIENT` and `STATUS_AGENT` are unfragmentable submessages,
    they bound the minimum MTU of the protocol.
    Therefore, it will be welcome a possible reduction of these submessages in order to reduce the minimum MTU.
    For example, currently, the `CREATE_CLIENT` submessage has 34 bytes of minimum size (without `ClientKey` nor `properties`),
    therefore, it could not be possible to use this protocol over version 4.0 of the BLE (Bluetooth Low Energy) protocol, which has only 27 bytes of maximum MTU.

    According to the aforementioned, the following `CREATE_CLIENT` and `STATUS_AGENT` submessage modification are purpose:

    1. Remove the `request_id` and `object_id` from both `CREATE_CLIENT` and `STATUS_AGENT` submessages.
    Thas is, remove the inheritance from `BaseObjectRequest` and `BaseObjectReply` from `CREATE_CLIENT` and `STATUS_AGENT` respectively.
    It should be noted that 1) the `object_id =

    {0xFF, 0xFE}

    ` is a redundant field and 2) the `request_id` has a similar behaviour to `sequence_nr` for unestablished session.
    2. Remove the `client_timestamp` and `agent_timestamp` from `CREATE_CLIENT` and `STATUS_AGENT` respectively.
    Both timestamps could be sent through a new `TIME` submessage which allows implementing clock synchronization protocols.

    These modifications involve the following changes in the IDL:

    @extensibility(FINAL)
struct CREATE_CLIENT_Payload {
    CLIENT_Representation client_representation;
};

@extensibility(FINAL)
struct CLIENT_Representation {
    XrceCookie   xrce_cookie;
    XrceVersion  xrce_version;
    XrceVendorId xrce_vendor_id;
    ClientKey    client_key;
    SessionId    session_id;
    @optional PropertySeq properties;
};

@extensibility(FINAL)
struct STATUS_AGENT_Payload {
    AGENT_Representation agent_info;
};

@extensibility(FINAL)
struct AGENT_Representation {
    XrceCookie   xrce_cookie;
    XrceVersion  xrce_version;
    XrceVendorId xrce_vendor_id;
    @optional PropertySeq properties;
};

    With the aforementioned modifications, the `CREATE_CLIENT` message will have 22 bytes of minimum size,
    while the `STATUS_AGENT` message will have only 17 bytes.

    CREATE_CLIENT message
-----------------------------------
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   session_id  |   stream_id   |         sequence_nr           | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CREATE_CLIENT |     flags     |       submessage_length       | 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          xrce_cookie                          | 12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          xrce_version         |       xrce_vendor_id          | 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          client_key                           | 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  session_id   |  properties?  | 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

STATUS_AGENT message
----------------------------------
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   session_id  |   stream_id   |         sequence_nr           | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STATUS_AGENT  |     flags     |       submessage_length       | 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          xrce_cookie                          | 12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          xrce_version         |       xrce_vendor_id          | 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  properties?  | 17
+-+-+-+-+-+-+-+-+
  • Reported: DDS-XRCE 1.0b1 — Tue, 15 Jan 2019 15:24 GMT
  • Disposition: Resolved — DDS-XRCE 1.0
  • Disposition Summary:

    Simplify the CREATE_CLIENT and STATUS_AGENT messages

    Perform the simplifications suggested in the issue description.
  • Updated: Tue, 8 Oct 2019 17:54 GMT

New TIME submessage

  • Key: DDSXRCE-3
  • Status: closed  
  • Source: eProsima ( Mr. Jaime Martin-Losa)
  • Summary:

    Some of the most extended clock synchronization protocol such as PTP or NTP require the exchange of multiple timestamp messages between the master and the slave.
    The current standard only supports the timestamp exchange using the `CREATE_CLIENT` and `STATUS_AGENT` submessages.
    For this reason, a new kind of submessage called `TIME` is purposed.

    This new `TIME` submessage, which could use the `stream_id` 0x00, requires the following changes in the IDL:

    ```
    enum SubmessageId

    { ··· @value(14) TIME }

    ;

    @extensibility(FINAL)
    struct TIME_Payload : Time_t {
    };
    ```

    An example of an XRCE message with a `TIME` submessage is shown below.

     0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   session_id  |   stream_id   |         sequence_nr           | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     TIME      |     flags     |       submessage_length       | 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          timestamp (s)                        | 12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          timestamp (ns)                       | 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Reported: DDS-XRCE 1.0b1 — Tue, 15 Jan 2019 14:56 GMT
  • Disposition: Resolved — DDS-XRCE 1.0
  • Disposition Summary:

    Add a TIME submessage

    Introduce a TIMESTAMP and a TIMESTAMP_REPLY submessages. The TIMESTAMP contains a simple timestamp and the TIMESTAMP_REPLY contains a timestamp plus the additional timestamps needed to run a simple version of the NTP clock synchronization algorithm.
  • Updated: Tue, 8 Oct 2019 17:54 GMT
  • Attachments:

Move section 11.4 'Serial Transport' to a new Annex C

  • Key: DDSXRCE-14
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    As a result of the AB review section 7.4 'Serial Transport' was moved to an Annex to make clear that it is non-normative. This was included in the Errata presented to the AB.

    Even if this doesn't change the conformance points (serial transport is not listed in the conformance section 3), this change also requires requires a FTF vote, it cannot be considered editorial.

    Therefore this issue performs the move.
  • Reported: DDS-XRCE 1.0b1 — Thu, 21 Mar 2019 18:51 GMT
  • Disposition: Resolved — DDS-XRCE 1.0
  • Disposition Summary:

    Create Annex C. Move section 11.4 there

    Perform the changes specified in the issue description.
  • Updated: Tue, 8 Oct 2019 17:54 GMT

StreamId in ACKNACK and HEARTBEAT

  • Key: DDSXRCE-2
  • Status: closed  
  • Source: eProsima ( Mr. Jaime Martin-Losa)
  • Summary:

    According to the specification, the `MessageHeader` interpretation depends on whether the following submessage is an `ACKNACK` or a `HEARTBEAT` submessage.
    In this case, the `sequenceNr` shall be interpreted as an epoch that may be used to discard the duplicate message.
    This dichotomy allows us to save bandwidth but it has some drawbacks.

    On the one hand, it prevents to send multiple `ACKNACK` and `HEARTBEAT` submessages, which refer to different streams, in a single message.

    On the other hand, it obfuscates the message handling because it is not enough to read the `MessageHeader` in order to discard, process, or buffer the message into the stream, but it is necessary to read the first `SubmessageHeader`.

    In order to avoid the aforementioned drawbacks, the following modifications are purposed:

    1. Add a `stream_id` member to `ACKNACK` and `HEARTBEAT` submessages.

    struct ACKNACK_Payload {
    short first_unacked_seq_num;
    octet[2] nack_bitmap;
    octet stream_id;
}

struct HEARTBEAT_Payload {
    short first_unacked_seq_nr;
    short last_unacked_seq_nr;
    octet stream_id;
}

    2. Use the stream 0 (`STREAMID_NONE`) since `ACKNACK` and `HEARTBEAT` submessage do not belong to any stream, but they inform about the state of the streams.

    This modification allows sending multiple `ACKNACK` and `HEARTBEAT` submessages in a single message and it simplifies the message handling.
  • Reported: DDS-XRCE 1.0b1 — Tue, 18 Dec 2018 11:16 GMT
  • Disposition: Resolved — DDS-XRCE 1.0
  • Disposition Summary:

    Add StreamId to ACKNACK and HEARTBEAT

    Do as proposed in the issue description
  • Updated: Tue, 8 Oct 2019 17:54 GMT

Erratum

Improve readability of a number of figures

  • Key: DDSOPCU-3
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    Figure 9.2, which describes the mapping of DDS primitive types to OPC UA is hard to read. We should break the figure into different class diagrams. For example, we could create one diagram for primitive types, one diagram for floating point types, and one diagram for boolean, char, and byte types.

    Also, Figures should be in black and white when possible; e.g., Figures 7.3, 8.1 and 9.1 could be made black and white.
  • Reported: DDS-OPCUA 1.0b1 — Fri, 1 Feb 2019 21:03 GMT
  • Disposition: Resolved — DDS-OPCUA 1.0
  • Disposition Summary:

    Fix figures with readability issues

    The resolution of this issue replaces existing figures with readability issues with new images.
  • Updated: Tue, 8 Oct 2019 17:53 GMT
  • Attachments:

Update Schema Files and XML files to Use DDS-XML 1.0

  • Key: DDSOPCU-1
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    DDS-XML 1.0 has been release, so we should upgrade our XML schema files to use the new version. This involves:

    1. Updating the include statement in dds-opcua_definitions_nonamespace.xsd
    2. Updating the reference in Clause 3 "Normative References" of the specification document.

    Also, we should make sure that we use working URLs in the rest of include statements instead relative paths. This involves:
    1. Updating the include statement in dds-opcua_definitions.xsd that includes "dds-opcua_definitions_nonamespace.xsd" on the current directory with a reference to "http://www.omg.org/spec/DDS-XML/20190101/dds-opcua_definitions_nonamespace.xsd", which is the URL where the schema file will end up as a result of this FTF.
    2. Updating the include statement in dds-opcua_opcua2dds_configuration.xml that includes "dds-opcua_definitions.xsd" on the current directory with a reference to "http://www.omg.org/spec/DDS-XML/20190101/dds-opcua_definitions.xsd", which is the URL where the schema file will end up as a result of this FTF.

    Also, we should use full URLs when we specify schema locations instead of relative paths. That would require changes in dds-opcua_definitions.xsd, dds-opcua_opcua2dds_configuration.xml, and dds-opcua_dds2opcua_configuration.xml. They should all point to resources under http://www.omg.org/spec/DDS-OPCUA/20190201, which would be the location of machine readable files for version 1.0 of the OPC UA/DDS Gateway specification.
  • Reported: DDS-OPCUA 1.0b1 — Mon, 28 Jan 2019 16:10 GMT
  • Disposition: Resolved — DDS-OPCUA 1.0
  • Disposition Summary:

    Update references to DDS-XML 1.0 Beta to 1.0 and Schema Location URLs

    This issue resolution replaces all references in Specification Document and Schema Files to Version 1.0 Beta of DDS-XML to new Version 1.0.

    Moreover, it modifies schemaLocation references to use full URLs instead of relative path references.
  • Updated: Tue, 8 Oct 2019 17:53 GMT
  • Attachments:

Update dds-opcua_model.xmi and normative references to most recent versions

  • Key: DDSOPCU-5
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    dds-opcua_model.xmi refers to an old version of XMI (xmlns:xmi="http://www.omg.org/spec/XMI/20110701); we should update this reference to the most recent version, which is 2.5.1 (accessible at http://www.omg.org/spec/XMI/).

    Likewise, the specification document points to OMG specifications, such as DDS-RTPS 2.2 and DDS-SECURITY 1.1 Beta, for which there are newer versions available. (The reference to the formal version of DDS-XML was added as part of the resoultion of DDSOPCU-1).
  • Reported: DDS-OPCUA 1.0b1 — Wed, 6 Feb 2019 17:35 GMT
  • Disposition: Resolved — DDS-OPCUA 1.0
  • Disposition Summary:

    Update outdated normative references and dds-opcua_model.xmi to most recent version

    This resolution updates normative references to the most recent available version. In particular, it updates the normative references to:

    • DDS-RTPS 2.3 Beta 1
    • DDS-SECURITY 1.1

    And updates dds-opcua_model.xmi to version 2.5.1.
  • Updated: Tue, 8 Oct 2019 17:53 GMT
  • Attachments:

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

  • Key: DDSXTY14-5
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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 ( Mr. 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. ( Mr. 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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

TypeSupport::get_type_name should be precisely specified

  • Key: DDS15-1
  • Legacy Issue Number: 18468
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • 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, PhD.)
  • 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 ( Mr. 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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 ( Mr. 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 ( Mr. 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

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

  • Key: DDS15-266
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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

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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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, PhD.)
  • 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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 ( Mr. 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

What can be done with a disabled Topic?

  • Key: DDS15-255
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. 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 ( Mr. 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 ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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

  • Key: DDSPSMC11_-3
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro 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 ( Mr. 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.

  • Key: DDSPSMC11_-86
  • Status: open  
  • Source: ZettaScale Technology ( Mr. 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

  • Key: DDSPSMC11_-77
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro 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

  • Key: DDSPSMC11_-69
  • Legacy Issue Number: 17063
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • 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

  • Key: DDSPSMC11_-71
  • Status: open  
  • Source: ZettaScale Technology ( Mr. 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

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

  • Key: DDSPSMC11_-25
  • Status: open  
  • Source: ZettaScale Technology ( Mr. 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

  • Key: DDSPSMC11_-73
  • Status: open  
  • Source: ZettaScale Technology ( Mr. 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.0 — Wed, 24 Apr 2019 13:22 GMT
  • Updated: Wed, 15 May 2019 12:50 GMT

Inconsistent ways to set functor in Condition types

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

    Conditions have an optional functor handler that WaitSet::dispatch() calls when they're active. But the ways to set this handler vary depending on the Condition type:

    Condition type How you set the handler
    GuardCondition handler(Functor&) setter (therefore mutable)
    ReadCondition In constructor (therefore immutable)
    QueryCondition No way to set it (it seems a oversight; should be same as ReadCondition)
    StatusCondition No way to set it (not clear if it's on purpose or an oversight)

    Note that making the handler mutable or immutable has consequences in the thread-safety requirements of the implementations.
  • Reported: DDS-PSM-Cxx 1.0b2 — Thu, 21 Jul 2016 22:35 GMT
  • Updated: Wed, 15 May 2019 12:24 GMT

StatusCondition should have a singleton delegate

  • Key: DDSPSMC11_-70
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Because the DDS-PSM-C++ abandoned the factory pattern, you now have to instantiate your own StatusCondition object, and pass the Entity to which it applies as parameter to its constructor.

    However, DDS spec states that each Entity can have only one StatusCondition, and the get_statuscondition operation is responsible for that. Since with the DDS-PSM-Cxx API I can repeatedly create a StatusCondition for the same Entity, I can potentially break the Singleton pattern.

    I would suggest that we state explicitly that when you instantiate multiple StatusCondition objects to the same Entity, they all end up pointing to the same Delegate.
  • Reported: DDS-PSM-Cxx 1.0 — Wed, 24 Apr 2019 12:51 GMT
  • Updated: Wed, 15 May 2019 12:22 GMT

DataReader semantics for historical data are insufficient

  • Key: DDS15-52
  • Legacy Issue Number: 10805
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    The current specification provides no solution for the following two use-cases:
    · A Volatile DataReader can receive data from a Transient or persistent DataWriter so it may also be interested in historical data. However a DataReader cannot receive historical data. Just making the DataReader Transient does not solve the problem because the DataReader may also be interested in volatile data.
    · A Transient or Persistent DataReader may not be interested in historical data, there is no way to avoid receiving historical data. A DataReader may be e.g. Transient to avoid receiving data from volatile DataWriters, in addition there may be no interest in historical data.

    Solution:
    Separate the control of receiving historical data from the DataReaders durability interest. The DataReaders Durability interest will specify from which DataWriter it will accept data. A separate call will control (ask for) the retrieval of historical data.
    Add the following method
    ReturnCode_t get_historical_data(Duration_t max_wait)
    And Transient and Persistent DataReaders should not automatically receive historical data. A consequence is that this invalidates the method
    ReturnCode_t wait_for_historical_data(Duration_t max_wait).
  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Fri, 3 May 2019 01:36 GMT

MAP_TYPE enumeration constant should be redefined due to clash with POSIX macro

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

    On some Linux systems the following enumeration:

    dds::core::xtypes::TypeKind::MAP_TYPE

    clashes with the macro MAP_TYPE defined in <sys/mman.h>
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 24 Apr 2019 14:07 GMT
  • Updated: Fri, 26 Apr 2019 14:52 GMT

DataReader.read should return an Iterable collection, not an Iterator

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

    The current signature of read() (and take) is:

    public Sample.Iterator<TYPE> read();

    This operation should return an Interable collection, to be aligned with the C++PSM:

    public LoanedSamples<T> read();

    An Iterable collection can be used in a foreach loop, and it can be managed by a try-with-resources block to return the loan automatically. An Iterator doesn't take advantage of these features.
  • Reported: DDS-Java 1.0b2 — Wed, 24 Apr 2019 21:36 GMT
  • Updated: Wed, 24 Apr 2019 21:38 GMT

API correction required to dds/sub/find.hpp

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

    The return type of dds::sub::builtin_subscriber() is a const reference, forcing to keep the builtin subscriber as a member in the DomainParticipant.

    We cannot make the subscriber a member of the DomainParticipant because this would cause a shared_ptr loop. This also unnecessarily restricts the implementation of this function.

    Proposed resolution:

    - const dds::sub::Subscriber&
- builtin_subscriber(const dds::domain::DomainParticipant& dp);
+ dds::sub::Subscriber 
+ builtin_subscriber(const dds::domain::DomainParticipant& dp);
  • Reported: DDS-PSM-Cxx 1.0b2 — Thu, 21 Jul 2016 22:12 GMT
  • Updated: Wed, 24 Apr 2019 16:18 GMT

Transform AnyDataWriter and AnyDataReader from wrappers into parent classes.

  • Key: DDSPSMC11_-72
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    In the current DDS-PSM-Cxx spec, the AnyDataWriter and AnyDataReader classes are untyped wrappers around the typed Writers and Readers that only expose their untyped operations.

    I suggest to make the AnyDataWriter and AnyDataReader the parent classes for the typed Writers and Readers. That makes it much easier to navigate from for example an untyped AnyDataWriter to typed DataWriter and vice versa.

  • Reported: DDS-PSM-Cxx 1.0 — Wed, 24 Apr 2019 13:06 GMT
  • Updated: Wed, 24 Apr 2019 13:56 GMT

Define relationship between Query and QueryCondition

  • Key: DDSPSMC11_-74
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The current DDS-PSM-Cxx spec distinguishes between Queries and QueryConditions. The former can be used in a Selector, the latter can be used in a WaitSet. However, from the end-user perspective it would make sense that if I want my WaitSet to trigger on incoming data matching my QueryCondition, that I then want to consume the data matching my Query in some way.

    According to the current specification I would need to instantiate both a Query and a QueryCondition based on the same expression. If I then want to modify my Query parameters, I would need to do so consistently for both my Query and my QueryCondition.

    I propose to make QueryCondition extend from Query, and make Query extend from Reference instead of Value. That allows us to store a reference to our internal query state (e.g. to the parse-tree) into the Query object instead of having to redo the whole thing over and over again.
  • Reported: DDS-PSM-Cxx 1.0 — Wed, 24 Apr 2019 13:31 GMT
  • Updated: Wed, 24 Apr 2019 13:31 GMT

CREATE_CLIENT example: typo in hex representation of submessageLength

  • Key: DDSXRCE11-2
  • Status: open  
  • Source: private ( Christian Rauch)
  • Summary:

    In the CREATE_CLIENT example, the submessageLength is given as:
    submessageLength = 26 = 0x001B

    While the length is correctly given as 26 bytes, the hexadecimal representation should be 0x001A and not 0x001B.
  • Reported: DDS-XRCE 1.0b1 — Wed, 13 Mar 2019 00:36 GMT
  • Updated: Mon, 8 Apr 2019 16:47 GMT

Serial Transport (section C.1) should be a subsection of 11

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

    The subsections of Annex C 'Additional Transport Mappings' should be moved to become subsections of section 11. Since section 11 is already covering the Transport mappings. Specifically C.1 should become 7.4 and the reference to C.1 at the end of current 7.4 'Other Transports' should be removed.
  • Reported: DDS-XRCE 1.0b1 — Thu, 21 Mar 2019 15:04 GMT
  • Updated: Tue, 2 Apr 2019 18:53 GMT

Consider possibility of adding Port concept to DI

  • Key: DD12_-6
  • Legacy Issue Number: 18680
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Max Bureck)
  • Summary:

    Hi, the concept of ports, attached to the outside bounds of an element allowing connections between elements is a widespread concept. Adding this concept would help generic layouting algorithms taking ports into account (such as KIELER) doing a much better job. Since DI defines abstract subclasses, meta models without ports can simply choose to not use the concept.
  • Reported: DD 1.0 — Mon, 22 Apr 2013 04:00 GMT
  • Updated: Tue, 8 Jan 2019 15:34 GMT

Constraints

  • Key: DD12_-5
  • Legacy Issue Number: 16492
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The spec currently has no constraint sections. Should we add them? For
    example, we might require unowned diagram elements to be diagrams
  • Reported: DD 1.0b1 — Mon, 31 Jan 2011 05:00 GMT
  • Updated: Tue, 8 Jan 2019 15:33 GMT

Why does A_style_canvas have no name?

  • Key: DD12_-4
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    All the Associations in DC/DG/DI have names except just one:

    <packagedElement xmi:type="uml:Association" xmi:id="A_style_canvas" memberEnd="Canvas-packagedStyle A_style_canvas-canvas">
    <ownedEnd xmi:type="uml:Property" xmi:id="A_style_canvas-canvas" name="canvas" type="Canvas" association="A_style_canvas"/>
    </packagedElement>

    Is this intended?
  • Reported: DD 1.1 — Thu, 14 Apr 2016 08:13 GMT
  • Updated: Tue, 8 Jan 2019 15:32 GMT

Small typo.

  • Key: DD12_-3
  • Legacy Issue Number: 19485
  • Status: open  
  • Source: yahoo.fr ( Lambert Clara)
  • Summary:

    There is a small typo in the DD specification document.
    On page 17 we can read:
    "namely the Diagram Graphics(DI) package (Clause 9) and the Diagram Interchange(DG) package"

    The acronyms in the parenthesis are reversed, it should be Diagram Graphics(DG) and Diagram Interchange(DI).
  • Reported: DD 1.0 — Mon, 23 Jun 2014 04:00 GMT
  • Updated: Tue, 8 Jan 2019 15:32 GMT

Small typos.

  • Key: DD12_-2
  • Legacy Issue Number: 19486
  • Status: open  
  • Source: yahoo.fr ( Lambert Clara)
  • Summary:

    There are some typos in the attributes description of Color data type, we can read:
    "Integer [1] - the red component of the color in the range (0..255)"
    for all three components, green and blue included.

    The description should reflect the correct color.
  • Reported: DD 1.0 — Mon, 23 Jun 2014 04:00 GMT
  • Updated: Tue, 8 Jan 2019 15:32 GMT

A_style_canvas Association is unnamed

  • Key: DD12_-1
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The final Association in DG.xmi

    <packagedElement xmi:type="uml:Association" xmi:id="A_style_canvas" memberEnd="Canvas-packagedStyle A_style_canvas-canvas">
    <ownedEnd xmi:type="uml:Property" xmi:id="A_style_canvas-canvas" name="canvas" type="Canvas" association="A_style_canvas"/>
    </packagedElement>

    has no name. This is at best poor practice and contrary to the guidance at the end of UML 2.5 2.4.2.
  • Reported: DD 1.1 — Tue, 13 Dec 2016 11:18 GMT
  • Updated: Tue, 8 Jan 2019 15:30 GMT

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

  • Key: DDSIRTP23-6
  • Legacy Issue Number: 17286
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Original Description

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

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

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

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

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

    RTF 2.3 Discussion

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

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

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

    • rtpsMsgLength

    The rtpsMsgLength indicates the length of the RTPS message

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

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

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

    RTF 2.3 Latest Proposed Revised Text

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

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

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

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

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

    Checksum_t Type used to hold a checksum. Used to detect message corruption.

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

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

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

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

    Table 29 – Structure of the Checksum SubmessageElement

    field type meaning
    value Checksum_t Checksum computed over a set of bytes.

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

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

    element type meaning
    EndiannessFlag SubmessageFlag Appears in the Submessage header flags. Indicates endianness.
    LenghtFlag SubmessageFlag Appears in the Submessage header flags. Indicates the the rtpsMessageLength field is present.
    ChecksumFlag SubmessageFlag Appears in the Submessage header flags. Indicates the the rtpsMessageChecksum field is present.
    PortFlag SubmessageFlag Appears in the Submessage header flags. Indicates the the destinationPort field is present.
    rtpsMessageLength ulong If present, contains the length of the RTPS Message starting from the beginning of the RTPS Header.
    rtpsMessageChecksum Checksum If present, contains a checksum computed over the content of the RTPS Message, which includes the HeaderExtension submessage. For the purposes of computing the checksum the rtpsMessageChecksum is set to zero.
    destinationPort ulong If present, contains the transport port where the RTPS Message is sent.

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

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

    8.3.7.1.4 Change in state of Receiver
    None.

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

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

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

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

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

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

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

    typedef unsigned long Checksum_t;
  • Reported: DDSI-RTPS 2.1 — Fri, 30 Mar 2012 04:00 GMT
  • Disposition: Deferred — DDSI-RTPS 2.3
  • Disposition Summary:

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

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

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

    Therefore the opinion of the RTF is to defer this issue until an additional RTPS Transport PSM is approved to better understand the requirements.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

PID_DIRECTED_WRITE and PID_ORIGINAL_WRITER_INFO need further description

  • Key: DDSIRTP23-78
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Table 9.14 introduces PID_DIRECTED_WRITE and PID_ORIGINAL_WRITER_INFO but they are not described in the subsequent sections.
  • Reported: DDSI-RTPS 2.2 — Mon, 18 Dec 2017 17:51 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Add description for PID_ORIGINAL_WRITER_INFO and deprecate PID_DIRECTED_WRITE

    A missing description for PID_ORIGINAL_WRITER_INFO has been added and PID_DIRECTED_WRITE type has been updated to match common practice with note to ignore when the format is not known.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

How should interoperable implementations deal with Group Coherent updates

  • Key: DDSIRTP23-29
  • Legacy Issue Number: 16100
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

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

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 Mar 2011 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Define RTPS Mechanisms for Group Ordered Access and Group Coherent Sets

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

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

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

  • Key: DDSIRTP23-30
  • Legacy Issue Number: 15885
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

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

    The RTF must decide what short name to use for this specification.
  • Reported: DDSI-RTPS 2.1 — Thu, 9 Dec 2010 05:00 GMT
  • Disposition: Deferred — DDSI-RTPS 2.3
  • Disposition Summary:

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

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

    The proposed resolution to this issue is to change the acronym to DDS-RTPS. So if the issue is approved the acronym will change. If it is rejected it will stay the same.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

GAP lack information on related (instance/key) needed for correct DDS behavior

  • Key: DDSIRTP23-31
  • Legacy Issue Number: 11035
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

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

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

    { long gapStartOffset; KeyHashPrefix keyHashPrefix; KeyHashSuffic keyHashSuffix; }

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

    Resolution:
    T4 should include code and description that states that when the sample is not relevant, send a GAP…same for the stateful best effort writer.
    Revised Text:
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

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

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

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

    Define more precisely when a writer that does writer-side content filter should send the DISPOSE, UNREGISTER, and FILTERED messages.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Editing issues

  • Key: DDSIRTP23-23
  • Legacy Issue Number: 16957
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

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

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

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

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

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

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

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

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

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

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

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

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

    14. Section: 9.6.3.2, Table 9.16
    Page: 190
    Change: KeyHashSuffix does not exist; remove this row from the table. The row for SerializedData should be sufficient to describe the use of PID_COHERENT_SET.
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Fix Editorial Issues

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

  • Updated: Wed, 19 Dec 2018 16:38 GMT
  • Attachments:

Clarify start of alignment for SerializedPayload

  • Key: DDSIRTP23-3
  • Legacy Issue Number: 19660
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 9.4.2.12 should clearly state where the alignment begins. Is it before the encapsulation header or after the encapsulation header?

    Note that 9.4.2.11 already talks about it for the ParameterList encapsulation so 9.4.2.12 should use the same approach.

    The language in 9.4.2.11 should also be improved to make it less ambiguous, specifically stating that the reset of the alignment occurs after the parameterID before the parameter data is serialized.

  • Reported: DDSI-RTPS 2.2 — Mon, 24 Nov 2014 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Clarify the start alignment for the SerializedPayload SubmessageElement

    The SerializedPayload SubmessageElement has been updated to clearly state that the CDR stream is logically reset after the encapsulation header, similar to what is already described in section 9.4.2.11. Section 9.4.2.11 has also been improved for clarity, with no change to semantics.

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Make sure all references to the RTPS version are updated to 2.4

  • Key: DDSIRTP23-119
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    DDS Security updated the RTPS version to 2.3. Consequently this revision should update it to 2.4. See also DDSIRTP23-56
  • Reported: DDSI-RTPS 2.2 — Wed, 25 Jul 2018 14:56 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Update protocol version from 2.2 to 2.4

    Replace all the version 2.2 with 2.4 in all places except Section 9.3.1.4 '9.3.1.4 Deprecated EntityIds in version 2.2 of the Protocol' and Section 9.6.4 'ParameterIds Deprecated by the Protocol'
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Builtin Interparticipant Channel should have DataReader reliability kind BEST_EFFORTS

  • Key: DDSIRTP23-40
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently it is RELIABLE. The problem is that this channel is used to send the Liveliness assertions. Being reliable if one is lost, future assertions cannot make it through even if they are written by the DataWriter. Rather it has to wait for the repair packet which depends on timing for HeartBeat and repair which may be longer than the assertion period.

    Since the assertion message is small, it is more efficient to send it faster than rely on faster heartbeats and ACKNACKs.

    This change would be backwards compatible since the DataWriter would still have reliability kind RELIABLE.
  • Reported: DDSI-RTPS 2.2 — Mon, 21 Aug 2017 22:09 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    *Add Flags to the BuiltinEndpointSet to Facilitate Communication of Configuration Options *

    It is useful to be able to configure the builtin endpoints and then communicate the configurations. A new PID has been defined that will allow communication of these specific configurations. One of the new flags will be used to communicate the Reliability kind of the inter-participant DataReader.

  • Updated: Wed, 19 Dec 2018 16:38 GMT
  • Attachments:

DomainId should propagated in the ParticipantBuiltinTopicData

  • Key: DDSIRTP23-118
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently the domainId is not propagated with the ParticipantBuiltinTopicData as a result there could be situations where Participant accidentally discovers another one on a different DomainId as a result of port overlaps.

    This issue requests the domainId to be propagated in the ParticipantBuiltinTopicData so it can be checked independently of port numbers.
  • Reported: DDSI-RTPS 2.2 — Tue, 15 May 2018 16:09 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Propagate DomainId as part of Participant Discovery

    Add domainId as an additional field in ParticipantProxy
    Add PID_DOMAIN_ID with value 0x000f containing a domainId
    Add PID_DOMAIN_TAG with value 0x4014 containing a domainTag
  • Updated: Wed, 19 Dec 2018 16:38 GMT
  • Attachments:

Update section 10 (Data Encapsulation)

  • Key: DDSIRTP23-42
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 10 was written before there was a good reference for the data representation used by DDS. Now that we have the DDS-XTYPES specification the section should updated to indicate the minimal requirements to comply with RTPS and reference XTYPES for full DDS type interoperability.

    Note that we should not make RTPS depend on XTYPES. The intent is just to clarify where different things are, not to change the things required for compliance.
  • Reported: DDSI-RTPS 2.2 — Thu, 16 Nov 2017 00:01 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Update Section 10 (Data Encapsulation)

    Replace Section 10 to more precisely define the Encapsulation Identifiers and and reference the Data Representation formats in DDS-XTYPES section 7.4.

    Include an example for builtin Topic and one for an application-defined Topic.
  • Updated: Wed, 19 Dec 2018 16:38 GMT
  • Attachments:

Describe how to create a WITH_KEY or NO_KEY RTPS Endpoint from DDS

  • Key: DDSIRTP23-113
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Describe how to create a WITH_KEY or NO_KEY RTPS Endpoint from DDS. The RTPS endpoints have a with_key attribute, but it is not clear how this attribute can be set
  • Reported: DDSI-RTPS 2.2 — Sat, 24 Feb 2018 02:44 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Describe how to create a WITH_KEY or NO_KEY RTPS Endpoint from DDS

    The text has been clarified to describe how an RTPS Writer and RTPS Reader can be defined as either WITH_KEY or NO_KEY from DDS.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Reference the PIDs that are reserved by the XTypes Spec in RTPS

  • Key: DDSIRTP23-115
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Xtypes Specification uses some of the protocol-specific PIDs, we should note that these PIDs are reserved in the RTPS spec.

  • Reported: DDSI-RTPS 2.2 — Mon, 26 Feb 2018 01:15 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Reference the PIDs that are reserved by the XTypes Spec in RTPS

    The Xtypes Spec uses PIDs 0x0072, 0x0073, 0x0074, and 0x0075, we have noted in RTPS that these PIDs are reserved.

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Update UML figures in the specification

Data/Frag submessage flag for security

  • Key: DDSIRTP23-110
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    See https://issues.omg.org/browse/DDSSEC12-33 for background.
    Since this revision of RTPS will take into account the extensions for DDS-Security, define a flag in Data/Frag submessages to indicate that the SerializedPayload submessage element was modified for security.
  • Reported: DDSI-RTPS 2.2 — Thu, 15 Feb 2018 19:42 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Reserve a flag in DATA and DATA_FRAG Submessages to indicate the SerializedPayload has been transformed

    A flag in DATA and DATA_FRAG Submessages was reserved to indicate that the SerializedPayload has been transformed.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Unused ParameterIds in Table 9.12

  • Key: DDSIRTP23-76
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The role of Table 9.12 is "...the list of ParameterIds used to encapsulate the data for the built-in Entities" (9.6.2.2.2).

    The following ParameterIds are not used for built-in entities and therefore do not belong in this table: PID_BUILTIN_ENDPOINT_SET, PID_PROPERTY_LIST, PID_TYPE_MAX_SIZE_SERIALIZED, PID_ENTITY_NAME, PID_KEY_HASH, PID_STATUS_INFO (the last six rows). Some of them are already in Table 9.14.
  • Reported: DDSI-RTPS 2.2 — Mon, 18 Dec 2017 17:46 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Remove ParameterIds incorrectly listed Table 9.12 and Add Missing Usage for PID_TYPE_MAX_SIZE_SERIALIZED

    PID_KEY_HASH and PID_STATUS_INFO are incorrectly listed in Table 9.12 which lists the data for the builtin entities. They are already listed in Table 9.14 'Inline QoS parameters' so they have been removed from Table 9.12. A new optional attribute has been added to WriterProxy for PID_TYPE_MAX_SIZE_SERIALIZED.
  • Updated: Wed, 19 Dec 2018 16:38 GMT
  • Attachments:

Update state machine to allow retrieving inline qos from a CacheChange

  • Key: DDSIRTP23-108
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    There are protocol messages that have sample-specific inlineQoS that comes from the higher layers (for example the original writer info) we need to add this to the CacheChange.inlineQos and the virtual machine should be updated that in addition to getting inlineqos from the writer, it should also get it form the cache change itself
  • Reported: DDSI-RTPS 2.2 — Mon, 12 Feb 2018 19:58 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Retrieve inlineQoS from CacheChange

    InlineQos can come from a CacheChange as well as from the writer. CacheChange has been updated to include inlineQos and the virtual machine has been updated to retrieve this inlineQoS as well.
  • Updated: Wed, 19 Dec 2018 16:38 GMT
  • Attachments:

Typo in 8.4.13

  • Key: DDSIRTP23-101
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    "All implementations must support the Wirter Liveliness Protocol", Wirter should be Writer
  • Reported: DDSI-RTPS 2.2 — Wed, 7 Feb 2018 16:55 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Fix typo

    Replace "Wirter" with "Writer"
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Inconsistent definitions of ParticipantMessageData

  • Key: DDSIRTP23-103
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The ParticipantMessageData appears defined in 3 places:

    Figure 8.26 - ParticipantMessageData

    Section 9.6.2.1 (Data Representation for the ParticipantMessageData Built-in Endpoints) in the IDL

    Section 9.6.2.1 In the CDR encoded representation.

    These definitions are not consistent. The IDL definition appears to be the correct one. This should be verified and the others should be adjusted to match it.
  • Reported: DDSI-RTPS 2.2 — Wed, 7 Feb 2018 21:24 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    Already covered by DDSIRTP23-23

    Close as duplicate as it is already covered by DDSIRTPS23-23
  • Updated: Wed, 19 Dec 2018 16:38 GMT

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

  • Key: DDSIRTP23-24
  • Legacy Issue Number: 16558
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

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

    [Nature] Architectural
    [Severity] Major

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

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

    For non X-Types compatible DDS implementations make the KeyHash compulsory, meaning require DDS compliant implementation to
    always send a key-hash along with a Data submessage.
  • Reported: DDSI-RTPS 2.0b1 — Mon, 19 Sep 2011 04:00 GMT
  • Disposition: Closed; No Change — DDSI-RTPS 2.3
  • Disposition Summary:

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

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

  • Updated: Wed, 19 Dec 2018 16:38 GMT

DDSI/RTPS Key MD5 Hash

  • Key: DDSIRTP23-28
  • Legacy Issue Number: 15912
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

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

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

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

    The suggested resolution is to require that Data SubMessage for keyed topic shall always include the KeyHash submessage element.
  • Reported: DDSI-RTPS 2.0b1 — Wed, 5 Jan 2011 05:00 GMT
  • Disposition: Closed; No Change — DDSI-RTPS 2.3
  • Disposition Summary:

    No immediate need to require sending the Keyhash with each sample

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

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section 8.4.9.1.4: Best-Effort Stateful Writer GAP semantics

  • Key: DDSIRTP23-20
  • Legacy Issue Number: 16965
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 92
    Change: Figure 8.18 notes that transition T4 can send a GAP, but this section doesn't describe when/how to send a GAP.
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Add descriptions of when Best Effort Writers Send GAP messages

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

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section 8.4.7.3, Table 8.52: Describe ReaderLocator operations' semantics

  • Key: DDSIRTP23-22
  • Legacy Issue Number: 16963
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 77
    Change: Unlike other tables of operations in this section, none of these operations are described in the text of the section
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Add missing descriptions of the ReaderLocator operations in Table 8.52

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

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Use the term "Encapsulation" consistently and precisely

  • Key: DDSIRTP23-25
  • Legacy Issue Number: 16955
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Section: 10
    This is handled on a separate issue.

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

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

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

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

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

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

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

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

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

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

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

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

    Section: 9.6.3.3
    Page: 190-191
    Change: replace “'“encapsulation'” with '“representation'” (seven times)
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Replace all uses of any form of 'Encapsulate'

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

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

    All other situations were dealt with on a case-by-case basis
  • Updated: Wed, 19 Dec 2018 16:38 GMT

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

  • Key: DDSIRTP23-27
  • Legacy Issue Number: 16954
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

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

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

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

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

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

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

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

    30. Section: 9.3.2, Table 9.4
    Page: 155
    Change: remove the “TopicKind_t” row
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Limit the use of TopicKind to the places where it matters

    The protocol works the same whether or not a Topic is keyed; the distinction was therefore unnecessary in many places and was removed.
  • Updated: Wed, 19 Dec 2018 16:38 GMT
  • Attachments:

Incorrect/misleading description of KeyHash computation

  • Key: DDSIRTP23-32
  • Legacy Issue Number: 19730
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

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

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

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

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

    With
    "If the maximum size of the sequential CDR encapsulation of all the key fields is guaranteed to be less or equal than 128 bits,"
  • Reported: DDSI-RTPS 2.0b1 — Mon, 2 Mar 2015 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

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

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

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Table 9.13 "reserved for future use" rows

  • Key: DDSIRTP23-77
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The presence of the final three rows of the table with "Reserved for future use" is confusing, why is it in the specification if all (non-vendor-specific) PIDs are effectively reserved?
  • Reported: DDSI-RTPS 2.2 — Mon, 18 Dec 2017 17:48 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Remove PID_GROUP_ENTITYID and PID_PARTICIPANT_ENTITYID

    PID_GROUP_ENTITYID and PID_PARTICIPANT_ENTITYID are not currently used for any purpose and are not being sent by any known implementors. They have therefore been removed from the specification.

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Reorganizing section 9.3.2

  • Key: DDSIRTP23-90
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Section 9.3.2 largely consists of a single 5-page table (Table 9.4). This creates a usability issue for the spec where important lists of constants (like the BuiltinEndpointSet_t values) need to be found within the huge table instead of directly being referred to by other parts of this spec or other specs (Security).
  • Reported: DDSI-RTPS 2.2 — Fri, 12 Jan 2018 19:49 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Split Table 9.4

    When current rows of Table 9.4 contain their own tables of constants (beyond just trivial constants that we don't expect to change in future minor versions), make these constants their own tables.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Incorrect definition of SequenceNumberSet

  • Key: DDSIRTP23-37
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 9.4.2.6 (SequenceNumberSet)

    Specifies that

    A valid SequenceNumberSet must satisfy the following conditions:
    • bitmapBase >= 1
    • 0 < numBits <= 256
    • there are M=(numBits+31)/32 longs containing the pertinent bits

    This is seems like an error in how the spec is worded.
    What it was trying to say is that for the bitset to represent a set f bits then it must be that 0 < numBits <= 256

    However the case with numBits=0 is still valid. It represents an empty set, but the bitmapBase still carries information since. This is use by the ACKNAK sub-message to acknowledges al sequence numbers less or equal to bitmapBase without Nacking anything.
  • Reported: DDSI-RTPS 2.2 — Wed, 30 Mar 2016 20:21 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    *Update SequenceNumberSet definition to explicitly allow 0-bits *

    The current definition of the SequenceNumberSet requires at least 1 bit in the bitset but there are use cases where 0 bits are needed so the definition will be updated.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Semantics of AckNack's Final Flag

  • Key: DDSIRTP23-36
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Users found that OpenDDS and CoreDX did not interoperate due to different interpretations of the Final Flag in AckNack.

    The use of FinalFlag in Heartbeat is pretty clear, but its extension to AckNack seems to be under-specified.

    This section tells us little:

    The FinalFlag indicates whether a response by the Writer is expected by the Reader or if the decision is left to the Writer. The use of this flag is described in 8.4.

    That last sentence is unhelpful as section 8.4 takes up about 60 pages. Searching through 8.4 results in very little about the AckNack's Final Flag.

    The key question is what is meant by "response by the Writer". Considering AckNacks that are both Final and have at least one "1" bit in the bitmap, is the Writer obligated to send the nacked DATA?

    a. One interpretation is that the Final Flag is a simple (constant-time) indication that the Writer need not resend DATA even with a "1" in the bitmap – in this scenario the Writer need not even read the bitmap. The AckNack is still useful because the bitmapBase can bump up the acknowledge sequence number.

    b. The other interpretation is that the presence of a "1" in the bitmap overrides the Final flag and the Writer must reply with DATA. In this interpretation the Final flag is used to indicate whether or not another HEARTBEAT is sent "soon" (instead of waiting for periodic heartbeat), but has no impact on sending DATA.
  • Reported: DDSI-RTPS 2.2 — Wed, 27 Jan 2016 16:06 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Clarify the meaning of the ACKNACK Final Flag

    The description of the ACKNACK final flag is not clear as to what is the expected behavior. The description needs to be updated to make clear that the absence of the Final Flag requires that the Writer send a HB and the presence of the flag leaves the decision up to the Writer.

  • Updated: Wed, 19 Dec 2018 16:38 GMT

RTPS Minor version should take into consideration DDS-Security

  • Key: DDSIRTP23-39
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS-Security 1.1 specification updated the RTPS minor version to 3. Consequently the result of the RTPS 2.3 RTF should be update the Minor version to 4 (not 3), assuming there are changes to the protocol.

    The section that states the RTPS minor revision should also reference DDS-Security so is clear that that specification may also update the minor versions and future revisions of RTPS take it into consideration.
  • Reported: DDSI-RTPS 2.2 — Sat, 8 Jul 2017 00:15 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Incorporate changes made by the DDS-Security specification to RTPS into the RTPS spec

    The DDS-Security specification reserves new ParameterIds and submessageIds which need to be included as reserved in the RTPS spec. Also, due to these changes, the DDS-Security Spec updated the RTPS minor version to 3, therefore the newest version of the RTPS spec shall be 2.4.

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Reference reserved ParameterIDs for DDS-Security and dependencies

  • Key: DDSIRTP23-38
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS-Security specification reserved a range of parameter IDs. Specifically section 7.4.1.3 (Reserved RTPS parameter IDs) of DDS-Security 1.1 states:

    This specification reserves the RTPS Simple Discovery Protocol ParameterIDs in the range: 0x1000 to 0x1FFF and 0x5000 to 0x5FFF.
    The second interval covers the same range of parametersID, except they have the must-understand bit set.
    This reserved range applies to RTPS version 2.3 (see 7.3.6.1) and higher minor revisions of RTPS. Future revisions of the DDS-RTPS specification shall take into consideration this fact.

    This reserved range should be included into the RTPS specification itself and a reference to DDS-Security so future revisions of RTPS can respect this reservation.
  • Reported: DDSI-RTPS 2.2 — Sat, 8 Jul 2017 00:12 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    Duplicates DDSIRTP23-39

    The proposal for issue DDSIRTP23-39 covers all changes required by the next version of the RTPS specification as a result of the most recent DDS-Security spec.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Figure 8.1 has extra classes. Figures 8.2 and 8.5 are missing attributes

  • Key: DDSIRTP23-97
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Figure 8.1 shows a DataReader and DataWriter but these classes are not explained in Table 8.1 as all other are.

    These classes seem unnecessary to the explanations on section 8.2.1 so they should be removed from the figure. They are already explained in Figure 7.3.

    In addition the explanation of the attributes in Table 8.2 mentions GUID_t, GuidPrefix_t, EntityId_t, Locator_t, VendorId_t, and ProtocolVersion_t which are not shown in the figure.

    Figure 8.1 should be updated to show were those attributes are used.

    Figures 8.2 and 8.5 are missing the Participant attribute guidPrefix and the Endpoint attribute endpointId
  • Reported: DDSI-RTPS 2.2 — Sat, 27 Jan 2018 02:20 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Update figure 8.1, 8.2, and 8.5

    Update figure 8.1. Remove DataWriter and DataReader and adding the missing attributes as described in the issue.
    Update figures 8.2 and 8.5 adding the missing attributes
  • Updated: Wed, 19 Dec 2018 16:38 GMT
  • Attachments:

Remove/deprecate Property_t, EntityName_t, PID_PROPERTY_LIST

  • Key: DDSIRTP23-75
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Table 9.4
    Property_t and EntityName_t are unused, so these can be removed without making any actual changes to the protocol

    Table 9.12
    PID_PROPERTY_LIST is unused, remove it from the table
  • Reported: DDSI-RTPS 2.2 — Mon, 18 Dec 2017 17:41 GMT
  • Disposition: Closed; No Change — DDSI-RTPS 2.3
  • Disposition Summary:

    Do not remove Property_t and EntityName_t

    There are open issues to add EntityName_t and Property_t to the DDS specification and Property_t is already being used in the DDS-Security Spec. These two types and PIDs have therefore not been removed from RTPS as they will be used once they have been added to the DDS specification.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

PIM-PSM inconsistent BuiltInEndpoints

  • Key: DDSIRTP23-74
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Table 8.73 "availableBuiltinEndpoints" describes the PIM's datatype BuiltinEndpointSet_t using 6 constants (note: change text in this table to indicate that each constant denotes a potential member of the Set not the Set itself). The PIM also maps these constants to EntityId_t values in 8.5.4.2.

    The PSM fails to directly reference these constants for BuiltinEndpointSet_t in Table 9.4.

    PIM PSM notes
    none DISC_BUILTIN_ENDPOINT_PARTICIPANT_ANNOUNCER needed?
    none DISC_BUILTIN_ENDPOINT_PARTICIPANT_DETECTOR needed?
    PUBLICATIONS_WRITER DISC_BUILTIN_ENDPOINT_PUBLICATION_ANNOUNCER clarify mapping
    PUBLICATIONS_READER DISC_BUILTIN_ENDPOINT_PUBLICATION_DETECTOR clarify mapping
    SUBSCRIPTIONS_WRITER DISC_BUILTIN_ENDPOINT_SUBSCRIPTION_ANNOUNCER clarify mapping
    SUBSCRIPTIONS_READER DISC_BUILTIN_ENDPOINT_SUBSCRIPTION_DETECTOR clarify mapping
    TOPIC_WRITER missing add to PSM
    TOPIC_READER missing add to PSM
    none DISC_BUILTIN_ENDPOINT_PARTICIPANT_PROXY_ANNOUNCER remove?
    none DISC_BUILTIN_ENDPOINT_PARTICIPANT_PROXY_DETECTOR remove?
    none DISC_BUILTIN_ENDPOINT_PARTICIPANT_STATE_ANNOUNCER remove?
    none DISC_BUILTIN_ENDPOINT_PARTICIPANT_STATE_DETECTOR remove?
    PSM-only BUILTIN_ENDPOINT_PARTICIPANT_MESSAGE_DATA_WRITER add to PIM?
    PSM-only BUILTIN_ENDPOINT_PARTICIPANT_MESSAGE_DATA_READER add to PIM?

    To satisfy the PIM, the PSM must also describe how vendors add extensions to this list. Perhaps the best way to do that is to use a separate vendor-specific PID, but that should be described in the PSM to avoid vendors using reserved bits.

    It would be good if the spec was consistent about naming for the PSM constants. Some start with DISC_ while others don't. Some use the brand new terms "announcer" and "detector", others don't.
  • Reported: DDSI-RTPS 2.2 — Mon, 18 Dec 2017 17:34 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Clarify the PIM-PSM mapping for BuiltinEndpoints

    There are some inconsistencies between the PIM and PSM with regards to the builtin endpoints which have bits reserved in the availableBuiltinEndpoints. Some possible values are missing from the PIM that are referenced in the PSM and vice versa. Because the PIM and PSM use different names, the mapping between the constants that are defined in the PIM and their corresponding constants in the PSM has also been clarified.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

resendDataPeriod in StatelessWriter

  • Key: DDSIRTP23-73
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    resendDataPeriod is listed in Figure 8.15, Table 8.49, and pseudocode 8.4.7.2.1
    The issue is that nothing in the definition of StatelessWriter's behavior (8.4.8) describes how resendDataPeriod is used.
  • Reported: DDSI-RTPS 2.2 — Mon, 18 Dec 2017 17:08 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Remove resendDataPeriod from the StatelessWriter reference implemenation

    The member resendDataPeriod of the StatelessWriter is not referenced in the described StatelessWriter's behavior and seems unnecessary. It will therefore be removed.

  • Updated: Wed, 19 Dec 2018 16:38 GMT
  • Attachments:

Deprecate PID_PARTICIPANT_BUILTIN_ENDPOINTS

  • Key: DDSIRTP23-72
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    It seems as though implementations are using PID_BUILTIN_ENDPOINT_SET instead of PID_PARTICIPANT_BUILTIN_ENDPOINTS for the ParticipantProxy::availableBuiltinEndpoints.

    Some implementations accept both, but from the information we have so far, all implementations are sending PID_BUILTIN_ENDPOINT_SET.

    We can add this PID to Table 9.17 as described in DDSIRTP23-48.

  • Reported: DDSI-RTPS 2.2 — Fri, 15 Dec 2017 19:09 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    Merged with resolution of DDSIRTP23-11

    The resolution of DDSIRTP23-11 was to deprecate a number of PIDs, the resolution of this issue was therefore added to that proposal by adding the deprecated PID_PARTICIPANT_BUILTIN_ENDPOINTS to the table described in DDSIRTP23-48.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Include the padded bits into the Encapsulation options

  • Key: DDSIRTP23-71
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Per the resolution of http://issues.omg.org/browse/DDSXTY12-10 the lower 2 bits of the encapsulation options shall be use to encode how many padding bits were added.

    This informations should be added to section 10.2.1.2 and an issue should be added to XTYPES 1.3 to remove it from there.

    Furthermore to avoid confusion/ambiguities we should be explicit about the endianess used to encode the "ushort options".

    Unless this would cause problems to existing implementations I would suggest we either state that the "ushort options" is always serialized using BigEndian or equivalently we change the type to octet[2] instead of "ushort".

    The reason is that the alternative interpretation, namely use the endianness implied by EncapsulationIdentifier is not well defined in all cases. Not all EncapsulationIdentifier kinds explicitly select an Endianness. The ones referenced in RTPS: CDR_BE, CDR_LE, PL_CDR_BE, and PL_CDR_LE that are defined in do. But others, including the "XML" defined in XTYPES do not. So RTPS could not make a general statement about the encoding of the "ushort options" unless the statement is to fix the endianess independent of the EncapsulationIdentifier.
  • Reported: DDSI-RTPS 2.2 — Fri, 15 Dec 2017 10:23 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    Merged with resolution of DDSIRTP23-42

    The resolution of this issue has been merged with the resolution of DDSIRTP23-42
  • Updated: Wed, 19 Dec 2018 16:38 GMT

InfoTimestamp dates past 2038

  • Key: DDSIRTP23-70
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The seconds portion of the Time_t structure used for InfoTimestamp is limited to 32 bits, so it can't represent dates past 2038.
  • Reported: DDSI-RTPS 2.2 — Thu, 14 Dec 2017 23:22 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Update Time_t to have an unsigned seconds field

    To support time stamps past the year 2038. the type of the seconds member in Time_t has been updated from a signed integer to unsigned. This will not rollover until the year 2106.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Normative references for IDL and CDR

  • Key: DDSIRTP23-69
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The previous RTF (2.2) had an issue (#7) that cleaned up IDL syntax. A note in the resolution of that issue indicated that RTPS should have a normative for this. Back then, that reference was to formal/11-11-01, a chapter of CORBA. Today we can use IDL 4.1 formal/17-05-07.

    Similarly, the spec is not implementable without knowledge of the CDR encoding. This is defined in formal/12-11-14, chapter 9.
  • Reported: DDSI-RTPS 2.2 — Tue, 12 Dec 2017 16:53 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Add missing normative references

    There are some missing normative references which should be added in section 3. They are:

    • IDL 4.1
    • CDR
    • IETF RFC 1305 (NTP Time)
    • IETF RFC 1321 (MD5)
  • Updated: Wed, 19 Dec 2018 16:38 GMT

BestEffort StatefulReader behavior does not handle GAP

  • Key: DDSIRTP23-100
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section 8.4.12.1 Best-Effort StatefulReader Behavior the state machine does not handle the GAP message.

    Best-Effort readers also process GAP messages so this should be reflected in the state machine.
  • Reported: DDSI-RTPS 2.2 — Wed, 7 Feb 2018 03:40 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Add transition for when Best Effort Readers Receive GAP messages

    The Best-Effort Stateful Reader Behavior should include logic for when a GAP message is received, similar to the logic already present for its Reliable counterpart.
  • Updated: Wed, 19 Dec 2018 16:38 GMT
  • Attachments:

Section 8.4.14.1.1, Bullet 3: Put precise bounds on the fragment size

  • Key: DDSIRTP23-19
  • Legacy Issue Number: 16966
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 120
    Change: Fragment size should be allowed to be equal to (instead of strictly greater than) 1KB, also define KB as 1024 bytes to avoid the KB/KiB issue (1000 vs. 1024).
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Remove the lower bound for fragment sizes

    We see no need to specify the lower bound for fragment sizes so we will remove that requirement.

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section 8.4.8.1.4: When does Best-Effort Stateless Writer send a GAP

  • Key: DDSIRTP23-21
  • Legacy Issue Number: 16964
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 85
    Change: Figure 8.16 notes that transition T4 can send a GAP, but this section doesn't describe when/how to send a GAP.
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    This issue is resolved as part of DDSIRTP23-20

    This issue is resolved as part of DDSIRTP23-20
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Referencing current version of DDS spec (was: Clarification of link comment)

  • Key: DDSIRTP23-5
  • Legacy Issue Number: 19237
  • Status: closed  
  • Source: gmail.com ( James Pope)
  • Summary:

    Please excuse my learning curve here.

    Section 6.1 says that this formal is a supplement to Version 1.1 formal, However there is now a version 1.2. That MIGHT suggest that aspects of 1.2 is not within interoperability to this specification. and that this one is interoperable to 1.1. Which I understand is across major versions and not a mandate.

    Anyway Please clareify.
    Is there a document that has version differences overview. If so a reference to that would be value added as well.
  • Reported: DDSI-RTPS 2.1 — Tue, 11 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Update references to the DDS Spec with the current 1.4 version

    Replace references to DDS version 1.2 with the most current version, 1.4
  • Updated: Wed, 19 Dec 2018 16:38 GMT

The Writer Liveliness Protocol should be removed

  • Key: DDSIRTP23-7
  • Legacy Issue Number: 17285
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The DDSI v2.1 specification describes in section 8.4.13 the Writer Liveliness Protocol as the mechanism used by participants to assess the liveliness of their contained data writers (with automatic liveliness).

    The Writer Liveliness Protocol is specified as mandatory for compliant implementations.

    The first remark is that the Writer Liveliness Protocol is not required at all for interoperability, thus it should not be a mandatory requirement for compliant implementation. This is not only easy to reason about, but wireshark captures made during the DDS interoperability demo of the past March 2012 showed how different DDS implementations could work w/o using this protocol.

    Beyond that, the protocol is simply superfluous as DataWriter liveliness can be anyway asserted via the Participant Liveliness, this in turns is asserted by the participant discovery protocol.

    Beyond the potential waste of resource required by yet another periodic information flow, what seems very odd is the choices of QoS for the built-in entities that write this periodic message. As described in section 8.4.13.3 these built-int entities communicate reliably and have a history set to KeepLast(1), along with TransientLocal durability.

    This QoS settings only "works" best for those implementations that tie the reliability send queue to the writer history but is less than ideal for those that rightfully decouple history and reliability.

    Anyway, however one looks at it this part of the specs seems bogus. In addition as mentioned above is not required for interoperability and generates yet another stream of periodic messages.

    The recommendation is to remove this section from the next version of the standard.

  • Reported: DDSI-RTPS 2.1 — Thu, 29 Mar 2012 04:00 GMT
  • Disposition: Closed; No Change — DDSI-RTPS 2.3
  • Disposition Summary:

    No Need to remove the Writer Liveliness Protocol

    The RTF does not see a need to remove the Writer Liveliness Protocol from the specification.

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section: 9.6.2.2.2, Table 9.13: Missing ParameterId mappings for RTPS fields

  • Key: DDSIRTP23-8
  • Legacy Issue Number: 16984
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 184-187
    Change: The following RTPS fields lack a mapping: ParticipantProxy::guidPrefix, ReaderProxy::remoteReaderGuid, WriterProxy::remoteWriterGuid. Table 9.10 indicates that they are optional, but they are not possible to encode without a mapping. Also, DiscoveredReaderData::contentFilterProperty (AKA DiscoveredReaderData::contentFilter in the PIM: these should be consistent) is lacking a mapping
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Cleanup up missing and unused ParameterId mappings

    Add a missing PID_ENDPOINT_GUID and map SubscriptionBuiltinTopicData::key and PublicationBuiltinTopicData::key to it.

    Add missing mapping of DiscoveredReaderData::contentFilterProperty, TopicBuiltinTopicData::topic_data, SubscriptionBuiltinTopicData::durability, PublicationBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::presentation

    Remove the mapping of SubscriptionBuiltinTopicData::lifespan, which is not present in DDS
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section: 9.6.2.2.2, Table 9.13: Missing ParameterId mappings for DDS fields

  • Key: DDSIRTP23-9
  • Legacy Issue Number: 16983
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 185
    Change: The following DDS fields lack a mapping: TopicBuiltinTopicData::topic_data, SubscriptionBuiltinTopicData::durability, PublicationBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::presentation, and the "key" field in Publication, Subscription, and Topic. Also, the mapped DDS field SubscriptionBuiltinTopicData::lifespan does not exist in DDS
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    Duplicates DDSIRTP23-8

    The resolution of DDSIRTP23-8 covers the resolutions of the missing/unnecessary mappings described in DDSIRTP23-9

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section: 9.6.2.2.2, Table 9.12: Duration_t not defined by PSM

  • Key: DDSIRTP23-10
  • Legacy Issue Number: 16982
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 184
    Change: Duration_t (used for PID_PARTICIPANT_LEASE_DURATION) is not defined in the PSM. Use Time_t instead?
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Define a PSM Mapping for Duration_t

    A PSM mapping of Duration_t has been defined in Table 9.4, specifying that the representation on the wire should be NTP.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section 9.6.2.2.2, Table 9.12: Specify IPv4Address_t and Port_t

  • Key: DDSIRTP23-11
  • Legacy Issue Number: 16981
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 183-184
    Change: IPv4Address_t and Port_t are not defined anywhere in the specification
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    *Deprecate PIDs *

    There are a number of PIDs for address and port fields that are no longer necessary or used since the information that they identify is sent in the form of a Locator, we are therefore deprecating these PIDs:
    PID_MULTICAST_IPADDRESS
    PID_DEFAULT_UNICAST_IPADDRESS
    PID_DEFAULT_UNICAST_PORT
    PID_METATRAFFIC_UNICAST_IPADDRESS
    PID_METATRAFFIC_UNICAST_PORT
    PID_METATRAFFIC_MULTICAST_IPADDRESS
    PID_METATRAFFIC_MULTICAST_PORT

    PID_PARTICIPANT_BUILTIN_ENDPOINTS is also not used and will be deprecated. Implementations are using PID_BUILTIN_ENDPOINT_SET instead.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section 9.6.2.2: What is the "key" parameter?

  • Key: DDSIRTP23-15
  • Legacy Issue Number: 16980
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 182
    Change: This section refers to a non-existent "key parameter" in the Data submessage.
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Clarify what the "key" parameter in section 9.6.2.2 is referring to

    In section 9.6.2.2 the phrase '"key" parameter' is referring to the parameters listed in table 9.10, the language used to indicate this should be clarified.

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section 9.6.2.2: Describe key-only encoding of built-in data types

  • Key: DDSIRTP23-12
  • Legacy Issue Number: 16979
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 181
    Change: This section under-specifies the key fields for all four data types. The "inherited" DDS structures do not provide a key field that is useful for RTPS because it is vendor-specific. This section should describe what a "key only" (KeyFlag==1) Data Submessage should contain as its payload for both SPDP and for all 3 types of SEDP. Table 9.13 indicates that Built-In Topic Keys can be encoded as a GUID, which has no correspondence to the actual definition of Built-In Topic Keys.
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Describe the contents of the key-only Data Submessage for each of the Builtin Topic Types

    Descriptions have been added to clarify that a key-only submessage for each of the Built-in Topic types requires:
    PID_PARTICIPANT_GUID (for SPDP)
    PID_ENDPOINT_GUID (for SEDP)

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section 9.6.2.2: Duration_t used in IDL, not defined

  • Key: DDSIRTP23-14
  • Legacy Issue Number: 16978
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 181
    Change: Duration_t (used for leaseDuration) is not defined in the PSM. Use Time_t instead?
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Duplicate or Merged — DDSI-RTPS 2.3
  • Disposition Summary:

    Duplicates DDSIRTP23-10

    Merged with DDSIRTP23-10
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section 8.7.6: RTPS support for semantics not present in DDS

  • Key: DDSIRTP23-16
  • Legacy Issue Number: 16970
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 147
    Change: There is no such "directed" or "peer-to-peer" function described by the DDS spec, therefore none is available to the user. If such a function should be used by RTPS to implement DDS communication, its use by RTPS must be described here. Otherwise remove this section.
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Remove explicit dependency on DDS api

    Accept suggested approach of editing section 8.7 to remove explicit dependency on DDS APIs
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section 8.5.3.2, Table 8.73: Make defaultUnicastLocatorList optional

  • Key: DDSIRTP23-13
  • Legacy Issue Number: 16969
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 127
    Change: In the row for defaultUnicastLocatorList, "at least one Locator must be present" constrains implementations unnecessarily. As long as each Endpoint has a locator, there is no need for the participant to have a default locator
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — DDSI-RTPS 2.3
  • Disposition Summary:

    Do not make the defaultUnicastLocatorList optional

    As the proposed change breaks backwards compatibility, the decision has been made to defer this issue to a major revision of the protocol. The label RTPS3 has been added to indicate this and to aid in future searches of issues like this one.

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section: 8.5.3.2, Figure 8.27 and Table 8.73

  • Key: DDSIRTP23-17
  • Legacy Issue Number: 16968
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 126-127
    Change: In the figure and the table, BuiltinEndpointSet_t is already a "set" so it should not also be an array with "[*]"
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Closed; Out Of Scope — DDSI-RTPS 2.3
  • Disposition Summary:

    Already fixed in 2.2

    Already fixed in 2.2
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Section 8.4.15.7: Scope of the count fields of Heartbeat and AckNack/NackFrag

  • Key: DDSIRTP23-18
  • Legacy Issue Number: 16967
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 123
    Change: Scope of counts is underspecified: is a Heartbeat count scoped to one Writer; is an AckNack/NackFrag count scoped to a Reader itself or to a Reader's conversation with a given Writer?
  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Clarify the scope of the HeartBeat and AckNack Submessage Count fields and how to deal with overflow in the count fields

    The scope of the count fields of the HeartBeat and AckNack have been clarified to make it clear that it is up to the implementation if it keeps track of each endpoint separately or reuses the epoch across endpoints as long as the epoch changes from the previous one sent to an endpoint.

    Clarification as to how overflow in these fields should be handled by an implementation has also been added.

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Locator_t kind needs a reserved range and a range for vendor extensions

  • Key: DDSIRTP23-2
  • Legacy Issue Number: 19694
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Locator_t contains an integer field that identifies the type of locator. Currently only the values -1, 0, 1, 2 are defined. Which correspond to reserved values as well as UDPv4 and UDPv6.

    Future revisions of the protocol may define additional kinds for things like TCP v4, TCPv6, shared memory and other transports.

    At the same time vendors are using this field to identify their own custom transports.

    To avoid collisions with future revisions of the protocol, the RTPS specification should reserve a range. For example, all kinds with values less than 0x00008000. These values should be reserved for future revisions of the protocol. Vendors that want to define their custom transport should use Locator_t kind with values between 0x00008000 and 0x0000FFFF (inclusive). And these values should be interpreted in the context of the RTPS vendorId so that different vendors can use the same value to mean different things.
  • Reported: DDSI-RTPS 2.2 — Thu, 18 Dec 2014 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Reserve protocol and vendor specific ranges for the Locator_t kind

    To avoid future conflicts with vendor-specific Locator_t kinds, ranges have been reserved for the protocol, for vendors, and for users.
    0x00000003 - 0x000001f are reserved for vendors
    0x00000020 - 0x00007ffff for future use by the spec.
    0x00008000-0x01FFFFFF (inclusive) for use by vendors.
    0x02000000 and greater are reserved for third-party add-ons
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Some constants specified in PSM table 9.4 conflict with the ones used in wireshark

  • Key: DDSIRTP23-4
  • Legacy Issue Number: 19508
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In table 9.4 the the PSM RTPS define ReliabilityKind_t defines RELIABLE as having the value 3. However the Wireshark packet dissector defines ReliabilityKind_t RELIABLE as having the value 2.

    In table 9.4 the PSM RTPS specification defines LOCATOR_KIND_UDPv6 having the value 2. However the Wireshark packet dissector defines LOCATOR_KIND_UDPv6 as having the value 8.

    The vendors interoperate and used Wireshark to fine-tune their discovery therefore they are actually using the Wireshark-defined values rather than the ones in table 9.4

    Proposed resolution:

    Modify Table 9.4 entry for ReliabilityKind_t from:
    #define RELIABLE 3

    to
    #define RELIABLE 2

    Modify Table 9.4 entry for Locator_t from:
    #define LOCATOR_KIND_UDPv6 2

    to
    #define LOCATOR_KIND_UDPv6 8
  • Reported: DDSI-RTPS 2.0b1 — Thu, 3 Jul 2014 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    *Change the value of RELIABLE_RELIABILITY and add a description of how it is marshalled *

    RELIABLE_RELIABILITY is currently defined with the value 3, however in practice all implementations are using 2, so the value has been changed in the spec.

    It was also noted that the values in the RTPS spec differ from the API-level values defined in the DDS spec. Therefore, a description of how to marshal the DDS-defined ReliabilityQosPolicy on the wire.

  • Updated: Wed, 19 Dec 2018 16:38 GMT

Sending a HeartBeat message when there is no data is unspecified

  • Key: DDSIRTP23-66
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Sending a HeartBeat message when a writer has no data to announce is unspecified.

  • Reported: DDSI-RTPS 2.2 — Sun, 10 Dec 2017 23:47 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    Update the definition of the HeartBeat Submessage to allow situations in which the Writer has no data to announce

    The HeartBeat submessage has been updated to better handle the situation in which a Writer has no data in its cache to announce.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Link to RTPS VendorId web page is broken

  • Key: DDSIRTP23-41
  • Status: closed  
  • Source: MORSE-Corp ( Eddy Scott)
  • Summary:

    The web link pointed to by the specification: http://www.omgwiki.org/dds/content/page/dds-rtps-vendor-andproduct-ids results in a page not found returned from the server. A brief search of the internet for the list of VendorIds results in nothing found.

  • Reported: DDSI-RTPS 2.2 — Tue, 29 Aug 2017 14:29 GMT
  • Disposition: Resolved — DDSI-RTPS 2.3
  • Disposition Summary:

    *Update URL for assigned vendor ids *

    The URL for the assigned vendor and product IDs has been updated to point to a valid location with that information.
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Rename BuiltinEndpointKind and add description

  • Key: DDSIRTP23-1
  • Legacy Issue Number: 11034
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    This type is actually a set of boolean flags and so should be renamed to reflect its actual intention. Additionally, the description for this type is missing from Table 9.4.

    Proposed Resolution:
    Rename the type from BuiltinEndpointKind to BuiltinEndpointSet_t. Provide an entry in Table 9.4 to describe the type.

    Revised Text:
    In Table 8.77, the third row from the end (the cell in the first column reads "availableBuiltinEndpoints"), replace "BuiltinEndpointKind" with "BuiltinEndpointSet_t."

    Replace Figure 8.26 with:

    In Table 9.4, add the following row to the end of the table:

    BuiltinEndpointSet_t Mapping of the type
    typedef unsigned long BuiltinEndpointSet_t;
    where
    #define DISC_BUILTIN_ENDPOINT_PARTICIPANT_ANNOUNCER 0x00000001 << 0;
    #define DISC_BUILTIN_ENDPOINT_PARTICIPANT_DETECTOR 0x00000001 << 1;
    #define DISC_BUILTIN_ENDPOINT_PUBLICATION_ANNOUNCER 0x00000001 << 2;
    #define DISC_BUILTIN_ENDPOINT_PUBLICATION_DETECTOR 0x00000001 << 3;
    #define DISC_BUILTIN_ENDPOINT_SUBSCRIPTION_ANNOUNCER 0x00000001 << 4;
    #define DISC_BUILTIN_ENDPOINT_SUBSCRIPTION_DETECTOR 0x00000001 << 5;
    #define DISC_BUILTIN_ENDPOINT_PARTICIPANT_PROXY_ANNOUNCER 0x00000001 << 6;
    #define DISC_BUILTIN_ENDPOINT_PARTICIPANT_PROXY_DETECTOR 0x00000001 << 7;
    #define DISC_BUILTIN_ENDPOINT_PARTICIPANT_STATE_ANNOUNCER 0x00000001 << 8;
    #define DISC_BUILTIN_ENDPOINT_PARTICIPANT_STATE_DETECTOR 0x00000001 << 9;
    #define BUILTIN_ENDPOINT_PARTICIPANT_MESSAGE_DATA_WRITER 0x00000001 << 10;
    #define BUILTIN_ENDPOINT_PARTICIPANT_MESSAGE_DATA_READER 0x00000001 << 11;
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Closed; No Change — DDSI-RTPS 2.3
  • Disposition Summary:

    This issue was already resolved

    This issue was already resolved as part of the first FTF. It must have been incorrectly imported when tranitioning to Jira
  • Updated: Wed, 19 Dec 2018 16:38 GMT

Erratum

  • Key: DDSIRTP23-136
  • Status: open  
  • Source: eProsima ( Mr. Jaime Martin-Losa)
  • Summary:

    An erratum has been attached with some grammatical mistakes we found.
  • Reported: DDSI-RTPS 2.2 — Wed, 5 Dec 2018 11:26 GMT
  • Updated: Mon, 17 Dec 2018 14:39 GMT
  • Attachments:

Remove the 'default' case in Requst and Return union types

  • Key: DDSRPC11-3
  • Status: open  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    Section 7.5.1.1.4 Mapping of Interfaces to the Request Topic Types, and Section 7.5.1.1.5 Mapping of Interfaces to the Reply Topic Types, each define a union and specify that the union should have a 'default:' case.

    This makes it difficult to extend the union to support interface inheritance.

    The 'default:' case should be removed.
  • Reported: DDS-RPC 1.0 — Wed, 12 Dec 2018 23:42 GMT
  • Updated: Wed, 12 Dec 2018 23:42 GMT

Fix a number of typos in specification document

  • Key: DDSXML11-1
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    In section 7.3.2.4.4.1, the "Is equivalent to the following XML" paragraph has the wrong style. It should be "Text Body" rather than monospace.
  • Reported: DDS-XML 1.0 — Mon, 29 Oct 2018 15:48 GMT
  • Updated: Mon, 29 Oct 2018 15:48 GMT

Namespace are uncompliant with OMG Policy for XML Namespaces in OMG Specifications

  • Key: DDSXML-2
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    DDS-XML schema files use the http://www.omg.org/dds namespace to be consistent with the schema files it incorporated from other DDS specifications. However, this namespace is uncomplaint with the OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces in OMG Specifications (see smsc/15-03-06 for its latest version).

    Consequently, we must replace http://www.omg.org/dds with a compliant namespace as part of this FTF. Given the rule specified in smsc/15-03-06:

    <XML Namespace URI> ::= <specification URI>[<dated version
number>"/"][<suffix>"/"]

    We could define the following compliant namespaces:
  • Reported: DDS-XML 1.0b1 — Mon, 8 Jan 2018 09:53 GMT
  • Disposition: Resolved — DDS-XML 1.0
  • Disposition Summary:

    Replace targetNamespace definitions with a compliant namespace

    Replace the uncompliant namespace specified in all the building blocks defined in clause 7.3 of the specification document and all machine readable XSD files (i.e., "http://www.omg.org/dds") with a namespace compilant with smsc/15-03-06: "http://www.omg.org/spec/DDS-XML".
  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Fix inconsistent rules for references between elements

  • Key: DDSXML-1
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    The syntax in DDS-XML contains places where an object references another object (e.g., topic_ref, domain_ref, type_ref or base_name). This is done normally using an attribute with type elementNameReference defined in http://www.omg.org/spec/DDS-XML/20170301/dds-xml_domain_definitions_nonamespace.xsd

    However, this rule is not applied consistently throughout the schema files in the specification. More specifically, the XSD associated with Building Block QoS use elementName for base_name, which is incorrect.

    Therefore, the definition of elementNameReference must be moved to the QoS building block, which is a dependency of all building blocks defining references.
  • Reported: DDS-XML 1.0b1 — Mon, 8 Jan 2018 09:25 GMT
  • Disposition: Resolved — DDS-XML 1.0
  • Disposition Summary:

    Change type of all references to elementNameReference

    The proposed solution moves the definition of elementNameReference from dds-xml_domain_definitions_nonamespace.xsd to dds-xml_qos_definitions_nonamespace.xsd and changes the type of all base_name attributes from elementName to elementNameReference.
  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Add OMG URL to schemaLocation attributes

  • Key: DDSXML-9
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    SchemaLocation attributes in the machine readable XSD and XML files reference documents in the working directory. This works well then he documents are local and the documents that are being included are in the working directory. However, because these files are going to be uploaded to the OMG servers, we must add the URLs to ensure that inclusions and imports will always work.

    This FTF must generate its report in May of 2018; therefore, the URL where the XML and XSD files will end up being published will be the following: "http://www.omg.org/spec/DDS-XML/20180501/"
  • Reported: DDS-XML 1.0b1 — Sun, 13 May 2018 18:59 GMT
  • Disposition: Resolved — DDS-XML 1.0
  • Disposition Summary:

    Add updated URL to schemaLocation attributes

    The proposal is to prepend the files included and imported by XSD and XML files with the following URL: "http://www.omg.org/spec/DDS-XML/20180501/"
  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

DDS System Block Set lacks Schema File and Example

  • Key: DDSXML-7
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    The DDS System Building Block defined in sub clause 8.1 lacks a properly documented schema file and an example XML file that may be reused by other specifications (e.g., DDS-XRCE).

    The RFC included a schema file (dds-xml_system_example.xsd) and an XML file (dds-xml_system_example.xml). However, these files were considered non-normative and were not linked to the specification document or the DDS System Building Block in any way.

    This FTF should:

    • move "dds-xml_system_example.xsd" to a pair of schema files following the chameleon schema patter (i.e., one without namespace and one with the standard namespace as modified by DDSXML-2).
    • update "dds-xml_system_example.xml" to reference the file with a namespace.

    Moreover, we should simplify the definition of the DDS top level element to be a choice of minOccurs="0" and maxOccurs="unbounded", which produces the same complexType with a more compact and correct syntax.

    Finally, we should update clause 8.1 to link the building block to the corresponding schema files.

  • Reported: DDS-XML 1.0b1 — Sun, 13 May 2018 10:50 GMT
  • Disposition: Resolved — DDS-XML 1.0
  • Disposition Summary:

    Create proper schema and example files for DDS Building Block Set

    This resolution applies the following changes:
    1. It creates proper schema and example files for the DDS Building Block Set defined in clause 8.1.
    2. It transforms the DDS top-level type definition into a simple choice.
    3. It adds a short paragraph at the end of clause 8.1 to reference those documents.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Minor typos, inconsistencies, and updates in specification document

  • Key: DDSXML-5
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    The specification includes a number of typos that should be fixed:

    • On Table 7.2, the caption should be "Supported XML Attribute Values" instead of "Supported XML Element Values"
    • In section 7.1.3.2.1 Using Schema Files with Different Namespaces fix closing tag of "datareader_qos", which is incorrectly labeled as "dateader_qos".
    • In section 7.2.3.1, the type of the "kind" element should be "historyKind" instead of "dds:historyKind".
    • In section 7.2.4.2.1, rename "Binary" simpleType as "ddsBinary" and change the value element's type to "ddsBinary".
    • In section 7.3.4.4.1.1 change the topic name from "FisrstTopic" to "FirstTopic".

    Moreover, the specification includes some inconsistencies:

    • Section 7.1.1 states that the XML representation of DDS-related resources shall use <dds> as the root of every document; however, this is incompatible with the flexibility offered by building blocks. It is also incompatible with having a root for type representation such as <types>. We should simply remove this requirement.

    Finally, some of the references are outdated and should be updated to the latest revision of the specifications:

    • Update reference to the IDL standard to version 4.2.
    • Update reference to the DDS-XTypes standard to version 1.2.
  • Reported: DDS-XML 1.0b1 — Sat, 12 May 2018 17:50 GMT
  • Disposition: Resolved — DDS-XML 1.0
  • Disposition Summary:

    Fix minor typos and update specification references

    This proposal fixes a number of typos in the specification document and updates outdated references to the latest revision of the specification they mention.
  • Updated: Wed, 3 Oct 2018 14:17 GMT

Communication Status changes for multiple events

  • Key: DDS15-244
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Plain Communication Status structures may undergo multiple changes between the time the first event occurs and when the application reads/resets the Plain Communication Status. This results in loss of important data that DDS should make available to the application. It is more likely to occur when using the WaitSet/StatusCondition mechanism instead of Listeners, but may occur with Listeners depending on how the implementation determines when to invoke the Listener.

    For example, an application creates a DataReader that uses Deadline QoS. In order to monitor for Deadline violations, the application gets the reader's StatusCondition and adds it to a WaitSet. If that Condition becomes active, the application invokes get_requested_deadline_missed_status to determine which instance experienced the deadline violation (using last_instance_handle). However, in the case that multiple instances have deadline violations since the last time status was checked (total_count_change > 1), the identity of all but the last of those instances is not available to the application.

    This same concept applies to any of the uses of "last_*" in the Plain Communication Status structures.
  • Reported: DDS 1.4 — Tue, 2 Oct 2018 17:44 GMT
  • Updated: Tue, 2 Oct 2018 17:44 GMT

Make use of C++11 final/override/delete

  • Key: DDSPSMC11_-66
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In case we have a C+11 or newer compiler we the C+ PSM should also make use of final/override/delete.

  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 26 Jun 2017 06:50 GMT
  • Updated: Sun, 30 Sep 2018 23:31 GMT

Small correctes to the specification

  • Key: DDSPSMC11_-68
  • Legacy Issue Number: 19586
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Some small fixes to the spec

    Section 7.1, change "sup- ported" to "supported"

    Section 7.4.3, C+11 talks about strong typed enums, so change "C+11 enumeration
    classes" to "C++11 strongly typed enums"

    Section 7.5.1.2, why let the user initialize a null reference by assigning dds::core::null, wouldn't be be easier to say "The trivial constructor for reference types will initialize it to a null reference"

    Section 8.2, constructor of RadarTrack doesn't use optional for argument z

  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 25 Aug 2014 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:31 GMT

Normative references not complete and out of date

  • Key: DDSPSMC11_-67
  • Legacy Issue Number: 19585
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The normative references lack the listing of the IDL2C++11 specification which is referred in several sections of the spec, this should refer to at least the V1.1 version of this spec. For DDS4CCM the reference should be updated to the V1.1 of the specification

  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 25 Aug 2014 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:31 GMT

Missing TBuiltinTopicTypes

  • Key: DDSPSMC11_-64
  • Legacy Issue Number: 19801
  • Status: open  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The built-in topics are defined in dds/core/BuiltinTopicTypes.hpp as:
    #include <dds/core/TBuiltinTopicTypes.hpp>

    namespace dds { namespace core

    { typedef TBytesTopicType<detail::BytesTopicType> BytesTopicType; typedef TStringTopicType<detail::StringTopicType> StringTopicType; typedef TKeyedBytesTopicType<detail::KeyedBytesTopicType> KeyedBytesTopicType; typedef TKeyedStringTopicType<detail::KeyedStringTopicType> KeyedStringTopicType; }

    }

    But dds/core/TBuiltinTopicTypes.hpp and the types TBytesTopicType, TStringTopicType, etc. don't exist.

  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Jun 2015 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

Provide extension constructors for standard classes

  • Key: DDSPSMC11_-63
  • Status: open  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The specification does not seem to provide any "standard" way to pass vendor-specific arguments to constructors of standard classes. As constructor is a special function, the trick of overloading operator -> (used for vendor-specific member functions) does not work.

    Take DataState for example: We need to pass more that just InstanceState, ViewState, and SampleState.

    Proposed Resolution: (1) Add overly-generic template constructors that accepts any number of generic arguments. For instance,

    template <class Arg1, class Arg2, class Arg3>
    Class(Arg1 &, Arg2 &, Arg3 &);

    Some classes like DataState may be extended with operator >> template. This style is used in DataReaderQos and DataWriterQos.

    RTI is not thrilled about this option. However, it may solve similar problems in all the classes that need vendor-specific constructors.

    Alternatively, (2) Allow vendor-specific constructors and member-functions in standard classes. The standard simply needs to say that it is allowed.

  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 4 Jan 2016 20:20 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

EntityQos is overly general

  • Key: DDSPSMC11_-65
  • Legacy Issue Number: 18445
  • Status: open  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    EntityQos template is a rather overly general way of setting and getting policies. Member template functions generate the code depending upon the policy type. If you pass a wrong type, it eventually ends up showing a link-time error as opposed to a compile-time error. For instance, there is a link-time error in the code below because DataWriterQos has no presentation policy.

    dds::pub::qos::DataWriterQos dwqos;
    dds::core::policy::Deadline d;
    dds::core::policy::Presentation p;
    dwqos >> p; /// Linker error here. No compile-time error
    dwqos >> d; /// Fine!

    Additionally, the dot operator provides no help for syntax completion because the policy function is a member template. Consequently, the end-user might be tempted to use the -> operator, which does provide syntax completion depending upon the implementation of the delegate. As a result, for standard policies -> will be used, which is unintended.

    Proposed Resolution:

    1. Add template classes DataReaderQos, DataWriterQoS, PublisherQos, SubscriberQos, DomainParticipantQos in the dds namespace.

    2. Support non-template member functions for setting and getting respective policies. For instance. dwqos.deadline() and dwqos.deadline(d) should be supported.

    3. Define operator << and operator >> outside the QoS class and overload for the respective policies.

    4. The templated verions of policy getters/setters can still be supported. However, I seriously doubt their usefulness. If we decide to keep them, at least I would like to turn the linker error into compiler error using a meta-programming technique described here:

    http://cpptruths.googlecode.com/svn/trunk/cpp/entityqos.cpp
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 12 Feb 2013 05:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

Names of the generated headers

  • Key: DDSPSMC11_-62
  • Legacy Issue Number: 19753
  • Status: open  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    To ensure application portability, the names of the generated header files should be standard. For example, for Foo.idl, generate Foo.h. The spec does not specify a standard naming scheme.

  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 27 Apr 2015 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

Default Constructors

  • Key: DDSPSMC11_-61
  • Status: open  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Reference types do not have default constructors, forcing the use of nullptr to construct null references. This runs counter to modern C++ conventions; for example, consider C++11 smart pointers. Forcing explicit initialization also prevents the sensible use of compiler-generated default constructors for objects containing DDS objects as members.

    To get the behavior I want, I've to define constructor and destructor for a struct for no purpose other than to initialize a member instance handle to null, or just make it a std::unique_ptr<dds::core::InstanceHandle> and circumvent the API.
  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 25 Jan 2016 19:02 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API corrections required to src/hpp/dds/core/Exception.hpp

  • Key: DDSPSMC11_-53
  • Legacy Issue Number: 18612
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Name: Simon McQueen
    Employer: PrismTech
    Specification: DDS CXX PSM RTF
    FormalNumber: ptc/12-10-03
    Nature: Revision

    Issues:

    API requires warning suppression with MS Visual Studio.
    MS symbol export macros missing.
    Missing constructor.
    Incorrect comments.
    Some in-line definition remaining in declaration only file.

    Suggested resolution:

    diff --git a/src/hpp/dds/core/Exception.hpp b/src/hpp/dds/core/Exception.hpp
index 84c7c28..22b05ab 100644
--- a/src/hpp/dds/core/Exception.hpp
+++ b/src/hpp/dds/core/Exception.hpp
@@ -23,194 +23,261 @@
 #include <string>
 #include <dds/core/macros.hpp>

-namespace dds { namespace core {
+#if defined _MSC_VER
+#   pragma warning (push)
+#   pragma warning (disable:4275) // non dll-interface class 'std::foo_error' used as base for dll-interface class 'dds::core::BarError'
+#endif

-  /**
-   * This files contains the exceptions corresponding to DDS errors.
-   * In the DDS-PSM-Cxx in place of DDS errors the associated expcetion
-   * should be raised. Please section 7.5.5 of the DDS-PSM-C++ specification.
-   */
+namespace dds
+{
+namespace core
+{

-  class Exception
-  {
-  protected:
+/**
+ *
+ * DDS PIM Return Code            | DDS-PSM-CXX Exception Class   | std C++ Parent Exception
+ * -------------------            | ---------------------------   | ------------------------
+ * RETCODE_OK                     | Normal return; no exception   | N/A
+ * RETCODE_NO_DATA                | Normal return with informational state attached    | N/A
+ * RETCODE_ERROR                  | Error                         | std::logic_error
+ * RETCODE_BAD_PARAMETER          | InvalidArgumentError          | std::invalid_argument
+ * RETCODE_TIMEOUT                | TimeoutError                  | std::runtime_error
+ * RETCODE_UNSUPPORTED            | UnsupportedError              | std::logic_error
+ * RETCODE_ALREADY_DELETED        | AlreadyClosedError            | std::logic_error
+ * RETCODE_ILLEGAL_OPERATION      | IllegalOperationError         | std::logic_error
+ * RETCODE_NOT_ENABLED            | NotEnabledError               | std::logic_error
+ * RETCODE_PRECONDITION_NOT_MET   | PreconditionNotMetError       | std::logic_error
+ * RETCODE_IMMUTABLE_POLICY       | ImmutablePolicyError          | std::logic_error
+ * RETCODE_INCONSISTENT_POLICY    | InconsistentPolicyError       | std::logic_error
+ * RETCODE_OUT_OF_RESOURCES       | OutOfResourcesError           | std::runtime_error
+ *
+ * The DDS-PSM-Cxx maps error codes to C++ exceptions defined in the dds::core namespace and
+ * inheriting from a base Exception class and the appropriate standard C++ exception.
+ * Table 7.3 lists the mapping between error codes as defined in the DDS PIM and C++ exceptions
+ * as used in this specification. Exceptions have value semantics; this means that they must
+ * always have deep copy semantics.
+ * The full list of exceptions is included in the file dds/core/Exceptions.hpp.
+ *
+ */
+
+class OMG_DDS_API Exception
+{
+protected:
     Exception();
-  public:
-    virtual ~Exception() throw ();
+public:
+    virtual ~Exception() throw();

-  public:
-    virtual const char* what() const throw () = 0;
-  };
+public:
+    virtual const char* what() const throw() = 0;
+};

-  class Error : public Exception, public std::exception
-  {
-  public:
-    Error();
+/**
+ *  Generic, unspecified error.
+ */
+class OMG_DDS_API Error : public Exception, public std::logic_error
+{
+public:
+    explicit Error(const std::string& msg);
     Error(const Error& src);
-  public:
-    virtual ~Error() throw ();
-
-  public:
-    virtual const char* what() const throw ();
-  };
+    virtual ~Error() throw();

+public:
+    virtual const char* what() const throw();
+};

-  class AlreadyClosedError : public Exception, public std::logic_error
-  {
-  public:
+/**
+ * The object target of this operation has already been closed
+ */
+class OMG_DDS_API AlreadyClosedError : public Exception, public std::logic_error
+{
+public:
     explicit AlreadyClosedError(const std::string& msg);
     AlreadyClosedError(const AlreadyClosedError& src);
-    virtual ~AlreadyClosedError() throw ();
-
-  public:
-    virtual const char* what() const throw ();
-  };
+    virtual ~AlreadyClosedError() throw();

+public:
+    virtual const char* what() const throw();
+};

-  class IllegalOperationError : public Exception, public std::logic_error
-  {
-  public:
+/**
+ * An operation was invoked on an inappropriate object or at an inappropriate time
+ * (as determined by policies set by the specification or the Service implementation).
+ * There is no precondition that could be changed to make the operation succeed.
+ */
+class OMG_DDS_API IllegalOperationError : public Exception, public std::logic_error
+{
+public:
     explicit IllegalOperationError(const std::string& msg);
     IllegalOperationError(const IllegalOperationError& src);
-    virtual ~IllegalOperationError() throw ();
-
-  public:
-    virtual const char* what() const throw ();
-  };
+    virtual ~IllegalOperationError() throw();

+public:
+    virtual const char* what() const throw();
+};

-  class ImmutablePolicyError : public Exception, public std::logic_error
-  {
-  public:
+/**
+ * Application attempted to modify an immutable QosPolicy
+ */
+class OMG_DDS_API ImmutablePolicyError : public Exception, public std::logic_error
+{
+public:
     explicit ImmutablePolicyError(const std::string& msg);
     ImmutablePolicyError(const ImmutablePolicyError& src);
-    virtual ~ImmutablePolicyError() throw ();
-
-  public:
-    virtual const char* what() const throw ();
-  };
+    virtual ~ImmutablePolicyError() throw();

+public:
+    virtual const char* what() const throw();
+};

-  class InconsistentPolicyError : public Exception, public std::logic_error
-  {
-  public:
+/**
+ * Application specified a set of policies that are not
+ * consistent with each other
+ */
+class OMG_DDS_API InconsistentPolicyError : public Exception, public std::logic_error
+{
+public:
     explicit InconsistentPolicyError(const std::string& msg);
     InconsistentPolicyError(const InconsistentPolicyError& src);
-    virtual ~InconsistentPolicyError() throw ();
-
-  public:
-    virtual const char* what() const throw ();
-  };
+    virtual ~InconsistentPolicyError() throw();

+public:
+    virtual const char* what() const throw();
+};

-  class InvalidArgumentError : public Exception, public std::invalid_argument
-  {
-  public:
+/**
+ * Application is passing an invalid argument
+ */
+class OMG_DDS_API InvalidArgumentError : public Exception, public std::invalid_argument
+{
+public:
     explicit InvalidArgumentError(const std::string& msg);
     InvalidArgumentError(const InvalidArgumentError& src);
-    virtual ~InvalidArgumentError() throw ();
-
-  public:
-    virtual const char* what() const throw ();
-  };
+    virtual ~InvalidArgumentError() throw();

+public:
+    virtual const char* what() const throw();
+};

-  class NotEnabledError : public Exception, public std::logic_error
-  {
-  public:
+/**
+ * Operation invoked on an Entity that is not yet enabled
+ */
+class OMG_DDS_API NotEnabledError : public Exception, public std::logic_error
+{
+public:
     explicit NotEnabledError(const std::string& msg);
     NotEnabledError(const NotEnabledError& src);
-    virtual ~NotEnabledError() throw ();
-
-  public:
-    virtual const char* what() const throw ();
-  };
+    virtual ~NotEnabledError() throw();

+public:
+    virtual const char* what() const throw();
+};

-  class OutOfResourcesError : public Exception, public std::runtime_error
-  {
-  public:
+/**
+ * Service ran out of the resources needed to complete the
+ * operation
+ */
+class OMG_DDS_API OutOfResourcesError : public Exception, public std::runtime_error
+{
+public:
     explicit OutOfResourcesError(const std::string& msg);
     OutOfResourcesError(const OutOfResourcesError& src);
-    virtual ~OutOfResourcesError() throw ();
-
-  public:
-    virtual const char* what() const throw ();
-  };
-
+    virtual ~OutOfResourcesError() throw();

-  class PreconditionNotMetError : public Exception, public std::logic_error
-  {
-  public:
-    explicit PreconditionNotMetError(const std::string& msg) : std::logic_error(msg) { }
-    PreconditionNotMetError(const PreconditionNotMetError& src) : std::logic_error(src.what()) {}
-    virtual ~PreconditionNotMetError() throw () { }
+public:
+    virtual const char* what() const throw();
+};

-  public:
-    virtual const char* what() const throw () {
-      return this->std::logic_error::what();
-    }

-  };
-
-
-  class TimeoutError : public Exception, public std::runtime_error
-  {
-  public:
+/**
+ * A pre-condition for the operation was not met
+ */
+class OMG_DDS_API PreconditionNotMetError : public Exception, public std::logic_error
+{
+public:
+    explicit PreconditionNotMetError(const std::string& msg);
+    PreconditionNotMetError(const PreconditionNotMetError& src);
+    virtual ~PreconditionNotMetError() throw();
+
+public:
+    virtual const char* what() const throw();
+};
+
+/**
+ * The operation timed out
+ */
+class OMG_DDS_API TimeoutError : public Exception, public std::runtime_error
+{
+public:
     explicit TimeoutError(const std::string& msg);
     TimeoutError(const TimeoutError& src);
-    virtual ~TimeoutError() throw ();
+    virtual ~TimeoutError() throw();

-  public:
-    virtual const char* what() const throw ();
-  };
+public:
+    virtual const char* what() const throw();
+};

-
-  class UnsupportedError : public Exception, public std::logic_error
-  {
-  public:
+/**
+ * Unsupported operation. Can only be returned by operations that are optional.
+ */
+class OMG_DDS_API UnsupportedError : public Exception, public std::logic_error
+{
+public:
     explicit UnsupportedError(const std::string& msg);
     UnsupportedError(const UnsupportedError& src);
-    virtual ~UnsupportedError() throw ();
+    virtual ~UnsupportedError() throw();

-  public:
-    virtual const char* what() const throw ();
-  };
+public:
+    virtual const char* what() const throw();
+};

-  class InvalidDowncastError : public Exception, public std::runtime_error
-  {
-  public:
+/**
+ * Application has attempted to cast incompatible types
+ */
+class OMG_DDS_API InvalidDowncastError : public Exception, public std::runtime_error
+{
+public:
     explicit InvalidDowncastError(const std::string& msg);
     InvalidDowncastError(const InvalidDowncastError& src);
     virtual ~InvalidDowncastError() throw();

-  public:
-    virtual const char* what() const throw ();
-  };
+public:
+    virtual const char* what() const throw();
+};

-  class NullReferenceError : public Exception, public std::runtime_error
-  {
-  public:
+/**
+ * Application returned a null reference
+ */
+class OMG_DDS_API NullReferenceError : public Exception, public std::runtime_error
+{
+public:
     explicit NullReferenceError(const std::string& msg);
     NullReferenceError(const NullReferenceError& src);
     virtual ~NullReferenceError() throw();

-  public:
-    virtual const char* what() const throw ();
-  };
+public:
+    virtual const char* what() const throw();
+};

-
-  class InvalidDataError : public Exception, public std::logic_error
-  {
-  public:
+/**
+ * Application returned invalid data
+ */
+class OMG_DDS_API InvalidDataError : public Exception, public std::logic_error
+{
+public:
     explicit InvalidDataError(const std::string& msg);
     InvalidDataError(const InvalidDataError& src);
-    virtual ~InvalidDataError() throw ();
+    virtual ~InvalidDataError() throw();
+
+public:
+    virtual const char* what() const throw();
+};
+
+}
+}

-  public:
-    virtual const char* what() const throw ();
-  };
+#if defined _MSC_VER
+#   pragma warning (pop)
+#endif

-}}

 #endif /* OMG_DDS_CORE_EXCEPTION_HPP_ */
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 3 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API corrections required to src/hpp/dds/core/TQosProvider.hpp

  • Key: DDSPSMC11_-51
  • Legacy Issue Number: 18616
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Name: Simon McQueen
    Employer: PrismTech
    Specification: DDS CXX PSM RTF
    FormalNumber: ptc/12-10-03
    Nature: Revision

    Issues:

    Incorrect comments.

    Suggested resolution:

    diff --git a/src/hpp/dds/core/TQosProvider.hpp
b/src/hpp/dds/core/TQosProvider.hpp
index ef2a3e3..9cdda28 100644
--- a/src/hpp/dds/core/TQosProvider.hpp
+++ b/src/hpp/dds/core/TQosProvider.hpp
@@ -47,8 +47,8 @@ public:
    * For instance, the following code:
    * <pre><code>
          QosProvider xml_file_provider("file:///somewhere/on/disk/qos-config.xml");
-         QosProvider json_file_provider(""file:///somewhere/on/disk/json-config.json");
-         QosProvider json_http_provider(""http:///somewhere.org/here/json-config.json");
+         QosProvider json_file_provider("file:///somewhere/on/disk/json-config.json");
+         QosProvider json_http_provider("http:///somewhere.org/here/json-config.json");
       </code></pre>


    * The URI determines the how the Qos configuration is fetched and the
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 3 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API corrections required to src/hpp/dds/core/TInstanceHandle.hpp

  • Key: DDSPSMC11_-52
  • Legacy Issue Number: 18615
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Name: Simon McQueen
    Employer: PrismTech
    Specification: DDS CXX PSM RTF
    FormalNumber: ptc/12-10-03
    Nature: Revision

    Issues:

    Incorrect comment.

    Suggested resolution:

    diff --git a/src/hpp/dds/core/TInstanceHandle.hpp
b/src/hpp/dds/core/TInstanceHandle.hpp
index c4c4014..b93975d 100644
--- a/src/hpp/dds/core/TInstanceHandle.hpp
+++ b/src/hpp/dds/core/TInstanceHandle.hpp
@@ -44,7 +44,7 @@ public:
   TInstanceHandle(const TInstanceHandle& other);


   /**
-   * Distructor
+   * Destructor
    */
   ~TInstanceHandle();
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 3 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

Documentation comments corrections required to src/hpp/dds/domain/discovery.hpp & find.hpp

  • Key: DDSPSMC11_-50
  • Legacy Issue Number: 18635
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Comment correction required.

    Suggested resolution:

    diff --git a/src/hpp/dds/domain/discovery.hpp b/src/hpp/dds/domain/discovery.hpp
index e43d28d..97943ec 100644
--- a/src/hpp/dds/domain/discovery.hpp
+++ b/src/hpp/dds/domain/discovery.hpp
@@ -26,7 +26,7 @@
 namespace dds { namespace domain {


   /**
-   * This function allows to express the will to ignore the entity
+   * This function allows one to express the will to ignore the entity
    * represented by the given <code>InstanceHandle</code> for the specific
    * <code>DomainParticipant</code>.
    *
@@ -40,7 +40,7 @@ namespace dds { namespace domain {
   void ignore(const dds::domain::DomainParticipant& dp, const dds::core::InstanceHandle& handle);


   /**
-   * This function allows to express the will to ignore a series of entities
+   * This function allows one to express the will to ignore a series of entities
    * whose instance handles are made available via the provided iterators.
    *
    * @param dp      the <code>DomainParticipant</code> for which the remote
diff --git a/src/hpp/dds/domain/find.hpp b/src/hpp/dds/domain/find.hpp
index 112d67c..2043f04 100644
--- a/src/hpp/dds/domain/find.hpp
+++ b/src/hpp/dds/domain/find.hpp
@@ -27,7 +27,7 @@ namespace dds { namespace domain {
   /**
    * This operation retrieves a previously created <code>DomainParticipant</code>
    * belonging to specified domain_id. If no such DomainParticipant
-   * exists, the operation will return a <it>nil</it> value.
+   * exists, the operation will return a @a nil value.
    *
    * @param id the domain id
    */
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/dds.hpp

  • Key: DDSPSMC11_-60
  • Legacy Issue Number: 18632
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    File has left over mistaken vendor include.

    Could probably do with a nice comment, whilst we're here.

    Suggested resolution:

    diff --git a/src/hpp/dds/dds.hpp b/src/hpp/dds/dds.hpp
index 9de7249..b6bf026 100644
--- a/src/hpp/dds/dds.hpp
+++ b/src/hpp/dds/dds.hpp
@@ -1,6 +1,28 @@
+/* Copyright 2010, Object Management Group, Inc.
+ * Copyright 2010, PrismTech, Corp.
+ * Copyright 2010, Real-Time Innovations, Inc.
+ * All rights reserved.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
 #ifndef __OMG_DDS_DDS_HPP__
 #define __OMG_DDS_DDS_HPP__


+/**
+ * @file
+ * This utility header includes the headers of all the DDS DCPS modules.
+ */
+
 #include <dds/core/ddscore.hpp>
 #include <dds/domain/ddsdomain.hpp>
 #include <dds/topic/ddstopic.hpp>
@@ -9,7 +14,5 @@
 #include <dds/pub/ddspub.hpp>


 #include <dds/core/QosProvider.hpp>
-#include <org/opensplice/topic/TopicTraits.hpp>
-


 #endif /* __OMG_DDS_DDS_HPP__ */
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/core/status/TStatus.hpp

  • Key: DDSPSMC11_-55
  • Legacy Issue Number: 18630
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Vestigial implementation code needs removing to fix compilation.

    Suggested resolution:

    diff --git a/src/hpp/dds/core/status/TStatus.hpp b/src/hpp/dds/core/status/TStatus.hpp
index 638e188..6d6122f 100644
--- a/src/hpp/dds/core/status/TStatus.hpp
+++ b/src/hpp/dds/core/status/TStatus.hpp
@@ -138,7 +138,7 @@ namespace dds { namespace core { namespace status {
   template <typename D>
   class TPublicationMatchedStatus : public dds::core::Value<D> {
   public:
-    TPublicationMatchedStatus() : dds::core::Value<D>();
+    TPublicationMatchedStatus();


   public:
     int32_t total_count() const;
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/core/status/State.hpp

  • Key: DDSPSMC11_-59
  • Legacy Issue Number: 18628
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Vestigial implementation code (and comments) need removing for consistency and to fix compilation.

    Header include missing.

    Required inline operation missing.

    Windows export macros required.

    Suggested resolution:

    diff --git a/src/hpp/dds/core/status/State.hpp b/src/hpp/dds/core/status/State.hpp
index 8ac4475..ab8d1cf 100644
--- a/src/hpp/dds/core/status/State.hpp
+++ b/src/hpp/dds/core/status/State.hpp
@@ -21,19 +21,20 @@


 #include <bitset>
 #include <dds/core/macros.hpp>
+#include <dds/core/types.hpp>



 namespace dds { namespace core { namespace status {



-  class SampleRejectedState : public std::bitset<OMG_DDS_STATE_BIT_COUNT> {
+  class OMG_DDS_API SampleRejectedState : public std::bitset<OMG_DDS_STATE_BIT_COUNT> {
   public:
     typedef std::bitset<OMG_DDS_STATE_BIT_COUNT> MaskType;


   public:
-    SampleRejectedState() : MaskType() { }
-    SampleRejectedState(const SampleRejectedState& src) : MaskType(static_cast<int>(src.to_ulong())) { }
-    SampleRejectedState(const MaskType& src) : MaskType(static_cast<int>(src.to_ulong())) { }
+    SampleRejectedState();
+    SampleRejectedState(const SampleRejectedState& src);
+    SampleRejectedState(const MaskType& src);


   public:
     inline static const SampleRejectedState not_rejected() {
@@ -50,29 +51,29 @@ namespace dds { namespace core { namespace status {
     }


   private:
-    // @TODO
-    // -- This Ctor should be fixed as currently there is this
-    // -- cast only to avoid an error when compiling with the  MS vC++ compiler
-    SampleRejectedState(uint32_t s)
-    : MaskType((uint64_t)s)
-    { }
-
+    SampleRejectedState(uint32_t s);
   };



   // StatusMask create_status_mask(uint64_t);


-  class StatusMask : public std::bitset<OMG_DDS_STATUS_COUNT> {
+  class OMG_DDS_API StatusMask : public std::bitset<OMG_DDS_STATUS_COUNT> {
   public:
     typedef std::bitset<OMG_DDS_STATUS_COUNT> MaskType;


   public:
-    StatusMask() { }
-    explicit StatusMask(uint64_t mask) : std::bitset<OMG_DDS_STATUS_COUNT>(mask) { }
-    StatusMask(const StatusMask& other) : MaskType(static_cast<int>(other.to_ulong())) { }
-    ~StatusMask() { }
+    StatusMask();
+    explicit StatusMask(uint32_t mask);
+    StatusMask(const StatusMask& other);
+    ~StatusMask();


   public:
+    inline StatusMask& operator << (const dds::core::status::StatusMask& mask)
+    {
+        *this |= mask;
+        return *this;
+    }
+
     inline static const StatusMask all() {
       return StatusMask(0x7fe7u);
     }
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/core/policy/TCorePolicy.hpp

  • Key: DDSPSMC11_-57
  • Legacy Issue Number: 18627
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Compilation fixes and corrections to API documentation comments required.

    Incorrect default reliability duration (infinite). Should be 100 milliseconds per table in section "7.1.3 Supported QoS" (formal 07-01-01)

    Suggested resolution:

    diff --git a/src/hpp/dds/core/policy/TCorePolicy.hpp b/src/hpp/dds/core/policy/TCorePolicy.hpp
index 382e521..1313b32 100644
--- a/src/hpp/dds/core/policy/TCorePolicy.hpp
+++ b/src/hpp/dds/core/policy/TCorePolicy.hpp
@@ -47,7 +47,7 @@ namespace dds { namespace core { namespace policy {
     /**
      * Create a <code>UserData</code> instance with an empty user data.
      */
-    TUserData() : dds::core::Value<D>();
+    TUserData();


     /**
      * Create a <code>UserData</code> instance.
@@ -56,7 +56,7 @@ namespace dds { namespace core { namespace policy {
      */
     explicit TUserData(const dds::core::ByteSeq& seq);


-    //@TODO Implement
+    /** @todo Implement this */
     TUserData(const uint8_t* value_begin, const uint8_t* value_end);


     TUserData(const TUserData& other);
@@ -102,16 +102,16 @@ namespace dds { namespace core { namespace policy {
   class TGroupData : public dds::core::Value<D> {
   public:
     /**
-     * Create a <code>GroupData<code> instance.
+     * Create a <code>GroupData</code> instance.
      */
-    TGroupData() : dds::core::Value<D>();
+    TGroupData();


     /**
-     * Create a <code>GroupData<code> instance.
+     * Create a <code>GroupData</code> instance.
      *
      * @param seq the group data value
      */
-    explicit TGroupData(const dds::core::ByteSeq& seq) : dds::core::Value<D>(seq);
+    explicit TGroupData(const dds::core::ByteSeq& seq);


     TGroupData(const TGroupData& other);


@@ -160,7 +160,7 @@ namespace dds { namespace core { namespace policy {
   template <typename D>
   class TTopicData : public dds::core::Value<D> {
   public:
-    TTopicData() : dds::core::Value<D>();
+    TTopicData();


     explicit TTopicData(const dds::core::ByteSeq& seq);


@@ -219,7 +219,7 @@ namespace dds { namespace core { namespace policy {
   template <typename D>
   class TEntityFactory : public dds::core::Value<D> {
   public:
-    TEntityFactory() :dds::core::Value<D>(true);
+    TEntityFactory();
     explicit TEntityFactory(bool the_auto_enable);
     TEntityFactory(const TEntityFactory& other);


@@ -255,7 +255,7 @@ namespace dds { namespace core { namespace policy {
   public:
     explicit TTransportPriority(int32_t prio);


-    TTransportPriority() : dds::core::Value<D>(0);
+    TTransportPriority();


     TTransportPriority(const TTransportPriority& other);


@@ -554,7 +554,7 @@ namespace dds { namespace core { namespace policy {
     const dds::core::Duration max_blocking_time() const;


   public:
-    static TReliability Reliable(const dds::core::Duration& d = dds::core::Duration::infinite());
+    static TReliability Reliable(const dds::core::Duration& d = dds::core::Duration(0, 100000000));
     static TReliability BestEffort();
   };
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/sub/AnyDataReaderListener.hpp

  • Key: DDSPSMC11_-56
  • Legacy Issue Number: 18643
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Vestigial implementation code needs removing to be consistent with other No-op listener declarations.

    Missing headers required to fix compilation.

    Suggested resolution:

    diff --git a/src/hpp/dds/sub/AnyDataReaderListener.hpp b/src/hpp/dds/sub/AnyDataReaderListener.hpp
index 4646bfd..aabd71a 100644
--- a/src/hpp/dds/sub/AnyDataReaderListener.hpp
+++ b/src/hpp/dds/sub/AnyDataReaderListener.hpp
@@ -19,6 +19,8 @@
  * limitations under the License.
  */


+#include <dds/core/refmacros.hpp>
+#include <dds/core/status/Status.hpp>


 namespace dds { namespace sub {


@@ -59,37 +61,36 @@ namespace dds { namespace sub {
         const dds::core::status::SampleLostStatus& status) = 0;
   };


-
   class NoOpAnyDataReaderListener : public virtual AnyDataReaderListener {
   public:
-    virtual ~NoOpAnyDataReaderListener() { }
+    virtual ~NoOpAnyDataReaderListener();


   public:
     virtual void on_requested_deadline_missed(
         AnyDataReader& the_reader,
-        const dds::core::status::RequestedDeadlineMissedStatus& status) { }
+        const dds::core::status::RequestedDeadlineMissedStatus& status);


     virtual void on_requested_incompatible_qos(
         AnyDataReader& the_reader,
-        const dds::core::status::RequestedIncompatibleQosStatus& status) { }
+        const dds::core::status::RequestedIncompatibleQosStatus& status);


     virtual void on_sample_rejected(
         AnyDataReader& the_reader,
-        const dds::core::status::SampleRejectedStatus& status) { }
+        const dds::core::status::SampleRejectedStatus& status);


     virtual void on_liveliness_changed(
         AnyDataReader& the_reader,
-        const dds::core::status::LivelinessChangedStatus& status) { }
+        const dds::core::status::LivelinessChangedStatus& status);


-    virtual void on_data_available(AnyDataReader& the_reader) { }
+    virtual void on_data_available(AnyDataReader& the_reader);


     virtual void on_subscription_matched(
         AnyDataReader& the_reader,
-        const dds::core::status::SubscriptionMatchedStatus& status) { }
+        const dds::core::status::SubscriptionMatchedStatus& status);


     virtual void on_sample_lost(
         AnyDataReader& the_reader,
-        const dds::core::status::SampleLostStatus& status) { }
+        const dds::core::status::SampleLostStatus& status);
   };
 } }
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

Missing file dds/pub/detail/find.hpp referenced in src/hpp/dds/pub/find.hpp

  • Key: DDSPSMC11_-54
  • Legacy Issue Number: 18641
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Missing include - fails to compile.

    Suggested resolution:

    Add vendor example file and remove below comment. 

    diff --git a/src/hpp/dds/pub/find.hpp b/src/hpp/dds/pub/find.hpp
index 6c10f59..6a50fad 100644
--- a/src/hpp/dds/pub/find.hpp
+++ b/src/hpp/dds/pub/find.hpp
@@ -21,9 +21,9 @@


 #include <string>


+/** @todo This does not compile - no such example file (in spec). Need to add one */
 #include <dds/pub/detail/find.hpp>


-
 namespace dds { namespace pub {


   /**
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

Documentation comments corrections to src/hpp/dds/pub/TPublisher.hpp

  • Key: DDSPSMC11_-47
  • Legacy Issue Number: 18638
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Corrections to documentation comments required.

    Suggested resolution:

    diff --git a/src/hpp/dds/pub/TPublisher.hpp b/src/hpp/dds/pub/TPublisher.hpp
index 3534a29..d872370 100644
--- a/src/hpp/dds/pub/TPublisher.hpp
+++ b/src/hpp/dds/pub/TPublisher.hpp
@@ -97,16 +97,16 @@ public:
    *
    * @param pqos the new publisher QoS
    */
-  TPublisher& operator <<(const dds::pub::qos::PublisherQos& the_qos);
+  TPublisher& operator <<(const dds::pub::qos::PublisherQos& pqos);


   /**
    * Get the publisher qos policies.
    */
-  TPublisher& operator >> (dds::pub::qos::PublisherQos& the_qos);
+  TPublisher& operator >> (dds::pub::qos::PublisherQos& qos);


   /**
-   * This operation sets a default value of the <code>DataWriterQos<\code>
-   * which will be used for newly created <core>DataWriter<code>entities
+   * This operation sets a default value of the <code>DataWriterQos</code>
+   * which will be used for newly created <code>DataWriter</code>entities
    * for which no <code>DataWriterQos</code> is provided in the constructor.
    * This operation will check that the resulting policies are self consistent;
    * if they are not, the operation will have no effect and raise an
@@ -115,7 +115,7 @@ public:
   TPublisher& default_writer_qos(const dds::pub::qos::DataWriterQos& dwqos);


   /**
-   * This operation retrieves the default value of the <code>DataWriterQos<\code>,
+   * This operation retrieves the default value of the <code>DataWriterQos</code>,
    * that is, the QoS policies which will be used for newly created DataWriter
    * that don't provide a QoS parameter in the constructor.
    */
@@ -155,7 +155,7 @@ public:
   //==========================================================================


   /**
-   * Return the <code>DomainParticipant<code> that owns this Publisher.
+   * Return the <code>DomainParticipant</code> that owns this Publisher.
    */
   const dds::domain::DomainParticipant& participant() const;

@@ -143,19 +159,21 @@ public:
     * This operation blocks the calling thread until either all data written
     * by the reliable DataWriter entities is acknowledged by all matched
     * reliable DataReader entities, or else the duration specified by the
-     * max_wait parameter elapses, whichever happens first.
+     * timeout parameter elapses, whichever happens first.
     * A normal return indicates that all the samples written have been
-     * acknowledged by all reliable matched data readers; A TimeoutError
-     * indicates that max_wait elapsed before all the data was acknowledged.
+     * acknowledged by all reliable matched data readers. A TimeoutError
+     * indicates that timeout elapsed before all the data was acknowledged.
+     *
+     * @param timeout the time out duration
     */
    void wait_for_acknowledgments(const dds::core::Duration& timeout);
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/sub/LoanedSamples.hpp

  • Key: DDSPSMC11_-48
  • Legacy Issue Number: 18646
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Compilation fixes required to code.

    Suggested resolution:

    diff --git a/src/hpp/dds/sub/LoanedSamples.hpp b/src/hpp/dds/sub/LoanedSamples.hpp
    index 633f065..1456e57 100644
    — a/src/hpp/dds/sub/LoanedSamples.hpp
    +++ b/src/hpp/dds/sub/LoanedSamples.hpp
    @@ -9,7 +9,7 @@
    namespace dds {
    namespace sub {
    template <typename T,

    • template <typename Q> class DELEGATE = detail::LoanedSamples>
      + template <typename Q> class DELEGATE = dds::sub::detail::LoanedSamples>
      class LoanedSamples;

    // Used by C++11 compilers to allow for using LoanedSamples
    @@ -67,8 +67,8 @@ private:
    namespace dds {
    namespace sub

    { template <typename T, template <typename Q> class D> - LoanedSamples<T, D<T> > - move(LoanedSamples<T, D<T> >& a); + LoanedSamples<T, D > + move(LoanedSamples<T, D >& a); }

    }
    #endif /* OMG_DDS_SUB_TLOANED_SAMPLES_HPP_ */
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

DataReader.hpp, ContentFilteredTopic.hpp, Topic.hpp, TopicDescription.hpp o not compile with MS Visual Studio

  • Key: DDSPSMC11_-58
  • Legacy Issue Number: 18644
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    In src/hpp/dds/sub/DataReader.hpp; src/hpp/dds/topic/ContentFilteredTopic.hpp; src/hpp/dds/topic/Topic.hpp; src/hpp/dds/topic/TopicDescription.hpp

    ... the template header file includes need to be moved as MSVC appears to ignore any attempt to 're-declare' a template class with a 'new' default argument and only considers defaults on the first time of asking.

    Without the move the compiler emits an error in each case like something like e.g.:

    dds/topic/detail/AnyTopicDescription.hpp(48): error C2976: 'dds::topic::TopicDescription' : too few template arguments
    dds/topic/TTopicDescription.hpp(41) : see declaration of 'dds::topic::TopicDescription'

    Suggested resolutions:

    diff --git a/src/hpp/dds/sub/DataReader.hpp b/src/hpp/dds/sub/DataReader.hpp
index b38ddaa..b476779 100644
--- a/src/hpp/dds/sub/DataReader.hpp
+++ b/src/hpp/dds/sub/DataReader.hpp
@@ -1,10 +1,8 @@
 #ifndef OMG_DDS_SUB_DATA_READER_HPP_
 #define OMG_DDS_SUB_DATA_READER_HPP_


-#include <dds/sub/TDataReader.hpp>
 #include <dds/sub/detail/DataReader.hpp>


-
 namespace dds {
   namespace sub {
     template <typename T,
@@ -15,6 +13,7 @@ namespace dds {
   }
 }


+#include <dds/sub/TDataReader.hpp>


 // = Manipulators
 namespace dds {


diff --git a/src/hpp/dds/topic/ContentFilteredTopic.hpp b/src/hpp/dds/topic/ContentFilteredTopic.hpp
index 057a2f6..cbc5cfc 100644
--- a/src/hpp/dds/topic/ContentFilteredTopic.hpp
+++ b/src/hpp/dds/topic/ContentFilteredTopic.hpp
@@ -20,11 +20,12 @@
  */


 #include <dds/topic/detail/ContentFilteredTopic.hpp>
-#include <dds/topic/TContentFilteredTopic.hpp>


 namespace dds { namespace topic {
   template <typename T, template <typename Q> class DELEGATE = dds::topic::detail::ContentFilteredTopic>
   class ContentFilteredTopic;
 } }


+#include <dds/topic/TContentFilteredTopic.hpp>
+
 #endif /* OMG_DDS_TOPIC_CONTENT_FILTERED_TOPIC_HPP_ */


diff --git a/src/hpp/dds/topic/Topic.hpp b/src/hpp/dds/topic/Topic.hpp
index cd69316..5545f76 100644
--- a/src/hpp/dds/topic/Topic.hpp
+++ b/src/hpp/dds/topic/Topic.hpp
@@ -2,11 +2,12 @@
 #define OMG_DDS_TOPIC_TOPIC_HPP_


 #include <dds/topic/detail/Topic.hpp>
-#include <dds/topic/TTopic.hpp>


 namespace dds { namespace topic {
   template <typename T, template <typename Q> class DELEGATE = dds::topic::detail::Topic>
   class Topic;
 } }


+#include <dds/topic/TTopic.hpp>
+
 #endif /* OMG_DDS_TOPIC_TOPIC_HPP_ */


diff --git a/src/hpp/dds/topic/TopicDescription.hpp b/src/hpp/dds/topic/TopicDescription.hpp
index 47e2dd1..6e908b0 100644
--- a/src/hpp/dds/topic/TopicDescription.hpp
+++ b/src/hpp/dds/topic/TopicDescription.hpp
@@ -20,7 +20,6 @@
  */


 #include <dds/topic/detail/TopicDescription.hpp>
-#include <dds/topic/TTopicDescription.hpp>


 namespace dds { namespace topic {
   template <typename T,
@@ -28,5 +27,6 @@ namespace dds { namespace topic {
   class TopicDescription;
 } }


+#include <dds/topic/TTopicDescription.hpp>


 #endif /* OMG_DDS_TOPIC_TOPIC_DESCRIPTION_HPP_ */
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/core/cond/detail/GuardCondition.hpp

  • Key: DDSPSMC11_-49
  • Legacy Issue Number: 18620
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Name: Simon McQueen
    Employer: PrismTech
    Specification: DDS CXX PSM RTF
    FormalNumber: ptc/12-10-03
    Nature: Revision

    Issues:

    Code incorrect.

    Suggested resolution:

    diff --git a/src/hpp/dds/core/cond/detail/GuardCondition.hpp b/src/hpp/dds/core/cond/detail/GuardCondition.hpp
    index a9143fa..fdc8b98 100644
    — a/src/hpp/dds/core/cond/detail/GuardCondition.hpp
    +++ b/src/hpp/dds/core/cond/detail/GuardCondition.hpp
    @@ -20,13 +20,13 @@
    */

    #include <dds/core/cond/TGuardCondition.hpp>
    -#include <foo/bar/core/cond/GuardConditionImpl.hpp>
    +#include <foo/bar/core/cond/GuardCondition.hpp>

    namespace dds {
    namespace core {
    namespace cond {
    namespace detail

    { - typedef dds::core::cond::TGuardCondition<foo::bar::core::cond::GuardConditionl> GuardCondition; + typedef dds::core::cond::TGuardCondition<foo::bar::core::cond::GuardCondition> GuardCondition; }

    }
    }
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 3 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

Inconsistent use of Type/type - fix compilation

  • Key: DDSPSMC11_-28
  • Legacy Issue Number: 18614
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Name: Simon McQueen
    Employer: PrismTech
    Specification: DDS CXX PSM RTF
    FormalNumber: ptc/12-10-03
    Nature: Revision

    Issues:

    Code in src/hpp/dds/core/SafeEnumeration.hpp and
    src/hpp/dds/core/policy/PolicyKind.hpp does not compile.

    Suggested resolution:

    diff --git a/src/hpp/dds/core/SafeEnumeration.hpp
b/src/hpp/dds/core/SafeEnumeration.hpp
index 3f7ca67..0d443c2 100644
--- a/src/hpp/dds/core/SafeEnumeration.hpp
+++ b/src/hpp/dds/core/SafeEnumeration.hpp
@@ -1,29 +1,76 @@
+/* Copyright 2010, Object Management Group, Inc.
+* Copyright 2010, PrismTech, Corp.
+* Copyright 2010, Real-Time Innovations, Inc.
+* All rights reserved.
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+*     http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/

 #ifndef OMG_DDS_CORE_SAFEENUMERATION_HPP_
 #define OMG_DDS_CORE_SAFEENUMERATION_HPP_

namespace dds {
namespace core {
+/**
+ * safe_enum provides a wrapper for enumerated types in a typesafe
+ * manner.
+ * safe_enums allow specification of the underlying type,
+ * do not implictly convert to integers, and resolve scoping issues.
+ */
-    template<typename def, typename inner = typename def::type>
+    template<typename def, typename inner = typename def::Type>
     class safe_enum : public def
     {
-      typedef typename def::type type;
+      typedef typename def::Type type;
       inner val;

     public:
diff --git a/src/hpp/dds/core/policy/PolicyKind.hpp
b/src/hpp/dds/core/policy/PolicyKind.hpp
index 6928742..9537d78 100644
--- a/src/hpp/dds/core/policy/PolicyKind.hpp
+++ b/src/hpp/dds/core/policy/PolicyKind.hpp
@@ -25,7 +25,7 @@
 namespace dds { namespace core { namespace policy {


   struct OwnershipKind_def {
-    enum type {
+    enum Type {
       SHARED


 #ifdef  OMG_DDS_OWNERSHIP_SUPPORT
@@ -37,7 +37,7 @@ namespace dds { namespace core { namespace policy {
   typedef dds::core::safe_enum<OwnershipKind_def> OwnershipKind;


   struct DurabilityKind_def {
-    enum type {
+    enum Type {
       VOLATILE,
       TRANSIENT_LOCAL


@@ -46,8 +46,7 @@ namespace dds { namespace core { namespace policy {
       TRANSIENT,
       PERSISTENT
 #endif  // #ifdef  OMG_DDS_PERSISTENCE_SUPPORT
-    };
-  };
+    }; };
   typedef dds::core::safe_enum<DurabilityKind_def> DurabilityKind;


   struct PresentationAccessScopeKind_def  {
@@ -60,11 +59,11 @@ namespace dds { namespace core { namespace policy {
       GROUP
 #endif  // OMG_DDS_OBJECT_MODEL_SUPPORT
     }; };
-
+  typedef dds::core::safe_enum<PresentationAccessScopeKind_def>
PresentationAccessScopeKind;



   struct ReliabilityKind_def {
-    enum type {
+    enum Type {
       BEST_EFFORT,
       RELIABLE
     };
@@ -73,7 +72,7 @@ namespace dds { namespace core { namespace policy {



   struct DestinationOrderKind_def {
-    enum type {
+    enum Type {
       BY_RECEPTION_TIMESTAMP,
       BY_SOURCE_TIMESTAMP
     }; };
@@ -81,7 +80,7 @@ namespace dds { namespace core { namespace policy {
   typedef dds::core::safe_enum<DestinationOrderKind_def>
DestinationOrderKind;


   struct HistoryKind_def {
-    enum type {
+    enum Type {
       KEEP_LAST,
       KEEP_ALL
     };};
@@ -89,7 +88,7 @@ namespace dds { namespace core { namespace policy {
   typedef dds::core::safe_enum<HistoryKind_def> HistoryKind;


   struct LivelinessKind_def {
-    enum type {
+    enum Type {
       AUTOMATIC,
       MANUAL_BY_PARTICIPANT,
       MANUAL_BY_TOPIC
@@ -97,7 +96,7 @@ namespace dds { namespace core { namespace policy {
   typedef dds::core::safe_enum<LivelinessKind_def> LivelinessKind;


   struct TypeConsistencyEnforcementKind_def {
-    enum type {
+    enum Type {
       EXACT_TYPE_TYPE_CONSISTENCY,
       EXACT_NAME_TYPE_CONSISTENCY,
       DECLARED_TYPE_CONSISTENCY,
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 3 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/core/Optional.hpp

  • Key: DDSPSMC11_-31
  • Legacy Issue Number: 18613
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Name: Simon McQueen
    Employer: PrismTech
    Specification: DDS CXX PSM RTF
    FormalNumber: ptc/12-10-03
    Nature: Revision

    Issues:

    Escape '@' annotation in comment

    Suggested resolution:

    diff --git a/src/hpp/dds/core/Optional.hpp b/src/hpp/dds/core/Optional.hpp
index 5e563d0..7f1a1fc 100644
--- a/src/hpp/dds/core/Optional.hpp
+++ b/src/hpp/dds/core/Optional.hpp
@@ -24,7 +24,7 @@ namespace dds { namespace core {


   /**
    * The optional class is used to wrap attributes annotated with the
-   * @optional annotation. This class provides a simple and safe way of
+   * \@optional annotation. This class provides a simple and safe way of
    * accessing, setting and resetting the stored attribute.
    */
   template <typename T, template <typename Q> class DELEGATE>
   class optional : public dds::core::Value< DELEGATE<T> >
   {
   public:
     optional(const T& t);

   public:
     /**
      * Returns true only if the attribute is set.
      */
     bool is_set() const;

     /**
-     * Reset the attribute
+     * Reset the attribute.
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 3 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

Example vendor code is incorrect

  • Key: DDSPSMC11_-43
  • Legacy Issue Number: 18625
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Suggested resolution:

    diff --git a/src/hpp/dds/core/cond/detail/StatusCondition.hpp b/src/hpp/dds/core/cond/detail/StatusCondition.hpp
index 400c6c8..06f0198 100644
--- a/src/hpp/dds/core/cond/detail/StatusCondition.hpp
+++ b/src/hpp/dds/core/cond/detail/StatusCondition.hpp
@@ -27,7 +27,7 @@ namespace dds {
   namespace core {
     namespace cond {
       namespace detail {
-        typedef dds::core::cond::StatusCondition<foo::bar::core::cond::StatusCondition> StatusCondition;
+        typedef dds::core::cond::TStatusCondition<foo::bar::core::cond::StatusCondition> StatusCondition;
       }
     }
   }
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/core/cond/TWaitSet.hpp

  • Key: DDSPSMC11_-29
  • Legacy Issue Number: 18619
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Name: Simon McQueen
    Employer: PrismTech
    Specification: DDS CXX PSM RTF
    FormalNumber: ptc/12-10-03
    Nature: Revision

    Issues:

    Code does not compile.
    Comments incorrect.

    Suggested resolution:

    diff --git a/src/hpp/dds/core/cond/TWaitSet.hpp b/src/hpp/dds/core/cond/TWaitSet.hpp
index dfb05a2..a7fa3ee 100644
--- a/src/hpp/dds/core/cond/TWaitSet.hpp
+++ b/src/hpp/dds/core/cond/TWaitSet.hpp
@@ -22,7 +22,9 @@
 #include <vector>


 #include <dds/core/types.hpp>
+#include <dds/core/Duration.hpp>
 #include <dds/core/cond/Condition.hpp>
+#include <dds/core/cond/WaitSet.hpp>


 namespace dds {
   namespace core {

@@ -39,209 +44,207 @@ namespace dds {
  * the attached Condition objects has a trigger_value of TRUE or else
  * until the timeout expires.
  * A WaitSet is not necessarily associated with a single DomainParticipant
- * and could be used to wait on Condition objects associated with different
+ * and could be used to wait for Condition objects associated with different
  * DomainParticipant objects.

 public:
-  OMG_DDS_REF_TYPE(TWaitSet, dds::core::Reference, DELEGATE)
+ OMG_DDS_REF_TYPE_PUBLIC(TWaitSet, dds::core::Reference, DELEGATE)

 public:
-  /**
-   * Creates a new waitset.
-   */
-  TWaitSet();
-
   ~TWaitSet();


 public:
 public:
  /**
   * This operation allows an application thread to wait for the occurrence
-   * of certain conditions. If none of the conditions attached to the
+  * of certain Conditions. If none of the Conditions attached to the
   * WaitSet have a trigger_value of TRUE, the wait operation will block
   * suspending the calling thread.
     *
     * The wait operation takes a timeout argument that specifies the maximum
-    * duration for the wait. It this duration is exceeded and none of
+    * duration for the wait. If this duration is exceeded and none of
     * the attached Condition objects is true, wait will continue and the
     * returned ConditionSeq will be empty.
     *
     * It is not allowed for more than one application thread to be waiting
     * on the same WaitSet. If the wait operation is invoked on a WaitSet that
-     * already has a thread blocking on it, the operation will raise
-     * immediately an exception PreconditionNotMet.
+     * already has a thread blocking on it, the operation will immediately 
+     * raise a PreconditionNotMet exception.
     *
     * The result of the wait operation is the list of all the attached
-     * conditions that have a trigger_value of TRUE (i.e., the conditions
+     * Conditions that have a trigger_value of TRUE (i.e., the Conditions
     * that unblocked the wait).
     *
     * @param timeout the maximum amount of time for which the wait
-     * should block while waiting for a condition to be triggered.
+     * should block while waiting for a Condition to be triggered.
     *
-     * @raise PreconditionNotMetException when multiple thread try to invoke
-     *        the method concurrently.
+     * @throws PreconditionNotMetException when multiple threads try to invoke
+     *        the function concurrently.
     *
-     * @return a vector containing the triggered conditions
+     * @return a vector containing the triggered Conditions
     */

@@ -95,11 +92,6 @@ public:
   /**
    * This operation allows an application thread to wait for the occurrence
-    * of certain conditions. If none of the conditions attached to the
+   * of certain Conditions. If none of the Conditions attached to the
    * WaitSet have a trigger_value of TRUE, the wait operation will block
    * suspending the calling thread.
    *
-   * The wait operation takes a timeout argument that specifies the maximum
-   * duration for the wait. It this duration is exceeded and none of
-   * the attached Condition objects is true, wait will continue and the
-   * returned ConditionSeq will be empty.
-   *
    * It is not allowed for more than one application thread to be waiting
    * on the same WaitSet. If the wait operation is invoked on a WaitSet that
-     * already has a thread blocking on it, the operation will raise
-     * immediately an exception PreconditionNotMet.
+     * already has a thread blocking on it, the operation will immediately 
+     * raise a PreconditionNotMet exception.
    *
    * The result of the wait operation is the list of all the attached
-    * conditions that have a trigger_value of TRUE (i.e., the conditions
+    * Conditions that have a trigger_value of TRUE (i.e., the Conditions
    * that unblocked the wait).
    *
-   * @param timeout the maximum amount of time for which the wait
-   * should block while waiting for a condition to be triggered.
-   *
-   * @raise PreconditionNotMetException when multiple thread try to invoke
+   * @throws PreconditionNotMetException when multiple threads try to invoke
    *        the method concurrently.
    *
-    * @return a vector containing the triggered conditions
+    * @return a vector containing the triggered Conditions
@@ -142,7 +131,7 @@ public:
   /**
    * This operation allows an application thread to wait for the occurrence
-    * of certain conditions. If none of the conditions attached to the
+    * of certain Conditions. If none of the Conditions attached to the
    * WaitSet have a trigger_value of TRUE, the wait operation will block
    * suspending the calling thread.
    *
    * The wait operation takes a timeout argument that specifies the maximum
-    * duration for the wait. It this duration is exceeded and none of
+    * duration for the wait. If this duration is exceeded and none of
    * the attached Condition objects is true, wait will continue and the
    * returned ConditionSeq will be empty.
    *
    * It is not allowed for more than one application thread to be waiting
    * on the same WaitSet. If the wait operation is invoked on a WaitSet that
-     * already has a thread blocking on it, the operation will raise
-     * immediately an exception PreconditionNotMet.
+     * already has a thread blocking on it, the operation will immediately 
+     * raise a PreconditionNotMet exception.
    *
    * The result of the wait operation is the list of all the attached
-    * conditions that have a trigger_value of TRUE (i.e., the conditions
+    * Conditions that have a trigger_value of TRUE (i.e., the Conditions
    * that unblocked the wait).
+    *
+    * @param triggered a ConditionSeq in which to put Conditions that were
+    * triggered during the wait.
    *
    * @param timeout the maximum amount of time for which the wait
-    * should block while waiting for a condition to be triggered.
+    * should block while waiting for a Condition to be triggered.
    *
-   * @raise PreconditionNotMetException when multiple thread try to invoke
+   * @throws PreconditionNotMetException when multiple threads try to invoke
    *        the method concurrently.
    *
-    * @return a vector containing the triggered conditions
+    * @return a vector containing the triggered Conditions
@@ -173,7 +162,7 @@ public:
    * This operation allows an application thread to wait for the occurrence
-    * of certain conditions. If none of the conditions attached to the
+    * of certain Conditions. If none of the Conditions attached to the
    * WaitSet have a trigger_value of TRUE, the wait operation will block
    * suspending the calling thread.
    *
    * The wait operation takes a timeout argument that specifies the maximum
-    * duration for the wait. It this duration is exceeded and none of
+    * duration for the wait. If this duration is exceeded and none of
    * the attached Condition objects is true, wait will continue and the
    * returned ConditionSeq will be empty.
    *
    * It is not allowed for more than one application thread to be waiting
    * on the same WaitSet. If the wait operation is invoked on a WaitSet that
-     * already has a thread blocking on it, the operation will raise
-     * immediately an exception PreconditionNotMet.
+     * already has a thread blocking on it, the operation will immediately 
+     * raise a PreconditionNotMet exception.
    *
    * The result of the wait operation is the list of all the attached
-    * conditions that have a trigger_value of TRUE (i.e., the conditions
+    * Conditions that have a trigger_value of TRUE (i.e., the Conditions
    * that unblocked the wait).
    *
+    * @param triggered a ConditionSeq in which to put Conditions that were
+    * triggered during the wait.
-    *
-    * @param timeout the maximum amount of time for which the wait
-    * should block while waiting for a condition to be triggered.
    *
-   * @raise PreconditionNotMetException when multiple thread try to invoke
+   * @throws PreconditionNotMetException when multiple threads try to invoke
    *        the method concurrently.
    *
-    * @return a vector containing the triggered conditions
+    * @return a vector containing the triggered Conditions
    ConditionSeq& wait(ConditionSeq& triggered);

public:
    /**
-     * Waits for at least one of the attached conditions to trigger and then
-     * dispatches the events.
+     * Waits for at least one of the attached Conditions to trigger and then
+     * dispatches the functor associated with the Condition.
     */
    void dispatch();

    /**
-     * Waits for at least one of the attached conditions to trigger and then
-     * dispatches the events, or, times out and unblocks.
+    * Waits for at least one of the attached Conditions to trigger and then
+     * dispatches the functor associated with the Condition, or, times
+     * out and unblocks.*
     */
    void dispatch(const dds::core::Duration& timeout);

@@ -199,12 +188,12 @@ public:
   /**
    * A synonym for attach_condition.
    */
-  WaitSet& operator +=(const dds::core::cond::Condition& cond);
+  TWaitSet& operator +=(const dds::core::cond::Condition& cond);


   /**
    * A synonym for detach_condition.
    */
-  WaitSet& operator -=(const dds::core::cond::Condition& cond);
+  TWaitSet& operator -=(const dds::core::cond::Condition& cond);


   /**
    * Attaches a Condition to the WaitSet. It is possible to attach a
@@ -216,7 +205,7 @@ public:
   /**
    * Attaches a Condition to the WaitSet. It is possible to attach a
    * Condition on a WaitSet that is currently being waited upon
    * (via the wait operation). In this case, if the Condition has a
-    * trigger_value of TRUE, then attaching the condition will unblock
+    * trigger_value of TRUE, then attaching the Condition will unblock
    * the WaitSet. Adding a Condition that is already attached to the WaitSet
    * has no effect.
    *
-    * @param cond the condition to be attached to this waitset.
+    * @param cond the Condition to be attached to this WaitSet.
+    *
+    * @return the WaitSet itself so that attaching Conditions
+    * can be chained.
    */
-  WaitSet& attach_condition(const dds::core::cond::Condition& cond);
+  TWaitSet& attach_condition(const dds::core::cond::Condition& cond);


   /**
    * Detaches a Condition from the WaitSet. If the Condition was not
    * attached to the WaitSet, the operation will return false.
    *
-    * @param cond the condition to detach from this WaitSet
+    * @param cond the Condition to detach from this WaitSet
    *
-    * @return true if the condition was found and detached, false if the
-    *         condition was not part of the WaitSet.
+    * @return true if the Condition was found and detached, false if the
+    *         Condition was not part of the WaitSet.
    */
   bool detach_condition(const dds::core::cond::Condition& cond);

   /**
-    * This operation retrieves the list of attached conditions.
+   * This operation retrieves the list of attached Conditions.
    *
-    * @return the list of attached conditions.
+    * @return the list of attached Conditions.
    */
-   const ConditionSeq conditions();
+   const ConditionSeq conditions() const;

   /**
-    * This operation retrieves the list of attached conditions.
+    * This operation retrieves the list of attached Conditions.
    *
+    * @param conds a ConditionSeq in which to put the attached
+    * Conditions.
+    *
-    * @return the list of attached conditions.
+    * @return the list of attached Conditions.
    */
   ConditionSeq& conditions(ConditionSeq& conds) const;
};
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 3 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/core/cond/StatusCondition.hpp

  • Key: DDSPSMC11_-45
  • Legacy Issue Number: 18618
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Name: Simon McQueen
    Employer: PrismTech
    Specification: DDS CXX PSM RTF
    FormalNumber: ptc/12-10-03
    Nature: Revision

    Issues:

    Does not compile.

    Suggested resolution:

    diff --git a/src/hpp/dds/core/cond/StatusCondition.hpp b/src/hpp/dds/core/cond/StatusCondition.hpp
index 4e33b3d..e500e39 100644
--- a/src/hpp/dds/core/cond/StatusCondition.hpp
+++ b/src/hpp/dds/core/cond/StatusCondition.hpp
@@ -22,7 +22,7 @@
 #include <dds/core/cond/TStatusCondition.hpp>


 namespace dds { namespace core { namespace cond {
-  typedef TStatusCondition<detail::StatusCondition> StatusCondition;
+  typedef detail::StatusCondition StatusCondition;
 } } }


 #endif /* OMG_DDS_CORE_STATUSCONDITION_HPP_ */
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 3 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

Code in src/hpp/dds/core/array.hpp does not compile

  • Key: DDSPSMC11_-33
  • Legacy Issue Number: 18617
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Name: Simon McQueen
    Employer: PrismTech
    Specification: DDS CXX PSM RTF
    FormalNumber: ptc/12-10-03
    Nature: Revision

    Issues:

    Does not compile

    Suggested resolution:

    diff --git a/src/hpp/dds/core/array.hpp b/src/hpp/dds/core/array.hpp
index cd39d02..dfa910b 100644
--- a/src/hpp/dds/core/array.hpp
+++ b/src/hpp/dds/core/array.hpp
@@ -219,6 +219,8 @@ namespace dds {
     template<std::size_t _Int, typename _Tp>
        class tuple_element;


+    template <typename _Tp> class tuple_size;
+
     template<typename _Tp, std::size_t _Nm>
        struct tuple_size<array<_Tp, _Nm> >
        { static const std::size_t value = _Nm; };
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 3 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/pub/AnyDataWriter.hpp

  • Key: DDSPSMC11_-41
  • Legacy Issue Number: 18637
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Incorrect and unnecessary operator declaration should be removed.

    Suggested resolution:

    diff --git a/src/hpp/dds/pub/AnyDataWriter.hpp b/src/hpp/dds/pub/AnyDataWriter.hpp
index b6bbde2..6d0bad5 100644
--- a/src/hpp/dds/pub/AnyDataWriter.hpp
+++ b/src/hpp/dds/pub/AnyDataWriter.hpp
@@ -72,9 +72,6 @@ public:
   template <typename T> AnyDataWriter&
   operator =(const dds::pub::DataWriter<T>& rhs);


-  template <typename T>
-  AnyDataWriter& operator =(const AnyDataWriter& rhs);
-
   inline AnyDataWriter& operator =(AnyDataWriter rhs);


 public:
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/domain/qos/detail/DomainParticipantQos.hpp

  • Key: DDSPSMC11_-34
  • Legacy Issue Number: 18636
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Example vendor code is incorrect.

    Suggested resolution:

    diff --git a/src/hpp/dds/domain/qos/detail/DomainParticipantQos.hpp b/src/hpp/dds/domain/qos/detail/DomainParticipantQos.hpp
index 9007702..c57454d 100644
--- a/src/hpp/dds/domain/qos/detail/DomainParticipantQos.hpp
+++ b/src/hpp/dds/domain/qos/detail/DomainParticipantQos.hpp
@@ -28,7 +28,7 @@ namespace dds {
   namespace domain {
     namespace qos {
       namespace detail {
-      typedef ::dds::core::qos::TEntityQos< foo::bar::domain::qos::DomainParticipantQos >
+      typedef ::dds::core::TEntityQos< foo::bar::domain::qos::DomainParticipantQos >
       DomainParticipantQos;
       }
     }
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/domain/TDomainParticipant.hpp

  • Key: DDSPSMC11_-32
  • Legacy Issue Number: 18634
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Vestigial implementation code needs removing to fix compilation.

    Correct comments.

    Suggested resolution:

    diff --git a/src/hpp/dds/domain/TDomainParticipant.hpp
b/src/hpp/dds/domain/TDomainParticipant.hpp
index ce51ea9..3bf7bb0 100644
--- a/src/hpp/dds/domain/TDomainParticipant.hpp
+++ b/src/hpp/dds/domain/TDomainParticipant.hpp
@@ -75,8 +75,7 @@ public:
    *           <code>DomainParticipant</code>.
    *
    */
-  TDomainParticipant(uint32_t did)
-  : ::dds::core::TEntity<DELEGATE>(new DELEGATE(did));
+  TDomainParticipant(uint32_t id);


   /**
    * Create a new <code>DomainParticipant</code> object.
@@ -103,11 +102,11 @@ public:
 public:


   /**
-   * Register a listener with the <core>DomainParticipant</code>.
+   * Register a listener with the <code>DomainParticipant</code>.
    * The notifications received by the listener depend on the
    * status mask with which it was registered.
    *
    * @param listener the listener
    * @param event_mask the mask defining the events for which the listener
    *  will be notified.
    */
-    void listener(Listener* the_listener,listener,
+    void listener(Listener* listener,listener,
                  const ::dds::core::status::StatusMask& event_mask);

@@ -144,19 +151,18 @@ public:

    /**
     * This operation manually asserts the liveliness of the DataWriter.
-     * This is used in combination with the LIVELINESS QoS policy
+     * This is used in combination with the Liveliness QoS policy
     * (see Section 7.1.3, Supported QoS, on page 96) to indicate to the
     * Service that the entity remains active.
     * This operation need only be used if the LIVELINESS setting is either
     * MANUAL_BY_PARTICIPANT or MANUAL_BY_TOPIC. Otherwise, it has no effect.
     *
-     * <b>Note</b> Writing data via the write operation on a DataWriter
+     * Note: Writing data via the write operation on a DataWriter
     * asserts liveliness on the DataWriter itself and its DomainParticipant.
     * Consequently the use of assert_liveliness is only needed if the
     * application is not writing data regularly.
     */
    void assert_liveliness();


    /**

@@ -187,17 +193,70 @@ public:
+    /**
+     * Set the QoS associated with this DomainParticipant.
+     * @param qos the new DomainParticipant QoS
+     */
+    dds::domain::qos::DomainParticipantQos& operator << (const dds::domain::qos::DomainParticipantQos& qos);
+
+    /**
+     * Get the QoS associated with this DomainParticipant.
+     *
+     * @param qos the current DomainParticipant QoS
+     */
+    const TDomainParticipant& operator >> (dds::domain::qos::DomainParticipantQos& qos) const;
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

src/hpp/dds/domain/TDomainId.hpp should be removed from the API

  • Key: DDSPSMC11_-42
  • Legacy Issue Number: 18633
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    uint32_t is used as the Domain ID throughout the spec so TDomainId.hpp is no longer required.

    Suggested resolution:

    diff --git a/src/hpp/dds/domain/TDomainId.hpp b/src/hpp/dds/domain/TDomainId.hpp
deleted file mode 100644
index dc6d9af..0000000
--- a/src/hpp/dds/domain/TDomainId.hpp
+++ /dev/null
@@ -1,29 +0,0 @@
-#ifndef OMG_DDS_DOMAIN_T_DOMAIN_ID_HPP_
-#define OMG_DDS_DOMAIN_T_DOMAIN_ID_HPP_
-
-#include <dds/core/Value.hpp>
-
-namespace dds { namespace domain {
-  template <typename DELEGATE>
-  class TDomainId;
-} }
-
-
-template <typename DELEGATE>
-class dds::domain::TDomainId : public dds::core::Value<DELEGATE> {
-public:
-
-  template <typename ARG0>
-  TDomainId(ARG0 id) : dds::core::Value<DELEGATE>(id);
-
-  template <typename ARG0, typename ARG1>
-  TDomainId(ARG0 arg0, ARG1 arg1);
-
-  operator uint32_t () const;
-
-  uint32_t value() const;
-
-  static const TDomainId default_domain();
-};
-
-#endif /* OMG_DDS_DOMAIN_T_DOMAIN_ID_HPP_ */
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/core/types.hpp

  • Key: DDSPSMC11_-40
  • Legacy Issue Number: 18631
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Windows export macros required.

    Suggested resolution:

    diff --git a/src/hpp/dds/core/types.hpp b/src/hpp/dds/core/types.hpp
index c58e002..90c56f4 100644
--- a/src/hpp/dds/core/types.hpp
+++ b/src/hpp/dds/core/types.hpp
@@ -33,8 +33,8 @@ namespace dds { namespace core {
   typedef std::vector<std::string> StringSeq;


   // DDS Null-Reference
-  class null_type { };
-  extern const null_type null;
+  class OMG_DDS_API null_type { };
+  extern const null_type OMG_DDS_API null;



 #ifdef OMG_DDS_EXTENSIBLE_AND_DYNAMIC_TOPIC_TYPE_SUPPORT
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/core/ref_traits.hpp

  • Key: DDSPSMC11_-30
  • Legacy Issue Number: 18629
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Advisory comment is inadvertently and inappropriately documenting namespace.

    Suggested resolution:

    diff --git a/src/hpp/dds/core/ref_traits.hpp b/src/hpp/dds/core/ref_traits.hpp
index 5a34f6f..ff469d1 100644
--- a/src/hpp/dds/core/ref_traits.hpp
+++ b/src/hpp/dds/core/ref_traits.hpp
@@ -19,11 +19,13 @@
  * limitations under the License.
  */


-/**
+
+namespace  dds { namespace core {
+
+/*
  * These traits have to be provided by compliant implementations
  * to enable safe polymorphic casts.
  */
-namespace  dds { namespace core {


   template <typename T1, typename T2>
   struct is_base_of;

@@ -38,12 +43,12 @@ namespace  dds { namespace core {
TO  polymorphic_cast(FROM& from);


}
} /* namespace dds / namespace core */


// This include should stay here as it provides implementations
-// for the declaration just above.
+// for the declaration immediately above.
#include <dds/core/detail/ref_traits.hpp>

#endif /* OMG_DDS_CORE_REF_TRAITS_H_ */
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/core/detail/conformance.hpp

  • Key: DDSPSMC11_-39
  • Legacy Issue Number: 18626
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Example vendor file is missing a conformance point macro used elsewhere in the API.

    Suggested resolution:

    diff --git a/src/hpp/dds/core/detail/conformance.hpp b/src/hpp/dds/core/detail/conformance.hpp
index f8b5f9b..bb8e974 100644
--- a/src/hpp/dds/core/detail/conformance.hpp
+++ b/src/hpp/dds/core/detail/conformance.hpp
@@ -22,6 +22,7 @@
 #define OMG_DDS_OBJECT_MODEL_SUPPORT                        FULL
 #define OMG_DDS_EXTENSIBLE_AND_DYNAMIC_TOPIC_TYPE_SUPPORT   FULL
 #define OMG_DDS_X_TYPES_DYNANIC_TYPE_SUPPORT                FULL
+#define OMG_DDS_X_TYPES_BUILTIN_TOPIC_TYPES_SUPPORT         FULL
 #define OMG_DDS_HAS_PRETTY_PRINT_COUT 1


 #endif /* OMG_DDS_CORE_DETAIL_CONFORMANCE_HPP_ */
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/pub/qos/detail/DataWriterQos.hpp & PublisherQos.hpp

  • Key: DDSPSMC11_-44
  • Legacy Issue Number: 18642
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Example vendor code is incorrect in these two files.

    Suggested resolution:

    diff --git a/src/hpp/dds/pub/qos/detail/DataWriterQos.hpp b/src/hpp/dds/pub/qos/detail/DataWriterQos.hpp
index 67483ec..2f7a23e 100644
--- a/src/hpp/dds/pub/qos/detail/DataWriterQos.hpp
+++ b/src/hpp/dds/pub/qos/detail/DataWriterQos.hpp
@@ -23,7 +23,7 @@
 #include <foo/bar/pub/qos/DataWriterQos.hpp>


 namespace dds { namespace pub { namespace qos { namespace detail {
-  typedef dds::core::qos::TEntityQos<foo::bar::pub::qos::DataWriterQos> DataWriterQos;
+  typedef dds::core::TEntityQos<foo::bar::pub::qos::DataWriterQos> DataWriterQos;
 } } } }


 #endif /* OMG_DDS_QOS_DETAIL_DATA_WRITER_QOS_HPP_ */
diff --git a/src/hpp/dds/pub/qos/detail/PublisherQos.hpp b/src/hpp/dds/pub/qos/detail/PublisherQos.hpp
index 1abff41..a60635b 100644
--- a/src/hpp/dds/pub/qos/detail/PublisherQos.hpp
+++ b/src/hpp/dds/pub/qos/detail/PublisherQos.hpp
@@ -23,7 +23,7 @@
 #include <foo/bar/pub/qos/PublisherQos.hpp>


 namespace dds { namespace pub { namespace qos { namespace detail {
-  typedef dds::core::qos::TEntityQos<foo::bar::pub::qos::PublisherQos> PublisherQos;
+  typedef dds::core::TEntityQos<foo::bar::pub::qos::PublisherQos> PublisherQos;
 } } } }


 #endif /* OMG_DDS_PUB_QOS_DETAIL_PUBLISER_QOS_HPP_ */
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

Documentation comments corrections to src/hpp/dds/pub/discovery.hpp

  • Key: DDSPSMC11_-36
  • Legacy Issue Number: 18640
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Corrections to documentation comments required.

    Suggested resolution:

    diff --git a/src/hpp/dds/pub/discovery.hpp b/src/hpp/dds/pub/discovery.hpp
index f50e179..5a8eb28 100644
--- a/src/hpp/dds/pub/discovery.hpp
+++ b/src/hpp/dds/pub/discovery.hpp
@@ -40,8 +40,6 @@ namespace dds { namespace pub {
    * @param dp      the <code>DomainParticipant</code> for which the remote
    *                entity will be ignored
    *
-   * @param handle  the <code>InstanceHandle</code> of the remote entity that
-   *                has to be ignored
    */
   template <typename FwdIterator>
   void ignore(const dds::domain::DomainParticipant& dp, FwdIterator begin, FwdIterator end);
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/pub/TSuspendedPublication.hpp

  • Key: DDSPSMC11_-35
  • Legacy Issue Number: 18639
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Destructor declaration incorrect.

    Suggested resolution:

    diff --git a/src/hpp/dds/pub/TSuspendedPublication.hpp b/src/hpp/dds/pub/TSuspendedPublication.hpp
index fcd096b..ac4ea26 100644
--- a/src/hpp/dds/pub/TSuspendedPublication.hpp
+++ b/src/hpp/dds/pub/TSuspendedPublication.hpp
@@ -72,7 +72,7 @@ public:
    * suspend_publications. Otherwise the operation will return the
    * error PRECONDITION_NOT_MET.
    */
-  ~SuspendedPublication();    // resumes publications implicitly
+  ~TSuspendedPublication();    // resumes publications implicitly
 };
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/sub/TDataReader.hpp

  • Key: DDSPSMC11_-46
  • Legacy Issue Number: 18649
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Duplicate function definition to remove.

    Missing header required to fix compilation.

    Correct comments.

    Suggested resolution:

    diff --git a/src/hpp/dds/sub/TDataReader.hpp b/src/hpp/dds/sub/TDataReader.hpp
    index e10705c..ca592bb 100644
    — a/src/hpp/dds/sub/TDataReader.hpp
    +++ b/src/hpp/dds/sub/TDataReader.hpp
    @@ -23,6 +23,7 @@
    #include <dds/topic/ContentFilteredTopic.hpp>
    #include <dds/topic/TopicInstance.hpp>
    #include <dds/sub/LoanedSamples.hpp>
    +#include <dds/sub/Subscriber.hpp>

    namespace dds {
    namespace sub {
    @@ -56,7 +57,6 @@ public:
    Selector(DataReader& dr);

    Selector& instance(const dds::core::InstanceHandle& h);

    • Selector& instance(const dds::core::InstanceHandle& h);
      Selector& state(const dds::sub::status::DataState& s);
      Selector& content(const dds::sub::Query& query);
      Selector& max_samples(uint32_t n);
      @@ -220,7 +220,7 @@ public:

    /**

    • Returns the default read-state (if not changed, it is set to
    • * ReaderState::any()).
      + * DataState::any()).
      */
      const dds::sub::status::DataState& default_filter_state();

    @@ -258,7 +258,7 @@ public:

    • Read all samples using the default filter state. The memory used for
    • storing the sample may be loaned by the middleware thus allowing zero
    • copy operations.
    • * Implementation should strike to makethis read implementation
      + * Implementors should strive to make this read implementation
    • exception safe.
      */
      LoanedSamples<T> read();
      @@ -267,7 +267,7 @@ public:
    • Take all samples using the default filter state. The memory used for
    • storing the sample may be loaned by the middleware thus allowing zero
    • copy operations.
    • * Implementation should strike to make this read implementation
      + * Implementors should strive to make this take implementation
    • exception safe.
      */
      LoanedSamples<T> take();
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/sub/SubscriberListener.hpp

  • Key: DDSPSMC11_-37
  • Legacy Issue Number: 18648
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Missing header includes are required for this header to compile.

    Suggested resolution:

    diff --git a/src/hpp/dds/sub/SubscriberListener.hpp b/src/hpp/dds/sub/SubscriberListener.hpp
    index b185342..77f3e08 100644
    — a/src/hpp/dds/sub/SubscriberListener.hpp
    +++ b/src/hpp/dds/sub/SubscriberListener.hpp
    @@ -19,6 +19,8 @@

    • limitations under the License.
      */

    +#include <dds/sub/AnyDataReaderListener.hpp>
    +#include <dds/sub/Subscriber.hpp>

    namespace dds { namespace sub {
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/sub/DataReaderListener.hpp

  • Key: DDSPSMC11_-38
  • Legacy Issue Number: 18645
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Code needs compilation fixes.

    Suggested resolution:

    diff --git a/src/hpp/dds/sub/DataReaderListener.hpp b/src/hpp/dds/sub/DataReaderListener.hpp
index 17c620e..70b2777 100644
--- a/src/hpp/dds/sub/DataReaderListener.hpp
+++ b/src/hpp/dds/sub/DataReaderListener.hpp
@@ -32,10 +32,10 @@ namespace dds { namespace sub {
 template <typename T>
 class dds::sub::DataReaderListener {
 public:
-  typedef ::dds::core::smart_ptr_traits<DataReaderListener>::ref_type ref_type;
+  typedef typename ::dds::core::smart_ptr_traits<DataReaderListener>::ref_type ref_type;


 public:
-  virtual ~DataReaderListener();
+  virtual ~DataReaderListener() = 0;


 public:
   virtual void on_requested_deadline_missed(
@@ -69,7 +69,7 @@ public:
 template <typename T>
 class dds::sub::NoOpDataReaderListener : public virtual DataReaderListener<T> {
 public:
-  typedef ::dds::core::smart_ptr_traits<NoOpDataReaderListener>::ref_type ref_type;
+  typedef typename ::dds::core::smart_ptr_traits<NoOpDataReaderListener>::ref_type ref_type;


 public:
   virtual ~NoOpDataReaderListener();
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API correction required to src/hpp/dds/sub/SharedSamples.hpp

  • Key: DDSPSMC11_-27
  • Legacy Issue Number: 18647
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Compilation fixes required to code.

    Suggested resolution:

    diff --git a/src/hpp/dds/sub/SharedSamples.hpp b/src/hpp/dds/sub/SharedSamples.hpp
    index c48271a..8c517c8 100644
    — a/src/hpp/dds/sub/SharedSamples.hpp
    +++ b/src/hpp/dds/sub/SharedSamples.hpp
    @@ -30,7 +30,7 @@ public:
    typedef typename DELEGATE<T>::iterator iterator;
    typedef typename DELEGATE<T>::const_iterator const_iterator;

    -
    + typedef typename dds::core::smart_ptr_traits< DELEGATE<T> >::ref_type DELEGATE_REF_T;

    public:
    /**
    @@ -44,7 +44,7 @@ public:

    • @param ls the loaned samples.
      *
      */
    • SharedSamples(LoanedSamples ls);
      + SharedSamples(dds::sub::LoanedSamples<T> ls);

    ~SharedSamples();
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 9 Apr 2013 04:00 GMT
  • Updated: Sun, 30 Sep 2018 23:30 GMT

API needs a standardized way of downcasting API entities

  • Key: DDSPSMC11_-23
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Right now, API entities are wrapper templates around the actual Delegate implementation, as in (depicted a bit simplified):

    typedef TEntity<EntityDelegate> Entity;
    typedef TPublisher<PublisherDelegate> Publisher;

    If I have an entity of type Entity, and I want to widen it to a type Publisher, I cannot use a regular cast because I need to cast both the wrapper and its Delegate.
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 16 Mar 2016 19:03 GMT
  • Updated: Sun, 30 Sep 2018 23:28 GMT

Name clash between Topic discovery functions

  • Key: DDSPSMC11_-26
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The discovery functions for Topics (dds/topic/discovery.hpp) has a name clash between the function to discover a single topic by name (first function) and the function to discover all topics using a back-inserting iterator (third function):

    template <typename TOPIC>
TOPIC discover(const dds::domain::DomainParticipant& dp,
               const std::string& name,
               const dds::core::Duration& timeout = dds::core::Duration::infinite());

template <typename ANYTOPIC, typename BinIterator>
uint32_t discover(const dds::domain::DomainParticipant& dp, BinIterator begin);

    The first function has a default value for the 3rd parameter, but when you try to invoke it with only 2 parameters, the compiler picks the latter function because it considers that one a better match. (It matches both the amount and the type of the parameters, since the 2nd parameter is templatized and accepts any type).
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 16 Mar 2016 19:53 GMT
  • Updated: Sun, 30 Sep 2018 23:28 GMT

dds::topic::TBuiltinTopicKey should be completely customizable.

  • Key: DDSPSMC11_-24
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    In the DDS 1.4 specification, the IDL file describing the builtin topics consists of two parts:

    • A section with #define statements where certain datatypes may be customized by the different vendors.
    • A section where these customized datatypes are actually embedded in the builtin topic declarations.

    All builtin topics contain a key field of type BuiltinTopicKey_t that is defined in the following way:

    #define BUILTIN_TOPIC_KEY_TYPE_NATIVE long

module DDS {
    struct BuiltinTopicKey_t {
        BUILTIN_TOPIC_KEY_TYPE_NATIVE value[3];
    };
};

    This implies that vendors may specify part of the key (the array element type), but they may not specify it to be anything else than an array of three of those vendor specific datatypes.

    Right now, different vendors have specified the BuiltinTopicKey_t in various different ways: some uses an array of 16 octets to directly reflect the RTPS GUID, but the official DDS spec does not allow for this.

    For the DDS 1.4 specification, this has been files as a separate issue (see DDS15-206). For the Cxx PSM for DDS, this also needs to be addressed which is the purpose of this ticket. Right now, for the Cxx PSM specifies the dds::topic::BuiltinTopicKey as a vendor spefic instantiation of the dds::topic::TBuiltinTopicKey template in the following way:

    template <typename D>
class dds::topic::TBuiltinTopicKey : public ::dds::core::Value<D>
{
public:
    /**
     * Gets the BuiltinTopicKey.
     *
     * @return the BuiltinTopicKey
     */
    const int32_t* value() const;

    /**
     * Sets the BuiltinTopicKey.
     *
     * @param v the value to set
     */
    void value(const int32_t v[]);
};

    It is clear from this description that although the size of the array is unspecified, it is still implied that the key is an array of int32_t. This conflicts with the original DDS specification that explicitly allows for the builtin topic key type to be customizable by the user.
  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 5 Dec 2017 19:29 GMT
  • Updated: Sun, 30 Sep 2018 23:28 GMT

dds/core/cond/TCondition.hpp should have virtual methods

  • Key: DDSPSMC11_-19
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The operations of the dds::core::cond::TCondition.hpp class should be virtual:

    public:
-   ~TCondition();
+   virtual ~TCondition();

public:
    /**
     * Dispatches the functors that have been registered with the condition.
     */
-   void dispatch();
+   virtual void dispatch();

    /**
     * This operation retrieves the trigger_value of the Condition.
     */
-   bool trigger_value() const;
+   virtual bool trigger_value() const;
  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 20 Apr 2015 09:54 GMT
  • Updated: Sun, 30 Sep 2018 23:28 GMT

Ownership label SHARED is already defined as a macro in some SUN compilers

  • Key: DDSPSMC11_-22
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Some SUN compilers have predefined a macro called SHARED. This clashes with the definition of the enumeration label SHARED for the OwnershipKind_def struct.

    We suggest to add some conditional code to undef the SUN macro in that case.

    git diff:

    --- a/include/dds/core/policy/PolicyKind.hpp
+++ b/include/dds/core/policy/PolicyKind.hpp
@@ -29,6 +29,10 @@ namespace core
 namespace policy
 {

+/** @todo raise spec issue **/
+#if defined (__SUNPRO_CC) && defined(SHARED)
+#   undef SHARED
+#endif
 struct OwnershipKind_def
 {
     enum Type
  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 13 Apr 2015 15:32 GMT
  • Updated: Sun, 30 Sep 2018 23:28 GMT

Compilation error in dds/core/policy/PolicyKind.hpp

  • Key: DDSPSMC11_-21
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The enumeration for the TypeConsistencyEnforcementKind_def is not scoped by a struct, as all the other enumerations, but by a namespace. This should be fixed.

    git diff:

    @@ -96,7 +96,7 @@ namespace dds { namespace core { namespace policy {
     }; };
   typedef dds::core::safe_enum<LivelinessKind_def> LivelinessKind;

-  namespace TypeConsistencyEnforcementKind_def {
+  struct TypeConsistencyEnforcementKind_def {
     enum type {
       EXACT_TYPE_TYPE_CONSISTENCY,
       EXACT_NAME_TYPE_CONSISTENCY,
  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 13 Apr 2015 13:46 GMT
  • Updated: Sun, 30 Sep 2018 23:28 GMT

dds/core/array.hpp is licensed under LGPL

  • Key: DDSPSMC11_-20
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    According to the comments mentioned in dds/core/array.hpp, it contains code that is licensed under LGPL. This may cause legal issues for users that do not want to have their code impacted by LGPL license conditions.
  • Reported: DDS-PSM-Cxx 1.0b2 — Fri, 9 Feb 2018 16:25 GMT
  • Updated: Sun, 30 Sep 2018 23:28 GMT

Reference should provide comparison operators

  • Key: DDSPSMC11_-12
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    dds::core::Reference<D> should provide comparison operators beyond == and !=. operator< is especially useful to make reference types the key of std::map.

    Proposed solution: add the following lines to Reference.hpp, inside the dds::core namespace:

    template <class T, class U>
bool operator <(
        const dds::core::Reference<T>& a,
        const dds::core::Reference<U>& b) OMG_NOEXCEPT
{
    return a.delegate().get() < b.delegate().get();
}

template <class T, class U>
bool operator <=(
        const dds::core::Reference<T>& a,
        const dds::core::Reference<U>& b) OMG_NOEXCEPT
{
    return a.delegate().get() <= b.delegate().get();
}

template <class T, class U>
bool operator >(
        const dds::core::Reference<T>& a,
        const dds::core::Reference<U>& b) OMG_NOEXCEPT
{
    return a.delegate().get() > b.delegate().get();
}

template <class T, class U>
bool operator >=(
        const dds::core::Reference<T>& a,
        const dds::core::Reference<U>& b) OMG_NOEXCEPT
{
    return a.delegate().get() >= b.delegate().get();
}
  • Reported: DDS-PSM-Cxx 1.0b2 — Fri, 5 Jan 2018 18:24 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

Missing constants/functions to obtain the built-in topic names

  • Key: DDSPSMC11_-15
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The API should provide a way to obtain the built-in topic names:

    • "DCPSParticipant"
    • "DCPSTopic"
    • "DCPSPublication"
    • "DCPSSubscription"

    Proposed resolution:

    Add the following free-standing functions to the dds::topic namespace:

    namespace dds { namespace topic {

/** 
 * @brief Participant builtin topic name 
 *  
 * Topic name of the builtin dds::sub::DataReader for the 
 * dds::topic::ParticipantBuiltinTopicData type 
 */
OMG_DDS_API std::string participant_topic_name();

/** 
 * @brief Topic topic name 
 *  
 * Topic name of the builtin dds::sub::DataReader for the 
 * dds::topic::TopicBuiltinTopicData type 
 */
OMG_DDS_API std::string topic_topic_name();

/** 
 * @brief  Publication topic name 
 *  
 * Topic name of the builtin dds::sub::DataReader for the 
 * dds::topic::PublicationBuiltinTopicData type 
 */
OMG_DDS_API std::string publication_topic_name();

/** 
 * @brief Subscription topic name 
 *  
 * Topic name of the builtin dds::sub::DataReader for the 
 * dds::topic::SubscriptionBuiltinTopicData type 
 */
OMG_DDS_API std::string subscription_topic_name();

} }  // namespace dds::topic
  • Reported: DDS-PSM-Cxx 1.0b2 — Fri, 15 Jul 2016 18:50 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

API corrections required to dds/core/Duration.hpp

  • Key: DDSPSMC11_-14
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The class Duration needs the following corrections:

    • Add missing operator!=
    • Replace type of member sec_ from uint32_t to int32_t.

    We also suggest adding the following implicit constructor that allows interchanging C++11 chrono types and Duration throughout the API:

        /**
     * @brief Allow implicit creation from std::chrono::duration
     *
     * For example:
     * \code
     * dds::core::cond::WaitSet waitset;
     * // ...
     * waitset.wait(std::chrono::seconds(1) + std::chrono::milliseconds(250));
     * \endcode
     *
     */
    template <typename Rep, typename Period>
    /* implicit */ Duration(const std::chrono::duration<Rep, Period>& duration)
        : sec_(static_cast<int32_t>(
              std::chrono::duration_cast<std::chrono::seconds, Rep, Period>(duration).count())),
          nsec_(static_cast<uint32_t>(
              (std::chrono::nanoseconds(duration) % 1000000000).count()))
    {
    }
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 13 Jul 2016 22:46 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

API correction required to dds/core/Time.hpp

  • Key: DDSPSMC11_-17
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The dds::core::Time structure declares the sec field as an int64_t, but in the DDS spec, Time is defined as: 

    struct Time_t {
long sec;
unsigned long nanosec;
};

    It should be replaced with int32_t.

  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 13 Jul 2016 18:12 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

API corrections required to dds/sub/AnyDataReader.hpp

  • Key: DDSPSMC11_-8
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    This class is missing most methods:

    • qos() — getter and setter
    • topic_name()
    • type_name()
    • subscriber()
    • operator== and !=
    • close()
    • retain()
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 13 Jul 2016 18:07 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

API does not provide functionality from the DomainParticipantFactory

  • Key: DDSPSMC11_-13
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:
    • There isn't a way to create DomainParticipants in disabled state, because there isn't a DomainParticipantFactory to set its EntityFactory policy.
    • There isn't a placeholder for extensions to the DomainParticipantFactoryQos.
    • There isn't any function that allows releasing global resources that in other APIs are contained in the DomainParticipantFactory.

    Proposed solution:

    • Create dds::domain::qos::DomainParticipantFactoryQos in a new file, dds/domain/qos/DomainParticipantFactoryQos.hpp}}
    • Add the following static methods to the DomainParticipant
      TDomainParticipant.hpp
          /**
     * @brief Set the 
     * dds::domain::qos::DomainParticipantFactoryQos
     *  
     * @param qos The DomainParticipantFactoryQos to set.
     */
    static void participant_factory_qos(
       const dds::domain::qos::DomainParticipantFactoryQos& qos)
    {
        DELEGATE::participant_factory_qos(qos);
    }

    /**
     * @brief Get the current dds::domain::qos::DomainParticipantFactoryQos
     *  
     * @return The current DomainParticipantFactoryQos 
     */
    static dds::domain::qos::DomainParticipantFactoryQos participant_factory_qos()

    /**
     * @brief Finalize the DomainParticipantFactory. 
     *  
     * The DomainParticipantFactory is a singleton that the C++ API 
     * uses implicitly to create participants. This operation allows releasing any memory allocated by this singleton.
     *
     */
    static void finalize_participant_factory();
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 13 Jul 2016 17:57 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

Correction required to dds/sub/ddssub.hpp

  • Key: DDSPSMC11_-9
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    Missing include: 

    + #include <dds/sub/discovery.hpp>
  • Reported: DDS-PSM-Cxx 1.0b2 — Thu, 21 Jul 2016 22:04 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

API correction required to dds/topic/TBuiltinTopic.hpp

  • Key: DDSPSMC11_-11
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    Missing const qualifier for TTopicBuiltinTopicData::key():

    Resolution:

    - const dds::topic::BuiltinTopicKey& key();
+ const dds::topic::BuiltinTopicKey& key() const;
  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 18 Jul 2016 22:03 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

Selector missing next_instance() function

  • Key: DDSPSMC11_-16
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The Selector class is missing the following member function:

    Selector& next_instance(const dds::core::InstanceHandle& h)

    Note that ManipulatorSelector does have it.
  • Reported: DDS-PSM-Cxx 1.0b2 — Thu, 14 Jul 2016 23:06 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

Declaring Reference::operator new() private causes undesired side effects

  • Key: DDSPSMC11_-10
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    Reference makes the new operator private to disallow dynamic allocation for reference types.

    However, this makes some compilers unable to find the placement-new operator (operator new (size_t, void*)), whose usage is still valid (for example, in STL containers):

    /local/VxWorks/GPP-3.6/gnu/4.1.2-vxworks-6.6/sun4-solaris2/bin/../../lib/gcc/../../include/c++/4.1/xmemory:37: error: no matching function for call to 'dds::core::TEntity<rti::core::Entity>::operator new(unsigned int, void*&)'
../../../hpp/dds/core/Reference.hpp:184: note: candidates are: static void* dds::core::Reference<DELEGATE>::operator new(size_t) [with DELEGATE = rti::core::Entity]

    We haven't found yet a solution other than not making new private.
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 13 Jul 2016 23:54 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

Generic InstanceHandle constructor should be explicit

  • Key: DDSPSMC11_-5
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    Replace:

    dds/core/TInstanceHandle.hpp
      template <typename ARG0>
  TInstanceHandle(const ARG0& arg0);

    with:

      template <typename ARG0>
  explicit TInstanceHandle(const ARG0& arg0);

    An implicit constructor like that one indicates the compiler that it can implicitly convert any type to InstanceHandle, which severely interferes with the compiler's template substitution procedures and error reporting.

  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 19 Sep 2016 16:59 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

Method SampleInfo::valid() should be renamed SampleInfo::valid_data()

  • Key: DDSPSMC11_-2
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    There are several reasons for this:

    (1) The DDS-PIM defines the information in the SampleInfo as a "valid_data" flag therefore when mapped to the C++ PSM the same name should be retained.

    (2) This is consistent with the other PSMs.

    (3) Semantically SampleInfo::valid() is incorrect. The SampleInfo is always valid. What is invalid is the associated SampleData. Hence the correct name would be SampleInfo::valid_data()
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 13 Jul 2016 23:07 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

API corrections required to ManipulatorSelector and related functions

  • Key: DDSPSMC11_-6
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The free-standing functions read() and take() should not be templates.

    They are meant to be passed as function pointers to the streaming ManipulatorSelector API:

    dr >> read >> ... >> loaned_samples;

    This syntax is not possible with the current definition of read() and take(), because they require an explicit template argument.

    Proposed solution:
    Remove the template argument, but leave a dummy argument to avoid users passing in any no-argument function.

    DataReader.hpp
    -  template <typename SELECTOR>
-  SELECTOR& read(SELECTOR& selector);
+  OMG_DDS_API
+  bool read(dds::sub::ReadModeDummyType);

-  template <typename SELECTOR>
-  SELECTOR& take(SELECTOR& selector);
+  OMG_DDS_API
+  bool take(dds::sub::ReadModeDummyType);
    TDataReader.hpp
    +class ReadModeDummyType {};

…

-  ManipulatorSelector
-  operator >> (ManipulatorSelector& (manipulator)(ManipulatorSelector&));
+        ManipulatorSelector&
+        operator >>(bool(*manipulator)(ReadModeDummyType))
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 13 Jul 2016 17:41 GMT
  • Updated: Sun, 30 Sep 2018 23:27 GMT

Dispose for topics without key

  • Key: DDS15-243
  • Status: open  
  • Source: Central Research Laboratory, Bharat Electronics Ltd ( Saurabh Bansal)
  • Summary:

    Behavior of dispose is not specified for topics without key.
    As per section "2.2.1.2.2 Overall Conceptual Model",. If no key is provided, the data set associated with the Topic is restricted to a single instance.

    If data set is considered as a single instance than dispose of that instance shall be possible.

  • Reported: DDS 1.4 — Wed, 19 Sep 2018 17:08 GMT
  • Updated: Thu, 20 Sep 2018 17:58 GMT

Use of Stateful versus Stateless Endpoints

  • Key: DDSIRTP23-135
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification defines two reference implementations for RTPS Readers and Writers:

    • Stateless Writer (section 8.4.8)
    • Stateless Reader (section 8.4.11)
    • Stateful Writer (section 8.4.9)
    • Stateful Reader (section 8.4.12)

    Section 8.4.3 (Implementing the RTPS Protocol) indicates that it is an implementation decision whether to have the implementation match either the "Stateful" or "Stateless" reference behaviors. There are tradeoff with regards to the scalability and resources that may dictate which is preferable. But it does not impact interoperability.

    While that is true, there are still some observable behavioral differences that users have encountered and been surprised by.

    For example a BestEffort StatelessReader can add to the ReaderCache samples that arrive out of order. If the Reader has PRESENTATION access_scope=INSTANCE and the out of order samples are for different instances then they can be received by DDS.

    A BestEffort StatefulReader will drop the out of order sample when this happens.

    The problem is that in some cases the users are sensitive to this difference in behavior. This is specially a problem for best-efforts when you mix samples that require fragmentation with some not requiring fragmentation. In this case a later "non-fragmented" sample can arrive ahead of a fragment in the "fragmented sample", or be prioritized by the receiver stack ahead of the re-assembly...

    Because of this there is a desire to be able to somehow indicate or configure the use of a Stateless Reader versus a StatefulReader. This does not mean the user's require that there is a portable configuration mechanism (e.g via DDS Qos) rather that they know that all implementations will provide some means to configure it.

    A possible way to address this would be to add a sub-section to 8.4.15 (Implementation Guidelines) that discusses the selection of Stateful versus Stateless readers, especially for the best-effort case, and recommends that the choice is configurable using the DDS layer.
  • Reported: DDSI-RTPS 2.2 — Thu, 6 Sep 2018 19:01 GMT
  • Updated: Thu, 6 Sep 2018 21:36 GMT

Errors in non-normative IDL of section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types

  • Key: DDSRPC11-2
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    Section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types cotntains the following IDL:

    @Choice @Autoid
struct RobotControl_command_Result { 
    RobotControl_command_Out result;
};@Choice @Autoid
struct RobotControl_stop_Result { 
    RobotControl_getSpeed_Out result;
};
};@Choice @Autoid
struct RobotControl_setSpeed_Result {
      RobotControl_setSpeed_Out result;
      TooFast toofast_ex;
};
};@Choice @Autoid
struct RobotControl_getSpeed_Result {
      RobotControl_getStatus_Out result;
};

    This IDL is not correct. It contains extra "};" preceding the @Choice annotations in several places.

    In Addition in IDL42 all annotations are lower case. Specifically @autoid is defined there.

    Therefore the correct IDL would be:

    @choice @autoid
struct RobotControl_command_Result { 
    RobotControl_command_Out result;
};

@choice @autoid
struct RobotControl_stop_Result { 
    RobotControl_getSpeed_Out result;
};

@choice @autoid
struct RobotControl_setSpeed_Result {
      RobotControl_setSpeed_Out result;
      TooFast toofast_ex;
};

@choice @autoid
struct RobotControl_getSpeed_Result {
      RobotControl_getStatus_Out result;
};
  • Reported: DDS-RPC 1.0 — Thu, 6 Sep 2018 00:04 GMT
  • Updated: Thu, 6 Sep 2018 00:04 GMT

set_expression_parameters on ContentFilteredTopic, MultiTopic

  • Key: DDS15-242
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    When expression parameters change, should any data stored in associated DataReaders be re-evaluated using the new parameters? Or do the DataReaders reflect the state of the parameters at the time the data was received?
  • Reported: DDS 1.4 — Wed, 22 Aug 2018 20:27 GMT
  • Updated: Wed, 22 Aug 2018 20:27 GMT

Clarify when a dispose or unregister may be omitted for a Reader

  • Key: DDS15-241
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    If a writer disposes an instance that it never sent to a reader, should it still send the dispose to the reader?

    In general sending it would cause an scalability problem. So it would be better not to.

    However there are cases where it may be needed. For example if a Writer sets an alarm and a different writer that never created it wants to dispose it.

    Perhaps this behavior something is something that should be configurable on the Reader or Writer.
  • Reported: DDS 1.4 — Wed, 8 Aug 2018 15:25 GMT
  • Updated: Wed, 8 Aug 2018 17:47 GMT

Add restrictions and guidelines that are required when writing GROUP coherent sets

  • Key: DDS15-238
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    RTPS 2.4 added support for GROUP ordered access and coherent access. As part of this effort, a number of restrictions and guidelines were identified that should be added to DDS in order to properly support these features.

    The restrictions include:

    • Writers shall not be created and/or deleted from the time a GROUP Publisher called begin_coherent_changes() to end_coherent_changes()
    • Readers belonging to a subscriber with PRESENTATION access_scope=GROUP must all have the same value for DESTINATION_ORDER, RELIABILITY?, DURABILITY, OWNERSHIP
    • Writers belonging to a Publisher with PRESENTATION access_scope=GROUP should have the same value for OWNERSHIP, DURABILITY, RELIABILITY?, DESTINATION_ORDER?
      • With OWNERSHIP: kind (i.e. all SHARED or all EXCLUSIVE) and in the case they are exclusive all Writers must have value of the the same OWNERSHIP_STRENGTH.
    • All samples in the coherent set should have the same reception_timestamp and source_timestamp:
      • If access_scope = GROUP the reception and source timestamp are equal to that of the EndCoherentChanges sample.
      • If access_scope < GROUP the reception and source timestamp correspond to the ones from the last sample in the coherent set which may or may not be the EndCoherentChanges sample.

    Guidelines:

    • Adding a note for users that it may often be required to change the HISTORY kind/depth from KEEP_LAST,1. This is because a publisher that is quickly publishing coherent sets which update the same instances could very easily invalidate a coherent set that has not been fully delivered to the subscribers. Replacing a sample in history that is part of a coherent set invalidates that coherent set. It may be worth adding a callback that is called when a writer removes a coherent set from its queue
      • In general, writers that are part of a GROUP Publisher should be configured homogeneously.
  • Reported: DDS 1.4 — Fri, 20 Jul 2018 16:55 GMT
  • Updated: Fri, 20 Jul 2018 17:49 GMT

Add resource limits related to coherent changes

  • Key: DDS15-239
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    RTPS 2.4 added support for GROUP ordered access and coherent access. It may be useful to consider adding some resource limits specifically associated with coherent sets.
    For example, limiting the maximum number of samples that can be outstanding per DataReader and per Subscriber.

    These resource limits would help to prevent a (potentially ill-intentioned) Writer from filling up the entire reader queue with a never-ending coherent set since the reader must store the coherent set until it is complete.

  • Reported: DDS 1.4 — Fri, 20 Jul 2018 16:58 GMT
  • Updated: Fri, 20 Jul 2018 17:49 GMT

How to handle some GROUP ordered Subcriber scenarios

  • Key: DDS15-237
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    When using a GROUP ordered Subscriber, how do you access the samples in the order in which they are produced? The DDS1.4 specification says the following thing about this:.

    "If the PRESENTATION QosPolicy of the Subscriber to which the DataReader belongs has the access_scope set to ‘GROUP.’ This operation should only be invoked inside a begin_access/end_access block. Otherwise it will return the error PRECONDITION_NOT_MET. Depending on the setting of the PRESENTATION QoS policy (see 2.2.3.6), the returned collection of DataReader objects may be a ‘set’ containing each DataReader at most once in no specified order, or a ‘list’ containing each DataReader one or more times in a specific order.

    1. If PRESENTATION access_scope is INSTANCE or TOPIC the returned collection is a ‘set.’
    2. If PRESENTATION access_scope is GROUP and ordered_access is set to TRUE, then the returned collection is a ‘list.’
      This difference is due to the fact that, in the second situation it is required to access samples belonging to different DataReader objects in a particular order. In this case, the application should process each DataReader in the same order it appears in the ‘list’ and read or take exactly one sample from each DataReader. The patterns that an application should use to access data is fully described in 2.2.2.5.1, Access to the data."

    The big question here is: what happens when the user does not follow this scenario exactly? Here is a couple of potential deviations from the described scenario:

    1. Reading more than one sample from every listed reader (i.e. use read/take with max_samples > 1)
      • We could state that no matter what the size of max_samples is, you get one sample at max.
    2. Reading/Taking samples with different sample/view/instance state masks than passed to the get_datareaders() call.
    3. Reading/Taking samples from a different reader than next one in the reader list.
    4. you invoke get_datareaders() before having fully iterated through the previous reader list.

    We should specify what happens if an application (intentionally or non-intentionally) does not follow the scenario laid out in the spec, or we should come up with an alternative reading mechanism that does not allow you stray off the correct path in these ways for example by introducing new function calls.
  • Reported: DDS 1.4 — Fri, 6 Jul 2018 19:34 GMT
  • Updated: Fri, 6 Jul 2018 19:34 GMT

Request/Offered behavior of DURABILITY Qos does not match use-cases

  • Key: DDS15-236
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DURABILITY Qos is defined as Request/Offered. If a DataWriter offers a kind, the DataReader 'request' kind must be 'less or equal'. Otherwise they will not match, for this comparison it is considered that
    VOLATILE < TRANSIENT_LOCAL < TRANSIENT < PERSISTENT.

    This is not intuitive to users and does not match many of the use-cases observed in practice.

    What users expect is for a DataWriter to configure its durability without impact on the matching (very much like HISTORY). The setting would just control whether the DataWriter keeps a local copy of the data for late joiners and whether it sends the data to the persistence services.

    The reader in the other hand should simple state whether it wants "historical data" meaning data that was published before the reader joined the domain. This could just be a "boolean" or maybe a boolean plus some extra information that controls how much "historical data" to get.

    If the DataWriter enabled durability then it would get the data that the DataWriters have on their "historical cache" that includes data from the Persistence services.

    If a DataWriter set DURABILITY to TRANSIENT or PERSISTENT, then it would send its data to the PERSISTENCE services. It it was 'TRANSIENT LOCAL" then the Persistence service would not match the writer.

    Ideally this could be done as an extension so it has minimal impact in current behavior or interoperabiity
  • Reported: DDS 1.4 — Tue, 27 Mar 2018 20:09 GMT
  • Updated: Tue, 27 Mar 2018 20:09 GMT

Incorporate common elements from DDS Security to the Builtin Topics

  • Key: DDS15-234
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    DDS Security added information to the builtin-topic data.
    Some if this information is generic and not specific to DDS Security. An example of this is DataTags. Even if those are things DDS Security can associate permissions with, the tags themselves are generic and would make sense for any DDS implementation.

    The purpose of this issue is to identify those "generic" additions made by DDS Security and incorporate them to the DDS specification.
  • Reported: DDS 1.4 — Wed, 7 Mar 2018 19:02 GMT
  • Updated: Wed, 7 Mar 2018 19:02 GMT

DDS DLRL Issue: Clarify behavior of a Composition

  • Key: DDSDLRL-2
  • Legacy Issue Number: 10998
  • Status: closed  
  • Source: OCI ( Don Busch)
  • Summary:

    Add a new subsection:

    8.1.3.2.3 Compositions

    o A composition implies cascading deletion. When the owning object is deleted, the composed (i.e. owned) object is also deleted. When the owning object is deleted, its composed objects must also be present in the same CacheAccess so they too can be deleted. Failure to do this will result in a PreconditionNotMet exception on the ObjectRoot::destroy() call.

    o A composed (i.e. owned) object may only have one owner. Any attempt to set an owned ObjectRoot on two different owning object will result in a PreconditionNotMet exception

    Modify 8.1.6.3.14 ObjectRoot, by adding to the descriptions of the relevant operations:

    destroy: If the object has composition relations, all composed objects must be present in the CacheAccess. Otherwise, a PreconditionNotMet is thrown.

    set_attribute: If the attribute is a composition relation, the composed object must not be owned by any other object. Otherwise, a PreconditionNotMet is thrown.
  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:
  • Updated: Mon, 12 Feb 2018 19:07 GMT

DDS DLRL Issue: Clarification on the use of a Set in a DLRL Query

  • Key: DDSDLRL-1
  • Legacy Issue Number: 10995
  • Status: closed  
  • Source: OCI ( Don Busch)
  • Summary:

    In a DLRL Query, there are [] operators to access members of a collection. For a Set, is the [] operator used to determine whether the value is in the set or not? Or does a "contains" operator need to be added to the query language?
  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:
  • Updated: Mon, 12 Feb 2018 19:05 GMT

Add DataTagQosPolicy

  • Key: DDS15-208
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS Security specification (see 7.2.5) added a DataTagQosPolicy defined as:

    @extensibility(APPENDABLE)
struct Tag {
    string name;
    string value;
};

typedef sequence<Tag> TagSeq;

@extensibility(APPENDABLE)
struct DataTags {
    TagSeq tags;
};

typedef DataTags DataTagQosPolicy

    This is actually a generic policy that does not require DDS Security. It makes sense even without security as a way to associate tags with DataWriters and DataReaders.

    Therefore it would be better to move that definition to the DDS specification. This is a user-visible API that is expected to be explicitly set. If it is not part of the DDS API than applications would not be directly portable between DDS and DDS security.

    The spec should also define values for DATATAG_QOS_POLICY_NAME and DATATAG_QOS_POLICY_ID. For example:

     const string DATATAG_QOS_POLICY_NAME = "DataTag";
 const QosPolicyId_t  DATATAG_QOS_POLICY_ID = 25;

    Note that currently DDS-XTYPES defines IDs 23 and 24. Probably XTYPES should have used numbers in a different range so the IDs in DDS could remain contiguous.

    See also DDS15-209.
  • Reported: DDS 1.4 — Thu, 18 Jan 2018 23:05 GMT
  • Updated: Thu, 18 Jan 2018 23:14 GMT

Define ranges of QosPolicyId_t

  • Key: DDS15-209
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    DDS defines values of QosPolicyId_t from 0 to 22. Other specs (e.g. XTYPES) define additional values (23 and 24) and vendors potentially also define values.

    To avoid confusion and collision DDS should allocate ranges for each of these. For example:
    0-499 for DDS
    500-999 for Other OMG specs
    1000- for vendor extensions.

    If we go with this proposal we need to file an issue with XTYPES to change the policy ID values to to the reserved range for "other specifications"
  • Reported: DDS 1.4 — Thu, 18 Jan 2018 23:13 GMT
  • Updated: Thu, 18 Jan 2018 23:13 GMT

Add name attribute to Entity

  • Key: DDS15-50
  • Legacy Issue Number: 10807
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    For system management it is very useful that Entities can be identified by a logical application defined name. This attribute should ideal be set via the factory create call but if changing API's is not desired it can also be set via a QoS policy. This attribute should also be supported by the built-in Topics

    Solution:
    Introduction of a new Properties QoS that can be used for a name, but also for other things. The new QoS would contain a sequence of "properties" where each property is a pair of strings:
    (property_name, property_value)
    This Properties QoS can be used very much the same as the USER_DATA, but because each property is named, multiple things can be stored without conflicting with each other. This also provides an extensibility mechanism for the DDS spec. We can reserve the property-names with the prefix "DDS." To indicate "built-in" properties that should not be used by applications.
    We can use this mechanism with the built-in property name "DDS.EntityName" to implement the name attribute.
  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Wed, 17 Jan 2018 02:48 GMT

Schema appears to be missing root element

  • Key: DDS4CCM11-15
  • Status: open  
  • Source: JHU/APL ( Michael Leatherman)
  • Summary:

    The document seems to missing the dds element at the very end of the schema.

    Probably OBE, but the 1.0 version of the PDF also is missing the element. In the xsd version of the 1.0 spec, the root element is dds_ccm, which doesn't match the XML File Syntax section (page 46 of the version 1.0 PF).

    Finally, the XSD download for 1.1 is not working when I click on the link on http://www.omg.org/spec/DDS4CCM/1.1/ Only the UML document is available in the informative machine consumable documents section.

    Thanks.
  • Reported: DDS4CCM 1.1 — Fri, 8 Dec 2017 07:09 GMT
  • Updated: Thu, 4 Jan 2018 16:40 GMT

Invalid domain_id tag used in multiple sections of the spec

  • Key: DDSSEC11-19
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The following sections are incorrectly using the "domain_id" instead of "domains":

    • 9.4.1.2.4.1 Domains element: "This element is delimited by the XML element <domain_id>."
    • 9.4.1.2.7 Example Domain Governance document (non normative)
      ... "<domain_id>0</domain_id>" ...
    • 9.4.1.3.2.3.1.1 Domains Section: "This Section is delimited by the XML element <domain_id>."
  • Reported: DDS-SECURITY 1.0 — Fri, 2 Sep 2016 14:38 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    *Correct XML tag <domain_id>. Should be <domains> *

    Replace <domain_id> with <domains> in 9.4.1.2.4.1, 9.4.1.2.7, and 9.4.1.3.2.3.1.1
  • Updated: Tue, 19 Dec 2017 20:03 GMT

No mechanism to free ParticipantSecurityAttributes or EndpointSecurityAttributes

  • Key: DDSSEC11-112
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    get_participant_sec_attributes, get_datawriter_sec_attributes, and get_datareader_sec_attributes return ParticipantSecurityAttributes and EndpointSecurityAttributes.

    These attributes contain PropertySeq, which needs to be allocated. So the Access Control plugin is responsible for allocating the SecurityAttributes, but there's no mechanism to deallocate them.

    The DDS core could possibly deallocate them, but for consistency, the Access Control plugin should do that job.

    There should be functions return_participant_sec_attributes, return_datawriter_sec_attributes, return_datareader_sec_attributes that take the attributes and return boolean.
  • Reported: DDS-SECURITY 1.0 — Mon, 10 Jul 2017 13:46 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add return_participant_sec_attributes, return_datawriter_sec_attributes, return_datareader_sec_attributes

    This proposal will add return_participant_sec_attributes, return_datawriter_sec_attributes, return_datareader_sec_attributes.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Clarify whether governance settings for a DataWriter and a DataReader must be consistent for a match to occur

  • Key: DDSSEC11-38
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not clarify what happens in a situation where a DataReader governance specifies one thing (e.g. Encrypted Payload) and the DataWriter governance something else (e.g. signing only).

    It may be advisable to consider this as some kind of "Qos mismatch" that prevents the DataWriter from matching the DataReader. Either way the behavior needs to be clearly spelled out.

    Furthermore currently the DataWriter does not send to the DataReader its Governance, nor any information regarding the crypto transformations applied. This would seem a weakness that could be exploited.

    When processing the submessage payload the DataReader could apply its local governance. Since it knows it is supposed to be encrypted/signed and who the DataWriter is it can then use the cryptphandle for that DataWriter. So in this case it seems like we should enforce matching only DataWriters that have a "compatible" treatment of the serialized payload. But to do this we should know at matching time whether the DataWriter intends to encrypt/sign or not.

    When processing a submessage "SEC_PREFIX" we do not know who the sender was... So we do not know how to treat it, all we can do is try to decrypt it. But after that is done it should verify that the GUID of the DataWriter is consistent with the datawriter_cryptohandle used to decrypt the message.

    Similarly we need some mechanism to enforce the governance of the discovered endpoints. Basically if a Topic should be sent via secure discovery but it is received via the regular discovery then it should be rejected. Implementing this would require a "is_discovery_protected" EndpointSecurityAttributes (see DDSSEC11-16)
  • Reported: DDS-SECURITY 1.0 — Wed, 19 Oct 2016 15:01 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define PID for Sending Endpoint Security Attributes

    This will define a new PID for sending the Endpoint Security attributes, so it is possible to do endpoint matching decisions based on the attributes.

    Note: current specification defines is_payload_protected. If this proposal is to be accepted, we will need to create an issue for that.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Clarify conditions for calling the operations on AccessControlPlugin

  • Key: DDSSEC11-14
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Table 21 (Description of the ParticipantSecurityAttributes) entry on "ParticipantSecurityAttributes :is_access_protected" mentions allowing matching of participants without having "authorization" from the AccessControl. This is underspecified. It should state what this means in terms of the access control plugin operations are called (or not called) and how their return values are handled.

    Specifically. Is register_matched_remote_participant still called? Is validate_remote_permissions still called?

    Conceptually saying ParticipantSecurityAttributes::is_access_protected=FALSE only means we allow open access to the DomainId, but that does not imply open access to all the Topics...

    This fact is implied by the rules in 8.8.7 (AccessControl behavior with remote domain entity discovery) which permit "Unauthenticated" participants to only join domains that have ParticipantSecurityAttributes::is_access_protected=FALSE but only read/write the topics with EndpointSecurityAttributes::is_access_protected==FALSE.
  • Reported: DDS-SECURITY 1.0 — Tue, 24 May 2016 01:11 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes to Clarify the Behavior of the AccessControl Plugin with Different Participant Security Attributes

    This will clarify how the Participant and Endpoint Security interact with the plugins behavior.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

begin_handshake_request in the IDL Not Consistent with the Main Document

  • Key: DDSSEC11-118
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In the DDS Security, Table 18 – Authentication plugin interface, begin_handshake_request is defined as:

    (empty) ValidationResult_t
    out: handshake_handle HandshakeHandle
    out: handshake_message HandshakeMessageToken
    initiator_identity_handle IdentityHandle
    replier_identity_handle IdentityHandle
    serialized_local_participant_data octet[]
    exception SecurityException

    However, in the normative IDL, is defined as:

                ValidationResult_t
                begin_handshake_request(
                    inout HandshakeHandle        handshake_handle,
                    in    HandshakeMessageToken  handshake_message_out,
                    in    HandshakeMessageToken  handshake_message_in,
                    in    IdentityHandle         initiator_identity_handle,
                    in    IdentityHandle         replier_identity_handle,
                    in    OctetSeq               serialized_local_participant_data,
                    inout SecurityException      ex );

    This is, the IDL has two issues:

    • "in HandshakeMessageToken handshake_message_in" should be removed
    • "in HandshakeMessageToken handshake_message_out" should be marked as inout and renamed "handshake_message"
  • Reported: DDS-SECURITY 1.0 — Thu, 13 Jul 2017 13:02 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Fix Inconsistent begin_handshake_request in the IDL

    This will cover changes in IDL to be consistent with the document.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Add the concept of "data origin authentication" and clarify what DDS-Security provides

  • Key: DDSSEC11-115
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 4 of the spec (Terms and Definitions) should be expanded to include these additional definitions.

    Data Integrity
    Assurance that data has not been altered since creation time.

    Data Origin Authentication
    A mechanism providing assurance that a party is corroborated as the source of specified data (it includes data integrity).

    Message Authentication
    An alternative term for Data Origin Authentication.

    Section 7.1 says that Securing DDS means providing "Non-repudiation of data" instead it should say "data-origin authentication"
  • Reported: DDS-SECURITY 1.0 — Wed, 12 Jul 2017 22:06 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Clarify Data Origin Authentication versus Non-Repudiation

    In Section 4 (Terms and Definitions) add definitions for: Data Integrity, Data Origin Authentication, and Message Origin Authentication.

    In Section 7.1 (Security Model) list also Message-origin and Data-origin authentication. Indicate that Non-repudiation may be optional.

    In Section 9.2 (Requirements and Priorities (Non-Normative)) change "Message integrity and authentication" to "Message integrity and data-origin authentication"
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Unclear Effectiveness of is_rtps_protected=true allow_unauthenticated_participants=true

  • Key: DDSSEC11-111
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Current specification allows for creating a participant with is_rtps_protected=true and allow_unauthenticated_participants=true.

    According to "Table 21 – Description of the ParticipantSecurityAttributes - is_rtps_protected":

    If is_rtps_protected is TRUE then:
    (1) The DDS middleware shall call the operations on the CryptoKeyFactory for the DomainParticipant.
    (2) The DDS middleware shall call the operations on the CryptoKeyExchange for matched DomainParticipants that have been authenticated.
    (3) The RTPS messages sent by the DomainParticipant to matched DomainParticipants that have been authenticated shall be transformed using the CryptoTransform operation encode_rtps_message and the messages received from the matched authenticated DomainParticipants shall be transformed using the CryptoTransform operation decode_rtps_message.

    In particular, I want to focus on (3). According to current specification, we should accept a not-signed RTPS message coming from an unauthenticated participant, independently of the "is_rtps_protected" value. I think this impacts the effectiveness of just using "is_rtps_protected". This is because it allows for an attacker to inject any RTPS message by properly tampering the GUID if that GUID has not been authenticated yet (at the very minimum, it enables for a time window that allows for injecting anything, until that GUID is actually authenticated).

    I want to bring this up so we can discuss if this is actually the behavior we want (if this is the case, we should document the scenario I described above somewhere), or if is_rtps_protected=true should be incompatible with allowing unauthenticated participants. If that is the case, the alternative secure configuration would be to protect submessages themselves (by signing them).
  • Reported: DDS-SECURITY 1.0 — Mon, 10 Jul 2017 13:41 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Duplicates DDSSEC11-14 and its resolution (DDSSEC11-126)

    Duplicates DDSSEC11-14 (and its already handled by its resolution DDSSEC11-126)
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Specify Authentication Challenge Length

  • Key: DDSSEC11-52
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Table 38 – HandshakeRequestMessageToken for the builtin Authentication plugin specifies the challenge as:

    A Random Challenge generated by the Participant,
compliant with the recommendations of Section 3.2.1 of
FIPS-196 [46]

    This is currently underspecified, as it does not impose restrictions to the challenge length. This can lead to vendor interoperability issues. In order to avoid these issues, the DDS-SECURITY specification should specify alength for DDS-SECURITY 1.0 interoperability. Proposal: 256 bits.

    NOTE: In https://tools.ietf.org/html/rfc5246 page 90 that for TLS 1.2, the challenge_length is between 16 and 32 bytes.

    Per the resolution of http://issues.omg.org/browse/DDSSEC_-114 it was established that challenges should contain 32 bytes of randomness so the proposal is to specify that the challenge shall be exactly 32 bytes.
  • Reported: DDS-SECURITY 1.0 — Thu, 23 Feb 2017 23:19 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes in Specification to Specify a Challenge Length and Fixing Typo

    Define changes according to DDSSEC11-52.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Clarify the receiver-specific MACs described in the Table 57 decode operations

  • Key: DDSSEC11-58
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Table 57, the language in decode_rtps_message and decode_datawriter_submessage should be made more consistent with the language in decode_datareader_submessage. For example, decode_datawriter_submessage mentions receiver_specific_mac_key_id and master_receiver_specific_mac_key, but those terms are not mentioned anywhere else in the specification.

    Proposal:

    decode_datareader_submessage: "receiver_specific key_id" is missing an underscore. It should be "receiver_specific_key_id".

    decode_datawriter_submessage: "receiver_specific_mac_key_id" and "receiver_mac_key_id" should be "receiver_specific_key_id". "master_receiver_specific_mac_key" should be "receiver_specific_macs".

    decode_rtps_message: "RemoteParticipant2ParticopantKeyMaterial" should be "RemoteParticipant2ParticipantKeyMaterial". "containe" should be "contained". Add "If the RemoteParticipant2ParticipantKeyMaterial specified a receiver_specific_key_id different from zero, then the operation shall check that the received SecureRTPSPostfixSubMsg contains a non-zero length receiver_specific_macs element containing the receiver_specific_key_id that is associated with local and remote CryptoHandles and use it to verify the submesage. If the receiver_specific_key_id is missing or the verification fails, the operation shall fail with an exception."
  • Reported: DDS-SECURITY 1.0 — Tue, 7 Mar 2017 14:25 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes to Table 57

    Perform the changes proposed in the issue description.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Missing Mechanism for Detecting Incompatibilities in ParticipantSecurityAttributes

  • Key: DDSSEC11-137
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In DDSSEC11-38 (modified by DDSSEC11-72, and DDSSEC11-106) we introduced a mechanism for detecting inconsistencies in the EndpointSecurityAttributes.

    We are still missing an equivalent mechanism for detecting inconsistencies in the ParticipantSecurityAttributes.
  • Reported: DDS-SECURITY 1.0 — Mon, 31 Jul 2017 10:51 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define PID for Sending Participant Security Attributes

    This will define the a new PID for sending the local participant security attributes to the remote participant. This way, we enable for early detection of incompatibilities (such as encrypting discovery in one side, and just doing signing in the other).
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Use of Non-Existing Submessage SecureSubMsg and Flag MultiSubmsg

  • Key: DDSSEC11-39
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS Security FTF changed some aspects of the construction of submessages eliminating SecureSubMsg and the MultiSubmsg flag. However some of the old language was not removed from the specification. Because of these there a re some sections that need to be modified as they do not completely make sense the way they are written now.

    Note that SecureSubMsg and the use of the MultiSubmsg were eliminated by the FTF and they were replaced by the combination of newly created submessage: SecurePrefixSubMsg, SecurePostfixSubmsg, SecureRTPSPrefixSubmsg, SecureRTPSPostfixSubmsg and SecureBodySubMsg.

  • Reported: DDS-SECURITY 1.0 — Sun, 13 Nov 2016 17:46 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    *Correct use of Non-Existing Submessage SecureSubMsg and Flag MultiSubmsg *

    Per the issue description, the following sections need to be corrected:

    Remove references to SecureSubMsg and replace with SecureBodySubMsg in:

    • Multiple places in: 7.3.6.2 RTPS Submessage: SecureSubMsg
    • 7.3.7.5.1 Wire Representation (the submessageId is wrong).
    • 8.5.1.9 : multiple places, see MultiSubmsg below
    • 8.8.10: multiple places, see MultiSubmsg below

    Remove references to MultiSubmsg and replace with the use of prefix/body/postfix pattern in:

    • 8.5.1.9.6 Operation: preprocess_secure_submsg: this needs to be modified to explain it now uses a prefix.
    • 8.5.1.9.7 Operation: decode_datawriter_submessage: this needs to be modified to explain that it now uses a SecurePrefixSubMsg.
    • 8.5.1.9.8 Operation: decode_datareader_submessage: this needs to be modified to explain that it now uses a SecurePrefixSubMsg.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

FIPS-196 reference to wrong chapter

  • Key: DDSSEC11-23
  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    Random Challenge recommendations are stated to be in non-existent Section 3.2.1 of FIPS-196.
    The correct Section is perhaps 3.1.2 (Random numbers).
  • Reported: DDS-SECURITY 1.0 — Mon, 3 Oct 2016 08:53 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Modify FIPS-196 reference to NIST Special Publication 800-90A

    Modify section 9.3.2.3 replacing the reference to a random number generation in FIPS-196 with a reference to the generation of a NONCE from NIST Special Publication 800-90A section 8.6.7
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Wrong Facility Value for Logging Plugin

  • Key: DDSSEC11-48
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    According to the DDS Security specification (9.6 Builtin Logging Plugin), the facility value for the BuiltinLoggingType must be 0x10 (16 in decimal):

    octet facility; // Set to 0x10. Indicates sec/auth msgs
LoggingLevel severity;

    However, according to the Syslog RFC 6.2.1. PRI (https://tools.ietf.org/html/rfc5424):

       Facility and Severity values are not normative but often used.  They
   are described in the following tables for purely informational
   purposes.  Facility values MUST be in the range of 0 to 23 inclusive.
[...]
             10             security/authorization messages
[...]
             16             local use 0  (local0)

    It defines 10 (0x0a) as the value for security/auth messages.
  • Reported: DDS-SECURITY 1.0 — Tue, 7 Feb 2017 00:58 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes in Specification to correct logging facility

    Changes in Specification to correct logging facility as per DDSSEC11-48
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Need to specify format of SubjectName used for adjusted_participant_key

  • Key: DDSSEC11-47
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This is regarding the DDS Security spec Table 41 validate_local_identity “The 47 bits following the first bit (bits 1 to 47) shall be set to
    the 47 first bits of the SHA-256 hash of the SubjectName appearing on the identity_credential”.

    The format of the SubjectName is not specified. It should say “The 47 bits following the first bit (bits 1 to 47) shall be set to the 47 first bits of the SHA-256 hash of the ASN.1 DER encoding of the SubjectName [40] appearing on the identity_credential”, where [40] is https://tools.ietf.org/html/rfc5280, which is already in the References section.

    Section 4.1.2.6 and Appendix C.2 of the RFC are the most relevant sections.
  • Reported: DDS-SECURITY 1.0 — Wed, 7 Dec 2016 18:01 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes in Specification to Specify SubjectName Format

    This will define the changes to the specification according to DDSSEC11-47.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Should differences in EndpointSecurityAttributesMask prevent matching?

  • Key: DDSSEC11-106
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    http://issues.omg.org/browse/DDSSEC11-38 introduced an EndpointSecurityAttributesMask that is propagated by Discovery within the PublicationBuiltinTopicData and SubscriptionBuiltinTopicData. This has the bit fields:

    is_access_protected	
is_discovery_protected	
is_submessage_protected	
is_payload_protected	
is_keyhash_obfuscated	
is_liveliness_protected

    So a participant only knows that a remote participant will "protect" the payload. But not the details of the protection. This is consistent with the fact that at the PIM level the DDS core only knows whether it needs to call the "encods_serialized_data" but not what this call does. It is the detail of a specific plugin (in our case the builtin ones) that has the knowledge of the SIGN versus ENCRYPT 'protection kinds'

    Currently the specification does not say whether matching should be allowed between endpoints that have different EndpointSecurityAttributesMask. This should be clarified.

    Moreover it seems it would not be possible with the current mechanisms to enforce that if a DataReader expects ENCRYPT, then it should get that rather than just SIGN. In principle this is something that could be enforced by the check_local_dataXXX_match operations. But it does not appear they get the information they need to make that determination.
  • Reported: DDS-SECURITY 1.0 — Wed, 5 Jul 2017 18:41 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define Mechanism for Matching Plugin Specific Attributes

    Define Mechanism for Matching Plugin Specific Attributes.

    Proposal: reserve a set of opaque bits on the endpoint security attributes mask to be used by security plugins.

    Also we are fixing in this issue an inconsistency between DDSSEC11-38 and DDSSEC11-72 (is_key_protected).

    NOTE: not adding information about origin_authentication as it should not prevent endpoint matching.
    Why is that? If the governance states that a Topic should have origin authentication I may be reasonable for a Reader to insist on that. Otherwise any data it accepts from that DataWriter would lack that and it would defeat the purpose of the configuration in the governance.
    I thought we wanted the writer to decide, but I see your point, I'm adding it
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

dds_security_plugins_spis.idl has inheritance commented out

  • Key: DDSSEC11-96
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The inheritance relations for some of the structures dds_security_plugins_spis.idl appear in comments. See for example declaration of struct DomainParticipantQos:

            struct DomainParticipantQos { // : DomainParticipantQos {
            PropertyQosPolicy  property;
        }; //@Extensibility (MUTABLE_EXTENSIBILITY)

    In addition the syntax for the annotations is the legacy "comment-style" rather that the more modern "annotation style".

    To correct this the above declaration should be replaced with:

            @extensibility(MUTABLE)
        struct DomainParticipantQos : DDS::DomainParticipantQos {
            PropertyQosPolicy  property;
        };

    The same kind of changes should be applied to other declarations in the IDL.
  • Reported: DDS-SECURITY 1.0 — Thu, 1 Jun 2017 03:02 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Use explicit inheritance for BuitinTopics

    The issue is broader. The problem is that the syntax does not comply with IDL 4.1 or XTYPES 1.2.
    In addition to the use of IDL inheritance, the syntax of the IDL should be updated to:
    (1) Use the modern annotations @annotationName(anotationParam) rather than the syntax that places annotations in a comment
    (2) Use the IDL4.1/XTYPES 1.2 annotation names which are all lower case
    (3) Include http://www.omg.org/spec/DDS-XTypes/20170301/dds-xtypes_discovery.idl instead of dds_rtf2_dcps.idl this has more up-to-date definitions of the Qos and builtin topics.
    (4) Add definition of DomainId_t which is not in dds-xtypes_discovery.idl
    (5) Remove the keyword "local" ahead of interface declaration. In IDL41 "local" interfaces are in the CORBA building block.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Apply sha256 to derived shared secret

  • Key: DDSSEC11-49
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently, section 9.3.2.3.2 says

    If the value of the c. kagree_algo property is “DH+MODP-2048-256”, then:
    • The Diffie-Hellman Public Key shall be for the 2048-bit MODP Group with 256-bit Prime Order Subgroup, see IETF RFC 5114 [47], section 2.3.
    • The Key Agreement Algorithm shall be the “dhEphem, C(2e, 0s, FFC DH) Scheme” defined in section 6.1.2.1 of NIST Special Publication 800-56A Revision 2 [48].
    Non-normative note: The OpenSSL 1.0.2 operation DH_get_2048_256() retrieves the parameters for the 2048-bit MODP Group with 256-bit Prime Order Subgroup.
    If the value of the c.kagree_algo property is “ECDH+prime256v1-CEUM”, then:
    • The Diffie-Hellman Public Key shall be for the NIST’s EC Curve P-256 as defined in appendix D of FIPS 186-4 [42] also known as prime256v1 in ANSI X9.62-2005 [41].
    • The Key Agreement Algorithm shall be the “(Cofactor) Ephemeral Unified Model, C(2e, 0s, ECC CDH)” defined in section 6.1.2.2 of NIST Special Publication 800-56A Revision 2 [48]. See also section 3.1 “Ephemeral Unified Model” of NIST Suite B Implementer’s Guide to NIST SP 800-56A [49].

    There's nothing wrong with this specification, but not all cryptography APIs provide a straightforward way of obtaining the raw bytes of a derived shared secret. Some APIs, such as the Microsoft Cryptography API: Next Generation (CNG), force you to compute a hash of the shared secret before obtaining the raw bytes of the hash. BCryptSecretAgreement outputs an opaque BCRYPT_SECRET_HANDLE, which you then pass into BCryptDeriveKey, which also takes a hash algorithm and outputs raw bytes. So in order to accommodate such APIs, the specification should state that a SHA-256 hash shall be applied to the derived shared secret.
  • Reported: DDS-SECURITY 1.0 — Wed, 22 Feb 2017 19:15 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes in Specification to apply SHA256 to DH shared secret

    Specify changes to specification according to DDSSEC11-49
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Correct Figure 9 to match description of the authentication protocol

  • Key: DDSSEC11-41
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The description of the authentication protocol in 8.3.2.7 states that when a step in the authentication fails the plugin should revert back to the state it was before. This prevents a third party from interfering with the authentication and making it fail.

    However Figure 9 (Authentication plugin interaction state machine) does not show that. Instead it shows the state machine transitioning to the Final State. This should be corrected.
  • Reported: DDS-SECURITY 1.0 — Mon, 21 Nov 2016 16:44 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Update Figure 9 (Authentication plugin interaction state machine)

    Update Figure 9 to show that failure of any step does not exit the state machine. Rather the state reverts to the previous one. The state machine is exited only on a successful authentication or on a timeout.

    Add additional states to handle the VALIDATION_PENDING_RETRY return from the operations on the Authentication plugin.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Remove duplicate of RTPS message inside the security envelope

  • Key: DDSSEC11-40
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently securing the RTPS message requires duplicating the RTPS header between the SecurePrefix and the SecureSuffix in order to be able to encrypt and sign.

    This may be useful when encryption is needed as it wold allow to put a "fake" RTPS header and obscure the content of the real one.

    However when we are signing only having the INFO_SOURCE seems an unnecessary duplication as it would be sufficient to include the existing RTPS in the computed MAC.

    To implement this it would be enough to add a flag to the SecurePrefix that indicates that the SecureSuffix MAC is done all the way from the beginning of the RTPS message (i.e. including the RTPS header).

    However this would break interoperability with any applications that do not understand this new flag...

    The only approach I can think of that does not break interoperability would be to add the flag to the SecureSuffix and include both signatures. One that does not include the RTPS header (for legacy applications) and one that does. The problem is that this would add the extra computation (and size) of the second signature which seems more expensive than just adding the INFO_SOURCE...
  • Reported: DDS-SECURITY 1.0 — Mon, 21 Nov 2016 16:29 GMT
  • Disposition: Closed; No Change — DDS-SECURITY 1.1
  • Disposition Summary:

    Not worth doing as it would break backwards interoperability

    The RTF task force decided it was not worth breaking backwards interoperability in order to gain what seems like fairly minimal performance.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

VALIDATION_PENDING_CHALLENGE_MESSAGE

  • Key: DDSSEC11-25
  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    Table 41 suggests begin_handshake_request/reply returning VALIDATION_PENDING_CHALLENGE_MESSAGE, and states it shall be used to determine when to call process_handshake.
    This value is not part of the return type (ValidationResult_t).
    8.3.2.9.4 states that the operations use the other ValidationResults.
  • Reported: DDS-SECURITY 1.0 — Fri, 30 Sep 2016 08:34 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Correct VALIDATION_PENDING_CHALLENGE_MESSAGE

    See issue description.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Normative IDL does not match the documentation for Auth::validate_remote_identity

  • Key: DDSSEC11-21
  • Status: closed  
  • Source: Kongsberg Geospatial ( Gilles Bessens)
  • Summary:

    In the normative IDL, validate_remote_identity's signature suggests it receives IdentityHandles for the initiator of and the replier to a handshake.
    This implies that this has been resolved by the middleware before calling Auth to initiate the sequence.
    In the specification document, however, the function instead receives IdentityHandles for the local and remote principal, moving the resolution to the plugin.
    The latter makes more sense, but to enforce this specification of the interface, the IDL has to be altered.
  • Reported: DDS-SECURITY 1.0 — Tue, 6 Sep 2016 10:28 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Fix validate_remote_identity on IDL and Document to be Consistent

    This will apply the changes described in DDSSEC11-21
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Normative IDL does not match documentation for Authentication::validate_remote_identity

  • Key: DDSSEC11-22
  • Status: closed  
  • Source: Kongsberg Geospatial ( Gilles Bessens)
  • Summary:

    In the normative IDL, validate_remote_identity's signature suggests it receives IdentityHandles for the initiator of and the replier to a handshake.
    This implies that this has been resolved by the middleware before calling Auth to initiate the sequence.
    In the specification document, however, the function instead receives IdentityHandles for the local and remote principal, moving the resolution to the plugin.
    The latter makes more sense, but to enforce this specification of the interface, the IDL has to be altered.
  • Reported: DDS-SECURITY 1.0 — Tue, 6 Sep 2016 10:14 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Duplicates DDSSEC11-21

    Duplicates DDSSEC11-21
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Inconsistent Behavior for Secure Volatile Endpoints

  • Key: DDSSEC11-27
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:
    Description:

    Secure Volatile Endpoint’s Endpoint Security Attributes are not defined by the spec. According to 9.5.2.1 DDS:Crypto:AES-GCM-GMAC CryptoToken, the encryption of the Secure Volatile Endpoint’s payload (the key material) is done by calling to encode_serialized_payload operation as part of “create_local_xxx_crypto_tokens(cryptoTokens /* out /)”. *This is inconsistent with the rest of endpoints, which will do encryption for the payload or submessages depending on the value of Endpoint Security Attributes.

    Additionally, current content is inconsistent with 8.8.8.1 Key generation for the BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader, which details the key material needed for securing the channel. This is inconsistent, because current specification is not securing the channel, is just sending encrypted crypto tokens that have been encrypted in create_local_xxx_crypto_tokens, and decrypting them during the set_remote_xxx_crypto_tokens.

    Proposal (see DDSSEC11-28):
    • Change Secure Volatile endpoint definition to follow same encryption process than the rest of endpoints, being the only difference that the key material used is derived from the SharedSecret (as defined in 8.8.8.1 Key generation for the BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader):
      • Secure Volatile endpoints will be consistent with the rest of endpoints.
      • Logic for create_local_xxx_crypto_tokens and set_remote_xxx_crypto_tokens will be simplified.
    • Also protect the submessage metadata. Currently the specification only protects the CryptoToken this makes it vulnerable to someone attacking a participant by sending wrong hearbeats or NACKs on the Volatile Endpoint since the HB and NACKS are only protected if metadata is protected. For this reason Secure Volatile endpoint definition should specify metadata_protection_kind=ENCRYPT and data_protection_kind=NONE that way we protect both meta data and data with a single operation which is more efficient.
  • Reported: DDS-SECURITY 1.0 — Wed, 5 Oct 2016 11:10 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define Secure Volatile Endpoint Attributes and Simplify create_local_xxx_crypto_tokens and set_remote_xxx_crypto_tokens

    General proposal:

    • Define Secure Volatile endpoint attributes to follow same encryption process than the rest of endpoints, being the only difference that the key material used is derived from the SharedSecret (as defined in 8.8.8.1 Key generation for the BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader):
      • Secure Volatile endpoints will be consistent with the rest of endpoints.
      • Logic for create_local_xxx_crypto_tokens and set_remote_xxx_crypto_tokens will be simplified.
    • Also protect the submessage metadata. Currently the specification only protects the CryptoToken this makes it vulnerable to someone attacking a participant by sending wrong hearbeats or NACKs on the Volatile Endpoint since the HB and NACKS are only protected if metadata is protected. For this reason Secure Volatile endpoint definition should specify metadata_protection_kind=ENCRYPT and data_protection_kind=NONE that way we protect both meta data and data with a single operation which is more efficient.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Handling expiration of Permissions or Certificates during operation

  • Key: DDSSEC11-110
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    The Permissions document includes a validity range (not-before + not-after). Also, PKI certificates (used for identification) have an expiration date.

    The standard should address what happens when, during the course of operation, either of these expiration dates are passed. That is, 1) a peer is discovered and authenticated and permissions are validated; 2) time passes such that either or both (permission and/or certificate) expiration date/s pass/es.

    Two possible approaches:

    • Do nothing - that is, matched and validated entities continue to communicate uninterrupted.
    • Enforce expiration - The middleware periodically checks expiration dates and terminates communication when things expire.
    • There are probably other approaches.

    It is likely that the details are not important to interoperability, and can be left to the vendor.

  • Reported: DDS-SECURITY 1.0 — Sun, 9 Jul 2017 17:18 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Merge with DDSSEC11-82

    This issue is related to DDSSEC11-82 so it makes sense to handle both together
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Non-Recoverable Communication After Authentication Session Terminated

  • Key: DDSSEC11-81
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    After two participants are mutually authenticated and authorized, each participant's session with the remote participant (certificate, shared secret, challenge1, challenge2...) may be terminated/removed at a certain time for various reasons such as:

    • Automatic termination: sessions should have a max lifetime to follow best security practices, to handle the fact that the remote participant's certificate may expire, be revoked, etc. and therefore no longer trusted (worst case scenario: the issuing CA (or any ancestor) cert expires/is revoked).
    • Administrative termination: some administrator decides to force the session termination because of a security alert or for debugging purposes.

    If the session is terminated on one side but not on the other, we end up in the same deadlock situation as in DDSSEC11-43 (scenario 1 and 2) except the root cause is not liveliness loss but simple automatic/administrative session termination.
  • Reported: DDS-SECURITY 1.0 — Sat, 20 May 2017 16:26 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Close as duplicate of DDSSEC11-43

    This will be handled with DDSSEC11-43
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Additional typos/inconsistencies

  • Key: DDSSEC11-85
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Several inconsistencies remain in the document:

    The document uses the terms " MasterReaderSpecificKey" and "MasterReceiverSpecificKey" to refer to the same key. Should rename one of the two. It would be better to keep MasterReceiverSpecificKey to be consistent with the name used for other keys, such as, SessionReceiverSpecificKey.

    Section 9.5.3.3.4.2 second paragraph starts: "Note that the built cipher operations..." The "built" word should be removed.

    The word: "operationg" is mis-spelled 5 times. Should be replaced with "operating"

    The words "AES-GMAC operation" appear 3 times in the spec. The more correct term would be "AES-GMAC transformation"

    Section 9.5.3.3.5 mentions a CryptographicSessionHandle three times. This is undefined. This really refers to the appropriate crypto handle (ParticipantCryptoHandle, DatawriterCryptoHandle, or DatawriterCryptoHandle).

    To fix this replace the first occurrence of "CryptographicSessionHandle" with "crypto handle (ParticipantCryptoHandle, DatawriterCryptoHandle, or DatawriterCryptoHandle)" and the remaining two occurences with "crypto handle"

    The IDL in the specification is still not using IDL 4.1 format. The following changes should be applied:
    @Extensibility (EXTENSIBLE_EXTENSIBILITY) -> @extensibility (APPENDABLE)
    @Extensibility (MUTABLE_EXTENSIBILITY) -> @extensibility (MUTABLE)

    Paragraph in section 9.4.1.2.4.6 (RTPS Protection Kind element) is in the wrong section
    The paragraph:

    This setting controls the contents of the ParticipantSecurityAttributes returned by the AccessControl::get_participant_sec_attributes operation on the DomainParticipant. Specifically the is_liveliness_protected attribute in the ParticipantSecurityAttributes shall be set to FALSE if and only if the value of the <liveliness_protection_kind> element is NONE.


    Appears in the wrong section. It should be moved to the end of 9.4.1.2.4.5 (Liveliness Protection Kind element)

    The numbered items in section 9.4.1.2.4 (Domain Rules) are missing one item. A new item numbered shown below should be inserted ahead of the current 6 (Topic Access Rules Section, containing topic rules).
    6. RTPS Protection Kind Element

    Provide the means to force strict parsing/formatting of the Governance file. See comments on DDSSEC11-114.

    The resolution of DDSSEC11-114 only addressed the strict formatting of the permissions file, not the governance file. To address the latter the AccessControl plugin should have an additional property "dds.sec.access.enable_strict_governance_formatting" with possible values "true" or "false". This property shuld be added ton 9.4.1(Configuration), Table 48 (Properties used to configure the builtin AccessControl plugin).

    The text in the newly added (by DDSSEC11-114) sections 9.4.1.2.5.9 Unknown elements in the domain rules and 9.4.1.2.5.9 Unknown elements in the topic rules would also need to change to say that this configured in the plugin, not controlled by the <enable_strict_permission_formatting>.element in the Governance file.

    In sections 9.4.1.2.5.9 (Unknown elements in the domain rules) and 9.4.1.2.6.8 (Unknown elements in the topic rules) the last paragraph in the section (see below) is wrong and should mention a configuration of the plugin instead:

    As specified in 9.4.1.2.5.7, unknown elements are only allowed if the governance file has set the Enable Strict Permissions Formatting element to FALSE.


    In 8.5.1.9.3 last paragraph, change receiving_datawriter_crypto_list.length with Length(receiving_datawriter_crypto_list)


    In section 7.4.1.5 after table 13 add IDL representation of the PublicationBuiltinTopicData and SubscriptionBuiltinTopicData

            @extensibility(MUTABLE)
        struct PublicationBuiltinTopicDataSecure  :  DDS::PublicationBuiltinTopicData {
	    @id(0x1003)  DataTags data_tags;
        };

        @extensibility(MUTABLE)
        struct SubscriptionBuiltinTopicDataSecure  :  DDS::SubscriptionBuiltinTopicData {
	    @id(0x1003)  DataTags data_tags;
        };


    In many of the tables there are "out" parameters, such as the exception that are not marked as such. They should be corrected.


    DDSSEC11-17 added enable_liveliness_protection but the XSD was not updated accordingly. To correct, in
    in section 9.4.1.2.3 "Domain Governance document format" in the Governance XSD under, under<xs:complexType name="TopicRule">, change from: 

                <xs:element name="enable_discovery_protection" type="xs:boolean" />

    To:

                <xs:element name="enable_discovery_protection" type="xs:boolean" />
            <xs:element name="enable_liveliness_protection" type="xs:boolean" />

    Also make that change to machine readable Governance XSD file

    Already applied
    Issue 88 changed all the BuiltinTopicKey_t to be GUID_t. However it missed some changes, partially because the resolution of Issue#21 added some parameters that thought have also been renamed by 88. As a consequence the following additional changes are needed:

    • Global replace of remote_participant_key with remote_participant_guid in the specification document
    • Global replace of local_participant_key with local_participant_guid in the specification document
    • Global replace of "local participant_key" with local_participant_guid in the specification document
    • Global replace of participant_key with participant_guid in the specification document
    • Replace replace of BuiltinTopicKey_t with GUID_t in the machine readable IDL dds_security_pugin_spis.idl operation validate_remote_identity
    • Global replace of remote_participant_key with remote_participant_guid in the machine readable IDL dds_security_pugin_spis.idl
  • Reported: DDS-SECURITY 1.0 — Fri, 26 May 2017 15:55 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Address identified typos and inconsistencies

    Apply the changes suggested in the issue description.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Unnecessary Additional Authenticated Data in common_mac

  • Key: DDSSEC11-70
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Current specification defines the followin additional authenticated data when calculating the common_mac:

    • In encode_serialized_payload() the Additional Authenticated Data is empty (9.5.3.3.4.4).
    • In encode_datawriter/reader_submessage the Additional Authenticated Data contains the 4 Bytes in the SEC_SUB_MSG (9.5.3.3.4.5)
    • In encode_rtps_message the Additional Authenticated Data contains the 4 Bytes in the SEC_SUB_MSG (9.5.3.3.4.6)

    It is not clear that this additional step is providing a real gain. We should discuss if we want to change the specification to use an empty additional data in all cases.
  • Reported: DDS-SECURITY 1.0 — Tue, 11 Apr 2017 11:32 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Change Specification to Use Empty AAD

    Change the specification to use an empty AAD.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Handling large numbers of receiver-specific MACs

  • Key: DDSSEC11-66
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The builtin crypto plugins sign messages with one MAC (common_mac) computed with a key shared with all the DataReaders followed by a sequence of MACs (receiver_specific_macs) each signed with a different key shared with only one DataReader.

    This approach ensures that a DataReader cannot impersonate the DataWriter and sign messages that other readers would validate as originating from the DataWriter.

    This approach results on two issues that need to be addressed:

    • Handling message sizes that approach/exceed the transport MTU
    • Handling large numbers of DataReaders

    The first problem appears because at the time the data sample is written by a DataWriter the DDS implementation needs to know how to fragment it. To do this is uses the known maximum transport MTU as well as knowledge of the overhead due to RTPS headers, etc. This overhead can take into consideration the extra DDS-Security sub-messages. However if the size if the signature depends on the number of matched DataReaders it is not possible to know it at the time the sample is written..

    The second problem appears when we have very large number of matched DataReaders. At some point the overhead of 32 bytes per remote reader starts being excessive in terms of both extra message size as well as the performance to compute each separate MAC.

    The specification should provide some means to handle these issues. A potential approach is this:

    • Allow the DataWriter to be configured with a maximum number of remoter_reader_macs. As long as the number of DateReaders does not exceed it the DataWriter will sign the message with each receiver-specific MAC. Given this maximum the system knows the maximum RTPS overhead and therefore when to fragment large messages.
    • If the number of matched DataReaders exceeds the specified maximum then the DataWriter has two possibilities:

    1. It could reuse the same MACs, that is, share the same receiver-specific Key with multiple DataReaders. This would allow certain reader to impersonate the DataWriter but it will only affect the other readers sharing the same receiver-specific key.

    2. Use a fast digital signature algorithm. This would keep the size of the message fixed and may have additional benefits for messages that are relayed by a persistence service or a routing service

    Looking at the literature of fast digital-signature algorithms one that seems popular is Ed25519. See https://ed25519.cr.yp.to/
  • Reported: DDS-SECURITY 1.0 — Tue, 4 Apr 2017 21:20 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Allow an Endpoint to configure a maximum number of "receiver-specific" MACS

    Specify that a DataWriter can be configured with a maximum number of receiver_specific_macs. As long as the number of matched DateReaders does not exceed it the DataWriter will sign the message with each receiver-specific MAC. Given this maximum the system knows the maximum RTPS overhead and therefore when to fragment large messages.

    If the number of matched DataReaders exceeds the specified maximum then the DataWriter can share the same receiver-specific MACs for more than one reader. This weakens origin authentication. Alternatively the DataWriter could use a different strategy (e.g. send the message multiple times, each limited to the maximum number of receiver_specific_macs) as long as it does not impact interoperability wit receivers that are not aware of this strategy.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Inconsistent format for Starting and End Dates in Validity Section

  • Key: DDSSEC11-62
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The format of the validity section specified in sub clause 9.4.1.3.2 and 9.4.1.4 are inconsistent with the format specified by the XSD in sub clause 9.4.1.3.

    Conformance to the "xs:dateTime" format requires changes in sub clauses 9.4.1.3.2.2 and 9.4.1.4, but the changes in 9.4.1.4 were already covered by the resolution of DDSSEC11-26.
  • Reported: DDS-SECURITY 1.0 — Wed, 29 Mar 2017 00:37 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Duplicate of DDSSEC11-6

    The problems described in this issue can be solved in DDSSEC11-6.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Specify a transformation_kind for BuiltinParticipantVolatileMessageSecure Endpoints

  • Key: DDSSEC11-53
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Table 52 - KeyMaterial_AES_GCM_GMAC for BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader defines the following two values for transformation_kind:

    • CRYPTO_TRANSFORMATION_KIND_AES128_GCM
    • CRYPTO_TRANSFORMATION_KIND_AES256_GCM

    This can lead to vendor interoperability issues. The DDS-SECURITY specification should specify one transformation_kind.

    Proposal: use CRYPTO_TRANSFORMATION_KIND_AES256_GCM
    otherwise we would potentially send AES256 keys protected with 128-bit encryption which makes little sense.
  • Reported: DDS-SECURITY 1.0 — Thu, 23 Feb 2017 23:21 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes in Specification to Specify a Transformation Kind in Table 52

    Specify changes according to DDSSEC11-53.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Wrong description of max_blocks_per_session

  • Key: DDSSEC11-60
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Table 58 max_blocks_per_session mentions SessionSalt and SessionHMACKey, which no longer exist. They should be replaced by SessionReceiverSpecificKey.
  • Reported: DDS-SECURITY 1.0 — Tue, 7 Mar 2017 14:30 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Table 58: replace SessionSalt and SessionHMACKey by SessionReceiverSpecificKey.

    Perform the changes suggested in the Issue description
  • Updated: Tue, 19 Dec 2017 20:03 GMT

check_local_*_match publisher/subscriber partition not present in IDL

  • Key: DDSSEC11-34
  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    8.4.2.6 and 8.4.2.6.13 make mention of the publisher/subscriber partition as parameters for the check_local_datawriter_match and check_local_datareader_match functions.
    This parameter is not present in the IDL, and is not covered in 9.4.3 (Table 48).
  • Reported: DDS-SECURITY 1.0 — Tue, 4 Oct 2016 09:05 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add Missing parameters to check_local_(datawriter/datareader)_match APIs

    This will implement changes described in DDSSEC11-34

    In addition, we are adding DataTagsQos to the writer & reader qos, to make those symmetric to the info propagated to the wire. This way we can also get rid of tags as parameters in these APIs.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

AccessControl behavior does not show check_local_datawriter/reader_match operations

Need a way to determine the builtinTopic used for the DataWriter automatic liveliness

  • Key: DDSSEC11-17
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    As described in 7.4.2 DDS-RTPS defines a the builtin ParticipantMessage topic used to carry two types of Liveliness messages:

    DDS-Security (section 7.4.2) defines a ParticipantMessageSecure that is used to securely send liveliness data messages.

    The Liveliness messages pertain two types of liveliness

    • DataWriter Automatic Liveliness
    • DataWriter Manual by Participant Liveliness

    According to section 7.4.2 both the ParticipantMessage and the ParticipantMessageSecure builtin endpoints should be created but it is not clear whether for a specific DataWriter the liveliness messages should be sent over both or just one of them and if so which...

    This will affect interoperability between vendors and also between an application using DDS-Security and one that is not.

    The specification should clarify this.
  • Reported: DDS-SECURITY 1.0 — Tue, 24 May 2016 02:45 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Apply the modifications suggested in the issue description and comments

    (1) If the Liveliness is "manual by Topic" then liveliness uses Hearbeat submessages associated with the regular DataWriter/DataReader channel so the protection is derived from the DataWriter meta-dataprotection kind. There is no other way to do this.

    (2) If the Liveliness is "manual by Participant" or "automatic" then we would use the ParticipantMessage or ParticipantMessageSecure. In this case we could derive the behavior from the <enable_discovery_protection> setting on the Governance or add a <enable_liveliness_protection>.

    For (2) it seems that tying the selection of the liveliness channel to the enable_discovery_protection would defeat having separate settings for <discovery_protection_kind> and <liveliness_protection_kind> so if we wanted that we should consolidate those two into single setting. So we would need to come up with some common concept for "discovery" and "liveliness" which is not so obvious what that would be.

    Because of this it seems the simplest and most transparent would be to add a <enable_liveliness_protection> under <topic_rule>, and its associated is_liveliness_protected attribute under EndpointSecurityAttributes.

    Also, we are adding a is_liveliness_protected attribute under ParticipantSecurityAttributes, so the "Liveliness Protection Kind" governance element has a clear mapping to a Participant attribute. We do this in a way that is consistent to other mappings (e,g., as the mapping for RTPS protection kind to is_rtps_protected).
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Inconsistent IDL encode_serialized_data and decode_serialized_data

  • Key: DDSSEC11-123
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Document:

    encode_serialized_payload
    (empty) Boolean
    out: encoded_buffer octet[]
    out: extra_inline_qos octet[]
    plain_buffer octet[]
    sending_datawriter_crypto DatawriterCryptoHandle
    out: exception SecurityException

    IDL:

                boolean
                encode_serialized_data(
                    inout OctetSeq                encoded_buffer,
                    in    OctetSeq                plain_buffer,
                    in    DatawriterCryptoHandle  sending_datawriter_crypto,
                    inout SecurityException       ex);

    Name should be changed in the idl to encode_serialized_payload, and we should add missing extra_inline_qos.

    Same issue for decode_serialized_data.
  • Reported: DDS-SECURITY 1.0 — Fri, 21 Jul 2017 08:52 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Change encode_serialized_data/decode_serialized_data in the IDL to be Consistent

    The IDL is wrong, we will fix it to match the rest of the specification.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Spec does not explain how t would use different keys for the encode_serialized_payload versus encode_serialized_submessage

  • Key: DDSSEC11-122
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The fact that we are calling encode_serialized_submessage on top of the result of encode_serialized_payload allows the use of different key material. This is in fact needed to support the relay mode.

    However the spec is confusing regarding this. In several places (e.g. register_local_datawriter in Table 55) and likewise in create_local_datawroter_cryptotokens seems to indicate that a single KeyMaterial is created.

    This should all be clarified so it is possible to use separate key material for the two operations.

    Seems like this should be stated in register_local_datawriter and register_matched_remote_datareader
  • Reported: DDS-SECURITY 1.0 — Tue, 18 Jul 2017 14:33 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Duplicates DDSSEC11-11 (and its resolution)

    This issue is already handled by the resolution of DDSSEC11-14 (DDSSEC11-126)
  • Updated: Tue, 19 Dec 2017 20:03 GMT

BuiltinTopicKey_t Inconsistent with current DDS Spec

  • Key: DDSSEC11-88
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    As also filed under http://issues.omg.org/browse/DDS15-153, current definition used by DDS-SECURITY for BuiltinTopicKey_t is inconsistent with current DDS specification.

    Changing BuiltinTopicKey_t definition would be risky, as multiple implementations may rely on what has been the standard for a long time.

    Also, at this point we should try to avoid changing the wire representation for DDS-SECURITY.

    As a solution that will not break compatibility, we can define a new GUID_t type that is an array of 16 octets, and use this one in the security specification.
  • Reported: DDS-SECURITY 1.0 — Mon, 29 May 2017 16:30 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Replace use of BuiltinTopicKey_t with GUID_t

    To avoid confusion the DDS-Security specification shall use the GUID_t type as defined by the DDS-RTPS specification, and not the BuiltinTopicKey_t.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Denial of Service Attack to DDS Security Participants by Injecting Participant Discovery Unregister&Dispose

  • Key: DDSSEC11-44
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    An attacker could do an easy Denial of Service attack by just injecting Participant Discovery Unregister&Dispose messages.

    Current DDS Security spec does not consider any mechanism to prevent this.

    Proposal

    This proposal allows for checking the authenticity of unregister&dispose messages at the same time that provides a secure way for changing local participant properties after authentication. The proposal is based in adding a new inline qos "PARTICIPANT_SESSION_SIGNATURE" to the Participant Discovery messages from secure participants.

    • The content of the inline qos will be:
      • Two fields for avoiding replay attacks:
        • A NONCE (c.nonce) set to a value generated upon local participant creation.
        • An epoch (c.epoch) incremented each time there is a change in the announced participant discovery information.
      • A signature generated using the private key of the participant. The signature is generated from the following input:
        • c.nonce
        • c.epoch
        • The info state for the sample.
        • (if the sample contains data) md5(c.pData)

    Upon reception of a Participant Discovery Message, and only if the remote participant is authenticated with us, the local participant will check if the received message would trigger a change in the properties or liveliness state of the remote participant. If the received message would trigger a change, the local participant will verify the signature using the certificate of the remote participant. If the verification fails, the message will be ignored. If the verification succeeds, the message will be parsed. In order to make this verification possible, the auth.plugin will expose three new APIs:

    • get_max_private_signature_size: get the max. size of a private signature.
    • private_sign: signs a set of bytes using the local participant private key.
    • verify_private_signature: verifies a set of bytes against a signature using the remote participant public certificate.

    Note: An operation private_sign is a bit too powerful. Would allow the application to sign anything it wants so it is not good practice. The operation should control what kind of data is signed so arbitrary bytes cannot be signed.

    Note that if the remote Participant is not authenticated, no additional checks are done and messages are just parsed as usual.
  • Reported: DDS-SECURITY 1.0 — Mon, 5 Dec 2016 12:05 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add a DCPSParticipantsSecure buitin Topic

    To address this issue the specification shall add a new builtin Topic to send the ParticipantBuiltinTopicData to authenticated applications. This shall be called the "DCPSParticipantsSecure" builtin Topic.

    After they authenticate the DomainParticipants will ignore data on the (unsecure) "DCPSParticipants" builtin Topic and only process ParticipantBuiltinTopicData data on the "DCPSParticipantsSecure" builtin Topic.

    This topic will be secured the same way as the other secure "discovery" topics.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Non Recoverable Communication After Asymmetric Liveliness Loss

  • Key: DDSSEC11-43
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    After two participants are mutually authenticated and authorized, there are two scenarios that could potentially lead to communication not to recover:

    Let's call the Participant sending token1 "requester" and the Participant sending token2 "replier".

    Scenario 1

    The "replier" participant removes the "requester" participant because of a liveliness loss, there is no way the system can recover:

    • Requester participant still knows about the replier (he did not lose the liveliness), so no AI for him.
    • Replier participant will wait for a request that will never arrive.
    Scenario 2

    The "requester" participant removes the "replier" participant because of a liveliness loss, there is no way the system can recover:

    • Requester participant sends periodic auth messages (token 1).
    • Replier participant still knows about the requester (he did not lose the liveliness), so no AI for him. , It just drop the messages he receives (as if they were duplicates for steps already done) by the replier.

    The problem is, there is no standardized mechanism for triggering a new "Figure 9 - Authentication plugin interaction state machine".

    Other Scenarios

    There may be other scenarios as described in DDSSEC11-81.

    Proposal

    Add a new mechanism that allow triggering the creation of a new Authentication state machine, as we do when we discover a remote participant. In order to do this in a secure way, we need to keep the old authentication session until this new state machine fully succeeds the authentication process. Also, we need to do this in a way an attacker cannot provoke a Denial of Service Attack by continuously triggering re-authentications.

    The proposal here is to solve these problem by adding a new "auth.req" message that asks the remote participant to create a new authentication state machine. If that authentication state machine succeeds, the old one will be replaced:

    • Add a new GMCLASSID (“dds.sec.auth.req”) so it is easly identified as a potential request of restarting the whole authentication process for a participant.
    • If processed (only if the remote participant is authenticated), this request will trigger the creation of a parallel state for a remote participant. This is, would be equivalent to receive discovery pData from new participant. It will therefore trigger the creation of a new authentication state machine.
    • Only if a whole authentication completes, the old remote participant state is removed and the new one triggers the authorization and all the remaining steps.
    • For the request, define a new HandshakeMessageToken ("DDS:Auth:PKI-DH:1.0+AuthReq") containing a NONCE.
    • That NONCE is the random number the Participant mean to use as part of the challenge process. This will be the same challenge will be used as part of the token1 (or token2) we send.
    • Received auth_request will be ignored by peers that are not authenticated with us.
    • Received auth_request will be processed by peers fully authenticated with us, used as a hint about the other remote participant could be willing to restart authentication.
    • Received NONCE will be compared against the random challenge we will receive in the next token1 (or token2). If that matches, means that the remote participant was the one generating the auth_request, so the authentication can continue. If it does not match, we will return VALIDATION_NOT_OK for that token.
    • If the authentication completes, we will remove old state and replace with new one.
    • In order to make the above possible, we need to move the generation of the local challenge to the validate_remote_identity step. That will be stored as part of the remote_identity_handle, so it can be used during the authentication process. Also, if the current state machine was triggered by the reception of an auth.request, we need also to store in the remote_identity_handle the "expected" remote challenge.
  • Reported: DDS-SECURITY 1.0 — Mon, 5 Dec 2016 11:06 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define New Authentication Request Mechanism

    This proposal will define a new Authentication Request mechanism for requesting for a re-authentication.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

get_endpoint_sec_attributes inconsistently specified

  • Key: DDSSEC11-36
  • Status: closed   Implementation work Blocked
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    IDL states that there exists one function: get_endpoint_sec_attributes.
    Table 23 lists get_datawriter_sec_attributes and get_datareader_sec_attributes separately.
    As does 8.4.2.6.23/24. (8.4.2.6.23 has a typo in the headline: "dataRwriter")
    Table 48 makes no mention of any of these functions.
  • Reported: DDS-SECURITY 1.0 — Tue, 4 Oct 2016 09:24 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Combine with DDSSEC11-16

    This issue affects the same APIs that are being refactored by DDSSEC11-16. Therefore it is best to merge it with that issue.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

AccessControl::check_create_topic( str_properties ) only present in IDL

  • Key: DDSSEC11-33
  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    The parameter "in Properties str_properties" is not covered in the specification document, yet is a parameter in the IDL interface.
  • Reported: DDS-SECURITY 1.0 — Tue, 4 Oct 2016 09:01 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Remove extra Properties parameter from check_create_topic in IDL file

    The IDL seems to be the one that is wrong as there the specification does not mention the "properties" parameter on the operation AccessControl::check_create_topic. Consequently the parameter should be removed in the IDL file.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

GUIDs for new builtin Topics do not comply with DDS-RTPS specification

  • Key: DDSSEC11-12
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    According to DDS-RTPS specification version 2.2 section 9.3.1.2 (Mapping of the EntityId_t) the last octet of the EntityId_t part of GUID for a builtin DataWriter and DataReader takes a specific value that depends on whether the builtin entity is used to send Topic whose data-type is keyed or unkeyed.

    RTPS uses the name EntityKind to refer to this last octet in the EntityId_t.
    According to Table 9.1 of the DDS-RTPS specification:

    • A builtin DataWriter of a keyed TopicType shall have EntityKind 0xc2.
    • A builtin DataReader of a keyed TopicType shall have EntityKind 0xc7.
    • A builtin DataWriter of a non-keyed TopicType shall have EntityKind 0xc3.
    • A builtin DataReader of a non-keyed TopicType shall have EntityKind 0xc4.

    This is inconsistent with some of the values defines in Table 9 ( section 7.3.7.1) of the DDS-Security 1.0 spec. In particular the following ones:

    • BuiltinParticipantStatelessMessageWriter has EntityKind 0xc2 but it should be 0xc3 because its TopicType has no key.
    • BuiltinParticipantStatelessMessageReader has EntityKind 0xc7 but it should be 0xc4 because its TopicType has no key.
    • BuiltinParticipantVolatileMessageSecureWriter has EntityKind 0xc2 but it should be 0xc3 because its TopicType has no key.
    • BuiltinParticipantVolatileMessageSecureReader has EntityKind 0xc7 but it should be 0xc4 because its TopicType has no key.
  • Reported: DDS-SECURITY 1.0 — Thu, 19 May 2016 02:36 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    *Correct EntityId_t for the builtin writers and readers of ParticipantStatelessMessage and ParticipantVolatileSecureMessage *

    See Issue description
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Wrong ValidationResult_t VALIDATION_OK_WITH_FINAL_MESSAGE Used In Multiple Places

  • Key: DDSSEC11-31
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The spec defines the retcode VALIDATION_OK_FINAL_MESSAGE in Table 19 and in http://www.omg.org/spec/DDS-SECURITY/20160303/dds_security_plugin_spis.idl.

    However, there are multiple uses of wrong VALIDATION_OK_WITH_FINAL_MESSAGE .
  • Reported: DDS-SECURITY 1.0 — Wed, 5 Oct 2016 13:34 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    *Replace VALIDATION_OK_WITH_FINAL_MESSAGE Occurrences with VALIDATION_OK_FINAL_MESSAGE *

    Replace the following VALIDATION_OK_WITH_FINAL_MESSAGE with VALIDATION_OK_FINAL_MESSAGE:

    • In Figure 9 – Authentication plugin interaction state machine.
    • In Figure 22 – Authentication sequence diagram with discovered DomainParticipant.
    • In 8.8.2.2 Behavior when allow_unauthenticated_participants is set to FALSE, step 11.
    • In Table 41 – Actions undertaken by the operations of the builtin Authentication plugin:
      • In "process_handshake on a handshake_handle created bybegin_handshake_request"
      • In "get_shared_secret"
      • In "get_authenticated_peer_credential_token"
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Inconsistent Definition of BuiltinLoggingType

  • Key: DDSSEC11-29
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    BuiltinLoggingType under Figure 20 – Logging Plugin Model (8.6.2 Logging Plugin Model) is not consistent with the IDL in 9.6 Builtin Logging Plugin.

    • facility is an octet in the IDL (a string in the figure).
    • hostname is a string in the IDL (a byte in the figure).
    • IDL contains a field appname. Figure contains procname.
    • procid is a string in the IDL (an int in the figure).
    • msgid is a string in the IDL (an int in the figure).

    Proposal:

    • Update the figure to be consistent with IDL.
  • Reported: DDS-SECURITY 1.0 — Wed, 5 Oct 2016 12:48 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Fix BuiltinLoggingType under Figure 20 – Logging Plugin Model To be Consistent with IDL

    In Figure 20 – Logging Plugin Model To be Consistent with IDL:

    • Change facility type to octet.
    • Change hostname type to string.
    • Replace procname with appname.
    • Change procid type to string.
    • Change msgid type to string.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

SecurityExceptionCode is undefined

  • Key: DDSSEC11-15
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Table 17 – SecurityException class uses the type SecurityExceptionCode without defining it anywhere.

    It seems like it should be defined as a long as it is a 'code' parallel to the 'minor code' which is defined as a long.

    Since SecurityExceptionCode only appears in this table the simples solution is to replace it with a long
  • Reported: DDS-SECURITY 1.0 — Tue, 24 May 2016 01:26 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Fix Table 17 SecurityException class

    Replace the undefined type 'SecurityExceptionCode' with 'long' in Table 17.

  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Participant's is_access_protected Functionality Overlaps with allow_unauthenticated_participants

  • Key: DDSSEC11-108
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In 8.8.6 AccessControl behavior with remote participant discovery, we state:

    If the ParticipantSecurityAttributes object returned by the AccessControl operation
    get_participant_sec_attributes has the is_access_protected attribute set to
    FALSE, the DomainParticipant may discover DomainParticipants that cannot be authenticated
    because they either lack support for the authentication protocol or they fail the authentication protocol.
    These “Unauthenticated” DomainParticipant entities shall be matched and considered
    “Unauthenticated” DomainParticipant entities.

    Also in 8.8.7.1 AccessControl behavior with discovered endpoints from “Unauthenticated” DomainParticipant:

    Note that, as specified in 8.8.2.2, a DomainParticipant for whom the
    ParticipantSecurityAttributes object returned by the AccessControl operation
    get_participant_sec_attributes has the is_access_protected attribute set to
    TRUE, cannot be matched with an “Unauthenticated” DomainParticipant and therefore cannot
    discover any endpoints from an “Unauthenticated” DomainParticipant.

    This is overlapping with allow_unauthenticated_participants. If allow_unauthenticated_participants, then we should allow for unauthenticated participants independently of is_access_protected. In fact, we will not call to any of the AccessControl (nor any other plugin) APIs for that unauthenticated participant.

    For authenticated participants, we should do all the checkings depending on the value for is_access_protected .
  • Reported: DDS-SECURITY 1.0 — Thu, 6 Jul 2017 13:33 GMT
  • Disposition: Duplicate or Merged — DDS-SECURITY 1.1
  • Disposition Summary:

    Duplicates DDSSEC11-14 (and its resolution)

    Duplicates DDSSEC11-14 (resolved as DDSSEC11-126)
  • Updated: Tue, 19 Dec 2017 20:03 GMT

EndpointSecurity's is_payload_protected is Insufficient

  • Key: DDSSEC11-72
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Current version of the specification defines is_payload_protected EndpointSecurity attribute. While this is useful for letting the DDS middleware know if it needs to call to security plugin operations for the payload, it is not giving information about the used protection (sign or encrypt).

    This information is needed by the DDS middleware to make a decision about the kind of KeyHash used (see 7.3.4 Mandatory use of the KeyHash for encrypted messages).
  • Reported: DDS-SECURITY 1.0 — Tue, 11 Apr 2017 12:16 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add is_key_protected

    This proposal will add a new EndpointSecurityAttribute: is_payload_obfuscated, so the middleware can take decisions regarding the format for the keyhash.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Confusing Sentence about Builtin Endpoints Payload Encryption

  • Key: DDSSEC11-55
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In the DDS-SECURITY specification, the following statement could lead to some confusion:

    9.4.1.2.4.4 Discovery Protection Kind element
The builtin endpoints shall never apply cryptographic transformations to the SecuredPayload
submessage element.

    The wording is not clear. It is suggesting that there should be a SecuredPayload submessage element whose contents are identical to the plaintext, i.e. not transformed.

    It should be changed to something like:

    • The builtin endpoints shall never apply payload-level cryptographic transformations.
  • Reported: DDS-SECURITY 1.0 — Thu, 23 Feb 2017 23:45 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Modify Confusing Sentence about Builtin Endpoints

    Change sentence to be more clear.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Permissions grant rule with no specified topic

  • Key: DDSSEC11-56
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    The Permissions XSD for the <allow_rule> and <deny_rule> elements allows for zero topics to be specified. In that case, does the rule match ANY topic or NO topics?
  • Reported: DDS-SECURITY 1.0 — Sun, 5 Mar 2017 19:46 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Modify description of permissions grant rules and XSD

    Make it clear that lacking <publish> Criteria, a rule does not match any topics names for publishing. Likewise lacking a <subscribe> Criteria a rule would match no topics for subscribing.

    These clarifications should be added to 9.4.1.3.2.3.1.2 (Publish Section) and 9.4.1.3.2.3.1.3 (Subscribe Section)

    Modify the XSD for the Permissions document to make the <topics> section mandatory within the <publish> and <subscribe> sections.

    This would impact the omg_shared_ca_permissions.xsd file.
    Also this affects the omg_shared_ca_permissions_example.xml in that the rule below is invalid:

                <allow_rule>
                <domains>
                    <id>0</id>
                </domains>
                <publish>
                </publish>
                <subscribe></subscribe>
            </allow_rule>

    This rule should be changed to remove the empty <publish> and <subscribe> elements. This change does not modify the meaning of the rule.

    In addition the copy of the example XML that appears in 9.4.1.4 (DomainParticipant example permissions document (non normative)) needs to also be updated.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Missing a Way to Pass Participant Data to begin_handshake_request and begin_handshake_reply

  • Key: DDSSEC11-46
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    We need to pass the local big-endian serialized ParticipantBuiltinTopicData to begin_handshake_request and begin_handshake_reply so that they can include it in the outgoing handshake message as c.pdata (DDS Security spec Tables 38 and 39).

    Proposal is to add a new input parameter to both begin_handshake_request and begin_handshake_reply. That parameter will consist on a buffer with the big endian CDR serialization of the participant data :

    serialized_participant_data octet[]
  • Reported: DDS-SECURITY 1.0 — Mon, 5 Dec 2016 12:46 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add serialized_participant_data to begin_handshake_request and begin_handshake_reply

    Add serialized_participant_data to begin_handshake_request and begin_handshake_reply
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

get_*_token should not return non-boolean values

  • Key: DDSSEC11-35
  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    Assuming all functions in the AccessControl interface should return a boolean value.

    get_permissions_token and get_permissions_credential_token:
    IDL states a boolean return value, which is also implied by 8.2.4.6.17/18. In both cases the Permissions*Token is an inout parameter.
    Table 23 claims the Permissions*Token is the returned value.

    validate_local_permissions and validate_remote_permissions:
    Stated to return a PermissionsHandle. This is consistent in all sources, so this is perhaps correct, but breaks the pattern.
  • Reported: DDS-SECURITY 1.0 — Tue, 4 Oct 2016 09:18 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Fix get__token in Table 23 To Be Consistent*

    This will move PermissionsToken and PermissionsCredentialToken to the list of regular parameters, and add boolean as return value.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Inconsisten ReturnCode NOT_ALLOWED_BY_SEC

  • Key: DDSSEC11-24
  • Status: closed  
  • Source: Kongsberg Defence & Aerospace ( Mr. Gilles Bessens)
  • Summary:

    NOT_ALLOWED_BY_SEC is not prefixed with "RETCODE_".
    This applies to both the IDL and the specification document.
  • Reported: DDS-SECURITY 1.0 — Mon, 3 Oct 2016 07:35 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Rename NOT_ALLOWED_BY_SEC with NOT_ALLOWED_BY_SECURITY

    The document will be changed so that return code NOT_ALLOWED_BY_SEC will be renamed to NOT_ALLOWED_BY_SECURITY.

    The machine-readable IDL file (dds_security_plugins_spi.idl) will be changed to that NOT_ALLOWED_BY_SEC will become RETCODE_NOT_ALLOWED_BY_SECURITY.

    This appears 6 times.

    • Once in the table of content
    • Twice in section 7.2.8
    • Three times in section 8.8.1
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Issue on DDS Security metamodel

Permissions XSD and XML files are inconsistent with normative machine readable file

  • Key: DDSSEC11-6
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The normative machine readable XSD file for the permissions document schema here is inconsistent with what is copied into section 9.4.3.1.

    • The root of the XSD document is the element "<dds>" whereas in section 9.4.1.3 and 9.4.1.4 this root is omitted and it jumps directly to the nested subelement "<permissions>."
    • The machine readable XSD is correct as this is also consistent with the format for the Governance file which also has "<dds>" as root.
    • Also the date format in the XSD file is inconsistent with the format that is used in sections 9.4.1.4 and 9.4.1.3.2.2.
  • Reported: DDS-SECURITY 1.0b1 — Fri, 25 Mar 2016 18:12 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Fixing inconsistencies with normative machine readable files

    This resolution addresses different inconsistencies between the normative machine readable files and the text of the specification.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Unify treatment of builtin endpoints with that of regular endpoints

  • Key: DDSSEC11-94
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The security specification introduces several new builtin endpoints, for secure discovery (DCPSPublicationsSecure, DCPSSubscriptionsSecure), secure liveliness (BuiltinParticipantMessageSecure), and Key Exchange (ParticipantVolatileMessageSecure).

    The behavior of these endpoints with regards to the security plugins is controlled by fields in the ParticipantSecurityAttributes, specifically is_discovery_protected and is_liveliness_protected.

    However the behavior of regular (application-defined) endpoints with regards to the security plugins is controlled by the value of the EndpointSecurityAttributes that are specific to each Endpoint.

    This difference in treatment complicates the specification as well as the implementation. It also limits what can be done with the builtin endpoints.

    A better solution would be to reuse the EndpointSecurityAttributes to specify the configuration of the builtin endpoints. This can be done by replacing the is_discovery_protected and is_liveliness_protected booleans with the EndpointSecurityAttributes fields for each type of endpoint as in:

    struct ParticipantSecurityAttributes {
    ....
    EndpointSecurityAttributes discovery_endpoint_attributes;
    EndpointSecurityAttributes liveliness_endpoint_attributes;
    ...
};

    That way the DDS core can treat the builtin endpoints as any other endpoint with regards to security.

    Note that this approach is already followed for the ParticipantVolatileMessageSecureMessage. Its behavior is specified in 7.4.4.2 given its EndpointSecurityAttributes which are hardcoded in the specification.
  • Reported: DDS-SECURITY 1.0 — Wed, 31 May 2017 23:38 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define the TopicSecurityAttributes for the secure builtin topics

    The cryptographic behavior of the secure builtin topics (for example DCPSPublicationsSecure) can be configured via existing elements in the DomainGovernance file. Clearly define how those elements impact the secure builtin topics.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Specify Endianness to be Used in Ciphertext

  • Key: DDSSEC11-54
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS-SECURITY specification is not specifying the endianness to use in the ciphertext. This can lead to interoperability issues.

    In particular:

    • "9.5.3.3.4.1 Format of the SecureDataHeader Submessage Element" and "9.5.3.3.4.3 Format of the SecureDataTag Submessage Element".
      • Should use the submessage endianness.
    • Section 9.5.3.3.4.2 Format of the SecureDataBody Submessage Element
      • When this is the content of the BODY submessage, the endianness should be the one in the submessage.
      • When this is an encrypted payload, the specification should define a default endianness. Proposal: big endian.

    EDIT
    After the discussion in the comments below, we decided to specify the endianness for the submessage elements to be Big Endian.
  • Reported: DDS-SECURITY 1.0 — Thu, 23 Feb 2017 23:22 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Specify Endianness to be Used in Submessage Elements

    Define changes according to the discussion under DDSSEC11-54.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Evaluation of data_tags when checking Permissions is unclear

  • Key: DDSSEC11-57
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    A 'rule' in the Permissions document can include any number of <data_tags> elements. Each data_tags element contains one or more <tag> elements. For example

    <publish>
  <topics><topic>A*</topic></topics>
  <data_tags>
     <tag>
          <name>a</name>
          <value>aVal</value>
     </tag>
     <tag>
          <name>b</name>
          <value>bVal</value>
     </tag>
  </data_tags>
  <data_tags>
     <tag>
          <name>a</name>
          <value>aVal</value>
     </tag>
     <tag>
          <name>c</name>
          <value>cVal</value>
     </tag>
  </data_tags>
</publish>

    The spec should be more clear about the circumstances under which this will and will not match with the tags provided to the check_create_datawriter/reader() and check_remote_datawriter/reader() operations.

    For example, would the above rule match a Writer with the following datatag qos: 

     
{ { a, aVal } }

    or:

     
{ {a, aVal}, {b, bVal}, {c, cVal} }

    Proposal:
    Add the following statement to the last paragraph of 9.4.1.3.2.3:

    For the data-tag criterion to match, the complete set of tags listed within one of the data_tags elements must match the complete set of data tags associated with the entity in question.
  • Reported: DDS-SECURITY 1.0 — Sun, 5 Mar 2017 20:23 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Clarify the matching criteria for partitions and data_tags

    The matching criteria will be explained. All sections must match.

    • The criteria for the sections within an "allow" rule is that the endpoint partitions/tags are a subset of the ones that are legal.
    • The criteria for the sections within a "deny" rule is that the endpoint partitions/tags cannot overlap any of the ones listed as illegal.

    Conservative defaults will be used when the section is not specified.
    <partitions> within an allow rule defaults to the empty partition
    <data_tags> within an allow rule defaults to no tags
    <partitions> within a deny rule defaults to "*"
    <data_tags> within a deny rule defaults to all tags
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

discovery_protection_kind is Underspecified

  • Key: DDSSEC11-45
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In current version of the spec, ParticipantSecurityAttributes only contains is_access_protected and is_rtps_protected.

    To be consistent with other fields like topic_rule's metadata_protection_kind (mapped to is_submessage_protected by the spec) or domain_rule's rtps_protection_kind (mapped to is_rtps_protected by the spec)), we should do the following modifications to the spec:

    • ParticipantSecurityAttributes: add new field is_discovery_protected
      • is_discovery_protected: Indicates the value of is_submessage_protected for the Builtin Discovery Secure endpoints.
    • Discovery Protection Kind element, add the following to 9.4.1.2.4.5 Discovery Protection Kind element:

    This setting controls the contents of the ParticipantSecurityAttributes returned by the
    AccessControl::get_participant_sec_attributes operation on the DomainParticipant. Specifically the is_discovery_protected attribute in the ParticipantSecurityAttributes shall be set to FALSE if and only if the value of the <discovery_protection_kind> element is NONE.
  • Reported: DDS-SECURITY 1.0 — Mon, 5 Dec 2016 12:13 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Define is_discovery_protected ParticipantSecurityAttribute

    Add an entry for is_discovery_protected to Table 21 in section 8.4.2.4. This field controls whether the Crypto plugin operations are called on the DCPSPublicationsSecure and DCPSSubscriptionsSecure.

    Edit section 9.4.1.2.4.4 (Discovery Protection Kind element) to explain that the setting of the <discovery_protection_kind> element determines the value of the ParticipantSecurityAttributes returned by the AccessControl::get_participant_sec_attributes. Specifically the field is_discovery_protected
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Table 51 CryptoToken should specify endianness of binary properties

  • Key: DDSSEC11-42
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Table 51 indicates that the key_material binary property should have as value the CDR serialized representation of a structure but it does not define an Endianness for the serialization. It should.

    Also in 8.3.2.9.4 , 8.3.2.9.5, and 8.3.2.9.6 it talks about message_data being the "cdr serialization" where it is not needed to say anything about serialization.

    Proposal: Use BIg Endian to be consistent with similar decisions on the DDS-Security spec
  • Reported: DDS-SECURITY 1.0 — Tue, 22 Nov 2016 23:39 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Changes in Specification to Use Big Endian Serialization For Crypto Tokens and To Remove Unnecessary Serialization Details for message_data

    Specify changes to specification according to DDSSEC11-42
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Inconsistency in SubMessage and SubMessageElement naming throughout document

  • Key: DDSSEC11-7
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:


    Most of the original list of points were addressed as part of the FTF2.
    The remaining two points are copied below:
    ----------------------------------------------------
    7.3.7 – missing section for SecuredPayload SubmessageElement
    Or, [and i think this is better], replace everywhere SecuredPayload with
    SecureDataBody. Then, add a section in 7.3.7 for SecureDataBody.

    ----------------------------------------------------
    7.3.6.2 RTPS Submessage: SecureSubMsg
    Figure 5 does not show SecureSubMsg.
    Should SecureSubMsg be removed?
    Or maybe it should be used only as a 'generic' term.
    SecureSubMsg is referenced many times in
    "Section 8.8.10 Cryptographic Plugins encoding/decoding behavior".
    Because of this, it might be good to define 'SecureSubMsg' as
    the sequence [ SecurePrefix + SecureBody|SerializedSubMsg + SecurePostfix ].
    Does that work?

    =======================================================
    Original list of points is below
    =======================================================

    ----------------------------------------------------

    7.3.7.4 SecureDataTag Element
    Typo in second para:

    The UDP/IP wire representation for the SecuredPayload shall be:

    Should be

    The UDP/IP wire representation for the SecuredDataTag shall be:

    Gerardo: Fixed in AB errata
    ----------------------------------------------------

    7.3.7.8 SecureRTPSPrefixSubMsg Submessage

    Is it true that it contains SecureDataTag?
    It should contain a SecureDataHeader, I think.

    Gerardo: Fixed in AB errata
    ----------------------------------------------------

    Mention of TransformationKeyId (section 9.5.2.5) and
    CryptoTransformationKeyId (section 9.5.2.1.1) should
    be CryptoTransformKeyId

    Gerardo: Fixed in AB errata
    ----------------------------------------------------

    9.5.2.4 DDS:Crypto:AES-GCM-GMAC SecureDataBody

    Second paragraph "SecureDataTag" should be "SecureDataBody".

    The IDL does not include the 'struct' typename:

    @Extensibility(FINAL_EXTENSIBILITY)
    struct

    { sequence<octet> secure_data; };

    Should be:

    @Extensibility(FINAL_EXTENSIBILITY)
    struct SecureDataBody { sequence<octet> secure_data; }

    ;

    Gerardo: This was already fixed by 182

    ----------------------------------------------------
    9.5.2.5 DDS:Crypto:AES-GCM-GMAC SecureDataTag

    The IDL shows receiver_mac is octet[8], but I think
    it should be octet[16]. 16 bytes is consistent with the
    format shown in 9.5.3.3.4.3.

    Gerardo: Fixed in AB errata
    ----------------------------------------------------
    7.3.7.8 SecureRTPSPrefixSubMsg Submessage

    Message structure shows contents as SecureDataTag. Should be
    SecureDataHeader.

    Gerardo: This was already fixed by 182
    ----------------------------------------------------

    7.3.7 – missing section for SecuredPayload SubmessageElement

    Or, [and i think this is better], replace everywhere SecuredPayload with
    SecureDataBody. Then, add a section in 7.3.7 for SecureDataBody.

    Gerardo: Too big a change for AB Errata. Push to RTF
    ----------------------------------------------------

    7.3.6.2 RTPS Submessage: SecureSubMsg

    Figure 5 does not show SecureSubMsg.
    Should SecureSubMsg be removed?
    Or maybe it should be used only as a 'generic' term.

    SecureSubMsg is referenced many times in
    "Section 8.8.10 Cryptographic Plugins encoding/decoding behavior".

    Because of this, it might be good to define 'SecureSubMsg' as
    the sequence [ SecurePrefix + SecureBody|SerializedSubMsg + SecurePostfix ].
    Does that work?

    Gerardo: Too big a change for AB Errata. Push to RTF
    ----------------------------------------------------
    7.3.7.5 SecureBodySubMsg Submessage

    Mentions SecureSubMsg, but should be SecureBodySubMsg

    Gerardo: Fixed in AB errata
    ----------------------------------------------------

    7.3.7.6 SecurePrefixSubMsg Submessage

    Mentions SecureSubMsg, should be SecurePrefixSubMsg

    Gerardo: Fixed in AB errata
    ----------------------------------------------------

    7.3.7.7 SecurePostfixSubMsg Submessage

    Mentions SecureSubMsg, should be SecurePostfixSubMsg

    Gerardo: Fixed in AB errata
  • Reported: DDS-SECURITY 1.0b1 — Sat, 12 Mar 2016 20:21 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Rename SecureDataHeader, SecurePayload, SecureDataTag

    Rename the following submessage elements:
    SecureDataHeader -> CryptoHeader
    SecuredPayload -> CryptoContent
    SecureDataTag -> CryptoFooter
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Crypto factory plugin implementation key generation

  • Key: DDSSEC11-8
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    After resolution of issue DDSSEC_-182 and -14 , the following issue exists:

    Table 55:

    1) register_matched_remote_participant() description, third sentence is missing sender_key_id.

    This :

    "The TransformationKind, master_salt, and master_sender_key shall match those of the ParticipantKeyMaterial. "

    should read

    "The TransformationKind, master_salt, master_sender_key, and sender_key_id shall match those of the ParticipantKeyMaterial. "

    2. register_matched_remote_datareader(), second sentence.

    This

    "The TransformationKind, master_salt, and master_sender_key for the Writer2ReaderKeyMaterial object shall match those in the DataWriter WriterKeyMaterial."

    should read

    "The TransformationKind, master_salt, master_sender_key, and sender_key_id for the Writer2ReaderKeyMaterial object shall match those in the DataWriter WriterKeyMaterial."

    3. register_matched_remote_datawriter, sentence 2.

    This

    "The TransformationKind, master_salt, and master_sender_key for the Reader2WriterKeyMaterial object shall match those in the DataReader ReaderKeyMaterial. "

    should read

    "The TransformationKind, master_salt, master_sender_key, and sender_key_id for the Reader2WriterKeyMaterial object shall match those in the DataReader ReaderKeyMaterial."

  • Reported: DDS-SECURITY 1.0b1 — Wed, 16 Mar 2016 19:24 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Perform the corrections listed in the issue description

    The issue description contains a number of editing corrections that should be used as the basis for the RevisedText
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Name of builtin topic is DCPSParticipantMessage not ParticipantMessage

  • Key: DDSSEC11-4
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section 7.4.2 (New ParticipantMessageSecure builtin Topic)
    It talks about the builtin Topic ParticipantMessage the correct name in RTPS spec is DCPSParticipantMessage.

    Consequently the names of the additional builtin Topics introduced by DDS Security should follow a similar naming convention.
    Specifically the following name changes are recommended:

    ParticipantMessageSecure -> DCPSParticipantMessageSecure
    ParticipantStatelessMessage -> DCPSParticipantStatelessMessage
    ParticipantVolatileMessageSecure -> DCPSParticipantVolatileMessageSecure

  • Reported: DDS-SECURITY 1.0b1 — Tue, 19 Jan 2016 01:39 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Correct names of new builtin topics

    Correct the names according to the issue description
  • Updated: Tue, 19 Dec 2017 20:03 GMT

How does the built-in Cryptographic plugin know whether to just Sign or EncryptThenSign?

  • Key: DDSSEC11-3
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The builtin plugins can be configured via the Governance and Permissions documents to selectively only Sign, or EncryptThenSign different Submessages and SubmessageElements.

    However the specification does not describe the mechanism by which Cryptographic plugin can know what the intent it when it creates the cryptographic material for the different DataWriters and DataReaders.

    The cryptographic material is created by the CryptoFactory operations register_local_datawriter and register_local_datareader. The only parameter that could be used to communicate a decision of Sign versus EncryptThenSign is the Properties parameter. But the specific property names and values to use should be prescribed in the specification.

  • Reported: DDS-SECURITY 1.0b1 — Sun, 3 Jan 2016 17:42 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Add EndpointSecurityAttributes Parameter to register_local_datawriter /register_local_datareader

    Add new parameter to register_local_datawriter and register_local_datareader: EndpointSecurityAttributes:

    register_local_datawriter
    (empty) DatawriterCryptoHandle
    participant_crypto ParticipantCryptoHandle
    datawriter_properties PropertySeq
    datawriter_security_attributes EndpointSecurityAttributes
    out: exception SecurityException
    register_local_datareader
    (empty) DatareaderCryptoHandle
    participant_crypto ParticipantCryptoHandle
    datareader_properties PropertySeq
    datareader_security_attributes EndpointSecurityAttributes
    out: exception SecurityException

    As per DDSSEC11-106 (which added plugin_specific_attributes), this will now include all the required information.

    For consistency, similar change proposed to register local participant:

    register_local_participant
    (empty) ParticipantCryptoHandle
    participant_identity IdentityHandle
    participant_permissions PermissionsHandle
    participant_properties PropertySeq
    participant_security_attributes ParticipantSecurityAttributes
    out: exception SecurityException
  • Updated: Tue, 19 Dec 2017 20:03 GMT

DomainGovernance -> domain_rule -> rtps_protection_kind description is unclear

  • Key: DDSSEC11-2
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    The description refers to the "liveliness protection element", which seems like an error.

    The description further says that this element specifies "the protection kind (see 9.4.1.2.1) used for the whole RTPS message". It is not clear to which message this refers.
  • Reported: DDS-SECURITY 1.0b1 — Sat, 21 Nov 2015 18:27 GMT
  • Disposition: Closed; No Change — DDS-SECURITY 1.1
  • Disposition Summary:

    Issue already corrected in the FTF

    This issue was corrected by http://issues.omg.org/browse/DDSSEC_-35
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Complexity of Authentication Plugin Model

  • Key: DDSSEC11-1
  • Legacy Issue Number: 19793
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The Authentication Plugin Model specifies a state machine to be implemented by the DDS middleware to manage the authentication of the remote Participants. The implementation of this state machine is complex because:

    • It is not specified when to call validate_remote_identity (for each received SPDP or only for the first received SPDP from a newly discovered Participant? What if a malicious Participant send a SPDP at first, usurping the GUID of a legit Participant?)
    • The handshake could be initiated from both sides at nearly the same time (nothing forbid this in §8.3)
    • There is no indication in the specification to tell how parallel handshakes between 2 Participants should interact
    • It is difficult to determine at which sense a received message belongs
    • In §8.3.2.8.1 it's specified that "The DDS security implementation shall pass to the AuthenticationPlugin any message received by the BuiltinParticipantStatelessMessageReader...". But there are states in the state machine where it's not specified how to pass those messages (e.g. when validate_remote_identity has not been called yet, and the state machine is not initialized)

    This results in quite complex code, and this is a weakness in a mechanism which needs to be very strong.

    Anyway, the state machine in the middleware is redundant with the one needed in the plugin. In addition, it has to deal with events where it doesn't know what is really going on. Only the plugin has the real information. Therefore, we think this middleware state machine is useless, add extra complexity which makes the authentication less robust, and consumes a lot of resources.

    Instead, we suggest to remove it and to change the mechanism to the following:

    • remove all the "_handshake" methods on the Authentication Plugin
    • add a treat_message method to the authentication plugin to handle any incoming authentication ParticipantStatelessMessage
    • add a send_message method to the authentication listener interface to tell the middleware to send an authentication ParticipantStatelessMessage
    • add a validated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is authenticated
    • add a invalidated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is not authenticated
    • once the authentication is initialised with validate_remote_identity, all the state machine is managed directly by the plugin which sends the appropriate messages and is given the received ones, until its decision is given to the DDS middleware through the authentication listener.

    This will provide the necessary functionality in a much simple, efficient and robust manner.
  • Reported: DDS-SECURITY 1.0b1 — Thu, 11 Jun 2015 04:00 GMT
  • Disposition: Deferred — DDS-SECURITY 1.1
  • Disposition Summary:

    Defer

    The issue does not affect the interoperability or behavior. The many benefit would be to simplify the explanation and potentially the implementation of the Authentication plugins. However addressing would be complex in terms of the amount of text that would be affected and the interactions with the text modified by other issues in this RTF.

    For this reason it seems most appropriate to defer it to the next RTF. At that point there will be less changes caused by other issues thus simplifying the resolution of this issue
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Miscellaneous typos/inconsistencies

  • Key: DDSSEC11-5
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:
    • In section 9.6 (BuiltinLoggingPlugin) it says "NameValurPair" it should say "NameValuePair"
    • In Figure 20 field "msgid" is "int" it should be "string" to be consistent with section 9.6
    • In section 9.4.1.2 there are two occurrences of "Encrypt+MAC" this is ambiguous as it could be interpreted as "Encrypt and MAC" which s not considered best practice. It should say "Encrypt-then-MAC" to be more precise and match what the plugins do.
    • Section 9.4.1.2.5.5 second paragraph says "This element may take the binary values TRUE or FALSE" instead it should say "This element may take the three possible values: NONE, SIGN, or ENCRYPT.''
    • Section 4, definition of Key management. Remove the words "of the keys" from the definition as shown here: "...during their entire life cycle of the keys from creation to destruction."
    • XML examples in Section 9.4.1.2.7 and 9.4.1.4 use encoding="utf-16" this should be changed to encoding="utf-8" to be consistent with the XSD in section 9.4.1.2.2, 9.4.1.3, and all the machine readable documents (both XSD and example XMLs).
    • Section 9.4.1.2.4.5 (Liveliness Protection Kind element) in the 3rd and last paragraph says: "The discovery protection kind..." it should say "The liveliness protection kind..."
  • Reported: DDS-SECURITY 1.0b1 — Mon, 28 Mar 2016 23:47 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Perform the corrections listed in the issue description

    The issue description contains a list of corrections that should become the RevisedText
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Examples of Wildcard permissions

  • Key: DDSSEC11-113
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    It is not clear whether the Permissions XSD allows to express all kinds of wildcard permissions. Just to make sure we cover all cases, we should give examples of permissions XML that grant only...

    1. all permissions to any domain? ("all permissions" = join, pub/sub/relay to any topic/partition/data_tag, etc.)
    2. all permissions to a specific domain, e.g. domain 0?
    3. all permissions to all topics of domain 0? ("all permissions" = pub/sub/relay, etc.)
    4. all permissions to all partitions of domain 0?
    5. all permissions to a specific topic, e.g. "Circle1", of domain 0?
    6. all permissions to a specific partition, e.g. "P1", of domain 0?
    7. the permission to publish to any topic of domain 0? (but not subscribe/relay)
    8. the permission to publish to any partition of domain 0? (but not subscribe/relay)

    Such examples would be very useful in the spec as well.
  • Reported: DDS-SECURITY 1.0 — Tue, 11 Jul 2017 12:43 GMT
  • Disposition: Deferred — DDS-SECURITY 1.1
  • Disposition Summary:

    Examples would be nice but can be deferred

    Having example permission files would help implementors of the specification so it is considered a desirable feature.

    However given the limited time to complete the RTF 1 the task force decided to defer to the next RTF
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

How is single-MAC versus MAC-per-reader configured?

  • Key: DDSSEC11-11
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently the governance document allows specification of a "protection_kind" which can be NONE, SIGN, ENCRYPT

    But we support a single MAC versus multiple MACs (one per reader). Who configures this. Is this something in the Governance document? Something that appears in the Permissions document of the DataReader?

    Also it should be stated in the specification that if a DataReader gets in its KeyMaterial from the DataWriter a "receiver_specific_keyid" then it shall expect that messages from that DataWriter are signed with the reader-specific key and if it is not so they shall be rejected.
  • Reported: DDS-SECURITY 1.0b1 — Sat, 20 Feb 2016 01:45 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Extend governance to indicate whether mac_per_readers are desired

    Note: This is work in progress (see comments at bottom of DDSSEC11-11 for issues still being resolved)

    The format of the Governance document of the builtin Authentication plugin shall be extended.

    • There shall be a new ExtendedProtectionKind simple type that is is similar to the existing ProtectionKind enumeration except with extra values: ENCRYPT_WITH_ORIGIN_AUTHENTICATION and SIGN_WITH_ORIGIN_AUTHENTICATION
    • The type associated with the <rtps_protection_kind>, <metadata_protection_kind>, <discovery_protection_kind> and <liveliness_protection_kind> shall be changed to be ExtendedProtectionKind instead of the current ProtectionKind

    The selection of ExtendedProtectionKind SIGN_WITH_ORIGIN_AUTHENTICATION or ENCRYPT_WITH_ORIGIN_AUTHENTICATION indicates that in addition to the common authentication code there shall be an additional authentication code that uses the reader-specific MAC key.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Provide mechanisms to extend Governance and Permissions files without breaking interoperability

  • Key: DDSSEC11-10
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • 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/
  • Reported: DDS-SECURITY 1.0b1 — Sat, 20 Feb 2016 01:36 GMT
  • Disposition: Deferred — DDS-SECURITY 1.1
  • Disposition Summary:

    Defer to RTF2

    This issue has been deemed of lower priority and some of the proposals to address it depend on standards that are not widely supported. Hence the RTF has determined to defer it to the next RTF in the hope that the situation and requirements will be more clear by then.
  • Updated: Tue, 19 Dec 2017 20:03 GMT
  • Attachments:

Built-in Authentication and Cryptography plugins tied together by SharedSecretHandle implementation

  • Key: DDSSEC11-9
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    An implementation of the built-in Cryptography plugin is not compatible with the local implementation of the built-in Authentication, unless it uses/understands the same type of SharedSecretHandle. (SharedSecretHandle is the interface defined at the architecture level.) Therefore, the two built-in plugins are tied together and you cannot replace one or another with any other implementation of the same built-in plugin.
    It is possible to make them independent in two possible ways (at least):

    1. Define a BuiltinSharedSecretHandle that extends SharedSecretHandle interface, and has 3 methods like this:
      • octet[] getChallenge1(): returns challenge1 from the authentication handshake
      • octet[] getChallenge2(): returns challenge2 from the authentication handshake
      • octet[] getSharedSecret(): returns the shared secret from the authentication handshake
    2. OR define a new type of Token (IDL structure) - e.g. HandshakeResultToken - for the final output of the Authentication handshake like this:
      • class_id DDS:Auth:PKI-DH:1.0+Result
      • binary_properties: challenge1, challenge2, SharedSecret

    In both cases, it would change the specs of the methods get_shared_secret() and return_shared_handle() of the Authentication plugin, section 9.3.3.
  • Reported: DDS-SECURITY 1.0b1 — Tue, 1 Mar 2016 17:36 GMT
  • Disposition: Deferred — DDS-SECURITY 1.1
  • Disposition Summary:

    Defer to RTF2

    Making the different interfaces independent from each other is a desirable goal. But it may require some additional changes beyond the ones mentioned in this issue description. For this reason the RTF decided to postpone it to the next RTF.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Determining the wire version of the DDS Security Protocol

  • Key: DDSSEC11-93
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In the case of the DDS-RTPS wire protocol, the version of the RTPS protocol can be determined from the RTPS header that starts each message.

    DDS-Security adds messages to RTPS. In that sense it extends the protocol creating an SRTPS protocol (with additional builtin endpoints, submessages, and submessage elements). However there does not seem to be an obvious way to determine this version from just observing the packets on the wire.

    Not having this version may complicate creating future revisions that do not break interoperability and also the development or use of packet level tools like wireshark.

    One possible solution is to use the minor version of the RTPS protocol to also encode the version of the secure RTPS protocol. For example current version of RTPS is 2.2 we could say that from now onwards the "odd" version numbers represent "secure" versions of the proceeding "even" version. So the result of DDS Security RTF 1 will be RTPS 2.3 and the result of DDS Interoperability RTF3 will be RTPS 2.4. If these RTFs do not alternate we just skip the intermediate version. For example if DDS Interoperability RTF4 comes without an interweaving DDS-Security we just jump to RTPS 2.6

    Proposal:
    This DDS-Security RTF will cycle the version of RTPS to the next (2.3)
    The current RTPS RTF3 will take that into consideration and indicate the range of sub-messages reserved for security. RTPS RTF3 will then set the RTPS protocol version to "2.4"

    Onwards each RTF will update the RTPS version (assuming there are changes to the protocol) because they should know about each other.

    In addition we need to say that the Plugin name has the version as part of the name and that the version should be parsed in a certain way to check compatibility. I.e. not require an exact match of the plugin names.

    We should also add a "version" properties for each plugin as in dds.sec.auth.version and dds.sec.access,version, these would be propagated.
    Also add a dds.sec.auth.common to have an overall version of the spec...
  • Reported: DDS-SECURITY 1.0 — Wed, 31 May 2017 16:55 GMT
  • Disposition: Resolved — DDS-SECURITY 1.1
  • Disposition Summary:

    Revise version of RTPS and provide rules for plugin versions

    Since the DDS-Security specification adds new RTPS submessages it should also update the version of RTPS to the next one (2.3).

    The DDS-Security should spec should also "reserve" a range of RTPS Discovery parameterIds 0x1XXX for the use of the DDS-Security spec and future revisions.

    Section 9.3.2 (DDS:Auth:PKI-DH Types) should indicate that the IdentityToken class_id should be parsed up to the last ":" character. The suffix after the column and interpreted as:
    <PluginClassName>:<MajorVersion>.<MinorVersion>
    If the <PluginClassName> or the <MajorVersion> differ, then the two participants should not attempt authentication.

    Section 9.4.2.2 (DDS:Access:Permissions PermissionsToken) should indicate that the PermissionsToken class_id should be parsed up to the last ":" character. The suffix after the column and interpreted as:
    <PluginClassName>:<MajorVersion>.<MinorVersion>
    If the <PluginClassName> or the <MajorVersion> differ, then the two participants should not try to interpret the permissions document of the other participant.
  • Updated: Tue, 19 Dec 2017 20:03 GMT

Durability section typos

  • Key: DDS15-207
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    2.2.3.4 DURABILITY

    paragraph 5: "serviced" should be "service"

    paragraph 8: "data-instances" should be "data-instance"

    item #3: "longer that" should be "longer than"

    last paragraph: "disposition" should be "disposal" or "dispose operation"
  • Reported: DDS 1.4 — Thu, 14 Dec 2017 22:54 GMT
  • Updated: Thu, 14 Dec 2017 22:54 GMT

BuiltinTopicKey_t should be completely customizable.

  • Key: DDS15-206
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The IDL file describing the builtin topics consists of two parts:

    • A section with #define statements where certain datatypes may be customized by the different vendors.
    • A section where these customized datatypes are actually embedded in the builtin topic declarations.

    All builtin topics contain a key field of type BuiltinTopicKey_t that is defined in the following way:

    #define BUILTIN_TOPIC_KEY_TYPE_NATIVE long

module DDS {
    struct BuiltinTopicKey_t {
        BUILTIN_TOPIC_KEY_TYPE_NATIVE value[3];
    };
};

    This implies that vendors may specify part of the key (the array element type), but they may not specify it to be anything else than an array of three of those vendor specific datatypes.

    Right now, different vendors have specified the BuiltinTopicKey_t in various different ways: some uses an array of 16 octets to directly reflect the RTPS GUID, but the official DDS spec does not allow for this.

    In order to allow for these kinds of vendor specific customizations, the entire BuiltinTopicKey_t should be declared as a vendor specific #define statement.

    As some context: this issue was filed in the RTPS RTF working group during the Dec 2017 San Fransisco OMG meeting. Basically the consensus was that indeed the builtin topic key type should be fully customizable. How this is exactly gonna be achieved was left to the DDS RTF working group.
  • Reported: DDS 1.4 — Tue, 5 Dec 2017 19:50 GMT
  • Updated: Wed, 6 Dec 2017 07:00 GMT

Specify behavior of filters and queries relative of lifecycle events

  • Key: DDS15-205
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    How are dispose and unregister samples treated for DataReaders that use a ContentFilteredTopic or a QueryCondition?

    Should these "lifecycle" notification samples pass all filters? Should the "key part" of the filter be considered when propagating these notifications?
  • Reported: DDS 1.4 — Tue, 5 Dec 2017 18:50 GMT
  • Updated: Tue, 5 Dec 2017 18:50 GMT

Add API for "directed writes"

  • Key: DDS15-204
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS-RTPS protocol supports directing samples to a specific DataReader. However there is no way to exercise this feature using standard DDS API.

    The idea is to add an additional operation to the DataWriter allowing the specification of the destination DataReader. This could be a specific write_directed() operation or a more generic write_with_parameters() that allows additional parameters to be specified.
  • Reported: DDS 1.4 — Sat, 2 Dec 2017 00:33 GMT
  • Updated: Sat, 2 Dec 2017 00:34 GMT

Topic Names are Restricted to Characters, Digits, and Hyphens

  • Key: DDS15-203
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    SQL grammar in BNF in clause B.2 limits topic names to the following characters: [A-Za-z0-9\-]+.

    The DDS specification should add support for more characters. Some candidates are "/", ":", ".", "_". The latter is actually used in the DDS-XTYPES as a separator in the mapping of interfaces to request and reply topics.
  • Reported: DDS 1.4 — Tue, 28 Nov 2017 16:13 GMT
  • Updated: Thu, 30 Nov 2017 14:35 GMT

Multiple DataReaders per topic on secured Participant

  • Key: DDSSEC_-190
  • Status: open   Implementation work Blocked
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    Looking at the datareader_crypto parameter description of the preprocess_secure_submsg operation:

    "If secure_submessage_category is DATAWRITER_SUBMESSAGE, the datareader_crypto shall be the DatareaderCryptoHandle returned by a previous call to register_local_datareader for the DataReader that is the destination of the RTPS Submessage."

    It seems that only a single DatareaderCryptoHandle can be returned. This implies that a secure DATAWRITER_SUBMESSAGE should be at destination of a single DataReader.

    How to deal with several DataReaders in a Participant matching the same DataWriter ? Most of the time, the submessage destination is ENTITY_UNKOWN. As a consequence a clarification is required.
  • Reported: DDS-SECURITY 1.0 — Tue, 29 Aug 2017 15:45 GMT
  • Updated: Wed, 30 Aug 2017 15:16 GMT

Users should have more control over when and how types match

  • Key: DDSXTY12-145
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The type assignability rules aim to make evolving types simple and intuitive. However, there are many cases in which the rules may not match a user's needs. For example, it may or may not be desirable for the member names to be taken into account during type assignability or it may be useful to disallow types from matching solely based on the type name in the absence of type information.

    Therefore we are proposing that the following behaviors are added to the TypeConsistencyEnforcementQosPolicy:

    1. Provide a way to specify to only match readers/writers that you have the TypeObject so that you can ensure type compatibility.
    2. Provide a way to ignore member names, sequence bounds and string bounds
    3. Provide a way to prevent type widening

    And that the following builtin annotation be added:
    @hash id("old_member_name")
    When using auto member ids, the member id is assigned to be the 4-byte hash of the member name. If a user wants to change the name of the member in another version of the type, the member id will change. This annotation will solve that situation by allowing the user to obtain the hash of the old member name as the member id for the member with a different name in the new version.

  • Reported: DDS-XTypes 1.1 — Thu, 22 Dec 2016 19:26 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Add new fields to the TypeConsistencyEnforcementQosPolicy and new @hash_id annotation

    Allow users to have more control over type evolution and the type assignability rules by adding fields to the TypeConsistencyEnforcementQosPolicy and a @hash_id annotation
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Computing the TypeObject and TypeId for recursive types

  • Key: DDSXTY12-147
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    A recursive type is one that refers to itself either directly or indirectly. These types are useful to represent dynamic data structures such as trees. For example:

    struct Node;
struct Node {
    long data;
    @external @optional Node left_child;
    @external @optional Node right_child:
};

    The children are marked @external so that the generated code in languages like C and C++ that can hold object by value uses a reference and therefore does not complain about "incompletely defined symbols"

    The children are marked @optional so that the recursive type can be terminated.

    There is no fundamental problem in supporting these types in the XTYPES type system. Except that the algorithm used to create the TypeObject and compute the TypeId would fail because the type object of an aggregate type requires knowledge of the TypeIdentifiers (and hence TypeObjects) of all the member types and the recursion creates a cyclic-dependency on this.

    Even if this not resolved in RTF 2.2 we need a plan so that we do not break interoperability in the future.
  • Reported: DDS-XTypes 1.1 — Tue, 10 Jan 2017 15:14 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    This is addressed by DDSXTY12-100

    Issue DDSXTY12-100 modifies the definition of TypeObject and updates the algorithm to compute TypeIdentifiers from the TypeObjects.

    The updated algorithm can handle mutually dependent types and "recursive" types. Therefore this issue is being merged into DDSXTY12-100.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

UML Model is not consistent with document and missing types

  • Key: DDSXTY12-149
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This changes are needed to align the XTYPES model with IDL4. Specifically with regards to annotations.

    In IDL4 it is possible to annotate type declarations, members, and elements in a collection as in:

    @MyAnnotation(3)
struct MyStruct {
    @MemberAnnotation  long l_member;
    sequence< @ElementAnnotation long, 55>   seq_member;
};

    Union discriminators can also be annotated and so can members, but not the case literals:

    @MyAnnotation(3)
union MyUnion switch ( DiscriminatorAnnotation(44)  long)  {
    case 1:
       @MemberAnnotation  long  l_member;
    default:
        sequence< @ElementAnnotation long, 55>   seq_member;
};

    It is also possible to annotate enumeration, bitmask and bitset members.

    @MyAnnotation(3)
bitmask MyBitmask{
    @position(2)  flag1;
};

    Annotation are also permitted in the “related type” for a typedef:

    typedef  @max(23) long  MyLong;
typedef  sequence<@external long>  LongPtrSeq;

    Another issue is that in the new XTYPES we are no longer requiring that all types are named. So that the inheritance of Type from NamedElement is not what we want.

    Currently we use NamedElement model both the name of a type as well as the name of a member (structure, union), name of a bitflag, module, and enum literal.

    Those are things we want to annotate. But we also want to annotate element of a collection as well as the discriminator of unions which have no name.
  • Reported: DDS-XTypes 1.1 — Fri, 20 Jan 2017 10:49 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Update UML Model to align it with IDL4

    This changes are needed to align the XTYPES model with IDL4. Specifically with regards to annotations.

    In IDL4 it is possible to annotate type declarations, members, and elements in a collection as in:

    @MyAnnotation(3)
struct MyStruct {
    @MemberAnnotation  long l_member;
    sequence< @ElementAnnotation long, 55>   seq_member;
};

    Union discriminators can also be annotated and so can members, but not the case literals:

    @MyAnnotation(3)
union MyUnion switch ( DiscriminatorAnnotation(44)  long)  {
    case 1:
       @MemberAnnotation  long  l_member;
    default:
        sequence< @ElementAnnotation long, 55>   seq_member;
};

    It is also possible to annotate enumeration, bitmask and bitset members.

    @MyAnnotation(3)
bitmask MyBitmask{
    @position(2)  flag1;
};

    Annotation are also permitted in the “related type” for a typedef:

    typedef  @max(23) long  MyLong;
typedef  sequence<@external long>  LongPtrSeq;

    Another issue is that in the new XTYPES we are no longer requiring that all types are named. So that the inheritance of Type from NamedElement is not what we want.

    Currently we use NamedElement model both the name of a type as well as the name of a member (structure, union), name of a bitflag, module, and enum literal.

    Those are things we want to annotate. But we also want to annotate element of a collection as well as the discriminator of unions which have no name.

    Modifications to the UML model

    The UML model needs an AppliedAnnotation class that models the application of annotations to some other classifier.

    Also NamedElement should not be modeled as a “base class” but rather as something that certain classifiers have. So it should be a “has-a” relationship. That would allow some types (e.g. anonymous types) to not have a name.

    String should not inherit from Collection. There should be a StringType that is specialized by String8 and String16. StringType would be a direct child of Type, peer to PrimitiveType.

    There should be a EnumeratedType peer of PrimitiveType. It should have Enumeration and Bitmask as specializations.

    Bitset should be added as another specialization of Aggregation.

    In addition:

    • Create an association between Aggregation and NamedElement. This has cardinality “1”. Every Aggregation type has a name.
    • Create an association between Collection and NamedElement. This has cardinality “0..1”. Collection types can be named or anonymous.
    • Create an association between Alias and NamedElement. This has cardinality “1”. Alias types always have a name.
    • Add an association between ConstructedType and NamedElement. It should have to be “0..1” to capture the possibility for anonymous collections.
    • Module, EnumerationLiteral, Bitflag, Member, and Bitfield would also have a “has-a” relation to NamedElement with cardinality “1”.
    • Model the annotations on collection element and union discriminator.
    • Union Discriminator requires a separate class. Currently it is modeled as a “member” but that is odd (e.g. it is unnamed, has hard-coded memberID) better to model it separately.
    • Change NamedElement to ScopedIdentifier.

    Enhance model for Annotations
    Currently Annotation specializes Aggregation type. This is wrong in several ways.
    Al constructed types can be annotated. But Annotations cannot have annotations.
    It does make sense to talk about the extensibility kind of an annotation. Nor about the type compatibility/assignability.

    Many associations to type (e.g. a structure member has a type) do not make sense if the “type” is an annotation.

    The only thing from Type is that they can have a type object.

    Annotations should not be modeled as types. They should not specialize “Type” they should be their own thing. Basically we define a AnnotationDeclaration an AppliedAnnotation (and AnnotationParameter). This can follow the TypeObject model.

    Then section 7.2.2.3.6 “Annotation Types” can be moved to a higher level. Say 7.2.2.6 after :”Try Construct Behavior”

    Also in the XTYPES it says (in section 7.2.2.3.6) that annotations can inherit from other annotations. However the IDL grammar 7.4.15 does not support annotation inheritance so we should get rid of that in the XTYPES.
  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Fix a Number of Issues in Final Document

XTypes impacts on IDL and language mappings; optional conformance

  • Key: DDSXTY12-142
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Since XTypes changes how IDL and language mappings work, determine if an XTypes implementation can still be conformant (perhaps using optional conformance) if certain features are not implemented – for example external/shareable types.

    There are many OMG specs listed in section 3 "Normative References." XTypes should be explicit about which of these are required dependencies, which are optional, and which sections of those specs are important for XTypes.
  • Reported: DDS-XTypes 1.1 — Fri, 18 Nov 2016 16:27 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    *Update the conformance section *

    Update the conformance chapter to reflect and include the new sections in the spec

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Improving Extensible Types

  • Key: DDSXTY12-18
  • Legacy Issue Number: 18146
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Extensible Types do not support monotonic extensions of nested struct types. Adding support for monotonic extensibility of nested structures is straight-forward and requires only a very small change to the existing specification.

    Our suggestion is to allow for monotonic extensibility at any level in the type structure and accommodate this by serializing a length parameter before any nested structure.

    No @Id should be serialized since it is likely that user won't specify IDs when using Extensible types and relying on Ids could break the whole scheme.

    Note that this no longer needs to address DDSXTY12-15 as that issue is already addressed by the resolution DDSXTY12-145
  • Reported: DDS-XTypes 1.1 — Mon, 8 Oct 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Improving Extensible Types

    In DDS-XTYPES 1.1 there are 3 extensibility kinds: Final, Extensible, Mutable. And two encoding formats: PLAIN_CDR and PL_CDR.

    In DDS-XTYPES 1.2 we are adding 2 encoding formats: DELIMITED_CDR and ENHANCED_PL_CDR.

    For simplicity and backwards compatibility DDS-XTYPES 1.2 keeps the same 3 extensibility kinds. But uses the name "APPENDABLE" instead of "EXTENSIBLE". "EXTENSIBLE can still be accepted in the IDL for compatibility. When serializing data the Encoding format is determined by “Extensibility Kind” and the encoding version:

    Extensibility Kind in the IDL Encoding Version Extensibility Kind in the TypeObject Encoding format on the wire
    FINAL 1 FINAL=0 PLAIN_CDR
    FINAL 2 FINAL=0 PLAIN_CDR2
    APPENDABLE 1 APPENDABLE=1 PLAIN_CDR
    APPENDABLE 2 APPENDABLE=1 DELIMITED_CDR
    MUTABLE 1 MUTABLE=2 PL_CDR
    MUTABLE 2 MUTABLE=2 ENHANCED_PL_CDR
  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Type Consistency Enforcement Policy does not allow to properly control type projection/widening

  • Key: DDSXTY12-15
  • Legacy Issue Number: 19405
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The X-Types specification suffers a of inconsistency with respect to how it treats type widening for extensible and mutable types. Specifically widening is always supported for mutable types and never for extensible types.

    That means that given two types X, and Y with Y <: X (read as Y subtype of X) then we have the following cases:

    1. If X and Y are mutable and the TypeConsistencyEnforcementQosPolicy is set to ALLOW_TYPE_COERCION then:
    i. a DR[X] will match a DW[Y] and in this case Y will be
    projected on X.

    ii. a DR[Y] will match a DR[X] and in this case X will be
    widened to Y – by initializing missing attributes
    with default constructors.

    2. If X and Y are extensible and the TypeConsistencyEnforcementQosPolicy is set to ALLOW_TYPE_COERCION then the only possible case is for a DR[X] to match a DW[Y] through a projection of Y on X.

    The inconsistency resulting from the non-uniform treatment of extensible types is not only unjustified but also creates practical issues.

    The fixes that we propose to the specification are the following.

    • Extend the the TypeConsistencyEnforcementQosPolicy to control both type widening as well as projection. Notice that although projection is safe (in most of the case) type widening may not be safe for some applications.

    Thus the the TypeConsistencyEnforcementQosPolicy should be extended to provide the following options:

    1. ALLOW_TYPE_PROJECTION to enable only type
    projection regardless of wether a topic is mutable or
    extensible.

    2. ALLOW_TYPE_WIDENING to enable only type widening

    The conjunction of the previous options should allow for a type to support both projection as well as widening. Otherwise, but this option is less desirable, a third option named ALLOW_TYPE_PROJECTION_AND_WIDENING may be added.

    3. Rename DISALLOW_TYPE_COERCION into
    DISALLOW_TYPE_CONVERSION.

    • Clarify the assignable-from to make it more explicit that type widening is also supported by extensible types.
  • Reported: DDS-XTypes 1.1 — Fri, 2 May 2014 04:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Merged with DDSXTY12-18

    This issue is addressed by the same mechanism proposed to address DDSXTY12-18 and therefore it is being merged with it.

    Even if it had been merged with DDSXTY12-18 it was eventually handled by DDSXTY12-145 which was resolved before DDSXTY12-18
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Enumerations should be represented as a Byte if the bit bound is small enough

  • Key: DDSXTY12-143
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently enumerations can only be represented using Int16 or Int32. But we see no reason why they couldn't be represented with a Byte if the bit bound is 8 or less.

  • Reported: DDS-XTypes 1.1 — Thu, 22 Dec 2016 16:55 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Allow Enumerations to be represented by a Byte if the Bit Bound is 8 or less

    Allow Enumerations to be represented by a Byte if the bit bound is 8 or less. Currently, if the bit bound is 1-16 the representation is Int16.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Add a @non-serialized annotation

  • Key: DDSXTY12-131
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.4.1.3 "Extension to RTPS Standard DCPSParticipants Builtin Topic" of the DDS-Security 1.0 specification defines a @non-serialized annotation. This is used to indicate that a member of an aggregate type should not be serialized.

    This annotation should be moved to XTYPES since it is not specific to DDS-Security and may be needed for other data-types.
  • Reported: DDS-XTypes 1.1 — Tue, 4 Oct 2016 11:43 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Add a @non_serialized annotation

    A @non_serialized annotation is currently defined in the DDS-SECURITY specification. It is not specific to security though, so we are moving it to the XTYPES specification.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

TypeObject IDL and its propagation suffers from significant problems

  • Key: DDSXTY12-100
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The TypeObject IDL in Annex B has some significant problems:

    • The TypeObject of a type embeds its TypeId. However to compute the TypeId one needs to serialize the TypeObject and hash the result. This recursion makes it impossible to create. The work around of first setting the TypeId=0, then computing a "adjusted" TypeObject, serialize and hash it, and use the hash of the "adjusted" TypeObject as its TypeId has been suggested but it is clunky to say the least.
    • Even with the workaround mentioned above the TypeObject format cannot handle recursive types. That is types that refer to themselves which are legal in IDL. For example, there is no way to compute the TypeId of the "child" member f IntTree without having the TypeObject for IntTree which creates an infinite recursion.
    typedef IntTree;
struct IntTree {
    long  value;
    sequence<IntTree> children;
};
    • There TypeObject IDL uses extensibility(MUTABLE) for many types. This allows multiple equivalent serializations for the TypeObject as members of a mutable type can be serialized in any order. Also there is a choice between serializing them using so called short parameters or "extended" parameters, and also they can be serialized in big endian or little endian. All this means that the TypeId which is a hash computed on the serialized TypeObject can be different depending on how/where it is computed. This is undesirable as the TypeSystem uses the equality of TypeId to detect when types are identical.
    • The TypeObject contains a very detailed representation of the type which is equivalent to the IDL and XML. This is propagated via discovery in the PublicationBuiltinTopic data. This information can be very large (100's of KB) which slows discovery and pushes information to every participant even if they have no interest on that Type, or already know it. Moreover, even when it is used the only need is to check type assignability and that does not require a lot of the information that is propagated with the type
    • The TypeObject is missing the new annotations and types introduced in IDL4.

    In view of this the TypeObject IDL should be refactored in a way that addresses the above problems. Moreover the specification should provide a more efficient way to propagate types that does not involve pushing the TypeObject in the discovery builtin topic data.
  • Reported: DDS-XTypes 1.1 — Wed, 29 Jun 2016 21:11 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Refactor the TypeObject IDL definition and provide a more efficient propagation mechanism

    This resolution includes:

    • A new TypeObject IDL
    • The computation of TypeId for mutually-dependent (recursive) types
    • The propagation of TypeObject (using the request/reply builtin objects)
    • The naming anonymous types.
  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Consider expanding TypeId 16 octets rather than 8

  • Key: DDSXTY12-127
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently the TypeId is 8 octets.
    The TypeId distinguishes identifies a Type and needs to have a low probability of collision relative to the size of the set (collection of types) that can potentially apply to the scope.

    A hash of 64 bits provides reasonably low probability of collision (e.g. < 1 in 10 million) when the set of possible values has a size smaller than 2 million. This was more than enough when we consider the "collection of types" to just be the types that can be associated with a particular Topic on a particular Domain.

    However if we consider the problem of identifying Types across Topics within a Domain, or across domains, or even across applications that evolve over time (e.g. keep a database of TypeId that is built over time) then 64 bits may not be enough...

    We should consider whether to make it 16 bytes now. If these use cases can become important then now would be the time to make the change...
  • Reported: DDS-XTypes 1.1 — Wed, 28 Sep 2016 22:13 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    The size of the TypeID is being increased so hashes are 14 bytes.

    This issue is being merged with DDSXTY12-100 because the resolution of that issue is already increasing the sizes of the hashes in the TypeID to 14 bytes.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

The current assignability rules are complex and too restrictive

  • Key: DDSXTY12-119
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The existing type compatibility rules create situations where DataWriters are not able to communicate with DataReaders because of type differences that could be easily accommodated by the type system.

    The assignability rules for strings are sequences are following the meta-rule: “If type T1 can have an object O1 that is not assignable to type T2, then type T1 is considered un-assignable to T2”. For example according to Table 13 string<256> is unnasignable to string<32> and sequence<long, 256> is unnasignable to sequence<long, 32>.

    Feedback from users indicates that this is undesirable. For example a type may have been designed containing a string<256> but never used to send strings longer than 30 characters. Then in a later version the type is modified to string<32> in order to reduce the max length to the actual size needed to conserve memory resources. This would make the new version of the type incompatible with deployed systems even if all the strings ever sent fit in the string<32> type.

    Type assignability rules are also complex because they are defined as an asymmetric relationship: T1 is-assignable-to T2. rather than a symmetric one. Another complexity comes from the need to define of "strong assignability" which captures the case where T1 is-assignable-to T2 and the end of the T1 object can be determined by T2. This is needed when the T1 appears nested inside another type or in a sequence.

    The main reason to define this asymmetric rule was caused by the previous point of having types like string<10> assignable to string<100> but not the other way around. If we change these assignability rules for strings/sequences then the need for the asymmetric is-assignable-to relationship goes away and can be replaced by a symmetric "is-compatible-with"

    The "strong assignability" is an artifact of the way extensible types are serialized. If they were serialized wrapped with a "length" around them as with the APPEND extensibility we would not need this concept.
  • Reported: DDS-XTypes 1.1 — Sat, 6 Aug 2016 19:47 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Increase flexibility of assignability rules

    Introduce new rules to increase the set of types that are assignable and avoid discarding data as soon as an object that does not "fit" into a target type.

    • Change compatibility of sequences and strings so that the types are compatible regardless of the length. Object initialization requires SOURCE.length <= TARGET_TYPE.length if not the object cannot initialize an object of the TARGET type. This affects Table 13.
    • Introduce a @TryConstruct annotation that can be used to indicate that an unassignable member does not cause the complete object to be dropped. Instead, the member is set to its default value.
    • Allow the use of @DefaultLiteral annotation on enum to allow selecting a default value for an enumeration other than the first or one with smallest member ID.
    • Change compatibility of unions and structures to take into consideration the @TryConstruct annotation.
    • Introduce some clarifying examples

    More details can be found in the attached document: TypeCompatibilityProposal_v3.docx
  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Reserved parameter IDs in 7.4.1.2.1 are wrong

  • Key: DDSXTY12-41
  • Legacy Issue Number: 17295
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Found by: Fernando Crespo, RTI (fernando@rti.com)
    Severity: Significant

    Problem:
    Table 27, "Reserved parameter ID values", in section 7.4.1.2.1, "Interpretation of Parameter ID Values", gives the 14-bit numeric IDs for the reserved parameters. However, it does not specify the corresponding values of the FLAG_IMPL_EXTENSION and FLAG_MUST_UNDERSTAND flags. The implication is that either flag may be set independently on an occurrence-by-occurrence basis, but that would be a bad idea: first of all, if FLAG_IMPL_EXTENSION is set, the specification should assume nothing about the contents of the parameter. And second of all, most parameters have a value of FLAG_MUST_UNDERSTAND that could reasonably be specified up front.

    For example, and in particular, with respect to PID_EXTENDED, the text currently says: "The setting of the FLAG_MUST_UNDERSTAND bit in the 16-bit parameter ID shall be interpreted to apply to the extended parameter as well, not just to the 12 bytes of the PID_EXTENDED parameter itself." In other words, the flag is set based on the the must_understand attribute of a given member. This behavior is inappropriate, given that non-XTypes-conformant DDS implementations may receive extended parameters within discovery data: such implementations, if they do not see FLAG_MUST_UNDERSTAND set, will erroneously interpret the first four bytes of the (extended) data value as a parameter header, effectively corrupting the input data stream.

    Proposed Resolution:
    1. Clearly indicate that any parameter with FLAG_IMPL_EXTENSION set is outside of the scope of the specification. For a parameter to be recognized as one of the well-known values in the table, this bit must be set to zero.

    2. Add a column to table 27 for the FLAG_MUST_UNDERSTAND flag. Set the value of this flag as follows:

    • PID_EXTENDED: Yes. This will force non-XTypes-conformant implementations
      to discard data containing extended headers rather than parsing it
      incorrectly.
    • PID_LIST_END: Yes. This will force implementations to either recognize
      the end of the list or to discard the data. It will avoid a situation
      where an implementation might "skip" the end of the list and start
      parsing out of bounds.
    • PID_IGNORE: No. The whole point is to ignore this parameter.

    3. When writing data, the Service shall conform to the setting of FLAG_MUST_UNDERSTAND indicated above. When reading data, the Service should be robust to the opposite setting as well and accept the parameter nevertheless.

    4. Within the four-bit set of flags that has already been reserved within the extended parameter header, use the most-significant bit to indicate vendor-specific extensions and the second-most-significant-bit to represent the value of the must_understand value of a data member. These flags are parallel to the flags in the short parameter header and restore the flexibility lost by specifying up front the value of the corresponding flags in that header.

    5. Do not leave the contents of the other flags in the extended parameter header with junk contents; if a given flag's value is not specified by some (other) OMG specification, it should be set to zero.
  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Fix and clearly specify the values of flags for parameters reserved in section 7.4.1.2.1

    The values for flags FLAG_IMPL_EXTENSION and FLAG_MUST_UNDERSTAND are either not explicitly stated or are incorrect in section 7.4.1.2.1 "Interpretation of Parameter ID Values". We need to explicitly state the values and fix the values for extended parameters.

    To resolve modify teh specification according to the five steps described as "proposed resolution" in the issue description.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Extended PID is not clear enough what the 2 value lengths mean

  • Key: DDSXTY12-45
  • Legacy Issue Number: 17294
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Found by: Fernando Crespo, RTI (fernando@rti.com)
    Severity: Support Text

    Problem:
    Section 7.4.1.2.1, "Interpretation of Parameter ID Values", says the following directly beneath Table 27, "Reserved parameter ID values":

    "The length of this parameter shall be at least eight bytes: the first
    four bytes of the parameter data shall be interpreted as a set of four
    reserved bit flags followed by the 28-bit member ID; the second four
    bytes shall be interpreted as a 32-bit unsigned data length measured
    from the end of that field until the start of the next 16-bit parameter
    ID. If the 16-bit length is greater than eight, the additional contents
    are undefined and are reserved for future use by OMG specifications."

    The meaning is that the "data value" of the (shorter) parameter is in fact itself a longer parameter ID header, and the length indicated in the former header is in fact the length of that (longer) header only. The actual data value follows both headers, and its length (i.e. until the next parameter header) is given in the longer parameter header. Thus the total length of the parameter following the shorter header is the sum of the two lengths. The values of the flag fields are unspecified, as of the 1.0 specification, and reserved for future OMG specifications.

    Proposed Resolution:
    Update the description to more clearly reflect the data layout and add a figure to show it graphically.
  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clarify how to use PID_EXTENDED and add graphic

    The text describing how to use the PID_EXTENDED parameter ID needs clarification and a graphic.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Proposed type-naming scheme is far from Robust

  • Key: DDSXTY12-19
  • Legacy Issue Number: 18292
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The naming scheme proposed in section 7.2.2.3.4 is far from Robust, since the prefixes used to identify a collection may clash with the names of a user defined type. For example: what is a user has created a type called sequence_10, and he creates a sequence of 10 elements from this? The resulting typename would then become sequence_10_sequence_10, for which the parser will assume it is now a 2-dimensional sequence without element type.

    To make robust type names, we should use special characters that are not allowed in the definition of user-defined type names, e.g. sequence<10, sequence_10> or something similar.
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    After applying the resolution of Issue 100 this is no longer a problem

    The problem arises from the fact that TypeObject of every type had to have a name for every types, those names had to be unique and match across implementations .

    However DDSXTY12-100 modified the TypeObject and now anonymous collection types no longer need a name.

    The issue is merged with DDSXTY12-100 so that as part of that resolution the section that talks about naming the anonymous types can be removed as it is no longer needed.
  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

The encoding of strings and wide strings should be standardized

  • Key: DDSXTY12-113
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently, strings and wide strings are treated as mere arrays of chars and wide chars respectively, regardless of their character encoding configuration. This can lead to interoperability issues between systems that assume different encoding configurations implicitly.

    Java and C# languages use UTF-16 encoding, which forces any user who wishes to interoperate their C/C+ application with a Java/.Net application to manually make sure that their strings are encoded in the UTF-16 encoding. There is no API to convert between DDS_Wchar (4 bytes) and a platform’s wchar_t. By default the conversion is done by casting wchar_t to DDS_Wchar, and the fundamental problem is that when casting, after converting back to wchar_t the right character may not be retrieved if the publisher was using a different encoding than the subscriber.

    The proposal is to standardize the wire encoding for char and wide char. For chars we propose using UTF-8 and for wide chars we propose UTF-32 encoding. Along with this change, we should provide conversion APIs to in C/C++ to convert between wchar_t and DDS_Wchar to avoid issues between platforms. For Java and C# the middleware knows the wire encoding (UTF-32) and the native encoding (UTF-16) so the conversion can be done automatically for the user.

    We need to think about how to maintain backwards compatibility with applications that may be using other wire encodings today.
  • Reported: DDS-XTypes 1.1 — Wed, 13 Jul 2016 20:55 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    *Change the standard encoding of strings *

    See the discussion and attached documents in DDSXTY12-113 for rationale behind the decisions to:

    • Not specify an encoding for characters
    • Encode strings using UTF-8
    • Encode wide characters and strings using UTF-16
    • Change the type of WChar to Char16 from Char32.
  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Misleading formulation

  • Key: DDSXTY12-118
  • Status: closed  
  • Source: Siemens ( Pieter Van Vlierberghe)
  • Summary:

    Table 7.4 contains the following misleading statement:
    "It merely provides an alternative name by which to refer to another
    type."
    The point is that alias types are NOT introducing a new type, so "another type" is actually about the same type.
  • Reported: DDS-XTypes 1.1 — Mon, 25 Jul 2016 08:57 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Correct misleading statement

    See issue description on DDSXTY12-118.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Section 7.4.1.2.2 "Member ID-to-Parameter ID Mapping" is underspecified

  • Key: DDSXTY12-40
  • Legacy Issue Number: 17296
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Found by: Fernando Crespo, RTI (fernando@rti.com)
    Severity: Support Text

    Problem:
    The mapping of type member IDs to DDS-RTPS parameter IDs described in section 7.4.1.2.2, "Member ID-to-Parameter ID Mapping", will never result in FLAG_IMPL_EXTENSION being set. However, this is not stated explicitly.

    Proposed Resolution:
    Explicitly state that RTPS parameters corresponding to members of user-defined data types should never set FLAG_IMPL_EXTENSION.

    RTPS parameters corresponding to members of RTPS discovery-defined data types may or may not have FLAG_IMPL_EXTENSION set as defined by RTPS itself; the contract is unchanged. The mechanism by which an implementation generates that flag's value is unspecified.
  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Explicitly State when FLAG_IMPL_EXTENSION cannot be used

    Problem description in DDSXTY12-40. There is no text explicitly stating that FLAG_IMPL_EXTENSION will never be set on user-defined data types. This clarifying text should be added to section 7.4.1.2.2
  • Updated: Thu, 22 Jun 2017 16:42 GMT

ths XSD has many errors

  • Key: DDSXTY12-38
  • Legacy Issue Number: 18781
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Checked with Xerces, the XSD file has many errors which come from the lack of use of namespace.
    Lines: 37, 57, 60, 108, 111, 114, 136, 139, 143, 146, 241, 248, 267, 270, 277, 294, 370, 373, 435, 439, 442, 445, 448, 465, 495, 520, 523, 557, 560, 578, 581, 640
    Xerces error (for the first one: "filename"): "E [Xerces] src-resolve.4.1: Error resolving component 'fileName'. It was detected that 'fileName' has no namespace, but components with no target namespace are not referenceable from schema document 'http://www.omg.org/spec/DDS-XTypes/20120202/dds-xtypes_type_definition.xsd'. If 'fileName' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'fileName' has no namespace, then an 'import' without a "namespace" attribute should be added to 'http://www.omg.org/spec/DDS-XTypes/20120202/dds-xtypes_type_definition.xsd'."
    W3C reference:
    http://www.w3.org/TR/xmlschema11-1/#src-resolve
  • Reported: DDS-XTypes 1.1 — Mon, 17 Jun 2013 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Fixing Namespace in XSD files

    The original XSD schemas had multiple problems related to namespaces.

    To address these issues and make it simpler for other specifications to refer to the types define in the schema included in the specification, we are applying the so-called Chameleon Namespace Design, dividing the original schema into two different XSD files:

    1. dds_types.xsd, which can be used by applications to validate the types defined in an XML file. This file sets targetNamespace="http://www.omg.org/dds/".
    2. dds_types_definition.xsd, which includes all the type definitions without specifying a targetNamespace.

    Accompanying these two XSD files we include a non-normative XML file that demonstrate how to load dds_types.xsd with the right namespace to define a set of data types.

  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Mapping of Map type underspecified for C

  • Key: DDSXTY12-28
  • Legacy Issue Number: 18304
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Section 7.5.1.3.1 is referring to a C-mapping defined above. However, no C-mapping is mentioned so far, or it should refer to section 7.5.1.3.3
    Section 7.5.1.3.3 seems to suggest the C-mapping should be done as in section 7.4.1.1.4, which is a sequence of name-value pair structs. I can't imagine that this is a serious mapping proposal, but if it is is should be clearly specified as such
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clearly define a C mapping for Map types

    The C mapping for map types is not well-defined and needs to be added.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

C++ shared member representation breaks safety mechanisms of the struct containing it

  • Key: DDSXTY12-27
  • Legacy Issue Number: 18303
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    By clearly stating that a shared member must map onto a plain pointer, not a _var type or other smart pointer you are breaking the safety mechanisms that the C++ struct had inherently built into it, since on destruction or re-assignment the shared pointer may now leak away. The whole point of using _var types or other smart types was to prevent this from happening. I see no good reason why to make this one exception for shared pointers, which will make it much harder to predict the struct's behaviour.
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Define the language binding for shared members in C and C++

    Shared members are currently mapped to plain pointers in C and C++. This mapping prevents safety mechanisms, such as shared pointers in C++, from being used to automatically handle the memory management of these members. We are redefining the language mapping to add in these safety mechanisms and to allow the memory to be handled differently on the sending and receiving sides of an application.

  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:
    • External.hpp.docx 9 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Contradictions in the assignability for collection types

  • Key: DDSXTY12-9
  • Legacy Issue Number: 19269
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The OMG approved more-restrictive assignability rules (OMG Issue No 16368). However, some examples in the current spec (Version 1.0, February 2012, OMG Document number ptc/2012-03-26) remain unchanged and contradict those new rules.
    For example, on page 39, we say that a sequence of 10 integers is assignable from a sequence of 20 integers, although some objects may not be. This is no longer true according to the new rules--the destination sequence bound must be greater or equal than that of the source sequence (see Table 13 on page 40).

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Merged with DDSXTY12-119

    This issue has been subsumed by DDSXTY12-119. Therefore it should be merged into it.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Mapping of optional arrays in C/C++

  • Key: DDSXTY12-12
  • Legacy Issue Number: 19272
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Spec does not specify the C/C++ mapping of optional arrays.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Add an example of how to declare an optional array for C and C++

    Optional members already map to pointers in C and C++, but the syntax of declaring a pointer to an array of objects rather than an array of pointers to that type of object is tricky. We would therefore like to provide an example of how to do this.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Unify name used for Aggregate and Enumerated types

Built-in annotations should be in DDS namespace

  • Key: DDSXTY12-42
  • Legacy Issue Number: 17293
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Found by: Rick Warren, RTI (rick.warren@rti.com)
    Severity: Minor

    Problem:
    The IDL Type Representation uses so-called "built-in annotations" to attach metadata to type definitions. The hypothetical module in which these annotations are defined is unclear. On the one hand, all (other) types defined by the specification are in the DDS:: module. However, in the case of the built-in annotations, no module is specified.

    Proposed Resolution:
    Clearly indicate that all built-in annotations are notionally in the DDS:: module
  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Merge with DDSXTY12-34

    This can be treated together with DDSXTY12-34 which is already aligning annotations with the syntax of IDL4

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Rendering of UML diagrams in each of the figures is of poor graphical quality

  • Key: DDSXTY12-44
  • Legacy Issue Number: 17018
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The gradient shading rendered in each of the elements on a low-color image results in elements rendered as follows:

    The diagrams should be rendered either by using a higher-color format (such as png), or without the gradient rendering enabled.

    NB: To turn off the gradient shading in Enterprise Architect, go to the "Tools->Options" dialog. Under the "Diagram->Appearance" group:
    1) Deselect the "Show Gradient Fill for Paper Color" option
    2) Set the "Gradient Fill Direction for an Element" to "<none>"
  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    This issue was already fixed on previous revisions

    The issue was in the adopted submission but it was resolved in version 1.0 and subsequent versions.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

All IDL should use local interfaces

  • Key: DDSXTY12-43
  • Legacy Issue Number: 15946
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    All IDL should be using local interfaces, not regular interfaces, please add the keyword local to all interfaces

  • Reported: DDS-XTypes 1.0b2 — Thu, 13 Jan 2011 05:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    No change needed as local interfaces are being deprecated in IDL4

    The use of IDL in XTYPES needs to be re-examined in light of IDL4. Specially features that are not part of the "DDS Profiles" defined in IDL4.

    XTYPES uses local interfaces to define the DynamicData and DynamicType interfaces. It also uses them to define annotations. XTYPES uses regular interfaces to define the TypeSupport interface. IDL4 local interfaces belong to the CORBA-Specific building block. They are not part of the "DDS Profiles"
    XTYPES uses (non-local) interfaces to define TypeSupport. This is in the RPC over DDS profile of IDL4.

    XTYPES uses valuetypes to describe parts of the DynamicData and DynamicType interfaces. These are part of the Building Block ValueTypes which is not in any of the the "DDS Profiles"
    Note that the fact that XTYPE uses a specific IDL building block (BB) does not mean that implementations of XTYPES that would end up having to support that BB. As long as that dependency on the BB is limited to describing interfaces that are "built into" the XTYPES DDS APIs there is no problem. If however they form part of the code being generated from user-defined datatypes then we would really have an issue.
    The issue with "local" interfaces is that IDL4 considers them deprecated and for that reason it included them in the CORBA module.

    The IDL4 view is that interfaces are just a contract specification, whether they are local or not is more up for interpretation by a particular use of the IDL. Hence this is specified via annotations like @service(DDS) or @service(CORBA). Therefore if an interface does not state anything it can be interpreted as a "local" interface...

    So while the current use of local interfaces and valuetypes on XTYPES appears fine, it may make sense (in light of IDL4) to actually remove all use of "local" interfaces replacing them with regular interfaces...

    However at this point it seems best to leave things as they are and wait for the alignment with IDL4...
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Extended parameters should be aligned the same as non-extended ones

  • Key: DDSXTY12-39
  • Legacy Issue Number: 17297
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Found by: Fernando Crespo, RTI (fernando@rti.com)
    Severity: Support Text

    Problem:
    The section on the parameterized CDR Data Representation (DDS-XTypes 7.4.1.2) contains a reference to the DDS-RTPS specification for the definition of the parameter list data structure. However, it does not specifically refer to the instructions in DDS-RTPS on how to handle alignment within such a structure. This omission may confuse some implementers, especially with respect to extended parameters, which should follow the same alignment rules as RTPS-traditional "short" parameters.

    Proposed Resolution:
    Add the following paragraph to the end of section 7.4.1.2.1, "Interpretation of Parameter ID Values":

    "The alignment rules for extended parameters shall be the same as
    those for non-extended parameters, which are defined in [RTPS]
    Section 9.4.2.11."
  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Specify alignment of Extended Parameters

    Accept the suggestion from the issue description.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

IDL annotation syntax fails to specify scoping rules for annotation type names

  • Key: DDSXTY12-36
  • Legacy Issue Number: 19145
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    There is no clear specification of whether annotation types are part of the same naming scope as other IDL declared types or not.
    The Type System Model described in chapter 7.2.2 seems to indicate they are all declared in a single naming scope as an annotation member could have "any enumeration type". In IDL this would require them to have the same naming scope as IDL declared enum types.
    As a consequence it would mean that annotation type names could clash with type names used by 'regular' local interface definitions.
    It would also seem to indicate that annotation application syntax would have to support scoped naming like "@Test::MyAnnotation()".
    Clear specifications for all these considerations are missing from the spec.

  • Reported: DDS-XTypes 1.1 — Sun, 15 Dec 2013 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Combine with DDSXTY12-34

    This problem is partly caused by the use of "interfaces" to define annotations.
    However annotation names should never conflict with any other types (interfaces or otherwise) as their use is proceeded by the character "@".
    IDL4 new syntax for declaring annotations makes it more obvious by using the keyword "@annotation" to define annotations.
    Since legacy IDL compilers are no expected to parse the annotation declarations it seems that this issue will only affect the new compilers.

    IDL4 does declare scopes for applying annotations, but all the builtin annotations (which include the XTYPES ones) are defined in the global scope.

    Therefore this issue should be solved the same way as XTYPE12-34 ideally aligning the syntax with that of IDL4.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Deserialization issues with Extensible types

  • Key: DDSXTY12-10
  • Legacy Issue Number: 19270
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Spec: DDS-XTYPES
    Document Number: ptc/2013-12-18
    Revision Data: 2013-12-18
    Version 1.2
    Nature: Enhancement
    Severity: Significant
    Title: Deserialization issues with Extensible types

    Problem description

    The XTypes specification uses "traditional" CDR to represent extensible types on the wire.

    The usage of "traditional" CDR encapsulation poses a problem in some scenarios where a DataReader with an extensible type "A" receives samples coming from a DataWriter with an extensible type "B" and where type "B" contains a subset of the members in type "A" (base to derive relationship). For example:

    struct TypeB  {
   char member1;
};
struct TypeA {
  char member1;
  short member2;
};

    At first sight, the usage of traditional CDR is enough to deal with the scenario described above:

    The deserialize operation for type "A" will deserialize member1. After that, the function will try to deserialize member2 but it will find that there are no more bytes in the input stream. In the absence of a value for member2, the deserialize function will initialize this member with its default value 0.

    So far so good.

    The problem is that the previous algorithm works fine only when the number of bytes in the input stream (serialized sample published by the DataWriter) is exactly equal to the number of bytes produced by the serialization function for Type "B". In our example, this number is 1. Unfortunately, in some scenarios, including our example, the number of bytes in the input stream will include some padding bytes that are added to guarantee that the RTPS DATA sub-message containing the sample published by the DataWriter has a size divisible by 4.

    The PSM in the RTPS specification requires that each sub-message is aligned in a 32-bit boundary with respect to the start of the RTPS message.

    In our example, the deserialization function for Type "A" will receive a stream with 4-bytes (1 for the char in member1 and 3 bytes for padding). Because of that, the previous algorithm may end up initializing member2 with padding bytes. Since padding bytes may have a value different than 0 the member2 value will not necessarily be equal to zero.

    Affected types

    The previous issue may occur when all the following conditions are met:

    • The top-level types used by DataReader and DataWriter are extensible.
    • The DataReader type is assignable from the DataWriter type and it contains more fields at the end (see example above).
    • The last primitive member on the DataWriter type is: char, octet, boolean, short, unsigned short, or string. Other types are not a problem because they require 4-byte alignment and the middleware will not have to add padding bytes at the end of the DATA message.
    • The first primitive member on the DataReader type after the last primitive member on the DataWriter type is: char, octet, boolean, short, unsigned short. Other types are not a problem because they require 4-byte alignment. The deserialization function will not use the padding bytes at the end of the DataWriter's sample to initialize the contents of the first primitive member on the DataReader type.

    For example:

    struct TypeB {
  char member1;
};
struct TypeA {
  char member1;
  short member2;
};

    The previous two types will be problematic.

    struct TypeB {
  long member1;
};
struct TypeA {
  long member1;
  short member2;
};

    The previous two types will be OK.

    struct TypeB {
 string member1;
};
struct TypeA {
  string member1;
  short member2;
};

    The previous two types may be problematic or not depending on the value of member1.

    struct TypeC {
 char member1;
};
struct TypeB {
  TypeC member1;
};
struct TypeA {
  TypeC member1;
  short member2;
};

    The previous two types will be problematic since the first primitive member of TypeB (including nested types) is a char.

    Are Mutable Types Affected?

    This problem does not affect mutable types directly. However, it may affect mutable types when they contain members of extensible types.
    For example:

    struct TypeB {
  char member1;
};
struct TypeBMutable {
  TypeB member1;
}; //@Extensibility MUTABLE_EXTENSIBILITY
struct TypeA {
  char member1;
  short member2;
};
struct TypeAMutable {
  TypeA member1;
}; //@Extensibility MUTABLE_EXTENSIBILITY

    Mutable members are encapsulated using parametrized CDR representation.

    Each member, within a mutable type is simply a CDR-encapsulated block of data. Preceding each one is a parameter header consisting of a two-byte parameter ID followed by a two-byte parameter length. One parameter follows another until a list-terminating sentinel is reached. Parameter headers must be aligned to a 4-byte boundary. If the serialized length of a member value is not divisible by 4, the implementation will add some padding bytes.

    The problem is that the length field of a mutable member represents the data length measured from the end of that field until the start of the next parameter ID (this is part of the XTypes specification). Therefore, the deserialize function for the member type may receive as input a stream containing the padding bytes.

    IN Implementation Changes

    To reduce the number of scenarios in which we run into the problem we will initialize the padding bytes to zero. This includes the padding bytes at the end of the serialized sample, and the padding bytes at the end of a mutable member serialization.

    By doing this the following scenario would not be an issue anymore

    struct TypeB {
  char member1;
};
struct TypeA {
  char member1;
  short member2;
};

    In the previous example the deserialize function would use padding bytes to initialize member2. However, since these padding bytes have a zero value, the value assigned to member2 would be the right value.

    With the previous fix we would have issues only when the first primitive member on the DataReader type is char, octet, boolean, short, unsigned short and in addition it is the discriminator of a union.

    For example:

    struct TypeB {
  char member1;
};
union UnionA switch (short) {
  case 0:
     long member1;
  default:
     long member2;
};
struct TypeA {
  char member1;
  UnionA member2;
};

    To detect the previous problem, we will change the type compatibility algorithm so that it reports an error when the issue occurs.

    Potential Changes to the XTypes Specification

    Resolving the extensibility problem described above for all the scenarios will likely require changes to the XTypes specification.

    For the top-level types, we propose to use two bits from the options bytes following the encapsulation identifier to identify the padding.
    For example:

    struct TypeB {
  char member1;
};

    In the previous example a sample for Type B would be encapsulated as follows:

    CDR_BE x x x x x x x x x x x x x x 1 1
    member1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

    Notice that the value '11' in the options indicates the number of padding bytes.

    For mutable members we propose to change the interpretation of the length field to not include the padding bytes to the next header.
    For example:

    struct TypeB {
  char member1;
};
struct TypeBMutable {
  TypeB member1; //@ID 1
}; //@Extensibility MUTABLE_EXTENSIBILITY

    In the previous example TypeBMutable would be encapsulated as follows:

    CDR_BE x x x x x x x x x x x x x x 0 0
    ID 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
    member1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    PID_LIST_END 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

    Notice that the length field for the member with ID 1 is set to 1 instead of 4

    Forward compatibility

    The changes described in the previous section should not affect backward compatibility with previous XTYPES compatible versions.

    Let's assume two XTYPE versions:

    • One DDS compliant with XTPES 1.1 and already deployed
    • A future DDS compliant with XTPES 1.2 incorporating the changes to the XTypes spec described in the previous section

    TOP-LEVEL Types:

    • XTYPES 1.1 DataReaders should ignore the option bits set by the XTYPES 1.2 DataWriters
    • XTYPES 1.2 DataWriters receiving samples from XTYPES 1.1 DataReaders will assume that there are no padding bytes

    MUTABLE Members

    • XTYPES 1.1 DataReaders will receive members with a header where the data length is smaller than expected. This should not be a problem because the DataReader will always align the beginning of the next parameter to a 4-byte boundary. Therefore, the padding bytes will be skipped by the align operation.
    • XTYPES 1.2 DataReaders will receive members with a header where data length includes padding. That should be fine as well. The align operation to go to the beginning of the next parameter will be a NOOP.
  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Fix the deserialization issues related to padding

    Modify the XTYPES specification to use the option bits that follow the encapsulation options to encode the number of padding bytes. Follow what is stated in the issue description. In addition padding bytes should be set to zero.

    Clarify/state that the lengths for both short and long member IDs encode the exact length of the serialized member without accounting for padding bytes.
  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Issues with UNIONS assignability rules

  • Key: DDSXTY12-5
  • Legacy Issue Number: 19265
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The IDL specification (pre-XTypes) allows the declaration and usage of unions that do not cover all possible discriminator values. For example:

    union Z switch(boolean)
{ 
  case TRUE: 
    short s; 
};

    In the previous union, it is possible to set the discriminator to FALSE. When that occurs, the union's value is composed solely of the discriminator value FALSE.
    The new XTypes specification has several issues concerning unions like the one before:
    It is not clear that you can set the discriminator to a value that is not associated with an union member. For example, can you set the discriminator to FALSE in the union Z?.
    The assignability rules may break assignability of a union object to itself. For example, with the previous UNION, if a received sample has a discriminator value of FALSE, it will be dropped according to the following rule in the Behavior column in table 15:
    If the discriminator value does not select a member in T1 then the T2 object is unassignable to T1.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Duplicates DDSXTY12-119

    This issue is being merged into the a broader issue (DDSXTY12-119) that seeks to make the assignability rules simpler and less restrictive. The resolution of DDSXTY12-119 issue includes changes to the Union assignability rules which addressed the concerns DDSXTY12-5 raises.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Applicable key types not clearly specified

  • Key: DDSXTY12-20
  • Legacy Issue Number: 18293
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    In section 7.2.2.3.5.6 it is stated that every member of a struct can act as key. If that is indeed the case, then keys could be set on attributes of type sequence or union for which the resulting behaviour is not clearly specified. (For example, how to compare a key from a sequence of length 1 to a key of a sequence of length 2? How to compare unions that have the same discriminator but different branch values? How to compare unions that have different discriminator values that map onto the same branch?)

    Either setting keys on sequence and union attributes should be prohibited, or the resulting behaviour should clearly be specified.
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Specify members of type Union, Array and Sequence can be keys

    Unions types can either be keyed or not. If keyed, the only union attribute that can form part of the key is the discriminator as it is the only attribute guaranteed to always be there.

    To indicate a union has a key the discriminator is annotated with the @key. See 7.3.1.2.2 (the switch in the union can have annotations).

    If the Union had not declared a key (its discriminator as key). Then it is unkeyed. And when used as a member and marked as key the whole value (discriminator included) would form the key.

    Allow BitSet, Arrays and Sequence member to be used as keys. Those are simple. But not maps. These could be added later if the need arises.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

DataRepresentationQosPolicy is making the application responsible for transport

  • Key: DDSXTY12-29
  • Legacy Issue Number: 18306
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Using a QosPolicy like DataRepresentationQosPolicy is breaking the abstraction between application and transport. This is fine if the application is managing its own transport, but not if the transport is implemented by some external service. We see no reason why this policy should be implemented as part of the XTypes specification as cleary it has no relationship to type extensibility.
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    Issue was withdrawn by the originating company

    Upon discussion during RTF the issue was withdrawn by the originating company.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

A @Version annotation shall be added

  • Key: DDSXTY12-17
  • Legacy Issue Number: 18145
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The X-Types specification does not provide any way of attaching version information to topic types. This is unfortunate as this information is quite essential to help debug running systems by identifying which version of the information model each element is working with.

    As a consequence a new annotation @Version should be added for topic types. A possible definition of this annotation is shown below:

    @Annotation
    local interface Version

    { attribute unsigned long major; attribute unsigned long minor; attribute unsigned long patch_level; }

    ;
  • Reported: DDS-XTypes 1.1 — Mon, 8 Oct 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Add a @Version annotation

    The RTF discussed what the purpose of the @version annotation was and it was determined the value comes from situations were there is a single authority/governance body that controls the type system.

    In this situation, having some "version" annotation that can distinguish intentional changes/evolutions of a type versus some error can be a useful "system integration" aid. The idea is that each time someone modifies a type in a system it would tag it with some "application meaningful" (it could be a version number like major.minor.revision, or a date, or some other label). Then duding deployment when compatibility of types between DataWriter and DataReaders is examined this additional tag is available.

    Type compatibility is determined using the "assignability rules" this done independent of the version number/tag. In addition to this:

    • If the tags are different (or absent in one side) then there no additional things to do.
    • If the tags are the same but the types are not identical, then this could trigger some warning/errors coming via DDS status/listeners. The fact that the same version tag was used indicated the application was trying to use the same version of the types for that writer/reader. The fact that they did not match indicates that there was some process error and somehow the two applications ended up with different types.

    There was agreement in the RTF that this was a useful feature, but leaving the version as an "unstructured" string. Without adding version numbers, dates, etc. It just needs to be checked for equality and it is up to the people defining the type system to create their own convention.

    The RTF discussed whether it made change to have a different behavior at the DDS level. The most "obvious" one suggested was to force "mismatched type" error for types that were assignable/compatible but not identical if their version tag was the same. Idea is similar to the compiler option of "error on warnings". Make it harder for people to deploy systems with this type of inconsistency. At the same time it was agreed that most of the benefit of this feature could be obtained using a tool that would monitor the types and detect that inconsistency. And this would not require a forceful change in matching behavior.

    The RTF agreed to add the @version annotation and describe the intended use, but not force any implementation behaviors. It would be up to vendors to provide tools around this or support a "error" behavior on those types with identical version and non-identical structure... If in the future the vendors determine that the "fail" behavior is important to support and must be made interoperable then it can easily be added without breaking deployed system
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Key order should be defined using the @Key annotation

  • Key: DDSXTY12-16
  • Legacy Issue Number: 18144
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The X-Types specification had left under-defined mechanism to be used for specifying the order of key attributes.

    The solution adopted by the FTF was to simply use the member ID to define such an order, but this is not optimal.

    We strongly suggest to define @Key annotation as follows:

    @Annotation
    local interface Key

    { attribute unsigned long value; attribute boolean value default true; }

    ;

    Where the value attribute is used to define a total order among the key attributes.

  • Reported: DDS-XTypes 1.1 — Mon, 8 Oct 2012 04:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    No change as it could be done as a vendor extension without affecting portability/interoperability

    Ordering of the keys for the purpose of sorting is something that can be handled internally by each vendor since there are no APIs in DDS that specify an order relative to the key order (e.g. the read_next_instance() specifies an order "by instance handle" which is not explicitly mapped to keys).
    In other words, a vendor could add an annotation e.g. @key_order to define the order and use that to optimize how samples are stored in the cache but it would not affect portability or interoperability.

    Making it part of the key definition itself would render types as incompatible as a result of something that seems more like a local optimization of a cache in a specific application which would not affect applications in other nodes.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Allow empty structures

  • Key: DDSXTY12-14
  • Legacy Issue Number: 19274
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Allow empty structures as part of the XTypes spec. XTYPES spec it does not require structures to have any members. It is not explicit about this but it does say they
    can have any number of members (including zero). The IDL syntax. XTYPES uses IDL as one of the ways to express types so if the IDL grammar specifies made empty structures
    illegal we would have an inconsistency between what the X-TYPES type-system says and what the IDL grammar supports...
    Looking at the IDL syntax in the X-Types it defines:
    <struct_type> ::= <struct_header> “

    {” <member_list> “}

    ”

    The <member_list> refers to the production on the IDL spec (X-TYPES
    only lists the new productions or the ones that are modified from
    IDL), the <struct_type> is modified in XTYPES to support inheritance,
    hence its appearance in the XTYPES duc but the <member_list> is
    unchanged.

    In IDL 3.5 <member_list> is defined as:

    <member_list>::=<member>+

    Which does seem to indicate that empty structures are not supported.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Closed; Out Of Scope — DDS-XTypes 1.2
  • Disposition Summary:

    The change should be applied to IDL 3.5/IDL4

    Supporting empty structures is desired to facilitate the mapping from other data-models that may support them in that sense the type system in XTYPES is already doing the right thing and it is IDL the one that needs to change...

    Given that the plan is to remove the IDL syntax extensions from XTYPES and have XTTPES reference IDL4+ instead. It is best to close this issue here with "NoChange" and instead file an issue with IDL4 to add support for empty structures.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

member ID algorithm flawed

  • Key: DDSXTY12-23
  • Legacy Issue Number: 18298
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    In section 7.3.1.3.1 is is stated that when explicitly assigning memberID's to some attributes (but not to all attributes), that:

    "In such cases, implicit values are assigned in a progression starting from the most-recently specified ID (or an implicit value of zero for the first constant, if there is no previous specified value) and adding one with each successive member."

    This algorithm could result in the same memberId being assigned multiple times. Consider the following example:

    struct A

    { long x; //@id 2 long y; //@id 1 long z; }

    ;
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Add clarifying text to section 7.3.1.3.1

    The main part of this issue is addressed in DDSXTY12-18. Therefore, the only thing we need to do here is clarify the member ID rules.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

IDL annotation syntax does specify how to use Any member type

  • Key: DDSXTY12-35
  • Legacy Issue Number: 19144
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    According to the Type System model in chapter 7.2.2. the Any type is allowed as an annotation member type.
    The IDL syntax does however not specifiy if and how that type could ever be used in IDL.
    Since standard IDL has now way to declare an Any value it seems logical that the IDL syntax should specify the Any type off limits for annotation types declared in IDL.

  • Reported: DDS-XTypes 1.1 — Sun, 15 Dec 2013 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clarify the IDL type "Any" is not part of the DDS-XTYPES type system

    This issues seems is the result of a confusion in the interpretation of the word "Any" when it is used in Section 7.2.2.3.6 (Annotation Types). That section says that the members of annotation types are restricted to certain types.
    These are:

    • Any Primitive type
    • Any String type of Char8 or Char32 elements
    • Any enumerated type

    In the above the word "Any" is used as an adjective and not to mean the type represented by the IDL "Any" keyword.

    To avoid this ambiguity the issue resolution will reword the bullet points removing the word "Any".
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Annotation member default declaration not compatible with Legacy IDL

  • Key: DDSXTY12-34
  • Legacy Issue Number: 19143
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    The DDS XTypes IDL Type representation spec defines an "alternative" annotation declaration for use with legacy IDL. This alternative syntax is however not compatible with legacy IDL compilers because it does not take into account that legacy attribute declarations do not support the 'default' value declaration used in the annotation syntax.
    To be compatible it should be specified that for the legacy syntax the attribute default declaration is not allowed.

  • Reported: DDS-XTypes 1.1 — Sun, 15 Dec 2013 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Merge with DDSXTY12-122

    DDSXTY12-34 is to be addressed as part of the broader issue of aligning the XTypes specification with the IDL4 Specification (DDSXTY12-122).

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Builtin topics not backward compatible

  • Key: DDSXTY12-33
  • Legacy Issue Number: 18310
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Builtin topics are not backward compatible with the DDS1.2 spec (not even according to the rules of the Extensible types spec itself).

    As an example, the BuiltinTopicKey_t array has been extended from 3 elements to 4 elements. This breaks compatibility with respect to non-xTypes compliant versions of a DDS product, and it is not cleared up why the keyfield suddenly required this extra element.
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Modify definition of BuiltinTopicKey_t to align it with RTPS spec

    In appendix D modify the BuiltinTopicKey_t to be wire-representation compatible with the RTPS spec.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Expose assignability options for ignoring member names and sequence lengths

  • Key: DDSXTY12-48
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The XTypes spec is too restrictive because it does not allow ignoring member names and sequence length in type compatibility. The spec should provide such flexibility. TypeEnforcementQoSPolicy should be extended to allow more flexibility.
  • Reported: DDS-XTypes 1.1 — Fri, 9 Oct 2015 20:59 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Include support for ignoring member names

    Ignoring member names in type consistency enforcement is a desirable QoS policy. Extended the TypeConsistencyEnforcementPolicy with a boolean condition. Updated section 7.6.2.3.2 and Annex D.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Keyhash computation not well-defined for mutable types

  • Key: DDSXTY12-47
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Keyhash computation is not specified precisely enough. For instance, for mutable types it is not clear whether to use short/long parameter IDs and for PID_SENTINEL whether to set must-understand bit = 1/0? As a result, the keyhash for the same key may be different from different vendors.
  • Reported: DDS-XTypes 1.1 — Fri, 9 Oct 2015 20:53 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Update keyhash computation for mutable types

    Removed ambiguities from keyhash computation algorithm for mutable types. Specifically the following ambiguities existed.

    1. Whether to use short/long parameter encapsulation
    2. What's the value of must-understand bit in PID_SENTINEL.

    Both ambiguities are avoided using the revised algorithm.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

specify language-specific bindings may exist

  • Key: DDSXTY12-46
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Include a sentence in section 7.5 Language Binding that language-specific PSMs might overrule some or all of the language binding rules specified below.
  • Reported: DDS-XTypes 1.1 — Thu, 10 Sep 2015 21:56 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Added clarification

    Added clarification in section 7.5 first paragraph.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

One sentence split in two bullets

  • Key: DDSXTY12-37
  • Legacy Issue Number: 19587
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    As part of section 7.2.2.3.7.1 the last two bullets should be one, so change

    • The string “*” (an asterisk) shall indicate that
    • text applies to all programming languages.

    to

    • The string “*” (an asterisk) shall indicate that text applies to all programming languages.

  • Reported: DDS-XTypes 1.1 — Tue, 26 Aug 2014 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    *Incorporated editorial changes *

    Editorial change in Section 7.2.2.3.7.1 bullet #4

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Spec should allow any value for the Optional flag in TypeObject union members

  • Key: DDSXTY12-6
  • Legacy Issue Number: 19266
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    By definition, union members are always optional. The spec should allow implementations to decide whether union members include the optional flag as part of the TypeObject member flags. In any case, implementations should ignore that flag for equality and type-compatibility purposes.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Duplicates DDSXTY12-11

    Duplicates DDSXTY12-11
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Optional flag in TypeObject union members

  • Key: DDSXTY12-13
  • Legacy Issue Number: 19273
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    By definition, union members are always optional. The spec should allow implementations to decide whether union members include the optional flag as part of the TypeObject member flags. In any case, implementations should ignore that flag for equality and type-compatibility purposes
  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Duplicates DDSXTY12-11

    Duplicates DDSXTY12-11
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Optional flag in TypeObject union members

  • Key: DDSXTY12-11
  • Legacy Issue Number: 19271
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    By definition, union members are always optional. The spec should allow implementations to decide whether union members include the optional flag as part of the TypeObject member flags. In any case, implementations should ignore that flag for equality and type-compatibility purposes.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Indicate the TypeObject union sets the member's isOptional flag to false.

    Union members shall have the IS_OPTIONAL set to 0 since the semantic is that if a member is selected then it has to be present.

    In the future we may want to support the @optional annotation on the union member to indicate that the selected member could be omitted. This is currently not supported in the IDL syntax. However if this were to change in the future, the future version of XTYPES could support it by setting the IS_OPTIONAL flag to 1 for those members.

    Furthermore indicate only the discriminator member can be declared as a key member for the union.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

The description for union types are not complete

  • Key: DDSXTY12-4
  • Legacy Issue Number: 19264
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    For Union Types the xTypes spec does not handle the following two cases:
    What is the criteria to select a value for the discriminator when a default case is specified?
    What happens if a default case label is specified when the set of case labels completely covers all the possible values for the discriminator.
    Note: This information is stated in section 1.9 (Mapping for Union) of the IDL to Java spec.
    If the branch corresponds to the default case label, then the simple modifier for that
    branch sets the discriminant to the first available default value starting from a 0 index
    of the discriminant type.
    It is illegal to specify a union with a default case label if the set of case labels
    completely covers the possible values for the discriminant*. It is the responsibility of
    the Java code generator (e.g., the IDL complier, or other tool) to detect this situation
    and refuse to generate illegal code.
    Proposal to determine what is the default value for a union discriminator:
    If there is no default case value, the default discriminator value is the lowest value associated with any union member. If the discriminator type is an enumeration, the value is the enumerator with the lowest ordinal.
    if there is default case value:
    For integer, boolean, byte, char, wchar: The default discriminator value is the first available value starting from a 0 value of the discriminant type.
    For enumerations: The default discriminator value is the first enumerator in the order declared in the enumeration that is not associated with any case value.

  • Reported: DDS-XTypes 1.1 — Thu, 27 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Duplicates DDSXTY-12-5

    Duplicates DDSXTY-12-5
  • Updated: Thu, 22 Jun 2017 16:42 GMT

lookup_topicdescription semantics make it unusable

  • Key: DDSXTY12-32
  • Legacy Issue Number: 18309
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Section 7.6.3.2 specifies that lookup_topicdescription returns 1 matching representation. On multiple matches, an arbitrary representation is returned.

    This is not helpful in any way for an application trying to access a certain representation. Either its signature should be changed to return a sequence of topic representations, or it should cyclically go over each representation and return 1 at a time, so that subsequent invocations may return different representations.
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clarified semantics of lookup_topicdescription

    Added clarifications in section 7.6.3.2. and enhanced PIM-to-PSM mapping for this operation as described in the revised text.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Multiplicity mismatch between TypeName and TypeObject

  • Key: DDSXTY12-30
  • Legacy Issue Number: 18307
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The builtin topics have 2 ways to identify the type to which they apply: a string called type_name and a TypeObject alled type. The string can only relate to 1 type, while the TypeObject could refer to more than 1 type.

    If the type_name is not uniquely identifying a type, then what is the use of having a type_name in the builtin topics for Reader and Writer? The topic_name already refers to a DCPSTopic sample that has a similar type_name.

    Furthermore, in the spec it is assumed that Readers/Writers just make the TypeObject refer to just 1 type, while the Topic could make it refer to more than one. This is not orthogonal, so wouldn't it be better to make a TypeObject refer to 1 type and give the DCPSTopic a sequence of TypeObjects instead?
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    ChangeType object to refer to a single TypeId

    Modify Annex B to correct the multiplicity of the TypeId. The TypeObject struct (Annex B) shall be updated to include just a single typeid instead of a sequence of typeids.

    The TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData already includes an optional TypeObject member. The specification shall include a guideline/warning that absent TypeObject it is not possible to ensure type compatibility
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Shareable members underspecified

  • Key: DDSXTY12-21
  • Legacy Issue Number: 18295
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    There are some questions regarding shared members that should clearly be addressed in this section:

    • Are shareable members always implemented as pointers in the way optional members are?
    • If so, can a shareable member be NULL?
    • If so, then is a shareable member not by definition also an optional member?
    • What will happen when I pass object graphs, even when the last sentence warns against this? (e.g. marshaling into 1 big blob anyway, passing an error, etc.)
    • May a shareable member be, or contain a key?
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Added clarification for Shareable members

    Updated the description in section 7.3.1.3.4.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Circular dependencies across types should be allowed

  • Key: DDSXTY12-8
  • Legacy Issue Number: 19268
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The XTypes spec does not make clear whether or not circular dependencies across types are allowed. They should be allowed.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Added clarification for Shareable members

    The necessary clarifications for this issue are added in section 7.3.1.3.4 Shareable Data through a different issue DDSXTY12-21.

    Essentially, circular dependencies are allowed but the m/w is not required to detect or warn against such uses.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

TypeId calculation errors/corrections

  • Key: DDSXTY12-7
  • Legacy Issue Number: 19267
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Section 7.3.4.1.2 Type Hierarchy in the XTypes spec explains how to calculate the TypeId for a given type.
    The description provided contains errors and ambiguities that must be resolved.
    1.- The spec explains that the TypeId of a constructed type is calculated by serializing the type in big-endian CDR data representation. However, the TypeId itself is part of the Type (ArrayType, StructureType). We cannot serialize without the TypeId and we cannot get the TypeId without serializing.
    To resolve this problem I am setting the Type's TypeId to the following value before serializing:
    RTI_CDR_TYPE_OBJECT_NO_TYPE (for the discriminator)
    RTI_CDR_TYPE_OBJECT_NO_TYPE_ID (for the union value)
    2.- The Type (ArrayType, StructureType) also has a member containing the type name (not fully qualified). The value of this member is used to calculate the TypeId. Since the name is not fully qualified, two identical types within different modules will have the same TypeId. The question is whether or not the type name should be used as part of the TypeId calculation.
    If the type name must be used as part of the calculation and it discriminates, then we will have to use the fully qualified name. Otherwise two identical types within different modules would get same TypeId.
    If the type name should not be used as part of the calculation then we can set it to the empty string for TypeId calculation purposes.
    According to the XTypes spec:
    "To allow types to refer to one another unambiguously, a given TypeId value shall uniquely identify a type within the TypeLibrary contained by a TypeObject object and in any other Type Libraries contains recursively therein. It shall have no narrower scope. There is no restriction that a type's definition must occur a TypeId reference to it; there is no concept of a forward declaration in this Type Representation."
    Therefore, two types within the library should not contained the same TypeId.
    3.- Also, the serialization in BigEndian of the TypeObject is not guaranteed to be the same across different DDS vendors since the TypeObject itself is a mutable type and therefore it requires parametrized encapsulation for its members. The choice of extended versus not extended parameter encapsulation may be different across different DDS vendors.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    New TypeID computation algorithm

    The previous algorithm included in the specification is not implementable because it causes inadvertent recursive dependency of type-id on themselves. The new computation of the TypeId has been defined such that all vendors compute the same values for the same types. See section 7.3.4.1.2 in the specification document.

  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

XML type description not orthogonal and not consistent

  • Key: DDSXTY12-26
  • Legacy Issue Number: 18302
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The XML description of a type seems cumbersome and not orthogonal. I have lots of questions regarding it. Why do we propose 2 separate XML representations (Valid and Well-formed) that both have obvious flaws instead of 1 XML representation that satisfies the requirements of both representations? PrismTech has written an extensive proposal on how represent the types in XML that is both valid, well-formed and orthogonal. I would propose to give that proposal a thought. (Can't attach the document to this ticket, but I will gladly make it available. Angelo also has access to that document
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clarified both xml data representations

    Resolutions applied: Added the revised text in section 7.4.2.2
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Type system severely underspecified

  • Key: DDSXTY12-25
  • Legacy Issue Number: 18301
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    In section 7.3.4.1.2 it is specified how to calculate the type ID for a given type. However, this algorithm heavily depends on the Type layout presented in Appendix B, which is not further explained. I have lots of questions about this algorithm, and am wondering if alternative mechanisms should not be considered instead.

    1) Where does the hash that identifies the typeID of a constucted type come from?

    It states that it comes from the Big Endian CDR respresentation of the type, which is an IDL representation of the model specified in Appendix B. However, this data model is not further explained, and far from mature and orthogonal. It looks like we created a pretty ad-hoc type system rather than deriving one from a well-designed meta-model with a minimal set of powerful transformation primitives.
    There is a lot of existing documentation on how to set up a proper type-system. I suggest we consult some best-practices instead of re-inventing the wheel here.

    2)The basis of the TypeObject consists of 2 fields, each having their own sequence. How the 2 sequences correlate is not further explained. The only thing that is explained in section 7.6.2.2 is that the the_type member of the TypeObject contains all types associated with the corresponding entity (1 for reader/writer, more for topic). I think it would be better to take this sequence outside TypeObject and give Topic a sequence of TypeObjects instead.
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    TypeId algorithm proposed

    See RTI's TypeId proposal attached to Issue #7: TypeId calculation errors/corrections. TypeId computation has been unambiguously specified.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

TypeObject semantics underspecified and inconsistent

  • Key: DDSXTY12-24
  • Legacy Issue Number: 18300
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Section 7.3.4.1 specifies that a TypeObject can include just a single TypeLibrary while in section 7.3.4.1.1 it is claimed that a TypeObject can recursively contain other TypeLibraries.

    Of course this is confusing: which is it?

    Also does a typeID need to be globally unique or just in the TypeLibrary in which it is contained?

    Finally, and even more important, since the TypeObject may recursively refer to other (existing) types by their typeID, it is difficult to communicate the meta-data to a node that has no a-priori knowledge about it. The current TypeObject representation is compact, but only able to check whether two existing representations are compatible. It can't be used to drive meta-data based tooling a logger or a service that connects the DDS to a database.
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Added clarification for TypeLibrary

    Added clarification in section 7.3.4.1 that a single TypeLibrary which may recursively contain more TypeLibrary objects
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Definition of "strongly assignable" seems to be used inconsitently

  • Key: DDSXTY12-22
  • Legacy Issue Number: 18297
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    if strongly assignable according to section 7.2.4 means that both types should be mutable, then why is the union in Table 15 (section 7.2.4.5, fifth bullet in 2nd column) talking about strong assignability for a T1 that is final or extensible?

    • Probably the definition for strongly typed is flawed, and should be about NON-mutable types.

    Generally speaking, the overall wording of the subject regarding strong assignability could is causing more confusion than it is clearing things up, and could use some big improvement.

    Lots of usecases regarding this subject are underspecified, for example:

    • If a type T1 is assignable from a type T2, and T1 has a non-optional member that is not represented in T2, it takes the default (non-configurable) default.
      How can I see the difference between a T1 with a member, that happens to be the default, and a T1 without that member?
      Since 0 is a very common value, it does not seems like a good candidate for default in this case.
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clarified definition of strongly assignable

    Updated section 7.2.4 with clearer definition of strongly assignable. Also updated union_type in Table 15 section 7.2.4.5 Aggregation Types.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

TypeId union is missing NO_TYPE from the possible values of the discriminator

  • Key: DDSXTY12-3
  • Legacy Issue Number: 19263
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The TypeId union declaration in Annex B is missing the value NO_TYPE as one possible discriminator. In addition, the use cases for the usage of that value are not documented.
    Assuming that we add a TypeId paramater to the endpoint information in addition to the type object. See issue "Send TypeId independently of the TypeObject". In a situation in which no type object or type id paramaters are found, we could indicate that to the user by providing a NO_TYPE TypeId as part of the PublicationBuiltinTopicData or SubscriptionBuiltinTopicData.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Merged with DDSXTY12-7

    Merged with issue DDSXTY12-7, which adds NO_TYPE case in _TypeId union.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Send TypeId independently of the TypeObject

  • Key: DDSXTY12-2
  • Legacy Issue Number: 19262
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Sending large TypeObjects is often an issue in discovery. Often times, the complete TypeObjects are not necessary as TypeId might just do the trick when exact matches are expected. Therefore, sending just the typeid is a good optimization.

    Therefore, add new discovery parameter in Publication and Subscription BuiltInTopicData to send the TypeId independently of the type object.

    Two use cases:
    1. Even if we cannot find type object at least we can verify typeId
    2. Allow a separate mechanism to get the TypeObject. This will help to reduce bandwidth

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Incorporated new TypeId algorithm

    A new typeid computation algorithm was added in section 7.3.4.1.2. Updated built-in topics with an optional typeid field. See revised text for details.
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Topic incosisstency only considered for incompatible types, not for incompatible qos

  • Key: DDSXTY12-31
  • Legacy Issue Number: 18308
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    What if 2 topics have the same type, but different Qos? Would that still trigger an INCONSISTENT_TOPIC status or not? The spec does not say anything about this.
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    Discussed clarifications

    The TF discussed clarifications and no changes are needed.

    Currently, the spec is clear about when inconsistent_topic status is raised. Only type (typeobject when present otherwise typename) is considered before raising the inconsistent topic status. One possibility to incorporate QoS in the mix would be to create yet another kind of status for topics. Right now it has only one. For DR and DW, there’s already inconsistent_requested_qos and inconsistent_offer_qos statuses. May be the new status could be a variant of those. It can’t be any of those however because (1) TopicQoS does not contain all QoS (2) TopicListener is a separate inheritance branch and (3) offered/requested semantics are not knowable at topic level because we don’t know what kind of entity might be created (so we can’t do as good a job as we do for entity’s inconsistent_requested/offered_qos statuses.)
  • Updated: Thu, 22 Jun 2017 16:42 GMT

Specification document cleanup

  • Key: DDSXTY12-1
  • Legacy Issue Number: 19261
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    1. Remove references to type signature in XType specification: The concept of type signature has been removed from the XTypes specification. See OMG Issue No: 16561. However there are still references to it in the latest spec.
    List of references:
    Figure 39 - Dynamic Type Support
    Annex D: DDS Built-in Topic Data Types - Remove references to equivalent_type_name and base_type_name from PublicationBuiltinTopicData, SubscriptionBuiltinTopicData and TopicBuiltinTopicData

    2. Replace the definition of the_type within TypeObject from TypeIdSeq to _TypeId:
    In the final version of "OMG Issue No: 16097" the spec allows association of one type to an endpoint to simplify implementations.
    However, the spec kept the member "the_type" as a sequence instead of going back to a single element.

    3. Error in IDL definition of TypeObject: Definition of MapType, SequenceType, and StringType and in Annex B is marked as EXTENSIBLE but it should be MUTABLE.

    4. The "type" member in SubscriptionBuiltinTopicData and PublicationBuiltinTopicData should have "DynamicType" type instead of "TypeObject"

    Proposed Solution: Make the suggested changes.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Incorporated corrections

    Document cleanup performed removing dangling elements and incorrect IDL structures.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Inconsistencies and missing items

  • Key: DDSXTY12-158
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 7.2.3, Table 12 in the rows for "Collection Types", "Enumerated Types", "String Types", and "Primitive Types" should state that "For these types the extensibility kind has no effect."

    In the submission document, Table 21 "IDL Built-in Annotations" does not list where the annotation @hashid can be applied.
    Also, the @id annotation is can be applied to both Structure members and union members (except union discriminator), so it should be moved to the second row on the table.

    In Annex B in the IDL comment for AppliedBuiltinMemberAnnotations refers to “@hash_id” as opposed to “@hashid”, which is the actual annotation name. Every reference to “@hash_id” should be modified to refer to "@hashid."
  • Reported: DDS-XTypes 1.1 — Thu, 16 Mar 2017 00:38 GMT
  • Disposition: Deferred — DDS-XTypes 1.2
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force
  • Updated: Thu, 6 Apr 2017 14:10 GMT

Relationship between begin/end coherent changes and presentation.coherent_access==true

  • Key: DDS15-202
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We observe differences between DDS vendors related to begin/end_coherent_changes and presentation.coherent_access==true. The question is how begin_coherent_changes() should behave when presentation.coherent_access==false. Some vendors are silent and the operation just works, some return a RETCODE_ERROR saying begin_coherent_changes may only be called when presentation.coherent_access==true. To our idea the DDS spec should be precise so that users who separate code and qos (like DDS4CCM) do know what behavior they get
  • Reported: DDS 1.4 — Tue, 28 Mar 2017 15:05 GMT
  • Updated: Fri, 31 Mar 2017 16:55 GMT

No specification for unregister_type for TypeSupport interface

  • Key: DDS15-201
  • Status: open  
  • Source: DSTO ( Michael Mathers)
  • Summary:

    Currently there is no specification on the TypeSupport interface for an unregister_type operation as a companion to the register_type operation. This leads to variation between vendor implementations with respect to the lifecycle of type registrations. In the case of component-based architectural approaches it is desirable to be able to unload components to free resources. With no clear ability to unregister a type, it is not safe to unload component libraries while a container or manager of DDS infrastructure may still hold a reference to a no longer used type.
  • Reported: DDS 1.4 — Sun, 15 Jan 2017 23:13 GMT
  • Updated: Thu, 26 Jan 2017 21:03 GMT

Builtin Access Control - Inadequate Validity datatypes in permissions schema

Remove key_fields

  • Key: DDS4CCM11-14
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We propose to remove key_fields completely from the DDS_TopicBase connector. The knowledge which fields are a key is specified in IDL using annotations and shouldn't be set again on the connector instance. This is duplicate information which could only lead to inconsistencies and possible problems. Until now we also have not seen any use case which require this information to be available as StringSeq as part of a connector instance.
  • Reported: DDS4CCM 1.1 — Mon, 7 Nov 2016 12:19 GMT
  • Updated: Fri, 18 Nov 2016 20:33 GMT

Syntax for Topic Names

  • Key: DDS15-200
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    For portability & interoperability it is necessary to know what the valid syntax of topic names can be, including valid characters. Some vendors support characters like '.' '/', ':' while others don't.

    The spec should make clear which characters are supported by all vendors

    Note that Appendix B does include a TOPICNAME syntax, but this section appears only related to content filters it is not clear if this would limit a Topic name in general. In Appendix B it says:

    TOPICNAME - A topic name is an identifier for a topic, and is defined as any series of characters ‘a’, ..., ‘z’, ‘A’, ..., ‘Z’, ‘0’, ..., ‘9’, ‘-’ but may not start with a digit.

    This seems limiting and also the "-" seems like an odd choice or perhaps a typo. "_" would be a more natural choice...

    Also it seems very restrictive to not allow things like "." or "/" or ":" given that large systems would want to organize their topic names and take advantage of this.
  • Reported: DDS 1.4 — Fri, 21 Oct 2016 14:29 GMT
  • Updated: Fri, 21 Oct 2016 14:37 GMT

Clean-up encode_serialized_payload and decode_serialized_payload

Typos in DDS Security

  • Key: DDSSEC_-166
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This issue gathers miscellaneous types in the spec

    For example, in 8.8.3 (DDS Entities impacted by the AccessControl operations) first paragraph is says "five types" when it should say "six types"
  • Reported: DDS-Security 1.0b1 — Thu, 11 Feb 2016 19:36 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix miscellaneous typos and issues in spec.

    The purpose of this issue is to provide the ability to correct small typos and issues that remain after application of the resolution of ll other issues in the FTF.
    It is a catch-all for small unrelated tasks that avoids having to reopen each issue or the complication of managing many issues separately
  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Document security error conditions and log messages

Update Figures to match new submessages introduced in DDSSEC-14

Use standard Key Derivation functions from the SharedSecret

  • Key: DDSSEC_-164
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    It appears that using the HMAC() by itself is not recommended in the case the shared secret Z comes from a diffie-hellman exchange because the DH-generated secrets are not random enough. It would be OK with the RSA approach if the secret was generated using a cryptographically-strong random number.

    The accepted way to derive keys from a "shared secret" is called a HMAC-based Key Derivation Function. As it turns out there is a great paper on this (http://eprint.iacr.org/2010/264.pdf) which was the basis for a recent IETF (informational) standard:
    https://tools.ietf.org/html/rfc5869

    This paper describes the pitfalls of using just a hash-function to generate keys from with DH shared secrets. It also criticizes some of the NIST recommendations because they are also "weak".

    The recommendation is to follow what https://tools.ietf.org/html/rfc5869 as it is a well stablished approach used by IKE and it is better than the simple HMAC the specification is using.

    Their recommended approach is along the lines of HMACsha256(Challenge_A # Challenge_B # Cookie, SharedSecret). However there is a twist. Rather than repeat this approach using different Cookies they recommend using the result of the above just as a first step, and then "expand on it" as in:

    Note: First argument to HMAC-sha256() function is the key material.

    PRK = HMAC-sha256(NonSecretSalt, SharedSecret)
    T(0) = "" (empty-zero length string)
    Cookie = "
    T(1) = HMAC-sha256(PRK, T(0) | Cookie | 0x01)
    T(2) = HMAC-sha256(PRK, T(1) | Cookie | 0x02)
    T(3) = HMAC-sha256(PRK, T(2) | Cookie | 0x03)

    The resulting material T = T(1) | T(2) | T(3) | T(4)
    is then used to get the needed keys and salts.
    In our case we would need: KxKey, KxSalt

    We could use, following RFC 5869:

    NonSecretSalt = Sha256(Challenge_A # Challenge_B # "key exchange")
    PRK = HMAC-sha256(NonSecretSalt, SharedSecret)

    KxKey = HMAC-sha256(PRK, KxKeyCookie | 0x01)
    KxSalt = HMAC-sha256(PRK, KxSaltCookie | 0x02)

    In addition it seems like our SessionKeys, SessionSalt, and SessionHMacKey may suffer from the same problem. they are using the secret (MasterKey) as the key to the HMAC instead of as the "payload".
    Perhaps we should also modify this to align it with RFC 5869

    This change would be limited to:

    Table 50 ( KeyMaterial_AES_GCM_GMAC for BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader )

    And Section 9.5.3.3.3 (Computation of SessionSenderKey and SessionReceiverSpecificKey)
  • Reported: DDS-Security 1.0b1 — Thu, 11 Feb 2016 14:25 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Use a HKDF to obtain the key material from the DH shared secret

    Follow the approach recommended in IETF RFC 5869https://tools.ietf.org/html/rfc5869
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Remove spurious references to PermissionCredential

  • Key: DDSSEC_-178
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The PermissionCredential type was removed from the spec by issues and 166. However, there are still a couple of references to it that should be removed.

    8.3.2.8 (Table 20), 8.3.2.8.10, 8.4.2.6.1, 8.8.1 (item 5), 8.8.2.2 (item 16 and 18), 8.8.6 (item 1 and 2), 9.4.3 (Table 47)

    The dds_security_plugin.idl operation set_permissions_credential_and_token()
  • Reported: DDS-Security 1.0b1 — Mon, 15 Feb 2016 18:47 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Remove the spurious references to PermissionCredential

    See issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Additional Enhancement to Mutual Authentication following ISO/IEC 9798-3 standard

  • Key: DDSSEC_-176
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Note: this issue was raised by Cyril Dangerville (THALES).

    Despite the enhancement in DDSSEC_-146 the Authentication protocol still has an "identity misbinding issue".

    The protocol after DDSSEC_-14 is applied can be summarized as:

    Revised (recommended) protocol:

Participant1                                                       Participant2


                               ParticipantDiscovery (pdata)
                  <------------------------------------------------------------

Message 1: 
c_1, Hash(c1), challenge_1
--------------------------------------------------------------------------->

                   Message 2: 
c_2, Hash(c_2) | dh_2 | challenge_1 | challenge_2, 
                  	Sign(Hash(c_2) | dh_2 | challenge_1 | challenge_2 ) )   
       <------------------------------------------------------------------------------

Message 3:
 Hash(c_1), dh_1, challenge_1, challenge_2,
         Sign(Hash(c_1) | dh_1 | challenge_1 | challenge_2)
-------------------------------------------------------------------->

    This protocol is vulnerable to Unknown Key Share (UKS), aka identity misbinding attack. Let participant P3 (with c_3 = id_3, etc.) be an attacker in the middle.
    P3 intercepts message 1 and replaces with the message below before transfering to P2:

    c_3, Hash(c_3), challenge_1

    P2 then replies message 2 and P3 transfers the message to P1 unchanged.

    P1 replies message 3 but P3 intercepts again and replaces with the message below before transfering to P2:

    Hash(c_3), dh_1, challenge_1, challenge_2,
		Sign_P3(Hash(c_3) | dh_1 | challenge_1 | challenge_2)

    In the end, P1 and P2 are the only ones sharing the secret (K) based on dh_1 and dh_2 as only P1 and P2 know the private values. However, P2 believes its peer to be P3 since he received (and could validate) only the certificate and signature of P3. Therefore, P2 believes he is sharing a key with P3, whereas he is actually sharing with P1. From then on, any subsequent message arriving to P2 and authenticated under K - or keys derived from it - will be interpreted by P2 as coming from P3. Note that this attack does not result in a breach of secrecy of the key (since the attacker does not learn, nor influence the key in any way), but it does result in a breach of authenticity since the two parties to the exchange will use the same key with different understandings of who the peer to the exchange is.

    To avoid this the protocol should be modified to something like this:

    Protocol flow:
P1 <- P2: ParticipantDiscovery (pdata)                                                                                             
P1 -> P2: c_1, challenge_1, dh_1
P1 <- P2: challenge_1, c_2, challenge_2, dh_2,
           SignP2(Hash(c_2)|challenge_2|dh_2|challenge_1|dh_1|Hash(c_1))
P1 -> P2: challenge_1, 
            SignP1(Hash(c_1)|challenge_1|dh_1|challenge_2|dh_2|Hash(c_2))
  • Reported: DDS-Security 1.0b1 — Mon, 15 Feb 2016 01:11 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify authentication protocol to avoid the Identity Misbinding Attack

    The authentication protocol should be modified to make it robust to the Identity Misbinding Attack. The approach shall follow what was suggested in the issue description with some minor additions that make it easier to implement in an interoperable manner.

    The modified protocol (including suggested optional properties) is:
    The notation [ xxx ] indicates properties that may be present for troubleshooting purposes but otherwise can be omitted.

    P1 <- P2: ParticipantDiscovery (pdata)
P1 -> P2: c_1, [Hash(c_1)], challenge_1, dh_1
P1 <- P2: c_2, [Hash(c_2)], challenge_1, challenge_2, dh_2, [Hash(c1)], [dh_1]
          SignP2(Hash(c_2) | challenge_2 | dh_2 | challenge_1 |dh_1 | Hash(c_1) ) 
P1 -> P2: [Hash(c_1)], [Hash(c_2)], [dh_2], [dh_1], challenge_1, challenge_2,     
          SignP1(Hash(c_1) | challenge_1 | dh_1 | challenge_2 | dh_2 | Hash(c_2))
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Enhance security of the Authentication Handshake

  • Key: DDSSEC_-146
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The mutual authentication handshake described in 9.3.2 does not validate the ParticipantBuitinTopicData exchanged via discovery. This can create some vulnerability.
    In addition the messages contain Information that is not being by the sender nor confirmed by the receiver. This includes the IdentityCertificates and Permissions, and other data. This is not considered best practices. Nominally each message in the handshake should tie-in to the previous message.
  • Reported: DDS-Security 1.0b1 — Mon, 8 Feb 2016 13:14 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Enhance Authentication handshake

    Enhance Handshake to follow best practices from NIST FIPS-196
    http://csrc.nist.gov/publications/fips/fips196/fips196.pdf
  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

More explicit Authentication and Permissions configuration

  • Key: DDSSEC_-14
  • Legacy Issue Number: 19777
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §8.3.2.9.3 the IdentityCredential parameter passed to the validate_local_identity operation is described as following:
    "The nature and configuration of the credential is specific to each Authentication plugin implementation"

    In §8.3.2.1:
    "The specific content of the IdentityCredential shall be defined by each Authentication plugin specialization and it may not be used by some Authentication plugin specializations. The interpretation of the contents as well as the mechanism used to pass it to the Authentication plugin shall be specified by each plugin implementation.”

    In §9.3.2.1:
    "The DDS:Auth:PKI-RSA/DSA-DH plugin shall set the attributes of the IdentityCredential objects as specified in the table below."

    So it seems it's up to the AuthenticationPlugin to create the IdentityCredential (it's the only one to know how to set/interprate the attributes). Moreover, we could imagine the credential to be provided by various ways which are specific to the AuthenticationPlugin implentation (e.g. security hardware as USB Credential Provider or fingerprint reader...)

    Nevertheless, the middleware is supposed to pass the IdentityCredential to the validate_local_identity operation. But it has no way to create or get this IdentityCredential object.

    We suggest to replace this IdentityCredential parameter with the DomainId and the QoS Policies of the DomainParticipant to validate. Thus, the AuthenticationPlugin has a way to make distinction between 2 local DomainParticipant to validate, and can internally applies different credentials.

  • Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Specify how to configure authentication and access control plugins. Also specify which cryto families shall be supported

    The resolution of this issue should is to define the configuration of the Authentication and Permissions plugins more explicitly such that they can be “plugged” in across vendors without requiring changes to the core DDS.

    Doing this requires a general-purpose mechanism to configure the plugins from DDS. This is accomplished by adding a PropertyQosPolicy to the DomainParticipantQos consisting of Name-Value pairs. This reuses the “Property_t” type already defined in 7.2.1 making it a “first-class” element within the DomainParticipantQos and also visible via discovery.

    The parameters to Authentication::validate_local_identity() and AccessControl::validate_local_permissions() need to be adjusted to receive those properties.

    Support for the following crypto families should be specified:
    Identity/Authentication: RSA-2048 and Elliptic Curve prime256v1with
    SharedSecret: Diffie-Hellman and Elliptic Curve Diffie-Hellman
    Encryption, MAC: AES128-GCM (Gallois Counter Mode) AES128-GMAC
  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Use standard format for subject name in permissions and identity

  • Key: DDSSEC_-168
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The example permissions file has subject name as:

    <subject_name>/C=US/ST=CA/L=Sunnyvale/O=ACME Inc./OU=CTO Office/CN=DDS Shapes Demo/emailAddress=cto@acme.com</subject_name>

    This uses the non-standard notation "/" to separate fields whereas in the X.509 certificates it will be "," this will fore a normalization to compare the subject names.

    It would be better to change that format in the XML so it also uses ","
  • Reported: DDS-Security 1.0b1 — Fri, 12 Feb 2016 02:37 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Change Certificate Subject Name element separator from "|" to ","

    Perform modifications shown in revised text section.
  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Use standard format for subject name in permissions and identity

  • Key: DDSSEC_-169
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The example permissions file has subject name as:

    <subject_name>/C=US/ST=CA/L=Sunnyvale/O=ACME Inc./OU=CTO Office/CN=DDS Shapes Demo/emailAddress=cto@acme.com</subject_name>

    This uses the non-standard notation "/" to separate fields whereas in the X.509 certificates it will be "," this will fore a normalization to compare the subject names.

    It would be better to change that format in the XML so it also uses ","
  • Reported: DDS-Security 1.0b1 — Fri, 12 Feb 2016 02:38 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Change subject name delimiter from "/" to ","

    Do as requested in issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

(meta)data_protection_kind takes incorrect values

  • Key: DDSSEC_-127
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 9.4.1.2.5.5 says:
    "This element may take the binary values TRUE or FALSE"
    This is wrong, it should say: "The metadata protection kind element may take three possible values: NONE, SIGN, or ENCRYPT".

    Likewise it says:
    "EndpointSecurityAttributes shall be set to the binary value specified in the “data protection kind" element"

    This is wrong, it should say: "EndpointSecurityAttributes shall be set to FALSE if the value specified in the “metadata protection kind" element is NONE and shall be set to TRUE otherwise".

    Similar issues occur in section 9.4.1.2.5.6.
  • Reported: DDS-Security 1.0b1 — Tue, 29 Dec 2015 22:23 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix (meta)data_protection_kind description

    Apply changes suggested in issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT

The example governance does not validate with the governance XSD

  • Key: DDSSEC_-130
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Example machine readable file example_governance.xml has two problems:
    (1) Inside the <domain_rule> it uses an the element name "allow_unauthenticated_participants" whereas the Governance XSD calls this element "allow_unauthenticated_join"

    (2) The governance document specifies the DomainRule as <xs:sequence> of various elements. These forces the elements to appear always in that exact order. The example puts the elements inside the <domain_rule> in a different order

    The (1) should be corrected in the example_governance.xml file. The element name "allow_unauthenticated_join" appears in the spec in several places and it seems simpler to retain it rather than change it. Although it does make it somewhat inconsistent with the name used in the ParticipantSecurityAttributes.

    Either reorder the elements in the example_governance.xml inside<domain_rule> or else change the dds_security_governance.xsd to use <xs:all> as this construct allows the elements to appear in any order and still preserves the constraint that each element can appear at most once.
  • Reported: DDS-Security 1.0b1 — Sun, 3 Jan 2016 19:33 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Make Governance consistent with example and Attribute naming

    Modify governance to make it consistent with naming of ParticipantSecurityAttributes and the example governance document: allow_unauthenticated_join -> allow_unauthenticated_participants

    Also address issue http://issues.omg.org/browse/DDSSEC_-135 by using xs:boolean instead of BooleanKind
    And the suggested change to the schema for <domains> that appeared in the comments to http://issues.omg.org/browse/DDSSEC_-131 but could not be done there because 131 was already closed.
  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Builtin Access Control - Use of 'TopicExpression' in Domain Governance

  • Key: DDSSEC_-133
  • Legacy Issue Number: 19874
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    The Domain Governance schema defines a 'TopicExpression' as same as 'string' (simple inheritance). Why not use the 'string' type directly instead?
    Also the description in 9.4.1.2.5.1 says it is a set of topic names but does not say how we specify such a set. This is better defined in later sections such as 9.4.1.3.2.3.1.2. I suggest to add the description of topic name expressions from 9.4.1.3.2.3.1.2 to 9.4.1.2.5.1, as it is more precise:

    "The Topic name expression syntax and
    matching shall use the syntax and rules of the POSIX fnmatch() function as specified in POSIX 1003.2-1992, Section B.6 [38]"

  • Reported: DDS-Security 1.0b1 — Tue, 5 Jan 2016 05:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Add description of TopicExpression to 9.4.1.2.5.1

    See issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Builtin Access Control - Useless BooleanKind in Domain Governance Schema

Typo - KxKeyCookie/KxCookie and KxMacCookie/KxMacKeyCookie

  • Key: DDSSEC_-144
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    In 9.5.2.1.2, the formula to compute KxKey and KxMacKey use the terms KxCookie and KxMacCookie, whereas the table 42 just below uses the terms KxKeyCookie and KxMacKeyCookie. They are the same thing, therefore names should be aligned.

    Regards,
    Cyril
  • Reported: DDS-Security 1.0b1 — Wed, 27 Jan 2016 16:22 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Addressed already by DDSSEC-14

    Addressed already by DDSSEC-14
  • Updated: Tue, 12 Jul 2016 14:45 GMT

adjusted_participant_key renamed to effective_participant_key without notice

  • Key: DDSSEC_-143
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    In 8.3.2.9.3, the validate_remote_identity method is defined to have an out parameter called adjusted_participant_key. In the built-in implementation (Authentication plugin) of this method, this parameter is no longer mentioned, or it is but with a different name: effective_participant_key. Are these both the same thing?
    If they are, then the spec should use the same name in both places .

    Regards,
    Cyril
  • Reported: DDS-Security 1.0b1 — Wed, 27 Jan 2016 16:13 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *Rename effective_participant_key to be adjusted_particpant_key *

    Rename effective_participant_key to be adjusted_particpant_key

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Typo CryptoTranformIdentifier instead of CryptoTranSformIdentifier

  • Key: DDSSEC_-142
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    CryptoTransformIdentifier is mispelled CryptoTranformIdentifier ('s' is missing) in various locations:

    • 8.5.1.5 - title of Table 20
    • 9.5.2.3 - transform_id type in SecureDataHeader
    • 9.5.3.3.1 - table 46 - in description of decode_rtps_message and preprocess_secure_submsg and decode_serialized_data
  • Reported: DDS-Security 1.0b1 — Wed, 27 Jan 2016 15:57 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Replace Tranform with Transform

    See Issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Construction of HandshakeRequestMessage is unclear

In DomainGovernance, what is default behaviour if a domain+topic topic_rule is not found

  • Key: DDSSEC_-75
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    What happens if no topic_rule (governance) is found for the 'domain+topic' ?

    This impacts behavior of: get_endpoint_sec_attributes()
  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:10 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Extend Governance doc to support default domain rules and explain what happens when no Domain or Topic rule matches

    Extend syntax for Domain Rule to accept domain expressions such that we can construct default domain rules.

    This can be done extending the content of the <domain_id> element to allow certain expressions (e.g. <domain_id>ALL</domain_id>) or to be ranges (e.g. <domain_id> 0-10 </domain_id>) or lists (e.g. <domain_id> 0,10,20 </domain_id>) or combinations (e.g. (<domain_id> 0-5, 10, 20-40 </domain_id>).

    Explain that rules are applied in the same order they appear in the governance document and the first one that matches is "selected"

    Explain that if no Domain or Topic rule is found then the operation under consideration should give a "permissions error"
  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Contents of KeyMaterial_AES_CTR_HMAC structure unclear

  • Key: DDSSEC_-78
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    How are the 'master salt', 'master session_salt' and 'master hmac_salt' values conveyed in the KeyMaterial_AES_CTR_HMAC data? Need a more complete description of the structure members.

    Also, recommend renaming/adding OctetSeq members to make it more clear:

    typedef long MasterKeyIdType;

Structure members of the DDS::Security::KeyMaterial_AES_CTR_HMAC
    @Extensibility(EXTENSIBLE_EXTENSIBILITY)
    struct KeyMaterial_AES_CTR_HMAC {
      CipherKind        cipher_kind;
      HashKind          hash_kind;
      MasterKeyIdType   master_key_id;
      OctetSeq      master_key;
      OctetSeq      master_salt;         /* here */
      OctetSeq      master_session_salt; /* here */
      OctetSeq      master_hmac_salt;    /* here */
    };
  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:22 GMT
  • Disposition: Closed; No Change — DDS-Security 1.0
  • Disposition Summary:

    With resolution of Issue14 this is no longer an issue

    With resolution of Issue14 this is no longer an issue
  • Updated: Tue, 12 Jul 2016 14:45 GMT

In DomainParticipant permissions XSD: minOccurs of in

  • Key: DDSSEC_-139
  • Legacy Issue Number: 19880
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In XSD for the DomainParticipant permissions document, the "Rule" complexType has a sequence of "publish" element with minOccurs="1".
    I don't see any reason to forbid a Rule with no "publish" element (e.g. a Grant with an allow_rule only allowing subscriptions).

    The minOccurs for the sequence of "publish" element should be "0".

  • Reported: DDS-Security 1.0b1 — Tue, 12 Jan 2016 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Merge into DDSSEC-134

    This issue is merged into DDSSEC-134 because that one is already modifying the Permissions XSD
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Parameters of get_endpoint_sec_attributes

  • Key: DDSSEC_-36
  • Legacy Issue Number: 19812
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The §8.4.2.7.23 doesn't describe the parameters of the get_endpoint_sec_attributes operation.

    Moreover, in Table 18, only a PermissionHandle is specified as in parameter for this operation. As specified in §8.4.2.4 the PermissionHandle is associated to a DomainParticipant.

    But, according to §8.4.2.7.23, the get_endpoint_sec_attributes operation shall return the information related to the endpoint (DDS DataReader or DDS DataWriter). Thus, this operation miss some parameter(s) to indicate this endpoint.

  • Reported: DDS-Security 1.0b1 — Thu, 25 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Split get_endpoint_sec_attributes() into two: get_reader_sec_attributes() and get_writer_sec_attributes() also add parameters for Topic, partitions, and DataTags

    The get_endpoint_sec_attributes() needs additional information to determine the name of the Topic, the Partitions, and the DataTags. The Topic name is already needed to implement the logic of the builtin plugins. The others are expected to be needed for future standard plugins or those implemented by vendors or users.

    Likewise the get_endpoint_sec_attributes() needs to distinguish whether the Endpoint is a DataReader or DataWriter. One of the suggested approaches to this was to split it into two methods: get_reader_sec_attributes() and get_writer_sec_attributes(). This seems the cleanest and it is aligned with other plugin operations which already have separate methods for datareaders and datawriters.

    This change impacts Table 18 (AccessControl Interface). It renames get_endpoint_sec_attributes to get_datarwriter_sec_attributes and adds a row for get_datareader_sec_attributes

    It renames 8.4.2.7.23 (Operation: get_endpoint_sec_attributes) to Operation: get_datarwriter_sec_attributes

    It adds 8.4.2.7.24 Operation: get_datareader_sec_attributes

    It modifies the rest of the document replacing get_endpoint_sec_attributes with either get_datarwriter_sec_attributes or get_datareader_sec_attributes. Also clarifies better the use of these operations.
  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Parameters of get_participant_sec_attributes

  • Key: DDSSEC_-34
  • Legacy Issue Number: 19809
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The §8.4.2.7.22 doesn't describe the parameters of the get_participant_sec_attributes operation.

  • Reported: DDS-Security 1.0b1 — Thu, 25 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Add more description of get_participant_sec_attributes

    Add a description of the parameters to get_participant_sec_attributes to section 8.4.2.7.22 (Operation: get_participant_sec_attributes)

    Add an entry to section 9.4.3, Table 40 (Actions undertaken by the operations of the bulitin AccessControl plugin) that describes get_participant_sec_attributes
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Builtin Authentication plugin: RSA or DSA ?

  • Key: DDSSEC_-33
  • Legacy Issue Number: 19800
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In Table 28 (p.152) it seems the Builtin Authentication plugin should accept RSA or DSA.
    But in §9.3 it's specified that the DomainParticipant must be configured with RSA material only (2048-bit RSA public key of the CA and the 2048-bit RSA public and private keys of the DomainParticipant)

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Addressed by DDSSEC-146

    This issue is addressed by DDSSEC_-146
  • Updated: Tue, 12 Jul 2016 14:45 GMT

PermissionsCredential in validate_local_permissions

  • Key: DDSSEC_-27
  • Legacy Issue Number: 19792
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §8.4.2.7.1 the PermissionsCredential parameter passed to the validate_local_permissions operation is described as following:
    "The nature of the credential is specific to each AccessControl plugin implementation."

    In §8.4.2.1:
    "The specific content of the PermissionsCredential shall be defined by each AccessControl plugin specialization and it may not be used by some AccessControl plugin specializations. The interpretation of the contents as well as the mechanism used to pass it to the AccessControl plugin shall be specified by each plugin implementation."

    In §9.4.2.1:
    "The DDS:Access:PKI-Signed-XML-Permissions plugin shall set the attributes of the PermissionsCredential objects as specified in the table below"

    So it seems it's up to the AccessControl plugin to create the PermissionsCredential (it's the only one to know how to set/interprate the attributes).

    Nevertheless, the middleware is supposed to pass the PermissionsCredential to the validate_local_permissions operation. But it has no way to create or get this PermissionsCredential object.

    We suggest to replace this PermissionsCredential parameter with the DomainId and the QoS Policies of the DomainParticipant to validate. Thus, the AccessControl plugin has a way to make distinction between 2 local DomainParticipant to validate their permissions, and can internally create different credentials.

  • Reported: DDS-Security 1.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Merged into DDSSEC_-14

    This issue was resolved by DDSSEC_14
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Plugins per-process or per-participant ?

  • Key: DDSSEC_-29
  • Legacy Issue Number: 19794
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The full §8 doesn't specify if the DDS middleware shall instantiate the plugins once per-process or once per-local-Participant.
    The plugins operations suggest 1 plugin per-process (see Autentication operations where the local Participant's identity is always passed as a parameter. Or the Access Control operations where the local Participant's permissions_handle is always passed as a parameter.)

    But in §9.4 it is specified that "Each DomainParticipant has an associated instance of the DDS:Access:PKI-Signed-XMLPermissions plugin". It is not specified for the other builtin plugins.

    The §8.1 should clearly states that the decision to instantiate 1 plugin per-process or 1 plugin per-participant is implementation dependant. And the §9.4 should not specify that "each DomainParticipant has an associated instance of the DDS:Access:PKI-Signed-XMLPermissions plugin", as it is possible to implement this plugin with 1 instance per-process only.

  • Reported: DDS-Security 1.0b1 — Thu, 11 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Specify plugins are instantiated per DomainParticipant

    In section 8.1 add a subsection that specified plugins are instantiated per DomainParticipant. Also state that the way the plugins are configured and bound to the DomainParticipant is implementation-specific

    Clarify that validate_local_identity, validate_local_permissions, and check_create_participant are called prior to the DomainParticipant being enabled.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Default permissions for partitions are too broad

  • Key: DDSSEC_-122
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section 9.4.1.3.2.3.1.2 (Publish Section) in the second to last paragraph it says:

    If there is no <partitions> Section then the rule allows publishing on any partition.

    Similarly in section 9.4.1.3.2.3.1.3 (Subscribe Section) in the second to last paragraph it also says:

    If there is no <partitions> Section then the rule allows subscribing on any partition.

    This seems to give too broad default permissions for 'allow rules' which can result on users incorrectly allowing what they did not intend.
    It is considered best-practices for allow rules to require explicit listing of what is allowed and default to not allow what not explicitly stated.

    Therefore it is suggested that the following changes are made.


    In section 9.4.1.3.2.3.1.2 (Publish Section) in the second to last paragraph replace
    If there is no <partitions> section then the rule allows publishing on any partition.
    With:
    If there is no <partitions> section then the rule allows publishing only in the "empty string" partition. See PARTITION QosPolicy entry in Qos Policies table of section 2.2.3 (Supported Qos) of the DDS Specification version 1.4.


    In section 9.4.1.3.2.3.1.3 (Subscribe Section) in the second to last paragraph replace:
    If there is no <partitions> section then the rule allows subscribing on any partition.
    With:

    If there is no <partitions> section then the rule allows subscribing only in the "empty string" partition. See PARTITION QosPolicy entry in Qos Policies table of section 2.2.3 (Supported Qos) of the DDS Specification version 1.4 .
  • Reported: DDS-Security 1.0b1 — Sun, 27 Dec 2015 15:29 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify 9.4.1.3.2.3.1.2 and 9.4.1.3.2.3.1.3 specify that if no partitions are specified permissions are limited to the empty partition

    As noted in the issue description it is safer for the allow behavior to default to narrower permissions. For this reason the changes suggested in the issue description should be applied.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Builtin Access Control - Useless BooleanKind in Domain Governance Schema

  • Key: DDSSEC_-135
  • Legacy Issue Number: 19876
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    The schema defines a new type for booleans: BooleanKind. However, XML schema standard already has a builtin 'boolean' type. Why not use it?

  • Reported: DDS-Security 1.0b1 — Tue, 5 Jan 2016 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Merged to DDSSEC_130

    Merging with DDSSEC_130 because they both affect the Governance XSD
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Builtin Access Control - Inadequate XML type for 'domainId' in schemas

Wrong reference to "create_local_datawriter_crypto_tokens" and "create_local_datareader_crypto_tokens" in §8.8.6.3

  • Key: DDSSEC_-107
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section §8.8.6.3
    In says

    the DDS middleware shall call the operation create_local_datawriter_crypto_tokens on the KeyFactory to obtain the DatawriterCryptoHandle for the builtin DataWriter.

    However create_local_datawriter_crypto_tokens does not return DatawriterCryptoHandle and moreover according section 8.5.1.7.3 (Operation: register_local_datawriter) the operation that creates the DatawriterCryptoHandle is register_local_datawriter

    In section §8.8.6.3
    In says

    the DDS middleware shall call the operation create_local_datareader_crypto_tokens on the KeyFactory to obtain the DatareaderCryptoHandle for the corresponding builtin DataReader.

    However create_local_datareader_crypto_tokens does not return DatareaderCryptoHandle and moreover according section 8.5.1.7.5 (Operation: register_local_datareader) the operation that creates the DatareaderCryptoHandle is register_local_datareader.

    Likewise in §8.8.6.3 the reference to create_local_datawriter_crypto_tokens should be changed to register_local_datawriter and the reference to create_local_datareader_crypto_tokens" to "register_local_datareader".


    For these reason the following changes should be made:
    In section §8.8.6.3 change "create_local_datawriter_crypto_tokens" to "register_local_datawriter"

    In section §8.8.6.3 change "create_local_datareader_crypto_tokens" to "register_local_datareader"

    n section §8.8.6.4 (Item 1 in first list of items) change "create_local_datawriter_crypto_tokens" to "register_local_datawriter"

    In section §8.8.6.4 (Item 1 on second list of items) change "create_local_datareader_crypto_tokens" to "register_local_datareader"

  • Reported: DDS-Security 1.0b1 — Wed, 2 Dec 2015 05:24 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix reference to "create_local_datawriter_crypto_tokens" and "create_local_datareader_crypto_tokens" in §8.8.6.3

    Analysis in issue description is correct. Apply suggested corrections.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Typos in DDS-Security Specification (2)

  • Key: DDSSEC_-106
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:


    The following typos in the spec should be fixed by applying the changes below

    In Section 9.4.1.2.5 Change "applies to apply" to "applies".

    In Table 44 Change "that can the" to "that the". (3 times)

    In Table 46 Change "receiving_articipant" to "receiving_participant".
    In Table 46 Change "with and" to "with an". (6 times)
    In Table 46 Change "transformation_id it that" to "transformation_id that". (2 times)

    In Section 9.5.3.3.4 Change "plain text the" to "plain text using the".

    In Section 9.6 Change "folowing" to "following".
    In Section 9.6 Change "means implies" to "states"
    In Table 48 Change "configurtion" to "configuration".
    In Section 10.1 Change "Entensibility" to "Extensibility".
    In Section 10.2 Change "In this rules" to "In these rules".
  • Reported: DDS-Security 1.0b1 — Wed, 2 Dec 2015 04:54 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix typos

    Fix the typos in issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Inconsistent naming "SingleSubmsgFlag", "SingleSubmessageFlag" versus "MultiSubmsgFlag"

  • Key: DDSSEC_-104
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The spec uses the three names: "SingleSubmsgFlag", "SingleSubmessageFlag" and "MultiSubmsgFlag" to refer to the same concept.

    We would recommended that the name "MultiSubmsgFlag" is the one used as it appears 16 times in the spec whereas the other forms only appear 3 times each.
  • Reported: DDS-Security 1.0b1 — Tue, 1 Dec 2015 21:52 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *Replace SingleSubmsgFlag and SingleSubmessageFlag with MultiSubmsgFlag *

    Replace SingleSubmsgFlag and SingleSubmessageFlag with MultiSubmsgFlag throughout the specification.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Wrong reference to check_create_datareader in §9.4.1.2.5.4

  • Key: DDSSEC_-109
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In §9.4.1.2.5.4 it says:

    If the value of “enable_write_access_control” element is TRUE, the operation
    check_create_datareader shall return a value according to what is specified in the Permissions document, see 9.4.1.3.

    This is incorrect, the write-access control setting should impact the creation of a DataWriter, not a DataReader.


    Corrective action:
    In §9.4.1.2.5.4 change the aforementioned sentence as shown below
    If the value of “enable_write_access_control” element is TRUE, the operation
    check_create_datawriter check_create_datareader shall return a value according to what is specified in the Permissions document, see 9.4.1.3.
  • Reported: DDS-Security 1.0b1 — Wed, 2 Dec 2015 05:39 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix reference to check_create_datareader in §9.4.1.2.5.4

    Analysis in issue description is correct. Apply suggested changes.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Wrong reference to BuiltinParticipantMessageSecureWriter in §9.4.1.2.4.5

  • Key: DDSSEC_-108
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section §9.4.1.2.4.5 it says:

    The liveliness protection element specifies the protection kind (see 9.4.1.2.1) used for builtin DataWriter and DataReader associated with the ParticipantMessageSecure builtin Topic (see 7.4.2): BuiltinParticipantMessageSecureWriter and BuiltinParticipantMessageSecureWriter.

    This is incorrect the two endpoints associated with the ParticipantMessageSecure builtin Topic are BuiltinParticipantMessageSecureWriter and BuiltinParticipantMessageSecureReader .


    Action: In Section §9.4.1.2.4.5 change the aforementioned sentence as shown below:

    (see 7.4.2): BuiltinParticipantMessageSecureWriter and BuiltinParticipantMessageSecureReader BuiltinParticipantMessageSecureWriter.
  • Reported: DDS-Security 1.0b1 — Wed, 2 Dec 2015 05:32 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Correct reference to BuiltinParticipantMessageSecureWriter in §9.4.1.2.4.5

    Analysis in issue description is correct. Apply suggested changes.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Size of NONCE (Challenge_A/Challenge_B) in Authentication handshake messages undefined

  • Key: DDSSEC_-114
  • Legacy Issue Number: 19864
  • Status: closed  
  • Source: THALES ( Cyril Dangerville)
  • Summary:

    The total size of the NONCE in binary_value1 of HandshakeRequestMessageToken and HandshakeReplyMessageToken (9.3.2.3.1) is undefined. The spec just says: "first 10 octets are set to match the ascii encoding of the string "CHALLENGE:"). There does not seem to be any mandatory size from a functional perspective, bu the spec should at least recommend a minimal size or refer to some recommendation on that.

  • Reported: DDS-Security 1.0b1 — Wed, 2 Dec 2015 05:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *9.3.2.3.1 and 9.3.2.3.2. Specify NONCE must include at least 32 characters and not be predictable *

    Specify that the NONCE in sections 9.3.2.3.1 and 9.3.2.3.2 must contain 32 characters in addition to the specified prefix.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

How to determine if creating a DomainParticipant is allowed

  • Key: DDSSEC_-73
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    The DomainParticipant Permissions document does not specifically indicate if we are allowed to create a participant in a domain. It indicates which topics are allowed/denied to publish/subscribe/relay. What specifically determines whether we are or are not allowed to create a participant?

    Is it simply the presence of a matching 'subject_name' entry?
  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 13:59 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify Table 40 adding detail on the conditions for the access control operations to succeed based on the governance and permissions documents

    Add more detailed information to Table 40 (Actions undertaken by the operations of the bulitin AccessControl plugin) in Section 9.4.3.

    Describe the precise behavior of the access-control operations for the built-in access control plugin based on the Governance and Permissions documents. Specifically the following aspects should be covered:

    • Impact of the existence of Topics in the Governance document that have enable_read_access_control or enable_write_access_control set to FALSE
    • Impact of the Publisher/Subscriber partition
    • Impact of DataReader/DataWriter Tags

    The description of the following operations in Table 40 should be updated with to include the behavior under the aforementioned circumstances:
    check_create_participant, check_create_datawriter, check_create_datareader, check_create_topic, check_local_datawriter_register_instance, check_local_datawriter_dispose_instance, check_remote_participant, check_remote_datawriter, check_remote_datareader, check_remote_topic
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Use of 'partition' in access control is unclear

  • Key: DDSSEC_-72
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    The mechanism of testing the 'partition' for match is not fully described. A “rule” specifies a set of partition names, and an “entity” provides a set of partition names.

    What is sufficient to determine that a match exists: exact set match, set intersection, strict subset match?

    This impacts the behavior of these methods on AccessControl:
    check_create_datareader()
    check_create_datawriter()
    check_remote_datareader()
    check_remote_datawriter()
  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 13:57 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify Permissions Document Schema to clarify rules for multiple partitions and topics

    Modify the XSD for the Permissions document so that each "grant" (publish/subscribe) contains three sections: <topics>, <partitions>, and <data_tags>.

    The <data_tags> remains as before.
    The <topics> section contains a list of topic expressions, each enclosed by the <topic> tag.
    The <partitions> section contains a list of partition expressions, each enclosed by the <partition> tag.

    For the grant to match there shall be a match of the topics, partitions, and data-tags criteria. This is interpreted as an AND of each of the criteria. For a specific criteria to match (e.g. <topics>) it is enough that one of the topic expressions listed matches (i.e. an OR of the expressions with the <topics> section).

    This change applies to the Permissions XSD as well as the Example Permissions files which appear both inside the specification and as separate machine readable documents.
  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Is there implicit handling for builtin secure endpoints in the access control plugin?

  • Key: DDSSEC_-74
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    Should there be 'implicit' governance rules for the builtin secure endpoints? OR, must they be listed (or defaulted) in DomainGovernance just like any other topic?

    This impacts the behavior of:
    get_endpoint_sec_attributes()
  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:04 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *Fully specify the behavior of the AccessControl plugin for the builtin endpoints *

    The objective is to clarify the use of the AccessControl Plugin when creating/matching the builtin secure endpoints .
    The behavior of the Crypto plugin relative to the builtin secure endpoints seems reasonably clear so there is not need to add extra material on this one.

    Propose to add two new sections 8.8.3 (DDS Entities impacted by the AccessControl operations) and 8.8.4 (AccessControl behavior with local participant creation) to clarify this (see Specific Changes below).

    Add a Properties (sec 7.2.1) member to EndpointSecurityAttributes. Specify those are included in the ones passed to the CryptoFactory operations register_local_datawriter and register_local_datareader

    For symmetry so that this is also extensible add a Properties member to ParticipantSecurityAttributes. Specify those are are included in the ones passed to the CryptoFactory operation register_local_participant.

    The spec is inconsistent in that sometimes it uses "Properties" and others "PropertySeq". Also to be consistent with the DDS PIM naming of types the name should be changed from "Property" to "Property_t". To correct this the following changes should be applied: Change the name from "Property" to "Property_t" from "BinaryProperty" to "BinaryProperty_t" from "Properties" to "PropertySeq" and from "BinaryProperties" to "BinaryPropertySeq"
  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Builtin Access Control plugin doesn't set is_rtps_protected

  • Key: DDSSEC_-35
  • Legacy Issue Number: 19811
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The §9.4.1.2.4 specifies how to set 2 of the ParticipantSecurityAttributes members: allow_unauthenticated_participants and is_access_protected.
    But it doesn't specify how to set the is_rtps_protected member.

  • Reported: DDS-Security 1.0b1 — Thu, 25 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Correct errors in 9.4.1.2.4.6 and explain how is_rtps_protected is set

    The text in §9.4.1.2.4.6 wrongly says: "The liveliness protection element specifies.." when it should say "The RTPS protection element specifies ..." Similarly it wrongly says "The discovery protection kind element may take ..." where it should say "The RTPS protection kind element may take ..."

    The ParticipantSecurityAttributes attribute is_rtps_protected should be set to TRUE if the <rtps_protection_kind> element ( §9.4.1.2.4.6) is set to anything other than NONE.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Which encryption algorithm for the SharedSecret ?

  • Key: DDSSEC_-32
  • Legacy Issue Number: 19799
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In Table 33 the binary_value1 of the HandshakeFinalMessageToken is described as following:
    "Shall be set to the result of encrypting the SharedSecret with the Public Key of the remote DomainParticipant that is the destination of the HandshakeFinalMessageToken."

    The encryption algorithm to use is not specified. It should be to ensure interoperability between different implementations of this builtin plugin
  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Specification of Encryption Algorithm for shared secret mentioned in Table 33

    The encryption algorithm for "Encrypting with a Public Key" is implied by the technology used for creating the Public/Private key pairs.
    In the case of Table 33 it is already specified in Section 9.3 that the Private/Public Key technology used is RSA with 2048-bit keys. However there is indeed an under-specification in that the padding used needs to be also specified.

    This issue of the need to specify the padding was also raised in DDSSEC_-38. Therefore issue DDSSEC_-32 is merged with DDSSEC_-38.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

In Table 18: check_remote_datawriter() should have a subscriber_partition parameter

  • Key: DDSSEC_-7
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    As specified in §8.4.2.7.10, the check_remote_datawriter() operation has a subscriber_partition parameter.
    It should appear in the table 18.
  • Reported: DDS-Security 1.0b1 — Tue, 2 Jun 2015 09:15 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Make Table 18 consistent with 8.4.2.7.10 and 8.4.2.57.11

    There several inconsistencies between table 18 and the definition on the corresponding section. The complete list is:

    For check_remote_datawriter:
    On Table 18 it takes an extra domain_id vs §8.4.2.7.10
    On §8.4.2.7.10 there is an extra subscriber_partition missing on Table 18
    On §8.4.2.7.10 there is an extra subscription_data_tag missing on Table 18

    For check_remote_datareader
    On Table 18 it takes an extra domain_id vs §8.4.2.7.11
    On §8.4.2.7.11 there is an extra publisher_partition missing on Table 18
    On §8.4.2.7.11 there is an extra publication_data_tag missing on Table 18

    In addition the operation check_local_datawriter_match operation needs access to the publisher_partition which is missing from Table 18 and §8.4.2.7.13. Similarly the operation check_local_datareader_match needs access to the subscriber_partition which is missing from Table 18 and §8.4.2.7.14.

    These inconsistencies need to be resolved so that both locations shown the same set of parameters and the check_local_datawriter_match and check_local_datareader_match get the parameters they need.

    The resolution is to preserve the parameters shown in Table 18 and adjust §8.4.2.7.10 and §8.4.2.7.11 to match Table 18 and add the missing parameters to check_local_datawriter_match and check_local_datareader_match.

    This means:

    On §8.4.2.7.10:

    • add domain_id parameter
    • remove subscriber_partition parameter
    • remove subscription_data_tag parameter

    On §8.4.2.7.11:

    • add domain_id parameter
    • remove publisher_partition parameter
    • remove publication_data_tag parameter

    On Table 18 and §8.4.2.7.13 add extra parameter publisher_partition to operation check_local_datawriter_match
    On Table 18 and §8.4.2.7.14 add extra parameter subscriber_partition to operation check_local_datareader_match
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Announcement of the new secure builtin endpoints

  • Key: DDSSEC_-5
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The chapter 7.3.7.1 specifies the EnityIds of the secure builtin endpoints.
    But the way a Participant announce those builtin endpoints are available is not specified, as it is for the DDSI builtin endpoints (see DDSI specification §8.5.3.2: availableBuiltinEndpoints attribute).
    This should be specified in this chapter.
  • Reported: DDS-Security 1.0b1 — Tue, 2 Jun 2015 09:54 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *Add specification of how the added buitin endpoints appear in the ParticipantBuiltinTopicData *

    Section 7.4.1.3 (Extension to RTPS Standard DCPSParticipants Builtin Topic) should get additional text to describe how the presence of the new builtin endpoints is encoded within the ParticipantBuiltinTopicData.

    The encoding reuses the existing availableBuiltinEndpoints bitmap which is already used to describe the presence of the discovery builtin endpoints. To describe the presence of the new endpoints we define new bits that encode to the presence of the corresponding endpoint
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Handle types are shared by some plugins

  • Key: DDSSEC_-18
  • Legacy Issue Number: 19781
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §9.5.2: "All “Handle” types are local opaque handles that are only understood by the local plugin object that creates them"
    should be re-phrased as:
    "All “Handle” types are local opaque handles that are only understood by the local plugin objects that create or use them"

    For instance: the SharedSecretHandle is created by Authentication plugin but is also used by the Cryptographic plugin to encode Tokens (§8.3.2.7). This handle can't be opaque to the Cryptographic plugin as it needs the material it contains to encode Tokens (see §9.5.2.1.2 where the un-encrypted value of the SharedSecret is required).

  • Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Correct description of Handle types on 9.5.2

    Make the change suggested in the issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT

In register_matched_remote_datareader() relay_out parameter should be IN

  • Key: DDSSEC_-1
  • Legacy Issue Number: 19752
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In chapter 8.4.2.7.11:
    "the relay_only parameter shall be remembered by the DDS middleware and passed to the register_matched_remote_datareader operation on the CryptoKeyFactory."

    To be consistent with this, the register_matched_remote_datareader() operation described in chapter 8.5.1.7.4 must have its relay_only parameter described as IN parameter.

  • Reported: DDS-Security 1.0b1 — Wed, 22 Apr 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *In section 8.5.1.7.4 (register_matched_remote_datareader) change relay_only to be an input parameter *

    As stated in the issue description section 8.5.1.7.4 (Operation: register_matched_remote_datareader) should change the parameter "relay_only" to be an input parameter. Currently it is an output parameter.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Errors in §8.8.6.4

  • Key: DDSSEC_-97
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:


    The following indicates typographical and wording errors in the spec that should be corrected as described below:


    In section §8.8.6.4 "register_matched_remote_datawriter" should be "register_matched_remote_datareader" in the the sentence:

    "For each non-builtin DataWriter...
    2. Call the operation register_matched_remote_datawriter for each discovered
    DataReader that matches the DataWriter."


    In section §8.8.6.4 Item numbered 2. after the sentence "For each non-builtin DataReader..." should be modified as shown below:
    2. Call the operation register_matched_remote_datawriter for each discovered
    DataWriter DataReader that matches the DataReader DataWriter.
  • Reported: DDS-Security 1.0b1 — Tue, 1 Dec 2015 14:45 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix erors in §8.8.6.4

    Fix erors in §8.8.6.4 listed in issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Errors in 8.8.5.2 step 6, step 7, and step 11

  • Key: DDSSEC_-96
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:


    The following indicates typographical and wording errors in the spec that should be corrected as described below:
    In §8.8.5.2. Step 6 after Figure 26.
    In the sentence:

    "DataWriter1 shall not call any operations on the AccessControl plugin and shall to match DataWriter2 subject to the matching criteria specified in the DDS and DDS-XTypes specifications."

    "shall to" should be "shall" and "DataWriter2" should be "DataReader2".

    In §8.8.5.2. Step 7 after Figure 26 and Step 11 after Figure 27
    In the sentence:

    "DataReader1 shall operate according to the DDS and DDS-RTPS specifications without any calls to the AccessControl plugin."

    "DataReader1" should be "DataWriter1"

  • Reported: DDS-Security 1.0b1 — Tue, 1 Dec 2015 14:36 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Correct errors in Errors in 8.8.5.2 step 6, step 7, and step 11

    Errors in 8.8.5.2 step 6, step 7, and step 11
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Typos in DDS-Security Specification

  • Key: DDSSEC_-95
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:


    The following typos in the spec should be fixed by applying the changes below

    §2.2.2 Change "middeware" to "middleware".
    §7.4.1.1 Change "since could" to "since it could".
    §7.4.1.2 Change "called using"to "called".
    §7.4.3.1 Change "there are not" to "there are no".
    §7.4.4.2 Change "associated with associated with" to "associated with".

    §7.4.4.6.2, §7.4.4.6.3 Change "that what" to "that".
    Table 11: Logging and DataTagging rows need periods at the end of sentences.

    §8.3.1 Change "to detects" to "to detect".
    §8.3.1 Change "materal in support" to "material in support of".
    §8.3.2.3 Change "and send over" to "and sent over".

    §8.3.2.8 Change "supports the establish" to "supports establishing".
    Table 14 Change "GMCLASID_SECURITY_AUTH_HANDSHAKE" to "GMCLASSID_SECURITY_AUTH_HANDSHAKE".

    §8.3.2.9.5 Change "validate_remote_identity returns VALIDATION_PENDING_HANDSHAKE_REQUEST" to "validate_remote_identity returning VALIDATION_PENDING_HANDSHAKE_REQUEST".

    §8.3.2.9.15 Change "begin_hadshake_request" to "begin_handshake_request".

    §8.3.2.10 Change "the AuthenticationListener shall call the AuthenticationListener" to "the AuthenticationPlugin shall call the AuthenticationListener".

    Table 16 Change "DomainParticiapant" to "DomainParticipant".

    Table 17 Change "access is_access_protected" to "is_access_protected".

    Table 17 Change

    "If is_discoverye_protected is TRUE then discovery information for that entity shall be sent using the SEDPbuiltinPublicationsSecureWriter SEDPbuiltinPublicationsSecureReader. If is_discoverye_protected is FALSE then discovery information for that entity shall be sent using the SEDPbuiltinPublicationsWriter or SEDPbuiltinSubscriptionsSecureWriter"

    to

    "If is_discovery_protected is TRUE then discovery information for
    that entity shall be sent using the SEDPbuiltinPublicationsSecureWriter or SEDPbuiltinSubscriptionsSecureWriter. If is_discovery_protected is FALSE then discovery information for that entity shall be sent using the SEDPbuiltinPublicationsWriter or SEDPbuiltinSubscriptionsWriter".

    Table 17 Change

    "If is_discoverye_protected is FALSE then discovery information for that entity shall be sent using the SEDPbuiltinPublicationsWriter or SEDPbuiltinSubscriptionsSecureWriter."

    to

    "If is_discovery_protected is FALSE then discovery information for that entity shall be sent using the SEDPbuiltinPublicationsWriter or SEDPbuiltinSubscriptionsWriter."

    Table 17 Change "entitity" to "entity".

    §8.4.2.7.14, §8.8.8.4 Change "datarwriter" to "datawriter".
    §8.4.2.7.18 Change "pemissions" to "permissions".

    Table 21 Change "submesage" to "submessage".
    Table 22 Change "local_datawritert_crypto_handle" to "local_datawriter_crypto_handle".

    §8.5.1.9.5 Change "SubmessagesMsg" to "Submessages".

    §8.5.1.9.6 Change

    "If the re returned SecureSubmessageCategory_t equals INFO_SUBMESSAGE, then the DDS Implementation proceed normally to process the submessage without further decoding"

    to

    "If the returned SecureSubmessageCategory_t equals INFO_SUBMESSAGE, then the
    DDS Implementation proceeds normally to process the submessage without further decoding".

    §8.5.1.9.6 Change "retuned" to "returned" (3 times).
    Table 34 Change "retuned" to "returned" (1 time).

    The following sections have operation names with typos that should all be changed to "preprocess_secure_submsg":

    §8.5.1.9.7 (preprecess_secure_submessage, prepreprocess_secure_submessage, prepreprocess_secure_submsg)

    §8.5.1.9.8 (preprecess_secure_submessage, prepreprocess_secure_subessage, prepreprocess_secure_submessage)

    §8.5.1.9.9 Change "key us available" to "key is available".

    §8.5.1.9.9 Change "receving_reader_crypto" to "receiving_reader_crypto".

    §8.8.1, §8.8.3, §8.8.4 Change
    "DomainParticpant" to "DomainParticipant".

    §8.8.1 "shall validates" should be "shall validate".

    §8.8.1 Change "get_psrticipant_sec_attributes" to "get_participant_sec_attributes".

    The following sentences in §8.8.2.2 have too periods at the end. Remove one of them:

    "The operation returns PENDING_HANDSHAKE_REQUEST indicating further handshake messages are needed and Participant1 should initiate the handshake. ."

    "The operation returns PENDING_HANDSHAKE_MESSAGE indicating authentication is not complete and the returned messageToken1 needs to be sent to Participant2 and a reply should be expected.."

    §8.8.2.2 Change "determines this is message originated" to "determines that this message originated". (appears 2 times)

    §8.8.2.2 Change "Participamt1" to "Participant1".

    §8.8.3 Change "DCPSSecureSubscritions" to "DCPSSecureSubscriptions".

    8.8.5.2 Change "Partcipant" to "Participant" (3 times)

    8.8.7.2 and 8.8.7.3 Change "Partcipant" to "Participant".

    Table 5. Change "ENTITYID_ SEDP_BUILTIN_ SUBSCRITIONS_SECURE_READER to "ENTITYID_ SEDP_BUILTIN_ SUBSCRIPTIONS_SECURE_READER"

    §8.8.6.1 Change "Crytpo" to "Crypto". (2 times)

    In the Figures 28-30 Legend Change "KeyExchanage" to "KeyExchange".

    After Figure 31 (item 8) and Figure 33 (item 7), there are occurrences of "encounters parses". It should be changed to "parses".

    After Figure 32 (first paragraph), "that on the" should be "that the".

    §9.3.2.3: Change "HandshakeReplyMessgeToken" to "HandshakeReplyMessageToken". Change "PersimissionsCredential" to "PermissionsCredential"

    On the caption of Table 34, Table 40, Table 44, Table 45, Table 46, Table 48
    Change "bultin" to "builtin".

    Table 34:
    Change "DomainPartipant" to "DomainParticipant".
    Change "shall identical" to "shall be identical".
    Change "referece" to "reference".
    Change "requied" to "required".
    Change "conditon" to "condition".

    Change "und" to "and" in the sentences:

    process_handshake: "If the handshake_message_in does not contain the aforementioned property or the verification fails, then the operation shall fail und return ValidationResult_Fail."

    begin_handshake_reply: " If the handshake_message_in does not contain the aforementioned property or the verification fails then the operation shall fail und return ValidationResult_Fail."

    begin_handshake_reply: "If this verification fails the operation shall fail und return ValidationResult_Fail."

    Table 34: (on process_handshake on a handshake_handle created by begin_handshake_request)
    Change "cryptographycally" to "cryptographically".
    Change "hansdhake" to "handshake".

    Table 34 Change "stablished" to "established" in the sentence

    get_shared_secret: "The operation shall return a SharedSecretHandle that is internally associated with the SharedSecret stablished as part of the handshake."

    §9.4.1.2 Change "a discovered DomainParticipants" to "a discovered DomainParticipant".

    §9.4.1.2.1 Change "encode_rtps message" to "encode_rtps_message".
  • Reported: DDS-Security 1.0b1 — Tue, 1 Dec 2015 14:31 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix typos in specification

    Apply the suggested fixes
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Replace encode_serialized_data with encode_serialized_payload

§8.8.7.1, §8.8.7.2, §8.8.7.3: "received by the BuiltinParticipantVolatileMessageSecureWriter" should be "received by the BuiltinParticipantVolatileMessageSecureReader"

  • Key: DDSSEC_-98
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In sections §8.8.7.1, §8.8.7.2, §8.8.7.3 it says that BuiltinParticipantVolatileMessageSecureWriter receives messages. This is wrong it is the BuiltinParticipantVolatileMessageSecureReader the one that receives messages.

    To correct this following changes should be made:

    In sections §8.8.7.1, §8.8.7.2, §8.8.7.3 the sentence:
    "received by the BuiltinParticipantVolatileMessageSecureWriter"

    this sentence should be replaced with:
    "received by the BuiltinParticipantVolatileMessageSecureReader"
  • Reported: DDS-Security 1.0b1 — Tue, 1 Dec 2015 14:52 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Replace "received by the BuiltinParticipantVolatileMessageSecureWriter" with "received by the BuiltinParticipantVolatileMessageSecureReader"

    Apply changes in issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT

9.4.1.2.5 Governance Document description typo

  • Key: DDSSEC_-82
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    XML Governance Document:
    9.4.1.2.5: Currently reads:

    This element is delimited by the XML element <topic_rules> and appears within the domain ruleSection.

    It should read:

    This element is delimited by the XML element <topic_rule> and appears within the domain ruleSection.

    Note <topic_rule> vs <topic_rules>
  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:34 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Change <topic_rules> to <topic_rule> in 9.4.1.2.5

    Fix the typo as requested in the issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Data type for CryptoTransformIdentifier.transformation_kind_id is unclear

  • Key: DDSSEC_-81
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    The 'transformation_kind_id' field (aka transformationKind) is specified as octet[4] in one place (Table 20) and as 'long' in another place (7.3.7.2). This will cause misinterpretation of the data in the case of differing endian's.

    @Extensibility(FINAL_EXTENSIBILITY)
struct CryptoTransformIdentifier {
  long        transformation_kind_id;  /* spec also says: transformationKind    octet[4] */
  OctetArray8 transformation_key_id;
};
  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:28 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Change type of transformationKind in Section 7.3.7.2 from long to octet[4]

    In the IDL definition of struct CryptoTransformIdentifier that appears in Section 7.3.7.2 change the type of the attribute transformationKind from long to octet[4]
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Do the encode operations prefix the CDR data with a CDR encapsulation header?

  • Key: DDSSEC_-80
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    Do the encode operations (encode_serialized_data(), encode_datawriter_submessage(), encode_datareader_submessage(), encode_rtps_message()) produce a CDR encapsulation header in front of the CDR bytes of EncodeOperationOutputData?

    Recommend clarify the presence of the CDR encapsulation header.
  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:26 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Change SerializedData to SerializedPayload

    "SerializedData" is not an RTPS submessage element. The correct name for the RTPS submessage element is "SerializedPayload" (RTPS version 2.2, section 9.4.2.12). So the specification should replace the references to "SerializedData" with "SerializedPayload".

    This affects: 7.3.1, 7.3.2, 7.3.4, 7.3.5, 8.5.1.3, 8.5.1.9.1, 8.5.1.9.9, 8.8.8, 8.8.8.1, 8.8.8.4, 9.4.1.2.1,

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Parameters to register_matched_remote_datareader() inconsistent between spec and IDL.

  • Key: DDSSEC_-79
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    Spec indicates that register_matched_remote_datareader() accepts a parameter named “remote_participant_permissions”. The IDL spec for this operation does not include this parameter. Which one is correct?
  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:25 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Section 8.5.1.7.4 Remove parameter remote_participant_permissions

    The operation register_matched_remote_datareader should not take the parameter remote_participant_permissions.

    This parameter does not appear in the IDL. It also does not appear in the parallel operation register_matched_remote_datawriter.

    For these reasons the paramater register_matched_remote_datareader should be removed from Section 8.5.1.7.4
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Description of HandshakeReplyMessage has an error

  • Key: DDSSEC_-77
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    Handshake Reply description, says same as Request message, "except that they correspond to the DomainParticipant that is sending the HandshakeRequestMessageToken."

    I think that should read {{

    {"... sending the HandshakeReplyMessageToken."}

    }
  • Reported: DDS-Security 1.0b1 — Tue, 17 Nov 2015 14:16 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Correct section 9.3.2.3.2, Table 32

    Apply correction suggested in issue description.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Section 8.3.2.9.1 (Authentication plugin interface) should not be under 8.3.2.9 (Unauthenticated DomainParticipant entities)

  • Key: DDSSEC_-57
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The section 8.3.2.9.1 "Authentication plugin interface" should not be nested under "Unauthenticated DomainParticipant entities". Rather it should be parallel section.
    The subsections 8.3.2.9.2 "Type: ValidationResult_t" to 8.3.2.9.17 "Operation: return_sharedsecret_handle" should be subsections of Authentication plugin interface".

    Suggested change:
    Change Section 8.3.2.9.1 (Authentication plugin interface) to be section 8.3.2.10. Then current section 8.3.2.10 (AuthenticationListener) becomes Section 8.3.2.11.

    The current subsections 8.3.2.9.2 "Type: ValidationResult_t" to 8.3.2.9.17 "Operation: return_sharedsecret_handle". Should become subsections of the new 8.3.2.10 (Authentication plugin interface) and take numbers 8.3.2.10.1 (for "Type: ValidationResult_t") to 8.3.2.10.16 (for "Operation: return_sharedsecret_handle").
  • Reported: DDS-Security 1.0b1 — Mon, 16 Nov 2015 08:19 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Change Section 8.3.2.9.1 (Authentication plugin interface) to be section 8.3.2.10.

    Make the changes suggested in the issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT

The padding used when encrypting the shared secret is not specified

  • Key: DDSSEC_-38
  • Status: closed  
  • Source: eProsima ( Mr. Jaime Martin-Losa)
  • Summary:

    RTI's secure DDS implementation uses RSA_PKCS1_OAEP_PADDING to encrypt the shared secret during the handshake process, but this is not present in the specification.
  • Reported: DDS-Security 1.0b1 — Mon, 28 Sep 2015 06:09 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    On section 9.3.4 specify the padding used when using the PublicKey to encrypt something.

    Modify Table 36 in section 9.3.4.1 to specify that the operation Encrypt(PubK, data) should use EME-OAEP padding as defined in PKCS #1 v2.0 with SHA-1, MGF1 and an empty encoding parameter.

    Note: This corresponds to using the RSA_PKCS1_OAEP_PADDING option when calling RSA_public_encrypt() on the OpenSSL library.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Confusion between is_access_protected and allow_unauthenticated_participants

  • Key: DDSSEC_-11
  • Legacy Issue Number: 19774
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    This chapter describes the behavior when a DomainParticipant discovers a remote DomainParticipant which lack the ability to authenticate.
    According to §8.4.2.5, the is_access_protected attribute applies only "with a remote DomainParticipant that has successfully authenticated". And the allow_unauthenticated_participants attribute "indicates whether the DomainParticipant shall only match discovered DomainParticipants that Authenticate successfully".

    Therefore, the §8.8.2.1 and §8.8.2.2 should rather describe behavior when the value of allow_unauthenticated_participants is TRUE or FALSE, instead of the value of is_access_protected.

  • Reported: DDS-Security 1.0b1 — Fri, 5 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Correct table 16, section 8.8.2.1 and 8.8.2.2

    The description of Table 16 Member allow_unauthenticated_participants and is_access_protected should be written to make it clear that:
    (1) allow_unauthenticated_participants determines whether remote DomainParticipant entities that cannot Authenticate are immediately rejected by the authentication process or allowed as "unauthenticated" entities.

    (2) is_access_protected determines whether the AccessControl plugin is called to check authorization for the remote DomainParticipant entities that are not disqualified by the authentication stage (this may include entities that were classified as unauthenticated).

    Also as indicated in the issue description sections 8.8.2.1 and 8.8.2.2 shall be corrected. In the places it says "-is_access_protected" it should say "allow_unauthenticated_access"
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Matching of ParticipantStatelessMessage builtin endpoints

  • Key: DDSSEC_-10
  • Legacy Issue Number: 19773
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In §8.8.2.2:
    "Discovered DomainParticipant entities that do implement the DDS Security specification, declare compatible Security Plugins and pass the Authentication protocol successfully shall be matched and the DomainParticipant shall also match ALL the builtin endpoints of the discovered DomainParticipant."

    Prior to Authentication protocol success, the ParticipantStatelessMessage builtin endpoints should have been matched for the handshake protocol to occur. The above sentence suggests the matching of those builtin endpoints only occurs after Authentication succeed, which cannot happen without this matching.

    The sentence could be rephrased as following:
    "Discovered DomainParticipant entities that do implement the DDS Security specification, declare compatible Security Plugins and pass the Authentication protocol successfully shall be matched and the DomainParticipant shall also match all the builtin endpoints of the discovered DomainParticipant, except the ParticipantStatelessMessage builtin endpoints which are matched prior to the Authentication protocol."

  • Reported: DDS-Security 1.0b1 — Fri, 5 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Edit section 8.8.2.2 to clarify that ParticipantStatelessMessage is matched prior to authentication.

    Make changes described in Revised Text.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

In Figure 12: preprocess_rtps_submessage() should be preprocess_secure_submsg()

Replace "BuiltinParticipantStatelessMessager" with "state-machine"

  • Key: DDSSEC_-3
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In 8.3.2.8.1:

    2. Any time the state-machine indicates that a message shall be sent using the BuiltinParticipantStatelessMessageWriter and a reply message needs to be received by the BuiltinParticipantStatelessMessageReader, the DDS implementation shall cache the message that was sent and set a timer. If a correct reply message is not received when the timer expires, the BuiltinParticipantStatelessMessager shall send the same message again. This process shall be repeated multiple times until a correct message is received.

    This BuiltinParticipantStatelessMessager was never introduced before. I think it refers to the "state-machine". If so, the term should be replaced with "state-machine":

    ... If a correct reply message is not received when the timer expires, the state-machine shall send the same message again. ...

  • Reported: DDS-Security 1.0b1 — Tue, 2 Jun 2015 10:01 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:
    • Replace "BuiltinParticipantStatelessMessager" with "state-machine" in section 8.3.2.8.1*

    Apply suggested correction
  • Updated: Tue, 12 Jul 2016 14:45 GMT

The adjusted_participant_key must be a valid Participant GUID

  • Key: DDSSEC_-4
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §8.3.2.9.3 (validate_local_identity), in the description of the adjusted_participant_key parameter, it's worth to specify that this BuiltinTopicKey_t must be a valid Participant GUID to conform with the DDSI specification (§8.2.4.2): i.e. with ENTITYID_PARTICIPANT.
  • Reported: DDS-Security 1.0b1 — Tue, 2 Jun 2015 09:34 GMT
  • Disposition: Closed; No Change — DDS-Security 1.0
  • Disposition Summary:

    It does not seem the place of the security plugins to check GUID correctness

    See comments on issue proposal.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

In Table 1 and Table 2: the "name" attribute should be renamed as "key"

  • Key: DDSSEC_-6
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §7.2.1.1 the IDL definition of Property type has 2 attributes: "key" and "value". The table 1 just above should reflect this definition, renaming the "name" attribute as "key".

    The same apply to the Table 2 to reflect the IDL definition in §7.2.2.1.
  • Reported: DDS-Security 1.0b1 — Tue, 2 Jun 2015 09:22 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Make IDL in 7.2.1.1 consistent with Table 1 and IDL in 7.2.2.1 consistent with Table 2

    Change the IDL in Section 7.2.1.1 and in Section 7.2.2.1. In both cases change the attribute "string key;" to "string name;"
  • Updated: Tue, 12 Jul 2016 14:45 GMT

In Table 18: check_create_topic should not have a "property" parameter

  • Key: DDSSEC_-9
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §8.4.2.7.6, the specification of the check_create_topic() doesn't have a "property" parameter.
    This parameter should be removed from the table 18.
  • Reported: DDS-Security 1.0b1 — Tue, 2 Jun 2015 09:17 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Remove "Parameter property" from Table 18 check_create_topic

    Remove "Parameter property" from Table 18 check_create_topic
  • Updated: Tue, 12 Jul 2016 14:45 GMT

register_matched_remote_datawriter: wrong parameter name

  • Key: DDSSEC_-19
  • Legacy Issue Number: 19782
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    According to Table 22 (p.94) the register_matched_remote_datawriter has a "local_datareader_crypto_handle" parameter.

    Consequently, in §8.5.1.7.6, the following text:
    "Parameter local_datawriter_crypto_handle: A DatawriterCryptoHandle returned by a prior call to register_local_datawriter. If this argument is nil, the operation returns nil."

    must be replaced by this:
    "Parameter local_datareader_crypto_handle: A DatareaderCryptoHandle returned by a prior
    call to register_local_datareader. If this argument is nil, the operation returns nil."

  • Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Section 8.5.1.7.6 change local_datawriter_crypto_handle to local_datareader_crypto_handle

    Make the change suggested in issue description.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Content of initialization_vector and hmac_key_id

  • Key: DDSSEC_-31
  • Legacy Issue Number: 19790
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The KeyMaterial_AES_CTR_HMAC is specified with 2 members named initialization_vector and hmac_key_id.
    But it's not clearly specified how those members are used and what should be their content.

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Duplicate or Merged — DDS-Security 1.0
  • Disposition Summary:

    Content of initialization_vector and hmac_key_id

    Section 9.5.2.1.1 just defines the data types. The way to use it and how these fields are filled is defined in section 9.5.3.3

    Combine with DDSSEC_78
  • Updated: Tue, 12 Jul 2016 14:45 GMT

New callback for authentication failures

  • Key: DDSSEC_-30
  • Legacy Issue Number: 19795
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    When a DomainParticipant tries to authenticate itself with a remote DomainParticipant but is rejected by this one, there is no way for the user of this DomainParticipant to know it has been rejected (unless a potential security log).

    We could add an operation to the DDS::DomainParticipantListener (or to an inheriting class) to do such a callback:
    on_remote_authentication_failure(BuiltinParticipantKey_t remote_participant_key)
    which will be called each time the DomainParticipant is rejected by a remote DomainParticipant.

  • Reported: DDS-Security 1.0b1 — Thu, 11 Jun 2015 04:00 GMT
  • Disposition: Closed; No Change — DDS-Security 1.0
  • Disposition Summary:

    New callback for authentication rejection

    In general it is considered best-practice to not communicate on the network authentication failures, nor provide the reasons for it. In addition the suggested enhancement would require an extra message which increases the surface of a DOS attack.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Benefit of session keys: wrong sentence

  • Key: DDSSEC_-23
  • Legacy Issue Number: 19787
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The following sentence has a wrong syntax (missing or extra words?) and should be re-phrased for clarification:
    "This has the benefit that the ‘session’ keys used to secure the DATE STREAM DATA can be modified as needed to maintain the security IF THE STREAM WITHOUT HAVING to perform explicit rekey and key-exchange operations."

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Section 9.5.3.3.2 "Encode/decode operation virtual machine": correct grammar

    In section 9.5.3.3.2 first paragraph below below Table 47, correct the grammar of the sentence.

    It says "date stream data" instead of "data stream"
    It says "security if the stream" instead of "security of the stream"
  • Updated: Tue, 12 Jul 2016 14:45 GMT

How to find the MasterSessionSalt to decrypt ?

  • Key: DDSSEC_-26
  • Legacy Issue Number: 19791
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The §9.5.3.3.5 explains how to find the MasterKey, the MasterSalt and the SessionId.
    Then it specifies:
    "The session_id attribute within the SecureDataHeader_AES_CTR_HMAC is used to obtain the proper SessionSalt and SessionKey. Note that this only requires a re-computation if it has changed from the previously received SessionId for that CryptographicSessionHandle."

    But a re-computation of the SessionSalt requires the MasterSessionSalt in combination with the MasterKey and the SessionId (see §9.5.3.3.3). And it's not specified how to find the MasterSessionSalt.

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *In Section 9.5.3.3.5 clarify how to locate the MasterSessionSalt *

    In section 9.5.3.3.5 clarify that the MasterSessionSalt is also located from the transformation_key_id.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Typo in KeyMaterial_AES_CTR_HMAC: initilization_vector

  • Key: DDSSEC_-25
  • Legacy Issue Number: 19789
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In definition of the KeyMaterial_AES_CTR_HMAC struct:
    sequence<octet, 32> initilization_vector;
    should be replaced by
    sequence<octet, 32> initialization_vector;

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    *Section 9.5.2.1: Modify IDL for KeyMaterial_AES_CTR_HMAC *

    Perform change indicated in issue descritption
  • Updated: Tue, 12 Jul 2016 14:45 GMT

CipherKind and HashKind enums both use NONE

  • Key: DDSSEC_-24
  • Legacy Issue Number: 19788
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The IDL declarations of CipherKind and HashKind enums both contain the NONE member.
    This is not allowed in IDL as "Enumeration value names are introduced into the enclosing scope and then are treated like any other declaration in that scope" (see CORBA 3.1 part 1 §7.20.2).

    We suggest to change the enums definitions as following:
    enum CipherKind

    { CIPHER_NONE = 0, CIPHER_AES128 = 1, CIPHER_AES256 = 2 }

    ;
    enum HashKind

    { HASH_NONE = 0, HASH_SHA1 = 1, HASH_SHA256 = 2 }

    ;

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Section 9.5.2.1: Modify IDL for CipherKind and HashKind

    Perform the change suggested in issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Meaning of MasterHMACSalt

  • Key: DDSSEC_-21
  • Legacy Issue Number: 19785
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In Table 47, the meaning of MasterHMACSalt is described as following:
    "A random vector used in connection with the MasterKey to create the SessionHashKey."

    But "SessionHashKey" is never specified and in §9.5.3.3.3 the MasterHMACSalt is used for the computation of the SessionHMACKey.

    Thus, the meaning shoud be rephrased as following:
    "A random vector used in connection with the MasterKey to create the SessionHMACKey."

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    In table 47 replace "SessionHashKey" with "SessionHMACKey"

    Change table 47 as stated in the issue description.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Extra parameter to register_local_datawriter

  • Key: DDSSEC_-20
  • Legacy Issue Number: 19784
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In §8.5.1.7.3 the register_local_datawriter operation is specified with 4 parameters (local_participant_identity, participant_crypto, local_datawriter_properties, exception).

    But in Table 22 (p.93) it's specified with 3 parameters only (participant_crypto, local_datawriter_properties, exception). And the register_local_datareader is also specified with 3 parameters only (participant_crypto, local_datareader_properties, exception).

    Thus, the local_participant_identity parameter should be removed from §8.5.1.7.3.

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Remove parameter "local_participant_identity" from section 8.5.1.7.3 (Operation: register_local_datawriter)

    Perform the change suggested in the issue description
  • Updated: Tue, 12 Jul 2016 14:45 GMT

validate_remote_permissions cannot return TRUE

  • Key: DDSSEC_-13
  • Legacy Issue Number: 19776
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In description of is_access_protected attribute:
    "...and only match those for which the validate_remote_permissions operation returns TRUE."

    According to §8.4.2.7.2 this operation returns a PermissionHandle. The sentence should be rephrased as:
    "...and only match those for which the validate_remote_permissions operation doesn't returns HandleNIL."

  • Reported: DDS-Security 1.0b1 — Fri, 5 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify table 16 description of validate_remote_permissions

    As requested in the issue description modify description to reflect the fact that validate_remote_permissions returns HandleNIL instead of FALSE on failure.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Typo: is_discoverye_protected

  • Key: DDSSEC_-12
  • Legacy Issue Number: 19775
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In description of is_discovery_protected attribute, there is twice the same typo:
    is_discoverye_protected instead of is_discovery_protected

  • Reported: DDS-Security 1.0b1 — Fri, 5 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Fix is_discoverye_protected typo in Table 17

    Replace is_discoverye_protected with is_discovery_protected in Table 17
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Value of HandshakeRequestMessageToken 1st property

  • Key: DDSSEC_-17
  • Legacy Issue Number: 19780
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In table 31, the "properties" attribute is specified with 2 properties. The first is described as:
    "A property with name set to “dds.sec.identity” and value set to string containing the elements of the value attribute of the IdentityCredential, one character per element. Note that the octets in the IdentityCredential value were defined to hold
    characters resulting from a PEM encoding ( 9.3.2.1) so the value of the property is precisely those characters."

    In §9.3.2.1 the IdentityCredential is defined with 2 "values" attribute: binary_value1 and binary_value2.
    Which one shall be used as property value for HandshakeRequestMessageToken ? binary_value1 I guess, but it should be specified.

  • Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Table 21 - Specify the use of the IdentityCredential binary_value1 in the properties

    Table 21 - "properties" row, "Attribute value" column. When describing the construction of the property name "dds.sec.identity" it mentions the use of the "value" attribute from the IdentityCredential. Instead of "value" it should say "binary_value1".
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Inconsistency between "BuiltinParticipantStateless" and "InterParticipantStateless"

  • Key: DDSSEC_-16
  • Legacy Issue Number: 19779
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    7.4.3 introduces the "ParticipantStatelessMessage builtin Topic" and the "BuiltinParticipantMessageWriter" and "BuiltinParticipantMessageReader".

    §8.3.2.8.1 specifies "the Authentication Handshake uses the BuiltinParticipantStatelessMessageWriter and BuiltinParticipantStatelessMessageReader endpoints".

    But in all §8.3.2.9 the words "InterParticipantStatelessMessage", "InterParticipantStatelessWriter", "InterParticipantStatelessReader" are used instead.

  • Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify Subsections of 8.3.2.9 renaming InterParticipantStatelessWriter/Reader

    Subsections of 8.3.2.9 use the term InterParticipantStatelessWriter/Reader where they should use BuiltinParticipantMessageWriter/Reader instead.

    Subsections of 8.3.2.9 InterParticipantStatelessMessage where they should use ParticipantStatelessMessage instead.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Wrong bits indexes in effective_participant_key

  • Key: DDSSEC_-15
  • Legacy Issue Number: 19778
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In description of actions for validate_local_identity (Table 34), the returned effective_participant_key is described with following sentences:
    "... The following 48 bits (bits 48 to 96) shall be set to the first 48 bits of the SHA-256 hash of the candidate_participant_key.
    "The remaining 32 bits (bits 97 to 127) shall be set identical to the corresponding bits in the candidate_participant_key"

    The correct bits indexes should be "bits 48 to 95" and "bits 96 to 127".

  • Reported: DDS-Security 1.0b1 — Mon, 8 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Modify Table 34 validate_local_identity description of effective_participant_key

    Modify the description of the effective_participant_key as suggested in the issue description.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Complexity of Authentication Plugin Model

  • Key: DDSSEC_-28
  • Legacy Issue Number: 19793
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The Authentication Plugin Model specifies a state machine to be implemented by the DDS middleware to manage the authentication of the remote Participants. The implementation of this state machine is complex because:

    • It is not specified when to call validate_remote_identity (for each received SPDP or only for the first received SPDP from a newly discovered Participant? What if a malicious Participant send a SPDP at first, usurping the GUID of a legit Participant?)
    • The handshake could be initiated from both sides at nearly the same time (nothing forbid this in §8.3)
    • There is no indication in the specification to tell how parallel handshakes between 2 Participants should interact
    • It is difficult to determine at which sense a received message belongs
    • In §8.3.2.8.1 it's specified that "The DDS security implementation shall pass to the AuthenticationPlugin any message received by the BuiltinParticipantStatelessMessageReader...". But there are states in the state machine where it's not specified how to pass those messages (e.g. when validate_remote_identity has not been called yet, and the state machine is not initialized)

    This results in quite complex code, and this is a weakness in a mechanism which needs to be very strong.

    Anyway, the state machine in the middleware is redundant with the one needed in the plugin. In addition, it has to deal with events where it doesn't know what is really going on. Only the plugin has the real information. Therefore, we think this middleware state machine is useless, add extra complexity which makes the authentication less robust, and consumes a lot of resources.

    Instead, we suggest to remove it and to change the mechanism to the following:

    • remove all the "_handshake" methods on the Authentication Plugin
    • add a treat_message method to the authentication plugin to handle any incoming authentication ParticipantStatelessMessage
    • add a send_message method to the authentication listener interface to tell the middleware to send an authentication ParticipantStatelessMessage
    • add a validated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is authenticated
    • add a invalidated_remote_participant method to the authentication listener interface to tell the middleware that the indicated participant is not authenticated
    • once the authentication is initialised with validate_remote_identity, all the state machine is managed directly by the plugin which sends the appropriate messages and is given the received ones, until its decision is given to the DDS middleware through the authentication listener.

    This will provide the necessary functionality in a much simple, efficient and robust manner.
  • Reported: DDS-Security 1.0b1 — Thu, 11 Jun 2015 04:00 GMT
  • Disposition: Deferred — DDS-Security 1.0
  • Disposition Summary:

    *Move authentication state machine to plugin implementation *

    This issue would may require a significant change to the Authentication Plugin API but does not affect interoperability and would not be observable to a regular end-user of a product that implements the specification.

    For these reasons the FTF decided it was best to defer it so that resources could be devoted to issues that affect interoperability of the experience the end user would have.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Meaning of SessionId

  • Key: DDSSEC_-22
  • Legacy Issue Number: 19786
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    in Table 47, the meaning of SessionId contains this sentence:
    "Knowledge of the MasterKey, MasterSalt, MasterHMACSalt, and the SessionId is sufficient to create the SessionKey, SessionSalt, and SessionHMACKey."

    This is not true, as the MasterSessionSalt is also required to create the SessionSalt (see §9.5.3.3.3).

    Thus, the sentence shoud be rephrased as following:
    "Knowledge of the MasterKey, MasterSalt, MasterSessionSalt, MasterHMACSalt, and the SessionId is sufficient to create the SessionKey, SessionSalt, and SessionHMACKey."

  • Reported: DDS-Security 1.0b1 — Wed, 10 Jun 2015 04:00 GMT
  • Disposition: Resolved — DDS-Security 1.0
  • Disposition Summary:

    Table 47. Improve description of sessionId

    Make the change specified in the issue description.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

How does the built-in Cryptographic plugin know whether to just Sign or EncryptThenSign?

  • Key: DDSSEC_-128
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The builtin plugins can be configured via the Governance and Permissions documents to selectively only Sign, or EncryptThenSign different Submessages and SubmessageElements.

    However the specification does not describe the mechanism by which Cryptographic plugin can know what the intent it when it creates the cryptographic material for the different DataWriters and DataReaders.

    The cryptographic material is created by the CryptoFactory operations register_local_datawriter and register_local_datareader. The only parameter that could be used to communicate a decision of Sign versus EncryptThenSign is the Properties parameter. But the specific property names and values to use should be prescribed in the specification.

  • Reported: DDS-Security 1.0b1 — Sun, 3 Jan 2016 17:42 GMT
  • Disposition: Deferred — DDS-Security 1.0
  • Disposition Summary:

    Defer specification of crypto factory configuration to RTF

    Issue deferred to RTF. It does not affect interoperability, or even portability as long as vendors provide a way to configure it.
    In a future revision we can standardize the configuration mechanism if it seems worthwhile.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

DomainGovernance -> domain_rule -> rtps_protection_kind description is unclear

  • Key: DDSSEC_-83
  • Status: closed  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    The description refers to the "liveliness protection element", which seems like an error.

    The description further says that this element specifies "the protection kind (see 9.4.1.2.1) used for the whole RTPS message". It is not clear to which message this refers.
  • Reported: DDS-Security 1.0b1 — Sat, 21 Nov 2015 18:27 GMT
  • Disposition: Deferred — DDS-Security 1.0
  • Disposition Summary:

    Clarify whether the whole RTPS message can be encrypted

    After discussing in the FTF we decided to close this one. It seems premature to force the restriction when it is something the user can configure. As we gather more user experience if this becomes an issue we can revisit it but for now it seems best to defer it.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Name of builtin topic is DCPSParticipantMessage not ParticipantMessage

  • Key: DDSSEC_-140
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section 7.4.2 (New ParticipantMessageSecure builtin Topic)
    It talks about the builtin Topic ParticipantMessage the correct name in RTPS spec is DCPSParticipantMessage.

    Consequently the names of the additional builtin Topics introduced by DDS Security should follow a similar naming convention.
    Specifically the following name changes are recommended:

    ParticipantMessageSecure -> DCPSParticipantMessageSecure
    ParticipantStatelessMessage -> DCPSParticipantStatelessMessage
    ParticipantVolatileMessageSecure -> DCPSParticipantVolatileMessageSecure

  • Reported: DDS-Security 1.0b1 — Tue, 19 Jan 2016 01:39 GMT
  • Disposition: Deferred — DDS-Security 1.0
  • Disposition Summary:

    Defer renaming to RTF

    Issue deferred to RTF because it is limited to the terminology used within the specification. It does not affect interoperability or portability.
  • Updated: Tue, 12 Jul 2016 14:45 GMT

Collisions in the implied IDL

  • Key: DDSRPC_-9
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Section 8.3.1.2
    What about collisions in the implied IDL types, hashes, etc. If a collision appears what are the rules to follow, because client and service could be developed by independent groups and DDS vendors which should than follow the same rules

    What when the user has an interface with a user defined parameter with the name return_ and there is a return value? This leads to a clash in the generated struct

    What when the user has an operation remoteEx in his interface IDL?

    What if there is a clash between the const hash name and user defined IDL?

    What is the behavior of @autoid with a hash-collision? Also what happens when operations are reordered at the moment there is a hash-collision? Couldn't that break interoperability?
  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:54 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Collision resolutions incorporated in multiple sections

    The following collision resolution techniques have been incorporated
  • Updated: Tue, 12 Jul 2016 14:44 GMT

missing attribute exception specification mapping

  • Key: DDSRPC_-15
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    For the result struct, with IDL attributes it is possible to define separate exceptions with the set and the get of the attribute (getraises/setraises), this is not reflected in the result mapping
  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:56 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Added mapping for interface attributes and collision resolution

    Added section 7.5.1.1.3
  • Updated: Tue, 12 Jul 2016 14:44 GMT

Potentially redundant UnknowEx

  • Key: DDSRPC_-13
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Section 8.5.1.1.3
    For the result unions, why is not the unknownEx be part of the RobotControl_Return union as described on page 25, that would save a lot of union members. This exception is generic and independent of the operation.
  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:55 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Removed UnknowEx

    Removed UnknownEx from Section 7.5.1.1.4
  • Updated: Tue, 12 Jul 2016 14:44 GMT

Clarifications and simple technical corrections

  • Key: DDSRPC_-1
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    This issue is a subset of the DDSRPC-1 issue reported by Remedy.

    IDL zip (mars/14-11-05)
    rpc_types.idl:
    Uses the RTI specific top-level annotation. Also top-level is illegal according to the IDL grammar.
    Uses anonymous types
    robot.idl:

    In the 4rd paragraph it mentions “asynchronous invocations”, but this is not mentioned in 8.2.2.1, how do asynchronous invocations look like with the function call style in the basic profile?

    Section 8.2.3
    Where in this document is the API defined to get the request id at both sides for implicit or explicit?

    Section 8.2.1
    Why include space as part of user_def_alpha_num?

    Section 8.5.1.1.1
    Why is SequenceNumber_t not using an “unsigned long long”. It is now a struct but there is no explanation in the specification about high and low

    Section 8.5.1.1.2
    Why not put the implied types into a nested module so that they don't pollute the user IDL module and resulting code, doxygen documentation, etc

    Section 8.5.1.1.4
    Why not put the implied types into a nested module so that they don't pollute the user IDL module and resulting code, doxygen documentation, etc

    What is the error when the remote service is not there (for example not running or not reachable), which exception do I get back?
    What when the service crashes during handling of the request, what kind of error do I get back, what is the timeout? How can configure timeouts etc?

    Section 8.7.1.3
    What about changing the exception specification of an operation?
    Section 8.8.2
    Not a legal IDL struct definition, struct has to be removed from its members
    Section 8.10.1
    What about the library name RTI DDS currently supports. It is very helpful to have multiple QoS profiles in one file and the spec should define how this works
  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 18:09 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Added clarifications to the spec document or provided justifications

    Added clarifications to the spec document or provided justifications below.
  • Updated: Tue, 12 Jul 2016 14:44 GMT

Editorial corrections in the spec document

  • Key: DDSRPC_-7
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The following content is a subset of DDSRPC-1 issue reported by Remedy.

    Document (mars/14-11-02)
    Section 4
    reference to CORBA should be updated to CORBA v3.3
    reference to IDL should be updated to CORBA v3.3
    reference for DDS4CCM lacks document number
    reference for DDS-Cxx-PSM and DDS-Java-PSM should be updated to the formal version
    reference to github, how can we in the future pinpoint the exact version of the files mentioned, shouldn't the reference be more explicit about which version?
    reference to IDL 3.5 is lacking (used in section 8.3.1)
    Section 5
    Shouldn't there be a reference in section 4 for this quote?
    Section 8.1
    The spec talks about “communication patterns”, but in the context of UCM we are talking about “interaction patterns”, what about adopting the UCM term?
    Section 8.2.1
    Second paragraph, the fact that a content-based filter “is” used forces that everyone must do this (which is the most logical implementation), but shouldn't it be “could”
    In the second paragraph its says “the service implementation contains a data reader to read the method name”, but shouldn't it be “the service implementation contains a data reader which receives the request and after that reads the method name and the parameters.”

    Can't the diagram be placed after the first paragraph, it is now on the next page but we refer in text already to it).

    Third paragraph, at the end “are filtered out”.

    Section 8.2.3
    Isn't it better to keep the term “client” instead of introducing “requester”

    Section 8.2.5
    “ it is” instead of “It is”
    Section 8.3.1.2
    Use a reference to DDS-XTypes in the first paragraph, not in the 3rd
    Section xx

    Section xx
    The spec uses IDL anonymous types in some places, these are deprecated and prevented to our idea.
    Section 8.4
    “by the used,”??
    Section 8.4.2.3
    Reference error
    Section 8.4.3.3
    Reference error
    Section 8.5.1.1.2
    Space missing before “shall” on 3rd line

    Section 8.5.1.1.4
    Typo Non-noramtive

    Section 8.7.1
    Evolution should be evolution.
    Section 8.8.2.1/8.8.2.2
    Add a reference to where in this specification this language binding is provided
  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 18:01 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Correction have been incorporated

    The suggested editorial corrections have been incorporated in the updated specification document.
  • Updated: Tue, 12 Jul 2016 14:44 GMT

modules in IDL

  • Key: DDSRPC_-11
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Section 8.3.1
    What about the support for modules in IDL. In larger systems it will almost get impossible to guarantee the uniqueness of an interface when multiple parts are integrated. Also with an UCM approach modules are the way to group interfaces together. The module is now completely left which could lead to problems in a larger system. To our idea a change of an interface to another module is something that RPC4DDS shouldn't silently adapt to
  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:51 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    include module hierarcy to fully qualify interfaces

    Replaced "unqualified" with "fully-qualified".
  • Updated: Tue, 12 Jul 2016 14:44 GMT

QoS library name with profile filename

  • Key: DDSRPC_-25
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Section 8.10.1
    What about the library name RTI DDS currently supports. It is very helpful to have multiple QoS profiles in one file and the spec should define how this works
  • Reported: DDS-RPC 1.0b1 — Thu, 5 Nov 2015 00:00 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Add optional library name at the end of the filename URL

    The URL may end with an optional library name. The profile filename and library_name are separated by a #. For example, file://path/to/filename#library_name.
  • Updated: Tue, 12 Jul 2016 14:44 GMT

return code mapping in IDL2C++11

  • Key: DDSRPC_-23
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    section 8.5.2
    What is the mapping for the return codes when the regular IDL to IDL2C+, IDL2C+11, etc language mappings are used
  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:59 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    *Clarified the mapping of remote error codes to IDL2C++11 *

    Reworded section 7.5.2 as follows.
  • Updated: Tue, 12 Jul 2016 14:44 GMT

Why do we need @Choice

  • Key: DDSRPC_-21
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    We still doubt the need to introduce @choice, with a union with the hash as discriminator value the is always one value active and there is a quick lookup at runtime. It works for the basic profile so why introduce this new IDL behavior for the enhanced one?
  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:58 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Clarification provided as the rationale

    The following clarification has been provided as the rationale behind @Choice

    It is our intent to support interface inheritance (including multiple inheritance) as cleanly as possible using the tools provided by DDS-Xtypes in the enhanced service profile. @Choice is added in response to that.
    The following must be satisfied.
    1. A requester must be able invoke operations in a service implementing an "evolved" version of the same interface (with more operations or fewer exceptions, etc.)
    2. A base interface requester must be able to invoke operations in a service implementing a derived interface.
    3. In case of multiple inheritance, order of base interfaces should have no impact with respect to interoperability of the derived interface. I.e., interface is a set of operations and has no ordering between.
    Mapping to union requires selection of a discriminator, which has natural ordering. The language mapping rules have to have complex rules to ensure that implicit ordering does not come in the way of supporting interface evolution. For instance, the order in which the base interfaces are listed must be deterministic to get the same union discriminators to all operations. Similarly, the order exceptions must also be deterministic for the operation-specific *_Result structures. (see 7.5.1.2.3 and 7.5.1.2.5)
    The @choice annotation which implies all members are optional and the type is mutable has simple assignability semantics. I believe it has "strong assignability". It really simplifies analysis of interface interoperability and evolvability.
    A common argument in favor of union is its ability to jump to the right member with a single lookup. That's conceptually true but I'm not sure if the mapping of @choice is slow. It requires finding a non-null pointer in an array of pointers. It appears like a micro-optimization.
  • Updated: Tue, 12 Jul 2016 14:44 GMT

Annotation Scope

  • Key: DDSRPC_-19
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Section 8.5.1.2.1
    Shouldn't the dds::rpc scope be used when the annotations are used?
  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:58 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    added a normative idl file with annotation definitions

    Added a normative idl file with annotation definitions. See attached rpc_annotations.idl
  • Updated: Tue, 12 Jul 2016 14:44 GMT
  • Attachments:

potential hash collisions

  • Key: DDSRPC_-17
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    What if there is a clash between the const hash name and user defined IDL?

    What is the behavior of @autoid with a hash-collision? Also what happens when operations are reordered at the moment there is a hash-collision? Couldn't that break interoperability?
  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:57 GMT
  • Disposition: Duplicate or Merged — DDS-RPC 1.0
  • Disposition Summary:

    Duplicate of DDSRPC_-9

    This issue is already addressed in Duplicate of DDSRPC_-9
  • Updated: Tue, 12 Jul 2016 14:44 GMT

Inconsistent ParameterIDs

  • Key: DDSRPC_-5
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    ParameterIDs for the extended SubscriptionBuiltinTopicData elements should be 0x80, 0x81, 0x82. Reported by Clark Tucker (Twin Oaks)
  • Reported: DDS-RPC 1.0b1 — Tue, 25 Aug 2015 17:30 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Updated PIDs

    @extensibility(MUTABLE_EXTENSIBILITY)
    struct PublicationBuiltinTopicDataExt : PublicationBuiltinTopicData

    { @ID(0x00540x0080) string<256> service_instance_name; @ID(0x00550x0081) GUID_t related_datareader_key; @ID(0x00560x0082) sequence<string<256>> topic_aliases; }

    ;
    @extensibility(MUTABLE_EXTENSIBILITY)
    struct SubscriptionBuiltinTopicDataExt : SubscriptionBuiltinTopicData

    { @ID(0x00540x0080) string<256> service_instance_name; @ID(0x00550x0081) GUID_t related_datawriter_key; @ID(0x00560x0082) sequence<string<256>> topic_aliases; }

    ;
  • Updated: Tue, 12 Jul 2016 14:44 GMT

Review comments Remedy IT on RPC4DDS

  • Key: DDSRPC_-3
  • Legacy Issue Number: 19693
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This is not a 100% review, we focused on the basic profile together with the IDL and after receiving the initial comments of the AB and the fact that there is not one submission we didn't complete a detailed review. We didn't review the github code.

    IDL zip (mars/14-11-05)
    rpc_types.idl:
    Uses the RTI specific top-level annotation. Also top-level is illegal according to the IDL grammar.
    Uses anonymous types
    robot.idl:

    Document (mars/14-11-02)
    Section 4
    reference to CORBA should be updated to CORBA v3.3
    reference to IDL should be updated to CORBA v3.3
    reference for DDS4CCM lacks document number
    reference for DDS-Cxx-PSM and DDS-Java-PSM should be updated to the formal version
    reference to github, how can we in the future pinpoint the exact version of the files mentioned, shouldn't the reference be more explicit about which version?
    reference to IDL 3.5 is lacking (used in section 8.3.1)

    Section 5
    Shouldn't there be a reference in section 4 for this quote?

    Section 8.1
    The spec talks about “communication patterns”, but in the context of UCM we are talking about “interaction patterns”, what about adopting the UCM term?

    Section 8.2.1
    In the second paragraph its says “the service implementation contains a data reader to read the method name”, but shouldn't it be “the service implementation contains a data reader which receives the request and after that reads the method name and the parameters.”
    Can't the diagram be placed after the first paragraph, it is now on the next page but we refer in text already to it).
    Third paragraph, at the end “are filtered out”.
    Second paragraph, the fact that a content-based filter “is” used forces that everyone must do this (which is the most logical implementation), but shouldn't it be “could”
    In the 4rd paragraph it mentions “asynchronous invocations”, but this is not mentioned in 8.2.2.1, how do asynchronous invocations look like with the function call style in the basic profile?

    Section 8.2.3
    Isn't it better to keep the term “client” instead of introducing “requester”
    Where in this document is the API defined to get the request id at both sides for implicit or explicit?

    Section 8.2.5
    “ it is” instead of “It is”

    Section 8.3.1
    What about the support for modules in IDL. In larger systems it will almost get impossible to guarantee the uniqueness of an interface when multiple parts are integrated. Also with an UCM approach modules are the way to group interfaces together. The module is now completely left which could lead to problems in a larger system. To our idea a change of an interface to another module is something that RPC4DDS shouldn't silently adapt to

    Section 8.3.1.2
    Use a reference to DDS-XTypes in the first paragraph, not in the 3rd
    Section xx
    What about collisions in the implied IDL types, hashes, etc. If a collision appears what are the rules to follow, because client and service could be developed by independent groups and DDS vendors which should than follow the same rules

    Section xx
    The spec uses IDL anonymous types in some places, these are deprecated and prevented to our idea.

    Section 8.4
    “by the used,”??

    Section 8.2.1
    Why include space as part of user_def_alpha_num?

    Section 8.4.2.3
    Reference error

    Section 8.4.3.3
    Reference error

    Section 8.5.1.1.1
    Why is SequenceNumber_t not using an “unsigned long long”. It is now a struct but there is no explanation in the specification about high and low

    Section 8.5.1.1.2
    Space missing before “shall” on 3rd line
    Why not put the implied types into a nested module so that they don't pollute the user IDL module and resulting code, doxygen documentation, etc

    Section 8.5.1.1.3
    For the result unions, why is not the unknownEx be part of the RobotControl_Return union as described on page 25, that would save a lot of union members. This exception is generic and independent of the operation.
    What when the user has an interface with a user defined parameter with the name return_ and there is a return value? This leads to a clash in the generated struct
    For the result struct, with IDL attributes it is possible to define separate exceptions with the set and the get of the attribute (getraises/setraises), this is not reflected in the result mapping
    What if there is a clash between the const hash name and user defined IDL?

    Section 8.5.1.1.4
    Why not put the implied types into a nested module so that they don't pollute the user IDL module and resulting code, doxygen documentation, etc
    Typo Non-noramtive

    Section 8.5.1.2.1
    Shouldn't the dds::rpc scope be used when the annotations are used?
    We still doubt the need to introduce @choice, with a union with the hash as discriminator value the is always one value active and there is a quick lookup at runtime. It works for the basic profile so why introduce this new IDL behavior for the enhanced one?
    What is the behavior of @autoid with a hash-collision? Also what happens when operations are reordered at the moment there is a hash-collision? Couldn't that break interoperability?
    What when the user has an operation remoteEx in his interface IDL?

    Section 8.5.2
    What is the mapping for the return codes when the regular IDL to IDL2C+, IDL2C+11, etc language mappings are used
    What is the error when the remote service is not there (for example not running or not reachable), which exception do I get back?
    What when the service crashes during handling of the request, what kind of error do I get back, what is the timeout? How can configure timeouts etc?

    Section 8.7.1
    Evolution should be evolution.

    Section 8.7.1.3
    What about changing the exception specification of an operation?

    Section 8.8.2
    Not a legal IDL struct definition, struct has to be removed from its members

    Section 8.8.2.1/8.8.2.2
    Add a reference to where in this specification this language binding is provided

    Section 8.10.1
    What about the library name RTI DDS currently supports. It is very helpful to have multiple QoS profiles in one file and the spec should define how this works

  • Reported: DDS-RPC 1.0b1 — Thu, 18 Dec 2014 05:00 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Split issue in multiple smaller issues

    Split issue in multiple smaller issues.
  • Updated: Tue, 12 Jul 2016 14:44 GMT

Add a write_sequence() operation to DataWriter

  • Key: DDS15-198
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS PIM DataReader read/take operations return a sequence. However there is no similar operation on the DataWriter.

    This makes the API non-symmetric.

    In fact the new DDS C++ PSM added a write() operation that takes a forward iterator. Which now is only available in this PSM and not the others.

    This operation should be added to the PIM as it is a generic capability that should be available on all PSMs.
  • Reported: DDS 1.4 — Fri, 1 Jul 2016 01:12 GMT
  • Updated: Fri, 1 Jul 2016 01:12 GMT

Correct inconsistency on the URLs for the machine readable documents

  • Key: DDSJAVA11-17
  • Status: open  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The machine-readable file URLs on the
    FTF report (ptc/15-09-21) and FTF 2 convenience document
    (ptc/15-09-13) disagree.

    The correct ones are the ones used in the FTF 2 document because these are consistent which the reference schema files that appear in the XML files also included as part of the specification.

    If nothing is done the URLs on the cover of the report (ptc/15-09-21) take precedence over the ones in the FTF2 specification, so it is imperative to re-issue the report to correct this.
  • Reported: DDS-Java 1.0 — Thu, 19 May 2016 00:35 GMT
  • Updated: Thu, 19 May 2016 00:37 GMT

Clarify behavior of "take" operation

  • Key: DDS15-175
  • Legacy Issue Number: 10365
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The act of taking a sample removes it from the DataReader so it cannot be ‘read’ or ‘taken’ again." See my earlier comment. Apparently if there are other DataReaders for the same Topic and the same Subscriber, their samples are not disturbed. Assuming this is true, it should be stated.
  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 18:40 GMT

Behavior of multiple calls to create_topic -- Section: 2.1.2.3.2

  • Key: DDS15-180
  • Legacy Issue Number: 10360
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "A Topic is identified by its name, which must be unique in the whole Domain." There is nothing in the description of create_topic that indicates that this constraint is enforced. Is it possible for multiple domain_participants to execute create_topic with the same name? What happens if they specify different types?
  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Sat, 2 Apr 2016 20:36 GMT

Clarify RxO behavior for DURABILITY Qos

  • Key: DDS15-196
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This issue was reported by email by Virginie Watine from THALES.

    Assume a DW is TRANSIENT and a DR is VOLATILE.
    According to the RxO policy attached to that QoS, they should match (all the other factors being OK). Is it correct?
    (at least that is what the spec says)

    But what are the first samples that are provided to the DR? I assume it receives only the ones that are produced after its creation (as opposed to a DR with TRANSIENT which receives also the ones that have been produced before its creation). Is it correct?
    (that point is not explained in the spec – or at least is not easy to find)
  • Reported: DDS 1.4 — Thu, 31 Mar 2016 18:04 GMT
  • Updated: Thu, 31 Mar 2016 18:07 GMT

Permissions XSD in section 9.4.1.3 and example in 9.4.1.4 are inconsistent with normative machine readable file

  • Key: DDSSEC_-187
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The normative machine readable XSD file for the permissions document schema
    http://www.omg.org/spec/DDS-SECURITY/20160301/dds_security_permissions.xsd

    Is inconsistent with what is copied into section 9.4.3.1. The most glaring difference is that the root of the XSD document is the element "<dds>" whereas in section 9.4.1.3 and 9.4.1.4 this root is omitted and it jumps directly to the nested subelement "<permissions>"

    The machine readable XSD is correct as this is also consistent with the format for the Governance file which also has "<dds>" as root.
  • Reported: DDS-Security 1.0b1 — Fri, 25 Mar 2016 18:12 GMT
  • Disposition: Deferred — DDS-Security 1.0
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force
  • Updated: Tue, 29 Mar 2016 15:35 GMT

[DDS] Data types permissible as topic key fields

  • Key: DDS15-30
  • Legacy Issue Number: 14089
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    The DDS 1.2 standard does not mention which IDL data types are permissible as
    key fields for topic data types.

    As the data types for keys, at least enumeration types and integral types
    (octet/short/long etc.) should be permissible.
    However, it would be desirable to also allow simple (non-array) typedefs
    of these types.
  • Reported: DDS 1.2 — Wed, 22 Jul 2009 04:00 GMT
  • Updated: Tue, 15 Mar 2016 16:05 GMT

Force KEEP_ALL to be RELIABLE Section: 2.1.3.18

  • Key: DDS15-171
  • Legacy Issue Number: 10369
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "If the kind is set to KEEP_ALL, then the Service will attempt to maintain and deliver all the values of the instance to existing subscribers. The resources that the Service can use to keep this history are limited by the settings of the RESOURCE_LIMITS QoS. If the limit is reached, then the behavior of the Service will depend on the RELIABILITY QoS. If the reliability kind is BEST_EFFORT, then the old values will be discarded." This violates the ordinary English meaning of KEEP_ALL. Can't the same effect be achieved by specifying KEEP_LAST with history_depth=max_samples_per_instance? If so, then KEEP_ALL should not be allowed for RELIABILITY=BEST_EFFORT.
  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 15 Mar 2016 14:41 GMT

Cancel coherent update

  • Key: DDS15-45
  • Legacy Issue Number: 10812
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    It is possible that a transaction needs to be canceled, for example because one of the participating writers gets blocked and finally stops while returning a timeout. This might lead to the situation in which you want to cancel all preceding writes as well.

    Solution:
    To be able to cancel such a transaction, we propose to add an additional operation like e.g. cancel_coherent_changes would then remove all samples that have already been written since the last begin_coherent_changes.
  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Tue, 15 Mar 2016 14:23 GMT

Specify Publishers with PRESENTATION access_scope GROUP should use same order for DataWriters

  • Key: DDS15-190
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    When PRESENTATION access_scope is GROUP samples need to e ordered across DataWriters. This is very hard/impossible if some writers use source_timestamp and others reception timestamp order

    Propose that this is not allowed. If PRESENTATION access_scope is GROUP then all writers must have same ORDER. E.g. as writers are created if one is not consistent it should give an error
  • Reported: DDS 1.4 — Tue, 15 Mar 2016 14:11 GMT
  • Updated: Tue, 15 Mar 2016 14:11 GMT

Enhancement to resolution of DDSWEB-3 / DDSWEB-20

  • Key: DDSWEB-25
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This issue proposes a minor enhancement/correction to the resolution in http://solitaire.omg.org/browse/DDSWEB-20 to account for the name changes introduced in the resolution of DDSWEB-1.

    These changes apply to the new section 8.3.5.2 added by the resolution of DDSWEB-3 / DDSWEB-20

    In the Table at the end of 8.3.5.2 before 8.3.5.2.1 replace element name
    dds.dataset_library_dataset.readSampleSeq with
    dds.dataset_library_dataset.read_sample_seq

    In the same Table, replace element name
    dds.dataset_library_dataset.writeSampleSeq with
    dds.dataset_library_dataset.write_sample_seq

    On section 8.3.5.2.1 Under XML preparation, item number 2. Append the following sentence at the end of that item:

    Schema name-space (xmlns) and location (schemaLocation, noNamespaceSchemaLocation) attributes are discarded.

    On section 8.3.5.2.1 Under Transformation rules, item number 4.4.1. Add the sub-item 4.4.1.1 with contents:

    4.4.1.1 If the resulting attribute name matches the element_name_property (see 4.4.2) then the property name is constructed as the concatenation of “@”, the element name, and the attribute name.
  • Reported: DDS-WEB 1.0b1 — Tue, 11 Aug 2015 07:06 GMT
  • Disposition: Resolved — DDS-WEB 1.0
  • Disposition Summary:

    Make requested enhancements

    Accept proposed changes and also make adjustments to the non-normative file webdds_rest1_example.xml to include the results of the change. Also adjust schema locations on webdds_rest1.xsd


    Changes to webdds_rest1_example.xml are:

    Change of xsi:noNamespaceSchemaLocation from:
    xsi:noNamespaceSchemaLocation="webdds_rest1.xsd"
    To
    xsi:noNamespaceSchemaLocation="http://www.omg.org/spec/DDS-WEB/20150901/webdds_rest1.xsd"

    Change of xsi:schemaLocation from:
    xsi:schemaLocation="http://www.omg.org/dds/ webdds_rest1.xsd"
    To
    xsi:schemaLocation="http://www.omg.org/dds/ http://www.omg.org/spec/DDS-WEB/20150901/webdds_rest1.xsd"
    Rename element <ShapeType> nested inside <dataset_library> to <ShapeStruct> this happens in 3 places.


    Changes to webdds_rest1.xsd are:
    Change of xsi:schemaLocation from:
    <xs:include schemaLocation="DDS_QoSProfile.xsd"/>
    To:
    <xs:include schemaLocation="http://www.omg.org/spec/dds4ccm/20110201/DDS_QoSProfile.xsd"/>

    Change of xsi:schemaLocation from:
    <xs:import
    schemaLocation="dds-xtypes_type_definition.xsd"
    namespace="http://www.omg.org/ptc/2011/01/07/XML_Type_Representation/"/>
    To:
    <xs:import
    schemaLocation="http://www.omg.org/spec/DDS-XTypes/20120202/dds-xtypes_type_definition.xsd"
    namespace="http://www.omg.org/ptc/2011/01/07/XML_Type_Representation/"/>
  • Updated: Tue, 22 Dec 2015 15:08 GMT
  • Attachments:

Missing HTTP return code for DDS_ERROR

  • Key: DDSWEB-9
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Page 63 – section 8.3.2) the ReturnCode for the DDS_ERROR is not specified. A suitable value could be 500 “Internal Server Error". (same we do for GENERIC_SERVER_ERROR)
  • Reported: DDS-WEB 1.0b1 — Fri, 7 Aug 2015 20:53 GMT
  • Disposition: Resolved — DDS-WEB 1.0
  • Disposition Summary:

    Add mapping from DDS_ERROR to HTTP status 500


    At the bottom of Section 8.3.2 add another bullet following all the ones already there:

    • ReturnCode DDS_ERROR shall be mapped to HTTP status 500 Internal Server Error
  • Updated: Tue, 22 Dec 2015 15:08 GMT

Inconsistent and incomplete specification of resource representations

  • Key: DDSWEB-14
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Table 5 in Section 8.3.3 lists the resource representations that appear in the bodies of the REST operations and Table 6 specifies the location in the XSD where those representations are defined.
    However the references to the XSD in Table 6 point to the definition of a “type” inside the XSD (for example participantObjectRepresentation points to the xs:complexType named “DomainParticipant”). It would be better if the specification of the representation was done in terms of an XML element (of an XSD-defined type) rather than in terms of the type itself. If the specification is done referencing just the XSD type the resulting definition does not specify an outer XML element name. This is ambiguous and could be interpreted as implying that there is no outer XML element (e.g. the information appears directly inside <body> section of the HTML). If the definition was done using an XSD element, the resource representation would appear inside a single XSD element facilitating parsing and avoiding potentially conflicting interpretations of the specification.
    In addition applicationRepresentation and qosRepresentation appear in webdds_rest1.xsd but are missing from section 8.3.4. They should be added to 8.3.4.
    Also missing is the definition of a list of participantObjectRepresentation and list of typeObjectRepresentation.
    The reference to DDS-XTYPES in Table 6, second row is incorrect. The referenced schema is in webdds_rest1.xsd, not DDS-XTYPES.
  • Reported: DDS-WEB 1.0b1 — Mon, 10 Aug 2015 08:36 GMT
  • Disposition: Resolved — DDS-WEB 1.0
  • Disposition Summary:

    Align section 8.3.4 with the XSD

    Align section 8.3.4 with the XSD. This means:

    • Update Table 5 and changing the “HTTP request and response bodies” column in the places where it says “List of <someObjectRepresentation>” to saying “<someObjectRepresentation>List” this applies to:
      • List of participantObjectRepresentation
      • List of typeObjectRepresentation
      • List of waitsetObjectRepresentation
      • List of registerTypeObjectRepresentation
      • List of topicObjectRepresentation
      • List of publisherObjectRepresentation
      • List of subscriberObjectRepresentation
      • List of datawriterObjectRepresentation
      • List of dataReaderObjectRepresentation
      • List of dataSampleRepresentation, except this should be changed to readSampleList intstead of dataSampleRepresentationList
    • Modify Table 6 adding adding participantObjectRepresentationList, applicationObjectRepresentation, applicationObjectRepresentationList, qosLibraryObjectRepresentation, qosLibraryObjectRepresentationList, qosProfileObjectRepresentation, and qosProfileObjectRepresentationList.
    • Modify Table 6 second column ( “Format for the object representation” ) so the object representation is defined as an XML element based on types in webdds_rest1.xsd rather than defined as an XSD type directly.
  • Updated: Tue, 22 Dec 2015 15:08 GMT
  • Attachments:
    • webdds_table6.docx 19 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Correct minor inconsistencies in naming

  • Key: DDSWEB-33
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The XSD uses the element name "domain_participant" while the REST resources refer to it as "participant". The two should be aligned.

    In some places of the document it refers to the different content types as webdds+xml and wendds+json. Other parts of the document use dde-web+xml and dds-web+json for essentially the same. These should be aligned.
  • Reported: DDS-WEB 1.0b1 — Thu, 20 Aug 2015 10:39 GMT
  • Disposition: Resolved — DDS-WEB 1.0
  • Disposition Summary:

    Correct the naming inconsistencies

    Use "domain_participant" for the resource URIs instead of "participant"

    Use "dds-web+xml" instead of "webdds+xml"

    This resolution shall apply after all other issue resolutions have been applied.
  • Updated: Tue, 22 Dec 2015 15:08 GMT

Use of WebSockets is underspecified

  • Key: DDSWEB-30
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 8.5 “Transport-LevelProtocolConsiderations” paragraph 4 states that WebSockets can optionally be used. Specifically it says”
    “As an option implementers may support upgrading the connection to using WebSockets in compliance with IETF 6455 (The WebSocket Protocol) [14].”

    However this information is not sufficient to ensure implementers of the specification manage the connection and stream the content in an interoperable way. Assume for example that a particular HTTP connection is upgraded to WebSockets. When is that connection closed? Does the client still need to issue a reparate “GET” operation to keep reading data or can data continue to be streamed from the server back to the client as it arrived on a DDS DataReader?

    These issues should be clarified to ensure interoperability independently of the implementation of the specification.
  • Reported: DDS-WEB 1.0b1 — Tue, 18 Aug 2015 03:13 GMT
  • Disposition: Resolved — DDS-WEB 1.0
  • Disposition Summary:

    Add description of WebSocket transport

    The main priority is to provide a way write and read DDS data using WebSockets. These are the performance-critical operations. The remaining operations, namely creation and deletion of entities, definition of data-types, QoS settings, etc., could continue to use the HTTP-based REST API.

    The resolution of this issue should allow information flow over WebSockets using one or more TCP connections.

    The resolution of this issue should be applied after the resolution of issue WEBDDS-7 which modified section 8.5 to clarify how to do secure HTTPS.
  • Updated: Tue, 22 Dec 2015 15:08 GMT
  • Attachments:

X-Types Dependency

  • Key: DDSWEB-8
  • Legacy Issue Number: 19251
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    mars/13-05-21 introduces a dependency on X-Types making this specification only implementable by DDS vendors that support X-Types.

    This dependency is superfluous and should be removed
  • Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
  • Disposition: Closed; No Change — DDS-WEB 1.0
  • Disposition Summary:

    Reject issue as the claim of requiring compliance with DDS-XTYPES is not correct

    An implementation compliant with DDS-WEB is not required to implement or comply with DDS-XTYPES. The dependency on DDS-XTYPES is simply a reuse of some syntactic elements, specifically the syntax of the XML description of types and data.

    It is entirely possible to comply with DDS-WEB and not implement DD-XTYPES all it is required is to understand the syntax of those XML documents and implement the proper parsers.

    Stated differently the dependency on DDS-XTYPES is similar to the dependency on other specifications like as dds4ccm, the IDL, XML, and XSD specifications. It just points to specific document syntax defined on those specifications to avoid duplicating that syntax in the DDS-WEB specification.
  • Updated: Tue, 22 Dec 2015 15:08 GMT

Access Control Relationship with DDS Security

  • Key: DDSWEB-7
  • Legacy Issue Number: 19250
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The mars/13-05-21 introduces an AccessController, yet it is not clear how this relates to DDS security access control plug-in.

  • Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-WEB 1.0
  • Disposition Summary:

    Clarify AccessControl class and relationship to DDS-Security

    The confusion stems from modeling the client application as a "User" rather than simply a client. Also the requirement for a login/logout transaction is not what typical rest-api users are accustomed to. In most API's the authentication is tied to some API key/token that is passed as part of each request. That way the server does not need to retain session information.

    To clarify this the revised text renames "User" to "Client" and introduces a REST-API-Key explaining how it is included in the HTTP headers It also specifies how this mechanism leverages the security mechanisms built in HTTPS.
    The change is not very large in terms of the rest protocol itself. But a lot of text and figures are affected by the rename.
    The new figures are not attached to this resolution because there is another issue (DDSWEB-21) that will update most of the figures so it would be redundant to attach the figures twice. The changes to the figures are nevertheless listed as part of the revised text.
  • Updated: Tue, 22 Dec 2015 15:08 GMT

The title of the submission is misleading

  • Key: DDSWEB-2
  • Legacy Issue Number: 19245
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Today the term "Web Applications" usually refers to HTML5/JavaScript applications. Assuming this mainstream interpretation, the mars/13-05-21 is not at all providing "Web-Enabled DDS".

    This recommended specification should be split into a W3C and a REST PSM for DDS. In any case the name should be updated accordingly to avoid confusing end-users, claiming "Web-Enabled" when the mars/13-05-21 is really "Web-Disabled".

  • Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
  • Disposition: Closed; No Change — DDS-WEB 1.0
  • Disposition Summary:

    No changes needed the name seems appropriate

    The specification defines the means for applications using standard web protocols (HTTP/REST) to participate as first-class citizens as publishers and subscribers of data in the DDS Global Data space. This participation is realized by exposing a WebDDS Object Model and making it accessible via web-protocols as a set of REST resources, or some other standard web protocols (e.g. SOAP).

    The specification therefore enables applications built on various web technology stacks (e.g. JavaScript, Python, PHP, Perl , etc.) to communicate with native DDS applications. So the name "web enabled DDS" is precise and appropriate.
  • Updated: Tue, 22 Dec 2015 15:08 GMT

Namespace are non aligned with new PSMs

  • Key: DDSWEB-6
  • Legacy Issue Number: 19249
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The mars/13-05-21 uses WEBDDS as a namespace for everything. This is perseverating the orinignal sin of the DDS specification using DDS as nanespace.

    This fragile use of namespaces should be replaces with the same style used now by the new Java/C++ PSM. mars/13-05-21 should use something like:

    org.omg.dds.xyz
  • Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
  • Disposition: Closed; No Change — DDS-WEB 1.0
  • Disposition Summary:

    Reject change as these classes are purely descriptive and do not appear in any user-visible APIs

    These name spaces are only in the conceptual model of how the service works. They are not reflected in any user-visible objects or APIs. '

    A compliant implementation of the specification is not forced to use any of these classes or to name them according to the name used in the specification.

    For this reason there is no need to make any changes to the specification.
  • Updated: Tue, 22 Dec 2015 15:08 GMT

Wrong Acknoledgment

  • Key: DDSWEB-5
  • Legacy Issue Number: 19248
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The acknowledgment page include PrismTech. This should be removed as PrismTech – who was clearly against this specification – does not want to be claimed as supporting it in any form.

    This specification is of doubtful use and does not reflect in any mean or form PrismTech vision on what Web-Enabled really is.

  • Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-WEB 1.0
  • Disposition Summary:

    Remove PrismTech from section 6.2 Acknowledgements

    In Section 6.2 remove the second bullet that says:

    • PrismTech
  • Updated: Tue, 22 Dec 2015 15:08 GMT

Copyright Violation

  • Key: DDSWEB-4
  • Legacy Issue Number: 19247
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The sumission is using a PrismTech copyrighted picture w/o asking permission.

    Notice that PrismTech is not part of the submission. This should be addressed ASAP by the submitters as they are in violation of copyright rules.
  • Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-WEB 1.0
  • Disposition Summary:

    Replace figure 1

    Replace Figure 1 with the one attached
  • Updated: Tue, 22 Dec 2015 15:08 GMT
  • Attachments:

The URL prefix of the specification documents is not consistent with the XSD targetNamespace

  • Key: DDSWEB-1
  • Legacy Issue Number: 19449
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification documents are all under the namespace: http://www.omg.org/spec/DDS-WEB/20131122
    Whereas the XSD documents use targetNamespace that use different prefixes:

    webdds_rest1.xsd sets targetNamespace="http://www.omg.org/spec/WEBDDS/20130601/"

    webdds_soap1_types.xsd sets targetNamespace="http://www.omg.org/webdds/"
    webdds_soap1.wsdl sets targetNamespace ="http://www.omg.org/spec/WEBDDS/20130601/
    webdds_soap1_notify.wsdl sets targetNamespace ="http://www.omg.org/spec/WEBDDS/20130601/

    While this is technically allowed it is likely to cause confusion because the xmlns used in an XML must match the targetNamespace of the referenced XSD.

    For this reason it would be better that the three targetNamespace are consistent. For example, assume that the result of the FTF has the machine-readable documents under the URL prefix:
    http://www.omg.org/spec/DDS-WEB/20140901/

    Then the XSD documents should all use the same target namespace "http://www.omg.org/spec/DDS-WEB/20140901/"

    Note that it is allowed for multiple schemas to have the same targetNamespace and it is one of the recommended practices when all the schemas are conceptually related and there is no need to separate identify the origin/lineage of each element.
  • Reported: DDS-WEB 1.0b1 — Wed, 4 Jun 2014 04:00 GMT
  • Disposition: Resolved — DDS-WEB 1.0
  • Disposition Summary:

    Resolve by updating the schema file webdds_rest1.xsd and the non-normative example file webdds_rest1_example.xml

    This issue is addresses by updating the XSD shema file (webdds_rest1.xsd ) and the the non-normative example file webdds_rest1_example.xml

    The two files are attached. Replacing this two files is the only change to the specification to address the issue.

    What follows is the detailed description of the changes performed to those files and the reasons for them.

    • To increase the usability of the XSD the namespaces and imports should be re-organized. The webdds_rest1.xsd schema declaration should be modified to use http://www.omg.org/dds/ as the target namespace. The result should be as follows:
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns="http://www.omg.org/dds/" 
           xmlns:dds="http://www.omg.org/dds/" 
           xmlns:xtypes="http://www.omg.org/ptc/2011/01/07/XML_Type_Representation/" 
           targetNamespace="http://www.omg.org/dds/" 
           elementFormDefault="qualified"
           attributeFormDefault="unqualified">
    • The import of DDS_QoSProfile.xsd in the webdds_rest1.xsd should be changed to a “include”.
      Also note the issue filed to change the definition of elementName: 
           
    <!-- Issue filed on DDS4CCM (DDS_QoSProfile.xsd) change definition of elementName
         to <xs:pattern value="([a-zA-Z0-9_.])+" />
         Also make it into a Chameleon schema
    -->
    <xs:include	schemaLocation="DDS_QoSProfile.xsd"/>

    This issue also impacts the XML files associated with that schema file should be modified accordingly.

    • The root element for webdds_rest1_example.xml and elements xmlns, xmlns:dds, xmlns:xtype, and xsi:schemaLocation should be modified to match what is shown below: 
      <!-- This is file webdds_rest1_example.xml -->
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://www.omg.org/dds/"
    xsi:schemaLocation="http://www.omg.org/dds/    http://www.omg.org/spec/DDS-WEB/20150901/webdds_rest1.xsd"
    • Consistently follow snake_case naming convention for the element names in the XSD. Rename all CamelCase to snake_case for the XSD elements. The XSD types can remain in CamelCase. This renames webdds_rest1.xsd XSD elements:

      sourceTimestamp, instanceHandle, validData, instanceState, sampleState, viewState, readSampleInfo, sampleData, writeSampleInfo, returnCode, returnMessage, accessToken, sessionId.

      To:

      source_timestamp, instance_handle, valid_data, instance_state, sample_state, view_state, read_sample_info, sample_data, write_sample_info, return_code, return_message, access_token, session_id.

    • Consistently use lower case for all type definitions in the XSD with CamelCase convention.
      This rename webdds_rest1.xsd XSD types:

      RegisterType, Topic, TopicList, DataWriter, DataWriterList, DataReader, DataReaderList, Publisher, PublisherList, Subscriber, SubscriberList, DomainParticipant, DomainParticipantLibrary, StatusCondition, ReadCondition, ContentFilter, ParameterList, Waitset, ReturnStatus, Application, AuthenticatedSession

      To:

      registerType, topic, topicList, dataWriter, dataWriterList, dataReader, dataReaderList, publisher, publisherList, subscriber, subscriberList, domainParticipant, domainParticipantLibrary, statusCondition, readCondition, contentFilter, parameterList, waitset, returnStatus, application, authenticatedSession

    • Introduce the following new definition on the webdds_rest1.xsd XSD: 
          <xs:simpleType name="elementNameReference">
        <xs:restriction base="xs:string">
            <xs:whiteSpace value="collapse"/>
            <xs:pattern value="((::)?[a-zA-Z0-9_.])+"/>
        </xs:restriction>
    </xs:simpleType>
    • Change the type of the “_ref” attributes (type_ref, register_type_ref, topic_ref), from “dds:elementName” to “elementNameReference”.
      Change the type of the “base_name” attribute on element domainParticipant to “elementNameReference”.
    • Change all type attributes in the elements of webdds_rest1.xsd that refer to types defined in DDS_QoSProfile.xsd. Currently all these references have the prefix “dds:” drop that prefix since the target namespace is now the same. Effectively this removes all the “dds:” from the values of the “type=” attribute.
    • Rename the webdds_rest1.xsd XSD types “Sample” and “SampleSeq” to “readSample” and “readSampleSeq” also changing the definition of “Sample” to use “xs:any” and “data” as an element name so the the type “xs:Sample” becomes: 
           <xs:complexType name="anyDataValue">
		<xs:sequence>
			<xs:any processContents="lax" minOccurs="1" maxOccurs="1"/>
		</xs:sequence>
     </xs:complexType>

    <xs:complexType name="readSample">
        <xs:sequence>
            <xs:element name="readSampleInfo" type="readSampleInfo" 
                                minOccurs="0" maxOccurs="1"/>
            <xs:element name="data" type="anyDataValue" minOccurs="0" maxOccurs="1"/>
        </xs:sequence>
    </xs:complexType>
    • Add the following definitions to the webdds_rest1.xsd XSD: 
         <xs:complexType name="writeSample">
        <xs:sequence>
            <xs:element name="write_sample_info" type="writeSampleInfo" minOccurs="0" maxOccurs="1"/>
            <xs:element name="data" type="anyDataValue" minOccurs="0" maxOccurs="1"/>
        </xs:sequence>
    </xs:complexType>
    
     <xs:complexType name="writeSampleSeq">
        <xs:sequence>
            <xs:element name="sample" type="writeSample" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="writeSampleSeq">
        <xs:sequence>
            <xs:element name="sample" type="writeSample" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType>
    • Modify the definition of application to match what follows. Remove unused type authenticatedSession from webdds_rest1.xsd 
         <xs:complexType name="application">
      <xs:annotation>
        <xs:documentation xml:lang="en-US">
          The Application is a a collection of domain participants they can refer to participants
          in a domain_partitipant_library by the inheritance provided by the base_name attribute
        </xs:documentation>
      </xs:annotation>
      <xs:choice maxOccurs="unbounded">
        <xs:element name="domain_participant" maxOccurs="unbounded" type="domainParticipant"/>
      </xs:choice>
      <xs:attribute name="name" type="elementName" use="required"/>
    </xs:complexType>
    • Add types qosLibraryList, qosProfileList, applicationList, domainParticipantList, to webdds_rest1.xsd 
      <!-- definitions to be added to webdds_rest1.xsd -->
 <xs:complexType name="applicationList">
       <xs:sequence minOccurs="0" maxOccurs="unbounded">
           <xs:element name="application" minOccurs="0" type="application"/>
       </xs:sequence>
    </xs:complexType>  

 <xs:complexType name="qosLibraryList">
       <xs:sequence minOccurs="0" maxOccurs="unbounded">
           <xs:element name="qos_library" minOccurs="0" type="qosLibrary"/>
       </xs:sequence>
    </xs:complexType>    
  
<xs:complexType name="qosProfileList">
       <xs:sequence minOccurs="0" maxOccurs="unbounded">
           <xs:element name="qos_profile" minOccurs="0" type="qosProfile"/>
       </xs:sequence>
    </xs:complexType>    

<xs:complexType name="domainParticipantList">
       <xs:sequence minOccurs="0" maxOccurs="unbounded">
           <xs:element name="domain_participant" minOccurs="0" type="domainParticipant"/>
       </xs:sequence>
    </xs:complexType>
    • Add types dataset and datasetLibrary to the webdds_rest1.xsd XSD. 
       <!--  ======================================================================== -->
    <xs:complexType name="dataset">
        <xs:all  minOccurs="0" maxOccurs="1">  
            <xs:element name="read_sample_seq" type="readSampleSeq" minOccurs="0" maxOccurs="1" />
            <xs:element name="write_sample_seq" type="writeSampleSeq"  minOccurs="0" maxOccurs="1" />
        </xs:all>
        <xs:attribute name="name" type="elementName" use="required"/>
    </xs:complexType>
    
    <xs:complexType name="datasetLibrary">
        <xs:annotation>
            <xs:documentation>
                Contains Collections of data samples
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:choice maxOccurs="unbounded">
                <xs:element name="dataset" type="dataset" minOccurs="0" maxOccurs="unbounded"/>
            </xs:choice>
        </xs:sequence>
        <xs:attribute name="name" type="elementName" use="required"/>
    </xs:complexType>
    • Modify webdds_rest1.xsd XSD as follows
      Rename element “restdds” to “dds”
      Modify the type “dataReader” moving the documentation annotation on the “query_condition” element to the “content_filter” element.
      Rename the type “contentFilter” to “filter” and modify documentation accordingly
      Remove the type definitions for instanceState, viewState, and sampleState. Change references the these types in type readSampleInfo to instanceStateKind, viewStateKind, and sampleStateKind, respectively. Change also readSampleInfo type so that so that minOccurs of any of the child elements 0 instead of 1. The resulting readSampleInfo type should match this:
    <xs:complexType name="readSampleInfo">
        <xs:all>
            <xs:element name="source_timestamp" type="time" minOccurs="0" maxOccurs="1"/>
            <xs:element name="valid_data" type="xs:boolean" minOccurs="0" maxOccurs="1"/>
            <xs:element name="instance_handle" type="instanceHandle" minOccurs="0" maxOccurs="1"/>
            <xs:element name="instance_state" type="instanceStateKind" minOccurs="0" maxOccurs="1"/>
            <xs:element name="sample_state" type="sampleStateKind" minOccurs="0" maxOccurs="1"/>
            <xs:element name="view_state" type="viewStateKind" minOccurs="0" maxOccurs="1"/>
        </xs:all>
    </xs:complexType>

    Modify the definition of the “registerType” type adding a “format” attribute. 

       <xs:attribute name="format" type="xs:string" use="optional">
          <xs:annotation>
              <xs:documentation>
                  Format used to read/write data of this type. If left unspecified
                  the default format is “XML”
               </xs:documentation>
           </xs:annotation>
        </xs:attribute>
    • Modify the definition of element “condition” within type “waitset” adding an intermediate “waitsetCondition” type that is just a reference to a condition. The added waitsetCondition and modified waitset is: 
         <xs:complexType name="waitsetCondition">
            <xs:attribute name="condition_ref" type="elementNameReference" use="required">
           <xs:annotation>
              <xs:documentation xml:lang="en-US">
                  Must refer to a condition associated with a DDS entity
              </xs:documentation>
           </xs:annotation>
        </xs:attribute>
    </xs:complexType>
    
    <xs:complexType name="waitset">
        <xs:sequence>
            <xs:element name="condition" type="waitsetCondition"/>
        </xs:sequence> 
        <xs:attribute name="name" type="elementName" use="required"/>                      
    </xs:complexType>
    • Modify the restdds element of webdds_rest1_example.xml to include the additional children and also to refer to the xtypes:types element directly. The resulting element is: 
         <xs:element name="dds">
        <xs:complexType>
            <xs:sequence>
                 <xs:choice maxOccurs="unbounded">
                    <xs:element name="qos_library" type="qosLibrary" minOccurs="0" maxOccurs="unbounded"/>
                    <xs:element ref="xtypes:types" minOccurs="0" maxOccurs="unbounded"/>
                    <xs:element name="waitset_library" type="waitsetLibrary" minOccurs="0" maxOccurs="unbounded"/>                   
                    <xs:element name="domain_participant_library" type="domainParticipantLibrary" maxOccurs="unbounded"/>
                    <xs:element name="application" type="application"  maxOccurs="unbounded"/>
                    <xs:element name="dataset_library" type="datasetLibrary" maxOccurs="unbounded"/>
                </xs:choice>
            </xs:sequence>        
        </xs:complexType>
    </xs:element>
    • Modify the non-normative webdds_rest1_example.xml to match the changes in the XSD. Also add example use for more of the elements defined in the XSD, this means adding examples for qos_library, dataset, waitset_library. Also change the type “ShapeType” to be inside a module.
  • Updated: Tue, 22 Dec 2015 15:08 GMT
  • Attachments:

Qos Profiles and Types are underspecified and inconsistent with XSD

  • Key: DDSWEB-21
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    There is no description of QosProfiles and Types in section 7.4 where all the other DDS proxy classes are described.

    There are no mappings of QosProfiles and Types to the REST platform in section 8.3.3 nor to the SOAP platform in section 8.4 Table 9 .

    QoS profiles are scoped inside applications in section 8.3.1. This is inconsistent with the XSD where they appear inside a “qosLibrary” element.

    Types are scoped inside applications. This is inconsistent with the XSD where they appear inside the root “restdds”.

    Also the name WSDDS should we changed so something better. “WSDDS” has no meaning as it is not a “web service”. In the specification is used to name specific singleton object that serves as a way to bootstrap the system. Hence a better name would be WebDDS::Root. This only affects the conceptual model. It has no user-visible effect on the the exposed APIs and protocols.
  • Reported: DDS-WEB 1.0b1 — Mon, 10 Aug 2015 10:38 GMT
  • Disposition: Resolved — DDS-WEB 1.0
  • Disposition Summary:

    Update UML model with additional classes. Add missing operations and update Table 5


    Make the following changes to the UML model.

    • Change the name of class WebDDS::WSDDS to WebDDS::Root
    • Introduce a WebDDS::QosLibrary class owned by WedDDS::Root
    • Move class WebDDS::QosProfile from its current owner (Applications) to be owned by WebDDS::QosLibrary
    • Move class WebDDS::Type from its current owner (Applications) to be owned by WebDDS::Root.
    • Add new operations to WebDDS::Root: get_applications, create_qos_library, delete_qos_library, get_qos_libraries,
    • Move operations create_type, delete_type, get_type from WebDDS::Application to WebDDS::Root
    • Remove the relationships from WebDDS::Application to WebDDS::Type and WebDDS::QosProfile. Instead there should be “uses” relationships from WebDDS::Participant to those classes.


    Regenerate figures 3, 4, 6, 7, 8, 9, 10, and 11. Such that they include the above-listed changes. The new figures are attached to this issue resolution.


    Change the specification where it mentions object “WSDDS”. Replace that with either “WebDDS::Root” or “WebDDS” as described below:

    • Section 7.2 (2 times)
    • Section 7.3 (4 times) the first 2 replace with “WebDDS::Root” the second two replace with “WebDDS”
    • Title of section 7.3.1. Change title to “Class WebDDS::Root”
    • Figure 7 caption change “WSDDS” to “WebDDS::Root”
    • Section 7.3.3 change “WSDDS” to “WebDDS::Root”
    • Table 5, (2 times) change “WSDDS” to “WebDDS::Root”
    • Section 8.4 change “WSDDS” to “WebDDS::Root”


    Modify section 7.3.1 as specified below:

    • Rename WebDDS::Root class operations “login” to “create_application”.
    • Rename WebDDS::Root class operations “logout” to “delete_application”.


    Modify section 7.3.1 first paragraph:
    Change:
    The WSDDS singleton directly manages three kinds of objects: Users, Applications, and AccessController.

    To:
    The WebDDS::Root singleton directly manages five kinds of objects: Client, Application, Type, QosLibrary, and AccessController.


    Add The following subsections to 7.3.1
    * 7.3.1.3 Operation: get_applications
    * 7.3.1.4 Operation: create_qos_library
    * 7.3.1.5 Operation delete_qos_library,
    * 7.3.1.6 Operation: get_qos_libraries
    These subsection appear in the attachment file subsections_7313_to_7316.docx


    Move operations: create_type , delete_type, get_type from WebDDS::Application to WebDDS::Root. create_type moves from section 7.4.3.4 to section 7.3.1.7. Operation delete_type moves from section 7.4.3.5 to section 7.3.1.8. Operation get_type moves from section 7.4.3.6 to section 7.3.1.9.


    Modify operation create_type (new section 7.3.1.7) to match the attached file webdds_section_7317.docx


    Modify 7.3.1.8 Operation: delete_type
    Replace last sentence:
    It deletes the located WebDDS::Type and the associated DDS:DynamicType object.

    With:
    It deletes the located WebDDS::Type object. If the operation succeeds it returns OK. Otherwise it returns GENERIC_SERVICE_ERROR.


    Modify 7.3.1.9 Operation: get_type.
    Change the name to “get_types” and replace description with that of the attached file webdds_section_7319.docx


    Add section 7.4.10 with the text in the attached file webdds_section_7410.docx :


    Add section 7.4.11 with the text below:
    7.4.11 Class WebDDS::QosProfile
    This class represents a Qos Profile as defined in the DDS4CCM specification (http://www.omg.org/spec/dds4ccm/) version 1.1.

    A Qos Profile is a named object containing DDS Qos definitions for each kind of DDS Entity: DomainParticipant, Topic, Publisher, Subscriber, DataWriter, and DataReader. This grouping under a single Qos Profile object enables applications to specify desired Qos by indicating only the name of the Qos Profile object to use. As DDS Entities are created the proper Qos is selected based on the kind of DDS entity.


    Update Table 5 in Section 8.3.3 the REST mappings with the following changes:
    Change:
    Application::create_type

    To:
    Root::create_type

    Change URI from:
    /applications/<appname>/types

    To:
    /types


    Change:
    Application::delete_type

    To:
    Root::delete_type

    Change URI from:
    /applications/<appname>/types/<typename>

    To:
    /types/<typename>


    Change:
    Application::update_type

    To:
    Root::update_type


    Add the operations in the attached webdds_table5_added_operations.docx to Table 5 in Section 8.3.3:
  • Updated: Tue, 22 Dec 2015 15:08 GMT
  • Attachments:

Inconsistent and incomplete specification of resource representations

  • Key: DDSWEB-19
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Table 5 in Section 8.3.3 lists the resource representations that appear in the bodies of the REST operations and Table 6 specifies the location in the XSD where those representations are defined.
    However the references to the XSD in Table 6 point to the definition of a “type” inside the XSD (for example participantObjectRepresentation points to the xs:complexType named “DomainParticipant”). It would be better if the specification of the representation was done in terms of an XML element (of an XSD-defined type) rather than in terms of the type itself. If the specification is done referencing just the XSD type the resulting definition does not specify an outer XML element name. This is ambiguous and could be interpreted as implying that there is no outer XML element (e.g. the information appears directly inside <body> section of the HTML). If the definition was done using an XSD element, the resource representation would appear inside a single XSD element facilitating parsing and avoiding potentially conflicting interpretations of the specification.
    In addition applicationRepresentation and qosRepresentation appear in webdds_rest1.xsd but are missing from section 8.3.4. They should be added to 8.3.4.
    Also missing is the definition of a list of participantObjectRepresentation and list of typeObjectRepresentation.
    The reference to DDS-XTYPES in Table 6, second row is incorrect. The referenced schema is in webdds_rest1.xsd, not DDS-XTYPES.
  • Reported: DDS-WEB 1.0b1 — Mon, 10 Aug 2015 09:35 GMT
  • Disposition: Duplicate or Merged — DDS-WEB 1.0
  • Disposition Summary:

    Issue duplicated DDSWEB-14

    Mark as duplicate
  • Updated: Tue, 22 Dec 2015 15:08 GMT

Missing HTTP return code for DDS_ERROR

  • Key: DDSWEB-17
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Page 63 – (section 8.3.2) the ReturnCode for the DDS_ERROR is not specified. A suitable value could be 500 “Internal Server Error. (same we do for GENERIC_SERVER_ERROR)
  • Reported: DDS-WEB 1.0b1 — Mon, 10 Aug 2015 09:26 GMT
  • Disposition: Duplicate or Merged — DDS-WEB 1.0
  • Disposition Summary:

    Duplicates DDSWEB-9

    This entry is duplicated
  • Updated: Tue, 22 Dec 2015 15:08 GMT

Incomplete specification of the GET operation on the DataReader (Section 7.4.8.1)

  • Key: DDSWEB-29
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.4.8.1 describes the operation “get” on a DataReader and describes the behavior when the sampleSelector is a pure “FilterExpression” or a pure “MetadataExpression” however the SampleSelector can be an expression that combines both a FilterExpression and a MetadataExpression and the behavior on that situation is not specified.

    In addition on that section Case 3. It says:
    “Case 3: If the sampleSelector is a FilterExpression, then the operation uses the MetadataExpression …”
    where it really should say:
    “Case 3: If the sampleSelector is a MetadataExpression, then the operation uses the MetadataExpression …”

    In addition the MetadataExpression can include an expression on the InstanceHandle. This case is also not described.
  • Reported: DDS-WEB 1.0b1 — Sat, 15 Aug 2015 02:35 GMT
  • Disposition: Resolved — DDS-WEB 1.0
  • Disposition Summary:

    *Extend description of the GET operation to capture all the cases where there is both a FilterExpression and a MetadataExpression *


    Edit the description in section 7.4.8.1 per the instructions below.

    Change “FilterExpression or MetadataExpression” to “FilterExpression, MetadataExpression, or both” in the sentence below:
    It parses the sampleSelector to determine if it is a DDS FilterExpression or MetadataExpression, MetadataExpression, or both. If there is a parse error, it returns the INVALID_INPUT error.


    Change “three” to “four” and “or it contains a MetadataExpression.” to “a MetadataExpression, or both” in the sentence below:
    There are fourthree possible cases depending on whether the sampleSelector is empty, it contains a FilterExpression, or it contains a MetadataExpression. a MetadataExpression, or both.


    Replace Case 3 with the text below:
    Case 3: If the sampleSelector is a MetadataExpression there are two situations:

    3.1 If the MetadataExpression does not contain an InstanceHandleExpr, then the operation uses the MetadataExpression to deduce the desired sample_state, view_state, and instance_state. These states are used as parameters to calling read and/or take to obtain samples that match the desired states. Other than this the logic is the same as in Case 1.

    3.2 If the MetadataExpression contains the InstanceHandleExpr, then the InstanceHandleExpr is analyzed to deduce the desired InstanceHandle objects. The rest of the MetadataExpression is analyzed as described in case 3.1 to also derive the desired sample/view/instance states. These parameters are used in multiple calls to read_instance or take_instance passing each of the desired InstanceHandle objects and the desired sample/view/instance states. Other than this the logic is the same as in Case 1.


    Add Case 4 as written below:
    Case 4: If the sampleSelector contains both a FilterExpression and a MetadataExpression then there are two situations:

    4.1 If MetadataExpression does not contain an InstanceHandleExpr, then the operation uses the MetadataExpression to deduce the desired sample/state/view states. There are two possibilities:
    4.1.1 If the logical operation between the MetadataExpression and the FilterExpression is AND, then the operation constructs a QueryCondition using the FilterExpression from the sampleSelector and the desired sample/state/view states and proceeds as in Case 2.
    4.1.2 If the logical operation between the MetadataExpression and the FilterExpression is OR, then the operation constructs a QueryCondition using the FilterExpression from the sampleSelector and leaving the states as "any". In addition it also creates a ReadCondition using the desired sample/state/view states. The operation uses the two conditions separately to call read_w_condition (or take_w_condition) separately using the ReadCondition and QueryCondition and then join the results. The management of the minSamples and maxWait parameters is the same as per Case 1.

    4.2 If the MetadataExpression contains the InstanceHandleExpr, then the InstanceHandleExpr is analyzed to deduce the desired InstanceHandle objects.
    4.2.1 If the logical operation between the MetadataExpression and the FilterExpression is AND the operation constructs a QueryCondition using the FilterExpression and the desired sample/state/view states similar to 4.1.1. The operation then calls read_instance_w_condition (or take_instance_w_condition) iterating over each of the instances. The results are combined. The management of the minSamples and maxWait parameters is the same as per Case 1.
    4.2.2 If the logical operation between the MetadataExpression and the FilterExpression is OR, then the operation constructs a QueryCondition and the ReadCondition the same way as in 4.1.2. In addition the operation analyzes the InstanceHandleExpr to deduce the desired instances. Finally the operation calls read_instance_w_condition (or read_instance_w_condition) on each of the instances of interest passing the ReadCondition and also calls read_w_condition (or take_w_condition) passing the QueryCondition. The results are combined. The management of minSamples and maxWait parameters is the same as per Case 1.
  • Updated: Tue, 22 Dec 2015 15:08 GMT

JSON Missing

  • Key: DDSWEB-3
  • Legacy Issue Number: 19246
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Pratically nobody uses XML in combination with REST today, yet the mars/13-05-21 only provides for this option.

    This is a critical issue that makes the submissing practically useless.

  • Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
  • Disposition: Deferred — DDS-WEB 1.0
  • Disposition Summary:

    AB resolved the issue out of scope for FTF. Requested RFC process is followed instead

    After some discussion the AB resolved that the issue was too big to be resolved by the FTF and should be solved via RFC instead.

    AB stated the RFC process could be very short and narrow. Essentially focusing it on addressing this one issue. Henceforth the previous resolution s cancelled an this issue is left open to be closed by a future RFC.
  • Updated: Tue, 22 Dec 2015 15:08 GMT
  • Attachments:

The file dds-xtypes_type_definition.xsd should not define a targetNamespace

  • Key: DDSWEB11-2
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This is the so called "Chameleon" Schema and it is best for XSDs that define "building blocks of XSD types" which may be then imported/included (included) by other XSDs.

    See http://www.xfront.com/ZeroOneOrManyNamespaces.html

    The issue is this. If a XSD is imported into another one that has a different target namespaces it will cause some "usability problems" in the resulting XML documents. This is only an issue when the XSD is imported in order to be a building block of the resulting XSD and is not natural for the end user to have to understand the original XSDs as separate conceptual units.

    For example if we wanted to create a "dds.xsd" that used a target namespace such as http://www.omg.org/dds/ and this imports XSDs like XTYPES with target namespace http://www.omg.org/xtypes/ and dds4ccm with target namespece (http://www.omg.org/dds4ccm). Note these are not the actual namespaces in those documents. I am selecting this to simplify the description.

    Then each time an element from a different namespace it would need to explicitly add the attribute xmlns to the element. This would happen for both for the included DDS_QosProfiles.xsd (it uses the namespace http://www.omg.org/dds4ccm) and for dds-xtypes_type_definition.xsd (it uses the namespace http://www.omg.org/xtypes/) the resulting references to elements in that XSD would need to specify the namespace using the "xmlns" attribute as in:
    <publisher name="ShapePublisher">
    <publisher_qos>
    <partition xmlns="http://www.omg.org/dds4ccm/">
    <name>
    <element>A</element>
    </name>
    </partition>
    <publisher_qos>
    </publisher>

    This is cumbersome and hard to get right for the user. Also many XML editors do not provide assistance with it. The best solution would have been for the referenced standards (DD4CCM and XTYPES) to define their XSD schemas without a targetNamespace. This would have allowed the namespace to be defined in the XSD that includes them.

    This is a common approach known as using “Chameleon Schemas”. These specifications could also preserve the use of their namespace by putting the namespace in a separate XSD that “includes” the Chameleon Schema. To address this an issue should be filed against those specifications to change their schemas into Chameleon schemas.

    There is no loss of generality as it is always possible to define another XSD that simply includes the Chameleon one and adds the namespace.
  • Reported: DDS-WEB 1.0b1 — Sat, 19 Sep 2015 06:07 GMT
  • Updated: Thu, 8 Oct 2015 14:21 GMT

JSON Missing

  • Key: DDSWEB11-1
  • Legacy Issue Number: 19246
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Pratically nobody uses XML in combination with REST today, yet the mars/13-05-21 only provides for this option.

    This is a critical issue that makes the submissing practically useless.

  • Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:21 GMT
  • Attachments:

missing space "eachother"

  • Key: DDSIRTP2-60
  • Legacy Issue Number: 19818
  • Status: open  
  • Source: Anonymous
  • Summary:

    There is a missing space in paragraph 5 of "eachother" should be "each other"

  • Reported: DDSI-RTPS 2.0b1 — Wed, 22 Jul 2015 04:00 GMT
  • Updated: Wed, 22 Jul 2015 16:01 GMT

Semantics instance liveliness and ownership unclear

  • Key: DDS15-49
  • Legacy Issue Number: 10808
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    From the OMG DDS specification the semantic of the liveliness of a reader instance is not clear, when it is exclusively owned by a writer. The LivelinessChangedStatus of the reader indicates how many active and inactive writers communicate with the reader. In case of exclusive ownership it is unclear whether only the reader sees the strongest writer as an active writer, or when it must see all available writers, since the reader will only receive samples from the strongest writer.

    Solution:
    Do we need to clarify this?
  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Get entity enabled state

  • Key: DDS15-44
  • Legacy Issue Number: 10813
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    It should be possible to obtain the "enabled" state of an Entity

    Solution:
    We propose to add a boolean operation to the Entity called something like is_enabled().
  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

All IDL should use local interfaces

  • Key: DDS15-29
  • Legacy Issue Number: 15945
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS uses IDL and defines its interface as regular interfaces, but these should all be local interfaces

  • Reported: DDS 1.4 — Thu, 13 Jan 2011 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Inconsistent lookup semantics

  • Key: DDS15-47
  • Legacy Issue Number: 10810
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    There is inconsistency in the spec: on page 2-24 there is a list of operations that is allowed when the DomainParticipant is in the disabled state. This list does not include any lookup operations. However, on page 2-14 there is also a list of operations which may be invoked when Entity has not yet been enabled, and here the 'lookup' operations are mentioned. So the questions are whether the DomainParticipant should be allowed to perform "find_topic" and "lookup_topicdescription" operations when it is in disabled state.

    Solution:
    Our proposal is that find_topic should not be allowed in this case, but lookup_topicdescription should be allowed. Also all delete operations including the delete_contained_entities should be allowed
  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Missing TypeSupport operations

  • Key: DDS15-48
  • Legacy Issue Number: 10809
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    In IDL, the operations on the TypeSupport interface are commented out: all operations are defined in its specialized sub-classes. That is strange, since all TypeSupport operations have a signature that is completely independent of this specific type.

    Solution:
    We propose to promote all these operations to the TypeSupport class itself, and thus to uncomment these operations in the TypeSupport interface.
  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Extend Topic with method to retrieve key fields

  • Key: DDS15-11
  • Legacy Issue Number: 14829
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For template meta programming as we are doing for the dds4ccm spec, it is needed to know at runtime time of the user program whether a topic has a key or not, because behaviour is dependent on that. we propose to add methods to the Topic to get its key fields

  • Reported: DDS 1.2 — Wed, 2 Dec 2009 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Attributes_on_the_data

  • Key: DDS11-10
  • Legacy Issue Number: 6733
  • Status: open  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Attributes_on_the_data Issue [Boeing SOSCOE] ? The DDS API forces the data to be written to be encapsulated into a single IDL structure. Moreover IDL-generated structures do not support pointers to other structures. ? These limitations are constraining the kinds of things that a layer such as SOSCOE can do. For example, it would be desirable to allow the DDS DataWriter to filter or perform other actions on information that is not “part of the data”. Not “being part of the data” means the attributes: • Are propagated along with the message (1-to-1 relationship) to the reader. • May be used for filtering, or intercepted by layers above DDS (e.g. SOSCOE). • Do not get passed to the read or take calls ? The problem is that since the DataWriter takes a single “compacted” data-structure, any additional information, whether introduced by the user-app or the SOSCOE layer must be somehow copied into the data and thus force the introduction of new data-types. ? In other words it would be desirable for DDS so provide some hook that would allow a user or a layer such as SOSCOE to add additional information to the “user-level” data that is then used by DDS to filter on. The filtering would then occur on the additional information provided by the SOSCOE layer and not by the application that is writing the data. There are three main ways to use this • The additional SOSCOE information, would be supplied in conjunction with every write operation. So the filtering is evaluated on every write. This may be too inefficient in some cases and therefore there should also be a way to turn off the filtering also (e.g. by providing an empty set of attributes). • The additional SOSCOE information is provided by some other means than a parameter to the write (e.g. a set_attributes(InstanceHandle_t, Attributes)) call on the DataWriter) so that the filtering does not examine every data-sample for filtering; rather it is performed on information that changes at much slower rate. For example, there is the concept of a “geographical region” in which the information lives; the filtering applies to getting information that is within our region of interest, and re-evaluation of the filter only occurs each time the region changes which is much rarer than the actual data changing. • The attributes could be attached to the instance by means of a separate API. These additional attributes would then be passed to the serialization as well as the filter operations. The deserialization would also need to handle them. This approach would meet SOSCOE’s requirements and has the advantage of not forcing filters to be re-evaluated each write; they would only be evaluated if the attributes change. Proposal [Boeing SOSCOE] ? Add a set of attributes (name-value pairs) (ref Issue#2035) that are provided separately from the data and can then be used to do the filtering. ? This allows reusing the same data with different attributes and thus filter it differently. ? Name-value pair representation would also potentially allow sending a partial list of attributes ? Filtering can be done on this name-attribute pairs. Similar to ContentFilteredTopic but the filtering is done on the attributes, not the data. Note that the ContentFilteredTopic may not know enough about the data. The data may be marshaled and encrypted. The brokering of the data may be done by nodes that do not know how to unmarshal/decrypt the data.

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Make all arguments inout

  • Key: DDS4CCM11-5
  • Legacy Issue Number: 15287
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In order to have the same memory management for the single data and datum operations, we propose to make all out arguments inout. This impacts:
    Reader::read_one_last, info to inout
    Getter::get_one, all arguments to inout

  • Reported: DDS4CCM 1.0 — Thu, 10 Jun 2010 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

DDS_TopicBase connector lacks type_name

  • Key: DDS4CCM11-7
  • Legacy Issue Number: 18499
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    When registering a topic to DDS we need to use an unique combination of domain id, topic name, and typename. Recent discussions revealed that there is no standard for a default typename, but also there could be reasons why an user don't want to use the default type_name. We propose to add to the DDS_TopicBase connector a type_name attribute, which when set, will be used as type_name, if not set, the DDS vendor default type_name will be used for the topic type
  • Reported: DDS4CCM 1.0 — Sun, 24 Feb 2013 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Name patterns should support underscores and scoping

  • Key: DDS4CCM11-1
  • Legacy Issue Number: 17399
  • Status: open  
  • Source: Northrop Grumman ( Trent Nadeau)
  • Summary:

    The name patterns in the normative XML schema in Annex C do not support underscores. For detailed or lengthy profile names (especially including internal acronyms), using underscores significantly improves readability.

    In addition, the elementName type is used both for the name and base_name attributes of the qosProfile type; however, the pattern for the elementName type does not support scoping, which is needed for inheritance between profiles in different libraries.

    In order to address these, I propose that the elementName and topicNameFilter patterns be changed from:

    "([a-zA-Z0-9 ])+"

    to:

    "^((:?([a-zA-Z0-9_])(:[a-zA-Z0-9_]))*)$"

    The latter is the currently commented-out pattern in the schema with the addition of the underscore.

  • Reported: DDS4CCM 1.0 — Wed, 30 May 2012 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Ref-232 Allow_reader_to_access_partition_of_writer

  • Key: DDS11-2
  • Legacy Issue Number: 6860
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Some applications would like to see originating partition as part of
    sample info. Thisis specially important if the application subscribes
    with wildcards to any partition

    There is a concern, however, with putting the information in the
    SampleInfo as it is a cost that has to be paid every time a sample is
    returned.

    Perhaps the SampleInfo is just an interface so that there are
    operations to access stuff and the cost can be performed as needed.

    **PROPOSAL**

    No concrete proposal as it would be hard to represent in IDL but it
    would be nice if such API was offered.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

ref-1053 Missing is_composition

  • Key: DDS11-3
  • Legacy Issue Number: 7065
  • Status: open  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The is_composition operation is described in the PIM, but is not in the IDL.
    It concerns the valuettype RefRelation, ListRelatrion, IntMapRelation, and
    StrMapRelation.

        • Proposal
          add the following operation
          boolean is_composition(); on those valuetypes
  • Reported: DDS 1.0 — Thu, 4 Mar 2004 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Make topic_name changeable

  • Key: DDS4CCM11-4
  • Legacy Issue Number: 16603
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In some systems they are receiving the topic_name after startup, at some moment they just get it and want to set it to a new value. We propose to remove topic_name, there seems to be no technical or structural reason not to allow the user to change the topic_name after the connector fragment has been initialized

  • Reported: DDS4CCM 1.1 — Fri, 14 Oct 2011 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

The model should us platform-independent data types

  • Key: DDC4RTC_-4
  • Legacy Issue Number: 17459
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Here are three issues that I found in the XMI file mars/12-06-12:

    The model should not use Java-specific data types EAJava_boolean etc: instead it should use platform-independent data types
  • Reported: DDC4RTC 1.0b1 — Thu, 21 Jun 2012 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Section 8.4.4 talks about threading, but this section is really under specified

  • Key: DDS4CCM11-9
  • Legacy Issue Number: 14060
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Section 8.4.4 talks about threading, but this section is really under specified. It should be much clearer how threading works and what guarantees are given.

  • Reported: DDS4CCM 1.0b1 — Wed, 8 Jul 2009 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Detection_of_dynamic_qos_failure Issue

  • Key: DDS11-4
  • Legacy Issue Number: 6737
  • Status: open  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2080 Detection_of_dynamic_qos_failure Issue [Boeing SOSCOE] ? DDS does not provide the complete means for a user of the DDS API to detect “dynamic” failure of QoS and other “configuration” changes that may be important. For example: • LATENCY_BUDGET (on the receiver side). • Messages dropped due to lack of resources (on the receiver side) • Messages lost when QoS is RELIABLE KEEP_ALL (related to Issue# 2070) • Changes on the ownership of data-instances. • Addition of a remote DataReader that matches a local DataWriter. Removal of a remote DataReader that matches a local DataWriter. • Addition of a remote DataWriter to a local DataReader; removal of a remote DataWriter to a local DataReader. • Changes in “liveliness” of a remote DataReader of a local DataWriter. The symmetric situation, that is changes in liveliness of a remote DataWriter to a local DataReader does have a listener in the DataReader. Proposal [Boeing SOSCOE] ? Add the missing operations to the proper listeners

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Let the user be able to instantiate one dds connector

  • Key: DDS4CCM11-8
  • Legacy Issue Number: 15238
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Currently the DDS4CCM specification puts within the Typed module the extended ports, but also the dds connectors. The drawback of this approach is that when the user instantiates this templated module he gets both connectors, even when he is only interested in using one. We propose to move the DDS_State and DDS_Event to their own typed module so that the end user can instantiate just one of these connectors. This also makes it easier for a code generator to just generate the implementation for a specific connector, at this moment there is nothing in idl which can be used to determine whether the end user wants to use DDS_Event and/or DDS_State

  • Reported: DDS4CCM 1.0 — Mon, 3 May 2010 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Extension_to_the_query_language

  • Key: DDS11-12
  • Legacy Issue Number: 6732
  • Status: open  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2035 Extension_to_the_query_language Issue [Boeing SOSCOE] ? SOSCOE has a need to allow function expressions to be added to the query language ? SOSCOE has created a provider property class that allows applications to have attributes with typed values; it becomes a triplet (name, type, value). Currently the “type” only supports simple types, but the intent is to extend it to well-known structured types. Proposal [Boeing] ? Extend the query language to allow user defined function expressions ? Extend the query language to allow user defined structured types

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Ref-167 Malloc_required_for_get_default_qos

  • Key: DDS11-1
  • Legacy Issue Number: 6852
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The problem is with the QoS that have dynamically-sized things inside,
    namely PARTITION (string) and USER_DATA (sequence). These fields force
    a "malloc" each time the structure is copied out (even if a
    pre-allocated structure is passed in)

    Moreover copies may also result in memory allocation and frees. Can't
    this be avoided?

    In the C mapping copies would then require the use of an explicit
    function rather than direct assignment

    One possibility would be to refactor the USER_DATA and PARTITION into
    a more generic NAME-value pair infrastructure. Allow these to be set
    with a different API (i.e. not by means of QoS, but as direct
    operation on the Entity). These avoids all the above problems

    **PROPOSAL**

    No concrete proposal yet
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Additional_qos_THROUGHPUT Issue

  • Key: DDS11-5
  • Legacy Issue Number: 6741
  • Status: open  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2110 Additional_qos_THROUGHPUT Issue [Boeing SOSCOE] ? The DDS specification has no provision to control the amount of bandwidth that the different entities can consume. ? Ideally the user of the DDS API could indicate bandwidth limits and also reserve bandwidth in a way that could then be mapped by the service into the underlying transport facilities, for the cases where those facilities are there. ? At a minimum the user would like to indicate bandwidth limits in bytes per second. Although low level, this kind of unit would make more sense than something like messages-per-second because each data-type, or maybe even each particular write to an instance may be of a different size. ? There is also the case where the communication infrastructure needs to communicate to the application how much bandwidth it can expect to have. This can also change dynamically based on current network conditions. The application can then take advantage of this knowledge to configure itself so that only the more important messages are sent. ? All we need is something that can be passed to the API; the middleware does not need to do anything with it. ? Not clear how it can be implemented or how it interacts with things. But there is a requirement that there is a way to specify this QoS. This comes from streaming type applications. They want to be able to reserve some bandwidth.

    Proposal [Boeing SOSCOE] ? No concrete action is proposed at this time. The precise definition is fairly involved. However there is a general desire to be able to allocate and control bandwidth utilization so it would be nice if approaches would be explored. Comment [RTI] ? The fundamental problem is how to map this to the DDS model. The DDS spec. does not have a model for the Transport or expose to the user which entities (writers / readers) are associated with each transport. It is in fact possible that a single write to an Entity may result on multiple messages each over a different transport, its all hidden from the application. ? So the first thing would be to introduce some model on how the entities interact with the transport. Where are the TranportPlugins installed (globally, per participant, per Connector), what are the transport “resources” (e.g. in RTI’s TPI the SendResource, and ReceiveResource) and how they map to the DDS entities. ? Introducing a QoS that limits the bandwidth used by each DataWriter would be straightforward. Similarly for a QoS that attempts to reserve certain amount of bandwidth for a particular DataWriter. The DDS implementation who knows what transports it is associated with would then map it to the appropriate transport calls. The problem is that it would apply indiscriminately to all transports. ? For the case of EndpointConnectors if transports were explicitly associated with the connector, then it may also be possible to set this kind of QoS. It would then apply to all the DataReaders and DataWriters in the EndpointConnector. ? Regarding the listeners, presumably the callbacks would refer to the bandwidth changes on each transport resource. So for the user of the DDS API to make sense of this they would need that mode/map to DDS entities.

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

DDS ISSUE# 50] Multiple observers sharing a datareader

  • Key: DDS11-8
  • Legacy Issue Number: 6850
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-166 Allow_multiple_observers_on_a_datareader

    Currently there can only be one "observer" on each DataReader. In
    other words, it is not possible to have some independent application
    observe the data that a DataReader gets without at the same time
    affecting the sample-state and this the behavior of other
    data-readers.

    It is often the case that debugging tool, an interceptor or some other
    utility would like to access the data available on the DataReader
    without making its presence noted and thus changing the behavior of
    other readers. This is particularly relevant for the built-in topics.

    **PROPOSAL**

    Add an operation: DataReader:: create_view that returns a
    DataReader. This affects 2.2.2.4.1 and the IDL in 2.2.3

    This DataReader is a view on the same DataReader so it has the same
    QoS and listeners.

    The application can use the original DataReader or a view to perform
    any operations allowed on a DataReader.

    A change of QoS or listener in one view or on the main object affects
    the main object and all views.

    Read and Take operations act independently on each view. The
    application must take the data from all views before it can be removed
    from the infrastructure and the resources reclaimed.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Filtered_out_lifecycle_state Issue

  • Key: DDS11-11
  • Legacy Issue Number: 6734
  • Status: open  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2050 Filtered_out_lifecycle_state Issue [Boeing SOSCOE] ? Sometimes the receiving application needs to know that data is being filtered-out. In some use cases this situation is different from the case where data is not being produced. ? A related question is whether the presence of filters (content-based, time-based) can be the cause of a DataReader to miss a requested deadline. It depends whether the deadline is interpreted to mean that data is produced at that rate, or else that data that passes the filter must be produced at that rate. ? SOSCOE thinks that the filter should not cause a deadline to be missed, rather the reader should receive explicit notification that the data was filtered-out. At least that data is starting to be filtered-out, not necessarily each time something is filtered out. ? In any case filters should not cause loss of liveliness. ? A typical use-case may be that a display-device is showing the tanks in a certain area (the one relevant to that particular display). The display has a filter to indicate that region of interest. When the tank leaves the region of interest, the display wants to know that. That way it can stop displaying it; however the display does not want to internally discard all the information about the tank immediately in case the tank appears again. The display needs to therefore know that the data for that tank instance is being filtered out. This situation is different from missing a deadline which may indicate that the data is not being generated as intended. ? Note that if a filter is present and a deadline is set, it would be necessary for the implementation to send some information to the reader so that the deadline would not fire. However, bandwidth is very important in some cases, so sending any information when the data is being filtered may be too expensive. ? One option may be to have the application change the deadline to a larger value when it finds out that the data is being filtered. Another possibility is to specify two values of the deadline, one when the data is not filtered and the other when the data is being filtered (the second one could be specified along with the filter). In this case the information that the middleware implementation sends to avoid missing the deadline could be sent at the lower rate. ? This facility may be hard to implement for all cases. For example in the case where the filter is applied at the source and the reliability QoS is BEST_EFFORTS it is not guaranteed that said notification would be received by the reader. If this is indeed the case then we would not require the filtered-out notification to be guaranteed if the reliability setting is BEST_EFFORTS. Proposal [Boeing SOSCOE] ? Add FILTERED_OUT lifecycle state to allow user to know that data is being filtered out. The usage of this state should be an option for the user. ? If the option is on, the state is set on a sample when the sample was filtered out and the previous sample was not filtered out. Only one notification of filtering is required, not one per sample being filtered. ? Optionally introduce a deadline_while_filtered QoS on the ContentFilteredTopic which would transition the deadline to a larger value when the data is being filtered.

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

The XMI includes the UML state machine metamodel

  • Key: DDC4RTC_-2
  • Legacy Issue Number: 17457
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The XMI includes the UML state machine metamodel
  • Reported: DDC4RTC 1.0b1 — Thu, 21 Jun 2012 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

All EA – specific content should be removed

  • Key: DDC4RTC_-3
  • Legacy Issue Number: 17458
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Here are three issues that I found in the XMI file mars/12-06-12:

    1. All EA – specific content should be removed
  • Reported: DDC4RTC 1.0b1 — Thu, 21 Jun 2012 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

StateListenerControl:: is_filter_interpreted should be documented as optional

  • Key: DDS4CCM11-3
  • Legacy Issue Number: 15313
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    is_filter_interpreted has to be documented as optional, not just the filtering of out.

    This is because there is no required feature in the DDS core or part of the DDS DCPS specification which provides the INSTANCE_FILTERED_IN or INSTANCE_FILTERED_OUT status. Near as I can tell, this functionality comes as part of the DLRL layer "Selection_Listener" object (8.1.6.3.13).

  • Reported: DDS4CCM 1.0 — Tue, 29 Jun 2010 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

It is not clear how much of the model is normative

  • Key: DDC4RTC_-5
  • Legacy Issue Number: 17460
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Here are three issues that I found in the XMI file mars/12-06-12:

    It is not clear how much of the model is normative. The state diagram that corresponds to figure 8.9 is clearly not normative. If some of these diagrams are normative, I believe that there should be two separate XMI files, one for normative content and the other for informative content
  • Reported: DDC4RTC 1.0b1 — Thu, 21 Jun 2012 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

The type of property RTComponentPortDescription

  • Key: DDC4RTC_-1
  • Legacy Issue Number: 17456
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The type of property RTComponentPortDescription:: properties is not Property from the external specification but the built-in EAJava_Property
  • Reported: DDC4RTC 1.0b1 — Thu, 21 Jun 2012 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Layout issue test

  • Key: DDS4CCM11-6
  • Legacy Issue Number: 15286
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    See page 35, line 35,

    read_one_last returns the last sample of a given instanceThe targeted

    Missing dot after instance

  • Reported: DDS4CCM 1.0 — Thu, 10 Jun 2010 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

DDS ISSUE# 51] Avoid use of dynamic memory for manipulating QoS

  • Key: DDS11-9
  • Legacy Issue Number: 6851
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-122 Make_incompatible_qos_fixed_size

    The structures RequestedIncompatibleQosStatus and
    RequestedIncompatibleQosStatus each contain a sequence listing each
    QoS and the corresponding count.

    However given that we have explicitly enumerated all the QoS policies
    it would be far simpler to replace this hard-to-use sequence with the
    actual counts for each QoS

    One possibility would be to Replace this "policies" sequence with
    explicit count for each QoS. Anotehr possibility would be to use the
    mask. To state which QoS are incompatible but loose the count.

    **PROPOSAL**

    No concrete proposal yet
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

attributes as part of porttype do appear on port and mirrorport

  • Key: DDS4CCM11-2
  • Legacy Issue Number: 15282
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This version of DDS4CCM adds the functionality to specify attributes as part of a porttype. This porttype can than be used by a component or connector as port or as mirrorport. The problem we see is that the attribute appears on the component/connector that uses the porttype as port or mirrorport. To our opinion the grammer should be more specific where the attribute appear, we propose to add the attribute by default to the component that uses the porttype as port, when the attribute has to appear on the component that uses the port as mirrorport we propose to define the attribute as:
    mirror attribute my_attribute;

    In case of DDS4CCM we see that the dds4ccm DDS_State connector gets 4 attributes which is what we want, but any user component using the porttype also gets a filter attribute

  • Reported: DDS4CCM 1.0 — Tue, 8 Jun 2010 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Key_separate_from_data Issue

  • Key: DDS11-7
  • Legacy Issue Number: 6742
  • Status: open  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2120 Key_separate_from_data Issue [Boeing SOSCOE] ? Keyed data is important but having the key being part of the data leads to duplication or copying into other types of structures. ? Note that this issue is not too critical. SOSCOE has worked around it by creating a container type that copies the data inside. Proposal [Boeing SOSCOE] ? Split the keys out from the data type. The idea would be to have the write operations take two parameters, one for the data and the other for the key. The same would apply to the reader side. Comment [RTI] ? Maybe this can already be accommodated with a small extension of the DDS API. If we had a DataReader::register_type that took only the key, then we could say that provided that the InstanceHandle_t is passed to the write() operation it is not required for the data to contain the key. ? This issue is exacerbated by the fact that IDL does not allow structures to contain pointers to other structures. If this limitation was not present, then it would reasonable for the user of the DDS API to define a wrapper data-type that would just contain pointers to the Key and to the data-blub. Note that there are other languages’ such as ITU’s ODL (object description language) that are extension to OMG’s IDL and do allow this pointer syntax. However, for now we would have to rely on the individual vendors to implement this feature which would be technically quite simple. ? Separating the key from the data would require DDS that the definition of a Topic would involve not just the specification of the data-type, but also the key-type. Also the implied IDL that represents the type-specific data-writers and data-readers would need to now be generated for each combination of data-type and key-type. There is no standard way to indicate in the IDL file what those combinations are so it would not be so simple for the code-generator to determine this. These problems do not arise if we followed the first approach to allow pointers within the structures. Comment [Boeing SOSCOE] ? The register instance_by_key, would also help this particular scenario.

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

DDS ISSUE# 47] Allow application to not specify a timstamp

  • Key: DDS11-6
  • Legacy Issue Number: 6847
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-157 Ability_of_the_application_to_not_specify_a_timestamp

    Getting a timestamp can be an expensive operation. It is desirable
    that the application can configure a datawriter such that it does not
    get/send the timestamp

    The option of letting the application not set a timestamp by means of
    calling write_w_timestamp() and passing TIME_INVALID is not good
    because certain QoS such as DESTINATION_ORDER BY_SOURCE_TIMESTAMP
    require this. Also it would be hard to manage if the application could
    sometimes specify a timestamp and sometimes not for the same
    DataWriter/instance.

    **PROPOSAL**

    Add an "receptionTimestamp" field to the SampleInfo.

    Make the DESTINATION_ORDER also an offered QoS on the DataWriter. For
    compatibility BY_SOURCE_TIMESTAMP>BY_DESTINATION_TIMESTAMP, that is if
    you offer SOURCE_TIMESTAMP you can accommodate both kinds or readers.

    Add the QoS WRITER_TIMESTAMP and READER_TIMESTAMP.

    The SOURCE_TIMESTAMP has a kind that can be NOT_PROVIDED and PROVIDED.
    And is set on both the DataWriter and the DataReader and also on
    Topic. It has request/offered semantics where PROVIDED > NOT_PROVIDED.

    The RECEPTION_TIMESTAMP is only set in the DataReader or Topic and has
    a kind that can be NOT_PROVIDED and PROVIDED.

    The SOURCE _TIMESTAMP indicates that data must be timestamped when
    sent.

    The RECEPTION_TIMESTAMP indicates that data must be timestamped when
    received.

    DESTINATION_ORDER BY_SOURCE_TIMESTAMP requires that the SOURCE
    _TIMESTAMP is set to PROVIDED otherwise we will flag an INCOMPATIBLE
    QoS.

    If SOURCE _TIMESTAMP.kind== NOT_PROVIDED, then the DataWriter ::write
    operation does not put any timestamp and the xxx_w_timestamp operation
    silently ignores the timestamp and behaves normally. Upon reception
    the sourceTimestamp field in the SampleInfo will be TIME_INVALID

    If SOURCE _TIMESTAMP.kind== PROVIDED, then the write operation will
    automatically get the timestamp by some means (i.e. the middleware
    will do it), the xxx_w_timestamp will allow the application to provide
    the timestamp. In either case the data will be sent with a timestamp
    and the SampleInfo.sourceTimestamp field will never be TIME_INVALID

    It is allowed for RECEPTION_TIMESTAMP to be NOT_PROVIDED and the the
    DESTINATION_ORDER to be BY_RECEPTION_TIMESTAMP because what matter is
    the relative order and that does not require to get a true
    timestamp. If this is too confusing we could rename
    BY_RECEPTION_TIMESTAMP to be BY_RECEPTION_ORDER

    If RECEPTION_TIMESTAMP is NOT_PROVIDED then the
    SampleInfo.receptionTimestamp will always be TIME_INVALID. Otherwise
    it will never be TIME_INVALID By default the source-timestamp is
    provided.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

ref-1003: Section 3.1.3.2 (editorial)

  • Key: DDS-178
  • Legacy Issue Number: 6707
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The last paragraph is a note, but is not is the note style
    Proposal [THALES]
    Correct the footprint
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Wed, 11 Mar 2015 01:53 GMT

ref-1001: section 3.1.1 (editorial

  • Key: DDS-176
  • Legacy Issue Number: 6705
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In the final editing process, "native-language constructs" has become "native-language data-accessing constructs". However, the mentioned constructs are not only related to accessing the data (e.g., creation of an object)
    Proposal [THALES]
    Remove the extra "data-accessing"
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Wed, 11 Mar 2015 01:53 GMT

Missing operations to allow the navigation described in the PIM

  • Key: DDS-175
  • Legacy Issue Number: 6687
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-200 Figure_2_10_arrow_readcondition
    The PIM indicates by means of the arrow pointing from ReadCondition to DataReader that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute).
    Proposal: Fix by adding get_datareader() operation to the ReadCondition. This operation should take no arguments and return a DataReader
    Ref-201 Figure_2_5_arrow_statuscondition
    The PIM indicates by means of the arrow pointing from StatusCondition to Entity that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute).
    Proposal: Fix by adding get_entity() to StatusCondition. This operation should take no arguments and return a Entity.
    Ref-202 Figure_2_10_arrow_topicdescription
    The PIM indicates by means of the arrow pointing from DataReader to TopicDescription that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute).
    Proposal: Fix by adding get_topicdescription to DataReader. This operation should take no arguments and return a Topicdescription.
    Ref-203 Figure_2_9_arrow_topic
    The PIM indicates by means of the arrow pointing from DataWriter to Topic that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute).
    Proposal: Fix by adding get_topic() to DataWriter. This operation should take no arguments and return a Topic.
    Ref-227 Missing_navigation_operations
    The PIM indicates by means of the arrow pointing from DataReader to Subscriber, from DataWriter to Publisher, and from DomainEntity to Participant that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute)
    Proposal: Fix by adding DataReader::get_subscriber (no parameters, returns a Subscriber), DataWriter::get_publisher (no parameters, returns a Publisher), and the operations Publisher:: get_participant(), Subscriber::get_participant, and TopicDescription::get_participant() (these 3 operations should take no arguments and return a Participant). It is not needed to add get_participant to DataReader or DataWriter because it is possible to navigate to the subscriber/publisher and from there to the participant.
  • Reported: DDS 1.0b1 — Mon, 8 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Wed, 11 Mar 2015 01:53 GMT

ref-1002: section 3.1.2.1 (editorial

  • Key: DDS-177
  • Legacy Issue Number: 6706
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Starting at "A DLRL object has at least one shared attribute..." (page 3-3), the whole section has been messed up during the final editing process; therefore, the content is no more understandable.
    Proposal [THALES]
    Restore the wording and footprint as it was in version V67 (the last Word one)
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Wed, 11 Mar 2015 01:53 GMT

Bad references

  • Key: DDS-174
  • Legacy Issue Number: 6686
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    DDS ISSUE# 2 Bad references
    Ref-67 Bad_reference_to_SubscriberFactory
    Sections 2.1.5, 2.1.6.2.1, and 2.1.6.2.2. Mention a SubscriberFactory. There is no SubscriberFactory. They should mention DomainParticipant. instead
    Proposal: Replace SubscriberFactory with DomainParticipant in said sections.
    Ref-71 Bad_reference_to_CORBA_PIM
    Section 2.2.2. Says "The CORBA PIM is provided by means of the IDL that defines the interface an application can use to interact with the Service."
    This should be: "The CORBA PSM ..."
    Proposal: Replace as stated above
    Ref-80 Bad_reference_to_appendixA
    On page 2-21, 2-22, 2-28, 2-29, 2-54, 2-59 all the references to appendix A should be references to appendix B
    Proposal: Replace as stated above
  • Reported: DDS 1.0b1 — Mon, 8 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Wed, 11 Mar 2015 01:53 GMT

DDS editorial issues

  • Key: DDS-173
  • Legacy Issue Number: 6685
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-66 Misplacing_of_key_in_builtin_topic_table
    Section 2.1.5. Fields "key" with Topic DCPSPublication and DCPSSubscription are placed one row to high compared to the relating Topic. In other words, DCPSPublication and DCPSSubscription should be placed one row higher.
    The thickness of the lines between the rows might suggest some relation between fields, but is implemented inconsequent.
    Proposal: Correct table as described above.
    Ref-103 Typo_on_section_2.1.2.5.2.8
    3rd paragraph Says "... prior to calling any of the sample-accessing operations, namely: … on the DataWriter"
    Should say "on the DataReader" instead of "on the DataWriter"
    Proposal: Replace "DataWriter" with "DataReader" in said paragraph
    Ref-105 Typo_on_section_2.1.3.11
    Section 2.1.3.11 says "Assuming the STRENGTH policy allows it…"
    Should say "Assuming the OWNERSHIP policy allows it…"
    Proposal: Replace as stated above
    Ref-115 Typo_consistent_use_of_term_publication
    Section 2.1.2.2.1.15 says "The publication to ignore"… The parallel sentence in section 2.1.2.2.1.16 says the "The DataReader to ignore"…
    These two sentences should be consistent
    Proposal: Replace "publication" with DataWriter in 2.1.2.2.1.15
    Ref-143 Typo_on_RELIABILITY_description
    In Section 2.1.3, QoS table. The description of RELIABILITY in the last line it says "and whether a samples can be discarded from it." Should say "samples" instead of "a samples"
    Proposal: Replace as stated above
    Ref-145 Bad_reference_to_DCPSEntity
    Section 2.1.3 Figure 15 Says DCPSEntity instead of Entity in one of the lines
    Proposal: Replace as stated above
    Ref-147 Typo_on_section_2.1.5
    Section 2.1.5 third paragraph says: The last "r" in "get_datareader" is not using italics as it should within the sentence "The built-in DataReader objects can be retrieved by using the operation get_datareader, with the Subscriber and the topic name as parameters."
    Proposal: Make the "r" italic.
    Ref-207 Grammar_errors_on_secs_2.1.2.4_and_2.1.2.5
    2.1.2.4.2.6: 2nd paragraph, 1st line: "one" should be "once" according to 2.1.2.1.1.7 this should be the case.
    2.1.2.5.2.8: 3rd paragraph, 3rd line: "....on any DataWriter" should be "....on any DataReader"
    2.1.2.5.3.8: Point 5, 3rd line: "....that is required that.... " should be "....that it is required that.....""
    Proposal: Fix above 3 typos as stated above
    Ref-221 Typo_on_section_2.1.4.4
    2.1.4.4: First paragraph after the bullets:"... is done after
    ininitial is at ion phase..." should be "... is done after initialization phase..."
    Proposal: Fix as stated above
    Ref-228 Typo_on_2.1.2.2.1.13
    2.1.2.2.1.13 2nd paragraph, 4th line: "filed" should be "field"
    Proposal: Fix as stated above
  • Reported: DDS 1.0b1 — Mon, 8 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Wed, 11 Mar 2015 01:53 GMT

section 8.3.1 Base Connectors

  • Key: DDS4CCM_-105
  • Legacy Issue Number: 15888
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Perry King)
  • Summary:

    Right now (in section 8.3.1 Base Connectors) the DDS_Base connector has an attribute named qos_profile and the only thing said about it is that it contains a File URL or XML string.

    Excerpt from 8.3.1 Base Connectors:
    connector DDS_Base

    { uses ConnectorStatusListener error_listener; attribute DDS:DomainId_t domain_id setraises (NonChangeable); attribute string qos_profile // File URL or XML string setraises (NonChangeable); }

    ;

    However, section 8.4.2.3 QoS Profiles talks about qos_profiles that are actually specified within the xml file.

    So the problems are:

    1. The same name “qos_profile” is used to mean both an attribute referring to a file URL or XML string as well as referring to a subsection within the XML file.

    2. There is no mechanism for the user to reference the qos_profile name that was defined within the xml file (the “subsection within the XML file “) which makes it useless.

    A possible solution would be to:

    1. Change the meaning of the qos_profile attribute to be a reference to the qos_profile defined within the XML file.

    2. Add another optional attribute for specifying the path to the xml file.
  • Reported: DDS4CCM 1.0b2 — Thu, 9 Dec 2010 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 20:38 GMT

Section 8.2.2.1.1: what about making is_lifecycle_checked a regular attribute, so not read only?

  • Key: DDS4CCM_-104
  • Legacy Issue Number: 13962
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    what about making is_lifecycle_checked a regular attribute, so not read only?
  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 20:38 GMT

Not every application limits itself to only 1 representation of a topic

  • Key: DDSXTY11-12
  • Legacy Issue Number: 18305
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Section 7.6.1 states that every component only uses 1 representation of a topic type.
    Some generic services (e.g. durability service or a logger) might discover a topic from another node but will still be able to handle all representations of it, without ever having type specific knowledge hardcoded into them.
  • Reported: DDS-XTypes 1.0 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    Corrected paragraphs:
    Typically, in application code, a topic is associated with a single type (as has always been the case in the [DDS] API) . Therefore, multiple API topics may correspond to (different views of) the same network topic. A given reader or writer endpoint is associated with one of them. See Section 7.6.3, “Local API Extensions”, for definitions of the programming interfaces that support this polymorphism.
    Generic services (e.g., logger, monitor) may discover a topic associated with one or more types. Such services may be able to handle all representations of the types, without ever having type specific knowledge hardcoded into them.
  • Updated: Sat, 7 Mar 2015 04:43 GMT

Semantics of overriding an attribute not clearly specified

  • Key: DDSXTY11-11
  • Legacy Issue Number: 18299
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Is it allowed to have a parent and a child struct share an attribute with the same name?

    • In most OO-languages this is allowed.
    • However, in scenario's like type-refactoring this will cause huge problems.

    We should clearly specify whether or not this is allowed, and when allowed we should clearly describe the consequences.
  • Reported: DDS-XTypes 1.0 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    The paragraph 7.2.2.3.5.1 updated as follows:
    A structure can optionally extend one other structure, its “base_type.” In the event that there is a name or ID collision between a structure and its base type, the definition of the member in the former takes precedence the definition of the derived structure is ill-formed.
  • Updated: Sat, 7 Mar 2015 04:43 GMT

Typo

  • Key: DDSXTY11-10
  • Legacy Issue Number: 18296
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Typo: 4rth paragraph: For the saMe of run-time efficiency -> For the saKe of run-time efficiency.....
  • Reported: DDS-XTypes 1.0 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    Corrected sentence: For the same sake of run-time efficiency …
  • Updated: Sat, 7 Mar 2015 04:43 GMT

Typo in opening sentence of section: Missing noun and verb

  • Key: DDSXTY11-9
  • Legacy Issue Number: 18294
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The opening sentence seems to be missing a noun and a verb. Probably what is meant is:

    System developers frequently require the ability to inject their own output into <code> that <is> produced by a Type Representation compiler.
  • Reported: DDS-XTypes 1.0 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    Corrected sentence: System developers frequently require the ability to inject their own text into the code produced by a Type Representation compiler.
  • Updated: Sat, 7 Mar 2015 04:43 GMT

issue create/addressed?

  • Key: DDS4CCM_-103
  • Legacy Issue Number: 15231
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The version of IDL3+ grammar extensions that I have shows

    <connector_body> ::= "

    {" <connector_export> "}

    "

    Shouldn't that line be

    <connector_body> ::= "

    {" <connector_export>* "}

    "

    ?
  • Reported: DDS4CCM 1.0b1 — Mon, 15 Feb 2010 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    issue withdrawn by submitter
  • Updated: Sat, 7 Mar 2015 00:50 GMT

ConnectorStatusListener::on_unexpected_stat

  • Key: DDS4CCM_-102
  • Legacy Issue Number: 15174
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On the ConnectorStatusListener there is an on_unexpected_status method. What
    is meant with an unexpected status, I don't find the spec clear in this
    area. If this are the statuses we don't handle explicitly, what can the user
    do with it? He gets the entity and the kind, but now the status field
    itself? Is this usefull to add?
  • Reported: DDS4CCM 1.0b1 — Fri, 6 Nov 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 00:50 GMT

InstanceHandleManager, local?

  • Key: DDS4CCM_-101
  • Legacy Issue Number: 15173
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The InstanceHandleManager interface is defined as abstract, but shouldn't
    this one also be defined as local (which means remove abstract, you can't
    have both). By now having abstract, it is technically possible to derive a
    regular (non local) interface from it. This means we have todo more code
    generation as necessary.

    We would like to propose to replace abstract with local.
  • Reported: DDS4CCM 1.0b1 — Mon, 22 Feb 2010 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Make this (abstract) interface local
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Supporting Content Filtered Topics

  • Key: DDS4CCM_-100
  • Legacy Issue Number: 15172
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The current QueryFilter in the spec seems to match best to a QueryCondition.
    But DDS also provides the ContentFilteredTopic support, that doesn't seem to
    be available at the ccm-dds level, is this intended?
  • Reported: DDS4CCM 1.0b1 — Mon, 15 Feb 2010 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    The resolution is to add on the reading-side DDS ports a filter attribute and a
    basic port to change filter parameters when appropriate (this basic port will be
    used in the port and provided in the associated mirrorport). This disposal implies
    to add configuration attributes in porttype definitions.
    In addition, for clarity purpose, the formerly named "filter" attribute on the Reader
    interface is renamed "query" and inside the QueryFilter structure, the first field
    (formerly "query") is renamed "expression" and the second (formerly
    "query_parameters") simplified to become "parameters".
    Rationale:
    • The current QueryFilter is definitively intended to match the DDS query.
    ContentFilteredTopic is also a very important DDS feature that should be
    accessible through ccm-dds.
    • Configuration attributes fin porttype definitions is also useful for many
    other uses of the GIS (was missing)
  • Updated: Sat, 7 Mar 2015 00:50 GMT

getter text should be clearer about the behavior

  • Key: DDS4CCM_-99
  • Legacy Issue Number: 14847
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Consider that timeout and max_delivered_data act as maximum boundaries
    (not minimums to be enforced). These just mean that you will never wait
    more than timeout nor receive more than max_delivered_data data.
    Applied to you precise questions:

    1) should directly return with the 50 samples.

    2) should return after receiving the first sample.
  • Reported: DDS4CCM 1.0b1 — Fri, 11 Dec 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Add a better explanation
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Typo, 09-10-25, ExtendePortType

  • Key: DDS4CCM_-98
  • Legacy Issue Number: 14846
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 09-10-25, page 3, line 17, it says ExtendePortType instead of
    > ExtendedPortType
  • Reported: DDS4CCM 1.0b1 — Tue, 8 Dec 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

read_last

  • Key: DDS4CCM_-97
  • Legacy Issue Number: 14845
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    read_last returns the last sample of all instances. Any DDS error when
    > reading the data will be reported by an InternalError exception.
    > read_all returns all samples of all instances. Any DDS error when reading
    > the data will be reported by an InternalError exception.
    >
    > But, what is a DDS error, is this != DDS_RETCODE_OK? What todo with
    > DDS_RETCODE_NO_DATA, also then throw an exception or return an empty
    > sequence?
  • Reported: DDS4CCM 1.0b1 — Thu, 3 Dec 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Add a better explanation
  • Updated: Sat, 7 Mar 2015 00:50 GMT

IDL3+ keyword question/issue

  • Key: DDS4CCM_-96
  • Legacy Issue Number: 14836
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    I just noticed, in section 7.2.2.1, that 'array' is allowed as a type
    designator for template parameters. So now it is also a keyword? it
    isn't on the list of new keywords in 7.3.6.
  • Reported: DDS4CCM 1.0b1 — Wed, 11 Nov 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Remove 'array' from allowed type designator.
    Rationale: Purpose was to avoid as much as possible new keywords. Expressing
    the fact that the parameter type must be of type array does not appear to be such
    a significant use case that a new keyword is justified.
  • Updated: Sat, 7 Mar 2015 00:50 GMT

csl::on_inconsistent_topic

  • Key: DDS4CCM_-95
  • Legacy Issue Number: 14830
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    When we check the ConnectorStatusListener we see that it has an
    on_inconsistent_topic. The CSL is part of the DDS_Base connector, but the
    concept of a topic is added to the DDS_TopicBase which is derived from
    DDS_Base. It looks inconsistent that the CSL has a callback for something
    that is not known at that connector level.

    Why do we have a DDS_Base and a DDS_TopicBase, why not merge them into one
    connector base?

  • Reported: DDS4CCM 1.0b1 — Tue, 1 Dec 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS_TopicBase::key_fields

  • Key: DDS4CCM_-94
  • Legacy Issue Number: 14825
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS_TopicBase::key_fields is read/write with nonchangeble. I am aware that
    DDS doesn't have a standardized way to specify keys in IDL. At the CCM level
    we always instantiate a connector for a specific IDL type. It looks a nice
    feature to be able to ask to the connector what the key_fields are, that is
    something the tooling can't get from the IDL itself. But, why should this be
    a writable (but not changeable) attribute, couldn't it just be readonly, it
    is just there for the component to retrieve, it can probably be implemented
    with some vendor specific code.
  • Reported: DDS4CCM 1.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 00:50 GMT

mirrorport in CCMComponentPortKind

  • Key: DDS4CCM_-93
  • Legacy Issue Number: 14612
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In CCMComponentPortKind ExtendedPort and Mirrorport are added. First in
    update 5, page 11, line 21, font of MirrorPort is not ok. The other issue is
    that MirrorPort is a keyword, so it should be _MirrorPort or maybe
    ExtendedMirrorPort to match the ExtendedPort.
  • Reported: DDS4CCM 1.0b1 — Wed, 4 Nov 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    In addition to the change “MirrorPort” to “ExtendedMirrorPort”, correction of two
    other related mistakes
    • “CCMPortKind” does not exist (“CCMComponentPortKind” instead)
    • The name of the attribute is "kind" (“CCMComponentPortKind” is the
    name of the enumeration)
  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS4CCM module name

  • Key: DDS4CCM_-92
  • Legacy Issue Number: 14611
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In the DDS4CCM specification the IDL module name is sometimes CCM_DDS sometimes DDS_CCM. It should be CCM_DDS everywhere.
  • Reported: DDS4CCM 1.0b1 — Wed, 4 Nov 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Nme always the module CCM_DDS
  • Updated: Sat, 7 Mar 2015 00:50 GMT

topic_name attribute

  • Key: DDS4CCM_-88
  • Legacy Issue Number: 14574
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    we propose to change the topic_name attribute to a regular attribute, not readonly

  • Reported: DDS4CCM 1.0b1 — Tue, 20 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    This attribute as well as the others on DDS-DCPS connectors are not
    changeable dynamically as they are used to create and configure the DDS
    entities in support to this DDS pattern. However as their configuration by an
    external tool is highly desirable, they have been turned into regular attributes
    which can raise a NonChangeable exception.
  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS port interfaces should be local

  • Key: DDS4CCM_-91
  • Legacy Issue Number: 14590
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The DDS4CCM specification states that a component with a DDS port and the fragment of connector supporting this DDS port should be collocated but the related interfaces are not defined as local.
  • Reported: DDS4CCM 1.0b1 — Fri, 30 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Define all interfaces used in the DDS ports as local
  • Updated: Sat, 7 Mar 2015 00:50 GMT

readonly attribute DDS::StringSeq key_fields;?

  • Key: DDS4CCM_-90
  • Legacy Issue Number: 14581
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Why does 8.3.1 add the following attribute to the DDS_TopicBase? What is the functional meaning of this, shouldn't we just remove this attribute?

    readonly attribute DDS::StringSeq key_fields;

  • Reported: DDS4CCM 1.0b1 — Tue, 27 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 00:50 GMT

on_subscription_matched missing

  • Key: DDS4CCM_-89
  • Legacy Issue Number: 14578
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    on_subscription_matched is missing from the connectorstatuslistener, we propose to add this to one of the listeners

  • Reported: DDS4CCM 1.0b1 — Mon, 26 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Updater and instance handle

  • Key: DDS4CCM_-87
  • Legacy Issue Number: 14567
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Currently DDS4CCM specifies the Updater port below. We are looking at using
    register_instance/write/unregister_instance for this? If this port is
    intended to deliver an abstraction of these methods, why don't we pass the
    instancehandle back to the CCM Level?

    Johnny

    interface Updater<typename T>

    { // T assumed to be a data type void create (in T an_instance) raises (AlreadyCreated, InternalError); void update (in T an_instance) raises (NonExistent, InternalError); void delete (in T an_instance) raises (NonExistent, InternalError); readonly attribute boolean is_lifecycle_checked; }

    ;

  • Reported: DDS4CCM 1.0b1 — Thu, 15 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Add the optional instance_handle parameter to each operation dealing with a
    specific instance
  • Updated: Sat, 7 Mar 2015 00:50 GMT

(Multi)Updater method names?

  • Key: DDS4CCM_-86
  • Legacy Issue Number: 14562
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We noticed that the (Multi)Updater uses delete as method name, this is a
    reserved keyword in C++ which leads to _cxx_delete in the C++ mapping. Maybe
    it is an idea to use different method names, like register/write/dispose as
    in DDS? It is now a small change, but prevents users to use _cxx_delete when
    using C++.
  • Reported: DDS4CCM 1.0b1 — Tue, 13 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14214 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Extended ports

  • Key: DDS4CCM_-85
  • Legacy Issue Number: 14558
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On page 5, line 17, the spec says the following of extended ports:
    >
    > Extended ports allow grouping a set of single CCM ports (facet/provides
    > and
    > receptacle/uses), to define a particular semantic. The extended ports
    > are
    > declared in IDL3+ (extended IDL3 with new keywords). A new keyword is
    > introduced to define extended ports (porttype) and to declare an
    > extended
    > port at component level (port).
    >
    > Shouldn't this be:
    >
    > Extended ports allow grouping a set of single CCM ports (facet/provides
    > and
    > receptacle/uses) and extended ports, to define a particular semantic.
    > The
    > extended ports are declared in IDL3+ (extended IDL3 with new keywords).
    > A
    > new keyword is introduced to define extended ports (porttype) and to
    > declare
    > an extended port at component level (port).
    >
    > So, add that an extended port can contain extended ports again.
  • Reported: DDS4CCM 1.0b1 — Wed, 9 Sep 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 00:50 GMT

MultiListener

  • Key: DDS4CCM_-84
  • Legacy Issue Number: 14534
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On page 34 (word) on line 30 it gives the paragraph below. There is an
    > inconsistency there, it says "a sequence" and the next sentence it says
    > "each sequence". Looking at the IDL, it just is one sequence, so it
    > should
    > probably be "Depending of grouping mode, the sequence will contain"
    >
    > Johnny
    >
    > Behavior of a MultiListener is as follows:
    > on_data is here called with a sequence of new values. Depending of
    > grouping_mode, each sequence will contain 1) all the samples of an
    > instance,
    > 2) all new last samples or 3) all new samples.
    > Query filter (if any) will be found in the associated Reader (see below
    > -
    > definition of DDS extended ports).
  • Reported: DDS4CCM 1.0b1 — Wed, 7 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14214 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

QoS profile attribute name?

  • Key: DDS4CCM_-83
  • Legacy Issue Number: 14217
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS4CCM spec says the following about specifying qos profiles
    > > through
    > > XML
    > > ***
    > > A QoS Profile shall be attached as a configuration attribute to a DDS
    > > connector. This profile should contain all values for
    > > initializing DDS Entities that are required by the connector.
    > > ***
    > > Shouldn't the attribute name also be standardized?
  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Do we need the Multi* interfaces/ports?

  • Key: DDS4CCM_-82
  • Legacy Issue Number: 14214
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    I have been thinking of how I could use the Multi* interfaces/ports. I can
    imagine that a component developer first starts to use the basic ports and
    when he is more concerned with efficiency/performance he wants to use the
    Multi ports where he can send batches of data to DDS in one call. This looks
    nice, but when he wants todo that, he has to use different ports, which
    leads to a different component design. It is just not an easy change to make
    a new implementation of the component, it will become something completely
    different by use the other ports. No easy swap to a more efficient component
    implementation.

    I think we should remove all Multi ports and merge their functionality into
    the regular ports. That way a component developer can use the more efficient
    sequences based interfaces without large changes in models and deployment
    plants.
  • Reported: DDS4CCM 1.0b1 — Sun, 16 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Merge the multi-operations with the simple ones in a consolidated interface:
    Writer + MultiWriter ¨ Writer
    Updater + MultiUpdater ¨ Updater
    RawListener + MultiListener ¨ Listener
    StateLisener + MultiLisener ¨ StateListener
    Take the opportunity of this recast of the IDL description for the DDS ports, to
    better harmonize the names of the operations and to rationalize the roles of each
    interface.
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Sequence typedef leads to multiple sequences

  • Key: DDS4CCM_-81
  • Legacy Issue Number: 14213
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Several of the DDS ports have the following typedef:
    typedef sequence<T> T$Seq;

    This leads to an unique sequence type for each DDS interface (MultiWriter,
    MultiUpdater, Reader, Getter, MultiListener). This leads to 5 times
    typecodes, footprint, but also the sequences are really from a different
    type in the programming language. A sequence returned from a Reader, just
    can't passed directly into a writer, it are different sequences.

    I think we do want to have the same sequence to be used, the one related to
    T and this then has to be in the same namespace of T (the topic).

    If we for example have
    struct GPS

    { long x; long y; }

    We want to get sequence<GPS> GPSSeq in the global namespace.

    Not ::CCM_DDS::GPS_reader::GPSSeq, ::CCM_DDS::GPS_getter::GPSSeq, etc.

    I think we should remove the typedef of the interfaces and add it as a
    template argument, so that for example we get a reader below.

    interface Reader <typename T, typename TSeq>

    { void read_all (out TSeq instances, out ReadInfoSeq infos) raises (InternalError); void read_all_history (out TSeq instances, out ReadInfoSeq infos) raises (InternalError); void read_one (inout T an_instance, out ReadInfo info) raises (NonExistent, InternalError); void read_one_history (in T an_instance, out TSeq instances, out ReadInfoSeq infos) raises (NonExistent, InternalError); attribute QueryFilter filter setraises (BadParameter); }

    This would mean that the user of the interface/port has to instantiate it
    with the basic type and the sequence type, but that seems the only way to
    get only one sequence definition used between all the ports, corba, and dds
    itself. The seqeunce just also has to be in the same namespace as the
    original type T, we just can't do that with a typedef in an interface that
    uses the sequence.
  • Reported: DDS4CCM 1.0b1 — Fri, 14 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    The whole template support has been revisited. According to that new support all
    parametrized constructs are now grouped in a module. The CCM_DDS::Typed
    module is parameterized with T and Tseq – sequence <T>).
    Making the second parameter of type sequence<T> allows to check at compile
    time that the type of the second parameter is actually sequence of the first one.
  • Updated: Sat, 7 Mar 2015 00:50 GMT

NonExisting::indexes with Reader/Getter/Writer

  • Key: DDS4CCM_-80
  • Legacy Issue Number: 14212
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    With the Reader/Getter/Writer we always handle one instance. When we can't
    find that instance, should NonExisting::indexes then just be a sequence that
    is empty, or with one index in it, 0?
  • Reported: DDS4CCM 1.0b1 — Thu, 13 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Clarify that in this case, the sequence should contain the only index 0
  • Updated: Sat, 7 Mar 2015 00:50 GMT

non-keyed datatypes

  • Key: DDS4CCM_-79
  • Legacy Issue Number: 14211
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    When I look at the reader I get the impression this interface is designed
    with keyed data types in mind. How would for example read_one work when
    there is no key defined? What is the value that then should be passed in as
    instance?
  • Reported: DDS4CCM 1.0b1 — Thu, 13 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14176 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Reader port question

  • Key: DDS4CCM_-78
  • Legacy Issue Number: 14210
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    What is the behavior of the methods on the Reader interface when there is no
    data? Should the methods throw an exception or return a Boolean (but all
    read methods are void)
  • Reported: DDS4CCM 1.0b1 — Thu, 13 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify text
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Dds4ccm and includes

  • Key: DDS4CCM_-77
  • Legacy Issue Number: 14209
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    I got this questions from one of our users. I think it would be a good thing
    to standardize the IDL filenames where the dds ports are defined in to get
    interoperability in the user code. What are the ideas of others on this?

    Johnny

    > Are the headers to include in idl to get dds4ccm capabilities
    > standardized? My guess is no. I need to include more than
    > components.idl to get definitions. Do we need to raise this with omg?

  • Reported: DDS4CCM 1.0b1 — Wed, 12 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Give the name “ccm_dds.idl” to the idl file.
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Reader interface

  • Key: DDS4CCM_-76
  • Legacy Issue Number: 14208
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    I noticed that all methods on the Reader<typename T> interface have only out
    arguments. Some return all samples for all instances, with just out, the
    caller can't preallocate a buffer that can be used, the memory has to be
    allocated each time again and released when not used. This doesn't really
    use the power of DDS to my idea, any ideas on this?
  • Reported: DDS4CCM 1.0b1 — Fri, 7 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Typo, betwen

  • Key: DDS4CCM_-75
  • Legacy Issue Number: 14207
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the spec there is a typo, between instead of betwen

    Page 48, line 45. Page 49, line 41

    Also page 49, line 18, or instead of od
  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Typo, erroneaous

  • Key: DDS4CCM_-74
  • Legacy Issue Number: 14206
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    There is a typo in the batch 2 document, page 48, line 21: erroneaous
  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

QueryFilter

  • Key: DDS4CCM_-71
  • Legacy Issue Number: 14203
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A small question related to QueryFilter. From which namespace is StringSeq
    coming? Is this from the DDS namespace or from the CORBA namespace?

    Johnny

    struct QueryFilter

    { string query; StringSeq query_parameters }

    ;

  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Closed; No Change — DDS4CCM 1.0b2
  • Disposition Summary:

    withdrawn by submitter
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Reader::read_all_history

  • Key: DDS4CCM_-70
  • Legacy Issue Number: 14202
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The Reader::read_all_history is documented as:
    read_all_history returns all samples of all instances

    This could return a lot of data, the reader has no idea how much he will
    get. Does this make sense? There is no way the Reader can limit the history
    to a certain size as we could do with DDS directly.

  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14214 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Return value of operations on MultiUpdater/MultiWriter/

  • Key: DDS4CCM_-73
  • Legacy Issue Number: 14205
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A question, several of the methods on MultiUpdater/MultWriter return an
    unsigned long for nb of instances update/written/etc. At the moment the
    method succeeds all instances are updated, the caller has passed in the
    sequence, so he knows which elements got updated. If it failed, we get an
    exception with the index failed (so no return value). It looks that the
    return value doesn't add a thing, why not make it void?
  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    withdrawn by submitter
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Typo, 8.3.1

  • Key: DDS4CCM_-72
  • Legacy Issue Number: 14204
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    8.3.1 has a typo on line 27 (page 37), attributre
  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    withdrawn by submitter
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Destination module for implied template interfaces

  • Key: DDS4CCM_-69
  • Legacy Issue Number: 14201
  • Status: closed  
  • Source: Vanderbilt University ( Mr. William Otte)
  • Summary:

    Suppose we have this:

    ========
    foo.idl:
    module Foo
    {
    interface Foo_Intf < typename T >
    {
    };
    };

    =========
    bar.idl:
    #include "foo.idl"
    module Bar
    {
    porttype Bar_Port <typename T>

    { uses Foo_Intf<T> foo_port; }

    ;
    };

    =========
    baz.idl:
    #include "bar.idl"
    module Baz
    {
    struct Baz_Struct
    {
    };
    };

    =========
    foobarbaz.idl:
    #include "baz.idl"
    module FooBarBaz
    {
    connector FooBarBaz_Connector

    { mirrorport Bar_Port < Baz::Baz_Struct > foobarbaz_port; }

    ;
    };

    =========

    In which module(s) are the implicit interfaces for Bar_Port and
    Foo_Intf (with respect to their parameterization with Baz_Struct)
    assumed to be declared?
  • Reported: DDS4CCM 1.0b1 — Sun, 23 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    To give names to the instantiated interfaces, the initial version of the specification
    was proposing a naming convention which was far from covering all the cases as
    shown by this issue. In addition, this strategy was not in line with the one
    selected by IDL to get rid of anonymous types resulting from instantiation of
    existing templates (such as sequences). IDL now requires an explicit instantiation
    with a name allocated by the developer.
    It has thus been decided to remove that naming convention and to rely on
    explicit instantiations.
    Ina addition, a typical use case for parametrized extended ports and connectors
    is as follows: a parametrized interface is used in a similarly parametrized port
    type, which itself is used in a similarly parametrized connector. Eventually, when
    instantiated, it is mandatory that the concrete interface in support of the extended
    port attached to a component be exactly the same type as the one if support to
    the corresponding mirror port of the connector (otherwise connections will not be
    feasible), when in fact two explicit interface instantiations would result in two
    different types (even if identical). Therefore it is mandatory that the interface, the
    port type and the connector be in the same template scope, to allow a unique
    interface instantiation be shared by the instantiated port type and connector.
    This lead to proposing template support for the only grouping structure of IDL,
    namely the module. Adding template modules is on the one hand less intrusive in
    the existing IDL grammar and on the other hand far more versatile than the initial
    proposed support. As it is needed to support almost all the possible extended
    ports and connectors and enough for that purpose, it was decided to limit the
    template support to template modules.
    Consequently it was needed to recast almost entirely chapter 7, in order to
    present in one place the template support (while in the initial chapter
    organization, it was spread over the descriptions of each of the interaction
    constructs – port types, ports, connectors). The resulting outline is as follows:
    7 Generic Interaction Support
    7.1 Simple Generic Interaction Support
    7.2 Generic Interaction Support with Templates
    7.3 IDL3+ Grammar
    7.4 Programming Model for Connectors
    7.5 Connector Deployment and Configuration taking the opportunity of this recast, the whole grammar description has been
    rewritten in order to make it closer to the initial IDL grammar.
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Return type of the MultiWriter/MultiUpdater?

  • Key: DDS4CCM_-68
  • Legacy Issue Number: 14182
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Why do the MultWriter/MultiUpdater methods have a return value of unsigned
    long and not void? When the method succeeds all elements are written, if it
    fails, the return value itself is worthless because we get an exception.
    When it has succeeded the number of instances written is the same as the
    number of instances passed, or not?
  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14214 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

or MultiUpdater the return value of unsigned long doesn't make sense

  • Key: DDS4CCM_-67
  • Legacy Issue Number: 14181
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Also for MultiUpdater the return value of unsigned long doesn't make sense, if the methods work, the number of elements written is all, if it fails, the exception will tell you the number failed
  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14182 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

MultiWriter

  • Key: DDS4CCM_-66
  • Legacy Issue Number: 14180
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For MultiWriter we have: unsigned long write(in T$Seq instances) // returns nb of written raises (InternalError); But, when write fails we get an exception. So, when it success all data has been written and then the return value is not needed. I would recommend to make this method void. In case it succeeds all instances are written, if it fails, the exception will tell you the number failed, so it the number written is one less then the number failed
  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14182 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

For timestamp, is this the DDS source_timestamp? If yes, rename the member to source_timestamp

  • Key: DDS4CCM_-63
  • Legacy Issue Number: 14177
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For timestamp, is this the DDS source_timestamp? If yes, rename the member to source_timestamp
  • Reported: DDS4CCM 1.0b1 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    change the attribute
  • Updated: Sat, 7 Mar 2015 00:50 GMT

line 17 and 21 the exception NonExistent: under which conditions has this exception to be thrown?

  • Key: DDS4CCM_-62
  • Legacy Issue Number: 14176
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On line 17 and 21 the exception NonExistent is mentioned but this chapter doesn't describe under which conditions this exception has to be thrown. What should the read_one and read_one_history do when there are no samples? Throw an exception? what is an_istance then with read_one?
  • Reported: DDS4CCM 1.0b1 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    As part of the DDS-DCPS ports reorganization, improve the description of the
    Reader operations has been improved
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Line 14, change inees to fields

  • Key: DDS4CCM_-65
  • Legacy Issue Number: 14179
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 14, change inees to fields
  • Reported: DDS4CCM 1.0b1 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

For line 44 and 20 I would recommend to have update/create/delete as bold font

  • Key: DDS4CCM_-64
  • Legacy Issue Number: 14178
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For line 44 and 20 I would recommend to have update/create/delete as bold font, this refers to method names. Maybe split it in 2 sentences. For example: If is_lifecycle_checked is TRUE, then create checks that the instances are not already existing and update and delete that the instances are existing; AlreadyCreated and NonExistent exceptions may be raised. Change If is_lifecycle_checked is TRUE, then create checks that the instances are not already existing. Update and delete check that the instances are existing. AlreadyCreated and NonExistent exceptions may be raised. On page 31/39 line3, it says: The write or dispose orders are stopped. Write/dispose is DDS terminology, use: The update and delete calls are stopped ... On pase 31/39 line 3, say what happens with the create call? Does it stop on the first error?

  • Reported: DDS4CCM 1.0b1 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify the text
  • Updated: Sat, 7 Mar 2015 00:50 GMT

if no key is specified the an_instance is supposed to be empty?

  • Key: DDS4CCM_-61
  • Legacy Issue Number: 14175
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On line 34 and 36 the spec mentions that the parameter an_instance has to be filled with the key value, but what if the topic doesn't have a key? I think the spec should mention this, if no key is specified the an_instance is supposed to be empty?
  • Reported: DDS4CCM 1.0b1 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify the text
  • Updated: Sat, 7 Mar 2015 00:50 GMT

One line 24 the spec uses BadParameter, but it doesn't describe when this exception has to be thrown.

  • Key: DDS4CCM_-60
  • Legacy Issue Number: 14174
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    One line 24 the spec uses BadParameter, but it doesn't describe when this exception has to be thrown. On line 8 a void query is mentioned, but what is a void query? A string of size 0?

  • Reported: DDS4CCM 1.0b1 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Clarify that the test of validity for query and query parameters is to be done by
    DDS.
  • Updated: Sat, 7 Mar 2015 00:50 GMT

We propose to change the tags to and

  • Key: DDS4CCM_-59
  • Legacy Issue Number: 14168
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On line 11 it says: The root tag of the configuration file must be <dds_ccm> and end with </dds_ccm>. We propose to change the tags to <dds> and </dds>. The XML QoS is coming from this spec but shouldn't be tied to it, it can be used without ccm at all.
  • Reported: DDS4CCM 1.0b1 — Fri, 31 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    appply change
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Lines 32-36 imply that value declarations and type declarations may be parameterized

  • Key: DDS4CCM_-58
  • Legacy Issue Number: 14122
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    Lines 32-36 imply that value declarations and type declarations may be parameterized the same as interface declarations. By extension, lines 14 & 15 imply that value declarations and type declaration may also be used to implement 'provides' and 'uses' ports.
  • Reported: DDS4CCM 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

On line 24, the term '' should be '+'.

  • Key: DDS4CCM_-57
  • Legacy Issue Number: 14121
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    On line 24, the term '<connector_export>' should be '<connector_export>+'.
  • Reported: DDS4CCM 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

The non-terminal 'extended_port_decl' appears as both a component export and a connector export.

  • Key: DDS4CCM_-56
  • Legacy Issue Number: 14120
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The non-terminal 'extended_port_decl' appears as both a component export and a connector export. In particular, the 'generic_template_spec' non-terminal is problematic here. Since a component cannot be parameterized, as a component export, it must be the scoped name of a previously defined IDL type. As a connector export, however, it would appear to be legal IDL in this form, but also as a simple identifier matching one of the connector's template parameters. Are both constructs legal as connector exports? If so, they can't both be covered by 'generic_template_spec'.
  • Reported: DDS4CCM 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

What are the semantics of the 'primitive' keyword? Letting it match any primitive type seems too vague

  • Key: DDS4CCM_-55
  • Legacy Issue Number: 14119
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    What are the semantics of the 'primitive' keyword? Letting it match any primitive type seems too vague
  • Reported: DDS4CCM 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 8.2.2.1.3: ListenerControl attribute

  • Key: DDS4CCM_-54
  • Legacy Issue Number: 14118
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The ListenerControl defines the attribute enabled. When checking the DDS spec I see that DDS only has the feature to enable an entity, not disable it. Shouldn't this attribute not be defined as: void enable (); as in the dds spec 7.1.2.1.1.7 enable Also DDS says an entity is enabled by default, the DDS4CCM says false in 8.2.2.1.3 What is the background of this, shouldn't DDS4CCM say it is enabled by default?
  • Reported: DDS4CCM 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14117 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

ListenerControl

  • Key: DDS4CCM_-53
  • Legacy Issue Number: 14117
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS4CCM spec defines the interface ListenerControl. This is used for the various ports of 8.2.2.2. Some ports (like DDS_RawListen) do specify multiple listen ports, listener and status. There is now just one flag to enable/disable them both. maybe I am just interested in the status and not listener. We propose to move the attribute enabled to each listen interface and remove the ListenerControl interface from the spec. Then each listener can be enabled/disabled independently of each other
  • Reported: DDS4CCM 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    The data listening extended ports are defined based on the fact that very often
    (not to say all times) an application component which wants to be notified of
    modifications of data (listener mode) needs to start by an initialization phase
    where he gets all the existing data (and not receive thousands of notifications to
    get the data that were existing before its creation). It is why they combine a Data
    Listener basic port with a Reader one. Before that init phase is completed, the
    component cannot treat well incoming notifications. This is why that
    DataListenerControl port is also provided to turn on/off the data 'tap'.
    In return, Status Listeners are slightly different in nature: they are there to allow
    the component receive errors. The component has no choice with that and
    should be in position to get errors even during the init phase! It is the reason why
    those are always enabled (enabled at creation and no means / needs to enable
    them explicitly).
    The recasting of DDS listen ports has added the necessity for two enabled
    modes (ONE_BY_ONE and MANY_BY_MANY). In addition, the StateListener is
    given a specific control interface allowing in addition to control how filtering in and
    out is reflected in the notifications.
  • Updated: Sat, 7 Mar 2015 00:50 GMT

SampleInfo

  • Key: DDS4CCM_-52
  • Legacy Issue Number: 14110
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The CCM4DDS spec defines SampleInfo in its own IDL. It describes that this is a simplified version of DDS::SampleInfo. This new struct has the following disadvantages to our idea: - the struct that gets received from DDS itself has to be converted to the CCM4DDS struct taking performance - not all DDS information is available anymore for the component We propose to use DDS::SampleInfo throughout the spec instead of introducing a simplified shadow struct

  • Reported: DDS4CCM 1.0b1 — Sun, 26 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 00:50 GMT

propose to read the AMI chapter that was part of the alpha spec

  • Key: DDS4CCM_-51
  • Legacy Issue Number: 14080
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We propose to read the AMI chapter that was part of the alpha spec. It seems useful for ccm to also standardize the ami ports. the chapter will need some more work and fine tuning
  • Reported: DDS4CCM 1.0b1 — Thu, 16 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS4LwCCM - template interface body

  • Key: DDS4CCM_-46
  • Legacy Issue Number: 14038
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    On page 11, line 10, the body of a template interface is given as identical to that of a non-template interface. However, if the concatenation symbol $ can be used in a template interface member, how can this be? The $ symbol can't be part of a legal identifier, so it will have to be a token in its own right. This changes the grammar at some level, whether it be in the definition of an individual export, such as an operation, or in the definition of an identifier itself.

  • Reported: DDS4CCM 1.0b1 — Tue, 30 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

the spec should be more clear for which constructs the $ can be used

  • Key: DDS4CCM_-50
  • Legacy Issue Number: 14057
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    the spec should be more clear for which constructs the $ can be used. The rules for the regular IDL should be extended. Is this possible for attributes, exceptions, etc?
  • Reported: DDS4CCM 1.0b1 — Tue, 7 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13884 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS4LwCCM - concatentation symbol usage

  • Key: DDS4CCM_-49
  • Legacy Issue Number: 14046
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    On page 7, lines 24-26, there are examples of $ usage.
    These all apply to the parameter value following the
    type classifier 'typename'. Will it also be legal to
    use it with parameter values following other type
    classifiers?

  • Reported: DDS4CCM 1.0b1 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13884 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS4LwCCM - standalone template interfaces?

  • Key: DDS4CCM_-48
  • Legacy Issue Number: 14040
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    Is it illegal to use a template interface to define an 'interface type' which may then be specialized for simple CORBA object requests? My guess would be that a template interface is intended for use only in an extended port, but it would be helpful to state it explicitly in the document.
  • Reported: DDS4CCM 1.0b1 — Tue, 30 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS4LwCCM - forward declared template interface?

  • Key: DDS4CCM_-47
  • Legacy Issue Number: 14039
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    Nothing in the new IDL3+ production rules suggests that a template interface can be forward declared. This restriction makes sense if a template interface may be used only in an extended port definition (submitted as a separate issue), but it would be helpful to state the restriction explicitly in the document.

  • Reported: DDS4CCM 1.0b1 — Tue, 30 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

table 2 on page 16 (adobe number) on line 1 should have the same fonts as table 1

  • Key: DDS4CCM_-43
  • Legacy Issue Number: 14025
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    table 2 on page 16 (adobe number) on line 1 should have the same fonts as table 1
  • Reported: DDS4CCM 1.0b1 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

keywords that can't be used in other IDL anymore

  • Key: DDS4CCM_-42
  • Legacy Issue Number: 14024
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec adds typename, primitive, port, mirrorport, porttype, and connector as keywords meaning that they can't be used anymore in other IDL. Below a list of files for TAO that have port, all from CORBA specs and for the keyword port. * orbsvcs/orbsvcs/SSLIOP.idl: * orbsvcs/orbsvcs/HTIOP.idl: * orbsvcs/orbsvcs/CSIIOP.idl: * tao/EndpointPolicy/IIOPEndpointValue.pidl: * tao/Strategies/sciop_endpoints.pidl: * tao/IIOP_Endpoints.pidl: * tao/IIOP.pidl: Because of this we need to use the _ prefix mechanism as specified in CORBA 7.2.3.1. To our idea the DDS4CCM spec should clearly specify all new keywords together and refer to the section in the corba spec. At the end also the CORBA spec has to be updated to list the new keywords

  • Reported: DDS4CCM 1.0b1 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Gather all the new keywords in a table
  • Updated: Sat, 7 Mar 2015 00:50 GMT

The spec uses $ as string replacement for IDL3+

  • Key: DDS4CCM_-41
  • Legacy Issue Number: 14020
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec uses $ as string replacement for IDL3+. We find this not real and doubt whether a new string substitution should be added to the world. We would propose to use a different form, based on 'variable substitution' as found in unix shells, perl, ruby Two other options where we prefer the first one - use $

    {var} or #{var}

    or %var%; this is much clearer and matches already supported substitution options The new way would be: interface EventsPusher <typename T> { typedef sequence<T> #

    {T}Seq; void push (in #{T}

    Seq events); void push_#

    {T}

    (in T event); }; The other option is to use the C preprocessor way X##Y -> XY It then becomes interface EventsPusher <typename T>

    { typedef sequence<T> T##Seq; void push (in T##Seq events); void push_##T (in T event); }

    ;

  • Reported: DDS4CCM 1.0b1 — Mon, 22 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13884 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS4LwCCM - template interface IDL grammar

  • Key: DDS4CCM_-45
  • Legacy Issue Number: 14037
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    On page 11, line10, it appears that the (optional) inheritance spec comes after the interface body. This is probably not intended.

  • Reported: DDS4CCM 1.0b1 — Tue, 30 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

The spec doesn't say anything about forward declared IDL3+ interfaces

  • Key: DDS4CCM_-44
  • Legacy Issue Number: 14028
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec doesn't say anything about forward declared IDL3+ interfaces. If it is not allowed, it should be mentioned. If it is allowed, the spec should mention it and describe it like section 7.8.4 of the regular CORBA spec for regular interfaces
  • Reported: DDS4CCM 1.0b1 — Wed, 24 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Annex D: Font of line 20 not ok

  • Key: DDS4CCM_-39
  • Legacy Issue Number: 13974
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Font of line 20 not ok

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Shouldnh't InternalError use DDS::ReturnCode_t

  • Key: DDS4CCM_-38
  • Legacy Issue Number: 13973
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Shouldnh't InternalError use DDS::ReturnCode_t

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    apply change
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 9.2.2: Line 16 doesn't read, line 33 should also be clear

  • Key: DDS4CCM_-37
  • Legacy Issue Number: 13972
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 16 doesn't read, line 33 should also be clear, "is likely" should be specified more strict

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify the text
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section: 8.2.2.1.4 and annex A missing parameter name

  • Key: DDS4CCM_-40
  • Legacy Issue Number: 14017
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Last parameter of ConnectorStatusListener:: on_unexpected_status ( in DDS::Entity the_entity, in DDS::StatusKind); should be given a parameter name

  • Reported: DDS4CCM 1.0b1 — Fri, 19 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the error
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 9.2.2: Line 13 says DCPOS, shouldn't this be DCPS?

  • Key: DDS4CCM_-36
  • Legacy Issue Number: 13971
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 13 says DCPOS, shouldn't this be DCPS?
  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 9.2.1.1: line 39 should be indented

  • Key: DDS4CCM_-35
  • Legacy Issue Number: 13970
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    line 39 should be indented

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 9: Line 4 should start with a capital

  • Key: DDS4CCM_-34
  • Legacy Issue Number: 13969
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 4 should start with a capital

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13896 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 8.2.2.2.5: On line 5 DURATION_INFINITE_NSEC should be used

  • Key: DDS4CCM_-33
  • Legacy Issue Number: 13968
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On line 5 DURATION_INFINITE_NSEC should be used

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 8.4.2: For Table 12, Boolean, font of BOOLEAN_TRUE is not ok

  • Key: DDS4CCM_-32
  • Legacy Issue Number: 13967
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For Table 12, Boolean, font of BOOLEAN_TRUE is not ok

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

why not use an exception instead of a return value for the methods in Getter<>?

  • Key: DDS4CCM_-28
  • Legacy Issue Number: 13963
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    why not use an exception instead of a return value for the methods in Getter<>? On line 28, it should say "return as result" when decided to keep bool. For the time_out, what about making this an argument of all methods, is setting this at this level at the correct level?
  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Proposed solution
    1. keep the boolean as result and correct the text line 28
    2. let the time_out as an attribute as purpose is to simplify as much as
    possible the API . Reducing the number of parameters goes in that
    direction. We noticed in our systems that time-out value was unlikely to
    change from one call to another, making it a recurring value is therefore
    sensible;
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 8.4.2: On line 1, the annex numbers are lacking

  • Key: DDS4CCM_-31
  • Legacy Issue Number: 13966
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On line 1, the annex numbers are lacking

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Insert correctly the cross-references to the annexes.
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 8.3.1: On line 19, after DDS_Base it should be a {

  • Key: DDS4CCM_-30
  • Legacy Issue Number: 13965
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On line 19, after DDS_Base it should be a {
  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section: 8.2.2.1.2 font

  • Key: DDS4CCM_-29
  • Legacy Issue Number: 13964
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The font of line 11,12,13 should show the name of the methods in bold On line 29, On_data should start with lower capital

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typos
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 7.2.4.5: this seems to lack a figure, line 7 ends with "extrat below:" but nothing is below line 7

  • Key: DDS4CCM_-27
  • Legacy Issue Number: 13961
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    this seems to lack a figure, line 7 ends with "extrat below:" but nothing is below line 7
  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify the test
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 7.2.4.4: Line 3-4 doesn't read

  • Key: DDS4CCM_-26
  • Legacy Issue Number: 13960
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 3-4 doesn't read
  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify the text
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section: 7.2.4.2.1

  • Key: DDS4CCM_-25
  • Legacy Issue Number: 13959
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 2, remove - from ConnectorPackage-Description Fix type in footer 3, ComponentUsageDescription and ComponentPackage Description (typo in first, space in second)
  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typos
  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS_Listen is never defined in this spec

  • Key: DDS4CCM_-19
  • Legacy Issue Number: 13953
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec uses DDS_Listen<> on page 38 and 54, but DDS_Listen is never defined in this spec
  • Reported: DDS4CCM 1.0b1 — Mon, 8 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    The correct name is DDS_RawListen
  • Updated: Sat, 7 Mar 2015 00:50 GMT

this struct uses a StringSeq but the namespace is lacking

  • Key: DDS4CCM_-18
  • Legacy Issue Number: 13952
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    this struct uses a StringSeq but the namespace is lacking, should it be CORBA::StringSeq? struct QueryFilter

    { string query; StringSeq query_parameters; }

    ;

  • Reported: DDS4CCM 1.0b1 — Mon, 8 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13890 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 7.2.1.2: Line 16 ends with two semi colons instead of 1

  • Key: DDS4CCM_-23
  • Legacy Issue Number: 13957
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 16 ends with two semi colons instead of 1
  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 7.1.2: Layout of figure 2 and 3 can be improved

  • Key: DDS4CCM_-22
  • Legacy Issue Number: 13956
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Layout of figure 2 and 3 can be improved, not all lines hit the connector, text is not all readable
  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Change the figures
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section: 6.1.2: It should be ExtendedPort and MirrorPort, not InversePort

  • Key: DDS4CCM_-21
  • Legacy Issue Number: 13955
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    It should be ExtendedPort and MirrorPort, not InversePort
  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

For 3, check UML CCM reference, it says 5formal, is that ok?

  • Key: DDS4CCM_-20
  • Legacy Issue Number: 13954
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For 3, check UML CCM reference, it says 5formal, is that ok?
  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

The usage of ULongSeq should be CORBA::ULongSeq

  • Key: DDS4CCM_-17
  • Legacy Issue Number: 13949
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The usage of ULongSeq should be CORBA::ULongSeq to show that these types are coming from the CORBA namespace
  • Reported: DDS4CCM 1.0b1 — Mon, 8 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13888 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Figure 1 should say IDL3+ instead of Extended IDL3

  • Key: DDS4CCM_-16
  • Legacy Issue Number: 13946
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Figure 1 should say IDL3+ instead of Extended IDL3
  • Reported: DDS4CCM 1.0b1 — Tue, 2 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Replace Extended IDL3 by IDL3+
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Line 15,19, use CORBA::ULongSeq instead of ULongSeq Line 23, use an enum for the error_code?

  • Key: DDS4CCM_-15
  • Legacy Issue Number: 13897
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 15,19, use CORBA::ULongSeq instead of ULongSeq Line 23, use an enum for the error_code?
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issues 13949 + 13973 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

line 4, replace the with The (T upper case)

  • Key: DDS4CCM_-14
  • Legacy Issue Number: 13896
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    line 4, replace the with The (T upper case)
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Line 13/16/21/24, shouldn't the DDS_ be removed from the kind?

  • Key: DDS4CCM_-13
  • Legacy Issue Number: 13895
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 13/16/21/24, shouldn't the DDS_ be removed from the kind?
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13894 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

line 8, shouldn't DDS_KEEP_ALL_HISTORY_QOS be replaces with KEEP_ALL_HISTORY_QOS

  • Key: DDS4CCM_-12
  • Legacy Issue Number: 13894
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    line 8, shouldn't DDS_KEEP_ALL_HISTORY_QOS be replaces with KEEP_ALL_HISTORY_QOS
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Discard DDS_ in front of all QoS values
  • Updated: Sat, 7 Mar 2015 00:50 GMT

line 27, change attributre to attribute also change StringSeq to CORBA::StringSeq

  • Key: DDS4CCM_-11
  • Legacy Issue Number: 13893
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    line 27, change attributre to attribute also change StringSeq to CORBA::StringSeq
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Correct the typo (the second part of the issue is already in issue 13890)
  • Updated: Sat, 7 Mar 2015 00:50 GMT

line 52, change DDS_StateLsisten to DDS_StateListen

  • Key: DDS4CCM_-10
  • Legacy Issue Number: 13892
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    line 52, change DDS_StateLsisten to DDS_StateListen
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

line 29, change On_data to on_data (lower case)

  • Key: DDS4CCM_-9
  • Legacy Issue Number: 13891
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    line 29, change On_data to on_data (lower case)
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Change on line 5 StringSeq to CORBA::StringSeq

  • Key: DDS4CCM_-8
  • Legacy Issue Number: 13890
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Change on line 5 StringSeq to CORBA::StringSeq
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    As CCM is meant to abstract from CORBA, it is not a good thing to create here a
    dependency to CORBA In addition, those StringSeq will be passed to DDS,
    DDS::StringSeq is therefore a much better choice.
    This concerns the query parameters as well as the topic key fields
  • Updated: Sat, 7 Mar 2015 00:50 GMT

wouldn't it be more maintainable to add to lines 35-40 a typedef for the return value (and other interfaces)?

  • Key: DDS4CCM_-6
  • Legacy Issue Number: 13888
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    wouldn't it be more maintainable to add to lines 35-40 a typedef for the return value (and other interfaces)? typedef unsigned long bytes; Also change the comment to // returns number of bytes written interface MultiWriter<typename T>

    { // T assumed to be a data type typedef sequence<T> T$Seq; nb_bytes write(in T$Seq instances) // returns nb of written raises (InternalError); attribute boolean is_coherent_write; }

    ;
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    The idea is good but the proposed name (bytes) is misleading as what is
    returned is a count of data samples. In addition, it in inconsistent to let unsigned
    long as index in lists of data. It is thus proposed to name that typedef
    DataNumber_t, to create also DataNumberSeq and to use them each time the
    unsigned long or sequence of Ulong were used.
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Should be as below (lower case) 7.2.3.4.1 set_configuration_values

  • Key: DDS4CCM_-5
  • Legacy Issue Number: 13886
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 18, has 7.2.3.4.1 Set_configuration_values Should be as below (lower case) 7.2.3.4.1 set_configuration_values
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo
  • Updated: Sat, 7 Mar 2015 00:50 GMT

Shouldn't table 10 take parameterized connectors into account?

  • Key: DDS4CCM_-4
  • Legacy Issue Number: 13885
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Shouldn't table 10 take parameterized connectors into account?
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

push operation should be push_T$

  • Key: DDS4CCM_-3
  • Legacy Issue Number: 13884
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Page 15 lists: // Parameterized interface interface EventsPusher <typename T>

    { typedef sequence<T> T$Seq; // construction of a type name void push (in T$Seq events); void push_$T (in T event); // construction of an operation name }

    ; The replacement, is that T$ or $T, seems the push operation should be push_T$
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    The new template support in response to issue 14201 removes the need for that
    controversial concatenation operator.
  • Updated: Sat, 7 Mar 2015 00:50 GMT

change nb to number in the comment on line 29/32/35

  • Key: DDS4CCM_-7
  • Legacy Issue Number: 13889
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    change nb to number in the comment on line 29/32/35
  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13888 for disposition
  • Updated: Sat, 7 Mar 2015 00:50 GMT

inout data parameters

  • Key: DDS4CCM_-2
  • Legacy Issue Number: 15225
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Currently in the spec when several data are to be returned, the related parameter is an 'out' sequence. Even if this is semantically correct, it makes implementation of smart memory management impossible.
    Suggestion is then to turn those parameters into 'inout' ones.

  • Reported: DDS4CCM 1.0b2 — Mon, 26 Apr 2010 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0
  • Disposition Summary:

    Change the sequence out parameters into inout.
  • Updated: Sat, 7 Mar 2015 00:48 GMT

Type, DDS Listen instead of DDS_Listen

  • Key: DDS4CCM_-1
  • Legacy Issue Number: 15160
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    page 40 line one has a type, DDS Listen should be DDS_Listen for the port name

  • Reported: DDS4CCM 1.0b2 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0
  • Disposition Summary:

    Correct the typo
  • Updated: Sat, 7 Mar 2015 00:48 GMT

DDS4CCM RTF - proposed simple spec extension for common DDS use case

  • Key: DDS4CCM11-13
  • Legacy Issue Number: 18874
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Mark Hayman)
  • Summary:

    We have what for our DDS4CCM applications is a common use case that is not currently covered by the DDS4CCM v1.1 spec, and the CIAO implementation of it that we use. We would like to propose a minor extension to the DDS4CCM specification to support this use case in accordance with spec paragraph 7.1.1, where it says “the most common DDS use patterns have been then identified as connectors…”

    Specifically, I’m speaking of being able to define a distributed state table via a keyed DDS topic with 1) the ability for a subscriber to receive an event notification/callback for published sample updates to the topic in a DRTE event-driven component framework, combined with 2) a subscriber ability to read the state table information for the topic non-destructively from the reader cache during post-initialization operation.

    Referencing old emails from the OMG dds4ccm mail list during the 2009-2010 timeframe, there were numerous discussions regarding the use of DDS read vs. take on reactive “push” vs. on-demand/polled “pull” extended port types and supporting interfaces. The result from that time was that the DDS_Listen and DDS_StateListen reactive extended port types that provide callback notification of newly received samples would utilize a take. This was ostensibly to help prevent typical user QoS configuration errors where read buffers within connectors using default QoS might fill up and consume excessive system resources, cause errors, etc. In contrast, the on-demand DDS_Read and DDS_Get ports implicitly do a read, rather than a take.

    Note that the spec does not explicitly require the use of either read or take on any extended port or connector type. In fact it doesn’t say anything at all about underlying connector buffer management and associated semantics, aside from an implication that take should be used on reactive listen type ports due to their normal behavior of always delivering “fresh” data in callbacks, as well as the following note from section 7.2.2.1.2 page 14 of the spec that describes the “Interface Reader”:

    "Note – This interface is the basis for a passive data reader (i.e., a component that just looks at the data as they are). It is also very useful for the reactive data getters (i.e., components that need to react to new data, whether they choose to get them in pull mode or be notified in push mode) in their initialization phase. This is the reason why all the DDS ports on the subscribing side will embed a Reader basic port."

    The assumption in this note that the Reader basic port interface on the DDS_Listen and DDS_StateListen reactive porttypes would only be useful for application layer initialization and subsequent duplication of the instanced state information flowing through the reader cache is what presumably led to their underlying assumed use of take. But again, this does not match our most common use case for the DDS_State connector in particular, where the reactive DDS_Listen and DDS_StateListen porttypes that offer the event notification callback also have the side-effect of destroying the reader cache with take vs. a read. This in turn renders their built-in Reader interfaces pretty useless for event-driven, run-time operation beyond the initialization phase of the component port’s lifecycle.

    The apparent original use case in mind for the existing reactive subscriber port types was an application component that would utilize the connector capabilities for distributing and receiving new/updated/deleted keyed instance samples, consume these incoming samples once received with a take, and then require the user to duplicate the state table information at the application layer in a map-like state structure or a database of some variety. Per the note, the Reader interface was only envisioned as useful for initialization of application layer state tables, prior to turning on either the ONE_BY_ONE or MANY_BY_MANY listener mode callbacks.

    We have a number of applications where we would like to receive event notifications for simple distributed state data on topics, with no required application layer state duplication, using a KEEP_LAST history QoS setting with small read buffer depth. In these applications, we would like to allow the latest samples for these instances to remain in the reader cache for run-time Reader query access by users, rather than having to copy and maintain them at the application layer instead.

    We have exchanged a number of ideas with our CIAO support contractor Remedy IT on how we might best handle the use case of subscriber side event notification + distributed state query access. Our proposed extension to cover this common use case is captured in the three minor requested spec extensions below. This approach appears to have the least impact on existing implementations of DDS4CCM. Since this is a functionality extension vs. a change, it should not affect existing implementations that use the v1.1 interfaces and connector definitions, aside from the possible need for an additional empty callback stub in the language level component executor (which for us is auto-generated by the CIAO IDL compiler anyway).

    1) Add a fourth DATA_AVAILABLE enumeration option to the existing “ListenerMode” enum definition, as defined in section 7.2.2.1.2 in the “Interface DataListenerControl” sub-section at the top of page 16 (26 of 72):

    enum ListenerMode

    { NOT_ENABLED, ONE_BY_ONE, MANY_BY_MANY, DATA_AVAILABLE // new mode setting for event notification + distributed state query }

    ;

    2) Add a new third callback operation called “on_data_available()” to the existing “Listener” interface definition, as defined in section 7.2.2.1.2 in the “Interface Listener” sub-section at the bottom of page 14 (24 of 72):

    local interface Listener

    { void on_one_data (in T datum, in ReadInfo info); void on_many_data (in TSeq data, in ReadInfoSeq infos); void on_data_available(); // new callback operation for DATA_AVAILABLE mode }

    ;

    3) Add a new fifth callback operation called “on_data_available()” to the existing “StateListener” interface definition, as defined in section 7.2.2.1.2 in the “Interface StateListener” sub-section in the middle of page 15 (25 of 72):

    local interface StateListener

    { void on_creation (in T datum, in ReadInfo info); void on_one_update (in T datum, in ReadInfo info); void on_many_updates (in TSeq data, in ReadInfoSeq infos); void on_deletion (in T datum, in ReadInfo info); void on_data_available(); // new callback operation for DATA_AVAILABLE mode }

    ;

    Functionally, a user wishing to support the event notification + distributed state query use case with DDS4CCM would first enable the DATA_AVAILABLE listener mode (after initialization) on the “data_control” basic port of either the DDS_Listen or DDS_StateListen extended port types – instead of either the ONE_BY_ONE or MANY_BY_MANY mode as they do now.

    Once DATA_AVAILABLE mode is enabled, the new on_data_available() callback would be invoked by the connector, in lieu of the other callback operations on the Listener or StateListener interfaces, when a new sample arrives on the topic. In this new listen mode, neither a DDS read nor take operation would be performed by the connector prior to the callback invocation, which is simply an event notification to the application component with no data passed. Within the application component’s on_data_available() implementation, the user is then free to utilize the existing Reader interface on these two reactive extended port types to query the state information in the underlying DDS reader cache, which should remain intact and accessible during post-initialization system operation.
  • Reported: DDS4CCM 1.0 — Wed, 14 Aug 2013 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.1
  • Disposition Summary:

    issue withdrawn by submitter
  • Updated: Fri, 6 Mar 2015 23:16 GMT

Inconsistent extensibility kind for enumerations

  • Key: DDSXTY11-8
  • Legacy Issue Number: 16559
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification of the extensibility kind for enumeration types is inconsistent. Figure 10 in section 7.2.2.3.1, "Enumeration Types", indicates that the extensibility_kind of all enumeration types is FINAL. However, Table 11 in section 7.2.3, "Type Extensibility and Mutability", says, "Enumeration types may be final, extensible, or mutable on a type-by-type basis."

    Proposed Resolution:

    The assignability rules for enumerations already address different extensibility kinds, so we can preserve the more general statement from 7.2.3. Fix Figure 10.

  • Reported: DDS-XTypes 1.0 — Mon, 19 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    The assignability rules for enumerations already address different extensibility kinds, so we can preserve the more general statement from 7.2.3. Fix Figure 10.
  • Updated: Fri, 6 Mar 2015 23:16 GMT

Inconsistencies related to use of const&

  • Key: DDSPSMC-24
  • Legacy Issue Number: 16269
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    There is consistency issue in the spec with respect to the use of const & versus returning copies.

  • Reported: DDS-PSM-Cxx 1.0b1 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    The API has been verified to consistently use const reference when possible and values when necessary. Notice that these changes do not change the semantics but in some case can reduce the number of temporary object created.
  • Updated: Fri, 6 Mar 2015 23:16 GMT

DynamicData interface of the Language Binding section

  • Key: DDSXTY_-26
  • Legacy Issue Number: 15418
  • Status: closed  
  • Source: Brookhaven National Laboratory ( Nikolay Malitsky)
  • Summary:

    First, thank you for this specification. It provides a systematic and comprehensive definition of the runtime type system which is important in the context of the next version of Experimental Physics and Industrial Control System (http://www.aps.anl.gov/epics/). Moreover, from my perspective, the conceptual idea of the dynamic container is more generic than DDS and EPICS and addresses other technologies, like AMQP. In this regard, I have several suggestions for the DynamicData interface of the Language Binding section, particularly, to scale down the number of methods from 270 to 30 and to replace the 'out' arguments with return values.

    At this time, we are working on the prototype of this variant based on the consolidation of several approaches, including DDS Dynamic Data, Google's Protocol Buffers, etc. Certainly, for us, it would be ideal to have some common solution. According to the Beta 1 procedure, OMG will accumulate comments by November 29. But, probably, it can be discussed earlier, for example, at the coming OMG technical meeting. Please advise.

  • Reported: DDS-XTypes 1.0b2 — Mon, 16 Aug 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    non issue, closed
  • Updated: Fri, 6 Mar 2015 23:15 GMT

The specification does not state how to generate unique GUIDs

  • Key: DDSIRTP21-12
  • Legacy Issue Number: 12509
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Niels Kortstee)
  • Summary:

    In RTPS each entity has a so-called GUID_t. It consists of a 12 Byte GuidPrefix_and a 4-Byte EntityId_t and must be globally unique. In heterogeneous systems (with multiple RTPS implementations), the specification provides no mechanism or guidance to ensure global uniqueness.

    A solution would be to make the vendorId part of the GuidPrefix_t.

    Resolution:
    The first two bytes of the GUID_t prefix should be the vendor id.
  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    The first two bytes of the GUID_t prefix should be the vendor id, the rest can be
    chosen by the vendors as they see fit, as long as they ensure uniqueness.
    This approach avoids collisions between vendors, but has the drawback that it limits
    the range of available GUID prefixes for each vendor. But as we can see below, this
    limitation should not cause a problem as the remaining 10 Bytes are sufficient to
    generate unique GUIDs even in very large DDS domains.
    The GUID_t prefix is 12 bytes, after 2 are used for the vendor there remain only 10
    bytes that can be used to generate unique DDS Entity GUIDs, this means there can
    be S = 2^80 different GUID prefixes.
    GUID prefixes are assigned in one-to-one correspondence with DDS
    DomainParticipants as all the DDS Entities within a participant share the same GUID
    Prefix.
    Assume that a particular DDS domain has ‘n’ DDS participants, if a good algorithm is
    used to generate GUID prefixes, the probability of a collision P (i.e. two or more
    entities having the same GUID) can be approximated as: P ~ 1 – exp(-(n^2)/(2*S))
    In a very large system with 1 Million DDS Participants the probability of a collision
    would be extremely small: 4e-13
    In a system with 1 Billion (10^9) DDS Participants the probability of a collision would
    be 4e-7 also very small.
    Therefore the solution requiring the first 2 bytes of the GUID_t Prefix to match the
    vendorId will not prevent the generation of unique GUID prefixes.
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Update protocol version to 2.1

  • Key: DDSIRTP21-9
  • Legacy Issue Number: 12506
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Summary:
    The set of proposed changes necessitates updating the protocol version.
    Resolution:
    Change protocol version from 2.0 to 2.1.
  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Change protocol version from 2.0 to 2.1.
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Change StatusInfo from SubmessageElement to Parameter

  • Key: DDSIRTP21-8
  • Legacy Issue Number: 12505
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Summary:
    The statusInfo field of DATA submessage holds flags relating DDS-level concepts that are interpreted at higher layers than RTPS. Hence, it is not necessary to have statusInfo as an explicit field; rather, it can be included in the inlineQos SubmessageElement.

    Resolution:
    Replace all instances of the statusInfo field of DATA with the new statusInfo inline parameter.
  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Replace all instances of the statusInfo field of DATA with the new statusInfo inline parameter.
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Computation of KeyHash is unspecified

  • Key: DDSIRTP21-11
  • Legacy Issue Number: 12508
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Niels Kortstee)
  • Summary:

    Summary:
    The specification does not describe how the KeyHash is computed from the Key.

    This implicates that key hashes in messages coming from different RTPS implementations can never be interpreted, because one implementation may utilize a different key hash algorithm then the other.

    I would prefer that the hash algorithm becomes part of the specification. RTPS implementations can choose to implement the prescribed algorithm or simply use a zero-valued key.

    Resolution:
    The UDP PIM should mandate that the KeyHash is computed either as the serialized key or else as an MD5 digest, depending on whether the serialize key for the type can exceed the 128 that are used for the KeyHash.
  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    The UDP PIM should mandate that the KeyHash is computed either as the serialized key or else as an MD5 digest, depending on whether the serialize key for the type can exceed the 128 that are used for the KeyHash.

    The resolution of this issue depends on the presence of new section 9.6.3.3 titled "Key Hash" added as part of the resolution of issue. 12504. If issue 12504 is resolved in a way that does not add this section, then the resolution proposed here would not be valid.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Properly assign vendor IDs

  • Key: DDSIRTP21-10
  • Legacy Issue Number: 12507
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Summary:
    Section 9.4.5.1.1 leaves unspecified the list of vendor IDs
    Resolution:
    Modify section to include a reference to an appendix or table where all the vendor IDs are listed.
  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Modify section to specify that vendor ID’s are managed separately from the
    specification and include a link to http://www.omgwiki.org/dds/content/page/ddsrtps-
    vendor-and-product-ids
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Some submessage kinds are logically redundant and not extensible

  • Key: DDSIRTP21-6
  • Legacy Issue Number: 12503
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    The submessages required to send Keyed and Unkeyed data are mapped in the PSM as two different submessages (DATA and NOKEY_DATA). These submessages have almost identical content so there is no reason to use two submessages for this. Furthermore having two different submessages at the PSM level and exposing the KeyHash as part of the submessage introduces problems with regards to the implementation and the extensibility of the protocol. For example, future versions of the protocol may want to support keyhashes that are either bigger or smaller than the 16 Bytes used today, and do that in an inter-operable manner without breaking backwards compatibility. They may also want to omit sending a key hash when the size of the key itself is small. As the key is always included as part of the data, sending the KeyHash for small keys is inefficient at best.
    This could be resolved by combining the two PSM submessages and moving the KeyHash into the InlineQos.

    Resolution:
    Combine the DATA and NOKEY_DATA submessages. Also combine the DATA_FRAG and NOKEY_DATA_FRAG. Include additional fields in these submessages to enable extensibility for future submessage-specific options.
  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Combine the DATA and NOKEY_DATA submessages. Also combine the DATA_FRAG and NOKEY_DATA_FRAG. Include additional fields in these submessages to enable extensibility for future submessage-specific options
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Change KeyHash from SubmessageElement to Parameter

  • Key: DDSIRTP21-7
  • Legacy Issue Number: 12504
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    The inclusion of keyHashPrefix and keyHashSuffix fields in DATA and DATA_FRAG submessages should be optional. The keyHash is a DDS-level optimization whose interpretation by RTPS is unnecessary. Hence, it is logically better to reassign it as a parameter that may be included inline.
    Resolution:
    Replace mentioned instances of keyHashPrefix/Suffix with keyHash inline parameter.
  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Replace mentioned instances of keyHashPrefix/Suffix with keyHash inline parameter.
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Clarify when a Payload is present in a submessage

  • Key: DDSIRTP21-5
  • Legacy Issue Number: 12502
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Some submessages can optionally include a payload. For example the DATA submessage includes a payload in most cases, except in some special cases where the submessage indicates unregistration and/or disposal of the data.

    Currently the presence of the payload is tied to the value of the unregister and dispose flags. This is inflexible and also does not support some use-cases where it is desirable to send data with dispose messages. It would be much better to make the presence of the Data Payload separately configurable in the submessage.

    Resolution:
    Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information
  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Introduce a new submessage element that represents a general submessage payload whose type is specified by submessage meta-information
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Include key in serialized ParticipantMessageData

  • Key: DDSIRTP21-4
  • Legacy Issue Number: 12501
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    The specification states in section 9.6.2.1 that the key portion of ParticipantMessageData is not serialized as part of the DATA submessage. The stated argument is that the key is already part of the DATA submessage. This argument is incorrect, the DATA message may optionally include a KeyHash which is not necessarily the same as the key. Moreover this makes the ParticipantMessageData special in the way it is serialized. The saving in bandwidth consumed do not justify all this "special code". It would be far better if the ParticipantMessageData was treated as any regular data message and the key was serialized along.
    Resolution:
    Change the description in Section 9.6.2.1 to not refrain from serializing the key of ParticipantMessageData.
  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Change the description in Section 9.6.2.1 to not refrain from serializing the key of ParticipantMessageData.
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Add implementation note on not serializing redundant info in builtin topic

  • Key: DDSIRTP21-3
  • Legacy Issue Number: 12500
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Simple discovery data has parameters containing redundant information. To not waste bandwidth, implementations should be able to refrain from sending redundant information. As such, the spec should include an implementation note on this matter.
    Resolution:
    Add text in PSM, Section 9.6.2.2 describing the general allowable case in which implementations may avoid serializing parameters with redundant information.
    Revised Text:
    Add to Section 9.6.2.2, right before section 9.6.2.2.1 the following paragraph::

    For optimization, implementations of the protocol may refrain from include in the Data submessage a parameter if it contains information that is redundant with parameters present in that same Data submessage. As a result of this optimization an implementation can omit the serialization of the parameters listed in - ParameterId subspaces- ParameterId subspaces

    Table 9.1 - ParameterId subspaces
    BuiltinEndpoint Parameter which may be omitted Parameter where the information on the omitted parameter can be found
    SPDPdiscoveredParticipantData ParticipantProxy::guidPrefix ParticipantBuiltinTopicData::key

    DiscoveredReaderData ReaderProxy::remoteReaderGuid SubscriptionBuiltinTopicData::key

    DiscoveredWriterData ReaderProxy::remoteWriterGuid PublicationBuiltinTopicData::key
    .
    For example, an implementation of the protocol sending DATA message containing the SPDPdiscoveredParticipantData may omit the parameter that contains the guidPrefix. If the guidPrefix is not present in the DATA message, the implementation of the protocol in the receiver side must derive this value from the "key" parameter which is always present in the DATA message.
  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Add text in PSM, Section 9.6.2.2 describing the general allowable case in which implementations may avoid serializing parameters with redundant information.
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Clarify usage of KeyHash

  • Key: DDSIRTP21-2
  • Legacy Issue Number: 12499
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Usage of keyHash is currently underspecified. It is not clear whether its presence in the message is mandatory and how it should be processed.
    Resolution:
    Expanded descriptions of the intended usage of keyHash parameter are added.
    Revised Text:
    Insert new Section 8.7.8

    8.7.8 "Key Hash"

    The Key Hash provides a hint for the key that uniquely identifies the data-object that is being changed within the set of objects that have been registered by the RTPS Writer.

    Nominally the key is part of the serialized data of a data submessage. Using the key hash benefits implementations providing a faster alternative than deserializing the full key from the received data-object.

    When the key hash is not received by a DataReader, it should be computed from the data itself. If there is no data in the submessage, then a default zero-valued key hash should be used by the DataReader

    If there is a KeyHash, if present, shall be computed as described in Section 9.6.3.3
  • Reported: DDSI-RTPS 2.0 — Tue, 20 May 2008 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.1
  • Disposition Summary:

    Expanded descriptions of the intended usage of keyHash parameter are added
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Add Parameter ID for Original Writer Info

  • Key: DDSIRTP2-28
  • Legacy Issue Number: 11075
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    In order to implement the DDS DURABILITY Persistent QoS, a persistence-service needs to send the data that has been received and stored on behalf of the persistent writer.

    The service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

    Resolution:
    Introduce a new parameter Id, ORIGINAL_WRITER_INFO, that can appear in parameter lists.

    Revised Text:

    Add to table 9.4:

    Type PSM Mapping
    OriginalWriterInfo_t struct

    { GUID_t originalWriterGUID; SequenceNumber_t originalWriterSN; ParameterList originalWriterQos;}

    OriginalWriterInfo;

    Append to table 9.13:
    Name ID Type
    PID_ORIGINAL_WRITER_INFO 0x0061 OriginalWriterInfo_t

    Add new section:

    8.7.6 Original Writer Info

    A service supporting the Persistent level of DDS Durability QoS needs to send the data that has been received and stored on behalf of the persistent writer.

    This service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

    The RTPS protocol supports this forwarding of messages by including information of the original writer.

    OriginalWriterInfo_t
    attribute type value
    originalWriterGUID GUID_t the GUID of the RTPS Writer that first generated the message
    originalWriterSN SequenceNumber_t the Sequence Number of the CacheChange as sent from the original writer
    originalWriterQos ParameterList the list of inline parameters that should apply to the CacheChange as sent by the RTPS Writer that first generated the sample

    When a RTPS reader receives this information it will treat it as a normal CacheChange, but once the CacheChange is ready to be commited to the DDS DataReader, it will not commit it. Instead, it will hand it off to the HistoryCache of the RTPSReader that is communicating with the RTPSWriter indicated in the ORIGINAL_WRITER_INFO inline-Qos and treat it as having the sequence number which appears there and the ParameterList also included in the ORIGINAL_WRITER_INFO.
  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 22:56 GMT

Add Max Sample Size Serialized Parameter Id

  • Key: DDSIRTP2-27
  • Legacy Issue Number: 11074
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A type's maximum serialized size may be included in a parameter list. A new parameter Id should be added.

    Resolution:
    Add parameter Id for Type Max Sample Size Serialized

    Revised Text:

    Append to Table 9.11:
    Name ID Type
    PID_TYPE_MAX_SIZE_SERIALIZED 0x0060 long
  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 22:55 GMT

Inconsistent generated code for DynamicType::descriptor

  • Key: DDSXTY_-25
  • Legacy Issue Number: 17090
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    DynamicType has a property "descriptor" of type (read-only) TypeDescriptor. This property is mapped to IDL as a readonly attribute. When code is generated for this attribute in C or C++, the corresponding getter is not consistent with the other getters in the same class, either in terms of its style or in terms of its memory management. (The other getters are all defined explicitly as methods in IDL.)

    Proposed Resolution:
    Remove this member and add an explicit getter method:

    DDS::ReturnCode_t get_descriptor(
    inout TypeDescriptor descriptor);

    This method overwrites a user-provided object, just like get_member_by_name and get_annotation.
  • Reported: DDS-XTypes 1.0b2 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Remove these attributes and add explicit getter methods, like:
    DDS::ReturnCode_t get_descriptor(
    inout TypeDescriptor descriptor);
    This method overwrites a user-provided object, just like DynamicType::get_member_by_name and get_annotation
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Circular reference in definition of specialized Primitive Types

  • Key: DDSXTY_-24
  • Legacy Issue Number: 17023
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The specialized Primitive Types defined for Int, UInt, Float, Boolean, etc... each define a property 'value' that is typed by the property's owner thus resulting in a circular reference in the model.

    Figure 6
    Figure 7
    Figure 8

    Each of these are specializations of the PrimitiveType abstract class. Changing the UML instance of the PrimitiveType definition to a UML:PrimitiveType will automatically convey the semantic that an instance of the specialized PrimitiveType is the value itself.

    NB: To do this in Enterprise Architect recreate the PrimitiveType abstract definition as an instance of the 'Primitive' element found in the 'Class' toolbox.
  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Remove the value members
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Introduce the notional value "null" that may be used in a content-filter expression

  • Key: DDSXTY_-19
  • Legacy Issue Number: 16720
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification introduces the concept of optional members into DDS data types. However, it does not address how comparisons of these members should work in content-filtering expressions. For example, if a content-filtered topic indicates that all samples are of interest where "x != 5", but x is not present in the sample at all, does the sample pass the filter or not?

    Proposed resolution: Introduce the notional value "null" that may be used in a content-filter expression. The null value is not equal to any value in the domain of any data type. (That is, x != null for any non-null value of x.) A member's value in a given sample shall be considered to be equal to null if that member is not present in the given sample. Its value shall not be considered equal to null if it is present.
  • Reported: DDS-XTypes 1.0b2 — Mon, 21 Nov 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Optional members:
    Introduce the notional value “null” that may be used in a content-filter expression. The null value is not equal to any value in the domain of any data type. (That is, x != null for any non-null value of x.)
    • An optional member’s value in a given sample shall be considered to be equal to null if that member is not present in the given sample.
    • Its value shall not be considered equal to null if it is present.
    • A non-optional member’s value shall never be considered equal to null.
    Maps:
    Use the same syntax as arrays and sequences, but instead of a numeric index, use the stringified representation of the key to be queried as a string literal. Such an expression evaluates to the “value” element of the map that is associated with the given key. For example:
    my_map['foo'] = 'bar'
    my_map['5'] = 'baz'
    Bit sets:
    Use the same syntax as arrays and sequences, but instead of a numeric index, use the enumerated constant identifying the desired bit. Such an expression evaluates to a Boolean value: true if the named bit is set or false if it is not. For example:
    my_bitset['MY_BIT_CONSTANT']
    Specify the above rules in a new section 7.6.5, “DCPS Queries and Filters”. Include the relevant updates to the DCPS Queries and Filters grammar (from Annex A in the DDS 1.2 specification).
    In addition, include a description of the following things that should be described in DDS already but seem to be missing:
    • The use square bracket syntax for arrays, strings, and sequences
    • Boolean literals
    An issue should be filed against DDS for this, but the resolution of this issue should not wait for it to be acted upon.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Invalid data types applied to AnnotationDescriptor::value, DynamicData::descriptor, DynamicData::value

  • Key: DDSXTY_-23
  • Legacy Issue Number: 17022
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The above-mentioned attributes (Figures 28 and 37) have types defined in the form "xxx --> yyy" which has no meaning in UML. Please clarify and correct.
  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Change the type of AnnotationDescriptor::value to Map<String, String>.
    Unify the property DynamicData::descriptor with the existing association to MemberDescriptor, and qualify this association by MemberId.
    Change the property DynamicData::value to an association to Type, and qualify this association by MemberId.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Conflicting data types applied to several Attributes, Operations and Parameters in UML notation

  • Key: DDSXTY_-22
  • Legacy Issue Number: 17021
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The following figures exhibit inconsistent application of data types to attributes, operations and parameters:
    Figure 4
    Figure 9
    Figure 10
    Figure 13
    Figure 14
    Figure 16
    Figure 26
    Figure 30
    Figure 33
    Figure 36
    Figure 37
    Figure 38
    Figure 39

    Certain attributes/parameters have 'int' or 'string' applied which conflict the data types defined within the aforementioned model, and the PrimitiveTypes defined in UML. What is the intent with these? Which set of primitive data types are intended for application here (IDL? Java, C++, UML, XTypes?)

    For example, the 'Enumeration' class in Figure 10 defines a 'bit-bound' property of type int.

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Use DDS-XTypes types consistently. Note that Figures 9 and 16 are already correct—they use the DDS-XTypes-derived basic types, not the UML-built-in ones.
    Note that if the resolution to issue #16561 is accepted, the modification to figure 38 will be irrelevant, because the corresponding section of the document will be removed.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Non-standard UML notation on figures

  • Key: DDSXTY_-21
  • Legacy Issue Number: 17020
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The following figures exhibit non-standard notation for specialized elements:
    Figure 4
    Figure 9
    Figure 11
    Figure 14
    Figure 16
    Figure 17
    Figure 20

    The textual notation showing generalized elements on specialized ones needs to either be hidden, or have the generalized element explicitly shown on the diagram (with generalization relationship between the elements showing).

    NB: To hide the generalized element names on specialized ones in Enterprise Architect, double-click on a blank area of the diagram to open the Diagram Properties Dialog. On the "Diagram" tab deselect the "Show additional Parents" option.
  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Figures 4, 6–9, 12, 13, 15, 16, 17, 20, and 38: Simply hide the additional parents, as described above. Note that if the resolution to issue #16561 is accepted, the modification to figure 38 will be irrelevant, because the corresponding section of the document will be removed.
    Figures 10, 11, and 14: Add class “Namespace” to the diagram.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Truncation of text in Figure 3

  • Key: DDSXTY_-20
  • Legacy Issue Number: 17019
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The first rectangular symbol in Figure 3 contains truncated text - Type Representation
  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Fix the truncated text
  • Updated: Fri, 6 Mar 2015 21:48 GMT

New DDS-XTypes issue: inability to consume data using new base class

  • Key: DDSXTY_-18
  • Legacy Issue Number: 16561
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    have a new issue to file against the DDS-XTypes spec that was pointed out to me by Reinier Torenbeek.

    Declared compatibility of types (i.e. type signature) includes base types but not derived types. Unfortunately, that means that a consumer using a base class unknown to an existing producer will not be able to consume data from that producer, because neither party will declare the relationship between the types.

    For example: I publish Dog, which extends Animal. In version 2, a new intermediate class Mammal is introduced. However, a new consumer of Mammal won't match with a legacy producer of Dog, because both the Dog and Mammal endpoints declare that their types extend Animal, and neither one asserts that Dog should now extend Mammal.

    Proposed Resolution:

    Remove the type signature concept and go back to registering simple names. In its place, introduce a new QoS policy that lists assertions about which types extend which others. Consider making these assertions transitive. As today, the operative set of assertions when matching producers and consumers should be the union between the producer's and the consumer's sets.
  • Reported: DDS-XTypes 1.0b2 — Tue, 20 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Remove the type signature concept and go back to registering simple names
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Object assignability rules should be more resilient

  • Key: DDSXTY_-17
  • Legacy Issue Number: 16368
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    Source:

    RTI (Mr. Alejandro de Campos, alejandro@rti.com)

    Summary:

    A small object-level assignability problem within a complex sample can result in an entire sample being discarded. For example, a string whose length is greater than the bound of a string it’s being assigned into must be discarded. A sequence with an unassignable member must be discarded. A structure with an unassignable member must be discarded. As a result, a small issue deep within a structure could cause a whole sample to be discarded. For example, an issue within a TypeObject could result in an entire built-in topic data sample being discarded and consequently a loss of discovery information.

    Discussion:

    If we attempt to prevent any possible semantic problem that could arise from partial samples, we will have to keep the existing draconian rules, which can have bigger impacts, as described above. Therefore, the rules should seek to be more lenient and allow type-aware code “above” the assignability algorithm to detect semantic problems.

    Proposed Resolution:

    The following are the cases identified in the specification in which individual objects may be unassignable:

    · Strings that are too long: No change. Strings are a basic type, and truncation can generally not be easily detected by applications.

    · Arrays with unassignable elements: No change. In CDR, arrays have no length or other means of delimiting elements, so it is not possible to “truncate” them.

    · Sequences that are too long or contain unassignable elements: Discard only the offending elements, “left-shifting” subsequent elements and reducing the length as necessary.

    · Maps that are too long or contain unassignable elements: No change. Map entries are not logically ordered, so elements may not be discarded in a stable fashion.

    · Enumeration with unrecognized value: No change.

    · Union whose discriminator does not select a value in the destination type: No change—otherwise, the union would be malformed.

    · Structure with a “must understand” member not present in the destination type: No change—otherwise, the union would be malformed.

    Add the following new rules:

    · Structure with an unassignable non-optional member: The entire structure is considered unassignable. (This behavior was previously underspecified.)

    · Structure with an unassignable option member: The member takes no value. The rest of the structure can theoretically be retained.
  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    The following are the cases identified in the specification in which individual objects may be unassignable along with the changes to be made, if any:
    • Strings that are too long: If the bound of a string increases, the string is unassignable. Strings are a basic type, and truncation can generally not be easily detected by applications.
    • Arrays with unassignable elements: No change. In CDR, arrays have no length or other means of delimiting elements, so it is not possible to “truncate” them.
    • Sequences that are too long or contain unassignable elements: If the bound of a sequence increases, or an element is unassignable, the whole sequence is unassignable. Applications have little ability to detect or mitigate sequence truncation, so automatic truncation is undesirable.
    • Maps that are too long or contain unassignable elements: If the bound of a map increases, or an element is unassignable, the whole map is unassignable. Applications have little ability to detect or mitigate map truncation, so automatic truncation is undesirable.
    • Enumeration with unrecognized value: No change.
    • Union whose discriminator does not select a value in the destination type: No change—otherwise, the union would be malformed.
    • Structure with a “must understand” member not present in the destination type: No change—otherwise, the structure would be malformed.
    Add the following new rules for structures, which cover behavior that was previously underspecified:
    • An unassignable non-optional member: The entire structure is considered unassignable.
    • An unassignable optional member: The member takes no value. The rest of the structure can be retained.
    • Mismatched “optional” attribute in a final or extensible structure: The types are not assignable. This restriction is necessary because of the header that precedes such members.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Definition of “strongly assignable” is incomplete

  • Key: DDSXTY_-16
  • Legacy Issue Number: 16367
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The definition of the term “strongly assignable” in section 7.2.4, Type Compatibility: “is-assignable-from” relationship, states:

    If types T1 and T2 are both mutable and T1 is-assignable-from T2, then T1 is said to be “strongly” assignable from T2.

    The purpose of this concept is to distinguish cases where it is possible to delimit adjacent objects. This is necessary, for example, when deserializing arrays, to avoid a situation where extra members in an array element could throw off the deserialization of subsequent elements.

    This definition is overly restrictive and can even prevent arrays of non-mutable elements from being assignable to themselves.

    Proposed Resolution:

    Amend the definition to consider any type strongly assignable to itself.

    Proposed Revised Text:

    The definition of the term “strongly assignable” in section 7.2.4, Type Compatibility: “is-assignable-from” relationship, states:

    If types T1 and T2 are both mutable and T1 is-assignable-from T2, then T1 is said to be “strongly” assignable from T2.

    Append the following sentence:

    Any type is also considered (trivially) strongly assignable from itself, regardless of its extensibility kind.
  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Amend the definition of “strongly assignable” to consider any type strongly assignable to itself
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Incorrect default extensibility kind value in XSD file

  • Key: DDSXTY_-12
  • Legacy Issue Number: 16271
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    OMG Issue No: ?????

    Title: Incorrect default extensibility kind value in XSD file

    Source:

    RTI (Mr. Alejandro de Campos, alejandro@rti.com)

    Summary:

    The declaration of the complex type structOrUnionTypeDecl in the XSD file contains the following attribute declaration:

    <xs:attribute name="extensibility"

    type="extensibilityKind"

    use="optional"

    default="false"/>

    However, “false” is not a valid value for the extensibilityKind type.

    Proposed Resolution:

    Change the default value to “extensible”.

    Proposed Revised Text:

    Replace the following attribute declaration within the complex type structOrUnionTypeDecl:

    <xs:attribute name="extensibility"

    type="extensibilityKind"

    use="optional"

    default="false"/>

    …with this one:

    <xs:attribute name="extensibility"

    type="extensibilityKind"

    use="optional"

    default="extensible"/>
  • Reported: DDS-XTypes 1.0b2 — Mon, 23 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Change the default value to “extensible”.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Incorrect union assignability rules

  • Key: DDSXTY_-15
  • Legacy Issue Number: 16366
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The type assignability rules for unions have a number of problems (see the UNION_TYPE row of the table in section 7.2.4.5, Aggregation Types):

    · The second and third bullets in the list of rules are redundant.

    · According to the fourth bullet (assignability of default members), a union with a default label may not even be assignable to itself.

    · The rules do not account for member IDs and names, which can be significant when deserializing objects in some data representations.

    · The rules do not account for the fact that the discriminator may or may not be a key.

    · The rules do not account for extensibility kind.

    · The rules are under-specified with respect to malformed samples. Specifically, the discriminator may select a particular member X of the union, but the implementation may discover in its place a different member Y. (This situation will be detectable only with certain data representations.)

    Proposed Resolution:

    Apply the followin rules:

    · Apply the member ID, name, and type matching rules for structures to unions as well.

    · Every discriminator value in T2 must select the “same” member in T1—or no member at all. This can be checked in three steps:

    1. Every discriminator value in a non-default label of T2 selects the same member in T1 or none at all.

    2. Every discriminator value in a non-default label of T1 selects the same member in T2 or none at all.

    3. If both T1 and T2 have a default label, the corresponding members must be assignable.

    · Either both types must have a key or neither.

    · The extensibility kinds must match.

    · Specify explicitly that an object of a union with a mismatch between its discriminator and non-discriminator members is considered malformed. The impact is unspecified, although implementations may consider the object unassignable.

    Proposed Revised Text:

    Replace the center column of the UNION_TYPE row of the table in section 7.2.4.5, Aggregation Types, with the following:

    UNION_TYPE if and only if it is possible to unambiguously identify the appropriate T1 member based on the T2 discriminator value and to transform both the discriminator and the other member correctly. Specifically:

    · T1.discriminator.id == T2.discriminator.id and T1.discriminator.type is-assignable-from T2.discriminator.type.

    · Either the discriminators of both T1 and T2 are keys or neither are keys.

    · Any members in T1 and T2 that have the same name also have the same ID and any members with the same ID also have the same name.

    · For each member “m1” in T1, if there is a member m2 in T2 with the same member ID then m1.type is-assignable-from m2.type.

    · T1.extensibility == T2.extensibility.

    · A discriminator value appearing in a non-default label of T2 selects a member m2. If the same discriminator value selects a member m1 of T1, then m1.id == m2.id.

    · A discriminator value appearing in a non-default label of T1 selects a member m1. If the same discriminator value selects a member m2 of T2, then m1.id == m2.id.

    · If both T1 and T2 have a default label, then the IDs of the members selected by those labels must be equal.

    AND if T1 is final, the number of members in T1 is equal to the number of members in T2.

    Remove the footnote that is linked to the old contents of that table cell.

    Append the following paragraphs to the right-hand column of the same table row:

    If either member of the union is unassignable, then the T2 object is unassignable to T1.

    If the discriminator value of a union object and its non-discriminator member do not agree with one another, the object is considered malformed. In such a case, the behavior is unspecified. In particular, the implementation may or may not be able to detect this error. If it can, it should consider the object unassignable.
  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Apply the following rules:
    • Apply the member ID, name, and type matching rules for structures to unions as well.
    • Every discriminator value in T2 must select the “same” member in T1—or no member at all. This can be checked in three steps:
    1. Every discriminator value in a non-default label of T2 selects the same member in T1 or none at all.
    2. Every discriminator value in a non-default label of T1 selects the same member in T2 or none at all.
    3. If both T1 and T2 have a default label, the corresponding members must be assignable.
    • Either both types must have a key or neither.
    • The extensibility kinds must match.
    • Specify explicitly that an object of a union with a mismatch between its discriminator and non-discriminator members is considered malformed. If an implementation is able to detect this case, it shall consider the object unassignable. If not, then the impact is unspecified.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Inconsistent bit set/integer equivalency

  • Key: DDSXTY_-14
  • Legacy Issue Number: 16365
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    A bit set with bit bound <= 8 is mapped to a byte in some places (page 78 and 40) and to an unsigned short in others (page 88). (Page numbers refer to beta 2.)

    Proposed Resolution:

    A bit set with bit bound <= 8 should be serialized as a single byte.

    Proposed Revised Text:

    In the table in section 7.5.1.2.2, BitSet Types, replace these rows:

    Bit Set Bound
    Unsigned Integer Equivalent

    1–16
    unsigned short

    …with the following:

    Bit Set Bound
    Primitive Equivalent

    1–8
    octet

    9–16
    unsigned short
  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    A bit set with bit bound <= 8 should be serialized as a single byte.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Ambiguous description of serializing discovery types

  • Key: DDSXTY_-13
  • Legacy Issue Number: 16364
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The definition of PID_LIST_END in Table 27 in section 7.4.1.2.1, Interpretation of Parameter ID Values, reads:

    RTPS specifies that the PID value 1 shall be used to terminate parameter lists within the DDS built-in topic data types. Rather than reserving this parameter ID for all types, thereby complicating the member ID-to-parameter ID mapping rules for all producers and consumers of this Data Representation, Simple Discovery types only shall be subject to a special case: member ID 1 shall not be used, and either parameter ID 0x3F02 or parameter ID 1 shall terminate the parameter list.

    The meaning of “Simple Discovery types” is not clear. It should not apply to all mutable types that might ever be used as part of the Simple Discovery process. It is intended only to maintain backward compatibility with types defined in DDS-RTPS.

    Proposed Resolution:

    See the Proposed Revised Text below.

    Proposed Revised Text:

    Append an additional sentence: “These types consist of the built-in topic data types, and those other types that contain them as members, as defined by [RTPS].”
  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    See the Revised Text below
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Difficult to apply automation to statically defined types

  • Key: DDSXTY_-9
  • Legacy Issue Number: 16241
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Application code (i.e. business logic) generally depends statically on particular types and their members. Therefore, it is appropriate to define these types statically (e.g. in IDL) and generate code for them in order to take advantage of static type safety and improved performance.

    In contrast, infrastructure code (i.e. logic that is independent of particular applications) generally must not depend on application-specific types, because such dependencies prevent that code from being reused.

    These two kinds of code can exist within a single component. For example:

    · The properties of application-specific types might be checked against a common set of rules to ensure that they meet organizational or program-specific guidelines.

    · Certain design patterns may call for arbitrary application-specific types to be augmented in uniform ways.

    · Type-specific application activities, such as reading and/or writing data, might be logged or recorded.

    The straightforward way to handle these scenarios would be to:

    1. Convert a generated type definition into a DynamicType object.

    2. Convert an object of a generated type into a DynamicData object.

    3. Pass these two dynamic objects to the infrastructure code and allow it to operate on them.

    Unfortunately, the specification does not provide such a capability. Instead, applications have to manually construct DynamicType and DynamicData objects member by member. This code is not only verbose but also brittle, because if the static type definition changes (e.g. during development or across versions), it can grow out of sync with the hand-written code that manipulates that definition.

    Discussion:

    We need three new conversions:

    1. TypeSupport à DynamicType

    2. DynamicData à sample object

    3. Sample object à DynamicData

    These operations could either be added to the TypeSupport interface or to a “type builder” interface. The former approach is preferred, because the generic type parameter of the TypeSupport in the C++ and Java PSMs allows a degree of type safety that way.

    Proposed Resolution:

    Introduce three new TypeSupport operations:

    1. get_type: Get a DynamicType object corresponding to the TypeSupport’s data type.

    2. create_sample: Create a sample of the TypeSupport’s data type from an input DynamicData object. If the DynamicType of the DynamicData is not compatible with the TypeSupport’s data type, raise an error.

    3. create_dynamic_sample: Create a DynamicData object from an input sample of the TypeSupport’s data type.

    Proposed Revised Text:

    TO DO
  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Introduce three new TypeSupport operations:
    1. get_type: Get a DynamicType object corresponding to the TypeSupport’s data type.
    2. create_sample: Create a sample of the TypeSupport’s data type from an input DynamicData object.
    3. create_dynamic_sample: Create a DynamicData object from an input sample of the TypeSupport’s data type.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Changing a DynamicType object is ambiguous

  • Key: DDSXTY_-8
  • Legacy Issue Number: 16240
  • Status: closed  
  • Source: Brookhaven National Laboratory ( Nikolay Malitsky)
  • Summary:

    The current DynamicType API allows a type definition to be changed. Such a change can be ambiguous at best and dangerous at worst.

    · Suppose that the type already types (DynamicData) objects. Should all of those objects refer to the old version of the type or the new version? If the new version, how shall we address the situation where the new type is inconsistent with the existing data contents?

    · Suppose that the type has already been registered with some domain participant. Does the registered type name refer to the old version of the type or the new version? What shall be done about samples that may already have been published or received using the old version?

    · Can DynamicTypeFactory cache and reuse identical types that are requested more than once? Ideally yes, but the ability to change a type makes the state management necessary to support this behavior very complicated.

    It would be safer, clearer, and more efficient if DynamicType objects were immutable once created. That implies that either the factory must take sufficient inputs to fully create a type in one step, or we must employ a builder or similar pattern.

    Discussion:

    A builder pattern would give the application more flexibility in how to create new types. It would also nicely encompass the current load_type operations as well as hypothetical PSM-specific operations, such the creation of a DynamicType from a Java Class object.

    Proposed Resolution:

    TO DO

    Proposed Revised Text:

    TO DO
  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Define a new class DynamicTypeBuilder as a copy of the current definition of DynamicType. Remove from DynamicType all operations that modify an object, and add to DynamicTypeBuilder an operation build that returns a corresponding (immutable) DynamicType.
    Update the existing DynamicTypeFactory to create instances of DynamicTypeBuilder instead of DynamicType. Rename this class DynamicTypeBuilderFactory accordingly.
    Replace the existing operation DynamicType::clone with a corresponding create operation in DynamicTypeBuilderFactory.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Optional, must_understand members of non-mutable aggregation types cannot be accurately represented in CDR

  • Key: DDSXTY_-11
  • Legacy Issue Number: 16243
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Members of a structure or union type have a small number of metadata attributes, among them:

    · optional: indicates that the member may or may not take a value in a particular sample

    · must_understand: indicates that a consumer of the data must discard the sample if it encounters such a field in it

    The type-level assignability rules detect mismatches respecting non-optional must_understand members. (Such members will always take a value, and therefore there is no possibility of data exchange between the producer and consumer.) However, must_understand members that are optional must be detected on a sample-by-sample basis: any sample that does not contain the offending member can be exchanged, but those that do cannot.

    The XML Data Representation allows the encoding of the must_understand attribute within each sample, as does the parameterized encapsulation variants of the Extended CDR Data Representation. However, the traditional, non-parameterized encapsulation variants—used by final and extensible structures and unions—do not permit this attribute to be expressed. As a result, consumers will not be able to detect when it should have been present, and may therefore present incorrect data to applications.

    Discussion:

    The traditional CDR encapsulations prefix each optional member with a 32-bit “header” that indicates the presence and size of the member. In contrast, the parameterized CDR encapsulations prefix each member with a 32-bit parameter header that indicates the presence, size, ID, and metadata flags of the member, including must_understand. Therefore, we can reuse the parameter header structure we already have to solve this problem, instead of using just a 32-bit size, with no increase in overhead.

    Proposed Resolution:

    Reorganize the Extended CDR Data Representation section such that it first defines the parameter header structure and the member-ID-to-parameter-ID mapping. Second it shall define the traditional encapsulation variants, and finally it shall define the (fully) parameterized encapsulation variants.

    Within the middle section—traditional CDR—update section 7.4.1.1.5.2, “Optional Members.” Remove the description of a 32-bit size, and in its place describe the use of a parameter header. Note that either the four-byte header defined by DDS-RTPS or the 12-byte extended header defined by DDS-XTypes may be used.

    Proposed Revised Text:

    TO DO
  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Update section 7.4.1.1.5.2, “Optional Members.” Instead of preceding each optional member with a 32-bit size, use a parameter header. Note that either the four-byte header defined by DDS-RTPS or the 12-byte extended header defined by DDS-XTypes may be used.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

New QoS policies don’t indicate whether they can be changed

  • Key: DDSXTY_-10
  • Legacy Issue Number: 16242
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Source:

    RTI (Mr. Alejandro de Campos, alejandro@rti.com)

    Summary:

    Each DDS QoS policy must define a couple of attributes: whether or not the policy has request-offer (RxO) semantics and whether or not it can be changed after an entity is enabled. The two new QoS policies defined by DDS-XTypes—TypeConsistencyEnforcementQosPolicy and DataRepresentationQosPolicy—define the first part but not the second.

    Discussion:

    Because of their potential interactions with historical data, neither of these policies should be changeable after an entity is enabled.

    Proposed Resolution:

    State in the introduction to each policy that its value cannot be changed after an entity is enabled.

    Proposed Revised Text:

    TO DO
  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    State in the introduction to each policy that its value cannot be changed after an entity is enabled
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Typographical errors

  • Key: DDSXTY_-7
  • Legacy Issue Number: 16239
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification contains the following identified typographical errors:

    · The third bullet in section 2.2, “Network Interoperability Conformance”, which begins with “Data Representation…”, is lacking an opening parenthesis at the start of the second sentence. The closing parenthesis is already present.

    Proposed Resolution:

    See the trivial corrections described above.

    Proposed Revised Text:

    See the trivial corrections described above
  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    See the trivial corrections described above
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Type signature fields in built-in topic data shouldn't use unbounded strings

  • Key: DDSXTY_-6
  • Legacy Issue Number: 16238
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The type_name members of TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData are bounded at 256 characters. The equivalent_type_name and base_type_name members store sequences of type names, but the strings in those sequences are unbounded. The flexibility to store strings of any length is unnecessary, because no string can appear there that doesn’t also appear in a type_name somewhere, and is therefore of 256 characters or less.

    This issue is minor in that it does not impact correctness. However, it does impact clarity to a small extent and can impact the efficiency of some implementations.

    Proposed Resolution:

    Define a typedef “TypeName”, a string bounded at 256 characters. (See also issue #15969.)

    Define a typedef “TypeNameSeq”, an unbounded sequence of TypeName elements.

    Change the type of the equivalent_type_name and base_type_name members from StringSeq to TypeNameSeq.

    Proposed Revised Text:

    TO DO
  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    This issue is obsolete in the face of issue #16561: the resolution of that issue eliminates the type signature concept altogether. Therefore, this issue should be merged with that one.
    Disposition: Merged with issue #16561
  • Updated: Fri, 6 Mar 2015 21:48 GMT

No way to get or set length of collection-typed DynamicData objects

  • Key: DDSXTY_-5
  • Legacy Issue Number: 16237
  • Status: closed  
  • Source: Brookhaven National Laboratory ( Nikolay Malitsky)
  • Summary:

    A DynamicData object may encapsulate the state of an object of a collection type—a sequence, array, string, or map. In such a case, it is necessary to be able to get and set the length of the collection.

    Discussion:

    We need to add an accessor for the current length. This accessor can also be useful for other object of other types; for example, it can return the number of members in a structure.

    However, it is not appropriate to add a mutator for the length directly:

    · If the length of a collection is increased, that implies the addition of new elements. But the values of these new elements will not be meaningful.

    · If the length of a collection is decreased, that implies the removal of existing elements. But that may not be meaningful (what does it mean to remove a non-optional member of a structure?) of useful (why would you want to clear the fifth element of a bit set just because of what its index is?).

    · The lengths of some types cannot legally be changed at all—for example, array types.

    Therefore, it is better to allow elements to be added and removed, where appropriate, and thereby modify the length implicitly.

    Proposed Resolution:

    Add an operation get_length to the DynamicData class.

    · If the object is of a collection type, return the number of elements currently in the collection. In the case of an array type, this value will always be equal to the bound.

    · If the object is of a bit set type, return the number of named flags that are currently set in the bit set.

    · If the object is of a structure or annotation type, return the number of members in the object. This value may be different than the number of members in the corresponding DynamicType—for example, some optional members may be omitted; see the existing DynamicData documentation.

    · If the object is of a union type, return the number of members in the object. This value will always be two: the discriminator and the current member corresponding to it.

    · If the object is of a primitive or enumeration type, it is atomic: return one.

    · If the object is of an alias type, return the value appropriate for the alias’s base type.

    Expand the contracts of the existing set_<type>_value operations to allow them to append new elements to resizable collections—strings, sequences, and maps. (This behavior is aligned with the existing contract of the clear operations, which states that cleared elements of resizable collections shall be removed.) Obtain the member ID associated with the new value as follows:

    · For a string or sequence type, use get_member_id_at_index to obtain an ID for the index one greater than the current length.

    · For a map type, use get_member_id_by_name to obtain an ID for the new map key.

    Proposed Revised Text:

    TO DO
  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Add an operation get_item_count to the DynamicData class.
    • If the object is of a collection type, return the number of elements currently in the collection. In the case of an array type, this value will always be equal to the product of the bounds of all array dimensions.
    • If the object is of a bit set type, return the number of named flags that are currently set in the bit set.
    • If the object is of a structure or annotation type, return the number of members in the object. This value may be different than the number of members in the corresponding DynamicType—for example, some optional members may be omitted; see the existing DynamicData documentation.
    • If the object is of a union type, return the number of members in the object. This value will always be two: the discriminator and the current member corresponding to it.
    • If the object is of a primitive or enumeration type, it is atomic: return one.
    • If the object is of an alias type, return the value appropriate for the alias’s base type.
    Expand the contracts of the existing set_<type>_value operations to allow them to append new elements to resizable collections—strings, sequences, and maps. (This behavior is aligned with the existing contract of the clear operations, which states that cleared elements of resizable collections shall be removed.) Obtain the member ID associated with the new value as follows:
    • For a string or sequence type, use get_member_id_at_index to obtain an ID for the index one greater than the current length.
    • For a map type, use get_member_id_by_name to obtain an ID for the new map key.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Annex D (“DDS Built-in Topic Data Types”) is out of sync with IDL file

  • Key: DDSXTY_-4
  • Legacy Issue Number: 16236
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The equivalent_type_name and base_type_name fields from TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData are described in the prose of the specification and are reflected in the IDL file. However, they missing from the annex; they need to be added.
  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    • Replace all literal-formatted text in Annex A (beginning with “<?xml…”) with the contents of the XSD file accompanying the specification.
    • Replace all literal-formatted text in Annex B (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
    • Replace all literal-formatted text in Annex C (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
    • Replace all literal-formatted text in Annex D (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
    • Replace all literal-formatted text in Annex E (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
    • Replace all literal-formatted text in Annex F (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

C++ mapping MAP type needs member access semantics specification

  • Key: DDSXTY_-3
  • Legacy Issue Number: 15981
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    The C++ mapping for the new MAP type needs a precise specification of member (or key) access semantics and memory management rules like the CORBA C++ mapping describes for the SEQUENCE type on pages 36-42 (par. 4.15) of the C++ language mapping, version 1.2, formal/2008-01-09.

  • Reported: DDS-XTypes 1.0b2 — Mon, 24 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Close this issue without making any change.
    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Restrictions on MAP key element type not (clearly) documented/specified

  • Key: DDSXTY_-2
  • Legacy Issue Number: 15976
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    Allthough the specification of the MAP_TYPE in paragraph 7.2.2.3.4 refers to restrictions for key element type this is not formalized in either the specification for the IDL representation for maps or the C++ language mapping.

    It should be clearly noted (for the IDL representation in bnf) that the key element type is restricted to integer and string types only.

    The current IDL representation specs for map leave all options open for defining the key element type.
    Although the specs in paragraph 7.2.2.3.4 describe the use of other element types as 'behaviour undefined' this is not clear enough as the chosen C++ representation simply will not work when f.i STRUCT or UNION types are chosen as key element type.

  • Reported: DDS-XTypes 1.0b2 — Fri, 21 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    In section 7.2.2.3.4, provide a rationale for the restriction on key types.
    In the section on the Plain Language Binding for map types (7.5.1.3), clarify that the use of an unsupported key element type shall result in a compilation error. Further indicate that in C++ (section 7.5.1.3.1), the Compare function implementation shall consider the character contents of strings; it shall not compare pointer values.
  • Updated: Fri, 6 Mar 2015 21:48 GMT

Anonymous types should not be used in IDL examples and the TypeObject representation IDL

  • Key: DDSXTY_-1
  • Legacy Issue Number: 15969
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    IDL Anonymous type declarations should not be used in IDL examples and the 'dds_xtypes.idl' file as this form of type declaration has been deprecated by the latest CORBA specs and will cause compatibility problems with modern CORBA IDL compilers.

  • Reported: DDS-XTypes 1.0b2 — Tue, 18 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    • In the definitions of GroupDataQosPolicy, TopicDataQosPolicy, and UserDataQosPolicy, replace sequence<octet> with ByteSeq. This change removes occurrences of an anonymous type inherited from DDS itself.
    • In the definitions of TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData, replace the type of the name, topic_name, and type_name fields (string<256>) with the existing typedef ObjectName. This change removes occurrences of an anonymous type inherited from DDS itself.
    • In the definitions of Bytes and KeyedBytes, replace sequence<octet> with ByteSeq.
    • Introduce two typedefs: “VerbatimLanguage” and “VerbatimPlacement”, the first a string bounded at 32 characters and the second at 128 characters. Change the type of the member Verbatim::language to VerbatimLanguage and the type of Verbatim::placement to VerbatimPlacement.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

ref-1054: Bad which_added operations in IDL

  • Key: DDS-170
  • Legacy Issue Number: 7134
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The "which_added" operations on the collections were designed in the PIM so
    that it is possible not to compute any result when the content of the
    collection had been totally changed. This is not present in the IDL. *** Proposal [THALES]
    change the operation to get a boolean result (true => the information is
    returned in the out parameter; false => no information) instead of sending
    the information as the result.

        • Concrete changes
          IDL
          abstract valuetype ListBase : CollectionBase {
          boolean which_added (out LongSeq indexes);
          [instead of LongSeq which_added ();]
          ...
          abstract valuetype StrMapBase : CollectionBase {
          boolean which_added (out StringSeq keys);
          [instead of StrinSeq which_added ();]
          ...
          abstract valuetype IntMapBase : CollectionBase {
          boolean which_added (out LongSeq keys);
          [instead of LongSeq which_added ();]
  • Reported: DDS 1.0b1 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 21:40 GMT

Changing the IDL module

  • Key: DDS-172
  • Legacy Issue Number: 7169
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    The module names in the IDL are very terse and not prefixed. In
    this form they pose a high risk of a name collision with any other,
    even user-written, IDL module. I would suggest to prefix the module
    names as explained in the IDL Style Guide (ab/98-06-03). The "Cos"
    prefix would be adequate. This means to change for example
    "module DDS" to "module CosDDS", or even to a more intuitive
    "module CosDataDistributionService" for the benefit of the user.
    I think non of today's systems has a severe name limitation
    anymore.

    Further email narrowed the proposal to "CosDDS".

    Proposed action: No Change

    Both RTI and THALES feel that the change significantly affect users that
    have started developing applications using the API. Our companies have
    invested significantly in the API and a change this late would make us
    lose a lot of credibility and may really upset some customers. In the
    case of RTI this includes documentation that has been in-use by
    customers over the last 6 months.

    In our respective markets there is a lot of people using C and C++ with
    compilers that don't support name-spaces so this change affects a very
    visible part of the API, namely the prefix of every function. The change
    may appear small but it may actually have big impact if we consider
    user-acceptance.

    Furthermore, the use of the "Cos" prefix may be misleading as the
    Data-Distribution Service was designed so it would be implementable
    without an object service.
  • Reported: DDS 1.0b1 — Tue, 30 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    closed no change
  • Updated: Fri, 6 Mar 2015 21:40 GMT

ref-1053 Missing is_composition

  • Key: DDS-171
  • Legacy Issue Number: 7136
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The is_composition operation is described in the PIM, but is not in the IDL.
    It concerns the valuettype RefRelation, ListRelatrion, IntMapRelation, and
    StrMapRelation.

        • Proposal
          add the following operation
          boolean is_composition(); on those valuetypes
  • Reported: DDS 1.0b1 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 21:40 GMT

Missing operations on DomainParticipantFactory and need for helper values

  • Key: DDS-169
  • Legacy Issue Number: 7100
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The resolution of issue 6816 added operation to get and set default QoS on all the entity factories except for the DomainParticipantFactory. This was an omission as this factory also needs to provide these operation such that DomainParticipant entities can also be created using default QoS.
    The operation lookup_participant is defined in the PIM (section 2.1.2.2.2) and does not appear in the PSM
    Furthermore, it would be desirable to have some utility constants in the IDL that can be used to indicate to the factory that default QoS should be used to construct an entity. This avoids having to explicitly get the default QoS in the case the application does not want to change any of the defaults. Helper constants can also be added for the specific case of constructing DataReader and DataWriter entities when the application wishes to indicate that the QoS should be obtaining by modifying the default values with the ones defined by the Topic Qos
  • Reported: DDS 1.0b1 — Mon, 8 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 21:40 GMT

New definition for Selections

  • Key: DDS-168
  • Legacy Issue Number: 7067
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    As notification_scope has been removed from the ObjectHome (cf. issue ref-1049), it is necessary to pass the information whether the modification of objects inside a Selection should be appreciated only on the object basis, or on the object + its contained objects basis
    clarification is requested regarding when the SelectionListener is activated
    Proposal [THALES]
    add a parameter concerns_contained when the Selection is created and add this characteristic in the selection attributes
    add a paragraph to specify when the Selection Listener is activated
    in SelectionListener::on_object_out, the ObjectRoot may no more exist, therefore passing the ObjectReference is better
    Concrete changes
    in IDL
    local interface Selection

    { ... readonly attribute boolean concerns_contained; [addition] ... }

    ;
    local interface SelectionListener

    { ... [the following method is no more commented out for it will not be redefined in the derived implied IDL] void on_object_out ( in ObjectReference the_ref); [instead in ObjectRoot the_object] }

    ;
    in section 3.1.6.3.7 Selection
    in the table, attribute list, add the following entry (as third attribute)
    concerns_contained boolean
    in the following text, starting with "It has the following attributes:"
    add the following text at the end of the second bullet:
    "; it is given at Selection creation time(cf. ObjectHome::create_selection)"
    add a bullet in third position, with the following content:
    "a boolean concerns_contained that indicates whether the Selection considers the modification of one of its members based on its content only (FALSE) or based on it content or the content of its contained objects (TRUE); it is given at Selection creation time(cf. ObjectHome::create_selection);"
    add at the end of the section, the following paragraph:
    "The SelectionListener is activated when the composition of the Selection is modified or when one of its members is modified. A member can be considered as modified, either only when it is itself modified or when itself or one of its contained objects is modifie (depending on the value of concerns_contained). Modifications in the Selection are considered with respects to the state of the Selection last time it was examined, i.e.:
    add one bullet with the following text:
    " at each incoming updates processing if autro_refresh is TRUE;"
    add a second bullet with the following text:
    "at each explicit call to refresh, if auto-refresh is FALSE."
  • Reported: DDS 1.0b1 — Thu, 4 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 21:40 GMT

ref-171 Rename_Topic_USER_DATA_to_TOPIC_DATA

  • Key: DDS-167
  • Legacy Issue Number: 7066
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The resolution of issue 6833 added USER_DATA QoS to Topic.
    However this name overlaps with the USER_DATA on the DataWriter and DataReader and prevents an application from using both at the same time.

    **PROPOSAL**
    Rename USER_DATA on Topic to be TOPIC_DATA.
    This involves adding a TOPIC_DATA QoS that concerns Topic, DataReader and DataWriter
    Add topic_data as a field in the DCPSTopic, DCPSPublication and DCPSSubscription tables describing the built-in topics in section 2.1.5, page 2-90.
  • Reported: DDS 1.0b1 — Wed, 3 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 21:40 GMT

Ref-170 Missing_description_of_OWNERSHIP_STRENGH

  • Key: DDS-166
  • Legacy Issue Number: 7064
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.3 "Supported QoS" is missing a subsection that describes the OWNERSHIP_STRENGH QoS policy

    ***Proposal ***
    Add section 2.1.3.7 with the text:

    2.1.2.3.7 OWNERSHIP_STRENGH
    This QoS policy should be used in combination with the OWNERSHIP policy. It only applies to the situation case where OWNERSHIP kind is set to EXCLUSIVE.
    The value of the OWNERSHIP_STRENGTH is used to determine the ownership of a data-instance (identified by the key). The arbitration is performed by the DataReader. The rules used to perform the arbitration are described in Section 2.1.3.6.2 .
  • Reported: DDS 1.0b1 — Wed, 3 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 21:40 GMT

A Status is not an Event. An Event is not a Status, it notifies a status change

  • Key: DDSJAVA-32
  • Legacy Issue Number: 16541
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The org.omg.dds.core.status.Status class currently extends the java.util.EventObject.
    The issue I have with this is that a status and an event are to different concepts.
    A status represents a continuous value or set of values which are always defined,
    while an event represents and happening. For instance an event could be used to notify
    the change of status but not the status itself.

    [Resolution]
    That said the refactoring suggested is to re-organize the current status types
    so to clearly distinguish what is are statuses and what are the events. As such,
    all the status currently defined should remove reference to the source. Why?
    Because the statuses are retrieved from the source thus it is kind of silly to
    add back the source on the communication status.

    Let me give you an example ("dr" below is a DataReader):

    RequestedDeadlineMissedStatus s = dr.getRequestedDeadlineMissedStatus();

    // this give back the reader we already know, thus it is not real useful
    // information which should simply be removed.
    s.source())

    BTW the status types as well as the relative accessor methods should
    drop the trailing "Status" as it is not so informative.

    That said, we should add an event type associated to each status defined like this:

    class RequestedDeadlineMissedEvent

    { private RequestedDeadlineMissed status; private DataReader source; //... useful methods }

    The event type is the one that should be used as a parameter of the listener methods.

    Finally, it is worth noticing that the suggested refactoring will fix the
    DataAvailableStatus anomaly. This type currently defined as a status is actually
    an event and as such should be treated. So where is the anomaly, for this status
    there are no methods on the data reader and there is really no status information
    such as saying... Yes there are 15 new samples or something like this.
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    That said the refactoring suggested is to re-organize the current status types so to clearly distinguish what is are statuses and what are the events. As such, all the status currently defined should remove reference to the source. Why? Because the statuses are retrieved from the source thus it is kind of silly to add back the source on the communication status.
    Let me give you an example ("dr" below is a DataReader):
    RequestedDeadlineMissedStatus s = dr.getRequestedDeadlineMissedStatus();
    // this give back the reader we already know, thus it is not real useful
    // information which should simply be removed.
    s.source())
    BTW the status types as well as the relative accessor methods should drop the trailing "Status" as it is not so informative.
    That said, we should add an event type associated to each status defined like this:
    class RequestedDeadlineMissedEvent

    { private RequestedDeadlineMissed status; private DataReader source; //... useful methods }

    The event type is the one that should be used as a parameter of the listener methods.
    Finally, it is worth noticing that the suggested refactoring will fix the DataAvailableStatus anomaly. This type, currently defined as a status, is actually an event and as such should be treated. So where is the anomaly, for this status there are no methods on the data reader and there is really no status information such as saying... Yes there are 15 new samples or something like this.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DataReader API

  • Key: DDSJAVA-31
  • Legacy Issue Number: 16540
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The read API currently seems a bit too complicated. In some in some instances
    it provides part of the results as a return value and the rest by means of arguments.
    This does not feel right and again violates one of the key goal of having a new PSM: simplcity
    and usability.

    The API does not provide a way of deciding if one wants to read/take only valid
    data. This is a remark true in general for DDS which needs to be fixed for all PSM
    as well as for the PIM!

    The following methods on the DataReader interface are superfluous:

    • cast
    • createSample

    [Resolution]
    Refactor and cleanup the data-reader API.
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    This issue has three parts: removing unnecessary methods, reading only samples with valid data, and simplifying method overloads.
    • The cast() method is not superfluous; it is the only type-safe way to narrow a DataReader<?> to a DataReader<Foo>. This method can potentially use internal state of the reader to provide immediate run-time type safety. The only alternative is for the application code to use a type cast like this: “(DataReader<Foo>)”. But such a cast is meaningless because of type erasure and will generate a compiler warning. If there is a type mismatch, it will potentially not be caught until later.
    • Issue #16324 already eliminated the createSample method.
    • Reading or taking only valid data samples may or may not be semantically meaningful and should be addressed in the PIM first, so that the semantics can be defined. At that point, the method can be introduced into this PSM in an RTF.
    • Issue #16321 already proposes simplifying the read/take overloads. Since this is the only remaining part of this issue not addressed in the bullets above, this issue can be merged with that one.
    Resolution:
    Merge this issue with issue #16321.
    Disposition: Merged with issue #16321
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Statuses API shoud be improved and made typesafe

  • Key: DDSJAVA-34
  • Legacy Issue Number: 16543
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The dds-psm-java currently passes statuses via collections. However this
    does not make it neither efficient nor simple to represent collections
    of related statuses, such as the Read Status, etc.

    [Resolution]
    The suggestion is to add a ReadState as currently present on the dds-psm-cxx
    to simplify the API and make it simpler to support the most common use cases.
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    [Angelo] The suggestion is to add a ReadState as currently present on the DDS-PSM-Cxx to simplify the API and make it simpler to support the most common use cases.
    [Rick] This issue is unclear to me. I take it that this issue is not referring to actual Status objects. The reference to what is called “Read Status” or “Read State” and to DDS-PSM-Cxx makes me think it is related to the DDS-PSM-Cxx class called “ReaderState”, which encapsulates sets of Sample States, View States, and Instance States. This change is already proposed in DDS-PSM-Java as part of the proposed resolution to issue #16321.
    Resolution:
    Merge this issue with issue #16321.
    Disposition: Merge with issue #16321
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Avoid unncessary side-effects on the DataWriter API

  • Key: DDSJAVA-33
  • Legacy Issue Number: 16542
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The methods that access the communication statuses should simply return
    an object as opposed to also require it as an argument. As the Status
    is immutable there is no risk in the client code changing it, thus no copies
    required!

    [Resolution]
    Apply the changes suggested in the description above.
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    [Rick] This issue seems to apply only to writer status accessors. It is unclear to me why this issue is filed against the writer and not all other such status accessors.
    Resolution:
    Issue #16587 is a blanket issue about “bucket” accessors; this issue should be merged with that one.
    Disposition: Merge with issue #16587
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DomainEntity should be removed

  • Key: DDSJAVA-30
  • Legacy Issue Number: 16539
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    What is the value of having the DomainEntity class?

    [Resolution]
    The DomainEntity class should be removed and the getParent method should be migrated to the Entity class.
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Close this issue with no change. DomainEntity is a classifier directly from the DDS PIM. Its value is to capture the invariant that domain participants have no parent entity, and entities of all other types do. If this type is removed, and getParent is moved to Entity, this static invariant will become a run-time invariant (i.e. getParent will have to return null when the object is a participant), making application code less robust.
    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

API Should Avoid Side-Effects, e.g. Remove Bucket Accessors

  • Key: DDSJAVA-35
  • Legacy Issue Number: 16587
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Description
    ----------------
    The DDS-PSM-Java provides bucket accessors that allow to "return" an object
    by "filling" a method parameter.

    As an example, for a property Foo there would be a method:

    Foo f = // some foo
    x.getFoo(f)

    The rationale for this API is to avoid a defensive copy of Foo each time it is accessed.
    However the cost of this "optimization" is an API that has side-effects everywhere,
    with all the nasty implications of side-effects.

    Resolution
    ---------------
    The solution suggested to avoid bucket accessors and thus side-effects is to
    rely as much as possible on immutable objects (e.g. value-types). This ensures
    that (1) defensive copies are unnecessary since the attribute returned is immutable,
    and (2) new objects are created when new values are required.

    If properly designed (as shown on an issue posted on QoS and Policies) this approach
    not only leads to a simpler and safer API, but it also leads to actually save memory in most
    of the cases.

    The only case where the suggested approach has a cost is when a property changes
    very often. However, in many of these cases (often found in loops) the new JDK7
    escape analysis will help greatly help in dealing with the potential garbage as it
    will allocate these short-lived objects on the stack.
  • Reported: DDS-Java 1.0b1 — Tue, 11 Oct 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Proposed Resolution:
    The solution suggested to avoid bucket accessors and thus side-effects is to rely as much as possible on immutable objects (e.g. value-types). This ensures that (1) defensive copies are unnecessary since the attribute returned is immutable, and (2) new objects are created when new values are required.
    If properly designed (as shown on an issue posted on QoS and Policies) this approach not only leads to a simpler and safer API, but it also leads to actually save memory in most of the cases.
    The only case where the suggested approach has a cost is when a property changes very often. However, in many of these cases (often found in loops) the new JDK7 escape analysis will help greatly help in dealing with the potential garbage as it will allocate these short-lived objects on the stack.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Sample class should provide a method to check wether the data is valid

  • Key: DDSJAVA-36
  • Legacy Issue Number: 16588
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The Sample Class as defined in the Beta1 of the DDS-PSM-Java does not define
    a method "isValid(): Boolean" to check wether the data is actually valid. This is a simple
    to fix oversight.

    Resolution
    ---------------
    Add an "isValid () : Boolean" method to the Sample Class
  • Reported: DDS-Java 1.0b1 — Tue, 11 Oct 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    This issue is closed without any changes. The Sample class does provide a method to check whether the data is valid. There is no oversight. As described in section 7.6.2, “Sample Interface”:
    Each sample is represented by an instance of the org.omg.dds.sub.Sample interface. It provides its data via a getData method; if there is no valid data (corresponding to a false value for SampleInfo.valid_data in the IDL PSM), this operation returns null.
    The existing design is appropriate. The alternative—returning a non-null data object, and then making people check a flag that tells them not to use that object—would be extremely error-prone.
    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Misnamed Listener Helper

  • Key: DDSJAVA-37
  • Legacy Issue Number: 16589
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The name of the classes DataReaderAdapter/DataWriterAdapter are misleading since what
    they are really providing are listeners with some default behaviour.

    Resolution
    ---------------
    Rename the classes DataReaderAdapter/DataWriterAdapter to
    SimpleDataReaderListener and SimpleDataWriterListener.

    For the SimpleDataReaderListener one could implement trivially all
    the method but the one that notifies the availability of data,
    e.g. <onDataAvailable>
  • Reported: DDS-Java 1.0b1 — Tue, 11 Oct 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    This issue is closed without any changes. Providing no-op listener implementations, and replacing “Listener” with “Adapter” in the class name, is a common JDK idiom. You will see it throughput AWT and Swing, for example, which abound with listeners. The rationale for this pattern is described in section 7.2.7.2, “Listeners”.
    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ReaderState: the class name does not reflect the intent of the class

  • Key: DDSPSMCF2-2
  • Legacy Issue Number: 17064
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The class ReaderState encapsulate the Sample, Instance and View States and provides some useful predefined statuses.
    However the name of the class is relatively misleading as these statuses have nothing to do with the DataReader.
    These statuses are really used to "filter" the data on the reader cache based on its status. The name of the class should
    be replaced by something that better express its role.

    Resolution
    ---------------
    Rename the "ReaderState" class into "DataStatus".

  • Reported: DDS-PSM-Cxx 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0
  • Disposition Summary:

    Rename the "ReaderState" class into "DataStatus".
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Status API, e.g. sample_rejected_status, deadline_missed_status, etc., are missing from the DataReader

  • Key: DDSPSMCF2-1
  • Legacy Issue Number: 17048
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Description
    ---------------
    The Status API, e.g. sample_rejected_status, deadline_missed_status, etc., are missing from the DataReader.

    Resolution
    ---------------
    Simply add them.
  • Reported: DDS-PSM-Cxx 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0
  • Disposition Summary:

    The missing statuses methods have been added to the DataReader
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Useless ReaderQuery on DataReader read/take

  • Key: DDSPSMCF2-3
  • Legacy Issue Number: 17066
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The ReaderQuery class bundles together the read-state as well as potential read conditions. However the read-condition is not always present. This leads to code that needs to check all the time wether something is set or not, which is not only very elegant/efficient but it is also error prone

    Resolution
    ---------------
    Remove the ReaderQuery and let the read API deal, through proper operations overloads, with ReadState and potential ReadConditions. This way it will always be clear if a read/take is with a condition or not both for the client code and the DDS implementor.
  • Reported: DDS-PSM-Cxx 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0
  • Disposition Summary:

    The DataReader API has been updated to provide the proper read/take overloads and remove the useless ReaderQuery. The concept of a Selector has been introduced to orchestrate complex read/take operations requiring selection based on state, content and instance. The new API is orthogonal, simple and composable. Below an example usage of the selector API:

    LoanedSamples<Foo> ls =
    dr.select()
    .instance(handle)
    . content(query)
    .take();

    This example takes the samples matching the query q for the instance with given handle.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Assignment Rule for Container Types

  • Key: DDSPSMCF2-4
  • Legacy Issue Number: 17067
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The ctors declared by the macros OMG_DDS_REF_TYPE_BASE and OMG_DDS_REF_TYPE_BASE_T for initializing proxy classes with delegates should be declared protected as opposed to public. This will ensure (1) that client code is not able to invoke these methods and (2) that the C++ compiler won't try to apply some of the parametrized ctors to incomplete arg-list provided by the user.

    Resolution
    ---------------
    Change ctors declaration from "public" to "protected"
  • Reported: DDS-PSM-Cxx 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0
  • Disposition Summary:

    The Reference class ctors identified in this issue were declared “protected”.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Get rid of the EntityQos Class

  • Key: DDSJAVA-28
  • Legacy Issue Number: 16537
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Close this issue without any change. This type serves two purposes for the DDS user: it gives them a way to work with QoS policies polymorphically, and it binds a type parameter of the Entity interface to provide static type safety.
    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

QoS DSL Needed

  • Key: DDSJAVA-27
  • Legacy Issue Number: 16536
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The absence of a DSL for facilitating the correct creation of QoS (in QoS classes such as:
    TopicQos, DataWriterQos, etc.) in the
    dds-psm-java not only makes QoS manipulation cumbersone, but it also
    introduces potential for errors.

    [Resolution]
    Define a QoS DSL for the dds-psm-cxx which might look like this:

    TopicQos topicQos =
    (new TopicQos())
    .with(Reliability.Reliable(), Durability.Transient());

    This is also legal:

    TopicQos topicQos =
    (new TopicQos())
    .with(Reliability.Reliable())
    .with(Durability.Transient());

    • These class should implement the Comparable interface as they need to
      provide a total order... Otherwise how can one do RxO?
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Define a QoS DSL for the dds-psm-cxx which might look like this:
    TopicQos topicQos =
    (new TopicQos())
    .with(Reliability.Reliable(), Durability.Transient());
    This is also legal:
    TopicQos topicQos =
    (new TopicQos())
    .with(Reliability.Reliable())
    .with(Durability.Transient());

    • These class should implement the Comparable interface as they need to
      provide a total order... Otherwise how can one do RxO?
  • Updated: Fri, 6 Mar 2015 20:58 GMT

RxO QoS Policies should be Comparable (idem for QoS)

  • Key: DDSJAVA-23
  • Legacy Issue Number: 16532
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Some of the DDS QoS Policies are Request vs. Offered in the sense that
    the value of matching policies on communicating entities have to satisfy a
    specific ordering relationship. Specifically, the policy set on the receiving side
    should always be less or equal than the analogous QoS Policy on the
    sending side. As a result there is a natural total ordering for RxO Policies
    which is not currently captured nor reflected in the API.

    As a consequence also QoS should be defining a total order.

    [Resolution]
    Ensure that all RxO Policies implement the Comparable interface. This is
    pretty logical as for this QoS Policies it has to be established
    a total order.

    Let QoS classes also implement a comparable interface.
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Define an interface RequestedOffered; all QoS policy types that require requested/offered compatibility extend this interface. The interface has one method, requestedOfferedContract, which returns a Comparable object. That objects compares the policy against another instance of the policy based on the requested/offered compatibility rule(s) for that policy type.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Getting rid of the Bootstrap Object

  • Key: DDSJAVA-22
  • Legacy Issue Number: 16531
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The boostrap class is a pain for users which is in place only to allow
    users to run 2 different DDS implementations on the same application.
    The introduction of the Bootstrap object makes it impossible to use
    natural constructors for creating DDS types, even for types such as
    Time and Duration.
    As one of the main goal of the new DDS PSM was to simplify the
    user experience and make the API as simple and natural as possible,
    it seems that the introduction of the Bootstrap object goes exactly
    on the opposite direction – all of this to be able to cover the case
    in which a user wants 2 different DDS implementation on the same
    application. Considering the wire-protocol interoperability
    this use case seems marginal and perhaps does not even count for 1% of
    DDS uses.

    [Resolution]
    The bootstrap should be removed and the resulting API should be simplified.
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Large Number of Spurious Import

  • Key: DDSJAVA-26
  • Legacy Issue Number: 16535
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The dds-psm-java makes use of import as a way to take care of the
    @link directive on Javadoc. This is not a good practice and it
    is better to use the fully qualified type name on the @link javadoc
    directive

    [Resolution]
    Clean up all the spurious import and use fully qualified types on the @link directives.
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    There are no changes in the specification document for this issue. Discussion:
    Spurious import statements have been removed (as indicated by the Checkstyle plugin for Eclipse). Java doc comments are updated to use the fully qualified class names. This issue does not affect the specification text.
    See Revision 181: https://code.google.com/p/datadistrib4j/source/detail?r=181
    See Revision 210: https://code.google.com/p/datadistrib4j/source/detail?r=210
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constant Values SHALL be defined by the standard

  • Key: DDSJAVA-25
  • Legacy Issue Number: 16534
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Constant values such as the infinite duration, etc. should be defined
    by the standard as opposed than the implementation.

    [Resolution]
    Define constants as part of the API.
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Close this issue without any change.
    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Qos Policies ID class vs. numeric ID

  • Key: DDSJAVA-24
  • Legacy Issue Number: 16533
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    QoS Policies define a nested ID class for capturing the Policy ID and PolicyName.

    [Resolution]
    Remove the ID class and (1) use Java introspection for accessing the policy name,
    and (2) define an integral ID for specifiying the policy ID.

    Notice that getid and getName methods are also needed.
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    [Angelo] Remove the ID class and (1) use Java introspection for accessing the policy name, and (2) define an integral ID for specifying the policy ID.
    Notice that getId and getName methods are also needed.
    [Rick] This issue is unclear to me. I do not understand what problem it is describing. It seems to be redundant with issue #16369.
    Resolution:
    This issue is a duplicate of issue #16369 and should be merged with that one.
    Disposition: Duplicate of issue #16369
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Superfluous "QoSPolicy" Suffix on Policy Types

  • Key: DDSJAVA-21
  • Legacy Issue Number: 16530
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The dds-psm-java uses a superfluous Policy suffix to name the DDS policies
    which themselves are already included in a "policy" namespace.

    [Resolution]
    This suffix should be removed.
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Close this issue without any change. In Java, fully qualified names are almost never used, and Eclipse (the most commonly used editing environment) commonly collapses imports so they will not be seen. Therefore, it is relevant and important to include this suffix in the names of QoS policy types (not to mention consistent with the PIM). “Reliability” and “Durability” are just attributes; they don’t make sense unless we know what they describe.
    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Entity class allows for breaking invariants

  • Key: DDSJAVA-29
  • Legacy Issue Number: 16538
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The Entity provides some generic methods that seem of doubtful usefulness
    but then on the other end open up a door for messing up with the invariant
    of a type or at least raising runtime errors. For instance via the
    Entity type I can add a non-applicable QoS policy to a DDS entity –
    this seems weakening the API.

    [Resolution]
    Remove all method that might break invariants such as setQos, setListener, etc.
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Reject this issue. The generic parameters of this type provide static type safety and polymorphic behavior.
    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception safety guarantees for the DataReader API

  • Key: DDSPSMC-11
  • Legacy Issue Number: 16402
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The DataReader API must provide an exception-safe way to retrieve samples and must specify guarantees when exceptions are thrown. The exception safety of the DataReader API is analyzed with respect to user level state and middleware state. Read and take are both logically non-const operations with respect to the m/w because both of them have side effects such as changes in the sample_state and instance_state. There could be exceptions while delivering samples from m/w space to user space on the boundary of the read/take function calls. Depending upon the implementation there may or may not be a way to roll-back the changes in sample_state and instance_state. However, it is critical to have a way to not lose the samples even in case of exceptions. In general, it is difficult to provide strong guarantees with respect to m/w for datareader api.

    1. Strong and no throw guarantees for LoanedSamples:

    The constructor of LoanedSamples should provide strong guarantees. All the remaining operations (specifically copy-ctor and copy-assignment operator) should provide no-throw guarantees. It is important for LoanedSample to not throw exception during copy because then the samples would be lost. Further, read/take api should minimize dynamic memory allocation and locks on the critical path for performance reasons. Therefore LoanedSamples can’t use reference semantics either. (Reference<D> uses shared_ptr, which uses dynamic memory allocation and mutex to construct and protect the reference count.)

    These strict guarantees for LoanedSamples appear to be essential to support at least minimally exception safe read/take api that does no lose samples in case of exceptions. It is also the intent of LoanedSamples<T> to return the resources to m/w as soon as it goes out of scope.

    Proposed Solution: Use std::auto_ptr semantics in LoanedSamples. A key property of std::auto_ptr is that it can be safely returned while moving the resources out of an inner scope to an outer. No exceptions will be thrown. LoanedSamples<T> should be designed as such to avoid exceptions on copy. There is an idiomatic way of implementing such a class: The Move-constructor Idiom.

    Consequences: No std::vector<LoanedSamples<T>> would be possible. However the anticipated use-case of LoandedSamples is that the users would iterate over the range of samples and copy them and return the loan. For those users who really want to create vectors of loaned buffers, they would take ownership of the buffer from the LoanedSamples and use std::vector<shared_ptr<T> > to automate memory management. Use of custom deleters feature of shared_ptr may facilitate returning of the loan.

    2. LoanedSamples take(): Basic exception safe.

    The take function is loaning a buffer from the m/w. The implementations may or may not provide a way to ‘untake' samples. So this function cannot provide strong exception safety with respect to m/w. Therefore, guarantees of LoanedSample above are applicable here. This would guarantee that the samples that are removed from the history cache are not destoyed before the user gets a chance to access them.

    3. LoanedSamples read(): Basic exception safe.

    An attempt can be made to reread the samples. Above guarantees of LoanedSamples are applicable here

    4. // — Forward Iterators: — //
    void read(SamplesFWIterator, InfoFWIterator, size_t max_samples): Basic exception safe void take(SamplesFWIterator, InfoFWIterator, size_t max_samples): Basic exception safe

    This API probably needs to specify guarantees with respect to two different things:

    1. With respect to state changes in the user supplied range
    2. With respect to m/w state

    Changes to user-supplied range ==== If Nth copy throws there is no way to recover earlier N-1 objects that were already copied successfully. So in general only basic guarantee is provided. If the first object in the range throws, nothing changes and strong safety is provided. Further the API must provide a way to return # of objects were actually copied. API should specify a precondition: iterators must be from a range that is initialized and contain valid max_samples objects. In other words, the range cannot contain any uninitialized object. This prohibits uses such as

    std::vector<T> v;
    v.reserve(max);
    dr.read(v.begin(), v.end(), max);

    Changes to m/w state ==== The read() function has side effects like changes in the view_state and instance_state so it's really not a const function. The implementations may or may not provide a way to ‘unread' samples. So with respect to these status bits there is no way to provide strong exception guarantee so only basic guarantee is provided.

    Proposed Solution: In case of an exception (e.g., std::bad_alloc) during these function calls, construct an internal LoanedSamples<T> object and wrap it in a ‘ReadTakeException’ object and throw it. ReadTakeException class must provide an API to retrieve the LoanedSamples. Nothrow guarantees of LoanedSamples are important here again. This solution provides at least one way to retrieve the samples that are read/take from the history cache. Such a wrapper may also need to wrap the original exception that was raised to support exception neutrality.

    5. // — Back-Inserting Iterators: — //
    read(SamplesBIIterator, InfoBIIterator, size_t max_samples): Basic exception safe take(SamplesBIIterator, InfoBIIterator, size_t max_samples): Basic exception safe

    In addition to the exceptions that forward iterator versions can throw, these functions can throw when vector::push_back throws. I think the same rules are applicable to these functions.

  • Reported: DDS-PSM-Cxx 1.0b1 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    This issue raises a very important and tricky point. Exceptions raised during a read/take operation might leave user without data and the cache with a side-effect. Although the exceptions that would induce such a undesirable side-effect are due to memory exhaustion, it is desirable to provide at least some variation of the read/take API that are exception safe.
    This issue has been addressed by recommending that the loan-based implementation of read/take operations on the data-reader are implemented using a move-idiom (see http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Move_Constructor) and thus are exception safe (see resolution for issue 16401).
    In addition a new class called SharedSamples has been introduced to ensure we can still use loaned data in combination with standard containers.
    The specification of the SharedSamples class is available at:
    dds-psm-cxx/src/hpp/dds/sub/SharedSamples.hpp
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Portable exception-safety guarantees for DDS C++ PSM

  • Key: DDSPSMC-10
  • Legacy Issue Number: 16401
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The users of the DDS C++ PSM can benefit significantly if the specification standardizes exception-safety guarantees of the API. Exception safety specification for normative classes would support portable safety guarantees irrespective of vendor implementation and extensions. This would facilitate frictionless transition from one vendor to another in user code.

    Exception safety is about how programs, libraries behave when an exceptional condition arises. It is often much more than just raising an exception. For instance, constructor or copy-ctor of std::string may run out of memory resulting into std::bad_alloc exception. However, in practice, APIs must specify guarantees about the internal state of the data structures after any exception propagates out. Exception-safety guarantees for C++ abstractions come in four categories: strong, basic, nothrow, and neutral. For instance, the push_back member function of std::vector, std::list guarantees that the container remains unchanged (strong exception safety) in case of any exception. In general, programmers expect strong exception safety guarantees but it is often expensive to do so.

    RTI is proposing refined specifications for normative DDS C++ PSM API to make it easier to use even in the face of exceptions.

    1. Strong guarantees for value types:

    All the constructors and copy-assignment operators of normative classes that inherit from Value<D> and the Value<D> template itself should provide strong guarantees. A simple way to achieve that is to ensure that Value<D> template provides strong guarantees and then implement the derived classes in terms of value<D>.

    Not all value types are POD. Some of them use std::string and may throw. Consider, for instance, SubscriptionBuiltinTopicData. Value<D> delegates the assignment to its delegate, SubscriptionBuiltinTopicDataImpl. This impl class has non-pod members such as std::string and does not define its own assignment operator. Assignment of one string (topic_name) may succeed but the assignment of second string (type_name) may fail with a bad_alloc exception. This may result into inconsistent left-hand-side SubscriptionBuiltinTopicData object when DataWriter:: matched_subscription_data is called.

    In general, classes that have more than one non-pod types should have an assignment operator that is strongly safe. Instead of handpicking such classes, Value<D should be made strong exception-safe so that irrespective of vendor-specific extensions, types that users will deal with the most, will be safe to use.

    Proposed solution: Implement the copy-assignment operator of Value<D> using copy-and-swap technique.

    2. At least basic guarantees for reference types:

    Not all implementations may be able to provide strong guarantees for reference types such as DataWriter<Foo>, DataReader<Foo>. Therefore, constructors and copy-assignment operators must provide at least basic guarantees. While Reference<D> itself should provide strong guarantees; just that is insufficient to extend the guarantees to all its derived classes. The normative reference types should provide strong guarantees whenever it is not prohibitively expensive to do so.

  • Reported: DDS-PSM-Cxx 1.0b1 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    Section 7.3 on page 16 of the specification lists not the mandatory exception safety requiremenst on Value types and Reference Types. Specifically, for reference types it is required that loan-based read/take are exception safe.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Union/array/bounded types lacking

  • Key: DDSPSMC-3
  • Legacy Issue Number: 16261
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification should describe the mapping for Union, Array, and the behavior for bounded strings (what happens if we go beyond the bound)

  • Reported: DDS-PSM-Cxx 1.0b1 — Tue, 24 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    Arrays are now mapped to the dds::core::array<T,N> type which is designed to be compatible with C+11 arrays and thus to simplify idiomatic C11 usage as well as portability of DDS code to C+11 compilers.

    The table 7.1 in section 7.4.2 reflects the new mapping of array (see last column).

    Section 7.4.3 provides now a definition of the mapping for enumerations.

    Section 7.4.4 provides a definition of the mapping for unions.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

factory methods on the "parents" (e.g. create_topic, create_data_writer, etc.)

  • Key: DDSPSMC-2
  • Legacy Issue Number: 15967
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The changes introduced in the final submission to support factory methods on
    the "parents" (e.g. create_topic, create_data_writer, etc.) has introduced a
    few issues.

    a. Reference types are not created in a uniform way. In essence,
    DomainParticipant, Subscriber, Publisher, DataReader and DataWriter
    types are instantiated using a different syntax than that used by
    WaitSets or Conditions. This is unfortunate as it reduces the
    consistency of the API.

    b. To eliminate the circular dependencies induced by the factory methods
    the API has to implement a few "creative" solutions that impact
    clarity as well as robustness. All of a sudden it is relatively hard
    to find where is defined what and also the include systems is very
    fragile, e.g. one can break the API very easily by mistakenly changing
    one include order.

    The changes suggested to the submission is to equip each
    Reference type with a factory method called "create". This not only allows to
    remove circular references, but it also allows for an organization of the API
    that is more robust and easier to follow. Furthermore, it ensures that
    all references are created in an uniform manner.
  • Reported: DDS-PSM-Cxx 1.0b1 — Mon, 17 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    The dds-psm-cxx API has been updated to remove the circular dependencies introduced by factory methods. Along with removing circular dependencies the API has been refactored to ensure that no forward includes are needed thus maintaining local, and thus clear and visible, the set of dependencies for each file. The necessary changes have been applied to all the DDS entities, such as DomainParticipant, Publisher and Subscriber.
    Examples in the specification have been updated to reflect the API change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compilation errors on Visual Studio 2008/2010

  • Key: DDSPSMC-5
  • Legacy Issue Number: 16338
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Description: The sources obtained from dds-psm-cxx.googlecode.com do not compile on Visual Studio compilers without significant efforts. There are multiple issues most related to type conversion.

    1. All the classes that inherit from dds::core::Value<D> seem to be missing a copy-ctor. For example, QosPolicyCount in src\hpp\tdds\core\policy\QosPolicyCount.hpp. Without a copy-ctor, VS2010 issues a “cannot convert from ...” error.

    Most of these classes are found in the following files:

    src\hpp\tdds\core\InstanceHandle.hpp
    src\hpp\tdds\core\policy\CorePolicy.hpp
    src\hpp\tdds\core\policy\QosPolicyCount.hpp
    src\hpp\tdds\core\qos\EntityQos.hpp

    Proposed Solution: Add a copy constructor to all the classes that inherit from dds::core::Value<D> as follows:

    QosPolicyCount(const QosPolicyCount& src) : dds::core::Value<DELEGATE>(src.delegate()) { }

    2. The exception classes in dds-psm-cxx\src\hpp\dds\core\Exception.hpp do not need copy-ctor because there is nothing to copy and the base classes don’t have copy constructors either.

    Proposed resolution: Remove the declarations of copy constructors in dds-psm-cxx\src\hpp\dds\core\Exception.hpp

    3. The private constructor of SampleRejectedStatus in dds-psm-cxx-read-only\src\hpp\dds\core\status\State.hpp needs a typecast to avoid compilation errors on Visual studio versions of STL.

    The following constructor can’t be called due to ambiguous overloads of bistset<N> constructors.

    private: SampleRejectedState(uint32_t s) : MaskType(s) { }

    Proposed solution: Change the call to the base constructor to include an explicit static_cast to int.

    private: SampleRejectedState(uint32_t s) : MaskType(static_cast<int>(s)) { }

  • Reported: DDS-PSM-Cxx 1.0b1 — Fri, 17 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    The Visual Studio C++ 2010 compiler was raising a series of errors and warning that were not caught by GCC relating to some lacking ctors and conversion operators in some template classes. All the errors raised by Visual Studio C++ 2010 have been addressed as verifiable on the latest version of the dds-psm-cxx source code available at https://github.com/kydos/dds-psm-cxx
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Dividing a scalar in Duration and Time classes

  • Key: DDSPSMC-4
  • Legacy Issue Number: 16308
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Duration and Time have some arithmetic operators that have the form:

    const Duration operator /(uint32_t lhs, const Duration& rhs);
    const Time operator /(uint32_t lhs, const Time& rhs);

    In the above, the intent of dividing a scalar by Duration/Time is not clear.

    Duration/N is conceivable but not N/Duration.

    Proposed solution:

    Remove the following free functions.
    const Duration operator /(uint32_t lhs, const Duration& rhs);

    const Time operator /(uint32_t lhs, const Time& rhs);

  • Reported: DDS-PSM-Cxx 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    Removed the operation:
    const Duration operator /(uint32_t lhs, const Duration& rhs);

    from the Duration class. The Time class did not have such a method to begin with.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML-Based QoS Policy Settings (DDS-PSM-Cxx/DDS-PSM-Java)

  • Key: DDSPSMC-1
  • Legacy Issue Number: 15965
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The newly introduced XML Based Policy configuration adds new methods in the core DDS entities that allow to fetch QoS from XML filers. This solution is not ideal since if generalized, e.g. QoS configuration from an URI, JSON stream, etc., would lead to an explosion of the core DDS API.

    The suggestion is to remove the added methods from the core API and use instead a Builder pattern (of some form).

    A sketch of the suggested change is provided below:

    PolicyBuilder builder = PolicyBuilder::load("XMLBuilder");

    TopicQos tqos = builder.topic_qos(file_name, profile_name);

    ==============================================================================

    Notice that the suggested approach allows to easily extend the supported format for QoS representation w/o any impact on the core DDS API and overall facilitate the support for multiple approaches.
  • Reported: DDS-PSM-Cxx 1.0b1 — Mon, 17 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    The class dds::core::qos::TQoSProvider provider has been added to the C++ API to allow the external configuration of QoS. Section 7.6.2.1 of the specification document has been updated accordingly to describe the dds::core::TQoSProvider
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixing bugs and improving usability of the InstanceHandle class

  • Key: DDSPSMC-7
  • Legacy Issue Number: 16340
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The InstanceHandle class in dds-psm-cxx\src\hpp\tdds\core\instancehandle.hpp appears to be incomplete in several ways.

    1. A missing constructor
    InstanceHandle(const DELEGATE & d) :
    dds::core::Value<DELEGATE>(d) {}

    There is no way to construct an instance handle except a null one!

    2. A missing copy-constructor
    InstanceHandle(const InstanceHandle& src) :
    dds::core::Value<DELEGATE>(src.delegate())
    { }

    3. Typos: a missing return and needs a dot instead of an arrow.

    InstanceHandle& operator=(const dds::core::null_type& src)

    { return this->delegate().operator=(src); }

    4. Missing comparison operators to allow comparisons like
    if(dds::null == instance_handle_object)

    Currently it supports other way round. The proposed solution is to add two overloaded operators in tdds::core namespace.

    template <class D>
    bool operator == (dds::core::null_type, InstanceHandle<D> const &ih)

    { return ih.is_nil(); }

    template <class D>
    bool operator != (dds::core::null_type, InstanceHandle<D> const &ih)

    { return !ih.is_nil(); }

    5. Finally, the InstanceHandle<D> class and in general the classes that support comparison with dds::null will benefit from supporting a generic and succinct syntax of the form: if(instance_handle_object).

    Proposed Solution:
    An idiomatic way of implenting it is the safe-bool idiom, which has been used widely in standard and boost smart pointer classes, such as std::auto_ptr, boost::shared_ptr. Here is a self-sufficient file that shows one way of implementing the safe bool idiom for the instance handle class:

    http://cpptruths.googlecode.com/svn/trunk/cpp/instance_handle.cpp

    Other possible implementation based on the discussions on the boost mailing list is available here:

    http://codepaste.net/c83uuj

  • Reported: DDS-PSM-Cxx 1.0b1 — Mon, 20 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    The following changes have been applied to the TInstanceHandle class to address this issue:
    1. Defined a new constructor for initializing the instance handle with a specific type:
    template <typename ARG0>
    TInstanceHandle(const ARG0& arg0);
    2. Added copy constructor

    The problems 3, 4 , and 5 are rejected since an InstanceHandle is a Value as opposed to a Reference type. As such comparison with null_ref is conceptually non-correct and potentially highly misleading. The current API provides an isNil method to check wether the handle is or isn’t nil. In addition, the InstanceHandle defines the NilHandle to allow proper comparisons. To this hand an operator== for the InstanceHandle has been added.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use traits for topic/datareader/datawriter

  • Key: DDSPSMC-9
  • Legacy Issue Number: 16374
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The proposed PSM takes the DDS PSM and now gives the users templates instead of new classes as with the IDL to C++ mapping.

    For example RadarTrackDataWriter becomes DataWriter<RadarTrack>.

    To my idea this this is syntactical sugar and I still see how the DDS implementation implement their support. I would like to propose a different way. As user I just have RadarTrack, that is coming from my user domain, so why now create a set of traits that can be used by the end user. Than he doesn't see anything special from DDS, not whether it is a template or a class.

    So he writes
    RadarTrack::data_writer_type dw = pub.create_datawriter()
    RadarTrack::topic_type tp = dp.create_topic().

    The DDS implementation can than do anything behind data_writer_type, the only thing the user has to know are the traits and the methods that are possible to be used.

  • Reported: DDS-PSM-Cxx 1.0b1 — Wed, 20 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance via dominance warning on Visual Studio

  • Key: DDSPSMC-8
  • Legacy Issue Number: 16354
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Visual Studio spits out many #C4250 warnings on the diamond hierarchy of listeners:

    for instance,
    DomainParticipantListener.hpp(48): warning C4250: 'dds::domain::NoOpDomainParticipantListener' : inherits 'dds::pub::NoOpPublisherListener::dds::pub::NoOpPublisherListener::on_offered_deadline_missed' via dominance

    Proposed solution:

    Add empty bodies for all the inherited virtual functions in all the NoOp*Listener classes. Particularly, NoOpDomainParticipantListener, NoOpPublisherListener, and NoOpSubscriberListener.

    Alternatively, #pragma warning( disable : 4250 ) could be used but its purpose will be less clear even with documentation: "Prevents via dominance warning."

  • Reported: DDS-PSM-Cxx 1.0b1 — Thu, 30 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    This problems raised by this issue are gone since the specification is not providing with default implementation of any methods. Trivial implementations where used during specification and finalization to ensure the implement-ability of the API along with catching compilation errors. However the finalized API does not include any implementation to avoid over-specification.

    Revised Text:
    No change.

    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improving usability of Reference class

  • Key: DDSPSMC-6
  • Legacy Issue Number: 16339
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    1. Safety of Reference<D> class should be improved by adding "explicit" keyword in the following constructors:

    template <typename D>
    Reference(const Reference<D>& ref);

    template <typename R>
    Reference(const R& that);

    Reference(const DELEGATE_REF_T& ref);

    2. With just member operator== and operator!= functions, Reference<D> can't be used in expressions like

    if(dds::null == r)

    { ... }

    Proposed solution: Add the following free functions in dds::core in Reference.hpp.

    template <class D>
    bool operator == (dds::null_type,
    const Reference<D> & r)

    { return r.is_nil(); }

    template <class D>
    bool operator != (dds::null_type,
    const Reference<D> & r)

    { return !r.is_nil(); }

  • Reported: DDS-PSM-Cxx 1.0b1 — Fri, 17 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    The changes suggested by the issue submitter have been applied to the Refence class.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

General Exception Safety Considerations

  • Key: DDSPSMC-12
  • Legacy Issue Number: 16403
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    1. The normative implementations shown in the wrapper classes should be at strong exception safe (or at least basic safe). For instance, implementation of DataReader:: create_readcondition as in dds-psm-cxx\src\hpp\dds\sub\DataReader.hpp is a shared_ptr usage anti-pattern.

    Proposed Solution:
    Create separate shared_ptr<T> objects for every new operation. Pass the shared_ptr<T> to the constructor of ReadCondition.

    2. All setters and getters (including overloaded operators) of EntityQos should be strong exception safe.

    Proposed Solution: Make copy-assignment operator of every qos type in normative namespaces strong exception safe.

  • Reported: DDS-PSM-Cxx 1.0b1 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Modifiable Types should be removed and replaced by values (e.g. immutable types).

  • Key: DDSJAVA-20
  • Legacy Issue Number: 16529
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The dds-psm-java introduces modifiable versions for conceptually immutable classes
    as a way to safe a few object allocations. However this is done for QoS which
    are not changed so often and that are overall very "thin" object.

    [Suggested Resolution]
    The proposed resolution is to get rid of this modifiable types and to ensure that
    value types are used everywhere.
    Althought this solution might lead to think that immutable types induce the creation
    of more objects this is not necessarily the case if the API si designed carefully as
    done for policies and Qos on simd-java (see git@github.com:kydos/simd-java.git).

    As an example, with the API included in the current DDS-PSM-Java modifying a policy
    would require the following steps:

    // Get unmodifiable QoS for inspection:
    DataWriterQos udwq = dw.getQos();

    // Get the Modifiable QoS
    ModifiableDataWriterQos mdwq = udwq.modify();

    // Modify the Qos
    mdwq.setReliability(...);

    With immutable Policies and QoS the same code could be rewritten as follows:

    DataWriterQos dwq = dw.getQos().with(Reliability.Reliable());

    But you could also do:
    DataWriterQos dwq = dw.getQos().with(
    Reliability.Reliable(),
    Durability.Transient());

    Notice that both code fragment both lead the lead the creation of a single new object.
    Yet the propsed approach not only gets rid of the complexity of the mutable objects,
    but it also get rids of the danger introduced by having mutable objects into multi-threaded
    applications. In summary, the proposed change (1) simplifies the API, (2) makes it safer, and (3) does
    not introduce runtime overhead (it actually allows for an higher degree of object sharing and thus
    better space efficiency).

    NOTE:
    Cloneable interface
    No need to implement the interface once the mutable pkg is removed
  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

QosPolicy.Id enumeration is redundant

  • Key: DDSJAVA-19
  • Legacy Issue Number: 16369
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    In the DDS PIM, each QoS policy has a name and an ID that uniquely identify it. In this PSM, these two things are encapsulated in the enumeration QosPolicy.Id. But the Java platform already provides equivalent information: the Class object. The ability to quickly compare Class object pointers is equivalent to comparing ID integer values, and each Class already has a name string.

    Proposed Resolution:

    Remove the enumeration QosPolicy.Id. Replace its uses with Class<? extends QosPolicy>.
  • Reported: DDS-Java 1.0b1 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Remove the enumeration QosPolicy.Id. Replace its uses with Class<? extends QosPolicy>.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove unnecessary DataWriter.write overloads

  • Key: DDSJAVA-15
  • Legacy Issue Number: 16325
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Title: Remove unnecessary DataWriter.write overloads

    Source:

    RTI (Rick Warren, rick.warren@rti.com)

    Summary:

    The specification currently provides overloads for DataWriter.write that take the following combinations of parameters

    1. The sample to write, without an instance handle. (If the type is not keyed, no instance handle is necessary. If it is keyed, the instance handle is implicitly nil and will be inferred by the implementation.)

    2. The sample to write, without an instance handle but with a time stamp.

    3. The sample to write, with an instance handle.

    4. The sample to write, with both an instance handle and a time stamp.

    The overloads would be easier to understand if they formed a progression from fewer parameters to more. We can do this by removing (2).

    Proposed Resolution:

    Remove the following methods:

    • public void write(
    • TYPE instanceData,
    • Time sourceTimestamp) throws TimeoutException;
    • public void write(
    • TYPE instanceData,
    • long sourceTimestamp,
    • TimeUnit unit) throws TimeoutException;

    Also, update the documentation of the remaining overloads to clarify that if the topic is not keyed, they can be called with a nil or null InstanceHandle.
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improve polymorphic sample creation

  • Key: DDSJAVA-14
  • Legacy Issue Number: 16324
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Source:

    RTI (Rick Warren, rick.warren@rti.com)

    Summary:

    The specification does not provide a simple, portable way to create a new data sample to use with the middleware. Instead, there are several partial solutions:

    · Instantiate a concrete sample type directly: “new Foo()”. This approach doesn’t work in generic methods—i.e. when the concrete type is not statically known. It also doesn’t work with DynamicData.

    · Instantiate DynamicData from DynamicDataFactory. But samples of statically known, user-defined types don’t have a “data factory”.

    · Use DataReader.createData(). But there is not equivalent on the publishing side.

    There should be a single way that works uniformly and generically.

    Proposed Resolution:

    The proposed resolution has several parts:

    1. Introduce a new factory instance method to the TypeSupport class: TypeSupport.newData(). The name of this method is parallel to that of other value type “constructor-like” factories.

    2. Support navigation from the TopicDescription to the TypeSupport. Add a new method TopicDescription.getTypeSupport().

    3. Simplify the number of ways to get from the data type’s TypeSupport to its Class. Add a method TypeSupport.getType(). Remove the existing methods TopicDescription.getType(), DataWriter.getType(), and DataReader.getType(): they are redundant.

    4. Remove the existing method DataReader.createData() and the existing class DynamicDataFactory. They are not needed.

    There will therefore be a single polymorphic and generic way to instantiate a sample of any type: by using its TypeSupport. (You can get the TypeSupport from any related TopicDescription, or transitively any DataReader or DataWriter.)

    Likewise, there will be a single polymorphic and generic way to get the Class object for any data type: from its TypeSupport. As described in the previous paragraph, you can get to the TypeSupport from a variety of places.
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    The proposed resolution has several parts:
    1. Introduce a new factory instance method to the TypeSupport class: TypeSupport.newData(). The name of this method is parallel to that of other value type “constructor-like” factories.
    2. Support navigation from the TopicDescription to the TypeSupport. Add a new method TopicDescription.getTypeSupport().
    3. Simplify the number of ways to get from the data type’s TypeSupport to its Class. Add a method TypeSupport.getType(). Remove the existing methods TopicDescription.getType(), DataWriter.getType(), and DataReader.getType(): they are redundant.
    4. Remove the existing method DataReader.createData() and the existing class DynamicDataFactory. They are not needed. In the specification document, rename section 7.7.1.1, “DynamicTypeFactory and DynamicDataFactory Interfaces”, to “DynamicTypeFactory Interface”. In the single paragraph of that section, make the word “factories” singular.
    See revision #123, which includes the above changes: http://code.google.com/p/datadistrib4j/source/detail?r=123.
    5. Remove the factory methods on the built-in topic data classes. Objects of these types can be constructed like those of any other sample type. See also revision #137, which includes this change: http://code.google.com/p/datadistrib4j/source/detail?r=137.
    There will therefore be a single polymorphic and generic way to instantiate a sample of any type: by using its TypeSupport. You can get the TypeSupport from any related TopicDescription, or transitively any DataReader or DataWriter.
    Likewise, there will be a single polymorphic and generic way to get the Class object for any data type: from its TypeSupport. As described in the previous paragraph, you can get to the TypeSupport from a variety of plac
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improve usability of “bucket” accessors

  • Key: DDSJAVA-6
  • Legacy Issue Number: 16316
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The third bullet at the end of section 7.1.5, “Method Signature Conventions”, reads:

    · Accessors for properties that are of mutable types, and that may change asynchronously after they are retrieved, are named get<PropertyName>. They take a pre-allocated object of the property type as their first argument, the contents of which shall be overwritten by the method. To facilitate method chaining, these methods also return a reference to this argument. This pattern forces the caller to make a copy, thereby avoiding unexpected changes to the property. An Entity’s status is an example of a property of this kind.

    (This pattern of passing a container to an object for that object to “fill in” has sometimes been referred to as a “bucket” pattern.)

    In cases where object-allocation performance is not a significant concern, the usability of this pattern can be improved with a trivial addition: allow the caller to pass in a null “bucket”, and require the implementation to allocate and return a new object with the appropriate contents.

    Proposed Resolution:

    Add a sentence to the bullet that indicates that a null argument is permitted.

    Proposed Revised Text:

    Replace the third bullet in section 7.1.5, “Method Signature Conventions” with the following:

    · Accessors for properties that are of mutable types, and that may change asynchronously after they are retrieved, are named get<PropertyName>. They take a pre-allocated object of the property type as their first argument, the contents of which shall be overwritten by the method. To facilitate method chaining, these methods also return a reference to this argument. The caller may alternatively pass a null argument into such accessor methods, in which case the implementation shall allocate a new object, set its contents appropriately, and return it. This pattern forces the caller to make a copy, thereby avoiding unexpected changes to the property. An Entity’s status is an example of a property of this kind.
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing -behavioural- descriptions of the interface

  • Key: DDSJAVA-5
  • Legacy Issue Number: 16104
  • Status: closed  
  • Source: Thales ( Andre Bonhof)
  • Summary:

    Some parts of the interface (javadoc) are poorly documented especially with respect to behaviour. This Java documentation will be the key documentation for the new DDS application programmers. It may be trivial or implicit for the ones writing the standard but it will not be for the application programmers which are not familiar with the existing DDS standard will use it

    For example have a look at the method createDataWriter(Topic<TYPE> topic) on the Publisher interface. What will happen if the middleware cannot create the datawriter. Will an unchecked exception be thrown or is a null value returned or even worse the datawriter is simply returned and will fail when the first write action is performed?

    I now that the existing OpenSplice DDS implementation will return null when the middleware is not able to create the datawriter but it would be nice that applications are not only portable from interface compliance aspect but also from behavioural aspect! (and that application programmers are aware of it)

  • Reported: DDS-Java 1.0b1 — Thu, 31 Mar 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Merge the descriptions of classes and operations from the DDS specification into the appropriate JavaDoc comments. This PSM does not introduce new concepts, so no merge is necessary in that case. DDS-XTypes is in finalization, so its contents are not yet fixed. Therefore, to avoid the possibility of errors and inconsistencies, we should put it aside for now.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Entity.setListener is missing listener mask

  • Key: DDSJAVA-8
  • Legacy Issue Number: 16318
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Source:

    RTI (Rick Warren, rick.warren@rti.com)

    Summary:

    The method signature for Entity.setListener does not include the listener “mask” (actually, a collection of status classes in this PSM) parameter from the PIM.

    Discussion:

    The current signature is useful as a convenience for the common case where the application wants all callbacks. But it lacks the expressiveness of the PIM, so an additional overload should be provided.

    Proposed Resolution:

    Add the following method to the Entity interface:

    public void setListener(

    LISTENER listener,

    Collection<Class<? extends Status<?, ?>>> statuses);

    Include the appropriate JavaDoc copied from the DDS specification
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Add the following method to the Entity interface:
    public void setListener(
    LISTENER listener,
    Collection<Class<? extends Status<?, ?>>> statuses);
    Include the appropriate JavaDoc copied from the DDS specification
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update specification to reflect DDS-XTypes FTF1 issue resolutions

  • Key: DDSJAVA-7
  • Legacy Issue Number: 16317
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Source:

    RTI (Rick Warren, rick.warren@rti.com)

    Summary:

    The (first) DDS-XTypes FTF has completed. Some of the issue resolutions result in API changes that impact this specification. Those changes should be reflected here to keep this specification aligned with the PIM.

    These issues potentially include:

    · #15689, Identifiers TypeId and Module collide with IDL keywords

    · #15691, Unclear member names when programming language doesn’t support typedef

    · #15693, Extensibility kinds of new QoS policies are not specified in a consistent way

    · #15696, Incorrect FooDataWriter overloads for built-in types

    · #15706, Reduce size of DynamicData API

    Note that this issue applies to DDS-PSM-Cxx too.
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    See the following revisions:
    • Revision #128: http://code.google.com/p/datadistrib4j/source/detail?r=128. Reflects DDS-XTypes issue #15696—overloads in writers of built-in types.
    • Revision #129: http://code.google.com/p/datadistrib4j/source/detail?r=129. Reflects DDS-XTypes issue #15691—clarity of member names in the absence of typedef.
    • Revision #130: http://code.google.com/p/datadistrib4j/source/detail?r=130. Reflects DDS-XTypes issue #15706—simplified DynamicData.
    Other aspects of issue #15689 and 15691 were already addressed in the drafting of DDS-PSM-Java. Issue #15693 is a no-op because of the way inheritance and annotations are used
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DynamicDataFactory.createData missing a parameter

  • Key: DDSJAVA-12
  • Legacy Issue Number: 16322
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Source:

    RTI (Rick Warren, rick.warren@rti.com)

    Summary:

    According to DDS-XTypes, the operation DynamicDataFactory.create_data (createData in this PSM) takes a parameter that indicates the DynamicType of the new data object to create. That parameter is missing, leaving implementations with no way to determine—and applications with no way to specify—the type of the created object.

    Proposed Resolution:

    Add the missing argument.

    Proposed Revised Text:

    Apply the following difference to the method signature:

    • public abstract DynamicData createData();

    + public abstract DynamicData createData(DynamicType type);
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    This issue is obsolete if the proposal for issue #16324 is accepted: that proposal calls for DynamicDataFactory to be eliminated entirely. Merge this issue with that one.
    Disposition: Merged with issue #16324
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Too many read/take overloads

  • Key: DDSJAVA-11
  • Legacy Issue Number: 16321
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The DataReader interface defines a very large number of read and take variants. While each one has a clear meaning, the sheer number of them makes the API harder to understand.

    Discussion:

    One possibility would be to follow the example of the C++ PSM, and combine things like condition, handle, etc. into a “filter” parameter.

    Note that this issue should be resolved at the same time as #16056.
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DataReader.createReadCondition() is useless

  • Key: DDSJAVA-18
  • Legacy Issue Number: 16328
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Source:

    RTI (Rick Warren, rick.warren@rti.com)

    Summary:

    The DataReader interface provides two overloads for the createDataReader method: one that takes no arguments and another that takes the appropriate sample states, view states, and instance states. The existence of the first overload supposes that it will be common to create a ReadCondition with any sample state, any view state, and any instance state. But in fact, such a ReadCondition is not very useful at all: there’s no point in passing it to read/take, because it will not filter the available samples in any way. And although you could use it with a WaitSet, it doesn’t do anything that you couldn’t do with a StatusCondition on the DATA_AVAILABLE status.

    Proposed Resolution:

    Remove the no-argument overload of DataReader.createReadCondition. Leave the three-argument overload unchanged.
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Remove the no-argument overload of DataReader.createReadCondition. Leave the three-argument overload unchanged.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parent accessors should be uniform across Entities and Conditions

  • Key: DDSJAVA-17
  • Legacy Issue Number: 16327
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Source:

    RTI (Rick Warren, rick.warren@rti.com)

    Summary:

    All DomainEntity interfaces, and some Condition interfaces, can provide a reference to the parent object. In the case of Entities, this accessor has been captured in the form of a generic base interface method:

    PARENT DomainEntity.getParent();

    However, StatusCondition and ReadCondition are not parallel. They provide the following methods:

    ENTITY StatusCondition.getEntity();

    DataReader<TYPE> ReadCondition.getDataReader();

    It would be more consistent if we renamed both of the above methods to getParent.

    Proposed Resolution:

    Rename StatusCondition.getEntity to getParent.

    Rename ReadCondition.getDataReader to getParent.
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Rename StatusCondition.getEntity to getParent.
    Rename ReadCondition.getDataReader to getParent.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect topic type specification in DomainParticipant.createMultiTopic

  • Key: DDSJAVA-10
  • Legacy Issue Number: 16320
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The method DomainParticipant.createMultiTopic specifies the type of the resulting object using a registered type name in string form. However, this is inconsistent with the way type registration is handled elsewhere in this PSM: callers provide a Class or TypeSupport object, and the implementation registers the type implicitly as necessary.

    Discussion:

    We should follow the model of createTopic: provide two overloads, one taking a Class and the other a TypeSupport.

    Proposed Resolution:

    Replace the existing createMultiTopic method declaration with two new overloads. In place of the typeName string, the first new overload shall take a Class parameter. The second shall take a TypeSupport parameter
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Replace the existing createMultiTopic method declaration with two new overloads. In place of the typeName string, the first new overload shall take a Class parameter. The second shall take a TypeSupport parameter
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unclear blocking behavior for WaitSet.waitForConditions overloads that don’t specify timeout

  • Key: DDSJAVA-9
  • Legacy Issue Number: 16319
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Source:

    RTI (Rick Warren, rick.warren@rti.com)

    Summary:

    The method WaitSet.waitForConditions is provided with several overloads, including some that do not take an explicit timeout. These are intended to wait indefinitely. However, they still throw TimeoutException. How can they time out if they wait forever?

    Discussion:

    Object.wait allows indefinite waiting, so it makes sense for this specification to allow it as well. However, these overloads should not ever throw TimeoutException.

    Proposed Resolution:

    Remove the clause “throws TimeoutException” from these method declarations.
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Remove the clause “throws TimeoutException” from these method declarations.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Logically ordered types should implement java.lang.Comparable

  • Key: DDSJAVA-13
  • Legacy Issue Number: 16323
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Source:

    RTI (Rick Warren, rick.warren@rti.com)

    Summary:

    Several of the types defined in this PSM have a natural order (such as Time). In order to better integrate with the Java platform, these types should implement the standard java.lang.Comparable interface.

    Proposed Resolution:

    Implement Comparable in the following types:

    · Bit—ordered based on index within a bit set

    · Duration—ordered from shorter durations to longer ones

    · Time—ordered from earlier points in time to later ones
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Implement Comparable in the following types:
    • Bit—ordered based on index within a bit set
    • Duration—ordered from shorter durations to longer ones
    • InstanceHandle—ordered in an implementation-specific way (DDS specification of DataReader::read() requires such an ordering)
    • Time—ordered from earlier points in time to later ones
  • Updated: Fri, 6 Mar 2015 20:58 GMT

copyFromTopicQos signatures are not correct

  • Key: DDSJAVA-16
  • Legacy Issue Number: 16326
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Proposed Resolution:

    Change the signatures as follows:

    In Publisher.java:

    • public void copyFromTopicQos(DataWriterQos dst, TopicQos src);

    + public ModifiableDataWriterQos copyFromTopicQos(

    + ModifiableDataWriterQos dst, TopicQos src);

    In Subscriber.java:

    • public void copyFromTopicQos(DataReaderQos dst, TopicQos src);

    + public ModifiableDataReaderQos copyFromTopicQos(

    + ModifiableDataReaderQos dst, TopicQos src);
  • Reported: DDS-Java 1.0b1 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML-Based QoS Policy Settings (DDS-PSM-Cxx/DDS-PSM-Java)

  • Key: DDSJAVA-1
  • Legacy Issue Number: 15966
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    ISSUE
    The newly introduced XML Based Policy configuration adds new methods in the core DDS entities that allow to fetch QoS from XML filers. This solution is not ideal since if generalized, e.g. QoS configuration from an URI, JSON stream, etc., would lead to an explosion of the core DDS API.

    The suggestion is to remove the added methods from the core API and use instead a Builder pattern (of some form).

    A sketch of the suggested change is provided below:

    PolicyBuilder builder = PolicyBuilder::load("XMLBuilder");

    TopicQos tqos = builder.topic_qos(file_name, profile_name);

    ==============================================================================

    Notice that the suggested approach allows to easily extend the supported format for QoS representation w/o any impact on the core DDS API and overall facilitate the support for multiple approaches.
  • Reported: DDS-Java 1.0b1 — Mon, 17 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    The suggestion is to remove the added methods from the core API and use instead a Builder pattern (of some form).
    A sketch of the suggested change is provided below:
    PolicyBuilder builder = PolicyBuilder::load("XMLBuilder");
    TopicQos tqos = builder.topic_qos(file_name, profile_name);
    Notice that the suggested approach allows to easily extend the supported format for QoS representation w/o any impact on the core DDS API and overall facilitate the support for multiple approaches
  • Updated: Fri, 6 Mar 2015 20:58 GMT

read/take consistency for loaned and non-loaned samples

  • Key: DDSPSMC-23
  • Legacy Issue Number: 17337
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The current DataReader API provides a slightly different API for getting samples when loaning the data vs. when providing user storage.

    When loaning the data the data and the SampleInfo is encapsulated on a Sample type, while when providing user storage two different containers hold the data and the SampleInfo.

    For consistency the two API should encapsulate the data and the SamplInfo on the Sample data structure.

  • Reported: DDS-PSM-Cxx 1.0b1 — Wed, 25 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    This issue raises a relevant consistency issue. All the operations on the DataReader have been revised to consistently use the Sample type to hold both sample data and sample info.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The tdds namespace should be merged into the dds namespace

  • Key: DDSPSMC-20
  • Legacy Issue Number: 16655
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The DDS-PSM-Cxx specification groups types constructors into the "tdds" namespace. However this separation makes it harder than it should be to navigate the code. The suggested approach is to remove the "tdds" namespace and migrate those classes into the "dds" namespace by prefixing them with a "T". For instance the "tdds::sub::Subscriber" would become "dds::sub::TSubscriber".
  • Reported: DDS-PSM-Cxx 1.0b1 — Tue, 8 Nov 2011 05:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    The API code has been refactored to remove the tdds namespace as suggested by the issue description. In addition figure 7.1 in section 7.2 and page 5 has been updated to reflect the new organization and figure 7.2 has been removed.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Getter/Setter for member arrays

  • Key: DDSPSMC-22
  • Legacy Issue Number: 16886
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The specification maps IDL array to C++ native array. There are two possible alternatives as far as getter/setter functions are concerned.

    class Foo {
    char data[10];
    public:
    char * begin_data()

    { return data; }
    char * end_data() { return data + 10; }


    void data(char * begin, char *end) {}


    template <class Iter>
    void data(Iter begin, Iter end) {}
    };


    AND


    class Foo {
    char data[10];
    public:
    char * data() { return data; }

    size_t data_size()

    { return 10; }

    void data(char *ptr, size_t size) {}
    };

    The first version is more consistent with modern C++ usage of iterators. In either case a convention must be defined for portability. This may also be applicable to idl sequences.

  • Reported: DDS-PSM-Cxx 1.0b1 — Fri, 9 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    This issue is automatically resolved as a consequence of the new mapping defined for array as result of issue 16261.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Expected use of AnyDataReader::get and its implication on AnyDataReader's template constructor

  • Key: DDSPSMC-21
  • Legacy Issue Number: 16885
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    AnyDataReader::get is a member template function, which requires passing a type to retrieve a typed data-reader. For example,

    AnyDataReader adr;
    DataReader<RadarTrack> dr = adr.get<RadarTrack>();

    It is better to pass the topic type instead of the data-reader type. For example,

    AnyDataReader adr;
    DataReader<RadarTrack> dr = adr.get<dds::sub::DataReader<RadarTrack> >();

    The first version is less error prone.

    Construction of AnyDataReader, however, does not look consistent with this use. Currently, the template constructor of the AnyDataReader accepts a data-reader as a type parameter (not just the topic type).

    Also, it is not consistent with AnyDataWriter constructor, which takes topic type as a type parameter.

    Resolution: Use the style of AnyDataWriter in AnyDataReader, AnyTopic, and AnyTopicDescription. I.e., Use the topic type as a type parameter for constructor and get() member function.

  • Reported: DDS-PSM-Cxx 1.0b1 — Fri, 9 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    The AnyDataWriter in AnyDataReader, AnyTopic, and AnyTopicDescription now use consistently the topic type as a type parameter for constructor and get() member function. Free function get() have also been added to avoid exotic C++ syntax under some circumstances.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Data access from DataReader using java.util.List

  • Key: DDSJAVA-4
  • Legacy Issue Number: 16056
  • Status: closed  
  • Source: Thales ( Andre Bonhof)
  • Summary:

    Currently the DataReader provides read() and take() methods that return a special type of java.util.ListIterator: Sample.Iterator. The Iterator is not the most convenient way to access data retrieved from the DataReader (e.g. an Iterator can only be traversed once).

    Propose to modify all read()/take() operations currently returning an Iterator to let them return a java.util.List. The List is more developer friendly, as it can be traversed multiple times and a List is also an Iterable with the added benefit that it can be used in Java’s “foreach” statement:

    List<Sample<TYPE>> data = dataReader.read();

    for (Sample<Type> sample : data)

    { // ... }

  • Reported: DDS-Java 1.0b1 — Thu, 10 Mar 2011 05:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    Merge this issue with #16321, which proposes other changes to the read/take overloads.
    • Overloads that return a loan should do so in the form of a ListIterator implementation, which will allows multiple forward and backward navigation of elements. The loaned samples should not be returned as a List, as retrieving an iterator from a list would force critical-path memory allocation—in direct contradiction of the low-latency goal of the loaning operations.
    • Overloads that return a copy should continue to accept a List to be filled in and should return a reference to the same list for convenience. These overloads will therefore support the “for-each” construct requested by this issue.
    Disposition: Merged with issue #16321
  • Updated: Fri, 6 Mar 2015 20:58 GMT

duplicate put definition resulting in a name clash

  • Key: DDSJAVA-3
  • Legacy Issue Number: 16050
  • Status: closed  
  • Source: Thales ( Andre Bonhof)
  • Summary:

    The ModifiableEntityQos contains put() definition that, after type erasure, cannot be distinguished from the inherited put definition in EntityQos (or the one inherited from Map) resulting in duplicate definitions of put: QosPolicy<?,?> put(QosPolicy.Id, QosPolicy<?,?>)

    Possible ways to resolve this:

    ·Drop the “extends Map” in EntityQos and put a dedicated get() in EntityQos and a dedicated put()/set() in ModifiableEntityQos and leave it up to the implementation on how to manage these values. This is the preferred solution as it prevents the user of the API to accidently use the Map inherited modification methods like put/remove/clear on a non-modifiable EntityQos.

    ·Modify the signature of put() in ModifiableEntityQos to match the inherited definitions in EntityQos and Map:

    public QosPolicy<?,?> put(QosPolicy.Id key, QosPolicy<?,?> value);

  • Reported: DDS-Java 1.0b1 — Thu, 10 Mar 2011 05:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    See the modifications described below.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Supporting automatic conversion from value types to delegate types

  • Key: DDSPSMC-14
  • Legacy Issue Number: 16405
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Supporting some vendor-specific extension api is significantly easier using automatic conversion from value types to the delegate types. The situation arises when an extension method defined in the idds namespace takes a parameter defined only in the idds namespace. The parameter type may also be used as a delegate elsewhere. While the programmers can use the -> operator to invoke the extension method, the parameter need must be obtained using the delegate() method of the value type. It would be quite seamless to support automatic convertibility from value types to the delegate.

    Proposed Solution:
    Define two additional generic conversion operators in dds::core::Value<D> template.

    operator D & ()

    { return d_; }
    operator const D & () const { return d_; }

    ;

  • Reported: DDS-PSM-Cxx 1.0b1 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    The suggested conversion operators have been added into the Value and Reference classes.
    See:
    dds-psm-cxx/src/hpp/dds/core/Reference.hpp
    dds-psm-cxx/src/hpp/dds/core/Value.hpp
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improving usability of EntityQoS API

  • Key: DDSPSMC-13
  • Legacy Issue Number: 16404
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    8. Supporting method chaining for setting qos parameters would improve readability of the API.

    For instance,
    DataWriterQos dwqos;
    dw >> dwqos;
    Dwqos.policy<History>().kind(KEEP_ALL).depth(200);
    Dwqos.policy<ResourceLimits>().max_samples(p).max_instances(q).max_samples_per_instance(r);
    dw << dwqos;

    Currently, it needs different function calls for every qos parameter.

    Proposed Solution: Change all the normative core qos policy classes (e.g., History, ResourceLimits) to return a reference to itself from the setters. Currently they return nothing.

  • Reported: DDS-PSM-Cxx 1.0b1 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    The problem raised has been addressed by equipping all the Policy classes with fluent setter methods. The example provided by this issue can now written as follows:

    DataWriterQos dwqos;
    dw >> dwqos;
    dwqos << History::KeepAll(200)
    << dwqos.policy<ResourceLimits>()
    .max_samples(p)
    .max_instances(q)
    .max_samples_per_instance(r);

    dw << dwqos;

    The changes applied to the given policy class P is to have its setter return P&.
    See dds-psm-cxx/blob/master/src/hpp/dds/core/policy/TCorePolicy.hpp
  • Updated: Fri, 6 Mar 2015 20:58 GMT

formal description of how topic types are mapped to Java classes needed

  • Key: DDSJAVA-2
  • Legacy Issue Number: 15968
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The DDS-PSM-Java currently provides examples of the the new mapping from the DDS type system to the Java programming language but does not provide a formal description of how topic types are mapped to Java classes. This underspecification should be filled to align the DDS-PSM-Java with the DDS-PSM-Cxx and to ensure that different/old mappings are used by DDS implementations.
  • Reported: DDS-Java 1.0b1 — Mon, 17 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

RadarTrack uses anonymous types

  • Key: DDSPSMC-17
  • Legacy Issue Number: 16563
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The RaderTrack uses an anonymous type in the example for plot on page 22
    of the beta 1 spec.

    So change

    struct RadarTrack

    { string id; long x; long y; long z; //@optional sequence<octet> plot; //@shared }

    ;

    To

    typdef sequence<octet> plot_type;
    struct RadarTrack

    { string id; long x; long y; long z; //@optional plot_type plot; //@shared }

    ;
  • Reported: DDS-PSM-Cxx 1.0b1 — Fri, 23 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    Insert required typedefs
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos in Value.hpp, Exception.hpp

  • Key: DDSPSMC-16
  • Legacy Issue Number: 16562
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:
    • hpp\dds\core\Value.hpp around line 67 added & to the return value:

    const D* operator->() const

    { return &d_; }

    2- same file, line 58, 62 added "const" to != and == operators
    bool operator==(const Value& other) const

    { return (d_ == other.d_); }

    bool operator !=(const Value& other) const

    { return !(d_ == other.d_); }

    3- hpp\tdds\core\qos\EntityQos.hpp line 88 added "const" to declaration

    const EntityQos& operator >> (POLICY& p) const {

    4- dds\core\policy\CorePolicy.hpp, line 38. name() method is not public.
    class policy_name<POLICY>

    { \ public: \ static const std::string& name(); \ }

    ;

    5- hpp\dds\core\Exception.hpp, line 202 wrong parameter type in the ctor
    InvalidDataError(const InvalidDataError& src);

    Proposed solution:

    Add the missing things.

  • Reported: DDS-PSM-Cxx 1.0b1 — Wed, 21 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    Add missing designators. Notice that as the final API does not include any implementation only designators have been addressed
  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL mapping for non-trivial struct fields

  • Key: DDSPSMC-19
  • Legacy Issue Number: 16565
  • Status: closed  
  • Source: Northrop Grumman ( Trent Nadeau)
  • Summary:

    The “representative” example in Section 8.2 is not very “representative”. For example, everything in the struct can be trivially returned by value (either a basic type or a pointer) with no impact on performance.

    If, instead, there were a substructure that was large and/or deeply nested, this example seems to break down. For example:

    typedef sequence<long, 1000000> HugeLongSeq; // 4 MB

    struct LargeStruct

    { long id; HugeLongSeq mySeq; }

    ;

    struct RadarTrack

    { string id; long x; long y; long z; //@optional sequence<octet> plot; //@shared LargeStruct myLargeMember; // new field }

    ;

    According to Section 7.4, the return value of the accessor for myLargeMember would either return by value or const reference. This would cause two copies (one for return value of getter and another for setter) of 4 MB of data in order to change one element of LargeStruct::mySeq in the instance.

    I believe that use cases like this require accessors that return by non-const reference if the generated code is to be at all efficient. On page 17 of the Beta 1 spec, there is already use of this pattern for the non-const accessors on the History class (where it probably makes less sense since the types are small). I believe that this pattern should also be used for generated code where many large types can be arbitrarily nested.
  • Reported: DDS-PSM-Cxx 1.0b1 — Fri, 23 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    This issue can be easily fixed by ensuring that constructed and sequence types have a reference return type as opposed to a const reference.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

optional support

  • Key: DDSPSMC-18
  • Legacy Issue Number: 16564
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS PSM does expose dds::core::optional to the end user when he uses
    @optional. At some moment we also have this available at the CCM level,
    what about using something that is not tied to DDS in the user defined
    type? Is there nothing in STL that can be used for this?
  • Reported: DDS-PSM-Cxx 1.0b1 — Fri, 23 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make parameter passing same for native/type parameters

  • Key: DDSPSMC-15
  • Legacy Issue Number: 16411
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We would like to propose to make the mapping for native and type parameters the same. So const T& for in and T/const T& for return. This makes the mapping easier and more consistent. For example the DDS InstanceHandle_t is defined as native, some vendors define it as long, some as a struct which leads to different code being generated when the end user has a local interface with a DDS InstanceHandle_t as argument. Also when the end user changes a typedef from a native to a struct the argument passing doesn't change from T to const T&. This doesn't impact performance in anyway, it just makes the mapping the same for all types

  • Reported: DDS-PSM-Cxx 1.0b1 — Mon, 1 Aug 2011 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0b2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implement Java5 Closeable interface

  • Key: DDSJAVAF2-3
  • Legacy Issue Number: 17302
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    DDS code will be easier to integrate into third-party I/O code if the Entity, ReadCondition, and TopicDescription interfaces implement the java.util.Closeable interface. This is especially true under Java 7, which provides specific new language constructs for dealing with this interface.

    The only method in the interface is a no-argument close(), which all of these interfaces already have.
  • Reported: DDS-Java 1.0b2 — Wed, 11 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0
  • Disposition Summary:

    Proposed Resolution:
    Update Entity, ReadCondition, and TopicDescription to inherit from java.io.Closeable.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Obsolete EntityQos interface name

  • Key: DDSJAVAF2-2
  • Legacy Issue Number: 17204
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The base interface for all Entity-level QoS objects (e.g. DataReaderQos) is org.omg.dds.core.EntityQos. At one time during the evolution of the specification, this interface was called org.omg.dds.core.Qos. Due to an editorial oversight, this obsolete name persists in the specification document and should be updated.

    • Section 7.2.5, "QoS and QoS Policies"
    • Section 7.2.5.2, "Entity QoS"
  • Reported: DDS-Java 1.0b2 — Wed, 29 Feb 2012 05:00 GMT
  • Disposition: Resolved — DDS-Java 1.0
  • Disposition Summary:

    Update the specification document.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Class for Query Expression

  • Key: DDSJAVAF2-1
  • Legacy Issue Number: 17065
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    ContentFiltered topics, QueryCondition, and MultiTopic all require a "Query" parameter made by an expression and a set of parameters. The current API, however treats the expression and the parameter as individual parameters and does not provide any abstraction of what could represent a generic DDS query. This makes the API more verbose and more error prone.

    Resolution
    ---------------
    Add a Query class that abstracts over the concept of a DDS query: an expression and a collection of mutable parameters
  • Reported: DDS-Java 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-Java 1.0
  • Disposition Summary:

    Add a Query class that abstracts over the concept of a DDS query: an expression and a collection of mutable parameters
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implement java.io.Closeable in Sample.Iterator

  • Key: DDSJAVAF2-6
  • Legacy Issue Number: 17415
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Java 7 has a try-with-resources construct that allows a close() method to be called automatically when a certain code block ends. Java PSM can support this construct with sample loans in a way that's backwards compatible with Java 5. All we have to do is to rename the Sample.Iterator.returnLoan() method to close() and make Sample.Iterator implement the interface java.io.Closeable. Note: java.lang.AutoCloseable is available only since 1.7

  • Reported: DDS-Java 1.0b2 — Fri, 8 Jun 2012 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0
  • Disposition Summary:

    Proposed Resolution:
    Inherit Sample.Iterator from Java.io.Closeable and rename the Sample.Iterator.returnLoan() method to close()
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update specification for final DDS-XTypes

  • Key: DDSJAVAF2-4
  • Legacy Issue Number: 17303
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The second FTF of the DDS-XTypes spec introduced several API changes that should be incorporated into the DDS-PSM-Java spec.

    At the same time, the contents of the relevant portions of the DDS-XTypes spec should be incorporated as JavaDoc comments, just as has already been done for DDS itself.
  • Reported: DDS-Java 1.0b2 — Wed, 11 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Redundant "QosPolicy" suffix on Policy Types

  • Key: DDSJAVAF2-7
  • Legacy Issue Number: 18285
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The dds-psm-java uses a superfluous "QoSPolicy" suffix to name the DDS policies which themselves are already included in a "policy" namespace.

    This issue is identical to issue #16530. This issue is created to revote on the decision taken on issue #16530 in the earlier FTF.

    Proposed Resolution:

    This suffix should be removed. This resolution will also make Java PSM consistent with the C++ PSM, which does not use "QosPolicy" suffix.
  • Reported: DDS-Java 1.0b2 — Fri, 30 Nov 2012 05:00 GMT
  • Disposition: Resolved — DDS-Java 1.0
  • Disposition Summary:

    This suffix should be removed. This resolution will also make Java PSM consistent with the C++ PSM, which does not use "QosPolicy" suffix. This issue requires no changes to the specification document
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update specification for final DDS-XTypes

  • Key: DDSPSMCF2-5
  • Legacy Issue Number: 17305
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The second FTF of the DDS-XTypes spec introduced several API changes that should be incorporated into the DDS-PSM-Cxx spec.
  • Reported: DDS-PSM-Cxx 1.0b2 — Wed, 11 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-PSM-Cxx 1.0
  • Disposition Summary:

    Update the DDS-PSM-Cxx API to reflect the finalization of the X-Type speficication.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improve compile-time type safety of EntityQos

  • Key: DDSJAVAF2-5
  • Legacy Issue Number: 17304
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The EntityQos interface implements java.util.Map. However, all checking of which policies apply to which Entity types is deferred to run time. The extension of Map should be updated to constrain which policies may legally be used.

    Proposal: Introduce marker interfaces for each Entity type and parameterize Map with these interfaces.
  • Reported: DDS-Java 1.0b2 — Wed, 11 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0
  • Disposition Summary:

    Introduce marker interfaces for each Entity type and parameterize Map with these interfaces. This issue requires no changes in the specification document.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Different applications in the same domain may associate the same Topic with different types

  • Key: DDSXTY-29
  • Legacy Issue Number: 16097
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Based on the DDS-XTypes specification, different applications in the same domain may associate the same Topic with different types. As a result through discovery it should be possible to find all such definitions. However this is not currently possible with the DDS v1.2 specification and the DDS-XTypes does not provide an extension for this API.
  • Reported: DDS-XTypes 1.0b1 — Fri, 25 Mar 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    The following resolution is related to the resolutions of issues #15702, #16007, and #16720.
    Abstract Model:
    A given topic is associated with one or more types. (This is a “topic” in the “virtual” system-wide sense independent of the way a topic is reflected through the API to any given component.) A given writer or reader endpoint is associated with one of the types of its topic.
    If a writer and a reader share the same topic, then it is assumed that they are intended to communicate with one another. At that point, the two endpoints are evaluated to make sure that they are type-compatible—see the resolution to issue #15702.
    On the Network:
    The Topic, Publication, and Subscription built-in topic data types already contain a type_name member. In addition, these data types shall contain a list of type definitions encapsulated in a TypeObject (defined in the resolution to issue #15702). In the Publication and Subscription cases, this “list” shall consist of only a single element. In the Topic case, it may consist of multiple elements.
    There is a related issue that will be addressed in the context of this issue, because it will improve matching performance and prepare the specification for the possibility of future support for polymorphic readers and writers: Today, the TypeObject type representation is not amenable to compact representation or fast comparison: types are identified by a “type ID” that an implementation can generate any way that it wishes. This approach has two weaknesses: (1) A definition is not self-contained—it requires a full tree of the types it uses to also be present. Also, (2) two types may be logically “equal” but may not have the same binary representation, because they refer to the “same” types by different indexes. Therefore, modify the TypeObject representation to replace ad hoc type indexes with deterministic hashes. (The lower-order 64-bits of an MD5 hash of the TypeObject representation of the type is sufficient: a system would require 1e6 types before it would have a 1e-6 probability of a collision. A full 128-bit hash could be used, but the overhead would be significant when data sample sizes are very small.) This change will address both of the above issues. It will also allow implementations to flexibly truncate the amount of detail they put on the network. The overhead can be further reduced if we assume that most members will be of primitive type—we can define a type ID as a union of a (small) primitive type ID and a (hashed, big) complex type ID.
    In the Application Code:
    As always, a Topic object is not the real virtual topic—it is only a local proxy. We retain the constraint that a single local Topic object is associated with only a single type. This constraint keeps the programming model the same for both XTypes-supporting and non-XTypes-supporting implementations, and it keeps the mental model simple for the majority of applications, which will not be aware of the presence of multiple types in their topics.
    To allow endpoints of the same virtual topic to be associated with different types, we make one change: The names of local Topic objects do not need to be unique within a given DomainParticipant, provided that all of those Topics of the same name really represent different slices of the same virtual topic—in other words, they must all have the same name.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS-XTypes @Key annotation Issue

  • Key: DDSXTY-28
  • Legacy Issue Number: 16007
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The @key annotation is currently defined as:

    @Annotation
    local interface Key

    { attribute boolean value default true; }

    ;

    Now suppose I have the following topic type:

    struct ATopicType

    { string a; @Key @ID(20) long b; long c; @Key @ID(10) }

    ;

    What is the key (a,b) or (b,a)? What if there were no annotations?

    The order of the key should be formally defined by the spec as this has an impact, among other things, on the computation of the keyhash.

    The rule could be as simple as taking the key element in the same order of the attribute ID. The other option is to extend the key to support a value, yet I think the first alternative is more orthogonal.
  • Reported: DDS-XTypes 1.0b1 — Wed, 2 Feb 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    The key hash is currently calculated in the following way, according to the DDS-RTPS specification:
    1. Serialize the key members…
    a. …in their declaration order
    b. …in big-endian CDR format
    2. If the serialization is less than or equal to 128 bits, that is the key hash.
    3. Otherwise, apply an MD5 hash to reduce the result to 128 bits.
    Update step (1a) above such that key fields are always serialized in ascending order by member ID rather than by declaration order. Note that this change applies only when calculating the key hash, not at any other time.
    This change is backwards compatible with pre-XTypes DDS implementations, because legacy type definitions will lack @ID annotations, and hence all members will always be in ascending ID order.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Can’t initialize TypeId from TypeKind

  • Key: DDSXTY-8
  • Legacy Issue Number: 15688
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    In the IDL definitions for the specification section Representing Types with TypeObject, the type TypeKind is declared to be an enumeration. The type TypeId is declared to be a typedef to long. Certain well-known TypeId values are initialized using TypeKind values. However, this causes compilation errors from some IDL compilers, which do not allow enumerated values to be assigned to integral constants.
    Resolution:
    Change TypeKind from an enumeration to a typedef to short.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    resolved
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Identifiers TypeId and Module collide with IDL keywords

  • Key: DDSXTY-9
  • Legacy Issue Number: 15689
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    In the IDL definitions for the specification section Representing Types with TypeObject:
    • The type “TypeId” collides with the IDL keyword “typeid.”
    • The type “Module” and its member “module” collide with the IDL keyword “module.”
    These collisions cause IDL compilation errors.
    Resolution:
    Escape the identifiers TypeId and Module by preceding them with underscores. Per the IDL specification, this lexical change does not impact the generated code.
    Rename the type member “module” to “mod” to prevent collisions either with the IDL keyword or with the name of the enclosing type.
    Revised Text:
    Replace the type identifier “TypeId” in the IDL file with “_TypeId” everywhere it occurs.
    Replace the type identifier “Module” in the IDL file with “_Module” everywhere it occurs.
    Replace the member identifier “module” (in the type “Module”) in the IDL file with “mod.”
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    resolved
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Don’t require CORBA namespace for primitive types in Plain Language Binding

  • Key: DDSXTY-23
  • Legacy Issue Number: 15703
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The Plain Language Binding relies on the IDL-to-C and IDL-to-C++ language mappings to generate programming APIs for these languages. Unfortunately, these mappings prefix all primitive type names with “CORBA,” which is incorrect and confusing for DDS users. For example:
    • DDS Int32 will become CORBA_Long in C.
    • DDS Float64 will become CORBA::Double in C++.
    Resolution:
    Update the Plain Language Binding for primitive types in C and C++ to place them in a conceptual “DDS” module instead of the current “CORBA” module. At the same time, rename them to be consistent with their names in the DDS type system—for example, “Int32” instead of “Long.” (The Plain Language Binding already makes several extensions to the IDL-to-C/C++ mapping specifications. This change would constitute one more.)
    These new primitive types must be compatible in size and representationwith the definitions in the Type System; these definitions will be provided in a table within the Plain Language Binding section. (As a side effect, they will also be compatible with to their CORBA-module counterparts, such that applications using both DDS and CORBA can assign from one to the other without type casts or loss of information.)
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Update the Plain Language Binding for primitive types in C and C++ to place
    them in a conceptual “DDS” module instead of the current “CORBA” module. At
    the same time, rename them to be consistent with their names in the DDS type
    system—for example, “Int32” instead of “Long.” (The Plain Language Binding
    already makes several extensions to the IDL-to-C/C++ mapping specifications.
    This change would constitute one more.)
    These new primitive types must be compatible with the definitions in the Type
    System; these definitions will be provided in a table within the Plain Language
    Binding section. (As a side effect, they will also be compatible with their CORBAmodule
    counterparts, such that applications using both DDS and CORBA can
    assign from one to the other without type casts or loss of information.)
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allow more flexible type consistency enforcement

  • Key: DDSXTY-22
  • Legacy Issue Number: 15702
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Summary:
    Section 7.6.1.3.1, TypeConsistencyEnforcementQosPolicy: Conceptual Model, identifies the type consistency enforcement kinds. This QoS policy is request-offer (RxO); readers and writers must match exactly in order to communicate. However, this requirement for an exact match is not required by implementations and is too restrictive for users.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    The resolution below is closely related to the resolutions of issues #16097 and #16561.
    The existing type consistency enforcement QoS policy, which governs both type signature consistency and type definition structural consistency, shall be simplified. It shall be removed from the Topic and DataWriter QoS and the corresponding built-in topic data types. It shall remain in the DataReader QoS and in the Subscription built-in topic data type. Its “kind” enumeration shall have the following values:
    • DISALLOW_TYPE_COERCION: The DataWriter and the DataReader must support the same data type in order for them to communicate.
    • ALLOW_TYPE_COERCION: The DataWriter and the DataReader need not support the same data type(s) in order for them to communicate as long as the reader’s type is assignable from the writer’s type.
    The default settings shall be as follows:
    • For compliant readers: ALLOW_TYPE_COERCION
    • Inferred for non-compliant readers: DISALLOW_TYPE_COERCION
    Type compatibility shall be determined according to the following steps:s
    1. The TypeObject type definition is considered first, provided that it is available for both the Publication and the Subscription. (This is anticipated to be the most common case for DDS-XTypes-conformant implementations.) If the Subscription allows type coercion, then its type must be assignable from the type of the Publication. If the Subscription does not allow type coercion, then its type must be equal to that of the Publication.
    2. If either the Publication or the Subscription does not provide any TypeObject definitions, then the type names are consulted. (This case is important in cases where a given component cannot, or does not wish to, provide concrete type definitions. For example, it may not support XTypes, it may wish to conserve bandwidth, it may not wish to reveal its type definition(s), or it may not even be type-aware—it may simply record binary payloads, for example.) The Subscription and Publication type_name fields must match exactly.
    If the reader and writer are not type-compatible, the middleware raises an INCONSISTENT_TOPIC status change.
    The following behaviors will result from the default values and evaluation orders above when writers and readers have default QoS:
    • Compliant writers will communicate with compliant readers. The reader will allow type coercion. This behavior is what we want, and it is unchanged from the current DDS-XTypes default.
    • Compliant writers will communicate with non-compliant readers. The reader will not allow type coercion, so the types (really the type names) must match exactly. This behavior is unchanged from the implied contract of DDS implementations prior to DDS-XTypes.
    (Suppose the writer has out-of-band knowledge of the reader’s type definition. If the writer determines that the types are not equal, it will consider the topic inconsistent and forbid communication. The reader will be unable to detect this inconsistency. However, the reader will not receive any data from the writer, so deserialization errors will be prevented just the same.)
    • Non-compliant writers will communicate with compliant readers. The reader will allow type coercion. This behavior provides maximum flexibility without requiring changes to deployed non-compliant applications.
    (Suppose the reader has out-of-band knowledge of the writer’s type definition. If the reader determines that the types are not assignable, the writer will be unable to detect this inconsistency and may send data to the reader nonetheless. The reader implementation will need to detect and eliminate this extraneous data without attempting to deserialize it—for example, by checking upon receiving the data from the socket whether the source data is actually from a matched writer. This edge case is little different from other preexisting cases, such as the use by a non-matching writer of a multicast address used by the reader. Therefore, it is not expected to be a barrier to implementation.)
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typographical errors

  • Key: DDSXTY-21
  • Legacy Issue Number: 15701
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification contains the following typographical errors:
    • Section 7.6.1.3.1, TypeConsistencyEnforcementQosPolicy: Conceptual Model, bullet EXACT_NAME: “…they’re structural definitions…” should be “…their structural definitions….”
    Resolution:
    Fix the errors as described above.
    Revised Text:
    Revisions are described in the summary above
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Fix the errors as described above.
    Note that the typo is section 7.6.1.3.1 will be addressed automatically by the resolution to issue #15702, which replaces the text is question. If no further typos are added to this issue, it can be closed as a duplicate of that issue.
    Revised Text:
    Revisions are described in the summary above.
    Disposition: Merged with issue 15702
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mutable structures with an empty intersection should not be considered assignable

  • Key: DDSXTY-20
  • Legacy Issue Number: 15700
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The type assignability rules for structure types (section 7.2.4.5, Aggregation Types) allow mutable types to be assigned in either direction, so long as there are no name, ID, or type conflicts among the types’ members. Unfortunately, these rules permit a degenerate case: two mutable types having no key members and no members in common will have no conflicts, and therefore will be considered assignable. However, readers will always observe every sample to have all default/empty contents.
    Resolution:
    Add an additional rule to the assignability determination to require that at least one member is in common.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add an additional rule to the assignability determination to require that at least
    one member is in common.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML representations should define namespaces

  • Key: DDSXTY-19
  • Legacy Issue Number: 15699
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Currently, the XML Type Representation and XML Data Representation do not define XML namespaces. This omission prevents XML documents of these types from being used in certain contexts, such as within XML catalogs or SOAP messages.
    Resolution:
    1. Specify the XML namespace for the XML Type Representation. This namespace shall be formed by appending the OMG document number of the specification to the OMG HTTP domain in the following way: http://www.omg.org/<TF or TC>/<year>/<month>/<document ordinal>/<section_name>. For example, the namespace for the beta 1 specification would be: http://www.omg.org/ptc/2010/05/12/XML_Type_Representation.
    2. Allow the association of a target namespace with the XSD Type Representation of a set of types, such that documents conforming to such type definitions may be properly validated against that namespace. This target namespace will be implied by the fully qualified name of each non-nested type, such that all DDS types, regardless of which Type Representation was used to define them, implicitly define a target namespace that can be used to validate XML Data Representation documentsThis mechanism will be specific to the XSD Type Representation; the concept of a target XML namespace will not be promoted into the Type System (or, by extension, into other Type Representations). (This implied target namespace will be a URN, not a URL; it will not be possible to dereference it.)
    2.3. Allow applications the choice of whether to include XML namespaces on the network. Split the XML Data Representation into two dialects: XML_VALID and XML_WELL_FORMED. The former will include explicit namespace declarations and properly qualify all element and attribute names. The latter will, for the sake of compactness, omit namespace information.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    1. Specify the XML namespace for the XML Type Representation. This
    namespace shall be formed by appending the OMG document number of the
    specification to the OMG HTTP domain in the following way:
    http://www.omg.org/<TF or TC>/<year>/<month>/<document
    ordinal>/<section_name>. For example, the namespace for the beta 1
    specification would be:
    http://www.omg.org/ptc/2010/05/12/XML_Type_Representation.
    2. Allow the association of a target namespace with the XSD Type
    Representation of a set of types, such that documents conforming to such
    type definitions may be properly validated against that namespace. If this
    target namespace is not specified explicitly, it shall be implied by the fully
    qualified name of each module, such that all DDS types, regardless of which
    Type Representation was used to define them, implicitly define a target
    namespace that can be used to validate XML Data Representation
    documents. The implied namespace shall take the form
    ddstype://www.omg.org/<module path>, where <module path> is a
    list of enclosing modules, separated by forward slashes, from outermost to
    innermost. (Note that this implied target namespace is a URN, not a URL; it
    will not be possible to dereference it.)
    3. Allow applications the choice of whether to include XML namespaces on the
    network. Split the XML Data Representation into two dialects: “valid” and “well
    formed.” The former will include explicit namespace declarations and properly
    qualify all element and attribute names. The latter will, for the sake of
    compactness, omit namespace information.
    With respect to (#2), the ability of an XSD author to explicitly specify a target
    namespace—rather than relying on a module-based implied namespace—is
    important to retain compatibility with the CORBA to WSDL/SOAP Interworking
    Specification, on which the XSD Type Representation depends. The authors of
    that specification explicitly chose not to support module-based namespaces for
    performance reasons, as described in section 4.1.4 of that specification.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide minimal backwards-compatible conformance point

  • Key: DDSXTY-25
  • Legacy Issue Number: 15705
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    One of the reasons for the development of the DDS-XTypes specification was the prior lack of explicitness and formality in the DDS type system and in its representations. DDS-XTypes addresses this need—and simultaneously extends both the type system and its representations. It would help the discourse about DDS systems, and the modeling of DDS systems, if a subset of DDS-XTypes were defined that identified only those parts of DDS and/or DDS-RTPS that were in broad use before the existence of DDS-XTypes.
    This subset would include the following:
    • A subset of the Type System:
    o The full set of primitive types
    o Strings of narrow or wide characters
    o Sequences
    o Aliases
    o Structures without inheritance and with “final” extensibility
    o Enumerations
    o Unions
    • The IDL Type Representation of the above
    • The CDR Data Representation of the above
    • The Plain Language Binding for the above
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Identify the above subset of the specification in a new, non-normative, annex
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide formal grammar for new IDL Type Representation constructs

  • Key: DDSXTY-24
  • Legacy Issue Number: 15704
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL Type Representation defines syntax for Type System concepts that were previously not expressible in IDL, such as annotations, maps, etc. This syntax is currently defined in prose and with examples. The specification should additionally provide a formal EBNF grammar.
    Resolution:
    Add EBNF grammar constructs to the relevant sections of the specification document.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add EBNF grammar productions to the relevant sections of the specification document.
    To avoid whitespace sensitivity in these productions, modify the Alternative (comment-like) Syntax when multiple annotations are applied. Instead of writing this:
    //@MyFirstAnnotation @MySecondAnnotation
    …write this:
    //@MyFirstAnnotation //@MySecondAnnotation
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improve support for shared data

  • Key: DDSXTY-27
  • Legacy Issue Number: 15707
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The Type System currently allows a type designer to specify that the storage for a type member may be located outside of the type itself. (This is an important capability when, for example, objects of the member’s type are very large.) However, it provides insufficient flexibility when such objects are stored in collections: the entire collection may be stored externally, but the collection members must be stored contiguously.
    Resolution:
    Enhance the Type System to allow collection elements to be shared, not just members of aggregation types. In the IDL Type Representation, this shall be expressed syntactically by the application of the built-in @Shared annotation to the collection member type.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Enhance the Type System to allow collection elements to be shared, not just members of aggregation types. In the IDL Type Representation, this shall be expressed syntactically by the application of the built-in @Shared annotation to the collection member type.
    Note that this resolution does not provide a general-purpose annotation facility for collection members. It merely provides an appropriate Type System property and Type Representation syntax to express it.
    Sequences:
    sequence<@Shared Foo, 42> sequence_of_foo;
    // or:
    sequence<
    Foo, //@Shared
    42
    > sequence_of_foo;
    Arrays:
    Foo array_of_foo @Shared [42];
    // or:
    Foo array_of_foo //@Shared
    [42];
    Maps:
    map<string, @Shared Foo, 42> map_of_string_to_foo;
    // or:
    map<
    string,
    Foo, //@Shared
    42
    > map_of_string_to_foo;
    Strings: Strings will not support this feature (i.e. individual characters cannot be stored externally to the string itself). Since string elements can only be individual narrow or wide characters, this “limitation” in theory is not expected to be a limitation in practice.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reduce size of DynamicData API

  • Key: DDSXTY-26
  • Legacy Issue Number: 15706
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The DynamicData class, part of the Dynamic Language Binding, has a huge API consisting of many dozens of methods. This large size makes the API harder to understand and reuse.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Change the design of the class to reduce the size of the API. Specifically:
    • Replace navigation by name, ID, or index with navigation by ID only. Provide conversion methods to obtain the ID based on either of the other two. When the object is of some type for which the concept of “member ID” is not applicable (e.g. sequences), the user can nevertheless convert from the index to a “member ID” and look up based on that. It is not necessary to specify the mapping from index to ID in such cases; all that matters is that the implementation can provide one. (Where the range of indexes and IDs overlap, the “mapping” could even be a no-op.)
    • Coalesce access to sequences and arrays.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect FooDataWriter overloads for built-in types

  • Key: DDSXTY-16
  • Legacy Issue Number: 15696
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The IDL file contains specializations of all of the type-specific interfaces for the new built-in types: “Foo”DataWriter and “Foo”DataReader. Some of these specializations contain additional “overloads” of DDS-standard types-specific methods for the sake of convenience. However, some of these overloads are not correct:
    • KeyedStringDataWriter::unregister_instance_w_key does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance method specified by DDS.)
    • KeyedStringDataWriter::unregister_instance_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance_w_timestamp method specified by DDS.)
    • KeyedStringDataWriter::dispose_w_key does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose method specified by DDS.)
    • KeyedStringDataWriter::dispose_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose_w_timestamp method specified by DDS.)
    • BytesDataWriter::write_string_w_bytes should be named BytesDataWriter::write_w_bytes (copy-paste error).
    • BytesDataWriter::write_string_w_bytes_w_timestamp should be named BytesDataWriter::write_w_bytes_w_timestamp (copy-paste error).
    • KeyedBytesDataWriter::unregister_instance_w_key does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance method specified by DDS.)
    • KeyedBytesDataWriter::unregister_instance_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance_w_timestamp method specified by DDS.)
    • KeyedBytesDataWriter::write_bytes_w_key doesn’t actually include the key among its arguments. It should.
    • KeyedBytesDataWriter::write_bytes_w_key_w_timestamp doesn’t actually include the key among its arguments. It should.
    • KeyedBytesDataWriter::dispose_w_key does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose method specified by DDS.)
    • KeyedBytesDataWriter::dispose_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose_w_timestamp method specified by DDS.)
    Resolution:
    Correct the method signatures as described in the summary above.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Correct the method signatures as described in the summary above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing definitions of TypeSupport specializations for built-in types

  • Key: DDSXTY-15
  • Legacy Issue Number: 15695
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The IDL file contains specializations of all of the type-specific interfaces for the new built-in types: “Foo”DataWriter and “Foo”DataReader. However, the FooTypeSupport definitions are not included. These specializations require no method overloads; however, they should be included for the sake of clarity and completeness.
    Resolution:
    Add the missing type definitions.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add the missing type definitions
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allow IDL compatibility pragma declarations to nest

  • Key: DDSXTY-18
  • Legacy Issue Number: 15698
  • Status: closed  
  • Source: Jackrabbit Consulting ( Dr. Robert (Nick) Stavros)
  • Summary:

    Section 7.3.1.1.2, Forward Compatibility with Respect to Compilers, defines a pragma declaration that IDL file authors can use to delimit portions of their IDL files that require certain versions of this specification. Especially since IDL files can include one another, it would be helpful if such pragma declarations were allowed to nest within one another.
    Resolution:
    Allow pragma declarations to nest.
    • Any version number specified by a nested pragma overrides the enclosing version number, if any.
    • Any unclosed declaration shall be considered to continue until the end of the input.
    In addition, the pragma “end” declaration shall—like the “begin” declaration—allow a version number to be specified to clarify the nesting relationship.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Allow pragma declarations to nest.
    • Any version number specified by a nested pragma overrides the
    enclosing version number, if any.
    • Any unclosed declaration shall be considered to continue until the end of
    the input.
    In addition, the pragma “end” declaration shall—like the “begin” declaration—
    allow a version number to be specified to clarify the nesting relationship.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consolidate IDL built-in annotations in machine-readable file

  • Key: DDSXTY-17
  • Legacy Issue Number: 15697
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification provides equivalent definitions for the built-in annotations defined by the IDL Type Representations. However, it only includes these in the specification document, not in the IDL file.
    Resolution:
    Add these definitions to the IDL file. Add this content as an additional annex in the specification document.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add these definitions to the IDL file. Add this content as an additional annex in
    the specification document
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Updated QoS definitions should be provided

  • Key: DDSXTY-14
  • Legacy Issue Number: 15694
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification dictates that the new QoS policies DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy apply to Topics, DataReaders, and DataWriters. These additions are reflected in the IDL file by the inclusion of corresponding members in the built-in topic data types TopicBuiltinTopicData, SubscriptionBuiltinTopicData, and PublicationBuiltinTopicData. Corresponding additions to TopicQos, DataReaderQos, and DataWriterQos are therefore implied, but updated definitions of those types are not provided in the IDL file.
    Resolution:
    Add the missing type definitions to the IDL file.
    The type extensibility kinds of the QoS structures should be MUTABLE to be consistent with the built-in topic data types, which are also containers of QoS policies and which have that extensibility kind.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add the missing type definitions to the IDL file.
    The type extensibility kinds of the QoS structures should be MUTABLE to be
    consistent with the built-in topic data types, which are also containers of QoS
    policies and which have that extensibility kind.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Extensibility kinds of new QoS policies are not specified in a consistent way

  • Key: DDSXTY-13
  • Legacy Issue Number: 15693
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The IDL file augments the DDS-standard QoS policies with meta-data defined by this specification in a way that is consistent with the serialization of those policies as defined by the DDS-RTPS specification. Specifically, it defines each policy to be “nested” (meaning that it is intended to be propagated only when contained within another type) to have an extensibility kind of EXTENSIBLE (meaning that members can be appended to the end of the type, but that members cannot be inserted in the middle or reordered).
    In contrast, the two new QoS policies introduced by the specification—DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy—are defined to be nested, but their extensibility kinds are not specified. Per this specification, the kind EXTENSIBLE will be inferred by default but could be overridden by implementations. In order to be clear and avoid potential interoperability problems, these types should explicitly specify the extensibility kind EXTENSIBLE, just as all other policies do.
    Resolution:
    Add the built-in annotation @Extensibility(EXTENSIBLE_EXTENSIBILITY) to the definitions of DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy in the IDL file.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add the built-in annotation @Extensibility(EXTENSIBLE_EXTENSIBILITY)
    to the definitions of DataRepresentationQosPolicy and
    TypeConsistencyEnforcementQosPolicy in the IDL file.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unclear member names when programming language doesn’t support typedef

  • Key: DDSXTY-11
  • Legacy Issue Number: 15691
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Summary:
    In the IDL definitions for the specification section Representing Types with TypeObject, some members of type MemberId are named simply member, and some members of type TypeId are named simply type. The fact that the integral types of these members represent IDs is clear to readers of the IDL or to readers of generated code in languages that support typedef (such as C), because the type name is explicit. However, in Java and other programming languages that do not support typedef, the types of these members degrades to simply int (or another built-in integral type). This type obscures the meanings of the members.
    Resolution:
    Name the members in question more explicitly: member_id and type_id.
    Revised Text:
    Rename the following type members in the IDL file:
    • AnnotationUsageMember::member ? AnnotationUsageMember::member_id
    • AnnotationUsage::type ? AnnotationUsage::type_id
    • TypeProperty::id ? TypeProperty::type_id
    • MemberProperty::id ? MemberProperty::member_id
    • MemberProperty::type ? MemberProperty::type_id
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Name the members in question more explicitly: member_id and type_id.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of built-in IDL annotation @Shared is missing

  • Key: DDSXTY-10
  • Legacy Issue Number: 15690
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The Type System defines a type member attribute shared, which indicates that a member should be stored by reference instead of by value to enable the use of external stores—for example, for large data members. This attribute appears in the TypeObject IDL definitions as a built-in annotation @Shared. However, this built-in annotation is never formally defined. (Possibly, it was deleted accidentally in a previous revision of the specification document.)
    Resolution:
    Add a section defining this built-in annotation to section 7.3.1.3, Built-in Annotations.
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add a section defining this built-in annotation to section 7.3.1.3, Built-in Annotations.
    Issue 15707, Improve support for shared data, needs to update the description of this new section. The FTF should not create the section in this issue only to modify it in that one. Rather, we should merge this issue with that one and make the entire change in one place.
    Revised Text:
    See issue 15707.
    Disposition: Merged with issue 15707
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of type “Parameters” inadvertently missing

  • Key: DDSXTY-12
  • Legacy Issue Number: 15692
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The IDL definition of the type AnnotationDescriptor from the section Representing Types with TypeObject depends on a typedef “Parameters,” which is an alias to a string-to-string map. This type definition was present in earlier revisions of the IDL file but was inadvertently deleted in the adopted revision.
    Resolution:
    Restore the missing type definition.
    Revised Text:
    Add the following definition immediately before AnnotationDescriptor in the IDL file:
    typedef map<ObjectName, ObjectName> Parameters;
  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Restore the missing type definition.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DD 1.0 defines DI, DC, DG as Models which is not in the CMOF subset for MOF 2.4.1

  • Key: DD11-16
  • Legacy Issue Number: 18954
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    DD 1.0 defines DI, DC, DG as Models which is not in the CMOF subset for MOF 2.4.1
  • Reported: DD 1.0 — Mon, 23 Sep 2013 04:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    This is a change to the DD XMI to replace Models with Packages. There is no change to the primary specification.
    Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Styling capabilities of Canvas ambiguous

  • Key: DD11-15
  • Legacy Issue Number: 18679
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Max Bureck)
  • Summary:

    The description of the Canvas element does not say how attributes inherited from GraphicalElement are handled. Since the Canvas explicitly references a background color and a fill, I assume that the attributes "sharedStyle" and "localStyle" are only taken into account for calculation of an effective style of child elements. Since the canvas defines a background, I guess it should fill the parent UI control, so a clip path wouldn't make much sense. Since transforms can also be applied to the fill of an application, I guess the transforms are just applied to the group of containing children. Please clarify, if this assumptions are correct.
  • Reported: DD 1.0 — Mon, 22 Apr 2013 04:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Since canvases are groups, they inherit the fact that "The (local or shared) styles defined on a group cascade to its member elements" (see Subclause 10.3.12), that is, the styles are not for the group itself (the revision below spells out the meaing of "cascade"). Conversely, canvases support background colors and fills for themselves (backgroundColor and backgroundFill), as opposed to their members.
    Graphical elements, including canvases, can have clip paths applied to them to restrict painting (for example, applying an oval mask to a background). This is separate from the fact that canvases, as groups, are lower in z-order than their members and therefore appear to be additionally clipped by their members.
    Fills can have transforms (Fill::transform) to change how they are applied on their graphical elements. This is separate from transforms on graphical elements (GraphicalElement:transform), which apply to graphical elements themselves.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MarkedElement should be abstract in provided CMOF files

  • Key: DD11-14
  • Legacy Issue Number: 18675
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Max Bureck)
  • Summary:

    In the standard the description of MarkedElement states "It is an abstract super class of all graphical elements whose vertices are explicitly specified and ordered.". However the heading declares "[Class]", which is inconsistent with the naming of other classes. The heading should declare it "[Abstract Class]". And in the CMOF files the MarkedElement is not modeled as an abstract class.
  • Reported: DD 1.0 — Wed, 17 Apr 2013 04:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Revise as suggested
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use MOF Primitive Types

  • Key: DD11-13
  • Legacy Issue Number: 17453
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Diagram Common should reuse MOF Primitive Types
  • Reported: DD 1.0 — Thu, 21 Jun 2012 04:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Remove DD primitive types and import UML PrimitiveTypes into DC
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DG library for BNF parsing

  • Key: DD11-12
  • Legacy Issue Number: 17147
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    A DG library for BNF parsing would enable language-specific DI's capture strings, instead of modeling BNF constraints.

  • Reported: DD 1.0 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Yes, but it would not be a DG library. It would be provided by the mapping language used between DI and DG, which is it is not defined by DD.
    Disposition: Closed No Change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Z-order in DC -> DI and DG

  • Key: DD11-9
  • Legacy Issue Number: 16910
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Section 8.1.3 (Z-Order) should be specific to the ownership association on DiagramElement to itself, and should be moved to DI and DG.

  • Reported: DD 1.0 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    This is merged with 16909, which addresses the same topic.
    Disposition: Duplicate/Merged
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DiagramElement ownership

  • Key: DD11-8
  • Legacy Issue Number: 16909
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    In Figure 9.2 (Diagram Element) DiagramElement ownership should be ordered and given occlusion semantics, per Section 8.1.3 (Z-Order).

  • Reported: DD 1.0 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Add ordering to DI::DiagramElement::/ownedElement ordered. Move Clause 8.1.3 (Z-Order) to the description of DiagramElement::/ownedElement, modified for diagram elements, and also to DG::Group::member, modified to diagram graphics
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DiagramElements cannot represent multiple model Elements

  • Key: DD11-5
  • Legacy Issue Number: 16628
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Christopher McClure)
  • Summary:

    The definition of DiagramElement has an association to the depicted MOF Element with a multiplicity of [0..1]; so, one DiagramElement can represent at most one model Element. However, UML contains at least one notation in which a single symbol represents more than one Element: using a single State symbol to represent multiple similar States (see p.601 of the UML 2.4 Superstructure Specification). Will DD be able to support this notation?

  • Reported: DD 1.0b1 — Tue, 18 Oct 2011 04:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Loosen multiplicity of DiagramElement::/modelElement property to *. Also resolves 16907 by using UML::Element instead of CMOF::Element in the Diagram Interchange metamodel
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DG library for string bounding

  • Key: DD11-11
  • Legacy Issue Number: 17099
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Is a DG library needed to calculate bounding boxes for strings in particular fonts?

  • Reported: DD 1.0 — Wed, 8 Feb 2012 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    No, would be provided by the mapping language used between DI and DG, which is it is not defined by DD.
    Disposition: Closed No Change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple modelElements per diagram element

  • Key: DD11-10
  • Legacy Issue Number: 16991
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Diagram elements might have multiple modelElements (for example, state lists in UML state machines, combined merge/decision diamonds in UML activities). Languages can specialize to 1 or order as needed.

  • Reported: DD 1.0 — Wed, 11 Jan 2012 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    This duplicates 16628.
    Disposition: Duplicate/Merged
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure A.1 multiplicities

  • Key: DD11-7
  • Legacy Issue Number: 16908
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Figure A.1 (UML DI Metamodel), the multiplicities opposite UMLLabel should be 0..1.

  • Reported: DD 1.0 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Revise as suggested.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CMOF version

  • Key: DD11-6
  • Legacy Issue Number: 16907
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    DD should use the latest formal version of CMOF
  • Reported: DD 1.0 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    See resolution of 16628.
    Disposition: Merge/Duplicate
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Simplify DI metamodel

  • Key: DD-1
  • Legacy Issue Number: 15902
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The DI metamodel can be simplified by removing
    planes (diagrams can be nested) and leaving
    packaging out of scope (DiagramCollection, and
    the association between Diagram and Style).

  • Reported: DD 1.0b1 — Wed, 15 Dec 2010 05:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    The DI metamodel is simplified by merging planes and plane elements into diagrams and diagram elements, respectively, and removing labels and diagram collections
    Planes are removed. These were to support nested diagrams, but it was decided the additional layer of terminology wasn't necessary, especially when some communities simply call them "nested diagrams". In the revised text, diagrams can be nested. Top level diagrams are those diagrams that happen not to be nested. We discussed various possibilities for modeling this, and settled on treating everything as a nestable diagram element, including diagrams, which are taken as a kind of shape. This means diagrams can have model elements, for example, as in UML composite structure. Top level diagrams won't use bounds. Diagrams can be connected by edges, for diagrams of diagrams.
    Labels are removed. The only difference from shapes is they are rendered as strings, which would often be determined by the mapping to DG. Language-specific DI's can define these as kinds of shapes if needed.
    It was decided that packaging should be out of scope, because domain languages usually have their own packaging mechanisms, resulting in these changes:
    The existing association between Diagram and Style is removed, because it was only packaging styles, it didn't mean styles applied to the diagram, like the association between DiagramElement and Style, which Diagram now inherits.
    DiagramCollection is removed, and its packaging associations to Style.
    Packaging of styles is left in Diagram Graphics, because DG is not intended to extend a domain language that might have its own packaging mechanism.
    Updates to the Annexes for these changes will be addressed in separate issues.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interchange extension

  • Key: DD-6
  • Legacy Issue Number: 16001
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The last pagraph of the DiagramElement section says:

    Other properties of diagram elements that tools need to interchange
    but are not defined in the metamodel can be interchanged using the
    extensibility mechanism that is native to the used interchange
    format. For example, in an XMIbased interchange, extended data can be
    placed on diagram elements within <xmi:extension> tags.

    I'm not sure we should be mentioning interchange level extensions,
    especially without mentioning metamodel extensions, and domain-specific
    extensions like profiles. Can we remove this paragraph, or generalize
    it to include other kinds of extension mechanisms?

  • Reported: DD 1.0b1 — Mon, 31 Jan 2011 05:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    The specification should not suggest ways of interchanging non-standard information
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diagram::resolution default

  • Key: DD-5
  • Legacy Issue Number: 15997
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The default for Diagram::resolution should be shown in the metamodel figures.

  • Reported: DD 1.0b1 — Mon, 31 Jan 2011 05:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    It is shown in Figure 9.3 (Diagram).
    Revised Text:
    None

    Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bounds should be optional

  • Key: DD-4
  • Legacy Issue Number: 15996
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    For example, as in compartmented property strings
  • Reported: DD 1.0b1 — Mon, 31 Jan 2011 05:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    Agreed that Shape::bounds should be optional. This is addressed in the resolution to 15902.
    Revised Text:
    None

    Disposition: Duplicate
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Waypoints should be optional

  • Key: DD-3
  • Legacy Issue Number: 15995
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Some tools might autoplace edge end points.

  • Reported: DD 1.0b1 — Mon, 31 Jan 2011 05:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    Agreed that Edge::waypoints should be optional. This is addressed in the resolution to 15902.
    Revised Text:
    None

    Disposition: Duplicate
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Diagram metaclass should be abstract

  • Key: DD-2
  • Legacy Issue Number: 15994
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The other DI classes are abstract.

  • Reported: DD 1.0b1 — Mon, 31 Jan 2011 05:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    Agreed that it should be abstract. This is addressed in the resolution to 15902.
    Revised Text:
    None

    Disposition: Duplicate
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update Annex A

  • Key: DD-11
  • Legacy Issue Number: 16372
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Update Annex A (UML Diagram Definition Example) for the changes in FTF ballot 1 and complete the example.

  • Reported: DD 1.0b1 — Tue, 19 Jul 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    Add a small example defining a subset of the UML Class diagram with DD
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Merge DI diagrams

  • Key: DD-10
  • Legacy Issue Number: 16371
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    After the first FTF ballot, the DI diagrams are small enough to be merged into one
  • Reported: DD 1.0b1 — Tue, 19 Jul 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    The DI metamodel is indeed small enough after Ballot 1 that all concepts can fit in one diagram.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Cascade specification in DG isn't as specific as DI

  • Key: DD-9
  • Legacy Issue Number: 16252
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Cascade specification in DG isn't as specific as DI. DG should align with DI (local overrides shared overrides inherited), so the mapping from DI to DG won't need to repeat the cascade algorithm. Multiple styles in DG can be ordered to resolve conflicts
  • Reported: DD 1.0b1 — Tue, 17 May 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    The algorithms only appear different because of a typographic error.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename DG::Canvas::style to packagedStyle

  • Key: DD-8
  • Legacy Issue Number: 16251
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Rename DG::Canvas::style to packagedStyle (and fills and markers) to clarify it is not applied to the canvas, like the one inherited from GraphicalElement::localStyle.

  • Reported: DD 1.0b1 — Tue, 17 May 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    Rename all the composite associations on Canvas to have a “packaged” prefix
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DG::GraphicalElement::local/sharedStyle should have unbounded upper multiplicity

  • Key: DD-7
  • Legacy Issue Number: 16250
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    DG::GraphicalElement::local/sharedStyle should have unbounded upper multiplicity, to enable DI and the mapping to DG to both introduce styles. The style properties from these two sources might overlap for properties with upper multiplicity greater than one. Use ordering to prioritize styles in case of conflict.

  • Reported: DD 1.0b1 — Tue, 17 May 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    Change the multiplicities as suggested above, and explain the use case.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optional bounds

  • Key: DD-15
  • Legacy Issue Number: 16389
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    After 15996, bounds should not be required, for example, search on "with a given bounds". Explain that if DI does not specify bounds, then the mapping to DG does.

  • Reported: DD 1.0b1 — Fri, 22 Jul 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    The only text remaining after 15902 that implies the presence of bounds is examples were bounds is supposed to be specified.
    Revise the description of bounds to indicate it is optional.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Cascading called inheritance

  • Key: DD-14
  • Legacy Issue Number: 16388
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The spec sometimes refers to style cascading incorrectly as inheritance. Inheritance applies to classes, cascading applies to instances. Search on "inherit" to find them.

  • Reported: DD 1.0b1 — Fri, 22 Jul 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    Revise as suggested
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Owning styles

  • Key: DD-13
  • Legacy Issue Number: 16387
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    After issue 15902, the spec should not refer to owning styles, for example, see DI, DiagramElement, fourth paragraph, next to last sentence, and DI, Style, second paragraph, first sentence.

  • Reported: DD 1.0b1 — Fri, 22 Jul 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    Revise as suggested
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF Compliance

  • Key: DD-12
  • Legacy Issue Number: 16386
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Update for compliance with MOF 2.4 (for example UML:Element instead of MOF:Element), and change text to not refer to MOF, just "metamodel extension".

  • Reported: DD 1.0b1 — Fri, 22 Jul 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    MOF 2.4 is not formalized yet. It is valid to leave the property typed by CMOF::Element as it is the super class of all metaclasses. We should add a package import from DI to CMOF to make the dependency explicit.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Spurious question marks

  • Key: DD-18
  • Legacy Issue Number: 16408
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Remove "?"s before attribute names
  • Reported: DD 1.0b1 — Sun, 31 Jul 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    The “•” (composition) symbols got replaced by “?” symbols by mistake during the editing process of the Beta 2 specification. The fix is to restore the “•” symbols

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optional waypoints

  • Key: DD-17
  • Legacy Issue Number: 16392
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    After 15959, multiple waypoints should not be required, for example, see DI Edge, first paragraph, and in the attribute description.

  • Reported: DD 1.0b1 — Sun, 24 Jul 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    Revise and suggested.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Visibility markers not needed

  • Key: DD-19
  • Legacy Issue Number: 16409
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Would be easier to read the specification with the "+" visibilitiy markers in the figures and attribute/association sections.

  • Reported: DD 1.0b1 — Sun, 31 Jul 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    We agree with the proposal to remove the visibility symbol as it is not relevant for metamodels
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diagram description

  • Key: DD-21
  • Legacy Issue Number: 16485
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Some of the clause 9.3.1 description is redundant with 8.1.3, and it does not make sense after changes from ballot 1.

  • Reported: DD 1.0b1 — Thu, 4 Aug 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    Remove the redundant paragraph as suggested
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Collections => sets

  • Key: DD-20
  • Legacy Issue Number: 16410
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Collections should be called sets, except when they are non-unique
  • Reported: DD 1.0b1 — Sun, 31 Jul 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    The word collection is valid as it is a generic way of describing sets, lists, sequences...etc. All metamodel properties are already annotated with the specific kinds of collections.
    Disposition: Closed, No Change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex B

  • Key: DD-16
  • Legacy Issue Number: 16390
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Update or remove Annex B (DG to SBV Mapping).
  • Reported: DD 1.0b1 — Fri, 22 Jul 2011 04:00 GMT
  • Disposition: Resolved — DD 1.0
  • Disposition Summary:

    Remove the annex until we have content for it.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Move generic interaction support (GIS) to the CCM specification

  • Key: DDS4CCM11-12
  • Legacy Issue Number: 15964
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The current DDS4CCM specification is made of two parts

    1) Description of a generic interaction support (GIS) allowing to define extended ports and connectors

    2) Use of this GIS to define extended ports and connectors dedicated to DDS.

    The first part (GIS) has been designed in purpose of supporting all future CCM extensions and would be better placed in the CCM specification.

    Proposal is therefore to move it from DDS4CCM to CCM.

    ––––-

    Severity I guess is minor as it does not affect at all the ability to implement. Actually it could have been treated as éditorial apat the point of revisiting compliance...
  • Reported: DDS4CCM 1.0 — Mon, 17 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.1
  • Disposition Summary:

    Move the GIS section as a sub-section in CORBA – Part 3 / Component Model
    Rationale for the move: The GIS is not at all specific to DDS-related extended ports and connectors and will be used for other CCM extensions.
    Rationale for keeping the addition in a single CCM sub-section: It is easier to understand the purpose of the extension and to set it as optional.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

proposed simple spec extension for common DDS use case

  • Key: DDS4CCM11-11
  • Legacy Issue Number: 18992
  • Status: open  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In paragraph 7.2.2.1.2, a note about interface Reader says:

    << Note: This interface is the basis for a passive data reader (i.e. a component that just looks at the data as they are). It is also very useful for the reactive data getters (i.e. components that need to react to new data, whether they choose to get them in pull mode or be notified in push mode) in their initialization phase. This is the reason why all the DDS ports on the subscribing side will embed a Reader basic port.>>

    This note may let people think that it is ONLY useful in initialisation phase, which is not true. A clarification sentence would avoid that misunderstanding.
  • Reported: DDS4CCM 1.1 — Wed, 9 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The model file ptc/11-02-11 is not valid UML – it has eclipse namespace and extraneous elements

  • Key: DDS4CCM11-10
  • Legacy Issue Number: 16092
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The model file ptc/11-02-11 is not valid UML – it has eclipse namespace and extraneous elements
  • Reported: DDS4CCM 1.0 — Mon, 21 Mar 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify Writer liveliness mechanism

  • Key: DDSIRTP2-5
  • Legacy Issue Number: 11031
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The current Writer liveliness mechanism piggybacks on SPDP messaging. As RTPS should also be able to support other discovery protocols beyond SPDP, including a static configuration, this is not the best approach.
    It is true that all implementations must support at least SPDP, but if a customer wants to disable it (e.g. no need to interoperate with a different vendor so it possible to use a different protocol exclusively), this should not affect the DW liveliness mechanism. To some extent, it does not, but sending SPDPDiscoveredParticipantData to maintain a DWs liveliness is wasteful, especially if SPDP is not even used.
    Resolution:
    Update the Writer liveliness protocol to be independent of Discovery.
    Revised Text:
    Since this change is lengthy, the editorial instructions appear in a blue font to help the reader distinguish them from document content.

    · Section 8.7.2.2.3, first paragraph, first bulleted item, replace:

    DDS_AUTOMATIC_LIVELINESS_QOS : liveliness is maintained through the SPDPbuiltinParticipantWriter. For a given Participant, in order to maintain the liveliness of its Writer Entities with LIVELINESS QoS set to AUTOMATIC, implementations must refresh the Participant's liveliness (i.e., send the SPDPDiscoveredParticipantData) at a rate faster than the smallest lease duration among the Writers.

    with:

    DDS_AUTOMATIC_LIVELINESS_QOS : liveliness is maintained through the BuiltinParticipantMessageWriter. For a given Participant, in order to maintain the liveliness of its Writer Entities with LIVELINESS QoS set to AUTOMATIC, implementations must refresh the Participant's liveliness (i.e., send the ParticipantMessageData, see Section 8.4.13.5 for details) at a rate faster than the smallest lease duration among the Writers.

    · Section 8.7.2.2.3, first paragraph, first bulleted item, replace:

    DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS : liveliness is maintained through the SPDPbuiltinParticipantWriter. If the Participant has any MANUAL_BY_PARTICIPANT Writers, implementations must check periodically to see if write(), assert_liveliness(), dispose(), or unregister_instance() was called for any of them. The period for this check equals the smallest lease duration among the Writers. If any of the operations were called, implementations must refresh the Participant's liveliness (i.e send the SPDPDiscoveredParticipantData) and add the PID_PARTICIPANT_MANUAL_LIVELINESS_COUNT in-line QoS, where the value of the in-line QoS is incremented each time.

    with:

    DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS : liveliness is maintained through the BuiltinParticipantMessageWriter. If the Participant has any MANUAL_BY_PARTICIPANT Writers, implementations must check periodically to see if write(), assert_liveliness(), dispose(), or unregister_instance() was called for any of them. The period for this check equals the smallest lease duration among the Writers. If any of the operations were called, implementations must refresh the Participant's liveliness (i.e send the ParticipantMessageData, see Section 8.4.13.5 for details).

    · Section 8.5.2, change the title from "RTPS built-in Endpoints" to "RTPS built-in Discovery Endpoints"
    · Add the following row to the end of Table 8.50:

    ParticipantMessageData Type used to hold data exchanged between Participants. The most notable use of this type is for the Writer Liveliness Protocol.

    · Insert new Section following 8.4.12 (so a new 8.4.13) with the following content:

    8.4.13 Writer Liveliness Protocol
    The DDS specification requires the presence of a liveliness mechanism. RTPS realizes this requirement with the Writer Liveliness Protocol. The Writer Liveliness Protocol defines the required information exchange between two Participants in order to assert the liveliness of Writers contained by the Participant.

    All implementations must support the Writer Liveliness Protocol in order to be interoperable.

    8.4.13.1 General Approach
    The Writer Liveliness Protocol uses pre-defined built-in Endpoints. The use of built-in Endpoints means that once a Participant knows of the presence of another Participant, it can assume the presence of the built-in Endpoints made available by the remote participant and establish the association with the locally-matching built-in Endpoints.

    The protocol used to communicate between built-in Endpoints is the same as used for application-defined Endpoints.

    8.4.13.2 Built-in Endpoints required by the Writer Liveliness Protocol
    The built-in Endpoints required by the Writer Liveliness Protocol are the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader. The names of these Endpoints reflect the fact that they are general-purpose. These Endpoints are used for liveliness but can also be used for other data in the future.

    The RTPS Protocol reserves the following values of the EntityId_t for these built-in Endpoints:
    ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER
    ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER

    The actual value for each of these EntityId_t instances is defined by each PSM.

    8.4.13.3 BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader QoS
    For interoperability, both the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader use the following QoS values:
    · reliability.kind = RELIABLE_RELIABILITY_QOS
    · durability.kind = TRANSIENT_LOCAL_DURABILITY_QOS
    · history.kind = KEEP_LAST_HISTORY_QOS
    · history.depth = 1

    8.4.13.4 Data Types associated with the built-in Endpoints used by the Writer Liveliness Protocol

    Each RTPS Endpoint has a HistoryCache that stores changes to the data-objects associated with the Endpoint. This is also true for the RTPS built-in Endpoints. Therefore, each RTPS built-in Endpoint depends on some DataType that represents the logical contents of the data written into its HistoryCache.

    Figure X defines the ParticipantMessageData DataType associated with the RTPS built-in Endpoints for the "DCPSParticipantMessage" Topic.

    Figure X The ParticipantMessageData structure.

    8.4.13.5 Implementing the Writer Liveliness Protocol using the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader

    The liveliness of a subset of Writers belonging to a Participant is asserted by writing a sample to the BuiltinParticipantMessageWriter. If the Participant contains one or more Writers with a liveliness of AUTOMATIC_LIVELINESS_QOS then one sample is written at a rate faster than the smallest lease duration among the Writers sharing this QoS. Similarly, a separate sample is written if the Participant contains one or more Writers with a liveliness of MANUAL_BY_PARTICIPANT_LIVELINESS_QOS at a rate faster than the smallest lease duration among these Writers. The two instances are orthogonal in purpose so that if a Participant contains Writers of each of the two liveliness kinds described, two separate instances must be periodically written. The instances are distinguished using their DDS key which is comprised of the participantGuidPrefix and the kind fields. Each of the two types of liveliness QoS handled through this protocol will result in a unique kind field and therefore form two distinct instances in the HistoryCache.

    In both liveliness cases the participantGuidPrefix field contains the GuidPrefix_t of the Participant that is writing the data (and therefore asserting the liveliness of its Writers).

    The DDS liveliness kind MANUAL_BY_TOPIC_LIVELINESS_QOS is not implemented using the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader. It is discussed in Section 8.7.2.2.3.

    · Add the following entries to Table 9.2

    BuiltinParticipantMessageWriter ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER =

    {00,02,00,C2}

    BuiltinParticipantMessageReader ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER =

    {00,02,00,C7}

    · Insert a new Section 9.6.2.1 with the following content:

    9.6.2.1 Data representation for the ParticipantMessageData built-in Endpoints
    The Behavior Module within the PIM (Section 8.4) defines the DataType ParticipantMessageData. This type is the logical content of the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader built-in Endpoints.

    The PSM maps the ParticipantMessageData type into the following IDL:

    struct ParticipantMessageData

    { KeyHashPrefix_t participantGuidPrefix; KeyHashSuffix_t kind; sequence<octet> data; }

    ;

    The DDS key consists of the both the participantGuidPrefix and the kind fields. On the wire, the participantGuidPrefix and the kind are not serialized as part of the ParticipantMessageData because they are already explicitly serialized as part of the Data Submessage (see Section 8.3.7.2).

    The following values for the kind field are reserved by RTPS:

    #define PARTICIPANT_MESSAGE_DATA_KIND_UNKNOWN

    {0x00,0x00,0x00,0x00}

    #define PARTICIPANT_MESSAGE_DATA_KIND_AUTOMATIC_LIVELINESS_UPDATE

    {0x00,0x00,0x00,0x01}

    #define PARTICIPANT_MESSAGE_DATA_KIND_MANUAL_LIVELINESS_UPDATE

    {0x00,0x00,0x00,0x02}

    RTPS also reserves for future use all values of the kind field where the most significant bit is not set. Therefore:

    kind.value[0] & 0x80 == 0 // reserved by RTPS
    kind.value[0] & 0x80 == 1 // vendor specific kind

    Implementations can decide the upper length of the data field but must be able to support at least 128 bytes.

    Following the CDR encoding, the wire representation of the ParticipantMessageData structure is:

    0...2...........8...............16.............24...............31
    ------------------------------------------------------+

    unsigned long data.length

    ------------------------------------------------------+

     

    ~ octet[] data.value ~

     

    ------------------------------------------------------+

    · Insert a new Section called 9.6.2.2
    Use the contents of Section 9.6.2 from the start until the beginning of Section 9.6.2.1
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change structure of (Nokey)DataFrag

  • Key: DDSIRTP2-4
  • Legacy Issue Number: 11030
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    (NOKEY_)DATA_FRAG PSM submessage definition should be modified to place inlineQos AFTER fragmentation related parameters to simplify an implementation based on gather send.
    Resolution:
    Reposition the inlineQos field to be consistent with other messages, implementation simplicity, and higher performance.
    Revised Text:
    · Section 9.4.5.4, change
    0...2...........8...............16..............24..............32
    +

    NOKEY_DATA_FRAG X X X X X X Q E octetsToNextHeader

    ------------------------------------------------------+

    EntityId readerId

    ------------------------------------------------------+

    EntityId writerId

    ------------------------------------------------------+

     

    + SequenceNumber writerSN +

     

    ------------------------------------------------------+

     

    ~ ParameterList inlineQos [only if Q==1] ~

     

    ------------------------------------------------------+

    FragmentNumber fragmentStartingNum

    ------------------------------------------------------+

    ushort fragmentsInSubmessage ushort fragmentSize

    ------------------------------------------------------+

    unsigned long sampleSize

    ------------------------------------------------------+

     

    ~ SerializedData serializedData ~

     

    ------------------------------------------------------+
    to
    0...2...........8...............16..............24..............32
    +

    NOKEY_DATA_FRAG X X X X X X Q E octetsToNextHeader

    ------------------------------------------------------+

    EntityId readerId

    ------------------------------------------------------+

    EntityId writerId

    ------------------------------------------------------+

     

    + SequenceNumber writerSN +

     

    ------------------------------------------------------+

    FragmentNumber fragmentStartingNum

    ------------------------------------------------------+

    ushort fragmentsInSubmessage ushort fragmentSize

    ------------------------------------------------------+

    unsigned long sampleSize

    ------------------------------------------------------+

     

    ~ ParameterList inlineQos [only if Q==1] ~

     

    ------------------------------------------------------+

     

    ~ SerializedData serializedData ~

     

    ------------------------------------------------------+

    · Section 9.4.5.6, change
    0...2...........8...............16..............24..............32
    +

    DATA_FRAG X X X X X H Q E octetsToNextHeader

    ------------------------------------------------------+

    EntityId readerId

    ------------------------------------------------------+

    EntityId writerId

    ------------------------------------------------------+

     

    + SequenceNumber writerSN +

     

    ------------------------------------------------------+

     

    + +

    KeyHashPrefix keyHashPrefix [only if H==1]

    + +

     

    ------------------------------------------------------+

    KeyHashSuffix keyHashSuffix

    ------------------------------------------------------+

     

    ~ ParameterList inlineQos [only if Q==1] ~

     

    ------------------------------------------------------+

    FragmentNumber fragmentStartingNum

    ------------------------------------------------------+

    ushort fragmentsInSubmessage ushort fragmentSize

    ------------------------------------------------------+

    unsigned long sampleSize

    ------------------------------------------------------+

     

    ~ SerializedData serializedData ~

     

    ------------------------------------------------------+

    to

    0...2...........8...............16..............24..............32
    +

    DATA_FRAG X X X X X H Q E octetsToNextHeader

    ------------------------------------------------------+

    EntityId readerId

    ------------------------------------------------------+

    EntityId writerId

    ------------------------------------------------------+

     

    + SequenceNumber writerSN +

     

    ------------------------------------------------------+

     

    + +

    KeyHashPrefix keyHashPrefix [only if H==1]

    + +

     

    ------------------------------------------------------+

    KeyHashSuffix keyHashSuffix

    ------------------------------------------------------+

    FragmentNumber fragmentStartingNum

    ------------------------------------------------------+

    ushort fragmentsInSubmessage ushort fragmentSize

    ------------------------------------------------------+

    unsigned long sampleSize

    ------------------------------------------------------+

     

    ~ ParameterList inlineQos [only if Q==1] ~

     

    ------------------------------------------------------+

     

    ~ SerializedData serializedData ~

     

    ------------------------------------------------------+
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add SerializedDataFragment as Submessage Element

  • Key: DDSIRTP2-7
  • Legacy Issue Number: 11033
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Encapsulation of serialized data should be the responsibility of the plug-in. Even though the protocol does not need to interpret the data stream, in the case of fragmented data, the data encapsulation header need only be pre-pended to the first fragment. Further fragments don't need the encapsulation header.
    Resolution:
    Add a new SubmessageElement subclass called SerializedDataFragment.

    Revised Text:

    Renumber 8.3.5.15 (StatusInfo) to 8.3.5.16, and add new section 8.3.5.15

    8.3.5.15 SerializedDataFragment

    SerializedDataFragment contains the serialized representation of a the value of a data-object that has been fragmented. Like for unfragmented SerializedData, the RTPS protocol does not interpret the fragmented serialized data-stream. Therefore, it is represented as opaque data. For additional information on data encapsulation, see Chapter 10.

    Add table 8.32 - Structure of the SerializedDataFragment SubmessageElement
    field type meaning
    value octet[*] Serialized data-stream fragment

    Replace Figure 8.12 with :
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    for updated figure see page 27 of ptc/2007-06-02
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Version number should be 2.0

  • Key: DDSIRTP2-6
  • Legacy Issue Number: 11032
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The extensions made to the protocol break backwards compatibility and therefore the major version should be changed not the minor version.
    Resolution:
    Change the version number from 1.2 to 2.0.
    Revised Text:
    Change "1.2" to "2.0" in the following locations:
    · Table 8.13, 5th row (first cell reads "SubmessageKind"), the cell in the second column
    · Section 8.3.3.1.2, first paragraph, first sentence.
    · Section 8.3.4.1, numbered item 3, second sentence

    {note: two occurrences in this sentence}

    · Section 8.3.4.1, numbered item 4, third sentence.
    · Section 8.3.5, first paragraph, second sentence
    · Section 8.3.5.3, second paragraph (right after Table 8.20), first sentence
    · Section 8.3.5.9, within the bulleted items following the second paragraph
    o the second sentence in the second bulleted item
    o the second sentence in the third bulleted item
    · Section 8.3.7, first paragraph, first sentence
    · Section 8.6, first paragraph, first sentence
    · Section 9.3.1.2, last paragraph (right before Table 9.1), second sentence
    · Section 9.3.1.4, the title
    · Section 9.3.1.4, first paragraph, first and second sentences
    · Table 9.3, the caption
    · Section 9.4.2.11, last paragraph, first (and only) sentence
    · Section 9.4.5.1.1, first paragraph, last sentence
    · Section 9.4.5.1.2, last paragraph, first and second sentences
    · Section 9.6.4, the title
    · Section 9.6.4, first paragraph, first and second sentences

    Other changes:
    · Table 8.2, 6th row (cell in first column reads "ProtocolVersion_t"), the cell in the second column, change "PROTOCOLVERSION_1_2" to "PROTOCOLVERSION_2_0"
    o NOTE: there are two instances of this change in this cell.
    · Table 8.16, 2nd row (cell in first column reads "sourceVersion"), the cell in the second column, change "PROTOCOLVERSION_1_2" to "PROTOCOLVERSION_2_0"
    · Section 8.3.3.1.2, change "(major = 1, minor = 2)" to "(major = 2, minor = 0)"
    · Section 8.3.5.3, second paragraph, within the list of special values, change "PROTOCOLVERSION_1_2" to "PROTOCOLVERSION_2_0"
    · Section 8.6, first paragraph, first sentence, change "(1)" to "(2)"
    · Section 9.3.1.2, last paragraph (right before Table 9.1), third sentence, change "(1)" to "(2)"
    · Table 9.4, 5th row (first cell contains "ProtocolVersion_t")
    change:

    #define PROTOCOLVERSION_1_2

    {1,2}
    #define PROTOCOLVERSION {1,2}

    to:

    #define PROTOCOLVERSION_2_0

    {2,0}
    #define PROTOCOLVERSION {2,0}

    also, in the last sentence, change "version 1.2 (major = 1, minor = 2)" to "version 2.0 (major = 2, minor = 0)"
    · Section 8.3.3.1, last paragraph, first (and only) sentence, change "(1)" to "(2)"
    · Section 8.3.3.2, last paragraph (following Table 8.15), first (and only) sentence, change "(1)" to "(2)"
    · Section 8.3.3.2.1, second paragraph, first sentence, change "(1)" to "(2)"
    · Section 9.3.1.3, second paragraph, third sentence, change "(1)" to "(2)"
    · Section 9.4.4, second paragraph, change "(1)" to "(2)"
    · Section 9.4.5.1, second to last paragraph, first (and only) sentence, change "(1)" to "(2)"
    · Section 9.4.5.1.1, second paragraph, first sentence, change "(1)" to "(2)"
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove length field in encapsulation chapter

  • Key: DDSIRTP2-3
  • Legacy Issue Number: 11029
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The protocol should clarify the sequence number of a writer's first sample. Currently, this is not specified in 8.3.5.4. Rather, it is implied by 8.3.5.5 which states that a sequence number set contains sequence numbers >= 1. The same issue applies for a fragment number.
    Resolution:
    Explicitly state that the sequence number of a writer's first sample or fragment is 1.
    Revised Text:
    · Section 8.3.5.4, first paragraph, append text

    Sequence numbers begin at 1.

    · Section 8.3.5.6, first paragraph, append text

    Fragment numbers begin at 1.
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide default timing parameters

  • Key: DDSIRTP2-2
  • Legacy Issue Number: 11028
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    For out-of-the-box interoperability, we should provide default timing parameters for the reliability protocol.
    Resolution:
    Provide default timing parameters for the reliability protocol.
    Revised Text:
    · Add a new Section 8.4.7.1.1 titled "Default Timing-RelatedValues" with the following content:

    The following timing-related values are used as the defaults in order to facilitate 'out-of-the-box' interoperability between implementations.
    nackResponseDelay.sec = 0;
    nackResponseDelay.nanosec = 200 * 1000 * 1000; // 200 milliseconds
    nackSuppressionDuration.sec = 0;
    nackSuppressionDuration.nanosec = 0;

    · Add a new Section 8.4.10.1.1 title "Default Timing-Related Values" with the following content (NOTE: heartbeatSuppressionDuration does not currently exist in RTPS but is added through issue R#7) :

    The following timing-related values are used as the defaults in order to facilitate 'out-of-the-box' interoperability between implementations.
    heartbeatResponseDelay.sec = 0;
    heartbeatResponseDelay.nanosec = 500 * 1000 * 1000; // 500 milliseconds
    heartbeatSuppressionDuration.sec = 0;
    heartbeatSuppressionDuration.nanosec = 0;
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS DURABILITY Persistent QoS

  • Key: DDSIRTP2-25
  • Legacy Issue Number: 11053
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    In order to implement the DDS DURABILITY Persistent QoS, a persistence-service needs to send the data that has been received and stored on behalf of the persistent writer.

    The service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

    Resolution:
    Introduce a new parameter Id, ORIGINAL_WRITER_INFO, that can appear in parameter lists.

    Revised Text:

    Add to table 9.4:

    Type PSM Mapping
    OriginalWriterInfo_t struct

    { GUID_t originalWriterGUID; SequenceNumber_t originalWriterSN; ParameterList originalWriterQos;}

    OriginalWriterInfo;

    Append to table 9.13:
    Name ID Type
    PID_ORIGINAL_WRITER_INFO 0x0061 OriginalWriterInfo_t

    Add new section:

    8.7.6 Original Writer Info

    A service supporting the Persistent level of DDS Durability QoS needs to send the data that has been received and stored on behalf of the persistent writer.

    This service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

    The RTPS protocol supports this forwarding of messages by including information of the original writer.

    OriginalWriterInfo_t
    attribute type value
    originalWriterGUID GUID_t the GUID of the RTPS Writer that first generated the message
    originalWriterSN SequenceNumber_t the Sequence Number of the CacheChange as sent from the original writer
    originalWriterQos ParameterList the list of inline parameters that should apply to the CacheChange as sent by the RTPS Writer that first generated the sample

    When a RTPS reader receives this information it will treat it as a normal CacheChange, but once the CacheChange is ready to be commited to the DDS DataReader, it will not commit it. Instead, it will hand it off to the HistoryCache of the RTPSReader that is communicating with the RTPSWriter indicated in the ORIGINAL_WRITER_INFO inline-Qos and treat it as having the sequence number which appears there and the ParameterList also included in the ORIGINAL_WRITER_INFO.
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ChangeKind Has DDS Relationship

  • Key: DDSIRTP2-24
  • Legacy Issue Number: 11052
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Table 8.5 incorrectly shows a ChangeKind_t as having no applicable relation to DDS. Rather, the instance state kind of being disposed and unregistered are related to ChangeKind_t.

    Resolution:
    Revise table 8.5 to show the relationship between CacheChange kind and DDS instance state kind.

    Revised Text:
    Revise table 8.5:
    Attribute Type Meaning Relation to DDS
    kind ChangeKind_t Identifies the kind of change. See Table 8.2 DDS instance state kind

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify GAP usage

  • Key: DDSIRTP2-23
  • Legacy Issue Number: 11051
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Clarify that GAPs should be used only when a sample is not meaningful and not sent in the first place (e.g. filtered out).
    Resolution:
    Clarify GAP usage.

    Revised Text:
    Revise 8.3.7.4.5:

    The RTPS Writer sends the Gap message to the RTPS Reader to communicate that certain sequence numbers are no longer relevant. This is typically caused by the KEEP_LAST setting of the History QoS on the corresponding DDS DataWriter. This is typically caused by Writer-side filtering of the sample (content-filtered topics, time-based filtering). In this scenario, new data-values may replace the old values of the data-objects that were represented by the sequence numbers that appear as irrelevant in the GAP.
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

TOPICNAME parameter appears in PSM but not in PIM

  • Key: DDSIRTP2-26
  • Legacy Issue Number: 11065
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Reinier Torenbeek)
  • Summary:

    Summary:
    Table 9.13 in section 9.6.3 contains a parameter called PID_TOPIC_NAME as one of the in-line QoS settings. This parameter is not mentioned in the PIM.
    Resolution:
    First extend section 8.7.1 explaining the rationale behind in-line QoS data. This is addressed in OMG issue #11050 already. Then add the TOPICNAME parameter in section 8.7.2.1.
    Revised Text:
    · Section 8.7.2.1, add the following sentence :
    In-line parameters are added to data sub-messages to make them self-describing. In order to achieve self-describing sub-messages, not only the parameters defined in table 8.7.2.1 have to be sent with the sub-message, but also a parameter TOPICNAME. This parameter contains the name of the topic that the sub-message belongs to.
  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Elaborate on Necessity and Usage of In-line QoS

  • Key: DDSIRTP2-22
  • Legacy Issue Number: 11050
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The RTPS specification state which QoS can appear in-line but does not offer background information to justify their usage. The specification should elaborate on how in-line QoS are required for stateless implementations.

    Resolution:
    Elaborate on necessities and justifications for having in-line QoS to support stateless implementations.

    Revised Text:
    Revise 8.7.1, insert starting as third paragraph:

    A stateless Reader's need for receiving in-line QoS to get information on remote Writers is the justification for requiring a writer to send in-line QoS if the reader requests them (section 8.4.2.2.2).

    For immutable QoS, all RxO QoS are sent in-line to allow a stateless reader to reject samples in case of incompatible QoS. Mutable QoS relevant to the reader are sent in-line so they may take effect immediately, regardless of the amount of state kept on the reader. Note that a stateful reader has the option of relying on its cached information of remote writers rather than received in-line QoS.
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify Data Encapsulation Schemes

  • Key: DDSIRTP2-21
  • Legacy Issue Number: 11049
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Data encapsulation for Serialized Data Fragments needs differentiation from data encapsulation of serialized data. Fragmentation should be done after encapsulation of large serialized data. Rather than having an encapsulation header for each fragment, only a single encapsulation header is needed, as this is used after the sample has been reconstituted from its fragments. The specification of data encapsulation schemes should describe this.

    Also, in Sections 10.1.1-2, the length field of the data encapsulation schemes shown in the submessage diagrams are unnecessary, because the serialized data and fragments already contain sufficient information to determine the length of data. Instead, the field should be designated for data encapsulation scheme-specific options.
    Resolution:
    Replace the length field of the standard data encapsulation schemes with a scheme-specific option field.

    Define fragmentation as happening after encapsulation of a large data sample.

    Revised Text:
    · Section 10.1.1.2
    WAS
    0...2...........8...............16..............24..............32
    +

    CDR_BE ushort length

    ------------------------------------------------------+

     

    ~ Serialized Data (CDR Big Endian) ~

     

    ------------------------------------------------------+

    0...2...........8...............16..............24..............32
    +

    CDR_LE ushort length

    ------------------------------------------------------+

     

    ~ Serialized Data (CDR Little Endian) ~

     

    ------------------------------------------------------+

    NOW:
    0...2...........8...............16..............24..............32
    +

    CDR_BE ushort options

    ------------------------------------------------------+

     

    ~ Serialized Data (CDR Big Endian) ~

     

    ------------------------------------------------------+
    Fragmentation is done after encapsulation of large serialized data.

    0...2...........8...............16..............24..............32
    +

    CDR_LE ushort options

    ------------------------------------------------------+

     

    ~ Serialized Data (CDR Little Endian) ~

     

    ------------------------------------------------------+

    · Section 10.1.1.3
    WAS:
    0...2...........8...............16..............24..............32
    +

    PL_CDR_BE ushort length

    ------------------------------------------------------+

     

    ~ Serialized Data (ParameterList CDR Big Endian) ~

     

    ------------------------------------------------------+

    0...2...........8...............16..............24..............32
    +

    PL_CDR_LE ushort length

    ------------------------------------------------------+

     

    ~ Serialized Data (ParameterList CDR Little Endian) ~

     

    ------------------------------------------------------+

    NOW:
    0...2...........8...............16..............24..............32
    +

    PL_CDR_BE ushort options

    ------------------------------------------------------+

     

    ~ Serialized Data (ParameterList CDR Big Endian) ~

     

    ------------------------------------------------------+

    0...2...........8...............16..............24..............32
    +

    PL_CDR_LE ushort options

    ------------------------------------------------------+

     

    ~ Serialized Data (ParameterList CDR Little Endian) ~

     

    ------------------------------------------------------+

    Fragmentation is done after encapsulation of large serialized data, so a SerializedDataFragment may contain the encapsulation header of its larger opaque SerializedData sample.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify implementing Count submessage element

  • Key: DDSIRTP2-12
  • Legacy Issue Number: 11040
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The use of the count submessage element is not fully explained.

    For heartbeats, the Count element differentiates logical heartbeats, so heartbeats with the same count as a previously received heartbeat can be ignored to prevent triggering duplicate repair sessions. Also, old heartbeats with count less than previously received counts should also be ignored. So, same logical heartbeats must not have the same count, and new heartbeats must have greater counts than older heartbeats.

    The same logic applies to counts of ACKNACKs.

    Resolution:
    Explain proper usage of the count element of Heartbeats and ACKNACKs.

    Revised Text:
    Add new section:

    8.4.14.6 Setting Count of Heartbeats and ACKNACKs
    The count element of Heartbeats differentiates logical heartbeats. A received heartbeat with the same count as a previously received heartbeat can be ignored to prevent triggering a duplicate repair seesion. So, an implementation should ensure same logical heartbeats are tagged with the same count.

    Also, new heartbeats should have counts greater than all older heartbeats. Then, received heartbeats with counts less than or equal to any previously received can be ignored.

    The same logic applies for counts of ACKNACKs: each logical ACKNACK

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reclaiming finite resources from inactive readers

  • Key: DDSIRTP2-11
  • Legacy Issue Number: 11039
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The specification should describe how finite resources impact reliable communications.

    Writer queue resources should be reclaimed when no remote reader needs the corresponding sample. This means at least samples that have been fully acknowledged may be reclaimed. However they may exist unresponsive readers that are alive but for some reason never acknowledge the writer. To enable a writer to reclaim resources in this case, we define the notion of inactive Readers. If a reader is detected to be unresponsive through some mechanism (for example, when not responding to successive Heartbeats), the reader is deemed inactive. Then, samples that have been fully acknowledged by all active readers may be reclaimed. The writer should continue sending new samples and Heartbeats to inactive readers, but the writer need not hold onto old samples that were not acknowledged by inactive readers. The specification must note that strict reliability is no longer guaranteed when a reader becomes inactive.

    Resolution:
    Explain reliability in the presence of finite resources. Introduce and describe "isActive" reader attribute.

    Revised Text:
    Add new section
    8.4.14.6 Reclaiming Finite Resources from Unresponsive Readers

    An implementation likely has finite resources to work with. For a writer, reclaiming queue resources should happen when all readers have acknowledged a sample in the queue and resource limits dictate that the old sample entry is to be used for a new sample.

    There may be scenarios where an alive reader becomes unresponsive and will never acknowledge the writer. Instead of blocking on the unresponsive reader, the writer should be allowed to deem the reader as 'Inactive' and proceed in updating its queue. The state of a reader is either Active or Inactive. Active readers have sent ACKNACKs that have been recently received. The writer should determine the inactivity of a reader by using a mechanism based on the rate and number of ACKNACKs received. Then samples that have been acknowledged by all active readers can be freed, and the writer can reclaim those resources if necessary. Note that strict reliability is not guaranteed when a reader becomes inactive.

    Add to table 8.59 - RTPS ReaderProxy Attributes
    Attribute Type Meaning Relation to DDS
    isActive bool Specifies whether the remote reader is responsive to the writer. N/A
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Supporting Inline QoS by Stateful Readers

  • Key: DDSIRTP2-17
  • Legacy Issue Number: 11045
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Stateful readers should be allowed to rely on cached information propagated by discovery of remote writers. Thus, support for receiving and parsing inline QoS should be optional for stateful readers.

    In the case of mutable QoS, a tradeoff happens, where not parsing these inline QoS may delay the point in time when a new QoS takes effect, as it first must be propagated through discovery. A stateful implementation may expose this tradeoff to the user: minimize bandwidth usage by not sending mutated inline QoS or avoid this delayed effect of certain mutable QoS for guaranteed semantics.

    Resolution:
    Allow stateful implementations the choice of whether or not to parse inline QoS.

    Revised Text:
    Add as last paragraph of 8.7.1:

    Stateful implementations can ignore inline QoS and rely solely on cached values obtained through discovery in order to improve performance. Note that not parsing inline QoS may delay the point in time when a new QoS takes effect, as it first must be propagated through discovery
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Directed Write Parameter Id

  • Key: DDSIRTP2-16
  • Legacy Issue Number: 11044
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A directed write feature for tagging a sample with the GUID of the sample's single intended recipient must be supported with a new parameter Id to allow the GUID to be serialized as an inline parameter.

    Resolution:
    Add a new standard parameter Id, PID_DIRECTED_WRITE, with ID of 0x0057 and type of a sequence of GUIDs.

    Revised Text:
    Add following section:

    8.7.6 Directed Write
    Direct peer-to-peer communications may be enabled within the publish-subscribe framework of DDS by tagging samples with the handles of the intended recipient(s).

    RTPS supports directed writes by using the inline QoS parameter extension mechanism. The serialized information denotes the GUIDs of the targeted readers.

    When a writer sends such a directed sample, only the recipients with the matching parsed GUIDs accept the sample; all others acknowledge but absorb the sample, as if it was a GAP indicating a filtered sample.

    Append to Table 9.13:
    Name ID Type
    PID_DIRECTED_WRITE 0x0057 sequence<GUID_t>
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify interoperability requirement 8.4.2.3.3

  • Key: DDSIRTP2-9
  • Legacy Issue Number: 11037
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The requirement contained in Section 8.4.2.3.3 is too restrictive and doesn't specify when resources can be reclaimed. If all Readers have acknowledged a sample, the Writer should be allowed to reclaim that sample's resources. Also, if a Reader NACKs a sample it has already ACKed, and the Writer is still able to provide a repair, it should.
    Resolution:
    Allow Writer to reclaim resources and send repairs if possible.
    Revised Text:
    Add the paragraph to the end of Section 8.4.2.3.3:

    Once a Writer has received positive acknowledgement from all Readers, the Writer can reclaim any associated resources. However, if a Writer receives a negative acknowledgement to a previously positively acknowledged sample, and the Writer can still service the request, the Writer should send the sample.
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify interoperability requirement 8.4.2.3.4

  • Key: DDSIRTP2-8
  • Legacy Issue Number: 11036
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Requirement 8.4.2.3.4 currently states "Readers can only send an ACKNACK Message in response to a HEARTBEAT message." This implies a reader may not poll for samples by unilaterally NACKing. This is true in general: the frequency and bandwidth of NACKs and associated repair messages is well maintained if controlled only by the writer. However, in the case when a Reader first finds out about a remote writer, before it receives any heartbeats, it may optionally send an ACKNACK to notify the writer. This can expedite communications between the new writer/reader pair, as the arrival time of the first heartbeat may be indeterminate.

    The rationale of writer-only control of NACK and associated repair messages should be incThis optimization should be noted within an implementation note.

    Resolution:
    Clarify requirement 8.4.2.3.4 to include the special case of a Reader first discovering a Writer.
    Revised Text:
    · Change the text of Section 8.4.2.3.4 to:

    In steady state, an ACKNACK Message can only be sent as a response to a HEARTBEAT Message from a Writer. ACKNACK Messages can be sent from a Reader when it first discovers a Writer as an optimization. Writers are not required to respond to these pre-emptive ACKNACK Messages.
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interpreting Liveliness Heartbeats

  • Key: DDSIRTP2-15
  • Legacy Issue Number: 11043
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    For better performance and simpler reliability, a liveliness heartbeat should be allowed to be a liveliness-only message without heartbeat semantics. As subclassed from a heartbeat, a liveliness heartbeat may trigger an ACKNACK response; to be a liveliness-only message, no ACKNACKs should be triggered. To enable this, setting the final flag should not trigger ACKNACKs.

    Resolution:
    A liveliness heartbeat with final-flag set must not trigger any ACKNACKs.

    Revised Text:
    Append to 8.4.2.3.2:

    The response is not required when a liveliness HEARTBEAT has both liveliness and final flags set to indicate it is a liveliness-only message.

    Revise statechart 8.24:

    Revise Table 8.76 with revised transition:

    Transition state event next state
    T2 waiting HEARTBEAT message is received if (HB.FinalFlag==NOT_SET)then must_send_ackelse if (HB.LivelinessFlag == NOT_SET)then may_send_ackelse waiting
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify Writer Response to ACKNACK

  • Key: DDSIRTP2-14
  • Legacy Issue Number: 11042
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Requirement 8.4.2.2.4 should be clarified: a writer does not only respond with data or a GAP as stated. Rather, since a writer may have KEEP_LAST semantics and so may not offer the requested sample anymore, it may also respond with a new HB indicating the requested sample is no longer available. This is the mechanism to trigger a reader's onDataLost callback.

    Resolution:
    Clarify 8.4.2.2.4 to include a Writer's response of a HB to an ACKNACK requesting a sample that the writer does not have available.

    Revised Text:
    Revise first paragraph of 8.4.2.2.4:
    When receiving an ACKNACK Message indicating a Reader is missing some data samples, the Writer must respond by either sending the missing data samples, sending a GAP when the sample is not relevant, or sending a Heartbeat when the sample is no longer available.
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Max Sample Size Serialized Parameter Id

  • Key: DDSIRTP2-20
  • Legacy Issue Number: 11048
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A type's maximum serialized size may be included in a parameter list. A new parameter Id should be added.

    Resolution:
    Add parameter Id for Type Max Sample Size Serialized

    Revised Text:

    Append to Table 9.11:
    Name ID Type
    PID_TYPE_MAX_SIZE_SERIALIZED 0x0060 long
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Property List Parameter Id

  • Key: DDSIRTP2-19
  • Legacy Issue Number: 11047
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    User definable name-value pairs can serve as a generic and extensible framework for DDS properties. These properties may be serialized in parameter lists and thus need a corresponding unique parameter Id.
    Resolution:
    Add parameter Id for Property List.
    Revised Text:
    Add section:

    8.7.5 Property Lists

    Property lists are lists of user-definable properties applied to a DDS Entity. An entry in the list is a generic name-value pair. A user defines a pair to be a property for a DDS Participant, DataWriter, or DataReader. This extensible list enables non-DDS specified properties to be applied.

    The RTPS protocol supports Property lists as inline parameters. Properties can then be propagated during discovery or as inline QoS.

    Append to Table 9.4:

    Type PSM Mapping
    Property_t struct

    { string name; string value;}

    Property_t

    Append to Table 9.11
    Name ID Type
    PID_PROPERTY_LIST 0x0059 sequence<Property_t>
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Define default multicast Reader behavior

  • Key: DDSIRTP2-10
  • Legacy Issue Number: 11038
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Currently, the specification does not state whether a multicast DataReader must also have a unicast locator or not.
    Resolution:
    A unicast locator should be supplied for multicast DataReaders so that repair sessions can be sent over unicast. If one is not provided directly, then the Participant's locator can be assumed.

    Revised Text:
    Revise following entry in Table 8.77 - RTPS SPDPdiscoveredParticipantData attributes:

    attribute type meaning
    defaultUnicastLocatorList Locator_t[1..*] Default list of unicast locators (transport, address, port combinations) that can be used to send messages to the user-defined Endpoints contained in the Participant.These are the unicast locators that will be used in case the Endpoint does not specify its own set of Locators, so at least one Locator must be present.
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reader-side Heartbeat response suppression

  • Key: DDSIRTP2-13
  • Legacy Issue Number: 11041
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The specification does not prevent multiple Heartbeats from arriving in rapid succession. For example, the piggyback heartbeat of a repair message may immediately be followed by a periodic wildcard heartbeat. In order to prevent duplicate repair sessions, the specification should define heartbeat suppression on the reader's side. This heartbeat response suppression should be handled by a reader attribute that controls the duration for which duplicate heartbeats would be ignored.

    Resolution:
    Add reader attribute, heartbeatSuppressionDuration, that defines the duration in which received heartbeats are suppressed from triggering duplicate ACKNACKs.

    Revised Text:
    Revised figure 8.21:

    Revised table 8.66

    Attribute Type Meaning Relation to DDS
    heartbeatSuppressionDuration Duration_t Protocol tuning parameter that allows the RTPS Reader to ignore heartbeats that arrive 'too soon' after a previous heartbeat was received. N/A
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Entity Name Parameter Id

  • Key: DDSIRTP2-18
  • Legacy Issue Number: 11046
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A DDS entity name could be serialized within a parameter list, so a corresponding unique parameter Id should be assigned.
    Resolution:
    Add parameter Id for Entity Name.
    Revised Text:

    Type PSM Mapping
    EntityName_t struct

    { string name;}

    EntityName_t

    Append to Table 9.11:
    Name ID Type
    PID_ENTITY_NAME 0x0058 EntityName_t
  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#182) Clarify mapping of PIM 'out' to PSM 'inout'

  • Key: DDS11-123
  • Legacy Issue Number: 8581
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    There is already a convention in the specification of mapping an out parameter in the PIM to an inout parameter in the IDL PSM. This convention is useful because it preserves more precise semantics in the PIM while allowing for more performant implementations in language PSMs based on the IDL PSM. However, the convention is never explicitly described in the specification, which could lead to confusion among readers.

    Proposed Resolution:

    The section 2.2.2 PIM to PSM Mapping Rules should explicitly describe and endorse the aforementioned convention.

    Proposed Revised Text:

    Insert a new paragraph after the current first paragraph in section 2.2.2:
    'Out' parameters in the PIM are conventionally mapped to 'inout' parameters in the PSM in order to minimize the memory allocation performed by the Service and allow for more efficient implementations. The intended meaning is that the caller of such an operation should provide an object to serve as a "container" and that the operation will then "fill in" the state of that object appropriately.
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#181) Clarify listener and mask behavior with respect to built-in entitie

  • Key: DDS11-122
  • Legacy Issue Number: 8580
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This issue subsumes two related issues.

    · Presumably, listener callbacks pertaining to built-in entities should fall back to the DomainParticipantListener of their containing DomainParticipant in the usual way in the event that those built-in entities have not requested to receive the callbacks themselves. However, this behavior may prove inconvenient in practice: users-even those completely uninterested in built-in entities-must recognize the callbacks pertaining to those entities and deal with them in some way whenever they install a participant listener. Implementers are also constrained, as they will find it difficult to ensure the correct listener behavior while preserving the freedom to create built-in entities on demand.

    · The specification does not state the behavior of installing a nil listener or what mask values are acceptable in that case.
    Proposed Resolution:

    Installing a nil listener should be equivalent to installing a listener that does nothing. It is acceptable to provide a mask with a nil listener; in that case, no callback will be delivered to the entity or to its containing entities.

    A DomainParticipant's built-in Subscriber and all of its built-in Topics should by default have nil listeners with all mask bits set. Therefore their callbacks will no propagate back to the DomainParticipantListener unless the user explicitly calls set_listener on them.

    Proposed Revised Text:

    Insert a new paragraph after the existing first paragraph of section 2.1.2.1.1.3 set_listener:

    It is permitted to set a nil listener with any listener mask; it is behaviorally equivalent to installing a listener that does nothing.

    Append a new sentence to the final bullet in the list in section 2.1.4.3.1:

    Any statuses appearing in the mask associated with a nil listener will neither be dispatched to the entity itself nor propagated to its containing entities.

    Insert the following paragraph immediately following the table of built-in entity QoS on page 2-129:

    Built-in entities have default listener settings as well. A DomainParticipant's built-in Subscriber and all of its built-in Topics have nil listeners with all statuses appearing in their listener masks. The built-in DataReaders have nil listeners with no statuses in their masks.
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#180) Clarify which entities appear as instances to built-in readers

  • Key: DDS11-121
  • Legacy Issue Number: 8579
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not explicitly state whether clients of the built-in DataReaders should be able to discover other entities that belong to the same participant by those means. In other words, if a DataReader 'A' belongs (indirectly) to a DomainParticipant 'B', will information about A appear when one reads from the subscription built-in reader of B?

    We believe that most users will not want to "discover" entities they created themselves; the purpose of the built-in entities is to discover what exists elsewhere on the network. Furthermore, there is currently no way for a client of the built-in reader to distinguish between entities belonging to its own DomainParticipant and those that exist elsewhere on the network.

    Proposed Resolution:

    Clarify the descriptions of the built-in topics to indicate that data pertaining to entities of the same participant will not be made available there.

    A mechanism to determine whether an instance handle (read from a built-in topic or obtained through any other means) represents a particular known entity is generally useful. Add the following operations:
    · InstanceHandle_t Entity::get_instance_handle()
    · boolean DomainParticipant::contains_entity(InstanceHandle_t a_handle)

    Proposed Revised Text:

    Add the following sentence to the end of the first paragraph on page 2-129:

    A built-in DataReader object obtained from a given participant will not provide data pertaining to other entities created (directly or indirectly) from that participant under the assumption that such objects are already known to the application.

    Add the following row to the Entity Class table in section 2.1.2.1.1:

    get_instance_handle InstanceHandle_t

    Add the description of the new operation as a new section:

    2.1.2.1.1.8 get_instance_handle

    Get the instance handle that represents the Entity in the built-in topic data, in various statuses, and elsewhere.

    Add the following row to the DomainParticipant Class table in section 2.1.2.2.1:
    contains_entity boolean
    a_handle InstanceHandle_t

    Add the description of the new operation as a new section:

    2.1.2.2.1.26 contains_entity
    This operation checks whether or not the given instance handle represents an entity that was created, directly or indirectly, from the DomainParticipant. The instance handle for an Entity may be obtained from built-in topic data, from various statuses, or from the Entity operation get_instance_handle.

    Add the new operations to the IDL PSM in section 2.2.3:

    interface Entity

    { InstanceHandle_t get_instance_handle(); }

    ;

    interface DomainParticipant : Entity

    { boolean contains_entity(InstanceHandle_t a_handle); }

    ;
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#179) Built-in DataReaders should have TRANSIENT_LOCAL durability

  • Key: DDS11-120
  • Legacy Issue Number: 8578
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The table in 2.1.5 says that built-in DataReaders should have TRANSIENT durability. However, the description of that durability states that support for it is optional.

    Proposed Resolution:

    The specification should be changed to state that built-in readers should have TRANSIENT_LOCAL durability.

    Proposed Revised Text:

    Change TRANSIENT to TRANSIENT_LOCAL in the DURABILITY row of the table on page 2-129.
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#150) Ambiguous description of create_topic behavior

  • Key: DDS11-118
  • Legacy Issue Number: 8576
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The description of the DomainParticipant::create_topic operation in section 2.1.2.2.1.5 states that if an existing topic is found with the same name and QoS, that Topic will be returned; no duplicate Topic will be created. However, the specification fails to describe what will happen in the event that the name and QoS match but the listener is different. Additionally, the behavior places a barrier of understanding before the user, because create_topic behaves differently from all other factory methods in this respect.

    Proposed Resolution:

    Revise the specification to remove the language about reusing Topics. The create_topic operation, like all other 'create' operations in the specification, should always return a new Topic.

    Proposed Revised Text:

    Section 2.1.2.2.1.5 contains the following paragraphs; they should both be stricken from the specification:

    The implementation of create_topic will automatically perform a lookup_topicdescription for the specified topic_name. If a Topic is found, then the QoS and type_name of the found Topic are matched against the ones specified on the create_topic call. If there is an exact match, the existing Topic is returned. If there is no match the operation will fail. The consequence is that the application can never create more than one Topic with the same topic_name per DomainParticipant. Subsequent attempts will either return the existing Topic (i.e., behave like find_topic) or else fail.

    If a Topic is obtained multiple times by means of a create_topic, it must also be deleted that same number of times using delete_topic.
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#144) Default value for DataWriter RELIABILITY QoS

  • Key: DDS11-117
  • Legacy Issue Number: 8575
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification states that the default value of the RELIABILITY QoS policy on a DataWriter is BEST_EFFORT; however this makes it automatically incompatible with readers that request a RELIABLE value. This situation is not a problem per se, but it means that applications desiring RELIABLE communications must change the default configuration in two places: both with the reader and with the writer.

    Proposed Resolution:

    Changing the default value-on the DataWriter only-to RELIABLE would make the initial configuration of DDS applications simpler. The default behavior would still be the same because the DataReader would still default to BEST_EFFORT and therefore the default communication would be BEST_EFFORT. However, applications desiring a RELIABLE setting would have to change the defaults in only one place: with the DataReader.

    Proposed Revised Text:

    Append the following sentence to the "Meaning" column of the RELIABILITY RELIABLE row of the table in 2.1.3: "This is the default value for DataWriters."

    The final sentence in the "Meaning" column of the RELIABILITY BEST_EFFORT row of the table in 2.1.3 currently states: "This is the default value." This sentence should be amended: "This is the default value for DataReaders and Topics."
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#178) Unclear behavior of coherent changes when communication interrupted

  • Key: DDS11-119
  • Legacy Issue Number: 8577
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Publisher entity has operations begin_coherent_changes and end_coherent_changes that allow groups of updates to be received by subscriptions as if they were a single update. Although the specification already contains a general statement about receivers not making updates available until all have been received, no specific mention of communication interruptions or configuration changes is made. This omission has caused questions to be raised with regards to the interactions between coherent changes and partitions, late-joining DataReaders, and network failures.

    Proposed Resolution:

    The specification should be amended to state that a Publisher should not prevent users from changing its partitions while it is in the middle of publishing a set of coherent changes, as the effect of doing so is no different than that of any other connectivity change. However, in the event that connectivity changes occur between the publishers and receivers of data such that some receiver is not able to obtain the entire set, that receiver must act as if it had received none of the data.

    Proposed Revised Text:

    Append the following text to the second paragraph of section 2.1.2.4.1.10 begin_coherent_changes:

    A connectivity change may occur in the middle of a set of coherent changes; for example, the set of partitions used by the Publisher or one of its Subscribers may change, a late-joining DataReader may appear on the network, or a communication failure may occur. In the event that such a change prevents an entity from receiving the entire set of coherent changes, that entity must behave as if it had received none of the set.
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#6) Inconsistent name: StatusKindMask

  • Key: DDS11-124
  • Legacy Issue Number: 8582
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In most cases in the specification, when constants of a type named like <something>Kind need to be combined together, a type <something>Mask is defined in the IDL PSM in addition to <something>Kind. The case of StatusKind is inconsistent, however: its mask type is called StatusKindMask, not StatusMask.

    Proposed Resolution:

    Replace StatusKindMask with StatusMask. Clarify the name mapping convention in section 2.2.2.

    Proposed Revised Text:

    Append the following sentence to the fourth paragraph of section 2.2.2: "The name of the mask type is formed by replacing the word 'Kind' with the word 'Mask'."

    Replace "StatusKindMask" with "StatusMask" everywhere it appears in the IDL PSM in section 2.2.3.
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 2-8

  • Key: DDS11-125
  • Legacy Issue Number: 8775
  • Status: closed  
  • Source: Vanderbilt University ( Dr. Douglas C. Schmidt)
  • Summary:

    I think the following sentence is incorrect: a Listener is used to provide a callback for synchronous access and a WaitSet associated with one or several Condition objects as far as I can tell, these roles should be reversed. There are a bunch of other bugs in the spec. I'll try to report them as time permits.
  • Reported: DDS 1.0 — Tue, 10 May 2005 04:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#124) Clarification on the behavior of dispose

  • Key: DDS11-62
  • Legacy Issue Number: 8417
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The description of DataWriter::dispose needs to clarify whether it can be called with a nil handle.

    Proposed Resolution:
    DataWriter::dispose should just behave like DataWriter::write in that if the instance is not yet registered, the Service will automatically register it for the user. In that case, the operation should not return PRECONDITION_NOT_MET.

    Proposed Revised Text:
    The second-to-last paragraph in section 2.1.2.4.2.12 states "The operation must be only called on registered instances. Otherwise the operation will return the error PRECONDITION_NOT_MET." This paragraph should be removed.
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need an extra return code: ILLEGAL_OPERATION

  • Key: DDS11-61
  • Legacy Issue Number: 8399
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    It would be useful to have an additional return code called RETCODE_ILLEGAL_OPERATION. This return code would be useful, for example, in preventing the user from performing certain operations on the built-in DataReaders. Their QoS values are stated in the specification; vendors need not allow those values to be changed. Users should also not be allowed to delete built-in Entities. If the user tries to perform either of these two operations, the choices of return code we could use that are in accordance to the spec are:
    · RETCODE_ERROR
    · RETCODE_UNSUPPORTED
    · RETCODE_BAD_PARAMETER
    · RETCODE_PRECONDITION_NOT_MET
    · RETCODE_IMMUTABLE_POLICY

    All of the above fall short of helping the user find out what the problem really is.
    · RETCODE_ERROR: This is the generic error code; it does not give much information as to what might be wrong.
    · RETCODE_UNSUPPORTED: This choice would be semantically incorrect. The failure is not due to a vendor's failure to support an optional feature of the specification, but rather to the user's violation of a policy consistent with the specification that was set by that vendor.
    · RETCODE_BAD_PARAMETER: This return code is a little confusing. For instance, when trying to delete a built-in DataReader, the reader parameter passed is a valid DataReader and the function is expecting a reader. Such usage would seem to constitute passing a good parameter, not a bad one.
    · RETCODE_PRECONDITION_NOT_MET: There is no precondition that the user could change that would make the call work. Therefore, this result would be confusing.
    · RETCODE_IMMUTABLE_POLICY: This return code could potentially work when trying to change the QoS policies of the built-in DataReaders but not when attempting to delete them. However, it would still be semantically incorrect. The problem is not that the user is trying to change immutable QoS policies.

    The QoS policies being changed may be mutable; what is not allowed is the Entity whose policies are in question. Such a return result could lead the user to think that s/he is confused about which QoS policies are mutable.

    Proposed Resolution:
    Add a return code RETCODE_ILLEGAL_OPERATION. This return code indicates a misuse of the API provided by the Service. The user is invoking an operation on an inappropriate Entity or at an inappropriate time. There is no precondition that could be changed to allow the operation to succeed.
    Vendors may use this new return code to indicate violations of policies they have set that are consistent with, but not fully described by, the specification. It is therefore necessary that the return code be considered a "standard" return code (like RETCODE_OK, RETCODE_BAD_PARAMETER, and RETCODE_ERROR) that could potentially be returned by any operation having the return type ReturnCode_t.

    Proposed Revised Text:
    Add the following row to the "Return codes" table in 2.1.1.1:
    ILLEGAL_OPERATION An operation was invoked on an inappropriate object or at an inappropriate time (as determined by policies set by the specification or the Service implementation). There is no precondition that could be changed to make the operation succeed.

    In the paragraph following the table, the sentence "Any operation with return type ReturnCode_t may return OK or ERROR" should be restated "Any operation with return type ReturnCode_t may return OK, ERROR, or ILLEGAL_OPERATION." The sentence "The return codes OK, ERROR, ALREADY_DELETED, UNSUPPORTED, and BAD_PARAMETER are the standard return codes and the specification won't mention them explicitly for each operation" should be restated as "The return codes OK, ERROR, ILLEGAL_OPERATION, ALREADY_DELETED, UNSUPPORTED, and BAD_PARAMETER are the standard return codes and the specification won't mention them explicitly for each operation".
  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#119) Need lookup_instance method on reader and writer

  • Key: DDS11-58
  • Legacy Issue Number: 8396
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    There are get_key_value operations in the DataReader and DataWriter to translate from an instance handle to a key. However, in order for a client of the Service to use the per-instance read and take operations of a DataReader, it would be convenient to have an operation to translate in the other direction: from key value(s) to an instance handle.

    Proposed Resolution:
    Add operations DataReader::lookup_instance and DataWriter::lookup_instance.

    Proposed Revised Text:
    Append the following rows to the DataWriter Class table in 2.1.2.4.2:
    lookup_instance InstanceHandle_t
    Instance Data

    Add a new section "2.1.2.4.2.23 lookup_instance" with the following contents:
    This operation takes as a parameter an instance (to get the key value) and returns a handle that can be used in successive operations that accept an instance handle as an argument.
    This operation does not register the instance in question. If the instance has not been previously registered, or if for any other reason the Service is unable to provide an instance handle, the Service will return the special value HANDLE_NIL.

    Append the following rows to the DataReader Class table in 2.1.2.5.3:
    lookup_instance InstanceHandle_t
    Instance Data

    Add a new section "2.1.2.5.3.33 lookup_instance" with the following contents:
    This operation takes as a parameter an instance (to get the key value) and returns a handle that can be used in successive operations that accept an instance handle as an argument.
    If for any reason the Service is unable to provide an instance handle, the Service will return the special value HANDLE_NIL.
  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

TransportPriority QoS range does not specify high/low priority values

  • Key: DDS11-57
  • Legacy Issue Number: 8395
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not state what the valid range of the transport priority values is, now does it state whether higher or lower values correspond to higher priorities.

    Proposed Resolution:
    Stipulate that the range of TransportPriorityQosPolicy::value is the entire range of a 32 bit signed integer. Larger numbers indicate higher priority. However, the precise interpretation of the value chosen is transport- and implementation-dependent.

    Proposed Revised Text:
    The second paragraph of section 2.1.3.14 contains the sentence:
    "As this is specific to each transport it is not possible to define the behavior generically."

    This sentence should be rewritten as follows:
    "Any value within the range of a 32-bit signed integer may be chosen; higher values indicate higher priority. However, any further interpretation of this policy is specific to a particular transport and a particular implementation of the Service. For example, a particular transport is permitted to treat a range of priority values as equivalent to one another."
  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#122) Missing QoS dependencies in table

  • Key: DDS11-60
  • Legacy Issue Number: 8398
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    A DataReader must specify a TimeBasedFilterQosPolicy::minimum_separation value that is less than or equal to its DeadlineQosPolicy::period value. (Otherwise, all matched DataWriters will be considered to miss every deadline.)
    There are dependencies among the fields of ResourceLimitsQosPolicy: max_samples >= max_samples_per_instance.
    The above dependencies are not made explicit in the specification.

    Proposed Resolution:
    The above dependencies should be made explicit in the QoS policy table in section 2.1.3.

    Proposed Revised Text:
    The following sentence should be added to the "Meaning" column of the "DEADLINE" row: "It is inconsistent for a DataReader to have a deadline period less than its TIME_BASED_FILTER's minimum_separation."

    The following sentence should be added to the "Meaning" column of the "TIME_BASED_FILTER" row: "It is inconsistent for a DataReader to have a minimum_separation longer than its deadline period."

    The following sentence should be added to the "Meaning" column of the "max_samples" row: "It is inconsistent for this value to be less than max_samples_per_instance."

    The following sentence should be added to the "Meaning" column of the "max_samples_per_instance" row: "It is inconsistent for this value to be greater than max_samples."
  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#120) Clarify use of DATAREADER_QOS_USE_TOPIC_QOS

  • Key: DDS11-59
  • Legacy Issue Number: 8397
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Title: (R#120) Clarify use of DATAREADER_QOS_USE_TOPIC_QOS constant when creating DataReader on ContentFilteredTopic or MultiTopic

    Summary:
    The specification defines the constant DATAREADER_QOS_USE_TOPIC_QOS that may be used to specify the QoS of a DataReader. The meaning of such usage is unclear when the DataReader's TopicDescription is a ContentFilteredTopic or a MultiTopic since those types do not have QoS of their own.

    Proposed Resolution:
    A ContentFilteredTopic is based on a single Topic; therefore, the meaning of DATAREADER_QOS_USE_TOPIC_QOS is well-defined in that case: it refers to the QoS of the Topic accessible via the ContentFilteredTopic::get_related_topic operation.
    The meaning of DATAREADER_QOS_USE_TOPIC_QOS is not well-defined in the case of a MultiTopic; using it to set the QoS of a DataReader of a MultiTopic is an error. Specifically, passing the constant to Subscriber::create_datareader when a MultiTopic is also passed to that operation will result in the operation returning nil.

    Proposed Revised Text:
    The last paragraph of section "2.1.2.5.2.5 create_datareader" (which begins "The special value…") should be rewritten as follows:
    Provided that the TopicDescription passed to this method is a Topic or a ContentFilteredTopic, the special value DATAREADER_QOS_USE_TOPIC_QOS can be used to indicate that the DataReader should be created with a combination of the default DataReader QoS and the Topic QoS. (In the case of a ContentFilteredTopic, the Topic in question is the ContentFilteredTopic's "related Topic.") The use of this value is equivalent to the application obtaining the default DataReader QoS and the Topic QoS (by means of the operation Topic::get_qos) and then combining these two QoS using the operation copy_from_topic_qos whereby any policy that is set on the Topic QoS "overrides" the corresponding policy on the default QoS. The resulting QoS is then applied to the creation of the DataReader. It is an error to use DATAREADER_QOS_USE_TOPIC_QOS when creating a DataReader with a MultiTopic; this method will return a nil value in that case.
  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#115) Destination order missing from PublicationBuiltinTopicData

  • Key: DDS11-56
  • Legacy Issue Number: 8394
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The PublicationBuiltinTopicData type is missing a destination order field.

    Proposed Resolution:
    Add the missing field in both the PIM and the IDL PSM.

    Proposed Revised Text:
    In the "DCPSPublication" row of the table in 2.1.5, pg. 2-131, add a sub-row like the following after the existing "ownership_strength" sub-row:
    destination_order DestinationOrderQosPolicy Policy of the corresponding DataWriter

    In the IDL PSM, modify the PublicationBuiltinTopicData declaration as follows (the member immediately preceding the new member is show below in order to demonstrate the position of the new member):

    struct PublicationBuiltinTopicData

    { OwnershipStrengthQosPolicy ownership_strength; DestinationOrderQosPolicy destination_order; }

    ;
  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#114) Operations should not return void

  • Key: DDS11-55
  • Legacy Issue Number: 8393
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    A number of operations in the specification have a void return type. However, without a specified return type, an implementation cannot indicate that an error occurred.

    Proposed Resolution:
    The following methods currently return void and should return ReturnCode_t instead.
    · GuardCondition::set_trigger_value
    · DomainParticipant::get_default_publisher_qos
    · DomainParticipant::get_default_subscriber_qos
    · DomainParticipant::get_default_topic_qos
    · DomainParticipant::assert_liveliness
    · DomainParticipantFactory::get_default_participant_qos
    · Publisher::get_default_datawriter_qos
    · Subscriber::get_default_subscriber_qos
    · DataWriter::assert_liveliness
    · Subscriber::notify_datareaders
    (The get_qos operations on each concrete Entity type are show to return void in the IDL PSM but a list of QoS policies in the PIM. That inconsistency is addressed in another issue.)

    Proposed Revised Text:
    In the GuardCondition Class table in 2.1.2.1.8, the void return type of set_trigger_value should be replaced by ReturnCode_t. The return type of that operation must be similarly changed in the IDL PSM in 2.2.3.
    In the DomainParticipant Class table in 2.1.2.2.1, the void return type of the get_default_*_qos operations and the assert_liveliness operation should be replaced by ReturnCode_t. The return types of those operations should be similarly changed in the IDL PSM in 2.2.3.
    In the Publisher Class table in 2.1.2.4.1, the void return type of get_default_datawriter_qos should be replaced by ReturnCode_t. The return type of that operation must be similarly changed in the IDL PSM in 2.2.3.
    In the DataWriter Class table in 2.1.2.4.2, the void return type of assert_liveliness should be replaced by ReturnCode_t. The return type of that operation must be similarly changed in the IDL PSM in 2.2.3.
    In the Subscriber Class table in 2.1.2.5.2, the void return type of get_default_datareader_qos and notify_datareaders should be replaced by ReturnCode_t. The return type of those operations must be similarly changed in the IDL PSM in 2.2.3.
  • Reported: DDS 1.0 — Tue, 14 Dec 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#127) Improve PSM mapping of BuiltinTopicKey_t

  • Key: DDS11-64
  • Legacy Issue Number: 8419
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The IDL PSM defines the type BuiltinTopicKey_t to be an array of element type BUILTIN_TOPIC_KEY_TYPE_NATIVE. This definition prevents some compilers from permitting shallow copies of instances of this type.

    Proposed Resolution:
    Redefine BuiltinTopicKey_t to be a structure containing an array rather than the array itself.

    Proposed Revised Text:
    In 2.2.3, change this:

    typedef BUILTIN_TOPIC_KEY_TYPE_NATIVE BuiltinTopicKey_t[3]
    to this:

    struct BuiltinTopicKey_t

    { BUILTIN_TOPIC_KEY_TYPE_NATIVE value[3]; }
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#125) Additional operations that can return RETCODE_TIMEOUT

  • Key: DDS11-63
  • Legacy Issue Number: 8418
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification currently states that the DataWriter::write operation may return TIMEOUT under certain circumstances. However, the DataWriter operations dispose, register, unregister, and their variants may also block due to a temporarily full history.

    Proposed Resolution:
    Revise the documentation for the listed operations to state that they may return TIMEOUT if the RELIABILITY max_blocking_time elapses.

    Proposed Revised Text:
    The following paragraph should be appended to sections 2.1.2.4.2.5, 2.1.2.4.2.6, 2.1.2.4.2.7, 2.1.2.4.2.8, 2.1.2.4.2.12, and 2.1.2.4.2.13:
    This operation may block if it would cause data to be lost or one of the limits specified in the RESOURCE_LIMITS to be exceeded. Under these circumstances, the RELIABILITY max_blocking_time configures the maximum time this operation may block (waiting for space to become available). If max_blocking_time elapses before the DataWriter is able to store the modification without exceeding the limits, this operation will fail and return TIMEOUT
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#130) Unspecified behavior of delete_datareader with outstanding loans

  • Key: DDS11-66
  • Legacy Issue Number: 8421
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not state what should occur if the user attempts to delete a DataReader when it has one or more outstanding loans as a result of a call to DataReader::read, DataReader::take, or a variant thereof.

    Proposed Resolution:
    State that Subscriber::delete_datareader should fail and return PRECONDITION_NOT_MET in that case.

    Proposed Revised Text:
    In section 2.1.2.5.2.6 delete_datareader, there is a paragraph (beginning "The deletion of a DataReader is not allowed…") that describes the operation's behavior in the event that some conditions created from the reader have not been deleted. Following that paragraph a new paragraph should be added:
    The deletion of a DataReader is not allowed if it has any outstanding loans as a result of a call to read, take, or one of the variants thereof. If the delete_datareader operation is called on a DataReader with one or more outstanding loans, it will return PRECONDITION_NOT_MET
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified behavior of DataReader/DataWriter creation w/t mismatched Topic

  • Key: DDS11-65
  • Legacy Issue Number: 8420
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not currently state whether it is permissible to create a DataReader or DataWriter with a TopicDescription that was created from a DomainParticipant other than that used to create the reader or writer's factory.

    Proposed Resolution:
    The use case in question is not allowed; create_datareader and create_datawriter should return nil in that case.

    Proposed Revised Text:
    The following paragraph should be appended to section 2.1.2.4.1.5 create_datawriter:
    The Topic passed to this operation must have been created from the same DomainParticipant that was used to create this Publisher. If the Topic was created from a different DomainParticipant, this operation will fail and return a nil result.
    The following paragraph should be appended to section 2.1.2.5.2.5 create_datareader:
    The TopicDescription passed to this operation must have been created from the same DomainParticipant that was used to create this Subscriber. If the TopicDescription was created from a different DomainParticipant, this operation will fail and return a nil result.
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect reference to LIVELINESS_CHANGED in DataWriter::unregister

  • Key: DDS11-68
  • Legacy Issue Number: 8423
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In the description of DataWriter::unregister in section 2.1.2.4.2.7 it says that if an instance is unregistered via a call to DataWriter::unregister, a matched DataReader will get an indication that its LIVELINESS_CHANGED status has changed.
    However, unregister refers to an instance; the LIVELINESS_CHANGED status is based on the liveliness of a DataWriter, not an instance.

    Proposed Resolution:
    Instead the specification should state that the DataReader will receive a sample with a NOT_ALIVE_NO_WRITERS instance state.

    Proposed Revised Text:
    The sentence:
    DataReader objects that are reading the instance will eventually get an indication that their LIVELINESS_CHANGED status (as defined in Section 2.1.4.1) has changed.
    …should be rewritten:
    DataReader objects that are reading the instance will eventually receive a sample with a NOT_ALIVE_NO_WRITERS instance state if no other DataWriter objects are writing the instance.
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#131) Clarify behavior of get_status_changes

  • Key: DDS11-67
  • Legacy Issue Number: 8422
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not make clear whether the set of status kinds returned by Entity::get_status_changes when that operation is invoked on a factory Entity (such as a Publisher) should include the changed statuses of the Entities created from that factory (such as a DataWriter).

    Proposed Resolution:
    Clarify that the set of status kinds will only contain the statuses that have changed on the Entity on which get_status_changes is invoked and not that Entity's contained Entities.

    Proposed Revised Text:
    Append the following sentence to section 2.1.2.1.1.6: "A 'triggered' status on an Entity does not imply that that status is triggered on the Entity's factory."
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect field name for USER_DATA, TOPIC_DATA, and GROUP_DATA

  • Key: DDS11-53
  • Legacy Issue Number: 8391
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The QoS table in section 2.1.3 does not mention the field names in the USER_DATA, TOPIC_DATA, and GROUP_DATA QoS policies. The UML diagram in figure 2-12 gives the names of these fields as "data"; however, that name is inconsistent with the names given in the IDL PSM.

    Proposed Resolution:
    The table and figure should indicate that the name of the field in each policy is "value." That name is consistent with the IDL PSM.

    Proposed Revised Text:
    In 2.1.3 figure 2-12, UserDataQosPolicy:
    value [*] : char

    In 2.1.3 figure 2-12, TopicDataQosPolicy:
    value [*] : char

    In 2.1.3 figure 2-12, GroupDataQosPolicy:
    value [*] : char
    In the table in 2.1.3, in the "Value" column of the USER_DATA, TOPIC_DATA, and GROUP_DATA rows:
    "value": a sequence of octets
  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#109) Unused types in IDL

  • Key: DDS11-52
  • Legacy Issue Number: 8390
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The types TopicSeq, SampleStateSeq, ViewStateSeq and InstanceStateSeq all appear in the IDL PSM but are never used.

    Proposed Resolution:
    Remove the unused types from the IDL PSM.

    Proposed Revised Text:
    The following declarations should be removed from the IDL PSM:

    typedef sequence<Topic> TopicSeq;
    typedef sequence <SampleStateKind> SampleStateSeq;
    typedef sequence<ViewStateKind> ViewStateSeq;
    typedef sequence<InstanceStateKind> InstanceStateSeq;
  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#112) Incorrect SampleRejectedStatusKind constants

  • Key: DDS11-54
  • Legacy Issue Number: 8392
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The constants in the enumeration SampleRejectedStatusKind should correspond to the fields of the RESOURCE_LIMITS QoS policy.

    Proposed Resolution:
    Remove the constant REJECTED_BY_TOPIC_LIMIT. Add the constants REJECTED_BY_SAMPLES_LIMIT and REJECTED_BY_SAMPLES_PER_INSTANCE_LIMIT.

    Proposed Revised Text:
    enum SampleRejectedStatusKind

    { REJECTED_BY_INSTANCE_LIMIT, REJECTED_BY_SAMPLES_LIMIT, REJECTED_BY_SAMPLES_PER_INSTANCE_LIMIT }

    ;
  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#142) OWNERSHIP QoS policy should concern DataWriter and DataReader

  • Key: DDS11-72
  • Legacy Issue Number: 8427
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The OWNERSHIP QoS policy only concerns the Topic Entity. It is the only such policy; all other Topic QoS policies also concern the DataReader and DataWriter, which may override the value provided by the Topic.
    The OWNERSHIP QoS policy is also missing from the PublicationBuiltinTopicData and SubscriptionBuiltinTopicData structures.

    Proposed Resolution:
    The OWNERSHIP QoS policy should concern the Topic, DataReader, and DataWriter Entities. It should have requested vs. offered (RxO) semantics: the two sides must agree on its value.
    A field of type OwnershipQosPolicy should be added to the PublicationBuiltinTopicData and SubscriptionBuiltinTopicData structures.

    Proposed Revised Text:
    Change the "Concerns" column of the OWNERSHIP row of the table on page 2-94 to read "Topic, DataReader, DataWriter."

    The second paragraph of section 2.1.3.8 OWNERSHIP begins "This QoS policy only applies to Topic and not to DataReader or DataWriter…" This paragraph should be removed.

    Add the following rows to the built-in topic table on page 2-131:
    DCPSPublication ownership OwnershipQosPolicy Policy of the corresponding DataWriter
    DCPSSubscription Ownership OwnershipQosPolicy Policy of the corresponding DataReader

    Modify the definitions of the DataWriterQos and DeadReaderQos structures in the IDL PSM in 2.2.3:

    struct DataWriterQos

    { OwnershipQosPolicy ownership; };


    struct DataReaderQosPolicy { OwnershipQosPolicy ownership; }

    ;
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#139) Rename *MatchStatus to *MatchedStatus

  • Key: DDS11-71
  • Legacy Issue Number: 8426
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Most statuses (and the callbacks corresponding to them) have names ending in a past tense verb (e.g. LivelinessLost, LivelinessChanged, *DeadlineMissed, etc.). This convention makes the names very understandable because they refer to an actual thing that happened.
    The publication and subscription match statuses/callbacks violate this convention, however. They are named after the match itself, not the event of matching.

    Proposed Resolution:
    To make the match statuses/callbacks consistent, they should be called PublicationMatchedStatus (on_publication_matched) and SubscriptionMatchedStatus (on_subscription_matched).

    Proposed Revised Text:

    Replace "PublicationMatchStatus" with "PublicationMatchedStatus," "on_publication_match" with "on_publication_matched," "SubscriptionMatchStatus" with "SubscriptionMatchedStatus," and "on_subscription_match" with "on_subscription_matched" in the DomainParticipantListener table in 2.1.2.2.3.

    Perform the same substitutions in the DataWriter table in 2.1.2.4.2 and in the DataWriterListener table in 2.1.2.4.4.

    Perform the same substitutions in the DataReader table in 2.1.2.5.3 and in the DataReaderListener table in 2.1.2.5.7.

    Rename "PublicationMatchStatus" to "PublicationMatchedStatus" and "SubscriptionMatchStatus" to "SubscriptionMatchedStatus" in figure 2-13, in the immediately following table of statuses, and in the IDL PSM definitions of the types PublicationMatchStatus, SubscriptionMatchStatus, DataWriterListener, DataReaderListener, DataWriter, and DataReader.
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#138) Add instance handle to LivelinessChangedStatus

  • Key: DDS11-70
  • Legacy Issue Number: 8425
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    It would be useful to have a field in LivelinessChangedStatus that provides the instance handle for the last DataWriter for which there was a change in liveliness.

    Proposed Resolution:
    Add a field last_publication_handle to LivelinessChangedStatus.

    Proposed Revised Text:
    Add an attribute "last_publication_handle : InstanceHandle_t" to LivelinessChangedStatus in figure 2-13.
    Add a row to the LivelinessChangedStatus section of the table on page 2-118:
    last_publication_handle Handle to the last DataWriter whose change in liveliness caused this status to change.
    Revise the definition of LivelinessChangedStatus in the IDL PSM in 2.2.3:

    struct LivelinessChangedStatus

    { InstanceHandle_t last_publication_handle; }

    ;
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#135) Add fields to PublicationMatchStatus and SubscriptionMatchStatus

  • Key: DDS11-69
  • Legacy Issue Number: 8424
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    There are two limitations to the PublicationMatchStatus and SubscriptionMatchStatus that prevent them from being used to detect the loss of a match:
    · The specification does not indicate whether those statuses are considered to have changed when a match is lost (e.g. as a result of a loss of liveliness or an incompatible QoS change).
    · The status structures contain fields that indicate the total number of matches that have ever occurred, but they lack fields to indicate the number of current matches.

    Proposed Resolution:
    Two fields should be added to each status structure: current_count and current_count_change. The specification should be updated to state that the publication and subscription match statuses are considered to have changed both when a match is established and when it is lost.

    Proposed Revised Text:
    Update the table in 2.1.4.1 as follows:

    DataReader SUBSCRIPTION_MATCH_STATUS The DataReader has found a DataWriter that matches the Topic and has compatible QoS or has stopped communicating with a DataWriter that was previously considered to have matched.

    DataWriter PUBLICATION_MATCH_STATUS The DataWriter has found DataReader that matches the Topic and has compatible QoS or has stopped communicating with a DataReader that was previously considered to have matched.

    Update PublicationMatchStatus and SubscriptionMatchStatus in figure 2-13 to add the following attributes to each:

    current_count : long
    current_count_change : long

    Update the PublicationMatchStatus section of the table on page 2-119 with the following rows:
    current_count The number of DataReaders currently matched to the concerned DataWriter.
    current_count_change The change in current_count since the last time the listener was called or the status was read.

    Update the SubscriptionMatchStatus section of the table on page 2-119 with the following rows:
    current_count The number of DataWriters currently matched to the concerned DataReader.
    current_count_change The change in current_count since the last time the listener was called or the status was read.

    Modify the declarations of the PublicationMatchStatus and SubscriptionMatchStatus structures in the IDL PSM in 2.2.3 as follows:

    struct PublicationMatchStatus

    { long total_count; long total_count_change; long current_count; long current_count_change; InstanceHandle_t last_subscription_handle; }

    ;

    struct SubscriptionMatchStatus

    { long total_count; long total_count_change; long current_count; long current_count_change; InstanceHandle_t last_publication_handle; }

    ;
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#145,146) Inconsistent description of Topic module in PIM

  • Key: DDS11-73
  • Legacy Issue Number: 8428
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Several members in the Topic module are described as attributes in the UML diagram in 2.1.2.3 but as operations in the following tables and in the IDL PSM. These include:
    · TopicDescription::type_name
    · TopicDescription::name
    · ContentFilteredTopic::filter_expression
    · ContentFilteredTopic::expression_parameters
    · MultiTopic::subscription_expression
    · MultiTopic::expression_parameters
    Also, the topic name and type name members are needlessly repeated in the tables of all of the TopicDescription subclasses. They are non-abstract; they need only appear in the TopicDescription table.

    Proposed Resolution:
    The read-only attributes should appear as such in the PIM tables. "Attributes" that can be changed return ReturnCode_t from the corresponding "set" methods; for clarity, they should consistently appear as operations in both the tables and the UML diagram. The duplicate descriptions of the topic name and type name attributes should be removed.
    The IDL PSM should continue to express all of the members as methods to preserve the consistency of the naming conventions used in all programming languages that may be generated from the IDL.

    Proposed Revised Text:

    In figure 2-7, replace the ContentFilteredTopic attribute expression_parameters with two operations: get_expression_parameters and set_expression_parameters. Replace the MultiTopic attribute expression_parameters with two operations: get_expression_parameters and set_expression_parameters.

    Revise the TopicDescription Class table in 2.1.2.3.1 as follows:
    TopicDescription
    attributes
    readonly name string
    readonly type_name string
    operations
    get_participant DomainParticipant

    Rewrite section 2.1.2.3.1.2 as follows:
    2.1.2.3.1.2 type_name
    The type name used to create the TopicDescription.

    Rewrite section 2.1.2.3.1.3 as follows:
    2.1.2.3.1.3 name
    The name used to create the TopicDescription.
    Remove the get_type_name and get_name operations from the Topic Class table in 2.1.2.3.2.
    Remove the get_type_name, get_name, and get_filter_expression operations from the ContentFilteredTopic Class table in 2.1.2.3.3. Add the following attributes to that table:
    attributes
    readonly filter_expression string

    Rewrite section 2.1.2.3.3.2 as follows:
    2.1.2.3.3.2 filter_expression
    The filter_expression associated with the ContentFilteredTopic. That is, the expression specified when the ContentFilteredTopic was created.

    Remove the get_type_name, get_name, and get_subscription_expression operations from the MultiTopic Class table in 2.1.2.3.4. Add the following attributes to that table:
    attributes
    readonly subscription_expression string

    Rewrite section 2.1.2.3.3.2 as follows:
    2.1.2.3.4.1 get_subscription_expression
    The subscription_expression associated with the MultiTopic. That is, the expression specified when the MultiTopic was created.
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#154) Undefined behavior if resume_publications is never called

  • Key: DDS11-77
  • Legacy Issue Number: 8432
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification fails to state what should happen to publications suspended with Publisher::suspend_publications if Publisher::resume_publications is never called by the time the Publisher is deleted.
    Proposed Resolution:
    The Publisher may be deleted in the situation described. Any samples that have not yet been sent will be discarded.

    Proposed Revised Text:
    Add the following sentence to the last paragraph of section 2.1.2.4.1.8: "If the Publisher is deleted before resume_publications is called, any suspended updates yet to be published will be discarded."
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#153) Ambiguous SampleRejectedStatus::last_reason field

  • Key: DDS11-76
  • Legacy Issue Number: 8431
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The value of the SampleRejectedStatus::last_reason field is undefined in that case where the user calls get_sample_rejected_status when no samples have been rejected.

    Proposed Resolution:
    Introduce a new SampleRejectedStatusKind value NOT_REJECTED and stipulate that it is to be used in the case described above.

    Proposed Revised Text:
    Add the following sentence to the description of SampleRejectedStatus::last_reason in the table on page 2-118: "If no samples have been rejected, the reason is the special value NOT_REJECTED."
    Modify the definition of SampleRejectedStatusKind in 2.2.3 to add a constant NOT_REJECTED.
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#152) Extraneous WaitSet::wakeup

  • Key: DDS11-75
  • Legacy Issue Number: 8430
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The operation WaitSet::wakeup is listed in the UML diagrams in 2.1.2.1 and 2.1.4.4. This operation is not listed in the WaitSet table in 2.1.2.1.6.

    Proposed Resolution:
    The GuardCondition class already provides a mechanism for manually waking up a WaitSet. The wakeup method should be struck from the UML diagrams noted above.

    Proposed Revised Text:
    Remove the wakeup operation from the WaitSet class in figure 2-5 and in figure 2-18.
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#147) Inconsistent error code list in description of TypeSupport::registe

  • Key: DDS11-74
  • Legacy Issue Number: 8429
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The description of register_type in 2.1.2.3.6.1 first says that the operation may return PRECONDITION_NOT_MET but later says that the only "special" error code that may be returned is OUT_OF_RESOURCES.

    Proposed Resolution:
    The operation should be able to return either PRECONDITION_NOT_MET or OUT_OF_RESOURCES.

    Proposed Revised Text:
    The last sentence of section 2.1.2.3.6.1 should read "Possible error codes returned in addition to the standard ones: PRECONDITION_NOT_MET and OUT_OF_RESOURCES."
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ReadOnly exception on clone operations

  • Key: DDS11-83
  • Legacy Issue Number: 8536
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The IDL section states that the operations "clone" and "clone_object" on "ObjectRoot" as well as the operation "clone_foo" on the implied IDL for "Foo" may raise the exception "ReadOnlyMode", while this is not true.
    Resolution:
    Correct the IDL
  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bad cardinality on figure 3-4

  • Key: DDS11-82
  • Legacy Issue Number: 8535
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Bad cardinality for relations Cache-> CacheListener and ObjectHome->ObjectListener on figure 3-4
    Summary:
    While the PIM text and the IDL state that several CacheListeners may be attached to a Cache and several ObjectListeners may be attached to an ObjectHome, the UML diagram shows a cardinality of at most 1 for those relations
    Resolution:
    Correct the figure to be in accordance with the rest of the document.
  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming inconsistencies (IDL PSM vs. PIM) for Cache operation

  • Key: DDS11-81
  • Legacy Issue Number: 8534
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The parameter of "Cache:: find_home_by_index" is named "registration_index" in the PIM and "index" in the IDL
    Resolution:
    Name everywhere that parameter "index"
  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming inconsistencies (IDL PSM vs. PIM) for ObjectHome operations

  • Key: DDS11-80
  • Legacy Issue Number: 8533
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The parameter of "ObjectHome::set_filter" operation is named "expression" in the PIM and "filter" in the IDL.
    The ObjectHome operation to register operation is named "register_object" in the UML diagram and in the ObjectHome table, but it is named "register_created_object" in the text and in the IDL.
    Resolution:
    Name everywhere "expression" the parameter of the set_filter" operation
    Name everywhere "register_object" the operation to register an object
  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTD Error (mainTopic

  • Key: DDS11-78
  • Legacy Issue Number: 8531
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The specification states that the mainTopic tag in the classMapping XML element is mandatory. However the example provided after does not contain that item, showing that it is actually not mandatory.
    Resolution:
    Change the status of that item in the DTD, to make it optional.

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_all-topic_names operation missing on figure 3-4

  • Key: DDS11-79
  • Legacy Issue Number: 8532
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The get_all_topic_names() operation is mentioned in section 3.1.6.3.5 (ObjectHome) and in the IDL, but not in Figure 3-4.
    Resolution:
    Add the missing operation on the UML diagram
  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent naming for status parameters in DataReader operations.

  • Key: DDS11-92
  • Legacy Issue Number: 8546
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In section 2.1.2.1.1.7 it is explained which entity operations may be invoked on an entity that has not yet been enabled. However, in subsequent sections describing the behavior of operations on specialized entities that are disabled, fewer than the above-mentioned operations are mentioned.
    Resolution:
    Add the missing operations for each specialized entity to the list of operations that will never return RETCODE_NOT_ENABLED. Also state explicitly that Conditions obtained from disabled entities will never trigger, until the corresponding entities become enabled.
    Revised Text:
    On page 2-13, section 2.1.2.1.1.7 it is stated that the operation that gets the StatusCondition can be invoked on a disabled entity. Add some text that specifies that a StatusCondition obtained this way will not trigger until the corresponding entity becomes enabled.
    On page 2-21, section 2.1.2.2.1 it is mentioned that for the DomainParticipant all operation except get/set_qos, get/set_listener and enable may return a RETCODE_NOT_ENABLED. To this list should be added: get_statuscondition, all factory methods (create_topic, create_publisher, create_subscriber) and all delete methods (delete_topic, delete_publisher, delete_subscriber).

    On page 2-35, section 2.1.2.3.2 it is mentioned that for the Topic all operations except get/set_qos, get/set_listener and enable may return a RETCODE_NOT_ENABLED. To this list should be added: get_statuscondition.
    On page 2-42, section 2.1.2.4.1 it is mentioned that for the Publisher all operations except get/set_qos, get/set_listener and enable may return a RETCODE_NOT_ENABLED. To this list should be added: get_statuscondition, create_datawriter, delete_datawriter.
    On page 2-48, section 2.1.2.4.2 it is mentioned that for the DataWriter all operations except get/set_qos, get/set_listener and enable may return a RETCODE_NOT_ENABLED. To this list should be added: get_statuscondition.
    On page 2-63, section 2.1.2.5.2 it is mentioned that for the Subscriber all operations except get/set_qos, get/set_listener and enable may return a RETCODE_NOT_ENABLED. To this list should be added: get_statuscondition, create_datareader and delete_datareader.
    On page 2-73, section 2.1.2.5.3 it is mentioned that for the DataRaeder all operations except get/set_qos, get/set_listener and enable may return a RETCODE_NOT_ENABLED. To this list should be added: get_statuscondition.
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior of DataReaderListener::on_data_available

  • Key: DDS11-91
  • Legacy Issue Number: 8545
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    It is not clearly defined whether the on_data_available notification should be generated on every arrival of new data, or just on the status change that happens when coming from a no data situation.
    Resolution:
    For every arrival of new data, a notification should be generated, regardless of whether the previous data has already been read before.
    Revised Text:
    Introduce textual changes to 2.1.4.2.2 that describes the complete set of conditions under which the read-communication status will change. The data available status is considered to have changed each time a new sample becomes available or the ViewState, SampleState, or InstanceState of any existing sample changes for any reason other than a read or take.
    Specific changes that cause the status to be changed include:
    · The arrival of new data
    · The disposal of an instance
    · The loss of liveliness of a writer of an instance when no other writer of that instance exists
    · Unregistration of an instance by the last writer of that instance
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#46) History when DataWriter is deleted

  • Key: DDS11-97
  • Legacy Issue Number: 8551
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The specification does not clearly describe what should happen with data in a reliable datawriter's history when the datawriter is deleted? Should it disappear immediately or wait until all messages in the history are delivered?
    Resolution:
    The right thing to do is provide some operation such that the user can wait for all data to be delivered:
    Add an operation Publisher::delete_datawriter_after_acknowledgement( Duration_t timeout). Like DataReader::wait_for_historical_data, this operation takes its own timeout rather than using ReliabilityQosPolicy::max_blocking_time because it has to potentially wait for many writes to complete. As soon as all outstanding reliable samples are acknowledged, the DataWriter will be deleted and the operation will return OK. If timeout expires, however, before all samples are acknowledged, the operation will return TIMEOUT and the writer will not be deleted.
    The regular Publisher::delete_datawriter should delete the writer immediately without waiting for any reliable samples to be acknowlwedged. Its description should be clarified accordingly. If delete_datawriter_after_acknowledgement fails, the user will then have the choice of either calling it again or accepting the possible loss of some samples and calling delete_datawriter.

    Revised Text:
    Change existing text according the resolution.
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#38) request-offered behavior for LATENCY_BUDGET

  • Key: DDS11-96
  • Legacy Issue Number: 8550
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In par. (2.1.3.7) is described that latency budget will neither prohibit connectivity nor send notifications if incompatible. However it also describes the RxO compatibility rule that will never be visible to applications. This is somewhat confusing and this description is only required because this QoS attribute is specified to be subject to the RxO pattern, however, since the description states that the latency budget is a hint to the service and that the service may apply an additional delay for optimizations then are we really speaking of RxO between datawriters and datareaders?
    Resolution:
    Make latency budget truly RxO by making connectivity dependent of compatibility rules and adding appropriate error notifications.
    Revised Text:
    Remove the "therefore the service will not fail to match…" from section 2.1.3.7
    Add new text that describes the RxO consequences
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove operations badly put on implied classes

  • Key: DDS11-90
  • Legacy Issue Number: 8543
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The "remove" operations of the collection types are mentioned in the implied IDL part, while their signatures have no typed parameters.
    In addition, the parameter for the get operation (key) wrongly starts with a capital letter (while all parameters are supposed to be in small letters)
    Resolution:
    Add those operations on the generic roots and remove them from the generated classes (implied IDL).
    Correct the spelling of the "key" parameter.
  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Attach_Listener and detach_listener operations on ObjectHome are untyped

  • Key: DDS11-89
  • Legacy Issue Number: 8542
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The ObjectListeners that need to be registered to an ObjectHome are typed (i.e. a FooListener must be attached to a FooHome), but the definition of the attach and detach methods can only be found in the generic IDL part. This way it is possible to attach a BarListener to a FooHome.
    Resolution:
    Move those operations from the generic IDL to the implied one.
  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#23) Syntax of partition strings

  • Key: DDS11-93
  • Legacy Issue Number: 8547
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In section 2.1.3 (Supported Qos) the table describes that specifying the PARTITION QOS by an empty sized sequence implies all partitions. However the default partition is specified to be exactly one partition with the name "". Any partition should be specified by means of wildcards. It is unclear how the default partition and wildcards can be used at publisher and subscriber side.
    Resolution:
    Concerning default partitions:
    The default value for PartitionQosPolicy is an empty sequence of names.The empty sequence of partition names is equivalent to a single partition name, the empty string.
    Concerning wildcards:
    "Wildcards" refers to the regular expression language defined by the POSIX fnmatch API (1003.2-1992 section B.6). Either Publisher or Subscriber may include regular expressions in partition names, but no two names that both contain wildcards will ever be considered to match. This means that although regular expressions may be used both at publisher as well as subscriber side, the service will not try to match 2 regular expressions (between publishers and subscribers).
    Revised Text:

    Change the PARTITION row of the table in 2.1.3 to state that the default value is an empty sequence, which is equivalent to a sequence containing the single element "".

    Add the text about the wildcards format and restrictions
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#37) Clarification on the value of LENGTH_UNLIMITED constant

  • Key: DDS11-95
  • Legacy Issue Number: 8549
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    It is not clear what the value of unlimited resource limits is.
    Resolution:
    Probably it is defined by the in IDL defined constant LENGTH_UNLIMITED=-1. This should be clarified.
    Revised Text:

    Replace "unlimited" with "LENGTH_UNLIMITED" in table in 2.1.3
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification of order preservation on reliable data reception

  • Key: DDS11-94
  • Legacy Issue Number: 8548
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    Does reliability include order preservation up to API level?
    In other words should data be made available to applications if older data exists but has not yet arrived (e.g. due to network irregularities), note that if a late arriving sample is accepted even after newer samples are made available then state inconsistencies may occur. In addition, not accepting a late coming sample should generate a sample lost notification.
    Resolution:
    Specify that data from a single writer (reliable and/or best-effort) will NOT be made available out-of-order.
    Revised Text:
    TBD
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

templateDef explanation contains some mistakes

  • Key: DDS11-86
  • Legacy Issue Number: 8539
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In section 3.2.2.3.2.3, the templateDef is explained. The 2nd bullet presents the possible values of the pattern attribute, but in this list "Ref" is missing. Furthermore, the example uses the wrong attribute name in its 2nd attribute: it says basis="StrMap", while this should be pattern="StrMap"
    Resolution:
    Correct the mistakes.
  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo CacheUsage instead of CacheAccess

  • Key: DDS11-85
  • Legacy Issue Number: 8538
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In section 3.1.6.5, the specification suggests that it is sensible to create a CacheUsage per thread. This should say a CacheAccess instead.
    Resolution:
    Change CacheUsage to CacheAccess in the sentence.
  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#47) Should a topic returned by lookup_topicdescription be deleted

  • Key: DDS11-98
  • Legacy Issue Number: 8552
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    It is unclear if a topic found by lookup_topicdescription (section 2.1.2.2.1.13.) should also be deleted if not used anymore similar to find_topic.
    Resolution:
    lookup_topicdescription, unlike find_topic, should search only among the locally created topics. Therefore, it should never (at least as far as the user is concerned) create a new topic description. So looking up the topic should not require any extra deletion. (It is of course permitted to delete a topic one has looked up, provided it has no readers or writers, but then it is really deleted and subsequent lookups will fail).
    Revised Text:
    Change text in section 2.1.2.2.1.13 accordingly
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong definition for FooListener

  • Key: DDS11-84
  • Legacy Issue Number: 8537
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    A wrong copy-paste lead to wrong inheritance and methods for the FooListener interface in the implied IDL (while it is correct in the PIM). In addition, the IDL for ObjectListener should have commented out the operation that is actually defined in the derived FooListener.
    FooListener is mentioned once in the PIM as FooObjectListener.
    Resolution:
    Fix the definition (based on ObjectListener) and name the class FooListener everywhere
  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter wrongly named "object" in implied IDL

  • Key: DDS11-88
  • Legacy Issue Number: 8541
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The "set" operation in the implied "FooRef" IDL class has a parameter named object. Since IDL may be used both case-sensitive and case-insensitive, this may not be allowed (possible confusion with CORBA::Object)
    Resolution:
    Name this parameter "an_object"
  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DlrlOid instead of DLRLOid in implied IDL

  • Key: DDS11-87
  • Legacy Issue Number: 8540
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In the implied IDL, "DlrlOid" is used 3 times instead of the correct "DLRLOid"
    Resolution:
    Use "DLRLOid" everywhere

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#52) Allow to explicitly refer to the default QoS

  • Key: DDS11-44
  • Legacy Issue Number: 8379
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    It would be nice to be able to use the "<item>QOS_DEFAULT" constant in both the set_default<item>_qos method of its factory and in its set_qos method as well.
    Resolution:
    Explicitly allow that passing the default qos constant ("<item>QOS_DEFAULT") to the "set_default<item>_qos" method in its factory will reset the default qos value for the item to its initial factory default state.
    Also state that using the "<item>_QOS_DEFAULT" constant in the set_qos method of an item will change the qos of that item according to the current default of its container entity at the time the call is made.
    Revised Text:
    For each "set_default_<item>_qos" method in each factory, add the fact that the "<item>_QOS_DEFAULT" constant may be used to revert it back to its factory settings. This impacts sections 2.1.2.2.1.20, 2.1.2.2.1.22, 2.1.2.2.1.24, 2.1.2.4.1.14 and 2.1.2.5.2.15.
    For each set_qos method in each entity, state that the corresponding "<item>_QOS_DEFAULT" constant may be used to change the qos of the item according to the current default of its container entity at the time the call is made, provided that this does not change any immutable qos once the entity is enabled. This impacts only section 2.1.2.1.1.1, since the set_qos method explanations are not repeated in the descriptions for every entity specialization.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#45) Clarification of syntax of char constants within query expressions

  • Key: DDS11-43
  • Legacy Issue Number: 8378
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    It is not clear how the value of a char constant should be expressed in a query expression.
    Resolution:
    Clarify that a char constant in a query expression must be places between single quotes.
    Revised Text:
    Add a bullet to Appendix B in the section "Token expression" where the char constant is introduced and where is explained how it should be defined (between single quotes, just like the tring).
    Keep Appendix C inline with this as well
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#55) Modification to how enumeration values are indicated in expressions

  • Key: DDS11-46
  • Legacy Issue Number: 8381
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    Appendix B describes an enumeration value as a name::value, during a telephone conference (in a hurry) this is decided to solve ambiguity between attribute names and enumeration labels. The description states that the name specifies the field, that should be the enumeration type. In addition the enumeration type should be a fully specified type name including its scope. This is a lot to specify in a query expression especially because within a query expression the enumeration value is always related to a field that already identifies the type. In addition in SQL enumeration labels are represented as string literals i.e. the values are put between single quotes.
    Resolution:
    Treat enumeration values as string literals and place them between single quotes instead of using a scope operator.
    Revised Text:
    In Appendix B in the section "Token expression" where the ENUMERATEDVALUE is introduced, replace the sentence that states that "A double colon '::' is used to separate the name of the enumeration from that of the field." with a sentence that states that enumeration labels should be treated as string literals and should therefore be put between single quotes. In the next sentence, remove the part which states that the name of the enumeration should correspond to the name specified in the IDL definition. (But keep the part of the sentence that states that the name of the value should correspond to the names of the labels.
    Keep Appendix C in line with this as well.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#54) Performance improvement to WaitSet

  • Key: DDS11-45
  • Legacy Issue Number: 8380
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The get_conditions and wait methods of the WaitSet pass the Conditions in which the user is interested back to the application as out-parameters. This causes unnecessary memory allocations each time a WaitSet is used for that purpose.
    Resolution:
    Make the WaitSet result sequence of the inout type for performance reasons, especially because the application is aware of the desired (worst-case) length. The user is then able to recycle these sequences every time.
    Revised Text:
    In the table in section 2.1.2.1.6 change the parameter types of the Condition Sequence from out to inout. Explain in sections 2.1.2.1.6.3 and 2.1.2.1.6.4 that the user can either pre-allocate the sequence and force the middleware to overwrite its contents, or to not to pre-allocate and let the middleware allocate the memory for him.
    Also change the IDL definition for both methods in section 2.2.3.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#57) Enable status when creating DomainParticipant

  • Key: DDS11-48
  • Legacy Issue Number: 8383
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    DomainParticipants , being entities, can be both enabled or disabled.. Because the DomainParticipantFactory is not an entity and therefore does not have a QoS, it doesn't support a Factory QosPolicy which specifies how to create a DomainParticipant (either enabled or disabled).
    Resolution:
    Add a DomainParticipantFactoryQos policy to the DomainParticipantFactory, and add the operation set_qos() and get_qos() to the DomainParticipantFactory class. (However, do not make the DomainParticipantFactory an Entity itself!)
    Revised Text:
    In section 2.1.2.2.2, add the get_qos and set_qos methods to the table. Create two new sections (2.1.2.2.2.7 and 2.1.2.2.2.8), which explain the semantics of these get_qos and set_qos. Also explain that the fact that although the DomainParticipantFactory has a qos, it is not an Entity, since it does not have any StatusConditions or Listeners and cannot be enabled.
    Add to the table in section 2.1.3 for the ENTITY_FACTORY policy in the "Concerns" column also the DomainParticipantFactory.
    Add to the IDL in section 2.2.3 the following things:

    struct DomainParticipantFactoryQos

    { EntityFactoryQosPolicy entity_factory; }

    ;

    interface DomainParticipantFactory

    { ….. ReturnCode_t set_qos(in DomainParticipantQos qos); ReturnCode_t get_qos(inout DomainParticipantQos qos); }

    ;

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#56) Return values of Waitset::detach_condition

  • Key: DDS11-47
  • Legacy Issue Number: 8382
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    section 2.1.2.1.6.2. (Waitset::detach_condition) describes to return BAD_PARAMETER if the given condition is not attached to the waitset. It would be more appropriate to return PRECONDITION_NOT_MET.

    Resolution:
    Change the return-code
    Revised Text:
    In section 2.1.2.1.6.2 (Waitset::detach_condition), change all mentioning of BAD_PARAMETER into PRECONDITION_NOT_MET.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Explicit mention of static DomainParticipantFactory::get_instance operation

  • Key: DDS11-42
  • Legacy Issue Number: 8377
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The get_instance method is mentioned in the PIM, but not in the IDL PSM.
    Resolution:
    Explicitly state that this is a static method and that it is therefore not specified in IDL.
    Revised Text:
    Add a piece of text to section 2.1.2.2.2.3 explaining that the get_instance method is a static method implemented as a native language construction, and can therefore not be expressed in IDL.
    Add the "static" keyword before the get_instance method mentioned in the table of section 2.1.2.2.2.
    Add piece of text in section 2.2.2 (right after the introduction of default constructors for WaitSet and GuardCondition) which explains that the DomainParticipantFactory has a static method called get_instance in the native classes that implement it.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#42) Behavior when condition is attached to WaitSet multiple times

  • Key: DDS11-41
  • Legacy Issue Number: 8376
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    It is not clearly defined what should happen when the same condition is attached to the same WaitSet multiple times.
    Resolution:
    Explicitly state that this has no effect: subsequent attachments of the same Condition will be ignored.
    Revised Text:
    Add a small piece of text to section 2.1.2.1.6.1, which explains that adding a Condition that is already attached to that WaitSet has no effect.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#107) Missing Topic operations in IDL PSM

  • Key: DDS11-51
  • Legacy Issue Number: 8389
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Topic interface in the PSM is missing the following operations which are present in the PIM: get_qos, set_qos, get_listener, and set_listener.

    Proposed Resolution:
    Add the missing operations to the IDL interface.

    Proposed Revised Text:
    In section 2.2.2:

    interface Topic : Entity, TopicDescription

    { ReturnCode_t get_qos(inout TopicQos qos); ReturnCode_t set_qos(in TopicQos qos); TopicListener get_listener(); ReturnCode_t set_listener( in TopicListener a_listener, StatusKindMask mask); }

    ;
  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#106b) Parameter passing convention of Subscriber::get_datareaders

  • Key: DDS11-50
  • Legacy Issue Number: 8388
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The mapping from PIM to IDL PSM for the operation Subscriber::get_datareaders represents the PIM 'out' sequence parameter to an IDL 'out' parameter. This maaping is inconsistent with that in other places in the API, in which PIM 'out' parameters are represented as 'inout' in the PSM. An 'out' parameter is also undesirable from a performance perspective.

    Proposed Resolution:
    The sequence argument to Subscriber::get_datareaders should be an 'inout' in the IDL PSM.

    Proposed Revised Text:
    In section 2.2.3:

    ReturnCode_t get_datareaders(
    inout DataReaderSeq readers,
    in SampleStateMask sample_states,
    in ViewStateMask view_states,
    in InstanceStateMask instance_states);
  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add autopurge_disposed_samples_delay to READER_DATA_LIFECYCLE QoS

  • Key: DDS11-49
  • Legacy Issue Number: 8384
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The READER_DATA_LIFECYCLE QoS specifies an autopurge_nowriter_samples_delay, however for the same reasons there should also be a autopurge_disposed_samples_delay.
    Resolution:
    Add the missing operation
    Revised Text:
    In section 2.1.3.21 add at the end:
    The autopurge_disposed_samples_delay defines the maximum duration for which the DataReader will maintain information regarding an instance once its view_state becomes DISPOSED. After this time elapses, the DataReader will purge all internal information regarding the instance, any untaken samples will also be lost
    In figure 2-12, class ReaderDataLifecycleQosPolicy, add "autopurge_disposed_samples_delay: Duration_t"
    In section 2.2.3 (IDL) add the field "Duration_t autopurge_disposed_samples_delay" to struct ReaderDataLifecycleQosPolicy
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#41) Default value for RELIABILITY max_blocking_time

  • Key: DDS11-40
  • Legacy Issue Number: 8375
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The default value of the RELIABILITY qos policy attribute max_blocking_time is not specified.
    Resolution:
    The default value shall be specified an arbitrary value greater then zero to avoid that writers will encounter timeouts on acceptable temporary buffer saturations and the value should not be too big since real-time behavior would expect that anything causing writers to block would not sustain for a long time.
    Revised Text:
    In section 2.1.3:
    Add to the description of the RELIABILITY QosPolicy value RELIABLE in the QosPolicy table the text:
    "The default max_blocking_time=100ms.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing description of DomainParticipant::get_domain_id

  • Key: DDS11-39
  • Legacy Issue Number: 8374
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In the class description of the DomainParticipant the description of the attribute domain_id is missing
    Resolution:
    The attribute domain_id shall be added to the table in 2.1.2.2.1
    The description of attribute domain_id shall be added as section 2.1.2.2.1.26
    Revised Text:
    1.1.2.2.1.26 domain_id
    The domain_id identifies the Domain of the DomainParticipant. At creation the DomainParticipant is associated to this domain
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Confusing description of behavior of Publisher::set_default_datawriter_qos

  • Key: DDS11-37
  • Legacy Issue Number: 8372
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The description of the Publisher method set_default_datawriter_qos describes the use in case the qos was not explicitly specified at the create_datawriter operation. However, specifying the qos policy at the create_datawriter is not optional, it should state in case the default is used.
    Resolution:
    The description shall be modified to clarify the use-case of using the defaults.
    Revised Text:

    In section 2.1.2.4.1.15:
    Replace "in the case where the QoS policies are not explicitly specified" with "in the case where the QoS policies are defaulted
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#33) Clarification in use of set_listener operation

  • Key: DDS11-38
  • Legacy Issue Number: 8373
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The description of the Entity method set_listener does not describe the result of this method if called with the value of the listener parameter set to NIL.
    the value NIL is passed for the listener parameter. Chapter 2.1.2.1.1.3 (set_listener): Explicitly state that passing the value NIL for the listener is valid and clears the listener.
    Resolution:
    The description of this use-case shall be added to the description.
    Revised Text:
    Only one listener can be attached to each Entity. If a listener was already set, the operation set_listener will replace it with the new one. Consequently if the value 'nil' is passed for the listener parameter to this method any existing listener will be removed.

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify meaning of LivelinessChangedStatus fields and LIVELINESS le

  • Key: DDS11-114
  • Legacy Issue Number: 8572
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    (R#132) Clarify meaning of LivelinessChangedStatus fields and LIVELINESS lease_duration

    Summary:

    The specification of LivelinessChangedStatus doesn't explain what the terms "active" and "inactive" mean nor what change is expected when various events occur. For example, the following actions should be accounted for:
    · Loss of liveliness by a previously alive writer
    · Re-assertion of liveliness on a previously lost writer
    · Normal deletion of an alive writer
    · Normal deletion of a not-alive writer
    · Assertion of liveliness on a new writer
    · A new writer is discovered (i.e. on_publication_match) but its liveliness has not yet been asserted

    The specification is also not clear about the usage of a DataReader's LIVELINESS lease_duration it is not clear whether this field is used solely for QoS compatibility comparison with matching remote writers or if it is also the rate at which the reader will update its LivelinessChangedStatus.

    Proposed Resolution:

    Change "active" to "alive" and "inactive" to "not_alive" in the LivelinessChangedStatus field names.

    In response to the list of events above:
    · Previously alive writer is lost: alive_count_change == -1, not_alive_count_change = 1
    · Lost writer re-asserts liveliness: alive_count_change == 1, not_alive_count_change == -1
    · Normal deletion of alive writer: alive_count_change == -1, not_alive_count_change == 0
    · Normal deletion of not alive writer: alive_count_change == 0, not_alive_count_change == -1
    · New writer asserts liveliness for first time: alive_count_change == 1, not_alive_count_change == 0
    · New writer but hasn't yet asserted liveliness: LivelinessChangedStatus is not changed

    Specify that the information communicated by a reader's LivelinessChangedStatus is out of date by no more than a lease_duration. That is, the reader commits to update its LivelinessChangedStatus if necessary at least once during its lease_duration, although it may update more often if it chooses.

    Proposed Revised Text:

    Add an additional paragraph to the end of section 2.1.3.10 LIVELINESS:

    The information communicated by a DataReader's LivelinessChangedStatus is out of date by no more than a single lease_duration. That is, the reader commits to updating its LivelinessChangedStatus if necessary at least once during each lease_duration, although it is permitted to update more often.

    Change active_count to alive_count, inactive_count to not_alive_count, active_count_change to alive_count_change, and inactive_count_change to not_alive_count_change in figure 2-13 on page 2-117.

    The rows for the LivelinessChangedStatus fields in the table on page 2-118 should be as follows:

    alive_count The total number of currently active DataWriters that write the Topic read by the DataReader. This count increases when a newly matched DataWriter asserts its liveliness for the first time or when a DataWriter previously considered to be not alive reasserts its liveliness. The count decreases when a DataWriter considered alive fails to assert its liveliness and becomes not alive, whether because it was deleted normally or for some other reason.

    not_alive_count The total count of currently DataWriters that write the Topic read by the DataReader that are no longer asserting their liveliness. This count increases when a DataWriter considered alive fails to assert its liveliness and becomes not alive for some reason other than the normal deletion of that DataWriter. It decreases when a previously not alive DataWriter either reasserts its liveliness or is deleted normally.

    alive_count_change The change in the alive_count since the last time the listener was called or the status was read.

    not_alive_count_change The change in the not_alive_count since the last time the listener was called or the status was read.

    Change active_count to alive_count, inactive_count to not_alive_count, active_count_change to alive_count_change, and inactive_count_change to not_alive_count_change in the IDL PSM on page 2-141.
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#126) Correction to DataWriter blocking behavior

  • Key: DDS11-113
  • Legacy Issue Number: 8571
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS spec currently states that the max_blocking_time parameter of the RELIABILITY QoS only applies for data writers that are RELIABLE and have HISTORY QoS of KEEP_ALL.

    These assertions are not true. Depending on the RESOURCE_LIMITS QoS, even a KEEP_LAST writer may eventually need to block.

    Proposed Resolution:

    The specification needs to be updated in the table of QoS in Section 2.1.3 and in the DataWriter section 2.1.2.4.2.10 for write to account for the case in which (max_samples < max_instances * HISTORY depth). In this case, the writer may attempt to write a new value for an existing instance whose history is not full and fail because it exceeds the max_samples limit. Therefore, if (max_samples < max_instances * HISTORY depth), then in the situation where the max_samples resource limit is exhausted the middleware is allowed to discard samples of some other instance as long as at least one sample remains for that instance. If it is still not possible to make space available for the new sample, the writer is allowed to block.

    The behavior in the case where max_samples < max_instances must also be described. In that case the writer is allowed to block.

    Proposed Revised Text:

    In the QoS table in 2.1.3, change the first sentence of the "Meaning" cell of the RELIABILITY max_blocking_time row to: "This setting applies only to the case where kind=RELIABLE."

    In section 2.1.2.4.2.10, replace the final paragraph with the following:

    If the RELIABILITY kind is set to RELIABLE, the write operation on the DataWriter may block if the modification would cause data to be lost or else cause one of the limits specified in the RESOURCE_LIMITS to be exceeded. Under these circumstances, the RELIABILITY max_blocking_time configures the maximum time the write operation may block waiting for space to become available. If max_blocking_time elapses before the DataWriter is able to store the modification without exceeding the limits, the write operation will fail and return TIMEOUT.

    Specifically, the DataWriter may block in the following situations (although the list may not be exhaustive), even if its HISTORY kind is KEEP_LAST.

    · If (RESOURCE_LIMITS max_samples < RESOURCE_LIMITS max_instances * HISTORY depth), then in the situation where the max_samples resource limit is exhausted the Service is allowed to discard samples of some other instance as long as at least one sample remains for such an instance. If it is still not possible to make space available to store the modification, the writer is allowed to block.

    · If (RESOURCE_LIMITS max_samples < RESOURCE_LIMITS max_instances), then the DataWriter may block regardless of the HISTORY depth.

    In section 2.1.3.13 RELIABILITY, the second paragraph currently states:

    The setting of this policy has a dependency on the setting of the HISTORY and RESOURCE_LIMITS policies. In case the RELIABILITY kind is set to RELIABLE and the HISTORY kind set to KEEP_ALL the write operation on the DataWriter may block if the modification would cause data to be lost or else cause one of the limits specified in the RESOURCE_LIMITS to be exceeded.

    The above text should be rewritten as follows:

    The setting of this policy has a dependency on the RESOURCE_LIMITS policy. In case the RELIABILITY kind is set to RELIABLE the write operation on the DataWriter may block if the modification would cause data to be lost or else cause one of the limits specified in the RESOURCE_LIMITS to be exceeded.
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#117) No way to access Participant and Topic built-in topic data

  • Key: DDS11-112
  • Legacy Issue Number: 8570
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification already provides the operations get_matched_publication_data and get_matched_subscription_data on the DataReader and DataWriter. These operations allow applications to look up information about entities that exist in the domain without having to use the built-in DataReaders directly. It would be useful to have the corresponding ability to look up information about remote DomainParticipants and Topics; however, no such operations exist.

    Proposed Resolution:

    Add the following operations:
    · ReturnCode_t DomainParticipant::get_discovered_participants(inout InstanceHandle_t[] participant_handles)
    · ReturnCode_t DomainParticipant::get_discovered_participant_data(inout ParticipantBuiltinTopicData publication_data, InstanceHandle_t participant_handle)
    · ReturnCode_t DomainParticipant::get_discovered_topics(inout InstanceHandle_t[]topic_handles)
    · ReturnCode_t DomainParticipant::get_discovered_topic_data(inout TopicBuiltinTopicData topic_data, InstanceHandle_t topic_handle)

    Proposed Revised Text:

    Add the names of the aforementioned new operations to figure 2-6.

    Append the following rows to the DomainParticipant Class table in 2.1.2.2.1:

    get_discovered_participant_data ReturnCode_t
    inout: publication_data ParticipantBuiltinTopicData
    participant_handle InstanceHandle

    get_discovered_participants ReturnCode_t
    inout: participant_handles InstanceHandle_t []

    get_discovered_topic_data ReturnCode_t
    inout: topic_data TopicBuiltinTopicData
    topic_handle InstanceHandle

    get_discovered_topics ReturnCode_t
    inout: topic_handles InstanceHandle_t []

    Insert new sections to describe the new operations:

    2.1.2.2.1.26 get_discovered_participant_data

    This operation retrieves information on a DomainParticipant that has been discovered on the network. The participant must be in the same domain as the participant on which this operation is invoked and must not have been "ignored" by means of the DomainParticipant ignore_participant operation.

    The participant_handle must correspond to such a DomainParticipant. Otherwise, the operation will fail and return PRECONDITION_NOT_MET.

    Use the operation get_matched_participants to find the DomainParticipants that are currently discovered.

    The operation may also fail if the infrastructure does not hold the information necessary to fill in the participant_data. In this case the operation will return UNSUPPORTED.

    2.1.2.2.1.27 get_discovered_participants

    This operation retrieves the list of DomainParticipants that have been discovered in the domain and that the application has not indicated should be "ignored" by means of the DomainParticipant ignore_participant operation.

    The operation may fail if the infrastructure does not locally maintain the connectivity information. In this case the operation will return UNSUPPORTED.
    2.1.2.2.1.26 get_discovered_topic_data

    This operation retrieves information on a Topic that has been discovered on the network. The topic must have been created by a participant in the same domain as the participant on which this operation is invoked and must not have been "ignored" by means of the DomainParticipant ignore_topic operation.

    The topic_handle must correspond to such a topic. Otherwise, the operation will fail and return PRECONDITION_NOT_MET.
    Use the operation get_discovered_topics to find the topics that are currently discovered.

    The operation may also fail if the infrastructure does not hold the information necessary to fill in the topic_data. In this case the operation will return UNSUPPORTED.

    2.1.2.2.1.27 get_discovered_topics

    This operation retrieves the list of Topics that have been discovered in the domain and that the application has not indicated should be "ignored" by means of the DomainParticipant ignore_topic operation.
    The operation may fail if the infrastructure does not locally maintain the connectivity information. In this case the operation will return UNSUPPORTED.
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#115b) Incorrect description of QoS for built-in readers

  • Key: DDS11-111
  • Legacy Issue Number: 8569
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:

    In Section 2.1.5, there is a table that lists all the QoS policies that are used to create built-in readers. Since the policies are for creating built-in readers, the table should only list the QoS for the corresponding subscriber, reader, and topic. It shouldn't list any policies that occur only in DataWriterQos. Specifically, TRANSPORT_PRIORITY, LIFESPAN, and OWNERSHIP_STRENGTH, all of which apply only to DataWriters, are currently listed erroneously.
    The following QoS are supposed to apply to DataReaders (or their related entities) but are missing from the table: ReaderDataLifecycleQosPolicy, EntityFactoryQosPolicy

    For the QoS that are already listed in the table, some of them don't list the default values of some of the fields.

    DURABILITY: missing service_cleanup_delay value
    RELIABILITY: missing max_blocking_time value

    Proposed Resolution:

    Remove TRANSPORT_PRIORITY, LIFESPAN, and OWNERSHIP_STRENGTH from the table.

    Add the following values:

    READER_DATA_LIFECYCLE autopurge_nowriter_samples_delay = INFINITE
    ENTITY_FACTOR autoenable_created_entities = TRUE
    DURABILITY service_cleanup_delay = 0
    RELIABILITY max_blocking_time = 100 milliseconds

    Proposed Revised Text:
    Change the table in section 2.1.5, page 2-129, as described above.
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#65) Missing get_current_time() function

  • Key: DDS11-106
  • Legacy Issue Number: 8560
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The DDS supports timestamping of information, either automatically or manually. These timestamps also appear in the SampleInfo data. What is missing is a get_current_time() call that allows applications to retrieve the current-time in the format as is utilized by the DDS. This means that the returned format and starting-time is the same as is used by the default/internal DDS timestamping.

    Resolution:
    Add such a 'get_current_time()' function to the participant class
    Revised Text:
    Add and explain the method and update the PSM.
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#62, R#141) Unspecified TOPIC semantics

  • Key: DDS11-105
  • Legacy Issue Number: 8559
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    a) The semantics of the DURABILITY Qos attribute "service_cleanup_delay" in relation to RxO mechanism is not specified.
    b) There is no relation between the history and resource-limits of the durability-service and the history and resource-limits of readers and writers.
    c) the durability-service still has to be configured by means of the above mentioned parameters: 'service_cleanup_delay', 'history' and 'resource-limits'
    Resolution:
    Remove service_cleanup_delay from the DURABILITY QoS policy for readers and writers.
    Add a new QoS "DURABILITY_SETTINGS" on the Topic whose sole purpose is to configure the durability service. The QoS policy should include the parameters: 'service_cleanup_delay', 'history' and 'resource-limits'.
    Revised Text:
    Remove the service_cleanup_delay from the DURABILITY QoS for readers and writers
    Remove the history QoS and resource-limits QoS policies from the TopicBuiltinTopicData
    Add the new DURABILITY_SETTINGS QoS and explain its behavior/meaning.
    Add this QoS policy also to the TopicBuiltinTopicData.
    Update the PSM accordingly
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#136) Additional operations allowed on disabled entities

  • Key: DDS11-116
  • Legacy Issue Number: 8574
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification states that before an entity is enabled, the only operations that can be invoked on it are get/set listener, get/set QoS, get_statuscondition, and factory methods. This list is unnecessarily restrictive.

    Proposed Resolution:

    The following operations should also be allowed:
    · TopicDescription::get_name
    · TopicDescription::get_type_name
    · DomainParticipant::lookup_topicdescription
    · Publisher::lookup_datawriter
    · Subscriber::lookup_datareader
    · Entity::get_status_changes and all get_*_status operations. Note that no status is considered 'triggered' when an Entity is disabled.
    · All get_/set_default_*_qos operations

    Proposed Revised Text:

    Revise the fourth paragraph of section 2.1.2.1.1.7 enable to read:
    If an Entity has not yet been enabled, the following operations may be invoked on it in general:
    · Operations to set or get an Entity's QoS policies (including default QoS policies) and listener
    · get_statuscondition
    · 'factory' operations
    · get_status_changes and other get status operations (although no status of a disabled entity is ever considered changed)
    · 'lookup' operations

    Other operations may explicitly state that they may be called on disabled entities; those that do not will return the error NOT_ENABLED.

    Add the following sentence to sections 2.1.2.3.1.2 (TopicDescription::get_type_name) and 2.1.2.3.1.3 (TopicDescription::get_name): "This operation may be invoked on a Topic that is not yet enabled or on a ContentFilteredTopic or MultiTopic based on such a Topic."
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#133) Clarify meaning of LivelinessLost and DeadlineMissed

  • Key: DDS11-115
  • Legacy Issue Number: 8573
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not state whether the LivelinessLostStatus should be considered changed (and the on_liveliness_lost listener callback called) once-when the writer first lost its liveliness-or whether should it be called after every period in which the writer fails to assert its liveliness. For example, if a writer with liveliness set to MANUAL_BY_TOPIC doesn't write for two LIVELINESS lease_duration periods, should the writer listener's on_liveliness_lost callback be called once per lease_duration, or should the callback be called only once after the first lease_duration?

    The analogous ambiguity exists with respect to the *DeadlineMissedStatuses.

    Proposed Resolution:

    The cases are somewhat different in that the deadline is under the application's control while a loss of liveliness is not (e.g. it may occur as a result of a network failure). Therefore, the *DeadlineMissed statuses should be considered changed (and the listeners invoked) at the end of every deadline period. The LivelinessLostStatus, on the other hand, should be considered changed only when a writer's state changes from alive to not alive, not after every lease_duration period thereafter.

    Proposed Revised Text:

    Change the description in the RequestedDeadlineMissed total_count row of the table in 2.1.4.1 (page 2-118) to read: "Total cumulative number of missed deadlines detected for any instance read by the DataReader. Missed deadlines accumulate; that is, each deadline period the total_count will be incremented by one for each instance for which data was not received."

    Change the description in the LivelinessLostStatus total_count row of the table in 2.1.4.1 (page 2-119) to read: "Total cumulative number of times that a previously-alive DataWriter became not alive due to a failure to actively signal its liveliness within its offered liveliness period. This count does not change when an already not alive DataWriter simply remains not alive for another liveliness period."

    Change the description in the OfferedDeadlineMissed total_count row of the table in 2.1.4.1 (page 2-119) to read: "Total cumulative number of offered deadline periods elapsed during which a DataWriter failed to provide data. Missed deadlines accumulate; that is, each deadline period the total_count will be incremented by one."
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#61) Restrictive Handle definition

  • Key: DDS11-104
  • Legacy Issue Number: 8558
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The current IDL PSM contains the following lines:

    #define HANDLE_TYPE_NATIVE long
    #define HANDLE_NIL_NATIVE 0

    typedef HANDLE_TYPE_NATIVE InstanceHandle_t;
    const InstanceHandle_t HANDLE_NIL = HANDLE_NIL_NATIVE;

    The two #defines can be vendor-specific. However, the constant definition in the last line restricts the HANDLE_TYPE_NATIVE to be of integer, char, wide_char, boolean, floating_pt, string, wide_string, fixed_pt or octet type; IDL does not allow any other (e.g. structured) types to be assigned a constant value.
    Resolution:
    The PSM contains a number of other elements that cannot be accurately expressed in IDL (e.g. static methods). As in those other cases, a comment should be added stating that structured and other non-primitive types may be used for HANDLE_TYPE_NATIVE and HANDLE_NIL_NATIVE even though IDL can't express it
    Revised Text:
    Mention the above in the introduction of the PSM.
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#60) Asynchronous write

  • Key: DDS11-103
  • Legacy Issue Number: 8557
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    Some customers require guarantees on delivery to the network, i.e. a means to block until the service can guarantee that the data will be or is received by all recipients.
    Resolution:
    Add a Publisher::wait_for_acknowlegments(timeout) method that will block until all data written by all its writers has been acknowledged. If called with Publisher is suspended it will return PRECONDITION_NOT_MET
    Revised Text:
    Add a paragraph describing the function, add the function to the publisher-table, change the PSM to include the new function.
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#69) Notification of unsupported QoS policies

  • Key: DDS11-108
  • Legacy Issue Number: 8562
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    If a QoS policy is not supported (i.e. is part of an unsupported profile) but the user supplies a non-default value for it, how should the system react
    Resolution:
    Just return UNSUPPORTED
    Revised Text:
    Add a remark in the specification that retcode UNSUPPORTED is returned when supplying a QoS-policy that is not supported by the middleware (i.e. is part of an optional-profile that is not supported by the specific middleware implementation)
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Read or take next instance, and others with an illegal instance_handle

  • Key: DDS11-107
  • Legacy Issue Number: 8561
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    Whenever an instance handle is passed as an input-parameter to a dataReader method, it may be invalid e.g. because they are disposed and reclaimed. The semantics of this case should be clarified.
    Resolution:
    Assuming that implementations want to check for invalid handles, they should generically return 'BAD_PARAMETER'.
    Revised Text:
    Specify that BAD_PARAMETER is returned when providing illegal handles to:
    · Read/Take_instance
    · Read/Take_next_instance
    · Read/Take_next_instance_with_condition
    · Get_key_value (both on dataReader and dataWriter)
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#53) Cannot set listener mask when creating an entity

  • Key: DDS11-100
  • Legacy Issue Number: 8554
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The entity::set listener method sets a listener in combination with a mask that specifies the event interest. Listeners can also be set at construction of entities by passing the listener as parameter to the entity factory method. However it is not possible to set a mask during construction.
    Resolution:
    Add an event mask parameter (listener_mask) to entity constructors.
    Revised Text:
    Change signature and description of all entity factory methods.
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#51) Identification of the writer of a sample

  • Key: DDS11-99
  • Legacy Issue Number: 8553
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    For applications it is not possible to relate a sample to its datawriter. There are many use cases where it is required to be able to make such a relation
    Resolution:
    Add an 'InstanceHandle_t publication_handle' field (the handle to the remote writer, not the data instance) to SampleInfo. The user can use this handle to call get_matched_publication_data ()
    Revised Text:
    Change SampleInfo definition and related explanation accordingly.
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#104) Inconsistent naming of QueryCondition::get_query_arguments

  • Key: DDS11-110
  • Legacy Issue Number: 8568
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The operations QueryCondition::get_query_arguments and QueryCondition::set_query_arguments are named inconsistently with respect to similar operations on the ContentFilteredTopic and the MultiTopic.

    Proposed Resolution:

    Rename get_query_arguments to get_query_parameters and set_query_arguments to set_query_parameters both in the PIM and PSM.

    Proposed Revised Text:

    Rename get_query_arguments to get_query_parameters and set_query_arguments to set_query_parameters in the table in section 2.1.2.5.9. Rename set_query_arguments to set_query_parameters in the paragraph immediately following the table in the same section.

    Rename get_query_arguments to get_query_parameters in the title of section 2.1.2.5.9.2. Rename set_query_arguments to set_query_parameters within that section (two occurrences).

    Rename set_query_arguments to set_query_parameters in the title to section 2.1.2.5.9.3.

    Rename set_query_arguments to set_query_parameters in figure 2-18.
    Rename get_query_arguments to get_query_parameters and set_query_arguments to set_query_parameters in the IDL PSM in section 2.3.3, page 2-144.
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

O#7966) Confusing terminology: "plain data structures"

  • Key: DDS11-109
  • Legacy Issue Number: 8567
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.1.2.2 states: "At the DCPS level, data types represent information that is sent atomically. For performance reasons, only plain data structures are handled by this level." It is not clear what "plain data structures" means.

    Proposed Resolution:
    Remove the second sentence quoted above from the specification.

    Proposed Revised Text:
    Remove the sentence "For performance reasons, only plain data structures are handled by this level" from section 2.1.1.2.2, page 2-7.
  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#59) Deletion of disabled entities

  • Key: DDS11-102
  • Legacy Issue Number: 8556
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    Currently entities must be enabled before they can be deleted.
    Resolution:
    Specify that entities may be deleted if not enabled.
    Revised Text:
    Explicilty state on each class that the delete method can be called also on disabled entities.
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#53) Cannot set listener mask when creating an entity

  • Key: DDS11-101
  • Legacy Issue Number: 8555
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The entity::set listener method sets a listener in combination with a mask that specifies the event interest. Listeners can also be set at construction of entities by passing the listener as parameter to the entity factory method. However it is not possible to set a mask during construction.
    Resolution:
    Add an event mask parameter (listener_mask) to entity constructors.
    Revised Text:
    Change signature and description of all entity factory methods.
  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-112 Value_of_data_for_DISPOSED_state

  • Key: DDS-146
  • Legacy Issue Number: 6856
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.5.3 of the specification does not clearly state that the
    data_value and the sample_info sequences returned by the read* and
    take* operations must be of the same length and are in one-to-one
    correspondence

    Furthermore, the specification does not describe what the element of
    the DataSeq should be when the SampleInfo states that the
    lifecycle_state is DISPOSED

    Same issue when the lifecycle_state is NO_WRITERS

    These should be clarified

    **PROPOSAL**

    This must be rephrased in accordance with the proposal in Ref-84.

    State in section 2.1.2.5.3 that both sequences are of the same length
    and in one-to-one correspondence

    State that when the that when the liveness_lifecycle is DISPOSED
    (NO_WRITERS or EXPLICIT) the last sample for the instance, that is the
    one with instance_rank==0 has no corresponding data
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-85 Garbage_collection_of_disposed_instances

  • Key: DDS-145
  • Legacy Issue Number: 6855
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In the current specification, the applications are fully responsible
    for the resource usage. Applications have means to detect when
    lifecycles end and resources can be freed. However even if
    applications are to be written correctly not all cases are covered and
    some situations potential produce garbage, that is memory that remains
    in use and never reclaimed.

    The following are potential scenarios:

    Instances become disposed but the application does not 'take' the
    sample and therefore does not allow the middleware to end the
    lifecycle and remove the state regarding the instance

    Instances that no longer have any "active" writers and consequently
    get no more samples.

    Even if the application 'takes' the disposed instance or instances
    with no writers it is not always possible for the middleware to
    reclaim the resources. This can occur in two cases; in case of the
    service keeping Transient and Persistent data and in case of
    incomplete MultiTopic samples. In both cases an immediate removal of
    samples is not desirable but eventually the samples should be removed

    On the one hand deleting the instances immediately will potentially
    cause problems since late coming readers may require the disposed
    instances, e.g. reallocating consumers requiring disposed instances to
    finish interrupted cleanup actions or MultiTopics joining Topics with
    different lifecycles.

    On the other hand the disposed instances cannot be kept
    indefinitely. Doing this will eventually flood the system, especially
    for Topics with increasing key-values.

    The solution is to keep them for a certain duration and then reclaim
    the resources the question is how long this duration should be?

    Note that, in general, just because a sample has been disposed the
    middleware cannot reclaim all the resources on it either on the writer
    side or on the reader side. For the middleware to reclaim resources it
    is necessary that the instance is also unregistered; otherwise
    disposing would automatically relinquish ownership which is not the
    desired behavior.

    This applies both to the writer side, the reader side, and/or the
    transient/persistent durability service.

    On the writer side it is therefore clear. Resources are only fully
    reclaimed when the instance is unregistered.

    So the tricky issue is how to handle the case where an instance has no
    writers, whether it had been disposed or not, whether there are
    samples in the queue or not. Nominally we notify the application of
    this event by some means (see Issue #84). The application should then
    take the samples.

    One approach would be for the middleware to keep some resources around
    for a certain duration (DISPOSE_LIFESPAN) in case this was just a
    transient situation and the instance appears again. This treats the
    DISPOSED_NO_WRITERS similarly to the DISPOSED_EXPLICIT

    **PROPOSAL**

    Add a new QoS on the DataReader called NO_WRITERS_LIFESPAN with a
    single Duration_t field "duration". It is mutable with a default
    value equal to DURATION_INFINITY. This represents the duration for
    which the DataReader should keep the knowledge of an instance once it
    detects it has NO_WRITERS.

    After the instance has no writers the middleware is not required to
    keep the information about the instance any longer than the
    NO_WRITERS_LIFESPAN. The implication is that if an instance becomes
    DISPOSED_NO_WRITERS and the application does not take the instance for
    a time that exceeds the NO_WRITERS LIFESPAN the application could miss
    the fact that the instance has DISPOSED and has no writers.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 53] Refactor lifecycle state

  • Key: DDS-144
  • Legacy Issue Number: 6854
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-84 Lifecycle_state_refactor

    The precise interpretation and representation of the lifecycle and
    sample states in the specification is not clear.

    Figure 2-11 is not easy to interpret as it refers to "observable"
    lifecycles rather than representing some internal state that the
    application accesses.

    Several issues are left open such as

    Whether what happens if in the sample history of a single instance are
    new, modified, and deleted samples (i.e. the instance was disposed and
    then created again before the reader accessed it). An additional
    question is then whether the read/take will return samples belonging
    to multiple "generations" of the instance.

    How can an application determine that as a result of a single
    read/take operation multiple samples of the same instance appear. This
    may be important because the processing a new/modified sample may
    depend on the number of samples the application has for that instance.

    Also the representation of the instance_state as an enumeration:
    NEW/MODIFIED/DELETED/NO_WRITERS is not natural. If this represents the
    state of the instance, then the instance can be simultaneously
    MODIFIED and DELETED; it can be MODIFIED and have no writers,
    etc. That is logically these are not mutually exclusive

    **PROPOSAL**

    Change the description in section 2.1.2.5.1 and representation
    lifecycle as described below.

    Replace the lifecycle_state with the following two variables (flags)

    observation_lifecycle =

    {NEW, NOT_NEW}

    liveness_lifecycle =

    { ALIVE , DISPOSE_EXPLICIT, DISPOSED_NO_WRITERS }

    Define DISPOSED as the union (DISPOSED_EXPLICIT | DISPOSED_NO_WRITERS)

    The observation_lifecycle and liveness_lifecycle are independent. All
    combinations are possible. So the lifecycle may be simultaneously NEW
    & DISPOSED_EXPLICIT, NOT_NEW & ALIVE, etc.

    All the samples in the history of an instance have the same
    "lyfecycles" states. Each time a sample is received (or a loss of
    liveliness on a remote DataWriter is detected) the liveness_lifecycle
    may change. If it changes it changes for all samples belonging to the
    same instance.

    If an instance was DISPOSED (either DISPOSED_EXPLICIT or
    DISPOSED_NO_WRITERS) and a samplefor that instance is received, the
    liveness_lifecycle of the instance changes to ALIVE.

    If a sample is received for a DataWriter, indicating that the ser has
    called "dispose" for that instance then the liveness_lifecycle of the
    instance changes to DISPOSED_EXPLICIT.

    If the infrastructure detects the loss of liveness of a DataWriter for
    the instance and this is the only DataWriter writing the instance
    known to the reader then the liveness_lifecycle of the instance
    changes to DISPOSED_NO_WRITERS

    Each time the liveliness of an instance changes from ALIVE to
    DISPOSED_EXPLICIT an internal count maintained per instance
    (disposed_explicit_count) is incremented. Each time the liveliness of
    an instance changes from ALIVE to DISPOSED_NO_WRITERS an internal
    count maintained per instance (disposed_no_writers_count) is
    incremented.

    The observation_lifecycle and liveness_lifecycle as well as the
    disposed_explicit_count and disposed_no_writers_count appear in the
    SampleInfo returned when the application reads/takes samples. This
    counters are from the perpective of the DataReader and start at 0 when
    the liveness_lifecycle is NEW

    Each time the application reads or takes samples, all returned samples
    for any one instance have the same observation_lifecycle and
    liveness_lifecycle. They represents the "snapshot" of the
    corresponding values for the instance taken at the time the data is
    read or taken.

    The disposed_explicit_count and disposed_no_writers_count in
    SampleInfo are not the same. On all samples. They represent the number
    of lifecycles of each kind that the instance had gone through at the
    time the sample stored into the history queue. The application can use
    this to distinguish samples belonging to different generations. In
    addition the SampleInfo contains an additional filed. The
    "instance_rank" that specifies how many samples for the same instance
    follow in the sequence retuned as part of the read/take. This helps
    the application anticipate that more samples for the same instance
    follow. The last sample for the instance returned will always have a
    instance_rank==0

    In addition the SampleInfo contains an additional filed. The
    "generation_rank" that specifies the generation to which the sample
    belongs relative to the generations

    The observation_lifecycle, liveness_lifecycle, disposed_explicit_count
    and disposed_no_writers can be used as in the expressions used for the
    purposes of making a Query.

    Figure 2-11 should be updated to reflect the state-transitions
    described above.

    Both the read and take operations affect the
    observation_lifecycle. The first time the application reads/takes
    samples for an instance the observation_lifecycle will be NEW. After
    the observation_lifecycle will be NOT_NEW.

    Once the application reads/takes samples with the liveness_lifecycle
    DISPOSED (either EXPLICIT or NO_WRITERS), the observation_lifecycle is
    'reset' and if new samples are received for that instance the
    observation_lifecycle will be set to NEW again.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 52] Provide for zero copy access to data

  • Key: DDS-143
  • Legacy Issue Number: 6853
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-121 Add_a_return_loan_operation_to_datareader

    For high-performance it is desirable to use a zero-copy API on the
    receive side where the middleware can "loan" buffers to the
    application on the "read" or "take" operations.

    However the use of "zero-copy" requires a mechanism for the
    application to indicate that it no longer needs access to the "loaned
    buffers"

    One possibility would be to an operation DataReader::finish or
    DataReader::return_loan that takes the SampleData and SampleInfo
    sequences as parameter and indicates to the middleware that the
    application is no longer accessing the buffers in the corresponding
    sequences.

    Another possibility would be to add a separate API for read/take

    **PROPOSAL**

    No concrete proposal yet
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-231 Provide_a_way_to_limit_count_returned_samples

  • Key: DDS-149
  • Legacy Issue Number: 6859
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Could be that the result of the read is many samples (100000s). This
    would be bad for the application.

    **PROPOSAL**

    No concrete proposal as it would be hard to represent in IDL but it
    would be nice if such API was offered.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 54] Refactor or extend API used to access samples

  • Key: DDS-148
  • Legacy Issue Number: 6858
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-74 Refactor_the_api_used_to_access_samples

    The read() and take() operations return a "one-dimensional" array of
    samples.

    For the case where the PRESENTATION.access_scope==BY_INSTANCE and
    either HISTORY.kind == KEEP_ALL or HISTORY.depth > 1 it is desirable
    that the application can easily access all the samples that correspond
    to one instance versus the samples that correspond to other
    instances. For this purpose a 2-dimensional array (or sequence) where
    a is preferable. That would allow for example to determine easily how
    many samples are for each instance (before examining all) and also
    easily examine the "first" or "last" sample of each instance without
    navigating though all the other instances

    What we would like is something like:

    struct FooSample

    { struct SampleInfo *info; struct Foo *data; }

    ;

    typedef sequence<FooSample> FooSampleSeq;

    read(out FooSampleSeq sample_seq);

    typedef sequence<FooSampleSeq>; FooSampleCollatedSeq;

    read_collated(out FooSampleCollatedSeq collated_seq);

    Data would be then accessed as

    sample_seq[i]->data;

    Or else as

    collated_seq[k][I]->data

    However t is not clear how to map this to the IDL PSM.

    **PROPOSAL**

    No concrete proposal as it would be hard to represent in IDL but it
    would be nice if such API was offered.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-113 Meta_sample_accounting_towards_resource_limits

  • Key: DDS-147
  • Legacy Issue Number: 6857
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Related to 112

    The specification does not mention whether the DISPOSED samples count
    towards the RESOURCE_LIMITS (max samples and such)

    Although this detail unspecified, it is something that would become
    observable to the user if, for some reason, an application does not
    "take" disposed samples.

    **PROPOSAL**

    State that these samples don't count towards the limits because they
    do not have "data" associated with it. Moreover in view of Ref-84
    there can be at most one such SampleInfo per instance so the
    worst-case needed resources are small and can be taken into account by
    the implementation
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    duplicate
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping DCPS-DLRL

  • Key: DDS-161
  • Legacy Issue Number: 7058
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Currently the specified mapping is rather strict with respects to the mapping between the DLRLOid and the DCPS topic keys. When an existing DCPS schema is reused, more flexibility would be desirable
    In particular, there exist cases when there are no DCPS keys at all (should correspond to a singleton class)
    In some circumstances, the indication of the class name while needed in the main topic (to guess what is the type of the corresponding object) is not needed in the relations to objects of that type
  • Reported: DDS 1.0b1 — Mon, 1 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

New definition for ObjectFilter

  • Key: DDS-160
  • Legacy Issue Number: 7057
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]:
    Selection could be slightly enhanced, by providing to the filter the fact if the object was previously a member.
    proposal [THALES]
    carry the fact that the object was previously part of the selection to the filter so that it may return quicker the result when appropriate
    Concrete changes
    IDL
    enum MembershipState

    { UNDEFINED_MEMBERSHIP, ALREADY_MEMBER, NOT_MEMBER }

    ;

    local interface ObjectFilter

    { /*IMPLIED* boolean check_object ( in Object an_object, in MembershipState membership_state); [addition of this parameter] *IMPLIED*/ }

    ;
    in section 3.1.6.3.8 ObjectFilter
    in the table, add a parameter to the check_object operation by adding the following entry:
    membership_state enum MembershipState
    in the following text, add the following text to the bullet
    [check ... (check_object);] this method is called with s first parameter the object to be checked and as second parameter an indication whether the object previously passed the filter (membership_state); this last parameter (which is actually an enumeration with three possible values - UNDEFINED_MEMBERSHIP, ALREADY_MEMBER and NOT_MEMBER) is useful when the ObjectFilter is attached to a Selection to allow the writing of optimized filters.
    ref-1051: New definition for Selections (clarification)
    Issue [THALES]
    As notification_scope has been removed from the ObjectHome (cf. issue ref-1049), it is necessary to pass the information whether the modification of objects inside a Selection should be appreciated only on the object basis, or on the object + its contained objects basis
    clarification is requested regarding when the SelectionListener is activated
    Proposal [THALES]
    add a parameter concerns_contained when the Selection is created and add this characteristic in the selection attributes
    add a paragraph to specify when the Selection Listener is activated
    in SelectionListener::on_object_out, the ObjectRoot may no more exist, therefore passing the ObjectReference is better
    Concrete changes
    in IDL
    local interface Selection

    { ... readonly attribute boolean concerns_contained; [addition] ... }

    ;
    local interface SelectionListener

    { ... [the following method is no more commented out for it will not be redefined in the derived implied IDL] void on_object_out ( in ObjectReference the_ref); [instead in ObjectRoot the_object] }

    ;
    in section 3.1.6.3.7 Selection
    in the table, attribute list, add the following entry (as third attribute)
    concerns_contained boolean
    in the following text, starting with "It has the following attributes:"
    add the following text at the end of the second bullet:
    "; it is given at Selection creation time(cf. ObjectHome::create_selection)"
    add a bullet in third position, with the following content:
    "a boolean concerns_contained that indicates whether the Selection considers the modification of one of its members based on its content only (FALSE) or based on it content or the content of its contained objects (TRUE); it is given at Selection creation time(cf. ObjectHome::create_selection);"
    add at the end of the section, the following paragraph:
    "The SelectionListener is activated when the composition of the Selection is modified or when one of its members is modified. A member can be considered as modified, either only when it is itself modified or when itself or one of its contained objects is modifie (depending on the value of concerns_contained). Modifications in the Selection are considered with respects to the state of the Selection last time it was examined, i.e.:
    add one bullet with the following text:
    " at each incoming updates processing if autro_refresh is TRUE;"
    add a second bullet with the following text:
    "at each explicit call to refresh, if auto-refresh is FALSE."
  • Reported: DDS 1.0b1 — Mon, 1 Mar 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

clean_modified (in ObjectRoot, Relations...)

  • Key: DDS-159
  • Legacy Issue Number: 7026
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    These operations are error-prone when there are called by the developer.
    Proposal [THALES]
    suppress them and specify that the internal cleaning of modifications is performed after the last call to listeners
    Concerns the interfaces
    ObjectRoot
    CollectionBase (was CollectionOperations)
    RefRelation (was ReferenceOperations)
    Concrete changes:
    IDL
    suppress the following operations
    ObjectRoot::clean_modified
    CollectionBase::clean_modified
    RefRelation::clean_modified
    in section 3.1.6.3.11 ObjectRoot
    in the table, suppress the 2 lines that describe the operation clean_modified
    in the following list of methods (starting with "it offers methods to") suppress the last bullet
    in section 3.1.6.3.13 Reference
    in the table, suppress the 2 lines that describe the operation clean_modified
    in the following list of methods (starting with "it offers methods to") suppress the last bullet
    in section 3.1.6.3.14 Collection
    in the table, suppress the 2 lines that describe the operation clean_modified
    in the following list of methods (starting with "it offers methods to") suppress the last bullet
    in section 3.1.6.4.1 General Scenario
    in the last bullet, suppress the end of the sentence "(if not already done)"
    Finally [..] of the updated objects are cleaned.
  • Reported: DDS 1.0b1 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 49] Behavior_of_register_type

  • Key: DDS-142
  • Legacy Issue Number: 6849
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-161 Behavior_of_register_type

    The specification does not say what happens if the application locally
    tries to define the same "type_name" via register_type

    The case where a different DataType is being "registered" with a name
    that was already used should clearly fail

    The case where the same DataType is registered again with the same
    name could either fail or be idempotent.

    **PROPOSAL**

    State in 2.1.2.3.6 that it is a pre-condition that the same name has
    not already been used to register a different type. In case this is
    attempted the register_type() operation shall return
    PRECONDITION_ERROR

    State in 2.1.2.3.6 the documentation that it is OK to re-register the
    same DataType again with the same type_name. In this case the
    operation is idempotent and returns OK.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename DataType interface to TypeSupport

  • Key: DDS-141
  • Legacy Issue Number: 6848
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    159 Rename_the_interface_DataType

    The name DataType used in the PSM and IDL to refer to the interface
    with the "register_type"operation from which the FooDataType derives
    for each user-data type 'Foo' is causing confusion.

    People think that the FooDataType actually represents the type of the
    objects being propagated. In reality the type is 'Foo' and FooDataType
    just provides the support to intgrate 'Foo' with the middleware

    **PROPOSAL**

    Rename DataType to TypeSupport. FooDataType to FooTypeSupport
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 46] Use of RETCODE_NOT_IMPLEMENTED

  • Key: DDS-140
  • Legacy Issue Number: 6846
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-152 General_use_of_RETCODE_NOT_IMPLEMENTED

    Many operations that can return may need the additional ReturnCode_t
    NOT_IMPLEMENTED don't explicitly say so.

    **PROPOSAL**

    In section 2.1.1.1 add ReturnCode_t NOT_IMPLEMENTED to the list of
    codes any functions may return, with the provision that it only
    applies to functions that are pert of some optional compliant point.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 45] Is OMG IDL PSM more correct than CORBA PSM?

  • Key: DDS-139
  • Legacy Issue Number: 6845
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-138 CORBA_PSM_OR_OMG_IDL_PSM

    Document refers to the PSM as a "CORBA" PSM. Wouldn't it be more
    appropriate to call it the OMG IDL PSM

    **PROPOSAL**

    Change to references to OMG IDL
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 44] Errors in figures

  • Key: DDS-138
  • Legacy Issue Number: 6844
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-146 Bad_arrow_direction_in_figure_19

    Section 2.1.4.4 Figure 2-20

    The arrows between the BLOCKED and UNBLOCKED states are backwards

    **PROPOSAL**

    Reverse directions in Figure 2-20
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-139 Bad_reference_to filter_expression

  • Key: DDS-137
  • Legacy Issue Number: 6843
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.3.4. Says It says "filter_expression" should be
    "subscription_expression" in the sentence "The expression_parameters
    attribute is a sequence of strings that give values to the
    'parameters' (i.e. "%n" tokens) in the subscription_expression. The
    number of supplied parameters must fit with the requested values in
    the filter_expression (i.e. the number of %n tokens)."

    **PROPOSAL**

    Replace "filter_expression" with subscription_expression in Section
    2.1.2.3.4
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 56] Missing fields in builtin topics

  • Key: DDS-151
  • Legacy Issue Number: 6862
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-??? Missing_fields_in_builtin_topics

    It appears that definition of built-in topics in section 2.1.5 is
    missing some fields

    Related to Ref-68

    **PROPOSAL**

    Add the missing fields

    Define a concrete type for the BuiltinTopicKey_t. Make it long[3]
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 55] Rename DataType interface to TypeSupport

  • Key: DDS-150
  • Legacy Issue Number: 6861
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-159 Rename_the_interface_DataType

    The name DataType used in the PSM and IDL to refer to the interface
    with the "register_type"operation from which the FooDataType derives
    for each user-data type 'Foo' is causing confusion.

    People think that the FooDataType actually represents the type of the
    objects being propagated. In reality the type is 'Foo' and FooDataType
    just provides the support to intgrate 'Foo' with the middleware

    **PROPOSAL**

    Rename DataType to TypeSupport. FooDataType to FooTypeSupport
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    See issue 6848 for disposition – duplicate
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectHome index and name

  • Key: DDS-155
  • Legacy Issue Number: 7022
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    For footprint reasons an ObjectHome is designated by its index in the Cache. For convenience, the index should be an attribute of the ObjectHome
    Proposal [THALES]
    add the index readonly attribute
    return the allocated index when the home is registered
    add an operation to retrieve the home based on the index and homogeneise names of find operations
    Concrete changes:
    IDL
    interface ObjectHome {
    ...
    readonly attribute unsigned long registration_index;
    ...
    interface Cache {
    ...
    unsigned long register_home (
    in ObjectHome a_home)
    raises (
    BadHomeDefinition);
    ObjectHome find_home_by_name (
    in ClassName class_name)
    raises (
    BadParameter);
    ObjectHome find_home_by_index (
    in unsigned long index)
    raises (
    BadParameter);
    ...
    In section 3.1.6.3.3 Cache
    In the table
    Change the return type for register_home operation from "void" to "integer"
    Change the name of "find_home" to "find_home_by_name"
    add the following entry:
    find_home_by_index ObjectHome
    integer registration_index
    In the following text, starting with "It offers methods"
    first bullet: add at the end "this method returns the index under which the ObjectHome is registered by the Cache;"
    second bullet:change to "to retrieve an already registered ObjectHome, based on its name (find_home_by_name) or based on its index of registration (find_home_by_index)
    in section 3.1.6.2.3.5 ObjectHome
    in the table
    at the end of the attribute list, add the following entry
    registration_index integer
    in the following text, in the list starting by "The public attributes gives"
    add a last bullet "the index under which the ObjectHome has been registered by the Cache (cf. Cache::register_home)
    Correct the UML diagram accordingly
  • Reported: DDS 1.0b1 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1032: User-provided oid

  • Key: DDS-154
  • Legacy Issue Number: 6867
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    There is a need that the application can provide the oid of an object at creation time
    That characteristic should be provided on a class basis.
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 43] Bad references

  • Key: DDS-136
  • Legacy Issue Number: 6842
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    ***Ref-137 Bad_reference_to_Condition

    Section 2.1.2.1.7.1 says "StatusCondition" when it should say
    "Condition"

    **PROPOSAL** Replace StatusCondition with Condition in 2.1.2.1.7.1
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 42] Clarify how counts in the status accumulate

  • Key: DDS-135
  • Legacy Issue Number: 6841
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-117 Deadlines_accumulate

    Some people have been confused reading the specification with regards
    to the "total" counts and whether they accumulate.

    For example, whether the "deadline count" accumulates missed
    deadlines. That is, each deadline-time period that passes without an
    instance being written increments the deadline count even if the
    application does not have time to read the status

    **PROPOSAL**

    State this more explicitly on section 2.1.4.1
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 41] Inconsistent use of instance in datawriter api

  • Key: DDS-134
  • Legacy Issue Number: 6840
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-116 Inconsistent_use_of_instance_in_datawriter_api

    Currently Section 2.1.2.5.1 mentions the function dispose_instance
    which does not exist.

    A broader issue is that we have functions called
    register_instance/unregister_instance, but other functions that also
    apply to an instance (dispose, write, dispose_w_timestamp,
    write_w_timestamp, etc.) do not have "instance" in their name... This
    can lead to some confusion

    **PROPOSAL**

    Rename dispose_instance to dispose

    Fix the sequence chart in figure 2.1.6.1

    Leave the register_instance alone
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming of the private members

  • Key: DDS-158
  • Legacy Issue Number: 7025
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    All private members should be named consistently starting by m_
    Concerns m_ref and m_refs in Relation
    Proposal [THALES]
    change the names
    Concrete changes
    IDL
    valuetype RefRelation {
    private ObjectReference m_ref;
    [instead ref]
    valuetype ListRelation : ListBase {
    private ObjectReferenceSeq m_refs;
    [instead refs]
    valuetype IntMapRelation : StrMapBase {
    ...
    private ItemSeq m_refs;
    [instead refs]
    valuetype IntMapRelation : StrMapBase {
    ...
    private ItemSeq m_refs;
    [instead refs]
  • Reported: DDS 1.0b1 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

New structure for DLRLOid

  • Key: DDS-157
  • Legacy Issue Number: 7024
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    Just a long seems too small to express a DLRLOid
    proposal [THALES]
    Change to a structure with 2 longs, one meant to identify the creator of the Oid and one local to this creator.
    Concrete changes
    IDL
    struct DLRLOid

    { unsigned long creator_id; unsigned long local_id; }

    ;
    [instead typedef long DLRLOid]
  • Reported: DDS 1.0b1 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectRoot::is_modified (clarification)

  • Key: DDS-156
  • Legacy Issue Number: 7023
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    return of is_modified() on a newly created object is unspecified
    Proposal [THALES]
    should return false
    concerns the text
    Concrete change
    in section 3.1.6.3.11 ObjectRoot
    in the text after the table, starting with "it offers methods to:"
    last bullet, add the following sentence at the end "in case the object is newly created, this operation returns false."
  • Reported: DDS 1.0b1 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 57] Clarify creation of waitset and conditions

  • Key: DDS-153
  • Legacy Issue Number: 6864
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-72 Creation_of_waitset_and_guardcondition

    The DDS spec already says they are not created from a factory because
    they are intended to be base classes that will be extended by
    application-defined classes. This makes them similar to the Listener
    interfaces.

    However it would be desirable to be more explicit regarding this

    **PROPOSAL**

    State in the PSM section that WaitSet GuardCondition are to be
    implemented as classes in the native language that can be created
    using the "new" operator natural in the PSM. Furthermore, they should
    have at least a constructor that takes no arguments so that
    applications can be portable across implementations of the DDS spec.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-224 Built_in_topics_not_in_PSM

  • Key: DDS-152
  • Legacy Issue Number: 6863
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The built-in Topics are defined in the PIM but not in the PSM.

    **PROPOSAL**

    Add the definition to the IDL PSM in section 2.2.3

    include structures containing the fields in the built-in topics
    described in the table in section 2.1.5
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    See issue 6862 for disposition – duplicate
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation DataWriter::register

  • Key: DDS11-23
  • Legacy Issue Number: 8358
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The method DataWriter::register conflicts with the C++ 'register' keyword.
    Resolution:
    Replace register and unregister by register_instance and unregister_instance
    Replace register_w_timestamp and unregister_w_timestamp by register_instance_w_timestamp and unregister_instance_w_timestamp
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Spelling inconsistencies between the PIM and IDL PSM

  • Key: DDS11-22
  • Legacy Issue Number: 8355
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In a number of instances, there are minor inconsistencies in spelling and naming between the specification's platform-independent model (PIM) and the included IDL platform-specific model (PSM).
    Resolution:
    In each case, the most descriptive term of the two options was chosen and the other was conformed to it.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#4) Typo in section 2.1.2.4.2.10 (write) and section 2.1.2.4.12 (dispose)

  • Key: DDS11-24
  • Legacy Issue Number: 8359
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    Summary:
    In par. 2.1.2.4.2.10 (write) and par. 2.1.2.4.12 (dispose) the specification does not specify an error code in case the specified handle is valid but does not correspond to the given instance (the key value must match), and neither for the case that the specified handle is invalid.
    Resolution:
    Specify that in general, the result is unspecified, but that depending on vendor-specific implementations, the resulting error-code is 'PRECONDITION_NOT_MET' if a wrong instance (i.e. with a wrong key-value) is provided and that the resulting error-code is 'BAD_PARAMETER' if a bad handle is provided
    Revised Text:
    Add the following text to the end of 2.1.2.4.2.10 (write)
    In case the provided handle is valid but does not correspond to the given instance, the resulting error-code of the operation will be 'PRECONDITION_NOT_MET'. In case the handle is invalid, the behavior is in general unspecified, but if detectable by a DDS-implementation, the returned error-code will be 'BAD_PARAMETER'.
    Replace in 2.1.2.4.2.12 (dispose), the text "Possible error codes returned in addition to the standard ones: PRECONDITION_NOT_MET" by the following text:
    In case the provided handle is valid but does not correspond to the given instance, the resulting error-code of the operation will be 'PRECONDITION_NOT_MET'. In case the handle is invalid, the behavior is in general unspecified, but if detectable by a DDS-implementation, the returned error-code will be 'BAD_PARAMETER'.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#29) Missing operations to Topic class

  • Key: DDS11-34
  • Legacy Issue Number: 8369
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In the DCPS PSM the Topic class does not specify the methods set_qos, get_qos, set_listener and get_listener.
    Resolution:
    The methods set_qos, get_qos, set_listener and get_listener shall be added to the IDL description of the Topic class.
    Revised Text:
    In the IDL in 2.2.3:

    interface Topic : Entity, TopicDescription

    { … ReturnCode_t set_qos( in TopicQos qos); void get_qos( inout TopicQos qos); ReturnCode_t set_listener( in TopicListener a_listener, in StatusMask mask); TopicListener get_listener(); ReturnCode_t get_inconsistent_topic_status( inout: InconsistentTopicStatus); … }

    ;
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#28) Typographical and grammatical errors

  • Key: DDS11-33
  • Legacy Issue Number: 8368
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The specification contains a number of misspellings and other minor typographical and grammatical errors.
    Resolution:
    The typographical and grammatical errors shall be corrected.
    Revised Text:
    Location Original Incorrect Text Corrected Text
    2.1.2.1, fig. 2-5 "Status" (the class name) "Status"
    2.1.2.2, fig. 2-6 "domainId" "domain_id"
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing operations on DomainParticipantFactory

  • Key: DDS11-31
  • Legacy Issue Number: 8366
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The class DomainParticipantFactory in figure 2-6 section 2.1.2.2. (Domain Module) misses the operations set_default_participant_qos and get_default_participant_qos..
    Resolution:
    Add the missing operations.
    Revised Text:
    In the class diagram Fig. 2-6 of section 2.1.2.2 (Domain Module), add the operations 'set_default_participant_qos' and 'get_default_participant_qos'.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Spell fully the names for the DataReader operations

  • Key: DDS11-30
  • Legacy Issue Number: 8365
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In some class diagrams, generic operations are indicated using 'xxx' in their names instead of fully specifying all the real operations and also some operations are missing.
    Resolution:

    • add the missing operations for the dataReader
    • explicitly mention all operations for the dataReader
      Revised Text:
      In the class diagram Fig. 2-8 on page 2-39:
    • add missing operations "read_w_condition", "take_w_condition" and "return_loan".
    • rename "read_xxx_w_conditon" into "read_next_w_condition".
    • rename "take_xxx_w_condition" into "take_next_w_condition"
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Default value for READER_DATA_LIFECYCLE

  • Key: DDS11-26
  • Legacy Issue Number: 8361
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    Section 2.1.3. (Supported QoS) the default value of the duration attribute of the READER_DATA_LIFECYCLE QoS is specified as "unlimited"..
    Resolution:
    Replace "unlimited" by "infinite", which in general is used in relation with durations.
    Revised Text:
    In the QoS-table of paragraph 2.1.3, replace the text "By default, unlimited" as belongs to the READER_DATA_LIFECYCLE QoS by the text "By default, infinite".
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in section 2.1.2.5.2.5

  • Key: DDS11-25
  • Legacy Issue Number: 8360
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In section 2.1.2.5.2.5. (create_datareader) the special value DATAWRITER_QOS_USE_TOPIC_QOS is mistakenly being used instead of DATAREADER_QOS_USE_TOPIC_QOS.
    Resolution:
    Replace the wrong text with the correct version.
    Revised Text:
    In 2.1.2.5.2.5 (create-datareader) replace the text "The special value DATAWRITER_QOS_USE_TOPIC_QOS" with "The special value "DATAREADER_QOS_USE_TOPIC_QOS
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

No mention of DESTINATION_ORDER on DataWriterQos

  • Key: DDS11-28
  • Legacy Issue Number: 8363
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In the table in section 2.1.3. (Supported QoS) the DESTINATION_ORDER QoS does not mention the 'datawriter' as concerned entity.
    Resolution:
    Add DataWriter to the 'concerns' column.
    Revised Text:
    In the table in section 2.1.3 (Supported QoS), add to the "DESTINATION_ORDER" column and the "Concerns" row, the word 'DataWriter'.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect reference to USER_DATA on TopicQos

  • Key: DDS11-27
  • Legacy Issue Number: 8362
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The table in section 2.1.3. (Supported QoS) wrongful specifies that USER_DATA concerns Topic.
    Resolution:
    'Topic' should be removed from the 'concerns' column.
    Revised Text:
    In the table in section 2.1.3 (Supported QoS), remove from the "USER-DATA" row, and from the "Concerns" column, the word 'Topic'.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Formal parameter name change in operations of ContentFilteredTopic

  • Key: DDS11-35
  • Legacy Issue Number: 8370
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    Some of the formal parameter names of ContentFilteredTopic methods are vague.
    Resolution:
    The names shall be changed into more distinct names.
    Revised Text:

    Location Original incorrect name Corrected name
    section 2.1.2.2.1, create_contentfilteredtopic expression_parameters filter_parameters
    section 2.1.2.2.1.7 topic_name related_topic
    section 2.1.2.2.1.7 expression_parameters filter_parameters
    section 2.1.2.3.3, get_expression_parameters expression_parameters filter_parameters
    section 2.1.2.3.3, set_expression_parameters expression_parameters filter_parameters
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Formal parameter name improvement in IDL

  • Key: DDS11-29
  • Legacy Issue Number: 8364
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In the IDL specification of section 2.2.3, the first parameter of the 'register_type' method is called 'domain' instead of 'participant' (as it is called elsewhere, like in the table of secion 2.1.2.3.6.
    Resolution:
    Change the parameter name to 'participant' in the typesupport::register_type IDL.
    Revised Text:
    In Chapter 2.2.3 (IDL specification), change the register_type parameter called 'domain' into 'participant'.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

T#18,24,) Missing operations and attributes

  • Key: DDS11-32
  • Legacy Issue Number: 8367
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In some of the figures some operations are missing.
    Resolution:
    The missing operations shall be added.
    Revised Text:
    Location Missing operation
    2.1.2.5, fig. 2-10 delete_contained_entities()
    2.1.2.2, fig. 2-6 set_default_publisher_qos()get_default_publisher_qos()set_default_subscriber_qos()get_default_subscriber_qos()set_default_topic_qos()get_default_topic_qos()
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Several instead one listener

  • Key: DDS-163
  • Legacy Issue Number: 7060
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    Currently there is only one ObjectHome and one Cache Listeners. This has been considered by users as fairly limited and as several selections are allowed, unjustified
    Proposal [THALES]
    Allow several listeners.
    Precise the triggering order
    Concrete changes
    IDL
    local interface Selection {
    ...
    SelectionListener set_listener (
    in SelectionListener listener);
    [instead attach_listener in the commented out section]
    ...
    local interface Cache {
    ...
    readonly attribute CacheListenerSeq listeners;
    [instead readonly attribute CacheListener listener]
    ...
    void detach_listener (
    in CacheListener listener);
    [instead no parameter]
    ...
    local interface ObjectHome {
    ...
    readonly attribute ObjectListenerSeq listeners;
    [instead readonly attribute ObjectListener listener]
    ...
    void detach_listener (
    in ObjectListener listener);
    [instead no parameter]
    ...
    in section 3.1.6.3.3 Cache
    in the table
    list of attributes replace the entry for listener by the following
    listeners CacheListener []
    list of operations, replace the entry for detach_listener by the following
    detach_listener void
    listener CacheListener
    in section 3.1.6.3.5 ObjectHome
    in the table
    list of attributes replace the entry for listener by the following
    listeners ObjectListener []
    list of operations, correct the entry for attach_listener by the following (ObjectListener instead of Listener)
    attach_listener void
    listener ObjectListener
    list of operations, replace the entry for detach_listener by the following
    detach_listener void
    listener ObjectListener
    in section 3.1.6.3.7 Selection
    in the table, change the entries for attach_listener and detach_listener to only one operation set_listener, as follows:
    set_listener SelectionListener
    listener SelectionListener
    in the following text, in the list starting with "it offers the methods to:"
    change the first bullet to:
    "set the listener (set_listener) that will be triggered when the composition of the selection changes as well as if one of its members is modified; set_listener returns the previously set listener if any; set_listener, called with a NULL parameter discards the current listener."
    in section 3.1.6.4.1 General Scenario
    In the list starting with "This set of updates is managed as follows"
    change the first bullet to:
    "First, all the CacheListener::start_updates operations are triggered; the order in which these listeners are triggered is not specified"
    change the last bullet to:
    "Finally all the CacheListener::end_updates operations are triggered and the modification state of the object are cleaned; the order in which these listeners are triggered is not specified."
    in section 3.1.6.4.2 Object Creation
    In the list
    change the first bullet to:
    "First, the ObjectListener suitable to that object are searched and their on_object_created operations triggered; the search follows the inheritance structure starting from the more specific ObjectHome (e.g., FooHome, for an object typed Foo) to ObjectRoot. The search is stopped when all on_object_created operations at one level return true; inside one level the triggering order is not specified."
    in section 3.1.6.4.3 ObjectModification
    In the list
    change the last bullet to:
    "Then, the ObjectListener suitable to that object are searched and their on_object_modified operations triggered; the search follows the inheritance structure starting from the more specific ObjectHome (e.g., FooHome, for an object typed Foo) to ObjectRoot. The search is stopped when all on_object_modified operations at one level return true; inside one level the triggering order is not specified."
    in section 3.1.6.4.4 ObjectDeletion
    In the list
    change the last bullet to:
    "the ObjectListener suitable to that object are searched and their on_object_deleted operations triggered; the search follows the inheritance structure starting from the more specific ObjectHome (e.g., FooHome, for an object typed Foo) to ObjectRoot. The search is stopped when all on_object_deleted operations at one level return true; inside one level the triggering order is not specified."
  • Reported: DDS 1.0b1 — Thu, 26 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

clone + deref

  • Key: DDS-162
  • Legacy Issue Number: 7059
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    ref-1041: clone + deref
    Issue [THALES]
    For performance, it seems good to offer a combined operation clone + deref that returns the instantiated cell instead the ObjectReference
    Proposal [THALES]
    Add such a method on ObjectRoot and also in the implied IDL
    Concrete changes:
    IDL
    ObjectRoot {
    ...
    ObjectRoot clone_object(
    in CacheAccess access,
    in ObjectScope scope,
    in RelatedObjectDepth depth)
    raises (
    ReadOnlyMode,
    AlreadyClonedInWriteMode);
    Foo {
    ...
    Foo clone_foo(
    in CacheAccess access,
    in ObjectScope scope,
    in ReletedObjectDepth depth)
    raises (
    ReadOnlyMode,
    AlreadyClonedInWriteMode);
    in section 3.1.6.3.11 ObjectRoot
    in the table, add the clone_object operation, by adding the following:
    clone_object ObjectRoot
    access CacheAccess
    scope ObjectScope
    depth integer
    in the following text, in the list starting with "it offers methods to":
    insert a second bullet, with the following contents:
    "clone and instantiate the object in the same operation (clone_object), this operations takes the same parameters as the previous one, but returns an ObjectRoot instead of an ObjectReference; it corresponds exactly to the sequence of clone followed by CacheAccess::deref on the reference returned by the clone operation;"
    in section 3.1.6.5.1 Read Mode
    item #2, change "(ObjectRoot::clone)" to "(ObjectRoot::clone or clone_object)"
    in section 3.1.6.5.2 Write Mode
    item #2, change "(ObjectRoot::clone)" to "(ObjectRoot::clone or clone_object)"
  • Reported: DDS 1.0b1 — Thu, 26 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

New definition for ObjectListener

  • Key: DDS-165
  • Legacy Issue Number: 7062
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    ref-1049: New definition for ObjectListener
    Issue [THALES]
    When a contained object is modified, it can be difficult to get the information in the ObjectListener
    In all cases, getting the old value seems useful in certain cases,
    As first parameter, the ObjectReference is more appropriate tah the ObjectRoot, for the object may not be instanciated; in addition, this simplifies because it is no more mandatory to generate the implied FooListener.
    Whether the notification concerns the object or the object + its contained object should be set on a Listener basis, rather than on the ObjectHome basis.
  • Reported: DDS 1.0b1 — Thu, 26 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

delete clone

  • Key: DDS-164
  • Legacy Issue Number: 7061
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    ref-1046: delete_clone
    Issue [THALES]
    Useful to remove a clone from a CacheAccess in addition to the deletion of all the clones.
    Proposal [THALES]
    add an operation on CacheAccess to delete a clone
    should concern the object itself + all its components, but not the related objects (regardless to what was the clone request)
    Concrete changes
    IDL
    local interface CacheAccess {
    ...
    void delete_clone(
    in ObjectReference ref);
    ...
    in section 3.1.6.3.2 CacheAccess
    in the table, after the purge operation, insert the delete_clone operation, by insetring the following entries:
    delete_clone void
    ref ObjectReference
    in the following text,
    introduce a bullet, before the last one, with the following content:
    "alternatively, the copy of one object and all its attached contained objects can be detached from the CacheAccess (delete_clone);"
  • Reported: DDS 1.0b1 — Thu, 26 Feb 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-37 Entity_ specialization_set_get_listener_in_idl

  • Key: DDS-67
  • Legacy Issue Number: 6773
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section 2.2.3 (IDL) the entities DomainParticipant, Topic,
    Publisher, DataWriter, Subscriber, and DataReader are missing the
    get_listener/set_listener operations.

    Those operation are all present in the PIM.

    **PROPOSAL**

    Add said operations to the IDL to match the PIM
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-34 Incorrect_guard_condition_enabled_statuses

  • Key: DDS-66
  • Legacy Issue Number: 6772
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.1.8. The enabled_statuses attribute for a GuardCondition
    is incorrect since a GuardCondition does not have any relationship
    with status conditions.

    **PROPOSAL**

    Remove the attribute from section 2.1.2.1.8
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-48 FooDataWriter_unregister_instance

  • Key: DDS-70
  • Legacy Issue Number: 6776
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.4.2. FooDataWriter class table. The unregister_instance
    method is specified to return InstanceHandle_t.

    The return type should be ReturnCode_t conform the IDL PSM.

    **PROPOSAL**

    Correct section 2.1.2.4.2 to match the IDL file.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-46 ContentFilteredTopic_related_topic

  • Key: DDS-69
  • Legacy Issue Number: 6775
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.3.3 in the ContentFilteredTopic class table, there is
    the attribute related_topic. This attribute is missing in the IDL PSM.

    **PROPOSAL**

    Correct the IDL to match the PIM.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-28 IDL_entity_get_statuscondition

  • Key: DDS-65
  • Legacy Issue Number: 6771
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.1.1. Method get_statuscondition. According to the IDL
    file, this method is replaced by two other methods named
    create_statuscondition and delete_statuscondition. Which of the two is
    right?

    The IDL is incorrect. Given that there is a single statuscondition
    associated with an Entity having only a get_statuscondition operation
    and no delete_statuscondition.

    **PROPOSAL**

    Correct the IDL. Replace the create_statuscondition and
    delete_statuscondition in the IDL with get_statuscondition as
    desxribed in the PIM.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-42 DomainParticipantListener_on_requested

  • Key: DDS-68
  • Legacy Issue Number: 6774
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.2.3. DomainParticipantListener Interface table: The
    operation on_requested_deadline_missed_qos is mentioned instead of
    on_requested_deadline_missed.

    **PROPOSAL**

    Correct section 2.1.2.2.3
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typographical and grammatical errors

  • Key: DDS11-21
  • Legacy Issue Number: 8354
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification contains a number of misspellings and other minor typographical and grammatical errors.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS 04-04-12 para. 2.1.1.1 Format and conventions

  • Key: DDS11-20
  • Legacy Issue Number: 7975
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    The table format used for documenting classes contains an
    "attributes" and an "operations" section.

    However, in order for applications to be portable across
    implementations of the DDS spec, it would be desirable to add
    a "constructors" section that explicitly states those constructors
    that take one or more arguments (i.e. non-default constructors.)
  • Reported: DDS 1.0 — Tue, 14 Dec 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

'synchrobnous' and 'asynchronous' switched

  • Key: DDS11-14
  • Legacy Issue Number: 12529
  • 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 'synchrobnous' and 'asynchronous' was switched as highlighted in red in the below paragraph in the spec.

    <para #4, page 11>
    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.1 — Wed, 14 May 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

section 2.1.2.5.2.16 "get_default_datareader_qos"

  • Key: DDS11-13
  • Legacy Issue Number: 10088
  • Status: open  
  • Source: Vanderbilt University ( Joe Hoffert)
  • Summary:

    I just wanted to let someone know about a typographical error I saw in the DDS spec 05-12-04-1. In section 2.1.2.5.2.16 "get_default_datareader_qos" The second paragraph reads in part

    "The values retrieved get_default_datareader_qos will match the set of values specified
    on the last successful call to get_default_datareader_qos, ..."

    I believe that last function should be "set_default_datareader_qos" rather than "get_default_datareader_qos". This is consistent with other sections of the specification and makes sense. I just wanted to point this out. It looks like there used to be this same kind of error for set_default_datawriter_qos but was fixed in 05-12-04-1. I didn't see this listed in the DDS issues.
  • Reported: DDS 1.1 — Tue, 8 Aug 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

no specific mention of interoperability in DDS 04-04-12 standard proposal

  • Key: DDS11-16
  • Legacy Issue Number: 7964
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    I find no specific mention of interoperability in the DDS 04-04-12
    standard proposal.

    It should be clarified whether the standard is intended to address
    interoperability, and if so, under what exact conditions (e.g., is it
    safe to assume that if the DCPS IDL PSM is implemented by IIOP based
    CORBA ORBs then it will be possible to interoperate?)
  • Reported: DDS 1.0 — Thu, 2 Dec 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS: DCPS generated interface FooTypeSupport

  • Key: DDS11-17
  • Legacy Issue Number: 7965
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    Nature: Enhancement

    Summary:

    Document 04-04-12 para. 2.2.3 near end
    In the implied IDL interface FooTypeSupport for a user type Foo,
    there is an operation

    DDS::ReturnCode_t register_type(in DDS::DomainParticipant
    participant,
    in string type_name);

    IMHO the type_name argument is superfluous:
    The generated stub code can fill it in automatically ("Foo").
  • Reported: DDS 1.0 — Thu, 2 Dec 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.1.3.20 WRITER_DATA_LIFECYCLE, itemized list, first bullet

  • Key: DDS11-19
  • Legacy Issue Number: 7974
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:
    • The setting 'autodispose_unregistered_instances = FALSE' causes the
      DataWriter [...]

    Change FALSE to TRUE.

  • Reported: DDS 1.0 — Fri, 10 Dec 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS: DCPS - define the term "plain data structures"

  • Key: DDS11-18
  • Legacy Issue Number: 7966
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    OMG document 04-04-12 para. 2.1.1.2.2 Overall Conceptual Model
    pg. 2-7 states:

    At the DCPS level, data types represent information that is sent
    atomically. For performance reasons, only plain data structures
    are handled by this level.

    Please define the term "plain data structures".
  • Reported: DDS 1.0 — Thu, 2 Dec 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 38] Allow application to install a clock

  • Key: DDS-131
  • Legacy Issue Number: 6837
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-114 Behavior_of_instances_when_deleting_datawriter

    What happens when an application deletes a datawriter? Do all
    registered instances become unregistered? What about samples that may
    have been written but not propagated to remote readers?

    There are two possibilities:

    Approch1 behave as if the application had crashed with regards to the
    readers. The application should have been explicit about the contained
    entities (e.g. unregister/dispose) before deleting the writer.

    Approach2 handle it as any deletion of a container entity. It is a
    pre-condition error if it has any registered instances and the entity
    is not deleted. But also we provide helper operations on the
    DataWriter to unregister_all_instances() and dispose_all_instances().

    **PROPOSAL**

    Use Approach2. Its more explicit and less error-prone.

    Also say that the infrastructure is not required to immediately
    release the resources before returning from the delete but can keep
    them around for a while until is properly has a chance to clean up its
    state, inform remote nodes, etc.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 37] SAMPLE_LOST_STATUS on DataReader

  • Key: DDS-130
  • Legacy Issue Number: 6836
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-101 Move_sample_lost_status_to_datareader

    Section 2.1.4.2 shows in a table that SAMPLE_LOST_STATUS is on the
    Subscriber. It would make more sense to have it on the Datareader. It
    is not as useful to the application to know that samples have been
    lost for DataReaders belonging to the Subscriber as it would be to
    know which DataReaders they affected.

    When we first specified this it was thought that it would be hard to
    implement as a status on the DataReader because, given that the
    samples are lost, it would not be clear which DataReader they
    affect. As it turns out the anticipated implementation difficulties
    are not there.

    **PROPOSAL**

    Remove the SAMPLE_LOST_STATUS from the status of the Subscriber and
    add it to that of the DataReader in the table in 2.1.4.2

    Also modify the PIM in section 2.1.2.5.2 and the PSM in section 2.2.3
    moving the get_sample_lost_status operation from Subscriber to
    DataReader
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-106 Desc_of_Inconsistent_topic_status::total_count_change

  • Key: DDS-121
  • Legacy Issue Number: 6827
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.4.1. The Table that describes the statuses and the meaning
    of the attributes has an incorrect description of the
    "total_count_change"

    Currently it talks about topic names, not counts

    **PROPOSAL**

    In section 2.1.4.1 replace the text "The type of the last topic
    discovered..."

    With: "The incremental number of inconsistent topics discovered since
    the last time the listener was called or the status was read"
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-156 Clarify_TIME_BASED_FILTER

  • Key: DDS-120
  • Legacy Issue Number: 6826
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not state clearly whether the TIME_BASED_FILTER
    applies on a per-instance basis or for the whole topic.

    It should probably be per instance but it should be said explicitly.

    **PROPOSAL**

    Add the clarification to section 2.1.3.8. State that the filter
    applier per instence, that is, the reader is requested not to receive
    more than one sample per minimum_separation period for each instance
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-104 Coupling_bwn_TIME_BASED_FILTER_and_RELIABILITY

  • Key: DDS-119
  • Legacy Issue Number: 6825
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.3 on the QoS table. The description of the
    TIME_BASED_FILTER QoS says"

    "The setting of this QoS is incompatible with RELIABILITY policy set
    to ALL"

    First there is no such setting for reliability policy. It intended to
    say it is incompatible with RELIABILITY 'RELIABLE' and HISTORY
    'KEEP_ALL'.

    However it is unclear why it is necessary introduce such
    incompatibility. It would be better to interpret the meaning of
    RELIABLE and KEEP_ALL to mean that the application desires that all
    samples that pass whichever filters have been specified are propagated
    reliably and kept by the middleware until they can be delivered to the
    DataReader. In other words, the RELIABILITY and HISTORY policies apply
    after the "filter-type" policies apply. The filters determine what is
    of interest, the reliability whether samples lost by the transport
    should be retried and the HISTORY whether to keep old values that have
    not been delivered to the application once a new value
    exist. Interpreted this way all combination of the above policies are
    sensical. This approach also extends to the ContentFilteredTopic

    **PROPOSAL**

    Remove that comment from the TIME_BASED_FILTER QoS

    Add a third paragraph to section 2.1.3.8 that explains that it is
    indeed possible to specify RELIABILITY RELIABLE, and a HISTORY
    KEEP_ALL and still set a TIME_BASED_FILTER. The paragraph would say:

    The setting of a TIME_BASED_FILTER, that is, the selection of a
    minimum_separation with a value greater than zero is compatible with
    all settings of the HISTORY and RELIABILITY QoS. The TIME_BASED_FILTER
    specifies the samples that are of interest to the DataReader. The
    HISTORY and RELIABILITY affect the behavior of the middleware with
    respect to the samples that have been determined to be of interest to
    the DataReader, that is, they apply after the TIME_BASED_FILTER has
    been applied.

    Specify that that if the reliability is RELIABLE then in steady-state
    it should behave as-if the last sample passes the
    TIME_BASED_FILTER. In other words, in steady state the last sample
    should eventually become available to the receiver.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 36] QoS clarifications

  • Key: DDS-116
  • Legacy Issue Number: 6822
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-208 Latency_budget_description

    Section 2.1.3 has a wrong description of LATENCY BUDGET. It says that
    it specifies the acceptable delay from production time until 'it is
    received by subscribing application' which might suggest that it
    includes the time an application might wait until actually reading the
    data.

    Rather it should say that it specifies the acceptable delay from
    production time until the data is inserted in application-cache and
    the application is notified of the fact.

    **PROPOSAL**

    Update the description. In the table to say that "it specifies the
    acceptable delay from production time until the data is inserted in
    application-cache and the application is notified of the fact"
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency on what operations may return NOT_ENABLED

  • Key: DDS-115
  • Legacy Issue Number: 6821
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-204 Entity_table_get_statuscondition_return_not_enabled

    Section 2.1.2.1.1, 1st paragraph under the Entity table: In the list
    of methods which cannot return a "NOT_ENABLED", the
    "get_statuscondition" method is not mentioned.

    This is inconsistent with the text in 2.1.2.1.1.7 where it says that
    get_statuscondition may be called even if the entity is not enabled.

    **PROPOSAL**

    Remove the sentence 2.1.2.1.1, 1st paragraph "All operation except for
    ... return the value NOT_ENABLED" as this is already described in
    2.1.2.1.1.7
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 34] Initial data when DataWriter appears

  • Key: DDS-114
  • Legacy Issue Number: 6820
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-90 Initial_data_from_transient_or_persistent_data

    The specification mentions that if the DURABILITY is set to TRANSIENT
    or PERSISTENT a newly appearing DataReader would be able to get some
    amount of history data.

    However the precise semantics of this are not clear. For example is
    the application allows to receive information as soon as the Reader is
    active (perhaps from active writers) even before the historical data
    has been received?

    It would be desirable to offer the application some control about how
    to initialize the reader when it first joins the system.

    **PROPOSAL**

    Introduce an operation DataReader:: get_historical_data(in Duration_t
    max_time_to_wait);

    This operation will block for a maximum of max_time_to_wait until the
    system gets the initial data.

    Introduce the ReturnCode_t "TIMEOUT" to section 2.1.1.1.

    State that the get_historical_data operation will return OK if all the
    initial data has been received. Otherwise it will return TIMEOUT if
    the system cannot ensure that all historical data has been received.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 40] Expression syntax is missing enumeration

  • Key: DDS-133
  • Legacy Issue Number: 6839
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-136 Missing_ENUMERATION_from_expression_syntax

    ENUMERATION missing from terminals of expression for
    Query/Filters/Multitopic on the appendix

    **PROPOSAL**

    Add the following to the grammars in Appendix B and C.

    Under the rule for Parameter ::=

    Add the ENUMERATION as a terminal analogous to the INTEGER value.

    In the table describing the terminals, explain that the ENUMERATION is
    named using the identifier for the enumerated member. Either using the
    plain label or if there is conflict using the
    EnumerationTypeName::EnumerationLabel
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 39] Combine module names

  • Key: DDS-132
  • Legacy Issue Number: 6838
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-131 Module_name_dcps

    The specification contains two top-level module names 'DCPS' and
    'DLRL' it is desirable to not have so many modules. It will complicate
    the C mapping and and also weaken the "brand"

    We have verified that there are no naming clashes between the two
    modules so they can be combined

    **PROPOSAL**

    In section 2.2.3 replace the module name from 'DCPS' to 'DDS'

    In section 3.2.1.2 replace the module name from 'DLRL to 'DDS'
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-162 Separate_transient_into_two_kinds

  • Key: DDS-129
  • Legacy Issue Number: 6835
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The description of the DURABILITY Qos in section 2.1.3 is ambiguous
    with regards to the TRANSIENT kind. It would appear that there are in
    fact two kinds:

    The first interpretation "TRANSIENT_LOCAL" would have the durability
    tied to the liveliness of the DataWriter..

    The second interpretation "TRANSIENT_GLOBAL would tie the durability
    to the fact that some "durability servide" in the system is still
    executing.

    It should be explained which of these interpretations is meant.

    **PROPOSAL**

    Modify the QoS table in 2.1.3 to separate the TRANSIENT durability
    into two kinds: TRANSIENT_LOCAL and TRANSIENT.

    TRANSIENT_LOCAL ties the durability to the liveliness of the
    writer. This is the mandatory level described in Appendix A.

    TRANSIENT allows the durability to survive the liveliness of the
    DataWriter. Explain this kinds in the table and in section 2.1.3.2
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-142 Confusing_description_of_manual_by_participant

  • Key: DDS-128
  • Legacy Issue Number: 6834
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 2.1.3, QoS table

    Clarify the LIVELINESS "MANUAL_BY_PARTICIPANT". What it says is
    correct. But its getting some people confused.

    It says:

    "The Service will assume that as long as at least one Entity within
    the domain has asserted its liveliness the Entity is also alive."

    Some people are mistakenly understanding this as:

    "...at least one Entity within the domain has asserted its liveliness
    the domain is also alive."?

    So maybe its best to say:

    "The Service will assume that as long as at least one Entity within
    the domain has asserted its liveliness the other Entities in the
    domain are also alive."

    **PROPOSAL**

    Replace as stated above
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-109 Destination_order_should_be_request_offered

  • Key: DDS-123
  • Legacy Issue Number: 6829
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In order to support the BY_SOURCE_TIMESTAMP setting the DataWriter
    needs to take appropriate actions (e.g. embed timestamps). Therefore
    the DESTINATION_ORDER QoS should follow the same request/offered
    pattern other QoSs do.

    **PROPOSAL**

    Modify the QoS table in section 2.1.3 and add DataWriter as in the
    "Concerns" column for DESTINATION_ORDER. Also replace with "Yes" in
    the "RxO" (request/offered) column.

    Add a paragraph to section 2.1.3.11 stating the request/offered
    compatibility as follows:

    The value offered is considered compatible with the value requested if
    and only if the inequality "offered kind >= requested kind" evaluates
    to 'TRUE'. For the purposes of this inequality, the values of
    DESTINATION_ORDER kind are considered ordered such that
    BY_DESTINATION_TIMESTAMP < BY_SOURCE_TIMESTAMP.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-108 Ownership_interaction_with_deadline

  • Key: DDS-122
  • Legacy Issue Number: 6828
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In case where the OWNERSHIP QoS is EXCLUSIVE, the specification
    describes that ownership is lost if the DataWriter loses its
    liveliness. However it does not describe whether it loses the
    ownership if it misses its deadline with regards to writing the
    instance.

    If this case is left unspecified the most natural interpretations
    would be that the DataWriter does indeed maintain ownership even when
    it is missing its deadlines. This seems undesirable.

    We do not want a DataWriter that has promised to write samples within
    a pre-stated deadline and fails that contract to retain ownership of
    an instance and by so doing starve prevent other writers from writing
    the instance and therefore starve the reader from data. The
    underlying goal is to make the system robust to faults that affect a
    single entity.

    **PROPOSAL**

    Modify section 2.1.3.6.2 (EXCLUSIVE kind) to reflect this. This
    affects several paragraphs:

      • First paragraph

    Replace: The owner is determined by selecting the DataWriter with the
    highest value of the strength that is currently "alive" as defined by
    the LIVELINESS QoS policy.

    With: The owner is determined by selecting the DataWriter with the
    highest value of the strength that is both "alive" as defined by the
    LIVELINESS QoS policy and has not violated its DEADLINE contract with
    regards to the data-instance.

      • First paragraph

    After "Ownership can therefore change as a result of (a) ..."

    Add a forth case (d) a deadline with regards to the instance that is
    missed by the DataWriter that owns the instance.

      • Fifth paragraph

    Modify "It is also required that the owner remains the same until
    there is a change in strength, liveliness, or a new DataWriter with
    higher strength modifies the instance."

    To: "It is also required that the owner remains the same until there
    is a change in strength or liveliness, the owner misses a deadline on
    the instance, or a new DataWriter with higher strength modifies the
    instance."
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-144 Wrong_description_of_compatible_DURABILITY

  • Key: DDS-125
  • Legacy Issue Number: 6831
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 2.1.3, QoS table. Section on DURABILITY setting.

    Says compatible only if requested kind > offered kind. Should have
    said requested >= offered. Same in PRESENTATION

    **PROPOSAL**

    Replace "requested kind > offered kind" with "requested kind >=
    offered kind"
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-111 Default_values_for_qos

  • Key: DDS-124
  • Legacy Issue Number: 6830
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The QoS table in section 2.1.3 specifies default values for some of
    the QoS. Others however are unspecified.

    To be consistent we should provide some default value for all
    QoS. Meaning if the user never specified the QoS (assuming the
    Topic_qos_as_default_for_datareader_or_datawriter_qos issue is
    resolved) then we should specify what the behavior should be

    **PROPOSAL**

    Complete the table in section 2.1.3 with the following values:

    USER_DATA: empty sequence (zero-sized)

    DURABILITY: VOLATILE

    PRESENTATION: access_scope=INSTANCE, coherent_access=FALSE,
    ordered_access=FALSE

    DEADLINE: (already specified)

    LATENCY_BUDGET: says "zero" but that is not really meaningful so
    perhaps INFINITE?

    OWNERSHIP: (already specified)

    OWNERSHIP_STRENGTH: zero

    LIVELINESS: (already specified)

    TIME_BASED_FILTER: (already specified)

    PARTITION: empty sequence (zero length)

    RELIABILITY: (already specified)

    DESTINATION_ORDER: BY_RECEPTION_TIMESTAMP

    HISTORY: (already specified)

    RESOURCE_LIMITS: (already specified)
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-212 Qos_Coupling_TimeBasedFilter_deadline

  • Key: DDS-118
  • Legacy Issue Number: 6824
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section 2.1.3.4 it is unclear whether the service is expected to
    check compatibilities between DEADLINE and TIME_BASED_FILTER
    policies. For example, a DataWriter offering a DEADLINE period smaller
    than a DataReaders TIME_BASED_FILTER is bound to lead to problems with
    reliable transmission.

    Another example is a DataReader which has a DEADLINE period smaller
    than the TIME_BASED_FILTER period.

    **PROPOSAL**

    State that DataReader which has a DEADLINE period smaller than the
    TIME_BASED_FILTER period results on INCONSISTENT_POLICY.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-210 Clarification_of_responsibility_of_RxO_qos

  • Key: DDS-117
  • Legacy Issue Number: 6823
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section 2.1.3 the explanation of the table mentions: "The QosPolicy
    objects that need to be set in a compatible manner at the publisher
    end are indicated by the setting of the RxO property" This suggests an
    asymmetry between publishers and subscribers. It is not true that
    compatibility of policy objects is entirely the responsibility of the
    publisher, is it?

    **PROPOSAL**

    In said sentence replace "at the publisher end" with "between the
    publisher and subscriber ends".
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-144 User_data_on_topic

  • Key: DDS-127
  • Legacy Issue Number: 6833
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Some use-cases would benefit from having USER_DATA also on Topic.

    **PROPOSAL**

    Add TOPIC_DATA to the TopicQoS with the same definition as the
    USER_DATA. The initial value should be an empty sequence

    Add topic_data as a field in the DCPSTopic in the table describing the
    built-in topics in section 2.1.5, page 2-90.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-165 Make_USER_DATA_changeable

  • Key: DDS-126
  • Legacy Issue Number: 6832
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 2.1.3, QoS table states USER_DATA is immutable.

    Many of the use-cases of the USER_DATA require the application to be
    able to change the USER_DATA dynamically.

    **PROPOSAL**

    Make USER_DATA mutable in section 2.1.3.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#30) Ambiguous description of TOPIC_DATA

  • Key: DDS11-36
  • Legacy Issue Number: 8371
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The last part of the description states: "They both concern Topic, DataWriter and DataReader…"although that furter in the text is described that TOPIC_DATA is only applicable for Topics it would be better to remove this part of the description.
    Resolution:
    The last section of paragraph 2.1.3.2 shall be removed.
    Revised Text:
    The text: "This QoS is very similar in intent to USER_DATA……primarily on the DataReader/DataWriter." shall be removed.
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-118 Introduce_TIME_INVALID_constant

  • Key: DDS-92
  • Legacy Issue Number: 6798
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The PSM/IDL does not provide the means for an application to specify
    an invalid time (e.g. in the SampleInfo)

    **PROPOSAL**

    Add the following constant to the IDL:

    Timestamp t TIMESTAMP_INVALID =

    { -1, 0 }
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 14] Helper addition to the IDL

  • Key: DDS-91
  • Legacy Issue Number: 6797
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-33 Specification_of_infinite_duration

    The PSM/IDL does not provide the means for an application to specify
    an infinite duration (e.g as a timeout)

    **PROPOSAL**

    Add the following constant to the IDL:

    Duration_t DURATION_INFINITE =

    { 0x7ffffff, 0xffffffff }
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-31 Reason_and_use_of_enabled

  • Key: DDS-90
  • Legacy Issue Number: 6796
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The "enable"operation was added in support of DLRL. However if the
    application is not using DLRL it is often inconvenient to have to
    explicitly "enable" each entity before using it.

    **PROPOSAL**

    Add a QoS to the DomainParticipant, Publisher and Subscriber called
    ENTITY_CREATION_SETTINGS. This QoS contains the Boolean
    "create_enabled". If this Boolean is set to "TRUE" then the entities
    created by the factory will be automatically enabled (i.e. the factory
    will call the enable() before returning the entity).

    Specify that the default value of this setting is TRUE.

    Specify that this QoS is mutable

    This affects sections 2.1.3, and 2.2.3
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reason and use of enable

  • Key: DDS-89
  • Legacy Issue Number: 6795
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-30 Topic_enable_semantics

    In section 2.1.2.1.1.7 it is not clear what is the precise semantics
    of the "enable" on a Topic are? Can the same or another node see it
    (by means of "lookup_topic") a Topic that has not been enabled?

    Similarly can the TopicListener be invoked before the Topic is
    enabled. It appear undesirable since the QoS may still change.

    **PROPOSAL**

    Clarify that the Topic is not accessible by means of "lookup" neither
    locally not globally until it has been enabled.

    Also clarify that the TopicListener will only be called after the
    Topic is enabled.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Duplicate use of domainId

  • Key: DDS-86
  • Legacy Issue Number: 6792
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-38 Duplicate_domainId_to_create_participant

    The specification does not clarify the behavior of
    DomainParticipantFactory create_participant when the domainId
    specified is already used.

    **PROPOSAL**

    Return a HANDLE_NIL in that case.

    Also add a lookup_participant method to DomainParticipantFactory with
    a parameter of type DomainId_t. to allow finding a pre-exising
    DomainParticipant.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-02 Data_Available_status_transition

  • Key: DDS-85
  • Legacy Issue Number: 6791
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The data available status becomes TRUE when data is available, but
    under what condition does it become FALSE again?

    According the specification when data is taken, but does this only
    apply to the object that is accessed? Or do the status values of other
    objects that become untrue as a result of the take action also need to
    be changed?

    Example: A reader with 3 queries, data arrives and the status of the
    reader and all queries become TRUE. The data is taken via the reader,
    do the status values of the queries become FALSE?

    **PROPOSAL**

    Add the following clarifications to section 2.1.4.4

    DataReader::take() and DataReader::read() changes the status of the
    queries that are no longer true after the 'take'. Since 'take' removes
    the data from the service so its no longer there it would make little
    sense for the status to remain enabled.

    In other words the same way that arrival of data may change the 'data
    available status' of any query, so would the 'taking' or 'reading' of
    data potentially affect all queries.

    Note that this does not mean that waitesets that were attached to the
    query will not be woken up. This is an implementation issue. Once the
    query status changes to 'enabled' it may wake up the attached waitset,
    transitioning to 'not-enabled' does not necessarily 'unwakeup' the
    waitset since this operation is in general not possible. The
    consequence is that the application may be woken up and not see any
    active conditions. This is unavoidable if multiple threads are
    concurrently taking data.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-40 Name_and_return_type_of_lookup_topic

  • Key: DDS-88
  • Legacy Issue Number: 6794
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently, the lookup_topic method returns a type Topic. Why does it
    not return a type TopicDescription? In that case, it could also be
    used to search for ContentFilteredTopics and MultiTopics.

    **PROPOSAL**

    Change prototype lookup_topic to return TopicDescription.

    Change name from lookup_topic to lookup_topicdescription

    Specify that lookup_topicdescription will also find
    ContentFilteredTopic and MultiTopic

    This affects sections 2.1.2.2.1.11, and 2.2.3.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of Topic versus TopicDescription

  • Key: DDS-87
  • Legacy Issue Number: 6793
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-43 TopicDescription _name_attribute

    In section 2.1.2.3 TopicDescription has an attribute called "name.
    However the IDL is inconsistent. TopicDescription does not have the
    "name" attribute, instead Topic has the name and the other derived
    classes (ContentFilteredTopic and MultiTopic) do not have a name

    In the IDL specification the name specified by the TopicDescription
    but instead only by the Topic.

    It makes sense to have the name on TopicDescription as in the PIM such
    that all kinds of TopicDescription entities can be locally accessed by
    means of "lookup_topic".

    **PROPOSAL**

    Fix the PIM IDL file to match the PSM.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-126 Inconsistent_parameter_order_to_get_datareaders

  • Key: DDS-80
  • Legacy Issue Number: 6786
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section 2.1.2.5.2 the order of parameters in get_datareaders is
    (LifecycleState, SampleState) is inconsistent with the order in the
    methods which is (SampleState, LifecycleState)

    **PROPOSAL**

    Change parameter order to (SampleState, LifecycleState) This affects
    both the PIM (section 2.1.2.5.2) and the IDL PSM
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-205 On_requested_deadline_missed_paramtype

  • Key: DDS-79
  • Legacy Issue Number: 6785
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    2.1.2.2.3: In the "on_requested_deadline_missed" method, the second
    parameter is of type "RequestedIncompatibleQosStatus" instead of type
    "RequestedDeadlineMissedStatus"

    **PROPOSAL**

    Fix section 2.1.2.2.3. parameter type should be
    RequestedDeadlineMissedStatus
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-88 Inconsistent_naming_PIM_IDL_instance_samples

  • Key: DDS-78
  • Legacy Issue Number: 6784
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Page 2-68 the field in QoS RESOURCE_LIMITS is called
    max_instance_samples. In the IDL (page 2-104) says
    max_samples_per_instance

    **PROPOSAL**

    Change table in 2-68 replace the two references to
    max_samples_per_instance
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-79 Missing_StatusKind_liveliness_idl_constants

  • Key: DDS-77
  • Legacy Issue Number: 6783
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The communication statuses LIVELINESS_LOST and LIVELINESS_CHANGED do
    not have a corresponding PSM IDL StatusKind constant definitions

    **PROPOSAL**

    Correct the IDL PSM. Add said definitions consistently with PIM.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-70 Missing_deadline_statuskind_from_pim

  • Key: DDS-76
  • Legacy Issue Number: 6782
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.2.2. The PSM IDL StatusKind constant definitions
    OFFERED_INSTANCE_DEADLINE_MISSED_STATUS and
    REQUESTED_INSTANCE_DEADLINE_MISSED_STATUS are not mentioned in the PIM
    and do not have a corresponding Status class either.

    **PROPOSAL**

    Correct PIM and add said statuses to section 2.1.4.1.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-59 FooDataReader_read_take_parameter_order

  • Key: DDS-75
  • Legacy Issue Number: 6781
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.5.3 FooDataReader class table, operation read and
    take. In the table, lifecycle_states and sample_states parameters are
    reversed with respect to IDL PSM.

    **PROPOSAL**

    Correct section 2.1.2.5.3.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification of listener invocation and waitset signaling

  • Key: DDS-84
  • Legacy Issue Number: 6790
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-01 Listener_waitset_triggering

    The specification does not make clear whether listeners and waitsets
    are awaken once per "event" that causes a change of status (implying a
    queue of events) or are they just awaken once when the status changes.

    **PROPOSAL**

    Clarify that there is no implied "queueing". The listeners and
    waitsets are enabled based on the status change but not necessarily
    called/signaled multiple times. This clarification should appear in
    section 2.1.4.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-229 IDL_rename_publisher_laxity_w_latency_budget

  • Key: DDS-83
  • Legacy Issue Number: 6789
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.2.3 IDL. TopicQos, DataWriterQos, DataReaderQos have field
    called delay_laxity should be latency_budget according to the PIM

    **PROPOSAL**

    Change the IDL to match the PIM by renaming delay_laxity to
    latency_budget
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-58 DataReader_read_take_w_condition

  • Key: DDS-74
  • Legacy Issue Number: 6780
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.5.3 (DataReader and FooDataReader class table),
    operations read_w_condition and take_w_condition. In the IDL file, the
    sample_info parameter is of type SampleInfo instead of SampleInfoSeq.

    **PROPOSAL** Correct the IDL PSM. sample_info parameter should be of
    type SampleInfoSeq.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-56 Subscriber_notify_datareaders_parameters

  • Key: DDS-73
  • Legacy Issue Number: 6779
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section 2.1.2.5.2, subscriber class table, operation
    notify_datareaders void. In the IDL file this method has two
    parameters: LifecycleStateMask and SampleStateMask

    **PROPOSAL**

    Correct the IDL PSM. Remove the parameters in the IDL file.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-63 QoS_USER_DATA_on_Publisher_and_Subscriber

  • Key: DDS-82
  • Legacy Issue Number: 6788
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.3. According to the QosPolicy table, USER_DATA does not
    concern Publisher and Subscriber entities. The IDL PSM however has
    UserDataQosPolicy as a member of both the PublisherQos and
    SubscriberQos structures.

    **PROPOSAL**

    Correct the PSM. USER_DATA remove USER_DATA from Publisher and
    Subscriber
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-135 Missing_accessor_for_SampleRejectedStatus

  • Key: DDS-81
  • Legacy Issue Number: 6787
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Attribute/accessor for SampleRejectedStatus missing from 2.1.2.5.3

    **PROPOSAL**

    Add the get_xxx accesor to the DataReader class
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-57 FooDataReader_get_key

  • Key: DDS-72
  • Legacy Issue Number: 6778
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.5.3. FooDataReader class table. The get_key_value
    method is named get_key in the IDL PSM.

    **PROPOSAL**

    Correct the IDL PSM. Method should be named get_key_value
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-49 DataWriter_get_key

  • Key: DDS-71
  • Legacy Issue Number: 6777
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.4.2. DataWriter class table. The get_key_value method
    is named get_key in the IDL PSM.

    **PROPOSAL**

    Correct the IDL PSM. Method should be named get_key_value
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 15] Semantics of register and unregister instance

  • Key: DDS-94
  • Legacy Issue Number: 6800
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-13 Semantics_of_register_unregister_instance

    The semantics of the register_instance and unregister_instance methods
    are not entirely clear. From section 2.1.2.5.1 it seems that both
    methods have, apart from their local memory management purpose on the
    Publisher side, also a purpose with respect to determining the
    LIVELINESS of a DataWriter on the Subscriber side. This means that
    these methods will probably result in network communication as well

    **PROPOSAL**

    Clarify the semantics by adding the following paragraphs as needed to
    sections 2.1.2.5 and to 2.1.3:

    The need for registering/unregistering instances stems from two use
    cases: (1) Ownership resolution on redundant systems, and (2)
    Detection of loss in topological connectivity and the consequent
    difference in the semantics of unregister and dispose (3).

    (1) Ownership resolution on redundant systems

    It is expected that users will use DDS to set up redundant systems
    where multiple DataWriters are "capable" of writing the same
    instance. The data-writers are either configured such that both are
    writing the instance "constantly" or else they use some mechanism to
    monitor each other and only write when they detect that the primary
    "writer" is no longer writing.

    Either of the above two cases uses the OWNERSHIP policy "Exclusive"
    and arbitrate themselves by means of the OWNERSHIP_STRENGTH. The
    desired behavior is that when the "primary" writer stops writing, the
    application should start to receive data from the secondary subscriber

    This approach requires some mechanism to detect that the "writer" is
    no longer "writing" the data as it should. There are several reasons
    why this may be happening and all must be detected (but not
    necessarily distinguished):

    The writing process is no longer running (e.g. the whole application
    has crashed)

    Connectivity to the writing application has been lost (e.g. network
    got disconnected)

    Application logic that was writing the data is faulty and has stopped
    doing so.

    Arbitrating from a writer to one of a higher strength is simple and
    the decision can be taken autonomously by the reader. Switching
    ownership from a higher strength writer to one of a lower strength
    requires that the "reader" application can make a determination that
    the "writer" application is "no longer writing the instance".

    (1.1) Case where the data is periodically updated

    This determination is reasonably simple when the data is being written
    periodically at some rate. The writer simply states its offered
    deadline (maximum interval between updates) and the reader monitors
    that the writer indeed updates the instance at least once per
    deadline_period. If the deadline is missed, the reader considers the
    writer "not alive" and gives ownership to the highest-strength writer
    that is alive

    (1.2) Case where data is not periodically updated

    The case where the writer is not writing data periodically is also a
    very important use-case. Since the data is not being updated at any
    fixed period, the "deadline" mechanism cannot be used to determine
    ownership. The liveliness neatly solves this situation. Ownership is
    maintained while the writer is "alive" and for the writer to be alive
    it must be fulfill its "LIVELINESS" contract. The different means to
    renew liveliness (automatic, manual) combined by the implied renewal
    each time data is written handle the three conditions above (a), (b),
    or (c) ( note that to handle (c) Liveliness must be
    MANUAL_BY_TOPIC). Now the writer can retain ownership by periodically
    writing data or else calling assert_liveliness() if it has no data to
    write. Alternatively if only protection against (a) or (b) is desired,
    it is sufficient that some task on the writer process periodically
    writes data or calls assert_liveliness() on the participant.

    However, this scenario requires that the reader knows what instances
    are being "written" by the writer. That is the only way that the
    reader can maintain ownership of specific instances from the fact that
    the writer is still "alive". Hence the need for the writer to
    "register" and "unregister" instances. Note that while "registration"
    can be done lazily the first time the writer writes the instance,
    "unregistration" in general cannot. Unless we are willing to say that
    once a writer writes an instance it will forever write the instance
    until the writer is deleted. Similar reasoning will lead to the fact
    that unregistration will also require a message to be sent to the
    readers

    (2) Detection of loss in topological connectivity

    There are applications that are designed in such way that their
    correct operation requires some minimal topological connectivity, that
    is, the writer needs to have a minimum number or readers or
    alternatively the reader must have a minimum number of writers.

    A common scenario is that the application does not start doing is
    logic until it knows that some specific writers have the minimum
    configured readers (e.g the alarm monitor is up).

    A more common scenario is that the application logic will wait until
    some writers appear that can provide some needed source of information
    (e.g. the raw sensor data that must be processed).

    Furthermore once the application is running it is a requirement that
    this minimal connectivity (from the source of the data) is monitored
    and the application informed if it is ever lost. For the case where
    data is being written periodically, the DEADLINE QoS and the
    on_deadline_missed() listener provides the notification. The case
    where data is not periodically updated requires the use of the
    LIVELINESS in combination with register/unregister instance to detect
    whether the "connectivity" has been lost, and the notification is
    provided by means of the "NO_WRITERS" lifecycle state.

    In term of the required mechanisms the scenario is very similar to the
    case of maintaining ownership. In both cases the reader needs to know
    whether a writer is still "managing the current value of an instance"
    even though it is not continually writing it and this knowledge
    requires the writer to keep its liveliness plus some means to know
    which instances the writer is currently "managing" (i.e. the
    registered instances).

    Note that the need to notify the reader that a particular instance has
    no writers does not imply that the mechanism is the use of a
    "NO_WRITES" lifecycle. We could just as well use a listener. The
    listener mechanism has the problem that there is no way to know which
    instances are the ones that have no writers. But this is also a
    problem for the "on_deadline_missed" listener so we think it would be
    a good idea to refractor these two mechanisms to that they are similar
    in nature and both provide the means to determine which instances have
    the problem.

    (3) Difference between unregister and dispose

    Dispose is different than unregister. The "dispose" indicates that the
    data-instance no longer exists (e.g. a track that has disappeared, a
    simulation entity that has been destroyed, a record entry that has
    been deleted, etc.) whereas the "unregister" indicates that the writer
    is no longer taking responsibility for updating the value of the
    instance.

    Deleting a data-writer is equivalent to unregistering all the
    instances it was writing, but is not the same as "disposing" all the
    instances.

    For a topic with EXCLUSIVE ownership if the current owner of an
    instance disposes it, the readers an instance will see the lifecycle
    as being "DELETED" and not see the values being written by the weaker
    writer (even after the stronger one has disposed the instance). This
    is because the owner of the instance is saying that the instance no
    longer exists (e.g. the master of the database is saying that a record
    has been deleted) and thus the readers should see it as such.

    For a topic with EXCLUSIVE ownership if the current owner of an
    instance unregisters it than it will relinquish ownership and thus the
    readers will see the value updated by another writer (which will then
    become the owner). This is because the owner said that it no longer
    will be providing values for the instance and thus any other writer
    can take ownership and provide those values
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-102 Addition_of time_related_constants

  • Key: DDS-93
  • Legacy Issue Number: 6799
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Sometimes it is necessary to represent a zero duration as well as an
    invalid time.

    A zero duration is needed for example to provide the value of a
    minimum_separation when a TIME_BASED_FILTER is not desired.

    An invalid time is needed when samples are returned that do not
    represent actual data.

    The representation of a DURATION_ZERO clearly is a Time_t with values

    {0, 0}

    . However it is desirable that the name of this constant is
    standardized across implementations.

    **PROPOSAL**

    Add the following constant to the IDL:

    Timestamp t DURATION_ZERO =

    { 0, 0 }
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 31] Topic QoS refactor

  • Key: DDS-111
  • Legacy Issue Number: 6817
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-86 Topic_qos_refactor and Ref-150
    Tracking_of_topic_properties_by_reader_writer

    The reason for the DDS specification to add QoS to the Topic was to
    allow annotating the information-model with Topic QoS settings. That
    way it is possible for the individual applications and their designers
    to be relieved from many details and configure the writers/readers
    from this information model.

    However the definition of the Topic QoS does not match this.

    Section 2.1.2.4.3.2 describes a model where if the QoS is 'not set' on
    a dataWriter or a DataReader, then the one of the Topic is used
    instead. Furthermore it says that in this situation the QoS of the
    Entity will "track" that of the Topic.

    These statements are not consistent with the PIM or PSM as there is no
    way provided to 'not set' a QoS. All the API's force complete setting
    of the QoS.

    Furthermore the 'tracking' behavior would be very hard to implement
    and it would also be very confusing for an user that has a QoS of an
    entity magically change when the QoS of the topic changes. Lastly it
    would also be hard to handle the case where as a result of the
    'tracking' the QoS of an entity becomes incompatible with that of
    other entities already associated with it.

    Given all this it would be desirable to make the use of Topic QoS
    consistent with the API's and also simpler to implement and understand

    **PROPOSAL**

    Modify section 2.1.2.4.3.2.

    Remove all references to behaviors regarding what happens if some QoS
    is "not set" rather say that QoS is always explicitly set although it
    can be set from defaults in the factories.

    Also remove the sentence regarding how the entity QoS can "track" the
    Topic qos.

    Explain that the pattern to create an entity with "default" QoS is to
    get the default qos from the factory, and also get it from the Topic,
    and then modify the desired policies before creating the entity.

    To assist this common pattern we recommend adding the following
    utility operations:

    Publisher::initialize_from_topic_qos(inout DataReaderQos qos, in Topic
    a_topic, in long mask)

    Subscriber::initialize_from_topic_qos(inout DataWriterQos qos, in
    Topic a_topic, in long mask)

    Specify that all QoS on Topic is immutable.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 30] Setting of default qos on factories

  • Key: DDS-110
  • Legacy Issue Number: 6816
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-?? Setting_default_qos_on_factories

    The specification provides a way to create Entities with QoS by
    explicitly providing the QoS when the entity is created.

    In some cases it would be desirable to provide a pattern such that
    many entities can be easily created with the same QoS without the
    application explicitly. Thst way the management of the Qos can be
    "centralized" in few modules in the application logic

    **PROPOSAL**

    Add the following operations:

    DomainParticipant::set_default_publisher_qos(),
    DomainParticipant::get_default_publisher_qos(),
    DomainParticipant::set_default_subscriber_qos(),
    DomainParticipant::get_default_subscriber_qos(),
    Publisher::set_default_datawriter_qos(),
    Publisher::get_default_datawriter_qos(),
    Subscriber::set_default_datawriter_qos(),
    Subscriber::get_default_datawriter_qos().

    This allows the application to set a default QoS for the entities that
    the factory will create, and then explicitly use that QoS to create
    the entities.

    Furthermore specify that if the set_default_xxx_qos operations are not
    called then the get_default_xxx_qos will return the defaults specified
    in section 2.1.3
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 29] Disposing a multi-topic

  • Key: DDS-109
  • Legacy Issue Number: 6815
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-83 Multitopic_refactor _

    The specification does not say when a MultiTopic is disposed

    **PROPOSAL**

    State in section 2.1.2.3.4 that MultiTopic will dispose as soon as one
    of the underlying Topic that are its components is disposed
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 33] Initialization of resources needed

  • Key: DDS-113
  • Legacy Issue Number: 6819
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    ] Initialization of resources needed to implement
    DURABILITY TRANSIENT or PERSISTENT

    ***Ref-91 Configuration_of_the_transient_and_persistent_service

    The DDS specification does not provide a clear model of the behavior
    of the service when the DURABILITY QoS is set to TRANSIENT or
    PERSISTENT

    Moreover for the application needs to be able to specify the QoS
    parameters and resources that the implementation is allowed to use
    when implementing this service.

    **PROPOSAL**

    Add the following explanation to section 2.1.3.2:

    For the purpose of implementing the the DURABILITY QoS settings of
    TRANSIENT, PERSISTENT the service behaves "as if" it had a "built-in
    DataReader and DataWriter" for each Topic that is configured to have
    said DURABILITY kind. In other words, it is "as if" somewhere in the
    system (possibly on a remote node) there was a "built-in durability"
    DataReader that subscribed to that Topic and a "built-in durability"
    DataWriter that published that Topic as needed for the new subscribers
    that join the system.

    For each Topic, the built-in "persistence service"
    datareader/datawriter has its QoS configured from the Topic QoS for
    that Topic as described in Issue Topic_qos_refactor (Issue #86). In
    otherwords, it is as-if the service first did a
    "Participant::lookup_topic" for that Topic, and then used the QoS on
    the Topic to configure the built-in entities.

    As a consequence of this model, the transient or persistence serviced
    can be configured by means of setting the proper QoS on the Topic.

    For a given Topic, the usual request/offered semantics apply to the
    matching between any DataWriter in the system that writes the Topic
    and the built-in transient/persistent DataReader for that
    Topic. Similarly for the builtin transient/persistent DataWriter for
    the Topic and any DataReader for the Topic. As a consequence, a
    DataWriter that has an incompatible QoS with respect to what the Topic
    specified for the built-in transient/persistent DataReader will not
    send its data to the transient/persistent service, and a DataReader
    that has incompatible QoS with respect to the specified in the Topic
    for the transient/persistent DataWriter will not get data from it.

    Incompatibilities between local DataReader/DataWriter entities and the
    corresponding builtin transient/persistent entities cause the
    "incompatible qos" listener to be invoked as they would with any other
    entity.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 32] Create dependencies on type

  • Key: DDS-112
  • Legacy Issue Number: 6818
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-89 State_dependency_register_type_create_datareader_writer

    The specification does not say clearly whether a TopicDescription can
    be created if the associated type has not been registered and what
    happens if the user tries to do that.

    **PROPOSAL**

    State explicitly that the operations that create specializations of
    TopicDescription, that is, create_topic and create_multitopic and
    lookup_topic, Will return PRECONDITION_NOT_MET if type not locally
    registered
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 20] Narrow the applicability of assert liveliness

  • Key: DDS-99
  • Legacy Issue Number: 6805
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-29 Entity_operation_assert_livelines

    Class Entity has a function assert_liveliness, which is inherited by
    all derived classes. However, this function is relevant in combination
    with the LIVELINESS QoS policy only, and has only defined behavior on
    DomainParticipant and DataWriter

    **PROPOSAL** Remove assert_liveliness from Entity and introduce it
    in DataWriter and Participant
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 19] Initial value of entity status changes

  • Key: DDS-98
  • Legacy Issue Number: 6804
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-26 Initial_value_of_entity_status

    The specification does not define the initial value of the status of
    an entity after initializations/enabling

    **PROPOSAL**

    Specify in section 2.1.2.1.1.6 that when the entity is created the
    return of get_status_changes is an empty mask indicating that no
    status have changed
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior on creation failure

  • Key: DDS-97
  • Legacy Issue Number: 6803
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-21 Error_status_on_create_calls

    The specification does not explain the return value of the factory
    "create" calls if the operation fails, for example due to inconsistent
    QoS.

    **PROPOSAL**

    Add text that explains that in case of failure the return value is NIL
    (as defined on each PSM).

    This affects 2.1.2.2.2.1, 2.1.2.2.1.1, 2.1.2.2.1.5, 2.1.2.2.1.7,
    2.1.2.2.1.9, 2.1.2.4.1.5, 2.1.2.5.2.5
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 25] Addition of read and take to ReadCondition

  • Key: DDS-105
  • Legacy Issue Number: 6811
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-60 Adding_read_take_to_ReadCondition

    Why not have a read and take operation on readcondition instread of
    read_w_condition and take_w_condition?

    In the current situation the middleware must perform consistency
    checking and handle error conditions.

    Moving the read and take to the readCondition will require generation
    of typed interfaces but this is merely a wrapper around the current
    situation avoiding the error prone design.

    For example, if a Waitset has many query conditions. Then the
    application would need to find the reader that matches it. Adding a
    get_reader in the querycondition would not give a strongly-typed
    reader.

    The simplest solution is to have a read in the querycondition.

    **PROPOSAL**

    create the ReadCondition and QueryReadCondition as implied IDL

    We will move create_readcondition to the FooDataReader

    Add a read to the Read and QueryConditions

    Remove the read_w_condition from the DataReader and FooDataReader
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 24] Clarification of status flag

  • Key: DDS-104
  • Legacy Issue Number: 6810
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-64 Association_of_status_and_statuschangedflag

    Why does every status have an associated object "StatusChangedFlag"
    instead of a boolean attribute "changed"?

    Figure 2-14 (2.1.4.2) is at least misleading and should be clarified
    regarding this point. It suggests a 1 to n relation with a
    "StatusChangedFlag" class.

    Even though the diagram was only meant as conceptual explanation, not
    for providing an implementation architecture it would be desirable to
    improve specification in this respect.

    **PROPOSAL**

    Add text to 2.1.4.2 to explain that this figure is conceptual and
    simply represents that the Entity knows which specific statuses have
    changed, it does not imply a particular implementation in terms of
    Boolean flags.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 17] Clarify consequence of changing partitions

  • Key: DDS-96
  • Legacy Issue Number: 6802
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-17 PartitionQos_behavior_on_change

    The specification does not make it clear whether changing the
    PARTITION QoS on a Publisher or Subscriber affects the existing
    DataReader or DataWriter establishing some "associations" that did not
    exist before, or breaking associations that existed.

    Furthermore the specification does not describe whether the
    INCOMPATIBLE_QOS listeners/ status will be triggered

    Given that partitions are intended to be used to separate logically
    separate 'communication words' so that you can isolate things it would
    seem that changing partitions should affect existing DataReader and
    writers and not trigger the INCOMPATIBLE_QOS.

    **PROPOSAL**

    Modify section 2.1.3.9 to clarify that (1) changing the PARTITION QoS
    on a Publisher or Subscriber does affect the existing DataReader or
    DataWriter entities. It may establish new "associations" that did not
    exist before, or break existing associations.

    Also explain in section 2.1.3.9 that not matching the PARTITION QoS
    does not trigger the INCOMPATIBLE_QOS listener nor change the
    associated status.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 16] Clarification of expression syntax

  • Key: DDS-95
  • Legacy Issue Number: 6801
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-14 Relationship_of_IDL_and_expression_syntax

    The fieldnames and topicnames used in SQL expressions need to be
    language-independent. This means that they have to be derived from the
    IDL-definition. The SQL description in Annex A/B does not define the
    relationship between the FIELDNAME and the IDL definition.

    Example, assume the following IDL definition:

    module mymodule { struct mystruct

    { long record; }

    ; };

    The SQL statement could become "SELECT record AS value FROM
    mymodule.mystruct ...".

    The field "record" would be translated into "IDL_record" by an ADA
    preprocessor. The SQL-statement should still use "record" to be
    language independent. This is a generic situation that occurs for each
    language when the name of the field matches a reserved keyword.

    **PROPOSAL**

    Improve specification "Annex A/B" stating that the syntax of the SQL
    statement will match the names used in IDL not necessarily those of
    the language mapping.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-134 Additional_w_timestamp_operations

  • Key: DDS-101
  • Legacy Issue Number: 6807
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    It seems that the samples that indicate the 'disposing' of an instance
    need to also be sorted with respect to other samples and the sorting
    should follow DESTINATION_ORDER policy

    However if DESTINATION_ORDER is BY_SOURCE_TIMESTAMP and the
    application is explicitly passing the timestamp to write_w_timestamp
    there is no way to also specify the time when an instance is disposed

    The same applies to unregister. It may be necessary to order it with
    respect to other events

    **PROPOSAL**

    Add a dispose_w_timestamp operation to DataWriter.

    Add an unregister_w_timestamp operation to DataWriter
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 21] Helper operations

  • Key: DDS-100
  • Legacy Issue Number: 6806
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-32 Quering_waitset_for_attached_conditions

    The WaitSet class has methods for attaching and detaching conditions
    to it, but no method for querying which conditions are attached.

    **PROPOSAL**

    In section 2.1.2.1.6 add a get_conditions method that returns a
    ReturnCode_t and has a collection of conditions as an out
    paramater. In section 2.2.3 (IDL) add the corresponding operation.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

[DDS ISSUE# 28] Desirability to define "information model" in a file

  • Key: DDS-108
  • Legacy Issue Number: 6814
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-77 Offering_the_possibility_to_define_topics_in_a_file _

    It would be desirable to have an "information model" where the QoS of
    the topics is specified in some file.

    This information model would also contain the QoS for the Topic.

    **PROPOSAL**

    No action as this seems beyond what the FTF could solve.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    No action as this seems beyond what the FTF could solve
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 27] Additional situations resulting in inconsistent QoS

  • Key: DDS-107
  • Legacy Issue Number: 6813
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-73 Depth_must_be_less_or_equal_ max_samples_per_instance

    Clarify that depth <= max_samples_per_instance otherwise its an
    inconsistent QoS

    **PROPOSAL**

    State this requirement in 2.1.3.12 and 2.1.2.13
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 26] Definition of DCPSKey

  • Key: DDS-106
  • Legacy Issue Number: 6812
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-68 Definition_of_DCPSKey

    Section 2.1.5. This section introduces a type DCPSKey, this type is
    not specified anywhere.

    This key however is only used for the built-in types so it would be
    better if, to avoid confusion, is named BuiltinTopicKey_t

    **PROPOSAL**

    Rename DCPSKey to be BuiltinTopicKey_t

    Define it in the IDL PSM the same way IntanceHandle_t is defined so
    that each vendor can define it as needed.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ISSUE# 23] Make Listener inheritance explicit in figures 2-9 and 2-10

  • Key: DDS-103
  • Legacy Issue Number: 6809
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-51Forward_mention_PublisherListener_inheritance and Ref-61
    Forward_reference_SubscriberListener_baseclass

    In 2.1.2.4 the PublisherListener interface extends the
    DataWriterListener, this is not mentioned until 2.1.4.3 after
    PulisherListener has been described

    The same applies to 2.1.2.5 with SubscriberListener and
    dataReaderListener

    **PROPOSAL**

    Modify figures 2-9 and 2-10 to show this relationships. Or at least
    mention them in section 2.1.2.4.3 and 2.1.2.5.6
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS ISSUE# 22] Details in the code generation

  • Key: DDS-102
  • Legacy Issue Number: 6808
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-47 Details_on_type_specific_code_generation

    Section 2.1.2.3.7 says "It is required that each implementation of the
    Service provides an automatic means to generate this type-specific
    class from a description of the type (using IDL for example in the
    CORBA mapping)."

    The details of this generation for the CORBA mapping should be
    mentioned in the CORBA PSM (Section 2.2).

    **PROPOSAL**

    Add to section 2.1.2.3.7 the clarification that IDL should be used for
    the language and perhaps also a figure similar to Figure 3-3 in
    section 3.1.4.5 (in the DLRL) showing the process with potential
    vendor-specific file for keys or QoS
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.1.1.2, 10.1.1.3

  • Key: DDSIRTP22-24
  • Legacy Issue Number: 16989
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 194-195
    Change: Remove the paragraphs starting "In addition to, …" since its only purpose is to describe a non-existent length field.
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Do as suggested
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The DDS specification should be separated into two documents

  • Key: DDS14-189
  • Legacy Issue Number: 19366
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS specification should be separated into two documents one for the DDS-DCPS layer and the other for DDS-DLRL layer.

    Details:
    Splitting the DDS specification into two separate specifications will simplify specification management and align better with the available implementations.

    The DDS-DCPS layer does not have any dependencies on the DDS-DLRL layer. Â DDS-DLRL is an optional compliance point built on top of DDS-DCPS.

    More than 9 vendors support DDS-DCPS whereas there are only experimental products with limited support that implement DDS-DLRL.

    The current situation where there is a single specification creates confusion and complexity. It forces each revision of the specification to handle the issues submitted against both DDS-DLRL and  DDS-DLRL. This is very cumbersome given that different companies support the different specifications and the fact that these companies have different priorities and timelines.

    The current situation is hard to sustain and has delayed the RTF work to the extent that RTF 3 closed without a report.

    Splitting the specification into two separate ones, one for the DDS-DCPS layer and the other for DDS-DLRL layer would solve these specification maintenance issues.
  • Reported: DDS 1.2 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Resolved — DDS 1.4
  • Disposition Summary:

    Split the documents per instructions in the revised text section below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Order of parameters incorrect in PSM

  • Key: DDS14-188
  • Legacy Issue Number: 9506
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In the PSM for get_discovered_topic_data() and get_discovered_participant_data() on the DomainParticipant, the data parameter should be first followed by the handle. The order is correct in the PIM.

    Proposed Resolution:
    Make the suggested modifications.

    Proposed Revised Text:

    Section 2.2.3 DCPS PSM : IDL
    In the DomainParticipant interface:

    Change the order of the parameters to get_discovered_participant_data from "in InstanceHandle_t participant_handle, inout ParticipantBuiltinTopicData participant_data" to inout ParticipantBuiltinTopicData participant_data, in InstanceHandle_t participant_handle".

    Change the order of the parameters to get_discovered_topic_data from "in InstanceHandle_t topic_handle, inout TopicBuiltinTopicData topic_data" to inout TopicBuiltinTopicData topic_data, in InstanceHandle_t topic_handle".
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.4
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS 04-04-12 Appendix B, C

  • Key: DDS14-187
  • Legacy Issue Number: 7976
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    Filters and Queries are not compile-time checked and are too
    heavy

    The 04-04-12 DDS document proposes a subset of SQL for defining filters
    andqueries.

    The filter/query expressions are passed into the corresponding methods
    as type "string".

    First, this means that conforming implementations need to provide an SQL
    expression parser/evaluator - a fairly complex piece of software.
    Second, since the expressions are given as strings, checking them at
    compile time is not straight-forward.

    We request the Revision Task Force to reconsider this design decision
    in favor of less heavyweight approaches that allow for compile-time
    checks.
  • Reported: DDS 1.0 — Tue, 14 Dec 2004 05:00 GMT
  • Disposition: Closed; No Change — DDS 1.4
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

String sequence should be a parameter and not return value

  • Key: DDS12-72
  • Legacy Issue Number: 9555
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:

    In Section 2.1.2.5.2.11 (notify_datareaders) the first sentence states
    This operation invokes the operation on_data_available on the DataReaderListener objects attached to contained DataReader entities containing samples with SampleState 'NOT_READ' and any ViewState and InstanceState.
    In Section 2.1.4.2.2 (Changes in Read Communication Statuses) it states in the first paragraph that the "StatusChangedFlag becomes false again when all samples are removed from the responsibility of the middleware via the take operation on the proper DataReader entities".
    In Figure 2-16 in the same section, the transition from the TRUE state to FALSE is accompanied by the condition "DataReader:take[all data taken by application]".

    However, in Section 2.1.4.4 (Condition and Wait-sets) in the last step in the general use pattern deals with using the result of the wait operation and in the third sub-bullet it states how if the wait unblocked due to a StatusCondition and the status change is DATA_AVAILABLE, the appropriate action is to call read/take on the relevant DataReader.
    If only a take of all samples will reset the status, then simply calling read in this use pattern will not reset the status and the given general use pattern will actual spin.

    Proposed Resolution:

    The actual condition for the StatusChangedFlag to become false should then be that the status has been considered read/accessed by the user. This should be considered as such when the listener for a Read Communication Status is called similar to Plain Communication Statuses (see T#6).
    In addition, it should be such if the user calls read/take on the associated DataReader.

    Subscriber's DATA_ON_READERS status is reset if the on_data_on_readers is called (same as for all listeners).

    In addition Subscriber's DATA_ON_READERS status is reset if the user calls read or take on any of the DataReaders belonging to the Subscriber.
    In addition, the Subscriber's DATA_ON_READERS status is also reset if the on_data_available callback is called on the DataReaderListener. This is needed such that if the application calls notify_datareaders it will reset the status.
    The inverse, i.e. resetting the DATA_AVAILABLE status when the on_data_on_readers callback is called) does not happen.

    Proposed Revised Text:

    Section 2.1.2.5.2.11 notify_datareaders

    In the first sentence, change

    DataReader entities containing samples with SampleState 'NOT_READ' and any ViewState and InstanceState

    To

    DataReader entities with a DATA_AVAILABLE status that is considered changed.

    Section 2.1.4.2.2 Changes in Read Communication Statuses

    Change the last sentence of the first paragraph from
    The StatusChangedFlag becomes false again when all the samples are removed from the responsibility of the middleware via the take operation on the proper DataReader entitites.

    To

    The DATA_AVAILABLE StatusChangedFlag becomes false again when either the corresponding listener operation (on_data_available ) is called or a read or take operation is called on the associated DataReader.

    The DATA_ON_READERS StatusChangedFlag becomes false again when any of the following occurs:

    o The corresponding listener operation (on_data_on_readers) is called.
    o The on_data_available listener operation is called on any DataReader belonging to the Subscriber.
    o The read or take on any DataReader belonging to the Subscriber

    In Figure 2-16

    Introduce two figures one for the DATA_ON_READERS and the other for the DATA_AVAILABLE
  • Reported: DDS 1.1 — Thu, 6 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improper prototype for get_XXX_status()

  • Key: DDS12-5
  • Legacy Issue Number: 9482
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:
    In the PIM, all get_XXX_status() methods return the relevant status by value. This does not allow for an error return and is inconsistent with other operations that accept a parameter.
    The same is true for the PSM except for get_inconsistent_topic_status() on the Topic which returns ReturnCode_t and the status is a parameter.

    Proposed Resolution:
    In the PIM and the PSM, the operations should return ReturnCode_t with the status as a parameter.

    Proposed Revised Text:

    Section 2.1.2.3.2 Topic Class; Replace
    get_inconsistent_topic_status InconsistentTopicStatus
    With
    get_inconsistent_topic_status ReturnCode_t
    inout: status InconsistentTopicStatus
    Section 2.1.2.4.2 DataWriter Class;
    Replace
    get_liveliness_lost_status LivelinessLostStatus
    get_offered_deadline_missed_status OfferedDeadlineMissedStatus
    get_offered_incompatible_qos_status OfferedIncompatibleQosStatus
    get_publication_match_status PublicationMatchedStatus
    With
    get_liveliness_lost_status ReturnCode_t
    inout: status LivelinessLostStatus
    get_offered_deadline_missed_status ReturnCode_t
    inout: status OfferedDeadlineMissedStatus
    get_offered_incompatible_qos_status ReturnCode_t
    inout: status OfferedIncompatibleQosStatus
    get_publication_match_status ReturnCode_t
    inout: status PublicationMatchedStatus
    Section 2.1.2.5.2 Subscriber Class;
    Replace
    get_sample_lost_status SampleLostStatus
    With
    get_sample_lost_status ReturnCode_t
    inout: status SampleLostStatus
    Section 2.1.2.5.3 DataReader Class;
    Replace
    get_liveliness_changed_status LivelinessChangedStatus
    get_requested_deadline_missed_status RequestedDeadlineMissedStatus
    get_requested_incompatible_qos_status RequestedIncompatibleQosStatus
    get_sample_rejected_status SampleRejectedStatus
    get_subscription_match_status SubscriptionMatchedStatus
    With
    get_liveliness_changed_status ReturnCode_t
    inout: status LivelinessChangedStatus
    get_requested_deadline_missed_status ReturnCode_t
    inout: status RequestedDeadlineMissedStatus
    get_requested_incompatible_qos_status ReturnCode_t
    inout: status RequestedIncompatibleQosStatus
    get_sample_rejected_status ReturnCode_t
    inout: status SampleRejectedStatus
    get_subscription_match_status ReturnCode_t
    inout: status SubscriptionMatchedStatus
    Section 2.2.3 DCPS PSM : IDL

    interface DataWriter; Replace:
    LivelinessLostStatus get_liveliness_lost_status();
    OfferedDeadlineMissedStatus get_offered_deadline_missed_status();
    OfferedIncompatibleQosStatus get_offered_incompatible_qos_status();
    PublicationMatchedStatus get_publication_match_status();
    With
    ReturnCode_t get_liveliness_lost_status(inout LivelinessLostStatus status);
    ReturnCode_t get_offered_deadline_missed_status(inout OfferedDeadlineMissedStatus status);
    ReturnCode_t get_offered_incompatible_qos_status(inout OfferedIncompatibleQosStatus status);
    ReturnCode_t get_publication_match_status(inout PublicationMatchedStatus status);

    interface DataReader; Replace:
    SampleRejectedStatus get_sample_rejected_status();
    LivelinessChangedStatus get_liveliness_changed_status();
    RequestedDeadlineMissedStatus get_requested_deadline_missed_status();
    RequestedIncompatibleQosStatus get_requested_incompatible_qos_status();
    SubscriptionMatchedStatus get_subscription_match_status();
    SampleLostStatus get_sample_lost_status();
    With:
    ReturnCode_t get_sample_rejected_status( inout SampleRejectedStatus status );
    ReturnCode_t get_liveliness_changed_status(inout LivelinessChangedStatus status);
    ReturnCode_t get_requested_deadline_missed_status(inout RequestedDeadlineMissedStatus status);
    ReturnCode_t get_requested_incompatible_qos_status(inout RequestedIncompatibleQosStatus status);
    ReturnCode_t get_subscription_match_status(inout SubscriptionMatchedStatus status);
    ReturnCode_t get_sample_lost_status(inout SampleLostStatus status);
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mention of get_instance() operation on DomainParticipantFactory beingstatic

  • Key: DDS12-4
  • Legacy Issue Number: 9481
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Title: R#4 Mention of get_instance() operation on the DomainParticipantFactory being static in the wrong section

    Summary:
    The last paragraph of section 2.1.2.2.2.4 (lookup_participant) mentioning that get_instance() is a static operation probably belongs in the preceding section 2.1.2.2.2.3 (get_instance).

    Proposed Resolution:
    Move the paragraph to the correct section

    Proposed Revised Text:

    Section 2.1.2.2.2.4 lookup_participant
    Remove the last paragraph:
    The get_instance operation is a static operation implemented using the syntax of the native language and can therefore not be expressed in the IDL PSM.

    Section 2.1.2.2.2.3 get_instance
    Add the paragraph removed from above:
    The get_instance operation is a static operation implemented using the syntax of the native language and can therefore not be expressed in the IDL PSM.
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Move the paragraph to the correct section
  • Updated: Fri, 6 Mar 2015 20:58 GMT

String sequence should be a parameter and not return value

  • Key: DDS12-3
  • Legacy Issue Number: 9480
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:
    The string sequence parameter in the get_expression_parameters() method of the ContentFilteredTopic and MultiTopic and in the

    get_query_parameters() method of the QueryCondition are all listed as the return value in both the PIM and PSM.
    It is desirable for the string sequence to be used as a parameter for consistency and to allow for an error return.

    Proposed Resolution:
    The PIM and the PSM should have the string sequence as a parameter and the methods should return ReturnCode_t.

    Proposed Revised Text:

    Section 2.1.2.3.3 ContentFilteredTopic class; ContentFilteredTopic class table
    Change row from:
    get_expression_parameters string[]
    To
    get_expression_parameters ReturnCode_t
    inout: expression_parameters string[]

    Section 2.1.2.3.4 MultiTopic Class [optional]
    Change row from:
    get_expression_parameters string[]
    To
    get_expression_parameters ReturnCode_t
    inout: expression_parameters string[]

    Section 2.2.3 DCPS PSM : IDL

    interface ContentFilteredTopic
    Replace:
    StringSeq get_expression_parameters();
    With:
    ReturnCode_t get_expression_parameters(inout StringSeq expression_parameters);

    interface MultiTopic
    Replace:
    StringSeq get_expression_parameters();
    With:
    ReturnCode_t get_expression_parameters(inout StringSeq expression_parameters);
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent prototype for Publisher's get_default_datawriter_qos() method

  • Key: DDS12-2
  • Legacy Issue Number: 9479
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:
    In the PSM it is returning void. However, in the PIM it is returning ReturnCode_t. Also, all other get_defatult_xxx_qos()

    methods return ReturnCode_t in both the PIM and the PSM.

    Proposed Resolution:
    The return code should be changed to ReturnCode_t in the PSM.

    Proposed Revised Text:

    Section 2.2.3 DCPS PSM : IDL
    interface Publisher :
    Replace
    void get_default_datawriter_qos(inout DataWriterQos qos);
    With
    ReturnCode_t get_default_datawriter_qos(inout DataWriterQos qos);
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    The return code should be changed to ReturnCode_t in the PSM.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistencies between PIM and PSM in the prototype of get_qos() methods

  • Key: DDS12-1
  • Legacy Issue Number: 9478
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    ummary:
    According to the PIM, get get_qos() method returns the QosPolicy [ ]. According to the PSM, the qos is a parameter and the

    method returns void.

    Proposed Resolution:
    The PIM should be updated to be consistent with the PSM.
    In addition, the return value in both the PIM and PSM should be changed from void to ReturnCode_t.

    Proposed Revised Text:

    Section 2.1.2.1.1 Entity Class; Entity class table
    Change row from:
    abstract get_qos QosPolicy []
    To
    abstract get_qos ReturnCode_t
    out: qos_list QosPolicy[]

    Section 2.1.2.2.1 Domain Module; DomainParticipant class table
    Change row from:
    abstract get_qos QosPolicy []
    To
    abstract get_qos ReturnCode_t
    out: qos_list QosPolicy[]

    Section 2.1.2.3.1 TopicDescription Class; Topic class table
    Change row from:
    abstract get_qos QosPolicy []
    To
    abstract get_qos ReturnCode_t
    out: qos_list QosPolicy[]

    Section 2.1.2.4.1 Publisher Class; Publisher class table
    Change row from:
    abstract get_qos QosPolicy []
    To
    abstract get_qos ReturnCode_t
    out: qos_list QosPolicy[]

    Section 2.1.2.4.2 DataWriter Class; DataWriter class table
    Change row from:
    abstract get_qos QosPolicy []
    To
    abstract get_qos ReturnCode_t
    out: qos_list QosPolicy[]

    Section 2.1.2.5.2 Subscriber Class; Subscriber class table
    Change row from:
    abstract get_qos QosPolicy []
    To
    abstract get_qos ReturnCode_t
    out: qos_list QosPolicy[]

    Section 2.1.2.5.3 DataReader Class; DataReader class table
    Change row from:
    abstract get_qos QosPolicy []
    To
    abstract get_qos ReturnCode_t
    out: qos_list QosPolicy[]

    Section 2.2.3 DCPS PSM : IDL
    interface Entity
    Change:
    // void get_qos(inout EntityQos qos);
    To
    // ReturnCode_t get_qos(inout EntityQos qos);
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

read/take_next_instance()

  • Key: DDS12-70
  • Legacy Issue Number: 9553
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Must read/take_next_instance() require that the handle corresponds to a known data-object?

    Summary:

    In sections for read/take_next_instance() and read/take_next_instance_w_condition() it states that if detectable the implementation should return BAD_PARAMETER in this case or otherwise the situation is unspecified.
    It might be desirable to allow for an invalid handle to be passed in, especially in the case that the user is iterating through instances and takes all samples to an instance that is NOT_ALIVE and has no writers in which case that action may actually free that instance, "invalidating" the handle of that instance.

    Proposed Resolution:

    Allow passing a handle that does not correspond to any instance currently on the DataReader to read_next_instance/take_next_instance. This handle should be sorted in a deterministic way with regards to the other handles such that the iteration is not interrupted.
    Proposed Revised Text:

    Section 2.1.2.5.3.16 read_next_instance

    Replace the paragraph:

    This operation implies the existence of some total order 'greater than' relationship between the instance handles. The specifics of this relationship are not important and are implementation specific. The important thing is that, according to the middleware, all instances are ordered relative to each other. This ordering is between the instances, that is, it does not depend on the actual samples received or available. For the purposes of this explanation it is 'as if' each instance handle was represented as a unique integer.

    With:

    This operation implies the existence of a total order 'greater-than' relationship between the instance handles. The specifics of this relationship are not all important and are implementation specific. The important thing is that, according to the middleware, all instances are ordered relative to each other. This ordering is between the instance handles: It should not depend on the state of the instance (e.g. whether it has data or not) and must be defined even for instance handles that do not correspond to instances currently managed by the DataReader. For the purposes of the ordering it should be 'as if' each instance handle was represented as a unique integer.

    Section 2.1.2.5.3.16 read_next_instance

    Remove the paragraph:

    The behavior of the read_instance operation follows the same rules as the read operation regarding the pre-conditions and post-conditions for the data_values and sample_infos collections. Similar to read, the read_instance operation may 'loan' elements to the output collections which must then be returned by means of return_loan.

    Replace the paragraph:

    This operation may return BAD_PARAMETER if the InstanceHandle_t a_handle does not correspond to an existing data-object known to the DataReader. If the implementation is not able to check invalid handles, then the result in this situation is unspecified.

    With

    Note that it is possible to call the 'read_next_instance' operation with an instance handle that does not correspond to an instance currently managed by the DataReader. This is because as stated earlier the 'greater-than' relationship is defined even for handles not managed by the DataReader. One practical situation where this may occur is when an applications is iterating though all the instances, takes all the samples of a NOT_ALIVE_NO_WRITERS instance, returns the loan (at which point the instance information may be removed, and thus the handle becomes invalid), and tries to read the next instance.

    Section 2.1.2.5.3.17 take_next_instance

    Replace the paragraph:

    This operation may return BAD_PARAMETER if the InstanceHandle_t a_handle does not correspond to an existing data-object known to the DataReader. If the implementation is not able to check invalid handles, then the result in this situation is unspecified.

    With

    Similar to the operation read_next_instance (see Section 2.1.2.5.3.16) it is possible to call take_next_instance with an instance handle that does not correspond to an instance currently managed by the DataReader.

    Section 2.1.2.5.3.18 read_next_instance_w_condition

    Replace the paragraph:

    This operation may return BAD_PARAMETER if the InstanceHandle_t a_handle does not correspond to an existing data-object known to the DataReader. If the implementation is not able to check invalid handles, then the result in this situation is unspecified.

    With

    Similar to the operation read_next_instance (see Section 2.1.2.5.3.16) it is possible to call read_next_instance with an instance handle that does not correspond to an instance currently managed by the DataReader.

    Section 2.1.2.5.3.19 take_next_instance_w_condition
    Replace the paragraph:

    This operation may return BAD_PARAMETER if the InstanceHandle_t a_handle does not correspond to an existing data-object known to the DataReader. If the implementation is not able to check invalid handles, then the result in this situation is unspecified.

    With

    Similar to the operation read_next_instance (see Section 2.1.2.5.3.16) it is possible to call take_next_instance_w_condition with an instance handle that does not correspond to an instance currently managed by the DataReader.
  • Reported: DDS 1.1 — Thu, 6 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify notification of ownership change

  • Key: DDS12-69
  • Legacy Issue Number: 9552
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    In section 2.1.3.9.2 EXCLUSIVE kind (the last sentence on page 2-114) the specification states that ownership changes are notified via a status change. However there is no status change that notifies of ownership change. The only way to detect it is to look at the SampleInstance and see that the publication_handle has changed.

    Proposed Resolution:
    Remove the sentence. We could add the Status, Listener, and Callback, but it seems unnecessary until we see some actual use-cases that require this…

    Proposed Revised Text:

    In section 2.1.3.9.2 EXCLUSIVE kind, last sentence in last paragraph, remove the sentence:
    "The DataReader is also notified of this via a status change that is accessible by means of the Listener or Condition mechanisms."
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unlimited setting for Resource limits not clearly explained

  • Key: DDS12-59
  • Legacy Issue Number: 9541
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    In section 2.1.3.19 it is not clear how to specify unlimited resource limits. (It is mentioned in the QoS table in section 2.1.3 that the default setting for resource_limits is length_unlimited, but in the context of 2.1.3.19 this is not repeated).

    Proposed Resolution::
    Specify in Section 2.1.3.19 that the constant LENGTH_UNLIMITED must be used to specify unlimited resource limits.

    Proposed Revised Text::
    In section 2.1.3.19 add the following paragraph before the last paragraph in the section (the one that starts with "The setting of RESOURCE_LIMITS …":

    The constant LENGTH_UNLIMITED may be used to indicate the absence of a particular limit. For example setting max_samples_per_instance to LENGH_UNLIMITED will cause the middleware to not enforce this particular limit.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Small naming inconsistentcies between PIM and PSM

  • Key: DDS12-58
  • Legacy Issue Number: 9540
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    In section 2.1.2.4.1.17, the explanation for the "copy_from _topic_qos" operation mentions two parameters called "topic_qos" and "datawriter_qos_list". Both parameter names do not exist.

    In the PSM (section 2.2.3) the first two parameters for all "read()" and "take()" methods (and their variants) are consistently called "received_data" and "sample_infos". In the DataReader PIM in section 2.1.2.5.3, these same names are only used for the "read()" and "take()" methods. All their variants and all have a first parameter called "data_values". The FooDataReader PIM has the same issue, but even uses the name "data_values" for the read() and take() methods themselves.

    Proposed Resolution::
    Replace "topic_qos" with "a_topic_qos" and "datawriter_qos_list" with "a_datawriter_qos".

    Consistently use the parameter name "received_data" in bot the PIM and the PSM.

    We propose we either ignore the second change regarding 'data_values' or change it the other way around (from received_data to data_values). This impacts the specification less. There are a lot of places that would be affected by the change to "received_data" from "data_values"

    Proposed Revised Text::

    Section 2.1.2.4.1.17 copy_from_topic_qos:
    1st paragraph, replace: "topic_qos" with "a_topic_qos"
    1st, 2nd, and 3rd paragraph, replace: "datawriter_qos_list" with "a_datawriter_qos"

    Section 2.2.3
    replace formal paramater name "received_data" with "data_value" or "data_values" depending on whether the typeis a sequence or not This affects DataReader::take* DataReader::read*, FooDataReader::take* and FooDataReader::read*

    Section 2.1.2.5.3 DataReader Class table replace "received_data" with "data_values". This affects the operations:
    return_loan
    take
    read

    Section 2.2.3 DCPS PSM : IDL
    Change formal parameter of read/take operations from "received_data" with "data_values". This affects the operations:
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Extended visibility of instance state changes

  • Key: DDS12-68
  • Legacy Issue Number: 9551
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    The instance state is only accessible via sampleInfo and this requires the availability of data.
    This implies that the dispose and the no writer state of an instance may not be noticed if the application has taken all samples.
    Subsequent instance state changes are only notified if all samples are taken.

    Consequently, it's very hard to receive notifications on disposal of instances.

    Requires data so applications should use read instead of take.
    But take is required for subsequent notifications.
    Applications are not notified on arrival of data if they choose not to take all data (read or take not all)

    Occasionally Application may need to react on disposal or the no writer state of instances e.g. cleanup allocated resources and applications may also continuously take all samples to save resources.

    In this case a dispose or no writer state will only be noticed if a new generation appears, which may never happen.
    Occasionally applications may want to keep all read samples and still be notified on data arrival.

    Applications should be notified whenever new data arrives whether they have taken all previous data samples or not
    According to the spec (section 2.1.2.5.3.8) it is possible to get 'meta samples' that is samples that have a SampleInfo but have no associated data, this can be used to notify of disposal, no writers and such.

    Proposed Resolution:
    Always reset the read communication status flag on any read or take operation.

    Provide a notification mechanism on the DataReader that specifies the instance handle of the instance whose state has changed.
    -> This is managed by the meta-sample mechanism mentioned above

    Provide a method on an instance handle to access the instance state.

    Modify figure 2-16 and section 2.1.4.2.2 to state that the ReadCommunicationStatus is reset to FALSE whenever the corresponding listener operation is called, or else if a read or take operation is called on the associated DataReader

    In addition the ON_DATA_ON_READERS status is reset if the on_data_available is called. The inverse (resetting the ON_DATA_AVAILABLE status when the on_data_on_readers is called) does not happen.

    Proposed Revised Text:

    Section 2.1.2.5 Subscription Module, Figure 2-10
    Add the following field to the SampleInfo class:
    valid_data : boolean

    Section 2.1.2.5.1 Access to the data (see attached document access_to_the_data2CMP.pdf for the resulting section with changes)

    >>Aftter 2nd paragraph "Each of these" add the section heading:
    2.1.2.5.1.1 Interpretation of the SampleInfo
    3rd paragraph; add the following bullet after the bullet that starts with "The instance_state of the related instance"
    The valid_data flag. This flag indicates whether there is data associated with the sample. Some samples do not contain data indicating only a change on the instance_state of the corresponding instance.

    >>Before the paragraph that starts with "For each sample received" add the section headings:
    2.1.2.5.1.2 Interpretation of the SampleInfo sample_state

    >>Before the paragraph that starts with "For each instance the middleware internally maintains" add the section heading:
    2.1.2.5.1.3 Interpretation of the SampleInfo instance_state

    >>Before the paragraph that starts with "For each instance the middleware internally maintains two counts: the disposed_generation_count and no_writers_generation_count" add the following subsections (2.1.2.5.1.4, and 2.1.2.5.1.5):

    2.1.2.5.1.4 Interpretation of the SampleInfo valid_data
    Normally each DataSample contains both a SampleInfo and some Data. However there are situations where a DataSample contains only the SampleInfo and does not have any associated data. This occurs when the Service notifies the application of a change of state for an intance that was caused by some internal mechanism (such as a timeout) for which there is no associated data. An example of this situation is when the Service detects that an instance has no writers and changes the coresponding instance_state to NOT_ALIVE_NO_WRITERS.

    The actual set of scenarios under which the middleware returns DataSamples containing no Data is implementation dependent. The application can distinguish wether a particular DataSample has data by examining the value of the valid_data flag. If this flag is set to TRUE, then the DataSample contains valid Data, if the flag is set to FALSE the DataSample contains no Data.
    To ensure corerctness and portability, the valid_data flag must be examined by the application prior to accessing the Data associated with the DataSample and if the flag is set to FALSE, the application should not access the Data associated with the DataSample, that is, teh application should access only the SampleInfo.

    2.1.2.5.1.5 Interpretation of the SampleInfo disposed_generation_count and no_writers_generation_count
    Before the paragraph that starts with "The sample_rank and generation_rank available in the SampleInfo are computed …" add the section heading:
    2.1.2.5.1.6 Interpretation of the SampleInfo sample_rank, generation_rank, and absolute_generation_rank

    >>Before the paragraph that starts with "These counters and ranks allow the application to distinguish" add the section heading:
    2.1.2.5.1.7 Interpretation of the SampleInfo counters and ranks

    >>Before the paragraph that starts with "For each instance (identified by the key), the middleware internally…" add the section heading:
    2.1.2.5.1.8 Interpretation of the SampleInfo view_state

    >>Before the paragraph that starts with "The application accesses data by means of the operations read or take on the DataReader" add the section heading:
    2.1.2.5.1.9 Data access patterns

    Section 2.1.2.5.5 Sample Info class

    Add another bullet to the list:
    The valid_data flag that indicates whether the DataSample contains data or else it is only used to communicate of a change in the instance_state of the instance.

    Section 2.2.3 DCPS PSM : IDL

    struct SampleInfo
    Add the following field at the end of the structure:
    boolean valid_data

    The resulting structure is:
    struct SampleInfo

    { SampleStateKind sample_state; ViewStateKind view_state; InstanceStateKind instance_state; Time_t source_timestamp; InstanceHandle_t instance_handle; InstanceHandle_t publication_handle; long disposed_generation_count; long no_writers_generation_count; long sample_rank; long generation_rank; long absolute_generation_rank; boolean valid_data; }

    ;
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in section 2.1.2.5.1

  • Key: DDS12-67
  • Legacy Issue Number: 9550
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    On page 2-65 the second last bullet states
    The sample_rank indicates the number or samples of the same instance that follow the current one in the collection.
    The 'or' should be 'of'.

    Proposed Resolution:

    Proposed Revised Text:
    Section 2.1.2.5.1 Access to the data, second to last bullet
    Replace 'or' with 'of' in the sentence:
    The sample_rank indicates the number or samples of the same instance that follow the current one in the collection.

    Resulting in:
    The sample_rank indicates the number of samples of the same instance that follow the current one in the collection.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Fix typo.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

instance resource can be reclaimed in READER_DATA_LIFECYCLE QoS section

  • Key: DDS12-71
  • Legacy Issue Number: 9554
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Clarification to when a instance resource can be reclaimed in READER_DATA_LIFECYCLE QoS section

    Summary:

    In Section 2.1.3.22 (READER_DATA_LIFECYCLE QoS) the fourth paragraph mention how "the DataReader can only reclaim all resources for instances that instance_state = NOT_ALIVE_NO_WRITERS and for which all samples have been 'taken'".
    This should be corrected to state "for instances for which all samples have been 'taken' and either instance_state = NOT_ALIVE_NO_WRITERS or instance_state = NOT_ALIVE_DISPOSED and there are no 'live' writers".
    In light of this the statement in the last paragraph stating that once the state becomes NOT_ALIVE_DISPOSED after the autopurge_disposed_samples_delay elapses, "the DataReader will purge all internal information regarding the instance; any untaken samples will also be lost" is not entirely true. If there are other 'live' writers, the DataReader will maintain the state on the instance of which DataWriters are writing to it.

    We should change the "will purge all" to "may purge all" or even "will purge". Alternatively, we could describe in further detail when it "will purge all", i.e. when there are no 'live' writers.

    The biggest thing here is to decide whether the instance lifecycle can end directly from the NOT_ALIVE_DISPOSED state (as Figure 2-11 currently states) or whether we must force it to go though the NOT_ALOVE_NO_WRITES; that is, in the case where the last writer unregisters a disposed instance do we transition to NOT_ALIVE_NO_WRITERS+NOT_ALIVE_DISPOSED or do we finish the lifecycle directly without notifying the user (as it is indicated now)

    We think the current behavior is better because from the application reader point of view, the instance does not exists once it DISPOSED, the fact that we keep the instance state such that we can retain ownership is a detail inside the middleware, so it would be unnatural to get a further indication that the instance (that it no longer knows about) has now no writers.

    We suggest the proposed changes should reflect this point of view.

    Proposed Resolution:

    Make the suggested corrections:

    (1) Correct when readers can claim resources to include NOT_ALIVE_DISPOSED state when there are no live writers. So we always reclaim when there are no writers and all the samples for that instance are taken; these samples will include a sentinel mata-sample with an instance state that will be either NOT_ALIVE_NO_WRITERS or NOT_ALIVE_DISPOSED

    (2) Clarify that the auto_purge_disposed samples removes only the samples, but not the instance; the instance will only removed in the above case.
    Proposed Revised Text:

    Section 2.1.3.22 READER_DATA_LIFECYCLE QoS

    Replace the paragraph:

    Under normal circumstances the DataReader can only reclaim all resources for instances that instance_state = NOT_ALIVE_NO_WRITERS and for which all samples have been 'taken.'

    With

    Under normal circumstances the DataReader can only reclaim all resources for instances for which there are no writers and for which all samples have been 'taken.' The last sample the DataReader will have taken for that instance will have an instance_state of either NOT_ALIVE_NO_WRITERS or NOT_ALIVE_DISPOSED depending on whether the last writer that had ownership of the instance disposed it or not. Refer to Figure 2-11 for a statechart describing the transitions possible for the instance_state.

    In the Paragraph starting with "The autopurge_nowriter_samples_delay defines.."
    Replace

    once its view_state becomes NOT_ALIVE_NO_WRITERS

    With

    once its instance_state becomes NOT_ALIVE_NO_WRITERS

    Replace the paragraph:

    The autopurge_disposed_samples_delay defines the maximum duration for which the DataReader will maintain information regarding an instance once its view_state becomes NOT_ALIVE_DISPOSED. After this time elapses, the DataReader will purge all internal information regarding the instance; any untaken samples will also be lost

    With

    The autopurge_disposed_samples_delay defines the maximum duration for which the DataReader will maintain samples for an instance once its instance_state becomes NOT_ALIVE_DISPOSED. After this time elapses, the DataReader will purge all samples for the instance.
  • Reported: DDS 1.1 — Thu, 6 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect description of enable precondition

  • Key: DDS12-62
  • Legacy Issue Number: 9544
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    In section 2.1.2.2.1. DomainParticipant Class it says:
    The following operations may be called even if the DomainParticipant is enabled. Other operations will have the value NOT_ENABLED if called on a disabled

    It should say:
    The following operations may be called even if the DomainParticipant is not enabled. Other operations will return the value NOT_ENABLED if called on a disabled

    Proposed Resolution:

    Proposed Revised Text:
    In section 2.1.2.2.1. DomainParticipant Class, paragraph at the end of the section before the bullet points

    Replace:
    The following operations may be called even if the DomainParticipant is enabled. Other operations will have the value NOT_ENABLED if called on a disabled

    With:
    The following operations may be called even if the DomainParticipant is not enabled. Other operations will return the value NOT_ENABLED if called on a disabled
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Perform the above change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Resetting of the statusflag during a listener callback

  • Key: DDS12-61
  • Legacy Issue Number: 9543
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    In section 2.1.4.2.1, it is explained that a statusflag becomes TRUE if a plain communication status changes, and becomes FALSE again each time the application accesses the plain communication status via the proper get_<plain_communication_status> operation. This is not a complete description, since it only assumes an explicit call to read the communication status. It is also possible (by attaching a Listener) to implicitly read the status (it is then passed as a parameter to the registered callback method), and then afterwards the status flag should also be set to FALSE as well.
    Furthermore, the Status table in section 2.4.1 mentions that all total_count_change fields are being reset when a Listener callback is performed. The same thing happens when a get_<plain_communication_status> operation is invoked. It would make sense that a Listener callback behaves in a similar way as an when explicitly reading the plain communication status.

    Proposed Resolution::
    Mention explicitly in section 2.1.4.2.1 that a status flag is also set to FALSE when a listener callback for that status has been performed. (We need to think what consequences this will have for NIL-Listeners, that behave like a no-op. Probably they should also reset the flag in that case.)

    Proposed Revised Text::

    In section 2.1.4.2.1 after the paragraph:
    For the plain communication status, the StatusChangedFlag flag is initially set to FALSE. It becomes TRUE whenever the plain communication status changes and it is reset to FALSE each time the application accesses the plain communication status via the proper get_<plain communication status> operation on the Entity.

    Add the paragraphs:

    The communication status is also reset to FALSE whenever the associated listener operation is called as the listener implicitly accesses the status which is passed as a parameter to the operation. The fact that the status is reset prior to calling the listener means that if the application calls the get_<plain communication status> from inside the listener it will see the status already reset.

    An exception to this rule is when the associated listener is the 'nil' listener. As described in section 2.1.4.3.1 the 'nil' listener is treaded as a NOOP and the act of calling the 'nil' listener does not reset the communication status.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the meaning of locally

  • Key: DDS12-64
  • Legacy Issue Number: 9546
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    On 2-94 section 2.1.2.5.5 (SampleInfo Class) the description of publication_handle states that it identifies locally the DataWriter that modified the instance.

    Clarify that locally means the instance_handle from the builtin Publication DataReader belonging to the Participant of the DataReader from which the sample is read.

    Proposed Resolution:

    Proposed Revised Text:

    In section 2.1.2.5.5 SampleInfo Class, replace the bullet:
    the publication_handle that identifies locally the DataWriter that modified the instance.

    With the bullet:
    the publication_handle that identifies locally the DataWriter that modified the instance. The publication_handle is the same InstanceHandle_t that is returned by the operation get_matched_publications on the DataReader and can also be used as a parameter to the DataReader operation get_matched_publication_data.

    In section 2.1.2.5.3.33 get_matched_publications after the first paragraph add the paragraph.
    The handles returned in the 'publication_handles' list are the ones that are used by the DDS implementation to locally identify the corresponding matched DataWriter. These handles match the ones that appear in the 'instance_handle' field of the SampleInfo when reading the "DCPSPublications" builtin topic.

    In section 2.1.2.5.3.33 get_matched_publications after the first paragraph add the paragraph:
    The handles returned in the 'subscription_handles' list are the ones that are used by the DDS implementation to locally identify the corresponding matched DataReader. These handles match the ones that appear in the 'instance_handle' field of the SampleInfo when reading the "DCPSSubscriptions" builtin topic.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Add the state clarification
  • Updated: Fri, 6 Mar 2015 20:58 GMT

invalid reference to delete_datareader

  • Key: DDS12-63
  • Legacy Issue Number: 9545
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    On page 2-70 at the end of section 2.1.2.5.2 (Subscriber Class) the description states that a list of operations including delete_datareader may return NOT_ENABLED. The operation delete_datareader should be removed from this list.

    Proposed Resolution:

    Proposed Revised Text:
    In section 2.1.2.5.2 Subscriber Class, at the end right before section 2.1.2.5.2.1 replace paragraph:

    All operations except for the base-class operations set_qos, get_qos, set_listener, get_listener, enable, get_statuscondition, create_datareader, and delete_datareader may return the value NOT_ENABLED.

    With:

    All operations except for the base-class operations set_qos, get_qos, set_listener, get_listener, enable, get_statuscondition, and create_datareader may return the value NOT_ENABLED.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Remove delete_datareader from said list
  • Updated: Fri, 6 Mar 2015 20:58 GMT

PIM and PSM contradicting wrt "get_sample_lost_status" operation

  • Key: DDS12-57
  • Legacy Issue Number: 9539
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    PIM and PSM are contradicting with respect to the "get_sample_lost_status" operation.

    Summary:
    According to the PIM in section 2.1.2.5.2(.12), the Subscriber class has got an operation called "get_sample_lost_status". According to the PSM in section 2.2.3, this operation is not part of the Subscriber, but of the DataReader.

    Proposed Resolution::
    Move the "get_sample_lost_status" operation in the PIM to the DataReader as well.
    RTI: We propose ewmoving this from the Subscriber altoguether and moving it to the DataReader.

    Proposed Revised Text::

    In the Subscriber table in section 2.1.2.5.2 Subscriber Class
    Remove the entry on the operation get_sample_lost_status()

    In the DataReader table in section section 2.1.2.5.3 DataReader Class
    Add the entry on the get_sample_lost_status() operation that was removed from the Subscriber class

    Add section 2.1.2.5.3.24, previous 2.1.2.5.3.24 becomes 2.1.2.5.3.25:
    2.1.2.5.3.24 get_sample_lost_status
    This operation allows access to the SAMPLE_LOST_STATUS communication status. Communication statuses are described in Section 2.1.4.1, "Communication Status," on page 2-125.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Move the operation from the Subscriber to the DataReader
  • Updated: Fri, 6 Mar 2015 20:58 GMT

PIM description of "get_domain_id" method is missing

  • Key: DDS12-56
  • Legacy Issue Number: 9538
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    In section 2.1.2.2.2, the "get_domain_id" method is mentioned in the table, but is not explained in the following sections.

    Proposed Resolution::
    Add a section that explains the "get_domain_id" method.

    Proposed Revised Text::
    Replace section 2.1.2.2.1.26 with the following one:

    2.1.2.2.1.26 get_domain_id
    This operation retrieves the domain_id used to create the DomainParticipant. The domain_id identifies the Domain to which the DomainParticipant belongs. As described in the introduction to Section 2.1.2.2.1 each Domain represents a separate data "communication plane" isolated from other domains.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Add a section that explains the "get_domain_id" method
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Illegal return value register_instance

  • Key: DDS12-66
  • Legacy Issue Number: 9549
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    In section 2.1.2.4.2.5 register_instance the description states that if this operation exceeds the max_blocking_time this operation will return TIMEOUT. However this is not possible because the operation cannot return a ReturnCode_t value.

    Proposed Resolution:

    Proposed Revised Text:

    Section section 2.1.2.4.2.5 register_instance
    At the end of the 5th paragraph Replace:
    If max_blocking_time elapses before the DataWriter is able to store the modification without exceeding the limits, the operation will fail and return TIMEOUT

    With:
    If max_blocking_time elapses before the DataWriter is able to store the modification without exceeding the limits, the operation will fail and return HANDLE_NIL
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    State that in this case the operation will return HANDLE_NIL instead
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing autopurge_disposed_sample_delay

  • Key: DDS12-65
  • Legacy Issue Number: 9548
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    In the QoS table for built-in Subscriber and DataReader objects (Section 2.1.5 Built-in Topics) the value for autopurge_disposed_sample_delay is missing.

    Proposed Resolution:

    Proposed Revised Text:
    In the UML figure in section 2.1.3 Supported QoS
    Class ReaderDataLifecycleQoS, Add the field:
    autopurge_disposed_sample_delay : Duration_t

    In section 2.1.5 Built-in Topics, QoS table, READER_DATA_LIFECYCLE row, add:
    autopurge_disposed_sample_delay = infinite
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Add the missing field.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent PIM/PSM for RETCODE_ILLEGAL_OPERATION

  • Key: DDS12-60
  • Legacy Issue Number: 9542
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:
    See also issue R#123 of our previous Issues document. (Addition of an IllegalOperation Errorcode). This issue has been solved on the PIM level, but the ReturnCode has not been added to the IDL PSM.

    Proposed Resolution::
    Add the RETCODE_ILLEGAL_OPERATION ReturnCode to the PSM in section 2.2.3.

    Proposed Revised Text::
    Section 2.2.3 DCPS PSM : IDL
    after the line "const ReturnCode_t RETCODE_NO_DATA = 11;" add the line:
    const ReturnCode_t RETCODE_ILLEGAL_OPERATION = 12;
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming consistencies in match statuses

  • Key: DDS12-21
  • Legacy Issue Number: 9498
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    For better naming consistency with other statuses, the PUBLICATION_MATCH_STATUS and SUBSCRIPTION_MATCH_STATUS may be renamed to PUBLICATION_MATCHED_STATUS and SUBSCRIPTION_MATCHED_STATUS. Also the get_publication_match_status and get_subscription_match_status operations may be renamed to get_publication_matched_status and get_subscription_matched_status.
    In addition the callback is named on_XXX_matched.

    Proposed Resolution:
    Rename PUBLICATION_MATCH_STATUS to PUBLICATION_MATCHED_STATUS, SUBSCRIPTION_MATCH_STATUS to SUBSCRIPTION_MATCHED_STATUS

    Proposed Revised Text:
    Section 2.1.2.4 Publication Module
    Figure 2-9; DataWriter class
    Rename
    get_publication_match_status()
    To
    get_publication_matched_status()

    Section 2.1.2.4.2 DataWriter Class
    DataWriter class table
    Rename
    get_publication_match_status()
    To
    get_publication_matched_status()

    Section 2.1.2.4.2.19 get_publication_match_status
    Rename section heading to:
    2.1.2.4.2.19 get_publication_matched_status

    Replace
    "allows access to the PUBLICATION_MATCH_QOS"
    With:
    "allows access to the PUBLICATION_MATCHED communication status "

    Section 2.1.2.5 Subscription Module
    Figure 2-9; DataReader class
    Rename
    get_subscription_match_status()
    To
    get_subscription_matched_status()

    Section 2.1.2.4.2 DataReader Class
    DataReader class table
    Rename
    get_subscription_match_status()
    To
    get_subscription_matched_status()

    Section 2.1.2.5.3.25 get_subscription_match_status
    Rename section heading to:
    2.1.2.5.3.25 get_subscription_matched_status

    Section 2.1.2.5.3.25 get_subscription_match_status
    Rename "SUBSCRIPTION_MATCH_STATUS" to "SUBSCRIPTION_MATCHED_STATUS"

    Section 2.1.4.4 Conditions and Wait-sets
    Figure 2-19; DataReader class
    Rename
    get_publication_match_status()
    To
    get_publication_matched_status()

    Section 2.1.4.1 Communication Status
    Communication status table replace:
    PUBLICATION_MATCH
    With
    PUBLICATION_MATCHED

    Communication status table replace:
    SUBSCRIPTION_MATCH
    With
    SUBSCRIPTION_MATCHED

    Section 2.2.3 DCPS PSM : IDL
    Status constants
    Replace:
    const StatusKind PUBLICATION_MATCH_STATUS = 0x0001 << 13;
    const StatusKind SUBSCRIPTION_MATCH_STATUS = 0x0001 << 14;
    With
    const StatusKind PUBLICATION_MATCHED_STATUS = 0x0001 << 13;
    const StatusKind SUBSCRIPTION_MATCHED_STATUS = 0x0001 << 14;

    interface DataWriter
    Replace:
    PublicationMatchedStatus get_publication_match_status();
    With
    PublicationMatchedStatus get_publication_matched_status();

    interface DataReader
    Replace:
    SubscriptionMatchedStatus get_subscription_match_status();
    With
    SubscriptionMatchedStatus get_subscription_matched_status();
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Description of set_default_XXX_qos()

  • Key: DDS12-20
  • Legacy Issue Number: 9497
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    For XXX = participant, topic, publisher, subscriber, and datareader, the specification states "in the case where the QoS policies are not explicitly specified".
    For XXX = datawriter, the specification states "in the case where the QoS policies are defaulted".
    The latter is technically more correct.

    Proposed Resolution:
    Use the wording in set_default_datawriter_qos().

    Proposed Revised Text:
    Section 2.1.2.2.1.20 set_default_publisher_qos
    First paragraph replace:
    in the case where the QoS policies are not explicitly specified
    With
    in the case where the QoS policies are defaulted

    Section 2.1.2.2.1.21 get_default_publisher_qos
    First paragraph replace:
    in the case where the QoS policies are not explicitly specified
    With
    in the case where the QoS policies are defaulted

    Section 2.1.2.2.1.22 set_default_subscriber_qos
    First paragraph replace:
    in the case where the QoS policies are not explicitly specified
    With
    in the case where the QoS policies are defaulted

    Section 2.1.2.2.1.23 get_default_subscriber_qos
    First paragraph replace:
    in the case where the QoS policies are not explicitly specified
    With
    in the case where the QoS policies are defaulted

    Section 2.1.2.2.1.24 set_default_topic_qos
    First paragraph replace:
    in the case where the QoS policies are not explicitly specified
    With
    in the case where the QoS policies are defaulted

    Section 2.1.2.2.1.25 get_default_topic_qos
    First paragraph replace:
    in the case where the QoS policies are not explicitly specified
    With
    in the case where the QoS policies are defaulted

    Section 2.1.2.2.2.5 set_default_participant_qos
    First paragraph replace:
    in the case where the QoS policies are not explicitly specified
    With
    in the case where the QoS policies are defaulted

    Section 2.1.2.2.2.6 get_default_participant_qos
    First paragraph replace:
    in the case where the QoS policies are not explicitly specified
    With
    in the case where the QoS policies are defaulted

    Section 2.1.2.4.1.16 get_default_datawriter_qos
    First paragraph replace:
    in the case where the QoS policies are not explicitly specified
    With
    in the case where the QoS policies are defaulted

    Section 2.1.2.5.2.15 set_default_datareader_qos
    First paragraph replace:
    in the case where the QoS policies are not explicitly specified
    With
    in the case where the QoS policies are defaulted

    Section 2.1.2.5.2.16 get_default_datareader_qos
    First paragraph replace:
    in the case where the QoS policies are not explicitly specified
    With
    in the case where the QoS policies are defaulted
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Use the wording in set_default_datawriter_qos().
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should write() block when out of instance resources?

  • Key: DDS12-19
  • Legacy Issue Number: 9496
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently it is stated that write() and dispose() may block and return TIMEOUT when the RELIABILITY QoS kind is set to RELIABLE and any of the RESOURCE_LIMITS QoS is hit.
    We should reconsider the action taken when it is instance resource limits that are hit. If instance resources are kept around until they are unregistered (and not even yet considering how RELIABILITY or DURABILITY QoS affects this), then it seems awkward to block when the user is required to take action. Perhaps returning immediately with OUT_OF_RESOURCES makes more sense in this situation.

    Proposed Resolution:
    When the writer is out of instance resources because all max_instances have been registered or written, the write/dispose() call will return OUT_OF_RESOURCES instead of blocking if it can be detected.

    Proposed Revised Text:

    Section 2.1.2.4.2.11 write
    Above the paragraph starting with "In case the provided handle is valid"; add the paragraph:
    Instead of blocking, the write operation is allowed to return immediately with the error code OUT_OF_RESOURCES provided the following two conditions are met:
    1. The reason for blocking would be that the RESOURCE_LIMITS are exceeded.
    2. The service determines that waiting the 'max_waiting_time' has no chance of freeing the necessary resources. For example, if the only way to gain the necessary resources would be for the user to unregister an instance.

    Section 2.1.2.4.2.12 write_w_timestamp
    After the paragraph "This operation may block" add the paragraph:
    This operation may return OUT_OF_RESOURCES under the same circumstances described for the write operation (Section 2.1.2.4.2.11).

    Section 2.1.2.4.2.13 dispose
    After the paragraph "This operation may block…" add the paragraph:
    This operation may return OUT_OF_RESOURCES under the same circumstances described for the write operation (Section 2.1.2.4.2.11).

    Section 2.1.2.4.2.14 dispose_w_timestamp
    After the paragraph "This operation may block…" add the paragraph:
    This operation may return OUT_OF_RESOURCES under the same circumstances described for the write operation (Section 2.1.2.4.2.11).

    Section 2.1.2.4.2.14 dispose_w_timestamp
    After the paragraph "This operation may block…" add the paragraph:
    This operation may return OUT_OF_RESOURCES under the same circumstances described for the write operation (Section 2.1.2.4.2.11).

    Section 2.1.2.4.2.5 register

    Replace the paragraph:
    This operation may block if the RELIABILITY kind is set to RELIABLE and the modification would cause data to be lost or else cause one of the limits specified in the RESOURCE_LIMITS to be exceeded. Under these circumstances, the RELIABILITY max_blocking_time configures the maximum time the write operation may block (waiting for space to become available). If max_blocking_time elapses before the DataWriter is able to store the modification without exceeding the limits, the operation will fail and return TIMEOUT.

    With:
    This operation may block and return TIMEOUT under the same circumstances described for the write operation (Section 2.1.2.4.2.11).
    This operation may return OUT_OF_RESOURCES under the same circumstances described for the write operation (Section 2.1.2.4.2.11).

    Section 2.1.2.4.2.5 register_w_timestamp

    Replace the paragraph:
    This operation may block and return TIMEOUT under the same circumstances described for the register_instance operation (Section 2.1.2.4.2.5 ).
    With:
    This operation may block and return TIMEOUT under the same circumstances described for the write operation (Section 2.1.2.4.2.11).
    This operation may return OUT_OF_RESOURCES under the same circumstances described for the write operation (Section 2.1.2.4.2.11).
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify ownership with same-strength writers

  • Key: DDS12-18
  • Legacy Issue Number: 9495
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:
    In Section 2.1.3.9 in the paragraph dealing with when there are multiple same-strength writers, the next to last sentence describes that the owner must remain the same until one of several conditions are met.
    The condition where "a new DataWriter with the same strength that should be deemed the owner according to the policy of the Service" should be explicitly mentioned although it may have been implied.

    Proposed Resolution:
    Add the explicit mention of the additional condition above.

    Proposed Revised Text:

    Section 2.1.3.9.2 EXCLUSIVE kind

    5th paragraph; replace the sentence:
    It is also required that the owner remains the same until there is a change in strength, liveliness, the owner misses a deadline on the instance, or a new DataWriter with higher strength modifies the instance.

    With:
    It is also required that the owner remains the same until there is a change in strength, liveliness, the owner misses a deadline on the instance, a new DataWriter with higher strength modifies the instance, or a new owner with the same strength that is deemed by the Service to be the owner modifies the instance.
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Add the explicit mention of the additional condition above.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming of filter_parameters concerning ContentFilteredTopic

  • Key: DDS12-12
  • Legacy Issue Number: 9489
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The method name is get/set_expression_parameters() whereas the parameter passed in is the "filter_parameters". Understandably the full name is filter expression parameters since the ContentFilteredTopic has a "filter_expression" attribute.
    Compare this with the MultiTopic which has the same named methods which take in "expression_parameters" and has a "subscription_expression" attribute.
    The name "filter_parameters" is also used in the create_contentfilteredtopic() method on the DomainParticipant.

    Proposed Resolution:
    Change the name of "filter_parameters" to "expression_parameters" for more consistency.

    Proposed Revised Text:

    Section 2.1.2.2.1 DomainParticipant Class; DomainParticipant class table
    On the row describing the operation "create_contentfilteredtopic"
    Replace parameter name "filter_ parameters"
    With parameter name "expression_ parameters"

    Section 2.1.2.2.1.7 create_contentfilteredtopic
    Last paragraph replace "filter_ parameters" with "expression_ parameters"

    Section 2.1.2.3.3 ContentFilteredTopic Class; ContentFilteredTopic class table
    On the row describing the operation "set_expression_parameters"
    Replace parameter name "filter_ parameters"
    With parameter name "expression_ parameters"

    Section 2.1.2.3.3 ContentFilteredTopic Class
    On the second bullet towards the end of the section:
    Replace "filter_ parameters" with "expression_ parameters"
    On the last paragraph just above section 2.1.2.3.3.1:
    Replace "filter_ parameters" with "expression_ parameters"

    Section 2.1.2.3.3.3 get_expression_parameters
    On the first paragraph:
    Replace "filter_ parameters" with "expression_ parameters"

    Section 2.1.2.3.3.4 set_expression_parameters
    On the first paragraph:
    Replace "filter_ parameters" with "expression_ parameters"

    Section 2.2.3 DCPS PSM : IDL
    interface DomainParticipant
    On the operation create_contentfilteredtopic
    Replace formal parameter name "filter_ parameters" with "expression_ parameters"
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos in built-in topic table

  • Key: DDS12-11
  • Legacy Issue Number: 9488
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:
    In the table in Section 2.1.5, for both the DCPSPublication and DCPSSubscription there is a typo in that "ownershiph" should be "ownership".
    Also, the destination_order row in the DCPSPublication should be of type "DesinationOrderQosPolicy" and not "QosPolicy".
    Also, the presentation row in the DCPSPublication should be of type "PresentationQosPolicy" and not "DestinationOrderQosPolicy".
    Also, in the paragraph at the top of the page containing the table there is a typo where "crated" should be "created".

    Proposed Resolution:
    Fix the typos.

    Proposed Revised Text:

    Section 2.1.5, 2 paragraphs above the Builtin-Topic table; at the end of the paragraph:
    Replace "crated" with "created" in the sentence:
    "application that crated them."

    Section 2.1.5 Builtin-Topic table;
    Replace DCPSPublication fieldname 'ownershiph' with 'ownership'
    Replace DCPSSubscription fieldname 'ownershiph' with 'ownership'
    Replace the type of the DCPSPublication, destination_order field from 'QosPolicy" to "DestinationOrderQosPolicy"
    Replace the type of the DCPSPublication presentation field from 'DestinationOrderQosPolicy" to "PresentationQosPolicy
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Fix the typos
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify PARTITION QoS and its default value

  • Key: DDS12-10
  • Legacy Issue Number: 9487
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:
    In the table in Section 2.1.3, the default partition value is said to be a zero-length sequence, which "is equivalent to a sequence containing a single element consisting of an empty string", which will match any partition. However, if an empty string will match any partition, it is not consistent with normal regular expression matching.

    Proposed Resolution:
    It is desirable to have the behavior in that if a special partition is specified, it will only match others who have that special partition. If the default behavior is that it will match all partitions, there is no way for a newly created entity to prevent others from matching it, unless the special partition is used.
    Therefore, we should not overload the meaning of the empty string to mean matching everything. Instead, the empty string is the default partition. An empty partition sequence or a partition sequence that consists of wildcards only will automatically be assumed to be in the default empty string partition.

    Proposed Revised Text:

    Section 2.1.3 Supported QoS PARTITION Table
    On the "Meaning" Column for the PARTITION QoS;

    Replace the following paragraph:

    The default value is an empty (zero-length) sequence. This is treated as a special value that matches any partition. And is equivalent to a sequence containing a single element consisting of the empty string.

    With

    The empty string ("") is considered a valid partition that is matched with other partition names using the same rules of string matching and regular-expression matching used for any other partition name (see Section 2.1.3.13)
    The default value for the PARTITION QoS is a zero-length sequence. The zero-length sequence is treated as a special value equivalent to a sequence containing a single element consisting of the empty string.
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Blocking of write() call

  • Key: DDS12-9
  • Legacy Issue Number: 9486
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Blocking of write() call depending on RESOURCE_LIMITS, HISTORY, and RELIABILITY QoS

    Summary:
    Section 2.1.2.4.2.11 states that even writers with KEEP_LAST HISTORY QoS can block and describes some scenarios.
    Some of these scenarios may no longer be valid depending on whether the implementation is willing to sacrifice reliability.

    In the table in Section 2.1.3, it states the max_blocking _time in the RELIABILITY QoS only applies for RELIABLE and KEEP_ALL HISTORY QoS.
    In Section 2.1.3.14 it is only mentioned that the writer can block if the RELIABILITY QoS is set to RELIABLE.

    Proposed Resolution:
    At the very least, remove mention of the requirement that the HISTORY QoS be KEEP_ALL for blocking to apply in the table in Section 2.1.3.

    Proposed Revised Text:

    Section 2.1.3 QoS Table
    On the entry for the RELIABILITY QoS max_blocking_time
    Replace:
    This setting applies only to the case where kind=RELIABLE and the HISTORY is KEEP_ALL.
    With:
    This setting applies only to the case where kind=RELIABLE.
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos in PIM sections

  • Key: DDS12-17
  • Legacy Issue Number: 9494
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:
    In Section 2.1.2.4.1.10 (begin_coherent_changes) there is a typo in the last sentence of the section where "if may be useful" should be "it may be useful".
    In the second paragraph of Section 2.1.2.2.2.4 (lookup_participant) there is a typo where "multiple DomainParticipant" should be "multiple DomainParticipants".

    Proposed Resolution:
    Make the suggested corrections.

    Proposed Revised Text:

    Section 2.1.2.4.1.10 begin_coherent_changes
    Last sentence, replace:
    "if may be useful"
    With
    "it may be useful"

    Section 2.1.2.2.2.4 lookup_participant
    Second paragraph replace
    "If multiple DomainParticipant belonging"
    With
    "If multiple DomainParticipant entities belonging"
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos in QoS sections

  • Key: DDS12-16
  • Legacy Issue Number: 9493
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:
    In Section 2.1.3.11 (LIVELINESS QoS) the second condition for compatibility uses "=<" for less than or equal to where "<=" might be more readable.
    Also, the last paragraph states "equal or greater to" where "equal or greater than" might be more readable.
    In next to last paragraph of Section 2.1.3.14 (RELIABILITY QoS), there is a typo where "change form a newer value" should be "change from a newer value".
    In Section 2.1.3.22 (READER_DATA_LIFECYCLE QoS) the last two paragraphs mention how "view_state becomes NOT_ALIVE_xxx" where it should be the "instance_state".

    Proposed Resolution:
    Make the aforementioned changes

    Proposed Revised Text:

    Section 2.1.3.11 LIVELINESS
    Second bullet in the enumeration near the end of the section:
    Replace "offered lease_duration =< requested lease_duration"
    With "offered lease_duration <= requested lease_duration"

    Section 2.1.3.11 LIVELINESS
    Last paragraph; replace:
    "Service with a time-granularity equal or greater to the lease_duration."
    With:
    "Service with a time-granularity greater or equal to the lease_duration."

    Section 2.1.3.14 RELIABILITY
    Next to last paragraph. Raplace:
    "change form a newer value"
    With:
    "change from a newer value".

    Section 2.1.3.22 READER_DATA_LIFECYCLE
    Paragraph before the last
    Replace "view_state" with "inatance_state" in:
    "maintain information regarding an instance once its view_state becomes NOT_ALIVE_NO_WRITERS."

    Section 2.1.3.22 READER_DATA_LIFECYCLE
    Last paragraph:
    Replace "view_state" with "inatance_state" in:
    "maintain information regarding an instance once its view_state becomes NOT_ALIVE_DISPOSED."
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Fix the typos.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consistency between RESOURCE_LIMITS QoS policies

  • Key: DDS12-8
  • Legacy Issue Number: 9485
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:
    In the description of the TIME_BASED_FILTER QoS, we are missing the description of the consistency requirements with the DEADLINE QoS, which is mentioned in the table in Section 2.1.3.
    Also, we should mention some consistency requirements between max_samples and max_samples_per_instance within the RESOURCE_LIMITS QoS.

    Proposed Resolution:
    In Section 2.1.3.12 on the TIME_BASED_FILTER QoS we should make explicit mention that the minimum_separation must be <= the period of the DEADLINE QoS.
    In both the table in Section 2.1.3 and in Section 2.1.3.22 on the RESOURCE_LIMITS QoS we should mention the consistency requirements that max_samples >= max_samples_per_instance.

    Proposed Revised Text:

    Section 2.1.3.12 TIME_BASED_FILTER;
    Add the following paragraph to the end of the section:

    The setting of the TIME_BASED_FILTER policy must be set consistently with that of the DEADLINE policy. For these two policies to be consistent the settings must be such that "deadline period>= minimum_separation." An attempt to set these policies in an inconsistent manner will cause the INCONSISTENT_POLICY status to change and any associated Listeners/WaitSets to be triggered.

    Section 2.1.3.22 RESOURCE_LIMITS
    Add the following paragraph before the last paragraph in the section:

    The setting of RESOURCE_LIMITS max_samples must be consistent with the setting of the max_samples_per_instance. For these two values to be consistent they must verify that max_samples >= max_samples_per_instance.

    Section 2.1.3.22 RESOURCE_LIMITS
    Add the following paragraph at the end of the section:

    An attempt to set these policies in an inconsistent manner will cause the INCONSISTENT_POLICY status to change and any associated Listeners/WaitSets to be triggered.
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect mention of INCONSISTENT_POLICY status

  • Key: DDS12-15
  • Legacy Issue Number: 9492
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:
    In Section 2.1.3.7 concerning the DEADLINE QoS, it is stated that if the QoS is set inconsistently, i.e. period is < minimum_separation of the TIME_BASED_FILTER QoS, the INCONSISTENT_POLICY status will change and any associated Listeners/WaitSets will be triggered.
    There is no such status. Instead the set_qos() operation will error with return code INCONSISTENT_POLICY.

    Proposed Resolution:
    Mention the return code instead.

    Proposed Revised Text:

    Section 2.1.3.7 DEADLINE
    Remove the last sentence in the section:
    "An attempt to set these policies in
    an inconsistent manner will cause the INCONSISTENT_POLICY status to change and any associated Listeners/WaitSets to be triggered."
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Mention the return code instead
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compatible versus consistency when talking about QosPolicy

  • Key: DDS12-14
  • Legacy Issue Number: 9491
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In the third paragraph of Section 2.1.3, it is stated that "some QosPolicy values may not be compatible with other ones". In this context we are really talking about the consistency of related QosPolicies as compatibility is already a concept concerning requested/offered semantics.

    Proposed Resolution:
    Reword the sentence to use the term "consistency" which is already used later in the paragraph.

    Proposed Revised Text:

    Section 2.1.3 Supported QoS
    3rd paragraph
    Replace "compatible" with "consistent" in the sentence:
    "Some QosPolicy values may not be compatible with other ones."
    Resulting in:
    "Some QosPolicy values may not be consistent with other ones."
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

OWNERSHIP_STRENGTH QoS is not a QoS on built-in Subscriber of DataReaders

  • Key: DDS12-7
  • Legacy Issue Number: 9484
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:
    The OWNERSHIP_STRENGTH QoS only applies to DataWriters, yet it is listed in the table of the QoS of the built-in Subscriber and DataReader objects in Section 2.1.5.

    Proposed Resolution:
    Remove OWNERSHIP_STRENGTH from the aforementioned table.

    Proposed Revised Text:

    Section 2.1.5
    In the table that follows the sentence:
    The QoS of the built-in Subscriber and DataReader objects is given by the following table:
    Remove the row for 'OWNERSHIP_STRENGTH'
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Remove OWNERSHIP_STRENGTH from the aforementioned table
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent naming in SampleRejectedStatusKind

  • Key: DDS12-6
  • Legacy Issue Number: 9483
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:
    We have REJECTED_BY_SAMPLES_LIMIT which comes from the max_samples in the ResourceLimitsQosPolicy.
    However, we have REJECTED_BY_INSTANCE_LIMIT which comes from the max_instances.

    Proposed Resolution:
    It should be named REJECTED_BY_INSTANCES_LIMIT.

    Proposed Revised Text:

    Section 2.2.3 DCPS PSM : IDL
    enum SampleRejectedStatusKind; Replace
    REJECTED_BY_INSTANCE_LIMIT
    With
    REJECTED_BY_INSTANCES_LIMIT
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    It should be named REJECTED_BY_INSTANCES_LIMIT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorect prototype for FooDataWriter method register_instance_w_timestamp()

  • Key: DDS12-13
  • Legacy Issue Number: 9490
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Incorrect prototype for the FooDataWriter method register_instance_w_timestamp() in the PSM

    Summary:
    The handle is incorrectly a parameter when it is already the return.

    Proposed Resolution:
    Remove the incorrect handle parameter.

    Proposed Revised Text:

    Section 2.2.3 DCPS PSM : IDL
    interface FooDataWriter
    On the register_instance_w_timestamp remove the parameter
    "in DDS::InstanceHandle_t handle,"

    The resulting operation is:
    DDS::InstanceHandle_t register_instance_w_timestamp(in Foo instance_data, in DDS::Time_t source_timestamp);
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Remove the incorrect handle parameter.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-87 Clarify_Topic_deletion_as_local_concept

  • Key: DDS-56
  • Legacy Issue Number: 6762
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.2.1.11 indicates that topics can be made globally
    available. So "creation" can have a global effect.

    It is not clear therefore whether deletion of a Topic also has a
    global effect.

    **PROPOSAL**

    Add to that paragraph in section 2.1.2.2.1.11. "In any case
    delete_topic deletes only the local proxy.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-20 Semantics_of_factory_delete_methods

  • Key: DDS-55
  • Legacy Issue Number: 6761
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not state what happens if the application tries
    to use an entity after it has been deleted by means of the
    corresponding "delete" operation on the factory. This is specially
    relevant in languages such as Java (or C++ when using the "var" types)
    that automatically maintain reference counts. Is the deletion delayed
    until the last reference is release?

    **PROPOSAL**

    Modify section 2.1.1.1 and ad the return code
    ALREADY_DELETED. Similarly add the "const ReturnCode_t RETCODE_
    ALREADY_DELETED = 9" to the IDL in section 2.2.3

    State that it is an error for the application to use an entity after
    it has been deleted. Also state that, in general the result is
    unspecified and may depend on the implementation or the PSM. Also
    state that in the cases where the implementation can detect this, the
    operation that uses the deleted entity should return RETCODE_
    ALREADY_DELETED (e.g. calling DataWriter::write on a data writer that
    has been deleted).
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Delete dependencies and semantics

  • Key: DDS-54
  • Legacy Issue Number: 6760
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Delete dependencies and semantics

    ***Ref-19 Delete_dependencies

    Delete operations on Entities are only allowed if all other Entities
    which have dependencies with it have been deleted first (for example,
    a Topic may not be deleted before all other Entities depending on this
    Topic have been deleted first)

    The specification does not explain what happens if an application
    tries to delete an entity that has dependent or contained entities.

    This applies to Sections: 2.1.2.2.1.2, 2.1.2.2.1.4, 2.1.2.2.1.6,
    2.1.2.2.1.8, 2.1.2.2.1.10, and 2.1.2.2.2.2.

    Given that Topic object can be obtained by means of the
    DomainParticipant::create_topic operation as well as the
    DomainParticipant::lookup_topic operation there is an ambiguity
    regarding the deletion of Topic objects prior to deleting the
    DomainParticipant. Should the application call delete just on the ones
    it obtained by means of "create_topic" or also on the ones obtained by
    means of "lookup_topic"

    **PROPOSAL**

    State that if said "delete" operations are called while there are
    dependent or contained entities the operation will fail and return
    PRECONDITION_NOT_MET.

    Fix by adding get_datareader() operation to the ReadCondition. This
    operation should take no arguments and return a DataReader

    Also state that the application should also delete the Topic obtained
    by means of lookup_topic as this is needed to remote the local
    resources devoted to it.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-22 Automatic_deletion_of_contained_entities

  • Key: DDS-58
  • Legacy Issue Number: 6764
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification describes that an entity cannot be deleted if it has
    contained entities. That is: Cannot delete Publisher if local
    datawriters. Cannot delete Pubscriber if local datareaders. Cannot
    delete DomainParticipant if any Topics, Publishers, Subscribers.

    However manually deleting all contained entities is cumbersome in the
    case in which the application is trying to do so as is the case when
    shutting down.

    **PROPOSAL**

    Add the operation "ReturnCode_t delete_contained_entities()" to
    DomainParticipant, Publisher, and Subscriber.

    This operation will return all contained entities and leave the system
    in a state that allows the application to delete the container. This
    affects sections 2.1.2.2.1, 2.1.2.4.1, 2.1.2.5.2, and 2.2.3 (IDL)
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-151 No_locally_duplicate_topics

  • Key: DDS-57
  • Legacy Issue Number: 6763
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not state what happens if the applcation
    attempts to create multiple times a Topic with the same name

    **PROPOSAL**

    In section 2.1.2.2.1.5 state that calling create_topic muiltiple times
    behaves as doing a lookup first with no timeout and if a Topic is
    found then it compares the data-type & the qos specified as parameters
    with those of the existing Topic.

    State that if the comparison fails, than the operation return
    PRECONDITION_FAILED.

    State that if the lookup and comparison succeed then the reference
    count to the Topic should be incremented such that the application
    must call delete_topic as many times as it called create_topic and
    directly lookup_topic for the local proxy to be deleted.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Single waitset attached to condition

  • Key: DDS-60
  • Legacy Issue Number: 6766
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-27 Single_waitset_attachement_to_condition

    Section 2.1.2.1. Why can only one "WaitSet" be associated with a
    "Condition". This contradicts figure 2-7 and figure 2-9.

    This seems too limiting. When this is combined with the fact that each
    entity has a single status condition we end up in a situation where
    one thread can wait on an entity changing states.

    **PROPOSAL**

    Correct section 2.1.2.1 and figure 2-5 to indicate that it is possible
    to attach the same condition to multiple waitsets
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-15 Behavior_on_deletion_from_wrong_factory

  • Key: DDS-59
  • Legacy Issue Number: 6765
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not mention what to do when an entity is passed
    to a delete method in a factory object, for which that factory object
    is not owner? (For example a DataWriter is passed to the
    delete_datawriter method of Publisher A, while it was created in
    Publisher B.)

    This applies to Sections: 2.1.2.2.1.2, 2.1.2.2.1.4, 2.1.2.2.1.6,
    2.1.2.2.1.8, 2.1.2.2.1.10, 2.1.2.4.1.6, 2.1.2.5.2.6, and 2.1.2.5.3.7

    **PROPOSAL**

    State that if said "delete" operations are called passing the wrong
    factory, the operation shall fail and return PRECONDITION_NOT_MET.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-36 Entity_specialization_set_get_qos

  • Key: DDS-62
  • Legacy Issue Number: 6768
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification shows these operations as being abstract on the
    base-class (Entity) and says that it will be overridden by each
    specialization (Section 2.1.2.1.1.3). This is consistent with the PSM.

    However, the get_listener/set_ listener operations are not mentioned
    in the tables and text that that describe the DomainParticipant
    (section 2.1.2.2.1.

    Also for the specialized Entity classes, the operations are not
    mantioned on the class table but do appear in the text that describes
    the table. This applies to DomainParticipant (section 2.1.2.2.1),
    Topic (section 2.1.2.3.2), Publisher (section 2.1.2.4.1), DataWriter
    (section 2.1.2.4.2), Subscriber (section 2.1.2.5.2), and DataReader
    (section 2.1.2.5.3.

    **PROPOSAL**

    In order to avoid ambiguity, the get_listener/set_listener operation
    should appear explicitly in all the aforementioned sections.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Entity specialization of set/get qos/listener

  • Key: DDS-61
  • Legacy Issue Number: 6767
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-35 Entity_specialization_set_get_qos

    The specification shows this operation as being abstract on the
    base-class (Entity) and says that it will be overridden by each
    specialization (Section 2.1.2.1.1.2). This is consistent with the PSM.

    However, the get_qos/set_qos operations are not mentioned in the
    tables and text that that describe the DomainParticipant (section
    2.1.2.2.1.

    Also for the specialized Entity classes, the operations are not
    mantioned on the class table but do appear in the text that describes
    the table. This applies to Topic (section 2.1.2.3.2), Publisher
    (section 2.1.2.4.1), DataWriter (section 2.1.2.4.2), Subscriber
    (section 2.1.2.5.2), and DataReader (section 2.1.2.5.3).

    **PROPOSAL**

    In order to avoid ambiguity, the get_qos/set_qos operation should
    appear explicitly in all the aforementioned sections.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-39 Entity_specialization_set_get_qos

  • Key: DDS-64
  • Legacy Issue Number: 6770
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.2.1. DomainParticipant class table defines an operation
    called delete_contentfilteredtopic. This operation is named
    inconsistently in the IDL PSM (section 2.2.3) where it appears as
    delete_contentfiltered in the IDL PSM.

    **PROPOSAL**

    Change the name of the operation in the IDL to
    delete_contentfilteredtopic.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistencies between PIM and PSM/IDL

  • Key: DDS-63
  • Legacy Issue Number: 6769
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    ***Ref-38 DomainParticipant_domainId

    Section 2.1.2.2.1. DomainParticipant class table. The attribute
    domainId is not mentioned although mentioned in the IDL PSM.

    **PROPOSAL**

    Correct PIM.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Attributes_on_a_topic_description

  • Key: DDS-30
  • Legacy Issue Number: 6730
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Attributes_on_a_topic_description Issue [Boeing SOSCOE] ? Some use-cases need more control on association of DataReader and DataWriters beyond the control offered by means of the Topic ? For example, SOSCOE may need to add a layer on top of the DDS API to offer additional customized services to the applications that sit on top. These services may include the propagation of identity-certificates, security, dynamic selection of the “best” DataWriter to use for a given Topic, etc. ? These mechanisms would like to benefit from the propagation of Topics and QoS that DDS offers and extend that mechanism with additional information that can then be used by the SOSCOE layer to provide these additional services. ? However the matching that DDS offers is performed only on the topic name. It would be useful to have a more extensible mechanism to allow matching on other application-defined attributes. ? These attributes are an expansion of the topic_name that appears in the TopicDescription. In addition to the string (topic_name) we could have a set of attribute-name/value pairs that could then be used to match the writers with readers. In a sense the topic_name would be a singular, mandatory attribute used for matching but they could be others. ? These attributes are not mutable. ? SOSCOE has created a provider property class that allows applications to have attributes with typed values; it becomes a triplet (name, type, value). Currently the “type” only supports simple types, but the intent is to extend it to well-known structured types. ? For example, the Topic “weather data” would describe a general topic but there may be an attribute that describes the region (e.g. “North America”) and the subscriber can specify they want weather-data but only over “North America” Proposal [Boeing SOSCOE] ? One approach would be to add a set of “name-value” attributes to the TopicDescription. Matching would be done not only on the topic-name but also on the remaining attributes. In a sense, the topic name is just one of the attributes that must be matched between the Topic that is published and that which is subscribed.

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Additional_communication_paradigms

  • Key: DDS-29
  • Legacy Issue Number: 6729
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2010 Additional_communication_paradigms Issue [Boeing SOSCOE] ? In addition to the Data-Distribution model, our applications also need two basic communication models; Point2Point and GroupCommunications. ? The API’s and PIM defined in DDS would fit well with those communication models as well. That is, the concept of typed DataReaders and DataWriters that are configured by means of QoS and interact with the user-level application by means of listeners and conditions are all applicable to Point2Point and GroupCommunications. ? It would therefore be useful to introduce extensions such that the application can use these additional communication models in a way that fits naturally with the data-distribution PIM. ? In Boeing SOSCOE’s applications Point2Point communications: • Represent 1-to-1 bi-directional communication channels similar to UNIX “pipes” that can be configured by means of QoS • Are “connection-oriented” in the sense that each endpoint must explicitly establish the “connection” and is made aware if the “connection” is broken • Allow the application to read-write typed data to the other end-point. Each “writer” in one side of the connection communicates with the corresponding “reader” at the other end. In general each writer must be matched by a reader at the opposite end. Otherwise it is a configuration error. • Allow prioritization among the data written by different writers by means of QoS • Allow both synchronous and asynchronous writes. • Support the concept of application-level acknowledgements or “transactional” messaging by which the writing application can receive notification that the reading application has received the message and has positively acted on it. • Support the classic “client-connect versus server-listen/accept” pattern such that the “server” side can establish multiple dedicated point-to-point connections to each “client” that requests a connection. • Filters are not generally expected to be required for Point2Point communications. However, in order to keep the same API they should be allowed. The middleware should automatically give positive acknowledgement of reliable or transactional data that has been filtered out. • It is an error for a data-writer to write a Topic that does not have a corresponding data-reader. The writer() call should return a special error code indication there is no matching DataReader. In Boeing SOSCOE’s applications GroupCommunications : • Provide the capability for a group of peer applications to organize themselves into a “group”, such that each member of the group is aware of the presence of all other members and can send messages directed to either one specific peer, all the peers in the group, or a subset of the members of the group. • Provide some means to control group membership. • Each member of the group is identified by some “ID” such that other members can refer to it and direct messages to it. • Provide a serialized view of membership and delivery of messages such that: • The writer knows the membership when it sends each message and anybody that does not belong to that membership will not get the message. • All members of the group have the same view of the membership for each message delivered to them. • Do not need to provide total order or even agreed order. • Act as a “live” group in that messages are only delivered to the members that are present when the message is sent. In other words, it does not store messages on behalf of future members of the group • It is OK to write a DataWriter that does not have a corresponding DataReader on some of the other Group members. The data is considered acknowledged for RELIABLE but not for the purpose of TRANSACTIONAL (ref issue# 2060). Proposal [Boeing SOSCOE] ? Consider introducing a more primitive concept for a group of endpoints, from which the following classes derive: Publisher, Subscriber, EndpointConnector, and GroupConnector. ? This base class could be called “Connector” but does not really mean a “connection” in the “TCP” sense, rather the “connectivity” into the middleware services. ? All these “Connectors” act as factories for DataReader and DataWriter entities (which represent the Endpoints). ? The type of the DataReader and DataWriter created from each kind of “Connector” is the same (even though they will act differently). This is because the DataReader and DataWriter are typed facades to write a specific data-type and it is not desirable to have to create (by means of implied IDL) different types for each kind of connector. ? The EndpointConnectors and GroupConnectors are informed of the connections/disconnections by means of Listeners with an “onConnect” and “onDisconnect” operations. ? For Point2Point communication the factory of DataReader and DataWriter entities would be the EndpointConnector • To match the two EndpointConnector objects that should be “hooked up” the application could use either a Topic, or a more general matching of “Attibute-value” pairs, or a combination of the above. • To aid in the establishment of many point2point connectors using the client-connect, server-listen/accept pattern the EndpointConnector could use an auxiliary “ServerConnector” and corresponding listeners that would inform it of the fact that clients are attempting a connection. ? For Group communications the factory of DataReader and DataWriter entities would be the GroupConnector • The same generic mechanism used by the EndpointConnector should be used to identify the group the GroupConnector entities are joining, that is either a Topic, or a more general matching of “Attibute-value” pairs, or a combination of the above. Comments[RTI] ? To avoid confusion it might be a good idea to propose a name other than “connector” for the base class and also avoid the use of the terms “client” and “server” which are often associated with the pattern of communications used by CORBA and RMI. ? Point2Point communications would never use KEEP_LAST QoS. They will use KEEP_ALL. They will also always have DURABILITY TRANSIENT. In a sense messages are sent to the other end “immediately” and held only as long as is necessary to ensure the QoS (e.g. RELIABLE or TRANSACTIONAL) afterwards they are removed from the middleware.

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Closed; No Change — DDS 1.0
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1019: Name of the ObjectRoot::clone method (editorial)

  • Key: DDS-28
  • Legacy Issue Number: 6723
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    in section 3.6.1.3.11 the clone method is named clone_object in the text explanation.
    Proposal [THALES]
    correct the text (everywhere else, the method is named clone)
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1018: Name of the methods for ObjectListener (editorial)

  • Key: DDS-27
  • Legacy Issue Number: 6722
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    In section 3.1.6.3.6 (ObjectListener) the method names used in the bulleted descriptions do not correspond to the names used in the Table
    page 3-38: section 3.1.6.4.2 (Object Creation) first bullet: two times on_object_created is mentioned according to figure 3-4 this should be on_new_object.
    Proposal [THALES]
    correct the table (the bullets are in accordance with the IDL)
    correct the figure (on_object_created is the name of the operation in other places, including IDL)
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1017: Section 3.1.4.4.2 topic (editorial

  • Key: DDS-26
  • Legacy Issue Number: 6721
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    1st bullet: section 3.1.4.4.2 (Mono Attribute) Class::topic should be Class::main_topic
    Proposal [THALES]
    correct the wording
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1016: Page 3-65 t2 (editorial)

  • Key: DDS-25
  • Legacy Issue Number: 6720
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    page 3-65: 4th line from below: t3->z(3000.0); t3 should be t2
    Proposal [THALES]
    correct the example
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1015: Page 3-62 manual edition (editorial)

  • Key: DDS-24
  • Legacy Issue Number: 6719
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    page 3-62: Just after the XML listing: manual edition should be manual editing
    Proposal [THALES]
    correct the sentence
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1010: Section 3.2.3.3 XML Model Tags of the example

  • Key: DDS-19
  • Legacy Issue Number: 6714
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    In the final editing process,
    the XML for the example has been truncated (cut by 2)
    the chosen font makes it difficult to read (why not use Courier New which is a fixed-sized font as for the code example)
    there should be a void line between the first sentence that introduces the XML description and the description itself
    Proposal [THALES]
    restore the contents as it was in version V67
    introduce a void line to keep it separated from the introduction
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1009: Section 3.2.3.2 IDL Model description of the example

  • Key: DDS-18
  • Legacy Issue Number: 6713
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    in the final editing process, the IDL for the example has been truncated (cut by 2)
    Proposal [THALES]
    restore it as it was in version V67
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1012: Section 3.2.3.3 Simplified XML of the example)

  • Key: DDS-21
  • Legacy Issue Number: 6716
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    In the final editing process,
    the minimum XML model tags for the example have been truncated (cut by 2)
    the removal of the title makes less clear the purpose of the description
    Proposal [THALES]
    restore the contents as it was in version V67
    change the last sentence of the introduction " In this case, the XML file would be as follows" with
    "In case no deviation is wanted from the default mapping, the XML description can be restricted to the following minimum:"
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1011: Section 3.2.3.3 Introduction to figure 3.9 (editorial)

  • Key: DDS-20
  • Legacy Issue Number: 6715
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    The style applied to the introduction to figure 3.9 is not correct
    The figure itself is badly placed on the page
    Proposal [THALES]
    Correct the footprint
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    Correct the footprint
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1004: Section 3.1.3.3 Metamodel (clarification)

  • Key: DDS-13
  • Legacy Issue Number: 6708
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Several readers wondered if the described metamodel should be implemented, while it is only given for description purpose
    Proposal [THALES]
    Add the following clarification sentence (at the end of the first paragraph of the section page 3.4):
    " This metamodel is given for explanation purpose. This specification does not require that it is implemented as such."
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1006: Page 3.11 (editorial)

  • Key: DDS-15
  • Legacy Issue Number: 6710
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    On that page, "Class", "Attribute" and "Relation" (line 2) and "Class" (first line before section 3.1.4.4.3) should be in bold+italics as the other words that are identifiers
    Proposal [THALES]
    Correct the words
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1005: figure 3.2 (editorial)

  • Key: DDS-14
  • Legacy Issue Number: 6709
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In the class "Relation", the attribute "rel_needs_class" should be named "full_oid_required" (according to the text description)
    In the class "Class" In the class "Relation", the attribute "id_needs_class" should be named "full_oid_required" (according to the text description)
    Proposal [THALES]
    Correct the figure
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    Correct the figure
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1008: Bad annex reference (editorial)

  • Key: DDS-17
  • Legacy Issue Number: 6712
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    in the whole DLRL section, Annex C is badly named Annex A
    Proposal [THALES]
    Change all the "cf. annex A", with "cf. annex C"
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1007: Section 3.1.6.3.4 CacheListener (editorial)

  • Key: DDS-16
  • Legacy Issue Number: 6711
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    In the textual description, the method "on_begin_updates" is named "start_updates"
    In the textual description, the method "on_end_updates" is named "end_updates"
    Proposal [THALES]
    Correct the textual description to align on the table.
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1014: Page 3-10, figure 3-2 min_topic (editorial)

  • Key: DDS-23
  • Legacy Issue Number: 6718
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    page 3-10: In figure 3-2 the class attribute min_topic should be main_topic
    Proposal [THALES]
    correct the figure
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    correct the figure
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ref-1013: Section 3.1.6.3.9 Table for ObjectQuery (editorial)

  • Key: DDS-22
  • Legacy Issue Number: 6717
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    attribute "parameter" is stated as of type "string[}" instead "string []"
    Proposal [THALES]
    correct the table
  • Reported: DDS 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Cache and CacheAccess should have a common parent

  • Key: DDS12-35
  • Legacy Issue Number: 9517
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Both the CacheAccess and Cache have some functional overlap. It would be nice if this overlap would be migrated to a common generalization (for a good reason, see also Issue T_DLRL#3).

    Proposed Resolution:

    Introduce a new class called CacheBase, that has represents the common functionality. Both the Cache and the CacheAccess inherit from this common base-class.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Simplify Relation Management

  • Key: DDS12-34
  • Legacy Issue Number: 9516
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The purpose of the DLRL has been described as being able “to provide more direct access to the exchanged data, seamlessly integrated with the native-language constructs”. This means that DLRL should offer applications an OO-view on the information model(s) they use. In this view, objects behave in the same way as ordinary, native language objects.
    Providing intuitive object access and object navigation should be key-benefits of DLRL compared to plain DCPS usage, where instances and their relations need to be resolved manually. Object navigation in DLRL therefore needs to be simple and intuitive, just like navigating between objects in any ordinary native OO-language.
    It is in this aspect that DLRL falls short: object navigation is not simple and intuitive, since it requires intermediate objects (RefRelations and ObjectReferences) that abstract applications from the navigable objects. The purpose of these intermediate objects was to serve as some sort of smart pointers, that abstract applications from knowledge about the exact location and even about the existence of objects (to allow a form of lazy instantiation).
    However, since the potential benefits from smart pointer management are rather dependent on the underlying target language, the DLRL specification does not address them and only explains the effort that an application should do in the absence of any smart pointer support. This results in the following problems:
    The way in which a DLRL implementation solves pointer arithmetic is not standardized and may change from vendor to vendor and from language to language.
    When smart pointer arithmetic is not available, applications will be expected to do lots of extra relational management, which is not in the scope of most application programmers.

    Proposed Resolution:

    Simplify relation management by removing all intermediate relation objects from the API (Reference, Relation, RefRelation, ObjectReference, ListRelation and MapRelation). Navigation of single relations is done by going directly from ObjectRoot to ObjectRoot (simplifying the IDL object model as well). Implementations can still choose to do smart resource management (e.g. lazy instantiation), but they should do so in a fully transparent way, one that is invisible to applications.
    This approach also makes the PIM and PSM (which deviated quite a lot from eachother with respect to these intermediate relation-like objects) more consistent.

    Proposed Revised Text:

    Section 3.1.5.2, 2nd paragraph, 1st sentence: “DLRL classes are linked to other DLRL classes by means of Relation Objects”. This should be replaced with “… by means of relations.”.

    Change the Object Diagram of Figure 3.4. (an alternative Object Diagram will be provided).

    Change the table immediately following Figure 3.4 by removing the ObjectReference, Reference, Relation, RefRelation, ListRelation, StrMapRelation and IntMapRelation entries from it.

    Remove the foot-note directly following this table (starting with with number 1) that says: “The specification does … (lazy instantiation).”

    Section 3.1.6.3.2: Remove the sequence of ObjectReference attribute from the CacheAccess table and from the explanation below it. As a replacement, see T_DLRL#2 and T_DLRL#3.

    Section 3.1.6.3.2: Remove the deref method from the CacheAccess table and from the explanation below it.

    Section 3.1.6.3.3: Remove the sequence of ObjectReference attribute from the Cache table and from the explanation below it. As a replacement, see T_DLRL#2 and T_DLRL#3.

    Section 3.1.6.3.3: Remove the deref method from the Cache table and from the explanation below it.

    Section 3.2.1.2.1: Remove the following lines from the CacheAccess and Cache interface:
    readonly attribute ObjectReferenceSeq refs;
    ObjectRoot deref( in ObjectReference ref) raises (NotFound);

    Section 3.1.6.3.5: Remove the sequence of ObjectReference attribute from the ObjectHome table, and from the explanation below it.

    Section 3.2.1.2.1: Remove the following line from the ObjectHome interface:
    readonly attribute ObjectReferenceSeq refs;

    Section 3.1.6.3.5: Change the entire explanation of the auto_deref attribute from:
    “a boolean that indicates if ObjectReference corresponding to that type should be implicitly instantiated (TRUE) or if this action should be explicitly done by the application when needed by calling a deref operation (auto_deref). As selections act on instantiated objects (see section 3.1.6.3.7 for details on selections), TRUE is a sensible setting when selections are attached to that home.”
    to:
    “a boolean that indicates whether the state of a DLRL Object should always be loaded into that Object (auto_deref = TRUE) or whether this state will only be loaded after it has been accessed explicitly by the application (auto_deref = FALSE).”

    Section 3.1.6.3.5: Change the entire explanation of the deref_all method from:
    “ask for the instantiation of all the ObjectReference that are attached to that home, in the Cache (deref_all).”
    To:
    “ask to load the most recent state of a DLRL Object into that Object for all objects managed by that home (deref_all).”

    Section 3.1.6.3.5: Change the entire explanation of the underef_all method from:
    “ask for the removal of non-used ObjectRoot that are attached to this home (underef_all).”
    To:
    “ask to unload all object states from objects that are attached to this home (underef_all).”

    Section 3.1.6.3.6: Replace all occurrences of ObjectReference with ObjectRoot in the ObjectListener table. Also remove the second parameter of the on_object_modified method.

    Section 3.1.6.3.6: Change the explanation of on_object_created from:
    “… this operation is called with the ObjectReference of the newly created object (ref).”
    to:
    “… this operation is called with the value of the newly created object (the_object).”

    Section 3.1.6.3.6: Change the explanation of on_object_modified from:
    “This operation is called with the ObjectReference of the modified object (ref) and its old value (old_value); the old value may be NULL.”
    To:
    “This operation is called with the new value of the modified object (the_object).”

    Section 3.1.6.3.6: Change the explanation of on_object_deleted from:
    “… this operation is called with the ObjectReference of the newly deleted object (ref).”
    To:
    “… this operation is called with the value of the newly deleted object (the_object).

    Section 3.1.6.3.10: Replace all occurrences of ObjectReference with ObjectRoot in the SelectionListener table.

    Section 3.2.1.2.1: Change in the IDL interfaces for ObjectListener en SelectionListener the following lines from:
    local interface ObjectListener

    { boolean on_object_created ( in ObjectReference ref ); /**** * will be generated with the proper Foo type * in the derived FooListener * boolean on_object_modified ( in ObjectReference ref, * in ObjectRoot old_value); ****/ boolean on_object_deleted ( in ObjectReference ref ); }

    ;

    local interface SelectionListener

    { /*** * will be generated with the proper Foo type * in the derived FooSelectionListener * void on_object_in ( in ObjectRoot the_object ); void on_object_modified ( in ObjectRoot the_object ); * ***/ void on_object_out ( in ObjectReference the_ref ); }

    ;

    To:

    local interface ObjectListener

    { /**** * will be generated with the proper Foo type * in the derived FooListener boolean on_object_created ( in ObjectRoot the_object ); boolean on_object_modified ( in ObjectRoot the_object ); boolean on_object_deleted ( in ObjectRoot the_object ); * ****/ }

    ;

    local interface SelectionListener

    { /*** * will be generated with the proper Foo type * in the derived FooSelectionListener * void on_object_in ( in ObjectRoot the_object ); void on_object_modified ( in ObjectRoot the_object ); void on_object_out (in ObjectRoot the_object ); * ***/ }

    ;

    Section 3.2.1.2.2: Change in the IDL interfaces for ObjectListener en SelectionListener the following lines from:

    local interface FooListener: DDS::ObjectListener

    { void on_object_modified ( in DDS ::ObjectReference ref, in Foo old_value ); }

    ;

    local interface FooSelectionListener : DDS::SelectionListener

    { void on_object_in ( in Foo the_object ); void on_object_modified ( in Foo the_object ); }

    ;

    To:

    local interface FooListener: DDS::ObjectListener

    { boolean on_object_created ( in Foo the_object ); boolean on_object_modified ( in Foo the_object ); boolean on_object_deleted ( in Foo the_object ); }

    ;

    local interface FooSelectionListener : DDS::SelectionListener

    { void on_object_in ( in Foo the_object ); void on_object_modified ( in Foo the_object ); void on_object_out (in Foo the_object ); }

    ;

    Section 3.1.6.3.13: Remove the ObjectReference attribute from the ObjectRoot table, and from the explanation below it.

    Section 3.2.1.2.1: Remove the following line from the IDL in the ObjectRoot:
    readonly attribute ObjectReference ref;

    Section 3.1.6.3.13: Change the following sentence from:
    “In addition, application classes (i.e., inheriting from ObjectRoot), will be generated with a set of methods dedicated to each shared attribute:”
    To:
    “In addition, application classes (i.e., inheriting from ObjectRoot), will be generated with a set of methods dedicated to each shared attribute (including single- and multi-relation attributes):”

    Section 3.1.6.3.14 can be removed (ObjectReference).

    Section 3.2.1.2.1: Remove the following lines from the IDL:

    /*****************

    • ObjectReference
      *****************/
      struct ObjectReference { DLRLOid oid; unsigned long home_index; }

      ;
      typedef sequence<ObjectReference> ObjectReferenceSeq;

    Section 3.1.6.3.15 can be removed (Reference).

    Section 3.1.6.3.20 can be removed (Relation).

    Section 3.1.6.3.21 can be removed (RefRelation).

    Section 3.1.6.3.22 - Section 3.1.6.3.24 can be removed (ListRelation, IntMapRelation and StrMapRelation).

    Section 3.2.1.2.1: Remove the following lines from the IDL:

    /********************************

    • Value Bases for Relations
      *********************************/

    valuetype RefRelation

    { private ObjectReference m_ref; boolean is_composition(); void reset(); boolean is_modified ( in ReferenceScope scope ); }

    ;

    valuetype ListRelation : ListBase

    { private ObjectReferenceSeq m_refs; boolean is_composition(); }

    ;

    valuetype StrMapRelation : StrMapBase {
    struct Item

    { string key; ObjectReference ref; }

    ;
    typedef sequence <Item> ItemSeq;
    private ItemSeq m_refs;
    boolean is_composition();
    };

    valuetype IntMapRelation : IntMapBase {
    struct Item

    { long key; ObjectReference ref; }

    ;
    typedef sequence <Item> ItemSeq;
    private ItemSeq m_refs;
    boolean is_composition();
    };

    Section 3.2.1.1: 1st paragraph after the numbered list of DLRL entities, remove the following sentence: “(with the exception of ObjectReference, …. , so that it can be embedded). Section 3.2.1.2.2: Change the following lines in IDL from:

    valuetype FooStrMap : DDS::StrMapRelation { // StrMap<Foo>
    …
    valuetype FooIntMap : DDS::IntMapRelation { // IntMap<Foo>

    To:

    valuetype FooStrMap : DDS::StrMap { // StrMap<Foo>
    …
    valuetype FooIntMap : DDS::IntMap { // IntMap<Foo>

    Section 3.2.2.3.1: Remove the “Ref” value from the allowed list of patterns, so change the templateDef . The templatedef then changes from:
    <!ATTLIST templateDef name CDATA #REQUIRED
    pattern (List | StrMap | IntMap | Ref) #REQUIRED
    itemType CDATA #REQUIRED>

    To (see also Issues T_DLRL#7 and T_DLRL#8):

    <!ATTLIST templateDef name CDATA #REQUIRED
    pattern (Set | StrMap | IntMap) #REQUIRED
    itemType CDATA #REQUIRED>

    Section 3.2.2.3.2.3, 2nd bullet: Remove the “Ref” pattern from the list of supported constructs.

    Section 3.2.3.2: Replace the forward valuetype declaration for RadarRef with a forward declaration of type Radar, so change from:
    valuetype RadarRef // Ref<Radar>
    To:
    valuetype Radar;

    Section 3.2.3.3: Remove the following line from the XML (in both XML examples):
    “<templateDef name=“RadarRef”
    pattern=“Ref” itemType=“Radar”/>”
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Object State Transitions of Figure 3-5 and 3-6 should be corrected

  • Key: DDS12-39
  • Legacy Issue Number: 9521
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Object State Transitions of Figure 3-5 and 3-6 should be corrected and simplified

    Summary:

    The state transition diagrams in Figure 3-5 and 3-6 are difficult to understand, and the 2nd diagram of Figure 3-5 is missing. (Instead of this 2nd diagram, the first diagram of Figure 3-6 has wrongly been duplicated here).
    Furthermore, since it is difficult to distinguish between primary and secondary Objects and their primary and secondary states, it would be nice if more intuitive names and states could be used instead.
    Finally, some of the possible conditions in which a state transition can occur are not mentioned in these state transition diagrams, which would even require for them to become more complex.

    Proposed Resolution:

    Introduce new names for the different states, and try to re-use the same set of states for each diagram. We propose not to speak about primary and secondary objects, but to speak about Cache Objects (located in a Cache) and CacheAccess objects (located in a CachAccess). Furthermore, we propose not to speak about primary and secondary states, but to speak about a READ state (with respect to incoming modifications) and a WRITE state (with respect to local modifications).
    Decouple Objects in the Cache from Objects in a CacheAccess, it makes the the the idea of what a Cache or CacheAccess represent more understandable. The Cache represents the global Object states as accepted by the System, a READ_ONLY CacheAccess represents a temporary state of a Cache, and a READ_WRITE or WRITE_ONLY CacheAccess represents the state of what the user intends the system to do in the future.
    Since a Cache then only represents the global state of the system (and not what the user intends to do), it does not have a WRITE state (it will be VOID). A READ_ONLY CacheAccess also has no WRITE state (VOID), but a WRITE_ONLY CacheAccess has no READ state (VOID). A READ_WRITE CacheAccess has both a WRITE and a READ state, and the WRITE state represents what the user has modified but not yet committed, and the READ state represent what the system has modified during its last update.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Introduce the concept of cloning contracts consistently in specification

  • Key: DDS12-38
  • Legacy Issue Number: 9520
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    The specification states that it is possible to clone an Object from the primary Cache into a CacheAccess, together with its related or contained objects for a specified navigatable depth. (We will refer to such an Object tree as a cloning contract from now on). However, while the cloning of objects is done on contract level, the deletion of clones is done on individual object level. What should happen to related objects when the top level object is deleted? Furthermore, it is unclear what the result should be when a relationship from an object A to an object B changes from object A to object C. Should the next refresh of the CacheAccess only refresh the states of objects A and B, or should object C be added and object B be removed from the CacheAccess?

    Proposed Resolution:

    Formally introduce the concept of a cloning contract into the API to replace all other clone-related methods. Cloning contracts are defined on the CacheAccess and are evaluated when the CacheAccess is refreshed.

  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectExtent and ObjectModifier can be removed

  • Key: DDS12-37
  • Legacy Issue Number: 9519
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The ObjectExtent is a manager for a set objects. Basically it is a wrapper that offers functions to modify its contents and to create a sub-set based on on a user-defined function. The problem with using an Extent is that it overlaps with the get_objects method introduced in issue T_DLRL#3, and that it is not clear whether a new Extent should be allocated each time the user obtains it from the ObjectHome, or whether the existing Extent should be re-used and therefore its contents be overwritten with every update.
    Furthermore, every application can easily write its own code that modifies every element in this sequence (no specialized ObjectModifier is required for that, a simple for-loop can do the trick), and similarly an application can also write code to filter each element and to store matching results in another sequence. Filtering and modifying objects like this are really business logic, and do not have to be part of a Middleware specification.

    Proposed Resolution:

    Remove the ObjectModifier and ObjectExtent from the specification. This saves two implied interfaces that are not required for most types of applications, but which can still be solved very well at application level. Replace the extent on the ObjectHome with a sequence of ObjectRoots.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Object notification in manual update mode required

  • Key: DDS12-36
  • Legacy Issue Number: 9518
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The DLRL offers two different update modes for its Primary Cache: an automatic mode in which object creations, updates and deletions are pushed into the Cache and a manual mode in which the Cache content are refreshed on user-demand.
    >From the perspective of a Cache-user, it is important to find out what has happened to the contents of the Cache during the latest update session. In automatic update mode, Listeners are triggered for each Object creation, modification or deletion in the primary Cache. However, when the Cache is in manual update mode none of these Listeners are triggered and no means exist to examine what has happened during the last update round. The same can be said for the CacheAccess, that does not have an automatic update mode and neither has any means to examine the changes that were applied during the last invocation of the “refresh” method.

    Proposed Resolution:

    We therefore propose to add some extra methods to the ObjectHome, that allow an application to obtain the list of Objects that have been created, modified or deleted in the latest update round of a specific CacheBase
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation dispose_w_timestamp() should be callable on unregistered instance

  • Key: DDS12-26
  • Legacy Issue Number: 9503
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 2.1.2.4.2.14 (dispose_w_timestamp) it states that the operation will return PRECONDITION_NOT_MET if called on an instance that has not yet been registered. This is not true as the operation will implicitly register the instance just as write does. This restriction was also originally in 2.1.2.4.2.13 (dispose) but has already been removed.

    Proposed Resolution:
    Remove the offending paragraph.

    Proposed Revised Text:
    Section 2.1.2.4.2.14 dispose_w_timestamp
    Remove the last two paragraphs , that is the text starting from "The operation must be only called on registered instances." till the end of the section.
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify valid handle when calling write()

  • Key: DDS12-25
  • Legacy Issue Number: 9502
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 2.1.2.4.2.11 the write() operation will return PRECONDITION_NOT_MET if the handle is "valid but does not correspond to the given instance". Further, it goes on to state that "in the case the handle is invalid, the behavior is in general unspecified, but if detectable by a DDS implementation, the returned error-code will be 'BAD_PARAMETER'." We should clarify what is "valid" versus "invalid".
    Valid means the handle corresponds to a registered instance.

    Proposed Resolution:
    Clarify that valid means the handle corresponds to a registered instance.
    When the handle is valid and does not correspond to the given instance should be up to the implementation to be able to detect this or not.

    Proposed Revised Text:

    Section 2.1.2.4.2.11 write
    Remove the last paragraph that reads "In case the provided handle is valid"

    Add a new paragraph directly following the one that reads "If handle is any value other than HANDLE_NIL" as follows:
    In case the provided handle is valid, i.e. corresponds to an existing instance, but does not correspond to same instance referred by the 'data' parameter, the behavior is in general unspecified, but if detectable by the Service implementation, the return error-code will be 'PRECONDITION_NOT_MET'. In case the handle is invalid, the behavior is in general unspecified, but if detectable the returned error-code will be 'BAD_PARAMETER'.

    Section 2.1.2.4.2.13 dispose
    Replace the next to last paragraph that reads "In case the provided handle is valid."
    With the same paragraph above:
    In case the provided handle is valid, i.e corresponds to an existing instance, but does not correspond to same instance referred by the 'data' parameter, the behavior is in general unspecified, but if detectable by the Service implementation, the return error-code will be 'PRECONDITION_NOT_MET'. In case the handle is invalid, the behavior is in general unspecified, but if detectable the returned error-code will be 'BAD_PARAMETER'.
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Corrections to Figure 2-19

  • Key: DDS12-33
  • Legacy Issue Number: 9511
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Figure 2-19 in Section 2.1.4.4 (Conditions and Wait-sets):
    There is no such delete_statuscondition() operation on the Entity.
    The ReadCondition should have a view_state_mask and an instance_state_mask instead of a lifecycle_state_mask.

    Proposed Resolution:
    Make the suggested corrections.

    Proposed Revised Text:
    Section 2.1.4.4 Conditions and Wait-sets
    In Figure 2-19
    Remove "delete_statuscondition()" from the operations listed on the Entity.
    Remove "lifecycle_state_mask [*] : ViewStateKind" from the attributes listed on the ReadCondition.
    Add "view_state_mask [*] : ViewStateKind" and "instance_state_mask [*] : InstanceStateKind" to the end of the attributes listed on the ReadCondition.
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Make the suggested corrections
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Non intuitive constant names

  • Key: DDS12-32
  • Legacy Issue Number: 9510
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The following literals are defined:
    DURATION_INFINITY_SEC
    DURATION_INFINITY_NSEC
    TIMESTAMP_INVALID_SEC
    TIMESTAMP_INVALID_NSEC

    These are incorrectly named and should be:
    DURATION_INFINITE_SEC
    DURATION_INFINITE_NSEC
    TIME_INVALID_SEC
    TIME_INVALID_NSEC

    Proposed Resolution:
    Add the correct names.

    Proposed Revised Text:

    Section 2.2.3 DCPS PSM : IDL

    Replace:
    const long DURATION_INFINITY_SEC = 0x7fffffff;
    const unsigned long DURATION_INFINITY_NSEC = 0x7fffffff;
    const long TIMESTAMP_INVALID_SEC = -1;
    const unsigned long TIMESTAMP_INVALID_NSEC = 0xffffffff;

    With:
    const long DURATION_INFINITE_SEC = 0x7fffffff;
    const unsigned long DURATION_INFINITE_NSEC = 0x7fffffff;
    const long TIME_INVALID_SEC = -1;
    const unsigned long TIME_INVALID_NSEC = 0xffffffff;
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Use the correct names
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Example in 2.1.4.4.2 not quite correct

  • Key: DDS12-31
  • Legacy Issue Number: 9509
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 2.1.4.4.2 (Trigger State of the ReadCondition) the last paragraph describes an example. However, it is not quite true because reading samples belonging to the latest generation will cause the view_state to become NOT_NEW.
    For the sake of the example considered, it may not be necessary to specify the view_state since it is not absolutely relevant to the desired condition being triggered when a new sample arrives given that all other samples were previously at least read.

    Proposed Resolution:
    Remove mention of the view_state.

    Proposed Revised Text:
    Section 2.1.4.4.2 Trigger State of the ReadCondition
    In the last paragraph, change the sentence from
    "A ReadCondition that has a sample_state_mask =

    {NOT_READ}, view_state_mask = {NEW} will have trigger_value of TRUE whenever a new sample arrives and will transition to FALSE as soon as all the NEW samples are either read or taken."


    To
    "A ReadCondition that has a sample_state_mask = {NOT_READ}

    will have trigger_value of TRUE whenever a new sample arrives and will transition to FALSE as soon as all the new samples are either read or taken. "

    Section 2.1.4.4.2 Trigger State of the ReadCondition
    In that last paragraph change the last sentence from
    "that would only change the SampleState to READ but the sample would still have (SampleState, ViewState) = (READ, NEW) which overlaps the mask on the ReadCondition".
    To
    "that would only change the SampleState to READ which still overlaps the mask on the ReadCondition".
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Remove mention of the view_state.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in copy_from_topic_qos

  • Key: DDS12-28
  • Legacy Issue Number: 9505
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 2.1.2.5.2.17 there is a typo in the last paragraph where "datawriter_qos" should be "datareader_qos".

    Proposed Resolution:
    Correct the typo.

    Proposed Revised Text:
    Section 2.1.2.5.2.17 copy_from_topic_qos
    Replace "datawriter_qos" with "datareader_qos" in the first sentence of the last paragraph that currently reads "This operation does not check the resulting datawriter_qos for consistency".
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Correct the typo
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior of dispose with regards to DURABILITY QoS

  • Key: DDS12-27
  • Legacy Issue Number: 9504
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 2.1.2.4.2.13 (dispose) it states "in case the DURABILITY QoS policy is TRANSIENT or PERSISTENT, the Service should take care to clean anything related to that instance so that late-joining applications would not see it".
    Is this really necessary? Is it not acceptable to allow late-joining readers to see an instance with the NOT_ALIVE_DISPOSED instance state?
    Does this also apply to TRANSIENT_LOCAL?

    We think disposed instances should be propagated to new-ly discovered applications, otherwise there would be no way to enforce ownership of a disposed instance.
    Furthermore the application should be notified of disposed instances even if this is the first time the middleware sees the instance because in practice there is no way for the middleware to tell if the application has seen the instance already; for example, following a network partition the middleware may have notified of NOT_ALIVE_NO_WRITERS and following the application taking all the samples it could have reclaimed the information on that instance, so when it sees it again it thinks it is the first time; the application meanwhile could still have information on that instance…
    So the user case where a newly joining reader wants to not receive instances that have been disposed before it joined should be handled on the writer side by either explicitly unregistering the instances, or having some new QoS that auto-unregisters disposed instances.

    Another issue is whether the act of disposing on the writer side should automatically remove previous samples for that instance, and whether that is done for particular values of the HISTORY (e.g. when it is KEEP_LAST only, or KEEP_LAST with depth==1, or, even for KEEP_ALL). Seems like the control of this should be another QoS on the WRITER_LIFECYCLE.

    Proposed Resolution:
    For now eliminate the following text from Section 2.1.2.4.2.13 (dispose)
    "In case the DURABILITY QoS policy is TRANSIENT or PERSISTENT, the Service should take care to clean anything related to that instance so that late-joining applications would not see it".

    Proposed Revised Text:
    Section 2.1.2.4.2.13 dispose
    Remove the paragraph:
    In addition, in case the DURABILITY QoS policy is TRANSIENT or PERSISTENT, the Service should take care to clean anything related to that instance so that late-joining applications would not see it.

  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

delete_contained_entities() on the Subscriber

  • Key: DDS12-22
  • Legacy Issue Number: 9499
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Should delete_contained_entities() on the Subscriber (and even the DataReader or DomainParticipant) be allowed to return PRECONDITION_NOT_MET?

    Summary:
    As described in Section 2.1.2.5.2.6, delete_datareader() can return PRECONDITION_NOT_MET if there are any outstanding loans. In a similar fashion, should we allow delete_contained_entities() on the Subscriber (and even the DataReader or DomainParticipant for that matter) to also return PRECONDITION_NOT_MET in this situation?

    Proposed Resolution:
    Return PRECONDITION_NOT_MET when delete_contained_entities() is called on either the DataReader, Subscriber, or DomainParticipant when a DataReader has outstanding loans.

    Proposed Revised Text:

    Section 2.1.2.2.1.18 delete_contained_entities
    Before the paragraph that starts with "Once delete_contained_entities returns successfully," add the paragraph
    The operation will return PRECONDITION_NOT_MET if the any of the contained entities is in a state where it cannot be deleted.

    Section 2.1.2.4.1.14 delete_contained_entities
    Before the paragraph that starts with "Once delete_contained_entities returns successfully," add the paragraph
    The operation will return PRECONDITION_NOT_MET if the any of the contained entities is not in a state where it can be deleted.

    Section 2.1.2.5.2.14 delete_contained_entities
    Before the paragraph that starts with "Once delete_contained_entities returns successfully," add the paragraph
    The operation will return PRECONDITION_NOT_MET if the any of the contained entities is not in a state where it can be deleted. This will occur, for example, if a contained DataReader cannot be deleted because the application has called a read or take operation and has not called the corresponding return_loan operation to return the loaned samples.

    Section 2.1.2.5.3.30 delete_contained_entities
    Before the paragraph that starts with "Once delete_contained_entities returns successfully," add the paragraph
    The operation will return PRECONDITION_NOT_MET if the any of the contained entities is not in a state where it can be deleted.
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need INVALID_QOS_POLICY_ID

  • Key: DDS12-24
  • Legacy Issue Number: 9501
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Requested/OfferedIncompatibleQosStatus contains the last_policy_id and we need to set this to something in case no QoS policy has ever been incompatible.

    Proposed Resolution:
    Add "const QosPolicyId_t INVALID_QOS_POLICY_ID = 0;" to the PSM.

    Proposed Revised Text:
    Section 2.2.3 DCPS PSM : IDL
    In the Qos section add the following to the list of QosPolicyId_t:
    const QosPolicyId_t INVALID_QOS_POLICY_ID = 0;
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Add "const QosPolicyId_t INVALID_QOS_POLICY_ID = 0;" to the PSM
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Return of get_matched_XXX_data()

  • Key: DDS12-23
  • Legacy Issue Number: 9500
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In get_matched_subscription_data, we return PRECONDITION_NOT_MET in this situation. However, in get_matched_publication_data, we return BAD_PARAMETER. Previously, they were both returning PRECONDITION_NOT_MET.
    In addition, in both sections we state "The operation get_matched_XXXs to find the XXXs that are currently matched" should probably read "can be used to find".

    Proposed Resolution:
    Make it consistent by returning BAD_PARAMETER in both.

    Proposed Revised Text:

    Section 2.1.4.2.23 get_matched_subscription_data
    In the first sentence of the second paragraph, replace
    Replace "the operation will fail and return PRECONDITION_NOT_MET."
    With "the operation will fail and return BAD_PARAMETER."
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Make it consistent by returning BAD_PARAMETER in both
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation wait() on a WaitSet should return TIMEOUT

  • Key: DDS12-30
  • Legacy Issue Number: 9508
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently TIMEOUT is not a specified valid return code for the wait() operation. The specification explicitly states that timeout is conveyed by returning OK with an empty list of conditions. We should consider adding TIMEOUT as an explicit valid return value.

    Proposed Resolution:
    Add TIMEOUT as a valid return code to wait().

    Proposed Revised Text:
    Section 2.1.2.1.6.3 wait

    In the next to last paragraph, replace
    "If the duration is exceeded, wait will also return with the return code OK. In this case, the resulting list of conditions will be empty."
    With
    "If the duration is exceeded, wait will return with return code TIMEOUT."
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Add TIMEOUT as a valid return code to wait().
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in get_discovered_participant_data

  • Key: DDS12-29
  • Legacy Issue Number: 9507
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 2.1.2.2.1.28 there is a typo in the next to last paragraph where "get_matched_participants" should be "get_discovered_participants".

    Proposed Resolution:
    Correct the typo.

    Proposed Revised Text:
    Section 2.1.2.2.1.28 get_discovered_participant_data
    In the next to last paragraph replace "get_matched_participants" with "get_discovered_participants" where it currently reads "Use the operation get_matched_participants to find ".
  • Reported: DDS 1.1 — Sun, 2 Apr 2006 05:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Correct the typo.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CacheAccess operations (documentation)

  • Key: DDS-42
  • Legacy Issue Number: 6748
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    The operations of the CacheAccess are not sufficiently clearly described, that lead to some confusions
    Proposal [THALES]
    Enhance section 3.1.6.1.2.2 (Cache Management), in introducing better the underlying concepts; in particular, clarify the dynamics with respects to enable/disable updates
    Introduce that the specification is designed to allow lazy instantiation
    Describe more deeply the CacheAccess operations (section 3.1.6.3.2); in particular state how they will behave with respects to enable/disable updates
    Enhance the description of typical uses of CacheAccess (section 3.1.6.5)
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Depth of cloning (addition)

  • Key: DDS-41
  • Legacy Issue Number: 6747
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    The ObjectRoot::clone operation takes as parameter an ObjectScope (only the object, the object + all its components, the object + all its components + all its related objects). In the latter case, this may result in cloning a lot of objects
    Proposal [THALES]
    Add an extra parameter to limit the depth of cloning for related objects, with a dedicated value for unlimited
    Precise that if some related objects are not cloned (depending on the ObjectScope and RelatedObjectsDepth) , traversing the related relation should raise the NotFound exception (cf. ref-1026)
    IDL
    typedef short RelatedObjectDepth;
    const RelatedObjectDepth UNLIMITED_RELATED_OBJECT_DEPTH -1;
    OidRef clone (in CacheAccess access,
    in ObjectScope scope,
    in RelatedObjectDepth depth)
    raises (ReadOnlyMode);
    concerns the PIM (table and text and the PSM)
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Names of the ObjectRoot attributes

  • Key: DDS-40
  • Legacy Issue Number: 6746
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue [THALES]
    The attribute ObjectHome is named 'owner' and would be better named 'home'
    The attribute CacheAccess is named 'cache' and would be better named 'access'
    Proposal [THALES]
    change as indicated
    concerns the PIM (figure, table and text) and the PSM
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ref-62 Return_type_of_set_query_operations

  • Key: DDS-53
  • Legacy Issue Number: 6759
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 2.1.2.5.9. The set_query_arguments method is of type void, and
    can therefore not return an Error status.

    **PROPOSAL**

    Subsumed by proposal to Ref-50. Explicit operation to set the
    attribute will return ReturnCode_t
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    See issue 6758 for disposition
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming_of_attribute_getter_operations

  • Key: DDS-52
  • Legacy Issue Number: 6758
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Naming_of_attribute_getter_operations

    DataWriter class table, and DataReader class table operations
    get_liveliness_lost_status, get_offered_deadline_missed_status and
    get_offered_incompatible_qos_status.

    In the IDL file, these getter methods are specified as readonly
    attributes with the same names, but without the preceeding
    "get_". This leads to getter methods with different names in different
    languages (In C++ the"get_" part will disappear, in Java only the "_"
    will disappear).

    These IDL-to-language mappings would invalidate the PIM. To avoid
    this kinds of issues we should avoid using attributes in either the
    PIM or the PSM. The use of explicit operations will make the PIM more
    easily mappede to different PSMs.

    **PROPOSAL**

    Replace the readonly attributes in the PIM or PSM with explicit
    get_xxx operations. Replace any read-write attributes attributes in
    the PIM or PSM with explicit get_xxx and set_xxx operations.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Potential problems in PSM mappings

  • Key: DDS-51
  • Legacy Issue Number: 6757
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    ***Ref-05 IDL_case_sensitive

    In the PSM, the IDL uses as formal parameter names the same string as
    the name of the type only distinguished by the case. This appears to
    treat IDL as a case sensitive language which is not, and would result
    in problems in languages such as ADA that are not case sensitive.

    This problem appears in several paces where "topic" appears as the
    formal parameter name of an argument of type "Topic". For instance the
    operations TopicListener::on_inconsistent_topic,
    DomainParticipant::delete_topic, Subscriber::create_datareader
    Similarly "listener" appears as the formal parameter name of an
    argument of a type derived from Listener. For instance the operations
    DomainParticipant::create_publisher,
    DomainParticipant::create_subscriber, DomainParticipant::create_topic,
    DomainParticipantFactory::create_participant
    Publisher::create_datawriter, Subscriber::create_datareader

    **PROPOSAL** To avoid confusion use "a_topic" for the formal
    parameter name of any parameter of type "Topic", or any specialization
    of Topic.

    Similarly use "a_listener" for the formal parameter name of any
    parameter of type "Listener", or any specialization of Topic.
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Additional_qos_LIFESPAN Issue

  • Key: DDS-36
  • Legacy Issue Number: 6740
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2100 Additional_qos_LIFESPAN Issue [Boeing SOSCOE] ? The LIFESPAN Qos Policy that prevents “stale” data from being delivered to receiving applications. ? The LIFESPAN defines a time period for which the data should live. If a message cannot be delivered before the specified time period, the message is dropped. This value is expressed in time units, it should not be confused with a network-level Time-To-Live (TTL), that could be set on network connections which is expressed in number of hops. ? LIFESPAN is specified as a “span” that is a time interval measured from the time the data is written. ? LIFESPAN should be mutable. ? LIFESPAN needs to be specified only in the writer side. ? Note that this QoS assumes that the sender and receiving applications have their clocks sufficiently synchronized. ? The filtering could be done on the sending side, on the receiving side, or both. It would be an implementation decision that would only affect performance but would otherwise not be observable by the application. ? If data is dropped because the LIFESPAN value expires, Reliable and Transactional QoS would still require the writer to be notified of the failure to deliver. Proposal [Boeing SOSCOE] ? Introduce the LIFESPAN Qos.

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Additional_qos_DATA_PRIORITY Issue

  • Key: DDS-35
  • Legacy Issue Number: 6739
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2090 Additional_qos_DATA_PRIORITY Issue [Boeing SOSCOE] ? Need for additional DATA_PRIORITY Qos on the DataWriter. This Policy defines a priority that is associated with the data contained in a message and would serve two purposes: • 1) It would provide a prioritization mechanism for the transport, and • 2) It would determine how the receiver queues things in the data reader ? For the SOSCOE application this policy would have to support at least 5 values each with descending priority: (Flash_Override, Flash, Immediate, Priority, Routine) ? Ideally there would be a way to propagate and map this to whatever underlying transport is being used to send the messages. ? In its effect on the queuing on the receiving side it acts as a DESTINATION_ORDER QoS. In effect, the order would be BY_PRIORITY. ? Note that it would be possible to have DESTINATION_ORDER BY_PRIORITY and HISTORY KEEP_LAST. In this case, the reader may throw away the higher priority data if another message arrives. This is OK. If this is not the desired behavior, then the application should specify KEEP_ALL (which is expected to be the normal use in practice). Proposal [Boeing SOSCOE] ? Add a DATA_PRIORITY Qos.

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Navigation_of_connectivity_information Issue

  • Key: DDS-34
  • Legacy Issue Number: 6738
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2085 Navigation_of_connectivity_information Issue [Boeing SOSCOE] ? There is no way to use the DDS API to find some of the information that is available internally to the service. ? For example there is no way to determine & enumerate the remote readers that are “associated” with a local writer, or the remote writers associated with a local reader. ? The DDS specification does provide a way to “name/identify” the remote entities. This is the DCPSKey that appears as part of the fields of the built-in-topics which are the ones used to access discovery information on remote entities. Proposal [Boeing SOSCOE] ? Add iterators to the DataReader and DataWriter entities that allow enumerating the remote entities (identified by DCPSKey) associated with it. ? Add helper operations that allow determining the QoS associated with remote entities (identified by DCPSKey)

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Writer_notification_of_delivery_failure Issue

  • Key: DDS-33
  • Legacy Issue Number: 6736
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2070 Writer_notification_of_delivery_failure Issue [Boeing SOSCOE] ? This requirement applies to Point2Point and Group communications, not to Pub/Sub. ? In the case where the QoS is set to RELIABLE or TRANSACTIONAL there is a need for the application to be notified of delivery failures and also find out the delivery-status of individual messages. ? The application needs to get delivery confirmation with the granularity of a single message. ? Notification of delivery can be either synchronous (wait for delivery) or asynchronous (notification via listener). Proposal [Boeing SOSCOE] ? Add DataWriterListener::on_sent_data_lost and DataWriterListener::on_sent_data_received listener methods to notify sender asynchronously of reliable message send status ? Add UserListenerData for use in transactional and reliable processing. This data is specified on each write() and given back to the user through the DataWriterListener::on_sent_data_lost and DataWriterListener::on_sent_data_received methods to help the user determine what should be done with the data. ? Provide a way to get the ID of each message written (WriteMessageID). This can be used by the user to learn more about the message that was lost or received and is used by the system to track transactional and reliable messages that might have to be present. This id is passed to the on_sent_data_lost and on_sent_data_received listener methods and could become invalid at the end of those methods (the system must have some consistent way of determining when to clean up). Comment [RTI] ? In order for the application to find out the status of an individual message it needs to have some way to identify each message. Currently the DDS specification does not provide said mechanism. ? There are several ways to extend DDS to provide message identification functionality. • One way would be to change the return value of DataWriter::write() to return some kind of messageID or handle that can be used to refer to that message. Or alternatively return the messageId as an out parameter. However, this approach may complicate the application which now would need to perhaps track these IDs. • Another would be to add an operation to DataWriter to get the messageId of the last message written. This would have the advantage that it does not require a change of the API, just an extension. However, this would be potentially less efficient and also not safe if multiple application threads are using the same DataWriter to send information. • Another approach is that the MessageId would only be available by means of the callback. • With regards to the UserListenerData, it appears it needs to be either a parameter to the write call, or else something that could be set using a separate call. The first would clearly be more efficient but increases the complexity of the write API.

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    duplicate, close
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Transactional_reliability Issue

  • Key: DDS-32
  • Legacy Issue Number: 6735
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2060 Transactional_reliability Issue [Boeing SOSCOE] ? For the case of Point2Point and Group communications there is a need to have “application-level” reliability where the sender can find out if a message was (1) delivered to the receiving application(s) and (2) whether it was successfully processed by the receiving application(s). ? SOSCOE uses the name “TRANSACTIONAL” to refer to this kind of application-level message-processed confirmation. ? This would only make sense for HISTORY QoS KEEP_ALL. TRANSACTIONAL and KEEP_LAST would be considered inconsistent QoS settings. Proposal [Boeing SOSCOE] ? Add the kind TRANSACTIONAL to Reliability QoS policy ? Add DataReader::set_transaction_status (or some operation to allow receiving application to accept or reject a transactional message) ? Add listener operations to the DataWriter to get notified of the transactional status. Potentially add also a method to the DataWriter to query the transactional status. ? Add a DataWriter::rewrite(WriteMessageID). This only applies to EndpointConnectors or GroupConnectors that have transactional QoS set. This handles the case where the message was transmitted to the receiving end and put on the reader queue successfully but the reading application does not set the transactional status indicating that the message was processed. The rewrite() is a convenience so that the writing application does not have to re-create the message but is being treated by the infrastructure as a message that needs to be sent again because the reader has presumably erased it from its queues.

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    duplicate, close issue
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Extension_to_the_partition_qos

  • Key: DDS-31
  • Legacy Issue Number: 6731
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2030 Extension_to_the_partition_qos Issue [Boeing SOSCOE] ? The DDS specification provides the means for an application to configure the “connectivity” of DataReaders and DataWriters by setting the PARTITION QoS on the corresponding Publisher and Subscriber. ? Partitions therefore provide means for publishers and subscribers to restrict the associations that can be established between the readers and writers they contain. ? This facility is useful, but the fact that the matching is done by strict string matching of the partition-name strings can be limiting. ? It would be desirable to have something more extensible like “name-value” pairs and some more flexible expression language (e.g. a filter expression) to indicate the matching, beyond pure string matching. ? SOSCOE has created a provider property class that allows applications to have attributes with typed values; it becomes a triplet (name, type, value). Currently the “type” only supports simple types, but the intent is to extend it to well-known structured types (ref Issue#2035). ? A potential use case is to use name-value pairs to identify the source of the information or a distribution restriction. Things like AREA_NAME, SENSOR_GROUP, etc. each with its value. ? This is the analogous to the attribute-value pairs on the topic except they apply to the Publisher/Subscriber or EndpointConnectors. Proposal [Boeing] ? Addition of a set of name-value pairs to the Publisher and Subscriber (in fact to all Connectors) which can then be used to determine whether the endpoints contained in the connectors should communicate ? The attributes in the Connector can be used to locate providers of interest or somehow the “best” provider where “best” can be specific to each peer Connector. ? The query language described in Appendix A would not be sufficient for SOSCOE’s needs due to the need for function expressions and, at some future time, the ability to support well-known structured types (ref Issue#2035).

  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operations on collections of objects (addition

  • Key: DDS-48
  • Legacy Issue Number: 6754
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    Rather than returning a sequence of objects as the list of instances and let the application iterate in it, it seems better to let the infrastructure iterate by providing operations that would
    filter the objects
    apply a modifier on the objects
    Proposal [THALES]
    Introduce a new class FooExtent that would embed a sequence of Foo and provide those operations.
    Make the find_objects returning a FooExtent to allow to filter on a filtered result (like was allowed with the initial ObjectFilter::filter)
    Suppres the filter operation in an ObjectFilter (that is now redundant)
    Replace the list of instances in FooHome and FooSelection, by an instance of this class
    IDL
    local interface FooFilter : DLRL::ObjectFilter

    { boolean check_object (in Foo an_object); }

    local interface FooModifier: DLRL::ObjectModifier

    { void modify_objects (in Foo an_object); }

    local interface FooExtend: DLRL::OjectExtent

    { readonly attribute FooSeq objects; FooExtent find_objects (in FooFilter filter); void modify_objects (in FooFilter filter, in FooModifier modifier); }

    local interface FooHome

    { readonly attribute FooExtent extent; // instead of FooSeq }

    local interface FooSelection

    { readonly attribute FooExtent members;// instead of FooSeq }

    concerns the PIM (figure, list of interfaces, interface sections - table and text) and the PSM
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectHome::get_all_topic_names (addition

  • Key: DDS-47
  • Legacy Issue Number: 6753
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    Getting all the names of all the topics that are used to store objects of a given class may be rather cumbersome
    Proposal [THALES]
    add an operation to get all in a single call
    IDL
    StringSeq get_all_topic_names()
    Concerns the PIM (figure, table and text) and the PSM
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

: Attributes and operations directly set on valuetypes

  • Key: DDS-39
  • Legacy Issue Number: 6745
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    Currently the valuetypes ObjectRoot, RefRelation, ListRelation, IntMapRelation and StrMapRelation use a supported interface in order to gather their respective attributes and operations. This can be simplified in defining directly the attributes and operations on the valuetypes
    Proposal [THALES]
    define the corresponding attributes and operations directly in the valuetypes
    concern only the PSM
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CacheFactory::find_cache (addition

  • Key: DDS-38
  • Legacy Issue Number: 6744
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    There in no means to retrieve a previously created Cache
    Proposal [THALES]
    Add on the CacheFactory::create_cache an extra parameter that is the name of the Cache
    Add the CacheFactory::find_cache method
    IDL
    Cache create_cache (in CacheUsage usage,
    in DCPS::DomainParticipant domain,
    in string name)
    raises (DCPSError, AlreadyExisting);
    Cache find_cache (in string name)
    raises (NotFound);
    concerns the PIM (figure, table and text and the PSM)
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make_USER_DATA_an_array_and_mutable Issue

  • Key: DDS-37
  • Legacy Issue Number: 6743
  • Status: closed  
  • Source: Boeing ( Matthew Liu)
  • Summary:

    Issue# 2140 Make_USER_DATA_an_array_and_mutable Issue [Boeing SOSCOE] ? There are several potentially independent uses for USER_DATA. It would be useful to have it as a set of name-value pairs or other extensible construct. That way layers such as SOSCOE could add its own USER_DATA and not conflict with the uses that the application above SOSCOE may make of the data. ? SOSCOE has created a provider property class that allows applications to have attributes with typed values; it becomes a triplet (name, type, value). Currently the “type” only supports simple types, but the intent is to extend it to well-known structured types (ref Issue#2035). The extension of the USER_DATA can be used to implement these properties. Proposal [Boeing SOSCOE] ? Make USER_DATA a set of name-value pairs and make it mutable. ? Alternatively keep the USER_DATA as it is for the simple cases and add something more flexible for the more complex cases.
  • Reported: DDS 1.0b1 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    closed no change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Obtaining the DomainParticipantFactory

  • Key: DDS-50
  • Legacy Issue Number: 6756
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    ***Ref-04 Initialization_of_DomainParticipantFactory

    The specification does not define how the application gets the
    DomainParticipantFactory if each implementation uses a different
    mechanism it would make applications non portable.

    **PROPOSAL**

    Modify section 2.1.2.2.2 adding the static operation "get_instance" to
    DomainParticipantFactory. This operation will return the factory which
    is a singleton. If the method is called multiple times the same
    factory is returned
  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Name of ObjectLink (consistency)

  • Key: DDS-49
  • Legacy Issue Number: 6755
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    This object is referred (in attributes or operations as refs (ex - refs, deref); therefore the name of the class ObjectLink is confusing
    Proposal [THALES]
    Rename this construct as OidRef
    Concerns the PIM (figure, list of entities, entities sections - tables and texts) and the PSM
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectHome::get_topic_name (editorial

  • Key: DDS-46
  • Legacy Issue Number: 6752
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    This operation is not described in the text of section 3.1.6.3.5
    Proposal [THALES]
    add the description in the text (at the end of the operation list)
    "retrieve the name of the DCPS Topic that contains the value for one attribute (get_topic_name)"
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

stringSeq and longSeq (editorial)

  • Key: DDS-45
  • Legacy Issue Number: 6751
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    Rather name those types StringSeq and LongSeq as in DCPS
    Proposal [THALES]
    Actually 2 different naming rules conflict:
    list of xxx -> xxxSeq
    all user-created types starting with a capital letter
    Give the precedence to the second!
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CacheAccess::deref (clarification)

  • Key: DDS-44
  • Legacy Issue Number: 6750
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    What does deref when no corresponding object exist in the related CacheAccess or if the object has been deleted?
    Proposal [THALES]
    In that case, the deref operation should raise an exception (NotFound in the first case - cf. issue ref-1023, and Deleted in the second?)
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    See issue 6748 for disposition – duplicate
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CacheAccess::delete_access (editorial

  • Key: DDS-43
  • Legacy Issue Number: 6749
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Issue [THALES]
    The operation is badly named delete_cache in the PSM (instead of delete_access)
    The parameter is badly stated as CacheUsage (instead of CacheAccess) in the PIM (in the table for Cache operations)
    Proposal [THALES]
    Correct the PSM and the PIM table
  • Reported: DDS 1.0b1 — Fri, 19 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Support sequences of primitive types in DLRL Objects

  • Key: DDS12-52
  • Legacy Issue Number: 9534
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    The current Metamodel explains the different BasicTypes that are supported in DLRL. Although on DCPS sequences are supported for all primitive types, the DLRL states that the only sequences that can be supported are sequences of octet.

    Proposed Resolution:

    Explicitly state that the DLRL supports sequences of all supported primitive types.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Explicitly state that the DLRL supports sequences of all supported primitive types
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify which Exceptions exist in DLRL and when to throw them

  • Key: DDS12-51
  • Legacy Issue Number: 9533
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    The DLRL PSM specifies a number of Exceptions, but these are not explained in the PIM, and they do not cover the entire range of all possible errors.

    Proposed Resolution:

    Make an extensive list of all possible Exceptions and explain them in the PIM as well.
    Add a String message to the exception that can give more details about the context of the exception.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make the ObjectFilter and the ObjectQuery separate Selection Criterions

  • Key: DDS12-43
  • Legacy Issue Number: 9525
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    In the current specification, the ObjectQuery inherits from the ObjectFilter, making it an ObjectFilter as well. That means that performing Queries can no longer be delegated to the DCPS, since the Selection invokes the check_object method on the ObjectFilter for that purpose.

    Proposed Resolution:

    Make the ObjectFilter and the ObjectQuery to separate classes with a common parent called SelectionCriterion. A SelectionCriterion can be then be attached to a Selection, which will either invoke the check_object method in case of a Filter, or delegate the Query to DCPS in case of a Query.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add the Set as a supported Collection type

  • Key: DDS12-42
  • Legacy Issue Number: 9524
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    In many applications there is a need for an unordered Collection without keys.

    Proposed Resolution:

    Add the Set as a supported Collection type in DLRL.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Harmonize Collection definitions in PIM and PSM

  • Key: DDS12-41
  • Legacy Issue Number: 9523
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    The Collection definitions are very different between the PIM and the PSM.

    Proposed Resolution:

    Use corresponding Collection definitions in PIM and PSM. Make a strict separation in the IDL between typed operations (to be implemented in the typed specializations, but to be mentioned in the untyped parents) and untyped operations (to be implemented in the untyped parents). Also remove methods that have a functional overlap with other methods.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Iterators to Collection types

  • Key: DDS12-40
  • Legacy Issue Number: 9522
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    It would be nice to have an iterator for Collection types to be able to iterate through the entire Collection. For Maps there should be iterators for both the keys and the values.

    Proposed Resolution:

    Add an abstract Iterator class to the DLRL, which has typed implementations to access the underlying data.

  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Issue was subsequently withdrawn from the RTF by the submitters of the issue
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Representation of OID should be vendor specific

  • Key: DDS12-48
  • Legacy Issue Number: 9530
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    The OID currently consists of two numbers: a creator_id and a local_id. The philosophy is that each writer should obtain its own unique creator_id, and can then sequence number each object created with it to obtain unique object identifiers. The specification does not specify how the writers should obtain their unique creator_id. Building a mechanism to distribute unique OIDs requires knowledge about the underlying system characteristics, and this information is only available in DCPS.

    Proposed Resolution:

    Make the definition of the OID vendor specific. This allows a vendor to specify its own algorithms to guarantee that each object has got a unique identifier.
    The only location where the application programmer actually has to know the contents of the OID is in the create_object_with_oid method on the ObjectHome. However, we see no use-case for this method and propose to remove it.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Listener callbacks for changes in the update mode

  • Key: DDS12-47
  • Legacy Issue Number: 9529
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    The CacheListener currently supports only two call-backs to signify the start and end of an update round. However because listeners are only used in enabled update mode it is important that when the DLRL switches between the enabled and disabled update mode that the listeners are notified, as the switch between update modes does not necessarily originate from the thread that registered the listener as well, and the fact that updates are enabled or disabled is a major event that should be known by the listeners.

    Proposed Resolution:

    Add two methods to the CacheListener interface, one for signalling a switch to automatic update mode, and for for signalling a switch to manual update mode.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Merge find_object with find_object_in_access

  • Key: DDS12-50
  • Legacy Issue Number: 9532
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    Currently there are separate methods to find a specific object based on its OID in the Cache and in a CacheAccess. It would be nice to have one method to search for an Object in any CacheBase.

    Proposed Resolution:

    Add a CacheBase parameter to the find_object method and remove the find_object_in_access method.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

define both the Topic name and the Topic type_name separately

  • Key: DDS12-49
  • Legacy Issue Number: 9531
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    XML mapping file does not allow you to define both the Topic name and the Topic type_name separately

    Summary:

    In the DCPS, there is a clear distinction between a topic name and a topic type. (Both names must be provided when creating a Topic). However, the DLRL mapping XML only allows us to specify one name attribute which is called ‘name’. It is unclear whether this name should identify the type name or the topic name. Currently we just have to assume that the topic name and type name are always chosen to be equal, but that does not have to be the in a legacy topic model.

    Proposed Resolution:

    Add a second (optional) attribute to the mainTopic, extensionTopic, placeTopic and multiPlaceTopic that identifies the type name. If left out, the type is assumed to be equal to the topic name.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification does not state how to instantiate an ObjectHome

  • Key: DDS12-54
  • Legacy Issue Number: 9536
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    There is no (default) constructor specified for the ObjectHome class. Nowhere in the specification it is specified how an ObjectHome should be instantiated and what the default values will be for auto_deref and for the filter expression.

    Proposed Resolution:

    Explicitly state that the default constructor should be used to instantiate an ObjectHome. Also state that by default the value of auto_deref will be set to true, and the filter expression will be set to NULL. Setting auto_deref to true by default ensures that the application developer has to make the conscious decision to set the auto_deref functionality to false for performance gain, which is more natural then the other way around
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

manual mapping key-fields of registered objects may not be changed

  • Key: DDS12-53
  • Legacy Issue Number: 9535
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Indicate that in case of manual mapping key-fields of registered objects may not be changed

    Summary:

    When using the DLRL with pre-defined mapping, keyfields of the topic can be mapped to ordinary attributes of a DLRL object. However, chaning these attributes on the DLRL object results in a change of identity on DCPS.

    Proposed Resolution:

    Do not allow attributes that are mapped to key fields in the underlying Topic to be modified after the DLRL object has been registered. Throw a PreconditionNotMet Exception if this rule is violated.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    No Data Available
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove lock/unlock due to overlap with updates_enabled

  • Key: DDS12-46
  • Legacy Issue Number: 9528
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    It is not clear why we should need a lock/unlock on the Cache when we can turn on and off the automatic updates. If an application does not want to be interrupted by incoming updates, it can simply disable the automatic updates, re-enabling them afterwards.

    Proposed Resolution:

    Remove the lock and unlock methods of the Cache.

  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    Remove the lock and unlock methods of the Cache
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make update rounds uninterruptable

  • Key: DDS12-45
  • Legacy Issue Number: 9527
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    According to the current specification, it is possible to interrupt an update round, by invoking the disable_update mehod in the middle of such an update round. This makes no sense, since it can leave the Cache in an undefined and possibly inconsistent state. The specification does also not explain how to recover from such a state.

    Proposed Resolution:

    Make sure that the automatic update mode can never be changed while in the middle of an update round. This way, update rounds can never be interrupted and the Cache will always be in a consistent state. This also removes the need for the interrupted and update_round parameters in the callback methods of the CacheListener.
    Also remove the related_cache parameter from the CacheListener, since it is not needed and is also missing in the IDL.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Raise PreconditionNotMet when changing filter expression on registered Obje

  • Key: DDS12-55
  • Legacy Issue Number: 9537
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Raise a PreconditionNotMet when changing a filter expression on a registered ObjectHome

    Summary:

    ObjectHome contains a set_filter method to set the filter attribute. This method may only be called before an object home is registered. However the only exception that is thrown is the BadParameter exception. We believe this exception does not cover the fact that the set_filter can be called after the objecthome is registered, as bad parameter is not a good description for the error that should be generated then.

    Proposed Resolution:

    Raise a PreconditionNotMet Exception when the set_filter method is invoked after the ObjectHome has been registered to a Cache.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add a static initializer operation to the CacheFactory

  • Key: DDS12-44
  • Legacy Issue Number: 9526
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    From the current DLRL specification it is not clear how to obtain your initial CacheFactory.

    Proposed Resolution:

    Add a static get_instance method to make the CacheFactory a singleton, just like we did for the DomainParticipantFactory in the DCPS.
  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use compliant OMG IDL syntax

  • Key: DDSIRTP22-7
  • Legacy Issue Number: 16956
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    IDL is defined by OMG’s own document formal/2011-11-01 in section 7. As another OMG specification (and most importantly, for clarity and precision), the current pseudo-IDL throughout the RTPS document must be changed to be actual compliant IDL. Compliant IDL does not use anonymous types: newly-constructed types appear in their own typedefs.
    Section: 9.2.2
    Page: 149
    Change: replace IDL with
    typedef octet OctetArray3[3];
    struct EntityId_t

    { OctetArray3 entityKey; octet entityKind; };

    Section: 9.3.1.1
    Page: 150
    Change: replace IDL with
    typedef octet GuidPrefix_t[12];

    Section: 9.3.1.2
    Page: 150
    Change: replace IDL with
    typedef octet OctetArray3[3];
    struct EntityId_t { OctetArray3 entityKey; octet entityKind; }

    ;

    Section: 9.3.1.5
    Page: 153
    Change: replace IDL with
    struct GUID_t

    { GuidPrefix_t guidPrefix; EntityId_t entityId; }

    ;

    Section: 9.3.2, Table 9.4 row “Time_t”
    Page: 153
    Change: replace IDL with
    struct Time_t

    { long seconds; unsigned long fraction; }

    ;

    Section: 9.3.2, Table 9.4 row “VendorId_t”
    Page: 153
    Change: replace IDL with
    typedef octet OctetArray2[2];
    struct VendorId_t

    { OctetArray2 vendorId; }

    ;

    Section: 9.3.2, Tables 9.4 and 9.5
    Page: 154-159
    Change: For ALL table entries with a struct move struct's identifier to directly follow the keyword "struct" (SequenceNumber_t, FragmentNumber_t, Locator_t, Count_t, ProtocolVersion_t, KeyHash_t, StatusInfo_t, ParameterId_t, ContentFilterProperty_t, ContentFilterInfo_t, OriginalWriterInfo_t, LocatorUDPv4_t) and in cases where "typedef" is used to introduce a struct, remove it (ProtocolVersion_t, ContentFilterProperty_t, ContentFilterInfo_t)
    Section: 9.3.2, Table 9.4
    Page: 155-157
    Change: Use of anonymous types is deprecated (applies to Locator_t::address, KeyHash_t::value, StatusInfo_t::value, all fields in ContentFilterProperty_t except for filterExpression). Replace the anonymous type with a typedef.
    Section: 9.3.2, Table 9.4
    Page: 157
    Change: Array bounds for FilterSignature_t must be at the end of the typedef
    Section: 9.4.2.6
    Page: 161
    Change: IDL syntax error due to use of anonymous types and the struct’s identifier must directly follow the keyword “struct”; also use unsigned long for bitmap
    Section: 9.4.2.8
    Page: 163
    Change: IDL syntax error due to use of anonymous types and the struct’s identifier must directly follow the keyword “struct”; also use unsigned long for bitmap
    Section: 9.4.2.11
    Page: 165
    Change: Use an unsigned short for “length” and mark this as "pseudo" IDL as there is no way to represent a sequence with a 2-byte length field or an array with runtime-determined bounds
    Section: 9.4.5.1
    Page: 168
    Change: struct’s identifier must directly follow the keyword “struct”
    Section: 9.6.2.1
    Page: 180
    Change: IDL syntax error due to use of anonymous types
    Section: 9.6.2.2
    Page: 181
    Change: IDL syntax error, the keyword "struct" is not used to identify types of fields. Also, IDL does not allow differences only in case so "WriterProxy writerProxy;" is ill-formed.
    Section: 10.1.1.1
    Page: 193
    Change: IDL syntax error, array bounds for Identifier must be at the end of the typedef, and the typedef keyword is missing.
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    In addition to making the IDL compliant, the reference to formal/2011-11-01 should
    added to the normative section.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typographical errors

  • Key: DDSIRTP22-6
  • Legacy Issue Number: 16953
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Section: 8.3.7.6.5
    Page: 56
    Change: In the expressions for reader and writer GUID, replace Heartbeat with HeartbeatFrag

    Section: 8.3.7.9.6
    Page: 59
    Change: InfoTimestamp should be section 8.3.7.10, not 8.3.7.9.6 which makes it a part of the InfoSource submessage
    Section: 8.4.7.5.1
    Page: 81
    Change: pseudocode line "IF ( DDS_FILTER"… is missing a ")" before "THEN"

    Section: 8.4.13.2, Pgh 1, line 2
    Page: 118
    Change: "Endpoinst" should be "Endpoints"

    Section: 8.4.13.5
    Page: 119
    Change: "ome" should be "one"

    Section: 8.4.14.1.4, last bullet
    Page: 121
    Change: "of" should be "or"

    Section: 8.4.15.7
    Page: 123
    Change: "sample logical" should be "same logical"

    Section: 8.7.1
    Page: 140
    Change: "WoS" should be "QoS"

    Section: 8.7.4
    Page: 145
    Change: "Submessges" should be "Submessages", "PIM" should be "PSM", "teh" should be "the", "Data_Object" should be "Data-Object"
    Section: 9.4.2.6
    Page: 162
    Change: A stray digit "1" appears to the left of expression that starts "(bitmap[deltaN/32]...". Also, parentheses are unbalanced in this expression: there must be one additional ")" before the "=="
    Section: 9.4.5.3.3, Paragraph 3
    Page: 171
    Change: Replace "skip any submessage headers" with "skip any submessage elements". Replace "fule" with "rule". Replace "the received will" with "the receiver will".
    Section: 9.6.2.1
    Page: 180
    Change: replace "tpe" with "type"

    Section: 9.6.2.2, Paragraph 6
    Page: 181
    Change: replace "teh" with "the"

    Section: 9.6.2.2.2, Table 9.12
    Page: 183
    Change: for consistency replace "0x001A" with "0x001a"

    Section: 9.6.3.3
    Page: 191
    Change: the paragraph that starts with "\Note" has a stray backslash
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Correction of the typographical errors
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Entity Name Parameter Id

  • Key: DDSIRTP22-5
  • Legacy Issue Number: 11073
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A DDS entity name could be serialized within a parameter list, so a corresponding unique parameter Id should be assigned.
    Resolution:
    Add parameter Id for Entity Name.
    Revised Text:

    Type PSM Mapping
    EntityName_t struct

    { string name;}

    EntityName_t

    Append to Table 9.11:
    Name ID Type
    PID_ENTITY_NAME 0x0062 EntityName_t
  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This issue was already resolved the suggested changes are already in the spec.
    Revised Text:
    Disposition: NoChange
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interpreting Liveliness Heartbeats

  • Key: DDSIRTP22-4
  • Legacy Issue Number: 11072
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    For better performance and simpler reliability, a liveliness heartbeat should be allowed to be a liveliness-only message without heartbeat semantics. As subclassed from a heartbeat, a liveliness heartbeat may trigger an ACKNACK response; to be a liveliness-only message, no ACKNACKs should be triggered. To enable this, setting the final flag should not trigger ACKNACKs.

    Resolution:
    A liveliness heartbeat with final-flag set must not trigger any ACKNACKs.

    Revised Text:
    Append to 8.4.2.3.2:

    The response is not required when a liveliness HEARTBEAT has both liveliness and final flags set to indicate it is a liveliness-only message.

    Revise statechart 8.24:
  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This issue was already resolved as part of the FTF, in that report it is labeled as
    issue 11043. It appears that a typographical mistake was made in the report (or else
    something changed in the database) so that the issue was not closed in the OMG
    database.
    Revised Text:
    Disposition: NoChange
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reader-side Heartbeat response suppression

  • Key: DDSIRTP22-3
  • Legacy Issue Number: 11071
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The specification does not prevent multiple Heartbeats from arriving in rapid succession. For example, the piggyback heartbeat of a repair message may immediately be followed by a periodic wildcard heartbeat. In order to prevent duplicate repair sessions, the specification should define heartbeat suppression on the reader's side. This heartbeat response suppression should be handled by a reader attribute that controls the duration for which duplicate heartbeats would be ignored.

    Resolution:
    Add reader attribute, heartbeatSuppressionDuration, that defines the duration in which received heartbeats are suppressed from triggering duplicate ACKNACKs.

    Revised Text:
    Revised figure 8.21:
  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This issue was already resolved as part of the FTF, in that report it is labeled as
    issue 11041. It appears that a typographical mistake was made in the report (or else
    something changed in the database) so that the issue was not closed in the OMG
    database.
    Revised Text:
    Disposition: NoChange
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify interoperability requirement 8.4.2.3.3

  • Key: DDSIRTP22-2
  • Legacy Issue Number: 11070
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The requirement contained in Section 8.4.2.3.3 is too restrictive and doesn't specify when resources can be reclaimed. If all Readers have acknowledged a sample, the Writer should be allowed to reclaim that sample's resources. Also, if a Reader NACKs a sample it has already ACKed, and the Writer is still able to provide a repair, it should.
    Resolution:
    Allow Writer to reclaim resources and send repairs if possible.
    Revised Text:
    Add the paragraph to the end of Section 8.4.2.3.3:

    Once a Writer has received positive acknowledgement from all Readers, the Writer can reclaim any associated resources. However, if a Writer receives a negative acknowledgement to a previously positively acknowledged sample, and the Writer can still service the request, the Writer should send the sample.
  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This issue was already resolved as part of the FTF, in that report it is labeled as
    issue 11037. It appears that a typographical mistake was made in the report (or else
    something changed in the database) so that the issue was not closed in the OMG
    database.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.7.3.5

  • Key: DDSIRTP22-10
  • Legacy Issue Number: 16960
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 52
    Change: Add parentheses around the subexpression: "(dataSize % fragmentSize) ? 1 : 0"
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Accept suggested change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.5.8

  • Key: DDSIRTP22-9
  • Legacy Issue Number: 16959
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 40
    Change: Time_t is underspecified. What real-world time does 0 represent?
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    No Change for this issue. Resolve as part of resolving 16975
    Revised Text:
    Disposition: NoChange
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.2.1.2, Table 8.2, Locator_t row

  • Key: DDSIRTP22-8
  • Legacy Issue Number: 16958
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 14
    Change: discriminator and port number using 4 octets each (insert the word “each”)
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Accept as submitted.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.2, Table 9.4

  • Key: DDSIRTP22-17
  • Legacy Issue Number: 16975
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 153
    Change: In NTP, TIME_ZERO represents a point in time in 1900. If this was followed by RTPS with its 31-bit field for positive seconds, the maximum point in time would be in 1968, long before RTPS was invented. Therefore the meaning of TIME_ZERO must be specified here. Additionally, leaving only 31 bits for positive seconds and assuming 1970 is used as TIME_ZERO, RTPS times are only valid through 2038. Is there a need for a sign bit in “seconds”?
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    The format used is similar to NTP in that is uses seconds and fractions of a second
    (to make arithmetic simple) rather than seconds and nanoseconds. However it uses
    a signed seconds such that signed arithmetic can be applied.
    For these reasons and to facilitate conversion to operating system times (timeval and
    timespec) the time origin TIME_ZERO is defined to be the Unix prime epoch 0h, 1
    January 1970
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.1.3, Table 9.2

  • Key: DDSIRTP22-16
  • Legacy Issue Number: 16974
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 151-152
    Change: All EntityId_t values should be shown with braces for the embedded array (see previous note)
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Change as suggested
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.4.5.1.3, Paragraph 3

  • Key: DDSIRTP22-19
  • Legacy Issue Number: 16977
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 169
    Change: This section refers to submessages larger than 64KB, which is impossible with UDP/IP.
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    No change: It is true that this is not needed for the UDP/IP PSM, but it is something
    that would be useful in other PSMs. By leaving it here it becomes possible to have
    the other PSMs refer to this section verbatim without having to add or modify the text.
    Revised Text:
    Disposition: NoChange
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.4.2.6 and 9.4.2.8 (last lines of each section)

  • Key: DDSIRTP22-18
  • Legacy Issue Number: 16976
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 163
    Change: The phase "does not follow strict CDR encoding" depends on an unspecified notion of "strict" vs. "nonstrict" CDR encoding where in actuality there is no such distinction. Remove the word "strict" to note that the wire representation is not following CDR rules. (This applies to both 9.4.2.6 and 9.4.2.8.)
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    see revised text
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.6.3.3

  • Key: DDSIRTP22-20
  • Legacy Issue Number: 16985
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 192
    Change: The "register" Lifecycle operation is not discussed, should it be indicated with a zero value for StatusInfo_t? This should be explicit in the spec.
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    The ‘register” operation is currently described as a local operation on the writer side
    and there is nothing in the specification requiring or preventing it from being
    propagated. From the reader perspective the registration will occur automatically the
    first time data is received for a particular instance.
    Most implementations do not propagate registrations, but in case some
    implementation chooses to do that we should clarify what the StatusInfo_t flags that
    would be associated with the submessage.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.7.7

  • Key: DDSIRTP22-13
  • Legacy Issue Number: 16971
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 146
    Change: There is no such "property list" feature in the DDS spec, this section should be removed.
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    There is an issue filed against the DDS spec to add these lists so once it is resolved
    this will no longer be an issue
    Revised Text:
    Disposition: NoChange
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.4.1.1, Item 16

  • Key: DDSIRTP22-12
  • Legacy Issue Number: 16962
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 65
    Change: DDS has no "finish" operation on DataReader
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    The operation should be called “return_loan”
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.1.1.1

  • Key: DDSIRTP22-22
  • Legacy Issue Number: 16987
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 193
    Change: This section should define the "options" field which is subsequently referenced.
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This is resolved as part of resolving 16989
    Revised Text:
    Disposition: NoChange (Merged)
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.1

  • Key: DDSIRTP22-21
  • Legacy Issue Number: 16986
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 193
    Change: Delete the last sentence of paragraph 2, the concept of a DDS "type-plugin" is not defined.
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This was already addressed as part of Issue 16955
    Revised Text:
    Disposition: NoChange (Merged)
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.7.8

  • Key: DDSIRTP22-14
  • Legacy Issue Number: 16972
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 146
    Change: Change "Persistent" level of DDS Durability to "Transient or Persistent levels" since due to DDS (v1.2 section 7.1.3.4) they both behave the same for the purpose of Original Writer Info.
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Accept suggested change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.1.1.1 and 10.1.1.2

  • Key: DDSIRTP22-23
  • Legacy Issue Number: 16988
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 194-196
    Change: In Table 10.1 and all examples, all Identifiers should be shown as

    {0x00, 0x0?}

    to indicate that they are two-element arrays. Showing it as a single two-byte value could lead to confusion about endianness.
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    replace as suggested
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.4.1.1, Figure 8.14

  • Key: DDSIRTP22-11
  • Legacy Issue Number: 16961
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 64
    Change: DDS has no "finish" operation on DataReader
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    The operation should be called “return_loan”
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.1.2

  • Key: DDSIRTP22-15
  • Legacy Issue Number: 16973
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Page: 150
    Change: ENTITYID_UNKNOWN is missing a level of braces to represent the embedded array inside the struct: {

    {0, 0, 0}

    , 0 }
  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    change as suggested
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency in close() operations wrt. "throw java.io.IOException" declaration

  • Key: DDSJAVA11-6
  • Legacy Issue Number: 18424
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The Entity interface inherits from java.io.Closeable and overrides the close() operation to NOT throw java.io.IOException. But some inherited entities such as DataReader and DataWriter might have to throw IOException on closure as their implementation might use sockets.

    On the other hand the Sample.Iterator interface also inherits from java.io.Closeable but its close() operation declare to throw IOException. There should not be any IOException in this case since the Samples are already received by the DaraReader
  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Operations with Collection as parameter should provide a "varargs" alternative

  • Key: DDSJAVA11-5
  • Legacy Issue Number: 18423
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The use of Collection for providing a single "parameter" is rather cumbersome and could be greatly improved by providing a "varargs" alternative.

    Here is an example that showcases the issue:
    p = dp.createPublisher(
    dp.getDefaultPublisherQos().withPolicy(
    pf.Partition().withName(Arrays.asList("MyPartition"))
    ));

    In this case a withName(String... names) operation will simplify the code as shown below:
    p = dp.createPublisher(
    dp.getDefaultPublisherQos().withPolicy(
    pf.Partition().withName("MyPartition")
    ));

    Moreover the use of Collection type could lead to compilation error as in the following case:

    statusCondition.setEnabledStatuses(Arrays.toList(DataAvailableStatus.class));

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

StatusCondition should be immutable and have fluent API

  • Key: DDSJAVA11-12
  • Legacy Issue Number: 18430
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The StatusCondition should be immutable and follow the same pattern than QoS policies:

    public interface StatusCondition<ENTITY extends Entity<?, ?>>
    extends Condition

    { /* statuses accessor */ public Set<Class<? extends Status>> getEnabledStatuses(); /* parent accessor */ public ENTITY getParent(); /* Copy this StatusCondition and override the value of the statuses */ public StatusCondition<ENTITY> withEnabledStatuses(Class<? extends Status>... statuses); }

    This allow simpler code such as following:
    waitset.attachCondition(
    reader.getStatusCondition().withEnabledStatuses(DataAvailableStatus.class));

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Error in Javadoc of DomainParticipantFactory.createParticipant(domain, qos, listener, statuses)

  • Key: DDSJAVA11-11
  • Legacy Issue Number: 18429
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The Javadoc description of the DomainParticipantFactory.createParticipant(domain, qos, listener, statuses) operation is following:

    "This operation creates a new DomainParticipant object having default QoS and no listener..."

    It should be replaced with following:

    "This operation creates a new DomainParticipant object with the specified QoS and the specified listener..."

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

In DomainParticipantFactoryQoS interface withPolicy() and withPolicies() have wrong parameters types

  • Key: DDSJAVA11-8
  • Legacy Issue Number: 18426
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In DomainParticipantFactoryQoS interface the following operation are defined:

    public DomainParticipantFactoryQos withPolicy(
    QosPolicy.ForDataWriter policy);

    public DomainParticipantFactoryQos withPolicies(
    QosPolicy.ForDataWriter... policy);

    In both operations the correct parameter type should be QosPolicy.ForDomainParticipantFactory.

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The PolicyFactory class misses operations for Presentation and TopicData creation

  • Key: DDSJAVA11-7
  • Legacy Issue Number: 18425
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The PolicyFactory class provides operation to create all Policies but Presentation and TopicData.

    Also, the Representation() operation should be renamed as DataRepresentation() to ensure consistency with the other factory operations (each is named accordingly to the type it returns).

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing "not"

  • Key: DDSJAVA11-16
  • Legacy Issue Number: 18652
  • Status: open  
  • Source: Software Pearls BVBA ( Laurence Vanhelsuwe)
  • Summary:

    "many of which do support Java EE"

    should be

    "many of which do not support Java EE"
  • Reported: DDS-Java 1.0b1 — Thu, 11 Apr 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The resolution of the FTF Issue 15966 was partially applied

  • Key: DDSJAVA11-15
  • Legacy Issue Number: 18582
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The resolution for the ISSUE 15996 required to remove all the operations of the kind:

    "public void setQos(String qosLibraryName, String qosProfileName);"

    from all DDS entities since this operation pollutes the DDS API with a specific way of configuring QoS policies. The accepted resolution was to introduce the concept of a QoSProvider that could provide QoS settings by fetching them from a URI.

    That said the type org.omg.dds.core.Entity still contains the operation:

    public void setQos(String qosLibraryName, String qosProfileName);

    This should be removed!
  • Reported: DDS-Java 1.0 — Wed, 27 Mar 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The DataReaderQos interface misses a getReliability() operation

  • Key: DDSJAVA11-10
  • Legacy Issue Number: 18428
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The DataReaderQos specifies accessors for all QosPolicy.ForDataReader policies but Reliability.
  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Error in implementation of TypeSupport.newTypeSupport()

  • Key: DDSJAVA11-9
  • Legacy Issue Number: 18427
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In TypeSupport class the newTypeSupport() operation is implemented as following:

    public static <TYPE> TypeSupport<TYPE> newTypeSupport(
    Class<TYPE> type,
    ServiceEnvironment env)

    { return newTypeSupport(type, type.getClass().getName(), env); }

    The correct implementation should be:

    public static <TYPE> TypeSupport<TYPE> newTypeSupport(
    Class<TYPE> type,
    ServiceEnvironment env)

    { return newTypeSupport(type, type.getName(), env); }

    Since type.getClass().getName() always return "java.lang.Class".

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

In WaitSet all waitForCondition() operations should return the triggered conditions

  • Key: DDSJAVA11-14
  • Legacy Issue Number: 18432
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    In WaitSet class, all waitForCondition() operation should return a Collection of the triggered conditions. The "activeConditions" parameter should be removed.

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

WaitSet should be aligned to the ISO C++ IDDS PSM

  • Key: DDSJAVA11-13
  • Legacy Issue Number: 18431
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The WaitSet class should be aligned to the ISO C++ IDDS PSM with regard to the dispatch() operation and associated functor.

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ModifiableInstanceHandle should be removed

  • Key: DDSJAVA11-2
  • Legacy Issue Number: 18420
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    The ModifiableInstanceHandle was not removed along with all other modifiable types.
    As such it should be removed for consistency, useability and performances.

    Specificaly the following methods should be removed:

    • ServiceEnvironment.newInstanceHandle()
    • DataReader.lookupInstance(ModifiableInstanceHandle handle, TYPE keyHolder)
    • DataWriter.lookupInstance(ModifiableInstanceHandle handle, TYPE keyHolder)

    And the following method should be modified to return InstanceHandle:

    • Sample.getInstanceHandle()
    • Sample.getPublicationHandle()

    Notice: the returning ModifialbeInstanceHandle forces defensive copying with obvious consequences in term of performances.

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The current Java PSM makes an implicit assumptions on member ordering

  • Key: DDSJAVA11-1
  • Legacy Issue Number: 16096
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The current Java PSM makes an implicit assumptions on member ordering when defining DDS Types in POJO that is not inherently guaranteed by the Java Language Specification. The possible resolution for this issue is to require @ID annotations when defining DDS Types using POJOs. In this case the ID would be used to uniquely defining the order to the attribute members.
  • Reported: DDS-Java 1.0b1 — Fri, 25 Mar 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bucket accessors shall be removed

  • Key: DDSJAVA11-4
  • Legacy Issue Number: 18422
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    Bucket accessors were supposed to be removed for all types (with exception of Time) as part of the FTF.
    Apparently some bucket accessors are still present (in some cases as the only possibility - e.g. Subscriber.getDataReaders()).

    This is very unfortunate since it forces defensive copies with the obvious performance impacts.
    Furthermore it makes the API inconsistent.

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

RequestOffered.requestedOfferedContract() semantic should be removed

  • Key: DDSJAVA11-3
  • Legacy Issue Number: 18421
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    Instead of providing the requestedOfferedContract() method for RxO comparison, the inherited Compare implementation should follow the RxO rules.

    For instance: Deadline(2) > Deadline(5)
    This change simplify the API and avoids the creation of temporary object when trying to evaluate RxO. Notice that, in this case, the natural ordering is still available via the Duration type.

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Durability Implementation Description does not consider the role of partitions

  • Key: DDS15-187
  • Legacy Issue Number: 19649
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The third paragraph of the DURABILITY section (2.1.3.4) describes the semantics that has to be provided by a durability service for TRANSIENT and PERSISTENT topics. Specifically, it states that given a Topic T with DURABILITY QoS set to TRANSIENT or PERSISTENT then the "built-in fictitious" DataReader and DataWriter used by the Durability Service to receive/distribute data have to be created with the same QoS T. Yet, nothing is said with respect to the role of the PARTITION QoS. Section 2.1.3.13 clearly states that:

    "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."

    Thus based on the current specification the Durability Service DataReader and DataWriter would only match the applications DataReader and DataWriter that are in the default partition.

  • Reported: DDS 1.4 — Wed, 29 Oct 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT