David, my understanding of the relative ordering of retained messages is the same as yours. In fact my reading is that the server is free to send the SubAck, existing retained publications and new publications in any order. So I think the answers to your questions are: 1. The key question: Is the retained message flow to SUBSCRIBE-rs considered ?out of band? of live message flow? That is, can the server deliver the retained messages arbitrarily interleaved with live message flow, at its discretion? If not, what are the constraints? >>Yes, the retained message flow is considered out of band, but the retained messages >>must be distinguished by having the RETAIN bit set. A server might choose to deliver >>the retained messages before any subsequent publications, as an "added value" differentiator. >>The client will observe a retained message being inserted into the flow of publications >>at an arbitrary point. If the retained message exists at all, it could have been produced >>some time ago, so it would be out of sequence whatever order the server uses. 2. If the client connection is Clean, and the client SUBSCRIBE-s to a Topic Filter that matches one or more retained messages (i.e., this is a ?new? subscription), are there any constraints on the ordering of the retained message vs. the ?live? message flow? For example, is it required or is there an expectation that the retained messages be delivered first? >>As above, it's not required but this might be a good feature for a server to offer. >>If the retained messages are delivered first the client cannot determine that it has >>received all of them until it receives one with the retained flag not set. 3. If the client connection is not Clean, and the client had previously subscribed to the same Topic Filter, the stream of missed or in-flight/unacked messages, including messages that were sent as Retained, will be a part of the session state. We would like to verify that if the client re-SUBSCRIBE-s to the same Filter Topic, thus triggering retained message delivery, it is possible for the client to see the same ?application? message multiple times: with Retained NOT SET as per the normal flow, and with Retained SET for the retained portion; all messages will go through their own separate quality of service flows, with unique Packet Identifiers if the Quality of Service is non-zero. >>I would expect the RETAIN bit to be set in all cases - including the re-sends >>of a previously unacknowledged retained message. If you have a client that >>repeatedly runs through the pattern where it Connects, Subscribes and then Disconnects >>without acknowledging its QoS 1 or QoS 2 messages, then I agree that each time this >>happens the server will send another copy of the message - with a different >>packetID - to the backlog of inflight messages. This isn't that different from a >>subscribing client that accepts - but doesn't ACK - any stream of newly published messages. >>Eventually the server's inflight buffer will fill up unless the server adminstrator takes >>some action. 4. In an extreme edge case where the network connection is highly unreliable, and a client always resubscribes after connecting, is it possible for the same non-zero Quality of Service retained message to be in-flight many many multiple times with unique Packet Identifiers if the client can?t fully ACK them before the network connection drops? >>As above. Once the server has responded with a SUBACK or any retained message >>It has to send all of the retained messages to behave correctly. 5. A Retained message with an empty payload is supposed to be delivered ?normally? but serves to remove any stored Retained message. If the server has a retained message A for a Topic and it receives a SUBSCRIBE to that Topic while the server receives a retained message B with an empty payload, can the server send to the client message A with the Retained flag set, and message B with no payload (and the Retained flag clear)? What about in the opposite order? >>The server is free to determine whether it processes the SUBSCRIBE first or the PUBLISH of B first. You could be thinking that we might specify the order to be: 1) Last publication resulting from an existing subscription. 2) SubAck. 3) Any retained publications. 4) New publications. This would, as you say, tighten up the normative language, but remove freedom from an implementation to perform some parallel processing, particularly if it is clustered implementation.