-
Key: DDSXTY14-53
-
Status: open
-
Source: ZettaScale Technology ( Mr. Erik Hendriks)
-
Summary:
Section 7.6.3.3.4 states the following sentence on how to encode the Participant GUID into the dds::rpc::RequestHeader:
The Service instanceName that appears in the dds::rpc::RequestHeader shall be set to the string obtained by concatenating the prefix “dds.builtin.TOS .” With the 16-character string version of the DomainParticipant GUID encoded using hexadecimal digits with lower case letters. There shall be no “0x” ahead of the hexadecimal digits. For example, “dds.builtin.TOS.123456789abcdf0”
This seems to imply that you need to encode the Participant GUID as a 16 digit hexadedecimal string, which wouldn't allow you to represent the entire GUID. Probably the 16 bytes do no intend to refer to the hexadecimal digits of the string representation, but rather to the 16 bytes of the GUID itself. A couple of paragraphs further down it refers to the DDS-RPC spec, where indeed the 16 byte restriction is not mentioned:
The dds::rpc::RequestHeader in the TypeLookup_Request and the TypeLookup_Reply shall be set as specified in the [DDS-RPC] specification.
-
Reported: DDS-XTypes 1.3b1 — Mon, 20 Dec 2021 16:09 GMT
-
Updated: Tue, 21 Mar 2023 15:36 GMT
DDSXTY14 — Description on how to encode Participant GUID in dds::rpc::RequestHeader seems wrong
- Key: DDSXTY14-53
- OMG Task Force: DDS Extensible Types (DDS-XTYPES) 1.4 RTF