Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
Section 220.127.116.11 (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 18.104.22.168 and specifically the definition of EMHEADER1 in table 39:
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 22.214.171.124.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.
Reported: DDS-XTypes 1.2 — Fri, 6 Jul 2018 00:09 GMT
Disposition: Resolved — DDS-XTypes 1.3
*Add a note to 126.96.36.199 'MemberId' indicating the range of member IDs. *
In section 188.8.131.52 (MemberId) add a reference to 184.108.40.206.4.4.4.
Updated: Tue, 8 Oct 2019 17:55 GMT