If SyncReply is always included, then why is it needed in the CPA? If it always goes all the way through, why is there Actor=Next? What is the advantage to having this as a top level element instead of in QualityOfServiceInfo? We are adding a new top-level element and gaining nothing. This is definitely not backward compatible, not a fix and not a clarification. If all we are doing is renaming Via, then we should leave Via alone since that would be backward compatible and this change gains nothing. If this is always present then it should be combined with MessageHeader since it adds no functionality to have it separate and adds 100+ characters to every single message. As we discussed, the simple solution is ALWAYS assume syncReply=true for HTTP then we don't need this at all. Why would we ever need syncReply=false? I can only think of one use case (very large files), which we have decided to ignore. In the case where there is an async hop/IM in the middle, the response/signals will be sent back async anyway so the IM can just close the connection -- the IM already knows what to do. If you are concerned with the BPSS requirements, then you are talking about another layer (layering violation). SyncReply in the MSH concerns sending back MSHsignals. If BPSS needs for the MSH to wait and send back a combo message, then only the end/ToParty needs that info, not the IMs. IMs can ALWAYS assume syncReply=true (there is no syncReply flag for SMTP and if it appears it is ignored -- no error). This is a bad/unnecessary idea that needs to go away. Regards, David.