Full Agenda WSRM TC Conference Call –
Jan 27, 2004
The meeting of the WSRM TC took place by teleconference
Tuesday Jan 06 2004, from 5:30 to 6:30 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/5166/Minutes-Jan04f2f-b.htm
3
Discussion of New Orleans Meeting and Conference papers
4
Discussion of Action Items - http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5090/Action%20Item%20List%20from%20Jan%20Face%20To%20Face%20Meeting.htm
5
Discussions of Issues Agenda approves
1
Roll
Call
Meeting was quorate.
2
Minutes
Discussion
2.1 Appointment
of Minute Taker
Tom Rutt will take
minutes.
??? agreed to serve for issue resolutions.
2.2 Approval
of previous meeting minutes
xx moved to accept the Jan f2f minutes. Zzz seconded.
?? opposition, f2f minutes approved.
3
Discussion of New Orleans Meeting and Conference
Tom Rutt
received the following mail from Oasis Staff:
Hello
Chairs,
This
is the preliminary schedule that we have for TC meetings in New
Orleans. As you can imagine, we need to guarantee a
quantity of sleeping
rooms in order to get the meeting room space at no charge,
so it's important
that I get a final commitment. Please confirm the number of
TC members that
have booked their rooms and please confirm the meeting times
for your TC. I
can not confirm meeting rooms until reservations are made.
Also, please let
me know if you need 1/2 day instead of full day, plan to
meet from
8:00am-12:00pm or 1:00-5:00pm. Thank you for your
prompt reply.
Regards,
Dee
Small
Room One
Wednesday
- OASIS Board
Thursday
- OASIS Board
Small
Room Two
Wednesday
- OASIS WS Reliable Messaging TC
Thursday
- OASIS WS Reliable Messaging TC
Large
Room Three
Wednesday
- OASIS Legal XML Member Section Electronic Court Filing Technical
Committee
Thursday
- OASIS Legal XML Member Section Electronic Court Filing Technical
Committee
Large
Room Four
Wednesday
- OASIS ebXML Registry TC
Thursday
- WS-CAF TC
Small
Room Five
Wednesday
- OASIS XDI TC
Thursday
- OASIS Emergency Management TC
Small
Room Six
Wednesday
- OASIS ebXML CPPA
Thursday
- OASIS CAM TC
Small
Room Seven
Wednesday
- OASIS ebXML Messaging TC
Thursday
- OASIS ebXML Messaging TC
4
Discussion of Action Item Status from Jan F2F
meeting
Action Item List Status
- from Jan Face To Face Meeting
01/27/04
1.
ACTION: Need to ensure faults in general being Cleaned up Sunil will try to
get a proposal to clean up fault text before the end of the F2f.. - DONE
2.
Action: Iwasa to apply
changes for reo 44, then we will change status after
done.
3.
Action: Iwasa is to
produce a change barred version of all the changes made from the 1-06 document. Use compare documents under Edit to do it.
4.
ACTION: Sunil took action to come up with additions to the
model text for section 2.1 by Friday. – Done Suni
updated section 2 for polling
5.
ACTION: Jacques will make a proposal to fix these group
semantic concerns. Done, sent proposed updated wording to Iwasa,
which he has consolidated in last spec draft. See section 2.2 ("Groups of
messages and message identity").
6.
ACTION: Iwasa needs to
remove the sentence on the description of invalidExipiryTime
stating it is sent when the message expires.
7.
ACTION: Iwasa has to
factor in the new syntax for the message Id schema in section 3.3. The sections need to be rearranged since some
items have been changed from elements to attributes., and some of the names
have changed
8.
ACTION: Sunil will provide text to include in the
specification for what is not covered by existing protocol for request/response
support. – done, see AI 9
9.
ACTION: Sunil will put a statement in a note
regarding reply pattern for one-way wsdl operations,
to add to the operation/replypattern table.
Section 2.9
This specification supports Reliable
Messaging capabilities for WSDL 1.1 [WSDL 1.1] One-way and Request-response
operation types only. While a Request-reponse
operation can use any of the three RM-Reply patterns to receive acknowledgments
or faults, an One-way operation can only use either
Callback or Poll RM-Reply pattern. See the table below for a complete support
matrix:
<insert
chart 1>
Insert another foot note for Supported items
for R-R operation under Callback and Poll patterns.
For that footnote, description should be:
While the specification doesn’t prohibit using Callback or Poll RM-Reply
patterns to receive acknowledgments or
faults for a Request-response operation, it is encouraged to use
Response RM-Reply pattern for such operations as the acknowledgment or the
fault can be sent on the same response itself thus saving extra round trips.
10. ACTION:
Iwasa will change MAY OPTIONAL for parameters to use
cardinality instead, for the entire document.
11. ACTION: Sunil will provide a
complete spec of the wsdl extension feature before we
decided on the resolution.
Done. Sent an email on Jan 20th.
http://www.oasis-open.org/archives/wsrm/200401/msg00079.html
-One change there after. Add the usage attribute with 2
different values (optional and required) on all the 3 elements.
12. ACTION; Sunil will
incorporate the processing faults into his fault proposal for review on Friday
morning. – done see AI 14
13. ACTION:
Iwasa to change, in the first sentence of definition
of guranteed delivery to: “A message submitted to the
sending rmp with guaranteed delivery requested, will
either be delivered by the receiving rmp, or the
sending rmp will notify the submitter of failure. “
14. ACTION:
Sunil will provide a new section 4,
Done. Sent an email on Jan 20th. http://www.oasis-open.org/archives/wsrm/200401/msg00078.html
15. Action:
Iwasa to add sentence: This element has cardinality
zero or 1 in the rm-request message.
16. ACTION:
Iwasa to add explanation for the table rows in
Section 3: e.g., for cardinality: “cardinality is a constraint on the number of
instances of an item type which may be present in an enclosing item.”
17. Action:
Iwasa will finish updating section 3 to fully reflect
the syntax changes for message references.
18. Action: Sunil will update
the schema. – done
Uploaded the schema
(http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5057/ws-reliability-2004-01-16a.xsd)
- Fixed a typo there after. Element name under MessageId
should have been SequenceNum and not SequenceNumbe
19. ACTION :Sunil will come up with text to resolve this issue
on clarification of Poll semantics..
I’d like to propose that we add a new sub-section under
Section 2 to explain in detail the Poll semantics and usage.
Section 2.X Poll Reply Pattern Semantics and Usage
Guaranteed Delivery will be most commonly used for a
one-way message as the Sender know the status of the
message delivery otherwise.
So the most common use case would be to use AckRequested with Callback RM-Reply pattern so that the
Sender can receive the acknowledgement or a fault on a listener at its end.
However this pattern doesn’t help when the Sender is within a firewall, as one
cannot receive requests without opening a firewall, thus causing security
lapses.
An alternate solution would be for the Sender to ask the Receiver for the
receiving status of the message it has sent earlier on a different
channel. Such a pattern is called the poll RM-Reply pattern. The Sender sends a
Poll request for a message it would like to inquire and the
Receiver sends a Poll response with the acknowledgement. The Sender can also batch multiple Poll
requests for an efficient use. Receiver in such case will send
acknowledgements for those messages it has received. If a Poll request is
partially or completely invalid or wrong, then
the Receiver sends either a InvalidPollRequest
or InvalidMessageId Fault back.
Also, a RM Poll response MUST NOT be piggybacked
on a different RM Poll request.
20. ACTION:
Iwasa will add sub-section to section 3 for Fault
element.
21. ACTION: Sunil will update to
have the soap 1.2 mapping of ws-reliability will not
use the rm:fault element, but
instead will use the soap 1.2 Subcode element. Done
Done. I’ve mentioned in the Section 4.0 of my write-up. Iwasa need to add this in Section 3 when describing the
Fault element.
22. ACTION:
Iwasa will put soap 1.2 statement in the new section
in 3 on rm:fault element.
23. ACTION: Sunil will
incorporate amended fault proposal into the Schema and into the new text for
section 4. Done see AI 14
24. ACTION:
Iwasa will update section 3 to accommodate the new
fault proposal
25. ACTION: Sunil add text that
a response to a poll may not coexist with a rm:request header.
Done see AI 19
26. ACTION:
Iwasa make the changes requested by Jacques for
section 2 lead in.
27. ACTION: Jacques will add
clarification of sender/receiver synch of termination criteria for his homework on clarifying
group termination. Done, provided to Iwasa as an
updated draft, where the Group termination section has been significantly
reworded.
28. ACTION:
Iwasa will start working on new examples.
29. Action:
Editors will produce up to date issues list by the next meeting.
5
Discussion
of Issues