DDSXTY13 — Clarify valid ranges of memberIDs

Section 7.5.2.5 (MemberId) states that

The type MemberId is an alias to UInt32 and is used for the purpose of representing the ID of a member of a structured type.

However it is clear from the serialization rules in 7.4.3.4 and specifically the definition of EMHEADER1 in table 39:

EMHEADER1 = (M_FLAG<<31) + (LC<<28) + M.id 

Where:
M_FLAG is the value of the Must Understand option for the member
LC is the value of the Length Code for the member.

That MemberId are restricted to a 28-bit range. This should be clarified in the specification.

Furthermore the specification should make it clear that the M_FLAG is not introducing a separate "space" of member IDs. So a type cannot have two members with the same value of the 28-bit memberID even if one has M_FLAG=1 and the other M_FLAG=0.

Additionally in section 7.4.1.2.1 (Interpretation of Parameter ID Values) where it talks about PID_EXTENDED it states:

The four bytes following the PID_EXTENDED and length shall be a serialized UINT32 value "eMemberHeader" that is constructed by combining four 1-bit flags with by the 28-bit member ID. The flags occupy the 4 most significant bits of the UINT32 value. The flags are combined with the memberId as shown below:
FLAG_1 = 0x80000000
FLAG_2 = 0x40000000
FLAG_3 = 0x20000000
FLAG_4 = 0x10000000
eMemberHeader = FLAG_1 + FLAG_2 + FLAG_3 + FLAG_4 + memberId

This text does not specify the reserved bit for the "FLAG_MUST_UNDERSTAND" and also in the case this is used for RTPS Discovery, the mapping for the "FLAG_IMPL_EXTENSION".

For compatibility with existing deployed systems the specification should state that FLAG_1 is the FLAG_IMPL_EXTENSION and FLAG_2 is FLAG_MUST_UNDERSTAND.

*Add a note to 7.5.2.5 'MemberId' indicating the range of member IDs. *

In section 7.5.2.5 (MemberId) add a reference to 7.2.2.4.4.4.4.