Subject: Re: [wsrm] comment on 1.085jdak
I suspect it will be necessary and useful to go one step further than "An RMP MUST be able to distinguish which SOAP MEP is being used when sending or receiving a Reliable Message." We need to explicitly state any WSDL instance describing the relevant Consumer interface defines the wire-level for the Reliable Message. That is, "The Sending RMP MUST use the SOAP MEP (as defined in Section 2.3) corresponding to the WSDL operation associated with this Reliable Message." I would also recommend resurrecting table 5.2 though not as a table. I do not believe the current drafts explicitly state the restriction that "the Response RM-Reply Pattern MUST NOT be used when the relevant Consumer WSDL is a one-way operation". This seems important and should not need to be inferred from other restrictions in our specification. Words to that effect should appear in Section 2.4.1 (or earlier). A few additional comments on draft "1085jdak" (using lines from the PDF): - At line 411 (in Section 2.4.2), the MEP restrictions on the Callback message itself (the publication) have been lifted. This implies it is possible for the Sending RMP to respond in some way to this message but we have not described any purpose for such a response. Since this SOAP message is almost always (apart from the "bundle" case discussed in Section 4.4, see below) an RMP signal and nothing else, this restriction should stand for the general case. It should, however, be overridden in the case where a Response and Reliable Message are combined -- meaning the Reliable Message constraints "win" when bundled. I recommend this change to step 2 not be made. Generally, the Consumer interface description controls the sending of a Reliable Message and, optionally, its response. That interface or WSDL instance does not describe how other RMP signals are exchanged. We do, however, need to clearly describe these exchanges in this specification -- without multiple options. - For this section and the next, we probably need to also be explicit about the soap:Body being empty (and the lack of attachments) for all steps in the sequences in the Callback and Poll RM-Reply Patterns but the first. That is, no application content may be bundled with the callback publication or poll request / response (except in the single bundle we define later). - At line 416 (in Section 2.4.3), the requirements on SOAP MEP support have been changed and made overly broad. These requirements should now be closer to the previous edit, though widened a bit: "... the SOAP One-way MEP MUST be supported. When using the "synchronous" option described below or when a Consumer payload is expected, the RMPs MUST also support the SOAP request-response MEP." - At lines 425 and 429, the MEP restrictions on the asynchronous Poll request and response have been lifted. Similarly to line 411, these extensions do not enhance interoperability and instead leave confusing options open. Unlike the Callback case, our protocol does not support bundling a Poll request or response with a Reliable Message. Therefore, I recommend this change to steps 2 and 3 not be made. - At line 932 (in Section 4.4), we introduce the idea of combining a Callback message with an unrelated Reliable Message. This paragraph should describe whether the Callback RM-Reply Pattern (ie. the original Reliable Message) or the new Reliable Message decides the SOAP MEP for this message. An additional sentence such as "The restrictions described in step 2 of Section 2.4.2 are not relevant for such a message; the Reliable Message is exchanged as it would without the additional (Response) element." might do it. - At line 1033 (in Section 4.5), the changes combine to leave us with "When a Reliable Message is sent over a SOAP Request-response MEP (regardless of the RM-Reply Pattern value), a Consumer response payload is therefore expected, and ..." Why not simply "When a Reliable Message is sent using a SOAP Request-response MEP and ..."? Perhaps a "(regardless of the RM-Reply Pattern used)" bit could be added but the rest is redundant. - Starting at line 1417 (in Section 6.2), a number of reminders that each message must be sent using the "HTTP POST method" appear. Since such requirements have already been made for the general case (the bullets at line 1320 in Section 6, for example), these additions seem unnecessary. The early references to the examples also do not seem as clear as the previous bulleted list of steps. - The new bullets as line 1430 seem correct but should be placed in Section 6 as they cover the general case. What is necessary in the sections specific to the RM-Reply Patterns is an explanation of and introduction to the examples. BP 1.0, SOAP, HTTP and WSDL have already been documented quite thoroughly, as has our general mapping from our generic SOAP MEPs to HTTP exchanges. - editorial: At line 1432, "then" is always unnecessary with a simple "if" clause. Most of these have been removed from the document, making this sentence inconsistent with the rest of the specification. This is one example of a more general need to repeat a number of editorial fixes (removing spaces and unnecessary "join" words mostly) before we are done. More generally, who is doing what at the moment? I have seen no email among the previous editing team and cannot quite grasp the outcome of our teleconference from either my time on the call or the preliminary minutes. thanx, doug  http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8746/WS-Reliability-1085-jdak.sxw  http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8747/WS-Reliability-1085-jdak.pdf On 18-Aug-04 16:45, Jacques Durand wrote: > inline > > -----Original Message----- > From: Tom Rutt [mailto:email@example.com] > Sent: Wednesday, August 18, 2004 10:46 AM > To: wsrm > Subject: [wsrm] comment on 1.085jdak > > > In general I like the approach taken by Jacques. > > My only concern is that the figures 9, 10, and 11 in the http binding > section for callback and poll do not show > the rm-operations for Respond. > > Either: > - the figures can be clarified as examples illustrating the use in the > one-way soap mep case (the easiest approch), with an explanation that > the corresponding figures for request/response mep are not shown, or > - change to a new set of figures which have a dotted respond arrow with > an explanation that the respond arrow is only used for request/response > mep. > > <JD> I'll keep track of these proposed updates in case Iwasa cannot do > them for > teh contribution by tomorrow. > > In any case there needs to be a statement that the sending and receiving > RMP must know when an application response is required for the operation. > > <JD> Yes, although the need to "know" which SOAP MEP is used when sending a > Reliable Message, has always been there due to the fact that the sender > (and receiver) needs to distinguish which SOAP MEP is used with the > Response reply pattern ( One-way MEP not allowed). The Receiving RMP > also had to distinguish (for handling of SOAP Faults) > > (see lines 1027-1046), although we could argue that just looking at the > RM Reply Pattern used was a sufficient - yet not error proof - way to > figure this out (no longer the case in this contribution as Callback and > Poll can be used on either MEP) > > So we may want to make this more explicit. > I'll suggest a line in Section 2.3, after L382, saying: > "An RMP MUST be able to distinguish which SOAP MEP is being used when > sending or receiving a Reliable Message." > Hamid reassures me that this is well supported by the WS stacks, whether an > RMP is implemented as a handler or an end-point (e.g. SOAP node) > so there is no need to specify further how the RNP gets this knowledge > (implementation specific) (see my previous email). > > Jacques > > > > > Tom Rutt > > -- > ---------------------------------------------------- > Tom Rutt email: firstname.lastname@example.org; email@example.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.