Section 9.2.6 and 9.2.7: Example response has an extra (typo) parameter. Need to remove the |0| field before the END.

These serve no purpose and are probably just typos. The typos will be fixed.

The header of the GEMS_base_types.xsd file does not match with section 7.1.1 of the GEMS Specification Beta 1 document. A. The new issue was mentioned in the AB review of the GEMS FTF report
B. Reported by Hugues Vincent

The GEMS XSD file contains the correct header information. Update section 7.1.1 of the document with the correct header found in this XSD file.

VALID_RANGE description contains extra copy of message UML image

a. This was found during our document review

b. Section 6.3.2.2

c. Reported by RT Logic

Remove the offending duplicate diagram from the INVALID_RANGE description.

There are two questions regarding hex_value types in the GEMS-ASCII PSM.

1. Hex value arrays are not well defined and the concept is complicated.
2. Can we use a 0xFFFF notation?
   Suggestions:
   Yes, the 0xFFFF notation can be used but it should be optional. ''(e.g. FAFA is the same as 0xFAFA)''
   As for arrays, this is a little complicated. Suggestions are as follows:

• Restrict arrays of hex_values to be the same bit length
• Move the bit length to the parameter value: e.g. hex_value[2]=22.FAF320,15.EB90 would specify an array with a 22 bit field and a 15 bit field
  RT Logic's recommendation is to use the 2nd option.

The GEMS PIM hex_value definition will be updated to make clear that all hex_values contained in arrays of hex_values must be of the same bit length.
The ASCII PSM definition will be updated to make clear what formats are allowable for hex_values.

Dave noted that the examples in the document do not clearly show the result description text. A simple ''Desc'' can be hidden. Better examples will help clear this up

Replace all 'Desc' text with wordier descriptions that are obviously visible.

There is no type defined for ConfigResult in either the PSM or the PIM. This is meant to be the result_description

The 'ConfigResult' type is really meant to be the 'result_description' defined in the base 'ResponseMessageType' in section 7.1.1.19.

The client_version is not defined in the PIM but offers the potential for client/server negotiations. This though might be too complex of a notion. Need to either delete it from the schema or update the PIM.
Recommend deleting it.

It is recommended that this notion of client_version be left out of the first version and reviewed for possible consideration at a later date.

Add XML and ASCII as normative references

Fill in section 3 with normative references for XML and ASCII.

Need an example of how to represent a parameter array in the GEMS-XML PSM

a. This missing example was found during our document review

b. Reported by RT Logic

This type of example is not suited to stand alone. Instead one of the existing examples will be modified to include an array of parameters for the purposes of demonstrating this concept.

The examples would be enhanced by providing an example of a directive with parameters and one with return values. Maybe these can be combined.

It seems appropriate to modify the example of a directive message in section 7.2.1 to include at least one parameter in the directive message and one return value in the directive message response. This would provide one comprehensive example of a directive message in the XML PIM.

Incorrect: ''Users connecting to a GEMS device are provide a token...''
Should be: ''.. are provided a token''

Simple correct the spelling error.

The standard device definitions are not defined yet. The original thought was that this section is populated by later revisions.
Suggest this be left for future versions/FTF.

Suggest this section be left empty with a short description regarding the notion of consistency across common devices. Future versions/FTF will expand this section with specific examples.

GEMS-ASCII messages do not specify a starting or trailing pipe character in either the table or in the examples. Dave's recommendation is to put this at the beginning of each message.

A beginning pipe will be added to the definition of the ASCII PSM message header. No ending pipe will be specified as one or the other is sufficient for parsing purposes.

The example only shows one parameter. Need to update one or the other.

The example is sufficient so it was decided to update the description to indicate only parameter would be requested.

The section provides a disconnect example, but the example has a connect message

The example will be changed to demonstrate a disconnect message in the GEMS-ASCII PSM.

The figure shows RTL instead of GEMS. Need to correct the figure.

Replace the figure with a correct version.

There is no description of ParameterSets in the GEMS-ASCII PSM. This needs to be added.

Discuss and flush out appropriately.

Need to define a standard way to escape and/or quote characters in string types

A new section (8.1.2 Reserved Words and Special Characters) will be added to discuss the requirements regarding any special characters and reserved words in the ASCII PSM.

1) The time format is closer to POSIX than UTC and does not allow for unambiguous leap second resolution.
A. This new issue was raised during the FTF.
B. Reported by David Overeem at Boeing

Disposition: See issue 14112 for disposition

Need a message to retrieve the list of saved/available configuration files. There is no current way to obtain the list of available configurations.

In the PIM the new messages are called GetConfigListMessage and GetConfigListResponse. The GetConfigListResponse includes a list of strings. Each string provides the name of a configuration.

The time stamp in the message header is loosely defined in the document. Need to clarify this. Suggest UTC following the time parameter type.

Update all related time stamp fields to specify UTC. Also changed the examples in the GEMS-ASCII PSM section to us ASCII time parameter format for the time stamp.
NOTE: There is an associated issue with this that was identified during the voting process. The time format is closer to POSIX than UTC and does not allow for unambiguous leap second resolution. Because the format of the message will likely not change, this should not impact GEMS 1.0 implementations. There are however several considerations that need to be taken in to account before a final decision can be made on using UTC vs POSIX. Therefore, the FTF is accepting the 3/4 yes vote as resolution of issue 12757. A new issue has been created (13132) and will be handled under a subsequent RTF to specifically address the UTC vs POSIX time concerns.

Should 64 bit integer values be added to the PIM?

Define the long type to be 64 bits in length. Originally the long type was redundant with the integer type. This approach matches the types used in XML.

The invalid_state field in the SetConfigResponse and LoadConfigResponse is confusing and might not apply to all cases (e.g. software only implementation). The original idea behind this was to provide a way to
indicate whether or not the hardware was left in a valid state in the event of an error.
Suggest moving this to a HARDWARE_ERROR ResultCode

Remove the valid_state Boolean members of the SetConfigResponse and LoadConfigResponse classes in the PIM. This change also needs propagating throughout the document. All references and sections to valid_state must be removed.

There are a number of places where internal table references are incorrect. This includes a few places where XXX is used.

All table references have been updated to reference existing tables with correct table numbers.