There are a handful of tweaks that need to be made on top of C2MS11-187, discovered during the Ballot #13 effort:

• In Device Message Additional Information. Device.n.Name should be R rather than D because Num-of-Devices is 1+.

• In the Heartbeat Message Diagram, we didn't remove the "=30" in PUBRATE, though it was supposed to be removed, according to C2MS11-187 (resolution to C2MS11-188)

• The same changes as C2MS11-25, should also be done for Heartbeat Message Tables and text and Resource Message Tables and text.

• In the diagram for TLM CCSDS Packet, add the warning on stream-mode.

• Replay Telemetry Data Request Message Diagram does not have correct Formats in the field names and comment.

• In MVAL Response and MVAL Data message, as well as the corresponding Archive Messages, C2MS11-187 introduced ALARM-STATUS. Change the name of this field in the table as well as the diagram and diagram comments to ALARM-STATE.

• Command Request and Command Echo messages didn't mark the CCSDSFRAME as DEPRECATED (did so in the descriptive text, but not in the field values for the table. Note the way this was done for Replay Telemetry Data Request Message Additional Information. Additionally, in all cases where we deprecate CCSDSFRAME, it should be bolded.

• The diagram for product request message has a label issue and needs to be adjusted.

• As part of C2MS11-191, we removed all the .xsds from the title page. However, that issue inadvertently did not remove the Fields.xsd. It should be removed as part of this issue.

• There is missing text in the Section 8.13.7.2 Header for Navigation Data Messages. In all other cases, there is a description under this heading. This one should say, "The abbreviated Table 8-174 below shows the required values of the MESSAGE-TYPE and MESSAGE-SUBTYPE fields for the header of Navigation Data Messages." The corresponding table name should be "Header Field Values for Navigation Data Messages".

• In C2MS11-187, table 8-20 Archive Message Retrieval Request Additional Information, the type is not shown for MSG.n.NUM-OF-FIELDS. This should be U16 and 'D'.

• Use Critical instead of Severe for alarm levels throughout (affects model diagrams and additional info tables). Under the Log Message use text: "4. A display application may subscribe to Critical (Level 4) Severity messages." In Directive Message use text "to provide a GO/NOGO or rollup Normal, Warning, Distress or Critical status on the data link."

• in the Heartbeat Message, NUM-OF-SUBSCRIPTIONS shows a "U16" in the Value column, which is redundant and should be removed.

• Throughout the "Additional Information" tables, where there are inner tables with "Value" and "Description", it is often the case that some of these columns are left-justified and some centered, and this is often true with in the same table (see "Telemetry Processed Frame Message Additional Information"). Recommend centering the "Value" column of the inner table and left-justifying the "Description" column of the inner table. See "Mnemonic Value Response Message Additional Information" for a good and consistent example of what this would look like.

• Related to the above, items in the 'Value' column for Message Additional Information tables are sometimes centered and sometimes left-justified. See Mnemonic Value Request Message. This needs to be made consistent.

• In Mnemonic Value Request Message Additional Information table, MNEMONIC.n.SAMPLE-RATE uses a divided 'Value' column showing both '1+' and 'milliseconds'. Merge the cell, leave '1+', but get rid of 'milliseconds' and add 'miliseconds' to the 'Description' column.

• In C2MS11-187, table 8-114 Archive Mnemonic Value Request Message Additional Information, the type is not shown for MNEMONIC.n.NAME. This should be String and 'D'.

Do this in 1.1

resolve all these leftover changes needed as the final C2MS11-187 was reviewed and the specification document was edited.

These changes depend and and are addendums to all other resolved issues in C2MS 1.1.

• Throughout the "Additional Information" tables, where there are inner tables with "Value" and "Description", it is often the case that some of these columns are left-justified and some centered, and this is often true with in the same table (see "Telemetry Processed Frame Message Additional Information"). Recommend centering the "Value" column of the inner table and left-justifying the "Description" column of the inner table. See "Mnemonic Value Response Message Additional Information" for a good and consistent example of what this would look like.

• Related to the above, items in the 'Value' column for Message Additional Information tables are sometimes centered and sometimes left-justified. See Mnemonic Value Request Message. This needs to be made consistent.

Do this in 1.1

Use consistent formatting in Additional Information Tables

With C2MS11-90 much explanatory text and tables regarding Message Fields and types have moved from Section 8 into Section 6. Because of this, rename from
"6 PIM – C2MS Subject Names and Message Structure"
to
"6 PIM – C2MS Subject Names and Message Composition"

Do this in 1.1

Rename from
"6 PIM – C2MS Subject Names and Message Structure"
to
"6 PIM – C2MS Subject Names and Message Composition"

Already identified as an issue in C2MS11-187, and resolved in its resolution, we are clarifying the text in the Additional Information Tables regarding PROD-SUBTYPE. The text describing ME5 and ME6 in Table 8-154 Properties of the Miscellaneous Elements for the Product Message needs to be updated as well.

Table Text for ME5 and ME6 as Described

Update text in Table 8-154 Properties of the Miscellaneous Elements for the Product Message

Align Alarm Text/Colors with other SDTF Specs.

Include a listing in the document that correlates colors with codes.

Do this in 1.1

NOTE: Model figures will be shown in C2MS11-88 resolution.
Table 8-9: Log message SEVERITY of 0=Debug, 1=Nominal, 2=Medium, 3=High, 4=Critical
Change to DEBUG, INFO, WARN, ERROR, FATAL [NEED C2MS issue]
Table 8-11: RED/YEL/NORM
Deprecate RED/YEL/NORM. Add: NORMAL,WARNING,DISTRESS,SEVERE [NEED C2MS issue]
Table 8-26: RESPONSE-STATUS enum 1=Ack, 2=Working/keep alive, 3=Successful completion, 4=Failed completion, 5=Invalid Request, 6=Final Response
Table 8-53: DEVICE.n.STATUS enum 0=Debug, 1=Normal/Green, 2=Yellow, 3=Orange, 4=Red
Rename to 0=Standby, 1=Normal, 2=Warning, 3=Distress, 4=Severe [NEED C2MS issue]
Table 8-58: COMPONENT-STATUS enum 0=Debug, 1=Normal/Green, 2=Yellow, 3=Orange, 4=Red
Rename to 0=Standby, 1=Normal, 2=Warning, 3=Distress, 4=Severe [NEED C2MS issue]
Table 8-84: MNEMONIC.n.STATUS enum 1=Valid, 2=Valid/No data, 3=Invalid
Table 8-104: Attributes: RED-HIGH, RED-LOW, YELLOW-HIGH, YELLOW-LOW
Deprecate the individual items above. Add new MNEMONIC.n.SAMPLE.STATUS with enum of: 0=Unavailable, 1=Normal, 2=Warning, 3=Distress, 4=Severe [NEED C2MS issue]
And SAMPLE..QUALITY 0=Good, 1=Questionable
Table 8-109: Attributes: RED-HIGH, RED-LOW, YELLOW-HIGH, YELLOW-LOW
Deprecate the individual items above. Add new MNEMONIC.n.SAMPLE.STATUS with enum of: 0=Unavailable, 1=Normal, 2=Warning, 3=Distress, 4=Severe [NEED C2MS issue]
And SAMPLE..QUALITY 0=Good, 1=Questionable
Table 8-126: Attributes: RED-HIGH, RED-LOW, YELLOW-HIGH, YELLOW-LOW
Deprecate the individual items above. Add new MNEMONIC.n.SAMPLE.STATUS with enum of: 0=Unavailable, 1=Normal, 2=Warning, 3=Distress, 4=Severe [NEED C2MS issue]
And SAMPLE..QUALITY 0=Good, 1=Questionable
Table 8-136: XTCE-STATUS enum Astro defines colors for: 2=Invalid, 9=Complete, 10=Failed
Table 8-141: CMD-ECHO-RESULT: NOTC=Not compared, GOOD=Good compare, MISC=Miscompare, TOUT=Timed out waiting for echo, UEX=Unexpected echo received
Table 8-160: PRIORITY enum 1=Nominal, 2=Medium, 3=High
Change to 1=Low [NEED C2MS issue]
Table 8-171: DATA-QUALITY: RAW, VALIDATED, DEGRADED

In C2MS11-163 we adjusted the base set of TLM messages to better handle CCSDS information and to include APID/SCID where appropriate.

There are some related messages that needed to have been adjusted as well. This issue takes up where the already-approved 163 left off. Specifically, we need changes to:

• Replay Telemetry Data Request Message
• Command Request Message
• Command Echo Message

These changes align these adjacent messages to the to TLM message set and include SCID where appropriate.

Make Changes to Adjacent TLM Messages in 1.1

Make the changes specified in the "Revised Text" section of this issue.

Note that in all "Additional Information" tables, the order should be SCID, VCID, APID where those fields exist. Therefore additional changes to these tables should be made according to these examples. This does not affect Message Subject tables.

Note the updated types for SCID, VCID, and APID.

Additionally, these should be called "CCSDS Virtual..." "CCSDS Application..." and "CCSDS Spacecraft..." throughout.

Some Message Subjects:

• Mnemonic Value Data Message
• Archive Mnemonic Value Data Message
• Command Echo Message
• Product Message

have Request ID as one of the Message Subject Miscellaneous Elements. However, the type of REQUEST-ID is now GUID.

We need to figure out how to resolve this in the document text and tables. An RFC 4122 GUID does comply with Subject Token String, but we should address this.

Document GUID as a Subject Element

Make the referenced changes to the document. These changes are in addition to and adapted from the already-approved C2MS11-16 and C2MS11-49, so those changes should be addressed first, and then the changes listed here.

After discussion in the C2MS 1.1 RTF March, 2024, we decided to soften some of the language that was previously inserted as part of the C2MS11-43 resolution, since the shorthand method, though deprecated, is still allowed.

Do this in 1.1

This issue shows changes to the already-approved text from the resolution for C2MS11-43, with the intent being to allow for use of the now-deprecated REQ-STRING if desired.

The text here uses the C2MS11-43 text as a basis, with additions and subtractions shown to it as normal.

Replay Telemetry Data Request Message and Replay Telemetry Data Response Message sections use inconsistent naming for section headers tables and figures compared to all other sections of the document. For example:

"Replay Telemetry Data Request Diagram"
"Replay Telemetry Response Message Header"

These should be made to use the full name of the message, just like other sections in the document.

Align Label Text in 1.1

This issue lists the items that need to be modified with the appropriate changes.

As the final version of 1.1 is being prepared, there are some items that need revisiting from already-approved issues.

Do this in 1.1

Adjustment to text as shown. Items discovered while working C2MS11-187.

Because many separate changes have been made in the [MESSAGE-TYPE] Message Additional Information Tables and in the [MESSAGE-TYPE] Message Contents (model) Figures, this issue seeks to consolidate all such changes together for final review. Changes here should be considered, therefore, to supersede all other C2MS 1.1 changes to the specific tables and figures enclosed in this issue.

All such tables/figures are in Chapter 8 PIM - Message Definitions.

Consolidate already-approved C2MS 1.1 Changes

Make all tables and figures in the document match what is in this issue. Note that if a table/figure is not shown here, it still may be modified in other already-approved issue(s). In other words, this proposal only governs the tables and figures listed here.

The changes here include and are limited to:

• [MESSAGE-TYPE] Message Additional Information Tables
• [MESSAGE-TYPE] Message Contents (model) Figures
• Occasional text associated with the above as indicated in this resolution

As part of this issue, we are also revising the types for CCSDS Telemetry message fields, SCID, VCID and APID. After lengthy discussion in the SDTF and C2MS 1.1 RTF, it was decided that these should be U32 for SCID and U16 for VCID and APID. This does not affect Replay Telemetry Data Request Message which uses String types for these fields, because it supports specifying a comma-delimited list or a range as a String. This change is also not made to the now-deprecated Telemetry CCSDS Frame Message.

Note, too, that as part of this resolution, we discovered and discussed in the SDTF and C2MS 1.1 RTF the need to rename one field type that is in conflict. Many messages have a PROD-SUBTYPE, a NUM-OF-PROD-SUBTYPES and a series of items called PROD-SUBTYPE.n. The series and its corresponding NUM-OF relate to a subcategory of PROD-SUBTYPES, so the name is in conflict and not possible to describe in UML. For this reason, the field names in question will now be NUM-OF-PROD-SUBTYPE-SUBCATEGORIES and PROD-SUBTYPE-SUBCATEGORY.n. This is manifest in Table 8-20 Archive Message Retrieval Request, 8-26 Archive Message Retrieval Response, 8-114 Archive Mnemonic Value Request Message, 8-119 Archive Mnemonic Value Response Message, 8-146 Product Request Message, 8-150 Product Response Message, and 8-156 Product Message.

As part of this resolution, use HEADER-VERSION "2024" and CONTENT-VERSION "2024" for any messages whose content has changed and preserve CONTENT-VERSION "2019" for all others. In the model figures add ".0" to keep with convention from C2MS 1.0. Eg: "2024.0" and "2019.0".

NOTES FOR REVIEWERS AND DOC EDITOR:

Throughout the table changes in this document, generally deleted text is lined-out, inserted text is underlined, tables within cells of a table are handled inline, but have a different look in the jira wiki markup than will exist in the final table, for example:

In the above table section, columns that have no header name should not be represented as columns in the final table. Tables-within-tables create rows with no row name, and sometimes columns with no values. So the above should appear in the final document as shown in attachment "C2MS-187 Tables-in-Tables"

In some cases, if there is no change to a cell, especially for a table within a table, we may use the designator [NO CHANGE]. Any other special cases will be made as a note to the reviewer and document editor, as [NOTE: ***]. Tables should use the same basic format as present in the 1.0 Spec.

Just the way the wiki markup works in JIRA, it's not easy to control column widths, so often text will be wrapped within a cell. The review/editor should take note to use the format of the existing document tables and make logical word breaks. For example, sometimes in the changes text the word SPECIFICATION might be split after SPECIFICAT with ION on the next line... clearly the document editor should make this look right in the final document.

For the modified figures, in the "C2MS-187xxx original" attachments, I have included the figure caption in the original document in the image for the purpose of locating it when reviewing/editing the document. However, the caption is, of course, not part of the figure, so it's not being included in the "C2MS-187 xxx" revised attachment should not be interpreted as removal when editing the figure in the document. Some figures may be new, so there will be a "C2MS-187 xxx new" attachment, and I'll make note of where that belongs below.

And just as a cautionary note for the review and document editor, other approved issues may reference one of these tables or figures, which are superseded here, but may also have other document changes, and there are other approved issues still that have their own changes not related to these figures and tables, so take care not to assume that other issues are superseded in their entirety by this issue.

The original, revised, and new diagrams related to this issue are attached as zip files rather than individual attachments due to their large number.

Finally, please see the attached Review Guide to help with contextual information related the consolidating effort of this issue resolution.

Each message includes a "[message name] Header table that repeats header field definitions as already listed in Table 8-3 Message Header Additional Information. Instead, this individual message table is intended to show what special values are applied to certain fields of the header. This needs to be made more clear, without duplicating information in the already-existing Header table. In other words, these tables should provide unique-to-the-message values rather than repeating header definitions.

A specific example of why this is not practical is that the existing set of tables all show the HEADER-VERSION 2019. Because the HEADER-VERSION is being updated in 1.1, each of these 31 tables must also be updated. In order to avoid this kind of issue in the future, these tables need to be reduced to just the necessary message-specific values.

See for example, "Table 8-108 Mnemonic Value Data Message Header". This table does not need to include the "Notes" column, since that is simply repeating word-for-word what exists elsewhere, and should not include the HEADER-VERSION row, since that is defined elsewhere, including its value.

To make this better, change the column name of column one to "Header Field Name". Additionally, should change the table title to "Table 8-108 Mnemonic Value Data Message Header Values".

Clear up header values tables

Throughout the document, in all "[message type] Header tables:

• change the name of the table
• change the title of column one
• remove the "Notes" column
• remove the HEADER-VERSION row
• remove the "More..." text and row at the end of the table (this text repeated 38 times in the document is not necessary)

This resolution updates the two new tables added in C2MS11-163, and for these two tables, the form here should be considered to replace those same tables in that issue.

Additionally, this resolution updates the two new tables added in C2MS11-45, and for these two tables, the form here should be considered to replace those same tables in that issue. Text of the table section is also updated for these two.

Throughout the document, we use APID and AP ID interchangeably. For consistency, we should reduce all these references to just APID.

Do this in 1.1

In the 12 instances where AP ID is used in the document, change to APID. Sometimes add "CCSDS" for clarity.

Review and fix all uses of DESTINATION-COMPONENT in the Miscellaneous Elements of subjects for all messages where that field is used. Also, see 2016 GMSEC ISD for discussion of destination component and add that back in to the description of Configuration Status Message. See pages 74 and 78.

Fix phrase "Component Name..." in ME1 and ME2 columns to COMPONENT and DESTINATION-COMPONENT

Update tables and text with the terms COMPONENT for the sender, and DESTINATION-COMPONENT for the receiver or recipient.

In the case of Mnemonic Value Request Message and Archive Mnemonic Value Request Message, the requestor can specify a STOP-TIME or DURATION, but both are optional. If neither is specified, the subscription is open-ended with no knowable end, until the requestor sends a 'STOP' message. In order to avoid infinite fulfillment of a subscription to a potentially lost requestor, we could enforce a concept that a requestor must specify either a STOP-TIME or Duration.

In practice, this is an inadequate requirement, since a caller could specify a very long duration, like 1000 years, and circumvent the desire of this issue.

However, this is issue simply captures the idea to promote further discussion.

Add responder's fields for service DURATION and STOP-TIME support

The responder to the request shall determine the time it can support based on the original request. For example, unlimited or very large durations or stop times past the end of the archive and so on may not be supported, in which case the responder may clip the response to the duration or stop-time it can support and this will be placed in the response. It's up to the requester to monitor this field and do something useful with it. It's an implementation detail as how the responder implements this other than providing the value in the response.

Changes to text and to diagrams as shown herein.

Changes need to be made to the "Additional Information" tables that contain Field listing for each message. The necessary changes are to provide complete information and to unify the names of the column headers across all messages.

Should add a type column to the fields table "Additional Info". Currently, the only indicator of type is in the UML diagram. Because of this, it is often the case that a reader of the table, must glance at the UML diagram in addition to reading the table.

Additionally, the tables are not uniform within the 1.0 document. Some use "Value" for a certain column header, while others use "Value/Description". To resolve this, it would be useful to use "Value" in every table and to rename the current "Notes" column to "Description" which is more accurate.

Add Type to Fields and Fix Column Names in the ("Additional Info") Tables

The change here shows one exemplar, but this same change will be made to all "Additional Information" tables for all messages in a final roll-up issue that will show all the consolidated table changes.

Add a column to the table showing type as already defined in the corresponding UML diagrams.

Note that this description of the change also shows the already-approved change to C2MS11-14, which added the "Presence" column. Both are shown here to illustrate their relative positions in the table.

Additionally, use "Value" for all tables (some have "Value" currently, others have "Value/Description" and replace "Notes" with "Description".

After discussion in C2MS RTF in Orlando 2023 Tech Meetings, we determined to clarify or clean up some text with Simple Service Request and Response messages as follows:

• Say it’s not intended to be long-term but for quick on-boarding. Services meant for long-term use should create their own message set apart from Simple Service
• Say that we intend to rework or replace Simple Service at some point in a future release.
• Consider removing text about using it for a publish mode

Note that the response message as it is lacks the Service-Group that was specified in the request message. This lack makes it impossible to correctly correlate a response to a request that did specify Service-Group. However, because we intend to 'rework' these messages in a future release, we won't make this change at present.

A related issue will be created to replace simple service and deprecate current simple service, but will be deferred to later.

Update Text Associated with Simple Service Request and Response

Indicate that the Simple Service is meant as a temporary.

Indicate that C2MS intends to rework this service, deprecating the current set of messages and creating new messages.

Issue C2MS11-54, already approved, has removed two subject elements that didn't belong in Telemetry TDM Frame Message. In fact, there are many more similar irregularities across all the Telemetry messages.

The needed changes are described below, but also shown in the attachment (original and revised) that shows the fields and subject elements as they exist today and should be after corrected.

• Add a new message type: Telemetry CCSDS CADU Message
• Rename Telemetry CCSDS Frame Message to Telemetry CCSDS Transfer Frame Message
• APID should be both a subject element and field in Telemetry CCSDS Packet, and in no other TLM messages.
• VCID should be both a subject element and field in Telemetry CCSDS Packet and Telemetry CCSDS Transfer Frame, and in no other TLM messages
• PHY-CHAN should be a field in the new Telemetry CCSDS CADU Message, with no subject element for it (Note that this message won't have APID, VCID or SCID represented.
• Add SCID as a subject element and field in Telemetry CCSDS Packet and Telemetry CCSDS Transfer Frame messages

Update TLM messages with current needs

Align messages per the issue description.

Tracking fields do not specifically belong in a C2MS Message. Rather, there should be a message envelope that contains these fields for the purpose of delivering a contained C2MS message. This "Message Envelope" is the logical place for managing tracking fields and other metadata related to, but not part of a C2MS message body.

This is clear when considering tracking fields, MW-INFO and CONNECTION-ID, which are message-bus handling constructs and have no meaning related to C2 of a satellite.

Note that this concept was originally moved to C2MQ. However, because C2MQ is a long way away and because message envelope is a useful construct within C2MS, it was determined at the Austin (Dec, 2023) C2MS meeting to bring this back in to C2MS and take the envelope concept out of C2MQ (leaving it to cover service-based interactions outside of the messages). Therefore, this is a re-entry of the envelope mechanism.

As part of this effort, we should do the following:

Add fields that allow encryption of content sections of the C2MS message body as well as message signatures or message authentication codes. This would not assume or provide any particular mechanism to encrypt/sign, but would allow for tracking of these fields to aid usage.

The benefit of doing this is to allow the Mission to determine levels of security and secure componentry, but to use the message definition as a way to track this information.

Add Optional Message Envelope in 1.1

Add a new section at the same level as C2MS Message Header and before it. C2MS Message Header is currently section 8.1. The new section should move into this place as section 8.1, with C2MS Message Header moving to 8.2, with all subsequent messages moving down by one as well. This new section details a C2MS Message Envelope that has many of the fields currently in Message Header.

Many fields will exist both in Message Envelope and in Message Header. A separate issue (C2MS11-182) covers deprecating these fields and this issue is expected to be deferred to 1.2.

Some fields will be new to the Envelope and will not also exist in the Header.

The Envelope will be "optional" in the sense that it is not required to be used (for now), but a note will indicate that at a future time, this will become the required mechanism for message handling.

Additionally, it is helpful in the flow of Section 8 "PIM- Message Definitions" to modify some of the front matter that is less consistent now that there is an Envelope as follows:

Remove the Figure 8-1. High Level UML Class Diagram and the paragraph immediately preceding it. All this material is low-value and would have to be changed greatly to conform to the this issue as well as to C2MS11-18, which is already approved.

Some XSDs were provided by NASA when v1.0 was created. However, these are only useful in a PSM for XML and should not be considered normative for the PIM. We don't have any intention to maintain/update these, so they should be removed. If NASA wants to create and deliver these to users, that is fine, but the OMG should not be the broker for these files.

See the listing of "Normative Documents" here: https://www.omg.org/spec/C2MS/1.0

Remove XSD Listing from Doc and Do Not Publish on OMG Page

The XSD Listing on the OMG C2MS 1.0 Specification webpage will remain, but these are not to be included in the OMG C2MS 1.1 Specification page when created. The model .xmi file will be the only file listed under "NORMATIVE MACHINE READABLE DOCUMENTS".

Additionally, remove references to XSDs from the title page of the specification document.

A new .xmi file will be provided to the OMG, and, of course, the link to the .xmi will be updated to point to the new specification page, but that is left to the Document Editor, since there is nothing to link to as of the creation of this proposal.

Add field SERVICE-GROUP (String, Optional) to the message. ME2 should refer to this field for its value.

Add SERVICE-GROUP to field

Add SERVICE-GROUP to the Simple Service Request Message fields. Also fix some text to match the new text of the table.

Add SERVICE-NAME to the Simple Service Response Message fields.

Additionally, the type for SERVICE-NAME is listed as String. This is valid if the field is not also used in the Message Subject.
To guide the user in this concept, text is being updated in the fields table for both Request and Response.

Modify the associated diagrams as shown in attachments.

There are n+2 number of optional elements between ME4 and ME7. These fields map the field(s) PROD-SUBTYPE.n.NAME.
API Workaround: API only maps the first two of these product subtypes, and the user will have set subject if they want more.
Required C2MS Spec changes: Ditch the n+2 logic in the middle of a message subject and only display the first two PROD-SUBTYPE values in the subject (or FILL if not used). A subject that can have dynamically shifting positions of its subject elements has serious implications on compatibility.

*PROD and SUBTYPE should be enough but if not... *

We lack use cases that show and problem here. This is just a possible problem for what seems like the unlikely case of product with a subtype that isn't enough to differentiate it from another one, and that then the 2 additional ME fields wouldn't be sufficient.

Overall with 4 pre-canned ME required and optional fields for a subject, it's difficult to see that this is not enough to differentiate some imaginary product in a topic/subject.

In fact due the complexity of such a product I kind of think it's better to just let such a need if it ever exists to just find some other localized way to handle it.

UNIQUE-ID in the Header is of type Header String (to be Subject Token String due to C2MS11-49). According to table 8-3: "Globally unique ID – reserved for use by implementation (PSM)". Note that a "Header String" is limited to upper and lower alphanumeric plus '-' and '_'. Recommendation of C2MS is that best practice is to keep Header String to no more than 12 characters.

So, Header String or Subject Token String isn't the right type.

I think we need to know what GMSEC uses for a type of UNIQUE-ID. But, it possible, it would be good if it was a GUID, relating to C2MS11-16.

Change Type of UNIQUE-ID from "Header String" to GUID

This change assumes that CSMS11-60 which creates a new C2MS type called "GUID" is accepted.

Almost all miscellaneous subject elements for messages are specified as mapping to fields in the message. But a few are not. For example, see the Miscellaneous Elements table 8-46 for the Control message. The elements DESTINATION_NODE and DESTINATION_FACILITY do not exist as fields in the message. (Note: it may be more appropriate to add some of these fields to the Message Header rather than many/most messages.) In this particular example, this may be resolved by C2MS11-28, but each message type would need to be evaluated to see what other subject elements are not mapped to fields.

Address node and facility terms to DESTINATION-NODE and DESTINATION-FACILITY

The following fields are added to 8.1 C2MS Message Header, optional fields:

DESTINATION-NODE=Header String
DESTINATION-FACILITY=Header String

These fields are also now associated ME3 and ME4 in all other tables within the document
where they are used or not otherwise specified.

==================================================================

8.5.1.1 Configuration Status Message Subjects
Table 8-40. Configuration Status Message
Column ME3 [Node] --> ME3 [COMPONENT-NODE]
Column ME4 [Facility] --> ME3 [COMPONENT-FACILITY]

==================================================================

Table 8-41. Properties of the Miscellaneous Elements for the Configuration Status Message

ME3 = destination node ---> DESTINATION-NODE
ME4 = destination facility --> DESTINATION-FACILITY

(soon after that table)

Examples
Publishing / Sending Configuration Status messages:
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CFG.APP1 or
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CFG.APP1.COMPONENT or
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CFG.APP1.COMPONENT.NODE.FACILITY

****TO*****

Examples
Publishing / Sending Configuration Status messages:
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CFG.APP1 or
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CFG.APP1.DESTINATION-COMPONENT or
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CFG.APP1.DESTINATION-COMPONENT.DESTINATION-NODE.DESTINATION-FACILITY

==================================================================
8.5.2.1 Control Message Subjects
Table 8.45. Control Message Subject Naming

Column ME3 [Node] --> ME3 [COMPONENT-NODE]
Column ME4 [Facility] --> ME3 [COMPONENT-FACILITY]

Table 8-46. Properties of the Miscellaneous Elements for the Control Message

ME3 = destination node ---> DESTINATION-NODE
ME4 = destination facility --> DESTINATION-FACILITY

(Then...)

Examples
Publishing / Sending Control messages:
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1 or
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1.COMPONENT or
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1.COMPONENT.NODE.FACILITY or
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1.COMPONENT.NODE.FACILITY.KEY
WORD

********TO*********

Examples
Publishing / Sending Control messages:
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1 or
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1.DESTINATION-COMPONENT or
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1.DESTINATION-COMPONENT.DESTINATION-NODE.DESTINATION-FACILITY or
C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1.DESTINATION-COMPONENT.DESTINATION-NODE.DESTINATION-FACILITY.KEY
WORD

We have previously approved C2MS11-55 that changes the concept of REQUEST-ID as Replacement. After reviewing this change with the EGS Team, it is apparent that we could tighten up some of the text in the proposed change to make it more clear what are valid second-uses of REQUEST-ID and what are invalid, along with the expected response to an invalid use.

It should be invalid in Replay Telemetry or MVAL Request to issue a start after a start has already been done using the same REQUEST-ID. In Replay Telemetry, we probably need to think about it. If an invalid re-use of REQUEST-ID is sent in a request message, an indicator should be returned in a response for Invalid Request.

Do this in 1.1

In this resolution, we show the already-accepted text associated with C2MS-55 which is not yet in the C2MS Document as the starting point, with text changes as indicated. In this way, this resolution fixes text that is not yet in the document.

The Subject for TLMTDM Frame Messages includes the following:
-ME3 = VCID
-ME4 = APID

However these fields:
a) don't exist in the TLMTDM Frame Message, so can't be populated to the message subject,
b) belong only to CCSDS frames, not TDM frames.

These Message Subject Miscellaneous Elements should be removed and replaced with "FILL" to preserve ME5 as Collection Point.

Do it in 1.1

Change table contents and examples.

From Justin: The REQUEST-ID field was defined as a U16. Recommend this field be changed to be a string to allow it to be utilized as a GUID. This allows it to work better for transport of existing interfaces that utilize a GUID to ensure message uniqueness, especially when multiple instances of the application are running concurrently.

Add GUID type

After discussion, it has been proposed that we do this one in 1.1.

Showing the change to one figure (Figure 8-7. Directive Response Diagram), which illustrates replacing the REQUEST-ID type from U16 to GUID. The others mentioned will all be changed in the same fashion. Rather than making all the changes here, we are voting on this style. There will be a subsequent issue to capture ALL the Figure and Table changes accounting for all the C2MS1.1 issues already accepted.

For the Archive Mnemonic Value Request Message, under the explanatory text, there is a paragraph stating:

"Optionally, if known or applicable, the requestor can specify the file type and file attributes with the optional dependent fields under the Output Product Category and Output File Attributes sections."

I'm not sure what this is referring to. There are no Product Category or Output File Attributes dependent fields in the Message. The terms "Output Product Category" and "Output File Attributes" occur in the document only in this paragraph.

The text either needs to be clarified or removed.

Remove nonsensical text

The text states "THIRD, for all the options above, the requestor must do the following:
• Identify the number and names of the mnemonics along with their extraction criteria.
• Optionally, if known or applicable, the requestor can specify the file type and file attributes with
the optional dependent fields under the Output Product Category and Output File Attributes
sections.
"
and should be

THIRD, for all the options above, the requestor must do the following:
• Identify the number and names of the mnemonics along with their extraction criteria.

Document clarification: The DDD portion of the Time Type, as shown in table 8-2 on page 40, has a range of 1-365 (or 366). But when using a relative time (by preceding the value with a "+" or a "-"), the DDD portion can contain a zero value. Make this clear and add a couple more relative time examples.

Consider replacing C2MS invented date format with RFC3339 or ISO8601 to include relative time.

Improve Description of DDD field for Time Field Type

Change text in Definition and Range columns of specified table.

The APID is associated with a telemetry packet, not the frame.

Duplicated of C2MS11-163

A number of these have been identified, but after discussion with the RTF and larger SDTF, we have decided to align across all these telemetry messages. C2MS11-63 has been created for that purpose, so marking this as a duplicate of that issue.

The APID is associated with packets, not the telemetry frame.

Duplicate of C2MS11-163

A number of these have been identified, but after discussion with the RTF and larger SDTF, we have decided to align across all these telemetry messages. C2MS11-63 has been created for that purpose, so marking this as a duplicate of that issue.

Mnemonic Value Request Message and its corresponding Mnemonic Value Response Message utilize a concept called "ONESHOT" or "Oneshot". These are the only messages in C2MS that have this construct.

This is described in Mnemonic Value Request Message as:
“The Mnemonic Value Request Message is used to request one or more mnemonics either as a single sample ('Oneshot') or as a request to Start publishing the mnemonics continuously.”

and

Mnemonic Value Response Message:
"For a 'Oneshot' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the values of the requested mnemonics and no further Mnemonic Value Data messages will be published."

However, in a significant way, these statements conflict with the next line:
"For a 'Start' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the initial values of the requested mnemonics and subsequent occurrences of the mnemonics will be published via the Mnemonic Value Data Message."

In other words, the Response Message will contain the initial set of data (current point values) in response to EITHER 'Start' or 'Oneshot'. The description says "either or" ("either as a single sample ('Oneshot') or as a request to Start publishing"), but the logical statement should be "yes and maybe" (Both Oneshot and Start will contain the initial set of data, but only Start will be followed with Mvals).

As written, the text has to be read carefully to understand the "yes and maybe" logic. I suggest adding some supporting text to clarify this.

Do this in 1.1

Improve text to make clear that the 'Start' and 'Oneshot' both result in a set of data being returned in the response, with the 'Start' request also being followed by a seiries of Mval data messages..

In Mnemonic Value Request Message, there is a PUBLISH-RATE and there is a SAMPLE-RATE that can be specified for each MVAL. The correlation between these is somewhat open to interpretation. For example, the text of the SAMPLE-CRITERIA, associated with SAMPLE-RATE, says it drives "when data should be provided" which overlaps with the PUBLISH-RATE. If taking SAMPLE-RATE to be independent of PUBLISH-RATE, it means something else entirely.

The supporting text of the Mnemonic Value Request Message needs to make clear how these interact.

Note that we previously determined to remove SAMPLE-RATE due to perceived overlap, but have since decided to leave it in place and make clear its usage.

Do it in 1.1 second attempt

Note that there was a previously accepted proposal to remove remove the SAMPLE-RATE field and corresponding text. Upon further review, we should have kept the field and clarified the text. The text could be interpreted in two ways. One way would still be valid, if we make the text more clear.

Note, two, that with the prior approved change, now undone, we modified a diagram. That modification is no longer valid. So, I've included the original model diagram, here, to show that it is unchanged from the original.

As part of C2MS11-14, which was already approved, there was a subtle inconsistency through its text and image changes. This issue is to capture the change for final submission of the documentation for C2MS 1.1.

In that issue, in the Configuration Status Message there is a field, NUM-OF-ASSOCS. It is marked optional in the diagram, but required in the text table.

In the Heartbeat Message, NUM-OF-SUBSCRIPTIONS is shown as optional, both in the diagram and in the text table.

In the Mnemonic Value Request Message, NUM-OF-MNEMONICS is shown as required, both in the diagram and in the text table.

In all cases throughout C2MS where there is a NUM-OF-[ITEMS] field, it should be required in the corresponding diagram and text table.

This is to align it with the obvious. The NUM-OF field indicates how many items are present in a set, such as MNEMONICS. If there are none, this field should simply be set to 0. However, if it were optional, that would mean that the field would either be present or set to 0. The former is preferred for clarity.

Do this in 1.1

Redo the diagrams and one table from C2MS11.14 resolution, since these had used 'optional' NUM-OF-... fields. These should have been required. As with C2MS11-14, this type of change will be replicated in all messages throughout the document that have NUM-OF-* fields, once approved, and a new final issue will be created to capture all the changes. In the case of these diagrams, the originals from before C2MS11-14 are shown, with revised diagrams.

Additionally, one table showed optional, should have been required... the update is shown in the revised text. In the case of the table update, it assumes all the changes already, and simply updates the one field from C2MS11-14.

C2MS11-56, already approved, removed MNEMONIC.n.SAMPLE-RATE. In conveying this to the EGS Team, including MAV (NASA) and Ryan Conrad (MITRE) there was concern that we were losing fidelity with the data by only using PUBLISH-RATE to create messages but not having multiple samples at a rate of SAMPLE-RATE.

When we were considering this one, we approached it from the perspective that SAMPLE-RATE and PUBLISH-RATE created a dual-mechanism for when to send the MVAL message. While this is still and issue, there may be a way to allow both desired results in a combined way.

One concern of both the C2MS Team and the EGS Team is in getting too many messages published. This is a clear concern with the SAMPLE-RATE, because of the CRITERIA's indication of "when data should be provided for the mnemonic", including on "Change". In fact, it's likely that CRITERIA is the suspect field basically determining how often to "provide" the data rather than SAMPLE-RATE.

Perhaps we could do the following:

• state in C2MS that the messages will only be produced at the PUBLISH-RATE, but that if SAMPLE-RATE is tighter, then there will be multiple samples in the message.
• Instead of removing SAMPLE-RATE, we remove CRITERIA, so that the SAMPLE rate simply determines how often to sample

Whatever we do, we need to revisit SAMPLE-RATE before finalizing 1.1.

Duplicate of C2MS11-56

We originally made a change to C2MS11-56, and this issue was to revisit that change. After review, we reopened 56 and make the complete change there. That makes is issue a dup of 56.

There is an already-accepted issue, C2MS11-56, that removed MNEMONIC.n.SAMPLE-RATE, but that issue did not address the related field, MNEMONIC.n.CRITERIA.

In that other issue, the MNEMONIC.n.SAMPLE-RATE was removed because it overlapped with the PUBLISH-RATE of the base message.

Since SAMPLE-RATE has been removed, one of the following additional steps needs to be taken:

Option A - remove the value "3 = Sample Rate" from MNEMONIC.n.CRITERIA

Option B - Remove MNEMONIC.n.CRITERIA completely for the same reasons SAMPLE-RATE was removed

Option B - Move MNEMONIC.n.CRITERIA to a field in the base message now to be called "PUBLISH-CRITEREA" with the following possible values:
1 = Change (value, flags, status) [publish when any MVAL experiences a change]
2 = Every Sample [publish when any new sample arrives for any MVAL]
3 = Publish Rate [publish at the rate specified in PUBLISH-RATE, already in the base message]

The bottom line is that just as in C2MS11-56, it doesn't make sense to have different publish/sample rates for the main message and each MVAL, so any of the above options are preferred over what it is in 1.0. (Mike: Personally, I like Option C).

Duplicate of C2MS11-56

We originally made a change to C2MS11-56, and this issue was to revisit that change. After review, we reopened 56 and make the complete change there. That makes is issue a dup of 56.

This value is used in the subject, so should be added to the message.
(NOTE: do NOT add this field to the CCSDS Frame message; TBD for Processed Telemetry Message and TDM Frame message. Also, check the VC ID usage appropriateness in all 4 TLM messages.)

Duplicates C2MS11-163

A number of these have been identified, but after discussion with the RTF and larger SDTF, we have decided to align across all these telemetry messages. C2MS11-63 has been created for that purpose, so marking this as a duplicate of that issue.

One goal for consistency (and ease of implementation and use of said implementation) is to have all subject elements also be fields in the message. Adding DESTINATION-COMPONENT late in the adoption process of C2MS was a step in this direction, but DESTINATION-NODE and DESTINATION-FACILITY are needed also. See page 82 for example for CFG messages.

(Note: this applies to all 5 C2CX messages - CFG, CNTL, DEV, HB, and RES)

Move to C2MQ

This is part of C2MQ

Add field AP-ID (String, Optional) to the message. ME4 should refer to this field for its value.

APID should NOT be present directly in the frame

Application identifiers are present in the CCSDS packet headers on a per packet basis. Frames have not been processed out to packets yet. Therefore, having a APID ("app-id") field in a frame message is not appropriate.

A number of C2MS Messages include the concept of marking the mode of the data as “real-time (RT), replay (RPY), simulation (SIM), or test (TEST)” through a required field, STREAM-MODE.

The specific messages are:

• Telemetry CCSDS Packet Message
• Telemetry CCSDS Frame Message
• Telemetry TDM Frame Message
• Telemetry Processed Frame Message
• Replay Telemetry Data Request Message
• Attitude Parameter Message
• Attitude Ephemeris Message
• Orbit Parameter Message
• Orbit Mean-Elements Message
• Orbit Ephemeris Message
• Tracking Data Message

Where used, STREAM-MODE is a required field. A typical explanation in the C2MS Spec is that, “The STREAM-MODE field is used to classify the kind or source of the” message.
Although this may be useful in a closed experimental/engineering system, the concepts are not appropriate for an operational SATOPS system, where replay, test, sim data should never be mixed with real-world operational data. In a system with many components, the use of the STREAM-MODE field assumes that every component will properly handle the distinction for every message. As an example, a FireThrusters CMD message is received and the component fails to note that this particular message is a RPY STREAM-MODE and thinks to itself… ‘huh, I thought we fired thrusters, yesterday… but, OK, here it goes…”. In another example, a SelfDestruct CMD message is received and the component fails to note that the message is marked as TEST or SIM…

Instead of marking messages themselves, this type of distinction should be performed environmentally; one system is the operational system, other, separate systems are for simulation or test, another separate system performs forensics (replay). Keeping these purposed environments isolated from each other ensures that data never intermixes where not appropriate.
The resolution to this concern could be any of the following:

1. Remove the STREAM-MODE field — breaks backward compatibility, and affects any system already using this field. However, it represents a clean break from a field that should never be used in practice, anyway.
2. Make the STREAM-MODE field optional with default value assumed to be RT (real-time) and mark the field as deprecated (deprecated = should no longer be used and will be removed in a future major release) — maintains backward compatibility, but signals to users to cease using the field.
3. Make the STREAM-MODE field optional with default value assumed to be RT (real-time) and provide a best-practices statement; something to the effect of, “Although maintained for backward compatibility, the use of this field is strongly discouraged for operational systems, where test, sim, or replay data should never mix with real-world operational data” — this weakest approach leaves the use of the field in the hands of the user, but would be a bit embarrassing from the standpoint of a specification to preserve a capability that is strongly discouraged.

See attachment for non-exhaustive use in C2MS Spec.

*Update Text to Indicate that this Should not be Used at Enterprise-level *

Create a section to describe this capability as appropriate for small-scale or experimental SATOPS, but inappropriate for formal enterprise-level operations.

Put a note in each field of the effected messages to indicate this as well.

The Archive Message Retrieval Request Message and related Archive Message Retrieval Response Message should be considered for deprecation.

These are useful messages in an engineering environment when all messages and their corresponding storage method allows unfettered access to all consumers regardless of authentication/authorization, but in a real-world operational environment, this construct is much too uncontrolled.

For example, the Archive Message Request allows, and suggests, sending a SQL statement or script expression in the REQ-STRING field, which the service provider would execute on behalf of the requestor, creating an exploitable cyber attack opportunity for malicious software.

Even if the REQ-STRING were removed and the request only allowed for PROD-TYPE/PROD-SUBTYPE (the other way to request the archive), this would allow for all messages that ever flowed in the environment to be forwarded to a single requestor. In an unsecured system, that might make sense, but it is not appropriate in any system that closely controls who is allowed to send/receive any given message.

Deprecate REQ-STRING in Archive Message Retrieval Request

Deprecate the REQ-STRING field in Archive Message Retrieval Request. This mechanism is not secure, allowing a requestor to provide a SQL statement or Script to be executed by the service on their behalf.

Describe the rationale for the change to the reader.

Provide a note that the "longhand" version of the query will continue to be supported.

Note that some fields that were previously "dependent" are now "required" because they were only required when using the "longhand" method (which is now the only methd).

Replace the UML diagram to with the new version that moves the previously dependent fields into the required category and adds the note that the REQ-STRING field is Deprecated. Note that because of other changes going into this same version, the Required and Optional blocks are being redone as well, so the illustrated new version is to show the type of change that is to be made, but will actually be different from this when all is said and done. But this issue is only concerned with the delta that is effected by this issue.

Similar to C2MS11-43, this issue is to consider deprecating REQ-STRING in the Product Request Message. The desciption of the field is a bit different than in the Archive Request Message, so just needs some investigation to make sure that this message is still usable without the field.

Clarify usage in 1.1 to discourage remote execution

Remove references to database "query" or script expression where the field is listed in the table. Below the table, state that this should specifically not be a database query or script expression.

All fields in the UML Model classes are shown as Private. This would make sense if these blocks were really supposed to be classes, but in their usage in C2MS, these are handled as structures with all fields accessible.

Since we are already going to change every UML diagram in C2MS 1.1, we should consider if it would be good to change these all to Public.

See the attachment for a comparison between fields. Private fields are marked with '-', while private fields (like DATA shown as an example) are marked with '+'.

No change to be done

After discussion between Kevin and Mike, we decided that no change is needed or warranted. Leaving data members private implies better data abstraction for classes with getters and setters, changing to public implies using structs without getters/setters. Which is better or more appropriate seems like a decision for the PSM, rather than the PIM. Leaving this way is less change, and nobody has asked for this. It seems unlikely to be something people will clamor for.

Add field AP-ID (String, Optional) to the message. ME4 should refer to this field for its value. Add field VCID (String, Optional) to the message. ME4 should refer to this field for its value.

Are required for CCSDS packets only, and optional otherwise.

CCSDS Application ID is not present in non-CCSDS telemetry packaging

The CCSDS application id ("APID", "app id") is only present in CCSDS headers for packets. It is not appropriate in other kinds of telemetry packaging.

This is has been removed in C2MS11-54.

It is not clear in the C2MS specification how to use/support the CMD-FORMAT=MNEMONIC on page 168. Explanation of the encoding should be provided to understand how to represent a command mnemonic and its arguments.

This duplicates the later, but more detailed, C2MS11-88

This is a duplicate.

C2MS 1.0 defines MESSAGE-CLASS as an optional field (in the C2MS Header, "Generic field for missions to classify their message set to aid message disposition.").

A principal user of C2MS reclassifies MESSAGE-CLASS as a required field with a finite set of defined enum-like values.

In order to help align this user with C2MS, the C2MS MESSAGE-CLASS field should become required. Alternatively, C2MS should define a way for a consumer of the C2MS definitions to require what is to C2MS an optional field with defined values.

No need to change in C2MS

After RTF discussion, there is no need to make this field required in C2MS. Systems that use C2MS can enforce requiring this field through business/domain logic.

The LOG message is nice to cover a certain scope of messages needing to be utilize by developers using the specification, however the ProductMessage again and again finds itself utilized instead of the LOG message because of the structure the LOG message has versus the ProductMessage for making things like status or event messages.

Because of this, I had looked at the ALMAS specification from Navy and the CAP (Common Alerting Protocol) from OMG to come up with an Alert Notification and Alert Ack message that would be greatly helpful in making a solid Header for alert and status messages that could be different in scope than typical LOG messages.

I have these messages defined in GMSEC/COMPATC2, and would need to attach it for you to see the details. Thank you

The log message is fine, propose a new alert/event message instead

Instead of modifying log beyond its original design goals, anyone may propose a new alert/event message for a future revision. Example: C2MS-1.2.

Subject not able to be fully created from Message fields in all cases.

Add fields DESTINATION-NODE (String, Optional) and DESTINATION-FACILITY (String, Optional) to the messages. ME3 and ME4 should refer to those two fields for their values, respectively.

This is a duplicate of C2MS11-36

This is a duplicate of C2MS11-36.

Add field AP-ID (String, Required) to the message. ME4 should refer to this field for its value. If field AP-ID is added as OPTIONAL, then ME4 should also be changed to OPTIONAL.

Duplicate of C2MS11-39

Duplicate of C2MS11-39

Set the association multiplicity for required fields to '1' and optional fields to '0..1'

Documentation Change to be Made in 1.1

The following changes will be made:

• Make changes to Section 8 PIM – Message Definitions under Field Name to clarify the notation used for "series".
  
  
  • Add a diagram to illustrate the text
    
    
• Make changes to Section 8 PIM – Message Definitions under Required, Optional, Dependent and Tracking to clarify how R/O/D are used and to separate out Tracking since that does not indicate R/O/D.
  
  
  • Add a diagram to illustrate the text
    
    

Make global changes as represented below:

• Make changes to all Message Diagrams, beginning with Figure 8-2. Message Header Diagram and ending with Figure 8-40. Tracking Data Message Diagram to show multiplicity of each attribute. Note that we no longer need the concept of a block called "Required Fields" and another called "Optional Fields". Additionally, each changed diagram will use fields in the same order as found in the "Additional Information" table for the message to improve readability.
  • This is illustrated in the attached before and after diagrams for the following, each showing a slightly different aspect of the changes:
    • the Directive Response Message
    • the Configuration Status Message
    • the Heartbeat Message
    • the Mnemonic Value Request Message
  • The identical pattern will be applied across all the above mentioned figures. Note that the 'revised' diagrams already show changes previously approved from C2MS11-18 (making all messages subclass C2MS Message which contains a Header) and C2MS11-31 (Clarify the UML diagrams regarding the values for the fields inherited from Message Header).
    
    
• Make changes to all Message "Additional Information" tables, beginning with Table 8-3. Message Header Additional Information and ending with Figure 8-40. Tracking Data Message Diagram to show multiplicity of each attribute. This will verify that all tracking fields are described in the tables clearly.
  • This is illustrated in the "revised text" of this issue with table changes for the same four messages listed above, again, each showing a slightly different aspect of the changes. The identical pattern will be applied across all the above mentioned figures.
    
    
• This proposal constitutes a plan to do the above if voted on, though there will be a follow-on vote with a separate issue/proposal to show all the changes before and after for completeness. Vote 'yes' on this one if you plan to vote 'yes' on the final (to avoid extensive work without commitment).

• If this proposal is accepted, a complete set of before and after images will be provided as part a second issue/proposal and if accepted will be provided as part of the RTF Report assuming that second issue/proposal is accepted.
  • Note that the final images may be a convergence with other voted in global figure changes, such as (but not limited to) C2MS11-18. In other words, if this proposal is accepted and others like C2MS11-18 the proposals are also accepted, all sets of changes will be made in the final "after" images in the RTF Report.

It would greatly aid readability of the specification if the tables listing the message contents by field separated the required fields from the optional fields. By doing this, the UML and descriptive tables would be in alignment.

This is true throughout, but for one pretty clear example, see section 8.6.1.3. The UML (figure 8-13) (page 101) and the table (table 8-69) are hard to read together when looking at both.

In this case, there are two blocks in the UML diagram that contain fields: one block is "Required Fields" and the other "Optional Fields". The table, simply shows fields. When reading down the fields in the table, the listed fields come from the two different UML blocks in the following order:

1-Required
2-Optional
3-Required
4-Optional
5-Optional
6-Required
7-Required
8-Optional
9-Optional
10-Required

It would be much more clear to have all the fields in the table be listed in the same order as the UML diagram, with Required first, followed by Optional, along with a column specifying required or optional. Alternatively, there could be two tables: one for required fields in the same order as the "Required Fields" block of UML, and a second table with all the optional fields in the same order as the "Optional Fields" block of UML.

As mentioned above, this is one example, but this disconnect between the UML and the Fields table is true throughout the document.

Changes are being made in C2MS11-14

This issue has been merged into (and is a duplicate of) C2MS11-14.

The ".... Message Header Notes" tables can be confusing. For example, table 8-8. It should be made clear that the fields listed in those tables are from the Message Header definition, but the values apply only for that specific message. A small wording change would go a long way to helping, especially for newer users.

The issue reported is non-specific

The issue reported suggests wording changes to a table or tables related to ... Message Header Notes. But doesn't specifically say what changes should made. Reviewing the text indicated doesn't clarify it, no obvious issue is found.

I believe the distinction between "Header String" and "String" types is to enforce compliance with Subject Element format (UPPERCASE Alphanumeric, "-" and "_" as only valid values). The description of "Header string" in Table 8-1, Field Type Definitions, indicates that this type is used for "subject name elements".

It's a bit confusing to call this a "Header String", because not all Strings in the Header are Header Strings, and some fields are Header String type even though they are not in the Header (Some examples: USER, SUBCLASS, REFERENCE-ID, and OCCURRENCE-TYPE in Log, CNTL-KEYWORD in Control Message).

In all cases, the fields that are Header String type are intended to be used as subject elements.

One side note, that would need to be fixed, either way is that the actual type listed in Table 8-1, Field Type Definitions, lists the type in two places as "Header string" (lowercase s on string), where everywhere else in the document and in UML model figures, it is listed as "Header String".

do it in 1.1

Make changes in the document to replace "Header String" (or sometimes "Header string") with "Subject Token String". Remove the UPPERCASE limitation everywhere except for the first subject element "C2MS". Increase the suggested length limit from 12 to 25 characters. Make consistent the use of "C2MS Subject Name" and "subject name" capitalization (capitalized as C2MS Subject Name, other wise not capitalized).

Numerous field tables in C2MS allow reusing the same REQUEST-ID for a request to provide a "replacement". For example, MVAL REQ Message says in the Fields table (Table 8-99) under REQUEST-ID:

"ID to identify the request message - if different request messages have the same value, the request is a replacement; else, it is a new request"

In all cases, this is the only explanatory text of what is meant by "replacement". This is pretty ambiguous about expected result. So, for example,

• If I send an initial request to start receiving MVAL A and B, and then send another request of the same REQUEST-ID for MVAL C, is the result that I'm now subscribed to A, B and C, or just to C?

• If I send a request to start receiving MVAL X and Y with a PUBLISH-RATE of 1 and then send another request for a duration of 120 minutes, and then send another request wit the same REQUEST-ID for MVAL Y with a PUBLISH-RATE of 5, am I subscribed to X at 1 and Y at 5, or just Y at 5?

There's no description of semantics regarding what is being replaced.

A related issue is STOP request, specifying non-symmetrical MVALs, and what to do in that situation.

• If I send a request to start receiving MVAL 11 and 12, and then send a STOP, but only specify MVAL 11, do I still get 12?

In C2MS 1.0, in every instance of sending a REQUEST-ID as part of a request, the Notes for the field states the identical, "ID to identify the request message – if different request messages have the same value, the request is a replacement; else, it is a new request." However this copy-paste doesn't always make sense.

Re-use of a REQUEST-ID only makes sense if the request leaves some process continuing to fulfill data streaming. Only two request messages have a start/stop concept. Therefore, this resolution assumes no other messages have a use case for 'replacement' and removes the confusing extra text.

Additionally, the concept of 'replacement' is not needed in the two cases where start/stop actions are present... just stop the old one and start a new one. Using 'replacement' can lead to confusion.

Do it in 1.1

Remove the reference about replacement from the Notes column of the corresponding table for messages that don't have any ongoing aspect controlled by start/stop. These are the following:

• Archive Message Retrieval Request Message (Table 8-20)
• Directive Request Message (Table 8-32)
• Archive Mnemonic Value Request Message (Table 8-114)
• Command Request Message (Table 8-131)
• Product Request Message (Table 8-146)
• Simple Service Request Message (Table 8-160)

Modify the text and table notes associated with the following messages to include explanation of the re-use of REQUEST-ID.

• Replay Telemetry Data Request
• Mnemonic Value Request Message

Add fields that allow encryption of content sections of C2MS messages as well as message signatures or message authentication codes. This would not assume or provide any particular mechanism to encrypt/sign, but would allow for tracking of these fields to aid usage.

The benefit of doing this is to allow the Mission to determine levels of security and secure componentry, but to use the message definition as a way to track this information.

Note that currently, GMSEC provides a level of encryption/signing, but my thought is that it would be preferred to allow the mission to manage this outside the transport layer. Providing encryption/signing FIELDS in the message definition allows for this decouplling.

I've got some specific ideas about how to do this, which I can share, but just want to capture the need here.

Part of a TBD Sister Spec

Although it would be a good idea to have security info accompany the message, it really is part of a TBD Sister Spec. Perhaps a Message Envelope that interacts with the MW, rather than embedded within the C2MS message.

There is no “need Echo” in the EGS REQ CMD Message. At present, all we can say is that based on MUS configuration, EGS CMDECHO may be generated.

I propose using a new Boolean CMD-ECHO field in Command Request Message to indicate if an ECHO should be sent at any configured point along the ground chain as the command is transmitted.

This would be an Optional field, defaulting to FALSE.

do it in 1.1

See description for what to do

Typo in the diagram only for Archive Message Retrieval Response calls the Header fields it uses MSG-TYPE and MSG-SUBTYPE. They should be MESSAGE-TYPE and MESSAGE-SUBTYPE, respectively. See page 64, figure 8-5.

Do this in 1.1

Fix Typos in Figure.

Note if accepted along with other proposals that alter figures, there will be a rollup figure changes issue that will contain all the before and after pics to be voted on and submitted for final set of figure changes.

Tracking fields do not specifically belong in a C2MS Message. Rather, there should be a message envelope that contains these fields for the purpose of delivering a contained C2MS message. Recommended here, is to define a C2MB Sister spec that encompasses the 'how' of sending C2MS messages. This is the logical place for managing tracking fields in a "Message Envelope".

This is clear when considering tracking fields, MW-INFO and CONNECTION-ID, which are message-bus handling constructs and have no meaning in C2MS itself.

Part of a TBD Sister Spec

Do this as part of a future possible C2MQ Spec.

The NODE and USER-NAME fields are tracking fields supplied by the implementation (API). They should just be whatever strings are returned by the local o/s rather than forcing them to be of type Header String (upper alphanumeric, "-", "_").

Do this in 1.1

Change the C2MS Message Header diagram. Note that this diagram will change because of other resolved issues. So, this proposal is to vote on this change. All diagram changes will be consolidated together in a future issue/proposal for final versions.

In the Message Header (pages 41-45), add the fields DESTINATION_NODE and DESTINATION_FACILITY as Optional with type of Header String. This enhances the routing/subscribing options currently available for the DESTINATION_COMPONENT field.

Move to C2MQ

It was determined at the RTF in September that this should be transferred to C2MQ.

The way the UML is shown for each message, each C2MS message inherits the Message Header type. This isn't really semantically correct.

Consider the diagram from section 8.6.3.3 (although this is true throughout all message specifications), which is included as Attachment 1. Organized this way, this UML means that Telemetry TDM Frame Message IS A Message Header, rather than that it contains a Message Header.

THere are two options for making this a little more clear:

Option A is that Instead, they should be subclasses of something called "C2MS Message" that itself contains a Message Header, as shown in Attachment 2, in which Telemetry TDM Frame Message IS A C2MS Message, and all C2MS Messages contain a Message Header.

Option B is to use composition where each message contains a message header. This is as shown in Attachment 3.

It's not a major point, but would increase readability and have better optics.

After discussion, Option B seems like the right choice.

Documentation Change to be Made in 1.1

The following changes will be made:

1. Update text in Section 8.1 C2MS Message Header to remove the concept that all C2MS Messages are sub-classes of C2MS Message Header, but rather are sub-classes of a new C2MS Message class that comprises a C2MS Message Header.
2. Modify Figure 8-2. Message Header Diagram to show the new C2MS Message class containing the Message Header, as shown in the attachments.
3. Make the changes to all Message Diagrams, beginning with Figure 8-4. Archive Message Retrieval Request Diagram and ending with Figure 8-40. Tracking Data Message Diagram to make the message contain, rather than specialize the C2MS Message Header.
   • This is illustrated in the attached before and after diagrams for the Telemetry TDM Frame Message.
   • The identical pattern will be applied across all the above mentioned figures.

If this proposal is accepted, a complete set of before and after images will be provided as part of the RTF Report

• Note that the final images may be a convergence with other voted in global changes, such as is proposed with C2MS11-59. In other words, if this proposal is accepted and C2MS11-59 is also accepted, both sets of changes will be made in the final "after" images in the RTF Report.

This issue is related to C2MS11-30, which is about the table immediately prior to every message UML diagram. The UML diagrams, for example figure 8-3, seem to indicate that "MESSAGE-TYPE" and "MESSAGE-SUBTYPE" are fields in the individual message when they are actually in the Message Header.

Do this in 1.1

Remove the current block attributes, and instead show Constraints as in:

with the required values. Display the full Message Header classifier for clarity.

If this proposal is accepted, a complete set of before and after images will be provided as part of the RTF Report

Note that the final images may be a convergence with other voted in global changes. In other words, if this proposal is accepted and other figure-affecting proposals are also accepted, all sets of changes will be made in the final "after" images in the RTF Report.

In Log, Directive Request, and Simple Service Request, there is a USER field for use by communicating applications. This field should be moved to the Message Header, so that any message can utilize this field.

Note: in the Log Message this field is used in the subject, so is defined as a Header String. In the Directive and Simple Service messages, it is not used in the subject so is defined as a string.

Note 2: There is another field in the Message Header called USER-NAME; this is a tracking Field, so is reserved for use by the implementation and is the account/user name that started the application.

Move to C2MQ

This is really part of the C2MQ effort, so rather than add it to C2MS only to later move it to C2MQ is not preferred.

Change the CNTL-STRING field in the Control Message from optional to required. That field is the reason for the message. This also will be consistent with Directive Message, where DIRECTIVE-STRING is required. See Figure 8-9.

Do this in 1.1

Fix Figure.

Note if accepted along with other proposals that alter figures, there will be a rollup figure changes issue that will contain all the before and after pics to be voted on and submitted for final set of figure changes.

The intent of tracking fields is to reserve them for use by the implementation. So, to be complete, these fields should be added to the specification. If any of these fields were to be inadvertently added to the messages by an application, the implementation (GMSEC API) could potentially overwrite their values.

Move to a TBD Sister SPEC

Tracking fields and encryption handling are likely to become part of the in-RFP C2MQ, so this should be transferred to that spec, rather than being implemented now in C2MS only to remove it soon.

The field CNTL-KEYWORD in the Control Message is supposed to contain the keyword extracted from the field CNTL-STRING. It should not be fixed. So, remove the value from the diagram. Figure 8-9. This is a Model change.

Do this in 1.1

Fix Figure.

Note if accepted along with other proposals that alter figures, there will be a rollup figure changes issue that will contain all the before and after pics to be voted on and submitted for final set of figure changes.

See C2MS11-47.

Duplicate of C2MS11-47

Close as Duplicate of C2MS11-47

This is just a documentation clarification. Header Strings are the type used for building message subjects. It's invalid for a message subject element to be null. So, Header Strings need to be at least one character.

Add Text to Table Describing Field

Add a sentence to the "Range/Comments" column of the Field Type Definitions Table.

Requesting data, such as telemetry, via pub/sub requires knowing the publisher's server name. There should be a way to request data without this being already known. This could potentially be solved by a registry concept, as in C2MS11-1, but this particular issue proposes adding a service-matching capability wherein the requester is asking for a subscription to some data and the request results in linking the subscription to a service that provides that data.

Move to a TBD Sister SPEC

There will be discussion in the SDTF about creating a Sister SPEC to C2MS that is more about HOW these messages are created, sent, handled. For now, call this C2MB (message bus). If created this spec would the the logical place for this particular issue.

In the Control Message, the field SPECIAL_INFO is Binary type in the UML diagram (Figure 8-9), but is described as "For application use. Any additional information can be provided here." (Table 8-48).

Because C2MS has no definition or understanding of the binary format, it is probably better if the type be changed to "String", so that opaque data is not transmitted around the system where only the producer and consumer can understand what it is. Log messages, for example, would not be able to record, in any meaningful way, what was sent in the control message.

close

The field needs to be as-is, so closing this issue..

This to be consistent with the XTCE Specification. Moreover Mnemonic isn't accurate as the very definition of mnemonic is a shorthand "code" for the actual parameter name.

Recommend close/deferring this issue, but believe it's important to capture our rationale as the community will ask why the inconsistency between SDTF specifications.

Will not implement.

Would be more correct, but has too much committed use already with GMSEC and existing users/missions.

Justin Boss:
A username or alternate security credential should be able to be provided with all C2MS requests (and possibly should be required)?

Systems should not automatically trust remote clients and therefore a credential should be required with all messages. This would allow components to authorize and audit requests on a per-user/connection level.

Part of a TBD Sister Spec

Although it would be a good idea to have security info accompany the message, it really is part of a TBD Sister Spec. Perhaps a Message Envelope that interacts with the MW, rather than embedded within the C2MS message.

In the current specification, RAW-VALUE is limited to a 32-bit integer and EU-VALUE is limited to 64-bit float (i.e., double). These data types should be changed to allow larger data types to be represented (at a minimum, 64-bit integer should be supported throughout). (From Justin Boss)

Duplicate of C2MS11-19

Not needed, as this duplicates another issue

C2MS should offer a mechanism for clients and/or servers to be able to check validity of a subscription.

Part of a TBD Sister Spec

Part of a TBD Sister Spec

(C2CX Heartbeat) Section 8.5.4

• Suggest not having CPU / Memory utilization in the messages. That would be better implemented through normal system monitoring mechanisms (e.g., SNMP). Code to retrieve such information is typically platform-specific and is not related to the business logic of the component.
• If such information is required, suggest having a system monitoring component instead.
• Unclear exactly how this would work in a clustered environment. Different hosts implementing the same service would provide conflicting answers.
• Unclear why the commentary on why memory leaks are bad is in the spec

Field and Text Changes to Heartbeat Message

Following changes to be made:

1. Remove CPU / Memory utilization in the messages
2. Replace Heartbeat Message Diagram
3. Remove text about memory leaks

See C2MS11-2 for rationale.

See attachments for original and revised figure, Figure 8-11. Heartbeat Message Diagram

Note: There had been discussion about whether it would be OK to remove fields from the spec. At a 2022 C2MS RTF Meeting, Jay was good with removing the fields.

(Archive Mnemonic Value Request) Section 8.9.1

• Need official registry for FORMAT values

The AMVR message has a field called FORMAT that is of type String, but there is no enumeration of possible formats. This could be handled by requestor and supplier agree on a format.

FORMAT is used to define the file format of the return data.

Clarify FORMAT field of AMVAL Request Message

Change the "notes" relating to FORMAT of the message to indicate, similar to SPECIAL-INFO field in Directive Request Message, that this is "For application use".

Based on review of latest specification, the problem detailed in C2MS-5 is still present. This problem makes it not possible for a client application to properly be developed to support all MEPs. If a client application is developed to support MEP2, then it will ignore all future responses after the first ACK comes in when communicating with a server that supports MEP4 or MEP5. If a client application is developed to support MEP4 and MEP5, then it will never think that a request finished when communicating with a server that supports MEP2.

As is currently specified, via table 6-9 on page 20, the Acknowledge is listed as a Final Status. Though it is only a final status in MEP2.

Possible solutions:
1. Remove MEP2. This would make Acknowledge in Table 6-9 have a Final Status of "No"
2. Add an additional status code of Acknowledge Complete (perhaps #7). In this option, Acknowledge (#1) would have Final Status of "No", though new Acknowledge Complete (#7) would have Initial Status of "Yes", Intermediate Status of "No", and Final Status of "Yes".

This is a good idea, but deferring this to a later release due to time

I've run out of time to get this done in 1.1. It's important, but there is already so much work put into 1.1, we need to close that release and can do this one in 1.2.

Discoverability of data is still a major concern due to the lack of a registry.

• Unclear how components are supposed to find out about available resources
• Unclear how components are supposed to find out about related subjects
• What is the associated heartbeat subject of a client, particularly a temporary one?
• ME1 depends on knowing the name of the other end beforehand. Where is this supposed to come from and why should a component have to care about that?
• Recommend a registry be considered and answers to question above.

Part of a TBD Sister Spec

This may be useful for "offline" data sharing services. Probably not for realtime operations on the floor. ... but probably not within scope of C2MS, because this spec defines the message set, not how they are used.

I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

For a complete implementation of C2MS on the systems I use, we need some kind of Procedure Script Execution set of messages. These would include being able to launch procedures, monitor them, show progress, etc. This could be a topic of some significant discussion and is entirely new scope. The closest analogue I have so far found is the Activity Tracking stuff in the CCSDS Mission Operations Common Services.

if I do not write it down, I will forget.

defer to a later 2.0 release

This is a good item to capture, but probably represents substantial work and new message types.

This proposal is to defer it to a future major release.

I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

It seems that there is a consensus that we need database data dictionary informational messages. It seems to be in work. Capturing the item here.

if I do not write it down, I will forget.

Defer Data Dictionary to Future Revision

Incorporating data dictionary messages is a large effort and would provide XTCE described information about parameters, telemetry containers, telecommand containers, streams, etc. This cannot be achieved by the existing RTF so needs to be deferred to a time when we come together to do this.

Due to lack of the ability to have multiple independent implementations of GMSEC due to its message-building API functions in source code, it would be appreciated if there were an XML PSM available. This would allow for an independent implementation apart from the single known implementation at this time. At this time, there is no known PSM that enables implementation of C2MS at this time that does not depend on FOSS or government-licensed IP.

This is based on inputs from C2MS-2.

This requires an RFP, post 1.1 and/or UML diagram update

This should be deferred until the 1.x UML diagram work is complete which will form a PIM.

Non-self-describing CCSDS attributes for either transfer frames or space packets should be provided as dependent attributes of the frame messages. This would enable full integration between a sender and receiver. Right now, whether these optional fields are provided is unknown, causing the proper rendering of the frame to not be possible without outside negotiation (beyond the specification).

Examples:

Frame Header Error Control of the AOS transfer frame (AOS Space Data Link Protocol (ccsds.org)), where nothing prior to it in the definition specifies whether it is there or not:

4.1.2.6 Frame Header Error Control
4.1.2.6.1 If implemented, Bits 48-63 of the Transfer Frame Primary Header shall contain the Frame Header Error Control. NOTE – The 10-bit Master Channel Identifier, the 6-bit Virtual Channel Identifier, and the 8-bit Signaling Field may all be protected by an optional error detecting and correcting code, whose check symbols are contained within this 16-bit field.
4.1.2.6.2 The presence or absence of the optional Frame Header Error Control shall be established by management.
4.1.2.6.3 If present, the Frame Header Error Control shall exist in every Transfer Frame transmitted within the same Physical Channel.

Space Packets and the secondary header (Space Packet Protocol (ccsds.org)): A space packet might have a secondary header with a variable length time code, a variable length ancillary data field, or both. A space packet might have a secondary header, a user data field, or both. The length is not specified for any of them. When present, the format of the time code can be one of several options, but which one is not specified:

4.1.3.3.3 Secondary Header Flag 4.1.3.3.3.1 Bit 4 of the Packet Primary Header shall contain the Secondary Header Flag. 4.1.3.3.3.2 The Secondary Header Flag shall indicate the presence or absence of the Packet Secondary Header within this Space Packet. It shall be ‘1’ if a Packet Secondary Header is present; it shall be ‘0’ if a Packet Secondary Header is not present. 4.1.3.3.3.3 The Secondary Header Flag shall be static with respect to the APID and managed data path throughout a Mission Phase. 4.1.3.3.3.4 The Secondary Header Flag shall be set to ‘0’ for Idle Packets

4.1.4.2.1.5 If present, the Packet Secondary Header shall consist of either: a) a Time Code Field (variable length) only; b) an Ancillary Data Field (variable length) only; or c) a Time Code Field followed by an Ancillary Data Field. 4.1.4.2.1.6 The chosen option shall remain static for a specific managed data path throughout all Mission Phases. NOTE – The format of the Packet Secondary Header is shown in figure 4-3. ANCILLARY DATA FIELD (optional) variable PACKET SECONDARY HEADER TIME CODE FIELD (optional) variable Figure 4-3: Packet Secondary Header

4.1.4.2.2 Time Code Field 4.1.4.2.2.1 If present, the Time Code Field shall consist of an integral number of octets. 4.1.4.2.2.2 The Time Code Field shall consist of one of the CCSDS segmented binary or unsegmented binary time codes specified in reference [3].CCSDS RECOMMENDED STANDARD FOR SPACE PACKET PROTOCOL CCSDS 133.0-B-2 Page 4-8 June 2020 NOTE – The time codes defined in reference [3] consist of an optional P-Field (Preamble Field), which identifies the time code and its characteristics and a mandatory T[1]Field (Time Field). Examples of time codes are CCSDS Unsegmented Time Code and CCSDS Day Segmented Time Code. Examples of characteristics are ambiguity period, epoch, length, and resolution. 4.1.4.2.2.3 The time code selected shall be fixed for a given managed data path throughout all Mission Phases. 4.1.4.2.2.4 If the characteristics of the chosen time code are fixed, the corresponding P[1]field (as described in reference [3]) need not be present. If the characteristics are allowed to change, the P-field shall be present so as to identify the changes. 4.1.4.2.2.5 The presence or absence of the P-field in the Time Code Field shall be fixed for a given managed data path throughout all Mission Phases. If present, it shall immediately precede the T-field that is defined in reference [3]

4.1.4.3 User Data Field 4.1.4.3.1 If present, the User Data Field shall follow, without gap, either the Packet Secondary Header (if a Packet Secondary Header is present) or the Packet Primary Header (if a Packet Secondary Header is not present). 4.1.4.3.2 The User Data Field shall be mandatory if a Packet Secondary Header is not present; otherwise, it is optional. 4.1.4.3.3 If present, the User Data Field shall consist of an integral number of octets. 4.1.4.3.4 If the Packet is not an Idle Packet, then the User Data Field shall contain application data supplied by the sending user. If the Packet is an Idle Packet, the User Data Field shall contain Idle Data. NOTE – The bit pattern of Idle Data is set by the mission and is not specified in this Recommended Standard

4.1.4.3 User Data Field 4.1.4.3.1 If present, the User Data Field shall follow, without gap, either the Packet Secondary Header (if a Packet Secondary Header is present) or the Packet Primary Header (if a Packet Secondary Header is not present). 4.1.4.3.2 The User Data Field shall be mandatory if a Packet Secondary Header is not present; otherwise, it is optional. 4.1.4.3.3 If present, the User Data Field shall consist of an integral number of octets. 4.1.4.3.4 If the Packet is not an Idle Packet, then the User Data Field shall contain application data supplied by the sending user. If the Packet is an Idle Packet, the User Data Field shall contain Idle Data. NOTE – The bit pattern of Idle Data is set by the mission and is not specified in this Recommended Standard

Topic requires deeper examination and solution in future revision

The topic is larger than the time frame to address in version 1.1 but is accepted overall.

Add the DBQUERY messages that were defined by NASA to the formal specification.

These messages are listed as being part of the OMG specification here:
https://software.nasa.gov/software/GSC-18536-1

"A Graphics User Interface (GUI) based desktop viewer for XML Telemetry and Command Exchange (XTCE) files which allows some editing of the various XTCE properties of that open file, and then allows saving the updated information back to file. It includes a Goddard Mission Services Evolution Center (GMSEC) GMSEC Search XTCE (GSX) connector to support some GMSEC/ (Command and Control Message Specification) C2MS Database Query (DBQUERY) messages to search for some XTCE information which is then sent over GMSEC bus to the initiator of the search request."

Redo this in 1.2

It turned out that this needs more work. Kevin to supply full analysis and rework this for 1.2.

For most of the message types in C2MS, this convention is followed. The exceptions are:

-Archive Message Retrieval Request
-Archive Message Retrieval Response

These were likely left this way because they already have "Message" in the name, though with a different meaning. Archive Message Retrieval Request Message does sound redundant. Perhaps renaming to any of the following would help:

• Archived Messages Request Message
• Archive Retrieval Request Message
• Archive Request Message
• Archive Message Request Message

Not using "Archive Message" in the title is a bit confusing because there is Archive data that is not simply archived messages, see "Archive Mnemonic Value Request Message"

Note that when originally entered, this issue listed all the following... but in 1.1, the only messages not ending in "Message" are the Archive request/responses.

-Archive Message Retrieval Request
-Archive Message Retrieval Response
-Telemetry Message for CCSDS Packet
-Telemetry Message for CCSDS Frame
-Telemetry Message for TDM Frame

defer to a later 2.0 release

Only the two messages are affected, and the solution is to rename these, so deferring to 2.0.

I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

The messages for mnemonic access do not appear to include a request/response for "setting" the value of a parameter (mnemonic) from an application participating using C2MS. This capability is used for ground and other types of non-telemetered parameters (mnemonics).

if I do not write it down, I will forget.

defer to a later 2.0 release

In Austin (Dec/2022) RTF, we determined that this should be deferred to 2.0, since it represents a more significant change.

Some services may depend on other services to satisfy a request. Create a MEP that discusses and shows how this could work.

Defer to later release

This needs a use case. Probably best to defer at this point, with so many other issues on the docket.

TLM and MVALs can be retrieved from the archive, but it would be useful to define a way to retrieve archived Commands and Events as well, since these represent, along with TLM, the SatOPs messages.

Add Session Type and Session UID to Standard Subject in a future version but defer for now

Add Session Type and Session UID to Standard Subject in a future version but defer for now

Harmonization Needed

I’d like to recommend a review of the Replay Telemetry Data Request Message compared to the Archive Mnemonic Value Request Message. These two messages should be nearly identical in form, but appear to have grown up in neighborhoods on opposite sides of the tracks.

Some base behaviors are different between the two. Many fields exist in one request message but not the other. In one case, the same field exists in both request messages, but has a different meaning. The response paradigm is different between the two message sets.

This issue is to harmonize the two message sets.

Throughout this discussion, I’ll use the following abbreviations:

• “RTDRM” - Replay Telemetry Data Request Message
• “AMVRM” - Archive Mnemonic Value Request Message

Sections below describe elements of the two that are dissimilar:

Message Naming

For TLM, the Message is called Replay Telemetry Data Request Message (RTDRM). For the MVAL it is Archive Mnemonic Value Request Message (AMVRM). Since both have the concept (implemented differently) of replay, but the AMVRM has a way to receive the data as an output file, I think that “Archive” is more meaningful. In fact the descriptive text under the RTDRM, refers to the “Telemetry Archive component”. So, I’d suggest renaming the RTDRM to Archive Telemetry Data Request Message to match better with Archive Mnemonic Value Request Message.

Real-time and Future “Replay”

Replay Telemetry Data Message set includes a long description of how to use the “replay” service provider as a way to get real-time, or even future TLM messages (Section 8.7). There is no analog in Archive Mnemonic Value Messages.

I recommend we don’t include that discussion in the Archive Mnemonic Value Messages. It seems odd to have “replay” messages for something that isn’t replay. I believe the same intent can be achieved by simply requesting a “replay” whose end-date-time is in the future, and indicate that the archive service will continue to send out TLM, as long as it is put in the archive during that window. That is logically similar, without trying to fake out the system, because the data would still originate from the archive.

The STREAM-MODE of the RTDRM (sec 8.7.1.3) can be RT or RPY, to accommodate the intent of separating real-time from replay. I don’t’ think this is needed. If we assume that we only replay data that is in the archive, whether it is arriving into the archive now or in the future, this is logically the same and wouldn’t require special handling in the message definition.

Section 8.7.1 indicates that the two fields PLAYBACK-RATIO and DATA-RATE (described in sec 8.7.1.3) only apply if the STREAM-MODE is RT. However, having to specify STREAM-MODE as RT or RPY doesn’t seen necessary. These values could easily be applied to RPY: this would mean that the playback rate would be some ratio of the timing of the original TLM (play back at the same rate it was originally received, or some ratio related to it) or play it back at a certain data rate, from the archive. The distinction makes it awkward and I don’t think it’s necessary. The AMVRM uses PLAYBACK-RATIO and DATA-RATE with exactly these meanings, without any indicator of STREAM-MODE.

I’m confused about what is meant by the fields of the RTDRM in Section 8.7.1.3 for files. There is a NUM-OF-FILES and a FILE.n.NAME-PATTERN, with very limited description of how this is to be used. The only clue is in Section 8.7.1, where there is indication that this only applies to a “real-time data stream”. I’m not sure how the requester is to know the names of files in the archive and why this would only apply to RT. Probably should be removed, unless we have a specific use-case for it.

STREAM-MODE

STREAM-MODE (described in sec 8.7.1.3) exists in RTDRM, but not in AMVRM at all. This would be useful in AMVRM, because STREAM-MODE can indicate SIM or TEST. RT and RPY are not needed, as described above.

Request All Data Construct

In addition to retrieving MVAL Data Messages as a stream, the AMVRM also has the concept of requesting the entire data set in a single message. In fact, this can either be in the payload of the single message or the data can be placed in a file at a specified URI. The RTDRM does not have this concept at all, and all retrieved TLM must be in a set of streamed messages. I like this capability of the AMVRM and recommend that it be added to the RTDRM.

One oddity in this concept is that in the AMVRM (sec 8.9.1.3), if the RESPONSE-VIA-MSG is set to RESP.AMVAL, then it can be delivered in the single message or at a URI. However, the selection is controlled by two Boolean fields: DELIVER-VIA-REFERENCE (URI) and DELIVER-VIA-INCLUDE (message payload). It’s odd that these are separate Booleans, because there is no description of what would happen if they are both set to ‘0’ or if they are both set to ‘1’. I can surmise that setting both to ‘0’ would be an error and setting both to ‘1’ would mean to deliver the data set in both the single data message and also at the URI, but it’s hard to imagine the usefulness of doing so. I’d recommend we drop DELIVER-VIA-INCLUDE and just use the DELIVER-VIA-REFERENCE to mean that the data is to be EITHER in a URI OR in the data message.

ACTION Field

The RTDRM has an ACTION field to control flow (start, stop, etc). There is no analogue in AMVRM, but there probably should be.

PDB-VERSION Field

The AMVRM has a PDB-VERSION field. This field does not exist in RTDRM. To me this seems way down in the weeds, and was probably an add-on for a special one-off case somewhere along the line. Is it necessary? If not it should be removed. If so, it should be added to RTDRM as well.

ORBIT Field

RTDRM can specify a particular orbit. This field does not exist in AMVRM.

Filename Fields

RTDRM, as discussed earlier, has fields for the source files for TLM. This concept doesn’t exist for AMVRM. Unless we can come up with a specific use case for this (along with a better description of the fields in the RTDRM), I’d be in favor or dropping it from RTDRM. Otherwise, it should probably be added to AMVRM for consistency.

FORMAT Field

Both RTDRM and AMVRM have a FORMAT field. They are used for different purposes. I’d recommend calling the one in RTDRM TLM_FORMAT and the one in AMVRM something like FILE_FORMAT since that corresponds to their use.

VCID and APID Fields

RTDRM has VCID and APID fields. The AMVRM does not. Yet, the MVALs originated from the same TLM stream, so these seem applicable to AMVRM. Needs discussion. Note that both request messages have COLLECTION-POINT with identical meaning, so the origination of TLM and MVALs are tied in that way.

Mnemonic Value Data Message vs Archive Mnemonic Value Data Message vs TLM Messages

In the RTDRM, asking to retrieve TLM messages results in identical TLM messages to when these messages came in, real-time. The only exception is in the STREAM-MODE of that message type, which is set to RT for original messages, or RPY for messages coming out of the archive. This is a useful construct.

However, for AMVRM, the original real-time messages have one format, defined in section 8.8.3.3 and a different format for messages retrieved from the archive, described in section 8.9.3.3.

It seems logical to use either one pattern or the other. I prefer the pattern used by TLM, where the original message format reappears, but with a designator that it is a RPY message.

defer to a later 2.0 release

This is a good reason to have a C2MS Roadmap discussion. For now, defer to a later release (2.0?)

From Justin: In the current specification, RAW-VALUE is limited to a 32-bit integer and EU-VALUE is limited to 64-bit float (i.e., double). These data types should be changed to allow larger data types to be represented (at a minimum, 64-bit integer should be supported throughout). May need a separate field to indicate the type of data in these fields.

[NOTE: the reason for deferment is simply say making the RAW-VALUE a 64 bit and the EU-VALUE 128-bit float falls outside of hardware support and programming language support -- and adding a DATA-TYPE field to support the specification of any valid c2ms data-type in either field seems like a big change that should be considered more fully.]

The current spec supports a RAW-VALUE and EU-VALUE (converted/calibrated) fields. Currently the RAW one is a 32-bit signed integer and the EU one is a double (64-bit). To support a broader value type and range, this change adds a RAW-VALUE-TYPE and an EU-VALUE-TYPE to any message these fields are in. In some cases, if the message has both a RAW and EU value, these could in some cases be identical. Additional optional (special case) fields are also added RAW-VALUE-LENGTH and EU-VALUE-LENGTH, these two are discussed below.

The RAW-VALUE-TYPE and EU-VALUE-TYPE would be one of the C2MS data-types and be valid for all samples in the message. Hence, they are only specified once per message.

For example, a typical combination might be: RAW-VALUE-TYPE=I32, EU-VALUE-TYPE=F64 for numeric calibrated telemetered values.

The main reason in some cases to preserve both the RAW and the EU value is that in some cases there's a need to re-calibrate existing values and the raw can then be used to do that... [are there any others?]

[It's worth noting that RAW here may mean literally bit-by-bit what's in the packet or it could mean "host corrected" (byte swapped) but without calibration -- we should sort that out. In fact, C2MS does not say that I can tell ... I'm aware that some orgs support the notion of raw from the packet, host-converted (byte/bit corrected), and fully calibrated) in which case within discussion we may want to have 3 fields, which seems excessive. I think I prefer 'host-corrected' for the raw, as we can only do so much, and some folks might not have the truly raw bits available anyway...]

RAW-FIELD-TYPE and EU-TYPE-TYPE are of type String. The legal values are specified in table 8.1 column Field-type. Note that these should probably be mixed character legal in these fields.

Two OPTIONAL fields are available for type binary (blob) and variable. These types SHALL supply RAW-VALUE-LENGTH and EU-VALUE-LENGTH which are both I32 and specify the number of bytes for either field value. Negative values are illegal. From an implementation point of view in regard to these variable length fields, that messages beyond a few megabytes are likely not supported.

Add RAW-VALUE-TYPE and EU-VALUE-TYPE and two additional optional fields.

[NOTE: the reason for deferment is simply say making the RAW-VALUE a 64 bit and the EU-VALUE 128-bit float falls outside of hardware support and programming language support -- and adding a DATA-TYPE field to support the specification of any valid c2ms data-type in either field seems like a big change that should be considered more fully.]

The current spec supports a RAW-VALUE and EU-VALUE (converted/calibrated) fields. Currently the RAW one is a 32-bit signed integer and the EU one is a double (64-bit). To support a broader value type and range, this change adds a RAW-VALUE-TYPE and an EU-VALUE-TYPE to any message these fields are in. In some cases, if the message has both a RAW and EU value, these could in some cases be identical. Additional optional (special case) fields are also added RAW-VALUE-LENGTH and EU-VALUE-LENGTH, these two are discussed below.

The RAW-VALUE-TYPE and EU-VALUE-TYPE would be one of the C2MS data-types and be valid for all samples in the message. Hence, they are only specified once per message.

For example, a typical combination might be: RAW-VALUE-TYPE=I32, EU-VALUE-TYPE=F64 for numeric calibrated telemetered values.

The main reason in some cases to preserve both the RAW and the EU value is that in some cases there's a need to re-calibrate existing values and the raw can then be used to do that... [are there any others?]

[It's worth noting that RAW here may mean literally bit-by-bit what's in the packet or it could mean "host corrected" (byte swapped) but without calibration -- we should sort that out. In fact, C2MS does not say that I can tell ... I'm aware that some orgs support the notion of raw from the packet, host-converted (byte/bit corrected), and fully calibrated) in which case within discussion we may want to have 3 fields, which seems excessive. I think I prefer 'host-corrected' for the raw, as we can only do so much, and some folks might not have the truly raw bits available anyway...]

RAW-FIELD-TYPE and EU-TYPE-TYPE are of type String. The legal values are specified in table 8.1 column Field-type. Note that these should probably be mixed character legal in these fields.

Two OPTIONAL fields are available for type binary (blob) and variable. These types SHALL supply RAW-VALUE-LENGTH and EU-VALUE-LENGTH which are both I32 and specify the number of bytes for either field value. Negative values are illegal. From an implementation point of view in regard to these variable length fields, that messages beyond a few megabytes are likely not supported.

According to the Command Echo Request:

“This message is nominally sent after a Command Request is processed by the final destination (e.g., antenna or spacecraft). The Command Echo Message can also be generated without a prior Command Request Message being sent; this is known as an 'unsolicited echo' and can be generated by ground station equipment as a result of the antenna receiving noise or interference.”

The concept of an unsolicited echo seems very strange, because it raises the question of what is being echoed, if it is not the command.

The Command Echo Message Additional Information table has a CMD-ECHO-RESULT value of UNEX "Unexpected echo received" which I suspect is tied to the "unsolicited echo".

If an unsolicited echo is meant to convey that the ground equipment is receiving noise or interference from the antenna, I believe a better approach would be to define a message to capture the noise or interference as an occurrence in the ground string and to send that, rather than to overload the Command Echo Message.

Move to a later release

We may need a new message type, or simply stop saying that there is an unsolicited echo, but either way, it's not urgent enough for 1.1's short timeline.

In the current version of the model, there is no descriptive documentation within the model itself. This could be easily added from the non-normative specification and would aid engineering teams who use the model.

Defer to later version when process is clear

Until we have a way to generate the doc from the model, we don't want to duplicate or create copy-paste issues or especially to become inconsistent between the document and the model documentation. The RTF meeting in June 2022 determined to defer it.

Many fields in many messages contain value information. Some of the values are defaults and some are intended to be constant. Also, this information is in the "notes" column. There should be a way to differentiate between fixed and default values more easily than reading the notes fields. Also, this will make encoding those attributes in the .xsd PSM easier.

Defer to a later release

This would have been nice to fix in 1.1, but more urgent issues still need work in that release.

There is a STREAM-MODE in Replay Telemetry Message, but in this case, I believe what it is there for is to say what types of telemetry messages to replay. It's not part of the Subject, the way STREAM-MODE is for other messages. I'm not sure it makes sense in this message type and should be re-evaluated. At a minimum, beefing up the description of it would be helpful.

Defer to a later release

Needs some re-evaluation, so moving out of 1.1

The "Publish" MEP second paragraph talks about using either MSG or REQ messages as a means of publishing. I think this could use some revisiting.

It seems on that a REQ message "may or may not require a response. For example, one component may request another component to take some action and does not need to know immediately if the action was successful or not." f(section 6.3.2.1, pg 15). This is then enabled by specifying a BOOLEAN value for "RESPONSE" indicating whether a reponse is expected in a REQ message.

To me, it seems like not expecting a response when issuing a REQ message is a corner case. Even in the example above, how do I know that ANY component received the REQ? I would prefer to say that components that process a REQ message are expected to respond AT LEAST with a RESP Message acknowledging receipt. If the sender chooses not to look for one, fine, but it seems like an odd pattern to make a request and ignore whether anyone heard you.

This would aid in simplifying the Publish MEP to reduce it to just MSG. Actually, if we don't do this, we need to fix the sequence diagram on pg 24, anyway, because as shown it's incorrect; requiring sending a MSG before sending a REQ. It's really meant to be either-or. So, if we remove REQ as a Publish mechanism, the diagram will be adjusted to be correct. If we don't remove it, we need to split the SD into two separate diagrams.

With all this in mind, I'd suggest:

• that the Publish MEP use only MSG Messages, which is what they are intended for
• and stating that REQ messages expect a response, even if it is only an acknowledgement (this would also remove the RESPOSE:BOOLEAN field from REQ messages.
• this results in modifying the Sequence Diagram for Publish MEP (Note that this diagram is actually incorrect, anyway, because as shown, it says that to Publish, the publisher sends a MSG and then a REQ.) At a minimum, this diagram needs to be fixed, even if we don't make the semantic changes described here.

Note that if we remove "RESPONSE:BOOLEAN" concept, this affects the following:
8.4.1.3 Directive Request Contents
8.10.1.3 Command Request Message Contents
8.12.1.3 Simple Service Request Message Contents

Additionally, we'd need to look for scattered text in the spec that says REQ does not require a response.

Defer to a later release

This would have been nice to do, but deferring because of it being a lower priority that several other issues still needing attention in 1.1.

Simple Service Request uses ME1 to indicate the target of the request, but this can have one of two mutually-exclusive forms:

• Service Provider Name (a named instance of a component, such as FDServiceApp1)
• A Service Name not related to a specific component (such as Flight Dynamics)

Meanwhile, the Simple Service Response also uses ME1 in a similar, but slightly different way. In the RESP, ME1 represents one of two mutually exclusive forms:

• A Requestor Name (a named instance of a components that requested a service, or will receive data from the Service Provider, such as C2App7)
• A Service Name not specific to a component (such as Flight Dynamics)

Note that when using ME1 to designate a component, it is always the target recipient of the request/response, but when specifying a Service Name, it is always the name of the Service Provided, which is more related to the responder than the requestor. In this way, the Request Message uses that form of ME1 to designate the recipient, but the Response Message in that form designates to the provider.

This dual-hatting of ME1 is pretty confusing. One major user of C2MS has modified these messages to separate out the two uses of ME1 into ME1 and ME2, shifting ME2 and ME3 to the right.

This issue reqeusts to do that same thing, matching the modification made by that major user.

Move to a later release

This will take some thought, so moving beyond the tight-timelines of 1.1.

In the Command Request Message, the Binary "CMD-DATA" message contains the packet/fram/CLTU, etc, for all CMD-FORMAT types. However, if the CMD-FORMAT type is MNEMONIC this doesn't make as much sense.

Suggestion here is to create a new field in Command Request Message, "CMD-MNEMONIC" as type STRING to hold the human-readable MNEMONIC for command lookup if the CMD-FORMAT is of type MNEMONIC.

In this way, both CMD-DATA and CMD-MNEMONIC would be Dependent fields, with usage based on the contents of CMD-FORMAT.

RTF proposed (Burlingame, 2022) to do a second message type for MNE types, with 0-n parameters, each parameter specifying a type. Mike to create proposal text.

propose a new message type for MNE with Req/Resp, but deferred to 1.2

We will want do to do a second message type for MNE types, with 0-n parameters, each parameter specifying a type. Mike to create proposal text.

However, this is being deferred to after 1.1.

Many fields in the C2MS Header (which have of necessity also been put in the C2MS Envelope) should be evaluated for change or removal in the next major release. Change to be made in both C2MS Message and C2MS Envelope. Examples:

• ROLE should be renamed COMPONENT-ROLE to avoid confusion with user role (authorization).
• USER-NAME should be removed. This seems to be only debug info and does not have anything to do with authentication/authorization. The new fields SENDER-IDENTITY and SENDER-ACCESS in the envelope provide that.
• FACILITY/NODE/PROCESS-ID/CONNECTION-ID are candidates for removal. These seem only valuable for debugging. Debug info doesn't belong in a standard, IMO.
• CONNECTION-ID should be removed. This is definitely only valuable for debugging.
• MW-INFO - no idea why this is there. Probably need a use case or example of what this is used for, but it doesn't seem to belong.

Defer to next major release

This should be done, but needs to be in a major release.

We have already added a CMD-ECHO boolean to the Command Request Message in C2MS11-87. However, there is a possible scenario where just because we asked for one, there is no way for one to be delivered.

According to C2MS11-87, the field is an attempt to "Indicate if an ECHO should be sent at any configured point(s) along the ground chain as the command is transmitted."

The question of this issue is around what to do if the back-end system is not capable of or is not configured to send an Echo. In that case, there would quietly be no echo at all in spite of setting that flag to true. Gerry has brought up that perhaps we need a message type that is "unable to echo" or use the CMD ECHO message with a value of "here's your echo, but we aren't able to collect any information".

Move to a later release

This will require some analysis, it's not urgent enough for 1.1's short timeline.

This is one for C2MS 2.0. Capturing it here, because this is the only avenue to enter issues at present.

Instead of a F32 for version number, which then uses a year, like 2024.0, we should change this to a formatted string that uses Semantic Versioning, with a string that looks like the following:

MAJOR.MINOR.PATCH

Examples: "2.0.0", "2.1.1"

Note that this means changing the base type and the meaning of the current version numbers.

Note, too, that this shouldn't simply be type STRING, but should be something like VERSION-STR with the format defined by C2MS.

Also, consider getting rid of the separate header version and message content version. This is just something to bring up to the group.

defer to a later 2.0 release

Defer

Mnemonic Value Request Message and its corresponding Mnemonic Value Response Message utilize a concept called "ONESHOT" or "Oneshot". These are the only messages in C2MS that have this construct.

This is described in Mnemonic Value Request Message as:
"The Mnemonic Value Request Message is used to request one or more mnemonics either as a single sample ('Oneshot') or as a request to Start publishing the mnemonics continuously."

and

Mnemonic Value Response Message:
"For a 'Oneshot' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the values of the requested mnemonics and no further Mnemonic Value Data messages will be published."

However, in a significant way, these statements conflict with the next line:
"For a 'Start' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the initial values of the requested mnemonics and subsequent occurrences of the mnemonics will be published via the Mnemonic Value Data Message."

In other words, the Response Message will contain the initial set of data (current point values) in response to EITHER 'Start' or 'Oneshot'. The description says "either or" ("either as a single sample ('Oneshot') or as a request to Start publishing"), but the logical statement should be "yes and maybe" (Both Oneshot and Start will contain the initial set of data, but only Start will be followed with Mvals).

The effect of this is that the MVAL Req/Resp works in a primary subscription-based manner or in a different manner when specifying ONESHOT.

With this in place the MVAL Req/Resp sometimes follow the Request/Response Message Exchange Patter, and other times follow the Request/Response/Publish MEP. In fact, figure 8-19 Mnemonic Value Message Sequence Diagram illustrates the Request/Response/Publish MEP. It is not valid for the Request/Response MEP. No example of the Request/Response MEP is shown for this message.

Furthermore, some fields are handled specially depending on which MEP is used. For example, it is stated in the spec that when using ONESHOT, the following fields are ignored in the Request:
• PUBLISH-RATE
• DURATION
• MNEMONIC.n.CRITERIA
• MNEMONIC.n.SAMPLE-RATE

Meanwhile, in the Reponse, RESPONSE-STATUS field values 3 and 4, likely only apply to ONESHOT, while 1 likely only applies to non-ONESHOT. requests.

This odd dual-purposing of these messages was all likely done at some point out of convenience of overloading existing messages rather than creating new messages that would have been a more coherent design.

It has the effect, for a 'Start' of the consumer needing to read both the MVAL Return message for data and then a series of MVAL data message, rather than simply reading MVAL data messages.

In order to remove this overload, I suggest one of the following:

1 - deprecating ONESHOT and related fields in those messages and creating a new Message Type for retrieving current values. These could be called Mnemonic Current Value Request Message and Mnemonic Current Value Response Message.

2 - removing the value fields from the Response Message above, then simply convert the ONESHOT to a form of Request/Response/Publish MEP in which only one publish happens, and then the subscription ends. Subscription termination is already part of the spec, because of DURATION. The way this would work is the requestor sends a request message marked for ONESHOT, the service sends a response message, the service sends a single Mnemonic Value Data Message, the subscription is terminated. In this way, Mvals are only communicated in one message: Mval Data Message, easing the burden for handling two message types.

In a certain sense, I like the first option better, because it addresses the need to get current values using dedicated messages. However, the second approach is a much smaller change and represents a solution that is FAR more straight-forward than the way it is implemented today.

move to a later release

This should be considered in a later release, maybe 2.0.

This is for 1.2, but have to enter it in 1.1 as that is the only current jira project. I expect it to be deferred, but think it should be done in 1.2.

There is frequently confusion about how C2MS should be used. Normal use patterns are not described in the C2MS document, and this would be useful to add as a guide to users. This is especially true when C2MS is used in an enterprise environment, because common interpretation is critical.

The idea is to communicate context for how C2MS has been created and how it is expected to be used.

This could be in the form of a section called "System Architecture", "Guidance", "User Guide", or something like that.

Defer to 1.2

Defer

The text for MVAL and related messages doesn't explain or give examples of how to specify for example an array or record – for example a BATV[1] or something more complicated like: SBUS.STATUS.PFRAME[27].STACK_DEPTH.

Any text addressing this should also discuss the XTCE repeat concept which the author of this issue believes today is handled by NUM-OF-SAMPLES.

Defer to a later release

Defer

In C2MS2.0, we need to revisit the Req/Resp/Pub MEP, as is the same with MVAL Req, followed by an MVAL Resp, followed by an indefinite number and duration of MVAL Data Messages.

This should really be either a standard Pub-Sub construct or should just be a simple req/response.

defer to a later 2.0 release

Defer

Replace simple service REQ/RESP and deprecate current simple service messages.

Numerous issues are present with the current Simple Service REQ/RESP Messages. These include:

• Destination Component is overloaded with two different meanings, depending on use.
• Using Destination Component for SERVICE-NAME essentially requires the mission to establish a naming convention to separate SERVICE-NAME from DESTINATION-COMPONENT strings in order to tell the difference between them.
• The Request can include a SERVICE-GROUP to further the SERVICE-NAME, sort of like namespacing, but this SERVICE-GROUP is not included in the Response message, which means that if needed in the Request, it is not possible to correctly correlate a Response to a Request.
• The paradigm does not include a publish MEP natively, so at some point in the past, GMSEC/C2MS declared that a Request Message could be used to publish information, completely outside the Req/Resp MEP.
• Current usage is to submit a request and then to have the response message indicate either the DESTINATION-COMPONENT of the original requestor or, alternately, the SERVICE-NAME associated with the original request. In keeping with other response messages, it should probably be just the DESTINATION-COMPONENT. It doesn't really need to have the option to use SERVICE-NAME, because the requestor is known. It also creates an odd and confusing alternate use, where in the current mode, the DESTINATION-COMPONENT is the requestor, but the SERVICE-NAME is related to the provider.

Together, this makes the Simple Service Messages hopelessly tangled. The effort here is to start from scratch, deprecate the existing messages and move forward with something more workable.

In this there are two factors that need consideration:

• The Simple Service (and its replacement) should be intended for emerging services that go online in an existing domain, but that have not yet been able to establish their own set of dedicated C2MS-derived messages. It should not be the case that services live forever on this Simple Service (or replacement) mechanism.
• The C2MS Messages themselves, perhaps in 2.0? should have a mechanism for extension without having to define new messages types. In other words, a service provider should be able to create a C2MS message that is simply expanded by what the service provider needs. If this can be accomplished, the Simple Service Paradigm is greatly aided, either by providing an easier path to offload the temporary use of Simple Service, or even by obviating the need for Simple Service.

Defer to a later release

This issue is important to work on, but doesn't fit in the timeframe of C2MS 1.1.

Some fields and message elements that should be required are listed as optional. For example, in the Telemetry CCSDS Packet Message, ME SCID was added in 1.1, so had to me marked optional, but it should be required. APID already existed in that message as a Message Element, but not as a field, so whereas the ME is required, the field had to be made optional (for backward compatibility).

Additionally, in section 6.2.2 Format of C2MS Subject Names, there is a description that says, "If an element is required but not applicable for that mission or to that type of message, the publisher inserts “FILL” (no quotes) for that element." However, this should be cleaned up. If a field is required it should be required, if not, then it should not be required. Need a run through the messages to see how this can be improved.

Do this in the next major release

This should be done, but in the next major release.

Some Message Elements and Fields are in different order from message to message. The fields are just a listing so not as important, but the MEs are order-dependent. One example of how this is an issue is that the Telemetry CCSDS Packet Message added a new ME, but this had to go to the end (ME6) because of backward compatibility. This creates a strange ordering with VCID, APID, Collection Point, SCID. This is just one example, but the need is to evaluate all the MEs and fields and see if any need to be moved to make messages more uniform in structure.

Additionally, there are cases where some MEs have been removed between 1.0 and 1.x, leaving "not used"/"FILL" in the corresponding positions of MEs and these need cleaning up.

Next Major Release

This should be done, but can't be done until the next major release.

With the advent of the C2MS Message Envelope, some tracking or meta-data fields exist in both the new Message Envelope and in the already-existing C2MS Message. For now, it is the case that we want to leave fields in the C2MS message and encourage migration toward Message Envelope usage. In a follow-on release, the duplicated fields should be deprecated in the C2MS Message.

Plan on doing this in 1.2

This needs to be done, but should wait at least one release cycle.

In C2MS 1.0, there is no indicator whether a tracking field (special fields in the Message Header and Heartbeat Messages) is required, optional or dependent. As such, in C2MS 1.1, we are marking these all optional, except for Heartbeat.SUBSCRIPTION.n.SUBJECT.PATTERN, which is being marked as dependent (required if NUM-OF-SUBSCRIPTIONS is > 0).

These should all be evaluated for R/O/D. One special case is HEARTBEAT.NUM-OF-SUBSCRIPTIONS. Normally, this should be required, because of C2MS11-135. However, in discussion for C2MS11-187, we went back to optional for this field. The rationale for this is that because it is a tracking field and therefore reserved for use by the PSM, rather than the generator of the message, it is difficult to understand what it means for a tracking field to be required. This reflects a shortcoming of the current C2MS documentation where it's not very clear what it means for a field to be a tracking field.

Finally, there are some tracking fields that should be considered for removal, such as CONNECTION-ID, MW-INFO, and USER from the Message Header. These fields seem useful for debugging, but not operations.

With the context stated above, the following need to be addressed in a future revision of C2MS:

• Revisit which tracking fields should remain and deprecate the others.
  • • As part of this, note that outside the Message Header, the only C2MS message that defines tracking fields is the Heartbeat Message. Do these belong? It just seems strange.
• Determine R/O/D (required/optional/dependent) for each tracking field. Note that in an OMG meeting in Jan, 2024, broad-brushing it, it appeared that UNIQUE-ID and PUBLISH-TIME in the Message Header and NUM-OF-SUBSCRIPTIONS in the Heartbeat could be required, and the others optional in the Message Header.
• Document the expected use for these tracking fields, including:
  • • What the expected population of tracking fields is by both the Message Sender and the underlying PSM. (example, many of these are set as part of the GMSEC API and are supposed to be left alone before invoking the API in the one PSM that we currently have, but this is inner-workings knowledge and not clearly specified in C2MS).
    • What the expected use of these tracking fields, if any, is by a Message Recipient. For example, are these stripped off by the PSM before delivery? That would be symmetrical if the PSM populates the fields, but no mention of this exists in the current documentation. Some fields may be handled differently from others... for example UNIQUE-ID makes sense, but is the PSM really going to deliver CONNECTION-ID to the Message Recipient?
    • What does it mean if a tracking field is required? If only the PSM sets them, this would mean that a message would have to be created without a required field and then handed to the PSM, which is required to populate it.... this all needs clarity in the documentation.

Defer to a later release

Defer

The Resource Message stated objective is to enable publishing "computer performance data" via a defined C2MS message. However, using C2MS messages to monitor CPU load, memory utilization, and network port status seems wholly out of scope for satellite command and control. This provides what is essentially a rudimentary mechanism for resource monitoring, which could easily be better accomplished through industry standard mechanisms completely outside of C2MS.

In C2MS11-2, we removed CPU and memory related data from the Heartbeat Message. It makes sense to completely remove the Resource Message (via deprecation) for the same reason.

Defer to a later release

Defer

Some message fields of type Boolean are listed as optional. This has a pretty ambiguous meaning for a boolean, which if present, is always True or False.

For one non-exhaustive example, some messages include a FINAL-MESSAGE boolean field that is optional. What does it mean when not present? It could be inferred that it is equivalent to False, but it could also be inferred that this is ignored when there is only one message, which would be the same as True.

We need to go through all these usages individually and decide if these should be required, rather than optional.

Defer to a later release

Defer