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.

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.

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.

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.

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.

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.

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.

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.

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.

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)

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.

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

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++

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.

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.

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

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

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.

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

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.

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.

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

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.

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

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

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

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;

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,

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

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.

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

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.

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.

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

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.

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

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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

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.

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.

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.

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?

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.

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.

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.

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.

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

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.

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.

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"

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"

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.

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?

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.

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.

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

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.

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.

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.

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)

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

DDS uses IDL and defines its interface as regular interfaces, but these should all be local interfaces

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.