OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Prelim Minutes of WSRM TC 9/6/ teleconf

Prelim minutes are attached.
Please post any required corrections by the end of this week.
Tom Rutt
WSRM TC  Chair.

Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: Full Agenda for WSRM TC Conference Call –June 14, 2005

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



First Name

Last Name






Fujitsu Limited*




Fujitsu Limited*



TC Chair

Fujitsu Limited*



Voting Member

Hitachi, Ltd.*



Voting Member

Hitachi, Ltd.*



Voting Member

Hitachi, Ltd.*







Voting Member

Oracle Corporation*



Voting Member





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:



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:


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 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:



The output of a task force effort (version .8) is posted,  at



Anish created a requirements analysis (marking both ws-reliability and ws-reliable messaging against the ws-reliability requirements document) , which was posted as:




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:



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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]