Since WebSockets is a message-based protocol, it could fit with GEMS and provide another transport for persistent connections.
Discuss the need and viability of this.
With HTTP as the transport for JSON/REST, there is little to no need to support the AsyncStatus message because HTTP is a request/response protocol with a stateless nature where each request/response pair is independent, i.e. the server does not retain session data between requests by default. That said, the following approach to support the AsyncStatus message in a future version of the JSON/REST PSM (post GEMS v1.7) has been vetted through the SDTF via the following notes captured during SDTF meetings:
Request from GEMS user - HTTP POST AsyncStatus-Directive containing:
1) a webhook/callback-URL of the GEMS user,
2) a list of parameters to provide status for, and
3) periodicity of response messages.
Response from GEMS device - HTTP POST AsyncStatus-Message containing the latest values of the requested parameter(s).
The GEMS PIM currently supports a "Save Configuration" message, however does not support a reciprocal "Delete Configuration".
Requesting the addition of a "Delete Configuration" message to the PIM and supporting content in each of the PSMs, i.e. the upcoming GEMS JSON/REST PSM.
Add the following section to the new GEMS JSON/REST PSM as follows:
9.2.17 Delete Configuration
The normative definition for the delete configuration message is defined below. Everything is normative other than the example values. The TARGET is the configuration service for the given GEMS device which must provide the deleteConfiguration directive that implements the following API to comply with this standard.
Delete Configuration in a GEMS device (i.e. deletes the specified configuration file):
HTTP Verb: POST
URI: https://<host>:<port>/gems/<configService>/_directives/deleteConfiguration
Content-Type: application/json
{
"name":
}
JSON Response for Load Configuration:
{
"result":
}
Add a new row to Table 9.2 of the JSON/REST PSM for GEMS Message "Delete Configuration" with HTTP Method/Verb "POST" and a link to the above "Delete Configuration" section 9.2.17.
Add corresponding sections for the XML and ASCII PSMs.
Currently the GEMS PIM supports nanoseconds in its "time" and "utime" standard types. All of the GEMS PSMs map to this nanoseconds requirement.
More satellite ground systems are requiring picosecond resolution, so adding GEMS support for picoseconds is requested.
This is the main addition for GEMS 1.7 RTF.
The 2024 Q4 San Francisco RTF made progress creating the new JSON/REST PSM via the draft GEMS_1.7_RTF_REST_PSM_v6.doc, specifically the JSON encoding formats.
The 2025 Q1 Reston RTF made more progress updating the draft GEMS_1.7_RTF_REST_PSM_v7.doc.
Continue updating the draft spec in Denver (2025 Q2) and in Leeds (2025 Q3).
Once done, update this ticket with a proposal containing the details.
This will be a new major section '9' in the GEMS spec, starting at page 48.
The time format in the specification is a variant of ISO 8601 (not RFC 3339). Recommend showing time format string as a reference to ISO 8601 and using "D" and fractional in alignment with ISO 8601 rather than alternate definition within the specification.
See https://en.wikipedia.org/wiki/ISO_8601#:~:text=It%20is%20represented%20as%20%22YYYY,as%20%221981%2D095%22.