IDL identifiers may not reuse the same names (disregarding case) of types already in scope. This is a problem for "instanceName" in the RPC spec:

struct RequestHeader {
  SampleIndentity_t requestId;
  InstanceName instanceName;
};

And SampleIndentity_t is misspelled. It should be SampleIdentity.

This issue has also been entered into DDS-Security as the solution could also involve changes to that specification. See:
https://issues.omg.org/browse/DDSSEC12-31

DDS-RPC maps each DDS-Service to a single (unkeyed) Topic-pair (request topic & reply Topic).

DDS-Security provides access control per Topic and per Instance (Key). Moreover, the builtin plugins only provide access control per Topic.

With these mappings is it not possible to configure access control per operation/method in the service. This is a common requirement for many service definitions.

One way to overcome this would be to provide a mapping where each a Service would map to multiple Topic pairs. E.g. one Topic pair per method/operation. That way it would be possible to separately grant permissions to call operations on a service or to implement operations on a service.

The mapping of a Topic pair per method/operation would also setting different Qos per operation...

Alternatively one could

The DDS-RPC added a @Choice annotation (see 7.5.1.2.1.1 @Choice Annotation) to indicate a Structure with the "single-member" semantics of a union. As stated in the aforementioned section the reason was:

Using unions to indicate which operation is being invoked is brittle. Operations in an interface have set semantics and have no ordering constraints. Union, however, enforces strict association with discriminator values, which are too strict for set semantics. Further, use of unions leads to ambiguities in case of multiple inheritance of interfaces.

However XTYPES 1.2 enhanced unions which now support inheritance and are not so brittle anymore. For this reason it makes sense to re-evaluate this decision.

An advantage of using unions (beyond avoiding a extraneous annotation) is that their API is better oriented to identifying the one branch that is present; whereas in the case of structures there is no standard API available to determine which member is present other than iterating over every member. This would be unnatural for processing the RPC calls.

Section 7.5.1.1.4 Mapping of Interfaces to the Request Topic Types, and Section 7.5.1.1.5 Mapping of Interfaces to the Reply Topic Types, each define a union and specify that the union should have a 'default:' case.

This makes it difficult to extend the union to support interface inheritance.

The 'default:' case should be removed.

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.

In Addition in IDL42 all annotations are lower case. Specifically @autoid is defined there.

Therefore 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;
};

Section 8.3.1.2
What about collisions in the implied IDL types, hashes, etc. If a collision appears what are the rules to follow, because client and service could be developed by independent groups and DDS vendors which should than follow the same rules

What when the user has an interface with a user defined parameter with the name return_ and there is a return value? This leads to a clash in the generated struct

What when the user has an operation remoteEx in his interface IDL?

What if there is a clash between the const hash name and user defined IDL?

What is the behavior of @autoid with a hash-collision? Also what happens when operations are reordered at the moment there is a hash-collision? Couldn't that break interoperability?

Collision resolutions incorporated in multiple sections

The following collision resolution techniques have been incorporated

For the result struct, with IDL attributes it is possible to define separate exceptions with the set and the get of the attribute (getraises/setraises), this is not reflected in the result mapping

Added mapping for interface attributes and collision resolution

Added section 7.5.1.1.3

Section 8.5.1.1.3
For the result unions, why is not the unknownEx be part of the RobotControl_Return union as described on page 25, that would save a lot of union members. This exception is generic and independent of the operation.

Removed UnknowEx

Removed UnknownEx from Section 7.5.1.1.4

This issue is a subset of the DDSRPC-1 issue reported by Remedy.

IDL zip (mars/14-11-05)
rpc_types.idl:
Uses the RTI specific top-level annotation. Also top-level is illegal according to the IDL grammar.
Uses anonymous types
robot.idl:

In the 4rd paragraph it mentions “asynchronous invocations”, but this is not mentioned in 8.2.2.1, how do asynchronous invocations look like with the function call style in the basic profile?

Section 8.2.3
Where in this document is the API defined to get the request id at both sides for implicit or explicit?

Section 8.2.1
Why include space as part of user_def_alpha_num?

Section 8.5.1.1.1
Why is SequenceNumber_t not using an “unsigned long long”. It is now a struct but there is no explanation in the specification about high and low

Section 8.5.1.1.2
Why not put the implied types into a nested module so that they don't pollute the user IDL module and resulting code, doxygen documentation, etc

Section 8.5.1.1.4
Why not put the implied types into a nested module so that they don't pollute the user IDL module and resulting code, doxygen documentation, etc

What is the error when the remote service is not there (for example not running or not reachable), which exception do I get back?
What when the service crashes during handling of the request, what kind of error do I get back, what is the timeout? How can configure timeouts etc?

Section 8.7.1.3
What about changing the exception specification of an operation?
Section 8.8.2
Not a legal IDL struct definition, struct has to be removed from its members
Section 8.10.1
What about the library name RTI DDS currently supports. It is very helpful to have multiple QoS profiles in one file and the spec should define how this works

Added clarifications to the spec document or provided justifications

Added clarifications to the spec document or provided justifications below.

The following content is a subset of DDSRPC-1 issue reported by Remedy.

Document (mars/14-11-02)
Section 4
reference to CORBA should be updated to CORBA v3.3
reference to IDL should be updated to CORBA v3.3
reference for DDS4CCM lacks document number
reference for DDS-Cxx-PSM and DDS-Java-PSM should be updated to the formal version
reference to github, how can we in the future pinpoint the exact version of the files mentioned, shouldn't the reference be more explicit about which version?
reference to IDL 3.5 is lacking (used in section 8.3.1)
Section 5
Shouldn't there be a reference in section 4 for this quote?
Section 8.1
The spec talks about “communication patterns”, but in the context of UCM we are talking about “interaction patterns”, what about adopting the UCM term?
Section 8.2.1
Second paragraph, the fact that a content-based filter “is” used forces that everyone must do this (which is the most logical implementation), but shouldn't it be “could”
In the second paragraph its says “the service implementation contains a data reader to read the method name”, but shouldn't it be “the service implementation contains a data reader which receives the request and after that reads the method name and the parameters.”

Can't the diagram be placed after the first paragraph, it is now on the next page but we refer in text already to it).

Third paragraph, at the end “are filtered out”.

Section 8.2.3
Isn't it better to keep the term “client” instead of introducing “requester”

Section 8.2.5
“ it is” instead of “It is”
Section 8.3.1.2
Use a reference to DDS-XTypes in the first paragraph, not in the 3rd
Section xx

Section xx
The spec uses IDL anonymous types in some places, these are deprecated and prevented to our idea.
Section 8.4
“by the used,”??
Section 8.4.2.3
Reference error
Section 8.4.3.3
Reference error
Section 8.5.1.1.2
Space missing before “shall” on 3rd line

Section 8.5.1.1.4
Typo Non-noramtive

Section 8.7.1
Evolution should be evolution.
Section 8.8.2.1/8.8.2.2
Add a reference to where in this specification this language binding is provided

Correction have been incorporated

The suggested editorial corrections have been incorporated in the updated specification document.

Section 8.3.1
What about the support for modules in IDL. In larger systems it will almost get impossible to guarantee the uniqueness of an interface when multiple parts are integrated. Also with an UCM approach modules are the way to group interfaces together. The module is now completely left which could lead to problems in a larger system. To our idea a change of an interface to another module is something that RPC4DDS shouldn't silently adapt to

include module hierarcy to fully qualify interfaces

Replaced "unqualified" with "fully-qualified".

Section 8.10.1
What about the library name RTI DDS currently supports. It is very helpful to have multiple QoS profiles in one file and the spec should define how this works

Add optional library name at the end of the filename URL

The URL may end with an optional library name. The profile filename and library_name are separated by a #. For example, file://path/to/filename#library_name.

section 8.5.2
What is the mapping for the return codes when the regular IDL to IDL2C+, IDL2C+11, etc language mappings are used

*Clarified the mapping of remote error codes to IDL2C++11 *

Reworded section 7.5.2 as follows.

We still doubt the need to introduce @choice, with a union with the hash as discriminator value the is always one value active and there is a quick lookup at runtime. It works for the basic profile so why introduce this new IDL behavior for the enhanced one?

Clarification provided as the rationale

The following clarification has been provided as the rationale behind @Choice

It is our intent to support interface inheritance (including multiple inheritance) as cleanly as possible using the tools provided by DDS-Xtypes in the enhanced service profile. @Choice is added in response to that.
The following must be satisfied.
1. A requester must be able invoke operations in a service implementing an "evolved" version of the same interface (with more operations or fewer exceptions, etc.)
2. A base interface requester must be able to invoke operations in a service implementing a derived interface.
3. In case of multiple inheritance, order of base interfaces should have no impact with respect to interoperability of the derived interface. I.e., interface is a set of operations and has no ordering between.
Mapping to union requires selection of a discriminator, which has natural ordering. The language mapping rules have to have complex rules to ensure that implicit ordering does not come in the way of supporting interface evolution. For instance, the order in which the base interfaces are listed must be deterministic to get the same union discriminators to all operations. Similarly, the order exceptions must also be deterministic for the operation-specific *_Result structures. (see 7.5.1.2.3 and 7.5.1.2.5)
The @choice annotation which implies all members are optional and the type is mutable has simple assignability semantics. I believe it has "strong assignability". It really simplifies analysis of interface interoperability and evolvability.
A common argument in favor of union is its ability to jump to the right member with a single lookup. That's conceptually true but I'm not sure if the mapping of @choice is slow. It requires finding a non-null pointer in an array of pointers. It appears like a micro-optimization.

Section 8.5.1.2.1
Shouldn't the dds::rpc scope be used when the annotations are used?

added a normative idl file with annotation definitions

Added a normative idl file with annotation definitions. See attached rpc_annotations.idl

What if there is a clash between the const hash name and user defined IDL?

What is the behavior of @autoid with a hash-collision? Also what happens when operations are reordered at the moment there is a hash-collision? Couldn't that break interoperability?

Duplicate of DDSRPC_-9

This issue is already addressed in Duplicate of DDSRPC_-9

ParameterIDs for the extended SubscriptionBuiltinTopicData elements should be 0x80, 0x81, 0x82. Reported by Clark Tucker (Twin Oaks)

Updated PIDs

@extensibility(MUTABLE_EXTENSIBILITY)
struct PublicationBuiltinTopicDataExt : PublicationBuiltinTopicData

;
@extensibility(MUTABLE_EXTENSIBILITY)
struct SubscriptionBuiltinTopicDataExt : SubscriptionBuiltinTopicData

;

This is not a 100% review, we focused on the basic profile together with the IDL and after receiving the initial comments of the AB and the fact that there is not one submission we didn't complete a detailed review. We didn't review the github code.

IDL zip (mars/14-11-05)
rpc_types.idl:
Uses the RTI specific top-level annotation. Also top-level is illegal according to the IDL grammar.
Uses anonymous types
robot.idl:

Document (mars/14-11-02)
Section 4
reference to CORBA should be updated to CORBA v3.3
reference to IDL should be updated to CORBA v3.3
reference for DDS4CCM lacks document number
reference for DDS-Cxx-PSM and DDS-Java-PSM should be updated to the formal version
reference to github, how can we in the future pinpoint the exact version of the files mentioned, shouldn't the reference be more explicit about which version?
reference to IDL 3.5 is lacking (used in section 8.3.1)

Section 5
Shouldn't there be a reference in section 4 for this quote?

Section 8.1
The spec talks about “communication patterns”, but in the context of UCM we are talking about “interaction patterns”, what about adopting the UCM term?

Section 8.2.1
In the second paragraph its says “the service implementation contains a data reader to read the method name”, but shouldn't it be “the service implementation contains a data reader which receives the request and after that reads the method name and the parameters.”
Can't the diagram be placed after the first paragraph, it is now on the next page but we refer in text already to it).
Third paragraph, at the end “are filtered out”.
Second paragraph, the fact that a content-based filter “is” used forces that everyone must do this (which is the most logical implementation), but shouldn't it be “could”
In the 4rd paragraph it mentions “asynchronous invocations”, but this is not mentioned in 8.2.2.1, how do asynchronous invocations look like with the function call style in the basic profile?

Section 8.2.3
Isn't it better to keep the term “client” instead of introducing “requester”
Where in this document is the API defined to get the request id at both sides for implicit or explicit?

Section 8.2.5
“ it is” instead of “It is”

Section 8.3.1
What about the support for modules in IDL. In larger systems it will almost get impossible to guarantee the uniqueness of an interface when multiple parts are integrated. Also with an UCM approach modules are the way to group interfaces together. The module is now completely left which could lead to problems in a larger system. To our idea a change of an interface to another module is something that RPC4DDS shouldn't silently adapt to

Section 8.3.1.2
Use a reference to DDS-XTypes in the first paragraph, not in the 3rd
Section xx
What about collisions in the implied IDL types, hashes, etc. If a collision appears what are the rules to follow, because client and service could be developed by independent groups and DDS vendors which should than follow the same rules

Section xx
The spec uses IDL anonymous types in some places, these are deprecated and prevented to our idea.

Section 8.4
“by the used,”??

Section 8.2.1
Why include space as part of user_def_alpha_num?

Section 8.4.2.3
Reference error

Section 8.4.3.3
Reference error

Section 8.5.1.1.1
Why is SequenceNumber_t not using an “unsigned long long”. It is now a struct but there is no explanation in the specification about high and low

Section 8.5.1.1.2
Space missing before “shall” on 3rd line
Why not put the implied types into a nested module so that they don't pollute the user IDL module and resulting code, doxygen documentation, etc

Section 8.5.1.1.3
For the result unions, why is not the unknownEx be part of the RobotControl_Return union as described on page 25, that would save a lot of union members. This exception is generic and independent of the operation.
What when the user has an interface with a user defined parameter with the name return_ and there is a return value? This leads to a clash in the generated struct
For the result struct, with IDL attributes it is possible to define separate exceptions with the set and the get of the attribute (getraises/setraises), this is not reflected in the result mapping
What if there is a clash between the const hash name and user defined IDL?

Section 8.5.1.1.4
Why not put the implied types into a nested module so that they don't pollute the user IDL module and resulting code, doxygen documentation, etc
Typo Non-noramtive

Section 8.5.1.2.1
Shouldn't the dds::rpc scope be used when the annotations are used?
We still doubt the need to introduce @choice, with a union with the hash as discriminator value the is always one value active and there is a quick lookup at runtime. It works for the basic profile so why introduce this new IDL behavior for the enhanced one?
What is the behavior of @autoid with a hash-collision? Also what happens when operations are reordered at the moment there is a hash-collision? Couldn't that break interoperability?
What when the user has an operation remoteEx in his interface IDL?

Section 8.5.2
What is the mapping for the return codes when the regular IDL to IDL2C+, IDL2C+11, etc language mappings are used
What is the error when the remote service is not there (for example not running or not reachable), which exception do I get back?
What when the service crashes during handling of the request, what kind of error do I get back, what is the timeout? How can configure timeouts etc?

Section 8.7.1
Evolution should be evolution.

Section 8.7.1.3
What about changing the exception specification of an operation?

Section 8.8.2
Not a legal IDL struct definition, struct has to be removed from its members

Section 8.8.2.1/8.8.2.2
Add a reference to where in this specification this language binding is provided

Section 8.10.1
What about the library name RTI DDS currently supports. It is very helpful to have multiple QoS profiles in one file and the spec should define how this works

Split issue in multiple smaller issues

Split issue in multiple smaller issues.