Prelim Minutes WSRM TC Conference Call –
Feb
10, 2004
The meeting of the WSRM TC took place by teleconference
Tuesday Feb 10 2004, from 5:30 to 6:45 PM Eastern Standard Time
(UTC - 5)
0
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 – http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5406/MinutesWSRMTC020304.htm
3 Discussion of New Orleans Meeting and
Conference papers
4 Discussions of Issues
Agenda approved
1
Roll
Call
Attendance:
Meeting
was quorate.
2
Minutes
Discussion
2.1 Appointment
of Minute Taker
Tom Rutt will take
minutes.
Doug will record issue resolutions.
2.2 Approval
of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5406/MinutesWSRMTC020304.htm
Jeff moved to accept the Feb minutes. Sunil seconded.
No opposition, 2/4 minutes approved.
Alan sent the following to be included in this
week’s minutes as a clarification of last week’s minutes, since it was not properly
recorded in the minutes of last week.
New issue:
Ack and Fault Response
Sunil, who had sent mail on this topic, stated
that it needs to become a (new) formal issue.
The problem: If a Fault message is
sent, we don't know the message associated with the fault if multiple messages
are outstanding (i.e. unacknowledged).
We need to look at a combination of Fault element and a Response element
together. Proposed solution is to add a
"message type field" in the Response message header, which would
distinguish the Response as being either an ACK or a Fault response.
Alan suggested another solution: Simply add a
message ID field to the Fault message header.
This was rejected by the group, because SOAP 1.2 does not permit Fault
messages to contain a message ID field.
Doug then stated, "I am confused by the
flurry of emails on this topic (between Iwasa and
Sunil). We previously got rid of message
type, because we had a fair number of cases with requests and responses
combined in same message. Now we want to
add it back again, reversing our early decision to remove it? It is not currently clear what the spec
implies."
Sunil replied that without this (the message
type in the Response header), it copmplicates things
further...
*
Hence, we could not resolve this issue, and are leaving it open
for now- subject to more emails on the reflector.
Alan Weissberger
3
Discussion of New Orleans Meeting and Conference
Tom stated he told the OASIS staff that we
wanted to meet all day Wednesday, and Thursday morning for our F2F. As soon as this is verified, Tom will send a
message on the email list so people can confirm their plans.
Jacques sent proposal in.
Jacques stated he found a hotel that is
cheaper. Baronne plaza.
4
Discussion of remaining Action Items from F2F
meeting
4.1 Message
ID text
Iwasa
needs to reflect the changes requested by Tom and Sunil
http://www.oasis-open.org/archives/wsrm/200402/msg00038.html
http://www.oasis-open.org/archives/wsrm/200402/msg00047.html
5
Discussion
of Issues
5.1 Issue
49 WSDL Annotation
Defer Issue 49 discussion to next week. Oracle needs time to prepare a fully enabling
proposal for discussion
5.2 Rel 114 - Ack and Fault Response
Contents
Sunil
summarized the current proposal.
He
send an email to justify the proposal. Their implementation people feel it is
important.
Attribute,
for response type, with two values ack and fault,
defaulting to Ack.
Tony,
need to consider Soap 1.2 case before coming too strongly.
Tom
We did agree.
With
poll reply pattern, there is no way to get a fault back.
Doug:
how do you get back errors. Suppose message 4 is malformed, and the poll
reply is in use one does not know why.
Sunil:
We decided before that all a poll delivers is knowledge is that the message is
not received. There is no way to get the
reason.
Doug:
I am not sure from a business prospective that it is required that the poll
reply pattern is fully functional. At
the moment it is missing some necessary features to be fully functional.
Open
a new issue, Functionality of poll reply pattern. Issue 115. Discuss on email.
Tony
graham will start discussion on email.
Name
would be Type, Default value would be ack.
Tony:
I would rather Defer the resolution to next week.
Agree:
To keep the issues open.
<Chair’s Note> I now think, after reviewing the
minutes that this is what issue 108 was supposed to be addressing. We need to
work on both 108 and 115 resolution together.
5.3
Rel 108 Clarify
semantics of polling
The
following text is quoted from the f2f Minutes: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5166/Minutes-Jan04f2f-b.htm
While
a PollRequest can request acknowledgment of a messages with a range of sequence number values, it is
not clear what happens when one or more of the messages in that range caused
faults.
Consider,
for example, a sequence of messages with the same
GroupId and
sequence numbers 0 to 4 sent using the Poll reply pattern. If message 1 fails with an InvalidMessageHeader fault and message 3 fails with an InvalidRequest fault, what is the expected response for a PollRequest element containing <SequenceNumberRange
from="0" to="4"/>?
ADD
NEW ISSUE: Clarify semantics of polling In particular there needs to be
clarification that the poll reply only includes references to messages which
were delivered.
Several
members stated that this has already been resolved with clarifications in the
current editor’s draft.
The
document still needs to add some clarifications about using poll.
Agreed to leave rel 108 open for now.
5.4
Rel 76 – Meet R7.3 for
general query mechanism of delivery
The
TC agreed at the f2f (and it is recorded in the issues list) to a clarification
that a Poll may be done for messages which were send by other reply
patterns. The following is quoted from
the f2f minutes and is also recorded in the issue resolution for Rel 76:
14.15
REL-76 Meet
Realization, R7.3 requirement
Description:
Spec must support ability of sender to ask the receiver if one or more of its
sent messages have been received. (see also issue
REL-43)
The
Specification must define a solution for sender to receive delayed Acks, when it is not willing to receive underlying protocol
requests, for one-way MEP. (see also issue REL-19)
Proposal: Close as accommodated by WS-Reliability spec,
since Polling reply pattern can be used to meet this requirement. However, the spec does not yet support a
general query for messages not sent using the poll reply pattern.
Add
text to poll element in section 3.3 that states
“
In
addition to its use for receiving replies for requests using the poll RM-Reply
pattern, a Sending RMP may use it as a general query to determine non-expired
messages which have been delivered.
If
a Receving RMP does not support this general query,
it MAY return a notSupportedFeature fault.
“
Resolution:
Close by adding new text above.
This
text has not yet been added to the document.
Iwasa needs to reflect this resolution it in
the document.
Also,
the following definition, in section 1.7, needs to have its last sentence removed
*PollRequest Message:*
A polling message for Acknowledgment message(s). This is used for Poll binding
pattern only.
5.5
Rel 106 Group
termination after delivery
Description:
Should
a reciever only update group termination value for
messages which are delivered?
Tom
Rutt sent email http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200402/msg00046.html
with the following proposal:
The
sender is only sure that a request was received when it gets the ack from the Receiving RMP.
It
might slightly increase the degree of synchronization of the Sending RMP's knowledge of the Group termination parameters in use by
the Receiving RMP, if the Receiving RMP only updates its group termination
parameter values after it has sent an acknowledgement to a message which
contains new parameter values sent by the sending RMP. However, such protocol behaviour
adds complexity to the protocol.
It
is much simpler to have the receiver update the group termination parameters it
uses as soon as it receives a new value from the sender. This will ensure that the sender's desires
are reflected as soon as possible in the receiver's protocol behaviour. Since we
are sending the group termination parameter with every request, the receiver's
knowledge of the sender's intent will be reflected back to the sender on an ack to a subsequent message to one that is lost..
Thus
I recommend we answer the question as no for the specification, and close the
issue with no change to the text..
Tom
Rutt moves we close 106 with no change. Jacques seconds.
No
opposition. Motion Passes.
5.6
102 Message persistence at receiver
Current
2.6 text:
“
With Reliable Messaging, the sender is REQUIRED
to persist the message until one of the following conditions are
met:
• Receipt of an Acknowledgment message from receiver, indicating the
message has been successfully delivered.
• All retry attempts have failed, and a delivery failure is reported to
the application layer.
• The span of time indicated by the ExpiryTime
element has expired.
The receiver MUST persist
out of order messages to support Guaranteed Message Ordering.
The receiver MUST persist
the Message Identifier to support Duplicate Elimination. Both sender
and receiver MUST behave as if there was no system
failure or system down after recovery.
“
Doug: the first phrase “with reliable messaging” is
incorrect. The existing text is
requiring too much.
Jacques:
I agree with Doug. Perhaps we do not
need to mention persistence requirements. There is no other way to implement.
Jacques
agreed to send his position on how to fix 2.7 to the list. Jacques will make a case to minimize the
statements.
Action:
Jacques to initiate email discussion.
Leave
issue open.
5.7
Rel 110 and 111 Fault
cleanup and resource limitation fault
Agreed
they are Completed.
Let
people review during two week period.
5.8
Rel 112 – Group termination semantics clarification.
Agreed
this is completed
Jacques gave text to Iwasa which is in
the spec..
Let
people review before we close.
5.9
Rel 113 Message Delivery processing after Fault.
Jacques:
this point Needs discussion on the list.
Jacques
volunteered to initiate discussion on the list.
Jacques:
In case some feature is not supported, (exactly once delivery). In case duplicate elimination is not
supported, but guaranteed is supported.
What should we do in this case. It is not a problem to deliver this message, but
sending an indication.
Tom:
do you mean an ack and a fault for the same message.
Jacques:
this could have an implication on Sunil’s indication.
Sunil:
this is complicating proposal. We do not know which succeeded which fails. This can have two response elements.
Jacques:
these are related.
Action:
Jacques will send an email do start discussion. Delivered with fault might be for
non-supported features.
Leave
open
5.10Rel
69 –
Agreed
it should have been closed.
5.11Rel
25 Compatibility
Jeff
will investigate with other oracle people to determine if we have any
compatibility problems with Ws-security, and report back to us.
Jeff:
it might be better to actually state how to use WS-Reliability with WS-Security.
Jeff
will report back to the TC after this investication..
Agreed to leave Open.
6
Initiation of two week TC review
Tom: We agreed at F2F in January, that now is the right time to have people go thru document for review.
Doug: At F2F some members requested the document not change
during this period. Doug would rather not make further changes so we can
compile the list of concerns, leading up to the meeting.
Meeting agreed we should have no changes to the editor’s
draft during the two week review. We
will freeze the editor’s draft for two weeks.
It was agreed that Iwasa will post
an editor’s draft, correcting the editorial problems identified in these
minutes by Wed Evening.
All TC members are encouraged to do a comprehensive review
of the document, and send detailed comments to the list.
The comments should indicate the section number, to facilitate
the chair collating the comments for discussion at the meetings.
During the review period, it was agreed to freeze the
document. Any further issue resolutions
during this two week period will be reflected in the issues list, but we agreed
to wait until the resolution of the review comments before being incorporated
into a future version of the spec.
The
meeting adjourned at 6:45 PM Eastern
Standard Time.