-
Key: C2MS11-8
-
Status: closed
-
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
-
Disposition: Deferred — C2MS 1.1b1
-
Disposition Summary:
This is a good idea, but deferring this to a later release due to time
I've run out of time to get this done in 1.1. It's important, but there is already so much work put into 1.1, we need to close that release and can do this one in 1.2.
-
Updated: Mon, 16 Sep 2024 14:18 GMT
C2MS11 — Acknowledge Final Status inconsistency
- Key: C2MS11-8
- OMG Task Force: Command and Control Message Specification (C2MS) 1.1 RTF