First, I agree there are still some difficulties with multihop and syncReply. This new element does not do anything to solve those difficulties. The only answer I can see is to do as Dale suggested and use a cascading Ack -- but that has difficulties too. Second, I still think there cannot be IM SOAP only nodes. This makes no sense at all since any SOAP IM MUST understand MessageHeader in order to route. This is the Store-and-Forward only IMs we have been discussing -- doesn't need to touch the Manifest. If it can look in MessageHeader to get the To then it can also look in MessageHeader/QualityOfServiceInfo to get syncReply. So I must ask again, why are we adding a new element? Third, when I made the assertion that syncReply is for MSHsignals, I did not mean to imply that it did not match SyncReplyMode -- it does follow. If SyncReplyMode is not *none* then syncReply MUST be *true*. This does not imply that syncReply cannot still be *true* even if SyncReplyMode is *none* -- this would mean MSHsignals only. However, when would the MSH syncReply ever be *false*? I must reiterate, we don't need syncReply at all. Doug, Chris? Regards, David Fischer Drummond Group.