Issues for Mailing list of the DDS Interoperability Finalization Deadline

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 11034: Rename BuiltinEndpointKind and add description
Issue 11070: Clarify interoperability requirement 8.4.2.3.3
Issue 11071: Reader-side Heartbeat response suppression
Issue 11072: Interpreting Liveliness Heartbeats
Issue 11073: Add Entity Name Parameter Id

Issue 11034: Rename BuiltinEndpointKind and add description (dds-interop-ftf)

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

Resolution:
Rename the type from BuiltinEndpointKind to BuiltinEndpointSet_t. Provide an entry in Table 9.4 to describe the type.

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.

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:

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:

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