Issue 12501: Include key in serialized ParticipantMessageData (dds-interop-rtf) Source: Real-Time Innovations (Mr. Kenneth Brophy, ken@rti.com ken.brophy@rti.com) Nature: Uncategorized Issue Severity: 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. Resolution: Change the description in Section 9.6.2.1 to not refrain from serializing the key of ParticipantMessageData. Revised Text: Remove following existing sentence from 9.6.2.1 (Data Representation for the ParticipantMessageData Built-in Endpoints): "On the wire, the participantGuidPrefix and the kind are not serialized as part of the ParticpantMessageData because they are already explicitly serialized as part of the Data Submessages (see Section 8.3.7.2)." Actions taken: May 20, 2008: received issue October 27, 2008: closed issue Discussion: End of Annotations:===== s is issue # 12501 Include key in serialized ParticipantMessageData Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com) 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. Revised Text: Remove following existing sentence from 9.6.2.1: .On the wire, the participantGuidPrefix and the kind are not serialized as part of the ParticpantMessageData because they are already explicitly serialized as part of the Data Submessages (see Section 8.3.7.2)..