Presumably the first step would then be to remove the following statement (lines 1783 & 1784) from the successor to the 2.0 specification. Although one wonders as to the original reasoning behind explicitly including this statement? "A Message Service SHOULD NOT use the Message Status Request Service to implement Reliable Messaging." Dave Elliot XML Global Technologies On Wed, 2002-10-16 at 13:46, Jacques Durand wrote: > > 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 > >