Issue 12500: Add implementation note on not serializing redundant info in builtin topic                                                                                                                              (dds-interop-rtf)
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken@rti.com ken.brophy@rti.com)
Nature: Uncategorized Issue
Severity: 
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.
  

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 (Simple Discovery Protocol built-in Endpoints), right before section 9.6.2.2.1 (ParameterId space) the following paragraph::

For optimization, implementations of the protocol may choose not to include a parameter in the Data submessage if it contains information that is redundant with other parameters already present in that same Data submessage.  As a result of this optimization an implementation can omit the serialization of the parameters listed in Table 9.10 

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

Actions taken:
May 20, 2008: received issue
Discussion: 

End of Annotations:=====
MG Issue No:  12500R#2
Title:	Add implementation note on not serializing redundant info in builtin topic data
Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
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.
  
Disposition: