[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Contribution taking away one-way restriction on Callbackand Poll
Doug Bunting wrote: > Tom, > > On 15-Aug-04 09:39, Tom Rutt wrote: > >> Due to the issue raised by Jacques in his email, I did not initiate >> the Kavi CD ballot on draft 1.85 >> >> To facillitate discussion and, possibly, voting on a CD at our next >> Teleconference, I just posted a contribution which removes the >> restriction (and fixes a typo) >> >> Based on Jacques email, I produced a version which takes away the >> restriction of using call back and poll with only one-way mep. I >> also corrected a typo. I just posted the revision as contribution: >> >> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8706/WS-Reliability-1085ter.sxw >> >> >> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8707/WS-Reliability-1085ter.pdf >> >> >> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8708/WS-Reliability-1085ter-diff.pdf >> >> >> >> >> >> The restrictions pointed out by Jacques, in section 6, have been >> there since CD .992 and earlier, however they are pertinent only for >> the one-way example, as shown in the figures. These had to be >> clarified as pertaining to one-way. > > > With the restrictions in Section 6 in place, we had two possible ways > forward: (1) support those restrictions with general constraints > earlier in the document, as I did and as the group apparently > supported me in doing; or (2) write a new HTTP Binding that (somehow) > provides an indication to the SOAP processor about whether or not it > should expect a SOAP Envelope in the underlying response for every > SOAP message initiated in what *might be* a request-response > situation. You have chosen a version of route (2) but have only > relaxed the restrictions without providing any information to fill the > gaps now open. I think the http binding example in the figures is for one-way. We could put in another example for request-response, or just clarify that the restriction stated is for One-way, which is what I did. We have discussed many times (with the old normative table in section 5 ) the support of callback and poll with request-response, and every time we agreed to keep the allowed behaviour. > > The restrictions in Section 6 have existed since that section was > first written, long before .992. They have never before been > constrained to only the one-way model. You are creating a new > protocol and have not filled in the gaps in that protocol when an RMP > (seemingly at its whim) makes use of an underlying request-response > binding. If we are going to support any underlying protocol and any > binding, we need to describe what the Sending RMP (or, for the > asynchronous poll and callback patterns, the Receiving RMP) can expect > to be returned. I know of no way to even describe to a standard SOAP > processor a situation in which a SOAP message may or may not result in > a SOAP Envelope in the underlying response. The RMP will only send the original request as request-response if it has been defined that way in the wsdl. The essential point of the protocol is that the rm-reply goes on a separate callback request. The response to the original http request depends on the WSDL definition for the operation. > >> The following changes were made, against draft 1.085 >> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8689/WS-Reliability-2004-08-12.pdf >> , to take away restrictions on use of callback and poll only with >> one-way mep. >> >> >> >> Page: 11 >> >> Sequence number: 1 >> >> Type: Typographic error >> >> line 336 - "between between" > > > Thanks for catching this. > > ... > > thanx, > doug > We need to discuss this at the meeting. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]