C2MS11 — Create an optional Message Envelope to hold Tracking Fields

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.