An XMPP compatibility pilot should treat reconnecting a live stream and retrieving missed history as two different jobs. XEP-0198 stream management lets a client and server account for handled stanzas and attempt to resume a stream after an interruption. The acknowledgement counter is evidence about what that stream says it handled; it is not a promise that every earlier message is available forever. XEP-0313 Message Archive Management is the separate archive query used to find messages outside that resumed stream.
Test the boundary, not a slogan
Start with two test accounts and three client types: a desktop client, a mobile client, and a web client if the organisation expects to use one. Record each client version, operating system, server address, login method, and the setting that enables or disables stream management or archives. The Meody compatibility review can scope that matrix; it should not label a client compatible before these observations exist.
Use a short timeline. Account A sends “one” to account B. On B’s phone, switch off the network after the message is displayed but before the app has a chance to finish its normal background work. Send “two” and “three” while it is offline. Restore the network, then note whether the mobile client resumes, receives a stream acknowledgement, and displays each message exactly once. Repeat after force-closing the app, where resumption may legitimately fail because the server session has expired.
Ask the archive a separate question
After each interruption, open B on the second device and request the conversation history. Compare the archive result with the sent-message timeline: which messages appear, in what order, and whether messages already displayed are duplicated. A clean resume can still leave a gap if an archive is disabled, permissions differ, or the client does not perform the expected archive query. Conversely, an archive may recover a message after resumption fails; that does not mean XEP-0198 succeeded.
- Mark the last outbound message the client reports as acknowledged.
- Mark the last inbound message visibly rendered before disconnecting.
- Record the server’s resume result or rejection, without treating a rejection as a defect by itself.
- Record the archive query result on a second device and any duplicates or ordering differences.
Decide what a failure means
A rejected resume needs a defined fallback: authenticate again, retrieve the relevant archive range, and explain to the user if history cannot be reconstructed. Duplicate delivery needs an application or client policy for identifying already-rendered messages. If the archive returns less than the timeline, check retention rules and server configuration before changing clients. Keep packets, timestamps, and redacted logs only as long as the pilot requires; message content may be sensitive.
Finish with a matrix row per client/server/version path and a plain outcome: resumed and matched; fresh login plus archive recovered; duplicate observed; or unresolved. The downloadable matrix is designed for that evidence. Before changing a production setting, agree the acceptable fallback time and who receives a failed-case report. A pilot result is useful only for the tested account, client version, server path, and date; an upgrade deserves a new row rather than an inherited pass. For a limited compatibility engagement, ask Meody about a scoped review and name the devices and server path to include.