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. -----Original Message----- From: Doug Bunting [mailto:
dougb62@yahoo.com] Sent: Monday, November 26, 2001 1:31 PM To:
ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: SyncReply Module David, I object to being misread in this fashion. I said nothing leading to any requirements for per-message SyncReply choices. Nor do I agree this parameter should be true for all HTTP connections. I suggested I'd turn on SyncReply if and only if I were behind a firewall and unable to receive incoming messages (one-time configuration of the MSH) or knew my trading partner could evaluate all MSH error cases within the HTTP timeout (per-relationship). Message size may not be the primary driver for slow processing at a recipient. (Besides, how would the sender know what processing time the receiver will need for a particular message size, payload split and overall complexity?) My default suggestion would be to leave SyncReply false. thanx, doug ----- Original Message ----- From: David Fischer To: Doug Bunting ;
ebxml-msg@lists.oasis-open.org Sent: Monday, 26 November 2001 08:04 Subject: RE: [ebxml-msg] Re: SyncReply Module <<comments in-line>> I am waiting on a ruling from the Chair about my objection, but I will make a couple of comments anyway. Regards, David Fischer Drummond Group -----Original Message----- From: Doug Bunting [mailto:
dougb62@yahoo.com] Sent: Tuesday, November 20, 2001 1:17 PM To:
ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: SyncReply Module David, This has gone on too long. I'll bite one last time but what exactly are we debating now the issue has been resolved? <<Resolved? Not really>> The use case described has been in the document for quite some time. I refer, for example, to lines 728-730 in section 2.2.10 of the 1.09 draft which explicitly describes the next MSH actor as allowing SOAP extensions to skip intermediate SOAP processors without full MSH capabilities. Otherwise, next would be sufficient. Though it isn't as explicit, the same could be said for the To Party MSH actor because it allows the default SOAP actor to be placed before or after the To Party actor on a multi-hop route. <<Doug, you make a good point. There were so many changes in v1.05 that I just did whatever Chris said and didn't think about it too much -- to get the restructured document out the door. You are correct that this is a new requirement and probably should not have been included. You are also right that next and the default are probably sufficient for our current needs.>> I'd turn off sync reply whenever I know the receiving end can't or won't reply synchronously. For example, signature validation and other security checks may be time-consuming. I'd rather wait for a single asynchronous reply (allow push) than retry (poll) for the transport confirmations. It becomes much more efficient to operate in this way once the chance of failure reaches measurable levels -- especially if the recipient does security checks prior to duplicate detection. This is exactly how the RosettaNet Integration Framework works today. In fact, I might turn on sync reply if and only if I were behind a firewall and unable to receive incoming messages. (We're only covering part of the requirements for such a configuration because we don't cover polling for business responses but it's a start.) <<Thank you, Thank you, Thank you! Final someone agrees with me. This is the Use Case I have been using all summer to justify per-message syncReply (Large Messages). Dale had me convinced to drop this use case since it is so rare it is not worth supporting! In the case where I am behind a firewall and unable to receive incoming, doesn't that mean that I MUST have syncReply set to true ? It seems like we are agreeing? I am suggesting that syncReply will never be false for synchronous transports (HTTP).>> thanx, doug ----- Original Message ----- From: David Fischer To: David Fischer ; Christopher Ferris Cc: Arvola Chan ;
ebxml-msg@lists.oasis-open.org Sent: Tuesday, 20 November 2001 10:48 Subject: RE: [ebxml-msg] Re: SyncReply Module It appears that the answer to my first question is, this is a new use case/new feature for a previously unmentioned/ unsupported set of functionality. OK, now my second question, why would syncReply ever be *false* for a synchronous transport (for all scenarios pertinent to v1.0). For all asynchronous transports, syncReply is ignored, so its value is irrelevant (see section 7.4.7). - David. -----Original Message----- From: David Fischer [mailto:
david@drummondgroup.com] Sent: Monday, November 19, 2001 1:57 PM To: Christopher Ferris Cc: Arvola Chan;
ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] Re: SyncReply Module OK Chris, since you are just talking and not answering the questions, I will KIS and ask one at a time. How can there be SOAP nodes in our path which do not understand MessageHeader? How would it route/forward? - David. BTW, I like the HTML ;-) -----Original Message----- From: Christopher Ferris [mailto:
chris.ferris@sun.com] Sent: Monday, November 19, 2001 12:17 PM To: David Fischer Cc: Arvola Chan;
ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: SyncReply Module David, Some comments below. Cheers, Chris David Fischer wrote:
NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com type= cite > 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. This doesn't address the problem, the issue isn't acknowledgments, it is all about message exchange patterns.
NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com type= cite > 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. There is nothing, nor should there be nothing to preclude OTHER SOAP headers, not just ebXML MessageHeader in a SOAP message that just happens to also contain ebXML defined extensions. There is no need for a non-ebXML MSH SOAP node to understand anything in the MessageHeader as long as it understands whatever headers are targetted to it by virtue of the actor of next or anything else for that matter. ebXML is not, nor should it be, a closed protocol, especially given that it is layered on top of SOAP.
NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com type= cite > 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. I don't buy this unless we are going to completely abandon multi-hop and intermediaries for v1.1. There needs to be some way of communicating to a node whether the connection over which a message was received is expecting a response so that it can be held open (as long as feasible and practical). Whether the node is a MSH or a plain old SOAP node serving some other purpose for which ebXML does not define itself is irrelevant. The reason that the actor of next is used is just to provide for the possibility, regardless of how remote that the node at which a message is received can be asked, in a manner that REQUIRES it to understand (mustUnderstand=1) at least the part about the fact that the connection over which the message was received will need to be kept open for a subsequent response. We agreed to this in the F2F by vote. I see no reason why it needs to be continuously debated.
NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com type= cite > Doug, Chris? Regards, David Fischer Drummond Group. -----Original Message----- From: Arvola Chan [ mailto:
arvola@tibco.com ] Sent: Monday, November 19, 2001 1:16 AM To: David Fischer;
ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: SyncReply Module David: Chris and Doug are the SOAP experts who have recommended the use of the SyncReply element. I would defer to them for an explanation on the necessity of this elemen (possibly for inclusion in the spec). Doug stated in his last message:
http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00223.html The previous synchronous mode would have sup ported MSH -> HTTP proxy -> MSH because HTTP proxies operate in a synchronous mode by default. The new flag allows MSH -> SOAP -> MSH in spite of the asynchronous mode the SOAP node might prefer. I suspect that is the main reason for the SyncReply element. I don't quite agree with your statement SyncReply in the MSH concerns sending back MSHsignals. Depending on the sync reply mode set in the CPA, SyncReply can mean returning the MSH signal synchronously, or returning the MSH signal along with business level message (signal and/or response) synchronously. It also occurs to me that SyncReply may be incompatible with an AckRequested element that is only targeted to the nextMSH. If the nextMSH returns the intermediate Ack synchronously, how can it possibly return the application level response also synchronously? If this observation is correct, perhaps the incompatibility should be identified in appropriate pl aces within the spec. Regards, -Arvola ----- Original Message ----- From: David Fischer <
david@drummondgroup.com> To: Arvola Chan <
arvola@tibco.com> ; <
ebxml-msg@lists.oasis-open.org> Sent: Sunday, November 18, 2001 3:04 PM Subject: RE: [ebxml-msg] Re: SyncReply Module 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. -----Original Message----- From: Arvola Chan [ mailto:
arvola@tibco.com ] Sent: Friday, November 16, 2001 8:35 PM To: David Fischer; Doug Bunting;
ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: SyncReply Module David: We used to have a syncReply attribute under both QualityOfServiceInfo and Via. We determined that the one under QualityOfServiceInfo is not needed because it should be obtained from the CPA. The Via element is essentially renamed as SyncReply because once we removed the TraceHeaderList, syncReply is the only attribute that is left in Via. Because the sender may not be aware of the presence of SOAP or MSH intermediaries, it should always include a syncReply element in the message header if the CPA specifies any syncReplyMode other than 'none'. Regards, -Arvola -----Original Message----- From: David Fischer <
david@drummondgroup.com> To: Arvola Chan <
arvola@tibco.com> ; Doug Bunting <
dougb62@yahoo.com> ;
ebxml-msg@lists.oasis-open.org <
ebxml-msg@lists.oasis-open.org> Date: Friday, November 16, 2001 6:18 PM Subject: RE: [ebxml-msg] Re: SyncReply Module No, SyncReply is NOT perMessage. I added a paragraph in 6.1 to cover this issue. My problem is that you never know if there is an intermediary so should you always include SyncReply if SyncReplyMode not equal *none*? If SyncReply is included, it will make it all the way to the end (one hop at a time), isn't there always a potential for mismatch? If it is always going to be pass all the way through, why put actor=next? If it is always included, then why bother with it in the CPA? What was the value of taking this out of QualityOfServiceInfo and making it an element? IMO, we just added 100+ bytes for nothing. Regards, David. -----Original Message----- From: Arvola Chan [ mailto:
arvola@tibco.com ] Sent: Friday, November 16, 2001 7:37 PM To: Doug Bunting;
ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: SyncReply Module Doug: Thanks for the clarification why SyncReply belongs in 'Core Functionality' rather than in 'Additional Features'. I have two related questions: 1. Is syncReply assumed one of those parameters that are perMessage? I don't think that the CPP/A team is aware of such an assumption. 2. If not, is the element mandatory when it is already specified in the CPA? When no intermediaries are involved, I would have expected that a syncReply specification in the CPA would imply that sync reply is to be used regardless of the presence or absence of a SyncReply element in the message header. What triggers the sender to include a SyncReply element in the first place? Thanks, -Arvola -----Original Message----- From: Doug Bunting <
dougb62@yahoo.com> To:
ebxml-msg@lists.oasis-open.org <
ebxml-msg@lists.oasis-open.org> Date: Friday, November 16, 2001 5:15 PM Subject: Re: [ebxml-msg] Re: SyncReply Module Arvola, My, you're a quick reader... You're understanding covers the flag's semantics as it appeared in the 1.08 document. Maintaining the existing keep channel open 'til a response is ready semantics, we slightly expanded the feature to include making sure an intermediate SOAP processor doesn't close the connection. In essence, we recognised the possibility of regular SOAP nodes linking full-blown MSH nodes. The previous synchronous mode would have supported MSH -> HTTP proxy -> MSH because HTTP proxies operate in a synchronous mode by default. The new flag allows MSH -> SOAP -> MSH in spite of the asynchronous mode the SOAP node might prefer. You're correct that the previous flag in QoS is no longer necessary. We discussed placement of this module's description in our document during the meeting and the consensus seemed to be putting this feature in the base section because it may apply even to a SOAP node with just a bit of ebXML smarts -- level 0 in ebXML conformance. thanx, doug ----- Original Message ----- From: Arvola Chan <
arvola@tibco.com> To: David Fischer <
david@drummondgroup.com> Cc: <
ebxml-msg@lists.oasis-open.org> Sent: Friday, 16 November 2001 16:47 Subject: [ebxml-msg] Re: SyncReply Module David: My understanding is that the SyncReply module is equivalent to the renaming of the former Via module, minus the TraceHeaderList. As such, shouldn't it stay in Part II (Additional Features) and under the Multi-hop chapter? The syncReply attribute under QualityOfServiceInfo goes away because the use of syncReply between the From and To parties is governed by a static (not per pessage) parameter in the CPA. In the single-hop case, it should be sufficient to indicate in the CPA that sync reply is to be used, without explicitly including a SyncReply element in the SOAP header. Regards, -Arvola -----Original Message----- From: David Fischer <
david@drummondgroup.com> To: ebXML Msg <
ebxml-msg@lists.oasis-open.org> Date: Friday, November 16, 2001 3:59 PM Subject: [ebxml-msg] v1.09 This includes all the edits I have received including those decided upon at the F2F this week. I do not yet have a Conformance Clause or the new sub-section dealing with Signature Security (Galvin). Regards, David Fischer Drummond Group ebXML-MS Editor. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>