Issue 11050: Elaborate on Necessity and Usage of In-line QoS                                                                                                                                                         (dds-interop-ftf)
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken@rti.com ken.brophy@rti.com)
Nature: Uncategorized Issue
Severity: 
Summary: Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The RTPS specification state which QoS can appear in-line but does not offer background information to justify their usage.  The specification should elaborate on how in-line QoS are required for stateless implementations.

Resolution:
Elaborate on necessities and justifications for having in-line QoS to support stateless implementations.

Revised Text:
Revise 8.7.1, insert starting as third paragraph:

A stateless Reader's need for receiving in-line QoS to get information on remote Writers is the justification for requiring a writer to send in-line QoS if the reader requests them (section 8.4.2.2.2).

For immutable QoS, all RxO QoS are sent in-line to allow a stateless reader to reject samples in case of incompatible QoS.  Mutable QoS relevant to the reader are sent in-line so they may take effect immediately, regardless of the amount of state kept on the reader.  Note that a stateful reader has the option of relying on its cached information of remote writers rather than received in-line QoS.

Resolution: see above
Revised Text: Revise 8.7.1, insert starting as third paragraph:

A stateless Reader's need for receiving in-line QoS to get information on remote Writers is the justification for requiring a writer to send in-line QoS if the reader requests them (section 8.4.2.2.2).

For immutable QoS, all RxO QoS are sent in-line to allow a stateless reader to reject samples in case of incompatible QoS.  Mutable QoS relevant to the reader are sent in-line so they may take effect immediately, regardless of the amount of state kept on the reader.  Note that a stateful reader has the option of relying on its cached information of remote writers rather than received in-line QoS.

Actions taken:
May 23, 2007: received issue
November 7, 2007: closed issue
Discussion: 
Resolution:
Elaborate on necessities and justifications for having in-line QoS to support stateless implementations.

End of Annotations:=====
s is issue # 11050

Elaborate on Necessity and Usage of In-line QoS

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The RTPS specification state which QoS can appear in-line but does not offer background information to justify their usage.  The specification should elaborate on how in-line QoS are required for stateless implementations.

Resolution:
Elaborate on necessities and justifications for having in-line QoS to support stateless implementations.

Revised Text:
Revise 8.7.1, insert starting as third paragraph:

A stateless Reader's need for receiving in-line QoS to get information on remote Writers is the justification for requiring a writer to send in-line QoS if the reader requests them (section 8.4.2.2.2).

For immutable QoS, all RxO QoS are sent in-line to allow a stateless reader to reject samples in case of incompatible QoS.  Mutable QoS relevant to the reader are sent in-line so they may take effect immediately, regardless of the amount of state kept on the reader.  Note that a stateful reader has the option of relying on its cached information of remote writers rather than received in-line QoS.