[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Contribution suggestions just uploaded
All, As an editor, I am concerned about the lack of comments on the list from non-editors as well as the continued existence and new-found awareness of technical issues. I am unable to pull together a document reflecting what I believe will be the outcome of these discussions and will let this email, Marks contribution and my contribution serve for now. I see Iwasa's schedule as somewhat possible but doubtful due to the lack of comment on a number of questions. Within the editing team, I had some questions about Mark's latest contribution we have not quite ironed out. I have seen no comments on my earlier contribution (which happens to include a few additional editorial items but is mostly (minor or minor minor?) technical). Additional questions for the group include: - "If the specific RM Fault encountered was due to a problem with processing by the Receiving RMP, a SOAP server fault SHALL be returned." in 4.5 (lines 1056-1057 in 1.082 "no changes" PDF) does not properly distinguish between the SOAP 1.1 and 1.2 cases. Jacques has suggested "... a SOAP fault with faultcode "Server" (in SOAP 1.1) or "Receiver" (SOAP 1.2) SHALL ..." Do we have other remaining cases where the 1.1 / 1.2 distinction should be clarified? Is this the correct fix for this case (for example, does "faultcode" cover both protocols)? - Jacques believes our current text does not properly cover errors when invoking the Deliver operation. I believe we have agreement within the editing team to add this case to Table 25 (as a 3rd case for MessageProcessingFailure) but have seen additional suggestions that go far beyond that. - "A property is an assertion or constraint on a specific RM capability and its value(s) associated with WSDL elements." in B.3.3 (lines 1840-1841 in 1.082 "no changes" PDF) remains murky. Mark's original question was "What's associated with WSDL elements here: a property, a constraint, an RM capability, or its values?" Mark has suggested removing "associated with WSDL elements" but we have not seen firm support for that change. This has been mentioned a number of times on the TC list without comment. Yes, I am probably leaving a few things out of interest beyond the editing team. Sorry. thanx, doug On 10-Aug-04 13:11, Tom Rutt wrote: > I cannot make a Friday meeting since I will be on a wilderness Lake > Canoe camping. > > Tom Rutt > > Iwasa wrote: > >> All, >> >> Since we are almost there, I would like to >> pursue possibility to meet 8/15 deadline >> for voting of the spec itself and its submission >> to OASIS. Would it be possible to realize that if: >> - We agree the resolution for all remaining issues >> at the telecon.(if any) >> - Editors publish the final version of the spec >> by the end of Thursday 8/12. >> - Additional telecon on Friday afternoon/evening 8/13. >> (This must have quorum.) >> The possible agenda is: >> - Check the last updates one by one. >> - Voting for the spec to be CD >> - Voting for OASIS submission >> ? >> >> Any thoughts? >> >> Thanks, >> >> Iwasa >> >> ----- Original Message ----- From: "Doug Bunting" <Doug.Bunting@Sun.COM> >> To: "wsrm" <wsrm@lists.oasis-open.org> >> Sent: Sunday, August 08, 2004 8:14 AM >> Subject: [wsrm] Contribution suggestions just uploaded >> >> >> >> >>> The contribution I just uploaded[1,2,3] represents another >>> improvement on >>> (but not the culmination of everything required to fix) the issues >>> discussed in my long-ago "Summary of WS-Reliability 1.01* issues >>> discussed >>> over past week" email as well as the more recent "Detailed review of >>> Section 2-2.5, 5.2 and related definitions" and "about review of Section >>> 2-2.5, 5.2". We have made a lot of progress on improvements in this >>> area >>> but a bit more remains. >>> >>> Note that the two footnotes I inserted are not intended for the final >>> document but simply explain a few deletions. Those deletions also make >>> >> >> the >> >> >>> footnotes much less sensible when not viewing the differences. >>> >>> Primary areas of concern addressed in this contribution include: >>> - The BP 1.0 WSDL / SOAP / HTTP restrictions inappropriately were >>> applied >>> to the allowed abstract operations used at the producer / consumer >>> level. >>> It does not make sense to apply HTTP and SOAP restrictions to the way in >>> which a SOAP processor (our RMP component) is invoked. That >>> represents an >>> unnecessary restriction reaching across 3 abstraction layers. >>> >>> - A few remaining clarity issues. For example, while WSDL might be >>> >> >> written >> >> >>> down to describe the RMP use of the underlying protocol, we have not >>> done >>> so. In spite of this lack, "WSDL" is occasionally used in ways that are >>> ambiguous. >>> >>> - A lack of support for the BP 1.0 restrictions presented in Section 6. >>> >> >> We >> >> >>> need to generically describe various message exchanges as following the >>> patterns introduced in Section 2.3 ("SOAP one-way MEP" and "SOAP >>> request-response MEP") before the HTTP binding builds on those >>> >> >> assumptions. >> >> >>> A few more assumptions and implications needed to be written down. >>> This >>> was particularly troubling in light of the over-generality previously in >>> 2.5.2 and 2.5.3. >>> >>> - Application of a SOAP One-way MEP restriction in 6.3 to the >>> synchronous >>> Poll RM-Reply Pattern case. Fixed by moving the appropriate >>> restrictions >>> into 6.3.1 and 6.3.2. >>> >>> The specification still does a poor job describing when the Respond >>> operation is or is not supported. Nor does it make clear the >>> "meaning" of >>> a payload in a message containing only a Response header or that >>> messages >>> with none of the Request, Response or PollRequest headers have no >>> significance under the WS-Reliability protocol. Both classes of change >>> would likely be more significant than I undertook. For example, it >>> might >>> be reasonable to link the first Reliable Message "mentioned" in a >>> Response >>> element with a payload in the same message but that would extend the >>> rules >>> in 4.4 beyond the Response RM-Reply Pattern. This contribution attempts >>> >> >> to >> >> >>> illustrate the differences between the Producer / Consumer interface and >>> the SOAP message exchanges the RMPs implement but may not be >>> "complete" in >>> this respect either. >>> >>> thanx, >>> doug >>> >>> [1] >>> >>> >> >> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8586/WS-Reliability-2004-08-07-drb.sxw >> >> >> >>> [2] >>> >>> >> >> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8587/WS-Reliability-2004-08-07-drb.pdf >> >> >> >>> [3] >>> >>> >> >> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8588/WS-Reliability-2004-08-07-drb-diff.pdf >> >> >> >>> 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. >> >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]