Jacques took an action item to post a document for review by thursday
evening.
Tom Rutt
Doug Bunting wrote:
> 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"[1] (using lines from the
> PDF[2]):
>
> - 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
>
> [1]
> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8746/WS-Reliability-1085-jdak.sxw
>
> [2]
> 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:]
>> 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: ;
>> 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.
>>
>
>
>
> 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.
>
>
--
----------------------------------------------------
Tom Rutt email: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
