GEMS VERSION 1.2

It is not obvious what happens to a client using either GEMS-ASCII or GEMS-XML across TCP when the TCP socket is closed. If the client has successfully connected to a GEMS Device, is that GEMS connection (and resulting token) still active or does it automatically disconnect? Section 6.5 indicates that it should be disconnected, but this is not an obvious place for this behavior to be described.

Also, GEMS-XML states that the HTTP header should be added. When using client-side HTTP libraries, the default behavior is to disconnect often. This is an internet-style approach. The GEMS specification should state that persistent socket connection are required

Clarify socket behavior for GEMS over a TCP connection by stating that once a TCP connection is lost, the GEMS device should disconnect

It is not clear how to define the multiplicity of a list of Parameters or ParameterSets when the list is unbounded or can vary in length. For example, if the multiplicity is set to 5, it is assumed this means the list must contain 5 parameters. How does one specify "up to 5" or "unbounded"?

Create standard method of declaring unbounded list sizes. Use a multiplicity of -1 to indicate an unbounded array, while a non-negative and non-zero multiplicity indicates that the array may contain up to the number. For example, a multiplicity of 5 indicates that the array may contain anywhere between 0 and 5 elements.

The comments about the GEMS Version field in Table 8.2 are confusing. Is the example trying to imply that starting with GEMS version 1.2 the GEMS Version field digits matches the actual GEMS version number, or what?

Clarify comment text to specify that starting after version 1.2, the GEMS version field will be the same as the GEMS version number, with the decimal point removed (1.2 is 12, 1.3 is 13, etc.)

GEMS-XML schema (GEMS 1.2) for MessageSequenceType does not support elements for DirectiveMessage, even though DirectiveMessageType shares the same base (MessageType) as the other supported elements defined in MessageSequenceType.

Add DirectiveMessages to the MessageSequenceType in the GEMS-XML schema. Upon analysis of this issue, it was discovered the several other message types were missing. These were not reported in the original issue, but are fixed as part of the resolution.

Currently the message length is limited to 999999 characters. This can
cause problems translating from GEMS-XML to GEMS-ASCII. It also limits
the utility of message sets

Extend message length to 10 characters

The current GEMS-XML schema requires that Parameters and ParameterSets are always listed in that order. (i.e. ParameterSets cannot precede Parameters). It seems that these should be order independent.

Reported to AMERGINT by Raytheon

Fix the schema to be order independent.

The GEMS-XML XSD bases the HexParameter on the xsd:hexBinary type. This type expects an even number of characters (two for each octet). The GEMS-XML specification should mention this and explain how it needs to be handled.

Recommend always providing an even number of hex characters and using the bit length to specify the actual length.

Example of an invalid 4 bit field: E/4

Example of a valid 4 bit field: E0/4

Pad the hex_value field to two full nibbles for the XML.

Authentication of a GEMS user is loosely defined in the specification.
This should be clarified and include a better definition of how
credentials are passed in, what is the roll (if any) of SSL and
similar transports, and how do proxies handle authentication. In
particular, how does a GEMS user grab control of a system without
creating a race condition.

Add a multiplicity attribute to the ParameterSetDefType declaration to the GEMS_Device file, where it was omitted.