Issue 12505: Change StatusInfo from SubmessageElement to Parameter (dds-interop-rtf) Source: Real-Time Innovations (Mr. Kenneth Brophy, ken@rti.com ken.brophy@rti.com) Nature: Uncategorized Issue Severity: 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. Resolution: Replace all instances of the statusInfo field of DATA with the new statusInfo inline parameter. Revised Text: Add to Table 9.4 (PSM mapping of the value types that appear on the wire) Type PSM Mapping StatusInfo_t struct { octet[4] value;} StatusInfo_t ============================================================= Add to Table 9.11 (ParameterId Values) Name ID type PID_STATUS_INFO 0x0071 StatusInfo_t ============================================================= Remove from Table 8.36 (Structure of the Data Submessage) rows corresponding to these elements: · StatusInfoFlag · statusInfo Modify the first paragraph in Section 8.3.5 (RTPS SubmessageElements) Remove the mention of StatusInfo. Remove Section 8.3.5.16 (StatusInfo) Remove from Figure 8.12 RTPS (SubmessageElements the StatusInfo class), the resulting figure is as shown in issue 12504 Remove from Figure 8.13 (RTPS Submessages), Data Submessage the StatusInfo field, the the resulting figure is as shown in issue 12503 Add section 8.7.4 Changes in the Instance LifecycleState after Section 8.7.3 (Content-filtered Topics) 8.7.4 Changes in the Instance LifecycleState Beyond writing data, a DDS DataWriter can register data object instances (operation register_instance) , update their value (operation write), dispose data-object instances (operation dispose), and unregister them (operation unregister_instance). Each one of these operations may cause notifications to be dispatched to the matched DDS DataReaders. The DDS DataReader can determine the nature of the change by inspecting the LifecycleState instance_state field in the SampleInfo that is returned on the DDS DataReader read or take call. RTPS uses regular Data Submessages and the in-line QoS parameter extension mechanism to communicate lifecycle changes. The serialized information within the inline QoS contains the new LifecycleState, that is, whether the instance has been registered, unregistered or disposed. The actual details depend on the PIM (e.g. see Section 9.6.3.4). An implementation of RTPS must use the Data Submessage to communicate a lifecycle changes. When doing so an implementation of RTPS is allowed to include only the Key of the Data-Object within the SerializedPayload submessage element (see Section 8.3.7.2). This is because the Key is sufficient to uniquely identify the Data_Object instance to which the LifecycleState change applies. An implementation of RTPS is not required to propagate registration changes until the DDS DataWriter writes the first value for that Data-Object instance. Add to Table 9.13 (ParameterId Values) Name ID type PID_STATUS_INFO 0x0071 StatusInfo_t Add to Table 9.14 (Inline QoS Parameaters) Name ID type PID_STATUS_INFO 0x0071 StatusInfo_t Add Section 9.6.3.4 StatusInfo_t (PID_STATUS_INFO) 9.6.3.4 StatusInfo_t (PID_STATUS_INFO) The status info parameter contains the CDR encoding of the StatusInfo_t. The StatusInfo_t is defined as a 4-Byte octet array (see Table 9.4) therefore the status info inline parameter just copies those 4 Bytes. The status info parameter may appear in the Data or in the DataFrag submessages. The StatusInfo_t shall be interpreted as a 32-bit worth of flags with the layout shown below: 0...2...........8...............16..............24..............32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|U|D| +---------------+---------------+---------------+---------------+ The flags represented with the literal 'X' are unused by this version of the protocol and should be set to zero by the writer and not interpreted by the reader so that they may be used in future versions of the protocol without breaking interoperability. The flags in the status info provide information on the status of the data-object to which the submessage refers. Specifically the status info is used to communicate changes to the LifecycleState of a data-object instance. The current version of the protocol defines the DisposeFlag and the UnregisterFlag. The DisposeFlag is represented with the literal 'D'. D=1 indicates that the DDS DataWriter has disposed the instance of the data-object whose Key appears in the submessage. The UnregisterFlag is represented with the literal 'U'. U=1 indicates that the DDS DataWriter has unregistered the instance of the data-object whose Key appears in the submessage. Actions taken: May 20, 2008: received issue Discussion: End of Annotations:===== MG Issue No: 12505R#7 Title: Change StatusInfo from SubmessageElement to Parameter Source: Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com) 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. Revised Text: Add to Table 9.4 PSM mapping of the value types that appear on the wire Type PSM Mapping StatusInfo_t struct { octet[4] value;} StatusInfo_t ============================================================= Add to Table 9.11 ParameterId Values Name ID type PID_STATUS_INFO 0x0071 StatusInfo_t ============================================================= Remove from Table 8.36 rows corresponding to these elements: · StatusInfoFlag · statusInfo Modify the first paragraph in Section 8.3.5 RTPS SubmessageElements Remove the mention of StatusInfo. Remove Section 8.3.5.16 StatusInfo TODO Remove from Figure 8.12 RTPS SubmessageElements the StatusInfo class TODO Remove from Figure 8.13 RTPS Submessages, Data Submessage the StatusInfo field TODO Add section 8.7.4 Changes in the Instance LifecycleState 8.7.4 Changes in the Instance LifecycleState Beyond writing data, a DDS DataWriter can register data object instances (operation register_instance) , update their value (operation write), dispose data-object instances (operation dispose), and unregister them (operation unregister_instance). Each one of these operations may cause notifications to be dispatched to the matched DDS DataReaders. The DDS DataReader can determine the nature of the change by inspecting the LifecycleState instance_state field in the SampleInfo that is returned on the DDS DataReader read or take call. RTPS uses regular Data Submessages and the in-line QoS parameter extension mechanism to communicate lifecycle changes. The serialized information within the inline QoS contains the new LifecycleState, that is, whether the instance has been registered, unregistered or disposed. The actual details depend on the PIM (e.g. see Section 9.6.3.4). An implementation of RTPS must use the Data Submessage to communicate a lifecycle changes. When doing so an implementration of RTPS is allowed to include only the Key of the Data-Object within the SerializedPayload submessage element (see Section 8.3.7.2). This is because the Key is sufficient to uniquely identify the Data_Object instance to which the LifecycleState change applies. An implementation of RTPS is not required to propagate registration changes until the DDS DataWriter writes the first value for that Data-Object instance. Add to Table 9.13 ParameterId Values Name ID type PID_STATUS_INFO 0x0071 StatusInfo_t Add to Table 9.14 Inline QoS Paramaters Name ID type PID_STATUS_INFO 0x0071 StatusInfo_t Add Section 9.6.3.4 StatusInfo_t (PID_STATUS_INFO) 9.6.3.4 StatusInfo_t (PID_STATUS_INFO) The status info parameter contains the CDR encoding of the StatusInfo_t. The StatusInfo_t is defined as a 4-Byte octet array (see Error! Reference source not found.) therefore the status info inline parameter just copies those 4 Bytes. The status info parameter may appear in the Data or in the DataFrag submessages. The StatusInfo_t shall be interpreted as a 32-bit worth of flags with the layout shown below: 0...2...........8...............16..............24..............32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|U|D| +---------------+---------------+---------------+---------------+ The flags represented with the literal .X. are unused by this version of the protocol and should be set to zero by the writer and not interpreted by the reader so that they may be used in future versions of the protocol without breaking interoperability. The flags in the status info provide information on the status of the data-object to which the submessage refers. Specifically the status info is used to communicate changes to the LifecycleState of a data-object instance. The current version of the protocol defines the DisposeFlag and the UnregisterFlag. The DisposeFlag is represented with the literal .D.. D=1 indicates that the DDS DataWriter has disposed the instance of the data-object whose Key appears in the submessage. The UnregisterFlag is represented with the literal .U.. U=1 indicates that the DDS DataWriter has unregistered the instance of the data-object whose Key appears in the submessage. Disposition: