Marty, How can SyncReply be used without a CPA? The only purpose for the SyncReply parameter is for the Sender to tell the Receiver whether or not to keep the connection open and wait for a reply or to close and send the reply later. If the SyncReply behavior was implicit with transport (True with HTTP and False with SMTP) then why have this parameter at all? I am not suggesting getting rid of this parameter because I believe there is good functionality here. SyncReply's sole purpose is requesting non-synchronous behavior on normally synchronous transports (you couldn't specify SyncReply=True on SMTP!). One of the basic premises of ebXML is that all the specs are orthogonal. We need to support both with or without a CPA. How can SyncReply be used without a CPA? Why is this hard? We didn't think it was before. SyncReplyMode, along with other parameters, was removed because the information was already in the CPA so why carry it? Then we realized that these parameters weren't necessarily in the CPA because we couldn't guarantee the CPA's existence. We have been putting parameters back, in MessageHeader or in Via. I am only asking that this too be put back so SyncReply can be used without a CPA. IMO, these parameters should never have been removed. I know of several in-work implementations and I don't know of any which are implementing CPPA (I'm sure someone out there must be). This does not mean they won't. CPPA is generally seen as a second level of implementation over Messaging. Messaging is the base. Once Messaging is in place, then we add CPPA, Registries, etc. We have to support non-CPA implementations -- at least for now. (One vendor actually suggested leaving CPAid blank for now since it is not needed -- except that the Schema specifies non-empty-string ;-). Regards, David Fischer Drummond Group.