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 10/04 teleconf

Prelim minutes are attached.

Please post corrections to the list by the end of this week.

Tom Rutt

Next meeting Nov 1

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 WSRM TC Conference Call –October 04, 2005


The meeting of the WSRM  TC will take place by teleconference 

Time         Tuesday, 4 October 2005, 05:30pm to 06:30pm ET

Description            Host: Fujitsu

Toll only : 1-512-225-3050

Participant code: 375491


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 

8) New Business

2       Roll Call



First Name

Last Name






Fujitsu Limited*



TC Chair

Fujitsu Limited*



Voting Member

Hitachi, Ltd.*



Voting Member

Hitachi, Ltd.*



Voting Member

Hitachi, Ltd.*



Voting Member

NEC Corporation*



Voting Member

Nortel Networks Limited*







Voting Member

Oracle Corporation*



Voting Member





Sun Microsystems*




Meeting was quorate.


3       Minutes Discussion


Tom Rutt Volunteered to take minutes.


3.1    Approval of previous meeting minutes


The minutes of the 9/06 teleconference meeting are posted at:




JAQUEST Moved to approve the 9/06  minutes, Alan.  seconded.


No opposition minutes 9/06   minutes are approved


4       Status of Action Items

4.1    Action 121404-2 (Anish) Closed

 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


No additional header dumps available.

4.2    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.


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  


Pass for no contributions

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:



Nothing posted on reliability requirements.


Tom: We may want to focus on reliability of request response.


Bob F: what is the benefit that we could extract from supporting WSDL request response would be.


Jacques: this is a valid question.   Depending on underlying protocol you may get extra reliability value.  If we only assume soap request/response mep I do not think we can always assume the binding may give reliability.  Acknowledgement of Response has been asked for.  As long as the notice of failure is received they can resend request.   The party sending the message wants to be notified in case it was not received.  Some people see value in having response acknowledged.


Bob F: I an application reply was made thru a reliable mechanism it would accomplish this.  Both could act as servers for reliabile


Tom: The issue is how to get wsdl request response on two asynch soap.


Bob F: ws Addressing is discussion how to define a back channel.


Tom: are one ways in each direction good enough, or do we need to actually support reliability in response for wsdl request/response.


Jacques: if response may fail, the behaviour is different than the resending of the request.  


Bob F: If the response comes in the same back channel, but is not received by the requestor. Then in this case the request will be resent.


Jacques: The request has to be reliabile,  For the response we can piggyback an ack with response.


Bob F: that opportunity exists for one ways, but if it is on the same connection, the thing that concerns me is on ack of the ack.  There is no request, response, ack mep.


Bob F: do you need to create a new connection to acknowledge the response.


Jacques: the ack of the response could be done in a callback way.


Tom : is the key issue wsdl request response.



Jacques; it is more like a soap request/response MEP.  I can make a short summary about issues and how we can cope with this.


Bob F: If a request response were done with a message to toggle thing in destination, if resent it should be a duplicate, but resending would continue.. 


Jacques: in WS reliability there is fuzzyness about duplicate request is received and eliminated, what is sent back in that case.  Cached responses are allowed, but this is not required.  We are almost there, except for ack of response.


Tom R: One can use callback for reliability of the response.


Jacques; beside reability to resend response, we are almost there.


Action: Jacques to provide summary on issue of reliable request response.

6       Discussion of Potential Future TC activites

The working list of potential enhancements to WS-Reliability was posted after the last f2f as:



Wait for Jacques summary on this.


7       New Business

Next meetings, Nov 1, 2005, Nov 29, 2005.


Bob F moved to adjourn to Nov 1  alan Seconded.


Meeting adjourned at 6:00 PM Eastern Time.


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