[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of WSRM TC teleconf 8/10/04
The prelim minutes are attached. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
Preliminary Minutes of WSRM TC
Conference Call – The meeting of the WSRM TC took place by teleconference 1
Draft
Agenda:
1 Draft Agenda to WSRM TC Conference Call 2 Roll Call 3 Minutes Discussion 3.1 Appointment of Minute Taker 3.2 Approval of previous meeting minutes – 4 Action Item Status Review 5 Discussions of unresolved comments 6 Scheduled Vote for CD (only if all comments are resolved and we are quorate, else we could initiate a Kavi 7 day ballot, or wait till Aug 17) 7 Scheduled Votes for further progression (only if CD is voted yes) 7.1 Vote on whether changes from CD .992 are substantive 7.2 Vote to Submit to OASIS for member vote (subject to no vote on 7.1)) 7.3 Vote for second 30 day public review (subject to yes vote on 7.1) 8 Discussion of document progression and future meeting schedule 2
Roll
Call
Attendance:
Meeting is quorate. 3
Minutes
Discussion
3.1 Appointment of Minute TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 3.2 Approval of previous meeting minutesThe minutes of the Aug 3 teleconf are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8457/MinutesWSRMTC080304.htm xx moved to approve, yy seconded. ?? opposition, minutes ?? approved. 1 Status of Action Items1.1 Action 052503-1 (Tom Rutt) pending
Tom took an action item to complete the status column of pre public review issues list, with correct URLs.
1.2 Action 060104-5 (Jacques) PendingAction: Jacques, will propose further edits, on the FAQ for composability. Still open, low priority 2
Discussion
of Issues and editorial Comments
The following issues list includes items which
have been resolved as of the output of the Additional
issues and comments were circulated to the list for discussion. These
need to be resolved before we can vote on a next CD. The editing
team posted draft 1.083 to the server which resolved the editorial action items
from the 8/03 minutes: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8621/WS-Reliability-1083-Contrib-Peel.pdf
WS-Reliability-2004-08-07-drb.pdf off 1.082 needing more discussion. 2.1 What changed discussionDoug: we have three documents:
· What changed in 1.082? · Re: [wsrm] What changed in 1.08? · Re: [wsrm] What changed in 1.08? 2.2 Email Discussion Items· Contribution suggestions just uploaded Subject:
Contribution suggestions just uploaded * From: Doug Bunting
<Doug.Bunting@Sun.COM> * To: wsrm
<wsrm@lists.oasis-open.org> * Date: Sat, 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 Re: [wsrm] Contribution suggestions just
uploaded Subject:
Re: [wsrm] Contribution suggestions just uploaded * From: "Iwasa"
<kiwasa@jp.fujitsu.com> * To: "Doug Bunting"
<Doug.Bunting@Sun.COM>, "wsrm"
<wsrm@lists.oasis-open.org> * Date: 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 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. Doug: This TC is not responding to requests from the editing team to help resolve text changes. This is a high level issue, and we need to have more reaction. Nobody has reacted to my contribution. 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 the following: -
"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)? Doug: I think Jacques suggestion is ok, but we have to check of Fault Code covers both soap 1.1 and 1.2. Sunil: I do not think if Fault code is used in 1.2. Soap 1.2 has Fault and Code, code has a subelement called value. Soap 1.1 uses terms server and client, 1.2 uses sender and receiver. Jacques: the latest draft needs improvement on this. Issue: Need improvement for wording. They Tom: This is an editorial Issue which needs resolution discussed. Action: Editing team
should propose suggested changes for soap fault codes text, with Sunil leading
the effort. -
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. Doug: this is regarding the composibility comment which needs further discussion. Doug: we can add case to Table 25 as an additional case for MessageProcessingFailure. Jacques: I agree with the third new condition for Message processing failure with Doug’s wording. Doug: There is disagreement on the other two changes. These changes are discussed in the section on edits to enhance composibility issue below in these minutes. -
"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. Doug: Needs discussion. B.3.3 Mark is working on this sentence, and the editor’s team does not have a firm decision made. There is a suggestion. Tom: anyone unhappy with Mark’s suggested fix in the above bullet should post by end of day tomorrow, so editors can include fix into the Thursday Document. Tom: also post any concerns with Marks latest contribution by end of Wednesday. 2.3 Edits to enhance composability· proposed edits for enhancing composability · RE: [wsrm] proposed edits for enhancing
composability · Re: [wsrm] proposed edits for enhancing
composability Subject:
Re: [wsrm] proposed edits for enhancing composability * From: Doug Bunting
<Doug.Bunting@Sun.COM> * To: Jacques Durand
<JDurand@us.fujitsu.com> * Date: Jacques, A few comments below. On
>
When looking at some composition patterns of WS-R with other specs, >
I observed the following, which I think deserves our attention for this >
release: >
>
- One case of failure is missing: we have implicitly recognized that the >
Deliver invocation >
may fail (as we require it to be "successful" in our RM contracts)
but >
we do not say what happens in that case (after the
message has passed > every other test). >
>
We know the message will not / should not be acked.
But what kind of >
fault is returned? >
>
Proposal: Edit Table 25 to add in the entry for MessageProcessingFailure: >
"In case of failure of the Deliver operation, a MessageProcessingFailure
>
RM fault SHALL be generated." This
table covers faults in every situation I believe. We need to be careful about SHALL in this context since the Receiving RMP
is *not* required to publish any fault unless AckRequested
was enabled for the received Reliable Message.
The only current RFC 2119 terminology in these tables is a single MUST NOT which is fully described in that
clause. I would recommend toning down this requirement and phrasing it
as an addition to the existing list: "3. The Deliver operation
fails." >
- A requirement of composability, is that we need to
be accommodating of >
3rd party faults: >
in Section 4.5 (rules for processing faults): The
response message (in >
case of Response reply pattern) may also contain a SOAP Fault generated >
by the next processor in case the next processor
faults it. This
seems to go against our overall Messaging Model as introduced in Section 2.1. How can
a "next processor" exist if the Receiving RMP is the SOAP
ultimate destination? On
the other hand, the RMP implementation may include other components operating in parallel with the infrastructure described in
the WS-Reliability specification. We make that provision explicit in a few places, including the "RMP" definition
itself. Since the RMP also includes generic SOAP processing capabilities, SOAP Faults are easily
returned with or without RM Faults.
For example, the Sending RMP may include something in the Reliable Message that causes a SOAP Fault (such as a mustUnderstand fault) -- preventing any WS-Reliability-specific handling of
that message. Since SOAP Faults are fatal and prevent other
processing of a received message, I believe the combined SOAP Fault / RM Fault cases
are limited to the list already described in Section 4.5. If
you believe it necessary to warn implementors again
that the SOAP processing model remains in effect, I guess some words about
"bare SOAP Faults
might arrive back at the Sending RMP in situations not described in this specification" could be added to Section 4.5. I probably would not bother. >
If we accept the proposal that "Deliver operation failure" is one
more >
case of MessageProcessingFailure,
we must also consider the following: >
>
depending on implementations, the Deliver operation
itself may involve >
some external SOAP processing in order to complete
successfully. >
>
A specific SOAP Fault may be generated when Deliver fails on Receiving >
side (cannot complete). Then we need to relax the
requirement that a >
"SOAP Server fault SHALL be returned". It could be another fault >
generated by the next processor (e.g. MustUnderstand). >
>
Proposal: Edit in 4.5 "rules for processing faults" as follows: >
Replace: >
> "If the specific RM Fault
encountered was due to a problem with > processing by the Receiving RMP, a SOAP
server fault SHALL be > returned." >
> with: > "If the specific RM Fault
encountered was due to a problem with > processing by the Receiving RMP, before
the Deliver operation >
> was invoked onthis
message, a SOAP server fault SHALL be returned." I
would prefer we rely on our normative references to the two
SOAP specifications for this type of constraint. It should not be necessary to repeat rules from those specifications. Ø Jacques Jacques: the point I am making is that our spec requires a specific
fault code with specific code value.
This code value, given the edits to be done by editing team, should be
restricted to the case where message processing fault are encountered before
the deliver operation is invoked. If the
failure occurs during execution of deliver, I would not make prescription on
what soap fault code is returned, because Deliver may involve external
processing. Doug: This change exposes the innards of a particular RMP
implementation to the world unnecessarily.
Any case where an rm fault is generated an published is under the RMPs
control, as far as the sending RMP should know.
The more I understand your intent, the more I see it as making one
implementation choice overly visible. Jacques: My example is not the main stream case,
my main incentive for suggesting we do not prescribe the soap fault once
deliver is invoked is I see no value for imposing the fault code for every rm fault. Jacques: we have not considered the case of Failed
invocation of Deliver, which should not be acknowledged. If we impose particular
soap fault with this. Sunil: Soap 1.1 has four fault codes, soap 1.2 has five. Sunil: The only time we prescribe sending client or sender fault code
is to indicate that the header has problems.
We send receiver, or server fault for all conditions because of
processing at the Receiving RMP. The
Must Understand fault is a specific case. Jacques: I am convinced there are some cases the server or receiver
fault code should not be sent with delivery not completed. Doug: If the receiver sends any other than server/receiver fault code,
it will confuse the sender. Doug: the case Jacques is talking about is if the receiving rmp is implemented to send a soap message to a downstream
soap processer.
That other place sends the receiving RMP why it failed. Jacques want to proxy the downstream soap
fault in the rmp response. I still think that for this case the
server/receiver fault code is the only appropriate one. Jacques: I do not want to push this that much, since this is a corner
case. If others believer that this is
the only appropriate fault, I can live with it as is, with the table change. 2.4 Section
2
· Re: [wsrm] about review of Section 2-2.5, 5.2 · about review of Section 2-2.5, 5.2 Doug: I posted a contribution WS-Reliability-2004-08-07-drb.pdf off 1.082, to resolve these concerns, but have received no response from the group. Jacques: I have not been able to review the detailed changes, and I think I can give my comments by Wednesday. Doug: I would like the TC to let us know whether my contribution improves or worsens the spec. If there are parts which need fixing it should not be Jacques. Doug: it is not perfect set of changes, but do those which we can reasonably undertake in this version of the specification. I believe we should make these changes now. Doug: the patterns of messages used by RMPs are different than the patterns of messages used by the consumer and producer, and I added sentences to section 2 to explain those differences. It is a different way to explain that as a difference rather than a restriction. Jacques: I just now got a hold of the contribution. My only comment of getting rid of table in 5.2 is that it clarifies what reply patterns can be used which which WSDL operation types This relationship is not because of WSDL, but is because of the underlying soap MEP which is assumed. Somewhere it must be made clear that the usage of the reply pattern is affected by the wsdl Operation type. Tom: the only restriction in the table is regarding the wsdl oneway message not being appropriate for response reply pattern. Doug: and that statement is tied to BP 1.0 and its binding to Soap-HTTP/post wsdl binding. You cannot use oneway because we require acknowledgements Jacques: I agree this restriction is only for when the BP 1.0 restriction for HTTP soap binding. Doug: I did not make major changes to the http binding section; I just referred to constraints in section 2. I made the general rules in section 2 a little bit tighter. Doug there are only a few items left in the editing of the document, I can take the editing changes from Mark, and apply the agreed suggestions from my contribution to the edited text from Mark. Tom: I suggest that we have the entire TC post any concerns about Doug’s contribution before the end of Wednesday, so the editors can have a new document by Thursday. 3 Scheduled Vote for CD (only if all comments are resolved and we are quorate)Will defer to after the next draft is posted. 4 Scheduled Votes for further progression (only if CD is voted yes)CD not voted. 5 Discussion of document progression and future meeting schedule5.1 Progression discussionAction: editors to post next draft on Thursday, Aug 12. Best possibility is a CD vote on Aug 17th. If not 2/3 quorate this could be a Kavi ballot. This would be followed by a Vote on whether changes are substantive from CD .992. Tom: As chair I must state that the schema changes would make an implementation of .992 not validate with the new schema. Some might consider such a change substantive. Jacques: because the changes are small, while the schema validation is different, the substantial algorithms are the same. The changes are superficial on the impact of the implementation. This could be considered not substantive. Tom: lets consider two possible tracks:
Possibilities
include the week of the Oct 4 in Tom: we Need to wait till next week to know if we are on track A or B and schedule the face to face as appropriate. Also need further discussion on the interop demo. 5.2 Possibility for early KAVI ballotDoug: rather than starting a Kavi vote after failing to get supermajority at beginning of teleconf next Tuesday, why not start that Kavi vote as soon as a document appears which Doug we can vote on same issue in person, the ballot can be closed. Tom: Do I have freedom to issue a Kavi ballot Saturday Evening or Sunday morning, if there are no comment on the Thursday draft. No opposition. If we are super-quorate on Tuesday we can start a new ballot right then. This might be required if there are late changes requested on Monday. It is crucial that people respond to any comments on existing contributions by Wed PM, and on the Thursday Draft by Saturday afternoon. Bob: I am concerned that we keep working for the 15th deadline. Summer is a tough time. We need to get things going as fast as possible. 5.3 Discussion of Interop DemoAlan: the implementations will have to change due to the schema changes, and thus we should work toward another interop demo. Bob:
I am sending mail to determine an appropriate venue and time for the next interop demo. The Alan: is the objective to gain publicity. Bob: another way is to have a clinic with anybody to bring implementations to. Bob: I will send a mail out to the entire TC on the particulars for the next interop demo. Doug: you could run this over a longer period of time with available endpoints. 5.4
Future work items
· Suggested
work items once we complete CD vote Defer this discussion to next week, after we know which track we are on. Bob moved to adjourn. Alan seconded. No opposition, meeting adjourned. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]