Sections are:

7.3.1.9 Map Types
Map types as described in this specification are fully compatible with the IDL constructs of the
same name defined in the Extended Data-Types Building Block of [IDL].
Structures as defined by this specification are fully compatible with the IDL constructs of the
same name.
7.3.1.10 Structure Types
Structures as described in this specification are fully compatible with the IDL constructs of the
same name.

"Structures as defined by..." is duplicated twice.

When serializing a sequences of non-primitive elements, the XTYPES spec requires serializing a DHEADER ahead of serializing the number of elements and each element. This is rule (12)

Arrays of non-primitive elements also serializing the DHEADER but not the number of elements. This is rule (9)

I think it would make sense to modify or at least relax these rules.
At a minimum arrays and sequeces of enumerated types and bitmask types should not have a DHEADER as it does not add information beyond what is available knowing the number of elements and size of each element. That it, they should behave as primitives (basically they are integers).

Additionally it may be better to not have the DHEADER at all for sequences and arrays. Or at least for sequences or arrays whose elements are final.

Basically the "extensibility" of the sequence is already handled by having the number of elements and having a DHEADER adds nothing and makes types that contain sequences of FINAL incompatible with XCDR1. This is a side-effect that we did not want or anticipate. Otherwise types that are constructed from only FINAL types would be compatible between XCDR1 and XCDR2 (except for 8-byte aligned types).

The goal of this issues is to identify incorporate any additions that would allow systems built using DDS-Security to meet the CNSSP-15 security requirements.
https://imlive.s3.amazonaws.com/Federal%20Government/ID151830346965529215587195222610265670631/CNSSP15.pdf)

This is an important requirements for many systems and we are running into many users that are asking whether DDS-Security can be used to meet CNSSP-15 security requirements.

It seems like currently the "builtin plugins" are not enough because they do not include support for stronger asymmetric key algorithms. For example when using ECDSA digital signatures the minimal requirement is using 384-bit keys (e,g, NITS's Curve P-384). However the builtin plugins only include support for 256 bit EC keys.

The description of PUSH states:
```
Pushes the specified XCDR stream variable VARIABLE
into the stack and sets the current value to <newvalue>.
The notation <?> indicates that the new value can be
chosen by the implementation.
This action is reverted by the POP() operation
```
However the first serialization rule that writes the HEADER calls `PUSH(ORIGIN=0)` after writing the ENCHEADER, even though it's already been set to 0 on initialization. PUSH(ORIGIN=0) is also called after writing PL_CDR headers. I'm confused as to what this is supposed to mean. Based off of the current definition of PUSH I would be lead to believe that it truly does set the origin equal to 0. However looking at it's usage I would think that PUSH(ORIGIN=0) should mean that the origin is reset to where the current offset is, and based of of what I've seen in PL_CDRv1 messages with 8 byte members, this has been a correct assumption.
Another confusing element around the usage of PUSH is that I don't see POP used anywhere in the Serialization rules.

1. In the specification and xsd file，can not find that how to describe the locator information of the domain participant such as metatrafficUnicastLocator or defaultUnicastLocator.
2. When the topicKind of a topic is WITH_KEY, how to describe the corresponding key-value information of the DateWriter in the "data_writer" part.
3. If user can add some bolcks that user defined and if there are some rules?
4. There are no "uint8" or "int8" in the the simpleType whose name is "allTypeKind" in the xsd file whose name is "dds-xml_type_definitions_nonamespace.xsd". But there are the definition in chapter "7.3.2.2 Basic Types" of the specification "Extensible and Dynamic Topic Types for DDS"(DDS-XTypes)

Starting with DDS-XTYPES version 1.2 a data type can be serialized using XCDR version 1 or version 2. This impacts the serialization of APPENDABLE and MUTABLE types. It does not impact the serialization of FINAL types unless they contain 8-byte primitives (long long or double) or optional members.

DDS-Security was written before DDS-XTYPES 1.2 came out. So all the products are using XCDR version 1.

Going forward DDS-Security should specify that it always uses XCDR version 1 for serialization of the types defined in the specification.

The InfoSource is meant to hold the same information inside the RTPS message such that an RTPS message can be used to relay RTPS submessages from other sources and the RTPS submessages are interpreted in the correct content of the originating Participant.

The RTPS Header Extension submessage was added to extend the RTPS Header in a way that did not break interoperability with existing systems. So logically the information inside RTPS Header Extension belongs in the RTPS Header. Therefore it should also be added to the InfoSource

The union TypeIdentifier definitoon in Annex B contain several cases commended out. This is done because (per the comment in the IDL) union cases all have to have an associated member/value

// All primitive types fall here.
// Commented-out because Unions cannot have cases with no member.
/*
case TK_NONE:
case TK_BOOLEAN:
case TK_BYTE_TYPE:
case TK_INT8_TYPE:
case TK_INT16_TYPE:
...

Since the union discriminator is an octet, it is possible to set it to the values shown in the comment (e.g. TK_INT8_TYPE) in this situation since the case member is not shown the discriminator will be set but no branch would be selected so there is no associated value.
In other words, we can get the desired behavior of having the discriminator set but no value selected (so nothing beyond the discriminator is serialized), but we cannot express the expectation of all those cases in the IDL...

This could be corrected in two ways:
(1) We could use a enumerated value with @bit_bound(8) as the type of the discriminator instead of the octet. The list of literals would make it obvious what the expected values for the discriminator
(2) We could keep the union discriminated by an octet and uncomment all the cases for the primitive types. Then we would need to add a "dummy" member so the case has an associated value, but we could mark it @non_serialized so it has no impact on the wire representation.

It would seem that (1) is cleaner but (2) is less disruptive...

It's not clear how a user of a DynamicData object that represents a union gets the discriminator value. We derive the following:

// see pgh 1 of 7.2.2.4.4.3 for use of "discriminator" as a magic string
const MemberId id_disc = dyndata->get_member_id_by_name("discriminator"); 
if (id_disc == MEMBER_ID_INVALID) { some error happened }
// based on union_type_descriptor.discriminator_type->get_kind(), determine the type of the discriminator
// in this example, let's say it's an IDL long
int val;
dyndata->get_int32_value(val, id_disc);

It would be better for the spec to have a clearly defined way of getting a MemberId that represents the discriminator. It could be a new API in DynamicType or TypeDescriptor.

Section 8.2.1 Message Module says:

To provide a deterministic behavior and a deterministic message size, DataWriters associated with an TsnTalker in the Deployment configuration (see subclause 7.2.3.1) may need to limit their RTPS Message exchange to RTPS Messages that include the following RTPS Submessages:
• InfoTimestamp
• Data
• DataFrag

This should be expanded to include the RTPS HeaderExtension as well as GAP.

Later in the section there is an explanation of why GAP may not be needed:

RTPS Submessages responsible for achieving reliability or in-order delivery, such as Gap, AckNack, NackFrag; as well as the rest of Interpreter Submessages, may be sent as part of “Best Effort” Streams. However, given the guarantees of the underlying TSN system, this sort of traffic may be unnecessary for TSN-enabled DataReaders and DataWriters. Also, retransmissions and other types of aperiodic traffic may fail to meet the schedule and configuration of the TSN Streams associated with the delivery of time-critical data.

However GAP is not just for reliability or in-order delivery. It is also used in best-efforts in situation where a sample is not relevant to a reader (e.g. because of writer-side content filtering), even if the sample is sent best-efforts.
Gaps are needed to distinguish lost samples from samples that are intentionally-skipped. If the gap is not present, the reader side will interpret non sequential sequence numbers as sample loss, impacting status variables in in the DataReader.

The specification does not address whether DDS-Security can be deployed on top of TSN.
The logical assumption would be yes, but then the use of the RTPS sub-messages introduced by DDS security (e.g. SRTPS_PREFIX) should be mentioned.

DomainTag was added to DDSI-RTPS as a mechanism to further identify/isolate DDS Domains beyond the separation provided by the DomainId. For two participants to be on the same domain both the DomainId and the DomainTag (a string) must match. The domain-tag string matching is literal (strcmp() character by character) there is no expressions.

Resulting from this it makes sense to add support for them to DDS security, without this support there would be no way to have different governance or permissions for domains that differ only on the DomainTag.

Adding support will impact the SPIs (e.g. extra parameters on validate_local_identity, validate_local_permissions, and most of thje check_operations. Operations that currently take the DomainId_t as a parameter should be expanded to also take a DomainTag.

Adding support will impact Governance and Permissions files.
E.g. the DomainIdSet should which is used on both files be expanded to incorporate domain tags.

Topic uses the DDS::Time_t which rolls over at 2038.
We should update to the newer definition to be adopted in DDS 1.6

We may need to use a different type name to allow both to co-exist
Curent definition is this:

extensibility(APPENDABLE) // After DDSSEC12-29
struct BuiltinLoggingType {
    octet  facility;  // Set to 0x0A (10). Indicates sec/auth msgs
    LoggingLevel severity;
    Time_t timestamp; // Since epoch 1970-01-01 00:00:00 +0000 (UTC)
    string hostname;  // IP host name of originator
    string hostip;    // IP address of originator
    string appname;   // Identify the device or application 
    string procid;    // Process name/ID for syslog system
    string msgid;     // Identify the type of message
    string message;   // Free-form message

    // Note that certain string keys (SD-IDs) are reserved by IANA
    map<string, NameValuePairSeq>  structured_data; 
};

IdentityStatusToken, AuthenticatedPeerCredentialToken, AuthRequestMessageToken are specified in Table 46, Table 47, Table 48 of the DDS Security 1.1 spec. as containing "properties".

This is inconsistent with the description of HandshakeRequestMessageToken, HandshakeReplyMessageToken, and HandshakeFinalMessageToken. These specify binary_property.

They should be consistent. In fact AuthRequestMessageToken specifies that the content of the property with key "future_challenge" should match what is sent in HandshakeRequestMessageToken "challenge1"

It appears vendors are all using binary_properties as they are all interoperating. Therefore Table 46, Table 47, Table 48 should be modified to say "binary_property' for the attribute name.

In 9.4.1.3.2 Grant Section, the spec states:

"A permissions [sic, should be grant] Section with a subject name that does not match the subject name given in the corresponding Authorization certificate shall be ignored."

It is not clear what algorithm should be applied to determine if two subject_names "match"; and this has interoperability implications.

A 'simple' approach would be a simple string comparison.

A 'complex' approach would be to do the following:

1) parse each subject_name as a series of name=value pairs,
2) check that all name's exist in each subject_name
3) check that for each name, the corresponding 'value' matches, using regex (for example fnmatch(), or similar) processing.

The more complex approach might be beneficial, because it could support using a 'wildcard' Common Name. For example, in the permissions file, use a Subject Name like this:

      <subject_name>/C=US/ST=CO/O=Twin Oaks Computing/CN=*.twinoakscomputing.com/emailAddress=support@twinoakscomputing.com</subject_name>

Then, the Identity Cert's could be constructed with a more specific Subject Name, like "CN=participant1.twinoakscomputing.com", and it would match.

The DDS Security version 1.1 specification mentions:

If the Participant Private Key is a RSA key, then:

The value of the c.dsign_algo property shall be “RSASSA-PSS-SHA256”.
The digital signature shall be computed using the RSASSA-PSS algorithm specified in PKCS #1 (IETF 3447) RSA Cryptography Specifications Version 2.1 [44], using SHA256 as hash function, and MGF1 with SHA256 (mgf1sha256) as mask generation function.
This RFC is the one aforementioned. It states:

This encoding method is parameterized by the choice of hash function, mask generation function, and salt length. These options should be fixed for a given RSA key, except that the salt length can be variable (see [31] for discussion). Suggested hash and mask generation functions are given in Appendix B.

In the appendix, we can see an example where the salt length is the same as the hash length:

RSASSA-PSS-params ::= SEQUENCE
Unknown macro:
Unknown macro:

However, the salt length doesn't have to be the hash length. The WolfSSL and OpenSSL crypto libraries support several options (Openssl doc here and WolfSSL doc here). Our current approach is to use OpenSSL's default option: "maximum permissible value" (pkcsBlockLen - hLen - 2) when signing and auto (detect salt length from the signature) when verifying.

proposed solution
The specification should mention the salt length used when generating the signature. Otherwise, it should say that auto must be used when verifying the signature. This would allow interoperability (WolfSSL for example doesn't use auto by default).

The check_create_participant entry of "Table 63 - Actions undertaken..." in the case where is_access_protected is true and all topic entries in Governance have enable_read_access_control and enable_write_access_control both true specifies that check_create_participant returns false. Thus the participant can't be created and this configuration won't be usable.

If the intent of enable_read/write_access_control is to defer to the Permissions document to determine both readability and write-ability of this participant (for the given topic) it would seem like this case should be supported and allowed by check_create_participant.

As part of resolving this issue we should also address DDSSEC12-85, meaning state whether a <default> clause should always be present.

The check_remote_participant row of Table 63 contains the text:

If the Permissions document contains a Grant for the remote
DomainParticipant and the Grant contains an allow rule on the
DomainParticipant domain_id, then the operation shall succeed and
return TRUE.

It seems like the intent is to ensure that there is some possible Action that this participant can do in the domain. That should take into account a <default>ALLOW</default> permission.

In general the <default> XML element seems to be not fully/consistently described in the section for Built-In Access Control. The xsd says it must be present, but section 9.4.1.3.2.3 says it may not be.

The HandshakeRequestMessageToken's dh1 property (Table 49) contains a Diffie-Hellman Public Key. The text of Table 49 says that this is encoded as a CDR Big Endian Serialization. However, the data type of the Public Key is neither a CDR Built-In type nor specified in IDL. Thus the encoding is underspecified.

Section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types cotntains the following IDL:

@Choice @Autoid
struct RobotControl_command_Result { 
    RobotControl_command_Out result;
};@Choice @Autoid
struct RobotControl_stop_Result { 
    RobotControl_getSpeed_Out result;
};
};@Choice @Autoid
struct RobotControl_setSpeed_Result {
      RobotControl_setSpeed_Out result;
      TooFast toofast_ex;
};
};@Choice @Autoid
struct RobotControl_getSpeed_Result {
      RobotControl_getStatus_Out result;
};

This IDL is not correct. It contains extra "};" preceding the @Choice annotations in several places. The correct IDL would be:

@Choice @Autoid
struct RobotControl_command_Result { 
    RobotControl_command_Out result;
};

@Choice @Autoid
struct RobotControl_stop_Result { 
    RobotControl_getSpeed_Out result;
};

@Choice @Autoid
struct RobotControl_setSpeed_Result {
      RobotControl_setSpeed_Out result;
      TooFast toofast_ex;
};

@Choice @Autoid
struct RobotControl_getSpeed_Result {
      RobotControl_getStatus_Out result;
};

The operations
check_create_participant
check_create_datawriter
check_create_datareader
check_remote_participant
check_remote_datawriter
check_remote_datareader
check_local_datawriter_match
check_local_datareader_match

Should be called when the Qos (or the discovery XXXBuiltinTopicData) change for the one of the involved entities.

This should be added to the proper 8.4.2.9.x sections.

The string literal "SessionKey" (and "SessionReceiverKey") is used without additional context as part of the binary input to HMAC. Add to this section that the ASCII encoding of "SessionKey" without a nul terminator is required.

Section 9.3.3.3.2 talks about a "bit array" type, clarify what that is.

In 7.3.5 (Immutability of Publisher Partition Qos in combination with non-volatile...)

The criteria (1) is not consistent with the goal stated at the end of the section about "prevents data that was published while the DataWriter had associated a set of Partitions from being sent to DataReaders that were not matching before the Partition change and match after the Partition is changed."

To accomplish this criteria (1) should be re-stated to say this impacts if the Topic associated with the DataWriter has TopicSecurityAttributes with is_read_protected set to TRUE.

In the definition of the various Handshake Tokens, certain property values are specified with literal strings in the spec (such as "RSASSA-PSA-SHA256"). Since these are inserted into binary_properties, the spec should describe the encoding: is there a length prefix (like CDR string?), is there a trailing nul (like CDR string?), assume the encoding is ASCII but it would be good to specify this.

Section 7.3.7.3 defines CryptoHeader as inheriting from CryptoTransformIdentifier. However CryptoHeader is APPENDABLE and CryptoTransformIdentifier is FINAL.

This does not seem possible according to XTYPES.

Other places of the spec (section 9.5.2.3 "DDS:Crypto:AES-GCM-GMAC CryptoHeader") define it as final.

The syntax in DDS-XML containes places where an object references another object. This is done normally using an attribute with type elementNameReference defined in http://www.omg.org/spec/DDS-XML/20170301/dds-xml_domain_definitions_nonamespace.xsd

However the specification does not deny any rules/constraints on the references themselves. In fact those references must follow a precise syntax to uniquely select an element which require a full path down the containment hierarchy down to the selected element.

The specification should define this and provide some examples.

The specification does not state what to do when Permissions and Governance files contain "extra elements" that are not valid according to the XSD.

This is expected to occur both as a result of vendor extensions as well as due to additions in future versions of DDS Security.

Allowing these extensions/additions without breaking compatibility is important. So the spec should be clear in that they are allowed and also provide rules/guidelines on them.

Some possibilities:

• Simply state that elements that are not expected/understood should be ignored
• Same as above but provide some structure for those elements. E.g. specify that they must have a "vendorId" attribute (used to avoid collisions) and a "mustUnderstand" attribute used to force failure in some cases.
• Define an "extensions" element that has known structure (e.g. name/value pairs) which is the one used for the extensions.
• Others to be proposed.

Common approaches are described here: http://www.ibm.com/developerworks/library/x-xtendschema/
This document also discusses various approaches: https://www.xml.com/pub/a/2004/10/27/extend.html

The specification provides mechanisms to extend the set of cryptographic algorithms in future revisions.
The specification also provides mechanisms to extend the set of cryptographic algorithms by a single vendor without requiring a revision of the standard. Those extended algorithms will be understood by the vendor and ignored by others.
What is not clear is if two vendors can agree to use another cryptographic algorithm and interoperate. This use-case may be relevant to an end-user that is using multiple vendors and wants to have those vendors work together to use a new crypto algorithm

This issue requests some mechanism to support this last use case.

There is an inherent DoS network amplification attack that exploits peer-to-peer discovery. See https://issues.omg.org/browse/DDSIRTP26-6

This issue should be addressed by DDS-Security. Likely using some pre-shared key mechanics to protect all messages not otherwise protected. For example, the authentication handshakes.

Section 7.4.1.3 'Reserved RTPS parameter IDs' reserves the whole 0x1000 to 0x1FFF (plus 0x5000 to 0x5FFF for must-understand) . That is 2 x 4096 PIDs. In reality DDS security only uses 6 PIDs... So this is a bit too much of a land grab.

It would be better to be more conservative and reserve a smaller range which can then be expanded as needed.

RTPS version 2.4 states that the reserved range for DDS security is 0x1000 to 0x10FF and 0x5000 to 0x50FF.

Section 7.4.1.3 should be updated to reflect this reduced range.

The RTPS specification allows implementations to send implementation-specific RTPS sub-messages inside an RTPS message. These submessages are distinguished by having submessageId's within a specific range.

Prior to DDS security skipping implementation-specific RTPS sub-messages was very efficient requiring only the receiver to jump their length indicated in. the header.
However with DDS security the submessages can be encrypted inside a SRTPS_PREFIX/SUFFIX envelope this requires the receiver to always decrypt them even if it will end up skipping them.
An extreme, but likely common case is when the SRTPS_PREFIX/SUFFIX contains exclusively implementation-specific RTPS sub-messages which makes the effort to decrypt the RTPS message fruitless.

A way to resolve this would be to designate a flag in the SRTPA_PREFIX submessage to indicate that the content contains only vendor-specific submessages. A receiver can use this flag to skip the whole RTPS message avoiding the effort to decrypt i n the event that the sender vendorId does not match the receiver's.

The proposal therefore is to designate the leftmost flag of the SRTPS_PREFIX submessage to indicate it contains only "vendor specific content".

Primarily targets environments that don't have multicast. Implementations support using a "discovery" service. In some cases it operates "transparently".

The SIG and vendors have discussed this and the conclusion was that it would be best to add tome description in the RTPS spec that explains how the discovery service would work and interoperate.

RTPS 2.3 section 9.4.5.3.1
"D=0 and K=1 means that the serializedPayload SubmessageElement contains the serialized Key."

XTypes section 7.4 "Data Representation" should define the rules for encoding an object of a type defined by the 7.2 "Type System" to a Key-only serialization.

Using what's currently in the spec, there are two potential interpretations:

a. follow all the encoding rules as for a full object (adding DHeader, EMHeader, etc.) but any part of that object that's not a key gets skipped, using 7.2.2.4.7 to determine what's a key

b. use the rules in 7.6.8 (which are explicitly only for a KeyHash) to get a KeyHolder object and then encode that

9.4.2.6 SequenceNumberSet defines one of the rules for validity as
bitmapBase >= 1

We have observed that other implementations use bitmapBase 0 in AckNack submessages. There seems to be no downside to just accepting these as valid even though the spec currently says they are not.

The RTF should determine if this condition in 9.4.2.6 can just be removed.

Both figures have get_member_id_by_index methods instead of get_member_id_at_index like the rest of the spec does.

Section 7.3.4.5 specifies that all struct and union members in TypeObjects are to be ordered by member index/declaration order.

•The elements in CompleteStructMemberSeq shall be ordered in increasing values of the member_index.
•The elements in MinimalStructMemberSeq shall be ordered in increasing values of the member_index.
•The elements in CompleteUnionMember shall be ordered in increasing values of the member_index.
•The elements in MinimalUnionMember shall be ordered in increasing values of the member_index.

There are comments in the IDL in front of the sequence typedefs for these members that also specify the order. The complete ones agree that they should be sorted by member index, but the minimal ones say they should be sorted by member id:

// Ordered by common.member_id
typedef sequence<MinimalStructMember> MinimalStructMemberSeq;
...
// Ordered by MinimalUnionMember.common.member_id
typedef sequence<MinimalUnionMember> MinimalUnionMemberSeq;

The spec states that @key members are always "must understand" does this mean that when represented in a TypeObject the member should also have the "must understand" flag set or is it enough with it being marked with the "key" flag as this would already imply its must understand nature?

Either way it should not impact assignability but it would impact the TypeId computation.

Typo, it says

@posiiton(2) XCDR2

but should say

@position(2) XCDR2

The class DynamicData inherits from Reference, but this class shouldn't behave differently from any other topic-type T, which (including the built-in types) are always value types.

The encoding of the TypeInformation member in the builtin topics should be explicitly specified. There is a normative comment on using XCDR2 for v1.3 types in the IDL, but this can be interpreted not to apply in the context of the builtin topics which are otherwise XCDR1.

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.

The XTypes spec seems to suggest that @must_understand fields are applicable to any non-final datatype. Section 7.3.1.2.1.9 mentions this:

"By default, the assignment from an object of type T2 into an object of type T1 where T1 and T2 are non-final types will ignore any members in T2 that are not present in T1. This behavior may be changed by applying the @must_understand annotation to a member within a type definition."

That would mean that @must_understand fields are also applicable to @appendable structs, but in this case there is no way for a field to be identified as must_understand field in its Delimited-CDR representation.

Of course you could state that in case of @appendable structs, you should determine assignability at discovery time and not at run time, in which case you are not dependent on the availability of a must_understand bit in the serialized blob. However, in case a Writer publishes a sample with a field that is both @must_understand AND @optional, according Table 19 (section 7.2.4.4.8) there is no mismatch between this Writer and a Reader that is missing the field (that is only the case if the field has @optional set to FALSE), which means the sample needs to be matched at runtime.

The spec is a little unclear of the semantics in this case: I guess that if the optional value is empty but must_understand you can slice it out of the projected type, but when it is not empty you are not allowed to slice the value out since it is a must_understand value and you will have to discard the whole sample instead. It would be nice if the spec could explicitly confirm or deny this.

But working from the presumption that you are indeed allowed to slice out values that are both empty and must_understand, the next problem arises immediately: how does a Reader know that a sample containing an unfamiliar field actually represents an optional field that is must_understand?

Let's consider a scenario where I have a Reader that is reading a type A with the following defintion:

@appendable struct A {
    @key long id;
     long x;
};

Now this Reader can be matched against all sorts of Writers, including Writers that have appended all kinds of fields to the end of this datatype: its deserializer simply slices everything out that comes after field x.

This works well for most appended versions of this datatype, but now suddenly an additional Writer joins the system with the following definition:

@appendable struct A {
    @key long id;
     long x;
    @optional @must_understand long y;
};

This Writer will match the Reader according to Table 19 since although the @must_understand annotation is TRUE, the corresponding @optional field is NOT false. So now the deserializer for our Reader has to deserialize a sample for which it doesn't know what the payload after the x actually represents. It might represent a value that it can safely slice out, or it might represent a value that may not be sliced out.

The spec states in rule number 20 of section 7.4.3.5.3 that in case of XCDRV2, an optional member is preceeded by a boolean called is_present. The problem here is that our deserializer doesn't know where the sample originates from therefore has no knowledge whether the byte following field x represent an is_present boolean or just some other sliceable field.

So the basic question boils down to this:

• Do we allow fields that are both must_understand and optional in case of Appendable extensibility?
• If so, how do we indicate in this case that a field is both optional and must_understand in a preferably backward compatible way?

Figure 16 defines bitset as another kind of aggregated type. One might assume that this has the semantics of an IDL4 bitset.

The text after Figure 16 and the rest of the spec doesn't define how bitset works in the type system (assignability), type representation, and data representation.

IDL value annotation for GAP is @value(8x08) instead of @value(0x08).

8.5.1.9.4 (4th pgh) describes that encode_rtps_message may determine that no encoding is necessary. This is currently an awkward fit with the common API design of returning a boolean and "setting" or "not setting" an exception struct. What does "not setting" the exception struct mean in practice? How does an implementation portably handle this?

It would be better to have an enum or integer return type so that the plugin can more directly influence the implementation's control flow, with distinct return values for OK_ENCODED, OK_NOT_ENCODED, ERROR, possibly others.

A similar issue occurs with decode_rtps_message (8.5.1.9.5). Because key exchange happens asynchronously with respect to encoded message transmission, the plugin may not be able to decode a given message. Simply "returning an exception" in this case is not ideal since the calling code should probably log this exception and it may raise alarms.

Extending this idea of enum (or integer constants) return types instead of boolean to other CryptoTransform operations may also be useful. For example, the other encode operations could return a OK_NOT_ENCODED instead of copying data.

DynamicTypeSupport has the following IDL definition in Annex C:

interface DynamicTypeSupport : TypeSupport {
  /* This interface shall instantiate the type FooTypeSupport
   * defined by the DDS specification where "Foo" is DynamicData.
   */
  /*static*/ DynamicTypeSupport create_type_support(
    in DynamicType type);
  /*static*/ DDS::ReturnCode_t delete_type_support(
    in DynamicTypeSupport type_support);
  DDS::ReturnCode_t register_type(
    in DDS::DomainParticipant participant,
    in ObjectName type_name);
  ObjectName get_type_name();
};

This definition can't be used in an XTypes implementation, at least in one using standard IDL. register_type and get_type_name can't use those names because a derived interface can't define operations that share names with ones in its base interfaces. This is described at the end of 7.4.3.4.3.2.1 in IDL 4.2. Another issue is the "static" operations. They get the point across as to what the author means but, they are also not usable as IDL can't define operations as static. DynamicTypeBuilderFactory and DynamicDataFactory also do this.

Table 8.42 defines the elements that comprise a DataFrag submessage. It includes the dataSize as one of those elements.

Section 9.4.5.5 must map all elements of the submessage to the PSM types. However, it is lacking a dataSize. Instead it includes a sampleSize. SampleSize should be renamed dataSize and perhaps should use a well-defined type from 9.3.2 such as MessageLength_t.

Section 8.3.3.1.2 indicates which version of the protocol is specified in this document.
No other place in the document should attempt to do the same, all others should refer back to 8.3.3.1.2. 8.3.3.1.2 should define the constant "PROTOCOLVERSION" as a symbol that indicates the current version (2.6). Add a reference to section 8.6 which defines how different versions can interoperate.

In Table 8.2:
In the cell to the right of ProtocolVersion_t, remove the text from "The following values are reserved..." until the end of the cell. Replace it with a reference to 8.3.3.1.2.

In Section 8.3.5.3:
Remove the text from "The RTPS protocol version X.Y defines..." until the end of this subsection. Replace it with a reference to 8.3.3.1.2.

In Section 9.3.2.1:
Remove the IDL comment

// The implementations following this version of the document
// implement protocol version 2.4

The spec uses two numbering schemes for bits:

For example 9.4.1 (Overall Structure)

0...2...........7...............15.............23. .............31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

But then in 9.4.4 (Mapping of the RTPS Header)

0...2...........8...............16.............24.............. 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should be consistent. The more correct scheme appears to be:

0...2...........8...............16.............24. .............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

With this scheme the number represents the number of bits that appear before the number (the "." positions). The other scheme seems inconsistent. "0" is placed ahead of the bit of that order, but '7' and the rest are placed after.

Add BITMASK_TYPE to table 9

LivelinessFlag in the last paragraph should be GroupInfoFlag, i.e.,
"The GroupInfoFlag is represented with the literal ‘G’. G=1 means the HeartBeat includes the currentGSN,
firstGSN, and lastGSN. The value of the LivelinessFlag can be obtained from the expression:"
should be changed to
"The GroupInfoFlag is represented with the literal ‘G’. G=1 means the HeartBeat includes the currentGSN,
firstGSN, and lastGSN. The value of the GroupInfoFlag can be obtained from the expression:"

Suppose the DATA_AVAILABLE StatusChangedFlag (see Figure 2.16) is set on a DataReader and then a listener (with DATA_AVAILABLE_STATUS in its mask) is attached to the DataReader by the user calling set_listener(). The specification does not specify if the listener should be invoked. If the decision is that the listener is not invoked, then guidance should be given to users that they may need to invoke the listener manually.

Details available to RTF members

Since "Core Data Types (Sub Clause 7.4.1 [IDL])" is included in the XTypes type system model, it needs to include "fixed"

TypeObject assumes that all union case labels are representable in a 32-bit integer:

// Case labels that apply to a member of a union type
// Ordered by their values
typedef sequence<long> UnionCaseLabelSeq;

Both IDL 4.2 and the general type system in XTypes (Figure 18, 7.2.2.4.4.3) allow 64-bit integer types as discriminators and therefore 64-bit values as case labels.

Section 7.3.4.9.2 describes the algorithm for computing type identifiers for strongly connected components. Step 4b says

If the Strongly Connected Component (SCC) has multiple types, then sort them using the lexicographic order of their fully qualified type name. Let SCCIndex(U) be the sort index of each type U belonging to the SCC starting with index 1 for the first type. For anonymous types concatenate the fully qualified name of the containing type with the member name using “.” as the separator, for example “MyModule::MyStruct.myMember”.

This does not cover all possibilities for anonymous types. To illustrate, the following IDL with recursive types uses an anonymous type in a typedef:

struct NodeData {
  long l_data;
};
struct TreeNode;
typedef sequence<@external TreeNode> Children;
struct TreeNode {
  NodeData data;
  Children children;
};

The algorithm requires a name for sequence<@external TreeNode>. In general, the rule for naming anonymous types in step 4b must be expanded to include anywhere an anonymous type may appear including structs, unions, typedefs, and other anonymous types.

An additional, related, problem is that given the definition of Plain...
7.3.4.1 “Plain types only have a TypeIdentifier. Non-plain types have both a TypeIdentifier and a TypeObject.”
the children field of TreeNode of the SCC example in 7.3.4.8 is a Plain Collection and has no TypeObject

struct NodeData {
  long l_data;
};
struct TreeNode {
  NodeData data;
  sequence<@external TreeNode> children;
};

Step 4(b)ii of the algorithm in 7.3.4.9.2 requires that all of the types in an SCC have a TypeObject 4(b)ii.
Possible Solutions and Notes:
The algorithm implies that all of the types involved in a Strongly Connected Component have a type identifier of TI_STRONGLY_CONNECTED_COMPONENT. The precludes the use of the Plain Collections in Strongly Connected Components. Thus, if the algorithm of 7.3.4.9.2 is not revised, then the definition of Plain Collections needs to be revised to exclude those involved in a Strongly-Connected Component.

DDS defines Time_t with seconds as long, this is 32bit. This will give an issue after 2038, almost all operating systems are now defining time as 64bit, shouldn't DDS do the same?

In addition, the the standard does not define the calendar time of Time_t at

This is required in order to convert a Time_t to/from a system's native time (such the the type time_t on Unix systems which has the calendar start time 1970-01-01 00:00:00).