Full Agenda WSRM TC Conference Call –Jan
The meeting of the WSRM TC will take place by teleconference
Tuesday, 24 Jan 2006, 05:30pm to
Toll only :
Participant code: 375491
2) Roll Call
3) Minutes approval
4) Action Items
5) Discussion of potential TC
5.1 Reliability of Response
5.2 Delivery Assertions for
6) New Business
?? Meeting was quorate.
Volunteered to take minutes.
<![endif]>Approval of previous meeting minutes
The minutes of the 11/29 teleconference meeting are posted
xx Moved to approve the 11/29
minutes, yy seconded.
?o opposition minutes 11/29 minutes
<![endif]>Status of Action Items
<![if !supportLists]>4.1 <![endif]>Action
012505-1 (Tom Rutt) Pending
OASIS Staff has posted the errata cd as:
However, on the posted standard the errata index is
referenced as as:
The errata Index still does not yet exist.
The action item will stay open until the errata index page
<![endif]>Discussion of Potential Future TC activites
The working list of potential enhancements to WS-Reliability
was posted after the last f2f as:
TC needs to decide among the following possibilities
to resolve new issues raised within charter of TC,
the tc into maintenance mode (i.e., two meetings
a year awaiting usage issues),
vote to disband TC
Insert of Late email posting from Fujitsu for discussion::
propose 2 important work items for the WSRM TC going forward and one bonus
1. Clarify and unambiguously define the reliability
of the response message.
should not assume that this is equivalent to the reliability of the request
message, but should define it separately and independently. We propose to
include this in WS-R 1.2 - a small incremental addition to the existing spec.
While the reliability of the response should be defined in
different terms than the reliability of the request (see proposal), it should not have a major impact on WS-R 1.1 standard or
implementations. If the WS-R 1.1 implementation supports the option to cache the
response and resend it, then all the functionality to support reliability of a
synchronous response message is already present.
-->The WS-R specification should make that clear by defining the criteria
for the reliability of the response message.
2. Develop a high level specification for
delivery assurance/QoS of a reliable message. We need to define the notion of reliable
message delivery assurance in the context of QoS
by describing the precise semantics (but not the syntax or protocol). The standardization of the expression of delivery assurance could be
used to support either WS-R or WS-RMg
believe that a "mark-up" of the standard representation of delivery
assurance would be very valuable for the WS industry and would be more
expediently developed, generated and approved in the WSRM TC (vs WSRX TC) due to its proposed sharper focus.
example, we recommend distinguishing between an acknowledgement from the
receiving RMg entity (e.g. in WS-RX spec) vs an acknowledgement that confirms that the layer
above the receiving RMg entity (perhaps a WS
control protocol or application layer) has correctly received
the message from the RMg entity.
there may be different notions of the various forms of reliable message delivery:
at least once, atmost once (AKA duplicate
elimination), guaranteed delivery, sequential delivery, etc. What do
these notions really mean to the layer above? They need to be precisely
defined and illustrated.
keeping the WSRM TC actively engaged by working on these two subjects, we also
reserve one or more placeholder work items that could be initiated when other
Web Services specs are more mature and able to be used with WS-R:
minimal level of interoperability between WS-R and WS-RMg.
For example, defining a common set of functionality or lowest common
denominator between the two specs and a corresponding (run time) syntax
translation mechanism for equivalent message types.
WS-R with WS-Addressing (for the SOAP binding case).
-Composability with other specs TBD (i.e. WS Resource
Framework or WS-Notification family of standards)
with ebXML version 3, which currently references WS-R.
<![endif]>Reliable Request Response
Jacques posted the following contribution
<![endif]>Delivery Assertions for Sequences
The following is a chair proposal for discussion:
The OASIS WS-RX TC is working on a
protocol which supports all the reliability Qos
Features from WS-Reliability, but has no mechanism for associating DA levels with
sequences on endpoints.
This TC, as a migration
specification, could specify extensions to allow ws-reliability
compatible association of DA levels with individual ws-Reliable
messaging protocol sequences.
Before undertaking such a task, the
TC could conduct a Survey of WS-Reliability implementers and Users to determine
the importance of associating DA levels with individual reliability sequences.
At last meeting, TC agreed to decide on the next meeting at this