Some design ideas for SM based on review of early draft implementation (https://github.com/noonien-d/wocky/compare/0.18_XEP-0198_XEP-0352) and my own (unpublished) early attempt.

SM needs to live in the porter - as this is the place where stanzas are being queued/dequeued/sent and handled(!). Handled is a keyword for SM h attribute:

Definition: Acknowledging a previously-received ack element indicates that the stanza(s) sent since then have been "handled" by the server. By "handled" we mean that the server has accepted responsibility for a stanza or stanzas (e.g., to process the stanza(s) directly, deliver the stanza(s) to a local entity such as another connected client on the same server, or route the stanza(s) to a remote entity at a different server); until a stanza has been affirmed as handled by the server, that stanza is the responsibility of the sender (e.g., to resend it or generate an error if it is never affirmed as handled by the server).

Therefore neither XML Reader nor XMPP Connection do not fit this definition for received stanzas.

Connector initiates SM (enable) but then hands it over to porter which starts with zero counters. When porter receives enabled response it starts actively participating in the SM (requesting/answering). Porter needs to know though if enable has been sent so it starts filling sent queue.

Porter will need to move sent stanzas(! not nonzas) from outgoing queue into (new) sent queue until it receives ack to head-drop the queue.

Connector will also need to understand resume vector (perhaps via reg_op). Resumption vector need to be handled by porter to avoid creating new one. In case of stream termination (not connection interruption) porter will just follow standard teardown vector, but for read/write errors it will discard connection and initiate resumption vector.