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 4/4 teleconf

Prelim minutes are attached.

Please post corrections to list before next monday.

Tom Rutt

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

Prelim Minutes WSRM TC Conference Call –April 4, 2006


The meeting of the WSRM  TC took place by teleconference 

Time         Tuesday, 24 Jan 2006, 05:30pm to 06:30pm ET

1          Draft Agenda:

1) review agenda

2) Roll Call

3) Minutes approval

4) Action Items

5) Discussion of potential TC future activities

5.1 Reliability of Response

5.2 Delivery Assertions for Sequences

5.3 Interworking WS-Reliability and WS-Reliable Messageing

5.4 OASIS IPR Status for TC

6) New Business

2          Roll Call



First Name

Last Name






Fujitsu Limited*




Fujitsu Limited*




Fujitsu Limited*



Voting Member

Hitachi, Ltd.*



Voting Member

Hitachi, Ltd.*



Voting Member

Hitachi, Ltd.*



Voting Member

Nortel Networks Limited*



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 2/21 teleconference meeting are posted at:



Bob F moved to approve the 2/21  minutes, Paul Knight  seconded.


No opposition minutes 2/21  minutes are approved


4          Status of Action Items

2006-02-21-1 - Closed

Action: Tom will post a contribution on interworking ws-reliablity with ws rm.


2006-02-21-3 - Open

Action: Jacques will clarify what he thinks we should do on reliability of req-resp.


2006-02-21-3 - Closed

Action: Iwasa will try to find out what da levels are being used for ws reliability.


5          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

  1. work to resolve new issues raised within charter of TC,
  2. put the tc into maintenance mode (i.e., two meetings a year awaiting usage issues),
  3. schedule vote to disband TC


5.1       Reliable Request Response

Jacques posted the following contribution before the last meeting: Reliability of Request-Responses


Jacques gave an overview of the “reliable synchronous response” with respect to what it would mean for an upgrade to ws-reliability.


The minimal updated would be for guaranteed delivery of synchronous response.  The QOS def for reliabile response is different than the one for request, since failure notification does not have to happen on the side of the sender.  The proposal is that to support guranteed deliver of response, the request must be send under guaranteed delivery, and in case of failure to receive response, the request is resent.  Not receiving the response means not receivint ack of the request, since ack is piggybacked with response.  The change is that the sending or response be done with original ressponse, (buffered).  We want to avoid duplicate invocation of resend of request.  The response must be cached.


In summary: the proposal is to redefine guaranteed delivery of response so the delivery notifications are received on side that receives the response.  The other difference is behaviour of caching response on the back channel has to be tightened in the spec..  Ack of the response is an optional.  It serves two purposes, when the ack is not received it concludes that a failure has occurred.  ; also you have to take measure to make effort in resending.


Tom: but the ack of response can be used to empty the response cache.


Jacques: message expiry time can be used for this.  It might be useful to have the ack as an additional mechanism.  The ack can be lost itsef.


Jacques: duplicate delivery is covered.  However I would leave out the case for response ordering.  The QOS for ordering of response would have to be changed.


Tom: is there a need for a new signal header that reliability of response is requested.


Jacques: the signal would be in the response message, including a request header, with a piggybacked ack.


Tom: Jacques will complete action item to give a short contribution on changes needed to ws reliability to make this happen.

5.2       Delivery Assertions for Sequences

Fujitsu posted a contribution in January:


Which included the following sub- proposal:

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 (WS-RX).*


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


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


Also, 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.


Tom: does anyone support this.  Ws-reliability has definition for qos with is precise, and ws-rm does not need the definition for the protocol, they leave qos on the endpoint to be outside of protocol. 


Tom does anyone want to keep this on the agends for future work.


Jacques: it is not a simple thing to do, I think we should take it off the agenda.  There are differences, and a markup for this might lead to a more broad qos beyone these two specs.  Perhaps it would be covered by a generic policy specification scope.


Agreed to take this off future agendas.


Iwasa posted the following Email::


Here is my action item in the last telecon.


Action: Iwasa will try to find out what da levels are being use for ws reliability.


As far as I know, there are two industry groups that are implementing WS-Reliability in Japan.

Both industry groups are implementing Delivery Assurance, but neither Duplicate Elimination

nor Ordered Delivery at this point.






Tom: It seems there is no features of ws reliability being used that are not covered by WS-RM.


Jacques: is duplicate elimination being done.


Iwasa: some might not even do resending, they only notifiy of failure.

5.3       Interworking WS-Reliability and WS-Reliable Messaging

Tom R posted the following Email, outlining an Interworking unit for WS-Reliability and WS-Reliable messaging.:



Tom: I think this demonstrates how one could interwork implementations with a simple IU.


Bob: could this work for reliability of the synchronous response.


Tom: I did not put this in the first cut, but I think It could be covered once ws-reliablity and ws-rm have specified reliability of response.


I also assumed only the callback scenario in the example.


Tom: is this something for standardization, or could it be only dealt with with product space..


Jacques: perhaps some app notes could be done.


Tom: perhaps we could do an apps note on this.


Tom: can people give comments on this before the next meeting.


Tom: my opinion is that we should focus on moving to the new platform with wider acceptance.  Interworking units could help to facilitate migration from ws-reliability to ws reliable messaging.


Bob F: we should make it simple to facilitate migration, namely do not add new features which make migration more difficult.


Paul K: ws-reliability does its job and is useful.  But if we add features, we will not have something which is implementable and stable.



5.4       OASIS IPR Status of TC

Tom Rutt forwarded the following email, from Jamie Clark, as:


    * From: James Bryce Clark <jamie.clarkAToasis-open.org>

    * To: tomATcoastin.com

    * Date: Tue, 21 Feb 2006 16:04:03 -0800


     As you know, our current OASIS IPR Policy was adopted in April 2005

with a 2-year transition period, during which the OASIS TCs then existing

could choose when to convert from the old IPR Policy to the new one under

the OASIS IPR Transition Policy [1].  As we announced back in 2005 [2],

each TC has until April 2007 to select one of the new policy's three

licensing IPR Modes, and conduct the transition vote;  or cease operations

if no transition vote is successfully completed by April 2007.


    Tom, it would be helpful to know whether your TC has discussed plans to

convert.   Could you please advise back to me whether your TC has begun

considering this, and if so, roughly on what schedule?  This is an informal

inquiry:  we are asking only for current thinking, not a binding

determination or TC member poll.  The level of answer we hope for is:


     __ We haven't considered our timing yet.

     __ We are considering starting a transition roughly in ___ [calendar quarter] 2006/07

     __ We probably will close before April 2007 and not convert.


If planning has not started, OASIS standards development staff will be in

touch to discuss your TC's plans, needs and timing between now and the

OASIS Symposium in San Francisco in May.  Obviously we will be happy to assist.


Thanks for your attention and assistance.

Best regards  Jamie Clark


~   James Bryce Clark

~   Director, Standards Development, OASIS

~   jamie.clark@oasis-open.org


[1] http://www.oasis-open.org/who/ipr/ipr_transition_policy.php

[2] http://lists.oasis-open.org/archives/members/200502/msg00006.html


Tom: I propose we answer we have not considered our timing yet.

6          Future Meetings

At last meeting, TC agreed to decide on the next meeting at this meeting.


May 8 and 9, OASIS Symposium TC meetings 10 and 11.


Paul K, Jacques, will be there.


Paul K : I do not see value for a f2f at this time.


Agreed to have One hour call on 16th of May was chosen.

7          New Business



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