Source: Kratos RT Logic, Inc. ( Justin Boss)
Based on review of latest specification, the problem detailed in
C2MS-5is 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.
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".
Reported: C2MS 1.0b1 — Mon, 26 Nov 2018 21:44 GMT
Updated: Sat, 18 Mar 2023 00:20 GMT
C2MS11 — Acknowledge Final Status inconsistency
- Key: C2MS11-8
- OMG Task Force: Command and Control Message Specification (C2MS) 1.1 RTF