DDSXTY12 — Reserved parameter IDs in 7.4.1.2.1 are wrong

Found by: Fernando Crespo, RTI (fernando@rti.com)
Severity: Significant

Problem:
Table 27, "Reserved parameter ID values", in section 7.4.1.2.1, "Interpretation of Parameter ID Values", gives the 14-bit numeric IDs for the reserved parameters. However, it does not specify the corresponding values of the FLAG_IMPL_EXTENSION and FLAG_MUST_UNDERSTAND flags. The implication is that either flag may be set independently on an occurrence-by-occurrence basis, but that would be a bad idea: first of all, if FLAG_IMPL_EXTENSION is set, the specification should assume nothing about the contents of the parameter. And second of all, most parameters have a value of FLAG_MUST_UNDERSTAND that could reasonably be specified up front.

For example, and in particular, with respect to PID_EXTENDED, the text currently says: "The setting of the FLAG_MUST_UNDERSTAND bit in the 16-bit parameter ID shall be interpreted to apply to the extended parameter as well, not just to the 12 bytes of the PID_EXTENDED parameter itself." In other words, the flag is set based on the the must_understand attribute of a given member. This behavior is inappropriate, given that non-XTypes-conformant DDS implementations may receive extended parameters within discovery data: such implementations, if they do not see FLAG_MUST_UNDERSTAND set, will erroneously interpret the first four bytes of the (extended) data value as a parameter header, effectively corrupting the input data stream.

Proposed Resolution:
1. Clearly indicate that any parameter with FLAG_IMPL_EXTENSION set is outside of the scope of the specification. For a parameter to be recognized as one of the well-known values in the table, this bit must be set to zero.

2. Add a column to table 27 for the FLAG_MUST_UNDERSTAND flag. Set the value of this flag as follows:

• PID_EXTENDED: Yes. This will force non-XTypes-conformant implementations
  to discard data containing extended headers rather than parsing it
  incorrectly.
• PID_LIST_END: Yes. This will force implementations to either recognize
  the end of the list or to discard the data. It will avoid a situation
  where an implementation might "skip" the end of the list and start
  parsing out of bounds.
• PID_IGNORE: No. The whole point is to ignore this parameter.

3. When writing data, the Service shall conform to the setting of FLAG_MUST_UNDERSTAND indicated above. When reading data, the Service should be robust to the opposite setting as well and accept the parameter nevertheless.

4. Within the four-bit set of flags that has already been reserved within the extended parameter header, use the most-significant bit to indicate vendor-specific extensions and the second-most-significant-bit to represent the value of the must_understand value of a data member. These flags are parallel to the flags in the short parameter header and restore the flexibility lost by specifying up front the value of the corresponding flags in that header.

5. Do not leave the contents of the other flags in the extended parameter header with junk contents; if a given flag's value is not specified by some (other) OMG specification, it should be set to zero.

Fix and clearly specify the values of flags for parameters reserved in section 7.4.1.2.1

The values for flags FLAG_IMPL_EXTENSION and FLAG_MUST_UNDERSTAND are either not explicitly stated or are incorrect in section 7.4.1.2.1 "Interpretation of Parameter ID Values". We need to explicitly state the values and fix the values for extended parameters.

To resolve modify teh specification according to the five steps described as "proposed resolution" in the issue description.