Create a PowerPoint Set of Slides with Further Guidance for C2MS which will be placed in the C2MS Spec site and referenced from the Non-normative References section.

Attached is a powerpoint that contains the main topics to cover.

Below is the set of modifications we had planned for 1.2, but then backed off:
= = =
(At the end of the Intro to Specification)
In addition to this detailed specification, the Space Domain Task Force of the OMG has created supporting documents that may aid in the use of C2MS, which are listed in the "Non-Normative References" (see Section 3.2.1 OMG Space Domain Task Force Guidance Documents).

(NOTE to Reviewers/Editor: OMG SDTF is to create two PowerPoints to be used to give additional guidance of a more free-form nature such as why and how to go about using these specs, best practices, etc that don't belong directly in the specs but that would be useful to people trying to figure these out. The documents haven't been created yet, but will be by the time this goes to BETA.)

3.2 Non-Normative References
3.2.1 OMG Space Domain Task Force Guidance Documents

The following documents provide guidance for the usage of C2MS set forth by the OMG Space Domain Task Force.

• OMG C2MS Overview and Guidance (see https://www.omg.org/spec/C2MS/1.2/OMG_C2MS_Overview_and_Guidance.pptx [final link to be provided during document finalization])
• System Integrator and Use of Standards (see https://www.omg.org/space/ [final link to be provided during document finalization])

3.2.12 NASA GMSEC Documents

Note that NASA has developed a Platform Specific Model (PSM) referred to as GMSEC. The GMSEC API software, selected components, and documentation are distributed by NASA. Others are free to develop alternative PSMs.

The following GMSEC documents set forth the NASA GMSEC Architecture and the GMSEC Applications Programming Interface User’s Guide. Documents for specific GMSEC-compliant software components should be consulted on an individual basis.

• GMSEC Architecture Document, Release 3.0.0, February 2018
• GMSEC API 5.2 User’s Guide, November 2023

Eric O would like to add to the description for Telemetry CCSDS Transfer Frame - PARSE-ERRORS to account for other types of errors that could be conveyed here.

(Note: This is a consolidated and cleaned-up issue for CCSDS SM&C and MAL, which exist in several other C2MS issues.
This information has been collected from those sources and refined for clarity moving forward. Previous issues listed below.)

The CCSDS (Spacecraft Monitor & Control) SM&C defines a set of mission operations services. At the bottom of these
services is an abstract MAL message layer.

It is possible that an abstract MAL message could be mapped to a C2MS version, along with an appropriate addressing
scheme so that SM&C services could flow over a C2MS system, coexisting with C2MS message-based services. The following
is a copy of the current MAL message. It has a header consisting of several fields; after these data fields, this will
be (preliminarily) further discussed following the header section.

Within the header, there are TO and FROM fields. The CCSDS MAL Blue Book states that these fields are “open” in the MAL
abstract definition, although some form of reasonable quality-of-delivery service should also be provided for MAL message
delivery. There is also a service model—this is described in a separate Blue Book—which suggests that each service has an
associated URI.

Finally, there are several MAL mappings defined in various Blue Books—TCP, HTTP, and Space Packets, to name three. These
show how the MAL URI TO/FROM fields are mapped to specific protocol headers such as source/destination IP addresses, HTTP
URLs, and APIDs, to align with the above references. Given that the C2MS message can define services using C2MS subjects,
these can be used directly for the MAL TO/FROM fields or mapped from corresponding URI/URL values.

The REFERENCES section at the end of this description points to several CCSDS reports and multiple implementations in
different programming languages, using a variety of transport mechanisms.

Abstract MAL Header

URI MAL Header

(possible and vague mapping of MAL as C2MS minus fixing up types and the List)

C2MS MAL Header

For C2MS most of the fields can be mapped to C2MS types with exception List<NameType> which should follow the C2MS pattern:
Field Type Description
Supplement.n.Name Scalar Value Optional supplementary fields

An "InteractionType" is:

Interaction Types

(PRELIMINARY)

MAL MESSAGE BODY
After these header items the MAL body appears to consist of a TYPE/VALUE pair that is aligned with a specific message specification from the service.
In other words there is not a name associated with each field.

This means there are 2 options to further map a MAL message to C2MS:
1) bundle up any concrete MAL message's data body into a C2MS blob type and send it on, with the idea that the MAL service receiving it through C2MS
layer will then know what to do with it, because it has its own service definitions.
2) Let the mapper handle this because it's sophisticated and it will map each MAL field to a C2MS field using the appropriate service definition,
(somehow) giving each field in that service (a type/value pair) a name as well.

Alternative approaches?
One alternative approach to all the above would be to take any concrete MAL message, and in total make it a blob-style part of C2MS message in the
data body – and broadcast this message on the C2MS bus – and any particular node implementing SM&C services would receive that message - and
then decode it enough to determine if it's recipient or not.

This is a simpler approach overall but every node that receives such "broadcast" MAL messages will have to look at every
one of them to determine if any particular one is for them or not.

Other approaches considering essentially involved tunnelling a URL based MAL message through C2MS and then inserting/stuffing it into the http "stack" and so on and
this seem messy and possibly a security horror.

REFERENCES
– there's a large number of related ccsds publication found here under the "Mission Operations..." title
---- https://ccsds.org/publications/moims/
– https://en.wikipedia.org/wiki/Message_Abstraction_Layer
– https://github.com/CNES/ccsdsmo-maljava
– https://github.com/CNES/ccsdsmo-malc (note: uses zeromq but not clear if c2ms subject/topics would be mappable to it)
– https://github.com/nasa/CCSDS-MAL-Http-Binding-Xml-Encoding
– https://github.com/CNES/ccsdsmo-malgo
– https://github.com/tanagraspace/ccsdsmo-malc-sepp-apps (fork may have updates)

PREVIOUS or EXISTING ISSUES (Deferred)
The following issues (& related proposals) have previously been submitted on this topic. They have in general been deferred (to 1.3 now). However the intent of this issue is to subsume them all into this one issue which will carry forward.

They are as follows:
– C2MS12-79
– C2MS12-97
– C2MS12-74
– C2MS12-112

All Response Messages have RESPONSE-STATUS in the ME2 position of the subject, but in the Suject Naming Table, this is represented inconsistently between different messages.

Simple Service is the only one that has the proper "Subject Content", which should be "[RESPONSE-STATUS]". However, Simple Service also has incorrect values in that ME2 field.

This issue is for the Subject Naming Tables to use [RESPONSE-STATUS] in ME2 for each Response Message and to confirm valid values in the examples.

Additionally, many other Message Elements that represent a value of a Message Field also show possible values in the Subject Content, even though this is already described elsewhere. See Log Message as an specific example. All these should be reduced to [<FIELD-NAME>] instead of showing the incomplete list of possible values. Doing so will make this table more clear. This change needs to be done for each Subject Naming Table, so should be a directive to the Editor with an example or two, rather than enumerating each case.

Additionally, when these MEs represent a specific named field of the message, they should list it in the brackets. For example, instead of "[request id]" it should be "[REQUEST-ID]"

An asterisk (*) can take the place of exactly one whole element

According to Section "6.2.2 Format of C2MS Subject Names", particularly:

• "Table 6-2 Asterisk, Greater Than, and Plus Sign Wildcard Syntax Examples" and
• "Table 6-3. Subject Name Matching Examples"
  The trailing '>' character means one or more, while trailing '+' character means zero or more.

However, in the subject subscription examples provided of subjects in each message's description, many examples use '>' when they should use '+'.

One example is found Simple Service Messages.

Additionally, some have an improper space character between the last period and the '>' '*' or '+' character, which is incorrect. See Log Message as an example.

Need to review all these and then offer correction.

Some model diagrams are affected by more than one issue, and as such, all the changes need to be combined into one final SVG image in this issue to finalize the edits.

Note, for example, that some messages (see Event and Log Message from C2MS12-43) have a 2025 date, but should be made 2026, because 1.2 has taken a bit longer than planned and will be finalized in 2026. It would be good to go through every model change and determine for sure if it needs to be content-version of 2026.

Also, note that in C2MS12-53, all message diagrams are being updated, so really, this issue should capture all the final changes. Because of the same issue, all messages should have a CONTENT-VERSION of 2026 because of the addition of CUSTOM-FIELDs.

Include the Request Data Stream MEP, which is slightly improved from the original issue (just better spacing of lines)

In the description of the Replay TLM Data Response, the text uses the term "requestor" when it should be "responder" leading to confusion.

In the already-approved C2MS12-22, there was no description provided for OMG Generic Service Response Message or OMG Generic Service Data Message. Need to add these.

Table 8-75 Telemetry CCSDS CADU Frame Message Subject Naming is Incorrect. It has incorrect formatting and lists ME5 instead of ME3 as the third ME.

Table 8-162 Product Message is missing Subject Content titles and FILL in ME5 and ME6. (see Telemetry Processed Frame for how to represent this)

In our model diagrams, we tend to use "default" values in UML to signify constants, which isn't correct UML. To resolve this, evaluate each item with a default value to decide if it is supposed to be constant and if so, check the "Is Read Only" flag in the attribute for that class. If it is also static, check the "Is Static" flag, too. The former adds "

" to the display of the attribute, the latter underlines it. Note, though, that with C2MS12-118, CONTENT-VERSION and SPECIFICATION, two obvious cases, have been added to the Constraints section of classes, which enforces a specific value, so these are already OK.

Also consider marking all final classes with "Final Specification" to indicate that they can't be subclassed.

Telemetry CCSDS Transfer Frame Message still has Optional and Required elements as aggregators in the model.

MNE Value Request Message still has Required element as aggregator in the model.

In both cases, we need to make sure all the fields are migrated to the top level and still exist in the C2MS Spec, then remove the elements listed here.

Many t&c systems support some form of namespaces in their database definitions. For example a "parameter" might be associated with a certain namespace ("/myagency/mymission/mysystem/mysubsystem/batv1") or a command as well. XTCE supports a kind of namespace through the spacesystem tree. GSFC's ITOS supports namespaces in the database. (the other one, ASIST does not). And so forth.

The SM&C defines a set of mission operations services. At the bottom of this we believe there's an SM&C MAL message.

We believe that if we define a C2MS MAL message and appropriate delivery (addressing) – that any C2MS service could flow over a C2MS implementation.

SM&C (Spacecraft Monitor & Control) is a CCSDS working area that defines a set of ground system services, it is mainly Parameter (Mnemonic) value based (low level info is largely gone except they've added a packet construct recently). At the bottom of SM&C is the MAL message. The MAL message is technically abstract and one is to map it to your transport technology of choice – but perhaps there's no reason to literally implement a MAL message on the GMSEC bus. Determining details like "how will this really work" and so on would be part of this effort.
Once completed, we then say to SM&C folks that we could support an SM&C service. There's an additional facet related about tying into XTCE. The MAL is explained further here – https://en.wikipedia.org/wiki/Message_Abstraction_Layer ... Note that in essence the idea which may need refinement is to make a mapping of the MAL into a concrete C2MS message. Implementation an addressing scheme in the pub/sub environ is another aspect. at least some implementations by esa use tcp/ip and it may be that some hard address approach would work well enough for pub/sub (broadcast not being needed)

In the already-approved C2MS12-119 (and added to in C2MS12-177), we applied FINAL-MESSAGE to response messages to replace RESPONSE-STATUS "6=Final Message".

However, there is also a FINAL-MESSAGE in a number of data messages used to indicate the end of a sequence.

To avoid confusion, we should change the new FINAL-MESSAGE in response messages only to FINAL-RESPONSE.

Section 8.12 Product Messages is the only major section of that Chapter without an Intro. The intro should discuss the purpose and use of all product messages. See any other major section of chapter 8 for examples.

Additionally, none of the Product Messages contain a Message Summary Table (see Table 8-146 Command Echo Message Summary).

All the other messages except Navigation Data Messages have summary tables. These NDMs are represented somewhat differently in C2MS, so not too worrisome that they don't, but Product Message are clear outliers with the other message types.

These tables typically are followed with examples, also missing for Product Messages.

None of the Product Messages contain a Message Summary Table (see Table 8-146 Command Echo Message Summary).

All the other messages except Navigation Data Messages have summary tables. These NDMs are represented somewhat differently in C2MS, so not too worrisome that they don't, but Product Message are clear outliers with the other message types.

These tables typically are followed with examples, also missing for Product Messages.

We could add a message called Service Lookup Request Message that asks "who is out there that can service this request?" Then the requestor will receive 0-many responses.

The idea here is to help with the issue that all request messages today want a DESTINATION-COMPONENT, but we have no facility for the requestor to find one native to C2MS.

Request would have all the standard subject elements, up to ME1, which instead of the DESTINATION-COMPONENT would be REQ-SUB-TYPE, so if I'm asking who serves MVALs for a given satellite, I'd have a topic of "Domain1.Domain2.Mission.Const.Sat.REQ.SVC-LOOKUP.MVAL" which means, who handles the specific satellite for the MVAL subtype (obviously, this would only be needed for request service providers, so the REQ is not needed as part of the query.

The responses would (all) contain the name of the servicing component, that could then be used in an MVAL REQ for DESTINATION-COMPONENT.

After the resolution to C2MS12-192, this may not be needed. However, capturing it for future consideration.

Table 8-15 Archive Message Retrieval Request Summary has the first column centered. It's the only one of this type, all others of this type use left-justified, so that needs to be corrected.

Additionally all these tables throughout the document use "Senders Intended Usage" and "Receivers Intended Usage". These should be "Sender's" and "Receiver's" respectively. Or maybe Senders' or maybe we just say "Intended Usage for Senders" They all have to change anyway, so this might be the best form.

Product Message, by its description, can be produced either 1) as the result of a Product Request Message or 2) unsolicited. The REQUEST-ID is used to match a Product Message to correlate the PM with the originating request, which would be case 1, above. However, in case 2, there would be no original request.

REQUEST-ID should therefore be optional.

The Product Message has a lot of aspects that are tied to it being a "response" to a REQ rather than simply a message with data (that might have been produced as a result of a REQ, but that shouldn't be tied to a REQ or RESP).

C2MS12-119 (already-approved) has deprecated FINAL-MESSAGE and RESPONSE-STATUS to try to get away from this, but the message is in need of more review/work in this regard. For example, it also contains a RETURN-VALUE which is a field related to the already-deprecated RESPONSE-STATUS. That would should probably be deprecated, too. Additionally, it has a TIME-COMPLETED which is a Response Message field, though in this case, it might make sense to keep it as it indicates when the product was created... in other words, it was put here along with the other Response fields, but has a different meaning here (ugh).

But other fields could stand review. The goal should be to make this a data message without reference to a REQ. Yet some of the fields seem to be in it exactly for this reason (see PROD-MSG-TO-SEND, for example).

A complete review of all the field should be done and deprecate those that should better be handled in the already-existing Product Response Message.

Special note on REQUEST-ID: as with other data messages in a REQ-RESP-NOTIFY Triade, Product Message, by its description, can be produced either 1) as the result of a Product Request Message or 2) unsolicited. The REQUEST-ID is used to match a Product Message to correlate the PM with the originating request, which would be case in 1, above. However, in case 2, there would be no original request.

REQUEST-ID should therefore be optional.

Allow ME1 (DESTINATION-COMPONENT) to be optional in all request message subjects. Note that the Header field DESTINATION-COMPONENT is already optional in the message itself. This would be the same we do on the OMG Generic Service Request in C2MS12-22, and we don't need SERVICE-GROUP/NAME/OPERATION-NAME, because the rest of the C2MS Messages are typed and already carry what is being requested.

This is backward compatible, because it's moving ME1 from Required to Optional (less stringent).

Note, too, that there was already a sort of hint at this in section 6.2.3.5 Miscellaneous Elements of the C2MS Subject Name which in its final paragraph talks about possibly using ME1 not for DESTINATION-COMPONENT, but for "group names" as a way to indirectly reach a component that is part of a single grouping of services. That's a bit of a kludge, but just allowing it to be not-specified works great. As it turns out, "group name" isn't needed because the request message is already strongly typed (I need MVALS for domain1, domain2, mission, constellation, satellite). That's very specific already, and leaving ME1 blank allows requestors to put out this message with no known component name, but to get back a response of exactly what I asked for.

Since there can be only one response, not sure ack makes sense. The idea is to start a stream of MVALs. Possible return values could be constrained to success, failed, invalid.

For Request Messages, ME1 is always the DESTINATION-NODE, currently.

Add another ME value for SERVICE-NAME. Make it mutually-exclusive. You either specify DESTINATION-COMPONENT or SERVICE-NAME. If the former, it's like it is today. If the latter, it is a REQUEST that doesn't know which component will process it.

We have to make ME1 optional for these request messages..

Strengthen the discussion of "FILL" in 6.2.2. State that is is a reserved word in subjects and that not only can it be sent as FILL, but a subscriber can also subscribe to FILL to catch cases where the DESTINATION-COMPONENT is not specified.

Add a subsection that talks about requests and their use of SERVICE-NAME. These services should subscribe to FILL for D/C so that they respond to any request with the SERVICE-NAME.

Somewhere Describe sense of component registry and not allowing more than one component to subscribe. These would be implemented in the domain according to domain requirements. In other words, Explain the peril about multiple responders and guidelines of how to approach it. Maybe they create a registry/lookup. Could use C2MS-EXT messages. Maybe we adopt this at a future time.

Similar to C2MS12-118, it would be nice to create a model hierarchy for the TDM messages. The are almost all nearly identical, so inheritance would be nice. Of course, this can't break the CONTENT in the tables, but can greatly improve the diagrams.

This might be a buy-back type of message. Need to see what there is and if we could use it. This may already be accomplished via Tracking Data Message. Need to identify the need and see if these satisfy it already.

Documentation and model figures of messages do not have a consistent generalization of message components. For example, all Request messages happen to have a REQUEST-ID, but this field is only defined in each request message individually, rather than discussed or shown as present for all request messages.

This should be improved for clarity.

On Request Messages, allow SERVICE-GROUP, SERVICE-NAME and/or OPERATION-NAME to be used to find a service rather than DESTINATION-COMPONENT.

One case would also use a DESTINATION-COMPONENT, implying that the message conveys to that directly-named component the S/G-S/N-O/N.

C2MS has constructs and language that make it seem like a pub/sub specification, though that is merely one possible architecture. C2MS message define a format for messages that could be used in a service-based architecture.

To aid with this, we should not use the term 'publish', and we should be careful with 'subscribe'.

This is in order to get away from the assumption of a pub/sub architecture. This will include renaming the MEPS that have "Publish".

Note that some already-approved issues in this release might have used "Publish". Need to find and correct these.

We should further state that the Subject is optional used to aid message delivery, most useful in a pub/sub setup, but the subject is derived from, rather than adding to the message itself.

In the document, use terms like 'send' instead of 'publish'. Make the patterns refer to Notify rather than publish.

See 6.2.2 Format of C2MS Subject Names in the 1.1 document. “An asterisk (*) can take the place of exactly one whole element but not a substring of an element.”

We want to allow asterisk to be used in a part of an element string, like:

".FO*-B*R-*AZ." matching to "FOO-BAR-BAZ"

There doesn't seem to be any reason that this couldn't work... we simply don't currently allow it. because it is not currently allowed and we would be now allowing it, it is backward compatible.

Also allow blank or empty subject elements and document the the use of FILL as only satisfying otherwise required elements. Make clear that you can't use blank for elements that are required. matching an empty would look like "foo..baz"... which would not match "foo.bar.baz".

In the OMG Leeds Meeting, we talked about idenifying a special character, instead of the special word FILL. Possible suggestions were = % ^ which would look like any of the following:

FOO.=.BAZ
FOO.%.BAZ
FOO.^.BAZ

But as we discussed using a special character in a subject name could cause problems and if so, the implementing component might have to substitute it with some text... I don't know... something like FILL.

So, for now, we are setting this aside, living with FILL and we can revisit at a time in the future.

This is in order to get away from the assumption of a pub/sub architecture. This will include renaming the MEPS that have "Publish".

Note that some already-approved issues in this release might have used "Publish". Need to find and correct these.

Other possible replacement terms include disseminate, Notify/Notification.

It would have to be optional, but could be useful. I'm thinking a String whose value is determined by the domain where it operates, as these could be different depending on the country and could include (or not) releasability tags.

From C2MS12.53 (already approved), the Typed Variable has a DATA-VALUE of type Binary. Could we make this String instead?

From an implementation standpoint, C2MS (and C2MS-EXT) Messages should be registerable at some kind of "C2MSMessageDescriptionManagerService" which serves them up, possibly pushing them out? To all active nodes on a gmsec bus ...

Perhaps a Register Service message that includes what 'services' and message types are provided, a Service Registered message published to all, a Lookup Service Request message that asks 'who can do what I need?' and a Service Lookup Response message.

C2MS doesn't need to define how that registry is maintained or made resilient or how services stay in the list (heartbeat?) at all. That is up to the implmentor, if any.

C2MS12-53 calls for a way to make C2MS-defined messages extensible. This issue is to allow new TYPES of messages to be defined, within the construct of C2MS. This is to avoid having new messages defined that are not really C2MS Messages.

This could also alleviate C2MS12-22.

If we do this, we should consider allowing the user to specify a MESSAGE-SUBTYPE that is custom (though the MESSAGE-TYPE would still be just MSG/REQ/RESP). A couple of ways this could be done would be to say it must always start with "CUSTOM-", such as "CUSTOM-MISSIONX-CALCULATE-ORBIT". Note that if we do this, we need to change the Description in Table 8-2 for MESSAGE-SUBTYPE.

Alternatively, we could use "CUSTOM" as the MESSAGE-SUBTYPE, and use ME1 to designate the "Custom Message Subtype". In many ways, this is cleaner, but doesn't take advantage of SUBTYP being a part of the message subject directly and uses up one of the ME slots.

Either way, we would describe that they should use naming that avoids conflicts as we said in the resolution for C2MS12-53.

We should consider some kind of registry, perhaps... maybe maintained at the DOMAIN1 level.

In C2MS 2.0, we could consider adding a SubSpecification to go along with the Specication (C2MS), but that wouldn't be possible in 1.x.

If we do anyting in 1.x, we should add a clear descriptoin of how it works, perhaps near or in 6.2.3.4 Message Elements of the C2MS Subject Name.

Current document references NASA Goddard docs in the front matter. These should be brought to current versions:

3.2.1 NASA GMSEC Documents
The following GMSEC documents set forth the NASA GMSEC Architecture and the GMSEC Applications Programming Interface User’s Guide. Documents for specific GMSEC-compliant software components should be consulted on an individual basis.
• GMSEC Architecture Document, Release 2.8.1, February 2014
• GMSEC API 4.3 User’s Guide, May 2017

In this section, anytime we have a table or subsection or diagram name it should always be C2MS Message Envelope, instead of simply Message Envelope. The type is the former.

In C2MS12-115, already approved, there was an error in the text of one cell in Table 8-155 Product Request Message Add'l Info which needs to be fixed. Specifically, under URI, the Description says "Location where the requesting component is asking for the product file(s) to be stored. Could be a web address, directory, or folder specification . Required if DELIVER-VIA-INCLUDE is True. Not used otherwise." but should be DELIVER-VIA-REFERENCE.

Mne Value Data Message AND Archive Mne Value Data Message have missing type for ALARM-STATE in diagram. Need an updated diagram for both of these.

The spec does not mention anything about text encoding. Although the PIM doesn't have to specify it, and it should be designated by PSMs, it would make sense to 'recommend' UTF-8 as the standard to be used by implementations.

Some messages have a RESPONSE-STATUS that has a value of 6=Final Message. However, "Final Message" is not a response status, especially when compared to the other five possible values, but rather a qualifier about an individual response message. Further, there is no guarantee that a Final Message will be sent. For example, if a response message is marked with "Acknowledge", should there then be a separate "Final Message"? If a response message is marked with "Working / Keep Alive", should there then be a separate "Final Message"? In these cases, it is actually ambiguous. Table 6-11 Sequence of Response Status seems to indicate that a Final Message may follow an Acknowledge or Working/Keep Alive, but no others. Yet it seems possible to see an ACK followed by Working / Keep Alive, Followed by either Successful Completion or Failed Completion, and the concept of a Final Message is left hanging in those cases. It's just a bit strange.

A better way would be to allow any response message that supports sequences to indicate in a Boolean that it is the last message that will be received in a response, allowing both sequencing and single messages. In fact, many messages (like product message) that can be sent as part of a sequence do have a FINAL-MESSAGE Boolean field.

This RESPONSE-STATUS is described in section 6.4.2.2 C2MS RESP Message Type Details and is used in the following messages:

• Directive Response Message
• Replay Telemetry Data Response Message
• Archive Mnemonic Value Response Message
• Command Response Message
• Product Response Message
• Product Message (it is wholly unneeded here and likely caused by copy-paste from the wrong source... It should be deprecated)
• Simple Service Response Message

In all the response messages above, deprecate the use of 6=Final Message, add an optional Boolean (default to false) called FINAL-RESPONSE-MESSAGE. This allows FINAL-RESPONSE-MESSAGE to be set for all true statuses. Ensure that there is a FINAL-MESSAGE Boolean in all things that could be sent, like Product Message (which already has this Boolean).

Show an improved MEP (via C2MS12-5) that includes product messages (or the like) flowing within a response set.

Four of the "revised" SVGs in the resolution for C2MS12-8 we from an earlier iteration and still used the term "CAL-VALUE" instead of just "VALUE". Correct these.

In C2MS 1.0, XSDs were provided by NASA Goddard and published as 'normative' along with the spec. However, these were somewhat incomplete and not maintained by OMG, so these were removed as part of C2MS in 1.1.

The issue is that we do need to supply some PSMs to encourage C2MS usage in the space community. To address GMSEC, it makes sense to supply an XML PSM, but it also seems good to have a REST/JSON PSM to make it more modern and usable in modern architectures. Also consider PSM for Protobuf.

The intent should be to stop using NASA Goddard as the point of contact for all things C2MS. In fact, OMG should supply these PSMs to Goddard as input, rather than Goddard supplying XSDs to OMG as happened in 1.0.

Additionally, a REST/JSON and/or Protobuf PSM should focus on non-pub-sub usage... something that can exist and operate in a services-based architecture. In this case, it could be that the message subjects are ignored as these are used entirely for pub-sub subscriptions/delivery. If that turns out to be the case, we might make clear in the PIM that subjects are optional.

Related to the above, we COULD make subjects part of a PSM rather than PIM???

PSMs can be done as new chapters within the spec, perhaps in a C2MS 1.3 release.

Where there is a

• MNEMONIC.n.SAMPLE.m.TIME-STAMP field,
• MNEMONIC.n.SAMPLE.m.RAW-VALUE field,
• MNEMONIC.n.SAMPLE.m.EU-VALUE field,
• MNEMONIC.n.SAMPLE.m.TEXT-VALUE field, or
• MNEMONIC.n.SAMPLE.m.LIMIT-ENABLE-DISABLE field

There is frequently incorrect description text that either refers to the 'nth' data sample (should be 'mth') or 'first' data sample (probably should be 'mth'. These need to be individually evaluated and corrected. Be sure when chaning 'first' to 'mth' as I'm not sure the history of saying 'first'.

Search the doc for 'nth' data sample or first data sample. Can search for a few 'mth' data sample for the correct usage.

Table 8-62 Resource Message Additional Information is blank for NUM-OF-DISKS Type and Presence, should be U16 and R.

The Simple Service Req and Resp have an association with C2MS Message. Should be generalization. This is in the model and model diagram in the spec document.

Need to look through all others and make sure they are OK.

In 1.2, we are adding a set of name-value pairs for Command Metadata Items to the new Command Creation Request Message. This is being done in the resolution for C2MS12-16.

The question here is we should add this construct to the Command Request Message as well.

Among the "Navigation Data Messages", the following messages all have supported FORMATs of KVN, XML, RAW and BIN:

• Attitude Parameter Message
• Attitude Ephemeris Message
• Orbit Parameter Message
• Tracking Data Message

However the following only support FORMATs of KVN and XML:

• Orbital Mean-Elements Message
• Orbit Ephemeris Message

I don't know if this was what was intended or an oversight not to include RAW and BIN in these last two (or if the other Orbit Parameter Message perhaps shouldn't have them).

I'm entering this issue to capture this question as it could stand investigation

We need to make a general statement in C2MS that all times are considered to be UTC. Additionally, every "Additional Info" table that has a Time type should put UTC in the Description column.

A minority (nine out of 60+) of "Properties of Miscellaneous" tables have lines for Miscellaneous Elements only to state that they are "not used". This is superfluous and inconsistent with most other tables of this type. The "not used" aspect is knowable by the ME not being listed either in this table or its preceding "Subject Naming" table.

This does not apply to the following tables, since they have some not used MEs in between others that are used, so they do need to be specified:

• Table 8-86. Properties of the Miscellaneous Elements for the Telemetry TDM Frame Message
• Table 8-91. Properties of the Miscellaneous Elements for the Telemetry Processed Frame Message

Additionally, "Table 8-182. Properties of the Miscellaneous Elements for the Navigation Data Message" lists ME6 but without any other information, including "not used". Upon review, though, it is not used, so the line should simply be removed to avoid confusion.

In the spec PDF, there is a lot of inconsistency about how XX Message Additional Information tables appear in the document.

Some have (mostly) heavy cell borders - ex: Table 8-36. Directive Response Message Additional Information

Some have normal cell borders - ex: Table 8-140. Command Request Message Additional Information

Some have both in the same table - ex: Table 8-31. Directive Request Message Additional Information

Having heavy cell borders leads to a propensity to add cells with inconsistent cell borders, unless care is taken by the editor. Because of this, I recommend using normal cell borders on all these tables. Normal borders are used in many of them and they look fine.

Similarly all the XX Message Header Field Values tables should be updated in the same way.

Additionally, there are other similar tables that follow this basic construct and should also be updated:

• Table 6-9. Ordinal Date and Time Field Type Definition
• Table 6-10. Response Status Substructure
• Table 8-3. Mapping of Message Header Fields to the C2MS Subject Name
• Table 8-9. Pass-Related Occurrence Types
• Table 8-10. Telemetry Limit Violation Occurrence Types
• Table 8-11. Command Verification Occurrence Types
• Table 8-12. Miscellaneous Occurrence Types
• Table 8-13. Log Message to Echo a Directive Request Message
• Table 8-14. Product Message to Echo a Directive Request Message
• Table 8-20. Examples of Start and Stop Times
• Table 8-26. Meaning of Response Status and Return Value with Recommended Actions
• Table 8-37. Group Hierarchical Associations
• Table 8-160. Meaning of RESPONSE-STATUS and RETURN-VALUE with Recommended Actions
• Table A-1. Software Class and Subclass Categories

Finally, - Table 8-161. Example Scenarios Using the Set of Product Messages should keep the format of the cells generally, but needs to be cleaned up.

As a note, there are some tables where the structure of the table is easier to distinguish with some heavy borders and these should remain. These are related to the XX Message Subject Naming Tables.

Some messages have an inconsistent layout or section naming for their "Message Subjects" section. These need to be brought into a standard from. Messages that have this issue:

• Section 8.3.1.1 Log Message Subject Names does not start at the right spot. It should begin before Table 8-5. Log Message Subject Naming. Additionally it should be "8.3.1.1 Log Message Subjects" (this is being fixed in the resolution of C2MS12-43)
• Directive Response and Requests Messages to do not have 'Message' in the section heading. (Instead of "Directive Response Subjects" it should be "Directive Response Message Subjects" to be consistent with others.

Late in C2MS 1.1, we aligned SDTF error levels across the specs. 1.1 initially used 'Severe' for the highest level of concern. Later, we changed this to 'Critical' as this was better alignment with XTCE. Although the document text was all changed, we had three model diagrams that referred to 'Severe' in notes: Log Message, Heartbeat Message and Device Message. The notes in these diagrams all need to be fixed to use 'Critical' instead of 'Severe'.

Note that Log Message is already being fixed as part of the proposed resolution for C2MS12-43. Therefore, this issue only addresses Heartbeat and Device Messages.