Prelim Minutes WSRM TC Conference Call –
Feb
17, 2004
The meeting of the WSRM TC took place by teleconference
Tuesday Feb 17 2004, from 5:30 to 6:45 PM Eastern Standard Time
(UTC - 5)
Conference call Dial-in number : Toll number (only): 1-512-225-3050 Participant code: 89772
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.
??? will record issue resolutions.
2.2 Approval
of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5479/MinutesWSRMTC021004.htm
xxx moved to accept the Feb 10 minutes. yyy seconded.
?? opposition, 2/10 minutes approved.
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. This has been verified.
The chair of the EBMS TC has contacted Tom Rutt, and requested some time for a joint meeting of the
two groups.
The schedule is now:
Small Room 1--Audubon (holds 18)
Wednesday -
OASIS XACML TC (10 participants)
Thursday -
OASIS XACML TC (10 participants)
Large Room 2--Balcony I (holds 30)
Wednesday -
OASIS WSRM TC (10 participants)
Thursday -
OASIS WSRM TC 8:00AM-12:00PM
OASIS ebXML IIC TC 1:00PM-5:00PM
Large Room 3--Balcony L (holds 30)
Wednesday -
OASIS LegalXML Electronic Court Filing TC (13
participants)
OASIS LegalXML
Electronic Court Filing TC--Evening reception
Thursday -
OASIS LegalXML Electronic Court Filing TC and OASIS LegalXML
Integrated Justice TC (30 participants)
Large Room 4--Balcony M (holds 30)
Wednesday - OASIS
Emergency Mgmt TC (15 participants) 8:00AM-12:00PM
OASIS
ebXML Registry TC (6 participants) 1:00PM-5:00PM
Thursday - OASIS
ebXML Registry TC (6 participants)
Small Room 5--Beauregard (holds 18)
Wednesday - OASIS
Li-XML TC (5 participants) 8:00AM-12:00PM
OASIS
ebXML CPPA (? participants) 1:00PM-5:00PM
Thursday - OASIS
CAM TC (? participants)
Large Room 6--Balcony N (holds 30)
Wednesday - OASIS
WS-CAF TC (15-20 participants)
Thursday - OASIS
WS-CAF TC (15-20 participants)
Small Room 7--Jackson (holds 18)
Wednesday - OASIS ebXML
Messaging TC (10-12 participants)
Thursday - OASIS ebXML
Messaging TC (10-12 participants)
Suite ONE
Wednesday - OASIS Board (12 participants)
Thursday - OASIS
Board (12 participants) 8:00AM-12:00PM
Suite TWO
Wednesday - OASIS XDI TC (12 participants)
Thursday - OASIS
WSDM TC (? participants)
***Wait List; OASIS XDI TC (needs another day),
OASIS ebXML BP TC ((?
participants), OASIS
Legislative TC (10-12 participants), FWSI (10-12
participants) need
phone***
4
Discussion
of Issues
4.1 Rel 108/115 Semantics of Polling and Fault Returns
Mail from Tom Rutt:
I
propose that we resolve rel 108 and 115 with the following resolution:
a)
accept the unified response schema (eliminating the
fault element) posted at:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5496/ws-reliability-uniresponseOpt.xml
The
Idea is simple, one element returned per group being reported.
That
element has a groupID attribute, and one or more
lists.
a)
a list of sequence numbers to report messages in that
group which have been delivered.
b)
for each fault code which has been encountered for
messages in that group, an element which has the fault code and a list of
sequence numbers which faulted due to that code. This proposed schema does not include fault
detail info, however that could go into the fault detail element if so
warranted.
The
following restrictions are to be applied:
1)
for response reply pattern, only one ack or only one fault can be reported in the response.
2)
for callback reply pattern, acks
may be batched, but only one fault can be reported in the callback. (this is to use the underlying fault
mechanisms for timely repoting of
fault conditions via callback).
3)
for poll requests (on messages send using any reply patternt), both acks and faults
must be batched in the poll response.
Tom
Rutt
4.2 Rel 114 - Ack and Fault Response
Contents
Would be accommodated by
proposal for Rel 108/115
4.3
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.
“
Proposal from Jacques
email:
Rel-102 (Persistence requirements):
Overall proposal:
just
remove the section 2.7, because it is redundant with what RM features require.
I.e. when implementing most of these features, persistence will automatically appear
as necessary. It is an implementation aspect.
In addition, some persistence requirements
may actually NOT be necessary to satisfy some RM requirements, i.e. are
encroaching on implementation choices.
Details:
<JD>
- the Sender side has to be able to resend the same message
(retry). We don't need to state more than that.
How is that achieved, is an implementation
decision. Some form of persistence is likely to be needed, but after all there
may be alternatives that we should not preclude (e.g. the RMP fetching messages
to be resent, from an external store...)
- Receiver side: same proposal:
persistence is implied by the RM features. In addition, here again the current
proposal in the Feb 4 issue list, will unnecessarily restrict implementation
choices.
</JD>
The current proposal:
"When supporting Guaranteed Message Ordering, the receiver is
REQUIRED to persist out of order messages until one of the following conditions
are met:
* Receipt of all previous messages and successful invocation of
the deliver operation.
* The span of time indicated by the ExpiryTime
element has expired.
<JD> The first bullet is a repeat
from the definition of Ordering, along with a way to implement
it (persist messages). The second bullet is also a consequence of our
definition of
Expiry time, obvious to an implementor.
Finally, the REQUIRED above is too strong:
memory constraints can also limit the persistence of such sequences.
Finally, there are other ways to implement
ordering, by relying on the persistence of the Sender instead of the Receiver: As Jun
mentioned, there is a way to implement Ordering without persisting any pending
out-of-order sequence, e.g. just by relying on the resending window to get
messages in the right order. This may not allow long out-of-order sequences,
but this is an implementor's discretion to decide how
much can be stored based on physical constraints.</JD>
When supporting Duplicate Elimination, the
receiver is REQUIRED to persist the Message Identifier until one of the
following conditions are met:
* The span of time indicated by the ExpiryTime
element has expired
* anything else?.
<JD> again, this is implied by the
definition of Duplicate Elimination, and the definition of Expirytime.
We might as well make this a more explicit and abstract
requirement of Duplicate elimination: "when D.E. is required,
the receiver RMP MUST check
duplicates over all previous non-expired messages." Plus, this persistence
requirement is somehow
confusing, as for groups we don't need to actually persist every ID but just
remember intervals of seq nums.</JD>
4.4
Rel 113 Message Delivery processing after Fault.
Jacques sent the following mail, which includes a dialog
with Sunil:
Sunil:
Case 1- a
message requires an Ack, yet the receiver does not
implement this feature.
Should the
Receiver drop the message and just send back the Fault? Why not deliver the
message?
It all should depend on the mustUnderstand (mU) attribute. If
the mU=1, and the
receiver doesn't understand it, then it MUST generate a Fault and message
should
not be delivered.
[Jacques Durand] I realize that we always generate
a SOAP fault for every RM fault header element (should we make that more
explicit in spec). If that is teh case then yes,
although the decision how to interpret "understand" being the RMP
decision, the level of processing done to the message before deciding of a
fault could include delivery to upper layer if we wanted.
In any
case, I agree now we should not "RMP-deliver" on a fault...
If mU=0, then if the receiver understands it,
then it will deliver and send an Ack. back
and if if the receiver doesn't understand it,
it MUST still deliver the message.
[Jacques Durand] I believe we always require mU=1 for RM headers, so that case should not occur? If
"does not understand" means an RM failure, we would not deliver I
guess - I think you talk about the SOAP node "delivery" ,
not RMP delivery.
Jacques
Tom Rutt also sent the following
email related to this issue:
It has been pointed out that the
spec needs to be clarified regarding the affect of a faulted message on the processing
of messages in a group.
Text needs to be added to section 4
on the affect of a fault on guranteed delivery,
duplicate elimination and ordered delivery processing by both the sending and
Receiving RMP.
Perhaps some of the statements in
Section 3 need to be qualified as to pertaining to delivered messages only.
Tom Rutt.
4.5
New issue on elimination of Message Header on
Replies
Tom Sent out the following email:
I propose to resolve the new issue
on elimination of message header on reply with the following proposal:
Add a ReplyPattern attribute to the response
header. For a reply to the request reply pattern it must have value
request, for a callback reply pattern it must carry value callback, and any
response to a poll request must carry the value poll.
Add protocol statement that rm-reply messages (that
are not themselves carrying reliable message request) do not
send the request header.
Tom Rutt
4.6
Issue 49 WSDL Annotation
No
discussion on Email list, recommend we defer until proposal in front of us.