C2MS12 — Reconsider Oneshot in MVAL Request/Response

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 type of 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.