Of course you object. We already decided not to set syncReply based upon message size -- so why bring it up. My point is there is never a reason to set syncReply to *false* for synchronous transports so why have a flag /element at all. Consider the options: If SyncReplyMode equals: 1) responseOnly -- then syncReply MUST be set to *true* and the MSH must wait for the business reply. 2) signalsOnly -- then syncReply MUST be set to *true* and the MSH must wait for the business signals. 3) signalsAndResponse -- then syncReply MUST be set to *true* and the MSH must wait for both the signals and response (presumably they would be packaged together by the application). 4) none -- then syncReply MAY be either *true* or *false* 4a) syncReply is *true* -- MSH signals would be sent with the HTTP 200 OK. 4b) syncReply is *false* -- MSH signals would be sent separately with a different connection. ONLY in the case of 4b would syncReply be *false* (1 case of 5, so why isn't the default *true* as in 4 out of 5 cases?). IMO, there is really no need for the 4b case since MSH signals SHOULD always be sent with the 200 OK (why would you ever NOT send them -- why wait?). The only case I can think of where 4b is usable is for large files where signature validation might take some time but we have decided NOT to consider this case. Doug, so far you have only expressed your opinion about what syncReply should be but you haven't really given any reason why syncReply should ever be *false*. I suspect your reason is because syncReply is default *false* for RNet. That's not a reason. Regards, David Fischer Drummond Group.