[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary agenda for WSRM TC meeting 7/6/04
There are proposals to resolve all remaining issues in this proposed agenda. Please review these proposals, and send your detailed comments with proposed changes to the list before the Tuesday evening teleconfence. 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
|
Full Agenda of WSRM TC Conference Call – The meeting of the WSRM TC will take 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 ?? 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 June 22 teleconf are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7555/MinutesWSRMTC062904.htm 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 · 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 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. “ 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 > 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 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 6 Discussion of Document Progression.For discussion July 6: agree on resolutions to all open issues. July 8: 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 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) 1 Frequently Asked QuestionsOasis staff posted the faq at: http://www.oasis-open.org/committees/wsrm/faq.php Members should propose changes to the list, to update the FAQ after the next CD is approved. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]