I don't think removing JTIDS data types and associated enumerations from RPR FOM 2.0 in order to remain compatible with draft17 or ENUM2002 is a good idea.

I appreciate the fact that we agreed to keep RPR FOM 2.0 = the IEEE 1278.1a-1998 (DIS 6) version. But in this case, the JTIDS data types and enumerations are not defined in DIS 6.  Neither are they defined in the DIS 7 (2012) version.  All we did in the DIS 7 version is point them to the SISO-STD-002 Link-16 standard. I doubt if we will ever include Link-16 details in a DIS Standard, certainly not as long as SISO-STD-002 is available. 

Why delay documenting an important use of the Transmitter and Signal PDU as part of the RPR FOM?  The sooner that we include the JTIDS data types and enumerations in the RPR FOM, the better it is for Link-16 interoperability.   If developers that want to implement JTIDS using HLA do not find anything about JTIDS in the RPR FOM, some of them may go off and develop their own JTIDS data types, even if they know bout the existence of SISO-STD-002. 

Also note that the present SISO-STD-002 has conflicting enumerations for the JTIDS Synchronization State. (The present SISO-REF-010-2011.1 lists erroneous enumerations for that field. (A CR has been submitted by Peter Ryan to the EWG to correct the SISO-REF-010 error.)

The RPR2communicationsFOM module, on the other hand, does list the correct enumerations for the JTIDSSynchronizationState.

Implementing Link-16 (JTIDS) in HLA based on the Transmitter and Signal PDUs has been done by various organizations and companies for years based on SISO-STD-002. 

I believe it should go in RPR FOM 2.0.

Sincerely,

Frank

Frank Hill
Sr. Systems Engineer
Unaffiliated
770.472.1261
  



To unsubscribe from the SAC-PDG-RPR list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-RPR