[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of aug 17 teleconf
The prelim minutes are attached Please post any corrections to the list before friday. 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 WSRM TC Conference
Call – The meeting of the WSRM TC will take 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 Straw Poll on whether changes from CD .992 are
substantive 7 Scheduled Vote for CD (only if all comments
are resolved and we are quorate, else we could
initiate a Kavi 7 day ballot) 8 Scheduled Votes for further progression (only
if CD is voted yes) 8.1 Vote on whether changes from CD .992 are
substantive 8.2 Vote to Submit to OASIS for member vote
(subject to no vote on 7.1)) 8.3 Vote for second 30 day public review
(subject to yes vote on 7.1) 9 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 The minutes of the Aug 10 teleconf are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8739/MinutesWSRMTC081004.htm
Jeff moved to approve, Jacques seconded. No opposition, minutes are approved. 4 Status of Action Items4.1 Action 052503-1 (Tom Rutt) pendingTom took an action item to complete the status column of pre public review issues list, with correct URLs.
4.2 Action 060104-5 (Jacques) PendingAction: Jacques, will propose further edits, on the FAQ for composability. Still open, low priority 4.3 Action 081004-1 (Sunil) closedAction: Editing team should propose suggested changes for soap fault codes text, with Sunil leading the effort. Sunil provided text for the editors. 4.4 Action 081004-1 (Editor) closedAction: editors to post next draft on Thursday, Aug 12. Draft 1.085 Posted on Aug 13. 5
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.085 to the server which resolved the editorial items
from the 8/10 minutes, including Doug B contribution: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8689/WS-Reliability-2004-08-12.pdf
. 5.1 Restriction of Callback and Poll Reply patterns to one way onlyDoug: our spec does not talk about the response operation. The text which has been there for a long time in section 6 is being changed. Doug I would like to move that 1.085 is the CD. Motion failed for lack of second. Jacques; I have moved text around so the changes may look greater. Section 6 for callback and poll was only discusses with one-way operations, which did not agree with the previous table 5.2 which allowed use of callback and poll reply patterns. The TC did not explicity approve this new restriction. Either we could align section 2 with the restriction, which is what 1.085 does, if we agree to keep these restrictions. What has been done to section 6.2 and 6.3 is adding the case when the reliable message may bind to http request responses when the response has a payload. Also if a fault is part of the request response this must be explained. The section in 4.5 has been edited to align with the requirements associated with the response reply pattern is used with callback. Given these changes the original section 2 does not need to be changed. I believe this is fixing an inconsistency in a way to support the previous definitions of callback and poll. It is deterministic how the binding section has been updated. Jeff: can Doug explain what is wrong with Jacques proposal. Doug: a number of things are happening here. We are muddling the request response language. We can use a one way binding of request response at some time. What is happening here is that we are expanding the protocol, thus producing more choices causing lack of interoperability. Doug, we are only talking about request response at the underlying protocol level. We are talking about soap over http as used by rmp to send messages back and forth. Jeff: can the soap mep be request response. Doug: at the top level there is either a consumer payload or not, based on wsdl one way or request response. Doug: request response can be mapped to underlying layer by putting the response payload with rm reply in a callback. Tom: this is a different wsdl binding than the traditional soap/http Post binding in the WSDL spec. Doug: what we are trying to do here is apply restrictions to the consumer interface. Doug: the application is supposed to respond before the RMP. The RMP can take its time to send the callback. Jacques: we have some use cases. Callback can be bundled, the acks can be bundled but if you do that you may not want to sort out which belongs to one way and which belongs to request/response mep. This use case shows one use. Sunil; another use case is the sender wants a centralized ack mechanism regardless of callback or response reply pattern. The same would apply for polling. This restriction does not really simplify the protocol. Doug: I do not understand how when sending rmp sends it message how it knows that there will be date in soap body of response. We should not apply bp 1.0 at the consumer interface level. Sunil one operation has an input but does not have an output. Jeff: BP enforcement looks at messages going across the wire. All the messages using the soap/http post binding, as in section 6, must obey BP 1.0 restrictions. Jacques: you must also look at the wsdl, including the port binding, for conformance. Jacques: the restriction in 1.085 precludes using a wsdl request response bound to soap http post binding with callback or poll reply pattern Tom: the question is how important the loss of this use case is with this restriction. Jeff: we have those use cases given to us, as Sunil as described. Jeff: the 10 second short hand question: you do not want to allow callback or POLL WITH Wsdl request response on Soap http/post binding. Tom We need to clarify that we are talking about the standard wsdl soap/http-Post port binding type. Doug: if wsdl says it is one way, then that means there can be no underlying response on the wire. The ws reliability spec is a slightly different wsdl binding. Jeff: we are not talking about one way, we are only talking about request response. Doug: I agree with Tom, that if a consumer interface described as a wsdl operation using request response has to go to the underlying level, then the section 2 changes disallow it. Tom: The standard soap/httpPost wsdl port binding does make a strong mapping of application level request response to the underlying Soap request response MEP. Other wsdl port bindings could be defined which map wsdl request/respose operations to underlying soap oneway MEP, but these have not been defined yet. Doug: I would like to ask a second part of this. Regarding Application level one way message, are we required to use a one-way message at soap level for the mapping. Tom: this restriction comes if one uses the standard wsdl port binding of type soap-http/post, and the BP 1.0 restrictions. Tom: the question is: do we want to continue to allow usage of wsdl request/response operation type with a wsdl port soap/http-post binding, with the use of the callback or poll reply pattern. Tom: is anyone opposed to removing the text in 1.085 which restricts usage of request response operations with callback or poll reply patterns (when using the soap/http-post wsdl port binding). Nobody expressed opposition to removing the restriction. Tom: There is some work need perhaps to hone up Jacques proposed text. The figures have no respond primitive shown. Jacques: I will look at the figures to fix the problem · about latest
contribution + 1 observation Doug made the case for his edit of 2.5 where only
SOAP One-way (not SOAP request-response) is now used for defining the Callback
reply pattern (and Poll ) in Section 2.5 ( I initially
did not write this restriction), by pointing that he was only aligning the
definitions so that they are compatible with the HTTP binding requirements
(Section 6), that require these messages to adjust to SOAP One-way, and One-way
only. So indeed, section 2.5 and section 6 are now more consistent with each
other. I must say I had not focused much on this section
(6) before, but I have to point out something important about its current
wording: After a careful reading of Section 6.2 and 6.3, my conclusion is
the following: For RMP implementations that are BP 1.0 compliant,
the current wording of Section 6.2/3 makes it impossible to use Callback and
Poll reply patterns for messages that relate to WSDL request-response operation
types (see explanation below). I know some
of us had proposed this (Tom) before, but I am not sure this is what the TC
really intended, as we did not pursue this idea. Certainly, the now defunct Table 5.2 contradicted
this restriction. I personally have no strong opinion on this yet would rather not have this restriction. Explanation: Section 6.2
describes precise HTTP requirements related to BP 1.0 for a Callback response in case of Faults
("empty HTTP entity-body", etc) .Two statements here are restricting
the use of Callback as applicable only to WSDL One-way operation types. - L1487 (item 2) clearly states that no SOAP
envelope should go in the HTTP response, at least in normal (non fault) cases.
This combined with BP 1.0 rules out the use of WSDL request-response
operations, which bind to HTTP request-response (via the SOAP binding mandated
in BP1.0. Although this can be seen as quite restricting, that also can be seen
as a major helper in
SOAP interoperability.). - L1479-1482 requires NO SOAP fault to be returned
in case of error. But
R1029 in BP 1.0 : ("Where the normal outcome of processing a
SOAP message would have resulted in the transmission of a SOAP response, but
rather a SOAP Fault is generated instead, a RECEIVER MUST transmit a SOAP Fault
message in place of the response.") requires a SOAP fault to be returned
when a SOAP response was in order. And BP 1.0 always requires a SOAP response
over HTTP response,
for output messages that are defined for WSDL requrest-responses
operations. So these operations must always generate a SOAP Fault on the HTTP
response, which conflicts with our requirement. We havea similar situation
for Poll pattern (6.3) Proposal: If the TC intends to accept this restriction, that
should be made more explicit and at higher level (our spec is also for WS users
who think in terms of what kind of reliability features they can use with what
Web service operations, not just for developers who will look at what HTTP
binding they should use.) If not, I would suggest we reword 6.2 / 6.3 (to
accommodate both WSDL one-way and request-response), and relax the One-way
restriction for Callback reliable message. Jacques · Contribution taking away one-way
restriction on Callback and Poll Page:
11 Sequence
number: 1 Type:
Typographic error line 336 - "between between" Page:
13 Sequence
number: 1 Type:
Undue Restriction lines 407-412 - Jacques email points out that this
restriction of callback Reply pattern to soap One Way is a technical change
which is not required for the protocol to work. While releasing this
restriction may not impact most use cases for the protocol, it takes
away a capability which has always existed in previous CDs. Page:
14 Sequence
number: 1 Type:
Undue Restriction lines 415-427: This new text introduces a restriction of
poll request to one-way soap mep, which is not
required for the protocol to work. This restriction is not necessary for the protocol to work. The following suggestions are superceded by the more complete proposal from Jacques below. Page:
52 Sequence
number: 1 Type:
Undue Restriction line 1416: While the statement that , for Callback Reply
pattern, the HTTP
response has no message body is appropriate for the example, it is not a restriction required by the protocol. Should clarify
that "in this example, the HTTP response". Sequence
number: 2 Type:
Undue Restriction lines 1409-14ll: the sentence "To achieve this, the
Receiving RMP MUST NOT
return a SOAP Fault and the HTTP response entity body SHALL be empty." is pertinent only for OneWay
operations, since request/response is allowed by the protocol, this statment
must be weakened to the one way case. Page:
54 Sequence
number: 1 Type:
Undue Restriction lines 1484-1485: As in the callback text, This sentence is
only pertient to one way operations, and it should be clarified that it is
not a requirement for request response operations. Page:
55 Sequence
number: 1 Type:
Undue restriction line 1494: While the statement that, for Poll reply pattern,
the HTTP response has no message body is appropriate for the example,
it is not a restriction required by the protocol. Should clarify by
inserting "in this example, the HTTP response". · Re: [wsrm] Contribution taking away
one-way restriction on Callbackand Poll · Re: [wsrm] Contribution taking away
one-way restriction on Callbackand Poll ·
Issue on support of
request/response for callback and poll Doug
has made the point that his interpretation is that the section 6 binding is
correct, and since it has no examples for request/response operations with
callback or poll, it precludes it. Doug's
view does simplify the protocol, since for callback and poll the receiving RMP
never has to determine if a response is expected for the original request. However,
the callback and poll response always are returned the same way for either
one-way or request/response operations, so the only complication for my
interpretation of the spec occurs if the Receiving RMP has to participate in
the return of the http response to the original message. It
states in section 2.2 hat the Receiving RMP must be aware of whether a respond
is required matching a Deliver, so the added complexity to support my
interpretation is not great. Tom
Rutt · RE: [wsrm] Contribution taking away
one-way restriction on Callback and Poll I believe our latest requirements
document required Callback and Poll to accommodate both One-way and
Request-response MEPs (see
wsrm-reqm-issues-2004-01-15.xml: ... <proposal> 1. Agree to have requirement for Spec
having a solution for response Ack binding pattern,
for both one way and request/response MEP<br /> 2. Agree to have requirement for Spec
having a solution for Callback Ack binding pattern,
for both one way and request/response MEP<br /> 3. Add new requirment
for spec having a solution for sender to recieve
delayed Acks when it is not willing to recieve underlying protocol requests, for one way MEP </proposal> <resolution> Proposals 1 and 2
accepted<br /> Proposal 3 accepted </resolution> ... · HTTP binding
upgrade for Callback : proposal Title: HTTP binding upgrade for Callback : proposal Here is a more precise proposal on how the HTTP
binding of Callback (and Poll) requests (Section 6.2 and 6.3) can: (1) support both
One-way and Request-response SOAP MEPs, (2) remain fully conforming with BP 1.0 Summary of HTTP binding requirements as they
would have to be reworded in 6.2: (A) general
requirements (same as before): - the initial message
carrying the RM Request with Callback element, is an HTTP request. - the RM Reply must be
returned on a different HTTP connection
(in a request) (B) requirements
related to BP 1.0 conformance: (b1) If
the HTTP request carrying
the Callback reply pattern element is binding to a WSDL One-way
operation: (then current requirements
are OK): - no SOAP envelope
should be returned in the HTTP response (HTTP entity-body is empty) - in case of RM fault,
NO SOAP Fault MUST be returned (and HTTP status code should be...) (NOTE: Abstracting this from WSDL, we can
require this for any SOAP One-way MEP) (b2) If
the HTTP request carrying
the Callback reply pattern element is binding to a WSDL
Request-response operation (this need be added): - a SOAP envelope may
be returned in the HTTP response by the responding party (Consumer) - in case of RM fault,
a SOAP Fault MUST be returned (and following same requirements as for Response
reply pattern, L1033-1047 Section 4.5...) and L1048-1050 must be corrected
accordingly. (NOTE: Abstracting this from WSDL, we can
require this for any SOAP Request-response MEP) I'll send a "contribution" matching
these asap, as Tom's
contribution remains silent on the (b2) part above. Regarding (B) above, a precision/correction must
be added to my previous sending: When complying to BP 1.0, a Receiving RMP (if
not the Sending RMP) must be able to distinguish the case (b1) from (b2) above, especially in order to
know how to handle faults. But it is always expected that this features is
supported by BP 1.0 compliant WS stacks on which the RMP is deployed, so that
an implementor of WS-R is always in a measure to know
when to add a SOAP Fault in the body (b2), and when not (b1), in case of RM
error, and this without having to be explicitly instructed of which MEP is
being used. The requirement that an RMP who invokes
"Deliver" knows whether or not a related "Respond" will be invoked, is satisfied in the same manner. Some implementation examples: (case 1) the RM
features are implemented as a Java handler in a WS stack complying with BP 1.0
(e.g. Axis 1.2). In that
case, when a request is faulted due to RM fault, the handler will
systematically generate an exception. The effect of this exception tells the
responding RM handler what to do: if the stack generates an empty HTTP response
with the right status code as BP
1.0 requires for One-ways WSDL ops, then our handler will not add anything to
it (b1). If the stack generates an HTTP response with a
SOAP Fault as BP 1.0 requires for Request-response WSDL ops, then our handler will make sure the Fault has
the right code, and let the WS stack forward it to Sender (b2). (case 2) the RMP is an
endpoint itself. In that case, it has knowledge of the [WSDL] operation types
the messages it receives/sends bind to. If no WSDL is used, the RMP will still have
knowledge of the SOAP MEP involved. Jacques The
contribution http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8742/WS-Reliability-1085-JD.pdf applies Jacques final proposal to the changes
in the contribution from Tom Rutt, to draft 1.085. 5.2 Anish Proposal for definition of Property· Suggestions
to improve wordings of features and properties 1) In section B.1 (Introduction), there is a
bullet list consisting of feature (and its
definition), property (and its definition) and compositor (and its
definition). I would like to propose that we keep the bullet list, but
remove the definitions and replace it with forward references to the
appropriate sections where the definition occurs) I.e: *
feature <reference-to-B.3.2> * property <reference-to-B.3.3> * compositor <reference-to-B.3.1> This would mean that the definition will occur
only once in the spec. 2) At the end of the 2nd sentence in B.3.3 add: "A property can occur only as a child of a
compositor." The complete paragraph now will be: "A property is identified by a QName. A property is an assertion or constraint on a
specific RM capability and its value(s). A property can occur only as a child of a compositor." Mark peel moved to accept Anish proposal, seconded by sunil. No opposition to accepting Anish’s proposal. Two contributions were posted by the chair: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8749/WS-Reliability-1085-ak.pdf applies the proposal from anish to the draft 1.085 http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8747/WS-Reliability-1085-jdak.pdf
applies the proposal to the contribution 1.085jd, from Jacques, to remove
restriction of callback and Poll Reply patterns to one-way 6 Straw poll on whether changes from CD .992 are substantive.Since the vote on CD might be influenced by whether that CD will be put out for another public review, the chair proposes an informal straw poll to determine whether the changes are considered substantive from CD .992. Thus the decision as to
whether the changes from CD .992 are substantive will be left to a vote when
the next CD is agreed. 7 Scheduled Vote for CD (only if all comments are resolved and we are quorate)wait till Aug 24. 1 Scheduled Votes for further progression (only if CD is voted yes)No cd to discuss 2 Discussion of document progression and future meeting scheduleGoal is to Vote on CD at next meeting. Based on agreement to not adding new restriction on use of wsdl request response with soap/http-post binding and callback or poll reply pattern, Chair suggested that we use contribution 1085-jdak (http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8747/WS-Reliability-1085-jdak.pdf) as the basis for comments. This incorporates Jacques changes, and Anish’s clarification of property. Comments due to wsrm list by Thursday Noon Pacific Time on 1085-jdak , used as the basis for comments. Action: Jacques will provide a new draft 1.086
By Thursday evening, to resolve any comments posted to the list by Thursday Go for CD vote at the next meeting. Discussion
on next face to face meeting From Aug 10 minutes: Tom: lets consider two possible tracks:
Agree to another two hour conference call next week. Go for a CD vote with all other possible votes. Alan: I think it would be good to have an interop for developers at the next Face to face. NEC cannot participate in an early October interop. The October 4 date is too early. Jeff The Brussels event is not meaningful. Tom: We are either talking about a face to face in November or December, timed to address the Oasis member comments. Alan: Interop is important. Tom : the spec has not changed much from the interop. The implementation changes from the last CD are not substantive. Bob: we need to have relatively friendly member interop which is not widely publicized. Subject to its outcome, we can do a public interop at a platform event. I do not want to confuse those into one event. Tom: a November meeting could accommodate the interop event. Jeff: the interop event does not need to be timed tightly with our meetings. Bob: I have put out a request for timing, when the responses come in, we can determine at time which accommodates us all for the private interop The public interop should be timed with some significant conference giving an appropriate audience. Tom: the next f2f should be based on evaluating member comments. · Agenda
items for next week's call Defer to next week. · Gartner 11/04 demo opportunity Bob F moved to adjourn Alan seconded. Nobody opposed. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]