Preliminary Minutes of WSRM TC Conference Call –Sept 06, 2005
The meeting of the WSRM TC took place by teleconference
Time Tuesday, 06 September 2005, 05:30pm to 06:30pm ET
1
Draft Agenda:
1) review agenda
2) Roll Call
3) Minutes approval
4) Action Items
5) Discussion of TC ongoing
activities
6) Discussion of potential TC
future activities
7) Determine future meeting
schedule
8) New Business
2
Roll Call
Attendance:
|
First
Name
|
Last Name
|
Role
|
Company
|
|
Jacques
|
Durand
|
Secretary
|
Fujitsu
Limited*
|
|
Kazunori
|
Iwasa
|
Secretary
|
Fujitsu
Limited*
|
|
Tom
|
Rutt
|
TC Chair
|
Fujitsu
Limited*
|
|
Robert
|
Freund
|
Voting
Member
|
Hitachi,
Ltd.*
|
|
Eisaku
|
Nishiyama
|
Voting
Member
|
Hitachi,
Ltd.*
|
|
Nobuyuki
|
Yamamoto
|
Voting
Member
|
Hitachi,
Ltd.*
|
|
Mark
|
Peel
|
Secretary
|
Novell*
|
|
Anish
|
Karmarkar
|
Voting
Member
|
Oracle
Corporation*
|
|
Pete
|
Wenzel
|
Voting
Member
|
SeeBeyond*
|
|
Doug
|
Bunting
|
Secretary
|
Sun
Microsystems*
|
Meeting is quorate.
3
Minutes Discussion
Tom Rutt Volunteered to take minutes.
3.1
Approval of previous meeting minutes
The minutes of the 7/14 teleconference meeting are posted
at:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/13660/MinuteswsrmTC071205.htm
Bob F Moved to approve the 7/14 minutes, Mark Peel seconded.
No opposition minutes 7/14 minutes are approved
4
Status of Action Items
4.1
Action
121404-2 (Anish) Open
Action: Oracle will provide examples of soap header
dumps with both ws-reliability and ws-Security headers in use, as in the interop
demo.
Anish posted email:
WSS and WS-Reliability header dumps Anish Karmarkar 24 Feb 2005
23:22:27
Anish may post some
additional examples of other combinations. Leave open
Anish: Sumit
Gupta signed on for the AI. Leave Open.
4.1
Action
012505-1 (Tom Rutt) Pending
OASIS Staff has posted the errata cd as:
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-v1.1-errata-cd1.0.pdf
However, on the posted standard the errata index is
referenced as as:
http://www.oasis-open.org/committees/wsrm/documents/errata/1.1/index.html.
The errata Index still does not yet exist.
The action item will stay open until the errata index page
is posted.
4.2
Action 042805-1 (Jacques Durand) Closed
Action: Jacques will post a new version of the composability analysis, to reflect discussions at the F2F
meeting.
Jacques posted the new version as: Composability of Specifications: Patterns and Properties
5
Discussion of ongoing TC activities
5.1
Composability
with other WS-Specs
WS-Security Composition paper from Fujitsu, Hitachi
and NEC:
WS-Reliabilty
And WS-Security - First Draft
The latest version of composability
aspects was posted by Jacques as:
Composability of Specifications: Patterns and Properties
Tom: I will Put out another request
for comments, if none come we can take of agenda in future.
5.2
WS-RX Gap Analysis
The WS-Reliability Requirements are posted at:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/3389/WS-Reliability_Requirements-2003-09-05a.pdf
The output of a task force effort (version .8) is posted, at:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/13186/Requirements-Analysis-WS-RM_WS-Reliability-v08.pdf
Anish created a requirements
analysis (marking both ws-reliability and ws-reliable messaging against the ws-reliability
requirements document) , which was posted as:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/13168/WSReliabilityRequirementsAnalysis.html
Tom: Use to refine our own requirements document. Put out for a call for contributions on our
own Requirements.
e.g., Future added sequence creation/deletion operations to
avoid clock alignment.
Jacques: I would like to discuss an observation about
requirements, they are at different levels. Our requirements are not worded exactly. We have requirements about delivery
assurances, there also system level requirements (e.g., expect clock
alignment), and architectural requirements (protocol the same for all levels of
DA). There are both user level
requirements and vendor requirements. It
might be helpful to avoid putting all requirements in the same bag. If we do future work we should distinguish
between these different types of requirements.
6
Discussion of Potential Future TC activites
The working list of potential enhancements to WS-Reliability
was posted after the last f2f as:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/12436/wsReliabityFutureFeatures.htm
Chair’s suggestion for discussion topics
for potential TC activites.
6.1
WS-Addressing Compatibility
1.
Make WS-R compatible with WS Addressing (W3C standard for WS-A to SOAP
binding). This may require elimination of the WS-R Reply-To message
element and/or other modifications to the spec.
Tom:
one example is to clarify the wsr:replyTo
as being equivalent to wsrm:ackTo, and is orthogonal
to wsa:ReplyTo. Add some clarification about wsa:messageID in retransmission.
Tom:
this kind of stuff could be driven by vendor activity.
6.2
Reliability of Synchronous response
2.
Improve the reliability of the Synchronous Response in a new version of WS-R.
Jacques:
while EBMS has this as a need, it is an important enhancement in its own right.
Looking at guaranteed delivery:
1)
is
it worth providing guaranteed delivery on a synchronous response
2)
Handling
Ack of the response. The resending mechanism is left out of ws-reliability
3)
What
to do with lack of ack (e.g., resending mechanism may
involve buffered reply)
We
need to consider these points if we want to make an abstraction to cover this
feature.
We
may decide we do not worry about resending mechanism,
we would not have to consider this in our protocol. What are conditions under which resending
request may work.
6.3
Composition with WS-Security
3.
Composability of WS-R and WS-Security: at least set
the issues at hand (handling of faults, pipe-line processing...).
Tom:
has anyone found problems in composing ws-reliability
and ws-security.
Tom:
any future work relies on how to use security with our existing spec.
Bob
F: Oracle had an implementation up, and they had no troubles to get interop.
Tom:
Seems to be of low priority unless we do have problems.
Jacques:
while getting things to work are not an issue, there are some questions on
sending a faults in some circumstances. In a pipelined implementation the message
could be send without Use. There might
be some corner cases warranting a second look taking into consideration
security faults.
Bob
F: often it suffices to let the implementation deal with the various fault
aspects from multiple protocols.
Jacques:
there might be some which warrant discussion in the TC to reach understanding
of some fault cases.
Doug:
I would like to +1 Bob’s comment. We do
not need to get into the fatality of a particular fault condition. Resigning a message may be possible in some
cases, while not in others.
Jacques:
For example our permanent processing failure fault is described as “fatal”. Other errors talk about “failure of delivery”. We have hints of different behaviour from different implementations. Do we want to go as far as interpreting some
security faults, perhaps in the context of a single binding (mapping of faults
from one spec into a category of faults in another spec.
6.4
Harmonization of WS-R and WS-RM specs
4.
Harmonizing WS-R and WS-RMg specs resulting in a
minimum level of interoperability between the two specs.
Tom: one output of this might be a gateway mapping specification.
Doug: this sounds like an implementation concern, how one maps between two protocols.
Tom: a small mapping document between the protocol elements
could be a small job.
Tom: Some common set of features might map better to both of
these protocols.
What we are trying to achieve here depends on user
requirements.
7
Future meeting schedule
Chair Suggests October 4 as next Teleconf.
Agreed to Set up pattern of every 4
weeks, until.Nov 29
Nov 1, Nov 29
8
New Business
Bob F moved to adjourn, Anish
seconded.
Meeting adjourned. At 6:11 PM Eastern Time