[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary minutes of 7/6 teleconf
The prelim minutes are attached. Please provide corrections before Friday. We resolved the issues, and Iwasa will post a draft 1.05 for serious review with comments requested before end of business on Next Monday, July 12. I will schedule a vote for CD at the next meeting on July 13. 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 –July 6, 2004 The meeting of the WSRM TC took place by teleconference 1
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call 1 Roll Call 2 Minutes Discussion 2.1 Appointment of Minute Taker 2.2 Approval of previous meeting minutes – 3 Action Item Status Review 4 Discussions of unresolved comments 5 Discussion of Document progression 6 Discussion of FAQ for WS-Reliability 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.1 Approval of previous meeting minutesThe minutes of the June 29 teleconf are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7555/MinutesWSRMTC062904.htm Bob F moved to approve, Jishnu seconded. No opposition minutes 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 4.3 Action 062904-1 (Jacques) ClosedAction: Jacques will propose refined text to resolve Binding model issue. Jacques provided text in contribution draft 1.04 at: 5
Discussion
of Issues and editorial Comments
The following issues list includes items which need further discussion: 5.1 PC24
· Uploaded contribution (June 30) on messaging
model - MEP update Jacques
took into account the remarks from several people. He edited the previous proposal, with edits
to make it clear, and to not include unnecessary terms. In
section 2.2, a shorter set of requirements on rmp
operations and invocations. It was
clarified that the submit and deliver are mandatory. Tom:
we need to clarify in a few places that the respond is invoked when a consumer
payload is expected. Use
proper subheadings for two subsections in section 2.4. Use
proper subheadings for subsection so section 2.5. · Re: [wsrm] Uploaded
contribution (June 30) on messaging model - MEPupdate Comments on how to amend the figures to go along
with Jacques new text: Perhaps Iwasa could post
another contribution with the figures fixed, for us to evaluate along with
Jacques new text.: Figure 2: messaging model (include the Respond
primitive (perhaps with dotted line) down arrow from
consumer to receiving rmp Figure 3: put solid respond arrow from consumer to receving rmp. Change "underlying
protocol" to "SOAP MEP" on both horizontal arrows Figure 4: Change "underlying protocol" to
"SOAP MEP" on both horizontal arrows Figure 5: Change "underlying protocol" to
"SOAP MEP" on all three horizontal arrows Figure 8: add the down arrow for Respond from
consumer to Receiving RMP Re: [wsrm]
Uploaded contribution (June 30) on messaging model - MEP update The
document FiguresFor1.05.pdf has been submitted by Kazunori Iwasa
(kiwasa@jp.fujitsu.com) to the OASIS Web Services Reliable Messaging TC
document repository. Document
Description: This
PDF file contains proposed updates for figure2, 3, 4, 5, and 8 consistent with
Jacques's contribution document at
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7523/COntribution-JD-WS-Reliability-2004-06-30.pdf Download
Document: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7562/FiguresFor1.05.pdf On
figure 5 change Response/Response to Response/Request Iwasa moved to resolve issue with Jacques
proposal as amended above. Bob Freund
seconded. No opposition,
motion passes. 5.2 PC25
· Proposal to resolve PR25 - Duplicate message
response Proposal to
resolve Issue PR25 – Duplicate message response The public review
draft, CD .992, clearly states the following behaviour
in section 4.5: “ A message with an
RM Fault indication MUST NOT be delivered by the receiving RMP. If the message cannot be
delivered due, say an request fault, then there would be no meaningful
data for the responder to put into the SOAP Body for the WSDL response. When using the
Response RM-Reply pattern, a WSDL operation reply will not always be available for the receiving
RMP to return with the RM-Response. This will occur when there is a Reliable
Messaging Fault for the message in the request, or when the message in the
request is a duplicate of a
prior delivered message with Duplicate Elimination in use. When a receiving
RMP cannot return the WSDL operation response for a request using the Response Reply
Pattern, it MUST return the RM Response in a SOAP Fault message. If the RM Fault encountered
was due to a problem with the request header element, a SOAP client fault MUST
be returned. If the RM Fault encountered was due to a problem with
processing by the receiving RMP (including
the inability to return a response due to Duplicate Elimination), a soap:server fault must be
returned. “ However, the
wording above needs to be amended, to use the new terms introduced by Jacques in
contribution draft 1.04. We agreed to put the duplicate elimination response behaviour in the section pertaining to duplicate
elimination. Propose
Resolution: Add the following
text at the end of section 3.2.2, Duplicate Elimination – protocol
requirements: “ “ When the Response
RM-Reply Pattern is requested with duplicate elimination for a reliable message, and a
resend of that message cannot be delivered to the Consumer by the Receiving RMP
because it is a duplicate of a previously delivered message, the response of the SOAP MEP
instance: - SHOULD contain
a copy of the original response payload returned for that message ID (in
the SOAP Body) in addition to the rm-acknowledgement indication (in the SOAP
Header). - MAY contain a
SOAP server Fault (in the SOAP Body) in addition to the rm-acknowledgment indication (in
the SOAP Header). The Sending RMP
and Producer expect either a complete response or a SOAP Fault when using the Response
RM-Reply Pattern and these two allowed behaviours
satisfies those expectations. “ Tom: need to add “and when a consumer response payload is expected,” to the lead in text. Bob moved to resolve issue with amended text above. Iwasa seconded. No opposition, motion passes. Jishun moves to amend, to clarify that this is either or, but not both. Bob seconded. No opposition. Final text of motion proposal: “ When the Response RM-Reply Pattern is requested with
duplicate elimination for a reliable message, and a
resend of that message cannot be delivered to the Consumer by the Receiving RMP because it is a duplicate of a
previously delivered message, and when a consumer response payload is expected,
the response of the SOAP MEP instance must
contain one or the other of the following, but not both: -
a copy of the
original response payload returned for that message ID (in the SOAP Body) in
addition to the rm-acknowledgement indication (in the
SOAP Header)., or; -
a SOAP server
Fault (in the SOAP Body) in addition to the rm-acknowledgment
indication (in the SOAP Header). The Sending RMP and Producer expect either a complete
response or a SOAP Fault when using the Response
RM-Reply Pattern and these two allowed behaviors satisfy those expectations. “ No opposition motion passes. 5.3 PC26Sunil Kunisetty Title: Soap Fault with RM-Fault Description: Sunil Mail 1Sunil Mail 2Sunil Mail 3 Proposal: under discussion Resolution: · Proposal to resolve PR26 - Soap Fault with
rm-fault · Re: [wsrm] Proposal to resolve PR26 - Soap
Fault with rm-fault Tom, I have a slight (very slight) preference toward a SOAP fault in the case that an RM fault leads to an unexpectedly empty SOAP Body. However, this text should be focused specifically on that case since the producer may not be expecting any consumer payloads. SOAP Body content (a SOAP fault) would be entirely redundant and itself unexpected unless a consumer payload was expected. To avoid such an over-generalized statement, I would suggest adding "and a consumer payload was expected" before the comma in both sentences you propose. An editorial nit: Should these two sentences be talking about "soap:client" and "soap:server" or "SOAP client" and "SOAP server" faults? Consistency seems necessary here. thanx, doug [1] ... whom, I assume, is the target of the SOAP fault. This is a bit counter-intuitive since the sending RMP hides the SOAP messaging layer from the producer to some extent. On > Proposal to Resolve Issue PR26 – Soap Fault with RM-Fault > > The behaviour that an RM-Fault is returned with a soap fault in the case > that a response > payload is not available for response reply pattern was part of the > public review draft > cd .992. The changes suggested by Sunil would constitute a substantive > change to the public review draft. > > This behaviour works, and provides fault information separately tarteted > for the rmp and > the producer. > > However the following sentences were inadvertently removed during > editing after > CD .992 > “ > If the RM-Fault encountered was due to a problem with the request header > element, a SOAP > client fault MUST be returned. If the RM Fault encountered was due to a > problem with processing > by the receiving RMP (including the inability to return a response due > to Duplicate Elimination), a > soap:server fault must be returned. > “ > > We agreed to have section 4.5 only talk about rm faults, so the > parenthetical statement should be removed. > > Proposed Resolution: > > Add the following paragraph in Line 1070 of 1.04JacquesContrib, after > the first sentence of the bullet: > “ > If the RM-Fault encountered was due to a problem with the request header > element, , a SOAP > client fault MUST be returned. If the RM Fault encountered was due to a > problem with processing > by the receiving RMP, a SOAP server fault must be returned. > “ > > > Tom Rutt > Tom: Doug suggested adding “and when a consumer response payload is expected” to both statements. Bob F moved, Jishnu seconded to resolve this issue with the amended text: “ If the RM-Fault encountered was due to a problem with the request header element, and a consumer response payload is expected, a SOAP client fault MUST be returned. If the RM Fault encountered was due to a problem with processing by the receiving RMP, and a consumer response payload is expected, a SOAP server fault must be returned. “ No opposition, motion passes. 5.4 Comment on the ref Schema· Minor technical issue (or two) in the
reference.xsd schema · Re: [wsrm] Minor technical issue (or two) in
the reference.xsd schema > The most recent copy of this schema[1] does not seem to support (allow > validation of) the WS-Reliability 'bare URI' scheme. To directly insert > text into the wsrm:ReplyTo element, the ref:ServiceRefType type must > support mixed content. That is, > > <xsd:complexType name="ServiceRefType"> > <xsd:sequence> > <xsd:any namespace="##other" processContents="lax"/> > </xsd:sequence> > <xsd:attribute name="reference-scheme" type="xsd:anyURI" use="optional"/> > </xsd:complexType> > > should instead be > > <xsd:complexType name="ServiceRefType" mixed="true"> > ... > </xsd:complexType> > > An alternative would be to leave ServiceRefType as is and define a > particular BareURI (simple) type or element in either reference.xsd or > ws-reliability-1.1.xsd. Lots of options but the element would be simple > in every case: > Good catch. I too prefer specifying a separate element/type to making it mixed. Making it mixed will require us to specify what happens if the content is indeed mixed -- i.e. has both CII and EII. Defining the new element/type for bare URI just seems simpler. > <xsd:element name="BareURI" type="xsd:anyURI"> > > or > > <xsd:simpleType name="BareURIType"> > <xsd:restriction base="xsd:anyURI" /> > </xsd:simpleType> > > <!-- > BareURIType would be ref:BareURIType if the element were in the > WS-Reliability schema while the type is in the reference schema. > --> > <xsd:element name="BareURI" type="BareURIType"> > > I lean slightly toward this second approach because it is more > consistent with the other expected (WS-Addressing or WS-MessageDelivery, > for example) cases. That is, the element of ref:ServiceRefType would > have the consistent semantics of identifying the set of messages in > which the contained address is relevant. The namespace of the contained > element and the @reference-scheme value would identify the semantics of > that address. > > Which raises another niggle I had not considered earlier: I believe the > namespace of the contained element or the direct inclusion of text in > the wsrm:ReplyTo element (if we leave that option) provides the same > information as the @reference-scheme value. Do we need both? > The reference-scheme attribute is optional. Therefore if it is considered to be redundant for a particular addressing scheme then it could certainly not be used (as is the case for bare uri). Having the optional reference-scheme attribute covers the case where the QName of the child EII does not specify the semantics of the addressing scheme. For example, WS-MD uses the WSDL 1.1 service element as a reference (with some restrictions on the contents of the service element). In this case the child EII will be wsdl11:service. It is possible that some other spec or some eventual addressing WG/TC may decide to use wsdl:service QName but with perhaps slightly different semantics/restrictions than WS-MD. In such a case the optional reference-scheme attribute comes handy. So I have a slight preference for keeping it. Thoughts? > thanx, > doug > > [1] > http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7108/reference-1.1.xsd > Action on Doug and Anish to come up with a proposal before the end of the week to resolve them. 5.5 Clarification of rm-faults without ack requested· Clarification of RM-faults without
ackRequested At last week's teleconference, it was agreed we have to clarify whether rm fault indications can be sent if the request does not include the ackRequested element. The replyPattern element is mandatory, implying that there will be behaviours which require an rm-reply, even if ackRequested is not present. The Sending RMP should be made aware when it sends request elements in a message which are badly formed This I propose we add the following sentence after the first paragraph of section 4.2.4 AckRequested " The Receiving RMP MAY publish an rm-fault indication for a reliable message, even if the AckRequested element is not present in the request element for that message. " Tom Rutt Bob F moved to add new issue and resolve with new text, Alan weisberger seconded. " The Receiving RMP MAY publish an rm-fault indication for a reliable message, even if the AckRequested element is not present in the request element for that message. " No opposition motion passes. Iwasa will publish a new edigtors draft 1.05 with the agreed changes above. 6 Discussion of Document Progression.For discussion July 6: Have agreed on resolutions to all open issues. July 7: Iwasa posts draft 1.05 with agreed resolutions July 12: all editorial comments posted on draft 1.05 July 13: Vote for CD 1.06, Vote on whether changes are substantive over .992 Potential votes on either (depending of whether changes are voted substantive): Submit to OASIS for member vote (if not substantive) Start second 30 day public review (if substantive) Bob: how did the state diagrams change. How substantive changes regard what fundamental changes are made to the state diagram. Tom: I can state we just allowed faults to be sent without ack requested. 7 Frequently Asked QuestionsOasis staff posted the faq at: http://www.oasis-open.org/committees/wsrm/faq.php OASIS Web Services Reliable Messaging TC FAQ 3.
How does the WS-Reliability protocol relate to WSDL operation types? WS-Reliability
has been designed to support One-Way and Request-Response operations. The two
following requirements are observed by WS-Reliability: • An implementation of
WS-Reliability is not supposed to be aware of the type of WSDL operation
associated with the messages it is processing. Tom:
This is old wording and needs to be fixed.
Agree that we should update this text after the next CD is approved. • The RM protocol specified is
compatible with current WS-I profiles. One-Way
operations: All specified RM features apply to these operations, with the
following restriction: in order to comply with current WS-I profiles, the
"Response" reply pattern must not be used with these operations. Members should propose changes to the list, to update the FAQ after the next CD is approved. Agreed to update the timing question when we have more information
after next week. Bob moved to adjourn, Alan seconded. No
opposition, meeting adjourned so Bob can complete his honeymoon. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]