In the C2MS 1.2 spec for the CCSDS Packet Message, Table 8-72 specifies VCID & APID as required for the subject but in the 8-74 table VCID & APID are optional Fields.

Need a disposition on VCID. Note that VCID was required in 1.0, optional in 1.1/1.2 (except in the subject), so maybe make it optional for backward compatibility with 1.1/1.2.

APID should be optional everywhere, because it was added in 1.1, so can't force backward requirement here.

Note, too, that the description in the Subject for APID should say it comes from the APID field instead of the nebulous "From the Header".

Some of the Navigation Data Messages have the field DATA as a Binary others have DATA as a String. Should just look into this and see why. Likely due to stated CCSDS formatting for each type.

It was determined in the RTF in Chicago 2026 that these should really just be String, but not backward compatible to make that change. Therefore, this is going to be in a major release. Meanwhile, the NDMs are being reworked and will handle the different types, as part of C2MS13-23.

Envelope, header, message... each of these has a version. What is this field for. Seems to overlap with the message's CONTENT-VERSION... I think it should just be deprecated... however, this is low low priority.

Table 8-118. Mnemonic Value Data Message Additional Information under Mnemonic, Sample used to have RED-HIGH, RED-LOW, YELLOW-HIGH, and YELLOW-LOW, which have been deprecated and replaced with MNEMONIC.n.SAMPLE.m.ALARM-STATE. However, while that ALARM-STATE can indidcate if a tlm point is out of limits, it doesn't say whether it was high or low given a normal range.

We should consider if we should add an optional field called something like SAMPLE-OUT-OF-LIMIT-CHARACTERISTIC that says whether it was high, low or n/a. THe latter has to be htere to cover cases where it's not a range but more like true/false state.

My own feeling is that this isn't necessary. If a TLM Point is out of limits then the component or operator that has to eveluate what to do can simply look at the value and determin characteristics. But capturing it here for discussion.

The GMSEC technical team has provided feedback that ____ (all, most, many) pub/sub products such artemis may not support upper lower case differentiation in the subjects.

Absolute real technical feedback is imperative to resolving this issue.

For all data-related messages (mostly notification messages, but could be some response messages), consider adding an array as a Participant Chain... what component or resource was involved in producing the data... probably would be String for the name, a Typed Varialble, plus a time-tag. Typed Variable would allow it to be a digital signature. This has some oerlap with both Participant in TDM and Originator in NDMs.

Archive Mnemonic Value Request Message has a lot of Dependent Fields, with no explanation of why dependent. After review, these are all D fields, but scant explanation of why, so maybe consider beefing that up. In this case, often the meaning of D is that the field is still optional, but only considered if some other criteria is in place. This could be done field-by-field, or in an explanation below that says, if you selected VIA-INCLUDE, the following fields are considered, and optionally used, but otherwise ignored.

NOTE: Consider doing this at the same time as C2MS13-107 since they will overlap.

In Telemetry Processed Frame Message NUM-OF-MNEMONICS is described in the table as a value of 1+. This may be right, but investigation is needed.

The diagram says zero to many.

Need to decide and update the wrong one. In this case it should be 1+.

Replay Telemetry Data Request Message - same concern for NUM-OF-FILES. should be 0+.

Product Request Message - same for NUM-OF-PROD-SUBTYPE-SUBCATEGORIES. should be 0+.

In Telemetry CCSDS Packet, DATA is required.

Transfer Frame Message has an optional DATA field, doesn't make sense for it to be optional, since the message needs to carry the transfer frame within it. Similarly, DATA is optional in TLM CCSDS CADU Frame and TLM TDM Frame. In all these listed messages, the message would not carry anything but info about the frame unless DATA were present, so should be required, in my mind.

Not concerned about backward compatibility, because it is already de facto required.

Note that TLM CCSDS Frame also has DATA as optional, but this message is deprecated, so leave it alone.

TLM Processed Frame MSG doesn't contain DATA. Should it? In other words, while it is supposed to be a hybrid with both the frame and MNE data, and it does contain information about the frame, it doesn't contain the frame itself.

Some issues have been found in 1.2 relating tot he diagram representation of the messages not matching the tabular definition of the messages. These are:

• Message Envelope...
  • PUBLISH-TIME and UNIQUE-ID are optional, but shows as required in diagram
  • NODE is String, rather than Subject Token String
• Configuration Status MSG Diagram
  • In ASSOC, GROUP/NODE/ROLE are Optional, but erroneously shown as required in the diagram
• Device MSG Diagram
  • Multiplicity of DEVICE is 1+, but shown in the diagram as zero to many
• Command Echo MSG
  • ECHOED-CMD-PACKET-COUNTER is Optional, but shown as Required in the diagram
• OMG Generic Service Response and OMG Generic Service Data Message both have wrong notation for the EXT-SPECIFICATION with a single equals sign.
  • “=OMG” but should be “==OMG”

MNE Value Reqponse Message - RESPONSE-STATUS description in the table is excessively long. Consider making this a note after the table.

In the Header additional info table, the description for COMPONENT could be improved. Using the description for Subcomponent 1/2 as a guideline, perhaps: “Name of the component that produced the message." Examples are fine, I suppose.

Currently both these are optional. However, it probably doesn't make sense to supply both. They aren't mutually exclusive, because neither has to be specified. Consider some text to describe this. Technically, both would be allowed, but unusual.

Somewhere in the definitions part of the doc, we should probably make a note about CONTENT-VERSION, that it only changes if the content of that message chagnes. For example, in 1.1, there were a few messages that retained CONTENT-VERSION of 2019.

When Boolean fields are listed in Message "Additional Information" tables, they sometimes use True/False of for the values and sometimes 0/1.

Should reduce to always use True/False.

Specific cases of the 0/1 usages:

Table 8-99. Telemetry Processed Frame Message Additional Information
Table 8-119. Mnemonic Value Response Message Additional Information
Table 8-124. Mnemonic Value Data Message Additional Information
Table 8-141. Archive Mnemonic Value Data Message Additional Information

At a future major revision (like 2.0), should reconsider all these. Many are not really boolean-friendly fields, like "QUALITY" or "LIMIT-ENABLE-DISABLE", leading to not being clear to what True or False would indicate. Because of that, when given the opportunity try to turn these into proper booleans, or make them enumerated values.

Should the CMD Request Message have any fields to indicate if it is a restricted or sensitive command requiring special handling? I note that we have the metadata now on CMD request and maybe that takes care of it. Just capturing for discussion.

I'm putting this issue forward simply for discussion. To me, it seems unnecessary, because the command-execution system that receives the request seems like a better arbiter of whether a command is restricted, and what to do with it... but just want discussion.

This is to consider if we should add the ability for MVAL REQ/RESP/MSG messages to support Ground Telemetry.

Perhaps Processed Telemetry could do this to, though since it is a hybrid between the unprocessed (raw) Telemetry Message and the Mnemonic Value Data Message, perhaps this doesn't make sense (is there ever a raw frame or sample for Ground TLM?).

Of note, all C2MS Messages have the following REQUIRED fields in the header:

• MISSION-ID
• CONSTELLATION-ID
• SAT-ID-PHYSICAL
• SAT-ID-LOGICAL

And in the Subject, all TLM messages have

MISSION, CONST, and SAT as required elements.

A current work-around is to use Mission, Constellation, and Satellite String values to represent something on the ground, such as an antenna, modem, gateway, etc. The question at hand is if we should make this a little more formal.

Options might be to rename the fields to something more generic than Mission, Constellation and Satellite. At issue, though, is how to capture this in a backward-compatible way.

For now, just capturing this for future discussion.

Notes on what we already say in the document:

6.2.3.2: If an element is defined as being required but is not applicable for that mission or to that specific message, "FILL" (no quotes) is placed in that element's position, meaning that it is not known or specified. For example, most but not all messages are satellite-related, so a “Satellite ID” is part of all message’s subjects. If a message is not satellite specific, "FILL" can be used in place of the "Satellite ID".

8.7 Real-time Telemetry Data Messages
Telemetry Messages are data packages that contain metrics from remote devices such as spacecraft.

In Reston, 2026, we felt it was best not to provide "ground" Telemetry for now, because we would have to 'fake-out' the system by using values other than Mission/Constellation/satellite designators in the header. Furthermore, it's unclear why we would supply ground telemetry, when GEMS performs that function already. Decision was to revisit in 2.0, when we might make the header for messages less-specifically for satellites, and more to do with Satellite Contacts.

This issue covers the reevaluation of the GUID type to consider specifying not only the format (RFC 4122), but also the algorithm for generating the guid.

In 6.4, there is discussion for REQ and RESP, that ME1 means certain things. But ME1 is a subject element, while the message (header) has COMPONENT and DESTINATION-COMPONENT that also carry the same meaning. So consider reworking this to be more like ME1 and DESTINATION-COMPONENT field" or something like that.

Always, but especially if not using a subject, COMPONENT and DESTINATION-COMPONENT are also in effect, so do we need to say that too?

Working with Eric, create a TLV Message that has a name-value concept to allow interoperability with external standards, for example to send a GDDI/GEMS/SNMP/SCARS message or receive one as defined with fields in that other spec.

Just for reference, see C2MS13-6 and its resolution.

In the Mnemonic Value Data Message, the REQUEST-ID is last, whereas it is first in the AMVAL corollary. AMVAL probably has it right. If given time, it would be a good idea to reorder this, obviously in both the diagram and the table, as these try to maintain same order for readibility.

Worth a look throughout, but a small number of fields have no descriptoin. Exmple CMD ECHO ECHOED-CMD-PACKET-COUNTER.

In Archive Mnemonic Value Request Message, the DELIVER-VIA-MSG/REFERENCE fields should be shown in the diagram to default to False and True respectively.

Archive Message Retrieval Request/Response ProdType and Subtype are constants, so I'm not sure why they are there. Seems like could be deprecated. They are weird, anyway, because they are optional constants???

Particularly in the response... what purpose does it serve to say what constant type and subtype was requested?

Guessing this is some kind of leftover from a weird corner case.

Also, Archive Mnemonic Value Request/Response Messages have optional constants for these two fields.

The size field in the request is a U32 in the response is a U16. Can probably make the latter U32 and still be compatible???

In the Header, many fields are Subject Token String, but if they are never used in a subject, they could just be String. In 1.0 most of these were type Header String, later changed to STS, which might be why... could be someone just declared any string in the Header to be Header String type? Evaluate and change where appropriate.

In the Subject Content line, we use [lowercase] to indicate a soft description, and [UPPERCASE] to indicate a field name. But compare this with Table 8 3. Mapping of Message Header Fields to the C2MS Subject. It could be that these are all field names??? If so, should probably capitalize all those (like [constellation]). See C2MS12-191.

Either way, near that table, maybe add descriptive text about how [lower] and [UPPER] are used in those tables, along with other formatting description as needed.

The Contact Reservation messages are not "Contact Schedule Messages" because in operational practice a contact schedule includes more data than simply time and antenna for an SV. Additionally, a "contact schedule" prorbably maintains some form of contact requirements, and may contain a command plan, set of automation tasks to perform, etc. So, we viewed reserving antenna time ans a PART of the schedule rather than the schedule itself.

It would be good to add a description about this to section 8.15.

And maybe look at each case where we use the phrase "scheduling messages". Like the title of 8.15, in particular. To me, it's OK that we say this because these are messages "related" to scheduling, but specific to reserving antenna time.

In the description for Req/Resp/Notify MEP, it says one response. However, it could actually be a series of responses, during or after which notification messages flow. Probably just need to cover this case to make sure its not overly proscribed.

Search for uses of this MEP and make sure their text aligns.

6.4.3.1 C2MS MSG Message Type, first paragraph says:

“Notification messages are sent to no specific consumer but are distributed to any component listening for that type of message.”

This is ok, but should find a way (and check throughout the doc) to say that they can be sent peer-to-peer (send message) pattern, if desired in the chosen architecture. In those cases, you do notify a specific component. Current language is very pub-sub oriented.

Figure 6-1 Message Field Multiplicity should be redone. It uses the Log Message, but has incomplete constraints, and some of the fields in Log Message are deprecated, so it's not a great example. Consider Event Message instead.

Additionally, I can't find a diagram in the model that was used to create this, so a specific diagram, including the note, should be created in the model as well for consistency when the given example message might change in the future.

In the next major revision (2.0), when backwards-compatibility is not an anchor, we need to update all Boolean fields in messages to be either required or dependent, and in the latter case to make clear what it is dependent upon.

No boolean field should be optional... They should all be present with either TRUE or FALSE values.

This is because it is ambiguous how a message receiver should interpret a non-present Boolean field. They must simply chose whether to treat it as TRUE or FALSE.

All C2MS Messages can be augmented via the CUSTOM-FIELD added in 1.2. However the C2MS Message Envelope does not have that capability.

This issue simply to evaluate if it should.

(My own feeling is 'no' because the envelope is not meant to convey any mission information, but is a generic way to handle the transport of the C2MS Message, but it should be discussed).

Typed Variable was added in 1.2. The field DATA-VALUE is represented in the model as just VALUE. The model needs to rename this to DATA-VALUE and the diagram for figure 6.3 needs to be updated.

In the model, Message Security (part of Message Envelop) has text under the model class->specification->documentation that is superfluous.

All such 'documentation' should only exist in notes on the diagram or as text in the spec document (until we move to a model-based spec in 2.x). For now, remove this, as it was used to capture information during development. When removing, perform an analysis to see if that text should be moved to a note on the diagram or placed in the spec document, instead. Otherwise, simply remove.

Message Security (part of Message Envelop)
"a sender-identity type (JWT/SAML) String. Note that this field could be a group.

SECURITY-CONTROL-INFO with 0 = no encryption/signing 1 = digital signature, 2 = mac, 3 = … and 7+ = Mission Defined."

In the model, a few package names don't line up exactly with the changed subsections as intended.

The following need to be changed in the model (and note that there is no change to the document itself, as it already has the desired names):

"Real-Time Telemetry Data Messages" to "Real-time Telemetry Data Messages"

"Real-Time Mnemonic Value Messages" to "Real-time Mnemonic Value Messages"

"Contact Reservation Messages" to "Satellite Contact Scheduling Messages"

"OMG Generic Service" to "OMG Generic Service Messages"

In the following cases, both the model AND the document titles need to change:

"Monitor Level Messages" to "Monitor-level Messages"

"Component To Component Transfer Messages" to "Component-to-Component Transfer Messages" (in the case of the document, drop (C2CX) from the section heading).

From Elisa during AB Review of C2MS 1.2:

“It's odd that there's only one external reference (href) to a UML primitive type in the whole model. There are several primitives masquerading as Classes in a Package called Type (line 696) which includes classes named String, Boolean etc. This is really isn’t right, and should be corrected to reference the standard UML PrimitiveTypes (which are not Classes). Some of the classes in the Type package are disguised datatypes e.g. U32. Others are odd such as "Dependent upon response" (line 729) (does not appear in the spec) and "Variable". See sect 6.3.5 of the spec which even starts with the statement that they are datatypes (not Classes). That includes the statement that Variable is deprecated but that's not indicated at all in the XMI. Typed Variable has a structure so should be a uml:Datatype not a PrimitiveType. The primitive types should be mapped to XSD types using the XMI tags”

C2MS Response at the time:

"I agree, but we have tried to maintain backwards compatibility except in cases where the prior definition is simply incorrect (and therefore unworkable). Our approach has been to live with the way C2MS 1.0 laid out data types and structures with the intent to revisit them in a 2.0 future release when backward compatibility doesn’t tie our hands. With that in mind, my recommendation is to leave this as it is in the spec and model as long as we are in the 1.x baseline. "