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 1/25 wsrm TC teleconf

The prelim minutes are attached,.

Please post requried corrections before 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: Draft Agenda to WSRM TC Conference Call – May 06, 2003

Preliminary Minutes of WSRM TC Conference Call –Jan 11, 2005


The meeting of the WSRM  TC took place by teleconference 

Tuesday, Jan 25 , 2005, from 5:30 to 6:38 PM Eastern Standard Time



1         Draft Agenda:


    1 Draft Agenda to WSRM TC Conference Call

    2 Roll Call

    3 Minutes Discussion

    3.1 Appointment of Minute Taker

    3.2 Approval of previous meeting minutes –

    4 Action Item Status Review

    5 Status of WS-Reliability Specification

    6 Status of Interop SC activities

    7 Next Step Documentation

    7.1 Editorial Clarifications and Errata

    7.2 Implementation Guidelines

    7.2 Future Enhancement Requests

    7.3 Composability with other WS-Specs

    8 Discussion of Future Meetings


2         Roll Call


First Name

Last Name






Cyclone Commerce











TC Chair

















NEC Corporation




NEC Corporation




Nortel Networks
















Sun Microsystems


Meeting is quorate.


3         Minutes Discussion


Tom Rutt will take minutes.


3.1      Approval of previous meeting minutes

The minutes of the 12/14 meeting are posted at:



The minutes of the 01/11 meeting are posted at:



Abbie Moved to approve the 12/14 minutes, Jacques seconded.


No opposition minutes approved


Alan moved to approve the 01/11 minutes, Jacques seconded.


No opposition, minutes approvesd



4         Status of Action Items

4.1      Action 090704-1 (Tom) Pending


Action: Tom will try to find, from previous minutes, a list of features we have put off for future versions and will post it to the list for discussion.


4.2      Action 113004-2 (Bob F and Interop SC) Completed


Action: Bob will work with the Interop SC to have them recast a next version of their feedback document using the following three categories (and taking into account the discussion at the F2F).


4.3      Action 121404-2 (Jeff M and Interop SC) Pending


Action: Jeff M will provide examples of soap header dumps with both ws-reliability and ws-addressing headers in use, as in the interop demo.


4.4      Action 011105-1 (Tom Rutt) Completed


Action: Tom will send an email soliciting comments on ws/reliability/ws-security composition document to the group..


4.5      Action 011105-2 (Tom Rutt) Completed


Action: Tom to post a pdf version of the ws-reliability/WS-Security composition document after the meeting


5         Status of WS-Reliability Specification

OASIS staff asked Tom Rutt to edit the wsrm TC group notes to remove the links from the OASIS TC Summary Page.


Tom updated the public and member web site pages for the TC to have a single announcement, which refers by URL to spec and  schema at the proper location on the OASIS web site.







The spec itself still shows status a CD.


Action: Tom will investigate how to change the status of printed document.

6         Status of Interop SC activities

Questions have been asked about public sites for testing spec.


There was discussion on the email list pertaining to the public domain implementation:


79811 donation to Apache ?? Mark Hansen 14 Jan 2005 14:13:05


80120 Re: [wsrm] donation to Apache ?? Kazunori Iwasa 18 Jan 2005 02:10:30


Iwasa stated he has no new information.  He has given this idea to the development team of the open source implementation.  He will relay any feedback to this TC.


7         Next Step Documentation


Tom Rutt obtained the text presented at the Face to Face, and edited the document to reflect discussions at that meeting.  The result was posted at:



There is a need for clarification on some of the implementation concerns expressed in the posted document.  The following excerpt is from the paper:

Req/Resp MEP Failure.


Consider the case of a request/response MEP. A client application makes a Web Service call in a synchronous way, and expects to get the results back (the business response data) on the same connection. This initial call goes through the sender RMP which would persist the message in its own database. The call for some reason does not succeed (e.g., the message is lost in the network). Without special mechanisms, the client application could be notified of the failure because a runtime exception (such as Time Out) is propagated up to the initial caller (which is the client application). At a later time, the sender RMP initiates the resend operation because the message it persisted in its database was not acknowledged. Let’s say the resending call succeeds this time, and the call is received by the Web Service endpoint, and a business response is propagated back to the sender RMP. With the above scenario, the sender RMP needs to know what to do with the business response.


Mechanisms are needed to let the client application know about ultimate failure (not initial failure), while enabling the sender RMP to give the business response to the client application when the operation invocation eventually succeeds?


Another fact to take into consideration is that the sender RMP may not be aware that a req/resp MEP is being used, because the sender RMP is deployed simply as a handler (an interceptor), and is not the initial caller (which is the client application).



Tom: the last paragraph might be the crux.  Can you implement the request response RMP without the sending MEP knowing that it is a request response rmp.


Jacques: the concern might be regarding the current soap stacks which implementers use.  The fault recovery models of these stacks might cause such problems.


Doug: I do not understand the background issue here.  In our spec we have not stated you taking an existing soap node, adding handlers to get a working rmp.  All this description is saying is that you do not want the application to call the pre existing soap node infrastructure, instead it has to invoke an intermediate layer.


Jacques: it is worth discussing this further to aid implementers.


Bob F: Doug had a good point there.  The origin was from people working quickly to reach an interop demo.  Some of their comments are colored by the tools which were at their disposal. We should not emphasize problems which would not exist in a clean implementation.


Tom suggested taking out the section and posting a revision on the web site.


Jacques: we should clarify this concern that it is a problem with one implementation approach.  We will try to extract what is the real concern and will post this as text for discussion in a more general way.


Tom: I hear no objection to taking out the section in a revision to be posted soon.


People should send comments on the posted document for discussion at the next meeting.


After these clarifications, the document needs to be separated into three separate documents corresponding to the following categories.

7.1      Editorial Clarifications and Errata 

Clarifications, editorial nits, interpretations of the actual specification,

which should be posted for others to see

7.2      Implementation Guidelines / Application Notes

Things to help implementers, which, would typically be specific to application environments.

7.3      Future Enhancement Requests

Proposed changes for future versions which would ease implementation or enhance protocol capabilities.

8         Composability with other WS-Specs

Jacques posted a contribution for discussion at:



From 1/11 minutes:

Jacques will act as editor, but will await input from others. Solicit comments on the original paper for discussion at next meeting Jan 11.


After the 1/11 meeting, Jacques posted the following update to the composibility paper:



Jacques clarified that this was only an editorial update.


Alan W posted the translation of a Japanese document regarding composition of WS-reliability with WS-Security at:



After the 1/11 meeting, Tom Rutt posted a pdf version of the ws-security composition document at:



Tom Rutt send an email soliciting comments on both of the above documents:

Soliciation for Member Comments Tom Rutt 12 Jan 2005 14:06:44


The following response was posted:

Kicking off the discussion of the WS-R and WS-S Composability document Alan Weissberger 14 Jan 2005 19:10:51


Alan stated that this mail was posted to spur further discussion.


Just before the meeting, Alan posted the following email:

Progression Plan for WS-R Composability document(s) Alan Weissberger 25 Jan 2005 16:26:27



Jacques and I propose a 2 phase approach to Composability of WS-R with other WS stds/specs:


Part I:  High level "Compsability Concepts" document, which describes: composability model(s), baseline assumptions for  SOAP HDR processing entities, composability requirements/ functionality, implications, etc.  Some examples and illustrations of ways to compose will be provided.  Implementation details will be contained in part II.


This document is targeted at a wide audience, which includes WS Architects, WS implementors that are using modular WS-R middleware (open source or otherwise), and technical decision makers (that probably have not participated in the WS-RM TC and are not intimately familiar with the WS-R standard).


Part II.  Composability Case Studies for WS-R and WS-Security


Detailed model and implementation guide for selected methods to compose WS-R and WS-Security, based on high level principles enumerated in Part I. "Compsability Concepts" document


This document is aimed at WS implementors that are working with WS-R and WS-Security middleware (open source or otherwise).  Sections of the translated "WS-R and WS-Security Composability" document will be included in this Case Studies document, as appropriate.


Note that the latter document assumes that the WS-R entity has intimate knowledge of the WS-Security entity such that they are implemented in the same SOAP HDR processing node.  Other models, such as a pipelined SOAP HDR processing in different nodes may also be considered as a separate case of composability.




Here are a few points to consider for the Part I Composability Concepts document:


-SOAP HDR processing entities are independent of each other and might be implemented in different nodes (or optionally, in the same node).  That is, both integrated WS-R and WS-S processing as well as pipelining of the SOAP HDR processing entities are permitted.  However, the modularity of SOAP HDR processing entities should always be assumed, even if extra HDR processing is the result.


-Routing of WS-R messages should not effect composability and the routing should be independent of the SOAP message contents.  That is, composability should not be constrained by any routing scheme.


-There are various ways to order the WS-R and WS-S entities.  For example, there may be cases where we have: WS-R then WS-S, WS-S then WS-R, WS-S then WS-R then another WS-S (say for encryption or authentication purposes).  In cases where there is no WS-S header, the WS-R entity will bypass the WS-S entity and pass on the received SOAP message body to the WS application entity.


-Encryption of only the SOAP message body, or the SOAP headers + message body should be considered as separate cases.


-Redundant processing of duplicate SOAP messages is permitted.  In some cases, redundant processing is a function of how the entities are ordered and that they are independent of each other.




Hopefully, we can get some email discussion going on this before the next WSRM TC call in early Feb 05.






Alan Weissberger



Alan gave a review of the email contribution:


  • To get approval of the direction
  • To stimulate email discussion on the part 1 composability document.


Jacques added some points.  The current ws-security/ws-reliability contribution from the Japanese companies, is addressing some requirements, however it is a assuming some restrictions in the architecture.  When new implementations have freedom to combine these two standards in a tighter manner, they may have a higher level of efficiency (e.g., do not repeat things unnecessarily for duplicates).  There are multiple ways to compose ws security and ws reliability.


The first part of the document will talk about these different implementation levels of composability.


Alan: we can look at two types of model:

Integrated model (entities are designed to work together)

Modular model (entities have no knowledge of other’s existence)


Tom: So Jacques contribution should be directed at part 1 document.


Abbie expressed an interest.  <abbieb@nortelnetworks.com>  Task force Jacques, Alan,  Abbie,. and Bob F.


Alan: we propose the preceeding contributions be directed at these two documents.  The task force will determine what goes into the second document.


Bob F: are we facing a fundamental issue with composability?


Alan:the translated document describes one particular way to compose ws-security and ws-reliability.


Bob F: Do you see any composability issues, or are you just discussing implementation guidelines.


Alan: we do not see any problems with the spec in the area of composability


Tom: do we need a document on defects in the specifications with regard to composability.


Alan: we may need such a document in the future, but have not found such problems yet.


Bob F asked to be added to the composability task force.   He stated he as interested in aligning it with the basic security profile.


Jacques: we would like to ensure that different processing models do not result in any difficulties.


Doug B: We are talking about an implementation guide, but now we are talking about delving deeply into that part. We had discussed in the past the need for general implementation guidelines.  Here we are talking about specific guidelines about ws security and ws –reliability aspects. 


We need to also work on the general implementation guidlelines, using feedback from interop SC.


Alan: I think that we need consensus in the group on what is needed for ws- security and ws-reliability composability.   This is a high priority.


Tom: we also have to pursue and progress the other documentation.


Doug B: I was just concerned about the earlier discussion on the need for multiple methods of composition.


Jacques: Some of the work we are doing might go into an implementation guidelines document.  I would like an abstract processing model with multiple soap headers.  Going beyond this might also be put into a specific implementation guidelines.


Tom: there is an existing call to have members look at the translated document and add scenarious they would like to see in the guide.


1         Discussion of Future Meetings


when is the next Face to face?


Third or fourth weeks March are both candidates.   Get a better idea at the next meeting.


Tom: do we want to add a short meeting at the OASIS symposium, wed 27, thur 28.


Alan we could spend a ˝ day on composability work.


Tom: we could get a day in.


Jacques will check if we can get a free room;


Pete : I do not believe there will be a charge.


Talking about a Two day meeting in either case.


Bob: I suggest you just ask for two days and see what we get.


Action: Tom and Jacques will see if they can get two days for our TC at the Symposium.


At Jan 11 meeting, we agreed to continue schedule of 90 minute teleconferences every two weeks, from Jan 11.


Jan 11, Jan 25, Feb 8, Feb 22,


Tom:  I will extend the existing two week sequence until the end of March..


2         New business:


Bob: I would like to introduce the concept of progressing this specification to ISO for their purposes.  It is potentially feasible for us.


Tom:  OASIS has been granted PAS (Publically Available Spec) Submitter status by ISO/IEC JTC1, and can now.submit specifications to be voted on as a fast track ISO standards.


Bob: people should discuss whether we should do this for ws-reliability on the list, and it should be put on the agenda for next meeting.


Tom: action – put out a summary of what PAS process is.


Bob F moved to adjourn, Mark Peel seconded.


Meeting adjourned at 6:39 PM EST.

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