Title: RE: [ebxml-msg] reliable messaging A more detailed definition of Reliability might answer this, so that expectations remain reasonable... The spec may have to distinguish two aspects, somewhat orthogonal: - the quality of the delivery, e.g "at-least-once" and "at-most-once", which we know cannot be always enforced, for the same reasons Chris mentioned. The number of retries states the limits of the effort. Probably the scope of the duplicate check should also be specified somehow - e.g. in CPA . (e.g. while duplicate elimination may not be guaranteed over a long time, it may be critical for a business to know that an MSH guarantees the elimination of duplicates over a 1 week period.) - the quality of the sender-receiver synchronization, where several [if not all] out-of-sync scenarios can be addressed. The message status service gives primarily a way to resynchronize at application level. This service could be more explicitly integrated in a reliability policy, at MSH level, where status values such as "received", "processed" make more sense. (For example, a refined policy could be that an MSH not receiving any Ack after all retries timeout, will send a status request... and notify a delivery failure to the app only if the status response is "NotRecognized", and will not if status is "Received" or "Processed". ) Regards, Jacques