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 New Orleans F2F

The prelim minutes of f2f minutes are attached.

Please provide corrections by the end of next week.

Tom Rutt

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

Prelim Minutes of WSRM TC Face to Face in New Orleans

Thursday April 28

9:00  Meeting opens,  Bridge starts. (1-512-225-3050 code 953641# )


1         Agenda Review and Refinement

Draft Agenda:

1   Agenda Review and Refinement

2   Roll Call

3   Minutes Discussion

3.1            Appointment of Minute Taker

3.2            Approval of previous meeting minutes

4   Action Item Status Review

4.1            Action 121404-2 (Anish) Open

4.2            Action 012505-1 (Tom Rutt) Pending

4.3            Action 020805-2 (Tom Rutt) open

5   Status of WS-Reliability Specification

6   PAS Progression Discussion

7   Charter discussion

8   Next Step Documentation

8.1            Finalization of Errata

8.2            Future Enhancement Requests

8.3            Implementation Guidelines

9   Scheduled Vote to post Errata as CD

10 Composability with other WS-Specs

10.1          Composability Analysis

10.2          WS-Reliability and WS-Security Composition

10.3          Discussion of Liaison with WS-RX TC

11 Future Meeting Discussion


2         Roll Call

First Name

Last Name













TC Chair




Voting Member




Voting Member




Voting Member




Voting Member

NEC Corporation







Voting Member - Prob




Voting Member




Voting Member




Voting Member





SOA Software Inc.




Sun Microsystems*


Meeting is Quorate.

3         Minutes Discussion

3.1      Appointment of Minute Taker

Tom Rutt agreed to take the minutes

3.2      Approval of previous meeting minutes




Bob F moved to accept minutes.  Anish Seconded.


No opposition , minutes approved.

4         Action Item Status Review

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

4.2      Action 012505-1 (Tom Rutt) Pending

Action: Tom will investigate how to change the status of printed document.  The posted standard still states CD.

Continuing action, need standard number from OASIS staff

4.3      Action 020805-2 (Tom Rutt) open

Action: Tom will investigate how to post the three OASIS pas documents on our server.

 Jamie Clark is investigating how to get the documents on the OASIS Site.

5         Status of WS-Reliability Specification



Chair’s Goal: finalize Cover Page and footers for official posting of standard.  Above URL for proposed document for posting.


Jamie will give final cover page by end of f2f Meeting.

6         PAS Progression Discussion

Chair’s Goal: determine whether TC wants to continue to push OASIS staff to progress WS-Reliability 1.1 as ISO/IEC JTC1 standard through OASIS PAS process.


Jamie Clark has confirmed that we can post the PAS documents associated with OASIS.  PAS status is a class that JTC1 grants in 6 month increments.  OASIS will continue to have PAS status until at least the end of 2005.


After that OASIS will revisit the issue as to whether we will keep the status.


Jamie stated that the OASIS Liaison policy states that OASIS can decide to send specs to outside bodies.  There are several ways, to send OASIS docs to orgs:

- OASIS keeps control of evolution,

- OASIS will transfer Control of evolution


The WSRM TC has asked that OASIS staff consider submitting ws-reliability as the first type of PAS doc (OASIS keeps maintenance responsibility).


Two EBxml standards have been progressed as ISO standard (15000 parts 1 thru 5)


Jamie asks that we read the Liaison rules. http://www.oasis-open.org/committees/liaison_policy.php


Tom asked whether we should continue to pursue the PAS progression of WS-Reliability.


Anish stated there is no need to change our course as of this time.


Tom: If we do nothing, OASIS will continue to pursue progression thru PAS process as full ISO standard.


Consensus of meeting is to let OASIS staff continue work to progress WS-Reliability 1.1 as an ISO standard, with OASIS controlling the maintenance.

7         Charter discussion


Chair’s goal: discuss the future activities of the WS-RM TC, and possible charter Amendments to enable these activities.


Jacques: we might consider charter changes to allow the TC to provide requirements and other contributions, from our perspective, for other related Web Service standards groups.


Defer until after discussion of the Future enhancements list.


Agreed that the TC should wait for further discussion of the proposed enhancement list, before reconsidering the charter for this TC.


We also have to consider that a charter change may impact the IPR transition status of the TC.


We also need to consider when we make a transition (if ever) of the group to the new IPR rules.


Jeff: after more than 50% of the members have signed the new membership agreement with OASIS, any one of them could propose that the TC transition to the new IPR status.


Tom: I will send a mail out to the list that observers can no longer post to the list.


8         . Next Step Documentation

8.1      Finalization of Errata




Chair’s goal: finalize errata, in preparation for Vote to post as CD in afternoon session.


Section1 was agreed to be included in the errata.



Section 2.1.1:

Jacques: clarification is that the tables should be read line by line.


Jacques and Pete agreed to recast the tables in a more clear format and distribute as a new errata for vote.


Section 2.1.2:


Agreed to change offending sentence to:


Errata Change offending sentence to:

In case GuaranteedDelivery is not required, remove the group immediately. Otherwise, remove it if every message has either been acknowledged or faulted


Section 2.1.3:


Agreed to change offending sentence to:


“ Remove the group after every message has either been acknowledged or faulted.”


8.2      Future Enhancement Requests




Chair’s Goal: review the futures list above, to prioritize potential enhancements required by industry.


The meeting went through the document, and produced a shorter list of future enhancement request, posted as:  http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/12436/wsReliabityFutureFeatures.htm


Comments on this new Future enhancements document are requested.

8.3      Implementation Guidelines




Chair’s Goal: determine progression plan for above document


Agreed that 1.1 and 1.4 are not of concern, and should be removed from the next version of this implementers guide.


Agreed to discuss 1.2 and 1.3 at the meeting.


1.2       Error Handling Edge Cases

The implementation Guidelines could give advice on elements to include in error responses for some of the corner cases described in the following list.


Error Status codes are described on page 39. There are some implementation concerns related to RM faults:

           According to the first row, the fault code “InvalidRequest” MAY be generated if MessageId is missing. This seems to be not possible if the RMP fault message needs to have a reference to the groupId, when it does not exist in the request message.


Suggest using ""  as anyURI value for this case in Fault message


           If the RMP replyPattern is missing, what is to be done with the RM fault (how to send it and to where?)


It is permissible for the Receiving RMP to not return the fault (.e.g, log it).

It may also be permissible in some cases (eg, if the wsdl operation is not ONEWAY) to return the wsrm:response header on the underlying HTTP response.


           If the replyPattern is callback and replyTo is missing, where is the fault sent?

It is permissible for the Receiving RMP to not return the fault (.e.g, log it).

It may also be permissible in some cases (eg, if the wsdl operation is not ONEWAY) to return the wsrm:response header on the underlying HTTP response.



           The case of “InvalidMessageId” fault code due to a missing groupId needs special handling, if the RM fault message needs a reference to the groupId.

It is permissable to respond with "" for the groupID anyURI value in such a case.


           When many error combinations occur (for example both attributes “number” and “groupExpiryTime” are invalid), what should be used for the RM fault code (InvalidMessageId or InvalidMessageParameters)?

There should be implementation freedom in this case.  The standard does not need to set up a precedence order for reporting faults.


1.3       Message Combination Concerns.


The WS-Reliability 1.1 specification does not mention the possibilities of combining RMP signals with business request/business response messages. By default, silence is always interpreted as not prohibited. So, since the specification does not mention message combinations, this means that one can mix RMP signals with business messages. This however introduces implementation concerns because the WS-Reliability headers were not designed to handle some circumstances.


To explore the possibilities, consider two mathematical sets: set A, and set B. Set A contains three elements, while set B contains four elements:


A = {B1, B2, B3}                               (3.1)

B = {R1, R2, R3, R4}                        (3.2)


The product set A x B = {(a, b) : a in A and b in B} would contain 3 × 4 = 12 elements. The interpretation of the symbols used in these sets is as follows:


           B1: this means a message has request business payload data

           B2: this means a message has response business payload data

           B3: this means a message has no payload data (i.e., no payload data in its SOAP Body, and no attachments either)

           R1: this means a message contains RM Ack headers

           R2: this means a message contains RM Fault headers

           R3: this means a message contains an RM PollRequest header

           R4: this means a message contains an RM Request header


Therefore there seems to be 12 possible message combinations.


The last combination which is (B3, R4) is not possible because there would not be a message having an RM Request header without any payload. Removing this case, there are 11 combinations. Some of these combinations have concerns.


The following combinations have concerns: (B1, R1), (B1, R2), (B1, R3). When receiving these three messages, the receiver RMP has no way of determining whether the message has a request business payload or not.


One answer for (B1, R1), and B1, R2) is the sending RMP has to look into the body, in some cases, to determine if there is a payoad in the rm-response, to deliver back to the sender using the "notify" primitive.


One answer for (B1, R3) is that this combination is outside the scope of the specification.  The response in such a case is not specified by the standard.


1         Scheduled Vote to post Errata as CD


Chair’s Goal: vote errata (as edited in morning session) to CD status, and post on OASIS web site as referenced from posted ws-reliability standard.




Pete moved to progress the above errata as CD1.0, and to post on the OASIS site as referenced from the posted WS-Reliability Standard. Seconded by Bob F.


No opposition, motion passes.  8 voting members present at time of vote (>50% voting members).

2         Composability with other WS-Specs

2.1      Composability Analysis



Chair’s goal: release an edited version of the above document for widespread review inviting comments from other OASIS TCs and W3C WGs.


Jacques provided an overview of the analysis document.


There were several comments raised on the draft.


Jacques will provide a new document for review at the next TC teleconference.


Jacques pointed out that this paper my lead to better characterization of how to compose ws-reliability with other specs.


Tom: I would like to have this paper be put out for a wider review by other web service standards people.


Bob: I have some concerns that this work could be pushing outside our charter.  Relatively little of the general case is chartered here.


Jeff: there are not groups working on this level of composition analysis.  However, we need to discuss how to compose with ws-security, and in the future ws-addressing etc.


Doug: I cannot see how releasing this document would affect any of the deliverables of this TC.


Jacques:  It would just clarify the meaning of composability, so we would know more precisely what we mean by it.  It might only affect the definitions we would use in any of our work on composability.  I have not seen any satisfying definition of composability in the industry.


Jacques: I can do another iteration to take into affect the comments we took.


Bob: would not your membership in the OASIS TAB be a venue for further discussion.


Tom: I wanted to have this be a TC document with some status before sending it out for review.


Jeff: nothing stops you from sending it as a company paper.


Bob: I believe that the right thing to do is put it in the contributions folder, and those authors should start distributing emails pointing to it.


Bob: I move to encourage the authors of this paper make it available to a wider audience, at a time and a manner at their choosing. Jeff Seconded.


No opposition, motion passed.


2.2      WS-Reliability and WS-Security Composition




Chair’s goal: Given no comments have been posted, discuss progression plans for the above document.


There is an open call for new use cases to include in this spec.


Agreed to wait for further contributions on this topic (e.g, Anish action item response).


2.3      Liaison with WS-RX TC

Bob: our TC requirements could serve as a basis for an analysis of how the following two xmlsoap.org ws-reliable messaging specs (2/5) relates to these requirements.


Web Services Reliable Messaging Protocol (WS-ReliableMessaging). February 2005.


Web Services Reliable Messaging Policy Assertion (WS-RM Policy). February 2005


Tom: TC members should provide contributions a gap analysis between our TC requirements and the above reference specs.


Contributions are solicited from TC members for discussion at the May 17 Teleconf on how the specs reference above meet (or do not meet) our requirements.


Contributions should focus on uses cases that one can or can not accomplish with each specification.


Tom: I will be put this gap analysis on the agenda for the May 17 teleconference meeting.



3         Future Meeting Discussion

Agreed to the following:

    Resume bi-weekly Tuesday 5:30 PM 60 Minute meetings starting May 17.


    Leave Next F2F timing and location TBD.  Put on agenda for May 17 telecom.



At 5:00 PM, Central Time, the meeting adjourned.

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