RE: FW: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo

Thanks Chris, idempotence goes after the IF, my mistake.  You said:
We don't say whether or not the MSH is actually responsible for
the packaging of the messages, we only say how they need to be
packaged so as to ensure interoperability.  Not true.  Look at figure 6-1 and accompanying text.
Look at B.3.6.  The packaging is applied by the MSH.  Signature must be applied after packaging so it also must be in the MSH.  Encryption is always applied after signature so it too must be applied by the MSH.  There may be a set of callable modules (helper apps) which comprise the MSH -- no problem.  This whole set would then be called the MSH.  There has been some talk towards defining a standard API to the MSH.  If we do this then we must be very careful to define what functions are in the MSH. Chris, if you want to do something different, that's fine as long as the message structure is compatible with the specifications.  However, when we get around to defining an API, your way won't work any more.  On Routing, there are two kinds.  First, end-to-end (single-hop) which is really just transport and is definitely within the bounds of MSH.  Second, IM Routing which is actually only a modification of the Via/TraceHeaderList and then Transport.  We do not specify how this is done and frankly, I don't think it works now.  If the IM Routing is an application then I must seriously question whether this is an IM or it is an end.  Functions decrypt/verify signature/encryption are within the bounds of the MSH (note MSH errors to these).  Since it is unlikely that a true store/forward IM could do these functions, it seems essential that IM routing be a part of the MSH and not an application function.  (MSH helper app should be fine).  Regards,  David Fischer Drummond Group.