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: Second Full agenda for 1/24 Teleconf

I just inserted the new discussion item from Jacques and Alan 
Weissberger into the full agenda, for discussion.

The new full agenda is attached.

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

Full Agenda WSRM TC Conference Call –Jan 24, 2006


The meeting of the WSRM  TC will take place by teleconference 

Time         Tuesday, 24 Jan 2006, 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 potential TC future activities

5.1 Reliability of Response

5.2 Delivery Assertions for Sequences

6) New Business

2          Roll Call



?? Meeting was quorate.


3          Minutes Discussion


Tom Rutt Volunteered to take minutes.


3.1       Approval of previous meeting minutes


The minutes of the 11/29 teleconference meeting are posted at:



xx Moved to approve the 11/29  minutes, yy  seconded.


?o opposition minutes 11/29  minutes ?? approved


4          Status of Action Items

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.


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



Insert of Late email posting from Fujitsu for discussion::

We propose 2 important work items for the WSRM TC going forward and one bonus benefit:


1.  Clarify and unambiguously define the reliability of the response message. 


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


Side benefit:


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


-Defining a 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.


-Composing 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)


-Consistency with ebXML version 3, which currently references WS-R.


5.1       Reliable Request Response

Jacques posted the following contribution


Groups - Reliability of Request-Responses (Reliable-Req-Resp-contribution.doc) uploaded

Jacques Durand

19 Jan 2006 21:30:33



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


6          Future Meetings

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

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