-
Key: C2MS12-5
-
Status: open
-
Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
-
Summary:
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.
Possible solutions:
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: Wed, 11 Sep 2024 21:06 GMT
C2MS12 — Acknowledge Final Status inconsistency
- Key: C2MS12-5
- OMG Task Force: Command and Control Message Specification (C2MS) 1.2 RTF