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 Wed F2F meeting

The wed prelim minutes are attached

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 WSRM TC Face to Face Meeting –November 10 and 11, 2004


Face to Face meeting held at

Fujitsu Software Corp

        1250 Arques Avenue, Building A, Sunnyvale, CA 94085

        Conference Room: Montego/Barbados


1          Draft Agenda:

Conference Bridge number Toll only : 1-512-225-3050 Participant code: 385218#    for Wednesday Nov 10, 9:00 AM to 11:00 am Pacific time.


    1 Draft Agenda to WSRM TC Meeting


[Wednesday Nov 10]

8:30 AM – coffee and introductions

9:00 AMTeleconference Bridge opens

     2 Roll Call

     3 Minutes Discussion

     4 Action Item Status Review

     5 Progression Vote For WS-Reliability after Member Vote

     6 Discussion of Press Release, Member Quotes, and Talking points

10:30 AM Teleconference Bridge Closes – break begins

10:45 AM

     7 Discussion of ongoing Errata Process

     8 General Discussion of Implementer’s Guide

12:00 PM - Lunch

1:00 PM

      9 Discussion of White Paper by Alan W

      10 General Discussion of Composition with other Web Services Standards

      11 Discussion of Composition with Web Services Security Standards

3:30 PM Break

3:45 PM

       12 Discussion of Future Enhancements for Version 2

5:00 PM Homework Assignment review and meeting recess


[Thursday Nov 11]

8:30 AM – Coffee

9:00 AM

       13 Report of Interop SC with possible demo

10:30 : Break


       14 Review of Homework Assignments

       15 Continuation of Future Work Items Discussion

12:00 Lunch


        16 Continued Discussions of Press Release talking points

        17 Future meeting planning

3:00 PM  Meeting closes


2          Roll Call


First Name

Last Name






Booz Allen Hamilton




Cyclone Commerce











TC Chair

















NEC Corporation




NEC Corporation




Nortel Networks




















Sun Microsystems




Sun Microsystems


 Meeting is quorate.


3          Minutes Discussion

3.1      Appointment of Minute Taker

Tom Rutt will take minutes.


Minutes will serve to record issue resolutions.

3.2      Approval of previous meeting minutes

The minutes of the October 19eleconf are posted at:



Alan moved to approve, Iwasa seconded.


No opposition, minutes are approved.


4         Status of Action Items

4.1      Action 052503-1 (Tom Rutt) closed

Tom took an action item to complete the status column of 
pre public review issues list, with correct URLs.
Completed Pre CD .992 issues list with resolutions was posted at:


4.1      Action 060104-5 (Jacques) Pending


Action: Jacques, will propose further edits, on the FAQ for composability.


Still open, low priority


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


5         Progression of WS-Reliability Spec after Member Vote

The Ballot closed on October 31, 2004


Voting Summary:


# Votes

% of Total








Eligible companies who have voted:

90 of 367



Text accompanying the No Vote from SAP is at:

·  SAP comment with No Vote for WS-Reliability

From Tom Rutt <tom@coastin.com> on 2 Nov 2004 21:29:34 -0000

Reasoning for SAP AG’s “No” vote on making the OASIS Web Services Reliable Messaging TC’s WS-Reliability v1.1 Committee Draft an OASIS Standard


The WS-Reliability v1.1 Committee Draft contains an optional, but normative appendix ("Appendix B. WS-Reliability Features, Properties

and Compositors") that introduces a means to advertise RM capabilities in WSDL 1.1.


There are several issues that led SAP to vote “no” on making WS-Reliability a committee draft in the first place (see http://www.oasis-open.org/apps/org/workgroup/wsrm/ballot.php?id=392&) and that still hold true:

·    The specification appears to be back porting the features and properties concept, which is currently part of WSDL 2.0. However, it also adds a new “compositors” concept to WSDL 1.1, which is not part of WSDL 2.0. This addition breaks the intended forward compatibility.

·    The mechanism is optional, which does not help to achieve interoperability.


SAP strongly believes that this is the wrong place to add such generic functionality.


As far as the compositor concept is concerned, there have been previous attempts to gain support from the W3C Web Services Description Working Group (WSD WG) for introducing the concept in WSDL 2.0, but the WSD WG has denied doing so (for example, see http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0039.html ). Besides the minority opinion to still introduce this concept (see http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0371.html ), there is also a minority opinion to completely remove the features and properties concept from WSDL 2.0 (http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0375.html  and http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0395.html ). After having the W3C Workshop on Constraints and Capabilities for Web Services (see http://w3.org/2004/06/ws-cc-cfp.html), it seems very likely that the W3C will establish a separate working group for this very subject and that it will be scoped to develop a technology more flexible than the features and properties concept.


Ignoring these developments and introducing a generic concept in a domain-specific specification now will most likely lead to inconsistency with core Web services standards in the future.


A draft response to this comment was prepared by Tom Rutt and Jacques Durand at:

·  Rationale for Approval Despite SAP NO Vote

From Tom Rutt <tom@coastin.com> on 10 Nov 2004 01:43:29 -0000

The WSRM TC has considered the SAP comments accompanying their NO vote on the OASIS WS-Reliability Specification.


There is currently no standard to represent the RM capabilities associated with a Web Service.


Appendix B of the WS-Reliability specification (i.e., Features, Properties and Compositors) provides a normative WSDL 1.1 extension mechanism to meet this requirement.


This mechanism is normative, but optional for conformance to the WS-Reliability Specification.  This provides one mechanism which may be implemented today to realize this requirement, but does not preclude usage of future standard mechanisms (e.g., for WSDL 2.0).


Without specifying a representation of reliability capabilities that a WS endpoint can advertise, web service providers and web service users would have to define their own ad-hoc ways to represent and exchange such capabilities. The current specification provides a WSDL extension

for describing RM capabilities which, even though optional, will facilitate interoperation for those who decide to use it. We do not think the optionality weakens interoperability in this case, as SAP

claims. We believe that not specifying such a feature at all would make it harder to agree on a representation mechanism between partners.


The WSRM TC (subject to Vote on Nov 10) agreed to request the OASIS TC Administration to approve the specification as submitted despite the SAP negative vote.



Jaques stated a better resolution would be “we discussed this before with SAP, on the CD .992 Vote, and decided to go forward”.


Iwasa moved, Abbie seconded to approve the following resolution:

The WSRM TC requests the OASIS TC Administration to approve the WS-Reliablity Specification as an OASIS Standard, despite the single no vote from SAP.  The committee discussed the concern of SAP, which also accompanied their NO vote on CD. .992, and agreed at that time to go forward with Appendix B as a normative, but optional, part of the specification.


No opposition, motion passes.

6         Discussion of WS-Reliability Press Release

Carol Geyer prepared a Draft Press Release at:

·  Member Quotes for Draft OASIS Press Release: WS-Reliability dueNov 9
From Tom Rutt <tom@coastin.com> on
6 Nov 2004 19:04:03 -0000


The meeting produced the following edited version of the press release (minor changes):


WS-Reliability Ratified As OASIS Standard


Booz Allen Hamilton, Cyclone Commerce, Fujitsu, Hewlett-Packard, Hitachi, NEC, Novell, Oracle, SeeBeyond, Sun Microsystems, and Others Produce Open Standard for Guaranteeing Message Delivery to Web Services



Boston, MA, USA; 15 November 2004 -- The OASIS international standards consortium today announced that its members have approved WS-Reliability version 1.1 as an OASIS Standard, a status that signifies the highest level of ratification. Developed through an open process, WS-Reliability provides a method to guarantee message delivery over the Internet, enabling companies to conduct reliable business-to-business trading or collaboration using Web services.


"Reliable message delivery is one of the key issues to be addressed if there is to be widespread adoption of Web services, particularly in business-to-business scenarios," said Neil Macehiter, research director at Ovum. "Communications using Internet-based protocols, such as HTTP and SMTP, are inherently unreliable and do not support the assured or ordered delivery demanded by the applications on which businesses depend. WS-Reliability, being an approved OASIS Standard developed in open forum that addresses these limitations, is an important step on the path to realizing the promise of Web services."


WS-Reliability supports guaranteed delivery, which ensures the message is delivered at least once, duplication elimination, which certifies that the message is delivered at most once, and message delivery ordering, which guarantees messages in a sequence are delivered in the order sent.


"Financial transactions are just one example of the kind of applications that need WS-Reliability to meet quality-of-service standards. A message requesting a money withdrawal, for instance, must be received by an application once and only once," noted Tom Rutt, chair of the OASIS Web Services Reliable Messaging (WSRM) Technical Committee. "With the WS-Reliability OASIS Standard, information can be shared between software programs over the Internet as reliably as within a single application on a laptop."


Patrick Gannon, president and CEO of OASIS, applauded the efforts of the technical committee members who produced the new standard, recalling, "The genesis for WS-Reliability was submitted to OASIS in March 2003 by Fujitsu, Hitachi, Oracle, NEC, Sonic Software, and Sun Microsystems. These companies recognized the importance of advancing their work within an open process where the entire community of vendors, users, and governments could contribute. Today's approval of WS-Reliability as an OASIS Standard is proof positive that it is possible to garner broad input on the development of a standard and still meet time-to-market needs."


Participation in the OASIS WSRM Technical Committee remains open to all organizations and individuals. OASIS hosts an open mail list for public comment and the ws-reliability-dev mailing list for exchanging information on implementing the standard. WS-Reliability is provided on a royalty-free basis.



Industry Support for WS-Reliability OASIS Standard:





Additional information:


OASIS WSRM Technical Committee



About OASIS:

OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. Members themselves set the OASIS technical agenda, using a lightweight, open process expressly designed to promote industry consensus and unite disparate efforts. The consortium produces open standards for Web services, security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 3,500 participants representing over 600 organizations and individual members in 100 countries. Approved OASIS Standards include AVDL, CAP, DocBook, DSML, ebXML, SAML, SPML, UBL, UDDI, WS-Reliability, WSRP, WSS, XACML, and XCBF.



Press contact:


Carol Geyer

OASIS Director of Communications


+1.978.667.5115 x290


6.1      Discussion of Draft Press Release

The group made some minor edits to the draft press release.

6.2      Discussion of Talking Points for Press Interviews

The group discussed some potential talking points, for use by members of the committee who have volunteered to be press contacts for the committee.


7         Discussion of White Paper by Alan W

·  Latest revised WS-R Whitepaper attached- to be published in Grid Today
From "Alan Weissberger" <ajwdct@technologist.com> on 10 Nov 2004 19:01:14 -0000


The group provided feedback to Alan W.  He will send a URL for the white paper to the list after it is published.

8         Discussion of ongoing Errata Process

The Interop SC provided a set of feedback comments, as an input to the errata process.


Some of these comments are pointing out needs for clarification, while others are requests for future enhancements to the specification.


It was agreed to address these comments at the Thursday portion of the meeting.


A set of errata can be published by the TC either informally or formally as a CD.


Jacques: conformance to the previous spec is not affected by errata documents.


Clarifications of Ambiguities, and editorial changes, which may help implementations, could be published informally.


An Implementer’s guide could serve to document clarifications to aid implementers.  It could be a living document, which is updated when required to add new clarifications on the WS-Reliability Specification.


If we decide to progress a new version of the specification, we could include some of the responses to these items in that new version.


9         General Discussion of Implementer’s Guide

One of the types of information this could hold is clarifications for implementer’s.


Alan: WSRF has the concept of an application note, which serves the same purposed.


Alan:  WSN has several additional specs, like primers.  Some issues are resolved by having best practices documented in a side spec.

10    General Discussion of Composition with other Web Services Standards

·  RE: [wsrm] Input for FAQ question
From Jacques Durand <JDurand@us.fujitsu.com> on 6 Apr 2004 17:27:19 -0000

Title: RE: [wsrm] Input for FAQ question


A way to approach the composability with other WS-* specs is that they

are likely to fall under these (fuzzy) categories :


(a)- "Under WS-R": Add-ons to SOAP transport like routing, addressing,

that WS-R may need to accommodate or profile.

Status: nothing in the open space yet...


(b)- "Supporting WS-R" specifications (policies, WSDL annotation), that support some function

assumed by WS-R but not central to its deployment:

Status: not finalized or not open.


(c)- "Complementary to WS-R" specifications (Security, transactions, Context...)

that support other business requirements requirements likely to be used in conjunction with reliability, and share message footprint.


Soap headers composability and processing model make this possible. Apparent redundancy (message ID, reply address..) should not be an issue.


Appropriate profiling and guidelines may apply.


(d)- "Over WS-R", Higher level specifications (BPEL, Choreography, CAF, ASAP...)

would use/profile reliability, not the reverse.


That may help a bit I hope. Our focus would be on (c) this time.




We should ask for input to this discussion.


WS-Security has already been signaled out as an important spec to compose with.


WS-Context is one candidate for composition.


In the Future, WS-addressing might be a candidate for composition (e.g., specify a reference mechanism URI to use in the Reply-To element.


Jacques: One aspect of composibility is fault handling.  If another WS protocol generates a soap fault, due to a protocol error, the sender may not want to resending in such cases.

11    Specific Discussion of Composition with Web Services Security

Once we have this work done, we could decide to publish it as a CD, without public review. 


We could also have it go thru the formal standards process at OASIS.


The TC could decide how to best progress such a document, after the work is almost completed.


Question: which header elements from WS-Reliability are sensitive enough to warrant protection by WS-Security:

  • Reply-to
  • Expiry Times


The ws-reliability headers, in some cases, need to be protected.


We may need to identify and potential constraints on how to use ws security with ws-relibility (e.g., Sender needs to process security after WS- reliability, receiver needs to process security before WS-Reliability).


Members are invited to post contributions on this topic.  We can decide on how to publish any outputs after the work is underway.

12    Discussion of Future Enhancements for Version 2

12.1Reliability for Response message

Jacques led a discussion on the nature of the problem for providing reliability assurances for the response message of a request/response exchange.


This requires a refinement of the definition of guaranteed delivery: the request must be resent if the response is not received by the sender.


The receiver is not notified that the response is not delivered unless the sender does something special (i.e., no three way handshake).


The sender could send a special ack to the receiver that it got the ack with the response to the original request.


With synch request/response, the rm-ack is bundled with the response payload, this gives the proper behavior for guaranteed delivery. However, the response is not acked, so there is no way for the original sender to return a fault on the response.


Jacques: we need to redefine the definition of reliability for the response, it cannot be defined the same way as for reliability of the request message.


Question: can a receiver of a request response operation place a wsrm:request header (with a callback reply pattern) in the response to the original request?  It is unclear why anyone would want to do this, since the response guarantee comes for free, given the lack of resend.


Questions for duplicate elimination for the response: one way is duplicate elimination or ordered deliver of response could be tied to the same requirement level as the request.


Questions for Ordered delivery for the response.




For one way, the same message must be resent, in its entirety.

12.2Wrapper Element for WS-Reliability Soap Headers


12.3Other Capabilities Deferred to Next Version


13    Report of Interop SC with possible demo


14    Review of Homework Assignments


15    Continuation of Future Work Items Discussion


16    Continued Discussion of Press Release Talking Points


17    Future meeting planning

In general, it was agreed to have every other week meetings in general.


When there is a conflict with another F2F meeting (e.g., WS-Addressing on Dec 7) we can agree to change the specific week for our meetings.


1.5 hours per conference call, on Tuesdays, 5:30 PM to 7:00 PM Eastern Time.


Next agreed call dates: Nov 30 and Dec 14.


It was agreed to decide on the next meeting cycles at the Dec 14 meeting.

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