The idea of maintaining compatibility with RPR d17 by not expanding functionality was not to add additional functionality beyond that specified in RPR FOM 1.0 and the 1998 DIS Standard. I think we need to refine the definition of compatibility with RPR d17 to be clearer and more reasonable.
1. First, RPR D17 is a draft to implement the functional equivalent of the additional capabilities contained in the 1998 DIS Standard. The present RPR FOM 2.0 PDG inherited that draft from the initial work done by the previous RPR FOM 2.0 PDG members.
2. We agreed not to included new functionality from the 2012 DIS Standard. We also agreed not to accept changes in functionality or new functionality developed by users of the draft RPR FOM 2.0 apart from the actual DIS functionality described in the 1995 and 1998 DIS standards.
3. To me, that means that if someone, such as NATO, expanded on an existing 1998 DIS function contained in the draft RPR FOM 2.0, or changed how the function worked, or added a new function that is not described at all in the 1998 DIS Standard, that those changes and new functions would not be put in RPR FOM 2.0. I think that was a good decision. We don't want to delay RPR FOM 2.0 by having to ensure, through analysis and debate that whatever changes are proposed to add new functionality are really well thought out and will be compatible with existing RPR FOM capabilities.
4. Which brings us to JTIDS. Here is a case where:
a. The JTIDS RPR FOM 2.0 data types and enumerations as implemented by NATO were based on an open international standard (SISO-STD-002) that has been widely used and implemented in both DIS and HLA for a number of years.
b. Although the JTIDS detailed implementation is not in any DIS standard, including the latest 2012 DIS 7 version, the DIS Standard, at least since the 1995 version together with SISO-REF-010 enumerations, has supported the ability of the Transmitter and Signal PDU to simulate data link, as well as, voice communications.
c. The proposed JTIDS RPR FOM 2.0 data types use the existing DIS data structures. They have not invented any new structures. The HLA adoption for JTIDS/Link-16 was based on an open, international standard (SISO-STD-002). This is a proven HLA JTIDS/Link-16 approach that has been implemented and used for a number of years in various federations.
5. I think the criteria for including an additional functional capability in RPR FOM 2.0 beyond 1998 DIS functionality should be something like this:
a. The additional functional capability uses existing DIS data structure(s), as of 1998, that were designed to support the additional functionality. The additional functional capability does not use any new data structures or new enumerations that are not already defined in one or more open, international standards.
b. The additional functional capability was derived from an open, international standard or through an open, international technical working group where consensus was reached with, at least, key stakeholders. If the functional capability was in an open, international standard based on a non-HLA architecture (e.g., DIS, TENA, etc.) SIMPLE) and was converted to HLA, the conversion must have been performed in either:
(1) an open, international group of, at least, key stakeholders or
(2), if the conversation was done in one or more, uncoordinated closed working groups, then different HLA implementations of the functional capability must have been widely used for a number of years in one or more federations to show that any incompatibles between FOM approaches have been resolved.
c. Both the necessary FOM data structures, any enumerations, and required transmit and receive rules have already been documented and available for inclusion in the RPR FOM and GRIM, or by reference to other, publically available documentation such as open, international standards.
I believe the JTIDS RPR FOM data types and enumerations meet that criteria.
To unsubscribe from the SAC-PDG-RPR list, click the following link: